Les agents ont besoin d’une signification interprétable : couches sémantiques, ontologies et métriques régulées.

Imaginez la réunion du lundi. Un collègue colle la réponse de l’agent dans Slack : le chiffre d’affaires par client pour le trimestre précédent, présenté de manière ordonnée, expliqué brièvement, avec une assurance totale. Un simple regard de la part du service financier suffit pour bloquer toute discussion. Ce chiffre correspond aux réservations, tandis que le chiffre d’affaires reconnu est stocké dans une autre donnée, avec une structure différente et sa propre liste d’exclusions. Il n’y avait rien de mal dans le SQL. Personne n’avait clarifié ce que signifiait la question.

Après avoir vu suffisamment de scénarios de ce type, l’affirmation « le modèle a généré du SQL valide » cesse d’être considérée comme un succès. Les grands modèles de langage ont rendu presque tous les documents des entrepôts lisible par des machines. Être lisible est peu coûteux. Être interprétable, en revanche, est ce qui manque : savoir quel client, quel chiffre d’affaires, quel statut d’activité, quel taux de désabonnement et quel chiffre du trimestre précédent ont une signification précise dans cette entreprise, pour cette décision en particulier.

Auparavant, une personne s’occupait de l’interprétation avant d’écrire toute requête. En déléguant cette tâche à un agent en temps de exécution, celui-ci improvisera une histoire plausible, à moins qu’une histoire prédéfinie ne lui soit fournie. La solution définitive consiste à gérer le sens au niveau de l’entreprise comme un produit : lui donner une identité, en gérer les versions, le tester, le relier aux données physiques, et permettre aux humains et au logiciel de l’utiliser de manière identique.

Pour la plupart des équipes, l’étape clé est l’implémentation d’une couche sémantique ou de métriques bien structurée. L’objectif à long terme est un modèle basé sur une ontologie qui compile les projections ultérieures, qu’il s’agisse de LookML, de vues SQL, de contrats API ou d’outils d’agents, afin que aucun produit n’ait à inventer sa propre vérité privée.

Pourquoi une réponse fiable représente un risque

La BI basée sur les chatbots est souvent décrite comme une transformation du langage naturel en SQL, une étiquette qui cache la partie la plus difficile. La partie difficile consiste à interpréter une question dans un cadre de référence donné et à en transmettre le sens dans un autre cadre.

Considérez la question : « Quel était le chiffre d’affaires par client au dernier trimestre ? » Il est facile pour un entrepôt d’exécuter une requête précise. L’effort réside plutôt dans le choix de la requête qui correspond à cette question. Le chiffre d’affaires peut désigner les réservations, les facturations ou le chiffre d’affaires reconnu. Le client peut être la partie à qui les produits sont vendus, la partie à qui la facture est envoyée, ou n’importe quel nœud de l’arborescence des comptes que les analyses trimestrielles présentent. Le dernier trimestre peut correspondre aux mois du calendrier, à l’année fiscale ou à une période dynamique privilégiée par les services opérationnels.

Sur un tableau de bord, un analyste a déjà pris ces décisions. Une icône intitulée « Chiffre d’affaires » donne une impression d’autorité, car la décision sémantique est intégrée directement dans l’outil. Avec les chatbots, l’ordre des choses change : la décision est désormais prise en temps réel, pour des questions arbitraires, au sein du logiciel, ce qui transforme la sémantique d’une page wiki en une infrastructure fonctionnant en temps réel.

La conséquence fâcheuse est que plus un modèle excelle à générer du SQL plausible, plus ses erreurs deviennent dangereuses. La correction syntaxique ne dit rien sur la validité sémantique. Une explication soignée peut répondre à la mauvaise question de manière si fluide que personne ne s’en aperçoit jusqu’à ce qu’un rapport contradictoire avec les archives de conversation apparaisse. Les équipes qui se contentent de vérifier si une requête a été exécutée s’entraînent ainsi à faire confiance à des erreurs présentées de manière convaincante.

