Agent IA dans n8n : configurer le RAG et les outils pour un agent autonome
Le nœud AI Agent de n8n permet de créer des agents capables de raisonner, d’utiliser des outils et d’interroger des bases de connaissances. Combine au RAG (Retrieval-Augmented Génération), il transforme un workflow d’automatisation en assistant qui repond à partir de vos données internes - pas à partir de son entrainement general. Cet article detaille l’architecture technique, la configuration pas a pas et un retour de déploiement en production sur un service client.
Mis à jour : mars 2026.
Quel type d'agent IA choisir dans n8n ?
Nombre d'outils externes
Besoin de raisonnement explicite
Conversations multi-tours
Modèle de langage utilisé
Répondez aux 4 questions pour obtenir une recommandation.
Besoin d'aide pour mettre ça en place dans votre entreprise ?
Discutons de votre projet →Architecture du nœud AI Agent dans n8n
Le nœud AI Agent est le composant central des workflows d’intelligence artificielle dans n8n. Introduit dans la version 1.19.0 (octobre 2023) et refondu en profondeur à partir de la version 1.60 en 2024, il fonctionne comme un orchestrateur qui coordonne quatre types de sous-nœuds (documentation officielle).
- LLM : le modele de langage qui raisonne (Claude, GPT-4, Mistral, Ollama)
- Tools : les outils que l’agent peut appeler (HTTP Request, Calculator, Code, Workflow Tool, MCP Client)
- Memory : le stockage du contexte conversationnel (Window Buffer Memory, Motorhead, Redis)
- Output Parser : le formatage structure des réponses (JSON, liste, texte)
L’agent recoit une requête, la transmet au LLM avec le contexte disponible, et le LLM decide quels outils appeler pour construire sa réponse. Ce mecanisme repose sur le function calling - une capacite native des LLM recents comme Claude (Anthropic) et GPT-4 (OpenAI) - qui permet au modele de générer des appels d’outils structures au lieu de texte libre. Source : docs.n8n.io.
Les trois types d’agents disponibles
n8n propose trois modes de fonctionnement pour le nœud AI Agent. Le choix du type determine comment l’agent raisonne et utilise ses outils.
Tools Agent
Le mode le plus utilise. L’agent utilise le function calling du LLM pour choisir quel outil appeler, avec quels parametres, et dans quel ordre. Il peut enchainer plusieurs appels d’outils dans une même requête. C’est le mode recommande pour la plupart des cas d’usage, car il produit les résultats les plus fiables avec les LLM recents. Compatible avec Claude, GPT-4, GPT-3.5 Turbo et Mistral.
ReAct Agent
Le mode ReAct (Reasoning + Acting) alterne explicitement entre phases de reflexion et phases d’action. L’agent ecrit son raisonnement à chaque étape avant de choisir une action. Ce mode est plus lent mais offre une meilleure tracabilite - utile pour le debug ou les taches complexes qui necessitent un raisonnement en plusieurs étapes. Il consomme plus de tokens car le raisonnement intermediaire est envoye au LLM à chaque iteration.
Conversational Agent
Concu pour les echanges multi-tours avec un utilisateur. Il maintient le fil de la conversation via la mémoire et gere les demandes de clarification. Ce mode est adapte aux chatbots et interfaces conversationnelles ou l’utilisateur interagit en plusieurs messages successifs.
Configurer le RAG dans n8n : le pipeline complet
Le RAG (Retrieval-Augmented Génération) permet a l’agent d’interroger une base de connaissances avant de formuler sa réponse. Au lieu de repondre à partir de son entrainement general, il récupéré les documents pertinents et généré une réponse basee sur des données concretes. Le pipeline RAG dans n8n se configure entierement via les sous-nœuds, sans ecrire de code.
Étape 1 - Ingestion des documents
Le workflow d’ingestion transforme vos documents bruts en vecteurs stockes dans une base vectorielle. La chaine de traitement dans n8n suit cet ordre : Un exemple concret de ce type de traitement : classer des factures automatiquement avec n8n.
- Document Loader : charge le contenu (PDF Loader, Text Loader, HTML Loader, ou un nœud custom via HTTP Request)
- Text Splitter : decoupe le texte en chunks. Le
Recursive Character Text Splitterest le plus courant - il decoupe en respectant les limites de paragraphes et de phrases. Taille recommandee : 400-800 tokens avec un overlap de 50-100 tokens - Embedding Model : transforme chaque chunk en vecteur numerique. Options natives dans n8n : OpenAI (
text-embedding-3-smalloutext-embedding-3-large), Cohere, Mistral, Ollama pour des embeddings locaux - Vector Store : stocke les vecteurs. Bases supportees nativement : Pinecone, Qdrant, Supabase Vector, PGVector, Chroma, Weaviate, Zep, In-Memory
Source : docs.n8n.io - Sub-nodes.
Étape 2 - Retrieval au moment de la requête
Quand l’agent recoit une question, le sous-nœud Vector Store Tool (ou Retrieve Documents) convertit la question en vecteur via le même modele d’embedding, puis cherche les N chunks les plus proches dans la base vectorielle. Par defaut, n8n retourne les 4 chunks les plus similaires - ce parametre est configurable dans les options du nœud. Les chunks récupérés sont injectes dans le prompt du LLM comme contexte, et le modele généré sa réponse à partir de ces données.
Options de stockage vectoriel
Le choix de la base vectorielle depend du contexte de déploiement. Pour les projets ou la simplicite et l’interface utilisateur comptent, AnythingLLM offre une solution complete qui intégré le stockage vectoriel, la gestion des documents et une interface de chat - il se connecte a n8n via API ou webhook. Pour une base vectorielle pure intégrée a PostgreSQL, Supabase Vector (pgvector) permet de stocker les vecteurs dans la même infrastructure que les données metier. Pour le prototypage rapide, le mode In-Memory de n8n fonctionne sans configuration externe mais ne persiste pas entre les exécutions.
Les outils que l’agent peut utiliser
La puissance d’un agent depend directement des outils a sa disposition. Dans n8n, chaque outil est un sous-nœud connecte au nœud AI Agent. L’agent lit la description de chaque outil et decide lequel utiliser en fonction de la requête. Une description claire et précise de chaque outil est donc critique - c’est elle qui guide le choix du LLM.
Outils natifs n8n
| Outil | Usage | Exemple |
|---|---|---|
Calculator | Calculs mathematiques | Convertir des devises, calculer des totaux |
Code | Exécuter du JavaScript/Python | Transformer des données, valider un format |
HTTP Request Tool | Appeler une API externe | Interroger un CRM, vérifier un stock |
Workflow Tool | Exécuter un autre workflow n8n comme outil | Déclencher un envoi d’email, créer un ticket |
MCP Client Tool | Appeler un serveur MCP | Acceder a des outils exposes via le protocole MCP |
Vector Store Tool | Recherche RAG dans la base vectorielle | Trouver les documents pertinents pour une question |
Le Workflow Tool est particulierement utile : il permet à un agent d’exécuter un workflow n8n complet comme s’il s’agissait d’un simple outil. Cela permet de decomposer des logiques complexes en workflows dedies, reutilisables et testables independamment. Voir aussi : déployer un serveur MCP dans n8n pour connecter des outils via le protocole MCP.
Mémoire conversationnelle : maintenir le contexte
Sans mémoire, l’agent traite chaque message comme une requête isolee. Le sous-nœud Memory permet de conserver l’historique de la conversation pour que l’agent se souvienne des echanges précédents.
Options de mémoire dans n8n
- Window Buffer Memory : stocke les N derniers messages en mémoire. Simple et efficace. Limite : la fenetre est fixe (par exemple les 10 derniers messages), donc les conversations longues perdent leur debut. Adapte à la plupart des chatbots
- Motorhead : serveur de mémoire externe avec resume automatique des conversations longues. Permet de depasser la limite de tokens en compressant l’historique
- Redis : stockage persistant dans Redis. Adapte aux cas ou la conversation doit survivre à un redemarrage du workflow ou être partagee entre plusieurs exécutions
Point technique : la mémoire consomme des tokens à chaque appel LLM, puisque l’historique est injecte dans le prompt. Avec un LLM facture au token (Claude, GPT-4), une conversation de 50 messages peut representer plusieurs milliers de tokens de contexte à chaque nouveau message. La Window Buffer Memory avec une fenetre de 10-20 messages offre un bon compromis entre contexte et cout.
Retour terrain : un RAG service client en production
Un cas concret de déploiement illustre les choix techniques et les résultats possibles. Un client disposant d’une base documentaire interne (procedures, fiches produit, conditions generales) avait besoin d’un service client disponible 24h/24, 7j/7. L’objectif : repondre aux questions courantes par chatbot pour liberer du temps au service client humain sur les demandes complexes necessitant un appel ou un echange personnalise.
Architecture deployee
La solution combine AnythingLLM pour le stockage vectoriel et l’interface de chat, connecte a n8n pour l’orchestration des workflows. La base documentaire de l’entreprise est indexee dans AnythingLLM, et les requêtes clients transitent par un workflow n8n qui gere la logique metier (routage, escalade, logging). Le LLM utilise est Claude (Anthropic) pour la qualité de ses réponses en francais et le respect des consignes.
Résultats mesures
| Indicateur | Résultat |
|---|---|
| Demandes traitees par le chatbot | 50 % des demandes entrantes |
| Disponibilite | 24h/24, 7j/7 - sans intervention humaine |
| Usage interne | Le service client utilise aussi le RAG comme source documentaire pour traiter les demandes restantes |
| Impact équipe | Temps libere pour les appels et demandes complexes |
Choix du LLM : cloud vs local
Le choix du LLM depend aussi des contraintes de confidentialite. Claude (Anthropic) ou GPT-4 (OpenAI) offrent les meilleures performances en comprehension et génération, mais les données transitent par des serveurs americains. Pour les entreprises soumises a des contraintes reglementaires ou qui manipulent des données sensibles, des LLM locaux deployes via Ollama (Mistral, Llama, Phi) permettent de garder toutes les données en interne. Le compromis : des performances moindres sur les taches complexes, mais aucune fuite de données vers l’exterieur. Avec des données d’entree bien structurees et un RAG bien configure, des modeles plus legers produisent des résultats fiables sur des domaines spécifiques.
Limites et erreurs courantes
Les agents n8n ne sont pas infaillibles. Voici les problèmes les plus frequents constates en production et en accompagnement de clients.
Boucles infinies
L’agent appelle un outil, recoit un résultat ambigu, et rappelle le même outil avec les mêmes parametres. Ce problème survient souvent quand les descriptions d’outils sont vagues ou quand le LLM n’arrive pas a interpreter le résultat. Solution : limiter le nombre d’iterations (parametre maxIterations dans le nœud AI Agent, defaut 10) et ecrire des descriptions d’outils précises avec des exemples de parametres attendus.
Hallucinations malgre le RAG
Le RAG reduit les hallucinations mais ne les elimine pas. Si les chunks récupérés ne contiennent pas la réponse exacte, le LLM peut completer avec des informations inventees. Solution : ajouter une consigne explicite dans le prompt système (“Si l’information n’est pas dans les documents fournis, reponds que tu ne sais pas”) et vérifier la qualité des chunks indexes - des documents mal decoupes ou mal structures produisent des réponses partielles.
Mauvais choix d’outil par l’agent
L’agent selectionne un outil non pertinent pour la requête. Ce problème vient presque toujours d’une description d’outil trop generique. Chaque outil doit avoir une description qui explique precisement quand l’utiliser, quand ne pas l’utiliser, et quel type de résultat il retourne. Exemple : au lieu de “Recherche dans la base de données”, ecrire “Recherche les fiches produit par nom ou reference. Utiliser quand le client pose une question sur un produit spécifique. Retourne le nom, le prix et la disponibilite.”
Données d’entree mal structurees
C’est le problème le plus frequent en entreprise. Le RAG ne peut pas compenser des documents source de mauvaise qualité. Si les procedures internes sont ambigues, si les fiches produit ont des informations contradictoires, ou si les documents ne sont pas à jour, l’agent reproduira ces defauts. La qualité du RAG commence par la qualité des documents indexes.
FAQ
Le RAG dans n8n nécessite-t-il de coder ?
Non. Le pipeline complet - ingestion, embedding, stockage, retrieval - se configure via les sous-nœuds visuels de n8n. Le Document Loader charge les fichiers, le Text Splitter les decoupe, l’Embedding Model généré les vecteurs, et le Vector Store les stocke. Aucune ligne de code n’est nécessaire pour un RAG standard. Le nœud Code n’intervient que pour des transformations spécifiques (nettoyage de données, logique metier custom).
Combien de documents peut gerer un RAG dans n8n ?
La limite depend de la base vectorielle choisie, pas de n8n. Le mode In-Memory convient pour quelques centaines de documents en test. Supabase Vector (pgvector) ou Qdrant gerent des centaines de milliers de vecteurs en production. AnythingLLM permet aussi de gerer des volumes importants avec son propre système de stockage. Le facteur limitant est generalement le cout des embeddings : text-embedding-3-small d’OpenAI coute 0,02 $ par million de tokens (tarif mars 2026).
Peut-on utiliser un LLM local avec l’agent n8n ?
Oui. n8n supporte Ollama comme fournisseur de LLM, ce qui permet d’utiliser des modeles open source (Mistral, Llama 3, Phi-3) heberges sur votre propre infrastructure. Les données ne quittent jamais votre réseau. Le nœud Ollama se configure avec l’URL de votre instance locale et le nom du modele. Les performances varient selon le modele et le hardware - un GPU est recommande pour des temps de réponse acceptables en production.
Quelle difference entre le Workflow Tool et le MCP Client Tool ?
Le Workflow Tool exécuté un workflow n8n interne comme outil de l’agent. Le MCP Client Tool appelle un serveur MCP externe via le protocole standardise (JSON-RPC 2.0). En pratique : utilisez le Workflow Tool pour des logiques internes a votre instance n8n, et le MCP Client Tool pour connecter des outils exposes par des serveurs MCP tiers ou par une autre instance n8n configuree comme serveur MCP.
Comment eviter que l’agent invente des informations ?
Trois leviers : (1) un prompt système explicite qui interdit de repondre si l’information n’est pas dans les documents fournis, (2) un RAG bien configure avec des chunks de qualité et des metadonnees pertinentes, (3) une vérification humaine sur les cas critiques via un workflow de validation (human-in-the-loop). Aucun LLM ne garantit zero hallucination - le système doit être concu pour detecter et gerer les cas d’incertitude.
Fiche technique
| Élément | Detail |
|---|---|
| Nœud principal | AI Agent (n8n >= 1.19.0, refonte 1.60+) |
| Types d’agents | Tools Agent, ReAct Agent, Conversational Agent |
| LLM compatibles | Claude (Anthropic), GPT-4/3.5 (OpenAI), Mistral, Ollama (local) |
| Vector stores natifs | Pinecone, Qdrant, Supabase Vector, PGVector, Chroma, Weaviate, Zep, In-Memory |
| Embedding models | OpenAI (text-embedding-3-small/large), Cohere, Mistral, Ollama |
| Outils natifs | Calculator, Code, HTTP Request, Workflow Tool, MCP Client, Vector Store Tool |
| Mémoire | Window Buffer Memory, Motorhead, Redis |
| Documentation | docs.n8n.io - AI Agent |
