n8n vs Make : open source brut vs builder visuel léché

Deux philosophies d'automatisation

n8n et Make veulent tous les deux remplacer Zapier dans la stack. Tous les deux offrent des builders visuels, des centaines d'intégrations, et la possibilité de connecter ses outils sans écrire une application complète. Mais ils attaquent le problème sous des angles très différents.

n8n est open source, dev-friendly, et self-hostable. Il part du principe qu'on sait déployer un container Docker et qu'on est à l'aise pour ouvrir un code node quand le builder visuel ne suffit plus. Make est une plateforme managée avec une expérience visuelle soignée qui part du principe qu'on préfère faire du drag-and-drop plutôt qu'écrire du JavaScript.

C'est pas une différence philosophique mineure. Ça façonne le modèle de pricing, la courbe d'apprentissage, la façon dont on debug quand ça casse, et au final si l'outil grandit avec nous ou finit par devenir un bottleneck.

Les forces de n8n

La killer feature de n8n, c'est le self-hosting. On lance un container Docker sur un VPS à $5/mois, on le pointe vers une base Postgres, et on a une plateforme d'automatisation avec zéro coût par exécution. Pour un indie builder qui fait tourner des dizaines d'automations qui fire des milliers de fois par mois, ça change complètement l'équation économique.

Avec Zapier, on paie par task. Avec Make, on paie par opération. Avec n8n self-hosted, on paie le serveur et c'est tout. Si les automations sont bavardes -- sync de données entre outils toutes les quelques minutes, traitement de webhooks de plusieurs sources, jobs schedulés -- les économies s'accumulent vite.

Les code nodes sont l'autre gros différenciateur. n8n permet de drop un node JavaScript ou Python n'importe où dans le workflow. Besoin de transformer des données d'une façon que les nodes natifs ne gèrent pas ? On écrit une fonction. Besoin d'appeler une API qui n'a pas d'intégration officielle ? On écrit une HTTP request avec de l'auth custom. Besoin d'un calcul complexe ou de parser un format de données bizarre ? Quelques lignes de code et on passe à autre chose.

C'est pas une question de remplacer le builder visuel. C'est avoir une escape hatch quand le builder visuel atteint ses limites. Tous les outils no-code finissent par buter contre un mur. Celui de n8n est plus loin parce qu'on peut toujours tomber sur du code.

L'éditeur de workflows de n8n s'est beaucoup amélioré ces deux dernières années. Le canvas est plus propre, les panneaux de config des nodes sont plus intuitifs, et le log d'exécution montre exactement quelles données ont traversé chaque étape. C'est toujours pas aussi léché visuellement que Make, mais l'écart se resserre.

Les community nodes étendent n8n au-delà de ses intégrations officielles. La communauté a construit des nodes pour des outils de niche et des API que ni Make ni Zapier ne supportent. Si on doit se connecter à un truc obscur, il y a de bonnes chances que quelqu'un ait déjà construit un node n8n pour ça. Et sinon, on peut construire le sien -- le framework de développement de nodes de n8n est bien documenté.

Le système de gestion des credentials est solide. On configure ses clés API et connexions OAuth une fois, et c'est dispo dans tous les workflows. Self-hosted signifie que ces credentials vivent sur notre infra, pas sur les serveurs de quelqu'un d'autre. Pour les fondateurs qui manipulent des données clients sensibles ou des clés API avec des permissions larges, ça compte.

Les forces de Make

Le builder visuel de Make est sincèrement best-in-class pour l'automatisation no-code. Le canvas est beau. Les modules se connectent proprement. Les chemins de branching sont visuellement clairs. Les routers permettent à un seul trigger de se diviser en plusieurs chemins d'exécution basés sur des conditions, et on voit le flow entier d'un coup d'oeil.

Cette clarté visuelle n'est pas juste cosmétique. Quand l'automation a dix étapes avec trois branches conditionnelles et un error handler, pouvoir voir l'arbre logique entier sur un canvas rend le debugging drastiquement plus facile. Le canvas de n8n fonctionne, mais celui de Make a l'air d'avoir été designé par quelqu'un qui est obsédé par l'architecture de l'information.

