Introduction

Les grands modèles de langage, ou LLM, ont la cote. C’est souvent le genre de technologie qu’on sous-entend aujourd’hui quand on parle d’IA. Leur promesse: agir comme l’employé le plus compétent, le plus rapide, et le moins cher de votre entreprise. Le rêve, n’est-ce pas?

Mais comme toute jeune recrue brûlant de faire ses preuves, un LLM doit avant tout s’intégrer dans l’entreprise qui l’exploite. Dans le monde moderne, cela signifie avant tout de savoir accéder à la bonne information au bon moment.

Et c’est là que le bas blesse: si la donnée est abondante (ça fait des années qu’on enregistre tout et n’importe quoi), si son accès tend à se standardiser (API, MCP et autres acronymes offrent un cadre d’échange presque universel), un LLM bute encore sur la sémantique nécessaire à la transformation de la donnée en information.

Autrement dit, il ne suffit pas de brancher votre IA à votre base de données, encore faut-il lui expliquer le sens de ce qu’elle observe pour espérer qu’elle puisse en faire bon usage lors de vos sessions d’utilisation.

OpenMetadata

OpenMetadata est un outil open source qui facilite l’enrichissement sémantique de vos données. Toutes sortes de sources de données sont supportées, mais je ne parlerai dans ce billet que de bases de données relationnelles, et plus particulièrement de PostgreSQL.

C’est un outil assez complet, qui permet d’annoter vos sources de données afin de les enrichir de différentes manières:

• Chaque entité (schéma, table, colonne, …) peut être décrite par un texte libre.
• Chaque entité peut également recevoir des tags arbitraires, par exemple pour indiquer le degré de confidentialité des données qu’elle recouvre.
• La gouvernance de la donnée est rendue possible par la définition et la vérification des permissions d’accès aux sources de données.
• Un glossaire d’entreprise peut être associé aux données afin de définie une terminologie commune au sein de toutes les données.
• La traçabilité des données (data lineage) est rendue possible en spécifiant la manière dont un jeu de données dérive de diverses sources de données.

OpenMetadata se connecte à de nombreux types de données et facilite la vie de ses utilisateurs en automatisant certaines tâches rébarbatives de la gouvernance de la donnée.

Par exemple, lorsqu’une base de données PostgreSQL est ajoutée, la structure de cette base est inspectée, et schémas, tables et colonnes avec leurs types, relations,  contraintes et descriptions sont automatiquement copiés. Un processus actualisé périodiquement cette connaissance, et il est possible de la compléter ou de la corriger.

Par ailleurs OpenMetadata expose un serveur MCP, ce qui permet à une IA d’exploiter simplement la connaissance qui y est enregistrée.

Impact des méta-données sur la qualité des réponses d’un LLM

Je disais en introduction que l’efficacité de l’usage d’un LLM reposait grandement sur la « compréhension » qu’il peut avoir des données liées à l’entreprise qui l’exploite. On peut distinguer plusieurs types d’enrichissement semantiques qui peuvent lui être profitables.

• Une description des ressources permet d’établir leur pertinence par rapport à une requête. Par exemple « profil salarial de chaque employé » sera plus parlant que simplement le nom de table « psalemp« .
• Les relations entre tables, par exemple par l’explication des clefs étrangères, permettent de réaliser des jointures qui ont du sens. Elles permettent également de clarifier la nature des relations. Par exemple, dans une table, employee_id désigne le bénéficiaire actuel d’une voiture de société. La multiplicité des relations (one-to-one, one-to-many, etc.) apporte un éclairage supplémentaire sur la modélisation des données tout en réduisant le risque de produire des requêtes SQL aux résultats erronés.
• Les encodages propres à une colonne sont explicités. Par exemple, 0 peut indiquer une personne célibataire, 1 indiquera qu’elle est en couple, tandis que 2 indique une situation maritale inconnue. Dans une autre colonne, JOUR désignera du personnel journalier, SAL un salarié et FL une personne en free-lance.
• Les contraintes d’unicité et de nullité des colonnes précisent le modèle de données en indiquant au LLM ce à quoi il doit s’attendre dans sa manipulation des sources de données.

