Qu’est-ce que l’ontologie Fabric ?

L’ontologie (preview) est un item de Microsoft Fabric IQ qui décrit le vocabulaire métier d’une organisation (concepts, propriétés, relations, règles) et le relie aux données réelles, pour que les personnes, les applications et les agents d’IA utilisent le même langage. Dans la documentation Microsoft, elle joue le rôle de couche de contexte et de modélisation sémantique entre les données et les expériences qui les consomment.

Concrètement, elle permet de :

• définir des types d’entités (un client, un magasin, une vente) avec leurs propriétés ;
• décrire les relations entre ces entités (une vente est réalisée dans un magasin) ;
• relier ces définitions aux données par des liaisons de données (data bindings) vers un lakehouse, un eventhouse, un entrepôt ou un modèle sémantique ;
• porter des métriques (les mesures DAX d’un modèle sémantique) et des règles métier écrites en langage naturel ;
• organiser le tout avec des espaces de noms, de l’héritage et des versions nommées ;
• servir de contexte à des agents, dont l’agent de données Fabric.

Deux expériences coexistent

Pendant mes tests, j’ai croisé deux versions de l’ontologie. Le tableau résume ce que j’ai observé et ce que la documentation indique.

Tableau :

La nouvelle version m’a paru nettement meilleure que l’ancienne. Microsoft indique qu’on ne peut plus créer d’ontologie de l’ancienne expérience depuis l’interface, et propose une action de copie vers la nouvelle expérience pour les ontologies existantes (agents, tableaux de bord et règles sont à reconnecter ou recréer ensuite).

Prérequis à anticiper

• Réglages du tenant. Un administrateur Fabric doit activer les réglages liés à l’ontologie et, pour les agents, le type d’item « Data agent » (preview). Les réglages Azure OpenAI autorisent un traitement des données hors de la région de la capacité : à valider avec la DSI avant activation.
• Un modèle sémantique propre, si l’on génère l’ontologie depuis un modèle : publié, hors de « Mon espace de travail », avec des tables visibles et des relations définies.
• Des types compatibles. D’après la documentation, Graph ne gère pas encore le type Decimal (les propriétés reviennent à null, il faut passer en Double), et les noms de propriétés identiques entre entités doivent avoir le même type.

Ces éléments viennent de la documentation Microsoft Learn à la date où j’écris (15 octobre 2026) : la fonctionnalité reste en préversion et ces points sont à re-vérifier avant toute décision.

De la préparation à l’utilisation : les limites rencontrées

Je suis parti d’un espace de travail Fabric et du jeu de démonstration Contoso (un distributeur fictif d’électronique), chargé dans un lakehouse (img 3) : 27 tables Delta, dont 18 dimensions et 9 tables de faits, avec des ventes de 2007 à 2009, toutes en dollars. Le point de départ était un modèle sémantique Direct Lake (img 4), sans relations initialement, et un second modèle en import (img 5). Le travail en amont a été bien plus long que la création de l’ontologie elle-même.

Préparer le modèle sémantique

• Des relations à reconstruire. Le modèle ne contenait pas de relations. J’ai dû créer les 46 relations, en les déduisant des colonnes de clés communes (*Key).
• Deux relations rendues inactives. Power BI refuse les chemins de filtre ambigus. J’ai désactivé dimcustomer → dimgeography (sinon la géographie filtrerait les ventes en ligne à la fois par le client et par le magasin) et dimmachine → dimstore (un incident est déjà relié au magasin et à la machine). Cette désactivation aura des conséquences plus tard, sur une question de test.

• Des marques en double à cause d’un espace. « Contoso » et « Contoso␣ » (avec un espace final) existent séparément, idem pour Litware et Fabrikam, et deux marques valent « 1 » et « 18 ». 61 produits n’ont pas de sous-catégorie, et le nom d’une catégorie finit lui aussi par un espace (« Cameras and camcorders␣ »). Ces défauts m’ont servi plus tard : ils permettent de mesurer comment chaque agent réagit à des données sales.

Direct Lake ou import : un chantier à part

