Peut-on construire un agent IA de production avec n8n ?

Le nœud AI Agent de n8n est une surcouche de LangChain. Vous lui branchez trois types de sous-nœuds : un modèle de chat, une mémoire, et autant d'outils que nécessaire. Il déroule ensuite la boucle classique, requête, appel d'outil, résultat, recommence, jusqu'à ce que le modèle cesse de demander des outils.

C'est la quarantaine de lignes que vous écririez vous-même, avec la gestion des erreurs et des appels parallèles en prime. Pour un premier agent, c'est plusieurs jours de gagnés, et c'est un vrai argument.

Le point qu'il faut comprendre avant d'aller plus loin : les sous-nœuds ne se comportent pas comme les nœuds normaux. Un nœud classique traite n éléments en entrée et produit n sorties. Un sous-nœud, lui, est appelé par le nœud racine quand celui-ci en a besoin, et la résolution des expressions suit une autre logique. C'est la première source de surprise quand on passe d'un workflow linéaire à un agent.

L'auto-hébergement est une voie de première classe, pas une note de bas de page. C'est la raison pour laquelle les secteurs réglementés le choisissent. L'agent, les données des workflows et les journaux restent sur une infrastructure que vous contrôlez, ce qui raccourcit beaucoup la conversation avec un DPO. Le cadre complet est dans notre guide RGPD et agents IA.

Les intégrations existent déjà. Plusieurs centaines. Un agent qui doit lire un Google Sheet, publier sur Slack et écrire dans Postgres, ce sont trois nœuds, pas trois clients d'API avec leur gestion d'authentification et leurs jetons à faire tourner.

Vous voyez ce qui s'est passé. Chaque exécution montre quel nœud s'est déclenché, avec son entrée et sa sortie. Déboguer un agent qui a choisi le mauvais outil devient un exercice visuel plutôt qu'une lecture de journaux. Sur un projet livré à un client non technique, cette différence vaut beaucoup : il peut regarder lui-même.

Les identifiants sont gérés hors des workflows. n8n sépare les credentials du corps du workflow, ce qui évite le motif le plus fréquent de fuite, la clé d'API écrite en dur dans un nœud de code.

Le nœud de mémoire par défaut s'appelle Simple Memory. Il garde une fenêtre d'historique de conversation indexée par une clé de session, avec un paramètre Context Window Length qui fixe le nombre d'échanges conservés.

Or le mode queue est exactement ce que vous activez pour passer à l'échelle. Dans ce mode, l'instance principale reçoit les déclencheurs et passe l'identifiant d'exécution à Redis, qui tient la file ; un worker disponible la récupère, exécute, écrit le résultat en base. C'est la seule façon d'ajouter de la capacité en ajoutant des machines.

Autrement dit, le mécanisme qui permet de grandir désactive la mémoire par défaut. Ce n'est pas un bug, c'est une conséquence d'architecture, et elle est assumée dans la doc. Mais elle n'apparaît dans aucun tutoriel d'agent n8n, parce que les tutoriels tournent en mode principal sur une seule machine.

La correction est donc simple : en production, Postgres Chat Memory ou Redis Chat Memory. Mais notez ce que vous obtenez même après correction : un historique de conversation, pas une mémoire. Vous ne pouvez pas y stocker « ce client refuse les appels le vendredi » comme un fait durable, le relire, le corriger ou l'auditer. Pour ça il faut un magasin de faits derrière un nœud outil, que vous construisez vous-même. C'est la même conclusion que dans le vrai plafond de votre agent IA.

Un agent qui réfléchit longtemps est souvent celui qui a de la valeur. C'est aussi celui qui rencontre les limites en premier.

Le dépassement mémoire est le mode d'échec le plus désagréable, parce qu'il ne dit pas toujours son nom. La documentation liste les messages à reconnaître : « Execution stopped at this node (n8n may have run out of memory while executing it) », ainsi que « Problem running workflow », « Connection Lost », « 503 Service Temporarily Unavailable », et côté serveur « Allocation failed - JavaScript heap out of memory ».

Sur Cloud et sur l'image Docker officielle, n8n redémarre automatiquement dans ce cas. Sur une installation maison, non : vous découvrez l'incident quand le client vous appelle. C'est un argument pour la supervision avant la mise en production, sujet traité dans déployer un agent IA en production.

