Interroger vos données en langage naturel : quel modèle IA pour une BI fiable (text-to-SQL)

La démonstration est toujours convaincante. Quelqu'un tape « quel est mon chiffre d'affaires par région ce trimestre ? », l'outil produit une requête SQL, un graphique apparaît. En dix secondes, on a l'impression que le reporting vient de se résoudre tout seul.

Puis on branche la chose sur la vraie base — celle avec trois cents tables, des colonnes nommées FLG_ACT_CLT, deux définitions concurrentes du mot « client » et une règle non écrite qui exclut les avoirs du chiffre d'affaires. Et le taux de réussite s'effondre.

Cet article ne discute pas de l'intérêt de la BI conversationnelle : il traite la seule question qui décide du succès ou de l'échec, quel modèle choisir, à quel coût, et pourquoi ce choix compte moins que vous ne le pensez. Tous les chiffres qui suivent sont datés et sourcés.

Le chiffre qui devrait décider à votre place

Il existe deux générations de tests pour le text-to-SQL, et l'écart entre elles raconte toute l'histoire.

Spider 1.0, le benchmark académique historique, utilise des bases propres et de taille modeste. Les modèles y sont excellents. Spider 2.0 utilise des environnements d'entreprise réels : plus de 3 000 colonnes, plusieurs dialectes SQL (BigQuery, Snowflake), des transformations en chaîne.

Le même modèle, testé sur les deux :

Source : Spider 2.0, consulté le 2 septembre 2026.

Ce n'est pas une dégradation, c'est un changement de nature du problème. Un modèle qui répond juste huit fois sur dix sur une base d'exercice se trompe neuf fois sur dix sur la vôtre. Tout écosystème d'outils qui vous montre une démo sur une base jouet vous montre le premier chiffre.

En bref — à jour au 2 septembre 2026. Le meilleur rapport fiabilité/prix aujourd'hui : Claude Sonnet 5 (2 / 10 $ par million de tokens), qui domine les classements publics à modèle brut et coûte quatre fois moins qu'Opus 5. Budget contraint, questions simples : Gemini 3.6 Flash (0,75 / 3,75 $) ou Claude Haiku 4.5 — à condition d'accepter un taux d'erreur plus élevé et une validation humaine. Exigence maximale sur bases complexes : Claude Opus 5 ou GPT-5.6 Sol, mais l'écart de fiabilité ne justifie leur surcoût que sur des schémas vraiment tordus. Le facteur qui pèse le plus lourd n'est aucun de ces modèles : c'est la couche sémantique que vous mettez entre la question et la base. Elle vaut plus de points que n'importe quel changement de modèle.

Ce que « text-to-SQL » veut dire dans votre entreprise

Concrètement : un dirigeant, un commercial ou un contrôleur de gestion pose une question en français, le système la traduit en requête SQL, l'exécute sur votre base et renvoie le résultat. Plus de ticket au service informatique, plus d'attente de trois jours pour un export.

C'est un cousin du RAG, mais sur données structurées — et les deux ne se ressemblent pas techniquement. Si votre besoin porte sur des documents, contrats ou comptes rendus, c'est l'autre problème que nous avons traité dans notre article sur l'assistant IA interne branché sur vos documents d'entreprise. Pour le cadre général de la démarche, notre guide d'intégration de l'IA en entreprise pour dirigeants pose les étapes.

Un mot sur la maturité : Gartner prévoit que 40 % des entreprises auront adopté l'analytique augmentée par l'IA d'ici fin 2026, tout en classant la requête en langage naturel parmi les technologies approchant le pic des attentes exagérées. Les deux sont vrais : le cas d'usage est réel, la promesse « plus jamais de tableau de bord » ne l'est pas.

Ce que valent les modèles seuls

Voici le tableau le plus utile qui existe publiquement : le même harnais d'exécution (Spider-Agent), plusieurs modèles. Les écarts viennent donc bien du modèle, pas de l'outillage autour.

Source : leaderboards Spider 2.0, consultés le 2 septembre 2026.

