n8n vs Make : lequel choisir pour automatiser son business ?

J’utilise Make et n8n en parallèle depuis plusieurs années — en production, sur des clients réels, pas dans un lab de test. La question « lequel choisir ? » a une réponse, mais elle dépend de votre profil technique, de vos volumes et de ce que vous automatisez. Pas d’un classement arbitraire. Voici ce que j’observe vraiment sur le terrain.

Ce que Make fait vraiment mieux

L’interface Make est lisible en 30 secondes. Un client non-technique peut ouvrir un scénario, suivre les flèches et comprendre ce qui se passe. C’est rare dans ce secteur et ça compte énormément quand vous livrez à des équipes marketing ou à des dirigeants de TPE qui veulent garder la main.

Les modules natifs Make pour HubSpot, Salesforce ou Pipedrive sont très complets : tous les champs exposés, des déclencheurs granulaires, des filtres en natif. Dans n8n, plusieurs intégrations « officielles » sont des wrappers partiels. Pour des outils mid-market européens — Brevo, Chargebee, certains CRMs — on se retrouve à passer sur le nœud HTTP Request pour des endpoints pourtant publics. Make évite ce contournement.

La gestion des erreurs est également plus intuitive dans Make. Vous attachez un Error Handler à n’importe quel module, vous définissez une route alternative si ce module échoue. Dans n8n, il faut construire un workflow dédié avec le nœud Error Trigger et gérer le retry manuellement. C’est faisable, mais c’est plus laborieux à mettre en place.

Dernier point souvent sous-estimé : la reprise sur incident. Make conserve un historique d’exécution avec rejeu en un clic depuis le module qui a échoué. Sur un workflow de facturation ou de synchronisation CRM en production, cette fonctionnalité vaut son pesant d’or.

Ce que n8n fait vraiment mieux

Le nœud Code JavaScript — ou Python — est la différence fondamentale entre les deux outils. Vous ouvrez un nœud, vous écrivez du JavaScript, vous manipulez des tableaux et des objets complexes. Dans Make, dès que vous avez besoin d’une logique custom non triviale, les outils disponibles sont soit limités soit spartiate. Pour tout workflow avec une vraie transformation de données, n8n est incomparablement plus puissant.

Sur les workflows IA, l’écart est encore plus marqué. n8n a intégré LangChain nativement. Agent avec outils, mémoire, plusieurs LLMs en cascade, parsing de sortie structurée — tout dans le canvas, sans code externe. Make vous permet d’appeler un LLM via HTTP, mais orchestrer un agent multi-étapes y est un bricolage. Pour tout workflow IA un peu sérieux, n8n est 3 à 4 fois plus rapide à construire.

Le self-hosting change la donne dès que les données sont sensibles. Santé, juridique, RH — hébergé sur un VPS en UE, les données ne transitent jamais par des serveurs tiers. Make est une société américaine. C’est un argument qui ferme des contrats dans certains secteurs, et il est légitime.

Sur les volumes élevés enfin, n8n self-hosted traite 10 000 lignes sans compter quoi que ce soit. Dans Make, chaque module exécuté sur chaque item est une opération facturée.

Les vrais tarifs 2025

Les deux outils communiquent sur leur plan d’entrée. Voici ce que ça donne vraiment en production.

Make — le modèle à l’opération

L’unité de mesure de Make est l’opération : chaque module exécuté sur chaque item compte pour une opération. C’est là que beaucoup de gens se font surprendre.

Opérations supplémentaires sur Core : environ 1,90 € pour 10 000 opérations. Ça a l’air raisonnable. Sauf que : un workflow CRM qui tourne toutes les 15 minutes, vérifie 50 contacts et met à jour 10 champs, c’est facilement 3 000 à 5 000 opérations par jour — soit 90 000 à 150 000 par mois. Sur Core, ça représente 14 à 19 € supplémentaires rien que pour ce workflow. Multipliez par 3 ou 4 workflows actifs, et le plan « 10 €/mois » devient 60 à 80 €.

n8n — cloud ou self-hosted

n8n mesure ses exécutions différemment : c’est le workflow complet qui compte pour une exécution, pas chaque module.

En self-hosted, le coût réel c’est le VPS. Un Hetzner CX22 — 2 vCPU, 4 Go RAM, 40 Go SSD, datacenter Allemagne — coûte 4,35 €/mois. Suffisant pour un usage solo à volume modéré. Pour des workflows plus lourds, le CX32 (4 vCPU, 8 Go RAM) est à 8,70 €/mois. Ajoutez 2 à 3 € pour les snapshots Hetzner. Total self-hosted sérieux : 7 à 12 €/mois tout compris, exécutions illimitées.

Ce que personne ne mentionne sur ces deux outils

Les pièges de Make

Le modèle à l’opération est trompeur. Un client qui ouvre Make pour la première fois ne comprend pas son usage avant le premier relevé. 12 modules × 100 items = 1 200 opérations consommées d’un coup. La facture surprend.

Le Datastore Make est lent et limité en taille. Utilisé pour du state management un peu sérieux, vous souffrez vite. Il n’y a pas de CLI Make non plus — dupliquer un scénario entre un environnement de dev et la production est laborieux. Et tester sans consommer des opérations réelles est possible mais mal fichu.

Les pièges de n8n

Les mises à jour peuvent casser des workflows en prod. J’ai vu des scénarios s’arrêter après une mise à jour mineure parce qu’un champ d’un nœud officiel avait changé de nom. Ce n’est pas la norme, mais ça arrive.

