Tester une migration de données : ce qu'un test réussi prouve vraiment

Prenons un exemple : un rapport de chargement affiche 100 %, sans rejet. Dans la source, un délai fournisseur vaut 6 semaines. Dans la cible, le champ attend des jours, mais la migration a copié 6 sans conversion. L’enregistrement est accepté ; le délai est pourtant sept fois trop court. Le rapport peut être vert alors que la donnée est fausse.

Ce rapport confirme l’acceptation des enregistrements. Il ne valide pas leur sens métier.

Ce que l’acceptation par la cible établit

Un rapport de chargement indique quels enregistrements le système cible a acceptés ou rejetés, avec les diagnostics exposés par l’interface. C’est une première preuve utile. Une chaîne peut aussi produire des contrôles de volumes, de valeurs et de relations, à condition de les avoir prévus.

L’acceptation seule ne démontre pas que la valeur arrivée conserve le sens attendu. Un délai de 6 peut être accepté malgré une unité incorrecte. Un centre de coûts peut être rattaché à un parent existant mais inapproprié ; un article peut rester actif malgré une décision d’obsolescence. La cible applique les contraintes techniques et métier configurées dans l’interface utilisée. Elle ne vérifie pas automatiquement toutes les règles de correspondance entre les deux systèmes.

C’est cet écart qui fait du test de migration une discipline à part entière plutôt qu’une étape du chargement. Tout ce qui suit sert à le combler.

Quatre niveaux, et ce que chacun établit

Les niveaux sont cumulatifs. Chacun couvre des défauts que les autres peuvent laisser passer.

Niveau 1 : l’enregistrement a été accepté. Le rapport de chargement confirme que les contrôles appliqués par l’interface cible ont été franchis. Il ne démontre pas à lui seul l’équivalence métier ni le bon fonctionnement des processus.

Niveau 2 : les comptages se réconcilient. Chaque enregistrement du périmètre source doit avoir un traitement traçable : repris, exclu par une décision approuvée, ou encore en anomalie. Ce suivi doit aussi repérer les enregistrements jamais traités. Conservez les correspondances entre identifiants source et cible, y compris lorsqu’une fusion regroupe plusieurs sources ou qu’une règle produit plusieurs objets cibles.

Une égalité de volumes entre les enregistrements source retenus et les objets cibles est attendue dans le cas d’un mapping de 1 pour 1. Avec des fusions ou des découpages, les totaux peuvent différer ou même coïncider sans que cela prouve la bonne transformation. Calculez le nombre et l’identité des objets cibles attendus à partir des règles validées de fusion, de découpage et d’exclusion, puis comparez-les au résultat chargé. Une exclusion silencieuse de 4 000 enregistrements peut rester invisible si l’attendu est simplement repris du rapport de chargement. Il doit être établi indépendamment, depuis le périmètre source et les décisions approuvées.

Niveau 3 : les valeurs sont équivalentes. Sur tout le périmètre repris, comparez chaque valeur cible à l’attendu calculé selon le mapping validé. Cet attendu peut venir d’un champ source, de plusieurs enregistrements regroupés, d’un référentiel ou d’une valeur par défaut approuvée. Un code qui change de format doit désigner l’objet attendu. Le délai en semaines est détecté ici, à condition de traduire la règle de conversion en contrôle explicite.

Niveau 4 : le métier se comporte. Exécutez les scénarios métier convenus de bout en bout dans la cible. Faites passer une commande d’achat en validation. Explosez une nomenclature et comparez-la à l’attendu issu de la source, sous des configurations, révisions et conditions d’effectivité équivalentes selon le mapping. Passez un mouvement de stock et vérifiez l’écriture comptable. Ce niveau vérifie les interactions entre entités dans les processus métier, en complément des contrôles techniques de relations et de valeurs.

Compter n’est pas comparer

La réconciliation par comptage est populaire parce qu’elle s’automatise facilement et qu’elle produit une coche verte. Elle révèle des écarts de nombre, par exemple des pertes ou des doublons. Elle ne démontre pas l’équivalence des valeurs.

Complétez les comptages par des contrôles qui portent sur les valeurs concernées. Pour les délais fournisseurs, comparez chaque couple article-fournisseur après normalisation dans la même unité : 6 semaines doivent devenir 42 jours calendaires, et non 6 jours. Si la cible utilise un calendrier ouvré, définissez et testez aussi cette règle de conversion.

Les quantités en stock par entrepôt et les montants de commandes par client restent des contrôles utiles de leurs propres domaines. Ils peuvent rester inchangés quand seul un délai est faux. Même le nombre d’unités distinctes peut valoir 1 avant et après : il ne suffit pas à détecter une conversion oubliée.

Choisissez des contrôles capables de détecter les erreurs envisagées. Combinez comparaisons détaillées et agrégats : deux erreurs opposées peuvent s’annuler dans un total.

Le piège de l’échantillon

