Modélisation · Reprise des données legacy
Reprise des données legacy — cibles de migration
Quels schémas doivent être créés, lesquels reçoivent réellement des données du legacy, et à quel service correspond chaque source (LOGESIN, LOGPROD, bordereaux, GED). Cette page cadre la cible de la reprise et l'aligne sur le découpage en microservices.
Principe : qui crée quoi
La migration ne crée pas de base cible « à la main ». Chaque service a sa propre base PostgreSQL, créée déclarativement par CloudNativePG (Database CR, en GitOps), et versionne ses tables via Liquibase (versionnées, épinglées — ADR-0002). Le chantier de reprise charge les données par fan-out dans ces bases déjà définies. Il ne faut ni écrire de DDL cible « à la main », ni regrouper les services par processus. (Choix « une base par service » plutôt que « un schéma par service » — cf. Exploitation › Socle GitOps.)
Deux questions à ne pas confondre :
- Persistance au runtime — le service possède-t-il un schéma quand le système tourne ?
- Cible de reprise — ce schéma reçoit-il des données legacy lors de la migration ?
Sur les 20 services, 15 ont un schéma métier au runtime ; les 2 BFF et les 3 edges n'en portent pas au sens métier (voir plus bas). Après confrontation aux compteurs réels des deux bases legacy, 8 schémas sont chargés par la reprise (dont un partiellement), 1 attend un arbitrage de périmètre, 1 est sans source applicative, et le reste démarre vide ou est alimenté autrement.
15schémas métier
8chargés
1périmètre à trancher
1sans source applicative
Statuts révisés après le retour du chantier migration (21/07/2026). Chaque ligne a été confrontée aux compteurs réels documentés (LOGESIN §5, LOGPROD §4) : 8 lignes validées telles quelles, 5 périmètres précisés, 1 statut corrigé (svc-field-inspections, trop prudent). Le contenu minimal en tables de chaque schéma, l'intégration point par point du retour et les écarts constatés entre modélisation, code et infrastructure font l'objet d'une page dédiée : Schémas de données — contenu minimal.
Les 20 services face à la reprise
Lecture de la colonne « Schéma runtime ». Elle exprime une intention de modélisation — le service possède-t-il un schéma quand le système tourne — et non un état constaté en base. L'état réel (modélisé / provisionné en staging / créé par Liquibase) est établi service par service dans Schémas de données §3. Côté chargement, le pipeline de reprise vérifie la version de schéma cible (changelog Liquibase, ADR-0002) avant tout chargement et s'arrête proprement en cas d'écart.
| Service | Schéma runtime | Reprise | Données portées | Source / justification |
|---|---|---|---|---|
| svc-reference-data | ✅ | À CHARGER | Référentiels : assureurs (19 compagnies), établissements de santé, experts médicaux, acteurs juridiques, paramètres réglementaires. | Tables de référence LOGESIN/LOGPROD + bordereaux (liste des compagnies) |
| svc-claims | ✅ | À CHARGER | Dossiers sinistres, victimes, ayants droit, accidents, consentements. | LOGESIN (aiew1598_fgsin · 38 tables) |
| svc-medical-care | ✅ | À CHARGER | Demandes de prise en charge, bons, lettres de garantie. À CONFIRMER feuilles de suivi et prescriptions. | LOGESIN — autorisation_pec : 363 lignes, acte : 875. En revanche suivi : 2 lignes → les feuilles de suivi et les prescriptions restent à confirmer au profiling. |
| svc-medical-billing | ✅ | À CHARGER | Factures médicales, dossiers de facturation, contrôles. À CONFIRMER détail de facturation. | LOGESIN — depense : 1 087 lignes ; mais acte_frais : 5, acte_fournisseur : 2 → le détail de facturation est quasi vide. Arbitrage depense : facturation ou décaissement, à charger une seule fois. |
| svc-compensation | ✅ | FINANCIER + INSTRUCTION | Dossiers d'indemnisation et montants à charger ; missions et rapports d'expertise, offres, protocoles selon décision n°2. | LOGESIN — les 61 dossiers d'indemnisation et leurs montants sont en base (reprise du volet financier quasi certaine). C'est l'historique d'instruction qui n'y est pas : reprise GED seule vs ressaisie ciblée (décision n°2). |
| svc-compensation-engine | ✅ | PARAMÉTRAGE | Barèmes et versions de barème, calculs d'attribution. | Paramétrage initialisé — pas de reprise transactionnelle |
| svc-contributions | ✅ | À CHARGER | Lignes d'attestation (assiette), journal d'import et rejets, bordereaux de production/recouvrement, contributions État et non-assurés. | LOGPROD seul (fga_production · 12 tables). La table attestation contient déjà le résultat de l'import des bordereaux : c'est elle la source de vérité, et elle seule est chargée. Les bordereaux Excel ne sont pas une seconde source — les charger aussi produirait un double comptage de l'assiette des 2 %. Leur rôle : justificatifs MinIO liés au journal d'import, référentiel compagnies, jeux de tests de parité, rattrapage des seuls bordereaux jamais importés. Détail et tables cibles. |
| svc-field-inspections | ✅ | À CHARGER | Programmes, missions et rapports de contrôle terrain, vérifications d'attestation, infractions. | LOGPROD — controle : 35 153 lignes (≈ 13 Mo) + observation. La matière est documentée. Ce qui reste au profiling est la qualité du rapprochement contrôle ↔ production (par immatriculation / n° d'attestation), pas l'existence des données : ce service est dans le chemin nominal du fan-out. |
| svc-statistics | ✅ | RECALCULÉ | Lots RC auto, jeux de données statistiques. | Recalculé à partir des données reprises — pas de reprise directe |
| svc-debt-recovery | ✅ | SANS SOURCE | Créances, dossiers de recouvrement, mises en demeure, relances, saisines. | Aucune source applicative : les pénalités et créances sont gérées hors système (processus manuel, RG-18). Le profiling ne tranchera rien ici — reste à obtenir du client où elles vivent aujourd'hui (Excel, comptabilité) pour une initialisation par reconstitution. Chantier à part. |
| svc-payments | ✅ | À TRANCHER | Ordres de paiement, encaissements, rapprochements. | depense (1 087 lignes) est revendiquée par ce service et par medical-billing. Même matière : à charger une seule fois. Règle proposée : la dette facturée → medical-billing, le décaissement → payments. Bénéficiaire en texte libre → rapprochement à faire. |
| svc-documents | ✅ | À CHARGER | Métadonnées documentaires : modèles, documents générés, entrées d'archive. | GED (9 familles de chemins → références) · fichiers vers MinIO (GED applicative, ADR-0008). L'inventaire disque et le contrôle d'existence des chemins vivent dans la base pivot, pas ici. |
| svc-notifications | ✅ | VIDE | Modèles et préférences de notification, envois. | Configuration — aucun historique repris |
| svc-signatures | ✅ | VIDE | Demandes et preuves de signature. | Runtime — rien à reprendre |
| svc-audit-trail | ✅ | VIDE | Journal d'audit. | Aucun historique (sauf décision de rejeu d'événements) |
| portal-bff | — | SANS BASE | Agrégation d'écrans pour le portail — orchestration sans persistance. | Aucune base : BFF sans état |
| mobile-bff | — | SANS BASE | Passerelle de synchro hors-ligne (delta par curseur). | Sans base : delta calculé à la demande depuis les services ; jetons push dans svc-notifications |
| asaci-edge | — | SANS BASE | Traduction des flux ASACI/compagnies en événements. | Sans base : idempotence en aval, reprise assurée par Kafka ; mapping de format = config |
| psp-edge | — | SANS BASE | Traduction des échanges PSP en événements ; rapprochement délégué. | Sans base : l'état des paiements appartient à svc-payments |
| erp-edge | — | SANS BASE | Traduction des écritures comptables vers Odoo. | Sans base : Kafka sert de file durable ; mapping des tiers = référentiel |
Distinction à conserver dans les statuts. « La donnée n'existe pas » et « la donnée existe, sa qualité est inconnue » ne se planifient pas de la même façon : le premier cas est une branche conditionnelle du chantier, le second entre dans le chemin nominal avec une étape de mesure. C'est ce qui a fait passer svc-field-inspections de l'un à l'autre.
Pourquoi les BFF et les edges sont sans base
Un BFF agrège et oriente : il ne détient pas d'état propre. Un edge (couche anti-corruption / connecteur) n'aurait besoin d'une base que dans deux cas — tous deux déjà couverts ailleurs dans l'architecture :
- Dédup / idempotence des flux entrants — traitée en aval : les consommateurs sont idempotents (déduplication par event id). L'edge n'a pas à la stocker.
- Fiabilité des envois sortants vers un système externe — Kafka est déjà la file durable : l'edge consomme, appelle l'API externe, et en cas d'échec l'offset n'est pas commité (retry) ou part en DLQ. Une table de rejeu locale ferait doublon.
| Service | Où vit l'état (au lieu d'une base d'edge/BFF) |
|---|---|
| mobile-bff | Synchro hors-ligne par curseur : le delta se calcule à la demande depuis les services du domaine ; jetons push dans svc-notifications. |
| asaci-edge | Idempotence en aval, reprise via Kafka ; le « mapping de format » est de la configuration, pas des données. |
| psp-edge | L'état des paiements (instructions, rapprochement) appartient à svc-payments ; corrélation via un identifiant porté dans le message. |
| erp-edge | Kafka sert de file durable ; le « mapping des tiers » relève du référentiel. |
| portal-bff | Aucun état : agrégation d'écrans, orchestration pure. |
Seule exception défendable. Un petit schéma purement technique (p. ex. une table d'idempotence côté psp-edge, l'argent étant sensible) reste un détail d'implémentation optionnel : il ne contient aucune donnée métier et n'est jamais une cible de reprise.
Correspondance source legacy → service cible
Le livrable clé pour le chantier de reprise : où atterrit chaque source. Le rattachement fin (table à table) est établi par l'étape de profiling ; ci-dessous la correspondance au niveau des sources.
| Source legacy | Services cibles |
|---|---|
| LOGESIN | svc-claims, svc-medical-care, svc-medical-billing, svc-compensation, svc-reference-data |
| LOGPROD | svc-contributions, svc-field-inspections, svc-statistics |
| Bordereaux Excel | svc-contributions, svc-reference-data |
| GED (filesystem) | svc-documents MinIO pour les fichiers |
Cibles hors PostgreSQL
| Fichiers GED | MinIO / S3 (buckets par service, checksums, versioning, SSE — ADR-0008). svc-documents n'en conserve que les métadonnées et références. |
| Comptes & rôles | Keycloak : realm agents fédéré depuis Entra ID (aucun compte agent créé en local) ; realm usagers a priori vide au démarrage. |
| Comptabilité / ERP | Odoo : périmètre distinct. Frontière svc-contributions ↔ Odoo à tracer. |
Disposition physique recommandée
- Une instance (ou un cluster) PostgreSQL, avec une base OU un schéma par service, isolé.
- Jamais de clé étrangère entre schémas de services différents : cela romprait l'isolation des bounded contexts. Les liens inter-services passent par les événements (Kafka) ou des appels REST, pas par la base.
- La base pivot de migration (sigfga_migration : staging, correspondance d'identifiants, réconciliation, registre) reste séparée des schémas de service.
Écart avec la cible « 4 bases par processus »
À réconcilier. La cible proposée côté DBA regroupe les données en 4 bases par processus (Prise en charge, Indemnisation, Production, Recouvrement). Ce n'est pas la maille de cette architecture :
- Des services traversent plusieurs processus et ne peuvent pas être coupés en deux bases : svc-claims (PR1·PR2), svc-medical-billing (PR1·PR2), svc-payments (PR1·PR2·recouvrement).
- Les services transverses/socle n'ont aucune place dans un découpage par processus.
- L'étape « Distribution » du pipeline vise déjà « les bases des services » : la maille réelle est bien par service.
Décisions à acter avant la reprise
- Historique & événements — le chargement SQL direct contourne Kafka/outbox : svc-audit-trail et svc-statistics ne verront pas l'historique migré. Décider : rejeu d'événements « migrés » ou chargement silencieux assumé.
- Périmètre des sous-ensembles « à confirmer » — le profiling mesure la qualité et le volume utile de : feuilles de suivi et prescriptions (medical-care), détail de facturation (medical-billing), rapprochement contrôle ↔ production (field-inspections). Ce ne sont plus des services entiers mais des sous-périmètres identifiés.
- Arbitrage
depense— facturation (medical-billing) ou décaissement (payments) : 1 087 lignes à charger une seule fois. - GED : MinIO et SharePoint O365 coexistent — décision actée : MinIO = GED applicative (pièces de dossiers, ADR-0008, seule cible de la reprise) ; SharePoint O365 = bureautique et collaboratif (cité par le CDC ERP). Deux briques, deux usages — la page Architecture technique le précise.
- Cibles manquantes dans les schémas — les lignes d'attestation (assiette des 2 %) n'ont pas encore de table cible dans svc-contributions : préalable bloquant au chargement de LOGPROD. Voir Schémas de données §7.
- Frontière ERP/Odoo — quelle part du legacy (compta, bordereaux) va vers Odoo plutôt qu'un schéma PostgreSQL.
- Keycloak — confirmer qu'aucun compte agent n'est provisionné en local (fédération Entra ID) et le sort du realm usagers.