n8n vs Make: l'unité de facturation décide de tout

La seule différence qui décide de la facture

Les deux plateformes vendent des quotas mensuels. Elles ne comptent pas la même unité, et c'est là que tout se joue.

Chez n8n, la documentation tarifaire est explicite: « An execution is a single run of your entire workflow. It doesn't matter how many steps are in the workflow or how much data it processes, it's still a single execution. » Un flux à trois étapes et un flux à quarante étapes consomment pareil.

Chez Make, l'unité est l'opération: « Each module action in your scenario, like adding a Google Sheet row or fetching Gmail account data, counts as one credit. » Chaque brique traversée compte.

L'écart n'est donc pas un pourcentage, c'est un facteur, et ce facteur est exactement le nombre d'étapes de tes flux.

Ce tableau ne dit pas que n8n est moins cher, il dit que la comparaison n'a aucun sens tant que tu n'as pas compté tes étapes. Sur des flux courts et peu fréquents, la question ne se pose pas. Sur des flux longs, elle décide seule.

Les deux grilles, relevées le 3 août 2026

Tarifs publiés par les éditeurs. n8n annonce en euros et facturation annuelle, Make en dollars et par mois. Ils changent souvent, d'où la date.

Deux précisions honnêtes sur ces chiffres. Les paliers Make affichés portent sur 10 000 crédits et le montant suit ensuite le volume acheté: au-delà, l'éditeur ne publie pas de grille lisible, donc aucun montant n'est cité ici plutôt qu'estimé. Et l'engagement annuel fait gagner « 15 % ou plus » sans que les prix annuels soient détaillés.

L'intervalle minimum du palier gratuit de Make mérite d'être lu avant de bâtir dessus: quinze minutes entre deux déclenchements, ce qui exclut tout ce qui doit réagir vite. Passer à la minute est la vraie raison de quitter le gratuit, avant le nombre de crédits.

Côté n8n, la marche entre Pro à 50 € et Business à 667 € est raide, et ce qu'elle achète est surtout du contrôle d'entreprise: authentification unique, Git, environnements séparés. Si aucun de ces trois mots ne te concerne, la marche ne se justifie que par le volume d'exécutions.

La licence de n8n n'est pas ce que tu crois

n8n est très souvent présenté comme l'alternative open source à Make. Le dépôt dit autre chose: « n8n is fair-code distributed under the Sustainable Use License and n8n Enterprise License ». Code visible, auto-hébergeable, extensible, et pas approuvé par l'Open Source Initiative.

Pour une PME qui auto-héberge n8n pour ses propres flux, la distinction ne change rien en pratique. Elle devient centrale dans un seul cas: revendre l'hébergement de n8n à des clients, ce qui est précisément le type d'usage que le modèle fair-code restreint. Si c'est ton projet, la question se règle avec l'éditeur avant la première facture, pas après.

Make ne pose pas cette question puisque c'est un service en ligne assumé, sans version auto-hébergée. Le choix se fait donc aussi sur ce point: n8n te laisse la possibilité de tout rapatrier chez toi, Make ne te la propose pas.

Ce qui décide vraiment, une fois les prix mis de côté

Trois choses pèsent plus lourd que l'écart de tarif sur la durée de vie d'une automatisation.

• Le nombre d'exceptions de ton process. Une chaîne qui marche pour 90 % des cas et casse sur les 10 % restants coûte plus cher en réparations qu'en abonnement. C'est le vrai facteur de coût, et aucune des deux plateformes ne le change.
• La qualité des données d'entrée. Un formulaire mal rempli produit une automatisation qui écrit des bêtises plus vite qu'un humain. Ça se règle en amont du choix d'outil.
• Qui la répare dans six mois. Une automatisation sans propriétaire désigné se dégrade silencieusement. C'est la question que les comparatifs d'outils ne posent jamais et qui décide de la valeur au bout d'un an.

Sur ces trois points, n8n et Make se valent. Ce qui les sépare est l'unité de facturation, la possibilité d'auto-héberger, et le fait que n8n demande davantage de compétence technique pour être exploité correctement.

Quand ni l'un ni l'autre

Les deux plateformes vivent de la même promesse: brancher des outils sans écrire de code. Trois situations sortent de cette promesse, et les forcer coûte plus cher que de l'admettre.

Quand la logique métier tient sur plus d'une trentaine de modules, la scène devient plus difficile à lire et à corriger qu'un script de deux cents lignes, et le coût d'exploitation bascule. Quand le volume dépasse largement les paliers hauts, l'abonnement finit par dépasser le coût d'un service que tu héberges. Et quand le traitement doit décider plutôt qu'exécuter, c'est un agent qu'il faut, pas un flux: une chaîne prévisible fait très bien le travail sans modèle, et y ajouter un modèle ajoute du risque sans gain.

La bascule vers le sur-mesure n'est pas un jugement sur les outils no-code, c'est un seuil. Le repérer tôt évite de reconstruire deux fois.