Le text-to-SQL est une promesse séduisante : l'utilisateur écrit sa question, le modèle génère la requête SQL correspondante, la base l'exécute. Les démonstrations sont spectaculaires et les résultats publiés sur des jeux de test sont élevés.
En production, sur une base d'entreprise réelle, le taux de réussite chute. Cet article explique où passe la différence, et ce qu'on met en place à la place.
Pourquoi les scores de test ne se transposent pas
Les jeux d'évaluation publics reposent sur des schémas propres, documentés, aux noms explicites, avec peu de tables et aucune règle métier implicite. Une base de production n'a aucune de ces propriétés.
Elle contient des tables mortes que personne n'a supprimées, des colonnes dont le nom ne décrit plus le contenu, des champs libres utilisés pour stocker autre chose que ce qui était prévu, des doublons de référentiel, et des règles que personne n'a écrites.
Un modèle qui génère du SQL sur ce terrain ne produit pas des erreurs franches. Il produit des requêtes valides, qui s'exécutent sans broncher, et qui renvoient un chiffre faux. C'est le cœur du problème.
Les quatre modes d'échec les plus fréquents
La table plausible mais fausse
Deux tables portent des noms voisins, l'une est l'historique actif, l'autre une archive de migration jamais nettoyée. Le modèle choisit la seconde parce que son nom colle mieux à la question. La requête s'exécute, le total est cohérent, il est faux de quarante pour cent.
Le filtre manquant
La règle « on exclut toujours les commandes au statut annulé » est connue de tout le service commercial et écrite nulle part. Le modèle ne l'invente pas. Chaque total est donc légèrement surévalué, dans une proportion qui varie selon la période.
La jointure approximative
Relier une facture à un chantier suppose parfois de passer par une table de liaison, avec une condition sur la date de validité. Le modèle peut construire une jointure directe qui semble raisonnable et qui duplique les lignes. Le compte est trop élevé, sans qu'aucune erreur ne s'affiche.
La requête coûteuse
Une question mal cadrée peut produire un balayage complet sur plusieurs tables volumineuses. En développement, on attend. En production, on dégrade le service pour tout le monde.
Le vrai problème n'est pas le modèle
La tentation est de conclure que les modèles ne sont pas encore assez bons, et d'attendre la génération suivante. C'est une mauvaise lecture.
Aucun modèle, aussi capable soit-il, ne peut deviner une règle métier qui n'est écrite nulle part. Il ne peut pas savoir que la table archivée ne doit pas servir, ni que les montants négatifs sont des avoirs, ni que l'entité fermée en 2022 doit sortir du périmètre. Ces informations n'existent pas dans le schéma. Elles existent dans la tête de trois personnes.
Améliorer le modèle ne résout donc pas le problème. Écrire les règles quelque part le résout.
Ce qu'on met en place à la place
L'approche que nous retenons ne consiste pas à faire écrire du SQL libre sur un schéma brut, mais à exposer des vues métier via un serveur MCP. La différence est structurelle.
| Point | Text-to-SQL sur schéma brut | Vues métier exposées via MCP |
|---|---|---|
| Ce que voit le modèle | Tout le schéma, tables mortes comprises | Un ensemble restreint de vues validées |
| Règles métier | À deviner à chaque requête | Écrites une fois dans la vue |
| Vérifiabilité | Il faut relire du SQL généré | Il faut relire une vue, une seule fois |
| Risque de requête lourde | Élevé, aucune borne | Volumétrie plafonnée par construction |
| Droits | Ceux du compte de connexion | Vues attachées à des rôles |
| Effort principal | Prompt et post-traitement | Cadrage métier en amont |
Le déplacement essentiel tient dans la ligne « vérifiabilité ». Avec du SQL généré à la volée, chaque réponse est un objet nouveau qu'il faudrait relire. Avec des vues, la relecture se fait une fois, par quelqu'un qui connaît le métier, et elle vaut pour toutes les questions suivantes.
Là où le text-to-SQL garde du sens
Il serait malhonnête de le disqualifier entièrement. Deux contextes lui conviennent.
Un entrepôt de données déjà modélisé. Si vos données sont passées par un travail de modélisation propre, avec des tables de faits et de dimensions correctement nommées, une bonne partie des pièges disparaît. Le schéma porte alors lui-même une partie des règles.
Un usage entre mains expertes. Un analyste qui lit le SQL généré, le corrige et l'exécute gagne un temps réel. Le risque n'existe que lorsque la requête n'est relue par personne.
La ligne de partage n'est donc pas technologique. Elle tient à la question de savoir si quelqu'un vérifie, et si cette personne en a les moyens.
Comment tester chez vous, sans rien installer
Un exercice de quinze minutes suffit à mesurer votre exposition au problème. Prenez trois indicateurs dont vous connaissez déjà la valeur exacte, issus d'un état comptable ou d'un tableau de bord validé.
Demandez à la personne qui écrit habituellement les requêtes de vous expliquer, pour chacun, les filtres qu'elle applique et pourquoi. Notez-les.
Si cette liste comporte plus de deux règles qui n'apparaissent nulle part dans le nom des tables ou des colonnes, vous savez déjà que le SQL généré à la volée produira des chiffres faux chez vous. Cette liste est aussi, très exactement, le point de départ de la définition de vos vues.
En résumé
Le text-to-SQL n'échoue pas parce que les modèles raisonnent mal. Il échoue parce qu'une base de production porte des règles implicites qu'aucun modèle ne peut inventer, et parce que ses erreurs prennent la forme de requêtes valides aux résultats faux.
La réponse consiste à sortir ces règles des têtes pour les inscrire dans des vues, puis à n'exposer que ces vues. C'est la démarche décrite sur la page serveur MCP et interrogation des données en langage naturel, et c'est aussi ce qui explique que la part la plus longue d'un projet se joue avant la première ligne de code.
