Comment créer un agent IA avec n8n : du prototype à la production
Quelle différence entre un agent IA et un workflow n8n ?
Un workflow n8n exécute une suite d'étapes figées ; un agent IA décide lui-même quel outil appeler, dans quel ordre, et quand s'arrêter. Concrètement, le workflow suit un chemin que vous tracez : si A, alors B, puis C. Vous décidez à l'avance de chaque branche. C'est prévisible, c'est testable, et pour beaucoup de besoins c'est exactement ce qu'il faut.
Un agent IA est différent : il décide quoi faire en fonction de l'entrée, puis il agit. Au lieu de suivre un chemin que vous avez codé, il dispose d'un objectif, d'un modèle de langage qui raisonne, et d'une boîte à outils. C'est l'agent qui choisit quel outil appeler, dans quel ordre, et quand s'arrêter.
Concrètement, dans n8n, cette différence se matérialise par le nœud AI Agent. Ce nœud est basé sur LangChain (intégration n8n-nodes-langchain.agent). Depuis la version 1.82.0, il fonctionne comme un Tools Agent unique qui implémente le tool calling de LangChain : le modèle reçoit la liste des outils disponibles et décide lui-même lesquels appeler.
La conséquence pratique est importante. Un workflow figé échoue de manière prévisible : vous savez où ça casse. Un agent peut échouer de manière créative : il peut choisir le mauvais outil, boucler, ou inventer une réponse. C'est pourquoi un agent demande plus de garde-fous qu'un workflow, surtout en production. Si votre besoin tient en quelques branches déterministes, un workflow simple sera plus robuste et moins cher. Réservez l'agent aux cas où la décision elle-même est la valeur ajoutée.
Les 4 prérequis pour un agent IA n8n : instance, modèle, outil, données
Quatre briques suffisent pour un premier agent fonctionnel : une instance n8n, un modèle de langage (Chat Model), au moins un outil (Tool) et des données de contexte.
1. Une instance n8n. Deux options. Soit l'auto-hébergement : officiellement via Docker (recommandé par n8n) ou via npm (Node.js 20.19 à 24.x). Sans clé de licence, vous tournez en édition Community gratuite. Soit n8n Cloud : pas d'infra à gérer, mais une facturation à l'exécution (voir plus bas).
2. Un modèle de langage (Chat Model). L'agent a besoin d'un cerveau. n8n se connecte à plusieurs fournisseurs via des sub-nodes Chat Model : OpenAI, Anthropic, Groq, Mistral, Azure OpenAI, entre autres. Vous fournissez votre propre clé API du fournisseur choisi ; ce coût est séparé de n8n.
3. Au moins un outil (Tool). C'est ce qui permet à l'agent d'agir, pas seulement de discuter. n8n propose plus de 100 intégrations utilisables comme outils : requête HTTP, exécution de code, Slack, Google Workspace, et beaucoup d'autres. La documentation est claire sur ce point : vous devez connecter au moins un outil à un nœud AI Agent.
4. Des données et un contexte. Un agent sans accès aux bonnes données produit des réponses génériques. Selon votre cas, cela peut être une base de connaissances, une API métier, un dossier de documents, ou un système via MCP (Model Context Protocol), que n8n supporte aussi bien en serveur qu'en client.
Pour un premier prototype, l'édition Community en local et une clé API de modèle suffisent largement. Vous n'avez rien à payer à n8n tant que vous restez en self-hosted.
Construire l'agent, étape par étape
Voici la séquence complète, du déclencheur jusqu'à la production. Chaque étape est détaillée, mais l'idée directrice reste la même : ne jamais sauter les points de contrôle.
- Définir le déclencheur et l'entrée. Choisissez comment l'agent est sollicité. Le
Chat Triggerconvient pour une conversation multi-tours. Pour un agent qui tourne sans humain, utilisez un autre déclencheur : webhook, planification, arrivée d'un email ou d'un fichier. Définissez précisément le format d'entrée attendu. - Poser le nœud AI Agent et son modèle. Ajoutez le nœud
AI Agent, connectez-lui un sub-node Chat Model (OpenAI, Anthropic, Mistral, etc.), et rédigez une instruction système claire : rôle, périmètre, ce que l'agent ne doit pas faire. Une bonne instruction système est votre premier garde-fou. - Brancher les outils. Connectez au moins un sub-node Tool. Commencez minimal : un ou deux outils bien décrits valent mieux que dix outils flous. La qualité de la description de chaque outil détermine si l'agent l'utilise correctement.
- Ajouter la mémoire (si conversation). Pour une conversation continue, attachez un sub-node Memory. Point important vérifié dans la doc : la mémoire ne persiste pas entre les sessions. Si vous avez besoin de persistance durable, prévoyez un stockage externe. n8n recommande de connecter le même sub-node Memory au Chat Trigger et à l'agent, pour une source unique de vérité.
- Insérer les points de contrôle et la validation. C'est l'étape que la plupart des tutoriels sautent. Avant que l'agent ne déclenche une action à conséquence (envoyer un email, écrire en base, publier), ajoutez une vérification : validation de format, règle métier, ou approbation humaine. Loggez chaque décision de l'agent pour pouvoir l'auditer.
- Tester sur des cas réels. Ne validez pas sur un "hello world". Rassemblez des entrées réelles, y compris les cas limites et les entrées malveillantes ou mal formées. Observez ce que l'agent décide, pas seulement ce qu'il répond. Corrigez les instructions et les descriptions d'outils jusqu'à un comportement stable.
- Maîtriser les coûts et les boucles. Posez une limite d'itérations pour éviter qu'un agent ne boucle indéfiniment. Surveillez le nombre d'appels au modèle : un agent peut multiplier les appels LLM sans que vous le voyiez. Définissez un budget et alertez en cas de dépassement.
- Passer en production. Activez le workflow, mettez en place le monitoring (exécutions, erreurs, latence), et conservez les logs de décision. Démarrez avec un périmètre étroit et une supervision humaine, puis élargissez l'autonomie à mesure que la fiabilité se confirme.
La règle d'or : un agent passe en production le jour où son comportement est prévisible sur des cas réels, pas le jour où la démo fonctionne.
Les erreurs fréquentes (et ce qui casse en vrai)
La plupart des agents échouent pour les mêmes raisons. Les connaître à l'avance fait gagner des semaines.
- L'hallucination. Le modèle invente une donnée, un identifiant, une référence. Sans validation en sortie, l'agent agit sur du faux. Parade : vérifier les sorties contre une source de vérité avant toute action.
- Les boucles. L'agent rappelle le même outil sans progresser, ou enchaîne les raisonnements à l'infini. Parade : une limite d'itérations stricte et une condition de sortie explicite.
- Les coûts qui dérapent. Chaque tour d'agent peut déclencher plusieurs appels au modèle. Sur du volume, la facture du fournisseur LLM grimpe vite. Parade : plafonner les itérations, choisir un modèle adapté à la tâche, monitorer la consommation.
- L'absence de garde-fous. Donner à un agent un accès en écriture sans validation revient à le laisser agir à l'aveugle. Parade : points de contrôle avant chaque action à conséquence, et approbation humaine sur les actions sensibles.
- Pas de test sur cas réels. Un agent qui marche sur trois exemples soignés casse sur la quatrième entrée réelle. Parade : tester sur de vraies données, cas limites inclus, avant la mise en production.
- Trop d'outils, trop tôt. Plus l'agent a d'outils, plus il peut se tromper de choix. Commencer minimal, ajouter au besoin.
Aucune de ces erreurs n'est une fatalité. Elles disparaissent quand on traite l'agent comme un système à fiabiliser, pas comme une démo à montrer.
Un exemple concret en production
Pour illustrer ce que "jusqu'à la production" signifie vraiment, voici un cas réel : Opposio (opposio.com), un service en ligne de contestation d'amendes routières françaises. Derrière l'interface, une chaîne d'agents traite chaque dossier.
Le principe suit exactement la logique décrite plus haut. L'agent lit le document reçu, analyse les motifs de contestation possibles, décide de la stratégie pertinente, produit la lettre de contestation, puis l'envoie au bon endroit. Ce n'est pas un workflow figé : à chaque dossier, le contenu et les motifs changent, donc l'agent doit raisonner sur le cas précis.
Ce qui distingue un système en production d'un prototype, c'est le contrôle à chaque étape. Lecture vérifiée, analyse validée, décision contrainte par des règles métier, lettre produite puis contrôlée avant tout envoi. L'agent ne fait jamais d'action à conséquence sans qu'un point de validation l'ait précédé. C'est cette discipline, et non la sophistication du modèle, qui rend le service fiable.
La leçon est généralisable à d'autres domaines (traitement de documents à l'échelle, veille, demandes de retrait, production de contenu) : la valeur d'un agent en production tient moins à sa capacité à impressionner qu'à sa capacité à ne jamais déraper sur un cas réel.
Le faire soi-même ou déléguer ?
Soyons honnêtes : vous pouvez le faire vous-même. n8n est conçu pour ça. L'édition Community est gratuite et self-hostable, l'interface visuelle réduit le besoin de code, et la documentation couvre l'essentiel. Pour un agent interne, un cas d'usage délimité, ou simplement pour apprendre, construire soi-même est la bonne voie.
La question change quand la fiabilité en production et le temps deviennent critiques. Construire un "hello world" prend une après-midi. Construire un agent qui ne casse pas sur des cas réels, qui respecte un budget, qui logge ses décisions et qui résiste aux entrées malveillantes prend bien plus, et demande l'expérience des erreurs décrites plus haut.
Déléguer a du sens quand : l'agent touche à des actions à conséquence (clients, argent, données sensibles), quand le volume rend les coûts et les boucles dangereux, ou quand vous n'avez pas le temps d'itérer sur les garde-fous. C'est précisément le travail de Going for Growth (Fabien Cavanna) : des systèmes n8n auto-hébergeables, avec un seul responsable, conçus pour tourner en production, pas pour faire joli en démo. Des systèmes qui tournent, pas des promesses.
Quel que soit votre choix, la règle reste la même : un agent IA n'est prêt que lorsqu'il est prévisible sur des cas réels. Opposio en est l'illustration, et la méthode est reproductible.