Qu'est-ce que le NL2SQL et comment ça fonctionne ?

Le NL2SQL désigne la traduction automatique d'une question en langage naturel vers une requête SQL exécutable sur une base relationnelle. Contrairement à un chatbot générique qui répond en texte libre, un système NL2SQL produit un artefact structuré, du SQL, qui s'exécute contre de vraies données et retourne un résultat vérifiable ligne par ligne.

Le terme « text-to-SQL » vient de la recherche académique en traitement du langage naturel. « NL2SQL » est l'abréviation la plus utilisée côté produit et documentation technique. Les deux désignent le même problème : combler l'écart entre une question posée en langue courante et la syntaxe précise attendue par un moteur SQL.

Le NL2SQL se distingue d'un agent conversationnel connecté à une base de données au sens large. Le premier produit une requête lisible et auditable ; le second peut enchaîner plusieurs appels d'outils (recherche, calcul, écriture) sans qu'un SQL unique et inspectable en sorte nécessairement. Un système NL2SQL correctement conçu reste sur ce périmètre volontairement restreint : traduire, valider, exécuter, retourner un résultat.

Un pipeline NL2SQL fiable suit toujours la même séquence, quel que soit le fournisseur : la question passe par un modèle de langage, puis le SQL produit est validé avant exécution, jamais après. L'implémentation d'Aurabase, vérifiée dans le code du service aura-ai, illustre chacune de ces étapes avec des règles concrètes plutôt qu'une description abstraite.

-- Question : "Combien de commandes ce mois-ci pour les clients premium ?"
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- ajouté par le serveur, absent du SQL généré

Le détail complet de ce pipeline, avec chaque appel HTTP et chaque réponse JSON, est couvert dans notre tutoriel pas-à-pas pour construire un endpoint NL2SQL sur Postgres.

Le NL2SQL n'a pas vocation à remplacer le SQL écrit à la main partout. Il couvre un périmètre précis : les questions ad hoc, ponctuelles, posées par quelqu'un qui ne maîtrise pas SQL ou qui veut simplement gagner du temps sur une requête simple.

• Exploration ad hoc d'un tableau de bord par une personne non technique (support, produit, direction).
• Prototypage rapide d'une fonctionnalité qui interroge la base sans écrire une route API dédiée pour chaque question possible.
• Auto-service analytique limité : compter, filtrer, agréger simplement, sans donner un accès direct à la base à l'utilisateur final.

Le SQL écrit à la main reste préférable dès que la question dépasse ce périmètre. Une implémentation validée par AST comme celle décrite plus haut exclut par construction les CTE, les sous-requêtes et les fonctions-fenêtre, pour des raisons de sécurité. Une analyse qui a structurellement besoin de ces constructions, cohortes, fenêtrage temporel avancé, ne passe pas par NL2SQL : elle se code directement. C'est un compromis assumé, la sécurité du système passe avant l'exhaustivité du SQL généré.

Trois risques reviennent systématiquement dans une implémentation NL2SQL, avec des réponses différentes selon la maturité du système.

Deux architectures produisent un résultat visible similaire, mais avec des garanties très différentes. Un NL2SQL natif intègre la génération, la validation et l'exécution directement dans la couche backend qui connaît déjà le schéma et les droits d'accès du projet : c'est la logique décrite plus haut pour Aurabase, où le service aura-ai partage l'infrastructure et l'isolation par schéma avec le reste du backend.

Un NL2SQL assemblé combine un service LLM générique, un connecteur vers la base de données, et une couche de validation à construire soi-même. Rien n'empêche cette approche d'être sûre, mais chaque garantie, schéma introspecté côté serveur, validation AST, plafond de lignes, isolation tenant, doit être implémentée et maintenue par l'équipe qui assemble ces briques, plutôt que fournie par la plateforme.

Le paysage des outils NL2SQL, natifs et assemblés, open source et commerciaux, est comparé en détail dans notre comparatif des outils NL2SQL 2026.

NL2SQL et RAG (retrieval-augmented generation) répondent à deux familles de questions différentes, souvent confondues parce que les deux s'appuient sur un LLM branché à une base de données.

NL2SQL cible les données structurées et relationnelles : combien, quand, quelle proportion, des questions qui se traduisent naturellement en SELECT, GROUP BY, agrégations. Le RAG cible le contenu non structuré : documents, notes, tickets de support, où la réponse ne tient pas dans une ligne de table mais demande de retrouver un passage pertinent par similarité sémantique, recherche vectorielle sur pgvector, index HNSW, avant de le donner en contexte au modèle.

Les deux capacités peuvent coexister dans un même projet et se combiner dans un agent qui choisit l'une ou l'autre selon la question posée. Le pilier IA native d'Aurabase détaille comment les deux mécanismes s'articulent, et notre guide du pipeline RAG sur pgvector couvre l'implémentation du second.