Un système Text-to-SQL fiable ne se résume pas à envoyer une question à un LLM. Il doit retrouver le bon schéma, comprendre les métriques métier, générer le bon dialecte SQL, valider la requête, appliquer les permissions et évaluer le résultat. Voici l’architecture complète.
Le Text-to-SQL avec des LLM est facile à démontrer et beaucoup plus difficile à fiabiliser.
Un grand modèle de langage peut souvent générer une requête SQL syntaxiquement correcte. En production, les erreurs les plus dangereuses sont ailleurs : mauvaise table, métrique mal interprétée, jointure qui duplique les lignes, question ambiguë, colonne sensible exposée ou requête plausible qui répond à une autre question.
L’architecture réelle n’est donc pas :
question → LLM → SQL
mais plutôt :
question → compréhension de l’intention → récupération du schéma → contexte sémantique → génération SQL → validation → permissions → exécution sécurisée → vérification du résultat → correction ou réponse
Qu’est-ce que le Text-to-SQL avec un LLM ?
Le Text-to-SQL avec LLM consiste à utiliser un grand modèle de langage pour transformer une demande analytique formulée en langage naturel en requête SQL sur un schéma de données connu.
Par exemple : « Quelles catégories de produits ont perdu le plus de marge brute en France au dernier trimestre par rapport au trimestre précédent ? »
Le système doit retrouver les bons concepts métier, les bonnes tables, comprendre le dialecte SQL, produire la requête et l’exécuter sans dépasser les droits de l’utilisateur.
C’est une forme de requête en langage naturel, mais le NLQ est plus large que SQL.
Pourquoi les LLM ont changé le Text-to-SQL
Les LLM savent mieux raisonner sur les schémas, instructions, exemples et formulations métier sans entraîner un modèle spécifique à chaque base.
Ils ne connaissent cependant pas vos définitions internes. Le modèle peut savoir ce qu’est le chiffre d’affaires en général ; il ne sait pas spontanément quelle table fait foi, si les remises sont incluses ni quelle date correspond à la reconnaissance du revenu.
CTA 1 À INSÉRER
Emplacement : après cette section
Titre : Donner accès aux données sans exposer toute la complexité du schéma
Bouton : Découvrir le Data Analyst Agent
Destination : /fr/plateforme/data-analyst-agent
Architecture Text-to-SQL pour la production
1. Comprendre l’intention et détecter l’ambiguïté
« Meilleurs clients du mois » ne suffit pas si “meilleur” peut signifier chiffre d’affaires, marge ou nombre de commandes. Le système doit demander une précision lorsque l’ambiguïté change réellement la requête.
2. Retrouver le bon schéma
Envoyer des milliers de tables et colonnes au modèle est coûteux et souvent contre-productif. Il faut récupérer les datasets, tables, colonnes, relations et exemples réellement pertinents.
3. Ajouter le contexte sémantique
Les métadonnées SQL ne suffisent pas. Il faut fournir définitions de KPI, dimensions autorisées, chemins de jointure, synonymes, règles temporelles, permissions et exemples validés.
4. Générer la requête SQL
Le LLM reçoit la question, le schéma ciblé, les règles métier, le dialecte et quelques exemples pertinents.
5. Valider de manière déterministe
Parser SQL, AST, allowlist de statements, tables autorisées, dry run / EXPLAIN, limites de coût et timeouts doivent contrôler ce que le modèle propose.
6. Appliquer les permissions
Les droits doivent être imposés au niveau de la base ou du moteur d’exécution, pas mémorisés dans un prompt.
7. Exécuter dans un contexte read-only
L’exécution doit être limitée en temps, volume et ressources.
8. Vérifier le résultat
Une requête peut s’exécuter sans erreur et répondre à la mauvaise question. Le système doit contrôler granularité, volumes, valeurs inattendues et cohérence avec la demande.
9. Corriger de manière bornée
En cas d’erreur, renvoyez l’erreur utile au modèle et limitez le nombre de tentatives.
IMAGE 1 À INSÉRER
Emplacement : après l’architecture
Prompt : Create a premium 16:9 thaink² editorial illustration explaining a production Text-to-SQL architecture. Use a very dark navy background and an ultra-minimal 3D enterprise style. Show three major groups only: a natural-language business question on the left, a central translucent SQL intelligence core receiving schema and semantic signals plus a validation gate, and a verified query/result packet on the right. Use cyan and violet glass materials with one pale-gold verification accent, generous negative space, no people, no text, no labels, no vendor logos.
Alt : Pipeline Text-to-SQL reliant question en langage naturel, schéma, contexte sémantique, validation et résultat vérifié.
Le schema linking est souvent le premier vrai problème
Le modèle ne peut pas écrire la bonne requête s’il raisonne sur les mauvaises tables. Le schema linking relie les mots de la question aux entités réelles de la base.
Descriptions, embeddings, recherche lexicale, historique de requêtes, clés étrangères, échantillons de données et glossaire métier peuvent tous améliorer cette étape.
La couche sémantique évite le SQL techniquement correct mais métierement faux
Une couche sémantique peut définir la formule officielle de marge, la date de référence du revenu, la définition d’un client actif, les jointures valides et les filtres implicites.
Cette même couche devient essentielle dans les workflows d’agentic analytics.
Techniques de prompting utiles
Préciser le dialecte
PostgreSQL, BigQuery, Snowflake et SQL Server n’utilisent pas exactement la même syntaxe.
Utiliser des exemples vérifiés
Quelques couples question/SQL réellement représentatifs apprennent au modèle vos conventions.
Injecter seulement les règles utiles
Évitez le system prompt gigantesque contenant toutes les règles de l’entreprise.
Structurer la sortie
Hypothèses, SQL, tables référencées et niveau de confiance peuvent être renvoyés sous forme structurée pour faciliter la validation.
Faut-il générer plusieurs requêtes SQL ?
Pour les questions complexes, plusieurs candidats peuvent être générés puis validés et comparés. Cette approche améliore parfois la robustesse, mais augmente coût et latence : elle doit être réservée aux cas qui le justifient.
La validation syntaxique ne suffit pas
Niveau | Question |
|---|---|
Syntaxe | La base peut-elle parser le SQL ? |
Sécurité | La requête est-elle read-only et limitée aux objets autorisés ? |
Coût | La requête risque-t-elle de scanner trop de données ? |
Schéma | Tables, colonnes et jointures sont-elles valides ? |
Sémantique | La logique métier correspond-elle à l’intention ? |
Résultat | Les données retournées ont-elles du sens ? |
Sécurité : traiter le SQL généré comme du code non fiable
Le modèle propose ; la politique décide si la requête peut s’exécuter.
credentials read-only ;
row-level et column-level security ;
allowlists de statements ;
timeouts ;
budgets de scan / compute ;
schémas système interdits ;
journalisation auditable.
Les métadonnées récupérées doivent également être traitées comme des données potentiellement non fiables afin d’éviter qu’un texte injecté dans le contexte ne devienne une instruction.
Comment évaluer un système Text-to-SQL ?
Execution accuracy
La requête renvoie-t-elle le résultat attendu ?
Correction sémantique
Répond-elle réellement à l’intention métier ?
Qualité du schema linking
Les bonnes tables et colonnes ont-elles été retrouvées ?
Safety pass rate
Quelle proportion des requêtes proposées respecte la politique sans intervention ?
Qualité des clarifications
Le système sait-il demander une précision au bon moment ?
Taux de correction
Une erreur peut-elle être réparée en quelques tentatives bornées ?
Latence et coût
Mesurez tout le pipeline : retrieval du schéma, LLM, validation et exécution.
Ce que Spider et BIRD permettent de mesurer
Les benchmarks publics restent utiles pour comparer les progrès, mais ils ne reproduisent ni vos schémas, ni vos définitions métier, ni vos permissions.
En 2026, le leaderboard BIRD conserve encore un écart entre performance humaine et meilleurs systèmes sur l’execution accuracy. Utilisez donc les benchmarks pour présélectionner les modèles, puis vos propres questions pour décider d’un déploiement.
IMAGE 2 À INSÉRER
Emplacement : après l’évaluation
Prompt : Create a refined 16:9 thaink² editorial illustration about Text-to-SQL evaluation. On a dark navy background, show one benchmark question set feeding two candidate SQL paths into a translucent evaluation gate. The gate should abstractly check schema match, execution, semantic correctness and safety before one pale-gold verified result continues. Premium cyan and violet glass, generous negative space, no people, no text, no labels, no vendor logos.
Alt : Évaluation Text-to-SQL comparant plusieurs requêtes sur précision d’exécution, correction sémantique et sécurité.
Construire un dataset d’évaluation interne
Collectez de vraies questions d’analystes et métiers : requêtes simples, jointures complexes, comparaisons temporelles, KPI, demandes ambiguës, questions impossibles, cas sensibles aux permissions et requêtes potentiellement coûteuses.
Figez ensuite ce jeu de test afin de mesurer les régressions lorsque prompt, modèle ou semantic layer évoluent.
Après un certain niveau, l’architecture compte autant que le modèle
Un modèle plus puissant aide sur les cas difficiles, mais schema retrieval, exemples vérifiés, contexte sémantique, validation déterministe et boucle de correction peuvent apporter davantage qu’un simple changement de LLM.
Cela permet aussi le model routing : requêtes simples sur un modèle moins coûteux, cas complexes ou incertains vers un modèle plus puissant.
Text-to-SQL multi-tour
L’analyse réelle est conversationnelle : « chiffre d’affaires par région », puis « uniquement les comptes enterprise », puis « compare avec l’année dernière ».
Conservez filtres, métriques et périodes sous forme d’état structuré plutôt que de dépendre uniquement de l’historique conversationnel.
Text-to-SQL dans un workflow d’agent analytique
Le SQL devient encore plus utile lorsqu’il est un outil parmi d’autres. Un Data Analyst Agent peut décider qu’une question nécessite du SQL, une autre du retrieval documentaire et une troisième un calcul ou une API.
C’est la différence entre une fonctionnalité Text-to-SQL et un véritable workflow analytique.
CTA 2 À INSÉRER
Emplacement : après cette section
Titre : Utiliser la génération SQL comme un outil analytique gouverné
Bouton : Découvrir Text-to-SQL
Destination : /fr/solutions/text-to-sql
Erreurs fréquentes en production
Mauvaise table, réponse plausible. La requête s’exécute sur une source non officielle.
Explosion de jointure. Une jointure many-to-many gonfle les agrégats.
Dérive de métrique. Le modèle reconstruit un KPI au lieu d’utiliser sa définition officielle.
Ambiguïté ignorée. Le système devine au lieu de poser une question.
Fuite de permissions. Une colonne sensible devient accessible.
Requête trop coûteuse. Le SQL est valide mais scanne inutilement trop de données.
Boucle de correction silencieuse. Les retries augmentent latence et coût sans être visibles.
Checklist de mise en production en 10 étapes
Définir les workflows et utilisateurs.
Identifier les schémas et métriques de référence.
Construire le schema retrieval.
Ajouter semantic layer et exemples validés.
Générer le bon dialecte SQL.
Parser et valider avant exécution.
Exécuter avec des droits read-only et permission-aware.
Vérifier le résultat et limiter les corrections.
Construire un harness d’évaluation représentatif.
Surveiller erreurs, latence, coûts et changements de modèle.
Où interviennent thaink² et aPowerB ?
thaink² utilise Text-to-SQL comme une capacité au sein de workflows data plus larges. Le Data Analyst Agent peut interroger des données structurées tout en conservant le contexte analytique, et la solution Text-to-SQL se concentre sur l’accès aux bases via le langage naturel.
aPowerB fournit un runtime open source pour les développeurs qui veulent composer modèles, outils de base de données, retrieval et validations dans leurs propres agents.
Dans les deux cas, la règle reste la même : le SQL généré est une action proposée qui doit passer une politique déterministe avant exécution.
CTA 3 À INSÉRER
Emplacement : après cette section
Titre : Construire une analytics en langage naturel autour d’une exécution gouvernée
Bouton : Découvrir thaink² Platform
Destination : /fr/plateforme
À retenir
Les meilleurs systèmes Text-to-SQL ne demandent pas au LLM de tout résoudre seul. Ils utilisent le modèle pour le langage et le raisonnement, puis l’entourent de retrieval, définitions sémantiques, validation déterministe, permissions, exécution sûre et évaluation.
L’architecture fiable n’est pas question → LLM → SQL, mais intention gouvernée → contexte contraint → SQL généré → exécution vérifiée.
Questions fréquentes
Qu’est-ce que le Text-to-SQL avec LLM ?
C’est l’utilisation d’un grand modèle de langage pour transformer une demande analytique en langage naturel en requête SQL sur un schéma connu, généralement avec contexte, validation et contrôles d’exécution.
Quel est le meilleur LLM pour le Text-to-SQL ?
Cela dépend du schéma, de la latence, du coût et des résultats sur votre dataset. En production, schema retrieval, couche sémantique et validation peuvent compter autant que le modèle.
Comment améliorer la précision du Text-to-SQL ?
Récupérez le bon schéma, fournissez les définitions métier et exemples vérifiés, générez le bon dialecte, validez de manière déterministe, exécutez avec des garde-fous et évaluez sur de vraies questions internes.
Le Text-to-SQL est-il sûr pour une base de production ?
Oui si le SQL généré est traité comme du code non fiable : credentials read-only, permissions ligne/colonne, allowlists, dry runs, timeouts, budgets et logs auditables.
Comment évaluer le Text-to-SQL ?
Mesurez execution accuracy, correction sémantique, schema linking, sécurité, qualité des clarifications, taux de correction, latence et coût sur un jeu de test représentatif.
Faq
Qu’est-ce que le Text-to-SQL avec LLM ?
C’est l’utilisation d’un grand modèle de langage pour transformer une demande analytique en langage naturel en requête SQL sur un schéma connu, généralement avec contexte, validation et contrôles d’exécution.
Quel est le meilleur LLM pour le Text-to-SQL ?
Cela dépend du schéma, de la latence, du coût et des résultats sur votre dataset. En production, schema retrieval, couche sémantique et validation peuvent compter autant que le modèle.
Comment améliorer la précision du Text-to-SQL ?
Récupérez le bon schéma, fournissez les définitions métier et exemples vérifiés, générez le bon dialecte, validez de manière déterministe, exécutez avec des garde-fous et évaluez sur de vraies questions internes.
Le Text-to-SQL est-il sûr pour une base de production ?
Oui si le SQL généré est traité comme du code non fiable : credentials read-only, permissions ligne/colonne, allowlists, dry runs, timeouts, budgets et logs auditables.
Comment évaluer le Text-to-SQL ?
Mesurez execution accuracy, correction sémantique, schema linking, sécurité, qualité des clarifications, taux de correction, latence et coût sur un jeu de test représentatif.
