Lundi matin, comité de direction. Le directeur commercial annonce 14,2 M€ de chiffre d’affaires sur le trimestre. Trente secondes plus tard, la directrice financière, qui a tapé une question presque identique dans la même interface de GenBI, affiche 12,8 M€. Personne dans la salle ne sait lequel est juste. La réunion dérape : au lieu de parler du pipe, on passe la demi-heure suivante à se demander d’où sortent ces deux chiffres. Une séance comme celle-là suffit à enterrer la confiance dans un outil de BI générative.
Le coupable n’est ni le modèle de langage ni l’utilisateur. C’est l’absence d’une couche sémantique. Tant qu’elle manque, la GenBI reste une démo bluffante qui ne survit pas au contact d’une décision réelle.
Le « text-to-SQL » sur schéma brut est une fausse bonne idée
L’architecture vue dans la plupart des démos séduit par sa simplicité : on donne au LLM le schéma de la base, l’utilisateur pose sa question, le modèle écrit le SQL, le moteur l’exécute. Sur trois tables propres et une question bien tournée, le temps d’un POC, ça tient. Branchez la même mécanique sur un entrepôt de plusieurs centaines de tables et elle se disloque très vite.
Parce qu’un schéma brut ne contient pas la logique métier. Reprenons nos deux dirigeants. « Chiffre d’affaires » n’a pas de définition unique dans la base. Pour le commercial, c’est le CA signé, avoirs déduits, hors taxes, daté sur la commande. Pour la DAF, c’est le CA reconnu comptablement, daté sur la facture, sur le périmètre des filiales consolidées. Chacune des deux requêtes est juste selon sa propre définition, et leur désaccord est mécanique. Le LLM, lui, n’a aucun moyen de savoir laquelle vous vouliez. Il en choisit une et ne vous le dit pas.
Ajoutez les pièges classiques du SQL généré à la volée :
- Jointures fausses. Le modèle relie deux tables sur une clé qui ressemble à la bonne mais ne l’est pas, et personne ne le voit dans le résultat.
- Double comptage. Une jointure un-à-plusieurs gonfle le total : une commande à trois lignes est comptée trois fois dans la somme du CA.
- Filtres oubliés. Les lignes annulées, les comptes de test, les doublons techniques restent dans le calcul faute de règle explicite.
- Granularité mélangée. Additionner des montants mensuels avec des montants quotidiens donne un nombre qui ne veut rien dire.
Le plus dangereux n’est pas que le LLM se trompe. C’est qu’il rende une réponse fausse avec exactement le même aplomb qu’une réponse juste : bien formatée, prête à coller dans un slide. Au moins, un tableau de bord classique est faux de la même façon pour tout le monde, et l’erreur finit par sauter aux yeux. La GenBI en SQL libre, elle, se trompe autrement à chaque question. Vous ne savez jamais où regarder.
Une couche sémantique, c’est quoi exactement
Une couche sémantique est une définition centralisée, versionnée et partagée de votre logique métier, posée entre l’entrepôt de données et les outils qui l’interrogent. Elle ne stocke pas de données : elle stocke le sens des données. Concrètement, elle déclare :
- Les métriques et leur formule exacte : ce qu’est le « CA net », la « marge brute », le « churn mensuel », avec les filtres, les exclusions et la date de référence.
- Les dimensions par lesquelles on peut découper : région, segment client, gamme produit, période, et la façon de les agréger proprement.
- Les relations entre entités, pour que les jointures soient écrites une fois, correctement, et réutilisées partout.
- Les synonymes métier : « CA », « revenus », « ventes », « turnover » pointent vers la même métrique validée.
Rien de neuf là-dedans : c’est ce que faisait déjà le référentiel sémantique des vieux outils de BI. La GenBI change juste son statut. Hier confort, la couche devient une condition de survie, parce qu’elle est le seul endroit où ancrer un modèle de langage qui, par construction, n’a aucune notion de votre vérité comptable.
Borner l’espace des réponses, pas brider l’utilisateur
Une couche sémantique bien posée rend les résultats déterministes et auditables. La même question donne le même chiffre, aujourd’hui et dans six mois, quel que soit l’utilisateur. Et chaque réponse est traçable jusqu’à sa définition : on peut montrer la métrique appelée, ses filtres, sa formule.
L’objection tombe toujours au même moment : si tout est prédéfini, n’a-t-on pas perdu la liberté de la BI conversationnelle ? C’est l’inverse. L’utilisateur reste libre de croiser les métriques et les dimensions qu’il veut, de filtrer, de comparer deux trimestres. La seule chose qu’on lui retire, c’est la possibilité d’improviser un calcul de CA qui contredira celui du voisin. On borne l’espace des calculs, jamais celui des questions. Toute la valeur tient dans cet écart.
Le vrai rôle du LLM : traduire l’intention, pas inventer le calcul
Avec une couche sémantique en place, le métier du modèle change radicalement. Il ne génère plus de SQL libre sur un schéma brut. Il fait du text-to-metrics : il traduit une phrase en langage naturel en un appel structuré à des métriques et dimensions déjà validées.
« Quel est notre CA net par région ce trimestre, comparé au trimestre dernier ? » devient une requête qui sélectionne la métrique ca_net, la dimension region, le grain trimestriel et une comparaison période à période. Le LLM choisit quoi demander. La couche sémantique décide comment c’est calculé. Le moteur d’entrepôt exécute et renvoie le seul chiffre faisant autorité.
C’est ce partage des rôles qui fait passer un projet de GenBI du gadget à l’outil de décision. Le modèle garde toute sa souplesse linguistique face aux formulations ambiguës, aux fautes de frappe, au jargon maison. Ce qu’on lui retire, c’est le droit d’inventer la logique métier. La surface d’hallucination se réduit alors d’un calcul entier à un simple choix de métrique, et ce choix-là, on sait l’afficher et le corriger.
Les outils qui font ça aujourd’hui
- dbt Semantic Layer / MetricFlow. Vous définissez vos métriques dans dbt, au plus près de la transformation des données, et elles deviennent interrogeables de façon cohérente par tous les outils en aval. Pertinent si votre pipeline est déjà sous dbt.
- Cube. Une couche sémantique indépendante, avec API, cache et contrôle d’accès, conçue pour servir aussi bien des dashboards que des agents et des applications. Souvent le choix quand on veut un point d’entrée unique au-dessus de plusieurs sources.
- LookML (Looker). Le modèle sémantique historique de l’écosystème Looker : métriques et explorations définies en code, gouvernées et réutilisées. Solide si vous êtes déjà dans cet environnement.
Le choix de l’outil compte moins que le principe : une définition unique des indicateurs, en code, versionnée, et un LLM qui s’y branche au lieu d’écrire du SQL dans le vide.
La gouvernance passe par la couche, pas autour
Reste un point qui pèse lourd dans une ETI ou un grand compte. Quand la couche sémantique est le seul chemin vers les données, c’est aussi par elle que passent les droits d’accès. Un commercial interroge son périmètre, pas la masse salariale. Une filiale voit ses chiffres, pas ceux du groupe. Les règles vivent au même endroit que les métriques, et elles tiennent que la question vienne d’un tableau de bord, d’un agent ou d’une API.
Sans elle, la gouvernance se rejoue à chaque outil et à chaque requête générée, avec le risque qu’un SQL un peu malin contourne un filtre de confidentialité. Avec elle, vous n’avez qu’un seul endroit à auditer : qui accède à quelle métrique et sur quel périmètre, et la trace de qui a demandé quoi. C’est cette traçabilité que votre direction des risques finira par réclamer, et c’est elle qui rend la GenBI défendable face à un commissaire aux comptes.
L’ordre des opérations n’est donc pas « branchons un LLM sur l’entrepôt et voyons ce que ça donne ». On formalise d’abord la couche sémantique sur les quelques indicateurs qui comptent vraiment, puis on y connecte le langage naturel. Jamais l’inverse. C’est exactement la démarche que nous outillons dans l’offre GenBI. Pour creuser la méthode et les choix d’architecture, le guide GenBI : Business Intelligence générative entre dans le détail.