Brancher un LLM sur votre BI : la fausse bonne idée qui peut coûter très cher

On voit fleurir partout la même promesse : "Demain, vous poserez vos questions en langage naturel à votre BI, et l'IA vous donnera la réponse."

Dans les comités de direction, l’idée séduit. Dans les directions data, elle intrigue. Dans les équipes métiers, elle fascine. Et c’est précisément pour cela qu’elle est dangereuse.

Car une BI n’est pas un chatbot. Une BI, c’est un instrument de pilotage. Et un instrument de pilotage ne peut pas tolérer un risque structurel : l’hallucination.

L’hallucination : un défaut “normal” en génération… catastrophique en décision

Les grands modèles de langage (LLM) ne “savent” pas. Ils génèrent du texte plausible. Résultat : ils peuvent produire des réponses confiantes, cohérentes… et fausses. NIST, dans son profil de gestion des risques pour l’IA générative, appelle cela la “confabulation” (souvent désignée comme hallucination) et le classe explicitement comme un risque à traiter.

Ce sujet n’est pas théorique : cabinets, chercheurs et acteurs industriels constatent que ces erreurs sont d’autant plus insidieuses qu’elles s’insèrent dans un discours “qui sonne juste”. La presse économique souligne aussi que les hallucinations ne disparaissent pas par magie et que l’enjeu devient : comment réduire, détecter, encadrer.

Or, une hallucination dans un texte marketing est un incident.
Une hallucination dans un axe décisionnel (marge, cash, churn, risques, conformité, prévision) peut devenir un désastre.

Le piège n°1 : la “narrative” de BI… plus persuasive que vraie

Les outils de BI ont déjà franchi une étape : ils ne se contentent plus d’afficher des graphes, ils produisent des récits (“voici pourquoi la performance baisse”, “voici les leviers à activer”). Ajoutez un LLM, et vous obtenez une machine à fabriquer des explications.

C’est là que le risque explose : une BI outillée par un LLM peut produire une analyse fausse mais crédible, et déclencher un phénomène connu en gestion du risque : l’automation bias (la tendance humaine à sur-faire confiance à une sortie automatisée). C’est exactement le type de dérive que les cadres de gestion des risques (NIST AI RMF) demandent d’anticiper via gouvernance, traçabilité et contrôles.

Le piège n°2 : le “text-to-SQL” qui invente un JOIN… et vous invente un monde

L’un des usages les plus “hypes” consiste à laisser le LLM traduire une question métier en SQL, exécuter la requête, puis résumer le résultat.

Sauf que dans la vraie vie :

un JOIN oublié, une granularité mal gérée, une date mal filtrée, et la vérité statistique s’effondre ;

le LLM peut produire une requête syntaxiquement correcte mais sémantiquement fausse (le pire cas).

Des travaux récents sur l’évaluation de SQL généré par des LLM dans des contextes BI parlent explicitement de “semantic hallucinations” et d’erreurs structurelles qui limitent l’usage en production.

Le piège n°3 : la sécurité — quand la BI devient une surface d’attaque

Brancher un LLM sur un système décisionnel, ce n’est pas seulement une question d’exactitude : c’est aussi une question d’attaque.

Deux points sont souvent sous-estimés :

Prompt injection : des acteurs de la cybersécurité alertent sur le fait que ces attaques pourraient ne jamais être totalement “corrigées” car elles touchent à la façon même dont les LLM interprètent données et instructions.

Improper output handling : OWASP documente des scénarios où des sorties de LLM (SQL, commandes, chemins de fichiers) deviennent dangereuses si elles sont exécutées ou consommées sans garde-fous.

Dit autrement : si votre LLM peut générer des requêtes, il peut aussi — volontairement ou non — générer des requêtes qui exposent des données, contournent des contrôles, ou dégradent l’intégrité.

“Mais on va mettre du RAG et des guardrails” : oui… et non

Oui, il existe des techniques de réduction du risque : grounding, RAG, vérification, évaluation, double-modèles, etc. Les acteurs du marché et de la recherche convergent sur ces approches.

Mais il faut dire la vérité simplement :
ces techniques diminuent le risque — elles ne le suppriment pas.

Et une direction générale ne signe pas un pilotage financier ou industriel sur “on a diminué le risque”.

C’est exactement l’esprit du travail de NIST : gérer les risques spécifiques de l’IA générative, pas les nier.

Ce qu’il faut faire à la place : séparer “interface” et “moteur de vérité”

Le bon modèle, en entreprise, c’est celui-ci :

Le moteur de vérité reste déterministe et auditable : couche métrique, définitions de KPI, règles de gestion, modèles statistiques testés, contrôles de cohérence, pistes d’audit.

Le LLM devient une interface, pas un arbitre : il aide à formuler une question, à retrouver un rapport, à expliquer une visualisation à partir de chiffres certifiés, mais ne fabrique pas la donnée, ne “déduit” pas la causalité, ne change pas les définitions.

En clair : on garde le LLM dans le cockpit, mais pas sur les commandes de vol.

Pourquoi j’insiste : parce que l’expérience “IA” ne date pas de 2023

Je prends volontairement une position à contre-courant, parce que je vois se reproduire un schéma classique : la technologie est excitante, donc on l’installe partout — puis on découvre les externalités.

Or, l’IA appliquée au business ne commence pas avec ChatGPT. 

La question à poser en comité de direction

Avant de “brancher un LLM sur la BI”, posez une seule question, très simple :

“Sommes-nous capables d’auditer, reproduire et prouver chaque réponse ?”

Si la réponse est non, alors vous ne déployez pas un assistant : vous déployez un générateur d’incertitude dans le cœur décisionnel de l’entreprise.

Les LLM sont formidables pour accélérer la recherche, la rédaction, la synthèse, l’accessibilité.
Mais en BI et en décision, la règle devrait être la même qu’en aviation : l’élégance ne remplace pas l’instrumentation.