n8n Agent IA : Workflows LLM (2026)

Q: Comment intégrer Claude ou OpenAI dans n8n ?

Ajoutez le node Anthropic Chat Model ou OpenAI Chat Model comme sub-node de votre AI Agent. Créez la credential correspondante avec votre clé API (Settings → Credentials), puis sélectionnez le modèle ( claude-sonnet-5 , gpt-4o , etc.). L'agent utilisera automatiquement le modèle attaché pour toutes ses inférences.

Mis à jour : 9 septembre 2026

Un agent IA n8n est un workflow low-code qui combine un node AI Agent, un modèle de langage (OpenAI, Claude, Ollama), une mémoire persistante et un jeu d'outils exécutables pour orchestrer des tâches sans écrire de serveur Python. En 2026, avec la sortie de n8n 1.75, la brique LangChain intégrée et le support natif de MCP, on peut assembler un agent conversationnel branché sur Slack, une base Postgres et Qdrant en moins d'une heure. Honnêtement, c'est le raccourci que j'aurais aimé avoir sur mon premier projet d'agent en clientèle : le guide qui suit détaille l'architecture, les nodes clés et les patterns de production que j'utilise vraiment sur le terrain.

Le node AI Agent de n8n intègre LangChain 0.3 et pilote OpenAI, Claude 5, Gemini 2.5 et tout modèle exposé via Ollama ou Groq, sans écrire une ligne de Python.
La configuration minimale d'un agent en production comprend quatre briques : un déclencheur (webhook ou chat trigger), un modèle, une mémoire (Postgres Chat Memory) et au moins un outil (HTTP Request Tool, Code Tool ou MCP).
n8n s'auto-héberge en Docker en 5 minutes, ce qui règle les problèmes de RGPD et de latence que Zapier et Make imposent aux workflows IA sensibles.
Le support MCP natif (depuis n8n 1.68, avril 2026) permet de brancher un même agent sur un serveur MCP Python et sur des outils n8n internes.
Les patterns de production incluent Error Trigger pour les retries, Execute Sub-workflow pour l'orchestration multi-agents et Langfuse pour la trace des exécutions LLM.

Qu'est-ce qu'un agent IA dans n8n ?

Un agent IA dans n8n, c'est un node bien précis, @n8n/n8n-nodes-langchain.agent, qui enveloppe un modèle de langage et lui donne accès à trois choses : un jeu d'outils qu'il peut invoquer (HTTP, requêtes SQL, appels à d'autres workflows, serveurs MCP), une mémoire qui persiste les tours de conversation entre les exécutions, et un parser de sortie optionnel pour forcer un JSON structuré. Sous le capot, c'est LangChain 0.3 avec la boucle ReAct classique, mais l'assemblage se fait à la souris.

Je vois passer beaucoup d'équipes qui écrivent des agents Python from scratch alors que 80% de leur besoin est un tour de boucle « reçois un webhook Slack → interroge une base → renvoie une réponse structurée ». n8n rend ces boucles triviales tout en gardant la porte ouverte : un node Code vous laisse insérer du Python ou du JavaScript arbitraire quand le low-code ne suffit plus. C'est cette porte qui distingue n8n de Zapier. Chez Zapier, quand vous butez sur le low-code, vous êtes coincé.

Voici les entités clés à garder en tête quand on parle d'agent n8n : le Chat Model (OpenAI Chat Model, Anthropic Chat Model, Ollama Chat Model), le Tools sub-node attaché à l'agent, la Memory sub-node (Buffer, Buffer Window, Postgres Chat Memory), et l'Output Parser (Structured Output Parser avec Zod ou JSON Schema). L'écosystème gravite autour de ces cinq blocs.

n8n vs Zapier vs Make : quel outil pour l'IA en 2026 ?

La question revient chaque semaine dans mes revues d'architecture. Trois outils dominent l'automatisation en 2026 : n8n, Zapier et Make (ex-Integromat). Pour de l'IA agentique en production, ils ne jouent pas la même partition. Voici la comparaison que je donne à mes clients pour trancher :

Critère	n8n 1.75	Zapier	Make
Self-hosted / RGPD	Oui, Docker natif	Non (SaaS uniquement)	Non (SaaS uniquement)
Node AI Agent (LangChain intégré)	Oui, complet	Zapier AI Actions (limité)	Modules OpenAI seulement
Support MCP natif	Oui (depuis 1.68)	Bêta	Non
Code arbitraire (Python/JS)	Oui, node Code + Function	Code by Zapier (limité)	Oui, module Tools
Prix pour 100k exécutions/mois	0 € (self-hosted) ou 50 €	~450 €	~90 €
Courbe d'apprentissage	Moyenne	Faible	Moyenne
Historique d'exécution complet	Illimité (self-hosted)	7 jours	30 jours