• Un passage de Direct Lake à l’import. Les tables du deuxième modèle étaient en Direct Lake, car elles proviennent du lakehouse. Je les ai passées en import.
• Une actualisation qui échouait. Pour récupérer les données, j’ai dû actualiser le modèle en import. Il utilisait la connexion par défaut, sans identifiants explicites : j’ai dû configurer une connexion cloud dans l’interface Fabric.
• Des tables de dates automatiques parasites. Power BI Desktop a ajouté 10 tables de dates automatiques (LocalDateTable_*), inutiles et gênantes pour une ontologie. D’où l’importance de désactiver la date/heure automatique dans Power BI Desktop et de créer une table calendrier séparée.
• Une comparaison à structure identique. J’ai ensuite aligné le modèle Direct Lake sur les mêmes 16 tables et les mêmes 19 relations (dont 2 inactives), puis vérifié que les requêtes de contrôle renvoyaient les mêmes résultats. C’est ce qui permet de parler d’une comparaison « ISO ».

Créer l’ontologie

• Une création manuelle longue et peu intuitive (img 6). Il faut ajouter chaque entité, avec ses propriétés et sa liaison vers une table source, puis chaque relation. Pour 16 entités et 19 relations, c’est un vrai chantier. La logique est aussi différente de celle de Power BI : une relation Power BI relie simplement deux colonnes, alors qu’une relation d’ontologie se lit comme une phrase entre deux entités (« une vente a lieu dans un magasin »), avec un nom qui doit être unique dans toute l’ontologie.

  Pour chacune, il faut identifier la table qui porte le lien et les colonnes qui correspondent aux clés des deux entités. La documentation rappelle d’ailleurs que les entités de départ et d’arrivée doivent avoir une clé définie pour que la relation puisse être liée aux données. Tout cela se fait un élément à la fois.

• Trois ontologies construites. J’en ai créé une sur le modèle Direct Lake, une sur le modèle en import, et une troisième branchée directement sur les tables du lakehouse pour tenter d’obtenir le graphe. Fabric crée automatiquement, pour chaque ontologie, un graphe (vide tant qu’on ne le matérialise pas).
• Un graphe inaccessible depuis un modèle sémantique (img 7). Pour les ontologies construites sur un modèle sémantique, les entités sont déclarées « non éligibles » à la création du graphe, avec ce message : « Ce entité utilise une source de données qui n’est pas prise en charge. » Déclarer une clé sur chaque entité n’a rien changé.
• Une ontologie figée. J’ai supprimé une relation du modèle Direct Lake et ajouté 11 mesures dans les deux modèles. Résultat : l’ontologie construite sur le modèle Direct Lake déclare toujours la relation que j’avais supprimée, et aucune des 11 mesures n’apparaît dans les ontologies. Une ontologie ne se met donc pas à jour quand le modèle change : elle garde l’état du modèle au moment de sa création. La documentation indique pourtant que les mesures DAX d’un modèle sémantique sont reprises dans l’ontologie sous forme de métriques.
• Le nommage, une décision de modélisation. J’ai renommé les entités avec des noms métier (factsales en « VenteEnMagasin », factonlinesales en « VenteEnLigne », dimcustomer en « Client », dimstore en « Magasin », dimgeography en « ZoneGeographique »). Les noms de relations doivent être uniques, d’où les suffixes « en ligne » et « en magasin ». Seul le nom affiché change : chaque entité reste branchée sur sa table. Je reconnais une erreur : factsales contient les quatre canaux (magasin, en ligne, catalogue, revendeur), donc « VenteMultiCanal » aurait été plus juste. Ce mauvais nom a probablement induit une erreur d’agent.

Les contrôles DAX faits avant de créer les relations ont permis de repérer ces défauts avant de construire l’ontologie dessus.

Les tests : protocole et résultats

J’ai comparé quatre agents de données sur le même jeu de questions, formulées comme le ferait un utilisateur métier, pièges compris. Sur 24 réponses (6 questions × 4 agents), aucune n’a comporté d’erreur de calcul pur : les erreurs viennent de l’interprétation, du périmètre ou du modèle.

Les quatre agents

Le score des quatre agents

J’ai noté chaque réponse : 1 point si elle est exacte et son périmètre clair, 0,5 si elle est partiellement juste, 0 si elle est fausse, avec un léger retrait pour une coquille ou un choix non signalé. Cette notation est la mienne, sur une seule tentative par agent et six questions : elle donne un ordre de grandeur, pas une mesure statistique.

