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.

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.

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

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.

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.