Un vocabulaire, deux publics : pourquoi votre IA et vos tableaux de bord doivent partager une couche sémantique

Le number a trois significations différentes.

Demandez à trois équipes d'une même entreprise les « membres actifs ce trimestre » et vous obtiendrez souvent trois numéros. Le marketing compte toute personne qui a ouvert un e-mail. L'équipe de fidélité compte les membres ayant effectué un achat. Les Finances comptent les membres qui ont racheté de la valeur. Aucun d’eux ne ment. Ils travaillent à partir de différentes définitions, codés dans différents SQL, vivant dans différents outils. La parole est partagée ; le sens ne l'est pas.

Ce problème était acceptable tant que seuls les humains utilisaient ces données. Un analyste expérimenté sait demander de quelle définition il s'agit, et une note de bas de page sur une diapositive suffit à masquer le reste. Mais dès qu'on soumet les mêmes données à un agent d'IA, la note disparaît et l'ambiguïté devient un handicap. Un agent ignore que le terme « actif » est sujet à controverse. Il choisira une définition – ou pire, en inventera une – et présentera le résultat avec la même assurance qu'il présente tout le reste.

Les outils sont des verbes ; la couche sémantique est le vocabulaire

Fournir des outils à un agent, c'est lui donner des verbes : interroger, synthétiser, comparer, prévoir. Le protocole de contexte de modèle d'Anthropic formalise cela : un outil est une capacité typée et nommée que le modèle peut invoquer. Cette formulation est correcte et utile. Cependant, un verbe sans vocabulaire partagé ouvre la porte à l'improvisation. « Indiquez-moi le chiffre d'affaires » n'est sûr que si le terme « chiffre d'affaires » correspond à une définition certifiée, celle-là même qu'un utilisateur voit sur un tableau de bord, calculée de la même manière à chaque fois.

Voici l'argument principal : la couche sémantique des métriques certifiées constitue le vocabulaire partagé qui garantit la cohérence des verbes de l'agent. Les outils permettent à l'agent d'agir. La couche sémantique définit la signification autorisée de ces actions. Séparer les deux revient à obtenir un agent capable d'exécuter des requêtes, mais incapable de les interpréter correctement. Les unifier permet à l'agent d'hériter automatiquement de toutes les définitions sur lesquelles vos analystes ont déjà élaboré des consensus.

La règle qui en découle est simple à énoncer et difficile à contourner : un vocabulaire unique, deux publics. Les utilisateurs y accèdent via des tableaux de bord et des questions ponctuelles. Les agents y accèdent via des outils MCP et des copilotes. Tous deux utilisent la même couche certifiée ; ainsi, une requête number a la même signification, qu’elle soit posée par un humain ou un agent.

Les problèmes liés à l'absence de couche partagée

Sautez la couche sémantique et trois échecs arrivent ensemble. Premièrement, l’IA hallucine les chiffres – non pas parce que le modèle est défectueux, mais parce que vous lui avez demandé de raisonner sur des tableaux bruts sans définition canonique de quoi que ce soit, elle comble donc le vide avec une supposition plausible. Deuxièmement, les définitions des KPI dérivent : chaque équipe, outil et notebook réimplémente le « churn » ou « AOV » de manière légèrement différente, et la divergence s'accroît silencieusement. Troisièmement, les « analyses en libre-service » produisent des chiffres contradictoires, et l'organisation cesse discrètement de leur faire confiance à tous.

L'étude de Deloitte intitulée « État de l'IA en entreprise » a systématiquement démontré que la confiance et la gouvernance, et non les capacités brutes du modèle, constituent les principaux freins au déploiement de l'IA en production. Ce constat s'applique directement à la problématique de l'analyse de données. Le véritable obstacle réside rarement dans la capacité du modèle à écrire des requêtes SQL. Il s'agit plutôt de savoir si l'on peut faire suffisamment confiance à la réponse pour agir en conséquence, et si l'on peut expliquer ultérieurement l'origine de la valeur number.

Définitions certifiées et leur historique des versions

Une métrique certifiée est une définition qu'un responsable a examinée et validée comme source unique de vérité. Un « membre actif » ne correspond pas au résultat de la requête en cours ; il s'agit d'un object nommé et géré, doté d'une logique explicite, d'un responsable et d'un statut. En cas de désaccord entre le marketing, la fidélisation et la finance, les discussions ne se limitent plus aux requêtes SQL. Elles se concentrent sur la définition, une seule fois, publiquement. Une fois certifiée, la réponse est partagée par tous, humains et agents.

Le versionnage garantit la pérennité des données. Les définitions évoluent : un calendrier fiscal change, un segment est affiné, une source de données est corrigée. Sans versionnage, une redéfinition efface l'historique et le tableau de bord du trimestre précédent (number) n'est plus reproduit. Avec le versionnage, chaque indicateur conserve son historique, ce qui permet de répondre à la question que se posent réellement les auditeurs et les directeurs financiers : non pas seulement « quelle est la number », mais « quelle était la number, selon quelle définition, à la date de son reporting ? »

Un seul point d'entrée pour les requêtes, avec une limitation de portée par locataire appliquée en dehors de celui-ci.

La fiabilité des définitions dépend de la méthode d'exécution. Dans notre architecture, chaque indicateur, qu'il soit demandé par un tableau de bord ou un outil agent, est traité par un point d'entrée de requête unique. L'IA ne dispose d'aucun autre chemin, moins rigoureux. Le copilote et le graphique à l'écran exécutent la même logique certifiée, ce qui explique mécaniquement l'incohérence de leurs résultats.

