La phrase revient à chaque première réunion : « notre base, honnêtement, personne ne sait vraiment ce qu'il y a dedans ». Elle est prononcée sur un ton d'excuse, comme si c'était une anomalie. C'est en réalité la situation la plus courante dans les PME et les ETI qui ont plus de dix ans d'existence.
Ce n'est pas rédhibitoire. C'est simplement la première tâche du projet, et elle se conduit dans un ordre précis.
Pourquoi il faut absolument passer par là
La tentation est de sauter l'étape, de donner un accès en lecture et de laisser le modèle explorer. Cela produit des réponses. Elles sont plausibles et partiellement fausses, ce qui est la pire configuration possible, puisque rien ne signale l'erreur.
Une base ancienne contient invariablement des tables abandonnées après une migration, des colonnes dont le nom ne correspond plus au contenu, des champs libres détournés de leur usage d'origine, des doublons de référentiel et des règles métier connues de trois personnes.
Aucun modèle ne peut deviner ces éléments : ils ne figurent nulle part dans le schéma. La cartographie consiste précisément à les faire sortir.
Étape 1 : partir des questions, pas des tables
Le réflexe naturel consiste à ouvrir le schéma et à le documenter table par table. Sur une base de deux cents tables, c'est un chantier de plusieurs mois dont l'essentiel ne servira jamais.
La bonne entrée est inverse. Réunissez cinq à dix questions réelles, formulées par les métiers, qui restent aujourd'hui sans réponse rapide. Écrivez-les dans leurs mots, pas dans un vocabulaire technique.
Ces questions désignent un sous-ensemble de tables, presque toujours entre dix et vingt. C'est ce sous-ensemble qu'on documente, et lui seul. Le reste attendra qu'un usage le réclame.
Étape 2 : mesurer ce que contiennent réellement les colonnes
Ne vous fiez pas aux noms. Sur le périmètre retenu, mesurez, colonne par colonne : le taux de remplissage, le nombre de valeurs distinctes, les valeurs les plus fréquentes, les valeurs extrêmes, et l'amplitude des dates.
Ce profilage se fait en quelques requêtes et révèle en une demi-journée ce qu'une lecture de documentation ne montrerait jamais. Une colonne remplie à quatre pour cent est morte. Une colonne « commentaire » qui contient systématiquement un numéro est un champ détourné. Une date qui s'arrête en 2019 signale une table remplacée par une autre.
Étape 3 : identifier les tables mortes
Trois indices suffisent le plus souvent : la date d'écriture la plus récente, l'existence d'une table au nom voisin avec un suffixe, et l'absence de référence depuis les autres tables.
Faites valider la liste par la personne qui connaît le mieux l'historique, en une réunion. Le sujet se traite plus vite à l'oral qu'en analyse, parce que la réponse est souvent « ah oui, celle-là c'est l'ancienne, on a migré en 2021 ».
Étape 4 : faire sortir les règles non écrites
C'est l'étape décisive, et elle n'est pas technique. Elle consiste à interroger les personnes qui écrivent aujourd'hui les requêtes, ou qui produisent les états mensuels à la main.
Une question suffit, posée pour chaque indicateur connu : quels filtres appliques-tu, et pourquoi ? Les réponses ressemblent à ceci.
- On exclut toujours les commandes au statut annulé, et aussi le statut 7 qui veut dire annulé mais n'a jamais été renommé.
- Les montants négatifs sont des avoirs, il faut les compter à part.
- L'entité juridique fermée en 2022 doit sortir, sauf pour l'historique avant sa fermeture.
- Les lignes créées par le compte de test ne comptent pas.
Chacune de ces phrases vaut une ligne dans une vue. Ensemble, elles constituent la véritable documentation de votre base, et elles n'existaient jusque-là que dans une mémoire humaine.
Étape 5 : trancher le vocabulaire
Reste à régler les mots qui désignent plusieurs choses. « Client » est le cas d'école : entité facturée pour la comptabilité, compte commercial pour les ventes, contact pour le support.
La règle est de ne pas arbitrer entre les trois, mais de les nommer distinctement. Trois vues, trois noms explicites, et l'utilisateur voit laquelle il interroge. Vouloir imposer une définition unique déclenche un débat interne qui n'a jamais de fin et bloque le projet.
Étape 6 : écrire les vues, et les faire relire
À ce stade, l'écriture des vues est presque mécanique : le périmètre est connu, les colonnes mortes écartées, les règles explicites, le vocabulaire fixé.
Le point à ne pas sauter est la relecture par quelqu'un du métier. Pas une relecture technique : on lui montre le résultat de la vue sur une période dont il connaît les chiffres, et on compare. Les écarts qui apparaissent à ce moment sont autant de règles oubliées à l'étape 4.
Combien de temps cela prend
Nous n'avançons pas de durée standard, parce qu'elle dépend entièrement de deux facteurs : le nombre de tables réellement concernées et la disponibilité des personnes qui portent la connaissance métier.
Le second pèse plus lourd que le premier. Une base compliquée avec un référent disponible se cartographie plus vite qu'une base simple dont la seule personne compétente a trois jours de disponibilité par mois. C'est le point à sécuriser avant de lancer le projet, davantage que le budget.
Ce que vous gagnez au passage
La cartographie a une valeur qui dépasse le projet IA. À la fin, vous disposez d'une documentation à jour d'un périmètre critique, de la liste des tables mortes, et des règles métier écrites ailleurs que dans une mémoire individuelle.
Plusieurs de nos clients ont découvert à cette occasion des anomalies de données qu'aucun contrôle ne remontait. Ce n'était pas l'objectif annoncé, c'est pourtant souvent le premier résultat tangible.
La suite, exposition des vues, droits par rôle et mise entre les mains d'utilisateurs réels, est décrite sur la page serveur MCP et interrogation des données en langage naturel. Et si le sujet de la qualité de données prend le dessus, un audit IA permet de traiter les deux dans le même mouvement.
