Aller au contenu principal

Agent IA dans n8n : configurer le RAG et les outils pour un agent autonome

Publié le 28 mars 2026 - Mis à jour le 6 avril 2026

Agent IA dans n8n avec RAG et outils - architecture orchestrateur connecte aux API et bases de donnees
Tutoriel vidéo

Le guide en vidéo

Découvrez comment connecter un agent IA à vos documents grâce au RAG dans n8n. Pipeline complète : chargement, découpage, embedding et vector store.

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.

  1. Document Loader : charge le contenu (PDF Loader, Text Loader, HTML Loader, ou un nœud custom via HTTP Request)
  2. Text Splitter : decoupe le texte en chunks. Le Recursive Character Text Splitter est 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
  3. Embedding Model : transforme chaque chunk en vecteur numerique. Options natives dans n8n : OpenAI (text-embedding-3-small ou text-embedding-3-large), Cohere, Mistral, Ollama pour des embeddings locaux
  4. 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

OutilUsageExemple
CalculatorCalculs mathematiquesConvertir des devises, calculer des totaux
CodeExécuter du JavaScript/PythonTransformer des données, valider un format
HTTP Request ToolAppeler une API externeInterroger un CRM, vérifier un stock
Workflow ToolExécuter un autre workflow n8n comme outilDéclencher un envoi d’email, créer un ticket
MCP Client ToolAppeler un serveur MCPAcceder a des outils exposes via le protocole MCP
Vector Store ToolRecherche RAG dans la base vectorielleTrouver 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

IndicateurRésultat
Demandes traitees par le chatbot50 % des demandes entrantes
Disponibilite24h/24, 7j/7 - sans intervention humaine
Usage interneLe service client utilise aussi le RAG comme source documentaire pour traiter les demandes restantes
Impact équipeTemps 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émentDetail
Nœud principalAI Agent (n8n >= 1.19.0, refonte 1.60+)
Types d’agentsTools Agent, ReAct Agent, Conversational Agent
LLM compatiblesClaude (Anthropic), GPT-4/3.5 (OpenAI), Mistral, Ollama (local)
Vector stores natifsPinecone, Qdrant, Supabase Vector, PGVector, Chroma, Weaviate, Zep, In-Memory
Embedding modelsOpenAI (text-embedding-3-small/large), Cohere, Mistral, Ollama
Outils natifsCalculator, Code, HTTP Request, Workflow Tool, MCP Client, Vector Store Tool
MémoireWindow Buffer Memory, Motorhead, Redis
Documentationdocs.n8n.io - AI Agent

Cet article vous a été utile ? Contactez-moi pour en discuter ou pour un projet d'automatisation.

Prendre RDV