Les modèles dimensionnels possèdent déjà un certain sens

Rien de tout cela ne fait d’un entrepôt une page blanche. Le modélisation dimensionnelle de style Kimball a passé des décennies à compenser le manque d’informations offert par les schémas relationnels polyvalents. Les faits, les dimensions, les mesures, le niveau de détail, les hiérarchies et les dimensions conformées inscrivent tous un sens métier dans des structures que les gens peuvent interroger.

Un schéma étoile bien conçu fonctionne déjà comme une couche sémantique informelle. Les couches sémantiques actuelles ajoutent davantage, en intégrant des définitions de métriques, des règles de calcul, une terminologie, des relations autorisées ainsi que des règles métier que les noms de colonnes ne peuvent révéler. Une ontologie formelle va encore plus loin, en séparant le modèle conceptuel de son implémentation relationnelle et en établissant délibérément une correspondance entre les deux.

Il est préférable de le considérer comme un continuum plutôt que comme un processus de conversion :

• schéma relationnel opérationnel
• modèle dimensionnel
• couche sémantique
• ontologie formelle

En descendant la liste, on inscrit davantage de sens et on demande au modèle de deviner moins. Chaque élément laissé implicite représente un pari sur le fait que l’inférence aboutira à la définition que le directeur financier accepterait sans hésiter.

Ce que la recherche continue de montrer

Les études récentes sur la conversion de texte en SQL aboutissent toutes au même résultat : l’explicitation du sens métier améliore la précision, et cela vaut même pour des schémas déjà conçus à des fins d’analyse.

Lors d’une expérience menée par Figueiredo et ses collaborateurs, GPT-4 Turbo a été utilisé sur un schéma en étoile. Ce schéma seul permettait d’obtenir environ 58 % de requêtes correctes, tandis que l’ajout de sémantique contextuelle a porté ce taux à environ 89 %. Rumiantsau et Fokeev ont ajouté un bref document sémantique à un modèle de entrepôt analytique basé sur Contoso, ce qui a fait passer la précision d’environ 48 % à 52 %, soit dans la haute cinquantaine. Ces améliorations sont significatives car les points de référence n’étaient pas des schémas transactionnels complexes.

Lorsque le schéma physique ne renseigne pas suffisamment sur l’activité commerciale, les effets négatifs s’accentuent. Painter et ses collègues ont travaillé sur une base de données opérationnelle comptant plus de 500 tables et ont augmenté le taux de génération d’SQL validé de près de 8 % à environ 78 % en fournissant de la terminologie, des règles, des relations et des mappages. Nascimento et ses collaborateurs ont constaté que la précision d’exécution sur une base de données industrielle complexe est passée de 41 % à 65 % rien qu’en utilisant des noms conceptuels orientés vers les besoins métier, pour atteindre 74 % une fois que les sémantiques des relations utiles étaient également clairement définies.

Les modèles formels suivent la même tendance. Dans une étude menée par Sequeda, Allemang et Jacob, poser des questions directement à une base de données relationnelle d’entreprise a donné une précision d’environ 17 %, tandis que l’utilisation d’un graphe de connaissances soutenu par une ontologie a atteint environ 54 %. Une étude ultérieure de Nascimento a conservé SQL pour l’exécution, mais a d’abord utilisé un graphe de connaissances pour relier les concepts métier au schéma physique. Mesuré par le score F1 de liaison de schémas, un LLM seul a obtenu environ 0,85. L’approche par graphe a atteint 0,90, le graphe combiné à un LLM 0,93, et le pipeline complet de liaison sémantique avec une mémorisation parfaite 0,996.

La lecture pertinente est d’ordre architectural et non promotionnel : rendre explicite la correspondance entre les concepts et les structures relationnelles, retirer à le modèle toute improvisation sémantique, et laisser l’exécution au moteur relationnel où il fonctionne déjà correctement.

Ce que le modèle relationnel a accompli et ce qu’il n’a pas accompli

