n8n vs code personnalisé pour l'automatisation IA : que faut-il acheter, que faut-il construire

Utilisez un moteur de workflow comme n8n lorsque l'automatisation est interne, à faible volume, et qu'une exécution échouée est un désagrément plutôt qu'un client perdu. Écrivez du code personnalisé lorsque le flux touche des clients, s'exécute des milliers de fois par jour, nécessite de vrais tests, ou contient un prompt LLM que vous allez continuer à affiner. L'erreur coûteuse n'est pas de choisir la mauvaise option. C'est d'en choisir une et de refuser d'en changer quand les signaux indiquent que vous l'avez dépassée.

Pourquoi cette question se pose maintenant

n8n est devenu la réponse par défaut lorsqu'un fondateur dit « on devrait automatiser ça avec l'IA ». C'est un logiciel source-available sous la Sustainable Use License propre à n8n, vous pouvez l'héberger vous-même, et il fournit des nodes pour la plupart des outils SaaS ainsi que des nodes LLM et HTTP génériques. Une personne non technique peut construire quelque chose qui fonctionne en un après-midi. C'est une vraie valeur, et c'est aussi exactement pourquoi les équipes finissent avec une douzaine de workflows fragiles que personne n'ose toucher.

La décision concerne moins n8n contre le code que de savoir quelles parties de votre automatisation méritent une rigueur d'ingénierie. Nous avons couvert la distinction conceptuelle entre agents et workflows dans AI agents vs workflows. Cet article en est la version pratique, celle où l'argent est sur la table.

Dans quoi n8n excelle réellement

Soyons honnêtes sur les forces, car elles sont réelles :

• Rapidité pour obtenir une première version fonctionnelle. L'authentification à Gmail, HubSpot, Slack, Notion et Postgres est un menu déroulant, pas une semaine de plomberie OAuth.
• Visibilité pour les non-ingénieurs. Les équipes ops et commerciales peuvent lire un canvas. Elles ne peuvent pas lire un service NestJS.
• Expérimentations peu coûteuses. Vous pouvez tester si une étape LLM apporte de la valeur avant que quiconque n'écrive une ligne de code de production.
• Plomberie interne. « Quand un deal se conclut, créer un dossier, poster dans Slack, rédiger un email d'onboarding » est le cas idéal. Le volume est faible, l'échec est visible, et un humain est à proximité.

Si votre automatisation se résume entièrement à cette liste, arrêtez de lire et allez la construire dans n8n. Embaucher une agence pour cela serait excessif.

Là où ça commence à faire mal

Les problèmes arrivent progressivement, et chacun, isolément, paraît tolérable.

Les prompts deviennent impossibles à tester

Un prompt LLM dans un node est une chaîne de caractères dans une base de données. Il n'y a ni diff, ni review, ni suite d'évaluation. Quand la qualité de la sortie dérive, le seul outil de débogage consiste à relancer le workflow et à scruter le résultat. Comparez cela avec la façon dont le prompt de notre propre moteur d'outreach vit : un fichier versionné, un ensemble fixe de sites web de prospects comme fixtures, et un schéma de sortie strict que chaque email rédigé doit respecter. Quand nous avons remplacé l'appel à l'action, passant d'un lien de calendrier à « répondez OUI », c'était un diff d'une ligne que quelqu'un pouvait reviewer et annuler. Quand la précision de l'extraction baisse, un test échoue en CI au lieu qu'un commercial le remarque une semaine plus tard. Si vous prenez la fiabilité au sérieux, lisez deterministic guardrails for AI features. Presque rien de tout cela n'est ergonomique dans un éditeur visuel.

La gestion des erreurs, là où les outils visuels perdent

Un vrai pipeline a besoin de : retries avec backoff, idempotence pour qu'un retry n'envoie pas l'email deux fois, gestion des dead-letter pour les entrées que le LLM ne peut pas analyser, et alertes quand une exécution planifiée ne se produit silencieusement pas. Reprenons le moteur d'outreach. Un crawl Firecrawl peut expirer sur un site de prospect lent, le LLM local peut renvoyer quelque chose qui échoue au schéma de sortie, et une exécution relancée ne doit pas envoyer un deuxième email de prospection à la même entreprise. Chacun de ces cas est possible dans n8n. Chacun est aussi un enchevêtrement de nodes et de branches supplémentaires qui rend le canvas illisible, ce qui annule le seul avantage que le canvas avait. En code, ce sont quelques patterns bien connus : un wrapper de retry autour du crawl, une vérification de schéma qui route les échecs vers une file de review, et un drapeau « envoyé » par entreprise vérifié avant que quoi que ce soit ne parte.

Le volume change l'économie du problème

À dix exécutions par jour, personne ne se soucie de la façon dont un workflow est exécuté. À dix mille, vous vous souciez de la concurrence, de la profondeur de la file d'attente, et de la manière dont les logs d'exécution sont stockés et purgés. n8n peut évoluer en mode queue, mais à ce stade vous gérez de l'infrastructure de toute façon, et vous avez pris le coût opérationnel d'un moteur de workflow sans obtenir la testabilité du code. Vous pourriez tout aussi bien posséder le code.

Propriété et verrouillage fournisseur