Évaluation de l’impact de l’enrichissement sémantique sur les résultats d’un LLM

Tentons de déterminer la véracité de mon affirmation, selon laquelle une connaissance de la sémantique des données améliore la qualité des réponses fournies par un LLM.

Nous allons considérer un jeu de données de référence, et vérifier l’impact que peut avoir l’enrichissement sémantique sur la capacité d’un LLM à fournir des réponses correctes, précises et utiles.

AdventureWorks

AdventureWorks est une base de données d’exemple célèbre créée par Microsoft pour une entreprise fictive de fabrication de vélos. Elle est principalement utilisée pour l’apprentissage et la pratique de SQL, de l’analyse de données et de Power BI.

Differentes variations de cette base de données existent sur Internet. J’ai choisi un portage sur PostgreSQL.

La base de données n’est pas triviale, avec plus de 100 tables et vues, réparties en dix schémas.

Propriété intéressante de ma version de AdventureWorks: les schémas originaux sont doublés de schémas aux noms cryptiques (souvent limités à un caractère). Ces schémas sont constitués de vues aux noms tout aussi dénués de sens. Nous avons ainsi deux versions des mêmes relations: celle de base, ayant des noms le plus souvent révélateurs pour un expert métier, et celle basée sur des vues, dont le sens ne peut être deviné à la lecture de leurs noms.

La base de données a été importée dans OpenMetadata, et chaque schéma, table, vue et colonne a été décrite. Les contraintes des colonnes (clef primaire, clef étrangère, unicité, …) ont été précisées.

Préparation du LLM

Claude Desktop a été installé sur la machine qui héberge les containers Docker de AdventureWorks et OpenMetadata. Les connecteurs appropriés ont été configurés afin de permettre au LLM d’interroger ces deux services.

Questions d’évaluation

Afin d’évaluer le bénéfice des méta-données sur les réponses fournies par le LLM, nous avons sélectionné huit questions. Y répondre nécessite une connaissance de la sémantique de la base de données.

Q1. Particuliers vs revendeurs par territoire

« Pour chaque territoire de vente, donne le nombre de clients particuliers et le nombre de clients revendeurs (magasins), trié par territoire. »

Teste : localiser la bonne table client (nom à 1 lettre), distinguer particulier/revendeur, jointure vers le référentiel territoires pour le libellé.

Q2. CA net par catégorie de produit de haut niveau

« Quel est le chiffre d’affaires net (après remise ligne) par catégorie de produit de plus haut niveau — pas la sous-catégorie ? »

Teste : double jointure Produit → Sous-catégorie → Catégorie (aucune colonne catégorie directe sur la table produit), et la formule de CA puisqu’il n’existe pas de colonne « montant ligne » (qty × prix × (1-remise) à reconstruire).

Q3. Répartition des types de personnes

« Combien de personnes dans la base sont des employés actifs, combien sont des clients particuliers, et combien sont des contacts rattachés à des magasins ou des fournisseurs ? »

Teste : décodage d’un code à 2 lettres non explicite (EM/IN/SC/VC/GC) porté par une colonne char(2), et jointure vers une autre table pour la notion d’« actif ».

Q4. Commandes d’achat en attente vs clôturées

« Combien de commandes passées auprès de nos fournisseurs sont encore en attente de traitement, et combien sont totalement clôturées ? »

Teste les limites réelles d’OpenMetadata autant que son apport : le statut est un smallint sans dictionnaire de valeurs exact même dans la description — bon indicateur du risque d’hallucination des codes numériques.

Q5. Adresse du siège des plus gros fournisseurs

« Donne la ville du siège (adresse principale) de chacun de nos 10 plus gros fournisseurs par montant total commandé. »
Teste une jointure à 3 tables (entité ↔ adresse ↔ type d’adresse) et le choix du bon type d’adresse parmi plusieurs types possibles rattachés à une même entité.

Q6. CA par grande zone géographique

