Documenter une base de données avant de brancher une IA dessus

Documenter une base de données avant de brancher une IA n'est utile que sur un périmètre restreint : les 10 à 20 tables qui répondent à la question métier posée, pas la base entière. Sur ce périmètre, il faut savoir ce que chaque colonne signifie vraiment et pourquoi elle existe. Le reste peut rester dans l'ombre : ce n'est pas là que le risque se loge.

Le problème n'est presque jamais technique. Une base legacy de plus de dix ans a toujours quelqu'un qui sait pourquoi telle colonne porte ce nom, pourquoi tel champ n'est rempli qu'à moitié, pourquoi deux tables qui se ressemblent ne sont pas redondantes. Le vrai risque, c'est que cette personne ne soit jamais interrogée avant que l'IA commence à répondre à sa place.

La méthode qui fonctionne n'est pas un audit exhaustif. C'est un périmètre restreint, choisi par la question posée, complété par ce que savent déjà les gens qui produisent, à la main, les rapports que l'IA doit demain automatiser.

Pourquoi une IA branchée sur une base non documentée ment sans que personne ne le voie

Une IA branchée sur un schéma qu'elle ne comprend pas ne dit pas qu'elle ne sait pas. Elle construit une requête qui s'exécute, qui renvoie un nombre ou une phrase, et rien dans la réponse ne signale que la table jointe n'était pas la bonne.

C'est le résultat le mieux établi sur le sujet. Sur le benchmark académique Spider 1.0, aux schémas propres et documentés, GPT-4o répond correctement à 86,6 % des questions. Sur Spider 2.0, construit à partir de vrais entrepôts d'entreprise avec des schémas de plusieurs milliers de colonnes, ce taux tombe à 10,1 %. Même modèle : seule la base change, et la réponse n'est plus une question de puissance du modèle mais de ce qu'il peut comprendre du schéma qu'on lui donne.

Ce qui rend l'écart dangereux, c'est sa forme. Une requête mal construite sur des données non documentées garde exactement l'apparence d'une requête juste : elle s'exécute, elle renvoie un résultat cohérent avec la question posée, et personne dans la chaîne ne reçoit de signal d'alerte. Sur une base documentée, une colonne ambiguë peut être signalée comme telle. Sur une base opaque, l'IA choisit la lecture la plus plausible du schéma et l'affiche avec la même assurance qu'une bonne réponse.

Le réflexe qui bloque tout : vouloir tout documenter avant de brancher une IA

Le réflexe le plus commun face à une base non documentée est de vouloir tout auditer avant de commencer : chaque table, chaque colonne, chaque contrainte. C'est précisément ce réflexe qui explique qu'un chantier de cartographie ne démarre jamais vraiment.

Une base legacy de dix ans compte souvent plusieurs centaines de tables. La majorité ne sert plus rien : un module abandonné, un test jamais nettoyé, une migration à moitié terminée. Documenter l'ensemble revient à documenter du bruit autant que du signal, pour un chantier sans fin visible que personne ne priorise vraiment.

Le vrai obstacle n'est pas la taille de la base, c'est l'absence de critère pour savoir où s'arrêter. Sans périmètre, un audit de données legacy se transforme en projet permanent, et un projet permanent ne livre jamais rien à brancher.

Partir des questions métier, pas de toute la base de données

La bonne manière de cadrer un périmètre est de partir de ce que l'IA doit répondre, pas de la structure de la base. Si l'objectif est un agent qui répond sur les délais de livraison, la question n'est pas « documentons toute la base logistique », c'est « quelles tables et quelles colonnes portent réellement cette information, du bon de commande à la livraison confirmée ».

En pratique, ce périmètre tient rarement à plus de 10 à 20 tables, même sur une base qui en compte plusieurs centaines. C'est un chantier de quelques jours, pas de plusieurs mois, et il produit un résultat qui peut être branché dès la première itération d'un agent, avant même que le reste de la base soit regardé.

Ce qu'on regarde vraiment dans les colonnes d'une base de données legacy

Une fois le périmètre posé, le travail utile n'est pas de documenter chaque colonne dans l'absolu. C'est de répondre à trois questions pour chacune : est-elle réellement utilisée par un processus actuel, quel est son taux de remplissage réel, et sa valeur est-elle cohérente avec ce que son nom promet.