Le modèle relationnel de Codd a assuré l’indépendance des données : les applications ne devraient pas dépendre de la manière dont les données sont physiquement stockées. Cette réalisation reste d’actualité.

Les outils d’analyse de données conversationnels exigent quelque chose de plus spécifique et de plus difficile. Un schéma analytique relationnel ne suffit pas à lui seul pour définir tous les sens métier nécessaires pour répondre à une question. Les noms, les clés, les contraintes et les commentaires aident, et les modèles dimensionnels aident encore davantage. Cependant, les définitions de métriques, les rôles joués par les termes, les conventions temporelles, l’origine des données et les règles permettant de relier les concepts aux objets physiques restent souvent dans l’esprit des personnes ou dans des diapositives.

C’est pourquoi des glossaires, des entrepôts métriques, des couches sémantiques et des catalogues ont vu le jour autour des entrepôts de données. Ils rendent progressivement explicite ce que un analyste ou un LLM improviserait autrement. Une couche sémantique moderne constitue une solution pratique au moment où les données sont utilisées dans les outils de BI. Elle reste plus restreinte qu’un modèle conceptuel général de l’entreprise, et confondre les deux est ce qui amène les équipes à être surprises par la suite.

Ajouter une ontologie tout en conservant l’entrepôt de données

Dans la pratique informatique, une ontologie décrit ce qui existe dans le domaine d’intérêt, c’est-à-dire les entités, les relations et les contraintes, de manière à ce que des logiciels puissent l’utiliser. Elle partage des racines avec le modèle relationnel en logique prédicative : des énoncés sur des objets et les relations qui les lient.

Les bases de données travaillent depuis longtemps sur ce sujet. W3C Direct Mapping et R2RML définissent la manière dont les données relationnelles se transforment en vocabulaires RDF. L’accès aux données basé sur des ontologies va encore plus loin : un utilisateur interroge le modèle conceptuel et le système le traduit en requêtes SQL à partir des sources déjà en place. Ontop, un graphique de connaissances virtuel open source mature, fait précisément cela grâce à des mappages R2RML et à des ontologies OWL 2 QL légères.

Le choix d’OWL 2 QL repose sur une logique peu spectaculaire mais utile. Il appartient à la famille DL-Lite, dont les limites sont intentionnelles afin que les requêtes gérées par l’ontologie restent gérables face à de grandes bases de données relationnelles. La puissance expressive a été sacrifiée en échange de la possibilité de le réécrire en SQL. Les travaux sur des ontologies pour les entrepôts et les modèles multidimensionnels existent déjà avant cela, permettant de représenter des dimensions, des mesures et des hiérarchies, ainsi que d’extraire des structures analytiques à partir de modèles conceptuels.

Ce qui reste peu adopté, c’est un langage d’ontologie conçu spécifiquement pour les outils BI modernes, capable de regrouper les entités commerciales, les relations, les mesures, le niveau de détail, les agrégations, le temps, l’origine des données et les mappages d’entrepôt dans un seul modèle structuré.

Adopter cette approche ne signifie pas transférer l’entrepôt dans une base de données graphique. La signification peut être décrite dans l’ontologie, tandis que les faits restent dans des tables relationnelles et que les calculs restent en SQL. La matérialisation d’un graphe est optionnelle, utile pour les charges de travail qui en tirent profit, et ne constitue pas un critère décisif.

Faits stockés et leur signification

Les lignes et les triples RDF sont plus étroitement liés que ne le suggèrent les rivalités entre outils. Une ligne indique qu’une tuplique appartient à une relation nommée, tandis qu’un triple divise une proposition en sujet, prédicat et objet. La normalisation forte oriente déjà les conceptions relationnelles vers des faits plus petits. Les deux ne sont pas formellement équivalents, mais leur similitude est utile.