« Regroupe le chiffre d’affaires total par grande zone géographique — pas par territoire individuel, mais par le regroupement de plus haut niveau auquel chaque territoire appartient. »

Teste la reconnaissance d’une colonne de regroupement distincte du nom du territoire lui-même (facile à manquer sans description).

Q7. Poids des offres réservées aux revendeurs

« Quelle part du chiffre d’affaires provient de lignes de commande bénéficiant d’une offre spéciale destinée aux revendeurs, par opposition à celles destinées aux clients particuliers ? »

Teste la jointure ligne de commande → offre spéciale et le décodage d’un champ catégorie textuel (‘Reseller’ vs ‘Customer’) non déductible du nom de table.

Q8. Fabrication interne vs achat externe

« Parmi les produits actuellement commercialisés, quelle proportion est fabriquée en interne plutôt qu’achetée à un fournisseur externe ? »

Teste le décodage d’un flag booléen métier et la logique de filtre « en vente actuellement » (date de fin nulle ou future).

Quatre conditions

Les questions d’évaluation seront soumises au LLM sous quatre conditions différentes:

A. En utilisant uniquement les schémas dérivés, dont les vues ont des noms cryptiques, et sans avoir recours à OpenMetadata.

B. En utilisant uniquement les mêmes schémas dérivés, mais en permettant l’usage d’OpenMetadata.

C. En utilisant les schémas originaux, dont les tables et vues ont des noms évocateurs, mais sans permettre l’usage de OpenMetadata.

D. En utilisant les schémas originaux, en permettant l’usage de OpenMetadata.

Consignes générales

Afin de limiter autant que possible la contamination du modèle d’une question à l’autre, chaque question est posée dans une nouvelle session, en mode incognito. Le modèle Sonnet 5, effort moyen, est utilisé.

De plus, chaque question est précédée de la consigne suivante:

Réponds à la question suivante en ne te basant que sur ce qui est vérifiable à partir de la base de données locale "AdventureWorks". 
N'utilise pas tes connaissances générales si elles ne peuvent être vérifiées par l'usage de connecteurs. Donc, pas de supposition sur le nom ou le sens des schémas, des tables et des colonnes qui ne puisse être formellement vérifiée.
N'utilise pas de connexion à Internet pour répondre à la question. 
N'utilise pas de connexion à Internet pour répondre à la question. 
N'utilise pas de connaissance issue d'une précédente discussion.
Si tu ne sais pas répondre, dis-le plutôt que d'inventer la réponse.
Avant de répondre, indique les requêtes que tu as réalisées envers la base de données.

Pour les conditions A et B, la consigne suivante est ajoutée:

N'utilise que les schémas suivants de la base de données, à l'exclusion de tout autre: 
- hr
- pe
- pr
- pu
- sa

Pour les conditions C et D, la consigne suivante est ajoutée:

N'utilise que les schémas suivants de la base de données, à l'exclusion de tout autre:
- humanresources
- person
- production
- purchasing
- sales

Pour les conditions A et C, le connecteur OpenMetadata est désactivé et la consigne suivante est ajoutée:

N'utilise pas OpenMetadata.

Pour les conditions B et D, le connecteur OpenMetadata est activé et la consigne suivante est ajoutée:

Utilise OpenMetadata si pertinent pour affiner ta compréhension de la base de données.

Interprétation des résultats

Le résultat le plus net de mon expérience concerne la question portant sur les commandes fournisseurs en attente et clôturées. Sans accès au catalogue, face à des schémas obfusqués, Claude s’est trouvé dans l’incapacité de relier les codes numériques de la colonne de statut à leur signification métier : aucune contrainte, aucun commentaire, aucune table de référence ne permettait de reconstituer ce lien depuis la structure seule. La réponse honnête a alors été un refus argumenté de trancher, ce qui ne rend aucun service à l’utilisateur métier qui attend un chiffre. Avec l’accès à OpenMetadata, la description de colonne explicite « 1 = Pending, 2 = Approved, 3 = Rejected, 4 = Complete » a permis de répondre immédiatement et avec certitude : 225 commandes en attente, 3 689 clôturées. C’est exactement le type de gain recherché : transformer une impasse analytique en réponse exploitable.