Deux enseignements, et une réserve importante.

Les écarts sont massifs : un facteur 3 entre le premier et le dernier, sur un test identique. Choisir un modèle bon marché n'est pas ici un arbitrage neutre — c'est accepter que deux réponses sur trois soient fausses au lieu d'une sur deux. La famille Claude domine ces classements, ce qui est cohérent avec la proximité entre génération de SQL et génération de code, où les mêmes modèles mènent — nous l'avons détaillé dans notre comparatif des modèles pour générer du code.

La réserve : ces lignes utilisent des modèles de génération précédente, les leaderboards n'ayant pas été rejoués avec les modèles de 2026. Le classement relatif reste informatif ; les valeurs absolues sont un plancher, pas l'état de l'art.

Vous voulez savoir si votre base est exploitable en langage naturel ? Nous auditons votre schéma, vos définitions métier et vos volumes, et vous repartez avec une réponse chiffrée — faisable, à quelles conditions, à quel coût. Réserver votre diagnostic text-to-SQL, 30 minutes, offert.

Pourquoi le modèle n'est pas le facteur décisif

Voici l'information qui devrait changer votre budget.

Sur ce même benchmark Spider 2.0, les systèmes qui figurent en tête ne sont pas des modèles : ce sont des architectures complètes, qui ajoutent au modèle une couche sémantique, une exploration de schéma et une boucle de vérification.

Source : Spider 2.0, consulté le 2 septembre 2026. Les entrées de tête sont des soumissions d'éditeurs, non reproduites indépendamment — à lire comme un ordre de grandeur, pas comme une garantie.

L'écart va d'un facteur 2 à un facteur 4. Aucun changement de modèle ne produit un gain comparable.

Et ce n'est pas une thèse d'agence : les éditeurs le disent eux-mêmes dans leur propre documentation.

Snowflake, à propos de Cortex Analyst : « Les solutions d'IA génériques peinent sur la conversion text-to-SQL lorsqu'on ne leur donne que le schéma de la base, car les schémas manquent de connaissances critiques comme les définitions de processus métier et le traitement des indicateurs. » (docs.snowflake.com)

Microsoft, à propos de Copilot dans Power BI : « Sans préparation, Copilot peut mal interpréter vos données et renvoyer des résultats génériques ou inexacts. » (learn.microsoft.com, mis à jour le 24 août 2026)

Traduction opérationnelle : la fiabilité vient de ce qu'on écrit noir sur blanc que « chiffre d'affaires » signifie hors taxes, avoirs déduits, hors intragroupe, que FLG_ACT_CLT = 1 désigne un client actif, et que l'exercice démarre en avril. Ce travail n'est pas de l'IA : c'est de la modélisation métier, et c'est lui qui détermine le résultat.

Les classements eux-mêmes sont fragiles

Un troisième élément doit tempérer la lecture de tout ce qui précède, y compris de nos propres tableaux.

Une équipe de l'université de l'Illinois a audité les deux benchmarks de référence du domaine. Résultat : 52,8 % des problèmes de BIRD Mini-Dev et 66,1 % de ceux de Spider 2.0-Snow contiennent des erreurs d'annotation — requête de référence incorrecte, question ambiguë, connaissance métier mal renseignée.

En rejouant cinq systèmes de tête sur la version corrigée, les auteurs observent des variations de performance de −3 % à +31 % en relatif, et des changements de classement allant jusqu'à trois places : CHESS passe de 62 % à 81 % et grimpe de la quatrième à la première place, tandis qu'OpenSearch-SQL recule de la première à la troisième.

Source : Jin, Choi, Zhu, Kang (University of Illinois), « Text-to-SQL Benchmarks are Broken: An In-Depth Analysis of Annotation Errors », CIDR 2026.

La conséquence pratique est simple, et elle vaut plus que tous les classements : ne choisissez pas votre modèle sur un leaderboard. Constituez trente questions réelles de votre entreprise, avec leurs bonnes réponses validées par vos équipes, et mesurez les candidats dessus. C'est une demi-journée de travail, et c'est la seule mesure qui vous concerne.