• Agent Modèle Import : le plus fiable. Aucune erreur franche, le plus transparent, cohérent d’une question à l’autre, et le seul à s’arrêter quand il ne comprend pas.
• Agent Modèle Direct Lake : fiable sur les questions précises. Ses chiffres sont exacts aux questions 1, 3, 4 et 5, avec un périmètre explicite à la question 1 (tous produits, tous canaux, toutes promotions).
• Agent Ontologie Direct Lake : le plus complet, et le plus risqué. Ses réponses sont les plus riches (questions 4 et 6), mais il commet les deux erreurs les plus graves (questions 2 et 3) sans rien remarquer. Soigné, donc crédible, même quand c’est faux.
• Agent Ontologie Import : le moins performant. Seule erreur sur une question simple, contradiction entre sa réponse à la question 1 et celle à la question 4, périmètres implicites.

Ce qui a très bien fonctionné

• Les calculs. Aucune erreur de calcul pur en 24 réponses.
• Les questions précises. Plus la question est précise, plus la réponse est fiable : les questions 4 et 5 sont réussies par les quatre agents.
• Les consignes métier. Les règles écrites dans les instructions sont bien suivies : le double comptage du canal en ligne, les données manquantes signalées (une partie des lignes en ligne sans produit référencé), la définition d’une commande.
• L’exhaustivité quand elle est bien menée (img 8). À la question 6, l’agent Ontologie Direct Lake couvre 100 % du chiffre d’affaires dans les deux groupes (avec et sans enfants) et annonce la période et la règle de calcul.
• La trace de l’agent (img 9). Elle permet de comprendre une réponse fausse en une minute (voir plus bas).

(8) Ici l’agent donne la totalité du CA et explique son calcul (à noter que les autres agents sont capables de faire la même chose)

(9) L’Agent Ontologie DL n’est pas capable de répondre à la question. Cependant, il nous donne les raisons de cet échec.

Ce qui a moins bien fonctionné

L’ontologie n’a pas amélioré les réponses des agents par rapport à un agent branché directement sur le modèle sémantique : le meilleur score, 5,4 sur 6, revient à un agent sans ontologie. Voici ce qui explique ce résultat.

• Un vocabulaire métier qui n’est pas relié aux valeurs. Je pose la question en français (« clients qui ont une licence »), les données sont en anglais (« Bachelors »), et aucun agent ne fait le lien. L’ontologie contient des noms, pas la liste des valeurs possibles ni un glossaire : l’agent ne sait pas que « licence » est un niveau d’études.
• Un nom d’entité mal choisi. Appeler « VenteEnMagasin » une table qui contient les quatre canaux (magasin, en ligne, catalogue, revendeur) est trompeur. Nommer, c’est déjà modéliser : ce nom a probablement favorisé le filtre « magasin » caché de l’agent Ontologie Import, même si l’agent Ontologie Direct Lake, avec les mêmes noms, ne l’a pas fait.
• Aucun contrôle de cohérence. Quand huit catégories affichent exactement le même chiffre d’affaires, un analyste s’arrête. À ma première tentative, l’agent Modèle Direct Lake a écrit lui-même que le total égale chaque catégorie et en a conclu une égalité. L’ontologie ne compense pas : un modèle cassé donne une réponse cassée, avec ou sans elle.
• De la variabilité. Avec la même ontologie et les mêmes instructions, les agents ne font pas les mêmes choix (questions 1 et 3). Le contexte de la conversation influence aussi la réponse : à la question 6, un agent a repris la logique « par commande » de la question 5.
• Des mesures ignorées. J’ai défini 11 mesures avec leurs descriptions, aucune n’a été utilisée en 24 réponses : les agents recalculent à partir des colonnes. Je n’avais pas écrit de consigne pour les imposer, mais c’est un constat important quand on investit dans des mesures.

