
Un agent IA dans n8n est un workflow dont l'étape centrale, le nœud AI Agent, reçoit une consigne en langage courant, choisit lui-même les outils à appeler et décide du moment où sa tâche est terminée. Pour un profil métier, cela revient à confier à n8n un objectif plutôt qu'un enchaînement d'actions figé.
Ce guide décrit l'outil tel qu'il se présente en octobre 2026, puis déroule une procédure en six étapes, sans code. Si vous découvrez la plateforme, commencez par notre présentation de n8n.
Un agent IA dans n8n, c'est quoi ?
La documentation de n8n emploie quelques termes qu'il vaut mieux poser dès le départ :
- Nœud racine, c'est le nœud principal d'un groupe de nœuds (cluster) : ici, le nœud AI Agent.
- Sous-nœud, c'est un nœud branché sous le nœud racine pour le configurer : le modèle, la mémoire, chacun des outils.
- Outil (tool), c'est une action que l'agent a le droit de déclencher : lire un agenda, appeler une API, lancer un autre workflow.
- Exécution, c'est un passage complet du workflow, du déclencheur au dernier nœud.
Pour la notion d'agent en général, reportez-vous à notre article sur ce qu'est un agent IA.
Ce que le nœud « AI Agent » ajoute à un workflow
Dans un workflow ordinaire, chaque nœud fait une chose précise puis passe la main. Le nœud AI Agent, lui, reçoit un modèle de chat et au moins un outil, et décide seul lesquels appeler pour accomplir la tâche.
Depuis la version 1.82.0, tous les nœuds AI Agent fonctionnent comme un agent à outils (Tools Agent). Deux options comptent d'emblée :
- Message système : il porte vos consignes.
- Max Iterations : fixé à 10 par défaut, il borne le nombre de passages du modèle avant la réponse.

Agent ou workflow classique : qui décide de la séquence
Un workflow classique peut très bien appeler un modèle à une étape donnée. Ce qui change avec l'agent, c'est l'auteur du chemin parcouru.
Les deux approches, critère par critère :
| Critère | Workflow classique | Agent n8n |
|---|---|---|
| Séquence décidée par | Vous, sur le canvas | Le modèle, à chaque exécution |
| Mémoire | Données de l'exécution | Historique de conversation |
| Outils mobilisés | Tous, dans l'ordre dessiné | Ceux jugés utiles |
| Cas type | Copier une commande | Croiser plusieurs sources |
| Limite principale | Casse hors des branches prévues | Mauvais outil ou boucle |
Un agent peut appeler le même outil plusieurs fois au cours d'une exécution, quand un workflow classique suit son tracé une seule fois.
Les quatre briques d'un agent n8n
Sur le canvas, un agent se reconnaît à sa forme : un déclencheur à gauche, le nœud AI Agent au centre, et sous lui les connecteurs du modèle, de la mémoire et des outils.