Un échantillon facilite le développement, surtout lorsque ses enregistrements sont faciles à expliquer et à tracer à la main. Il devient insuffisant pour la recette s’il écarte les cas complexes qui existent dans le périmètre réel.

Un échantillon choisi uniquement pour sa simplicité sous-représente les risques. L’article créé en 2008 par quelqu’un qui est parti, portant un statut absent de la documentation actuelle, peut ainsi rester hors des tests. Il faut au contraire couvrir les règles nominales et les cas difficiles à expliquer.

Notre article sur les pièges d’une migration Windchill vers 3DEXPERIENCE décrit les limites des preuves de concept choisies pour leur simplicité. La même précaution s’applique côté ERP : inclure les cas difficiles avant de dimensionner la suite.

Si vous testez sur un sous-ensemble, sélectionnez-le de façon hostile : les enregistrements les plus anciens, ceux qui portent des valeurs nulles dans des champs devenus obligatoires, ceux dont les chaînes sont les plus longues, ceux qui ont le plus de liens, ceux créés par des systèmes qui n’existent plus. Un sous-ensemble choisi pour sa difficulté vous apprend quelque chose. Un sous-ensemble limité aux cas propres ne vérifie pas le traitement des exceptions.

Testez les règles nominales et les exceptions

Une façon utile de dimensionner l’effort de test : à la fin de l’audit, vous savez à peu près quelle part des enregistrements passe sur une règle déterministe et quelle part demande une décision. Pour illustrer le raisonnement, supposons une répartition 95 / 5 ; elle doit être mesurée sur votre périmètre.

Les règles nominales doivent être testées, puis vérifiées à pleine volumétrie. Regroupez les exceptions par cause et par décision métier, testez chaque règle de résolution, puis vérifiez son application à tous les enregistrements concernés. Une faible part d’exceptions peut demander une part importante de l’effort de test si elle concentre des arbitrages complexes.

Un mécanisme de suivi et de rejeu des erreurs réduit le coût des corrections successives. Rejouer 12 000 exceptions et leurs dépendances peut être bien moins coûteux que reprendre tout le périmètre à chaque tentative. Des traitements par lots avec points de reprise comme une architecture asynchrone peuvent le permettre. Il reste à mesurer les temps de reprise et à vérifier que le rejeu n’introduit ni doublon ni incohérence.

Le dry run vérifie la bascule à l’échelle réelle

Tout ce qui précède peut s’exécuter dans un environnement confortable, un mardi, avec le temps d’investiguer. Le dry run est autre chose : volumétrie réelle, chaîne complète y compris les interfaces de chargement de la cible, et chronomètre de bascule enclenché.

Il vérifie ce qu’un test unitaire ne couvre pas : la durée du chargement dans la fenêtre prévue, le comportement de la cible à 300 000 enregistrements au lieu de 30 000, ou la disponibilité du responsable du rollback à 4 h du matin. Il éprouve aussi la capture des deltas entre le dernier instant couvert par l’extraction et l’arrêt des écritures à la source, avec un scénario représentatif des changements pendant cette période. Les transactions en cours et les éventuelles écritures autorisées après le gel doivent avoir un traitement explicite.

Un dry run qui se termine tôt et proprement n’est pas une répétition gâchée, c’est le résultat que vous avez payé. Sauter le dry run parce que le planning a glissé laisse la durée et la coordination de la bascule sans répétition complète.

Répéter, puis mesurer ce que les répétitions démontrent

La question centrale est : quels contrôles ont été exécutés sur quel périmètre, avec quels résultats et quels écarts restants ? Documentez aussi les itérations par périmètre et les répétitions complètes, en distinguant les deux.

Le nombre de passes renseigne sur la capacité à répéter la migration, mais ne constitue pas à lui seul un critère d’acceptation. Suivez aussi le périmètre couvert, les écarts non résolus, les résultats métier et la durée du cutover. Répéter vingt fois le même contrôle incomplet ne détectera toujours pas une conversion de délai qu’il ne vérifie pas.

La répétabilité se vérifie en conservant les versions des règles, les extractions utilisées, les résultats des contrôles et les durées. Après une correction, rejouez les contrôles concernés et les scénarios de régression avant la répétition finale sur la version prévue pour la bascule.

Les tests ne garantissent pas une migration sans incident. Ils aident à découvrir les erreurs tôt, dans un environnement où leur correction mobilise du temps d’ingénierie avant d’affecter la production. C’est pourquoi la phase qui précède le Go-Live dans notre méthodologie comprend une répétition complète de la bascule.

Pour situer le test dans l’enchaînement complet, de l’audit jusqu’à la bascule, voyez le guide de la migration de données ERP ou, si vous déplacez une structure produit plutôt qu’un système de gestion, le guide de la migration de données PLM.

La part des exceptions ne se devine pas : elle se mesure. Un audit de préparation identifie les règles et arbitrages à couvrir avant de dimensionner l’effort de test.