n8n vs Make vs Zapier : le comparatif honnête après une dizaine de projets livrés

TL;DR — le verdict en 30 secondes

Vous n'avez pas le temps de lire 2 000 mots ? Voici la décision en quatre lignes. Pour 90% des projets B2B sérieux : n8n auto-hébergé, point. Pour une équipe marketing qui automatise sa propre vie sans aide tech, tant qu'on reste sous dix zaps : Zapier, suffisant. Pour les workflows à logique visuelle complexe avec une équipe métier qui doit prototyper rapidement : Make, mais attention au pricing par operation.

Le reste de l'article explique pourquoi, sur quels critères, avec les calculs de coût réels en 2026 et deux cas concrets en production.

Zapier — quand c'est OK, et quand ça craque

Zapier reste l'outil le plus connu, le plus facile à prendre en main, et — soyons clairs — le bon choix dans certaines situations. Le problème, c'est qu'on l'installe le plus souvent dans les mauvaises. Quand un dirigeant de PME nous dit « on a déjà Zapier, on veut juste étendre », notre premier réflexe est de regarder la facture mensuelle. Souvent, elle révèle un usage déjà à la limite de ce que le pricing par task autorise.

Le modèle Zapier : vous payez par task. Une task = une étape d'un zap qui s'exécute. Si votre zap fait cinq étapes (récupérer un lead, l'enrichir, le créer dans le CRM, envoyer un email de bienvenue, notifier Slack), il consomme cinq tasks. Multiplié par 1 000 leads/mois, vous atteignez 5 000 tasks. Sur l'offre Professional vous êtes déjà à plafond. Doublez le volume et c'est l'offre Team, puis Company à plusieurs centaines d'euros par mois selon la complexité. À noter : Zapier ajuste sa grille tarifaire tous les 6 à 12 mois — les chiffres mentionnés ici sont à reconfirmer à la date où vous lisez l'article.

À 5 000 tasks/mois, Zapier coûte donc grossièrement 75 à 100 €/mois. n8n auto-hébergé sur un VPS Scaleway à ~8 €/mois traite le même volume sans même chauffer. À 50 000 tasks/mois, Zapier passe en offre Company à plusieurs centaines d'euros — toujours 8 à 20 € sur le VPS n8n. L'écart se creuse vite, et il devient absurde au-delà d'un certain volume.

Cas concret en production : le projet Toshify — qualification automatique des chauffeurs sur WhatsApp pour Cabify Argentine. Le workflow doit gérer une multitude de cas exotiques dans un seul flow lisible : profils chauffeurs avec historique sur d'autres plateformes, qualification en espagnol argentin (voseo) vs ibérique, transferts conditionnels selon le profil CRM, vérifications documentaires asynchrones. Sur Zapier, il aurait fallu enchaîner sept ou huit zaps avec passage manuel d'état entre eux — facture mensuelle qui explose, maintenance impossible à six mois. Sur n8n, c'est un seul workflow versionné. Voir le cas complet →

Quand Zapier reste le bon choix. Une équipe marketing de cinq personnes qui veut connecter HubSpot, Slack, Google Sheets et Calendly sans aide IT. Moins de dix zaps actifs, chacun avec deux à quatre étapes simples, volume modéré, pas de données particulièrement sensibles. Dans ce contexte, l'effort d'installer et de maintenir n8n n'est pas justifié — c'est de la dette technique pour rien. Zapier fait le job, et c'est très bien ainsi.

Make — le bon outil qu'on utilise mal

Make a un atout que ni Zapier ni n8n n'ont vraiment : un éditeur visuel agréable à utiliser pour modéliser des workflows complexes avec branches, gestion d'erreurs, retries. Quand on veut représenter graphiquement « si X alors Y sinon Z, et en cas d'échec de Y on retry trois fois », Make est plus lisible que n8n et bien plus expressif que Zapier.

Le piège : Make facture par operation, pas par scenario run. Une operation = un appel d'API ou un module élémentaire. Un scenario qui boucle sur 100 items pour les traiter consomme 100+ operations par exécution. Sur des workflows naturellement itératifs (traitement de listes, mise à jour de masse, sync de catalogues), la facture explose vite — et le pricing est moins lisible que celui de Zapier.

L'autre limite : pas d'auto-hébergement. Vos données passent par les serveurs Make (ils ont une option EU residency, c'est correct côté RGPD), mais vous ne pouvez pas isoler totalement le traitement dans votre infra. Pour des clients avec une politique sécurité stricte ou une exigence de localisation absolue des données, ça reste un point bloquant.

Quand Make reste le bon choix. Une équipe métier (marketing, ops) qui doit prototyper rapidement, avec un volume modéré et sans contraintes RGPD/sécurité fortes. Make est aussi excellent pour les workflows qui consomment essentiellement des APIs externes (HubSpot, Notion, Airtable) plutôt qu'une logique de transformation lourde. À ce moment-là, le visuel l'emporte sur la flexibilité de n8n.

n8n — pourquoi on l'installe sur 90% de nos projets

Sur 90% des projets B2B sérieux, n8n l'emporte sur les deux autres pour quatre raisons techniques structurelles. Pas une préférence d'opérateur — quatre points concrets qui font qu'au moment de la décision, les arguments tombent dans le même sens.

Auto-hébergeable et fair-code. n8n n'est pas totalement open source — la licence est dite « fair-code » (Sustainable Use License) — mais le code est lisible, modifiable, et l'auto-hébergement est explicitement autorisé sans frais. Concrètement : il tourne sur un VPS européen (Scaleway, Hetzner, OVH) à 8-20 €/mois. Vos credentials, vos workflows, vos logs : tout reste chez vous. Pour un client soumis à un audit sécurité de son donneur d'ordre, c'est souvent le critère qui ferme la discussion. C'est la stack que nous avons déployée chez Toshify : toutes les conversations chauffeurs transitent par leur propre instance n8n, jamais par des serveurs SaaS tiers.

Pricing fixe peu importe le volume. Que vous traitiez 1 000 ou 1 000 000 d'opérations par mois, le coût d'un n8n auto-hébergé ne change quasiment pas (juste le tier du VPS si vous saturez vraiment). Pour les projets qui consomment du volume — qualification de leads, sync continue de bases, scoring d'événements — c'est un game-changer économique. Le calcul fait plus haut : à 50 000 tasks/mois, n8n coûte un ordre de grandeur de moins que Zapier.

Code Node JavaScript quand le no-code ne suffit pas. Aucun outil no-code ne couvre 100% des besoins. Pour les 5-10% restants, n8n a un Code Node où vous écrivez du JavaScript directement. Vous n'êtes jamais bloqué par une limite de l'outil — quand quelque chose manque, vous le codez en dix lignes au lieu de monter en gamme ou de changer d'outil.

Exemple concret en production : sur Heex, une matrice de pondération métier devait s'appliquer au-dessus du score brut renvoyé par Gemini — closing pondéré plus fort que découverte, qualification du budget non-zéro obligatoire, malus si le commercial n'a pas posé telle question clé. Aucun nœud no-code n'expose ce niveau de logique. En une demi-heure dans un Code Node, c'était écrit, testé, et relisible par le client en revue. Sur Make ou Zapier, c'est une chaîne de cinq étapes avec des recalculs faux à chaque édition de prompt.

Les inconvénients réels. La courbe d'apprentissage est plus raide que Zapier ou Make. L'UI est moins léchée que Make. Le debug peut être douloureux quand un workflow plante en prod à 2h du matin. Et l'auto-hébergement implique d'avoir quelqu'un qui sait gérer un Docker sur un VPS — donc pas une équipe purement métier. Sans équipe technique en interne ou partenaire qui opère la stack, n8n n'est pas le bon choix : il faut quelqu'un derrière. C'est précisément ce que couvre notre service Automatisation IA côté Mynos.

Le critère qu'on oublie systématiquement : la sortie

Dans la majorité des décisions outils que nous voyons en audit, personne n'a posé la question : que se passe-t-il si je veux quitter cet outil dans 18 mois ? C'est le critère le plus important à long terme, et c'est celui qui différencie le plus durement les trois.

Avec Zapier, vous êtes prisonnier. Les zaps sont une représentation propriétaire interne à Zapier. Il n'y a pas d'export structuré exploitable ailleurs. Quand vous quittez, vous repartez de zéro sur un autre outil. Si Zapier change son pricing, ferme une intégration majeure, ou évolue dans une direction qui ne vous va pas — ce qui s'est déjà produit — vous payez la migration en temps de redéveloppement complet.

Avec Make, c'est mieux : vous pouvez exporter un scenario en JSON, mais le format est spécifique à Make. Aucun autre outil ne sait l'importer tel quel. C'est utile pour le backup, pas vraiment pour la portabilité.

Avec n8n auto-hébergé, vos workflows sont du JSON standardisé, votre base Postgres contient vos credentials chiffrés, et vous pouvez tout migrer sur une autre instance n8n en quelques minutes. Si demain le service cloud n8n.io est racheté, change de modèle ou disparaît, vous ne dépendez de rien — vous tournez sur votre VPS. La continuité d'activité est entièrement entre vos mains.

Ce critère n'apparaît jamais dans la phase « j'ai besoin d'automatiser, vite ». Il apparaît invariablement 18 à 24 mois plus tard, le jour où vous voulez changer pour x ou y raison. Anticipez-le maintenant.

Notre arbre de décision en 5 questions

Quand un client nous demande lequel choisir, nous déroulons cinq questions dans cet ordre. Selon les réponses, le choix est presque automatique.

1. Quel volume mensuel de tasks/operations attendez-vous ? Sous 1 000/mois, n'importe lequel marche, optez pour la simplicité (Zapier). Au-dessus de 5 000/mois, n8n auto-hébergé est imbattable économiquement.

2. Vos données sont-elles soumises au RGPD avec des contraintes de localisation strictes ? Si oui, n8n auto-hébergé en région UE. Make en option EU residency reste acceptable. Zapier (US-based par défaut) est à éviter si la localisation stricte des données est exigée.

3. Avez-vous une équipe technique interne ou un partenaire qui peut opérer un VPS ? Si non, oubliez n8n auto-hébergé — passez sur n8n.cloud (la version SaaS) ou Make. Zapier reste valable pour les usages simples.

4. Votre workflow va-t-il devoir évoluer fréquemment avec de la logique métier complexe ? Si oui, n8n (Code Node). Make en deuxième choix. Zapier vous coincera vite.

5. Quel est votre budget mensuel acceptable juste pour l'outil ? Sous 50 €/mois, Zapier basic ou n8n auto-hébergé sur petit VPS. Sous 200 €/mois, large choix possible. Au-dessus, ça signale du volume ou de la complexité — n8n redevient le bon choix.

La stack n8n de référence en 2026

Pour une instance n8n auto-hébergée en production B2B, voici l'architecture qui tient à l'échelle — déployable en interne avec un ingénieur familier de Docker.

VPS européen : Scaleway DEV1-S (~8 €/mois) pour les petits volumes, ou DEV1-L (~20 €/mois) à partir de 50k tasks/mois. Hetzner et OVH sont d'excellentes alternatives, le critère est la localisation UE et le rapport perf/prix.

Containerisation Docker : n8n tourne dans un conteneur, avec Postgres séparé pour la persistance des workflows et des credentials. Docker Compose orchestre les deux. Backup quotidien de la base sur un bucket S3-compatible (Scaleway Object Storage ou OVH Storage).

Reverse proxy : Caddy ou Traefik devant n8n pour TLS automatique (Let's Encrypt). Les webhooks entrants sont signés en HMAC-SHA256 quand l'émetteur le permet, sinon filtrés par allowlist d'IP.

Monitoring : Uptime Kuma sur le même VPS pour surveiller la santé de l'instance n8n. Notifications Slack en cas d'incident. Logs n8n exportés via Loki sur les setups plus matures.

Mise à jour : Watchtower pour les patches mineurs automatiques, mise à jour manuelle pour les versions majeures (n8n peut casser des workflows quand des nodes changent leur API en majeur).