Le modèle (Chat Model)
Le modèle de chat est le moteur de décision et se branche comme un sous-nœud. Selon la documentation du nœud au 01/10/2026, les modèles compatibles avec l'agent sont ceux d'OpenAI (l'éditeur de ChatGPT), d'Anthropic (Claude), de Mistral Cloud, de Groq et d'Azure AI Foundry.
n8n propose aussi des nœuds pour Gemini ou Ollama (modèle local), sans les citer dans cette liste : testez l'appel d'outils avant de les retenir.
La mémoire
Sans mémoire, l'agent traite chaque message comme le premier. Simple Memory stocke l'historique dans les données du workflow, avec une clé de session qui sépare les conversations et une fenêtre qui fixe le nombre d'échanges conservés.
La documentation interdit de l'utiliser en mode file d'attente (queue mode), où rien ne garantit que chaque appel atteigne le même worker. Pour un agent durable, préférez une mémoire adossée à une base : Postgres Chat Memory, Redis Chat Memory ou Xata, entre autres.
Les outils (tools)
Les outils fixent ce que l'agent peut faire hors de la conversation. Quand un logiciel n'a pas de nœud dédié, le HTTP Request Tool interroge directement son API.
Les quatre familles d'outils et ce que chacune apporte :
| Outil | Apport à l'agent | Exemple |
|---|---|---|
| Nœud d'application | Agir dans un logiciel | Lire des disponibilités |
| Call n8n Workflow Tool | Lancer un sous-workflow | Vérifier un contrat client |
| HTTP Request Tool | Appeler une API | Interroger un annuaire |
| MCP Client Tool | Outils d'un serveur MCP | Service exposé en MCP |
Sur un nœud d'application comme Google Calendar ou Gmail, l'agent renseigne lui-même une partie des paramètres. Le sous-workflow appelé démarre, lui, par un Execute Sub-workflow Trigger.
Le sous-workflow comme outil est la pièce maîtresse en entreprise : il cache derrière une seule action (« vérifier le contrat d'un client ») une logique déterministe que vous maîtrisez. L'agent décide quand l'appeler, jamais comment il fonctionne.
Chaque outil porte aussi une description, que le modèle lit pour choisir : une description vague donne un agent hésitant.
Le déclencheur
Le déclencheur fixe quand l'agent se met au travail et sous quelle forme il reçoit la demande. Le nœud Webhook, par exemple, applique à n8n le principe du webhook.
Trois déclencheurs utiles pour un agent :
| Déclencheur | Lance l'agent sur | Point d'attention |
|---|---|---|
| Chat Trigger | Un message de chat | Chat privé en construction |
| Webhook | Un appel entrant | URL de test puis de production |
| Schedule Trigger | Une horloge ou un cron | Workflow à publier |
Le Chat Trigger existe en Hosted Chat, l'interface fournie par n8n, ou en Embedded Chat, à intégrer dans votre propre interface. L'URL de production d'un Webhook ne s'active qu'une fois le workflow publié.
Construire son premier agent IA dans n8n, étape par étape
Prenons un exemple type : un agent d'agenda qui, depuis un chat interne, propose des créneaux à un commercial et pose le rendez-vous dans Google Calendar. Les six étapes valent pour n'importe quel autre agent.
Étape 1 : délimiter la tâche et choisir le déclencheur
Écrivez la mission en une phrase : « Trouver un créneau libre de 30 minutes dans les cinq jours ouvrés et créer l'invitation. » Le reste est hors périmètre. La demande arrive par une conversation : ce sera donc un Chat Trigger, laissé privé pendant la construction.
Étape 2 : ajouter le nœud AI Agent et son modèle
Reliez le nœud AI Agent au déclencheur, puis branchez un modèle de chat sur le connecteur prévu. Ajoutez Simple Memory pour les premiers essais : sans elle, l'agent oublierait d'un message à l'autre le créneau qu'il vient de proposer.
Étape 3 : connecter les outils dont l'agent a besoin
Deux outils, pas plus : Google Calendar en lecture des disponibilités (opération Availability), et Google Calendar en création d'événement, chacun avec une description qui dit quand s'en servir.
Placez la création d'événement derrière une validation humaine : dans le panneau des outils, la section Human review soumet un outil à l'approbation d'une personne, via le chat de n8n, Slack, Microsoft Teams ou Gmail notamment. En cas de refus, l'action n'a pas lieu et l'agent en est informé.

Étape 4 : écrire les instructions système
Le message système contient ce que l'agent doit savoir à chaque exécution. Pour notre agent d'agenda, quatre blocs suffisent :
- le contexte : fuseau horaire, plages ouvrées, durée par défaut d'un rendez-vous ;
- la méthode : toujours vérifier la disponibilité avant d'avancer un horaire ;
- les limites : ne jamais déplacer ni supprimer un événement existant ;
- la sortie de secours : sans créneau libre, le dire et proposer d'élargir la recherche.
Notre guide de prompt engineering détaille la façon de structurer ce genre de consigne.
Étape 5 : tester sur des cas réels
Dialoguez avec l'agent dans le chat de l'éditeur, option Return Intermediate Steps activée pour voir quel outil est appelé et avec quels paramètres. Testez des demandes ambiguës (« jeudi après-midi », « la semaine prochaine sauf lundi »).
Les évaluations légères de n8n (en auto-hébergé, à partir de la Community Edition enregistrée) vont plus loin : elles passent un jeu d'exemples, rangé dans une data table ou un Google Sheets, à travers le workflow ligne par ligne, et inscrivent chaque sortie en regard.
Étape 6 : mettre sous surveillance
Une fois le workflow publié, chaque exécution apparaît dans l'onglet Executions. Associez-lui un workflow d'erreur, qui démarre par un nœud Error Trigger et vous prévient dès qu'une exécution échoue. Relisez aussi un échantillon de conversations chaque semaine : c'est là qu'apparaissent les demandes mal comprises.
Trois cas d'usage concrets en entreprise
Trois exemples types, présentés selon la même grille.
Router et traiter les demandes entrantes
Prenons un éditeur de logiciel dont le formulaire de contact mélange incidents, facturation et démonstrations.
- Déclencheur : un Webhook qui reçoit chaque envoi du formulaire.
- Outils : un sous-workflow « fiche client » qui retrouve le contrat à partir du domaine de l'adresse email, un HTTP Request Tool vers l'outil de tickets, le nœud Gmail pour préparer un brouillon d'accusé de réception.
- Résultat : chaque demande arrive dans la bonne file avec son contexte client, puis un nœud Slack placé après l'agent prévient l'équipe concernée.
Qualifier et enrichir des données
Prenons une équipe marketing qui récupère des centaines de contacts de salons, aux intitulés de poste saisis à la main.
- Déclencheur : un Schedule Trigger qui tourne chaque nuit sur les nouvelles lignes de la base.
- Outils : un HTTP Request Tool vers une API d'annuaire d'entreprises, un sous-workflow qui applique votre grille de scoring, un nœud de base de données (Airtable, Google Sheets ou équivalent) pour écrire le résultat.
- Résultat : chaque contact reçoit un secteur, une taille d'entreprise, une fonction normalisée et un score ; ceux que l'agent n'a pas pu rattacher avec certitude sont marqués « à vérifier ».
Réglez ici le plafond d'itérations avec soin : sur un lot, un contact introuvable peut déclencher des recherches en série.
Produire et diffuser un livrable récurrent
Prenons une société de services dont les chefs de projet reconstituent chaque lundi l'état de leurs chantiers.
- Déclencheur : un Schedule Trigger chaque lundi à 7 h.
- Outils : un sous-workflow par source (gestion de projet, temps saisis, tickets ouverts) et un nœud de messagerie pour la diffusion.
- Résultat : une note par projet qui signale les jalons dépassés, les budgets qui dérivent et les points à arbitrer.
Les sources sont fixées par les sous-workflows ; l'agent choisit ce qui mérite d'être signalé.
Limites et points de vigilance
Le coût des appels et les boucles d'agent
Le coût d'un agent n8n se répartit sur plusieurs postes, dont aucun ne se chiffre à l'avance :
| Poste | Facturé par | Varie selon |
|---|---|---|
| Plan n8n Cloud | n8n | Exécutions mensuelles |
| Appels au modèle | Fournisseur d'IA | Passages du modèle |
| Gateway credits | n8n, à la requête | Requêtes aux modèles |
| Instance auto-hébergée | Hébergeur, licence n8n | Infrastructure et édition |
Les Gateway credits sont réservés aux offres Cloud Starter et Pro, depuis la version 2.36.0. En auto-hébergé, la Community Edition est gratuite, mais les fonctions avancées (SSO, Git, environnements) demandent une licence Business ou Enterprise.
Les appels au modèle varient le plus : il peut être sollicité plusieurs fois par exécution, jusqu'au plafond d'itérations, et un agent qui hésite entre deux outils coûte plus cher. Trois leviers :
- Le plafond : un Max Iterations ajusté à la tâche.
- Les descriptions : des outils décrits sans ambiguïté.
- La mémoire : une fenêtre courte.
Données, confidentialité et auto-hébergement
C'est l'argument qui distingue n8n pour une entreprise : la plateforme s'installe sur votre propre infrastructure, sur site ou dans un cloud privé, avec Docker Compose notamment. Sans clé de licence, elle tourne en Community Edition, l'édition gratuite. Trois précisions :
- La licence. n8n est distribué sous Sustainable Use License, un modèle fair-code : le code source est consultable, mais l'usage est restreint, notamment aux besoins internes de l'entreprise. n8n ne se dit pas open source.
- Le périmètre. La Community Edition reprend presque toutes les fonctionnalités, sauf notamment le SSO, les environnements, le contrôle de version via Git et les secrets externes.
- Le modèle. Si l'agent envoie ses prompts à un fournisseur externe, héberger n8n ne suffit pas : il faut aussi un modèle local (Ollama, par exemple), capable d'appeler des outils.
Côté Make, la documentation décrit un agent on-premise, réservé aux clients Enterprise, qui permet aux scénarios d'atteindre les applications de votre réseau local sans toucher au pare-feu. C'est un pont vers vos systèmes ; avec n8n auto-hébergé, c'est la plateforme entière qui s'exécute chez vous.
Quand un workflow classique suffit
Si la séquence s'écrit à l'avance, sans « ça dépend », l'agent est superflu. n8n propose des nœuds IA plus simples, au comportement plus prévisible :
- Basic LLM Chain : envoie un prompt au modèle, avec un format de réponse imposé si besoin.
- Text Classifier : range une donnée entrante dans des catégories que vous définissez.

Le construire soi-même ou le faire construire ?
Un premier agent interne, comme l'agent d'agenda, se monte très bien en autonomie, surtout si quelqu'un dans l'équipe a déjà publié des workflows n8n.
La question change quand l'agent écrit dans vos outils de gestion, échange avec des clients, ou doit tourner sur une instance auto-hébergée qu'il faudra sécuriser et maintenir. Tout se joue alors sur l'architecture : sous-workflows exposés, validations humaines, mémoire.
C'est le métier de notre agence n8n : Alegria.solutions prend en charge vos projets n8n, du design au développement et à la mise en production. Si le besoin dépasse un seul agent, notre offre d'automatisation couvre l'ensemble de vos flux.
Si l'enjeu est plutôt de rendre votre équipe autonome, Alegria.academy forme des profils métier à concevoir leurs propres automatisations avec l'IA.