Le module router mérite une attention particulière. Il permet de construire une automation qui gère plusieurs scénarios : si condition A, faire ce chemin ; si condition B, faire celui-là ; sinon, faire un fallback. On peut nester des routers dans des routers. C'est plus expressif que les paths de Zapier et plus visuel que d'écrire de la logique conditionnelle en code.

La gestion des erreurs de Make est intégrée au paradigme visuel. On peut attacher des modules d'error handling à n'importe quelle étape du workflow. Si un module échoue, l'exécution coule dans l'error handler où on peut retry, ignorer, commit le résultat partiel, ou router vers un chemin complètement différent. Le module break permet de pauser l'exécution et de reprendre plus tard, ce qui est pratique pour les API rate-limitées.

Le catalogue d'intégrations est massif. Make supporte plus de 1 500 apps avec des modules pré-construits. Pour les outils SaaS mainstream -- CRM, plateformes email, processeurs de paiement, gestion de projet -- Make a quasi toujours une intégration native prête à configurer. n8n a moins d'intégrations officielles, même si l'écart se réduit.

Le scheduling et les contrôles d'exécution sont flexibles. On peut lancer des scénarios sur un schedule fixe, les trigger via webhook, ou les connecter à des événements d'apps. L'historique d'exécution montre chaque run avec les données complètes d'input/output pour chaque module, et on peut re-run les exécutions échouées en un clic.

L'interface de data mapping de Make mérite aussi qu'on en parle. Quand on connecte deux modules, Make affiche chaque champ disponible de l'étape précédente et permet de les mapper visuellement. L'auto-complétion aide à trouver le bon champ rapidement. Pour les transformations de données complexes avec des arrays et des objets imbriqués, l'interface gère ça mieux que la plupart des outils visuels.

Self-hosting : la vraie ligne de fracture

C'est la plus grande différence entre les deux plateformes, et ça vaut le coup de s'y attarder parce que ça impacte tout le reste.

n8n peut être self-hosted. Make ne peut pas. Point final.

Self-host n8n veut dire qu'on fait tourner le logiciel sur son propre serveur. On contrôle l'infra, les données, l'uptime, et la structure de coûts. Un setup n8n basique sur un VPS coûte $5-20/mois quel que soit le nombre de workflows ou le nombre de fois qu'ils s'exécutent. Pas de frais par exécution, pas de limite d'opérations, pas de throttling.

Pour un builder solo qui automatise agressivement -- sync de données entre une base et un CRM, traitement de webhooks entrants, jobs de scraping schedulés, envoi de notifications -- la différence de coût entre n8n self-hosted et le pricing par opération de Make peut être de 10x ou plus sur un an.

Le compromis, c'est la maintenance. On gère les mises à jour, les backups, la sécurité du serveur et l'uptime soi-même. Si le serveur n8n plante à 2h du mat, personne ne nous appelle à part notre propre monitoring. n8n propose une option cloud si on veut de l'infra managée, mais l'avantage pricing se réduit et le modèle par exécution revient.

Make gère tout ça pour nous. On s'inscrit, on construit son scénario, et ça tourne. Pas de serveurs, pas de Docker, pas de gestion de base de données. Pour les fondateurs qui veulent automatiser sans penser à l'infra, c'est un vrai bénéfice.

L'évaluation honnête : si on est à l'aise avec un container Docker et qu'on a des compétences basiques en administration serveur, n8n self-hosted est le meilleur deal. Si les mots "container Docker" mettent mal à l'aise, Make est le meilleur choix et le surcoût est le prix de la tranquillité.

Builder visuel : face à face

Les deux outils sont des builders visuels, mais le ressenti en pratique est différent.

Le canvas de Make est plus affiné. Les modules sont des nodes circulaires connectés par des lignes. Le layout est propre et spatial. On peut zoomer, grouper les modules en dossiers, et l'esthétique d'ensemble est soignée. Les nouveaux utilisateurs trouvent souvent le builder de Make intuitif dès la première heure.

Le canvas de n8n utilise des nodes rectangulaires sur un layout en graphe. C'est fonctionnel et ça s'est beaucoup amélioré, mais ça fait toujours plus outil de dev qu'outil de design. Les panneaux de config des nodes montrent plus de données brutes et plus d'options, ce qui est puissant mais peut être intimidant quand on construit son premier workflow.