La clé de chiffrement des credentials est critique. n8n chiffre ses identifiants avec la variable N8N_ENCRYPTION_KEY. Si vous perdez cette clé en migrant le serveur, tous vos credentials sont illisibles. Il faut tout reconfigurer depuis zéro. Ce n’est pas un cas d’école — c’est arrivé en production.

Les sauvegardes sont entièrement de votre responsabilité. n8n ne sauvegarde pas lui-même. La base SQLite par défaut : si problème disque, tout disparaît. En production sérieuse, il faut PostgreSQL et un cron de backup. Et sur les volumes importants, l’OOM killer est un vrai risque : un workflow qui traite 50 000 items peut être tué par le kernel sur un VPS à 2 Go RAM, sans déclencher le moindre error trigger. 4 Go RAM minimum dès qu’on fait du volume.

Dernier point : les expressions n8n ({{ $json.field }}) ont leur propre syntaxe. Un champ qui retourne undefined ne lève pas d’erreur explicite — il passe silencieusement. Ça peut rendre le debug contre-intuitif.

Quel profil doit choisir quoi

Choisissez Make si vous êtes dans l’un de ces cas

TPE ou solopreneur sans bagage technique qui veut construire et maintenir ses propres workflows. Agence marketing qui livre à des clients qui doivent pouvoir modifier eux-mêmes les scénarios. Workflows dans l’écosystème HubSpot — Pipedrive — ActiveCampaign sans besoin de customisation poussée. Freelance qui ne veut pas gérer un serveur — c’est un choix de sérénité opérationnelle tout à fait valide.

Choisissez n8n si vous êtes dans l’un de ces cas

Consultant ou développeur avec des workflows qui nécessitent de la transformation de données sérieuse — enrichissement, calculs, normalisation. Client avec contraintes RGPD ou données sensibles : santé, juridique, RH. Toute personne qui intègre des LLMs dans ses automatisations — la différence avec Make sur ce terrain est nette. Agence ou freelance avec un volume de clients et d’exécutions important : l’économie à l’échelle est imbattable.

4 workflows réels — avec les nœuds utilisés

Pipeline de qualification lead par LLM (n8n)

Trigger Webhook Typeform → HTTP Request vers Apollo pour l’enrichissement → nœud Code (normalisation du payload, score préliminaire) → AI Agent LangChain avec Claude (classification en 3 catégories, extraction des signaux d’intention) → nœud Switch → trois branches : création de deal dans HubSpot, notification Slack pour les leads chauds, archivage Google Sheets. Error Trigger en parallèle connecté à un channel Slack dédié aux erreurs. Ce workflow nécessite le nœud Code pour la normalisation et l’agent LangChain pour la classification — deux éléments que Make ne peut pas reproduire proprement.

Alertes chute de trafic Search Console (n8n)

Trigger Schedule (lundi 8h) → deux HTTP Requests vers l’API GSC (30 derniers jours + 30 jours précédents) → nœud Code (calcul du delta de clics par page, filtre sur les chutes supérieures à 20%) → nœud IF (vérifie que la liste n’est pas vide) → nœud Code (formatage message Slack avec tableau récapitulatif) → Slack. Simple, tourne depuis 18 mois sans maintenance. Les données SEO restent sur le serveur, aucune opération à comptabiliser.

Synchronisation contacts entre deux CRMs (Make)

Webhook HubSpot déclenché sur création ou mise à jour de contact → module HubSpot Get Contact → Router selon le champ « source » → branche 1 : Pipedrive Create or Update Person + Company → branche 2 : Airtable Upsert. Error Handler attaché à chaque module critique. C’est exactement le type de workflow pour lequel Make est taillé : mapping de champs, routage simple, modules officiels complets pour HubSpot et Pipedrive. Aucune raison de passer sur n8n ici.

Routing tickets support (Make)

Webhook Intercom sur nouveau ticket → Text Parser (extraction du mot-clé du sujet) → Router selon trois catégories (facturation / technique / commercial) → branche facturation : module Stripe récupère le dernier paiement + note interne Intercom avec contexte Stripe → branche technique : création de ticket Jira avec priorité définie. Ce workflow exploite les modules Make très finis pour Intercom et Stripe. Construire la même chose dans n8n demanderait davantage de configuration HTTP manuelle sans gain concret.

Et Zapier dans tout ça

Zapier a l’écosystème le plus large — plus de 7 000 intégrations — et le nom le plus reconnu. On y revient parfois quand un SaaS mid-market n’a pas encore investi dans un connecteur Make ou n8n. Son problème en 2025 : significativement plus cher que Make pour des fonctionnalités équivalentes, les Zaps multi-étapes nécessitent un plan payant, et il n’y a rien qui ressemble au nœud Code de n8n ni aux agents IA natifs. C’est la solution par défaut du client non averti, pas un choix délibéré.

Conclusion

Make gagne sur l’accessibilité, la lisibilité des scénarios et la qualité des modules pour les CRMs mainstream. n8n gagne sur la puissance de traitement, les workflows IA, la souveraineté des données et l’économie à l’échelle. Ce ne sont pas des outils interchangeables — ils répondent à des besoins différents, et souvent complémentaires.

Le mauvais choix n’est pas de préférer l’un à l’autre. C’est de rester sur Make à 80 000 opérations par mois par habitude, ou de forcer n8n à quelqu’un qui n’a aucune appétence pour le technique et qui voulait juste synchroniser deux outils.

Si vous voulez structurer vos premiers workflows ou cadrer ce que l’automatisation peut vraiment apporter à votre activité, je propose un accompagnement Make et n8n — configuration, tests, documentation — pour que vous repreniez la main sans dépendance. Et si vous souhaitez d’abord comprendre les cas d’usage pertinents pour une PME, la page sur l’automatisation IA pour les entreprises pose les bases.