Le text-to-SQL expliqué : du langage naturel à la requête SQL

Le text-to-SQL transforme une question écrite en langage courant en requête SQL, en associant la question au schéma de la base : noms de tables et de colonnes, types, relations et descriptions éventuelles. La requête produite est une proposition sur ce que vous vouliez dire ; la façon dont elle a été générée, sa validation avant exécution et ce qui accompagne le résultat déterminent si la réponse est fiable. Ce guide suit une question de reporting depuis les mots jusqu’à la requête exécutée, puis présente le parcours utilisé par Datarelix.

Comment une question de reporting devient-elle une requête ?

Vous cherchez les ventes mensuelles dans une base sans rédiger une requête de zéro. Un outil text-to-SQL associe votre question aux informations du schéma, puis génère du SQL avec les noms de tables et de colonnes.

Exemple sur le schéma d’un commerçant : « Affiche les ventes finalisées par mois d’avril à juin 2026, en euros. » Voici une requête PostgreSQL :

SELECT date_trunc('month', ordered_at) AS month,
       SUM(total_eur) AS completed_sales_eur
FROM orders
WHERE status = 'completed'
  AND ordered_at >= DATE '2026-04-01'
  AND ordered_at < DATE '2026-07-01'
GROUP BY 1
ORDER BY 1;

La table doit contenir ces colonnes et total_eur correspondre à la définition retenue. La requête regroupe les commandes par mois. Un mois sans commande correspondante est absent si la requête ne comble pas explicitement ce manque. Elle ne soustrait pas les remboursements et ne convertit aucune devise.

On peut accomplir la même tâche en écrivant le SQL. La comparaison avec le SQL manuel présente les étapes de production, de relecture et de réutilisation.

Que doit connaître l’outil ?

Le contexte du schéma fournit noms, types et relations. Les descriptions métier précisent quelle table est actuelle, ce qu’un statut signifie et quel montant convient au reporting. Les autorisations déterminent les données accessibles.

Information manquante	Effet possible	Précision utile
Définition des ventes	Commandes, factures et encaissements diffèrent	« Utilise la valeur des commandes finalisées avant remboursements. »
Période	Dernier trimestre et 90 derniers jours diffèrent	Indiquez des dates ou une période civile.
Table à utiliser	Une ancienne table ressemble à la nouvelle	Nommez la table validée.
Relation entre tables	Une commande peut avoir plusieurs paiements	Décrivez la relation et vérifiez son utilisation.

Les descriptions aident sans garantir l’interprétation. Consultez le guide du contexte.

Générer, exécuter et vérifier

Dans une comparaison, identifiez si l’outil génère seulement du SQL, l’exécute, affiche l’instruction exécutée et conserve les résultats. Examinez séparément les contrôles d’accès et les reprises après erreur. L’étiquette « générateur SQL par IA » ne suffit pas à connaître ces capacités.

Le dialecte compte : PostgreSQL, MySQL, BigQuery et Snowflake emploient différentes fonctions de dates et règles de nommage. Choisissez un outil compatible avec votre source et essayez une question dont vous pouvez contrôler la réponse.

Dans Datarelix, les identifiants restent hors du contexte du modèle, tandis que questions, descriptions et certaines valeurs de résultats à une ligne peuvent lui parvenir ; les résultats sont conservés avec l’exécution. La présentation sécurité détaille ce qui circule et vers où.

Comment Datarelix traite la question

Ce parcours décrit Datarelix ; les autres outils text-to-SQL peuvent répartir ces étapes autrement.

1. Préparer le contexte du schéma

Les noms, les types, les relations déclarées et les descriptions relues aident à choisir les données pertinentes. Ce contexte de schéma ne contient pas d’échantillons de lignes. Votre question peut toutefois contenir les informations que vous saisissez, et certaines valeurs d’un résultat d’une seule ligne peuvent servir aux questions suivantes. Les secrets de connexion restent hors du contexte du modèle.

2. Produire une demande structurée

