Gemini-SQL2 domine le text-to-SQL : pourquoi la qualité de votre schéma est la vraie clé

Google Research vient d'annoncer Gemini-SQL2, un système de génération automatique de requêtes SQL à partir de langage naturel. Sur le benchmark BIRD — la référence du secteur pour mesurer la précision de ces traductions — il atteint 80,04 % d'exactitude d'exécution, devançant largement GPT-5.5-xhigh d'OpenAI (72,8 %) et Claude Opus 4.6 d'Anthropic (70,9 %). Les solutions de Databricks, AWS, Tencent et Alibaba restent encore plus loin derrière.

Ces chiffres font sensation. Mais en tant que développeurs PHP/Symfony travaillant quotidiennement avec des bases de données relationnelles, la vraie question n'est pas « quel modèle est le meilleur ? » — c'est : dans quelles conditions peut-on réellement faire confiance à ces outils pour interroger nos données métier ?

Ce que mesure vraiment le benchmark BIRD

Le benchmark BIRD (Big Bench for Large-scale Database Grounded Text-to-SQL Evaluation) est conçu pour aller au-delà des requêtes triviales. Il évalue la capacité des modèles à générer des requêtes SQL correctes sur des bases de données complexes, avec des jointures multiples, des agrégations, et surtout une logique métier non triviale.

Google Research souligne un point fondamental : transformer du langage naturel en SQL valide est difficile précisément parce que les données sont souvent structurées en couches, et que les requêtes doivent refléter des règles métier implicites. Une requête peut sembler correcte syntaxiquement et même s'exécuter sans erreur, tout en renvoyant un résultat erroné sur le plan sémantique.

C'est exactement ce que mesure BIRD : non seulement la requête s'exécute-t-elle, mais produit-elle le bon résultat ?

Avec 80 % de précision, Gemini-SQL2 est impressionnant. Mais cela signifie aussi que 1 requête sur 5 sera fausse — une réalité à ne pas oublier avant de déployer ce type de système en production.

Le facteur silencieux : la qualité de votre schéma de base de données

Les benchmarks comparent les modèles sur des jeux de données standardisés, avec des schémas bien documentés et des nommages cohérents. Dans la réalité d'un projet Symfony, c'est rarement le cas.

Voici ce qui détermine concrètement si un LLM pourra interroger votre base de données de manière fiable :

1. Le nommage de vos tables et colonnes

Un modèle text-to-SQL s'appuie massivement sur les noms pour inférer la sémantique. Une colonne nommée val1 ou flg_x ne lui dit rien. À l'inverse, order_total_amount_ht ou is_invoice_paid lui donnent des indices précis.

Dans vos entités Doctrine, prenez l'habitude de nommer vos propriétés de façon explicite, même si cela allonge légèrement le nom de colonne en base :

#[ORM\Column(name: 'total_amount_excl_tax', type: 'decimal', precision: 10, scale: 2)]
private float $totalAmountExclTax;

2. Les commentaires et descriptions de colonnes

Certains systèmes text-to-SQL peuvent exploiter les commentaires de colonnes SQL ou les métadonnées du schéma. Si vous générez vos migrations avec Doctrine, pensez à enrichir vos annotations :

#[ORM\Column(options: ['comment' => 'Montant total hors taxes en euros, arrondi à 2 décimales'])]

Ces commentaires peuvent servir de contexte supplémentaire injecté dans le prompt du LLM.

3. La cohérence des conventions

Les incohérences de nommage (parfois created_at, parfois date_creation, parfois dt_crea) sont le principal facteur de dégradation des performances. Un modèle entraîné sur des schémas cohérents sera désarçonné par vos exceptions historiques.

Si vous avez une base de données legacy, envisagez de créer une couche de vues SQL bien nommées, spécifiquement dédiées aux usages analytiques et aux agents IA.

Intégrer du text-to-SQL dans un projet Symfony : les bonnes pratiques

Si vous souhaitez expérimenter avec ces capacités dans votre stack PHP/Symfony, voici une approche pragmatique.

Isoler les accès en lecture analytique

Ne laissez jamais un agent IA générer des requêtes sur votre base opérationnelle principale. Utilisez un utilisateur de base de données en lecture seule, idéalement sur un réplica dédié :

# config/packages/doctrine.yaml
doctrine:
    dbal:
        connections:
            analytics:
                url: '%env(DATABASE_ANALYTICS_URL)%'
                # Connexion read-only sur le réplica

Fournir un contexte schéma enrichi

Pluôt que de laisser le LLM deviner votre schéma, injectez-lui un contexte structuré. Vous pouvez générer automatiquement ce contexte depuis Doctrine :

$metadata = $entityManager->getMetadataFactory()->getAllMetadata();
// Sérialisez les noms de tables, colonnes, types et relations
// pour les injecter dans le prompt système

Valider et logger toutes les requêtes générées

Avant toute exécution, parsez la requête pour vérifier qu'elle ne contient que des instructions SELECT. Des bibliothèques PHP comme greenlion/php-sql-parser peuvent vous y aider. Loggez systématiquement chaque requête générée pour auditer le comportement du système.

Ce que cela change pour les applications métier

Google mentionne que de meilleures performances en text-to-SQL pourraient améliorer les fonctionnalités en langage naturel à travers ses services de données. C'est l'enjeu réel : transformer un LLM en analyste métier capable d'interroger directement vos données.

Imaginez un back-office Symfony où un responsable commercial peut taper « Quels sont les clients ayant commandé plus de 3 fois ce mois-ci sans avoir encore reçu leur facture ? » et obtenir une réponse en temps réel, sans solliciter l'équipe technique.

C'est techniquement atteignable aujourd'hui — mais la fiabilité de ce système dépend bien plus de la qualité de votre modélisation de données que du modèle IA choisi. Un schéma bien pensé avec Gemini-SQL2 à 80 % sera plus utile qu'un schéma cryptique même avec une hypothétique précision à 95 %.

Conclusion

Les performances de Gemini-SQL2 sont un signal fort : le text-to-SQL devient mature. Mais ces benchmarks sont établis dans des conditions idéales. En production, votre schéma de base de données est le premier facteur de succès — avant même le choix du modèle.

Si vous travaillez sur un projet Symfony et envisagez d'intégrer des capacités d'interrogation en langage naturel, commencez par auditer vos conventions de nommage et votre documentation de schéma. C'est là que se joue l'essentiel.

Google Research n'a pas encore publié de papier de recherche ni annoncé de disponibilité publique pour Gemini-SQL2. À suivre de près.

Source originale : The Decoder — Google Research's Gemini-SQL2 tops text-to-SQL benchmarks by a wide margin