Couche sémantique : pourquoi votre IA ne trouve pas le même chiffre d’affaires que vous

« Combien de clients actifs avons-nous ? » L’assistant branché sur la base de données répond en quatre secondes, avec un chiffre net et une phrase bien tournée. La direction commerciale en a un autre, le service financier un troisième. Personne n’a fait d’erreur de calcul : chacun compte autre chose sous le même mot. C’est le problème que règle une couche sémantique, et c’est celui qu’on découvre juste après avoir réussi à alimenter une IA avec ses données. Le branchement fonctionne, les tables sont lisibles, et les réponses restent fausses de façon parfaitement plausible.

Le modèle lit des colonnes, pas vos conventions

Une base de gestion contient des factures, des avoirs, des commandes, des contrats. Elle ne contient nulle part la phrase « un client actif, chez nous, c’est un client qui a passé commande dans les douze derniers mois, filiales regroupées ». Cette règle vit dans la tête de l’administration des ventes, dans une formule de tableur, parfois dans un rapport que plus personne n’ose modifier. Quand on demande à une IA d’interroger les tables, elle écrit elle-même la requête : c’est ce qu’on appelle le text-to-SQL. Il lui faut bien choisir une définition. Elle prend la plus vraisemblable au vu des noms de colonnes, et elle ne dit pas qu’elle a choisi.

C’est ce dernier point qui coûte cher. Un chiffre manifestement faux se repère. Un chiffre vraisemblable, présenté avec assurance, part dans une présentation au comité de direction. Les ingénieurs de dbt Labs, l’éditeur d’un outil de modélisation de données très répandu, le résument d’une formule dans leur banc d’essai publié en avril 2026 : avec le text-to-SQL, l’échec prend la forme d’une réponse plausible mais incorrecte ; avec une couche sémantique, il prend la forme d’un message d’erreur.

Une couche sémantique, c’est le dictionnaire qui s’intercale entre les tables et ceux qui les interrogent, humains ou machines. Chaque notion de gestion y a un nom, une définition écrite, une formule de calcul et un propriétaire. L’IA n’invente plus la règle : elle va la chercher.

Avec ou sans couche sémantique : ce que disent les mesures

Le test de référence date de 2023. Trois chercheurs de data.world ont posé 43 questions de gestion à GPT-4 sur la base d’un assureur fictif, 199 tables, des questions allant du simple listing aux indicateurs de pilotage. En interrogeant directement les tables, le modèle donnait la bonne réponse dans 16,7 % des cas. Avec une représentation enrichie de cette base, qui décrivait les notions métier et leurs liens avec les tables, la justesse montait à 54,2 %. Sur les questions qui obligent à croiser beaucoup de tables, le score en interrogation directe tombait à zéro (rapport technique sur arXiv).

Bonnes réponses aux mêmes questions de gestion, avec et sans définitions métier

16,7 %

GPT-4 sur les tables brutes (2023)

54,2 %

GPT-4 avec les notions métier décrites (2023)

90 %

Claude Sonnet 4.6, requêtes écrites par l’IA (2026)

98,2 %

Même modèle via la couche sémantique (2026)

Les modèles ont progressé depuis, et dbt a rejoué en 2026 onze questions tirées de ce jeu d’essai, vingt fois chacune. Après l’ajout de trois tables préparées, Claude Sonnet 4.6 passe de 90 % de bonnes réponses en écrivant ses requêtes à 98,2 % en passant par la couche sémantique ; GPT-5.3-Codex, de 84,1 % à 100 %. L’écart se resserre, il ne disparaît pas. Et la différence qui compte tient moins au score qu’à la façon d’échouer : quand la question sort de ce que la couche sémantique sait calculer, elle refuse de répondre au lieu d’improviser.

Deux réserves s’imposent. Ces bancs d’essai sont petits et portent sur un seul secteur. Et leurs auteurs vendent ce qu’ils mesurent : data.world commercialise des graphes de connaissances, dbt une couche sémantique. Les ordres de grandeur restent parlants, la précision des décimales beaucoup moins.

