Données & reprise · MCD · sigfga_migration
sigfga_migration — modèle de données minimal
Séparée des bases de service et jamais lue par un service au runtime. Elle porte la traçabilité du chantier et doit survivre à la bascule : c'est elle qui prouve, après coup, d'où vient chaque ligne migrée.
6tables du noyau
2compléments
≈ 50tables source à stager
MCD minimal
Contenu minimal en tables
Le noyau est ce sans quoi le service ne peut pas tenir ses agrégats ni sa première tranche fonctionnelle. Les tables du socle technique s'ajoutent à cette liste et ne sont pas répétées.
| Niveau | Table | Contenu et point de vigilance |
|---|---|---|
| NOYAU | run_registry | Chaque exécution : périmètre, horodatage, opérateur, version de schéma cible constatée (lue dans databasechangelog de la base visée). Le pipeline s'arrête proprement si la version diffère de celle attendue. |
| NOYAU | staging_<table_source> | Copie brute d'une table source, tout en texte, sans contrainte : on charge d'abord, on type ensuite. Une table par table source utile (≈ 50 tables héritées). |
| NOYAU | id_map | La table centrale du chantier. (système, table, clé source) → (service cible, identifiant cible). Indispensable pour résoudre les liens par varchar métier du legacy, rejouer un lot sans doublon, et tracer l'origine de toute ligne migrée. |
| NOYAU | rejects | Ligne rejetée, règle violée, motif lisible. Avec 275 dossiers, la revue manuelle des rejets est réaliste — à condition qu'ils soient tous ici. |
| NOYAU | reconciliation | Compteurs source vs cible par table et par lot, écarts, et les contrôles métier : re-vérification 2 % ± 1 FCFA, totaux bordereaux vs somme des lignes. |
| NOYAU | file_inventory | Inventaire de la GED disque : chemin legacy, existence constatée, taille, empreinte, objet MinIO cible, statut de versement. Le vrai poids du chantier se pilote ici. |
| COMPL. | lookup_overrides | Recodages manuels varchar libre → entrée de référentiel, versionnés et rejouables. Évite la correction « à la main dans la cible ». |
| COMPL. | volumetry_baseline | Compteurs réels relevés via information_schema — les volumétries documentées sont des AUTO_INCREMENT (suppressions non déduites) et servent d'ordre de grandeur, pas de cible de contrôle. |
Sources legacy et transformations
| Table legacy | Volumétrie | Table cible | Transformation clé |
|---|---|---|---|
| LOGESIN (<code>aiew1598_fgsin</code>) | 38 tables · ~7 890 lignes | staging_* | MyISAM, latin1, aucune FK : charger en texte brut, typer ensuite. |
| LOGPROD (<code>fga_production</code>) | 12 tables · attestation 0,8–3 M | staging_* | Table centrale sans PK, montants en float : générer les clés, convertir en numeric. |
| GED (arborescence disque) | des Go | file_inventory | Inventaire et contrôle d'existence avant tout versement MinIO. |
| bordereaux Excel | 1 567 | file_inventory | Archivés comme justificatifs et utilisés comme jeux de parité, jamais comme source de chargement. |
Points de vigilance
Cette base survit à la bascule. id_map et reconciliation sont les seules pièces qui permettront, six mois après, de répondre à « d'où vient cette ligne ? » et « le total a-t-il été conservé ? ». Les supprimer après la migration reviendrait à effacer la preuve du travail fait.
Aucun service ne lit cette base au runtime. Pas de vue partagée, pas de foreign data wrapper, pas de FK vers les bases de service : la seule communication est le chargement, dans un sens, à un instant donné.
Décisions attendues
- Obtenir un dump complet des deux bases de production et une copie de l'arborescence GED.
- Décider de la profondeur d'historique : tout depuis 2010/2019, ou stock vivant plus archive ?