Une reprise de données peut compter exactement le même nombre de lignes avant et après tout en ayant relié des commandes au mauvais client, perdu des statuts ou transformé des montants avec une règle impossible à expliquer.
Un projet de développement web sur mesure doit traiter la migration comme un produit temporaire : contrats, versions, tests, supervision, responsables et critères de fin.
La méthode va de l’inventaire à la bascule et impose un manifeste pour chaque lot. Elle prévoit des contrôles métier et plusieurs répétitions complètes avant la fenêtre finale.
Le succès n’est jamais résumé par le simple message technique « import terminé ». C’est la capacité des utilisateurs à travailler, de la finance à rapprocher et de l’équipe à prouver l’origine de chaque donnée sensible.
Deux signaux faibles annoncent une migration mal cadrée : les volumes annoncés changent selon l’interlocuteur et les règles de transformation existent seulement dans un tableur personnel. Ils indiquent que la population et la connaissance ne sont pas encore opposables.
Définir mandat et décision de go
Le mandat nomme les sources, la cible, les populations, l’historique, la fenêtre, les responsables et les obligations. Il précise qui signe la qualité métier et qui décide un report lorsque les critères ne sont pas atteints.
Les critères couvrent intégrité, exhaustivité, délai, performance et capacité de retour arrière. Les tolérances sont décidées avant la bascule avec leur population, leur justification et leur approbateur.
Les fonctions non disponibles dans la cible ont une stratégie : transformation, archive consultable, procédure ou exclusion acceptée.
Le go/no-go évite les moyennes rassurantes : une population financière ou réglementaire peut imposer zéro erreur tolérée, tandis qu’un historique descriptif accepte quelques exclusions documentées. Chaque seuil autorise une décision précise plutôt qu’une négociation pendant la nuit de bascule.
Inventorier sources et populations
L’inventaire inclut bases, fichiers, pièces jointes, référentiels, exports, tables temporaires et traitements manuels. Chaque source possède un responsable, une date de fraîcheur, un mode d’extraction et une règle de conservation.
Les volumes sont segmentés par entité, par période et par niveau de criticité métier. Les relations, les contraintes, les encodages et les données sensibles sont documentés avec leurs règles de contrôle.
Un profilage mesure valeurs nulles, doublons, distributions, valeurs impossibles et références orphelines. Il produit des faits avant d’écrire les règles et évite de concevoir la reprise à partir de quelques exemples propres.
L’inventaire rapproche le nombre d’objets métier, l’espace physique et les relations attendues. Un écart important entre ces trois vues révèle souvent des archives cachées, des doublons ou des pièces jointes stockées hors de la base principale.
Choisir quoi reprendre
Chaque population reçoit une décision explicite : migrer en actif, migrer en historique, archiver, agréger ou supprimer selon les règles validées. La décision conserve son motif, son approbateur et son mode d’accès futur.
L’ancienneté seule ne décide jamais de l’exclusion ou de la migration d’une donnée. Un contrat ancien encore opposable ou une facture liée à un dossier actif reste nécessaire.
Les volumes exclus sont comptés avec leurs motifs, leurs règles et leurs approbateurs. L’équipe sait ce qui ne sera pas disponible et comment le consulter si besoin.
Réduire le volume n’est pas seulement une optimisation technique : cela simplifie les contrôles, les recherches et la responsabilité future. En revanche, supprimer trop tôt une donnée encore reliée à un dossier actif transfère le coût vers le support et les utilisateurs.
Versionner le dictionnaire de correspondance
Chaque champ source possède une cible, un type, une règle, une valeur par défaut, un contrôle et un responsable. Les tables de correspondance deviennent des éléments versionnés, relus et déployés avec le code de migration.
Les changements de sens sont documentés avec leur période de validité et leur conséquence. Un ancien statut peut se répartir entre plusieurs nouveaux selon le contexte ; la correspondance le montre.
Les exemples contradictoires valident la règle sur ses cas limites et ses ambiguïtés. Une valeur par défaut n’est utilisée que si elle reste honnête pour toute la population concernée.
Une règle de correspondance doit répondre au cas qui ne rentre pas proprement dans la cible. Si l’ancien statut mélange validation et paiement, la migration le répartit à partir d’autres preuves ou place le dossier en revue ; elle ne choisit pas arbitrairement le statut le plus fréquent.
Résoudre identités et doublons
Une clé stable relie chaque ancien identifiant au nouvel objet correspondant dans la cible. La table de correspondance est sauvegardée et utilisée par tous les objets dépendants.
Les doublons suivent une règle métier : fusion, conservation séparée ou revue manuelle. Les critères, les champs conservés et les références redirigées restent traçables après la bascule.
Les références orphelines entrent dans une file de quarantaine avec leur contexte complet. Les rattacher au premier nom proche crée une corruption silencieuse, souvent plus coûteuse qu’une exclusion temporaire clairement assumée.
Le test part d’un objet enfant, comme une ligne de facture, et remonte jusqu’à toutes ses identités parentes. Cette approche détecte mieux les collisions qu’une simple recherche de doublons dans la table des clients.
Rendre les transformations explicables
Les conversions de date, devise, unité, adresse et statut sont déterministes et testées sur leurs limites. Le fuseau, l’ordre des opérations et l’arrondi restent explicites dans chaque version de transformation.
Chaque ligne importante conserve source, version de correspondance et lot. Le support peut reproduire le résultat sans relancer toute la migration.
Les enrichissements externes sont séparés de la copie afin de préserver sa reproductibilité complète. Leur indisponibilité ne doit pas rendre le lot non reproductible.
Le coût caché d’une transformation opaque apparaît plusieurs mois après le projet, lorsqu’un utilisateur conteste une valeur. Conserver la donnée source, la version de règle et le lot permet alors d’expliquer le résultat sans restaurer tout l’ancien système.
Construire des lots rejouables
Le manifeste indique population, extraction, empreinte, version, heure, résultat et contrôles exécutés. Un lot peut être rejoué sans doubler les objets ni modifier ceux déjà validés par une version plus récente.
Les dépendances fixent l’ordre : référentiels, comptes, dossiers, transactions et documents. Les reprises partielles restent possibles sur une population bornée sans rejouer les objets déjà validés.
La cadence protège la cible et laisse une marge suffisante pour le rattrapage. Un import rapide mais impossible à superviser n’est pas prêt, car aucune équipe ne peut distinguer son progrès d’un blocage silencieux.
Les lots sont dimensionnés pour limiter le rayon d’impact tout en respectant la fenêtre. Trop grands, ils rendent la reprise coûteuse ; trop petits, ils multiplient les contrôles et les points de coordination jusqu’à saturer l’exploitation.
Gouverner les rejets
Un rejet porte un motif, une source, un champ, une sévérité et une action attendue. Les erreurs techniques et métier sont séparées afin que la bonne équipe puisse traiter la cause.
La correction se fait dans la bonne source ou par une règle explicitement approuvée. Les modifications manuelles sont tracées, exportables et rejouables pendant les répétitions suivantes.
Les seuils de rejet par population font partie du go/no-go. Une moyenne globale ne masque pas une entité entièrement en échec.
La file affiche le volume restant et surtout le temps nécessaire pour le résoudre avant l’ouverture. Cent erreurs identiques corrigées par une règle valent mieux que dix dossiers uniques exigeant chacun une enquête de trente minutes.
Prouver par contrôles métier
Les contrôles comptent lignes, montants, soldes, états et relations par population. Ils comparent des agrégats à des échantillons entièrement reconstitués afin de détecter les compensations invisibles.
Les utilisateurs exécutent des parcours : retrouver un client, poursuivre un dossier, éditer un document et expliquer une transaction.
Un total global juste peut parfaitement compenser deux erreurs opposées sur des dossiers différents. Les invariants par entité et période empêchent cette fausse validation.
Les contrôles métier ont un signataire différent de l’équipe qui a écrit la transformation. Cette séparation évite que le projet valide seulement ce qu’il sait déjà mesurer et oublie un usage rare mais indispensable.
Répéter et chronométrer
Plusieurs répétitions complètes utilisent des copies représentatives et les mêmes contraintes que la fenêtre finale. Elles mesurent l’extraction, le transfert, l’import, l’indexation, le contrôle et la correction de chaque lot.
Chaque répétition ferme des causes et actualise la procédure de bascule avec ses temps réels. La marge restante demeure visible dans la fenêtre finale au lieu d’être absorbée par des tâches ajoutées tardivement.
La dernière répétition applique des versions et des volumes proches de la production, avec les mêmes personnes et droits. Elle inclut les communications, la décision d’arrêt et la restauration, pas seulement l’exécution des scripts.
Une amélioration de durée n’est acceptée que si elle préserve les contrôles. Supprimer une vérification pour tenir la fenêtre transforme un retard visible en risque de corruption découvert après l’ouverture.
Piloter delta, gel et bascule
Le plan choisit entre gel, synchronisation des écarts ou double écriture maîtrisée. Il définit précisément le point où la cible devient le système maître et interdit les modifications concurrentes non gouvernées.
La procédure ordonne sauvegarde, extraction, lots, contrôles, ouverture et communication. Chaque étape possède un responsable, une heure attendue, une preuve et une condition explicite d’arrêt.
L’écart final est chargé de manière idempotente puis rapproché avec la dernière extraction. Les transactions arrivées pendant la fenêtre ne doivent disparaître entre deux systèmes ni être comptées deux fois.
Le tableau de commandement affiche seulement les décisions nécessaires : poursuivre, ralentir, corriger, revenir ou ouvrir. Les métriques techniques détaillées restent accessibles, mais elles ne doivent pas masquer les seuils métier de la bascule.
Préparer retour arrière et archive
Le retour arrière précise jusqu’où l’ancien système peut reprendre et comment réinjecter les écritures produites dans la cible. Cette procédure est testée avec des données réelles avant la fenêtre définitive.
Après le point de non-retour, une progression vers l’avant et une capacité renforcée remplacent la promesse de restauration. La décision est assumée avant la fenêtre avec les moyens humains et techniques correspondants.
L’archive conserve données, correspondances, manifestes et contrôles selon les règles applicables. Le guide import, export et migration de données complète ce dispositif.
Conclusion : basculer une donnée opposable
La reprise réussit lorsque la population, les correspondances et les exclusions deviennent parfaitement explicites. Les lots rejouables rendent l’exécution contrôlable et limitent le rayon d’impact de chaque correction.
Les contrôles métier et les répétitions prouvent la qualité bien au-delà du simple comptage. La synchronisation finale et le retour arrière protègent la fenêtre sans promettre une réversibilité irréaliste.
Manifestes et archive permettent d’expliquer une donnée après la fin du projet, quand l’ancienne équipe n’est plus disponible.
Dawap conçoit et exécute ces reprises dans ses projets de développement web, depuis l’audit des sources jusqu’à la bascule et à l’exploitation durable.
