À trois semaines de la bascule, le fichier client contient des dates impossibles, des contrats sans signataire et plusieurs codes pour une même agence. L’équipe découvre chaque jour un nouvel écart. Certains veulent tout corriger avant de continuer ; d’autres proposent de charger la base telle quelle et de traiter plus tard. Les deux positions peuvent mettre le projet en échec.
Une migration ne transforme pas une donnée historique en donnée parfaite. Elle doit garantir que le nouveau système peut prendre ses décisions, retrouver les dossiers et expliquer les exceptions. Une adresse ancienne peut rester acceptable si elle n’est plus utilisée ; un contrat actif sans devise peut rendre la facturation impossible. La priorité vient de la conséquence, pas du taux global de complétude.
Le vrai enjeu est de rendre chaque anomalie compatible avec une décision sûre. Le nettoyage utile définit des règles, mesure leur portée et attribue une sortie à chaque anomalie : correction certaine, enrichissement métier, quarantaine ou dette acceptée. Le pipeline reste rejouable. La bascule ne dépend plus d’un tableur corrigé une seule fois ni d’une connaissance conservée par l’expert qui part en congé.
Dans un projet de développement web sur mesure, cette discipline relie données, fonctionnalités et run. Elle permet d’avancer sans dissimuler les inconnues.
Définir la qualité nécessaire à la bascule
Commencez par les décisions du nouveau produit : facturer, livrer, autoriser, renouveler, calculer ou notifier. Pour chacune, listez les attributs indispensables, les relations et les périodes. La qualité minimale devient un ensemble de propriétés testables plutôt qu’une formule comme « atteindre 98 % de complétude ».
La donnée historique n’a pas partout la même exigence. Un dossier clos doit parfois rester consultable et opposable sans pouvoir être modifié. Un dossier actif doit franchir les prochains workflows. Une donnée de contact secondaire peut être reportée, tandis qu’une identité légale ambiguë impose une revue avant la bascule.
Fixer le périmètre temporel
Définissez ce qui sera migré, archivé ou accessible depuis l’ancien système. La conservation dépend des usages et obligations réels. Une frontière par date doit prendre en compte les dossiers réouverts et les relations avec les données actives, sinon les équipes recréent immédiatement les objets absents.
Profiler avant de corriger
Inventoriez tables, fichiers, API, exports et corrections manuelles. Pour chaque champ, mesurez nullité, cardinalité, formats, valeurs extrêmes, références orphelines et évolution dans le temps. Échantillonnez aussi les textes libres : ils cachent souvent une relation ou une décision que le schéma cible doit représenter.
Le profil doit être reproductible sur chaque extraction. Gardez requête, version et date. Comparez les résultats pour distinguer stock historique et nouveaux défauts. Si les anomalies continuent à entrer, corriger le stock sans fermer la source revient à remplir un réservoir percé.
Relier une anomalie à son objet
Un même taux change de sens selon l’objet. Cinq codes postaux manquants sur des prospects inactifs ne valent pas cinq références produit absentes sur des commandes ouvertes. Le rapport rattache l’écart à l’identité, au statut, au montant ou au prochain événement métier.
Classer les anomalies par conséquence
Une anomalie bloquante empêche une décision correcte ou viole un invariant cible : relation indispensable absente, identité non résolue, montant incohérent, état sans transition ou droit impossible à reconstruire. Une anomalie dégradable permet le chargement avec une capacité limitée et une action connue. Une anomalie cosmétique n’altère ni décision ni preuve.
Ajoutez fréquence, exposition et coût de correction. Un cas rare peut rester prioritaire s’il touche une obligation ou un montant élevé. Une anomalie fréquente peut être tolérée si le nouveau système la représente explicitement comme inconnue et empêche une décision dangereuse.
Séparer invalide, inconnu et non applicable
Une chaîne vide ne dit pas pourquoi la valeur manque. Le mapping cible distingue information inconnue, non collectée, non applicable et rejetée. Cette sémantique évite les fausses valeurs « N/A » et permet au workflow de demander un enrichissement seulement lorsqu’il est possible.
Écrire des règles reproductibles
Chaque règle porte un identifiant, une description métier, une requête ou transformation, une sévérité, un propriétaire et une action. « Téléphone valide » reste trop vague sans pays, usage et comportement pour les numéros historiques. Les exemples acceptés et refusés protègent la règle contre les interprétations.
Les contraintes de la cible défendent les invariants certains. La documentation officielle de PostgreSQL couvre clés, unicité, références et vérifications de ligne. Une règle qui dépend d’autres enregistrements ou d’un état externe doit rester dans le pipeline ou le domaine ; ne l’enfermez pas dans une contrainte fragile.
Versionner les décisions de nettoyage
Une règle évolue après découverte d’un cas légitime. Conservez sa version avec chaque résultat. Ne requalifiez pas silencieusement les anciens lots. Le rapport explique pourquoi un enregistrement a été corrigé, mis à part ou accepté à une date donnée.
Bloquer, corriger ou mettre en quarantaine
Corrigez automatiquement seulement si la transformation est déterministe et réversible : normaliser une casse, convertir une date dont le format est certain ou rattacher un alias exact. Un rapprochement probabiliste propose un candidat ; il ne fusionne pas des contrats sans contrôle proportionné au risque.
La quarantaine est un produit temporaire, pas un dossier oublié. Elle porte raison, objet, responsable, date limite et options de résolution. Le système cible sait représenter les dossiers concernés sans les rendre actifs. Une dette acceptée reçoit une conséquence documentée et une date de revue.
Préserver la donnée source
Gardez l’extraction brute immuable et liez chaque valeur cible à sa provenance. Une correction produit une valeur transformée avec motif. Cette séparation facilite audit, reprise et comparaison ; elle évite d’écraser la seule preuve disponible au nom du nettoyage.
Cas concret : migration de contrats
Une société migre 18 000 contrats vers une application de renouvellement. Certains portent deux devises, d’autres n’ont pas de date de fin, et 430 références clients pointent vers des doublons. L’équipe ne choisit pas une cible abstraite de qualité. Elle classe les contrats actifs, futurs, résiliés et archivés selon les actions attendues.
Un contrat actif sans partie canonique bloque. Une date de fin absente est légitime pour une durée indéterminée si le type le permet. Une devise contradictoire exige une revue financière. Les contrats clos restent consultables avec leur valeur historique, même si l’adresse ne respecte plus le format courant.
Le pilote porte deux cents contrats représentatifs. Le seuil local exige zéro montant modifié sans justification, zéro relation orpheline et une balance complète des échéances. Trente dossiers ambigus passent en quarantaine avec responsable. Ce verdict ne promet pas zéro anomalie : il prouve que chaque anomalie restante a un comportement sûr.
Organiser les vagues de nettoyage
Travaillez par cohorte fonctionnelle : objet, statut, période ou entité. Chaque vague ferme source, règles, transformations, exceptions et recette. Les enseignements enrichissent les suivantes. Une campagne horizontale « nettoyer tous les emails » donne peu de valeur si les décisions reposent d’abord sur contrats et identités.
Corrigez au plus près de la source lorsque le défaut continue à entrer. Pour le stock figé, le pipeline suffit. Pour une information que seul le métier connaît, fournissez une interface de revue avec contexte et choix bornés ; les utilisateurs ne doivent pas éditer directement le fichier de migration.
Geler sans immobiliser l’activité
Le delta entre extraction initiale et bascule doit être prévu. Choisissez gel court, journal des changements ou double alimentation. Testez l’ordre et les corrections concurrentes. Un gel non réaliste conduit les équipes à maintenir des listes parallèles qui ne seront jamais reprises.
Financer la revue humaine
Estimez le débit depuis un échantillon réel, pas depuis le nombre de cellules. Une décision sur l’identité peut demander documents et appel, tandis qu’un format se corrige instantanément. Donnez à l’interface le contexte utile, les candidats, la règle et un choix borné. Mesurez les accords entre relecteurs sur les cas risqués. Si la capacité ne ferme pas la file avant la bascule, réduisez la cohorte ou changez le comportement cible au lieu d’espérer une accélération tardive.
Contre-intuitivement, laisser une valeur inconnue explicitement qualifiée peut être plus sûr que compléter depuis une source faible. Une donnée plausible franchit les validations et produit une mauvaise décision ; une inconnue déclenche une demande ou bloque un acte précis. Le nettoyage doit donc améliorer la confiance, pas seulement remplir les colonnes. Documentez les enrichissements externes et leur date afin que le produit puisse réévaluer une valeur devenue obsolète.
Industrialiser transformation et reprise
Les entrées sont extraction identifiée, schéma source, version des règles et paramètres de cohorte. Les sorties sont enregistrements chargés, rejets classés, métriques et balance. Le pipeline sépare lecture, normalisation, mapping, validation, écriture et réconciliation. Chaque étape journalise l’identifiant source et la version.
Les traitements sont idempotents et utilisent un curseur stable. Le retry ne duplique ni objet ni relation. Le monitoring suit débit, rejets par règle, âge des quarantaines et écarts de balance. Le rollback supprime ou invalide la cohorte cible depuis un manifeste, sans toucher l’extraction ni les décisions de revue.
Le contrat de fichier précise encodage, séparateur, colonnes, format de date, valeur nulle et checksum. Chaque lot reçoit un identifiant et un accusé détaillant acceptés, rejetés et déjà traités. Les dépendances externes sont figées ou enregistrées par version. Une alerte se déclenche si le volume ou la distribution s’écarte du profil attendu, avant que l’écriture ne contamine la cible. La reprise réutilise le même manifeste et produit les mêmes identifiants.
Les entrées de contrôle sont le manifeste, les compteurs source et les seuils signés ; les sorties sont balance, quarantaines et verdict. La responsabilité de l’opérateur consiste à suspendre le lot sur divergence, puis à reprendre depuis le dernier curseur. Les dépendances, droits et fichiers de référence sont vérifiés avant l’écriture. La journalisation relie chaque rejet à sa règle, tandis que le monitoring suit l’écart. Le rollback et le retry sont testés ensemble pour prouver qu’une relance idempotente ne masque aucun enregistrement.
Rendre les scripts testables
Les fonctions de transformation sont pures quand possible, avec jeux de données versionnés. Les tests couvrent limites, caractères, fuseaux, doublons et valeurs inconnues. Un dry-run produit les mêmes rapports sans écrire. Le code de migration suit la même revue que le produit, car il prend des décisions irréversibles à grande échelle.
Prouver la migration par réconciliation
La recette ne se limite pas à compter les lignes. Balancez identités, relations, montants, statuts et échéances selon l’objet. Comparez des agrégats, puis remontez aux écarts. Un total identique peut masquer deux erreurs qui se compensent ; échantillonnez les dossiers à forte exposition et les exceptions.
Faites exécuter les parcours cibles sur des données migrées : renouveler, corriger, annuler, exporter et auditer. Le support doit retrouver provenance, règle et décision depuis l’identifiant métier. La reprise d’un lot interrompu et la restauration sont jouées avant le go.
Définir un verdict signé
Le rapport sépare bloqueurs, quarantaines, écarts acceptés et limites du périmètre. Chaque bloqueur a un propriétaire ; chaque acceptation un sponsor et une date. Le verdict est reproductible depuis les requêtes, pas construit manuellement la veille de la bascule.
Pour qui ce chantier devient critique
La méthode est essentielle quand l’ancien modèle a plusieurs décennies, quand plusieurs sources se recouvrent ou quand argent, droits et obligations dépendent des données. Elle réunit experts métier, data, développeurs, QA, sécurité, support et responsables de la bascule.
Une migration purement technique sur un petit périmètre peut utiliser une version allégée. Mais dès qu’un script interprète une valeur ou fusionne une identité, il réalise un choix métier. Ce choix doit être nommé, testé et attribué même si l’équipe ne possède pas de programme de gouvernance formel.
Erreurs fréquentes avant migration
Viser un score global
La moyenne masque les attributs critiques et récompense les champs faciles. Mesurez la capacité à exécuter les décisions par cohorte, puis exposez les exceptions restantes.
Corriger manuellement le fichier final
La modification ne sera ni rejouée ni expliquée. Ajoutez la règle au pipeline ou passez par une revue journalisée. Le fichier généré doit rester un produit, jamais une nouvelle source.
Reporter toute qualité après le go
Le nouveau système recevra des dossiers qu’il ne peut pas traiter et le support deviendra l’outil de migration permanent. Reportez uniquement les écarts représentables avec une action et un propriétaire.
Décision : jusqu’où nettoyer
Nettoyez avant bascule tout écart qui empêche une décision correcte, brise une relation indispensable ou rend une preuve introuvable. Mettez en quarantaine un dossier isolable avec procédure. Reportez une imperfection cosmétique ou un enrichissement non requis si le nouveau système la représente honnêtement.
Si l’anomalie expose argent ou droit, alors privilégiez la précision et la revue. En revanche, automatisez une normalisation déterministe. À éviter : bloquer toute la migration pour un champ sans consommateur ou accepter une identité ambiguë parce que le taux global semble bon.
- Commencer par les cohortes actives et les décisions critiques.
- Documenter règle, propriétaire, sortie et preuve.
- Tester reprise, balance et parcours sur les données migrées.
- Élargir lorsque les nouvelles anomalies cessent d’entrer.
Plan d’action sur six semaines
Semaines un à trois : définir et profiler
Listez décisions cibles, cohortes et usages historiques. Inventoriez sources et deltas. Exécutez le profil sur une extraction représentative. Classez chaque anomalie par conséquence et volume, puis fermez règles, exemples, propriétaires et comportements dans la cible.
Construisez le pipeline en étapes, le manifeste et les rapports. Préparez quarantaine, interface de revue et balance. Corrigez les défauts encore produits à la source. Choisissez deux cents dossiers couvrant nominal, limites et contradictions pour le pilote.
Semaines quatre à six : répéter et décider
Exécutez le pilote sans écriture, examinez les décisions puis chargez un environnement cible. Rejouez après correction et comparez les résultats. Provoquez interruption, doublon, valeur tardive et changement concurrent. Vérifiez idempotence et rollback depuis le manifeste.
Faites exécuter les parcours par métier et support. Réconciliez objets, relations, montants et statuts. Chaque écart obtient cause, action et échéance. Les quarantaines sans responsable deviennent bloquantes, car elles n’ont pas de véritable sortie.
Répétez sur une extraction récente et mesurez les nouveaux défauts. Le go est proposé si les invariants sont prouvés, les dettes acceptées et la reprise chronométrée. Sinon, réduisez la cohorte ou corrigez la source ; ne maquillez pas le rapport en changeant le dénominateur.
Organisez enfin une répétition générale avec les horaires, accès et personnes du jour de bascule. Conservez heure de début, durée de chaque étape, consommation, erreurs et décisions. Le runbook précise qui arrête, qui corrige et qui autorise une reprise. Une seconde équipe doit pouvoir exécuter le lot depuis les artefacts. Les écarts de la répétition deviennent des actions datées ; aucun nouveau script non testé n’entre dans la fenêtre finale.
- Relier qualité et décisions du produit cible.
- Profiler, classer et versionner les règles.
- Migrer une cohorte, perturber et réconcilier.
- Répéter sur le delta puis signer les exceptions.
Approfondir référentiels et modèles
Maintenir la qualité après ouverture
Transformez les règles critiques en contrôles continus près de la source ou dans le domaine cible. Le tableau sépare nouveaux défauts, stock accepté et quarantaines. Une alerte ouvre une action nommée ; elle ne se contente pas de dégrader un score. Revoyez les seuils quand le produit change de décision, pas pour faire disparaître une alerte. Après quelques cycles, retirez les règles propres à l’ancien système qui ne protègent plus aucun invariant.
Conservez aussi la capacité de rejouer un ancien lot pour un audit ou une correction. Image du code, schémas, règles, dépendances et source brute forment l’archive technique. Testez périodiquement qu’elle produit encore le rapport attendu dans un environnement isolé. Cette preuve évite de dépendre d’une bibliothèque disparue ou d’un secret non renouvelable au moment où un dossier historique doit être expliqué.
Traiter les identités dupliquées
Le guide sur les données métier dupliquées détaille rapprochement, fusion, aliases et prévention des recréations.
Préparer la cible commune
Poursuivez avec le référentiel commun et le modèle face aux exceptions terrain. Appliquez-les à une cohorte réelle.
- Une source brute préservée.
- Des règles rejouables.
- Un verdict réconcilié.
Conclusion : migrer une donnée assumée
Le bon niveau de nettoyage ne se mesure pas à une base parfaite. Il se mesure à la capacité du produit cible à décider, expliquer et reprendre. Les anomalies critiques sont corrigées ; les inconnues légitimes sont représentées ; les exceptions restantes possèdent une sortie.
Le profil reproductible, le pipeline versionné et la réconciliation remplacent les corrections de dernière minute. La quarantaine isole sans oublier. Les balances et parcours prouvent le sens, pas seulement le volume chargé.
Commencez par une cohorte active et les décisions qu’elle doit franchir. Ce périmètre montrera quelles règles méritent un investissement et quelles imperfections peuvent attendre sans mettre le run en dette.
- Une qualité liée à l’usage.
- Une migration rejouable.
- Une dette explicitement acceptée.
Dawap peut accompagner cette trajectoire de développement web sur mesure : audit, règles de qualité, pipeline, réconciliation, bascule et préparation du support.
