n8n ou Make : lequel choisir pour automatiser vos processus en 2026 ?

L'erreur classique est de comparer les abonnements mensuels affichés. Ce n'est pas là que se joue la facture.

Make facture à l'opération. Une opération, c'est l'exécution d'un module, pas d'un scénario. Un scénario qui contient huit modules et tourne 1 000 fois par mois consomme 8 000 opérations, pas 1 000. Ajoutez un itérateur qui traite cinquante lignes, et vous multipliez encore. C'est mécanique, et c'est ce qui surprend au troisième mois.

n8n facture différemment. En cloud, la facturation porte sur l'exécution du workflow, quel que soit le nombre de nœuds à l'intérieur. En auto-hébergé, vous ne payez que le serveur : le coût devient fixe, et il ne bouge plus que si vous manquez de ressources.

La conséquence est simple. Sur des volumes faibles, Make coûte moins cher qu'un serveur. Passé un certain volume, la courbe de Make croise le coût fixe de n8n, puis s'en éloigne. Le travail à faire avant de choisir tient en trois questions : combien de modules par scénario, combien de déclenchements par mois, et ces volumes vont-ils croître avec l'activité. Multipliez, comparez au coût d'un serveur et du temps d'administration. Vous avez votre réponse, chiffrée, en vingt minutes.

C'est l'argument massue de n8n, et c'est aussi celui qu'on vend le plus mal. Auto-héberger n'est pas gratuit, c'est déplacé.

Vous ne payez plus d'abonnement, mais vous prenez en charge le serveur, qui doit grandir avec vos volumes. Les mises à jour, car n8n publie souvent et une instance qu'on ne met pas à jour devient un risque de sécurité. Les sauvegardes, car vos workflows et leurs identifiants de connexion sont une base de données. Et la supervision, car un scénario qui échoue en silence pendant trois jours coûte plus cher que l'abonnement économisé.

C'est parfaitement gérable, et c'est exactement le genre de chose qu'on met en place puis qu'on documente pour que vous restiez autonome. Mais il faut le décider en connaissance de cause, pas parce que c'est open source donc gratuit. À l'inverse, si personne chez vous ne veut entendre parler d'un serveur, Make est le bon choix et le débat est clos.

Si vos automatisations manipulent des données de santé, des données juridiques, des pièces comptables ou des données personnelles sensibles, la question du lieu de traitement passe devant le coût.

Avec n8n auto-hébergé sur un serveur en France, la donnée ne quitte pas votre infrastructure. Avec un SaaS, elle transite par l'infrastructure de l'éditeur. Ce n'est pas disqualifiant en soi, les éditeurs sérieux sont conformes, mais c'est un point que votre DPO ou votre client final peut soulever. Dans les secteurs réglementés, ce critère tranche avant tous les autres.

Ce critère a la particularité de rendre les autres accessoires. Quand il s'applique, il décide seul, et aucun gain de confort ne le compensera.

Il s'applique dans trois situations que nous rencontrons régulièrement : une donnée de santé, une donnée soumise à un engagement contractuel de localisation, ou un flux qui transporte des informations que votre client vous a confiées sans savoir qu'elles transiteraient par un tiers.

Dans ces cas, la question n'est plus le confort de l'outil mais l'endroit où la donnée passe et l'endroit où elle se pose, même temporairement. Une plateforme hébergée conserve des journaux d'exécution qui contiennent le contenu des messages traités, et c'est ce détail, rarement lu, qui pose problème.

Si aucune de ces trois situations ne vous concerne, ce critère ne doit pas peser dans la décision. Le mobiliser par principe conduit à s'auto-héberger sans en avoir besoin, et à payer une maintenance qui ne sert à rien.

Un flux d'automatisation ne casse jamais quand vous le regardez. Il casse un vendredi soir, sur un cas non prévu.

Make propose une gestion d'erreurs par scénario, avec des routes dédiées et des tentatives de reprise. C'est correct et lisible. n8n permet la même chose, avec en plus la possibilité d'écrire la logique de reprise en JavaScript, et de brancher votre propre supervision. Vous allez plus loin, en échange de plus de travail de mise en place.

Dans les deux cas, la règle est la même : un scénario en production sans alerte en cas d'échec n'est pas terminé. C'est le premier réflexe que nous mettons en place.

Le point à cadrer avant de construire n'est pas la capacité brute, que les deux atteignent, c'est ce qui se passe quand une exécution échoue.

Une automatisation silencieuse qui tombe un vendredi soir produit des données incomplètes pendant tout le week-end, et personne ne le découvre avant que le client ne le signale. C'est le scénario le plus coûteux, et il n'a rien à voir avec le volume.

Notre exigence sur ce type de projet : toute automatisation qui touche un client ou une facture doit lever une alerte visible par un humain, pas seulement une ligne dans un journal que personne n'ouvre. Et toute étape qui écrit dans un système doit pouvoir être rejouée sans créer de doublon.

Ces deux règles se posent à la conception. Les ajouter après coup revient à reprendre chaque scénario un par un.

C'est le risque le plus fréquent sur ces projets, et il n'apparaît dans aucun comparatif de fonctionnalités.

Une automatisation est du logiciel écrit par quelqu'un. Si cette personne part, ce qui reste est un enchaînement d'étapes sans commentaire, dont l'intention doit être devinée. La question n'est donc pas seulement quel outil, mais qui ouvrira ce scénario dans un an et comprendra-t-il ce qu'il regarde.

L'auto-hébergement ajoute une couche à cette dépendance : au scénario s'ajoute le serveur, ses mises à jour et ses sauvegardes. Une automatisation qui tourne sur une machine que plus personne ne sait administrer est une dette, même si elle fonctionne.

Notre règle de livrable : chaque scénario porte un nom explicite, une description de ce qu'il fait et de ce qui se passe s'il échoue, la liste des systèmes qu'il touche, et pour l'auto-hébergé, la procédure de restauration. Dix minutes à la construction, et la différence entre une automatisation qui survit à un départ et une qui meurt avec.

Vous démarrez, votre équipe n'est pas technique, vos volumes sont modérés : Make. Vous serez opérationnel plus vite, et le coût reste maîtrisé tant que les volumes ne s'emballent pas. Vous pourrez migrer plus tard, les concepts sont transposables.

Vos volumes grimpent, ou votre facture d'automatisation devient une ligne visible du budget : n8n. Le calcul se fait sur douze mois, serveur et temps d'administration compris.

Vous traitez de la donnée sensible ou réglementée : n8n auto-hébergé, la question du coût passe en second.

Vous voulez internaliser progressivement : n8n. Les workflows s'exportent en JSON, se versionnent, et votre équipe monte en compétence sur un outil dont vous gardez la main.

Une TPE qui démarre, avec quelques flux entre des outils courants et personne de technique en interne : la plateforme hébergée. La mise en route est immédiate, et à ce volume la question du coût ne se pose pas encore.

Une PME qui monte en charge, dont les scénarios traitent des listes et se déclenchent des centaines de fois par jour : c'est le moment où la mécanique de facturation devient le premier poste du projet, et où l'auto-hébergement mérite d'être chiffré sérieusement plutôt qu'écarté par réflexe.

Une équipe qui internalise, avec quelqu'un capable de maintenir un serveur et l'intention de couvrir des processus métier complets : l'auto-hébergement devient rentable, à condition que la maintenance soit une ligne budgétaire assumée et pas un espoir.

Si la souveraineté des données s'applique à votre cas, elle tranche avant tous ces critères, et la discussion s'arrête là.