Pour les agents, la distinction importante n’est pas entre tableau et graphe. Il s’agit plutôt de données extensionnelles et de sens intentionnel : les faits qui sont stockés par rapport aux règles définissant ce que ces faits signifient. Une ontologie peut indiquer qu’une classe englobe une autre, que deux prédicats sont inverses, qu’une relation est transitive, ou qu’une combinaison particulière est impossible. OWL fournit une sémantique formelle pour de telles déclarations, SHACL valide les formes des graphes, et des cadres logiques plus avancés existent en cas de besoin.

Une ontologie ne se traduit pas toujours facilement en SQL, car certaines langages sont plus expressifs que ce que les fragments de réécriture efficaces peuvent gérer. La recherche en OBDA aborde ouvertement ce problème, en proposant des solutions pour limiter l’expressivité, effectuer des approximations, matérialiser les données ou raisonner dans une étape distincte. Cette contrainte est utile, car elle oblige à préciser quelles sémantiques s’appliquent sur le chemin d’exécution, celles qui sont compilées à l’avance, et celles qui relèvent d’un profil différent. Peu d’entreprises enregistrent aujourd’hui ces pertes, ce qui se traduit par des conflits dans les canaux de discussion.

Le contexte d’un fournisseur n’est pas votre ontologie

Les fournisseurs sont déjà en train de s’adapter. Google Cloud constitue un exemple pertinent, car plusieurs de ses versions prévues pour 2026 ciblent des contextes d’entreprise que les machines peuvent utiliser. Dataplex Universal Catalog a été réorganisé en Knowledge Catalog et fonctionne davantage comme un graphe de contexte en temps réel qu’un registre statique. Il offre une recherche sémantique, des descriptions enrichies, des graphes de relations, des modèles SQL vérifiés, des API de contexte ainsi que des chemins d’accès pour les agents. Parallèlement, l’interface Open SQL de Looker permet aux clients JDBC de consulter des modèles LookML comme s’il s’agissait de schémas, en réutilisant les dimensions, agrégats, calculs et relations déjà définis.

Ces mises à jour soulignent un point fondamental : un agent a besoin de plus que simplement un accès aux lignes de données. Il a besoin d’un contexte soigneusement organisé, de modèles sémantiques, de relations, d’exemples vérifiés ainsi que d’interfaces gérées.

Même ainsi, elles ne parviennent pas à former une seule ontologie d’entreprise cohérente. Les sémantiques de LookML, les termes de catalogue, les définitions de graphes de BigQuery et le contexte écrit par des agents constituent des représentations liées mais distinctes. À moins que l’organisation ne dispose des identifiants canoniques et des mappages explicites entre elles, la promesse de définir une fois se transforme en une définition nécessaire pour chaque produit.

Des trimestres entiers ont été perdus à cause de ce piège. Le graphe de contexte d’un fournisseur peut être très précieux sans pour autant servir de source formelle de vérité sémantique. Adoptez-le librement, tout en gardant à l’esprit que l’adoption ne signifie pas la propriété.

Six principes de conception

La règle qui prime sur toutes les autres est que le sens doit être lisible à la fois par les humains et par les machines, et rester cohérent à travers toutes les représentations.

Donnez un sens et une identité. Chaque concept, relation, métrique, politique et affirmation de qualité doit disposer d’un identifiant stable. Un nom n’est qu’une étiquette, tandis qu’un identifiant constitue l’objet lui-même. Le terme « client » apparaît dans les tableaux de bord, les API, les tables de entrepôt et les messages destinés aux agents, et tous ces éléments doivent faire référence à un même objet sémantique, ou consciemment à des objets distincts si l’entreprise considère réellement des concepts séparés. Le service client et le service financier peuvent définir le « client actif » différemment, à condition de ne jamais partager d’ID sans en indiquer la raison.

Rendez les définitions exécutables. Le texte narratif s’adresse aux personnes et aux modèles, mais tout ce qui influence le calcul nécessite une structure : types, relations, cardinalités, unités, formules, niveau de détail, période de validité, contraintes, règles de mappage et politiques. Un paragraphe descriptif dans un catalogue relève principalement d’une convention humaine.

