Page mise à jour le
Les deux options
De quoi on parle exactement
n8n
Un moteur d'automatisation à nœuds, source disponible, que vous pouvez installer sur votre machine ou prendre en cloud chez l'éditeur. Un parcours complet compte pour une exécution, quel que soit le nombre d'étapes. Il accepte du code, des agents, et un vrai journal d'exécution — au prix d'une courbe d'apprentissage plus raide.
Make
Un atelier visuel dans le cloud, anciennement Integromat : modules, routeurs, itérateurs, le scénario se lit comme un schéma. C'est souvent le plus rapide à mettre dans les mains de quelqu'un qui n'écrira jamais une ligne. Vous n'hébergez rien. Vous payez des opérations, et vous vivez dans le compte Make.
Critères
Ce qui les sépare vraiment
Un critère par ligne, chaque option répondue séparément. Les lignes qui ne changent rien à la décision ne sont pas là.
| Critère | n8n | Make |
|---|---|---|
| Qui peut le modifier dans six mois | n8n se lit bien par un profil un peu technique, mal par quelqu'un qui n'a jamais vu un nœud. Si la personne du métier doit corriger un mapping seule, le vendredi soir, n8n lui résiste. C'est un outil qu'on laisse à celui qui accepte d'apprendre un environnement, pas à celui qui veut cliquer. | Make est fait pour être relu par le métier. Un scénario court tient sur un écran, les modules portent le nom du service, et la personne qui subit le flux peut souvent le corriger sans nous rappeler. Cette lisibilité est le vrai produit. Elle s'érode dès que le schéma déborde de l'écran, mais jusque-là elle n'a pas d'équivalent dans n8n. |
| Ce que vous payez quand ça tourne vraiment | n8n, en cloud, facture l'exécution du workflow, pas chaque nœud. En auto-hébergé, vous payez la machine et le temps de celui qui la tient. Les grilles changent : lisez n8n.io/pricing le jour où vous décidez, pas cette page. La structure, elle, ne change pas : un flux à vingt étapes n'est pas vingt fois plus cher qu'un flux à deux. | Make facture des opérations. Chaque module qui s'exécute en consomme, y compris certains déclencheurs qui interrogent un service même quand il n'y a rien de nouveau. Sur un scénario simple, ça reste raisonnable. Sur un scénario qui itère des lignes, ça se multiplie. La page tarifaire de Make fait foi, pas un comparatif figé. |
| Où tournent les données | n8n s'installe chez vous : Docker sur une machine en Europe, et les secrets, les payloads, les journaux restent sur cette machine. L'offre cloud de n8n existe aussi, et là vos flux vivent chez l'éditeur. La possibilité de ne pas les y laisser est le critère, pas une obligation de tout auto-héberger dès le premier scénario. | Make est un service cloud. Vos scénarios, vos connexions aux API, une partie des données qui transitent, vivent chez Make. Il n'existe pas d'édition auto-hébergée comparable que Make publie pour une PME. Si une contrainte interne interdit de faire transiter certaines pièces par un SaaS américain, Make sort de la liste avant même le débat sur l'ergonomie. |
| Logique, erreurs, cas particuliers | Dès qu'il faut des conditions imbriquées, une reprise sur erreur, un bout de code, n8n est dans son élément : nœud Code, expressions, branches, exécutions rejouables. C'est aussi le moment où un non-technicien décroche. Le flux reste versionnable et testable d'une façon que le visuel pur n'offre pas. | Make est fort sur le visuel des branches : routeurs, filtres, agrégateurs, itérateurs. Un scénario de moyenne complexité se lit encore. Passé un seuil — le schéma ne tient plus, on glisse du code dans les modules pour contourner l'outil — Make devient un plat de spaghettis, et plus personne n'ose y toucher sans le dupliquer d'abord. |
| Catalogue de connecteurs | n8n a un catalogue solide et des nœuds communautaires. Il n'a pas la couverture de Make sur certains SaaS de niche. Quand l'app n'existe pas, on passe par HTTP, ce qui est puissant et ce qui demande de lire une doc d'API. C'est là que n8n perd le premier après-midi face à Make. | Make couvre un très grand nombre de services avec des modules prêts, y compris des apps que n8n n'a pas en natif. Pour « connecter cet outil-là dès demain », Make gagne souvent. Le revers : vous dépendez de ce que Make maintient, et un module qui change casse le scénario sans que vous ayez le code sous la main. |
| Supervision et sortie | Les exécutions n8n se consultent, se rejouent, se filtrent. En auto-hébergé, les journaux sont à vous. Sortir de n8n, c'est reprendre des workflows que vous pouvez exporter. Ce n'est pas indolore, mais ce n'est pas non plus un compte SaaS dont l'export se résume à des captures d'écran. | Make montre les exécutions dans son interface, et c'est lisible. La sortie est plus rude : vos scénarios vivent dans Make, vos connexions aussi. Un export existe ; une reconstruction ailleurs reste un projet. Tant que Make vous convient, vous ne le sentez pas. Le jour où le tarif ou le produit bascule, vous le sentez d'un coup. |
Là où chaque option perd
Les cas où c'est le mauvais choix
Les deux options ont un domaine où elles coûtent plus cher qu'elles ne rapportent. Le vôtre est peut-être décrit ici.
n8n
n8n perd dès que la personne qui doit vivre avec le flux n'est pas technique et n'a aucune envie de le devenir. Un dirigeant qui veut relier Gmail à un tableur ce week-end se heurte à l'interface, aux identifiants d'API, parfois à Docker. n8n perd aussi sur certains connecteurs de niche que Make a et qu'il n'a pas. L'auto-hébergement, souvent vendu comme un avantage, est une perte sèche si personne chez vous n'accepte de patcher, de sauvegarder, et de se lever quand le conteneur ne redémarre pas. Dans ces cas, choisir n8n « parce que c'est plus puissant » vous laisse avec un outil que personne n'ouvre.
Make
Make perd quand le volume ou l'itération font exploser le compteur d'opérations, et quand le scénario cesse de tenir sur un écran. Il perd aussi dès qu'une contrainte d'hébergement ou de réversibilité entre en jeu : vous ne ramenez pas Make chez vous. Un flux métier qui va vivre trois ans, avec de la logique et des cas particuliers, se retrouve prisonnier d'un schéma visuel que plus personne ne sait modifier sans peur. Make n'est pas le mauvais outil. C'est le mauvais endroit pour faire tenir une usine. Le laisser grandir au-delà de son format, c'est exactement le piège décrit dans l'article sur l'outil visuel et le code.
Verdict
Make pour démarrer lisible, n8n dès que ça doit durer sous votre main
Si le flux est court, stable, et tenu par quelqu'un du métier qui doit pouvoir le relire, partez sur Make. Si quelqu'un chez vous peut tenir n8n, que le volume va monter, ou que les données ne doivent pas vivre dans un SaaS d'automatisation, partez sur n8n.
Chez Craft AI, on pose plus souvent n8n que Make, et ce n'est pas une raison pour vous le vendre par défaut. C'est une habitude d'atelier, pas une loi. Make reste le meilleur premier outil quand le besoin tient dans un schéma et que personne n'opérera un serveur. n8n devient le bon outil le jour où vous refusez de payer chaque étape, où vous voulez du code testable dans le flux, ou où l'hébergement est un critère et plus une préférence. La bascule se lit à trois signes : le scénario Make ne tient plus sur un écran ; une partie du métier est déjà écrite en code dans les modules ; plus personne n'ose modifier le flux sans le dupliquer. À ce moment-là, rester sur Make coûte plus cher que migrer.
Sources
Chaque affirmation de cette page renvoie au texte qui fait foi. En cas d'écart entre cette page et la source, c'est la source qui a raison.
- n8n — tarification (exécutions, cloud et self-hosted) (nouvel onglet)
Grille de l'éditeur, consultée le 21-08-2026. Les montants changent : cette page ne les recopie pas. Structure retenue : facturation à l'exécution de workflow, édition Community auto-hébergée.
- n8n — documentation d'hébergement (nouvel onglet)
Confirme qu'une instance self-hosted est un mode d'installation documenté par l'éditeur, distinct de n8n Cloud.
- Make — tarification (nouvel onglet)
Grille de l'éditeur, consultée le 21-08-2026. Structure retenue : facturation à l'opération. Pas d'édition auto-hébergée proposée sur cette page.
Vos questions
Faut-il savoir coder pour utiliser n8n ?
Pour un flux linéaire — un déclencheur, deux ou trois nœuds, un envoi — non : l'interface suffit, et beaucoup de nœuds se configurent sans écrire une ligne. Dès qu'il faut transformer une structure de données un peu vicieuse, gérer une erreur, ou contourner un nœud qui n'existe pas, le nœud Code apparaît, et là un minimum de JavaScript change la donne. Ce n'est pas « savoir développer ». C'est accepter de lire une expression et de la corriger. Si personne dans l'entreprise n'a cette tolérance, n8n n'est pas le premier outil à poser, même si c'est celui que le studio utilise le plus souvent.
Make peut-il s'héberger chez nous ?
Make est un produit cloud. L'éditeur ne publie pas, pour une PME, une édition que vous installez sur votre serveur comme on installe n8n. Vos scénarios, vos connexions et une partie des données transitent donc par leur infrastructure. Ce n'est pas un jugement, c'est un fait de produit, et il tranche certaines situations avant tout le reste : une contrainte contractuelle sur la localisation, un métier qui refuse de faire passer des pièces par un tiers d'automatisation, ou simplement la volonté de pouvoir éteindre un jour le SaaS sans éteindre le métier. Dans ces cas, le débat d'ergonomie ne se pose même pas.
Le studio recommande-t-il n8n par habitude ?
Oui, et le cacher serait malhonnête : on pose plus souvent n8n que Make, parce qu'on sait l'opérer, le versionner, et le brancher sur du code. Cette habitude n'est pas un argument pour vous. Un outil que nous maîtrisons et que personne chez vous ne pourra toucher est une dépendance déguisée, exactement ce que ces pages essaient d'éviter. La section où n8n perd est écrite pour ça. Si votre cas ressemble à ce qui y est décrit — flux court, personne non technique aux commandes, pas de contrainte d'hébergement — Make est le bon choix, et on le dira dans un diagnostic plutôt que de vous vendre l'outil qu'on a sous la main.
Une idée en tête ?
Réservez un rendez-vous ou écrivez-nous — réponse sous 24 h.