Métadonnées, sémantique, ontologie : la pile de contexte qui fiabilise vos agents IA

Vos agents IA n’ont pas un problème de modèle. Ils ont un problème de contexte

La promesse des agents IA est énorme : automatiser, aller plus vite, décharger les équipes. Pourtant, la plupart des projets restent coincés au stade du POC. Le modèle hallucine, les réponses sont approximatives, la confiance ne s’installe pas, et on finit par arrêter.

La cause n’est presque jamais le modèle. C’est ce qu’il y a autour : le contexte. Les définitions métier, les règles, les rôles, l’historique, les relations entre les données. Sans cette matière, un agent fonce tête baissée et fabrique un résultat qui paraît crédible mais ne l’est pas.

C’est le sujet qu’ont disséqué Laurent Dresse, Chief Evangelist chez DataGalaxy, et Charlotte Ledoux, experte indépendante en gouvernance des données et autrice de la newsletter The Data Governance Playbook, lors d’un webinaire dédié. Leur message tient en une idée : un agent ne devient fiable que si on lui donne une vraie pile de contexte, construite en trois couches, exposée proprement, et gouvernée.

Comme le résume Charlotte Ledoux : « Le risque est élevé que la réponse de l’agent ne soit pas correcte. Soyez un peu dans la méfiance par rapport à ce qu’un agent vous donne. »

Ce guide reprend leur démonstration et la traduit en plan d’action.

1. Le « semantic blending » : le risque invisible de vos agents

Prenez un terme aussi banal que « client actif ». Pour le marketing, c’est quelqu’un qui a téléchargé un livre blanc. Pour le commerce, quelqu’un qui a une souscription en cours. Pour la finance, quelqu’un qui paye en temps et en heure. Trois services, trois définitions, un seul et même mot.

Face à ça, un agent IA doit trancher. Et comment tranche-t-il ? « Il prend des hypothèses, il regarde ce qui se rapproche le plus de la question. Mais ça reste un peu du doigt mouillé », explique Charlotte Ledoux. C’est ce qu’on appelle le semantic blending : l’agent mélange des définitions concurrentes et produit une réponse hybride.

Le vrai danger, c’est que ça passe sous les radars. L’agent répond avec aplomb, on lui fait confiance par réflexe, et personne ne voit qu’il a bricolé sa réponse. D’où le conseil de Charlotte Ledoux : prenez des exemples concrets dans votre organisation, montrez à vos équipes qu’un même terme a trois ou quatre définitions, et installez une dose de méfiance saine.

La réponse à ce risque commence par une définition unique et partagée. C’est le rôle du glossaire métier : aligner toute l’organisation sur ce qu’est un « client actif », une bonne fois.

2. Shadow AI : quand l’IA sort de tout contrôle

On connaissait le Shadow IT, quand les métiers souscrivaient à leurs propres outils hors du contrôle de la DSI. Puis le Shadow BI, quand les utilisateurs exportaient un jeu de données dans Excel pour bâtir leur propre reporting. Voici maintenant le Shadow AI.

Le scénario est simple : un collaborateur achète une licence ChatGPT à son nom et l’exécute sur des données de l’entreprise. Aucun contexte, aucune gouvernance, aucun contrôle de sécurité. La donnée fuit, et personne ne le sait.

La parade n’est pas d’interdire l’IA. C’est de donner aux agents un accès cadré : du contexte fiable, une couche de confiance, et une gouvernance qui rend visibles et auditables les sources auxquelles l’agent accède.

3. La pile de contexte en trois couches

Bonne nouvelle de Charlotte Ledoux : « Il ne faut pas paniquer. Certaines briques du puzzle, vous les avez déjà. » Le contexte d’un agent se construit en trois couches qui se complètent.

Couche 1 — Le catalogue : l’inventaire de confiance

C’est la bibliothèque de vos données. Vous y trouvez l’inventaire des assets, leur propriété (data owners, data stewards), le tagging, et le lignage : d’où vient la donnée et quelles transformations elle a subies. Le data catalog et le data lineage répondent à cette première couche.