• Des défauts de forme. À la question 4 (évolution des ventes par canal entre 2008 et 2009), les agents donnent le chiffre d’affaires de chaque canal pour les deux années, puis l’écart. Pour le canal catalogue (345 528 219,49 USD en 2008, 314 303 239,23 USD en 2009), l’écart attendu est d’environ −31 224 980 USD, soit −9,0 %.

  Deux agents, l’agent Ontologie Import et l’agent Modèle Direct Lake, l’affichent sous une forme tronquée et illisible, du type « −31 225 − », alors que les autres canaux sont lisibles. Le même défaut chez deux agents distincts laisse penser à un problème de génération du texte sur ce nombre précis. Par ailleurs, l’agent Ontologie Import donne des écarts en valeur, sans pourcentages, alors que la question portait sur l’évolution.

• Un graphe inexploitable et une ontologie figée. Aucune entité bâtie sur un modèle sémantique n’a été éligible au graphe, et l’ontologie n’a pas suivi les modifications du modèle (relation supprimée toujours déclarée, mesures absentes). La documentation actuelle présente le graphe comme facultatif : je ne l’ai donc pas utilisé pour répondre aux questions. Une ontologie construite à partir d’un lakehouse, en revanche, permet de créer le graphe : il n’accepte que des tables Delta du lakehouse (10).
• Un évaluateur qui a lui aussi besoin de définitions. Mon propre corrigé de la question 3 était contestable : tous points de vente, ou magasins physiques seulement ? Les agents ont donné les deux lectures. Sans définition écrite de ce qu’est un magasin, il n’existe pas de bonne réponse unique.
• Une portée de test limitée. Six questions posées, une tentative par agent, un seul domaine (un schéma en étoile de démonstration), des données sales volontairement conservées. Les résultats montrent des tendances, pas des taux de réussite.
• Une hiérarchie hors d’atteinte de l’ontologie. Comme Power BI refuse les relations d’une table vers elle-même, une ontologie générée depuis un modèle sémantique ne peut pas contenir la hiérarchie des employés. C’est pourtant le cas où l’ontologie devrait briller, et elle n’a rien apporté : le résultat dépend uniquement de l’habileté de chaque agent. C’est une limite structurelle de la génération depuis un modèle sémantique.
• Une absence de résultat transformée en fait. À la question sur la hiérarchie, l’agent Modèle Direct Lake répond qu’aucun magasin n’est sous la responsabilité de David Probst, alors qu’il y en a 52. Dire « je n’ai pas trouvé » n’est pas la même chose que dire « il n’y en a pas » : un utilisateur prendra la deuxième réponse pour un fait.

Ce qui m’a le plus surpris

La surprise principale vient de la trace que l’agent affiche à chaque réponse (« Analyse de <modèle> SemanticModel pour : <question réécrite> »). Elle montre ce que l’agent a réellement fait, et elle change la compréhension du rôle de l’ontologie. Voici les traces de deux agents pour la question 3 (« Qui sont nos 3 meilleurs responsables de magasin en 2009, et dans quels pays ? »). D’abord celle de l’agent Modèle Import, sans ontologie :

Analyse de Ontologie Import SemanticModel pour : « Pour l’année civile 2009, trouve les 3 meilleurs responsables de magasin, définis comme les 3 employés dont les magasins réalisent le plus grand chiffre d’affaires en magasin. Utilise VenteEnMagasin (factsales) reliée à dimstore par magasin_de_la_vente, puis à dimemployee par magasin_gere_par (responsable du magasin), et à dimgeography par magasin_situe_dans pour le pays (RegionCountryName). Agrège le chiffre d’affaires (somme de SalesAmount) par responsable de magasin (Employe) et pays, filtre sur CalendarYear = 2009 via la relation date_de_la_vente_en_magasin vers dimdate, puis retourne les 3 responsables avec leur nom, leur pays et le chiffre d’affaires 2009, triés du plus élevé au plus faible. »

Puis celle de l’agent Ontologie Import :

Analyse de Ontologie Import SemanticModel pour : « Identifie les 3 meilleurs responsables de magasin en 2009 sur les VentesEnMagasin, en te basant sur le chiffre d’affaires total (somme de SalesAmount) généré par les magasins qu’ils gèrent. Utilise la relation magasin_de_la_vente vers Magasin puis magasin_gere_par vers Employe pour obtenir le responsable, et magasin_situe_dans vers ZoneGeographique pour obtenir le pays (ZoneGeographique.RegionCountryName). Filtre sur l’année civile 2009 (Date.CalendarYear = 2009). Retourne pour chaque responsable dans le top 3 : son nom (Employe.FirstName, Employe.LastName) et le pays de son magasin (ZoneGeographique.RegionCountryName), avec le chiffre d’affaires total correspondant, classé du plus élevé au plus faible. »

