Audit qualité des données avant migration ERP : juger un état, pas un changement

Avant une migration ERP, la question n'est pas « qu'est-ce qui a changé dans nos données ? », mais « cet export est-il juste ? ». La plupart des outils de qualité de données sont conçus pour la première question, pas pour la seconde. Cet article explique pourquoi, et ce qu'un audit qualité des données doit vérifier avant la reprise.

Que se passe-t-il quand on découvre les erreurs au premier chargement ?

Prenons un cas type, fictif. Une ETI industrielle prépare le passage à un nouvel ERP. L'intégrateur charge un premier lot de données dans l'environnement de test. Les anomalies tombent : des clients en double sous deux raisons sociales, des lignes de commande qui pointent vers des articles supprimés, des prix saisis dans la mauvaise unité.

Personne n'avait menti. Chaque table, prise seule, avait l'air propre. Les erreurs étaient dans les liens entre tables et dans le sens des valeurs. Le planning de reprise glisse, et la discussion porte sur qui aurait dû le voir.

Les erreurs d'une reprise de données ERP se trouvent rarement dans une colonne ; elles se trouvent entre les tables.

Que vérifient les outils de qualité de données du marché ?

On peut ranger la plupart des outils en deux familles.

• Les plateformes à règles. Un expert écrit des contrôles, ou l'outil en suggère à partir d'un profil des colonnes. Elles vérifient très bien ce qu'on leur a demandé de vérifier. Le travail reste d'écrire les bonnes règles, table par table, avant de savoir où sont les erreurs.
• L'observabilité des données. L'outil apprend le comportement normal de la base au fil du temps, puis alerte quand il change. C'est utile en production. Mais il apprend la base telle qu'elle est, erreurs comprises : une erreur présente depuis des années devient la norme.

Les outils du marché vérifient des règles qu'on leur écrit ou apprennent la base telle qu'elle est, erreurs comprises ; aucun ne juge seul la cohérence entre tables et la plausibilité métier d'un export unique.

Pourquoi juger un état n'est pas surveiller un changement ?

Le jour d'une migration, il n'y a pas de « avant » utile. Il y a un export, une fois, de toute la base. La question est simple : ces données sont-elles assez justes pour être reprises ?

Surveiller un changement suppose un historique et une base saine au départ. Juger un état ne suppose ni l'un ni l'autre. C'est ce que nous appelons un audit « à froid » : un export suffit, sans accès à la production.

Que doit vérifier un audit qualité des données avant migration ERP ?

Six questions, chacune avec un exemple simple.

1. Complétude : la donnée est-elle là ? Un client sans adresse de facturation.
2. Unicité : existe-t-elle une seule fois ? Deux fiches clients pour le même SIREN.
3. Validité : a-t-elle le bon format ? Un SIRET à 13 chiffres au lieu de 14.
4. Cohérence dans une ligne : les champs s'accordent-ils ? Un montant TTC inférieur au montant HT.
5. Cohérence entre tables : les liens tiennent-ils ? Une ligne de commande sans commande, une facture pour un client qui n'existe plus.
6. Plausibilité : la valeur a-t-elle du sens ? Un prix unitaire mille fois supérieur à celui des articles de la même famille.

Un audit qualité des données avant migration ERP doit vérifier le sens des données et les liens entre tables, pas seulement le format.

Pourquoi les incohérences entre tables passent-elles inaperçues ?

Parce que les contrôles classiques vérifient colonne par colonne. Une colonne « code article » peut être parfaitement remplie, au bon format, sans doublon. Elle peut quand même pointer vers des articles qui n'existent plus dans la table des articles.

Pour le voir, il faut lire la base comme un tout : clients, commandes, articles, factures. Il faut aussi comprendre ce que représente chaque colonne. Un prix, une quantité et une date de livraison ne se contrôlent pas de la même façon.

La qualité des données multi-tables se mesure en suivant les liens entre clients, commandes, articles et factures.

Comment savoir qu'un audit trouve vraiment les erreurs ?

Un audit qui ne dit pas ce qu'il rate ne vaut pas grand-chose. La seule façon honnête de le mesurer, c'est de le tester sur des bases où l'on connaît toutes les erreurs.

C'est le principe d'un banc d'essai : des bases synthétiques multi-tables, des erreurs injectées volontairement, et une vérité terrain cellule par cellule. On compte alors ce que l'audit trouve, ce qu'il rate et ce qu'il signale à tort.

Les erreurs injectées doivent ressembler aux vraies. Un écart d'arrondi d'un centime n'a pas la même fréquence qu'un montant faux de plusieurs milliers d'euros. Un banc qui les injecte au même rythme mesure un monde qui n'existe pas.

Gimlo AI se mesure sur un banc d'essai avec vérité terrain : trois bases synthétiques (distribution, industrie, services) et neuf niveaux de corruption ; les résultats seront publiés. Avant cela, nous ne donnons aucun chiffre de performance.

Que doit exiger un DSI d'un audit avant migration ?

Une liste courte, à reprendre telle quelle dans un cahier des charges.

• Un export suffit. Pas d'accès à l'ERP en production, pas d'historique exigé.
• Les données restent chez vous. L'audit tourne dans votre infrastructure.
• Le sens et les liens, pas seulement le format. Les contrôles entre tables sont explicitement couverts.
• Un rapport priorisé. Quoi corriger d'abord, table par table, prêt pour l'équipe de reprise.
• Une méthode mesurée. Le prestataire dit comment il sait qu'il trouve les erreurs, et ce qu'il rate.

Quand lancer l'audit ?

Le plus tôt possible, avant le premier chargement de test. C'est le moment où corriger coûte le moins et où le planning de reprise peut encore intégrer les corrections. Pour un intégrateur, c'est un livrable en amont du projet, qui sécurise ce planning.

Gimlo AI est proposé en programme d'audit pilote accompagné, pour les ETI en préparation de migration ERP. Pour voir comment l'audit se déroule, consultez les trois étapes ou les questions fréquentes.