Votre modèle sémantique est l’API : fournir aux agents des métriques certifiées.
Pourquoi les agents d’IA inventent-ils des définitions privées de revenus et d’inventaire, et comment un modèle sémantique géré avec des granularités, des propriétaires et des refus leur fournit un contrat unique.
Deux chiffres, tous deux officiels
La réunion de planification a débuté par une diapositive intitulée « La semaine dernière, les ventes ». La veille au soir, deux collaborateurs avaient chacun reçu la même question, et tous deux avaient renvoyé des graphiques accompagnés de fichiers SQL. Un chiffre était supérieur de 4 % au plan prévu, tandis que l’autre était inférieur de 3 %.
Personne dans la pièce n’a imputé cela à des colonnes fantômes. Le entrepôt disposait bien d’une table sales contenant une colonne net_amt ainsi que des dates. Les requêtes se compilaient correctement, les clés de jointure existaient, et du point de vue de la base de données, les deux résultats étaient valables.
La finance a ensuite présenté une troisième version, celle qui avait déjà été utilisée pour la lettre hebdomadaire du conseil d’administration. Elle comptabilisait les revenus reconnus selon la date de facturation, soustrayait les notes de crédit, et excluait à la fois les achats effectués par les employés et les ventes en gros. Copilot un se basait sur la date de commande et incluait les achats effectués dans les magasins internes aux employés. Copilot deux se basait sur la date d’expédition et prenait la région à partir de l’adresse de livraison plutôt que de l’organisation vendeuse.
Lorsqu’on a demandé dans le même thread quelle date chacun avait utilisée, l’un a indiqué order_dt et l’autre ship_dt. Aucun des deux n’a mentionné les notes de crédit. Concernant l’inclusion des achats des employés, l’un a dit ne pas avoir vu de filtre pour eux, tandis que l’autre a inventé une histoire au sujet d’un indicateur channel qui s’est avéré être un champ d’attribution marketing sans lien avec les magasins internes aux employés.
La question ici était l’obéissance. Les deux agents se sont comportés comme des analystes compétents ayant une journée difficile : ils ont repéré une colonne dont le nom ressemblait à la question et l’ont additionnée. Un humain s’arrêterait normalement pour demander quel numéro de vente était recherché, tandis qu’un agent interprète une colonne plausible comme un signal vert pour terminer.
Par la suite, le fil Slack contenait trois graphiques et un numéro financier. Personne n’a collé le nom d’aucune métrique, seulement des captures d’écran, ce qui constitue un signe d’alerte utile. Lorsque le débat porte sur des images, le contrat n’est jamais consulté.
Donnez à un agent un entrepôt et une instruction claire, et il inventera l’activité commerciale. Cette invention ressemble à de la compétence et finit sur Slack, où les gens discutent des poids des modèles au lieu de s’occuper du contrat manquant. De telles discussions sont facilement qualifiées de problèmes culturels, mais elles proviennent en réalité d’une interface absente, et ce n’est que lors des réunions quotidiennes que l’échec devient visible.
Une façon pratique d’imaginer le modèle sémantique, c’est de le considérer comme une API, mais pas au sens de la tendance REST. Pensez à une interface qui exclut toute interprétation subjective. Lorsque quelqu’un demande les ventes de la semaine dernière, l’utilisateur n’a pas le choix de la colonne de date à utiliser. Le système exécute recognized_revenue selon les paramètres indiqués, sinon il refuse la demande. L’engine peut toujours générer du SQL, mais ce n’est pas l’agent qui le rédige.
Il est acceptable d’imaginer des points de terminaison et des clés API si cela aide. Ce qui compte, c’est quelque chose de plus précis : une opération dotée d’un nom et d’une signification bien définie que tout appelant autorisé peut exécuter.
Les API disposent également de propriétaires, de versions et de règles relatives aux changements perturbateurs. Une mesure sans propriétaire n’est qu’une rumeur qui se produit par hasard. Lorsque le secteur financier modifie la manière de gérer les notes de crédit, cela devrait entraîner une mise à jour de version ressentie par tous les appelants, sinon on revient aux anciennes versions. Afficher la version de la métrique en pied de page de la lettre hebdomadaire pendant un mois peut sembler pedantique, mais cela transforme la question « quel revenu ? » d’un conflit de personnalités en une question de version.
La requête était parfaite, mais la signification ne l’était pas
En donnant à un modèle moderne un dump de schéma ainsi qu’une question liée aux revenus, le SQL généré est généralement suffisamment propre pour avoir été impressionnant il y a dix ans. Ce n’est plus là que réside le risque.
Le chiffre d’affaires n’est pas une colonne. Même une seule entreprise peut avoir un chiffre d’affaires enregistré, facturé, livré et reconnu, ainsi que tout montant enregistré par les caisses avant les retours. Les notes de crédit peuvent compenser ou non ces montants. Les ventes interentreprises peuvent être prises en compte ou non. « Pays-Bas » peut désigner le pays de facturation, le pays de livraison ou l’organisation commerciale propriétaire du compte, et « le mois dernier » peut correspondre à un mois calendaire ou à une période fiscale se terminant un dimanche.
Rien dans tout ceci ne concerne la syntaxe JOIN. Une opération de jointure classique peut encore produire une réponse erronée pour la décision qui en dépend.
L’inventaire se comporte de la même manière. Les stocks disponibles ne sont pas considérés comme pouvant être promis, et ceux qui le sont ne correspondent pas à ce que le moteur d’allocation libérera réellement pour le e-commerce ce soir. Un agent qui répond « pouvons-nous le promettre pour vendredi » en se basant sur les quantités en stock donnera l’impression de gérer la situation, mais cela laissera malgré tout le client dans l’incertitude.
Dans un cas, un agent a rassuré un responsable d’entrepôt au sujet d’un modèle, car il avait additionné la valeur qty_on_hand de chaque site, y compris celui présentant des dommages, bien que la planification ait déjà indiqué que ce conteneur était inutilisable. La requête SQL était bien structurée, mais sa signification n’était qu’une supposition. Le responsable avait personnellement vérifié le conteneur plus tôt dans la journée, tandis que l’agent ne disposait que de données issues d’un tableau.
Les rapports instantanés montrent la même disparité. Les services de gestion des magasins souhaitent des données relatives aux transactions effectuées avant 16 heures, tandis que le service financier exige que les revenus soient reconnus après déduction des crédits. Lors d’une réunion, les deux parties parlent de « ventes d’hier ». Un agent qui reçoit cette phrase sélectionne une colonne de date et une colonne de montant, puis s’arrête là ; les discussions commencent une fois le graphique affiché.
La planification des marchandises présente le même piège. La demande diffère des données de point de vente, et celles-ci diffèrent des ventes nettes une fois que les retours sont pris en compte. Un style peut apparaître comme épuisé dans l’outil de gestion des promesses en ligne, tandis qu’un tableau visible par l’agent indique encore des stocks disponibles, car ce tableau inclut également les unités en transit, celles en contrôle qualité ainsi que la quantité réservée pour des livraisons en gros. Si l’agent répond « est-ce que nous l’avons » en se basant sur des informations erronées, l’entreprise fera des promesses excessives dès le matin, avant de devoir passer l’après-midi à expliquer un manque de stock que le tableau n’avait jamais signalé.
Appeler cela un échec de la requête manque le point essentiel, puisque la requête « avons-nous cela ? » était correcte. Ce qui manquait, c’était un objet available_to_promise décrivant en détail les éléments concernés : l’ensemble des lieux, les types de stock exclus, les quantités en transit, ainsi que l’instantané temporel auquel il se réfère. En l’absence de cela, chaque utilisateur doit improviser sa propre chaîne d’approvisionnement.
C’est pourquoi le confort traditionnel offert par les outils BI en mode auto-service ne s’applique plus. Dix personnes consultant un même tableau de bord partagent au moins le même chiffre erroné. Dix agents écrivant chacun dix requêtes privées semblent raisonnables localement, mais l’organisation se retrouve alors plongée dans un chaos de désaccords sans chiffre fiable.
Un analyste qui manque de contexte pose une question supplémentaire. Un agent qui manque de contexte complète la phrase. Dans les démonstrations, c’était une curiosité, mais en production, c’est un danger, car la même architecture qui rendait les données facilement accessibles les rendait également facilement consultables sans aucun accord préalable.
Deux décennies ont été nécessaires pour rendre les données accessibles via des entrepôts de données, des lakehouses, des solutions ELT, des notebooks et des API, si bien que le goulot d’étranglement se trouve désormais ailleurs. Le fait que le logiciel puisse voir la table est acquis. En revanche, le fait qu’il puisse décider de ce que signifie cette table ne l’est pas.
Ce qu’implique un contrat de signification
Un glossaire est insuffisant car il peut simplement être mal interprété, tandis qu’un contrat fonctionne soit correctement, soit est rejeté. Les opérations définies par un modèle sémantique utilisable sont celles sur lesquelles les parties prenantes ont déjà débattu et trouvé un accord :
- Les revenus reconnus ont une définition précise, et certaines lignes n’en font jamais partie.
- Un client actif est défini par une règle, et non par une intuition.
- C’est la relation client-région que les services financiers sont prêts à soutenir.
- Pour cet indicateur clé, la période est déterminée par la date de facturation et jamais par la date de commande.
- Certaines dimensions peuvent être utilisées légalement pour le filtrage, tandis que les autres ne servent qu’à la présentation.
En dessous se trouvent des mesures, des dimensions, des hiérarchies, des champs calculés, des métadonnées et des filtres de ligne, et il n’a pas d’importance quel fichier du fournisseur les contient. Fonctionnellement, un fragment du langage métier a été capturé sous une forme que le logiciel peut appeler. Jusqu’à récemment, l’utilisateur principal était un rapport. Le nouvel utilisateur ne s’ennuie jamais, ne se rend jamais au bureau de l’analyste et n’éprouve aucune honte à se tromper avec assurance.
Les détails sont ce que les équipes négligent car cela ressemble à des devoirs de modélisation, or c’est justement le cœur du domaine API. En ne déclarant rien, chaque utilisateur crée ses propres règles. Cela se résume à quatre questions qui nécessitent des réponses au même endroit :
- Quelle date marque la fin de la période.
- Quelle entité le chiffre concerne, qu’il s’agisse de l’organisation vendeuse, du destinataire ou du destinataire de la facture.
- Quelles lignes doivent être exclues, comme les employés, les ventes en gros, les commandes interentreprises et les commandes de test.
- Quelles règles de sécurité s’appliquent encore lorsque l’utilisateur est un agent.
En l’absence de ces informations dans le modèle, les réponses finissent dans une discussion Slack, ce qui revient à dire nulle part.
Une métrique de marge montre comment les choses se passent. La formule était bonne, mais la date utilisée était imprécise. Un appelant a utilisé la date de commande car c’était la valeur par défaut dans la table factuelle, tandis qu’un autre a utilisé la date de facture car c’était le cas dans la vue financière. Tous deux ont indiqué une « marge », mais leurs valeurs se sont écartées de deux points en une semaine lorsque les coûts de transport ont fortement augmenté. L’agent a pris la responsabilité, bien que le véritable défaut résidât dans l’absence de données pertinentes. L’ajout de la date de facture, d’une règle d’inclusion des coûts de transport et d’un identifiant précis a résolu le problème, et les valeurs de la semaine suivante étaient cohérentes. Personne n’a remercié le modèle, mais les demandes de vérification ont cessé.
La démarche à suivre est conçue de manière monotone : intention, liaison, application, exécution, réponse. À aucun moment le modèle ne décide de ce que signifie le chiffre d’affaires. Il est acceptable de choisir la métrique certifiée qui correspond à la question, car il s’agit alors de classification. Assembler une métrique à partir de tableaux bruts relève de l’interpolation, et c’est par interpolation que deux chiffres officiels apparaissent avant même le premier café.
Le suivi raconte l’histoire. Si l’agent sélectionne les colonnes en fonction de leur similitude de nom, c’est un collecteur de données. S’il utilise recognized_revenue accompagné d’une période et d’une région, c’est un demandeur. Le deuxième suivi est moins spectaculaire, mais c’est celui qu’il convient de présenter lors d’un audit.
Les métadonnées ont cessé d’être de la documentation
Les descriptions étaient autrefois ajoutées en dernier recours, une fois le tableau de bord livré et uniquement si la séance de travail laissait encore des heures, ce qui arrivait rarement. Une mesure nommée [NS Adj LY %] était acceptable car les trois personnes qui modifiaient le fichier connaissaient son historique.
Un agent ne connaît pas ces particularités. Les directives de Microsoft pour la préparation de modèles sémantiques destinés aux agents de données le confirment : les noms, les descriptions, les relations et la réduction de l’ambiguïté conditionnent la qualité des réponses, et cela vaut même en dehors de ce cadre technique. Ces chaînes de caractères constituent désormais des entrées obligatoires. Une description vide n’empêche pas l’agent de répondre, elle se contente de relier à une rumeur.
Ce changement est facile à sous-estimer car le fichier semble identique. Il contient toujours un modèle avec des mesures. Ce qui a changé, c’est l’utilisateur : un développeur humain infère, tandis qu’un agent relie les données, et même une liaison approximative produit encore une réponse accompagnée d’un graphique.
Un nom de mesure énigmatique est désormais considéré comme un défaut de production, tout comme une fonction publique non documentée. Personne ne livrerait fn_x3() en tant qu’API de facturation, pourtant pendant une décennie elle a été acceptée comme une API de mesures simplement parce que des gens l’utilisaient.
Les plateformes ont fait le même pari
En retirant les couleurs de la marque des pages produits, un schéma se dessine clairement. Microsoft, Snowflake, Databricks et ThoughtSpot investissent tous dans des couches sémantiques, une gouvernance et ce qu’ils appellent un contexte d’affaires fiable. Leur argumentation ne repose pas sur une démonstration spectaculaire d’un modèle générant du SQL.
Tous espèrent qu’un modèle doit raisonner en se basant sur un sens certifié plutôt que sur la colonne qui se trouve par hasard la plus proche d’un mot dans la question. Les agents de données de type Fabric, qui interagissent avec des entrepôts de données, des lakehouses et des modèles sémantiques Power BI, reflètent cette conviction. Il en va de même pour les analystes de type Cortex qui privilégient une vision sémantique à un simple affichage de schéma brut, ainsi que pour les vues et catalogues métriques qui transforment un KPI en objet de plateforme. ThoughtSpot vend depuis des années la fonctionnalité « demander aux données » via une couche modélisée, et le reste du marché a compris pourquoi une fois que le logiciel est devenu un interlocuteur possible.
Une stratégie consistant à choisir le modèle le plus intelligent et à l’utiliser pour analyser le lac va à l’encontre de l’orientation des plateformes pour lesquelles des frais sont déjà payés. Ils ajoutent une couche de signification devant le lac, car les modèles sont devenus experts en SQL, la fluidité augmentant le coût des désaccords sans pour autant les éliminer. Acheter un autre copilote ne définit pas le client ; cela crée plutôt davantage de surfaces susceptibles de diverger.
Un protocole ne définit pas les revenus
MCP apparaît dans ces mêmes discussions, et le protocole est parfois confondu avec une stratégie. Il possède en réalité une véritable valeur. Prenons par exemple un agent de données Fabric publié en tant que serveur MCP, encore en version préliminaire au moment de la dernière lecture des documents : il montre que l’endroit où une question est saisie n’a pas nécessairement à être celui où la logique est gérée. Qlik et d’autres fournisseurs ont suivi la même voie, fournissant des analyses contrôlées à des assistants qui ne lancent jamais l’outil original. L’interface de saisie des questions et l’interface de représentation des résultats peuvent donc être séparées.
Néanmoins, associer un protocole à une solution est imprudent, car les protocoles sont remplacés au fil du temps. Le principe fondamental reste que le sens est un service et que le chatbot en est le client.
Exposer un fichier Power BI désorganisé via MCP ne fait que déplacer ce désordre à distance. L’agent présent dans Claude, Copilot ou un système interne se connectera toujours à [NS Adj LY %] si c’est bien ce qui a été publié.
Les solutions BI sans interface utilisateur ont déjà connu ce problème. Les équipes ont ajouté une interface SQL simplifiée au-dessus des mêmes métriques non documentées, puis ont blâmé le nouveau client lorsque les chiffres changeaient. Le protocole a fait son travail, mais ce qu’il transportait n’était rien de plus que des croyances populaires associées à une route réseau.
Ainsi, le protocole reste intégré aux mécanismes internes : recherche d’outils, transmission de contexte, appels entre processus. La signification est gérée séparément, par le biais du lien avec les métriques, du rejet des données illégales et de l’application de mesures de sécurité par ligne. De superbes mécanismes internes basés sur une définition que personne ne défendrait devant les services financiers restent des croyances populaires, seulement accompagnées d’une URL.
Le vieux débat sur les outils d’analyse se demandait quel outil standardiser. Avec des agents en tant qu’utilisateurs, la meilleure question est de savoir où se trouve le contexte analytique fiable et quels utilisateurs peuvent y accéder. La génération de rapports peut rester dans un seul produit, tandis que les agents sont servis à partir d’un modèle géré situé plus près du stockage, ou l’inverse. Ce qui ne fonctionne pas, c’est de permettre à chaque utilisateur de conserver sa propre copie privée des données financières, pour ensuite feindre la surprise lorsque les chiffres diffèrent.
Les tableaux de bord sont devenus un parmi plusieurs utilisateurs
Autrefois, les tableaux de bord étaient le seul utilisateur sérieux, ce qui n’est plus le cas aujourd’hui. On supposait longtemps qu’un modèle sémantique appartenait à un seul outil d’analyse : les modèles Power BI alimentaient les rapports Power BI, et les modèles LookML alimentaient Looks. Cette approche était logique tant que les seuls utilisateurs étaient des humains et que le rapport constituait le produit final.
Aujourd’hui, un seul contrat peut servir des tableaux de bord, Excel, des applications opérationnelles, des copilotes, des outils de chat, des agents, ainsi qu’un système qui enregistre une demande lorsque une métrique sort de sa fourchette. Les tableaux de bord restent utiles, mais ils ne constituent plus le but principal du modèle, car un graphique n’est qu’un des clients de cette définition.
C’est un changement bienvenu. Les graphiques vieillissent rapidement, tandis que les définitions de chiffre d’affaires, de marge, d’occupation et de taux de désabonnement devraient évoluer lentement. Lorsque ces définitions sont correctement gérées, un nouveau copilote introduit au prochain trimestre ne nécessite pas de reprendre tout depuis le début, et un agent chargé de détecter des anomalies peut réutiliser la métrique à l’origine de la lettre hebdomadaire. C’est dans cette réutilisation que réside l’avantage réel. Un tableau de bord attrayant dont la logique est enfouie dans une mesure de niveau visuel ne mène nulle part, car un élément visuel ne peut pas être invoqué.
Chaque critique suscite une réplique : si les modèles peuvent écrire du SQL, pourquoi continuer à financer des mesures supplémentaires, et pourquoi ne pas le laisser au agent ? L’agent est de plus en plus capable de le faire. Cependant, du point de vue commercial, c’est précisément cette capacité qui provoque les problèmes. L’accès est devenu bon marché, tandis que l’obtention d’accords reste coûteuse. Dix employés qui consultent un tableau de bord partagent un même chiffre, même s’il est erroné, mais dix agents qui interagissent avec un entrepôt produisent dix vérités locales, chacune présentée avec la même assurance.
Une version bon marché de l’expérience le montre bien. Prenez un entrepôt, une question et trois configurations d’agents sans métrique commune : le résultat se traduit par trois chiffres de chiffre d’affaires accompagnés de trois explications sur pourquoi chacun d’eux serait le bon. L’un s’est basé sur les réservations parce que le nom d’une table contenait order. Un autre a doublé le comptage des kits en confondant les données de ligne avec celles de en-tête. Un troisième s’est rapproché de la méthode financière en utilisant la date de facture, tout en incluant encore les ventes en gros. N’importe lequel de ces résultats publiés dans un thread destiné à un vice-président aurait entraîné une semaine de litiges concernant le chatbot plutôt que sa définition.
Un accès bon marché, sans contrat, permet à davantage de personnes, et désormais à davantage d’agents, de créer leurs propres vérités privées. Cela explique pourquoi la modélisation est devenue plus importante, et non moins, à mesure que la génération de SQL s’est améliorée.
Une seule technologie ne suffit pas
Le prochain piège à éviter est la couche sémantique des souvenirs : certifiée dans un outil et considérée comme du folklore dans tous les autres. Une équipe peut passer un an à développer un modèle excellent au sein du produit BI que tout le monde met en avant, puis connecter directement un agent au entrepôt sous prétexte que celui-ci représente la source de vérité. Ce qui se produit en réalité, c’est que l’ambiguïté se déplace simplement. Le tableau de bord indique les revenus reconnus, l’agent affiche net_amt, et le service financier conserve son tableau de calcul. L’organisation acquiert ainsi un autre dialecte sans gagner en clarté.
La vérification est simple : lorsque la définition d’une métrique ne passe pas du entrepôt à l’outil BI, puis à l’agent, seul le nom a été changé, et le conflit persiste.
La portabilité ne nécessite pas une quatrième plateforme. L’exigence est qu’un appelant extérieur au fichier d’origine puisse effectuer la même opération et obtenir les mêmes résultats. Ce moyen peut être un objet de métriques natif du entrepôt reconnu par tous les moteurs, un service de métriques sans interface, ou un modèle sémantique strictement géré, accessible via une API de requête ou un adaptateur MCP. Un test simple permet de trancher : modifiez la définition une fois et voyez si tous les appelants la suivent. Ce qui reste inchangé n’est qu’une copie.
Les métriques natives du entrepôt semblent attrayantes lorsque la plupart des données se trouvent sur une seule plateforme, mais avec un piège bien connu. La définition est certifiée en ce lieu précis, et un agent destiné à un autre entrepôt ou à une réplique ne la rencontrera jamais. Les approches fédérées cherchent à maintenir une seule signification entre les moteurs, mais elles échouent dès que ce soi-disant niveau universel devient simplement une autre copie présentée sous un format YAML plus agréable.
Un modèle portable en métrique, légèrement peu attrayant, vaut mieux qu’un modèle magnifique coincé dans un fichier que seuls trois développeurs peuvent compiler, car les agents n’attendront pas ce fichier. Ils chercheront des alternatives.
À quoi ressemble un modèle prêt pour les agents
La plupart des modèles hérités ont été conçus pour des personnes déjà au courant des rumeurs du bureau. Un développeur comprend pourquoi une expression d’analyse de jeu supprime un canal ; un agent qui ne voit que le résultat ne le comprend pas. Une mesure DAX portant un nom humoristique sert de signal privé, mais apparaît comme du bruit pour un utilisateur qui tente de l’utiliser. Un fichier réel utilisait [NS Adj LY %] pour désigner les ventes nettes, ajustées, de l’année précédente, en pourcentage, déduisant les ventes en gros et les coûts liés aux boutiques temporaires. Seules trois personnes pouvaient le déchiffrer, et le quatrième lecteur était un agent qui interprétait NS comme les ventes nettes et s’arrêtait là.
La liste de contrôle n’est pas quelque chose d’exotique. Il s’agit de l’ancienne méthode de BI, avec un coût plus élevé en cas de négligence :
- Noms honnêtes. Empruntez le vocabulaire déjà utilisé par l’entreprise, de sorte que
recognized_revenueprévaut surNS_Adj. Si deux équipes utilisent des termes différents, choisissez-en un dans le modèle et enregistrez l’autre sous forme d’alias dans la description, plutôt que de cacher le différend derrière une abréviation. - Clauses d’utilisation. Précisez où la métrique s’applique, par exemple en indiquant qu’elle convient aux rapports du conseil d’administration, qu’elle est inadaptée aux chiffres instantanés des magasins existants, et qu’elle exclut le commerce de gros. Autrefois optionnel, ce paragraphe permet désormais de distinguer une donnée fiable d’une simple supposition.
- Relations déclarées. Le client, la facture et l’abonnement doivent être liés explicitement, afin que l’agent ne doive pas tenter de relier les données de manière arbitraire parce que deux identifiants portent tous deux le nom de
cust_id. - Une petite surface d’affichage. Chaque colonne technique restée visible représente une opportunité d’éviter de présenter les métriques. Il faut cacher les données brutes que les utilisateurs ne doivent pas réagréger. C’est difficile sur le plan politique, mais c’est nécessaire, car une API qui expose tous les champs privés n’est pas vraiment une API.
- Propriétaires et versions. Il convient de préciser quelles métriques sont officielles et lesquelles sont expérimentales, qui les modifie, et ce que signifie « v3 » alors que la lettre du conseil d’administration du dernier trimestre utilisait v2.
- Sécurité itinérante. Un agent ne doit jamais pouvoir accéder à un ensemble de lignes plus large que celui visible dans le rapport standard. Lorsque les règles au niveau des lignes n’existent que dans le service de BI tandis que l’agent se connecte directement au stockage, cela entraîne un contournement plutôt qu’un véritable accompagnement.
Considérez recognized_revenue dans le secteur du commerce de détail. Sa formule correspond au montant facturé déduit des crédits, converti depuis la monnaie de la transaction au taux comptable en vigueur à la date de la facture. La référence temporelle est la date de la facture ainsi que l’organisation vendeuse, et non le destinataire de la livraison. Ce chiffre exclut les magasins employés, les ventes en gros, les commandes de test et les ventes interentreprises. Les dimensions juridiques sont l’organisation vendeuse, la hiérarchie des produits et le canal, définis en fonction du type de commande, tandis que le tableau de référence marketing « dernier clic » est exclu de ce calcul. Le responsable financier en est le gardien, et la version utilisée est celle qui a été fournie dans la lettre destinée au conseil d’administration la semaine dernière.
Supposons qu’un agent demande des informations sur les « ventes via Instagram ». Cette dimension n’existe pas dans cette métrique, donc la réponse appropriée est un refus ou une transmission à une autre métrique certifiée gérée par le service marketing. Une personne chargée de la collecte de données pourrait intégrer ces informations dans le tableau des derniers clics et qualifier le résultat de donnée utile. Cette intégration pourrait même être techniquement valide, mais elle décrirait alors une activité commerciale différente.
Un refus vaut mieux que le silence, et le silence vaut mieux qu’une définition privée. Les équipes n’aiment pas créer de refus car les démonstrations en résultent moins convaincantes, mais les démonstrations qui échouent reflètent fidèlement le fonctionnement d’une entreprise réelle.
Aucun tour de passe-passe lié aux LLM n’est impliqué ici. Ce sont les anciennes méthodes de BI, celles qui justifiaient l’existence de différents univers de données et régissaient les modèles de données à l’époque, qui accomplissent tout le travail. Seul le consommateur a changé : autrefois, une négligence entraînait un tableau de bord incorrect que quelqu’un pouvait détecter, tandis qu’aujourd’hui elle provoque une action erronée à une vitesse mécanique.
Le travail qui ne disparaît pas
Si cela fonctionne, la file d’attente des demandes diminue effectivement. Une demande de segmentation d’un graphique par région peut être traitée par un agent lorsque la région constitue une dimension légale de cette mesure. En revanche, une demande d’ajout des données de l’année précédente relève de l’analyse temporelle, et ces données ont soit déjà été prises en compte, soit ne l’ont jamais été.
Il serait erroné de dire à une équipe de BI que son travail a disparu, car il s’est simplement déplacé. Quelqu’un doit toujours déterminer la signification de chaque KPI ainsi que la version officielle à retenir. Il faut également choisir quelles relations sont correctes, quelles sources méritent une confiance absolue, et quelles exceptions s’appliquent. Enfin, quelqu’un est responsable de définir qui peut consulter quelles lignes, quels modèles sont considérés comme fiables, comment les modifications sont testées, et comment l’historique et les responsabilités apparaissent lors des revues.
Ce travail est moins amusant qu’une représentation visuelle soignée, et envoyer un graphique presque chaque semaine est plus tentant. Néanmoins, la valeur à long terme réside du côté du travail ennuyeux. Les éléments visuels sont jetables, tandis qu’une définition que le responsable du conseil d’administration et l’agent de nuit peuvent tous deux utiliser constitue un atout.
On peut s’attendre à moins de demandes discrètes du type « veuillez créer une interface graphique » et à davantage de conflits impliquant des demandes du type « veuillez agir en tant qu’organe législatif ». Ceux qui voulaient simplement créer des graphiques pourront trouver cette période dégradante. Ceux qui souhaitaient que les chiffres restent fiables même après manipulation par le logiciel constateront que ce travail ingrat est devenu la tâche principale.
Modèles de défaillance récurrents
Ces problèmes continuent d’être classés comme des défauts liés à la qualité du modèle, et il convient d’examiner leur nature avant que quiconque ne remplace le modèle.
- Le collecteur de colonnes. L’agent saisit le premier champ dont le nom contient
rev. Aucune métrique n’est invoquée, bien que la trace paraisse active. - Le grain privé. Chaque appelant choisit sa propre date, et chacun est convaincu d’avoir répondu correctement « le mois dernier ».
- Le contrat wiki. La règle réelle est écrite sur une page Confluence que personne n’a touchée depuis une réorganisation, et le modèle lui-même ne contient que un commentaire de colonne indiquant « ventes ».
- Le souvenir de pile. La seule métrique certifiée se trouve dans un fichier BI, et l’agent communique avec l’entrepôt car c’était la voie de démonstration la plus simple.
selling_org. Le tableau de bord du lundi que ce manager utilisait normalement aurait rejeté la requête. L’agent semblait plus performant, ayant contourné le seul mécanisme de contrôle en vigueur.Si deux de ces points vous semblent familiers, les évaluations par chatbot ne devraient pas être la première étape. Commencez par définir la métrique et en préciser la granularité dans le modèle, puis exigez que l’agent l’appelle, et ce n’est qu’après cela que vous devriez commencer à mesurer.
Un test rapide pour les évaluations : demander les revenus du mois dernier, puis vérifier les détails. Quelle colonne de date a été choisie ? Quelles exclusions ont été prises en compte ? Les achats des employés ont-ils été comptabilisés ? Un agent qui doit inventer ses réponses est en réalité un générateur SQL qui a simplement accès aux données.
Un deuxième test consiste à modifier la liste officielle des exclusions, par exemple en retirant enfin les achats des employés des revenus reconnus, puis à vérifier qui met à jour les informations le même jour. Lorsque le tableau de bord change tandis que l’agent ne fait rien, il s’avère que l’API réelle est le fichier compilé manuellement, et l’agent n’est alors qu’un simple utilisateur occasionnel.
Faites également attention à l’agent « utile » qui ajoute discrètement une dimension lorsque la métrique certifiée n’en possède pas. C’est à ce moment-là que le contrat devient invalide. Le comportement correct consiste à indiquer que cette dimension n’est pas présente dans cette métrique. Les chefs de produit n’aiment pas cette formulation, mais c’est toujours mieux que d’écrire une lettre au conseil d’administration qui devra ensuite être retirée.
Ne commencez pas avec le chatbot
La plupart des programmes commencent par présenter les outils visibles : quel modèle, quelle base de données vectorielle, s’il faut utiliser MCP, quels abonnements Copilot acheter. Si l’objectif est d’obtenir des réponses fiables concernant une entreprise en particulier, un point de départ plus direct est préférable.
Où la définition des revenus est-elle établie dans un logiciel de formulaires ? Quelle est la classification des clients considérée comme officielle ? Où se trouve actuellement la logique relative au marge brute : dans une vue SQL, une mesure DAX, une expression Qlik, un carnet de notes, ou dans la mémoire d’une seule personne ? Une réponse du type « plusieurs de ces éléments » signifie que le problème fondamental n’est pas la génération des données. L’interface que le logiciel doit utiliser n’a jamais été conçue.
Une séquence pratique se présente comme suit :
- Identifier le conflit. Choisir une métrique sur laquelle deux équipes sont déjà en désaccord, sans besoin d’une ontologie complexe.
- Rédiger le contrat : formule, niveau de détail, exclusions, responsable ainsi que les dimensions juridiquement valides.
- Fournir ces données via un seul chemin de requête sécurisé que les rapports et les agents puissent utiliser.
- Ajouter un utilisateur, et ce n’est qu’à ce stade qu’on peut mettre en place un copilote ou un agent pour gérer cette métrique.
En l’absence d’un indicateur relatif à l’opération officielle de génération de revenus, le chatbot met en évidence un problème sémantique que personne n’a encore identifié.
Une équipe a dû un jour présenter un copilote de planification avant la réunion suivante du comité de direction ; pendant les deux premières semaines, elle a délibérément mis ce copilote de côté. Les données ont été stockées dans available_to_promise, dont les règles étaient consignées sur une seule page. Les stocks en attente de contrôle qualité ainsi que les cages endommagées ont été exclus. Les quantités destinées à l’emballage ne comptaient que pour les commandes en gros, et les unités en transit n’étaient prises en compte qu’une fois l’ASN reçu. Ces règles ont été intégrées dans le modèle déjà utilisé par le service de entrepôt ; pour les questions relatives aux stocks, le copilote n’était autorisé à consulter que cette métrique et rien d’autre. La première démonstration s’est déroulée dans le calme. Dès la deuxième semaine, plus personne ne mentionnait de troisième chiffre lors des réunions quotidiennes, ce qui constituait une victoire, et le fournisseur du modèle est resté le même.
Les tableaux de bord restent en usage. Une représentation visuelle bien conçue permet de présenter les données hebdomadaires de manière plus efficace qu’une bulle de chat. Ils ne sont tout simplement plus le seul outil utilisé, et le même contexte doit désormais fonctionner aussi bien lorsqu’il est consulté par une personne, un rapport ou un processus automatisé qui ne détectera pas immédiatement une anomalie dans les chiffres.
L’interface qui existe déjà
Les réunions quotidiennes avec deux chiffres officiels expliquent tout cela. Les modèles n’étaient pas confus au sens intéressant du terme ; c’était plutôt l’organisation qui l’était, et les agents ont transposé cette confusion dans des phrases qui semblaient exprimer de la connaissance.
Lorsque le logiciel commence à utiliser une description officielle de la façon dont l’entreprise perçoit ses données, les tableaux cessent d’être l’interface principale, remplacés par des métriques nommées.
Une demande adressée aux agents pour qu’ils fassent attention aux revenus disparaît rapidement. Ce qui persiste, c’est un modèle qui ne permet jamais de reconstituer les revenus de manière ad hoc.
Ce qui sera publié, c’est ce que l’agent choisira. Si l’on expose des tableaux bruts, cela constitue déjà une solution commerciale ; si l’on expose une opération nommée, l’agent pourra finalement sélectionner celle déjà retenue par les analystes.
Ces outils spectaculaires restent attrayants : un copilote qui détecte une anomalie à 6 heures du matin, ou un agent qui ouvre un ticket lorsque le niveau de disponibilité diminue. Ils restent fiables uniquement pour les mêmes opérations que celles déjà convenues par les humains.
Commencez par la métrique qui suscite déjà des débats, et formulez les quatre questions pertinentes à son sujet. Concentrez un tableau de bord et un agent sur cet objet, et laissez le reste inchangé jusqu’à ce que les deux outils s’accordent pendant un mois. Étendez ensuite le catalogue.
Lectures complémentaires
- Qu’est-ce qui fait vraiment fonctionner un réseau neuronal : des compilateurs d’IA en dehors de Python — Suivez un modèle à partir d’une expression Python à travers des graphes de calcul, la fusion d’opérateurs, des IR de type MLIR et sa traduction en code pour CPU, GPU et accélérateurs.
- Recherche sémantique dans PostgreSQL avec pgvector et Node.js, sans besoin de LLM — Créez une recherche basée sur le sens à l’intérieur de PostgreSQL à l’aide de pgvector, des embeddings MiniLM et de Node.js : tokens, chunks, vecteurs, un index IVFFlat, des opérateurs de distance et la manière de lire les scores.