Agents de données pilotés par des ontologies dans Microsoft Fabric IQ : Un guide pratique
Découvrez comment Microsoft Fabric IQ combine des modèles sémantiques, des ontologies et MCP pour faire passer les agents d’IA d’entreprise de la simple récupération de données à un raisonnement commercial contrôlé.
Sources: Microsoft Fabric IQ and Data Agents for Ontology based Consumption
En résumé : l’IA d’entreprise est en train de connaître un changement significatif. La première vague d’IA générative pour les entreprises était principalement axée sur la récupération des données. La prochaine vague d’agents d’entreprise ira au-delà du simple récupération de données — ils seront capables de raisonner en s’appuyant sur des significations commerciales contrôlées.
Question
↓
LLM
↓
Vector Search / RAG
↓
Documents
↓
Answer
Le modèle émergent se concentre sur la raisonnement basé sur les significations commerciales:
Business Question
│
▼
Agent / Planner
│
┌─────────┴─────────┐
▼ ▼
Semantic Model Ontology
"How measured?" "What does it mean?"
│ │
└─────────┬─────────┘
▼
Enterprise Data
│
▼
Insight / Decision
│
▼
Action
Cette différence est extrêmement importante.
Une base de données classique peut indiquer à un agent quelque chose comme :
customers.CustomerId = sales.CustomerId
En revanche, une ontologie peut indiquer à l’agent :
Customer ── PURCHASES ──> Product
Et un modèle sémantique peut aller encore plus loin en lui indiquant :
Total Revenue = governed enterprise measure
Ces éléments représentent trois niveaux de compréhension complètement différents.
Microsoft intègre ces idées au sein de Fabric IQ : le modèle sémantique fournit des mesures analytiques fiables, l’ontologie propose un vocabulaire et une structure de relations communs à toute l’entreprise, la couche graphique permet de naviguer dans les données connectées, et les Agents de données mettent en évidence toute cette intelligence via des conversations. Microsoft présente Fabric IQ comme une couche de contexte métier qui transforme les données analytiques et opérationnelles brutes en concepts commerciaux sur lesquels un agent peut réellement raisonner.
Le élément architectural qui rend cela vraiment intéressant est le suivant :
Il est possible de publier un Agent de données Fabric et de le rendre accessible via le Model Context Protocol (MCP), afin que les agents Microsoft Foundry — ou tout autre agent compatible MCP — puissent utiliser cette intelligence d’entreprise gérée comme n’importe quel autre outil.
Microsoft prend désormais en charge précisément ce flux : un Fabric Data Agent publié peut apparaître comme une outil MCP à un agent Foundry, et un seul agent Foundry peut alors coordonner plusieurs Fabric Data Agents en même temps que d’autres outils et sources de connaissances.
1. Pourquoi l’ontologie est soudainement à nouveau importante
L’ontologie n’est pas une idée nouvelle.
Les graphes de connaissances ne le sont pas non plus.
De même pour les modèles sémantiques.
Ce qui a vraiment changé, c’est ceux qui les utilisent.
Historiquement, la technologie sémantique d’entreprise était principalement utilisée par :
- les plateformes de recherche
- les outils BI
- les systèmes d’intégration de données
- la gestion des taxonomies
- les applications basées sur des graphes
- les experts du domaine
Aujourd’hui, un nouveau utilisateur fait son apparition :
Les agents IA.
Ces agents se heurtent cependant à un véritable obstacle.
Les grands modèles de langage raisonnent efficacement à partir des informations qui leur sont fournies, mais les bases de données d’entreprise ne décrivent presque jamais l’activité commerciale de la manière dont les gens y pensent naturellement.
Par exemple :
CUSTOMER_MASTER.CUST_ID
SALES_TXN.CUST_ID
SALES_TXN.PROD_NM
SALES_TXN.NET_REV
Cependant, une personne pense en termes tels que :
Customer
│
│ PURCHASES
▼
Product
│
└── generates → Revenue
C’est l’écart entre ces deux représentations qui est à l’origine d’une grande part de l’incertitude des agents.
Manquant de fondement sémantique, l’agent est contraint de deviner :
- quelles tables correspondent à quels concepts commerciaux
- quelles jointures sont réellement valides
- ce que représente réellement une colonne donnée
- quelle définition de métrique doit être considérée comme officielle
- comment les entités sont liées entre elles
- si deux champs ayant des noms différents signifient réellement la même chose
C’est un problème tolérable dans une démonstration à cinq tables.
Au vu des centaines de produits de données d’entreprise existants, cela devient véritablement risqué.
La fonctionnalité d’ontologie de Fabric a été conçue spécifiquement pour servir de vocabulaire commercial lisible par les machines et partageable, composé de types d’entités, propriétés, relations, contraintes et liens vers des données réelles de OneLake. Ce vocabulaire peut être utilisé à égalité par les utilisateurs humains et par des agents.
2. Mais « Graph de connaissances » ne signifie pas une architecture unique
Un flux de décision visuel accompagnant cette discussion aide à clarifier pourquoi choisir une approche basée sur des graphes et des ontologies n’est pas une solution universelle.
[Insérer : Flux de décision pour les solutions graphiques et ontologiques]
Il n’existe pas de manière unique et correcte pour concevoir un graphique.
Le paysage peut être approximativement divisé en cinq modèles.
Modèle 1 — RDF / Graph de connaissances sémantique
C’est l’approche traditionnelle du web sémantique :
Subject ─ Predicate ─> Object
Elle est généralement associée à :
RDF
RDFS
OWL
SPARQL
Avantages : une sémantique riche et expressive, une interopérabilité basée sur des normes, des méthodes éprouvées pour le modélisage des ontologies, ainsi que un soutien au raisonnement formel.
Inconvénients : une complexité de modélisation plus élevée, le besoin de compétences spécialisées, et une infrastructure qui dépasse souvent les besoins réels de l’application.
3. Graphes de propriétés étiquetés
Le modèle des graphes de propriétés étiquetés (LPG) adopte une approche plus axée sur l’application :
(Customer)
│
│ PURCHASED
│ {date, quantity}
▼
(Product)
Les nœuds et les arêtes peuvent tous deux comporter leurs propres propriétés.
Des outils comme Neo4j ont popularisé ce modèle car il convient naturellement aux applications nécessitant beaucoup de parcours.
Avantages : modélisation graphique intuitive, performances élevées pour les parcours, algorithmes graphiques éprouvés, ainsi qu’une solide expérience en développement d’applications.
Inconvénients : le schéma graphique en soi ne constitue pas un vocabulaire sémantique d’entreprise géré — cette couche de sens doit encore être modélisée et gérée séparément.
Microsoft Fabric Graph suit cette approche LPG, en associant les tables OneLake aux types de nœuds et d’arêtes, et en permettant les parcours via GQL. L’implémentation de GQL par Microsoft respecte le langage de requête graphique normalisé ISO.
4. Une approche plus légère : une ontologie associée à un graphique en mémoire
Tous les agents n’ont pas besoin d’une base de données graphique d’entreprise complète.
Pour les applications de type chat, les scénarios simples, des assistants à portée restreinte ou des projets de démonstration, vous pouvez représenter une ontologie simple sous forme de JSON pur :
{
"entities": {
"Customer": {},
"Product": {}
},
"relationships": {
"Purchases": {
"from": "Customer",
"to": "Product"
}
}
}
Votre couche d’application peut alors charger cette définition dans NetworkX, Memgraph, une bibliothèque RDF ou toute autre structure de graphe en mémoire.
Cette approche se met en place rapidement et est peu coûteuse à exploiter.
Cependant, la gouvernance, la sécurité, le suivi de l’historique des modifications, l’échelle, le synchronisation des données ainsi que la gestion partagée des définitions sémantiques deviennent des problèmes que vous devez résoudre vous-même.
5. Pourquoi Microsoft Fabric se distingue
Fabric aborde le problème sous un angle différent.
Au lieu de partir du principe que toutes les données d’entreprise doivent être migrées dans une base de données graphique, l’architecture peut partir du principe que les données d’entreprise restent là où elles se trouvent, dans OneLake, et que l’intelligence sémantique et relationnelle est ajoutée par-dessus.
Sous forme de diagramme :
Fabric IQ
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Semantic Model Ontology Graph
│ │ │
trusted metrics business meaning traversal
│ │ │
└─────────────────┼──────────────────┘
│
OneLake
Microsoft établit une distinction claire entre ces responsabilités : les modèles sémantiques fournissent des KPI fiables ainsi que des structures analytiques, l’ontologie propose un vocabulaire métier commun, le graphe gère la navigation à travers les données connectées, et les agents de données ou d’opérations assurent une interaction intelligente et des actions basées sur ce contexte.
Cette séparation des responsabilités est importante du point de vue architectural.
6. Le modèle sémantique, l’ontologie et le graphe sont trois choses distinctes
Ces termes sont souvent utilisés comme s’ils étaient des synonymes. Ce n’est pas le cas.
Une façon utile de les comprendre :
DATA
"What happened?"
│
▼
SEMANTIC MODEL
"How should it be measured?"
│
▼
ONTOLOGY
"What does it mean?"
│
▼
GRAPH
"How is everything connected?"
│
▼
AGENT
"What should I investigate or do?"
Total Revenue
Average Order Value
Customer Count
Revenue by Segment
Customer
Product
Customer ── PURCHASES ──> Product
Customer A
│
├── PURCHASES → Laptop
│
├── PURCHASES → Monitor
│
└── PURCHASES → Dock
L’agent de données expose ensuite toutes ces informations grâce à une interaction en langage naturel.
Fabric permet également d’obtenir une ontologie directement à partir d’un modèle sémantique existant : les tables deviennent des types d’entités, les colonnes deviennent des propriétés, et les relations déjà définies dans le modèle sémantique deviennent des relations ontologiques.
7. Construction : un produit de données commerciales minimal
Afin de concentrer l’attention sur l’architecture plutôt que sur l’ingénierie des données, l’exemple reste délibérément simple.
Seules deux tables sources sont utilisées :
NP_SalesDataProduct_LH
customers
──────────────
CustomerId
CustomerName
Segment
City
State
Country
sales
──────────────
OrderId
OrderDate
CustomerId
ProductName
ProductCategory
Quantity
UnitPrice
DiscountPct
Revenue
SalesChannel
La relation entre elles est simple :
customers.CustomerId
1
│
*
sales.CustomerId
Cela suffit pour présenter l’architecture dans son intégralité, sans que la complexité de la modélisation ne vienne entraver la leçon fondamentale.
8. Étape 1 — Créer le produit de données Fabric
Les deux fichiers CSV sont chargés dans un Fabric Lakehouse :
NP_SalesDataProduct_LH
│
├── Tables
│ └── dbo
│ ├── customers
│ └── sales
│
└── Files
├── customers.csv
└── sales.csv
[Insérer une capture d’écran : Lakehouse montrant les clients et les ventes]
À ce stade, vous disposez déjà d’un Fabric Data Agent fonctionnel.
Celui-ci peut répondre à des questions telles que le montant total des revenus, quelles catégories de produits génèrent le plus de revenus, et comment les revenus se répartissent par segment de clientèle.
Cependant, quelque chose d’important se passe en arrière-plan.
Puisqu’aucune sémantique supplémentaire n’a été définie, l’agent doit inférer lui-même la jointure :
customers.CustomerId
=
sales.CustomerId
et il doit également inférer que :
Revenue → SUM(Revenue)
Cela vous fournit une référence de base à comparer.
9. Étape 2 — Ajouter le modèle sémantique
Ensuite, vous introduisez le contrat analytique.
Customer
1
│
*
Sales
avec des mesures gérées telles que :
Total Revenue =
SUM(sales[Revenue])
et :
Total Orders =
DISTINCTCOUNT(sales[OrderId])
À ce stade, l’agent n’a plus besoin de deviner ce que signifie « Total Revenue ».
Cette définition appartient à la couche sémantique.
Cela souligne un principe important pour les agents d’entreprise :
Les agents devraient utiliser des métriques gérées plutôt que de reconstruire manuellement les calculs de l’entreprise à partir des colonnes brutes chaque fois qu’une question arrive.
10. Étape 3 — Ajouter l’ontologie
À partir de là, on passe des définitions analytiques au sens au niveau métier.
L’ontologie dans cet exercice définit simplement deux types d’entités :
Customer
Product
Le client correspond à :
customers.CustomerId
customers.CustomerName
customers.Segment
customers.City
customers.State
customers.Country
using :
KEY = CustomerId
Le produit, quant à lui, est dérivé directement de la table existante sales :
sales.ProductName
sales.ProductCategory
using :
KEY = ProductName
Encore une fois, il n’était pas nécessaire de créer une table physique distincte pour Produit afin que cela fonctionne.
11. Définir la relation métier
Ensuite, une relation est ajoutée :
Customer
│
│ PURCHASES
▼
Product
Le point intéressant ici concerne le fonctionnement du liage de données.
La table sales elle-même agit comme le pont pour cette relation :
Customer.CustomerId
↑
sales.CustomerId
sales.ProductName
↓
Product.ProductName
Ainsi, une ligne brute de ventes comme :
sales row:
CustomerId = C001
ProductName = Laptop Pro
devient :
Customer(C001)
│
│ PURCHASES
▼
Product(Laptop Pro)
C’est à ce moment-là qu’un enregistrement relationnel simple se transforme en quelque chose que l’entreprise reconnaît réellement comme du savoir.
Le modèle d’ontologie de Fabric a été conçu spécifiquement pour ce flux de travail : on définit d’abord les types d’entités et leurs relations, puis on lie ces définitions abstraites aux données concrètes stockées dans OneLake.
12. Quels changements pour l’agent ?
Prenez cette question :
Quels produits sont achetés par les clients Enterprise ?
Sans une ontologie en place, l’agent doit raisonner de la manière suivante :
Find customers table
↓
Find Segment
↓
Filter Enterprise
↓
Determine CustomerId join
↓
Join sales
↓
Find ProductName
Avec l’ontologie disponible, le raisonnement se résume à :
Customer
│
Segment = Enterprise
│
└── PURCHASES ──> Product
La question correspond presque directement au modèle lui-même.
Microsoft décrit ce changement comme un passage des agents qui pensent en termes de tables individuelles à des vues gérées construites à partir d’entités, de relations, de définitions, de règles et de mappages sources.
13. Étape 4 — Créer l’agent de données Fabric
L’agent de données est ce qui transforme tout cela en une interface en langage naturel :
User
│
▼
NP_Sales_DataAgent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Lakehouse Semantic Model Ontology
│ │ │
raw facts trusted KPIs relationships
│ │ │
└─────────────┼─────────────┘
▼
OneLake
Microsoft décrit les Fabric Data Agents comme une couche de réponse à des questions en langage naturel dédiée à un domaine de données précis, l’ontologie fournissant le contexte métier plus approfondi sur lequel ces agents s’appuient.
14. Ensuite vient le changement architectural important : MCP
Un Fabric Data Agent n’est pas obligé de rester confiné à Fabric.
Vous pouvez le publier.
Une fois publié, Fabric expose cet agent en tant que serveur de Model Context Protocol.
Conceptuellement, le flux se présente comme suit :
Fabric Data Agent
│
│ Publish
▼
MCP Server
│
├── tool description
├── input schema
└── governed execution
À ce stade, votre intelligence artificielle pour les données d’entreprise devient quelque chose de réutilisable — un outil agent que d’autres systèmes peuvent appeler.
15. Microsoft Foundry devient la couche d’orchestration
Cela ouvre la voie à une architecture considérablement plus intéressante.
USER
│
▼
Microsoft Foundry Agent
│
planning / orchestration
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
CRM Tool Search Tool Fabric MCP
│
▼
Fabric Data Agent
│
┌───────────────────┼───────────────┐
▼ ▼ ▼
Semantic Model Ontology Lakehouse
│ │ │
└───────────────────┼───────────────┘
▼
OneLake
La séparation des préoccupations est importante ici.
L’agent Foundry est responsable du raisonnement lié aux workflows.
L’agent Fabric Data est responsable du raisonnement lié aux données.
Dans sa forme actuelle, l’intégration Foundry de Microsoft permet à un agent Foundry de découvrir des agents Fabric Data publiés via Fabric IQ / OneLake Catalog et de les traiter comme des outils MCP. Un seul agent Foundry n’est pas non plus limité à un seul domaine : il peut récupérer et utiliser plusieurs agents Fabric Data en même temps.
16. Un exemple concret
Imaginons qu’un utilisateur soumette une demande à l’agent Foundry dans les termes suivants : identifier le segment de clients qui contribue à la plus grande part des revenus, déterminer quels produits sont responsables de la performance de ce segment, et transformer ces résultats en une recommandation que l’équipe commerciale peut mettre en œuvre.
C’est ainsi que l’exécution pourrait se dérouler :
USER
│
▼
Foundry Orchestrator
│
│ "I need enterprise sales intelligence."
│
▼
Fabric Data Agent MCP Tool
│
├── Semantic Model
│ → trusted revenue calculation
│
├── Ontology
│ → Customer → PURCHASES → Product
│
└── Lakehouse
→ transaction data
│
▼
Result:
Enterprise customers generate...
Laptop category contributes...
│
▼
Foundry Agent
│
├── reasoning
├── CRM lookup
├── recommendation generation
└── potentially action
│
▼
Sales recommendation
Ce qui est important ici, ce n’est pas que un modèle de langage ait produit une recommandation. Ce qui compte, c’est que cette recommandation soit basée sur une représentation métier structurée, et non improvisée à partir de tables brutes ou de sémantiques approximatives.
17. MCP change l’architecture des agents d’entreprise
Sans MCP, les équipes finissent généralement par configurer les choses de cette manière :
Agent A → custom Fabric integration
Agent B → another custom Fabric integrationAgent C → another SQL implementationAgent D → another Power BI integration
Au fil du temps, chaque agent accumule des connaissances profondes mais fragiles concernant la plateforme de données sous-jacente.
Avec MCP en place, la situation est différente :
Enterprise Agents
┌───────────┼───────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└───────────┼───────────┘
│
MCP Tool
│
▼
Fabric Data Agent
│
▼
Governed Data IQ
L’agent de données Fabric devient un produit d’intelligence des données conçu pour être consommé par les agents, plutôt qu’une intégration sur mesure que chaque équipe doit reconstruire. Il s’agit d’un changement apparemment mineur mais ayant une grande importance architecturale.
18. Une autre option : exposer l’ontologie directement
Il existe un deuxième scénario à prendre en considération.
Au lieu d’acheminer tout via un Fabric Data Agent, l’ontologie Fabric elle-même peut être exposée via MCP à n’importe quel agent externe compatible. Microsoft documente un serveur Ontology MCP qui inclut des outils pour découvrir les types d’entités de l’ontologie et exécuter des requêtes dessus.
Cela vous offre deux schémas distincts :
PATTERN A
External Agent
│
│ MCP
▼
Fabric Data Agent
│
▼
Ontology
contre :
PATTERN B
External Agent
│
│ MCP
▼
Fabric Ontology
Choisissez le premier schéma lorsque vous souhaitez utiliser la couche de raisonnement conversationnel et basée sur des agents de données propre à Fabric. Choisissez le second lorsque l’agent externe dispose déjà d’une logique de planification sophistiquée et a simplement besoin d’un accès plus direct au modèle sémantique de l’entreprise.
19. Avantages et inconvénients du schéma Fabric
Avantages
Sémantique centralisée. Les définitions métier se trouvent en un seul endroit géré, au lieu d’être copiées-collées dans chaque requête.
Bâti sur OneLake. Il n’y a pas d’exigence stricte de dupliquer l’ensemble de vos données dans une plateforme graphique distincte.
Trois couches qui fonctionnent ensemble. Les métriques analytiques et la sémantique au niveau des relations peuvent coexister dans le modèle sémantique, l’ontologie et le graphe.
Développé pour les agents. Les Fabric Data Agents ainsi que la couche d’ontologie ont été conçus expressément pour servir de sources de référence aux agents IA.
Ouvert via MCP. La couche d’intelligence ainsi créée peut être utilisée par Foundry ainsi que par des clients MCP personnalisés.
Séparation claire des responsabilités.
Fabric → data intelligence
Foundry → orchestration intelligence
Cette séparation crée une frontière particulièrement nette au niveau de l’entreprise.
20. Compromis
Quelques mises en garde importantes s’appliquent.
Une grande partie de cette technologie reste en version bêta. Le support des ontologies, plusieurs intégrations Fabric IQ et Foundry, ainsi que les fonctionnalités MCP associées restent des fonctionnalités de prévisualisation ; vous devez donc vérifier leurs conditions d’utilisation en version bêta fournies par Microsoft avant de les utiliser en production.
La gouvernance des ontologies est un travail continu et réel. Dès que plusieurs domaines commencent à définir leurs propres entités telles que Customer, Account, Product, Contract et similaires, quelqu’un doit s’occuper de la nomenclature, de la gestion des versions et de l’alignement entre les différents domaines.
L’ontologie ne peut pas corriger des données de mauvaise qualité. Même en enveloppant un ensemble de données de faible qualité dans des sématiques métier élégantes, on obtient toujours des réponses de même qualité.
L’ontologie n’est pas toujours nécessaire. Pour une agrégation simple de KPI, interroger directement le modèle sémantique peut être plus simple et suffisant.
Tous les cas d’usage graphiques ne conviennent pas ici. Les algorithmes graphiques complexes, le raisonnement spécialisé de type RDF ou les charges de travail graphiques hautement personnalisées peuvent nécessiter une plateforme graphique dédiée.
C’est précisément pourquoi un cadre de décision en étapes est utile.
21. Le plan d’action que j’utiliserais
Au lieu de se lancer directement dans un projet d’ontologie à l’échelle de l’entreprise, il est judicieux de procéder par étapes.
Phase 1 — Produits de données
Sources
↓
OneLake
↓
Domain Data Products
Le but ici est d’établir des données de domaine fiables et clairement gérées.
Phase 2 — Sémantique analytique
Data Product
↓
Semantic Model
↓
Measures / KPIs / Dimensions
Cette phase définit la manière dont l’organisation mesure les choses.
Phase 3 — Sémantique métier
Semantic Models + Data Products
↓
Ontology
↓
Entities / Relationships / Rules
Cette phase définit ce que signifient réellement les éléments mesurés.
Phase 4 — Intelligence connectée
Ontology
↓
Graph
↓
Traversal / dependency / impact analysis
À ce stade, on utilise des structures graphiques uniquement là où l’analyse des relations est véritablement utile.
Phase 5 — Agents de données métier
Ontology + Semantic Model + Data
↓
Data Agent
Ici, on transforme ces connaissances métier accumulées en quelque chose de conversationnel.
Phase 6 — MCP
Data Agent
↓
Publish
↓
MCP
Cette étape transforme le produit conversationnel en une capacité que d’autres agents peuvent utiliser.
Phase 7 — Orchestration des agents d’entreprise
Foundry Agent
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Sales Data Agent Supply Agent Finance Agent
│ │ │
└──────────────────┼──────────────────┘
│
Fabric IQ
Microsoft est déjà en train de se diriger dans cette voie : les agents Foundry peuvent récupérer des données auprès de plusieurs agents Fabric Data Agents publiés via Fabric IQ, chacun de ces agents étant exposé en tant qu’outil MCP.
Où cela mène-t-il ?
Le changement architectural global se présente comme suit :
GENERATION 1
LLM + RAG
│
Documents
en évoluant vers :
GENERATION 2
LLM + Tools + Data
│
SQL / APIs / RAG
et finalement vers :
GENERATION 3
Agent Systems
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Documents Tools Enterprise IQ
│
┌──────────┼──────────┐
▼ ▼ ▼
Semantics Ontology Graph
│ │ │
└──────────┼──────────┘
▼
Enterprise Data
Le facteur déterminant dans ce domaine cessera progressivement d’être la question de savoir quel modèle est le plus performant.
Cela dépendra plutôt de l’organisation qui aura développé la couche de contexte d’entreprise la plus riche, permettant à ces modèles d’y puiser des informations.
Microsoft définit sa direction globale sous le nom de Microsoft IQ, où Fabric IQ fournit des informations sur les entités commerciales et les données, en collaboration avec Work IQ, Foundry IQ et Web IQ.
Cette approche tient la route.
Il doit comprendre :
Quelles sont les choses.
Comment elles se rapportent les unes aux autres.
Comment l’organisation les mesure réellement.
Quelles définitions ont autorité.
Quel est l’état actuel de ces choses.
Et, en fin de compte :
Quelles actions sont pertinentes compte tenu de tout cela.
Conclusion : De RAG au raisonnement d’entreprise
RAG a donné à l’intelligence artificielle d’entreprise un moyen d’accéder aux connaissances.
L’utilisation d’outils a donné aux agents un moyen d’accéder aux systèmes.
L’ontologie leur offre quelque chose de complètement différent :
le sens.
Lorsque ce sens est associé à des métriques contrôlées, des relations graphiques, des données opérationnelles en temps réel et une orchestration d’agents, on obtient une architecture nettement plus convaincante :
DATA
│
▼
SEMANTICS
│
▼
ONTOLOGY
│
▼
CONNECTED INTELLIGENCE
│
▼
DATA AGENTS
│
▼
MCP
│
▼
ENTERPRISE AGENTS
│
▼
DECISIONS
│
▼
ACTIONS
C’est là, en fin de compte, la véritable valeur ajoutée des analyses agnitives basées sur des ontologies.
Ce n’est pas simplement un autre chatbot ajouté à une base de données.
C’est une architecture d’intelligence d’entreprise dans laquelle les produits de données fournissent les faits, les modèles sémantiques des mesures fiables, les ontologies le sens, les graphes les relations, les agents de domaine l’intelligence, et MCP permet de composer toute cette intelligence au sein d’un écosystème d’agents plus vaste.
Cette combinaison rend la prochaine génération d’IA d’entreprise bien plus intéressante à développer.