GenBI : la Business Intelligence générative sans chiffre faux
Poser une question data en langage naturel et obtenir un chiffre juste, traçable, gouverné. Voici pourquoi « coller un LLM sur la base » échoue, comment une couche sémantique change la donne, et où subsiste le vrai risque même une fois la gouvernance en place.
Définition
GenBI : la Business Intelligence générative, qu’est-ce que c’est exactement ?
La GenBI (Business Intelligence générative) désigne une famille d’outils où l’utilisateur métier pose une question en langage naturel — « quel est le chiffre d’affaires net du trimestre par région ? » — et reçoit une réponse chiffrée accompagnée d’une visualisation. La promesse est séduisante : supprimer le ticket à l’équipe data, raccourcir le délai entre la question et la décision. Mais derrière l’étiquette « GenBI » se cachent deux architectures radicalement opposées, et l’une d’elles est dangereuse en production.
La première consiste à donner à un LLM un accès direct au schéma de la base et à le laisser générer du SQL libre, voire à lui injecter des extraits de tables dans le contexte. C’est l’approche « text-to-SQL naïf ». La seconde — celle que nous défendons — interpose une couche sémantique gouvernée entre la question et l’entrepôt : le LLM ne touche jamais aux données brutes, il traduit l’intention métier vers des métriques définies une fois pour toutes. La différence n’est pas cosmétique : c’est la frontière entre un assistant fiable et un générateur de chiffres faux.
Pourquoi parle-t-on de self-service BI en langage naturel ?
Le but réel de la GenBI n’est pas la magie conversationnelle : c’est l’autonomie des métiers. Dans la plupart des organisations que nous accompagnons, une large part des demandes adressées aux équipes data sont des questions récurrentes et standardisées — un même indicateur, décliné par période, par région ou par produit — qui finissent dans la file d’attente d’analystes surchargés. C’est un ordre de grandeur observé sur nos missions, pas une statistique universelle : selon la maturité de l’organisation, la proportion varie fortement. Le self-service en langage naturel rend ces réponses immédiates — à condition que chaque réponse soit aussi fiable que si un analyste l’avait produite. Sans cette garantie, vous n’avez pas démocratisé la data : vous avez démocratisé l’erreur.
Pourquoi « brancher un LLM sur la base de données » produit des hallucinations ?
Un LLM est un modèle probabiliste de langage : il prédit le token le plus plausible, pas le plus exact. Quand on lui demande de produire un chiffre, il a deux façons de le faire — et toutes deux posent problème en l’absence de garde-fous.
Premier cas : on lui injecte des lignes de données dans le contexte et on lui demande de « faire le calcul ». Le modèle ne possède pas de calculatrice fiable : il agrège mentalement, arrondit, oublie des lignes, additionne mal. Sur une somme de quelques dizaines de valeurs, le taux d’erreur silencieuse est élevé — et personne ne le voit, car la réponse est formulée avec aplomb. C’est l’hallucination de chiffres : un nombre faux présenté comme une vérité.
Second cas : le LLM génère du SQL libre. Là, le calcul est fait par la base (correct par construction), mais le danger remonte d’un cran : le modèle choisit lui-même les tables, les jointures et la définition de la métrique. Or « le chiffre d’affaires » n’a pas de définition universelle : net ou brut ? TTC ou HT ? Remboursements déduits ? Avec ou sans intra-groupe ? Le LLM tranche au hasard du contexte, et chaque question peut donner une définition différente. Vous obtenez des chiffres qui ne se réconcilient pas entre deux conversations.
Anecdote de terrain. Sur une mission, deux directions présentaient en comité un « CA mensuel » issu du même assistant conversationnel branché en text-to-SQL libre : 4,2 M€ pour l’une, 3,9 M€ pour l’autre. Le modèle avait, selon la formulation de la question, tantôt inclus les avoirs, tantôt non. Une demi-journée perdue à réconcilier deux chiffres « exacts » et pourtant incohérents — exactement le genre de scène que la couche sémantique élimine à la racine.
Le text-to-SQL est-il forcément dangereux ?
Non — le text-to-SQL gouverné est au cœur d’une bonne GenBI. Ce qui est dangereux, c’est le text-to-SQL libre, sans contrainte. La nuance : le LLM ne génère pas du SQL contre le schéma physique de la base, il appelle, via du function calling / tool-use, une API de métriques pré-validées. Le SQL final est composé par la couche sémantique, pas par le modèle. On garde la souplesse du langage naturel sans abandonner la rigueur des définitions.
La couche sémantique : la pièce qui rend la GenBI fiable
Une couche sémantique est un référentiel central qui traduit le langage métier en logique data. Elle déclare, une fois pour toutes : voici la métrique « chiffre d’affaires net », voici sa formule SQL exacte, voici les dimensions selon lesquelles on peut la découper (région, produit, période), voici les filtres par défaut. Tous les outils — dashboards classiques comme interface conversationnelle — consomment cette même définition.
Côté outillage, ce n’est pas un concept abstrait : il existe des standards éprouvés. Le dbt Semantic Layer (MetricFlow), Cube, LookML (Looker) ou Malloy permettent de déclarer métriques et dimensions en code versionné, testé en CI/CD. Dans une architecture GenBI gouvernée, le LLM (Claude, Gemini, Mistral ou un modèle hébergé selon le contexte de conformité) interprète la question puis appelle l’API de cette couche en tool-use : il transmet la métrique ciblée, les dimensions et les filtres. La couche compile le SQL correct, l’exécute sur l’entrepôt, et renvoie un résultat chiffré exact. Le LLM n’a fait que de la traduction d’intention. Le calcul appartient à la base ; la définition appartient à la gouvernance.
Métriques définies une fois
« CA net », « marge brute », « churn » : une seule formule, un seul propriétaire, partagée par tous les usages. Fini les chiffres qui divergent d’un service à l’autre.
Traçabilité native
Chaque réponse expose la métrique utilisée, les filtres appliqués et la requête exécutée. On peut auditer d’où vient le nombre, ligne par ligne.
Contrôle d’accès par profil
Le périmètre de données est appliqué au niveau de la couche, par profil et par périmètre. Le langage naturel ne permet jamais de contourner les droits existants.
À quoi ressemble un parcours de bout en bout ?
Un exemple concret vaut mieux qu’un schéma. Prenons une question réelle posée par un directeur commercial.
1. Question (langage naturel) : « Quel est le CA net réalisé en France au T1, par région ? »
2. Mapping par le LLM (tool-use) : métrique ca_net · dimension region · filtre pays = "FR" · période 2026-Q1. Le LLM ne propose que des objets déclarés dans la couche ; toute métrique inconnue est rejetée.
3. SQL compilé par la couche sémantique : SELECT region, SUM(montant_ht) - SUM(avoirs_ht) AS ca_net FROM ventes WHERE pays = 'FR' AND date BETWEEN '2026-01-01' AND '2026-03-31' GROUP BY region; — formule figée une fois, avoirs déduits par définition.
4. Résultat exécuté par l’entrepôt : Île-de-France 1,84 M€ · Auvergne-Rhône-Alpes 0,92 M€ · Hauts-de-France 0,61 M€. Source : métrique ca_net, requête ci-dessus, exécutée à 14:02.
Le chiffre est juste parce que la base l’a calculé, cohérent parce que la définition est unique, et auditable parce que la métrique et la requête sont citées. Le LLM, lui, n’a jamais vu une seule ligne de la table.
La couche sémantique suffit-elle ? L’angle mort à connaître
Soyons honnêtes : la couche sémantique élimine l’hallucination de calcul et de définition, mais pas le risque le plus subtil — celui du mauvais mapping d’intention. Le LLM peut renvoyer un chiffre parfaitement exact… qui répond à côté de la question. Trois cas classiques : il choisit la mauvaise métrique (CA brut au lieu de net), la mauvaise dimension (région de facturation au lieu de région de livraison), ou le mauvais filtre temporel (trimestre calendaire au lieu de trimestre fiscal). La réponse est « vraie » au sens où elle est correctement calculée, mais elle est hors-sujet — et donc trompeuse.
C’est l’angle mort que la plupart des démos passent sous silence. On le traite par deux mécanismes. D’abord le clarifying : quand l’intention est ambiguë, l’assistant ne devine pas, il reformule (« souhaitez-vous le CA net ou brut, sur le trimestre fiscal ? ») avant d’exécuter. Ensuite l’évaluation continue : un jeu de questions de référence, avec la métrique/dimension/filtre attendus, rejoué à chaque évolution du modèle ou de la couche, pour mesurer le taux de mapping correct — pas seulement la justesse du nombre. Présenter la gouvernance comme une solution totale serait malhonnête ; la présenter comme une architecture qui rend le risque mesurable et corrigeable, c’est la réalité opérationnelle.
Et la conformité : où partent les questions, que voit le LLM ?
C’est l’ADN de notre maison sœur Datanaos, et un point trop souvent négligé en GenBI. Bonne nouvelle structurelle : dans une architecture gouvernée, le LLM ne voit jamais les lignes de données. Il manipule des noms de métriques et de dimensions, pas des montants ni des données personnelles — la minimisation est native, ce qui réduit fortement l’exposition au regard du RGPD. Restent deux questions à trancher explicitement : où sont envoyées les questions des utilisateurs (un modèle hébergé en UE ou auto-hébergé sur AWS/Docker peut être requis pour des contextes sensibles) et la traçabilité des usages côté AI Act. La gouvernance des prompts et le suivi des coûts LLM (logs, quotas, plafonds par profil) font partie du trust layer au même titre que les évals : sans eux, une GenBI dérive en silence, en qualité comme en budget.
Comment déployer une GenBI gouvernée, étape par étape ?
Une GenBI fiable ne s’installe pas comme un plugin. C’est une démarche d’industrialisation qui part du socle de données et remonte jusqu’à l’usage métier. Voici la séquence que nous appliquons.
Cartographier les données
Prérequis non négociable : savoir quelles sources existent, leur qualité, leur fraîcheur et leur signification. Sans cartographie, la couche sémantique repose sur du sable.
Définir les métriques
Avec le métier et la data, on fige les définitions des indicateurs clés, leurs formules, leurs dimensions et leurs règles. C’est l’acte de gouvernance central.
Construire la couche sémantique
On implémente ces définitions dans un référentiel versionné (dbt/MetricFlow, Cube, LookML…) branché sur l’entrepôt, avec les périmètres d’accès par profil intégrés dès la conception.
Brancher l’interface conversationnelle
Le LLM est cantonné au tool-use vers les métriques déclarées. Aucun SQL libre, aucun calcul côté modèle. Clarifying si l’intention est ambiguë ; la réponse cite toujours sa source.
Évaluer et mettre en run
Jeu de questions de référence (mapping attendu inclus), suivi du taux de réponses traçables, logs, coûts LLM et conformité. On itère avant d’élargir le périmètre et la population.
Les étapes 1 et 2 sont là où se joue l’essentiel de la réussite — de loin la plus grosse part de l’effort, d’après nos missions. Une organisation qui croit pouvoir sauter la cartographie pour « tester vite » revient systématiquement en arrière. Voir notre guide dédié sur la cartographie des données pour l’IA pour structurer ce socle.
LLM direct sur la base ou GenBI gouvernée : comment trancher ?
| Critère | LLM direct sur la base | GenBI gouvernée (couche sémantique) |
|---|---|---|
| Exactitude des chiffres | Hallucinations possibles | Calcul fait par la base, exact |
| Cohérence des définitions | Variable d’une requête à l’autre | Métrique définie une fois, stable |
| Traçabilité | Quasi nulle | Source et requête auditables |
| Risque de mauvais mapping | Élevé et invisible | Réduit par clarifying + évals |
| Contrôle d’accès | Contournable par prompt | Appliqué par profil et périmètre |
| Adapté à la production | Non — démos uniquement | Oui |
Ces trois indicateurs forment le tableau de bord d’une GenBI en production. Soyons précis sur leur statut : le time-to-insight en minutes est un objectif réaliste une fois la couche sémantique mature — pas une promesse instantanée. La hausse d’adoption est une cible à mesurer, propre à chaque organisation, pas un multiplicateur garanti. Le taux de réponses traçables, lui, est crédible à 100 % comme objectif car la traçabilité est une propriété de l’architecture, pas un espoir : toute réponse non traçable est un risque, pas un service.
Les pièges à éviter sur un projet GenBI
- Laisser le LLM calculer. Tout chiffre produit par le modèle plutôt que par la base est suspect. La règle : traduction oui, calcul jamais.
- Sauter la couche sémantique. Sans définitions partagées, vos chiffres divergent entre conversations et entre services. C’est la première cause de perte de confiance.
- Ignorer le risque de mauvais mapping. Un chiffre exact mais hors-sujet est plus dangereux qu’une erreur visible. Clarifying et évals de mapping sont indispensables.
- Démarrer sans cartographie. Une couche sémantique sur des données mal connues hérite de toutes leurs ambiguïtés. Le socle data passe avant.
- Oublier le contrôle d’accès et la conformité. Si le périmètre n’est pas appliqué dans la couche, le langage naturel devient une porte dérobée — et la question « où partent les prompts ? » doit être tranchée avant la prod.
- Confondre démo et production. Une démo impressionnante sur trois questions ne dit rien de la robustesse sur des centaines de requêtes réelles et concurrentes.
Ces écueils sont les mêmes qui font échouer les POC d’IA en général. Pour le cadre complet du passage à l’échelle, lisez notre checklist sur passer un POC d’IA en production, et pour l’architecture des agents et orchestrations qui alimentent ces flux, notre guide N8N, MCP et agents LLM.
Vous voulez savoir si votre socle data est prêt pour la GenBI ? Notre diagnostic & cadrage — forfait court, prix fixe, sans engagement — identifie les métriques prioritaires et l’effort de cartographie restant. Découvrez aussi notre offre GenBI de bout en bout.
Questions fréquentes sur la GenBI
La GenBI peut-elle vraiment éviter toute hallucination sur les chiffres ?
Oui pour l’hallucination de calcul et de définition, si le LLM ne calcule jamais : dans une GenBI gouvernée, le modèle traduit la question en métriques déclarées et le calcul est exécuté par l’entrepôt. Les chiffres viennent de vos données, pas du modèle, et chaque réponse est traçable. Subsiste un risque de mauvais mapping (réponse exacte mais hors-sujet), couvert par le clarifying et l’évaluation continue.
Qu’est-ce qu’une couche sémantique en BI, concrètement ?
C’est un référentiel central qui déclare une fois pour toutes les métriques (formules), les dimensions et les règles d’accès. Des standards comme dbt Semantic Layer (MetricFlow), Cube, LookML ou Malloy l’implémentent en code versionné. Tous les outils consomment la même définition, ce qui garantit que « chiffre d’affaires » signifie la même chose partout, en dashboard comme en langage naturel.
Le text-to-SQL généré par un LLM est-il fiable ?
Le text-to-SQL libre ne l’est pas : le modèle choisit tables, jointures et définitions au hasard du contexte. Le text-to-SQL gouverné l’est : le LLM cible, via function calling, des métriques pré-validées et c’est la couche sémantique qui compile le SQL exact. On garde le langage naturel sans abandonner la rigueur.
Une réponse peut-elle être exacte mais fausse pour ma question ?
Oui, et c’est le risque le plus subtil : le LLM peut mal mapper l’intention (mauvaise métrique, dimension ou filtre temporel) et renvoyer un chiffre correctement calculé mais hors-sujet. On le traite par le clarifying (l’assistant reformule au lieu de deviner) et par des évals de mapping rejouées à chaque évolution du modèle ou de la couche.
Où partent les questions et qu’en est-il du RGPD / de l’AI Act ?
Dans une architecture gouvernée, le LLM ne voit jamais les lignes de données : il manipule des noms de métriques et de dimensions, ce qui minimise nativement l’exposition de données personnelles. Restent à trancher l’hébergement du modèle (UE ou auto-hébergé AWS/Docker pour les contextes sensibles) et la traçabilité des usages côté AI Act, intégrés au trust layer avec la gouvernance des prompts et des coûts.
Quels KPIs suivre pour piloter une GenBI en production ?
Le time-to-insight (délai question-réponse, objectif en minutes une fois la couche mature), l’adoption (usage réel par les métiers, à mesurer dans la durée), le taux de mapping correct et le taux de réponses traçables jusqu’à la source. Ce dernier est le garde-fou qualité : une réponse non traçable est un risque à traiter.
Passez de l’expérimentation à l’IA en production
Commencez par un diagnostic court à prix fixe : maturité, cas d’usage à fort ROI, et une roadmap priorisée. Sans engagement.