La question qu'on nous pose chaque semaine
Un founder demande : « je devrais construire ça dans n8n ou en code ? » La réponse est presque jamais celle qu'il veut. C'est souvent une troisième option qu'il n'avait pas envisagée. Voici comment on décide, et pourquoi « fais-le à la main » est plus souvent le bon appel qu'on ne le pense.
Quand n8n gagne
n8n (et Make, et Zapier, et le reste de cette famille) est la bonne réponse quand :
- Le workflow est principalement de la colle — tirer du système A, transformer, pousser vers le système B. Peu de branchement, peu d'état.
- Il doit changer chaque semaine selon ce que votre équipe sales ou ops apprend. Le code requiert un deploy ; un graphe de nœuds non.
- Les intégrations sont sur étagère — Slack, Gmail, HubSpot, Notion, Airtable. n8n a 400+ connecteurs préfaits et vous écririez des flows OAuth from scratch autrement.
- L'équipe qui possède c'est non-engineering. Un marketeur peut lire un graphe n8n. Il ne peut pas lire un service TypeScript.
Le fit classique c'est « envoyer une alerte Slack quand un deal HubSpot passe en négociation, avec un résumé généré par Claude ». C'est un build n8n de 15 minutes. La même chose en code custom c'est deux jours, six dépendances, et un déploiement Vercel.
Quand le code custom gagne
Le code custom gagne quand :
- Le workflow a un état non-trivial à travers plusieurs étapes — retries, idempotence, récupération d'échec partiel
- Le budget de latence est serré — l'exécuteur n8n ajoute 100–300ms par nœud, et ça s'additionne vite
- Vous avez besoin de gestion d'erreur et observabilité propres — chaque workflow n8n finit avec des nœuds try/catch en forme de sapin de Noël
- Le workflow sera appelé depuis un autre système — endpoints API avec contrats stricts, pas juste des jobs en background
- Vous bougez de la donnée régulée — la story d'audit n8n est mince, et la plupart des stacks régulées ne le tolèrent pas dans la boucle
Le fit classique c'est « un webhook de notre agent voice déclenche un check de conformité multi-étape, persiste le résultat, et peut escalader à un reviewer humain ». C'est là où n8n s'écroule et un service TypeScript de 300 lignes est plus propre.
Quand la réponse est « fais-le à la main »
Voici celle que personne ne veut entendre. Beaucoup de workflows IA que vous envisagez d'automatiser ne devraient pas l'être encore. Pas parce que la techno ne peut pas, mais parce que vous ne comprenez pas encore assez bien le workflow pour l'automatiser.
Les signes qu'il faut le garder manuel un peu plus longtemps :
- Vous ne pouvez pas écrire le workflow comme une checklist sans trois branches « ça dépend »
- Le volume est < 10 instances par semaine — l'automatisation paiera en mois, pas en jours
- Le coût de se tromper est élevé et votre eval set est vide
- Vous l'automatisez parce que c'est intéressant, pas parce que c'est un bottleneck
Faites tourner le workflow à la main pendant deux semaines de plus. Prenez des notes sur ce qui vous coince. Ensuite automatisez, et vous automatiserez la bonne chose.
Le pattern hybride qu'on utilise
Pour la plupart des clients on finit en hybride : n8n possède la colle ennuyeuse (notifications, sync CRM, reporting) et un petit service TypeScript possède le cœur agentique (les appels modèle, la state machine, le trail d'audit). n8n appelle le service via webhook. Le service rappelle n8n quand c'est fait.
Ce split laisse l'équipe non-engineering itérer sur ce qu'elle possède sans toucher au cœur régulé, et laisse l'équipe engineering garder les parties qui comptent sous version control et tests propres.
À retenir
n8n est un multiplicateur pour la colle ops. Le code custom est obligatoire pour tout ce qui est stateful, régulé, ou latence-sensible. Et la question à se poser d'abord est de savoir si le workflow est assez bien compris pour être automatisé tout court. La réponse change plus souvent qu'on ne le croit.