Les éditeurs convergent vers les mêmes trois gestes

Snowflake vient d’annoncer pour sa plateforme un module baptisé Business Ontology, présenté le 3 novembre. Le principe : définir, attribuer et faire approuver les termes métier partagés, puis relier chaque définition aux tables et aux vues qui la calculent. Seules les définitions approuvées sont servies aux agents IA. L’exemple choisi par l’éditeur est justement le chiffre d’affaires net, défini une fois pour la finance, avec un responsable et une validation. La préversion publique est annoncée « bientôt », sans date.

Chez Microsoft, Power BI propose en préversion une fonction de préparation des données pour l’IA : des instructions qui expliquent à Copilot le vocabulaire de l’entreprise, des réponses vérifiées associées à des formulations types, un modèle de données marqué « approuvé pour Copilot », et un panneau qui montre sur quoi Copilot s’est appuyé pour répondre. Microsoft prend soin de préciser que ces réglages ne garantissent pas la même réponse à chaque fois.

Trois éditeurs, trois architectures, et une liste de gestes commune : écrire la définition, désigner qui la tient, rendre visible le calcul. Aucun de ces outils n’écrit les définitions à la place de l’entreprise. C’est le travail qui reste, et il commence bien avant le choix d’un logiciel.

Trois mots à définir avant de brancher quoi que ce soit

Inutile de cartographier toute l’entreprise. Trois notions suffisent à démarrer, parce qu’elles reviennent dans presque toutes les questions posées à un assistant de pilotage, et parce que chaque service les compte à sa façon.

Le client actif d’abord. Les commerciaux comptent souvent ceux qui ont commandé récemment, la finance ceux qui ont un contrat en cours, le support ceux qui ont ouvert un ticket. La définition doit trancher la période, l’événement qui compte et le sort des groupes à plusieurs entités.

Le chiffre d’affaires net ensuite. Facturé ou commandé, avant ou après avoirs, remises de fin d’année comprises ou non, rattaché à la date de facture ou à la date de livraison : quatre choix, et autant d’écarts possibles avec le chiffre de la comptabilité. Le dilemme se retrouve dans toute prévision des ventes confiée à l’IA : un modèle entraîné sur les commandes ne prévoit pas ce que prévoit un modèle entraîné sur les factures.

L’affaire gagnée enfin. Le jour de la signature, de la réception du bon de commande ou de la première facture ? Et que devient une affaire gagnée puis annulée ? Tant que le CRM et la comptabilité ne répondent pas pareil, le taux de transformation calculé par l’IA ne vaudra rien.

Pour chacune, une ligne écrite suffit : la règle en une phrase, la formule, les exclusions, et un nom. Ce responsable n’a pas besoin d’être technicien. C’est la personne qui tranche quand deux services ne sont pas d’accord, et qui valide toute modification.

Une réponse sans son calcul n’est pas une réponse

Le dictionnaire ne sert à rien si l’assistant ne s’en sert pas, ou s’en sert sans le dire. La règle à imposer tient en deux phrases. Chaque chiffre donné par l’IA cite la définition utilisée et la période retenue. Et quand la question porte sur une notion absente du dictionnaire, l’assistant le signale au lieu d’en fabriquer une.

Cette règle se met en place avec ce que l’on a déjà. Dans un assistant généraliste, les définitions vont dans les instructions permanentes, avec la consigne de les citer. Dans Power BI, dans les instructions pour l’IA et les réponses vérifiées. Dans une pile de données plus outillée, dans les métriques d’une couche sémantique dédiée. Le support change, pas le principe, déjà au cœur de notre article sur l’agent qui vaut ce que vaut son contexte : ce que l’IA ne sait pas de l’entreprise, elle le devine.

Le test de départ ne demande ni projet ni budget. Posez à votre assistant les trois questions (combien de clients actifs, quel chiffre d’affaires net le trimestre dernier, combien d’affaires gagnées), puis posez-les aux trois services concernés. Si les six réponses concordent, vous êtes en avance. Si elles divergent, vous savez par quels mots commencer.