Interroger sa base de données en langage naturel avec un agent IA n8n

« Combien de commandes en retard cette semaine ? », « Quel est le panier moyen des clients venus par LinkedIn en juillet ? » — ce genre de question atterrit en général dans un canal Slack adressé à la seule personne de l'équipe qui sait écrire du SQL. Un agent IA n8n branché sur votre base peut absorber une bonne partie de ces allers-retours : il traduit la question en requête, l'exécute, et répond en français avec les chiffres. C'est une mécanique différente d'un pipeline RAG classique — pas de découpage de documents ni d'embeddings, l'agent lit directement le schéma de vos tables et écrit du SQL à la volée. Voici comment la construire proprement dans n8n, et surtout comment ne pas donner les clés de votre base de production à un modèle de langage sans garde-fou.

Le piège du tutoriel obsolète : le node SQL Agent n'existe plus

Si vous cherchez « n8n SQL agent », vous tomberez sur des tutoriels qui pointent vers un node dédié, SQL Agent, rangé parmi les root nodes LangChain. Ce node a été retiré de n8n en février 2025 : les workflows qui l'utilisaient encore doivent être reconstruits. L'approche actuelle, plus flexible, consiste à équiper un node AI Agent standard d'un node Postgres (ou MySQL) configuré comme outil plutôt que comme étape de workflow classique.

Concrètement, sur le node Postgres, l'option Usable as Tool transforme le node en sous-node branché sur l'entrée Tools de l'AI Agent, au même titre qu'un outil personnalisé décrit dans notre guide sur les outils personnalisés de l'AI Agent. L'agent dispose alors de plusieurs actions qu'il choisit lui-même selon la question posée : lister les tables et leur schéma, récupérer la définition détaillée d'une table, puis exécuter la requête SQL qu'il a construite. Rien à coder : l'assemblage se fait entièrement par configuration.

Construire l'agent pas à pas

1. Chat Model — branchez un modèle capable d'appel d'outils fiable (GPT-4o, Claude, Gemini). La qualité du SQL généré dépend directement de cette capacité, comme le détaille notre guide du node AI Agent.
2. Postgres en mode outil — ajoutez le node, activez Usable as Tool, et donnez-lui une description claire de ce sur quoi il porte (« Base de données commerciale : commandes, clients, produits »). C'est cette description que le modèle lit pour décider quand l'appeler.
3. System message — précisez le dialecte SQL (PostgreSQL), une limite de lignes par défaut (« ajoute toujours LIMIT 50 sauf demande explicite d'un volume plus grand »), et surtout les règles métier absentes du schéma : quel statut de commande signifie « livré », quelle colonne fait foi pour le chiffre d'affaires net de remises. C'est exactement l'ancien rôle des variables top_k et dialect qu'imposait le défunt node SQL Agent — sauf qu'aujourd'hui, c'est vous qui les écrivez dans le prompt plutôt que de les remplir dans un champ dédié.
4. Output Parser (optionnel) — si les résultats doivent nourrir un Slack formaté, une ligne de tableur ou un email, contraignez la sortie avec un Structured Output Parser plutôt que de parser un texte libre en aval.

Sécuriser l'accès : le rôle SQL avant le prompt

C'est le point que la plupart des tutoriels expédient en une phrase, alors qu'il est le seul qui compte réellement. Le node SQL Agent historique bloquait par défaut les instructions DML (INSERT, UPDATE, DELETE, DROP) au niveau du prompt d'agent. Un AI Agent générique associé à un node Postgres en mode outil n'a aucune protection de ce type par défaut : si le credential utilisé dispose des droits d'écriture, l'agent peut techniquement écrire.

La seule barrière fiable est en base, pas dans le prompt :

CREATE ROLE agent_lecture LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE monapp TO agent_lecture;
GRANT USAGE ON SCHEMA public TO agent_lecture;
GRANT SELECT ON commandes, clients, produits TO agent_lecture;

Ce rôle dédié, branché sur le credential du node Postgres, garantit qu'aucune requête générée par l'agent — même mal formulée, même manipulée — ne peut modifier une ligne. C'est le principe de moindre privilège appliqué à la lettre : n'exposez que les tables réellement utiles à l'usage prévu, jamais l'ensemble du schéma par facilité. Notre guide sur la sécurisation des credentials API détaille la même logique pour les autres connecteurs.

Deuxième risque, plus subtil : un agent qui lit le contenu de vos données (par exemple un champ commentaire client rempli en texte libre) peut être exposé à une injection indirecte si ce contenu est réinjecté dans une réponse ou dans un raisonnement ultérieur — le mécanisme documenté par Greshake et al. (2023) dans leurs travaux sur l'injection de prompt indirecte, consultables sur Google Scholar. Un rôle en lecture seule limite les dégâts possibles, mais ne dispense pas de filtrer les sorties si l'agent est exposé à des utilisateurs externes — voir notre article dédié à la prompt injection et aux guardrails n8n.

Les limites à connaître avant de mettre ça en production

Un agent texte-vers-SQL n'est pas infaillible, y compris avec les meilleurs modèles actuels. Le benchmark de référence en recherche, Spider (Yu et al., EMNLP 2018, voir sur Google Scholar), a été construit précisément parce que traduire une question en SQL correct devient nettement plus difficile dès que le schéma est inconnu du modèle, comporte plusieurs tables liées entre elles et des noms de colonnes ambigus — ce qui décrit assez bien une base de production réelle, par opposition à une démo à deux tables. Deux implications pratiques :

• Testez avec des questions réelles, pas seulement des cas simples type « combien de clients en France ». Les jointures à trois tables et les agrégations conditionnelles sont là où les erreurs apparaissent.
• Affichez la requête générée, pas seulement le résultat — un simple additionalOutput ou un log dans le canal cible permet à un humain de repérer une requête fausse avant qu'elle ne devienne une décision business erronée.

Cas d'usage concrets

• Support interne Slack : un agent qui répond « la commande #4521 est en statut expédié depuis mardi » sans qu'un humain ouvre le CRM.
• Reporting ad hoc : remplacer les demandes ponctuelles « peux-tu me sortir un chiffre » adressées à l'équipe data par un canal self-service, en lecture seule.
• Complément d'une piste d'audit : coupler l'agent à la même base Postgres/Supabase qui alimente le workflow d'audit du Pack Conformité & Audit (149 €), pour interroger en langage naturel l'historique déjà journalisé plutôt que d'écrire des requêtes SQL à chaque contrôle.

Si votre besoin porte sur des documents plutôt que sur des tables structurées — PDF, contrats, base de connaissances — c'est un problème différent : direction notre guide RAG avec Supabase et le Pack Assistant RAG (119 €), qui couvre l'ingestion, la recherche sémantique et les réponses sourcées plutôt que le SQL généré.

Un agent texte-vers-SQL bien construit fait gagner un temps réel à une équipe qui croule sous les demandes de chiffres ponctuelles. Mais son intérêt tient entièrement à la rigueur de sa mise en place : un rôle SQL en lecture seule, un périmètre de tables restreint, et des règles métier écrites noir sur blanc dans le system message plutôt que supposées évidentes.