n8n excelle à connecter des systèmes et à déclencher des enchaînements : c'est un orchestrateur, et un très bon. Il devient un mauvais choix dès que la logique métier de votre agent grossit, parce qu'un graphe visuel n'a ni tests, ni revue de code lisible, ni retour arrière propre.

Voici où passe la ligne, et les quatre pièges qui font exploser une facture d'agent en production.

Ce que n8n fait vraiment bien

Connecter. Des centaines d'intégrations prêtes, et un nœud HTTP générique pour le reste. Recoder ces connecteurs est une perte de temps que rien ne justifie.

Déclencher. Sur un horaire, un webhook, un e-mail reçu, un fichier déposé. C'est la couche que personne n'a envie de réécrire.

Rendre visible. Un graphe se montre à un non-développeur. Pour aligner une équipe sur ce que fait un processus, c'est un support supérieur à du code.

Auto-héberger. Point non négligeable : vos données restent chez vous, ce qui change la conversation pour les secteurs contraints.

Le résumé honnête : n8n est excellent en plomberie. Le problème n'est jamais la plomberie.

Où la ligne se déplace : la logique métier

Un agent, ce n'est pas un enchaînement d'appels : c'est une boucle qui décide, agit, observe et recommence. Cette boucle contient des décisions, et les décisions sont de la logique métier.

Le symptôme du dérapage : votre graphe compte plus de nœuds de condition que de nœuds d'action. Vous n'orchestrez plus, vous programmez, dans un environnement qui n'a pas été conçu pour ça.

Ce qui manque alors, et qui manque cruellement : les tests automatisés qui garantissent qu'une modification ne casse rien ailleurs ; une revue de modifications lisible, un différentiel de graphe étant très difficile à relire ; un retour arrière propre ; et la possibilité de rejouer un cas précis pour comprendre une décision.

La bonne architecture : n8n déclenche et connecte, votre logique métier vit dans un service que vous appelez. Le graphe redevient lisible, et la partie qui décide redevient testable.

Les quatre pièges qui font exploser la facture

1. La boucle sans plafond. Un agent qui décide de rappeler un outil jusqu'à satisfaction peut boucler longtemps. Sans plafond d'itérations et de coût, une seule exécution mal partie consomme un budget mensuel. Posez toujours les deux garde-fous.

2. Le contexte qui gonfle. À chaque tour, l'historique complet est renvoyé au modèle. Le coût d'une boucle de quinze étapes n'est pas quinze fois celui d'un appel : il est bien supérieur, parce que chaque étape traîne tout ce qui précède. Résumez ou tronquez explicitement.

3. Le déclencheur trop bavard. Un webhook branché sur un événement fréquent déclenche des exécutions à la chaîne. Filtrez avant d'appeler le modèle, jamais après.

4. Le rejeu silencieux. Une erreur transitoire relance l'exécution ; sans clé d'idempotence, l'action externe part deux fois. En prospection, cela signifie deux messages au même prospect, le genre d'incident qui coûte plus qu'une facture.

Les garde-fous à poser dès le premier agent

Un plafond d'itérations, en dur, avec échec explicite au-delà.

Un plafond de coût par exécution et par jour, avec alerte.

Une clé d'idempotence sur toute action externe : envoi, création, paiement. C'est ce qui rend un rejeu sans danger.

Un journal de ce qui a été décidé, pas seulement de ce qui a été exécuté. Sans la raison, un incident est inanalysable.

Une validation humaine avant les actions irréversibles. C'est notre position par défaut dans CodAgents : les brouillons sont générés, la mise en file est automatique, l'envoi est validé par une personne.

Quand sortir du graphe

Quatre signaux, chacun suffisant.

Vous ne savez plus expliquer ce que fait le graphe. Le signal le plus fiable de tous.

Personne n'ose modifier un nœud existant. On en ajoute un à côté. Six mois plus tard, il y en a quarante, dont douze morts que personne n'ose supprimer.

Vous testez en production. Parce qu'il n'existe pas d'autre moyen de vérifier.

Le même bug revient. Sans test de non-régression, une correction ne tient pas.

Comment sortir : pas en migrant tout d'un coup. Extrayez d'abord les deux ou trois décisions qui portent réellement votre métier, mettez-les dans un service testé, et laissez le graphe appeler ce service. Le reste peut rester dans n8n indéfiniment, une architecture mixte n'est pas un échec, c'est souvent la bonne réponse.

Ce que nous avons fait, et pourquoi

Nous exploitons nos propres agents pour la prospection et le marketing. Relevé de notre code au 18 août 2026 : 643 outils exposés en production, dont 139 pour le seul module SEO et 21 pour la prospection.

Ces outils vivent dans un service testé, pas dans un graphe, précisément pour les raisons de cet article : nous avions besoin de tests, de journaux d'audit et de plafonds non contournables. Un agent ne peut pas relever son propre plafond dans notre système : cela exige un humain administrateur, avec effet le lendemain.

Notre limite, avouée : cette architecture coûte plus cher à démarrer qu'un graphe. Pour valider une idée d'automatisation en trois jours, n8n est le bon choix, et nous l'utilisons aussi.

Questions fréquentes

n8n suffit-il pour un agent IA ? Pour un agent simple, un déclencheur, quelques outils, une décision, oui, très bien. Dès que la boucle décide vraiment, la logique mérite un service testé.

n8n est-il gratuit ? Le projet est disponible en auto-hébergement sous licence, avec une offre infonuagique payante. En auto-hébergement, vous remplacez un abonnement par du temps d'exploitation : sauvegardes, montées de version, disponibilité.

Comment limiter le coût d'un agent sur n8n ? Plafond d'itérations, plafond de coût, filtrage avant l'appel au modèle, et troncature explicite du contexte à chaque tour. Les quatre, pas trois.

n8n ou du code ? n8n pour la plomberie et la validation d'idée ; du code pour la logique qui décide et pour tout ce qui doit être testé, journalisé et repris par quelqu'un d'autre.

---

Nos agents tournent sur un service testé, avec plafonds non contournables et validation humaine. Pour en discuter, écrivez-nous.