Là où Make gagne clairement, c'est l'UX de routing et de branching. Le module router de Make visualise les chemins conditionnels comme des lignes divergentes sur le canvas. On voit en un coup d'oeil quelles conditions mènent où. n8n supporte la logique conditionnelle via des nodes IF et switch, mais la représentation visuelle est moins immédiatement lisible.

Là où n8n gagne, c'est la vue des données d'exécution. Quand on teste un workflow dans n8n, on peut cliquer sur n'importe quel node et voir exactement quelles données il a reçues et ce qu'il a sorti. Les données coulent à travers le graphe visuel d'une façon qui rend le debugging naturel. Make montre aussi les données d'exécution, mais l'approche de n8n qui pin les données sur le canvas pendant les tests est plus immédiate.

Pricing : les chiffres qui comptent

n8n self-hosted est gratuit. Pas de limite d'exécution. Pas de feature gates. On paie son serveur ($5-20/mois pour la plupart des cas d'usage indie) et c'est tout. Toutes les features, toutes les intégrations, workflows illimités, exécutions illimitées.

n8n Cloud commence à $24/mois pour 2 500 exécutions. Le plan Starter inclut 5 workflows actifs. Les paliers supérieurs augmentent les comptes d'exécutions et les limites de workflows. Le pricing Enterprise est custom.

Make offre un tier gratuit avec 1 000 opérations par mois et 2 scénarios actifs. Le plan Core est à $10.59/mois pour 10 000 opérations. Le Pro est à $18.82/mois pour 10 000 opérations avec des features supplémentaires comme les variables custom et l'exécution prioritaire. Le Teams est à $34.12/mois.

Le truc important : n8n compte des exécutions (une par run de workflow), alors que Make compte des opérations (une par exécution de module dans un workflow). Un workflow avec 10 étapes compte pour 1 exécution chez n8n mais 10 opérations chez Make. Ça rend la comparaison de prix directe délicate. Un workflow Make qui traite 100 items à travers 5 modules consomme 500 opérations. Le même workflow dans n8n Cloud consomme 1 exécution (ou 100 si chaque item trigger un run séparé).

Pour n8n self-hosted, le calcul est simple : le coût du serveur est le coût total. Pas de calcul par exécution. Cette simplicité est en soi une feature.

Extensibilité code

n8n traite le code comme un first-class citizen. Le Code node permet d'écrire du JavaScript ou du Python avec un accès complet aux données d'exécution. On peut importer des packages npm en instances self-hosted. On peut construire des nodes custom qui apparaissent à côté des officiels. L'API est bien documentée et le SDK de nodes est activement maintenu.

Ça veut dire que n8n peut tout faire. Si une intégration n'existe pas, on écrit une HTTP request. Si une transformation de données est trop complexe pour le mapper visuel, on écrit une fonction. Si on doit interagir avec une base directement, on utilise le node approprié ou on écrit du SQL brut dans un code node.

Make a des modules code -- un module HTTP et un parser texte/JSON -- mais ils sont limités. On ne peut pas écrire du JavaScript arbitraire dans un scénario Make. La plateforme est intentionnellement no-code, et bien que ça la rende plus accessible, ça veut aussi dire qu'on tape dans le mur plus tôt sur les cas d'usage complexes.

Pour les fondateurs techniques qui codent tous les jours, l'extensibilité de n8n est un avantage massif. Pour les fondateurs non techniques, les guardrails de Make sont une feature, pas une limitation.

Profondeur des intégrations

Make a le catalogue le plus large : plus de 1 500 intégrations avec des modules pré-construits. Pour les outils SaaS populaires, les intégrations de Make tendent à être plus complètes, avec plus de triggers et d'actions par app.

n8n a 350+ intégrations officielles plus une bibliothèque grandissante de nodes contribués par la communauté. Les intégrations officielles couvrent bien les outils les plus courants, et la communauté comble les trous pour les produits de niche. Le node HTTP Request de n8n est aussi plus flexible que l'équivalent de Make, ce qui compense partiellement le catalogue plus petit -- si un outil a une API, on peut s'y connecter depuis n8n qu'un node officiel existe ou non.