Dans les deux cas, la trace affiche « Ontologie Import SemanticModel » : c’est le nom du modèle sémantique interrogé, qui s’appelle ainsi même pour l’agent sans ontologie. Quatre enseignements en découlent :

1. L’agent branché sur une ontologie n’interroge ni l’ontologie ni le graphe : il interroge le modèle sémantique. La trace indique « SemanticModel », et c’est le même modèle que celui de l’agent sans ontologie.
2. Il travaille en deux temps. Un orchestrateur réécrit ma question en détaillant le chemin à suivre (vente, magasin, employé, zone géographique, par les relations magasin_de_la_vente, magasin_gere_par et magasin_situe_dans), l’année et le regroupement. Un outil génère ensuite la requête sur le modèle.
3. L’agent sans ontologie obtient presque la même réécriture. Les deux réécritures nomment les mêmes relations et le même filtre sur l’année. Pour l’agent sans ontologie, ce vocabulaire venait des instructions que je lui avais données. L’ontologie sert donc de dictionnaire pour reformuler la question : ses relations ne servent pas au calcul, la jointure entre les tables dépend du modèle sémantique.
4. La réécriture ne dit pas tout, et c’est là que les agents divergent. Aucune des deux ne précise le canal de vente : l’une parle de chiffre d’affaires « en magasin », l’autre de chiffre d’affaires « total ». Pourtant le résultat est l’inverse de ce qu’on attendrait : l’agent qui écrit « en magasin » additionne tous les canaux (Nuria Gonzalez, 543,4 M), celui qui écrit « total » ne garde que les magasins physiques (Daniel Goldschmidt, 27,5 M). La différence apparaît dans la requête générée, que la trace n’affiche pas, et ni l’un ni l’autre ne signale son choix.

Il comprend sans qu’on soit précis. À la question « C’est quoi le panier moyen d’une commande en ligne en 2009 ? », les quatre agents ont compris qu’une commande se définit par un numéro de commande distinct, qu’il fallait agréger le chiffre d’affaires par commande puis faire la moyenne, et ont trouvé 2 268,70 USD. À la question sur les clients avec enfants, l’agent Ontologie Import traite explicitement le cas « zéro enfant ou non renseigné » pour ne pas perdre de clients.

Il propose des améliorations non demandées. Pour l’évolution des ventes par canal, l’agent Ontologie Direct Lake ajoute les ventes en ligne de la table dédiée avec un avertissement de ne pas les additionner au canal en ligne de la table magasin (risque de double comptage). À la question 2, l’agent Modèle Import propose de lui-même le classement des catégories sans le filtre qu’il ne sait pas traduire, et l’agent Ontologie Direct Lake signale que certaines lignes en ligne n’ont pas de produit référencé.

Il challenge, y compris son propre travail, mais pas assez. L’agent Modèle Import précise qu’il n’a pas additionné les ventes en ligne séparément pour éviter un double comptage : il applique et explique une règle que je lui avais donnée. En revanche, à ma première tentative, l’agent Modèle Direct Lake a remarqué que le total est égal à chaque catégorie et en a tiré une égalité au lieu de douter de son résultat. L’esprit critique est donc inégal : il ne va pas jusqu’à vérifier la cohérence d’un résultat.

Il dit quand la demande n’a pas de sens, avec des réactions très différentes. Pour « licence », trois agents signalent que la notion n’existe pas dans leurs données, mais répondent quand même à une autre question (tous les clients). Le seul à s’arrêter est l’agent Modèle Import : il explique qu’il ne peut pas répondre précisément et propose une alternative. C’est le comportement que j’attendais d’un assistant de données.

La contrepartie. Plus une réponse est soignée, plus elle inspire confiance, y compris quand elle est fausse : l’agent Ontologie Direct Lake donne les réponses les plus riches et les deux erreurs les plus graves, présentées avec le même aplomb. Il faut donc relire les chiffres, vérifier le périmètre annoncé et ne jamais prendre l’explication de l’agent pour une preuve du calcul. Et l’agent décide seul de ce qui est « nécessaire » : filtrer, exclure une année, changer de mesure.

