La plupart des projets qu'on reçoit pourraient techniquement tourner sur n8n. Ça ne veut pas dire qu'ils devraient. La vraie question n'est pas "quel outil", c'est "quel outil pour ce niveau de complexité, ce niveau d'exigence, et cet horizon de maintenance".
Ce que n8n fait très bien
Soyons clairs : n8n est un bon outil. Il y a des cas où on le recommande sans hésitation, et même où on le déploie nous-mêmes.
Les intégrations rapides, sans ambiguïté
Quand un client a besoin de connecter deux SaaS en trois semaines, avec une logique linéaire (si événement A, alors action B dans l'outil C), n8n est difficile à battre. L'écosystème de connecteurs est large, la prise en main est rapide pour un profil non-technique, et le time-to-value est réel.
Exemple concret : une équipe commerciale qui veut envoyer automatiquement un résumé Slack chaque fois qu'un deal passe en "Gagné" dans leur CRM. Pas besoin de coder. n8n gère ça en quelques heures, y compris le déploiement.
Les automations pilotées par un business user
Il y a une catégorie de flux qu'on appelle en interne "automations de confort" : des tâches répétitives, à faible criticité, où l'équipe opérationnelle a besoin de pouvoir modifier le comportement sans passer par un développeur. n8n est fait pour ça. L'interface visuelle devient un avantage réel quand la personne qui maintient le flux n'est pas ingénieure.
Le prototypage de faisabilité
Avant de coder un pipeline complet, il arrive qu'on construise une version n8n pour tester une hypothèse d'intégration. C'est rapide, c'est lisible, et ça permet de valider la logique avec le client avant d'investir dans du code de production.
Pourquoi on code par défaut
Pour tout le reste, on écrit du code. Ce n'est pas du dogmatisme pro-engineering : c'est une décision qui vient de la réalité des projets en production.
La logique complexe se gère mal en visuel
n8n est un outil de composition : tu relies des noeuds, tu passes des données, tu conditionnes des branches. Ça fonctionne très bien jusqu'à un certain point de complexité. Au-delà, le canvas devient illisible, les transformations imbriquées dans des expressions JavaScript dispersées dans vingt noeuds deviennent impossibles à auditer, et le débogage vire au cauchemar.
On a repris un projet de ce type il y a quelques mois : un workflow n8n d'environ 80 noeuds qui gérait la qualification de leads entrants pour un client dans le secteur média. La logique métier (scoring, déduplication, enrichissement, routing) était éparpillée dans des expressions custom à l'intérieur des noeuds. Personne ne pouvait dire avec certitude ce que le flux faisait dans les cas limites. On l'a réécrit en Python en deux semaines. Le résultat : un code de 600 lignes, testé unitairement, documenté, avec des logs structurés. Le comportement était identique, mais auditable.
L'observabilité fine, ça ne s'improvise pas
En production, un système autonome doit être observable : on a besoin de savoir exactement ce qui s'est passé, pourquoi une exécution a échoué, quel volume a transité, où est le goulot. n8n a des logs d'exécution basiques, mais ils ne permettent pas de brancher des systèmes de monitoring avancés sans des contournements fastidieux.
Sur le projet Périscope, notre système de monitoring opérationnel, toute la couche d'ingestion et de traitement est en code custom. Ça nous permet de pousser des métriques précises vers des dashboards temps réel, de définir des seuils d'alerte granulaires, et de rejouer des exécutions en erreur avec contexte complet. Rien de ça n'aurait été proprement faisable avec un outil no-code ou low-code.
L'ownership client est une question de fond
Quand un client investit dans un système qui va tourner en production pendant trois ans, on a une responsabilité : le laisser avec quelque chose qu'il peut comprendre, auditer, faire évoluer, et si nécessaire reprendre sans nous. Un workflow n8n est propriétaire de fait : il dépend de l'instance, de la version, des connecteurs maintenus par l'éditeur. Un service Python ou TypeScript bien documenté appartient vraiment au client. Il peut le faire tourner où il veut, avec qui il veut.
Ce n'est pas un argument contre n8n en soi. C'est un argument pour la clarté sur ce qu'on livre.
La performance à l'échelle
n8n n'est pas conçu pour le traitement en volume. Sur des flux à fort débit (plusieurs milliers d'événements par heure, orchestration de batch processing, pipelines avec retry logic complexe), les limites de l'outil deviennent vite structurelles. Ce n'est pas une critique : n8n cible les intégrations ponctuelles, pas le throughput industriel. Pour Turismo, le projet de scaling d'infrastructure qu'on a livré l'année dernière, le volume de données à orchestrer rendait l'approche low-code simplement hors-sujet dès le départ.
Le vrai critère de décision : la dette de maintenance
La vraie question n'est pas "est-ce que ça marche aujourd'hui", c'est "est-ce que ça tient dans 18 mois sans que je doive tout refaire."
Voici comment on tranche en pratique :
| Critère | n8n | Code custom |
|---|---|---|
| Logique métier | Simple, linéaire | Complexe, conditionnelle |
| Mainteneur cible | Profil ops / business | Développeur interne ou externe |
| Volume | Faible à modéré | Fort, ou croissance prévue |
| Observabilité | Logs basiques suffisent | Métriques fines requises |
| Durée de vie prévue | Court terme, pilote | Long terme, production |
| Criticité | Faible (si ça plante, pas grave) | Élevée (interruption = impact business) |
Ce tableau n'est pas une règle absolue. Il y a des projets en production sur n8n qui tiennent très bien depuis des années. Mais quand plusieurs critères dans la colonne de droite s'accumulent, le custom devient moins un choix technique qu'une nécessité opérationnelle.
Ce que ça change concrètement pour la maintenance
Parler de "maintenabilité" sans aller dans le concret, c'est rester dans l'abstraction. Voici ce que ça change vraiment.
Tester
Du code custom, ça se teste : tests unitaires sur la logique, tests d'intégration sur les connecteurs, tests de non-régression automatisés dans la CI. Un workflow n8n, ça ne se teste pas de la même façon. On peut valider manuellement, activer des executions de test, mais on ne peut pas couvrir les cas limites de façon systématique sans contournements lourds.
Versionner et faire des reviews
Du code, ça passe par Git. Chaque modification est tracée, attribuée, réversible. Une équipe peut faire des code reviews, un nouveau développeur peut comprendre l'historique des décisions. Un workflow n8n exporté en JSON, c'est une série de blobs de configuration : lisible en théorie, exploitable en pratique seulement avec l'interface.
Faire évoluer sans casser
La refactorisation d'un workflow complexe en n8n est risquée : déplacer un noeud, modifier une expression, restructurer une branche peut casser des chemins d'exécution difficiles à anticiper visuellement. Du code bien structuré, avec des tests, se modifie de façon beaucoup plus contrôlée.
Ce qu'on dit aux clients qui nous demandent "pourquoi pas n8n"
On leur explique exactement ce qui précède. Et souvent, on leur propose les deux : n8n pour les flux légers que leur équipe ops doit pouvoir modifier elle-même, du code custom pour le coeur du système. Ce n'est pas exclusif.
Ce qu'on refuse, c'est de partir sur du low-code par défaut parce que "c'est plus rapide à coder", puis de se retrouver à devoir tout réécrire six mois plus tard parce que le client a besoin de logs structurés, d'une montée en charge ou d'une logique que le canvas ne peut plus exprimer proprement. Sur le projet Universal de génération de leads qualifiés, on aurait pu prototyper vite en n8n. On a choisi de coder d'entrée, parce que le volume attendu et la logique de scoring le justifiaient. Le client a un système qui tient, pas un prototype glorifié.
En résumé
n8n a sa place dans une stack d'automatisation : intégrations légères, business users en autonomie, prototypage. Dès qu'on parle de logique complexe, d'observabilité, de volume ou de durée de vie longue en production, le custom devient plus économique sur le long terme, même s'il coûte plus à l'entrée.
Si vous hésitez sur l'approche pour un projet d'automatisation en cours, c'est exactement le type de décision qu'on arbitre en quelques heures d'analyse. Un échange court sur votre contexte suffit généralement à identifier si vous êtes dans un cas n8n, un cas custom, ou un cas hybride.