Les solutions basées sur Google Cloud s’organisent de manière hiérarchisée, et une allocation fonctionnelle se présente comme suit : Knowledge Catalog gère l’identité, les définitions, les unités, les propriétaires, la période de validité, les politiques, les relations et les mappages. LookML contient les formules exécutables, les dimensions, les jointures ainsi que la génération des requêtes. Conversational Analytics interprète le langage naturel dans ce contexte, les requêtes vérifiées servant de points de référence pour les analyses de régression. Cette organisation n’est possible que si les identifiants franchissent délibérément chacune de ces frontières.

Associez explicitement la sémantique aux données physiques. Supposons que l’ontologie indique qu’un Client possède un Compte. L’implémentation doit alors nommer la relation ou la dérivation qui rend cette affirmation vraie, et la correspondance doit être versionnée avec ses deux extrémités. Aucun outil en un clic ne permet de transformer OWL en chaque produit de catalogue. Quelqu’un doit créer et maintenir ce pont, sinon le terme « sémantique » ne signifie guère plus que du branding.

Traitez les relations comme étant de première importance. Un rôle prend son sens à travers ses liens avec des processus, des organisations, des activités, des capacités et des coûts, et non à cause d’une colonne nommée role_type. Il en va de même pour les clients, les produits, les contrats, les comptes et les métriques. Une nomenclature et un style de rédaction peu structurés aident déjà à la conversion du langage naturel vers SQL, mais ce sont les sémantiques relationnelles formelles qui distinguent la simplicité relationnelle de la clarté ontologique. Leur définition exige un effort réel, et une ontologie qui ignore ce coût échoue dès sa phase pilote.

Conservez les métriques au sein du même modèle. Les mesures dimensionnelles possèdent déjà une identité, une formule, un niveau de détail et un comportement d’agrégation, et les couches sémantiques permettent d’en exploiter davantage les fonctionnalités. Le sens plus large, y compris la propriété, les unités, les exclusions, l’origine, les politiques, les dates d’effet ainsi que les liens avec les concepts d’entreprise, a tendance à se disperser dans d’autres systèmes. La fragmentation est souvent le véritable problème architectural : une mesure dimensionnelle, une mesure LookML et un terme de catalogue décrivent chacun une partie superposée d’une même idée commerciale, mais sous trois identités distinctes.

Compilé une fois, utilisé de multiples façons. Un modèle canonique doit générer ou guider ses projections, telles que LookML, des vues SQL, des schémas API, des entrées de catalogue, des formes de graphes, des contrats d’outil pour les agents, de la documentation ainsi que des tests de validation. Les plateformes peuvent conserver leur propre syntaxe, mais elles ne doivent pas inventer le sens.

LinkML montre qu’un modèle indépendant de la technologie peut générer du DDL SQL, du DDL BigQuery, des schémas JSON, OpenAPI, OWL, SHACL, de la documentation ainsi que des validateurs. Ce qu’il ne peut pas faire, c’est choisir à la place de quiconque les faits, les dimensions, les mesures, le niveau de détail ou les dimensions conformes. Il existe des recherches visant à transformer des ontologies en schémas en étoile, mais aucune chaîne dominante ne permet de passer complètement d’une ontologie canonique à un entrepôt dimensionnel géré, à un modèle sémantique exécutable, puis à une conversion texte-SQL basée sur l’ontologie. C’est ce manque de pipeline qui représente le défi technique, et la génération de DDL n’est qu’une démonstration simple.

Deux approches et la nécessité de convergence

La plupart des entreprises ne peuvent pas mettre en pause le programme de gestion d’entrepôt pour le reconstruire d’abord autour d’une ontologie. Ce n’est pas un problème. La tâche consiste à faire en sorte que les agents résolvent de manière fiable la signification de ce qui peut être expédié, et à concevoir un parcours tactique permettant leur évolution.