Il sait dépasser la structure déclarée. À la question sur la hiérarchie, deux agents ont suivi un lien qui n’existe ni dans le modèle ni dans l’ontologie, en repérant seuls la colonne ParentEmployeeKey. Sur une question structurelle et explicite, ils se débrouillent bien.

Quatre agents, quatre raisonnements. Pour la même question, alors que deux paires partagent la même source et que tous ont les mêmes instructions, la variabilité porte sur la méthode elle-même, pas seulement sur l’interprétation.

Il ne voit un problème de données que quand sa requête plante. Ici, une boucle dans les données fait échouer la requête de l’agent Ontologie Direct Lake : il s’arrête et explique. À la question 2, lors de ma première tentative, la requête s’exécutait et renvoyait huit catégories au même montant : les agents Direct Lake les ont présentées comme normales. La vigilance de l’agent dépend de la manière dont l’erreur se manifeste, pas de sa gravité.

Trois types d’échec, aux risques très différents. Un résultat absurde présenté comme normal (question 2, première tentative) est dangereux. Un refus justifié (l’agent Ontologie Direct Lake sur la hiérarchie) est sans danger. Une absence de résultat transformée en fait (« aucun magasin », agent Modèle Direct Lake) est dangereuse.

Limites et points de vigilance

• ⚠️ Maturité. L’ontologie reste en préversion d’après la documentation Microsoft à la date où j’écris, avec des problèmes connus publiés sur le site Microsoft Fabric known issues. L’ancienne expérience sera retirée le 31 janvier 2027 : toute ontologie créée avec elle est à copier vers la nouvelle expérience, avec des agents et tableaux de bord à reconnecter. Prévoir de reconstruire plutôt que de supposer que tout sera conservé.
• ⚠️ Une source de vérité et du contrôle de version. J’ai constaté qu’une republication depuis Power BI Desktop écrase les modifications faites ailleurs, qu’une relation peut disparaître sans alerte, et que l’ontologie ne suit pas les changements du modèle. La documentation décrit des versions nommées créées à la main, mais je n’ai pas testé Git ni les pipelines de déploiement. Les instructions des agents sont à maintenir aussi : j’y avais figé des règles et des chiffres qui deviendront faux.
• ⚠️ Sécurité non testée. La documentation indique que l’ontologie respecte les droits sur les données liées, notamment la sécurité OneLake et la sécurité par ligne, par objet et par colonne appliquée à la source. Je ne l’ai pas vérifié : ni la sécurité par ligne dans l’ontologie, ni celle dans l’agent. Un agent qui répond à des utilisateurs métier doit être validé sur ce point avant tout déploiement.
• ⚠️ Coût et capacité non mesurés. Chaque ontologie crée un graphe, un eventhouse et une base KQL. Plusieurs éléments de l’ontologie, comme le graphe et son actualisation, peuvent consommer de la capacité et donc avoir un impact sur le coût. Je n’ai pas mesuré cet impact : c’est un point à surveiller avant de généraliser.
• ⚠️ Confidentialité des données. Les fonctionnalités d’IA reposent sur Azure OpenAI, et les réglages de tenant associés autorisent un traitement des données hors de la région de la capacité. Selon la sensibilité des données, c’est à valider avec la DSI et le DPO avant activation.
• ⚠️ Une relecture indispensable. Une réponse d’agent n’est ni une preuve ni un contrôle. Il faut écrire les définitions métier (qu’est-ce qu’un magasin, un client actif, une vente ?) avant l’ontologie, valider les réponses sur un jeu de questions de référence rejoué à chaque changement, et surveiller la dérive du modèle sémantique.

Conclusion

L’ontologie Fabric est une bonne idée dans un produit encore jeune. Sur mon cas (un seul modèle en étoile, des données de démonstration), elle n’a pas amélioré les réponses des agents par rapport à un agent branché directement sur le modèle sémantique, et elle a ajouté une étape de réécriture qui peut introduire des erreurs. Ce que j’en retiens : elle ne remplace pas un bon modèle sémantique, elle s’appuie dessus, et la qualité de ce modèle et des définitions métier conditionne tout le reste.

