Vous demandez à un agent IA « le chiffre d'affaires du mois » et il vous répond avec aplomb. Le problème : il a peut-être lu le mauvais tableau, appliqué une définition périmée du « client actif » ou mélangé deux périmètres. Dans la plupart des projets d'agents en entreprise, ce n'est pas le modèle qui se trompe, c'est le contexte qu'on lui donne. Cet article explique ce qu'est une couche de contexte métier, pourquoi elle devient une brique d'infrastructure à part entière, et comment l'appliquer à une PME sans plateforme géante.
Pourquoi un bon prompt ne suffit pas
Un agent généraliste ne connaît ni vos définitions, ni vos règles, ni vos sources de confiance. Pour répondre à une question métier, il doit les reconstituer à chaque fois. Databricks décrit ce travail dans un billet publié le 5 octobre 2026 : sans contexte préparé, un agent généraliste doit « crawl schemas, sample tables, read documents, and run repeated queries », ce qui consomme du temps et des jetons et expose à des erreurs d'interprétation (extraits en anglais, traduction libre : il doit parcourir les schémas, échantillonner les tables, lire des documents et relancer des requêtes).
Trois symptômes reviennent quand ce contexte manque :
- des réponses plausibles mais fausses, parce que deux définitions du même indicateur coexistent dans l'entreprise ;
- des coûts qui dérivent, parce que l'agent explore beaucoup avant de répondre ;
- une confiance qui s'érode, parce que personne ne sait d'où vient un chiffre.
Ajouter des consignes au prompt aide un temps, mais le prompt devient vite un fourre-tout impossible à maintenir. La bonne réponse est de sortir le contexte du prompt et de le gérer comme un actif.
Ce que Databricks appelle Genie Ontology
Databricks présente Genie Ontology comme une compréhension continuellement mise à jour du savoir institutionnel d'une entreprise : définitions métier, règles, relations et sources fiables. L'architecture décrite repose sur deux couches complémentaires.
- Le contexte curé : des concepts gouvernés et certifiés dans Unity Catalog, le catalogue de gouvernance de Databricks (par exemple des « metric views » et des pages qui servent de wikis gouvernés).
- Le savoir appris : des faits extraits automatiquement de tableaux de bord, documents, requêtes, notebooks et applications connectées. Le billet l'explique ainsi : il est impossible de curer chaque concept à la main, d'où des « ontology snippets », des faits sur l'entreprise que le système a appris et évalués.
Un mécanisme de classement, appelé OntoRank, hiérarchise ces éléments selon des signaux comme la certification, l'usage et l'auteur. L'agent s'appuie d'abord sur les actifs certifiés par des humains avant d'explorer seul.
Le billet illustre le tout avec un cas interne : un chef de produit prépare une revue hebdomadaire d'adoption. Le système identifie un indicateur certifié d'utilisateurs actifs hebdomadaires, va chercher du contexte dans Google Docs, Jira et Slack via MCP, produit l'analyse, planifie la revue de façon récurrente, puis transforme la conversation en agent partageable. Le billet précise aussi que ce contexte est sensible aux permissions : l'agent n'utilise que les données et connaissances auxquelles l'utilisateur a accès.
Ce billet est une publication éditeur : il décrit l'usage interne chez Databricks et ne donne ni chiffre de performance ni tarif. Il faut le lire comme une architecture de référence, pas comme une preuve de résultat.
Ce qu'on peut en retenir, même sans cette plateforme
Vous n'avez pas besoin de Databricks pour appliquer le principe. Trois idées se transposent à toute entreprise qui déploie des agents.
1. Une définition unique par indicateur
Les « metric views » de Databricks reposent sur un principe simple, exposé dans leur documentation : séparer la définition d'une mesure des champs qui servent à la regrouper, afin de définir une métrique une seule fois et de l'interroger ensuite sous différents angles. Le même réflexe vaut partout : un document de référence qui fixe ce que veut dire « client actif », « marge » ou « délai de livraison », avec un responsable nommé.
2. Une hiérarchie de sources
Dites explicitement à l'agent quelles sources font autorité, lesquelles sont indicatives et lesquelles sont à ignorer. L'idée d'un classement par certification, usage et auteur est transposable en version légère : une liste ordonnée de sources, avec la date de dernière validation.
3. Des permissions héritées, pas recréées
Un agent ne doit pas avoir plus de droits que la personne qui l'utilise. Plutôt que de lui donner un compte à large accès, faites-le travailler avec les droits de l'utilisateur, ou avec un compte de service limité à ce qui est strictement nécessaire.
Le rôle de MCP
Pour que l'agent aille chercher le contexte là où il se trouve, un standard de connexion est utile. Le Model Context Protocol (MCP) se définit lui-même comme un standard open source pour connecter des applications d'IA à des systèmes externes : sources de données, outils et workflows. Sa documentation l'image comme un port USB-C pour les applications d'IA.
MCP règle la connexion. Il ne règle ni la qualité de ce qu'on récupère, ni les droits qu'on accorde. Brancher dix sources sans hiérarchie ni définitions, c'est donner à l'agent dix façons de se tromper. C'est pourquoi la couche de contexte et la gouvernance des accès doivent être pensées avant la multiplication des connecteurs.
Une démarche en cinq étapes pour une PME
Voici une méthode que l'on peut mener sans infrastructure lourde, en complément du cadrage d'un premier agent IA.
- Lister les dix questions que l'agent devra traiter en pratique, formulées par les personnes qui les posent aujourd'hui.
- Relever les termes ambigus dans ces questions (client actif, dossier clôturé, marge) et les faire trancher par un responsable.
- Désigner les sources de référence pour chaque question et noter qui les maintient.
- Écrire les règles d'accès : qui peut demander quoi, quelles données l'agent peut lire, quelles actions exigent une validation humaine.
- Tester sur des cas réels : comparer les réponses de l'agent aux réponses attendues et corriger d'abord les définitions, ensuite seulement le prompt.
Cette démarche s'insère naturellement dans notre approche en étapes : cadrer, prototyper, mettre en production, transférer. Elle vaut aussi bien pour un agent branché sur des workflows, comme ceux décrits dans notre article sur n8n et les agents, que pour un assistant interne.
Les limites à garder en tête
- Un contexte appris automatiquement peut se tromper. Il doit rester sous contrôle humain, avec la possibilité de voir d'où vient chaque élément.
- Le contexte vieillit. Une définition non revue depuis un an est un risque ; prévoyez une date de revue.
- Le coût de curation est réel. Mieux vaut commencer par les dix indicateurs qui comptent que par un référentiel exhaustif.
- Les annonces éditeurs ne sont pas des mesures. Testez sur vos propres cas avant de généraliser.
Questions fréquentes
Qu'est-ce que le contexte métier d'un agent IA ?
C'est l'ensemble des définitions, règles, relations et sources de référence qui permettent à l'agent d'interpréter correctement une question propre à votre entreprise. Il complète le modèle, qui ne connaît pas ces éléments.
Faut-il une plateforme de données pour en bénéficier ?
Non. Une base de définitions maintenue par des responsables, une liste de sources hiérarchisée et des règles d'accès claires apportent déjà l'essentiel pour une PME. Les plateformes automatisent et industrialisent ce travail à grande échelle.
MCP suffit-il à rendre un agent fiable ?
Non. MCP standardise la connexion aux systèmes, mais ne garantit ni la qualité des données ni la gestion des droits. Ces deux points relèvent de votre gouvernance.
Par où commencer concrètement ?
Par les dix questions les plus fréquentes que l'agent devra traiter, et par la clarification des termes ambigus qu'elles contiennent. C'est peu coûteux et cela améliore immédiatement la fiabilité.
Passer du principe au projet
Si vous préparez un agent et que vous voulez fiabiliser son contexte avant de multiplier les connecteurs, un premier échange permet de repérer les définitions à trancher et les sources à hiérarchiser. Nos offres et tarifs publics détaillent ce que nous réalisons, de l'audit à la mise en production.
Sources : Databricks, How Genie Ontology powers product development at Databricks (5 octobre 2026) ; Databricks, Unity Catalog metric views ; Model Context Protocol, What is MCP?.