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

Tout le monde veut commencer à construire. L’audit, lui, n’a rien de spectaculaire : pas de démo, pas de livrable visible, juste l’inventaire patient de ce qui existe vraiment. 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 :

l’extraction et l’analyse des données réelles, pas d’un échantillon de confort ;
la mesure des volumétries effectives, pas des chiffres annoncés ;
l’identification des incohérences, doublons et cas limites ;
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.

Ce que l’audit révèle presque toujours

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 mortes qui gonflent le périmètre : versions intermédiaires, brouillons jamais promus, objets de test créés en production ;
des exceptions historiques : les enregistrements d’avant 2015 qui ne respectent aucune règle actuelle, parce que les règles ont changé trois fois depuis.

Aucune de ces anomalies n’est visible dans la documentation. Toutes sont critiques au moment du chargement. C’est exactement ce qui fait échouer les migrations en production.

Les volumétries mentent presque toujours

Une estimation de volume fournie en début de projet est, dans la quasi-totalité des cas, sous-évaluée. Les historiques, les versions intermédiaires, les objets orphelins et les exceptions accumulées gonflent le périmètre réel bien au-delà de ce qui était prévu.

Et le périmètre ne tient presque jamais dans un seul système : instances multiples, bases annexes, exports devenus la vraie référence. Une migration PLM réelle réconcilie plusieurs sources ; elle n’en copie pas une seule.

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

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

Trois raisons reviennent systématiquement. L’audit n’a pas de livrable démontrable : des semaines de travail pour produire des chiffres, quand un prototype d’écran impressionne davantage 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. Et surtout, chacun suppose que les données sont bonnes : le système source fonctionne, donc ses données doivent être saines. C’est faux : un système en production tolère très bien des années d’incohérences que le modèle cible, lui, refusera.

É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 :

extraction complète des données sources : pas un échantillon, l’intégralité ;
profiling systématique : taux de remplissage, formats, valeurs hors référentiel, distributions ;
mesure des volumétries par type d’objet, historiques et versions comprises ;
cartographie des dépendances : quels objets doivent migrer ensemble, et dans quel ordre ;
restitution chiffrée : périmètre réel, anomalies par famille, risques hiérarchisés.

L’audit ne dit pas si la migration sera facile. Il dit exactement où elle sera difficile.

Quelques semaines suffisent généralement. Une fraction du projet, pour une visibilité qui conditionne tout le reste : l’estimation des délais, le dimensionnement de la chaîne, et les arbitrages métier à préparer.

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

Chaque anomalie repérée pendant l’audit est une anomalie qui ne fera pas dérailler la production. L’audit ne résout pas les problèmes, mais il les rend visibles assez tôt pour qu’ils soient traitables, et chiffrables. C’est la différence entre provisionner une correction et payer la facture d’un fiasco.

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.