Ma recommandation par défaut en 2026 : n8n self-hosted dès que le workflow touche des données sensibles ou que le volume dépasse 5 000 exécutions/mois. Zapier reste pertinent pour les workflows purement SaaS chez les non-techs, et Make brille sur les scénarios de scraping et de transformation lourde. Mais pour des agents IA en production, avec mémoire longue et outils métier, n8n gagne sur tous les axes qui comptent.

Installer n8n en self-hosted avec Docker

La méthode que j'utilise en production s'appuie sur Docker Compose avec Postgres pour la persistance des workflows et de la mémoire conversationnelle. Voici le docker-compose.yml minimum qui tient debout sous charge :

services:
  postgres:
    image: postgres:16-alpine
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 5s

  n8n:
    image: n8nio/n8n:1.75.0
    restart: always
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
    depends_on:
      postgres:
        condition: service_healthy

  redis:
    image: redis:7-alpine
    restart: always

volumes:
  pg_data:

Les trois variables sensibles vont dans un fichier .env à côté : POSTGRES_PASSWORD, N8N_ENCRYPTION_KEY (32 caractères aléatoires, à ne jamais perdre parce que c'est la clé qui déchiffre les credentials stockés) et éventuellement N8N_BASIC_AUTH_USER/PASSWORD si vous ne mettez pas de reverse proxy. Le mode queue avec Redis est essentiel dès que vous exécutez plusieurs agents en parallèle : sans ça, un agent lent bloque toute l'instance.

Une fois docker compose up -d lancé, l'interface est sur http://localhost:5678. La première étape sur une instance neuve : aller dans Settings → Community Nodes et installer @n8n/n8n-nodes-langchain si ce n'est pas déjà inclus (c'est le cas par défaut depuis la 1.60).

Créer votre premier agent avec le node AI Agent

Le workflow minimal qui répond à un message dans un chat de test comprend quatre nodes reliés à un unique node AI Agent. Voici la séquence, en prose :

Un Chat Trigger reçoit l'entrée utilisateur et expose une URL de chat.
Cette entrée est passée au node AI Agent, configuré en type « Conversational Agent ».
Sur la ligne inférieure de l'AI Agent (les sub-nodes), on branche un Anthropic Chat Model avec claude-sonnet-5.
On ajoute une Window Buffer Memory avec une fenêtre de 10 tours pour garder le contexte de la conversation.
Le résultat du node est renvoyé automatiquement au Chat Trigger.

Pour le node AI Agent lui-même, le champ System Message est le point critique. Un prompt système propre (clair sur le rôle, les contraintes et le format attendu) évite 80% des dérapages en production. Un exemple qui marche pour un agent de support :

Tu es Aurore, l'agent de support technique de LabIA.
Règles :
- Réponds en français, ton professionnel et concis.
- Si la question sort du support technique, redirige poliment vers [email protected].
- N'invente jamais de numéros de version ni de références produit ; utilise l'outil `docs_search` pour vérifier.
- Toute réponse finale doit tenir en 4 phrases maximum.

Testez ce workflow dans l'éditeur en cliquant sur Chat en bas à droite, et vous obtiendrez une vraie fenêtre de conversation. En interne, chaque tour est journalisé dans le panneau Executions, avec le prompt exact envoyé au modèle, la réponse brute, les outils appelés et le nombre de tokens consommés. Cette introspection est, à mon avis, le principal argument commercial de n8n face à un agent LangChain écrit à la main.

Ajouter des outils et brancher un serveur MCP

Un agent sans outils est juste un chatbot. Le node AI Agent accepte cinq types d'outils dans son sub-node Tools : HTTP Request Tool (appel REST arbitraire), Code Tool (fonction JS/Python custom), Workflow Tool (invoquer un autre workflow n8n), les Vector Store Tool (interroger Qdrant, Pinecone, Supabase ou pgvector) et depuis avril 2026 le MCP Client Tool.

Le MCP Client Tool change la donne. On peut brancher n'importe quel serveur MCP (développé maison en Python, ou public comme celui de GitHub ou de Slack) et l'agent découvre automatiquement les outils exposés. Pour le côté serveur, notre guide FastMCP en Python couvre la partie construction. Côté n8n, la configuration tient en trois champs :

{
  "endpointUrl": "https://mcp.example.com/sse",
  "authentication": "bearerAuth",
  "toolsToInclude": ["search_docs", "create_ticket"]
}

Une fois branché, chaque outil MCP apparaît comme s'il était natif à l'agent. La boucle ReAct interne décide quand les appeler, et vous voyez chaque invocation dans le journal d'exécution avec les arguments transmis et la réponse reçue.

Mémoire persistante : Postgres, Redis et pgvector

La Window Buffer Memory par défaut vit uniquement dans l'exécution en cours : elle est perdue dès que le workflow se termine. Pour un vrai agent conversationnel qui reconnaît l'utilisateur entre deux sessions, on utilise la Postgres Chat Memory. Elle stocke chaque tour dans une table n8n_chat_histories indexée par une session key que vous choisissez, typiquement l'identifiant utilisateur venant du webhook.

Pour la mémoire longue (au-delà de la fenêtre de contexte du modèle), il faut passer à une mémoire vectorielle : embedder les tours passés, les stocker dans pgvector ou Qdrant, et recharger les plus pertinents à chaque question. n8n gère ce pattern via le sub-node Vector Store Retriever qu'on branche à l'agent en tant qu'outil, pas en tant que mémoire. Le choix du store dépend du volume et des contraintes ops. Nos retours d'usage se recoupent avec ceux de notre guide sur les systèmes multi-agents en Python avec LangGraph, qui applique les mêmes principes côté code.

La configuration pgvector dans n8n :

-- Créer la table côté Postgres
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE agent_memory (
  id BIGSERIAL PRIMARY KEY,
  session_id TEXT NOT NULL,
  content TEXT NOT NULL,
  embedding vector(1536),
  created_at TIMESTAMPTZ DEFAULT now()
);
CREATE INDEX ON agent_memory USING hnsw (embedding vector_cosine_ops);
CREATE INDEX ON agent_memory (session_id);

Côté n8n, on ajoute un Postgres PGVector Store, on branche un OpenAI Embeddings node avec text-embedding-3-small dessus, et on relie le tout à l'agent en tant que Vector Store Tool nommé rappel_conversation. L'agent apprendra tout seul à l'invoquer avec des requêtes du type « qu'est-ce que l'utilisateur m'a dit sur son projet Odyssée la semaine dernière ? ».

Déclencheurs : webhooks, chat trigger et cron

Un agent n8n n'est utile qu'attaché à un point d'entrée bien choisi. Voici les quatre patterns que je déploie régulièrement.

Webhook Trigger : API HTTP publique

Le node Webhook expose une URL https://n8n.example.com/webhook/agent-support qui accepte POST/GET. C'est le déclencheur idéal quand l'agent est appelé par une app web ou un CRM. Attention à activer l'authentification (Header Auth ou Basic Auth) et à valider la charge utile avec un node Edit Fields avant de la passer à l'agent : un webhook non protégé est une pompe à tokens LLM pour n'importe quel bot.

Chat Trigger : interface conversationnelle intégrée

Le Chat Trigger génère automatiquement une page web de chat que vous pouvez embarquer ou partager. Parfait pour les prototypes internes et les démos client. J'ai gagné pas mal de contrats en montrant en 20 minutes un agent branché sur les données du prospect via ce trigger.

Schedule Trigger : agents proactifs

Le Schedule Trigger déclenche l'agent en cron. Utile pour les résumés quotidiens (« lis les 20 derniers tickets et envoie un digest sur Slack »), les surveillances (« vérifie chaque heure si un nouveau lead correspond à ce profil ») ou les jobs de nettoyage.

Événements applicatifs : Slack, Discord, Gmail, Notion

Les triggers natifs Slack/Discord/Gmail réagissent à un message ou un email. Combinés à un agent avec mémoire, on obtient rapidement un assistant qui répond dans un canal comme s'il en était membre.

Gestion des erreurs et observabilité en production

Un agent en démo tourne, un agent en prod se casse. Trois patterns non-négociables :

1. Error Trigger workflow. Créez un workflow dédié qui commence par un node Error Trigger. Attachez-y les workflows critiques via Settings → Error Workflow. Chaque exception (timeout, quota LLM dépassé, outil qui renvoie 500) est routée vers ce workflow, qui peut journaliser en base, poster sur Slack et relancer l'exécution avec un backoff. Sans ça, vos échecs sont silencieux jusqu'au moment où un utilisateur se plaint.

2. Retry sur les nodes fragiles. Chaque node dispose d'un onglet Settings → Retry On Fail. Activez-le sur les nodes d'appel LLM et HTTP externes avec 3 tentatives et un délai exponentiel (2s, 4s, 8s). Cela absorbe les 429 et les blips réseau sans déclencher l'Error Trigger inutilement.

3. Trace LLM via Langfuse. n8n a un node Langfuse qui trace chaque appel LLM avec ses inputs, outputs, tokens et latence. C'est indispensable pour comprendre pourquoi un agent a dépensé 4 dollars sur une requête simple. J'ai debuggé exactement ce cas sur un agent de support la semaine dernière : la trace Langfuse a immédiatement pointé un outil qui renvoyait 15 000 tokens de JSON inutile. Notre guide sur l'observabilité LLM avec Langfuse détaille la configuration côté Python ; le principe est le même côté n8n, il suffit de câbler le node en parallèle de l'AI Agent.

Orchestration : sous-workflows et agents multiples

Un agent monolithique qui doit à la fois classer un ticket, chercher dans la KB, rédiger une réponse et l'envoyer devient rapidement lent et cher. La pratique standard en 2026 est de décomposer en agents spécialisés reliés par des sous-workflows. Le node Execute Sub-workflow appelle un autre workflow n8n de façon synchrone, ce qui permet d'utiliser un workflow entier comme un outil pour un agent parent.

Architecture typique que je déploie pour un support client automatisé :

Agent Triage (petit modèle, claude-haiku-4-5 ou gpt-4o-mini) : classe le ticket entrant en question_produit, bug_technique, facturation, autre.
Agent Produit (modèle standard, RAG sur la doc) : répond aux questions produit.
Agent Technique (modèle standard, outils accès logs et Jira) : investigue les bugs.
Agent Facturation (modèle spécialisé, outils Stripe et CRM) : traite les demandes de remboursement.
Agent Superviseur (LLM juge) : contrôle la qualité de la réponse finale avant envoi.

Chaque agent tourne dans son propre workflow, exposé via Execute Sub-workflow. L'agent Triage est le seul appelé directement par le webhook, et il route vers l'un des trois agents spécialisés. Ce pattern isole les prompts système, permet des A/B tests par agent et réduit la facture LLM de 40 à 60% par rapport à un agent unique qui doit connaître tout le domaine. C'est aussi une bonne manière de garder la main sur les coûts, un sujet qu'on creuse plus en détail dans notre guide d'optimisation des coûts API LLM.

Le versioning : n8n peut synchroniser tous vos workflows sur Git via la fonction Version Control (disponible depuis la 1.20). Chaque modification est un commit, on peut ouvrir des PR sur les workflows, et un environnement staging peut fetcher automatiquement la branche main. C'est le chaînon manquant qui a fait passer n8n du statut de « joli jouet » à « outil de production sérieux » chez la plupart de mes clients. La documentation source control et environnements de n8n détaille les patterns.

Enfin, pour tout ce qui touche à la sécurité des sorties d'agents (injection de prompt, exfiltration de données, contenu toxique), les mêmes principes que côté Python s'appliquent : notre guide sur les guardrails IA en production couvre les patterns à répliquer via des nodes Code ou des outils externes appelés en post-traitement de l'agent. Le changelog GitHub de n8n annonce d'ailleurs pour n8n 1.80 (Q4 2026) un node Content Safety natif qui devrait simplifier tout ça.

Questions fréquentes

n8n est-il gratuit ?

Oui, la version self-hosted (Community Edition) est gratuite et open-source sous licence Sustainable Use License. Vous payez seulement l'infrastructure Docker et les appels API aux LLM. La version cloud managée démarre à 20 €/mois pour 2 500 exécutions.

Comment intégrer Claude ou OpenAI dans n8n ?

Ajoutez le node Anthropic Chat Model ou OpenAI Chat Model comme sub-node de votre AI Agent. Créez la credential correspondante avec votre clé API (Settings → Credentials), puis sélectionnez le modèle (claude-sonnet-5, gpt-4o, etc.). L'agent utilisera automatiquement le modèle attaché pour toutes ses inférences.

n8n peut-il remplacer LangChain ?

Pour 80% des cas d'usage agentiques standard (chatbots, RAG simple, orchestration d'outils), oui : n8n embarque LangChain 0.3 sous le capot et expose les mêmes primitives en low-code. Pour des architectures avec graphes complexes, boucles conditionnelles fines ou évaluations custom, LangGraph en Python reste préférable.

Quelle est la différence entre n8n et Zapier pour les workflows IA ?

n8n est self-hostable, expose un vrai node AI Agent avec outils, mémoire et parser structuré, et supporte MCP nativement. Zapier reste plus simple pour les non-techs et propose plus d'intégrations SaaS pré-faites, mais son support IA se limite à des « AI Actions » sans boucle agentique complète.

Comment donner de la mémoire longue à un agent n8n ?

Utilisez Postgres Chat Memory pour la mémoire tour-par-tour persistante, et ajoutez un Vector Store Tool (pgvector, Qdrant ou Pinecone) branché à l'agent pour la mémoire sémantique longue. La combinaison des deux permet à l'agent de rappeler des faits vieux de plusieurs semaines sans exploser la fenêtre de contexte.

Peut-on versionner un workflow n8n dans Git ?

Oui, depuis la version 1.20, n8n propose une fonctionnalité Source Control (Enterprise et Community) qui synchronise les workflows en JSON avec un dépôt Git. Chaque modification devient un commit, on peut ouvrir des Pull Requests et un environnement staging peut fetcher automatiquement une branche donnée.