La qualité des intégrations compte autant que la quantité. Les intégrations Make exposent souvent plus de la surface API d'une app. Par exemple, l'intégration Notion de Make supporte plus de types de blocs et de configurations de propriétés que celle de n8n. D'un autre côté, les intégrations de n8n sont open source, ce qui veut dire qu'on peut les inspecter, les fork, et fixer des bugs sans attendre le vendor.

Si on construit des automations qui connectent principalement des outils SaaS mainstream, le catalogue de Make donne plus d'options pré-construites. Si on connecte des API, des bases de données, ou des outils internes qui n'ont pas d'intégrations pré-construites, la flexibilité code de n8n couvre mieux.

Gestion des erreurs et fiabilité

La gestion des erreurs de Make est plus visuelle et plus accessible. On attache des modules d'error handling à n'importe quelle étape, et le canvas visuel montre le chemin d'erreur comme une ligne de branching. Le module break permet de pauser l'exécution et de retry plus tard. Le module ignore permet de skip les échecs et continuer. Le module rollback permet d'annuler les changements commités dans les modules précédents.

Cette approche visuelle de l'error handling signifie que les utilisateurs non techniques peuvent construire des workflows robustes qui gèrent les échecs proprement. Pas besoin de comprendre les blocs try/catch -- on drag un module sur le canvas et on le connecte au chemin d'erreur.

n8n a du retry logic et des error workflows, mais ça demande plus de configuration manuelle. On peut définir des comptes de retry sur les nodes individuels et configurer des error workflows qui trigger quand un workflow principal échoue. Les données d'erreur incluent quel node a échoué et pourquoi, ce qui aide au debugging. Mais le setup est moins intuitif que les error handlers visuels de Make.

Pour les automations de production qui doivent être fiables -- traitement de paiements, sync de données clients, gestion de webhooks de systèmes critiques -- les deux outils peuvent être rendus robustes. Make rend plus facile la mise en place de l'error handling dès le départ. n8n donne plus de contrôle sur ce qui se passe quand ça casse, mais on doit construire ce contrôle soi-même.

Quand choisir n8n

• On est technique et à l'aise avec Docker et l'administration serveur basique.
• On veut self-host et éliminer complètement le pricing par exécution.
• Les automations ont besoin de code custom -- transformations de données, appels API, ou logique que les outils no-code n'expriment pas.
• On se soucie de la souveraineté des données et on veut ses données d'automatisation sur sa propre infra.
• On construit des automations qui vont scaler à des milliers d'exécutions par jour et on veut des coûts prévisibles.
• On valorise l'open source et on veut pouvoir inspecter, modifier ou étendre la plateforme.
• On fait déjà tourner de l'infra pour son produit et ajouter un service de plus n'est pas une charge.

Quand choisir Make

• On veut le builder visuel le plus soigné du marché.
• On préfère l'infra managée et on ne veut pas penser aux serveurs.
• Les automations connectent principalement des outils SaaS mainstream avec des intégrations pré-construites.
• On n'est pas dev et on veut construire des automations puissantes sans écrire de code.
• On valorise la gestion visuelle des erreurs et on veut voir les chemins d'échec sur le canvas.
• Le volume d'opérations rentre dans les paliers de pricing de Make sans exploser le budget.
• On a besoin de logique de branching complexe et on veut la clarté visuelle du module router.

Verdict

n8n est le power tool. Make est l'outil soigné. Les deux sont un upgrade massif par rapport à Zapier sur le prix et les capacités.

Si on est un fondateur technique -- et si on lit ce site, c'est probablement le cas -- n8n est le meilleur choix long terme. Le self-hosting élimine le problème de coût par exécution définitivement. Les code nodes font qu'on ne bute jamais contre un mur. L'open source fait qu'on possède sa couche d'automatisation de la même façon qu'on possède le reste de sa stack.

Si on est un fondateur non technique ou qu'on ne veut simplement pas gérer de l'infra, Make est excellent. Le builder visuel est best-in-class, les intégrations sont larges, et la gestion des erreurs est plus intuitive que tout le reste de la catégorie. Le pricing par opération est fair, surtout comparé à Zapier.

Le pire choix, c'est de rester sur Zapier et de payer 5-10x plus par automation que nécessaire. Que l'on choisisse n8n ou Make, on va dans la bonne direction.