La licence de n8n est permissive pour un usage interne mais restreint le fait de l'offrir comme service hébergé à des tiers. Si l'automatisation fait partie de ce que vous vendez, vérifiez la licence avec quelqu'un qui lit les licences, et considérez que la logique doit vivre dans du code que vous possédez entièrement. Il en va de même pour tout ce qui comporte une exposition réglementaire : les journaux d'audit, la résidence des données et le contrôle d'accès sont plus faciles à prouver quand le flux est un service que vous contrôlez de bout en bout.

Un exemple concret tiré de notre propre stack

Nous faisons tourner notre moteur d'outreach sur du code personnalisé, pas sur un outil de workflow, et la raison est instructive. Le pipeline crawle le site web de chaque prospect avec une instance Firecrawl auto-hébergée, transmet le contenu à un LLM local, et produit un email personnalisé par entreprise. Le premier instinct était une chaîne multi-étapes : un appel pour extraire les faits, un autre pour choisir un angle, un autre pour rédiger. Nous l'avons essayé, et avons aussi essayé un seul appel qui extrait les faits et rédige l'email ensemble, avec un schéma de sortie strict. La version à appel unique a gagné à la fois en coût et en qualité. Nous approfondissons le pourquoi dans single call vs agent chains.

Le point pertinent ici : découvrir cela a nécessité des dizaines d'exécutions contrôlées sur le même jeu de fixtures, en comparant les sorties côte à côte, et en changeant une variable à la fois. C'est un harnais de test, et c'est trivial dans un repo TypeScript. C'est misérable dans un canvas drag-and-drop. Si nous avions construit le moteur dans n8n, nous ferions probablement encore tourner la chaîne plus lente et plus coûteuse, car le coût d'expérimentation aurait été trop élevé.

Deuxième leçon tirée du même outil : le plus grand gain en taux de réponse est venu d'un changement de copy, pas d'un changement de modèle. Remplacer l'appel à l'action d'un lien de calendrier par un « répondez OUI » plus doux a constamment obtenu plus de réponses des prospects froids. Ce changement a pris une ligne dans un prompt versionné. Pouvoir le faire et le mesurer à moindre coût est tout l'argument en faveur du code quand le flux compte pour le revenu.

Un cadre de décision applicable en dix minutes

Notez chaque automatisation sur ces cinq questions. Trois réponses « oui » ou plus signifie qu'il faut la construire en code.

1. Un client voit-il directement la sortie ? Emails, réponses WhatsApp, devis, réponses support.
2. Va-t-elle s'exécuter plus de quelques centaines de fois par jour dans l'année ?
3. Contient-elle une étape LLM dont vous allez continuer à affiner la qualité ? Extraction, classification, rédaction.
4. Une exécution échouée ou dupliquée coûte-t-elle de l'argent ou de la confiance ? Double facturation, double envoi, leads manqués.
5. Touche-t-elle des données réglementées ou sensibles ? Santé, finance, gouvernement, données personnelles de résidents de l'UE ou du Golfe.

Zéro ou un « oui » : n8n, construit par quiconque possède le processus. Deux : n8n pour l'orchestration, mais gardez les prompts et les règles métier dans un petit service de code que n8n appelle via HTTP. Ce modèle hybride est sous-estimé. Il conserve le canvas lisible pour les ops tout en offrant à l'ingénierie un cœur testé et versionné. Trois ou plus : du code, avec n8n tout au plus comme source de déclenchement.

À quoi ressemble l'hybride en pratique

• Une petite API NestJS ou Next.js avec un endpoint par capacité : extract-company-facts, draft-email, qualify-lead.
• Les prompts, les schémas Zod pour la sortie structurée, et les fixtures vivent dans le repo et s'exécutent en CI.
• n8n gère les aspects ennuyeux : déclencheurs cron, récupération depuis le CRM, publication sur Slack.
• Quand le volume ou les exigences de fiabilité augmentent, vous remplacez l'orchestration n8n par une file d'attente. Rien ne change dans la logique.

Cela simplifie aussi la question du recrutement. Vous pouvez faire réaliser le câblage n8n par une personne ops ou un freelance. Vous faites venir des ingénieurs pour le service, qui est la partie nécessitant des tests et un plan de maintenance. Pour avoir une idée réaliste de ce que représente ce coût continu, voir the real maintenance cost of an AI agent.

Que demander à qui vous embauchez

• « Quelles parties de ceci garderiez-vous délibérément hors de n8n, et pourquoi ? » Une bonne réponse mentionne les prompts, les retries et l'idempotence.
• « Comment allons-nous tester un changement de prompt avant qu'il ne passe en production ? » Si la réponse est « on lance le workflow et on vérifie », continuez à chercher.
• « Que se passe-t-il quand le LLM renvoie du charabia à 3 heures du matin ? » Vous voulez entendre parler de file dead-letter, d'alerte, et d'une étape de revue humaine.
• « Qui possède les prompts et les schémas, et où vivent-ils ? » La réponse devrait être « vous, dans votre repo ».

En résumé

n8n est un excellent outil de prototypage et un bon foyer pour la plomberie interne. C'est un mauvais foyer pour la logique IA qui génère du revenu, parce que cette logique a besoin d'expérimentations, de tests et d'un historique de versions, et que les outils visuels rendent ces trois éléments coûteux. Prototypez dans n8n, prouvez la valeur, puis déplacez le cœur dans du code que vous possédez. Si vous voulez de l'aide pour tracer cette ligne selon votre stack spécifique, parlons-en.