Le text-to-SQL en français : comment ça marche

Le text-to-SQL, c'est la traduction automatique d'une question écrite en langage courant (« combien de commandes en octobre ? ») en une requête SQL (langage de requête structuré), le langage que comprend la base de données. L'outil écrit la requête, la base l'exécute, vous lisez le résultat. Le gain : vous n'avez plus à connaître le SQL. Le risque : une requête peut être parfaitement valide et répondre à une autre question que la vôtre. D'où la règle de ce site : on lit la requête avant de croire le chiffre.

Ce qui se passe entre votre question et le résultat

1. Vous posez la question, en français.
2. L'outil regarde la structure de la base : les noms des tables, des colonnes et leurs liens. Google le décrit pour AlloyDB, sa base de données en ligne : la fonction s'appuie sur une « couche de contexte » qui décrit tables, colonnes et relations.
3. Il choisit les tables et les colonnes qui lui semblent correspondre à vos mots. C'est l'étape la plus fragile : « client » peut désigner trois colonnes différentes.
4. Il écrit la requête SQL.
5. La requête est exécutée, tout de suite ou après votre accord selon l'outil.
6. Le résultat s'affiche, souvent en tableau ou en graphique.

Retenez l'étape 2 : l'outil ne connaît votre entreprise qu'à travers les noms de vos colonnes. C'est pourquoi un dictionnaire de données améliore souvent les réponses autant qu'un meilleur outil.

Trois exemples en français, annotés

Les exemples ci-dessous sont illustratifs : ils supposent une base simple avec une table clients et une table commandes. Votre base aura d'autres noms.

Question : « Combien de commandes avons-nous reçues en octobre 2026 ? »

SELECT count(*)
FROM commandes
WHERE date_commande >= '2026-10-01'
  AND date_commande <  '2026-11-01';

À vérifier : la période (du 01/10/2026 inclus au 01/11/2026 exclu, donc tout octobre), et la colonne de date choisie. Si la table contient aussi une date de livraison, l'outil a pu prendre la mauvaise.

Question : « Quels clients ont commandé cette année ? »

SELECT DISTINCT c.nom
FROM clients c
JOIN commandes o ON o.client_id = c.id
WHERE o.date_commande >= '2026-01-01';

À vérifier : le DISTINCT, qui évite de voir un client autant de fois qu'il a commandé, et le JOIN, qui relie chaque commande à son client.

Question : « Quels clients n'ont jamais commandé ? »

SELECT c.nom
FROM clients c
LEFT JOIN commandes o ON o.client_id = c.id
WHERE o.id IS NULL;

À vérifier : le mot LEFT. La documentation de PostgreSQL l'explique : une jointure simple ne garde que les lignes qui ont une correspondance des deux côtés, alors qu'une jointure externe gauche garde aussi les lignes sans correspondance. Sans LEFT, la requête ne pourrait trouver aucun client sans commande, et répondrait « aucun ».

Pour lire ces mots un par un, voyez comprendre une requête SQL, puis nos exemples de requêtes annotés.

Pourquoi l'outil se trompe

• Les mots sont ambigus. « Chiffre d'affaires » : hors taxes ou toutes taxes ? Factures ou commandes ? Avoirs déduits ou non ?
• Les noms de colonnes sont obscurs. Une colonne mt2 ne dit rien à personne.
• La base est grande. Metabase indique que, si la question ne nomme pas de table, Metabot ne regarde que les 100 premières tables de la base, et qu'il peut alors inventer des tables : la requête échoue.
• La langue. Metabase indique que Metabot est plus fiable en anglais. Microsoft indique, pour Copilot dans Power BI, que des demandes dans une autre langue que l'anglais peuvent donner des réponses pertinentes, mais que l'usage multilingue n'est pas officiellement pris en charge.
• Le résultat a l'air juste. Google prévient, dans la documentation de Data Studio (anciennement Looker Studio), que l'outil peut produire des résultats plausibles mais factuellement inexacts, et demande de valider toutes les sorties.

Comment vérifier, en trois gestes

1. Afficher la requête. Dans Data Studio, Google indique qu'un clic sur « How was this calculated? » puis sur l'onglet « Code » montre le SQL généré. Dans Metabase, le SQL de Metabot apparaît dans l'éditeur avant exécution.
2. La relire avec la question en tête : bonne table, bonne période, bonne jointure, bon total.
3. La tester sur une réponse connue : posez d'abord une question dont vous avez le chiffre par ailleurs.

La liste complète est dans vérifier une requête SQL générée par l'IA.

Bien formuler sa question

• Nommez la période avec des dates : « du 01/10/2026 au 31/10/2026 » plutôt que « le mois dernier ».
• Nommez la table si vous la connaissez : « dans la table des factures ».
• Dites l'unité : « montant hors taxes ».
• Une question à la fois. Deux questions dans une phrase donnent souvent une requête qui n'en traite qu'une.

Et si la base contient des données sensibles, faites travailler l'outil avec un compte en lecture seule : il ne pourra rien modifier, même par erreur.