Pourquoi un agent consomme-t-il autant ? Parce que chaque tour renvoie toute la conversation et que les résultats d'outils s'y accumulent. Un outil qui retourne deux cents lignes de base de données injecte ces deux cents lignes dans le contexte, et elles y restent pour tous les tours suivants. C'est le même piège que côté MCP, détaillé dans MCP en entreprise.

Un workflow n8n est un document JSON. Tant qu'il décrit « quand un formulaire arrive, écris une ligne dans un tableur », l'absence de versionnage est supportable. Dès qu'il décrit un agent qui tranche sur des dossiers clients, elle devient un problème de gouvernance avant d'être un problème technique.

En dessous de ce palier, il reste l'export manuel en JSON. Techniquement vous pouvez le committer. En pratique personne ne relit un diff de JSON généré, et deux personnes ne peuvent pas valider une modification comme elles valideraient une pull request. Pour un agent qui touche à des données juridiques, médicales ou RH, c'est la question que posera votre premier audit.

Le reproche classique fait à n8n était qu'on ne pouvait pas tester un agent. Ce n'est plus vrai et il faut le dire.

n8n a livré une fonction d'évaluations. Le principe est celui qu'on attend : vous constituez un jeu de cas de test, chacun avec une entrée type et souvent une sortie attendue, vous le faites passer dans le workflow, et des métriques mesurent la qualité des réponses. Leur documentation présente l'exercice comme « la différence entre une preuve de concept instable et un workflow de production solide », et recommande de l'utiliser pendant la construction comme après la mise en ligne.

Ce que ça couvre : la qualité des sorties de l'agent. Ce que ça ne couvre pas : la revue des modifications, la non-régression quand une intégration change de comportement, et l'infrastructure. C'est un vrai progrès, pas un substitut au versionnage.

Lisez les troisième et quatrième lignes ensemble. Passer de Pro à Business, c'est treize fois le prix pour quatre fois les exécutions. Ce que vous achetez réellement dans cet écart, ce ne sont pas les exécutions : c'est la collaboration et le versionnage.

C'est pour cette raison que la plupart des équipes qui franchissent 10 000 exécutions par mois basculent en auto-hébergé plutôt que de payer le palier. Et c'est la demande la plus fréquente qu'on reçoit à propos de n8n, devant toute question technique.

Une exécution d'agent compte pour une exécution, quel que soit le nombre de boucles internes. C'est une facturation généreuse de la part de n8n, et il faut le reconnaître.

Mais le coût qui suit la boucle est ailleurs. Un agent à cinq tours, ce sont cinq appels à l'API du modèle, chacun renvoyant toute la conversation accumulée jusque-là. n8n ne l'affiche nulle part : vous le découvrez sur la facture de votre fournisseur de modèle, le mois suivant.

Deux leviers font l'essentiel du travail. La mise en cache du prompt système et des définitions d'outils, identiques à chaque tour. Et le fait de ne pas laisser un outil déverser des centaines de lignes dans le contexte : paginez, et donnez à l'agent un second outil pour aller chercher le détail d'un seul enregistrement. Les tarifs par modèle et le calcul complet sont dans le prix de l'API Claude en entreprise.

On présente couramment n8n comme open source. Il ne l'est pas au sens de l'OSI. Il est distribué sous Sustainable Use License, un modèle dit fair-code : le code source est lisible et modifiable, l'usage interne est libre, mais la revente comme service hébergé est interdite.

Pour une entreprise qui l'utilise pour elle-même, la contrainte est théorique. Pour une agence qui voudrait revendre du n8n hébergé à ses clients, elle ne l'est pas du tout. Et pour un service public ou un grand compte dont la politique interne exige une licence approuvée OSI, c'est un motif de refus en comité. Les conséquences détaillées, et neuf alternatives réellement ouvertes, sont dans les meilleures alternatives à n8n par licence.

Dans les faits, la plupart de nos déploiements sont hybrides. n8n porte les déclencheurs, les intégrations, les reprises et la supervision visuelle. La logique de l'agent et sa mémoire vivent dans du code, derrière un seul nœud outil HTTP. Vous gardez le débogage visuel là où il aide et le versionnage là où il compte, et vous ne payez pas 667 € par mois pour mettre un JSON dans git.

C'est ce que nous construisons en agents IA sur mesure, et notre façon de travailler en tant qu' agence n8n. Pour voir à quoi ça ressemble en pratique, nos 12 exemples de workflows par secteur donnent les coûts de fonctionnement réels.