La question revient à chaque projet, et elle est souvent mal posée. Il ne s’agit pas de choisir le meilleur outil dans l’absolu, mais celui qui correspond au volume, à la durée de vie et à la criticité de ce que vous automatisez.
Ce que font ces trois approches
Make est une plateforme d’automatisation visuelle. On assemble des blocs, on relie des applications, et la facturation se fait à l’opération. La prise en main est rapide, l’écosystème de connecteurs est large.
n8n répond au même besoin, mais peut être hébergé chez vous ou sur votre propre serveur. On paie l’hébergement, pas le volume. En contrepartie, il faut quelqu’un pour maintenir l’instance.
Le développement sur mesure consiste à écrire le code qui fait exactement ce que vous voulez. Coût initial plus élevé, aucune limite fonctionnelle, aucun abonnement dépendant d’un tiers.
Les critères qui décident vraiment
Le volume
C’est le critère le plus mécanique. Les plateformes facturent à l’opération, et une automatisation qui traite quelques centaines d’événements par mois y reste très bon marché.
Le raisonnement s’inverse dans les volumes élevés. Une automatisation déclenchée plusieurs milliers de fois par mois, avec quinze étapes à chaque passage, atteint vite un montant où l’hébergement de n8n ou un développement dédié devient moins cher — et le calcul mérite d’être refait chaque année, les grilles tarifaires bougeant régulièrement.
La durée de vie prévue
Une automatisation liée à une opération ponctuelle n’a aucune raison d’être développée sur mesure. Montez-la en une journée sur une plateforme, elle aura rendu son service avant que la question de la maintenance ne se pose.
À l’inverse, un flux qui touche à la facturation ou à la paie tournera pendant des années. Là, la question devient : qui saura le reprendre dans trois ans ?
La criticité
Demandez-vous ce qui se passe si l’automatisation s’arrête sans prévenir un vendredi soir.
Si la réponse est « on le verra lundi et on rattrapera », une plateforme convient parfaitement. Si la réponse implique des clients mécontents ou des données perdues, il faut de la reprise sur erreur, des rejeux et une supervision réelle — ce que les plateformes offrent de façon limitée.
La logique métier
Les plateformes excellent sur les enchaînements linéaires : ceci arrive, alors fais cela. Elles deviennent pénibles dès que la logique se ramifie.
Un signal fiable : quand votre scénario dépasse la trentaine de blocs et que personne n’ose plus y toucher, vous avez écrit un programme dans un outil qui n’est pas fait pour ça. Le coût de maintenance a déjà dépassé celui du développement.
Ce que nous faisons en pratique
Nous commençons presque toujours sur une plateforme. Pas par principe, mais parce que c’est le moyen le plus rapide de vérifier qu’une automatisation apporte vraiment quelque chose.
Le scénario tourne quelques semaines. On observe : le volume réel, les cas particuliers auxquels personne n’avait pensé, le temps effectivement gagné. Cette observation coûte peu et évite de développer soigneusement une automatisation dont personne ne voulait.
Ensuite seulement, on décide. La plupart des flux restent sur la plateforme, et c’est très bien. Ceux qui montent en volume ou deviennent critiques sont réécrits, avec l’avantage considérable de connaître exactement le comportement attendu.
Le piège à éviter
Le vrai risque n’est pas de choisir le mauvais outil. C’est de construire quelque chose que vous ne pouvez pas récupérer.
Trois questions à poser avant de vous engager, quel que soit le prestataire :
- Les comptes et les abonnements sont-ils à votre nom ?
- Pouvez-vous exporter les scénarios et le code ?
- Existe-t-il une documentation qui permette à quelqu’un d’autre de reprendre ?
Si l’une des réponses est non, le sujet à traiter n’est pas le choix de la technologie.
Vous hésitez sur un cas précis ? Décrivez-le nous — nous vous dirons quelle approche tient la route, et à quel coût.
Ce sujet vous concerne ?
L’audit d’automatisation est gratuit : une heure pour savoir ce qui, chez vous, mérite d’être automatisé en premier.