Selon le Plan A, une ontologie d’entreprise canonique détient l’autorité sémantique, avec des identifiants stables et une sémantique logique explicite. Les données physiques ne sont pas modifiées, et l’ontologie est mise en correspondance avec des représentations relationnelles et autres. Les indicateurs analytiques deviennent des projections compilées. Les agents tirent des concepts formels, des relations, des politiques et des informations sur l’origine des données, et les modifications sont versionnées et publiées de la même manière que le code. Les représentations contenues dans les produits sont générées à partir de la sémantique détenue par l’entreprise, ou mises en correspondance avec elle.

Le plan B commence à partir du niveau déjà occupé : une couche de métriques gérées associée à un catalogue et à un modèle de contexte, auxquels des identifiants canoniques stables sont ajoutés délibérément. L’entrepôt reste la source d’autorité, et la correspondance entre les objets sémantiques et les tables, colonnes, jointures et filtres est consignée. Les agents sélectionnent des champs et des métriques certifiés plutôt que des tables brutes, puisant le contexte dans des services de contexte, des requêtes vérifiées et des opérations de récupération respectant les permissions. Les métriques, les correspondances, les questions types et les tests de régression sémantique sont intégrés au pipeline CI/CD. Les identifiants propres à un produit ne deviennent jamais des identités d’entreprise, et les liens croisés permettent une migration continue.

Un plan B concret pour Google Cloud associe le Knowledge Catalog, qui fournit un contexte et des outils de découverte, au Looker : un modèle sémantique géré permet de limiter l’analyse conversationnelle aux objets sémantiques certifiés, de conserver les requêtes vérifiées comme points de référence pour les tests de régression, et de stocker les identifiants d’entreprise en dehors de tout produit spécifique. Le Knowledge Catalog ressemble à une ontologie uniquement au sens restreint, offrant un contexte et des relations structurés pour les agents sans constituer un système d’ontologie formelle complet. Il faut le considérer comme un outil pratique et non comme une vérité absolue.

Le risque réside dans une couche sémantique tactique dont les identifiants et la logique ne peuvent jamais être intégrés dans un modèle plus formel. Un plan B qui ne peut pas aboutir n’est qu’un cul-de-sac décoré de tableaux de bord.

Résoudre d’abord, puis s’occuper des tables

Une approche solide en matière d’analyse conversationnelle ne devrait pas commencer par la sélection des tables, mais par la résolution sémantique.

Prenez la question « Le taux de désabonnement a-t-il augmenté parmi les clients de détail à haute valeur cette période ? ». Les termes « taux de désabonnement », « clients de détail à haute valeur » et « cette période » doivent d’abord être traduits en objets gérés avant toute autre chose. Ces objets contiennent la définition de la métrique, sa classification, la convention temporelle, les dimensions autorisées, les mappages sources et les politiques associées. Ce n’est qu’après cela que la couche d’exécution peut rédiger la requête physique.

Les équipes chargées des boucles doivent être capables de décrire les étapes de traitement en huit étapes :

1. Question et contexte utilisateur
2. Résolution sémantique vers des concepts et des métriques gérés
3. Récupération du contexte filtrée par les politiques et les permissions
4. Mappage des objets sémantiques vers les données physiques
5. Génération de la requête ou du plan d’outil
6. Exécution et conciliation
7. Réponse étayée par des preuves et une traçabilité

Régression ou évaluation sémantique, ainsi que des actions contrôlées là où cela est applicable

La démarche est loin d’être simplement de coller un schéma analytique dans la demande et d’espérer. Le LLM peut encore clarifier l’intention et élaborer un plan, mais il fonctionne à travers des objets sémantiques contrôlés et des contrats d’outils, et non en décodant le vocabulaire du CFO à partir d’une table nommée fct_rev_v3.

Les requêtes vérifiées sont précieuses en tant que tests et exemples, mais elles ne représentent pas la sémantique. Elles prouvent seulement qu’une question a donné lieu à une implémentation acceptée à un moment donné. Le sens sous-jacent nécessite encore sa propre identité et définition.