Un point clé soulevé par Laurent Dresse : ne cataloguez pas pour cataloguer. Partez toujours d’un cas d’usage et de la valeur attendue. Plus vos données sont taguées, plus vous pouvez dire à un agent « connecte-toi au catalogue, utilise les données taguées X, pas les autres ». Le tagging devient un filtre de contexte.

Couche 2 — La sémantique : le sens métier

Ici, on définit le sens. Qu’est-ce qu’un « client actif » ? Dans quels cas cesse-t-il de l’être ? Quelles règles métier s’appliquent ? Cette couche porte les définitions et les règles qui rendent un terme compréhensible dans son contexte. Elle ne descend pas au nom de la colonne ni aux relations entre objets : ça, c’est le travail des deux autres couches.

Et l’outil dans tout ça ? Charlotte Ledoux est directe : démarrer dans un simple tableur, c’est mieux que rien. « Posez-vous plutôt la question de ce que vous allez mettre dedans. Vos définitions métier sont-elles claires ? En général, non. Le vrai sujet est là. » Mettre les définitions au format prend cinq minutes ; se mettre d’accord entre la finance et le marketing prend bien plus longtemps.

Couche 3 — L’ontologie : les relations

La troisième couche décrit les liens entre les concepts et les contraintes qui s’y appliquent : un client actif doit avoir des coordonnées bancaires, au moins une facture, peut-être une facture sur le dernier mois. C’est cette logique qui nourrit le raisonnement de l’agent et l’empêche de produire un résultat incohérent. La construction de ces relations, c’est le data modeling, et elle vient en amont du catalogue.

Pourquoi les trois ? Parce qu’aucune ne suffit seule. Comme le rappelle Laurent Dresse : « Un agent IA n’est pas intelligent. Il agrège de l’information. Si on ne lui a pas dit qu’un client actif doit avoir une facture, il fonce tête baissée et il hallucine. » Catalogue, sémantique et ontologie forment un tout : c’est leur combinaison qui rend le raisonnement d’un agent pertinent.

4. Le MCP : l’USB-C de vos agents

Comment un agent va-t-il chercher tout ce contexte ? Via le MCP (Model Context Protocol). L’analogie de Charlotte Ledoux est parlante : « C’est un peu l’USB-C de l’IA. Une façon de standardiser l’accès des agents à l’information, quel que soit le système. »

Concrètement, prenez une question simple : « affiche-moi le chiffre d’affaires du Q3 sur la région EMEA ». Avant de requêter quoi que ce soit, l’agent doit comprendre le contexte. C’est quoi, le chiffre d’affaires ? C’est quoi, le Q3 ? Faute de définition, un agent chez un constructeur automobile pourrait croire qu’on parle d’un modèle de voiture, pas d’un trimestre. Une fois le contexte compris, il navigue vers les bons systèmes et requête la bonne source.

D’où la notion de maillage de MCP. Les data platforms comme Snowflake ou Databricks exposent leurs métadonnées techniques (tables, colonnes, flux). Un serveur MCP adossé à un data catalog comme DataGalaxy apporte la couche que les catalogues techniques n’ont pas : définitions métier, data owners, domaines, usages, tagging d’expertise opérationnelle. Ce n’est pas l’un ou l’autre. C’est les deux qui se complètent pour que l’agent consomme la bonne information.

5. « Lien qui informe » vs « IA qui agit » : la gouvernance change de dimension

Aujourd’hui, beaucoup d’usages relèvent de l’IA qui informe : l’agent recommande, un humain analyse et tranche. On corrige les erreurs au fil de l’eau, on avance à petits pas. Le risque reste contenu.

Le basculement, c’est l’IA qui agit. Elle décide en autonomie, en millisecondes, sans humain dans la boucle. Et dès qu’une mauvaise décision est prise, elle se propage au reste de l’organisation, parfois à d’autres agents qui consomment la sortie du premier.

L’exemple d’Air Canada est devenu un cas d’école. Un chatbot a analysé les politiques de la compagnie et a inventé sa propre règle de remboursement pour un passager en deuil, une règle qui n’existait pas. Un tribunal canadien a jugé la compagnie responsable : tout comme elle répond des actes de ses employés, elle répond des actes de son IA. Impact immédiat sur la marque, et signal d’alarme fort pour tout le monde.