Ce cas illustre un principe plus général: le catalogue ne se contente pas d’accélérer une réponse que le modèle aurait de toute façon trouvée, il élargit l’espace des questions auxquelles une réponse fiable peut être apportée. Sur des colonnes encodées (statuts numériques, indicateurs sans contexte, catégories abrégées, …), l’absence de documentation transforme une question business simple en zone d’incertitude que le modèle doit soit deviner, au risque de se tromper, soit refuser de trancher, au prix de l’utilité.

Un deuxième avantage, moins spectaculaire mais tout aussi structurant, tient à la capacité du catalogue à fournir une source citable et vérifiable pour chaque affirmation métier. Dans les réponses produites avec accès à OpenMetadata, chaque terme employé (« fournisseur », « client particulier », « zone géographique », « chiffre d’affaires net ») a pu être rattaché à une définition de colonne ou de table explicitement consultée, avec citation. C’est ce qui permet de distinguer un fait vérifié d’une supposition plausible, une distinction cruciale dès lors que ces réponses servent à orienter des décisions. Sur la question du chiffre d’affaires par territoire, par exemple, la description confirmant que la colonne group désignait un regroupement géographique de niveau supérieur a permis de lever une ambiguïté que le nom de colonne seul ne suffisait pas à clarifier.

Il convient toutefois d’exposer ces résultats avec la rigueur qui s’impose. Sur l’ensemble des huit questions, une seule a produit un écart de résultat véritablement dépendant du catalogue entre les conditions avec et sans OpenMetadata. Pour les sept autres, Claude a le plus souvent compensé l’absence de métadonnées par un raisonnement empirique: inspection des valeurs distinctes, vérification de contraintes de clé étrangère et recoupement entre tables. Cela réduit l’écart mesurable entre les conditions. La cause a été identifiée avec un niveau de confiance élevé : AdventureWorks présente des noms de colonnes et de tables sémantiquement transparents dans la grande majorité des cas, ce qui permet au modèle de reconstruire le sens sans documentation externe. Le bénéfice du catalogue ne devient pleinement mesurable que sur les colonnes dont le sens ne peut être déduit de la structure seule.

Malgré ces réserves, la valeur ajoutée d’OpenMetadata dans ce type de contexte se dessine avec suffisamment de clarté. L’intérêt du catalogue n’est pas de remplacer la capacité de raisonnement du modèle sur des schémas déjà lisibles, mais de sécuriser les zones où cette lisibilité s’effondre. Il s’agit de la situation la plus fréquente dans les environnements de production réels, où les conventions de nommage historiques, les abréviations héritées et les codes métier non documentés sont la norme plutôt que l’exception. AdventureWorks, conçu comme jeu de données pédagogique, sous-estime structurellement ce phénomène par rapport à un entrepôt de données d’entreprise vieux de quinze ans.

Cette observation a une portée directe au-delà du seul cadre expérimental: dans un environnement réglementé où la traçabilité des définitions métier conditionne la confiance accordée à une réponse générée par IA, la capacité du catalogue à fournir une source vérifiable pour chaque affirmation constitue un avantage qui dépasse la seule précision du SQL généré. Elle touche à l’auditabilité de la réponse elle-même: un critère au moins aussi important que l’exactitude du résultat dans un contexte où les décisions prises sur cette base doivent pouvoir être justifiées a posteriori.

En résumé, cette expérience établit un signal positif mais limité: là où le catalogue est mobilisé sur une zone d’ambiguïté réelle, il transforme un refus de répondre en réponse fiable et traçable: un gain de valeur immédiate pour un utilisateur métier. Sur un schéma aussi lisible qu’AdventureWorks, ce gain reste ponctuel plutôt que systématique; il serait vraisemblablement plus marqué sur un schéma d’entreprise réel, dont les conventions de nommage sont rarement aussi transparentes.