Ce qui ne compte pas comme une architecture sémantique

Un catalogue rempli de descriptions en prose facilite la découverte. Ce n’est pas un système sémantique exécutable.

En orientant par défaut les agents vers des schémas de entrepôt bruts et en qualifiant cela de BI en auto-service, on transfère simplement le risque sémantique sur un modèle probabiliste.

Dupliquer chaque fait lié à l’entrepôt dans un graphe de connaissances « pour l’IA », sans bénéfice concret en termes d’exécution, crée une deuxième version de la vérité entreprise qui reste en retard en raison des délais de synchronisation.

Séparer complètement les métriques de l’ontologie au point qu’un même concept métier finisse par avoir des identités contradictoires dans la BI et dans les modèles de connaissances, cela engendre des conflits à terme.

Confondre une représentation avec la sémantique, par exemple en supposant qu’un graphe est intrinsèquement plus sémantique qu’un modèle dimensionnel, relève d’une pensée de type culte du cargo. Les modèles dimensionnels, les couches sémantiques, les graphes de connaissances et les ontologies codent tous le sens à des degrés différents, et choisir un graphe ne crée pas de sens par lui-même.

Considérer les métadonnées ou les relations générées par l’IA comme des faits, sans indication de provenance ni statut de vérification, c’est ainsi que la fiction plausible se transforme en politique officielle.

L’objectif en une phrase

Les gens voudraient obtenir les chiffres du mois dernier avec la même facilité qu’ils demandent des informations météorologiques. Ce n’est plus de la fantaisie. Le logiciel prend en charge le travail sémantique que les analystes et les ingénieurs effectuaient autrefois sans y prêter attention, et obtenir des réponses cohérentes signifie rendre ce travail explicite.

Ni un LLM intégré à un entrepôt, ni un catalogue combiné à une recherche vectorielle ne constituent la solution finale. Il s’agit d’un système sémantique géré de manière rigoureuse, dans lequel les concepts, les relations, les métriques, les contraintes, les politiques, la qualité et la provenance conservent tous un même sens pour les humains et les machines, reliés par des mappages formels aux données sous-jacentes.

Une grande partie des données de base reste à traiter de manière optimale dans des moteurs analytiques relationnels et SQL, et les technologies sémantiques ou ontologiques ne sont pas encore là pour les remplacer. Leur rôle est de compléter le modèle à un niveau que un schéma relationnel ne pouvait jamais atteindre seul, même après avoir été optimisé par le modélage dimensionnel et une nomenclature soignée.

Lorsqu’il n’est pas encore réaliste d’écrire et de maintenir une ontologie analytique complète, il convient de déployer une couche sémantique gérée, tout en conservant l’structure existante. Les aspects sémantiques devraient être intégrés progressivement, en sortant des tableaux de bord et des requêtes pour former un modèle d’entreprise de premier ordre, où chaque produit dispose de sa propre couche considérée comme une vue compilée.

L’objectif n’est pas une seule base de données, outil ou syntaxe. Il s’agit d’un sens unique que une personne, un tableau de bord, une application et un agent IA interprètent de la même manière. Si les quatre ne sont pas d’accord, le problème ne réside pas dans le LLM. Il s’agit d’un problème d’identité qui a été reporté.

Lectures complémentaires

• Concepts de LangGraph expliqués simplement : état, mémoire et orchestration — Avant d’écrire du code : ce que signifient l’orchestration, le temps d’exécution, les agents à état, la mémoire à court et long terme, ainsi que les systèmes multi-agents et l’intervention humaine dans LangGraph.
• Notes pratiques : Évaluation des agents et détection du dérive — ce qu’offre le nouveau coding-agent — Guide pas à pas des Notes pratiques : Évaluation des agents et détection du dérive — ce qu’offre le nouveau coding-agent : contrats, vérifications et emplacements de code à insérer pour les équipes utilisant ce modèle.