À titre de repère, la performance humaine sur le benchmark BIRD est estimée à 92,96 %, quand les meilleurs systèmes publiés plafonnent autour de 80-82 %. L'écart restant n'est pas comblé.

Ce que ça coûte à votre volume

Prenons une PME qui déploie l'outil auprès de 15 utilisateurs, à raison de 10 questions par jour chacun : environ 3 300 questions par mois. Chaque question envoie au modèle le schéma, les définitions métier et quelques exemples — comptons 12 000 tokens d'entrée — et produit 800 tokens de sortie (la requête et son explication).

Prix par million de tokens, relevés le 2 septembre 2026 sur les grilles officielles Anthropic, OpenAI et Google. Conversion au taux de référence BCE du 1er septembre 2026 (1 EUR = 1,1590 USD).

Trois remarques sur ces chiffres.

La mise en cache change tout sur ce cas d'usage précis. Le schéma et les définitions métier sont identiques d'une question à l'autre : c'est le scénario idéal pour le cache, facturé un dixième du prix d'entrée. Claude Sonnet 5 passe ainsi de 91 € à 42 € par mois. C'est le levier le plus rentable du tableau, et il est purement technique.

Deux tarifs ont bougé depuis notre relevé d'août. Claude Sonnet 5 devait passer à 3 / 15 $ le 1er septembre : Anthropic a annulé cette hausse, le tarif de lancement 2 / 10 $ devient le prix standard. Et GPT-5.6 Sol est descendu à 4 / 20 $, en tarif promotionnel jusqu'au 21 novembre 2026. Nous tenons la table complète à jour, tous fournisseurs confondus, sur notre page de référence Prix des modèles IA.

Attention au seuil de contexte long. Chez Google, un prompt qui dépasse 200 000 tokens fait basculer Gemini 3.1 Pro de 2 / 12 $ à 4 / 18 $ — sur la totalité de l'appel. Si vous injectez un schéma volumineux à chaque question, vous pouvez doubler la facture sans changer de modèle.

Les plateformes packagées : ce que vous achetez vraiment

Beaucoup de PME n'intégreront pas une API : elles activeront la fonction déjà présente dans leur outil. Ce qui se paie alors n'est pas le modèle.

Power BI Copilot exige une capacité Microsoft Fabric payante (F2 minimum) ou Power BI Premium P1 : « Une licence Power BI Pro ou Premium Per User seule ne suffit pas — Copilot requiert une capacité organisationnelle. » Vous n'achetez pas un abonnement par utilisateur, mais une capacité de calcul mutualisée facturée à l'heure.

Snowflake Cortex Analyst est facturé aux messages traités, en crédits — et l'exécution de la requête produite est facturée séparément sur votre entrepôt. Deux lignes sur la facture, pas une.

Databricks Genie est inclus dans la consommation AI/BI : pas de coût par question, mais vous payez l'entrepôt SQL, temps d'inactivité compris.

Même logique dans les trois cas : le coût réel est celui du calcul et de la préparation du modèle sémantique, pas de l'inférence.

Le coût du modèle n'est pas votre budget. Entre 16 € et 228 € par mois pour 3 300 questions, le moteur ne pèse rien à côté d'une journée d'analyste. Ce qui coûte — et ce qui décide de la réussite — c'est la couche sémantique : documenter vos définitions métier, arbitrer les concepts concurrents, cadrer les droits d'accès pour qu'un commercial ne lise pas la masse salariale, et construire le jeu de questions de contrôle qui prouve que le système répond juste. C'est ce travail que nous chiffrons, au tarif d'une prestation d'ingénierie — pas d'un abonnement.

Quand il ne faut pas faire de text-to-SQL

Le conseil le plus utile que nous puissions donner sur ce sujet est parfois de ne pas le faire.