C’est là que l’EU AI Act entre en jeu : vous êtes responsable de vos agents. Vous devez donc savoir où ils cherchent l’information, comment elle est générée, et où elle est consommée, de bout en bout. La gouvernance se repense autour de cette traçabilité.

La bonne nouvelle, c’est que l’humain garde sa place, autrement. Il n’est pas dans l’usage quotidien des agents (impossible, vu les volumes), mais en amont : c’est lui qui définit les bonnes relations, le bon contexte, les bonnes définitions. Les agents consomment ensuite, à l’échelle industrielle.

6. Par où commencer : 5 actions à lancer maintenant

La feuille de route partagée par Charlotte Ledoux n’est pas séquentielle. Idéalement, on lance ces chantiers en parallèle, parce qu’il faut de toute façon adresser tous ces points.

1. Choisir un cas d’usage prioritaire parce qu’il porte une valeur business identifiée. Construisez un mini business case qui intègre aussi les coûts (tokens, mais surtout la couche de sécurité et de gouvernance à mettre autour de l’agent, souvent sous-estimée).
2. Cartographier les données et métadonnées nécessaires : ce que vous avez déjà, ce qu’il faut aller collecter.
3. Documenter le sens : glossaire, couche sémantique, définitions et règles métier.
4. Documenter les relations : la couche ontologie, le data modeling de vos concepts.
5. Exposer via MCP et gouverner les agents : ownership du contexte, niveau de risque acceptable, sécurité avec votre DSI (à quelles données l’agent accède, et lesquelles il peut exposer), et la question à ne pas oublier — faut-il prévoir un kill switch ?

FAQ : fiabiliser ses agents IA par le contexte

Un simple tableur suffit-il pour démarrer une pile de contexte ? Oui, pour commencer. Le pragmatisme prime. Le temps ne se joue pas sur le format mais sur l’accord entre services autour des définitions. Une fois que vous industrialisez, vous outillez la couche applicative pour faciliter l’intégration avec vos agents.

Quelle différence entre le MCP d’une data platform (type Unity Catalog / Databricks) et celui d’un data catalog ? Ce n’est pas une question de valeur mais de couverture. La data platform donne la vue technique (tables, colonnes, vues, modèles). Le data catalog ajoute la couche métier : définitions, data owners, domaines, usages, tagging d’expertise. Les deux sont complémentaires.

Les règles métier doivent-elles être portées par le glossaire ou par les cas d’usage ? Commencez par une définition unique et propre de vos data assets. Si vous définissez « client actif » pour chaque cas d’usage, vous vous retrouvez avec cinquante définitions et un nouveau problème. Soyez ferme sur l’unicité, puis laissez les différents cas d’usage consommer cette définition.

Qui est responsable si un agent prend une mauvaise décision ? Vous. Le cas Air Canada et l’EU AI Act le confirment : vous répondez des actions de vos agents. C’est précisément pourquoi la gouvernance, l’audit des accès et un éventuel kill switch doivent être pensés tôt.

Faut-il garder un humain dans la boucle ? Pas dans l’usage opérationnel quotidien, ce n’est pas tenable à grande échelle. Mais en amont, oui : l’humain définit le contexte, les relations et les définitions que les agents consommeront ensuite.

Conclusion : le contexte, nouveau socle de confiance de l’IA

Un agent vaut ce que vaut son contexte. Tant que les définitions sont floues, que les relations ne sont pas modélisées et que les accès ne sont pas gouvernés, vos projets resteront au stade du POC. Construisez la pile (catalogue, sémantique, ontologie), exposez-la proprement via le MCP, et gouvernez les agents comme vous gouvernez vos équipes.

Une donnée comprise, c’est un agent fiable, des décisions tracées, et une IA qui crée de la valeur au lieu d’en détruire.

Vous voulez la démonstration complète, avec les exemples et les questions de la salle ?

À propos de l'auteur: Laurent Dresse

Data Governance Kitchen Head Chef

Laurent met à profit sa connaissance approfondie du secteur, son expérience ainsi que son expertise du marché pour partager avec le public les principales tendances, observations et analyses du moment.