Vérifier qu'une migration de données n'a rien perdu suppose de dépasser le simple constat que "ça a l'air bon" dans le nouveau système. Il faut combiner quatre niveaux de contrôle, du comptage global jusqu'à la comparaison champ à champ, et s'appuyer sur un jeu de contrôle constitué avant la bascule à partir de cas réels, normaux et limites. C'est cette méthode, pas un sentiment de confiance, qui permet d'affirmer qu'aucune donnée n'a été perdue, tronquée ou déformée pendant le transfert.
Les pertes les plus coûteuses d'une migration ne sont jamais celles qu'on voit tout de suite. Un compteur de lignes identique avant et après rassure, mais il ne dit rien d'une adresse tronquée, d'une date décalée d'un fuseau horaire ou d'un montant arrondi au centime près. Ces écarts silencieux ne cassent rien à l'œil nu : ils se découvrent au moment d'une clôture comptable ou d'un premier litige avec un client, quand corriger devient beaucoup plus coûteux que de contrôler en amont.
Cet article détaille la méthode complète : les quatre niveaux de contrôle à empiler, la construction d'un jeu de contrôle représentatif, les pièges techniques qui trompent les vérifications naïves, ce qu'une IA peut réellement automatiser dans cette recette, et la période de double contrôle à tenir après la bascule pour attraper ce qu'aucun test statique ne révèle.
Points clés à retenir
- Un comptage de lignes identique avant et après migration ne prouve rien : les pertes les plus coûteuses sont silencieuses (champ tronqué, date décalée, montant arrondi, relation orpheline)
- Quatre niveaux de contrôle se complètent et doivent tous être passés : comptage par entité, totaux de contrôle, intégrité relationnelle, comparaison champ à champ sur échantillon
- Le jeu de contrôle est la pièce maîtresse de la recette : un lot d'enregistrements réels validés par le métier, couvrant les cas normaux et surtout les cas limites
- L'encodage des accents, les formats de date, les séparateurs décimaux, les arrondis et les longueurs de champ trompent les contrôles trop rapides et doivent être testés explicitement
- L'IA accélère la génération de cas de test et la détection d'écarts anormaux dans des comparaisons de masse, mais la définition de ce qui est correct reste une décision métier
Pourquoi "ça a l'air bon" ne suffit jamais
Après une migration, le réflexe naturel consiste à ouvrir le nouveau système, parcourir quelques fiches, constater que tout semble en ordre, et déclarer la bascule réussie. Ce contrôle visuel a une vraie utilité : il attrape les erreurs grossières, un module qui ne s'est pas chargé, une table entièrement vide. Mais il ne détecte presque rien des erreurs qui coûtent réellement cher.
Les pertes les plus coûteuses d'une migration sont silencieuses par nature. Elles ne font planter aucun écran, elles n'affichent aucun message d'erreur, et elles passent un contrôle visuel sans aucune difficulté :
- Un champ tronqué. Une adresse ou une raison sociale coupée à un certain nombre de caractères parce que le champ cible est plus court que le champ source. La fiche existe, elle a juste perdu sa fin.
- Une date décalée. Un fuseau horaire mal géré qui fait basculer une commande passée à 23h50 sur le jour suivant, avec des conséquences sur un délai contractuel ou une période de facturation.
- Un montant arrondi. Un centime perdu par ligne qui, multiplié par des dizaines de milliers de lignes, finit par créer un écart de trésorerie difficile à expliquer.
- Une relation orpheline. Une ligne de commande qui existe encore, mais dont le lien vers le client ou vers la commande parente s'est cassé pendant le transfert.
Personne ne voit ces pertes avant qu'un événement précis les révèle : une clôture comptable qui ne recoupe plus, un client qui conteste un montant sur une facture, un auditeur qui demande à retracer une écriture jusqu'à sa source. À ce moment-là, l'ancien système est parfois déjà éteint, et corriger devient beaucoup plus difficile que de contrôler avant la bascule.
C'est cette réalité qui justifie une méthode de contrôle structurée plutôt qu'un simple coup d'œil, et c'est exactement ce que nous intégrons dans chaque projet de migration et reprise de données : la recette fait partie du livrable, pas une étape optionnelle ajoutée si le temps le permet.
Les quatre niveaux de contrôle, du plus grossier au plus fin
Aucun contrôle isolé ne suffit à valider une migration. Chaque niveau détecte une catégorie d'erreur que les autres laissent passer. Les empiler dans l'ordre, du plus rapide au plus coûteux, permet d'éliminer les problèmes évidents avant d'investir du temps sur les vérifications fines.
Comptage par entité
Le niveau le plus simple : compter le nombre de clients, de factures, de commandes, de lignes de commande dans l'ancien système et dans le nouveau, entité par entité. Un écart de comptage signale immédiatement un problème, un filtre trop restrictif à l'export, une table oubliée, des doublons créés à l'import.
Ce niveau attrape les erreurs les plus grossières mais ne dit rien du contenu des lignes. Un comptage parfaitement identique peut cacher des données entièrement fausses.
Totaux de contrôle sur les valeurs qui s'additionnent
Le chiffre d'affaires total, l'encours client total, la quantité totale en stock : ces valeurs agrégées doivent correspondre entre l'ancien et le nouveau système, à l'euro et à l'unité près. Un total qui ne tombe pas juste révèle une erreur de mapping sur un champ numérique, un arrondi mal géré, ou une ligne exclue par erreur.
Attention à un piège classique : un total qui tombe juste peut aussi cacher deux erreurs qui se compensent, une ligne en trop et une ligne en moins de même montant. Ce niveau réduit fortement le risque, il ne l'élimine pas seul.
Contrôles d'intégrité relationnelle
Toute donnée qui dépend d'une autre doit rester rattachée après la migration. Aucune facture sans client associé, aucune ligne de commande sans commande parente, aucun paiement sans facture à solder. Ces contrôles se formulent comme des règles simples à automatiser : compter les enregistrements orphelins, ceux dont la clé de rattachement pointe vers rien.
Une relation cassée est souvent invisible tant qu'on ne cherche pas spécifiquement les orphelins : la fiche existe, elle s'affiche, elle a juste perdu son lien vers le reste des données.
Le jeu de contrôle, la pièce maîtresse de la recette
Les trois premiers niveaux valident la structure globale. Ils ne disent rien de la fidélité réelle du contenu, champ par champ, sur des cas précis. C'est le rôle du jeu de contrôle : un lot d'enregistrements réels et représentatifs, constitué avant la bascule, avec leurs valeurs attendues validées par le métier.
Le principe : au lieu de comparer des masses de données de façon générique, on choisit à l'avance un échantillon précis, on note ce qu'il doit contenir après migration, et on vérifie ligne par ligne, champ par champ, que le résultat correspond exactement à ce qui était attendu. Ce jeu de contrôle sert ensuite deux fois : à chaque migration à blanc pendant les tests, puis une dernière fois au moment de la bascule finale.
Comment échantillonner : cas normaux et cas limites
Un échantillon composé uniquement de cas normaux valide une migration qui fonctionne bien dans le cas moyen, ce qui est rassurant mais insuffisant. Les erreurs de migration se cachent presque toujours dans les cas limites, ceux qui sortent du gabarit standard :
- Le plus gros client, avec le plus de commandes, le plus de lignes de facturation cumulées.
- Le plus ancien enregistrement, créé avec un ancien format de données ou une ancienne version du logiciel source.
- Celui avec le plus de lignes, une commande à cent lignes plutôt qu'à trois, pour tester les limites de volume.
- Celui avec des caractères spéciaux, un nom accentué, une raison sociale avec un tiret ou une esperluette, un champ en majuscules mêlées à des minuscules.
- Un avoir, dont le comportement de calcul diffère souvent d'une facture classique.
- Une commande annulée, pour vérifier que le statut d'annulation survit à la migration au lieu de redevenir une commande active par défaut.
La validation de ce jeu de contrôle par le métier n'est pas une formalité. C'est la personne qui connaît les données, la comptable, le responsable ADV, qui sait ce qu'une facture ou une fiche client doit contenir exactement. Sans cette validation, le jeu de contrôle vérifie que la migration reproduit fidèlement les données, sans jamais confirmer que ces données étaient correctes au départ.
À retenir
Un jeu de contrôle composé uniquement de cas moyens ne détecte presque jamais les vraies erreurs de migration. Ce sont les cas limites, le plus gros client, le plus ancien dossier, l'avoir, la commande annulée, qui révèlent les défauts de mapping avant qu'ils n'atteignent la production.
Les pièges techniques qui trompent les contrôles naïfs
Certaines erreurs de migration survivent aux quatre niveaux de contrôle si personne ne les cherche explicitement. Elles se ressemblent toutes : la donnée est présente, elle paraît correcte au premier regard, mais elle a subtilement changé de valeur ou de forme pendant le transfert.
| Piège | Symptôme typique | Ce qu'il faut tester |
|---|---|---|
| Encodage des caractères accentués | Un nom affiche des caractères illisibles à la place d'un é ou d'un ç | Toujours inclure des noms accentués dans le jeu de contrôle |
| Formats de date et fuseaux | Une date bascule sur le jour précédent ou suivant selon l'heure de l'enregistrement | Comparer des dates proches de minuit, pas seulement en milieu de journée |
| Séparateurs décimaux | Une virgule interprétée comme un point, un montant multiplié par mille | Vérifier des montants avec décimales sur les deux systèmes côte à côte |
| Arrondis en cascade | Un total légèrement différent selon que l'arrondi se fait ligne par ligne ou sur le total | Recalculer un total à partir des lignes migrées, pas seulement lire le champ total |
| Champs tronqués | Une longueur maximale plus courte dans le système cible coupe silencieusement la fin d'un texte | Tester spécifiquement les champs texte les plus longs de la base source |
| Vide confondu avec zéro | Un champ jamais renseigné devient 0 au lieu de rester vide, ce qui change le sens de la donnée | Vérifier que les champs numériques vides restent distincts d'une vraie valeur zéro |
Chacun de ces pièges partage le même point commun : un contrôle qui se contente de comparer des comptages ou des totaux arrondis ne les voit jamais. Seule une comparaison champ à champ, sur des cas choisis pour être exigeants, les fait apparaître. C'est pour cette raison que le jeu de contrôle doit être pensé pour révéler ces cas précis, pas seulement pour représenter la moyenne des données.
Ce que les contrôles automatiques ne couvrent jamais
Une fois les quatre niveaux de contrôle passés et les pièges techniques écartés, il reste une catégorie de vérification qu'aucun script ne peut faire à la place du métier, et une phase de surveillance qu'aucun test statique ne remplace.
La relecture métier, sur ce qu'aucun contrôle automatique ne juge
Un contrôle technique confirme qu'une donnée est arrivée intacte. Il ne confirme jamais qu'elle était juste au départ. Une migration peut reproduire fidèlement une erreur ancienne, un statut client mal mis à jour depuis des années, une adresse de livraison jamais corrigée après un déménagement.
De la même façon, certains cas exigent un arbitrage humain qu'aucune règle générale ne peut trancher : un client fusionné avec un autre pendant la migration, un ancien contrat encore actif dans les faits mais marqué comme clos dans le système, une remise commerciale négociée oralement et jamais saisie. Ces cas doivent être identifiés et relus par la personne qui connaît le dossier, pas seulement passés au filtre d'un contrôle automatique.
La bonne pratique consiste à distinguer clairement, dans le rapport de recette, ce qui a été vérifié automatiquement de ce qui a nécessité une relecture métier, et à ne jamais présenter la seconde catégorie comme "validée" au même titre que la première.
La période de double contrôle après la bascule
Un jeu de contrôle, aussi bien construit soit-il, reste une photographie prise à un instant donné. Certains écarts n'apparaissent que lorsque le nouveau système traverse un cycle métier complet, ce qui ne se produit pas pendant les tests, seulement en production réelle. C'est pourquoi une période de double contrôle, généralement deux à quatre semaines après la bascule, reste nécessaire. Pendant cette période, quelques indicateurs se surveillent en priorité :
- Les rapprochements bancaires. Les paiements reçus doivent se solder correctement contre les factures migrées, sans écart de montant ni facture introuvable.
- Les relances automatiques. Vérifier qu'elles partent sur les bons dossiers, avec les bons délais, et pas sur un client déjà soldé dont le statut aurait mal migré.
- Les processus mensuels ou trimestriels. Une clôture, une déclaration, un export réglementaire qui ne se déclenche qu'une fois par mois peut révéler un écart qu'aucun test quotidien n'avait détecté.
- Les remontées spontanées du terrain. Les équipes qui utilisent le système au quotidien repèrent souvent des incohérences plus vite qu'un contrôle automatisé, à condition qu'on leur demande explicitement de signaler tout ce qui leur semble étrange.
Garder l'ancien système accessible en lecture seule pendant cette période, sans y autoriser de nouvelles écritures, donne une référence immédiate pour trancher un écart signalé plutôt que de devoir le reconstituer de mémoire.
La documentation de recette et l'apport réel de l'IA
Une migration bien contrôlée mais non documentée perd une grande partie de sa valeur probante. Elle gagne en revanche à s'appuyer sur l'IA pour deux tâches précises, sans jamais lui déléguer la décision de ce qui est correct.
Ce qu'un auditeur doit pouvoir consulter
Un comptable qui doit justifier un montant lors d'une clôture, ou un auditeur qui doit retracer une écriture, a besoin d'un dossier consultable, pas d'un souvenir de la personne qui a piloté le projet. La documentation de recette devrait au minimum consigner :
- Les règles de mapping retenues, champ par champ, entre l'ancien et le nouveau système, avec les cas particuliers traités différemment de la règle générale.
- Le jeu de contrôle utilisé, sa composition et les raisons du choix de chaque cas limite, ainsi que son résultat détaillé.
- Les écarts identifiés à chaque niveau de contrôle, leur cause une fois trouvée, et la correction apportée.
- Les décisions métier prises sur les cas non automatisables, avec le nom de la personne qui a validé chaque arbitrage.
- La date de la bascule finale et la durée de la période de double contrôle, avec les indicateurs suivis pendant cette période.
Ce dossier n'a pas besoin d'être élaboré. Il doit surtout exister, être daté, et rester accessible plus longtemps que la mémoire des personnes qui ont piloté le projet.
Où l'IA aide réellement, sans surpromettre
Deux tâches se prêtent bien à un appui par l'IA, sans remplacer le jugement métier qui reste au centre de la recette. Générer les cas de test à partir des règles de mapping : une fois les règles de transformation posées, un modèle de langage peut proposer une liste de cas à tester, y compris des cas limites auxquels on ne pense pas spontanément. Cela accélère la constitution du jeu de contrôle, mais la validation finale de ce que chaque cas doit produire reste une décision humaine.
Repérer les écarts anormaux dans les comparaisons de masse : sur des volumes de plusieurs dizaines de milliers de lignes, un modèle peut trier les écarts détectés par similarité et faire remonter en priorité les motifs qui reviennent souvent, plutôt que de laisser une personne parcourir une liste plate. Cela réduit fortement le temps d'analyse d'un rapport de contrôle volumineux.
Dans les deux cas, l'IA traite le volume et propose des pistes. Elle ne décide jamais seule qu'une donnée est correcte : cette définition reste et doit rester une décision métier, posée avant la migration et vérifiée par la personne qui connaît le sens réel des données.
C'est cette approche que nous appliquons dans nos projets de migration et reprise de données : une méthode de contrôle structurée en quatre niveaux, un jeu de contrôle validé par le métier avant toute bascule, et une documentation de recette qui reste consultable bien après la mise en production.
Avant même de parler de contrôle, la qualité d'une migration se joue souvent en amont, sur la façon dont les champs des deux systèmes ont été mis en correspondance : notre article sur la correspondance des champs entre deux logiciels détaille cette étape de mapping. Si la migration s'accompagne d'un nettoyage préalable de la base clients, notre article sur le dédoublonnage d'une base clients avant migration couvre spécifiquement ce cas. Pour la méthode complète de migration, du cadrage au mapping, notre article sur la méthode pour migrer les données d'un logiciel se lit en amont de celui-ci. Et lorsque l'historique contient des champs libres ou du texte non structuré, notre article sur la reprise d'historique en champs libres avec l'IA traite ce cas particulier.
Questions fréquentes sur la vérification d'une migration de données
Pour aller plus loin
- Migrer les données d'un logiciel : la méthode pour une PME : le cadrage complet d'une migration, en amont des contrôles détaillés ici.
- Correspondance des champs entre deux logiciels avec l'IA : construire le mapping qui sert de base à la recette.
- Dédoublonner une base clients avant migration : nettoyer la base source avant de la contrôler après transfert.
- Reprendre un historique en champs libres avec l'IA : le cas particulier des données non structurées lors d'une migration.
- Résoudre les conflits et erreurs de synchronisation entre logiciels : quand la vérification doit se poursuivre au delà de la bascule initiale.
- Garanties d'un projet IA si les résultats ne sont pas atteints : comment un projet cadre l'engagement de résultat au delà de la seule migration.