Une colonne remplie à 12 % n'est pas fiable, même si son nom est parfaitement clair. Une colonne « statut » qui contient sept valeurs différentes, dont trois abandonnées depuis deux ans, raconte l'historique de trois refontes successives, pas l'état réel du processus aujourd'hui. C'est ce genre d'écart, invisible dans un schéma brut, qui produit ensuite une réponse d'IA fausse mais plausible.

Documenter, c'est d'abord extraire la mémoire orale avant qu'elle parte

Les colonnes qui restent après ce tri ont presque toujours une histoire que le schéma ne raconte pas, et cette histoire vit dans la tête de deux ou trois personnes : celles qui produisent déjà, à la main, les rapports que l'IA est censée automatiser demain.

Ce sont elles qu'il faut interroger en priorité, pas les développeurs qui ont construit la base à l'origine. Elles savent pourquoi telle ligne est exclue du calcul, pourquoi tel champ n'est fiable qu'à partir d'une certaine date, pourquoi deux clients apparemment identiques ne le sont pas dans le système.

C'est exactement ce que mesure la notion de bus factor en gestion de projet : le nombre de personnes qui peuvent disparaître avant qu'un savoir critique ne disparaisse avec elles. Sur une base de données legacy, ce chiffre tombe souvent à un.

Ce n'est pas une dette technique. C'est une dette de connaissance métier, qui ne s'accumule pas dans le code mais dans la tête de deux ou trois personnes, et qui ne se rembourse pas en réécrivant le schéma. Documenter, dans ce contexte, veut dire transformer une connaissance orale en règle écrite que n'importe qui, humain ou IA, peut consulter avant d'agir.

Une vérité par définition documentée, pas une définition unique imposée d'en haut

Une fois les règles orales couchées par écrit, la tentation est de vouloir trancher : une seule définition officielle pour chaque métrique, votée en comité. C'est un piège différent mais tout aussi coûteux.

Deux services qui calculent une même notion différemment ont souvent raison chacun dans leur contexte. Un commercial et un contrôleur de gestion ne comptent pas un « client actif » de la même façon, et ce n'est pas une erreur à corriger.

La bonne pratique, celle qu'on documente aussi dans notre article sur la couche sémantique, consiste à écrire plusieurs définitions nommées et assumées plutôt qu'à en imposer une seule. Le schéma source garde sa complexité réelle ; ce qui est documenté, c'est la règle qui transforme cette complexité en réponse fiable pour chaque usage.

Le geste Hyperstack : documenter avant de brancher un agent IA

Cadrer ce périmètre avant tout agent ou tout socle data n'est pas une étape administrative : c'est la condition pour que le reste du projet ne reparte pas de zéro trois mois plus tard. Un agent construit sur une base mal cadrée ne tombe pas en panne. Il continue de répondre, avec de moins en moins de rapport avec la réalité du terrain, jusqu'à ce que quelqu'un remarque un chiffre qui ne colle pas.

C'est la méthode qu'on applique avant tout audit IA ou tout socle data : mapper les pain points, les process et les données réellement en jeu avant de construire quoi que ce soit, pour que les cas d'usage émergent du terrain plutôt que d'un cahier des charges théorique. Un diagnostic de maturité data et IA sert précisément à poser ce périmètre avant d'aller plus loin.

Documenter une base de données avant de brancher une IA n'est donc pas une case à cocher avant le vrai projet : c'est le projet, dans sa première semaine utile. La question à se poser avant de lancer quoi que ce soit reste simple : qui, aujourd'hui, dans votre entreprise, est la seule personne capable de dire pourquoi cette colonne existe, et que se passe-t-il le jour où elle change de poste ?

Si la réponse n'est pas claire, échanger sur vos pain points et vos données pour cadrer ce périmètre avant de construire quoi que ce soit reste le geste le plus rentable. Le vrai risque n'est pas de brancher une IA sur une base mal documentée : c'est de ne jamais savoir qu'elle s'est trompée.

Par l'équipe Hyperstack, agence IA et automatisation en France, 40+ projets IA et data déployés.