L'audit de données : la phase qu'on néglige toujours

Tout le monde veut commencer à construire. L’audit produit des livrables moins spectaculaires qu’une démo applicative : un inventaire mesuré, une cartographie des risques et une restitution des décisions à prendre. C’est pourtant la phase qui conditionne tout le reste.

Ce qu’un audit doit réellement produire

Un bon audit ne se contente pas de lister des tables. Il répond à une question simple : qu’est-ce qui est réellement migrable, et à quel risque ?

Concrètement, cela passe par :

1. l’extraction et l’analyse des données réelles du périmètre convenu, en documentant les éventuelles limites d’accès ;
2. la mesure des volumétries effectives, pas des chiffres annoncés ;
3. l’identification des incohérences, doublons et cas limites ;
4. la compréhension des dépendances fonctionnelles entre objets.

Le livrable n’est pas un rapport de conformité. C’est une cartographie chiffrée du risque : ce qui passe tel quel, ce qui demande une règle de transformation, ce qui exige un arbitrage métier, et dans quelles proportions.

Les anomalies à rechercher

D’un projet à l’autre, les systèmes changent ; les découvertes, elles, se ressemblent :

• des doublons structurels : le même article créé trois fois sous trois codifications, chacune avec son historique propre ;
• des objets orphelins : nomenclatures pointant vers des pièces supprimées, documents rattachés à rien ;
• des référentiels divergents : l’unité de mesure absente ici, codée autrement là, et un tableur quelque part qui fait office de vérité ;
• des données dont l’utilité et la conservation restent à qualifier : versions intermédiaires, brouillons ou objets de test. Leur reprise, archivage ou exclusion demande une décision selon les usages et obligations applicables ;
• des exceptions historiques : par exemple, des enregistrements antérieurs à 2015 soumis à des règles qui ont changé depuis. Leur date seule ne suffit pas à déterminer le traitement.

La documentation ne suffit pas à localiser et dénombrer ces anomalies. Leur impact dépend des objets concernés et des processus qui les utilisent : l’audit sert à les hiérarchiser avant qu’elles ne perturbent la reprise en production.

Vérifier les volumes et les sources annoncés

Une estimation initiale peut omettre des historiques, des versions, des objets orphelins ou des exceptions. Comparez les volumes annoncés aux extractions par famille, puis distinguez ce qui doit être repris, archivé ou exclu.

Recherchez aussi les sources annexes : autres instances, bases locales, exports utilisés comme référentiel. Lorsqu’elles interviennent dans le même périmètre, il faut rapprocher leurs données et convenir du système de référence. Notre article sur les pièges d’une migration PLM décrit ces dépendances.

Mesurer tôt, c’est s’éviter une mauvaise surprise au pire moment.

Pourquoi cette phase est-elle si souvent sacrifiée ?

Trois raisons peuvent conduire à réduire l’audit. Ses livrables paraissent moins immédiats : la cartographie chiffrée et les arbitrages à préparer attirent moins l’attention qu’un prototype d’écran en comité de pilotage. Le planning est déjà sous tension : l’audit paraît compressible parce que ses conséquences sont invisibles au moment où on le coupe. Enfin, le fonctionnement du système source peut être pris à tort comme une preuve de qualité des données. Certaines incohérences y sont tolérées ou compensées par les usages ; elles peuvent provoquer un rejet ou une erreur métier après transformation.

Économiser l’audit ne supprime pas le travail. Cela le déplace en fin de projet, au moment où chaque correction coûte le plus cher.

Comment se déroule un audit chez MigQuest

L’audit est la première phase de notre méthodologie, et il suit toujours la même discipline :

1. extraction des données du périmètre convenu, à volumétrie réelle ; les sources indisponibles et les limites d’analyse sont consignées ;
2. profiling systématique : taux de remplissage, formats, valeurs hors référentiel, distributions ;
3. mesure des volumétries par type d’objet, historiques et versions comprises ;
4. cartographie des dépendances : quels objets doivent migrer ensemble, et dans quel ordre ;
5. restitution chiffrée : périmètre réel, anomalies par famille, risques hiérarchisés.

L’audit localise les difficultés observées, mesure leur portée et rend explicites les incertitudes restantes.

Le périmètre, les accès, la mobilisation métier et le calendrier sont convenus au cadrage de l’audit. La restitution sert ensuite à estimer la migration, dimensionner la chaîne et organiser les arbitrages nécessaires.

Auditer, c’est déjà réduire le risque

Une anomalie repérée peut être affectée à un responsable, corrigée ou arbitrée, puis vérifiée avant la bascule. La repérer ne garantit pas sa résolution. L’audit rend le travail visible et estimable ; les phases suivantes doivent démontrer que le traitement convient et que les écarts restants sont acceptables. C’est ainsi qu’il contribue à réduire les risques opérationnels de la reprise.

C’est exactement l’esprit de la démarche : travailler à partir des données réelles, pas des hypothèses. Le reste de la migration en dépend.