Le modèle propose un plan avec la requête et les éventuelles étapes d’analyse. À ce stade, produire du SQL ne l’exécute pas. Le service peut vérifier les champs du plan avant de transmettre une requête acceptée à l’exécution.

3. Valider la requête proposée

Datarelix analyse le SQL et applique sa validation en lecture seule avant l’exécution ; le guide des contrôles de l’analytique IA en lecture seule précise ce que cette validation protège et ne protège pas. Une CTE n’est admissible que si son contenu respecte aussi ces restrictions : commencer par WITH ne suffit pas. KQL et ES|QL ont leurs propres validateurs. Les limites de sortie bornent les lignes renvoyées, pas nécessairement les données parcourues. Les droits de la base participent aussi à la protection.

4. Exécuter avec la connexion

Le service utilise les identifiants de connexion pour contacter la source. Ils servent également aux tests de connexion et à la découverte du schéma. Ils ne sont pas transmis au modèle. La requête acceptée lit les données accessibles à cette identité dans la base.

5. Traiter les erreurs et conserver le résultat

Une requête en échec peut être corrigée dans la limite des nouvelles tentatives autorisées. Un message d’erreur peut entrer dans le contexte du modèle pour permettre cette correction ; toute requête révisée repasse la validation. L’exécution réussie conserve la requête exécutée, ses sources, son résultat et ses informations d’exécution. Relisez la version réellement exécutée, qui peut différer de la première proposition.

6. Vérifier l’interprétation métier

Une exécution réussie indique que la base a accepté la requête. L’utilisateur métier doit encore confirmer la définition du rapport ; l’analyste, la granularité, les jointures et les bornes temporelles. Les questions suivantes permettent d’affiner le rapport, mais un graphique familier ne remplace pas ces contrôles.

D’une question en langage courant au SQL : un exemple détaillé

Les exemples ci-dessous utilisent les tables customers, orders et order_items d’un détaillant.

Question : « Quels sont nos dix premiers clients par valeur de commandes terminées, avant remboursements, au deuxième trimestre 2026 ? »

Les prix unitaires sont en EUR et chaque article appartient à une commande. Voici une requête PostgreSQL :

SELECT
  c.customer_id,
  c.name,
  SUM(oi.quantity * oi.unit_price) AS revenue
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.customer_id
JOIN order_items AS oi ON oi.order_id = o.order_id
WHERE o.status = 'completed'
  AND o.ordered_at >= DATE '2026-04-01'
  AND o.ordered_at < DATE '2026-07-01'
GROUP BY c.customer_id, c.name
ORDER BY revenue DESC
LIMIT 10;

La même question sur BigQuery produit une requête structurellement identique, avec des différences de dialecte :

SELECT
  c.customer_id,
  c.name,
  SUM(oi.quantity * oi.unit_price) AS revenue
FROM `demo_retail.customers` AS c
JOIN `demo_retail.orders` AS o ON o.customer_id = c.customer_id
JOIN `demo_retail.order_items` AS oi ON oi.order_id = o.order_id
WHERE o.status = 'completed'
  AND DATE(o.ordered_at) >= '2026-04-01'
  AND DATE(o.ordered_at) < '2026-07-01'
GROUP BY c.customer_id, c.name
ORDER BY revenue DESC
LIMIT 10;

BigQuery utilise des accents graves pour ces identifiants qualifiés par jeu de données. Ici, ordered_at est un TIMESTAMP et DATE(ordered_at) utilise UTC si aucun fuseau n’est précisé. Le filtre approprié dépend aussi du partitionnement. Vérifiez les types de colonnes et le fuseau du rapport ; toutes les requêtes BigQuery ne nécessitent pas une conversion de date. Le guide BigQuery détaille les partitions et les coûts.

Commencer par une réponse connue

Utilisez une connexion autorisée et posez une question dont vous connaissez la réponse. Contrôlez dates, sources et définition avec le guide de vérification. Commencez par une table comprise ; faites vérifier les jointures complexes avant de vous y fier.

Le démarrage rapide couvre la connexion et la première question. Datarelix interroge les données existantes ; écritures, migrations et administration nécessitent d’autres outils.