Cette conclusion vaut pour le cas que j’ai testé : une ontologie construite sur un seul modèle sémantique. La valeur de l’ontologie se situe probablement ailleurs, sur des points que je n’ai pas testés :

• relier plusieurs sources (CRM, facturation, support, temps réel) sous un même vocabulaire, ce qui est la promesse centrale de Microsoft ;
• utiliser le graphe pour les hiérarchies, les parcours et l’analyse d’impact, là où le DAX est moins adapté, en sachant que dans mes tests il n’a pas fonctionné à partir d’un modèle sémantique ;
• servir de documentation et de gouvernance, grâce aux vues de traçabilité et d’ontologie complète ;
• porter les définitions métier une seule fois (règles, métriques) pour tous les usages, à condition de les écrire.

La promesse est séduisante, notamment pour les grandes organisations qui doivent partager un vocabulaire entre domaines, mais elle me paraît encore loin d’être mature. Sa mise en place me semble compliquée dans une grande entreprise : préparation des modèles, création manuelle de l’ontologie, absence de synchronisation avec les modèles, sans compter la sécurité, le coût et les versions, qui restent à valider. À ce stade, elle me paraît se prêter à des pilotes sur un domaine précis plutôt qu’à un socle d’entreprise. Le frein n’est pas seulement technique : il faut aussi se mettre d’accord sur les définitions et assurer la qualité des données.

Mes recommandations

1. Commencer par le modèle sémantique : relations, qualité des données, mesures, descriptions.
2. Écrire les définitions métier avant l’ontologie : ce qu’est un magasin, une vente, un client actif, avec un petit glossaire qui relie les mots des utilisateurs à ceux des données. Ces définitions peuvent être ajoutées dans le modèle sémantique (descriptions, synonymes), dans l’ontologie (règles métier, métadonnées) ou dans les instructions de l’agent.
3. Choisir les noms avec soin : nommer, c’est déjà modéliser.
4. Réserver l’ontologie aux cas où elle apporte quelque chose : relier plusieurs sources de données sous un même vocabulaire, suivre des liens sur plusieurs niveaux (par exemple retrouver le responsable d’un responsable), ou documenter ce que veut dire chaque terme et d’où viennent les données. Sur un seul modèle sémantique, je n’ai pas constaté de gain.
5. Encadrer les agents : imposer les mesures, annoncer chaque filtre, s’arrêter en cas de doute ou de résultat suspect.
6. Constituer un jeu de questions de référence et le rejouer à chaque changement du modèle, de l’ontologie ou des instructions.
7. Valider sécurité, coût et versions avant de généraliser, puis réévaluer dans 6 à 12 mois.

Et ensuite

Mon prochain test consiste à améliorer l’ontologie (renommer l’entité des ventes, ajouter un glossaire et une définition du magasin physique), puis à reposer les questions 1 à 3. Je reposerai aussi les mêmes questions plusieurs fois pour mesurer la variabilité, et j’en ajouterai de nouvelles. Restent à explorer : l’éligibilité au graphe de l’ontologie branchée sur le lakehouse, la sécurité par ligne, Git et les pipelines de déploiement, le coût et les temps de réponse.

Pour la hiérarchie, je veux aussi tester trois choses : une question sur le sommet de l’organigramme (« Qui est tout en haut de la hiérarchie au-dessus du responsable du magasin de Paris ? »), qui peut faire boucler ou échouer un agent ; la question « Qui est le responsable du magasin de Paris, et de qui dépend-il ? », pour voir comment les agents lisent « dépend de » (supérieur hiérarchique ou entité de rattachement) ; et la déclaration explicite de la hiérarchie dans l’ontologie (un employé qui reporte à un employé), pour mesurer ce qu’apporte une ontologie qui décrit vraiment cette hiérarchie.

Et vous : avez-vous testé une ontologie Fabric sur plusieurs sources, ou seulement sur un modèle sémantique ? Qu’avez-vous constaté sur la qualité des réponses de vos agents ? Je serais curieux de comparer.

L’outil n’est pas le facteur limitant : ce sont la qualité des données, la rigueur du modèle et la clarté des définitions métier.