L’isolation des locataires est appliquée en dehors de la requête, et non à l’intérieur. L’appelant ne fournit jamais, et ne peut influencer, les données du locataire qu’il consulte. La limitation de portée est appliquée par la couche d'exécution à partir du contexte authentifié. Ceci est crucial pour les agents, qui composent les entrées d'une manière non prévue par le script. Si l'isolation résidait au sein d'une requête string construite par le modèle, une invite malencontreuse pourrait la perturber. La limitation de portée étant externe à la requête, aucune invite, qu'elle soit malveillante ou accidentelle, ne peut franchir la limite d'un locataire. Il en résulte des réponses reproductibles, isolées au niveau du locataire et auditables par construction.

Vues en lecture seule basées sur les autorisations : une sécurité que le modèle ne peut contourner

Le modèle le plus dangereux en IA d'entreprise actuellement consiste à intégrer un chatbot directement à des tables de données brutes. La démonstration est impressionnante, mais les défaillances sont précisément celles que vous ne pouvez pas vous permettre. Avec un accès aux tables, un agent peut joindre des données qui n'étaient pas censées l'être, faire apparaître des colonnes qui n'auraient jamais dû quitter le système source et calculer une métrique de trois manières apparemment valides, mais qui divergent toutes. Vous faites confiance à un système probabiliste pour respecter des limites qui n'existent que par convention.

L'alternative consiste à imposer la limite au niveau de la base de données, sous le modèle. Nous exposons la couche certifiée via des vues en lecture seule, soumises à autorisation. Les identifiants de l'IA lui permettent de lire ces vues autorisées et rien d'autre : ni tables brutes, ni chemins d'écriture, ni colonnes en dehors de la surface certifiée. Le modèle n'est jamais tenté de franchir une limite, car celle-ci est une autorisation d'accès à la base de données, et non un paragraphe d'instructions dans une invite système. C'est précisément le type de contrôle technique explicite que préconisent des cadres comme le NIST AI RMF 1.0 : gouverner et cartographier les flux d'accès et de données réels de votre système d'IA plutôt que de faire confiance au modèle.

Connecter les agents à cette interface relève d’une simple configuration, et non d’une reconstruction. La même couche certifiée qui alimente les tableaux de bord humains est accessible aux agents via les outils MCP et SoCode. Ainsi, l’agent raisonne à partir de métriques certifiées et jamais à partir de tableaux bruts. L’IA ne peut pas inventer de chiffre, car elle n’en produit pas : elle interroge la couche, qui lui renvoie la valeur certifiée number.

Pourquoi une couche partagée sécurise la création sans code

Le libre-service ressemble à un risque de gouvernance : donnez aux utilisateurs professionnels un générateur de métriques et ils créeront sûrement les mêmes définitions contradictoires par d'autres moyens. L’inverse est vrai, à condition que le constructeur se situe au-dessus de la couche certifiée. La création de métriques structurées et sans code permet aux utilisateurs de composer de nouvelles métriques sur les vues sécurisées de la liste blanche (en choisissant des dimensions, des filtres et des agrégations certifiés) sans écrire de SQL brut et sans jamais toucher à une table de base.

Puisque chaque indicateur créé est construit à partir de composants déjà réglementés, les propriétés de sécurité sont héritées plutôt que remises en question. Un nouvel indicateur est adapté au locataire, reproductible et auditable pour la même raison que les indicateurs certifiés : il emprunte le même point d’entrée, utilise les mêmes vues et bénéficie des mêmes autorisations. La gouvernance cesse d’être un obstacle et devient un socle permettant à un plus grand nombre de personnes de créer en toute sécurité. C’est la seule version du libre-service qui permette une mise à l’échelle sans fragmenter à nouveau vos définitions.

Ce qu'un CDO doit réellement mettre en place

Si vous êtes CDO et que vous développez une couche d'analyse IA, résistez à la tentation de commencer par le chatbot. Le chatbot représente les 20 % les plus faciles, mais aussi les plus dangereux. Commencez par le vocabulaire. Certifiez vos indicateurs clés : définissez-les, désignez des responsables et gérez leurs versions. Placez-les derrière un point d'entrée de requête unique qui impose une limitation du périmètre d'accès par locataire. Exposez-les via des vues en lecture seule avec autorisations. Connectez ensuite les agents à cette interface contrôlée, via des outils de type MCP. En procédant ainsi, l'IA est fiable dès le premier jour, car elle n'a aucun élément susceptible de la faire dévier de son objectif.

Il ne s'agit pas d'un exercice théorique. Les marques qui bouclent la boucle de fidélisation grâce à l'IA sont celles dont les agents et les tableaux de bord parlent déjà le même langage : McDonald's China, en collaboration avec SocialHub.AI, a augmenté la part du GMV des membres de 5 % à 85 %. Les résultats à cette échelle ne sont crédibles que lorsque les chiffres en dessous sont certifiés, reproductibles et identiques pour l'humain qui examine le tableau de bord et l'agent qui y agit.

En résumé : les outils sont les verbes, la couche sémantique est le vocabulaire, et il vous faut un vocabulaire unique pour deux publics afin qu'un number ait la même signification, qu'il soit posé par une personne ou un agent. Si vous mettez en place une couche d'analyse IA et souhaitez découvrir à quoi ressemblent des indicateurs certifiés, isolés par locataire et auditables, alimentant à la fois un tableau de bord et un agent à partir d'une source unique de vérité, réservez une démonstration et nous accompagnerons votre équipe en fonction de vos propres définitions.