Si vos questions sont toujours les mêmes, cinq tableaux de bord bien faits coûtent moins cher, répondent instantanément et ne se trompent jamais. Le text-to-SQL se justifie sur l'exploration, pas sur le récurrent.

Si vos données ne sont pas propres, aucun modèle ne les nettoiera : une base où le même client existe en quatre exemplaires produira quatre réponses à la même question — et c'est le système qui sera accusé.

Si personne ne peut arbitrer les définitions, le projet est bloqué avant de commencer. Sans quelqu'un capable de trancher ce qu'est un « client actif », il n'y a pas de couche sémantique possible.

Si une réponse fausse est coûteuse — clôture comptable, déclaration réglementaire, investissement — imposez une validation humaine. À 80 % de fiabilité au mieux, on ne signe pas des comptes.

En revanche, sur une base bien modélisée, à périmètre restreint et avec des utilisateurs capables de repérer un résultat aberrant, le gain est réel et rapide. C'est l'arbitrage que nous posons avec l'équipe qui branche l'IA sur vos bases de données avant d'écrire la moindre ligne de code.

L'avis de Laurent, Directeur Général et développeur back-end chez EpickOne : « La première fois qu'on a branché un modèle sur une base client réelle, on a fait l'erreur classique : lui envoyer le schéma brut et espérer. Le résultat était plausible et faux, ce qui est le pire des cas — une requête qui tourne, renvoie un nombre, et ce nombre est mauvais. Ce qui a débloqué la situation, ce n'est pas d'être passé à un modèle plus cher : c'est d'avoir écrit un document de trente lignes définissant les dix indicateurs qui comptaient vraiment, avec leurs règles d'exclusion. Le même modèle est devenu exploitable. Mon conseil : avant de comparer des modèles, demandez à votre contrôleur de gestion d'écrire ses définitions. S'il n'y arrive pas, le projet n'est pas mûr — et ce n'est pas un problème d'IA. »

Questions fréquentes

Quel est le meilleur modèle IA pour le text-to-SQL en 2026 ?

Sur les classements publics à harnais identique, la famille Claude devance ses concurrents, avec Claude Sonnet 5 comme meilleur rapport fiabilité/prix (2 / 10 $ par million de tokens). Mais l'écart entre modèles est deux à quatre fois plus faible que l'écart entre « modèle seul » et « modèle plus couche sémantique ». Choisissez le modèle en dernier, sur vos propres questions de contrôle.

Peut-on faire confiance à une réponse générée automatiquement ?

Pas aveuglément. Les meilleurs systèmes publiés plafonnent autour de 80 % sur les benchmarks entreprise, contre 92,96 % pour un humain expert. Un système bien conçu doit donc afficher la requête SQL qu'il a produite, permettre de la corriger, et signaler quand il n'est pas sûr — plutôt que de renvoyer un chiffre nu.

Mes données doivent-elles sortir de l'entreprise ?

Non, à condition de concevoir l'architecture dans ce sens. Seuls le schéma, les définitions métier et la question ont besoin d'atteindre le modèle : les données, elles, restent dans votre base, puisque c'est votre moteur SQL qui exécute la requête. C'est une différence de nature avec le RAG documentaire, et elle facilite nettement la conformité RGPD.

Ce qu'il faut retenir

Le text-to-SQL est passé du gadget de démonstration au cas d'usage crédible, mais il est encore fragile sur bases réelles — et les classements publics le surestiment. La hiérarchie des priorités est contre-intuitive : la couche sémantique d'abord, le jeu de questions de contrôle ensuite, le choix du modèle en dernier. C'est l'inverse de l'ordre dans lequel la plupart des projets démarrent, et c'est pourquoi la plupart s'arrêtent après la démonstration.

Si vous vous demandez si votre base est prête, la réponse tient en un test : demandez trois définitions d'indicateurs à trois personnes différentes. Si vous obtenez trois réponses, vous savez par quoi commencer.

Réserver votre diagnostic text-to-SQL — 30 minutes, offert, avec une réponse franche sur la faisabilité et le coût.