Ontologie ou couche sémantique ? Ce dont a besoin un agent IA de chacune d’elles.
En quoi les ontologies et les couches sémantiques diffèrent, ce qui ne fonctionne pas lorsque l’une seulement existe, où s’inscrivent les graphes de connaissances, et une méthode pratique pour construire la couche de contexte.
Sources: **Ontology vs. Semantic Layer: Why Your AI Agent Needs Both**
En posant une question à trois sources concernant le montant des revenus, les réponses diffèrent souvent : 10,2 M provenant du service financier, 10,4 M du service marketing, et 9,8 M de l’assistant IA intégré à Slack. Personne n’est d’accord. Auparavant, les humains résolvaient ce type de problème lors de réunions courtes. Un agent ne contacte pas un collègue pour demander la signification d’une métrique ; donc, lorsqu’il tombe sur une colonne nommée rev_ttm_adj_v2, il invente une réponse ou choisit la première définition qu’il trouve.
Selon certaines sources, l’intégration de connaissances sectorielles modélisées dans le système de récupération des données permettrait de réduire les hallucinations d’environ 40 %. Cependant, cela ne fonctionne que si ces connaissances existent sous forme modélisée, et non simplement dans la mémoire de quelques personnes ayant créé les tableaux. Le volume de stockage et les compétences des agents ont peu d’importance lorsque seuls des tableaux bruts et du SQL sont utilisés, car l’entreprise ne se fiera pas aux résultats obtenus.
La couche de contexte
La couche de contexte désigne une fonction, et non un produit. Elle rassemble des définitions sémantiques, des connaissances sectorielles, des informations sur l’historique, des politiques de gouvernance, des indicateurs de qualité ainsi que le statut de certification, et les expose via une seule interface destinée aussi bien aux utilisateurs qu’aux agents.
Les ontologies et les couches sémantiques accomplissent la majeure partie du travail ici. Le marketing des fournisseurs a tendance à les confondre, mais chacune traite un problème différent ; une construction dans le mauvais ordre entraîne des projets d’IA qui semblent excellents lors des démonstrations mais se bloquent avant la mise en production.
Division du travail en une phrase
Version courte : la couche sémantique traite des questions comme le montant des revenus, tandis que l’ontologie s’occupe de questions telles que la définition même d’un client.
La couche sémantique est responsable des métriques. Elle définit la manière dont les revenus, le nombre d’utilisateurs actifs par mois et la valeur à vie sont calculés, quels indicateurs utiliser et quels filtres appliquer, afin que toutes les équipes et outils obtiennent des résultats identiques.
L’ontologie est chargée du sens. Elle précise ce qui compte comme client, comment les clients sont liés aux commandes, ce qui fait d’une personne un client de niveau Platinum, et si le logiciel peut en tirer de nouvelles conclusions à partir des faits déjà stockés.
Ontologie : concepts, relations, raisonnement
La définition classique, une spécification formelle explicite d’une conceptualisation partagée, se résume en trois parties :
- Classes : les types d’entités dans le domaine, par exemple Client, Produit, Commande, Région.
- Propriétés et relations : la manière dont ces éléments sont liés. Un client passe une commande, et un produit appartient à une catégorie.
Les ontologies sont écrites selon des normes W3C telles que RDF et OWL, afin que les machines puissent non seulement les lire mais aussi en tirer des conclusions. Supposons que l’ontologie indique qu’un client de niveau Platinum a un chiffre d’affaires annuel supérieur à 1 million, et que les faits montrent qu’Acme en génère 2 millions. Le moteur en déduit alors automatiquement que Acme est de niveau Platinum, sans qu’aucun code if-else n’ait été écrit. Les couches sémantiques et les outils de BI ne peuvent pas faire cela ; ils effectuent uniquement des calculs définis à l’avance et ne déduisent jamais de fait qui n’aurait pas été défini.
Les ontologies relient également les vocabulaires entre les systèmes. Un CRM utilise le terme « Customer », un ERP utilise « Client », le secteur financier utilise « Account », et l’ontologie les associe tous à un seul objet métier. Un agent fonctionnant de cette manière suit un graphe connecté au lieu de deviner en se basant sur des tables non liées. Dans le secteur de la santé, SNOMED CT est l’instance standard, dans les services financiers c’est FIBO, et dans les secteurs réglementés, une ontologie formelle est presque obligatoire.
Le coût est tout aussi évident. Palantir a fait de l’ontologie d’entreprise une catégorie de marché, mais sa mise en œuvre est complexe : ingénieurs intégrés, modélisation manuelle, un délai allant de six à dix-huit mois pour une mise en place complète, ainsi qu’un manque de profils qualifiés en logique formelle.
Couche sémantique : métriques et chiffres cohérents
Cette approche est la plus pratique. Dans les années 1990, Business Objects a introduit Universe, un outil permettant de placer le vocabulaire métier devant des schémas complexes. Le problème de fond persiste : les revenus sont calculés de différentes manières, les chiffres entrent en conflit et la confiance diminue. Aujourd’hui, les enjeux sont encore plus importants, car un manque de cohérence pouvait autrefois entraîner une diapositive peu claire, mais peut désormais conduire à l’inclusion d’un chiffre inventé dans un rapport qui influence les décisions.
Une couche sémantique moderne se compose de quatre éléments :
- Un entrepôt de métadonnées, qui associe des identifiants tels que mrr_calc_v3 au revenu récurrent mensuel.
- Un moteur de logique métier, qui regroupe les formules de mesure en un seul endroit afin qu’elles soient définies une seule fois et réutilisées.
- La traduction des requêtes, qui génère les jointures et les filtres nécessaires.
- Le contrôle d’accès, qui applique de manière cohérente des permissions au niveau des lignes et des colonnes.
Les outils évoluent très rapidement. dbt a ajouté une couche sémantique alimentée par MetricFlow, qui gère les définitions de métriques au format YAML sous contrôle de version et les compile en plusieurs variantes SQL. En septembre 2025, Snowflake, Salesforce, dbt Labs et BlackRock ont lancé le projet Open Semantic Interchange (OSI) ; sa version 1.0, sortie en janvier 2026, a fourni un format neutre pour l’échange de métadonnées sémantiques. Des produits tels que Cube, AtScale, LookML, DAX, Databricks Metric Views et Snowflake Semantic Views vont tous dans le même sens : la couche sémantique devient un élément essentiel au sein des architectures de données prêtes pour l’IA.
Cependant, il existe une limite. La couche peut préciser comment le chiffre d’affaires est calculé, mais pas comment un client se connecte à un marché et à ses réglementations, ni si un compte mérite une étiquette de risque élevé selon les règles de domaine. Jessica Talisman, dans Metadata Weekly, l’a formulé clairement : les couches sémantiques gèrent les recherches, tandis que les ontologies gèrent le contexte et le raisonnement.
Quelles sont les conséquences d’en utiliser seulement une ?
- Seule la couche sémantique fournit des réponses précises mais superficielles. Quel canal a généré le plus de GMV le mois dernier ? Une réponse exacte. Pourquoi a-t-il diminué, ou les dépenses devraient-elles augmenter ? Silence, car rien ne modélise la manière dont les canaux, les dépenses et les profils clients sont interconnectés.
- L’ontologie seule permet de bien décrire les concepts, mais échoue en ce qui concerne les données chiffrées. Est-ce Acme Platinum ? Un raisonnement solide. Qu’a apporté Acme le mois dernier ? À nouveau trois réponses contradictoires, car le système ne dispose d’aucun lien vers la table de faits ou la règle d’agrégation.
Les chiffres du secteur confirment cela. Gartner prédit que plus de 40 % des projets d’IA agente seront abandonnés d’ici la fin de 2027 en raison des coûts élevés, d’une valeur floue et de contrôles insuffisants. Parmi les 248 dirigeants en gestion de données interrogés, 63 % ont admis manquer de pratiques adaptées pour soutenir l’IA. Le modèle n’est que rarement la cause ; les données sous-jacentes n’ont aucune base sémantique.
Le mouvement va également dans l’autre sens. Selon les prévisions du sommet Gartner 2026, des couches sémantiques universelles intégreront les plateformes de données et la cybersécurité en tant qu’infrastructures critiques d’ici 2030, et Futurum estime que leur adoption passera de 16 % cette année à 30 % en 2031. Microsoft présente actuellement une version préliminaire de prise en charge intégrée des ontologies dans Fabric IQ, tandis que Timbr.ai vend des couches sémantiques dotées de capacités de raisonnement. Ces deux approches se rapprochent l’une de l’autre.
Graphes de connaissances et taxonomies
Un graph de connaissances stocke les instances, de sorte que les clients réels et les commandes apparaissent sous forme de nœuds. Pensez à l’ontologie comme au schéma et au graph de connaissances comme aux données elles-mêmes. Un agent qui suit les relations en temps de exécution se déplace à travers ce graphique.
Une taxonomie est une ontologie simplifiée : des hiérarchies de parents et d’enfants, sans inférence ni liens latéraux. Les catalogues de produits, la classification des domaines de données et l’étiquetage des PII commencent généralement par là, ce qui constitue un bon point de départ. Une ontologie complète n’est nécessaire que lorsque l’agent doit raisonner à travers plusieurs catégories, par exemple pour déterminer si une dégradation dans la catégorie A affecte les stocks de la catégorie B.
Comment les éléments s’assemblent
La couche de contexte se divise en deux parties :
- Contexte des données : ontologie, couche sémantique, graphe de connaissances, filiation, scores de qualité et politique d’accès. Elle indique à l’IA dans quel type d’entreprise elle opère.
- Contexte de l’application : préférences de l’utilisateur, historique des conversations, documents du domaine et faits récupérés (mémoire + RAG). Elle indique à l’IA avec qui elle communique.
Une seule question passe par quatre étapes :
- L’ontologie définit un concept tel que la reconnaissance des revenus, avec les règles qui y sont associées.
- La couche sémantique le transforme en opérations de calcul : quels tableaux joindre et comment les agréger.
- Le graphe de connaissances relie le concept à ses métriques, à son historique et aux utilisateurs finaux.
- MCP fournit le contexte à l’agent au moment de l’inférence.
Deux années de discussions sur l’ingénierie du contexte convergent ici : une sortie fiable nécessite un contexte structuré, et les ontologies ainsi que les couches sémantiques représentent les deux parties les plus difficiles. MCP résout le problème de la transmission, pas celui du contenu. Donnez à un agent des tableaux non régulés et du SQL, et le protocole transmettra fidèlement une hallucination.
La méthode d’un fournisseur
Un fournisseur de bases de données décrit sa solution comme une pile sémantique ouverte, également appelée OSI, qui combine des métriques, des définitions, des données brutes, un graphe de contexte et une ontologie au lieu d’une autre couche sémantique de BI. Elle se compose de trois couches :
- En bas, la couche sémantique : définitions de métriques, règles de calcul et mappages des dimensions vers les données. Elle s’appuie sur la norme Ant-OSI, fonctionne avec l’OSI du secteur, et est déjà en usage en production au sein d’Ant Group.
- Le graphe de contexte au milieu : métriques, objets, événements, filières et consommateurs connectés en réseau, sur lesquels un LLM peut raisonner de manière nettement plus efficace que avec des schémas bruts ou du YAML.
- La couche d’ontologie en haut : sémantique métier alignée sur la sémantique de la base de données, avec des termes propres à l’espace de travail et des concepts à l’échelle de l’entreprise, reliés entre eux tout en évoluant selon leurs propres calendriers.
Le principe sous-jacent est celui des codes sémantiques. Définissez les sémantiques une seule fois, puis laissez les outils de BI créer des tableaux de bord, les agents écrire du SQL et les outils de gouvernance tracer l’arborescence, tous en se basant sur cette même définition, sans sémantiques distinctes pour le BI, l’IA et la gouvernance. Lors des essais clients de ce fournisseur, la précision de la conversion du langage naturel en données était nettement supérieure à celle des alternatives. Selon eux, ce ne sont pas les modèles qui distinguent les produits, car tout le monde qualifie les mêmes systèmes de LLM ; c’est plutôt la qualité du contexte sémantique qui compte. Fournir des définitions commerciales correctes à la place de tables brutes améliore davantage la précision de la conversion NL en SQL que le simple ajustement des prompts.
Où commencer
Commencez par la couche sémantique dans les cas suivants :
- Les équipes ne s’accordent pas sur la signification de « revenus » ou d’« utilisateurs actifs ».
- Le projet concerne l’analyse conversationnelle ou les interactions par chat avec des données.
Commencez par l’ontologie dans les cas suivants :
- L’organisation opère dans le secteur financier, de la santé ou gouvernemental, avec des exigences strictes en matière de conformité.
- L’IA doit raisonner à travers différents domaines, tels que le client, le produit ou la réglementation.
- Un même concept porte des noms différents dans une demi-douzaine de systèmes.
- Une classification automatisée ou une détection d’anomalies basée sur des règles est nécessaire.
Pour la plupart des entreprises, l’ordre pratique est le suivant :
- Construisez d’abord la couche sémantique, en centralisant les métriques clés afin que les outils BI et l’IA utilisent des définitions identiques.
- Restez modeste avec l’ontologie au début, en la concevant comme un glossaire métier plutôt que comme une implémentation complète OWL.
- Ajoutez des mécanismes de gouvernance : traçabilité, scores de qualité, responsabilités et certifications.
- Exposez tout cela aux agents via MCP, ce qui transforme la couche de contexte d’un simple diagramme en une véritable infrastructure.
dbt ne fournit pas d’ontologie, et une ontologie de type Palantir ne convient pas à toutes les équipes. Passer d’un glossaire à une ontologie formelle est bien plus réaliste que de tout mettre en place d’un coup.
Le propre plan stratégique du fournisseur montre ce même approche progressive. À court terme, la couche sémantique atteint chaque espace de travail, avec des métriques gérées centralisément et une terminologie recherchable. À moyen terme, des glossaires, des hiérarchies de catégories et des relations entre entités apparaissent d’abord sous forme de taxonomie, avant d’acquérir une cohérence entre systèmes et des capacités de raisonnement de base, en s’étendant domaine par domaine. La question à long terme est de savoir ce qui se passe lorsque des domaines ayant modélisé leurs sémantiques séparément doivent les fusionner, et comment maintenir l’évolution des définitions locales et globales.
Lectures complémentaires
- Pourquoi les agents IA ont besoin d’une couche de gouvernance, et non seulement de meilleurs prompts — Les prompts influencent un seul échange, pas un flux de travail. Comment une couche de gouvernance composée de règles, de contexte ciblé, de limites d’autorité et de preuve de finition rend les agents de codage fiables.
- Pourquoi le mémoire d’un agent de codage ne doit contenir que le delta, et comment le stocker — Le mémoire de l’agent ne devrait enregistrer que ce que le modèle ne pouvait pas deviner. Quatre tests pour chaque entrée, trois exigences pour le stockage, et pourquoi le markdown dans git convient.