Google Research vient de placer son système Gemini-SQL2 en tête du classement text-to-SQL. Le récit est tout trouvé : la data se démocratise, n’importe qui pourra bientôt interroger une base sans connaître une ligne de SQL. Mais ce récit oublie l’essentiel.
Ce que dit le benchmark, et ce qu’il ne dit pas
Les chiffres sont réels et impressionnants. Construit sur Gemini 3.1 Pro, Gemini-SQL2 atteint 80,04 % de précision d’exécution sur le benchmark BIRD, qui mesure si une requête traduite depuis le langage naturel s’exécute correctement. Selon Google, c’est la première place, devant GPT-5.5-xhigh d’OpenAI (environ 72,8 %) et Claude Opus 4.6 d’Anthropic (environ 70,9 %). Les modèles de Databricks, AWS, Tencent et Alibaba suivent loin derrière.
Traduire une phrase en SQL exécutable est notoirement difficile : les données sont souvent empilées en couches, et les requêtes doivent intégrer une logique métier complexe. Google souligne que les requêtes générées « semblent correctes et s’exécutent avec succès ». Voilà la formule à relire deux fois.
Car 80 %, ce n’est pas 100 %. Une requête sur cinq, dans le meilleur des cas du leader, échoue ou renvoie un résultat qui n’est pas celui attendu.
Le vrai problème n’est pas la requête fausse, c’est la requête plausible
Une requête qui plante, on la repère. L’erreur saute aux yeux, le système renvoie un message, on corrige. Ce n’est pas le danger.
Le danger, c’est la requête qui « semble correcte et s’exécute avec succès » mais répond à une question légèrement différente de celle posée. Elle agrège sur le mauvais champ, ignore un filtre de périmètre, double-compte une jointure. Elle ne plante pas : elle renvoie un chiffre. Un chiffre crédible, qui finira dans un tableau de bord, une décision, un reporting.
C’est là que le récit de la « démocratisation » se retourne. Un text-to-SQL fiable à 80 % ne supprime pas le risque. Il le déplace : de l’écriture vers la lecture, de l’expert qui formulait la requête vers le destinataire qui consomme le résultat sans avoir les moyens de le contester.
Qui audite, et selon quels droits ?
Tant que l’analyste écrivait sa requête à la main, deux garde-fous tenaient. Le premier : il comprenait ce qu’il demandait, donc il pouvait douter du résultat. Le second, plus discret mais décisif : ses droits d’accès s’appliquaient. Il ne pouvait interroger que ce que la base l’autorisait à voir.
Avec un assistant qui génère la requête à la place de l’utilisateur, ces deux garde-fous vacillent. Posons les questions qui dérangent :
- Sous quelle identité s’exécute la requête générée : celle de l’utilisateur final, ou celle, large, du service qui orchestre le modèle ?
- Qui relit le SQL produit avant qu’il ne touche des données sensibles : paie, RH, santé ?
- Comment tracer une décision quand plus personne n’a écrit la requête qui l’a produite ?
Une requête que personne n’a écrite à la main est une requête que personne ne s’approprie vraiment. Or l’audit, la conformité, la responsabilité reposent justement sur cette appropriation. On ne peut pas demander des comptes à un prompt.
Pour le praticien qui orchestre, le travail change de nature
Cela ne veut pas dire qu’il faut bouder l’outil. Gagner 80 % de précision sur une tâche aussi ingrate que le SQL ad hoc, c’est un levier réel. Mais l’orchestrateur d’IA qui intègre ce type de système ne supprime pas une charge de travail : il en hérite d’une autre.
Le travail ne consiste plus à écrire la requête. Il consiste à construire la couche de confiance autour d’elle : périmètres d’accès appliqués au niveau de la base et non du modèle, validation systématique du SQL généré sur les jointures et les filtres critiques, journalisation de qui a demandé quoi et avec quel résultat. La compétence rare bascule de « savoir écrire du SQL » vers « savoir vérifier du SQL qu’on n’a pas écrit ».
C’est un métier différent, et pour l’instant largement sous-outillé. Le benchmark mesure la précision de génération. Personne ne publie de score sur la facilité d’audit.
Une avancée technique, une dette de gouvernance ?
Google n’a annoncé ni publication du modèle, ni article scientifique pour l’instant. L’entreprise évoque surtout l’amélioration des fonctionnalités en langage naturel à travers ses services data. Autrement dit : la performance brute progresse, mais la question de l’usage responsable reste largement ouverte.
Et c’est peut-être le vrai enseignement de ce classement. Chaque point de précision gagné sur BIRD rend l’outil plus tentant à déployer largement, donc plus exposé au scénario de la requête plausible mais fausse, consommée sans contrôle. La performance et le risque progressent ensemble.
La question n’est donc pas de savoir si l’IA saura un jour écrire un SQL parfait à 100 %. Elle est de savoir qui, dans nos organisations, restera capable de dire « non, ce chiffre est faux » quand plus personne n’aura écrit la requête qui l’a produit.
