Make vs n8n : choisir c'est se tromper

Pourquoi "lequel est le mieux" n'est pas la bonne question

La question me revient régulièrement, formulée presque toujours de la même façon : « Cédric, on hésite entre Make et n8n, lequel tu nous recommandes ? ». J'y réponds rarement directement. Et pour cause : cette question n'est pas la bonne. Elle ne permet pas de décider.

Le réflexe qu'on a quasiment tout le temps dans cette situation de choix, c'est de comparer fonctionnalité par fonctionnalité. Combien d'apps connectées de chaque côté ? Combien d'opérations dans le forfait gratuit ? Tel ou tel connecteur est-il présent ? Quel est le prix par utilisateur ? La grille rassure parce qu'elle paraît objective.

Elle rate l'essentiel.

En réalité, il y a quatre questions à se poser : qui va maintenir ce qu'on déploie, où vivent les données, combien de scénarios tourneront dans six mois, quel rapport au technique a l'équipe qui va vivre avec. Aucune de ces questions n'apparaît dans une comparaison fonctionnalité par fonctionnalité.

En fait, la moitié des entreprises qui me posent la question du choix le font trop tôt. Il y a d'autres choses à définir avant.

Deux philosophies, et tout en découle

Make et n8n font à peu près la même chose : connecter des applications, déclencher des actions, manipuler des données, intégrer de l'IA. Mais ils ne s'adressent pas aux mêmes personnes. Et c'est ce point qui les différencie.

Make est visuel et accessible. L'interface fait tout le travail d'abstraction : on compose un scénario comme on monterait des Lego. La donnée circule de manière claire et évidente et on n'a presque jamais besoin de comprendre ce qui se passe sous le capot. Un opérationnel un peu curieux y produit déjà quelque chose d'utile en quelques heures.

n8n est tourné vers les builders et open-source. L'interface ressemble à du Make en surface, mais en plus exigeant. Les nodes sont moins guidés et le code JavaScript pointe vite le bout du nez (dès qu'on dépasse les usages les plus standards). Pour un profil technique, n8n est un terrain de jeu exceptionnel, mais la courbe d'apprentissage est plus raide.

Cette différence fait tout le reste. Qui maintient un scénario quand son auteur n'est plus dans l'entreprise ? Qui audite ce qui se passe sur des données sensibles ? Qui fait évoluer un workflow sans appeler un prestataire ? La réponse (choix A : un ops, choix B : un dev) dicte assez souvent l'outil.

Le bon service n'est pas celui qui fait le plus, c'est celui que votre équipe pourra maintenir la semaine prochaine, quand je ne serai plus là.

Et qu'on ne se trompe pas : je vois souvent des PME finir par choisir Make "par défaut", en se disant que c'est plus simple. De fait, un déploiement n8n qui perd son garant technique tourne vite au terrain vague : plus personne ne sait ce que fait chaque module. Mais un déploiement Make qui se retrouve contraint par les fonctionnalités de l'outil oblige, lui, à tout réécrire ailleurs. Aucun de ces deux scénarios n'est souhaitable.

Bonne nouvelle, les deux s'anticipent. Quand on réfléchit. Avant.

Quatre critères pour trancher

Oui, selon moi quatre critères suffisent à décider. Et ils ne sont pas tous techniques.

1. Les agents IA. Make et n8n proposent tous les deux la fonctionnalité en 2026. Côté Make, le module AI Agent offre un environnement très intégré, où la définition d'un agent (prompt système, outils, mémoire) tient en quelques modules visuels. Encore une fois, des Legos et votre créativité. Côté n8n, le node AI Agent existe depuis toujours ou presque. Il est associé à l'écosystème LangChain et offre donc plus de contrôle, mais aussi plus de matière à câbler. Si vous voulez un orchestrateur agent-tool simple, Make va plus vite. Si vous voulez du RAG personnalisé sur des bases documentaires internes, n8n vous laissera la main.

2. La souveraineté des données. Make est cloud-only, hébergé chez son éditeur (en Europe). n8n peut être hébergé sur son propre serveur (on dit self-hoster), derrière un firewall d'entreprise. La question n'est pas neutre. Sur des données régulées, cela peut être un prérequis. Le cloud Make suffit largement aux autres usages, et économise une infrastructure.

3. Le coût réel à six mois. Make facture à l'opération : chaque module exécuté compte, et quand on ajoute de l'IA un module peut même coûter plusieurs crédits. n8n facture à l'exécution (qu'un workflow comporte trois ou trente nodes, c'est une exécution). Ça peut sembler contre-intuitif mais sur des workflows courts et nombreux, Make peut s'avérer plus avantageux ; sur des workflows longs et complexes, n8n l'emporte. Et n8n self-hosted est gratuit en licence (mais peut avoir un coût caché, cf. plus haut).

4. Le rapport au technique. Celui-là est très clairement celui que l'on néglige, alors que c'est le plus déterminant à mon sens. Qui sera aux commandes de l'automatisation au quotidien ? Un opérationnel qui veut produire vite et déléguer la complexité ? Make. Un dev, ou un ops curieux qui assume de monter en compétence ? n8n. Aucun des deux n'est un mauvais choix dans l'absolu. Le mauvais choix, c'est celui qui ne correspond pas à la personne qui va vivre avec.

La démo, et ce qu'elle révèle vraiment

J'ai construit pour Uncode School (vidéo à retrouver plus bas) le même cas d'usage sur les deux plateformes pour une démo : un agent de qualification de leads. Voici le scénario : un webhook qui reçoit la fiche prospect (équivalent d'un formulaire de contact sur un site), une IA qui analyse la demande et quatre outils en sortie pour notifier le commercial sur Slack, créer la fiche dans Airtable, envoyer un mail d'accusé via Gmail et consulter une FAQ interne pour répondre aux questions fréquentes.

Make et n8n se retrouvent au même niveau sur la mécanique pure de l'agent. Prompt système, définition des outils, test avant activation, ils le font tous les deux sans souci. C'est l'évolution majeure de ces derniers mois, notamment du côté de Make. Il y a un an, les stacks de dev avaient un avantage net sur ce point. Plus aujourd'hui. Faire un agent prend le même temps des deux côtés, à quelques minutes près. Les écarts ne se voient plus là.

La différence, elle se fait ailleurs : sur la couche de connaissance à avoir pour bien exécuter et calibrer son automatisation. L'exemple le plus concret, c'est la base documentaire qu'on voudrait donner à notre agent (la FAQ interne dans notre cas). Côté Make, on connecte un document, l'UI gère l'embedding et le vector store de façon transparente, rien de plus à faire. Côté n8n, il faut instancier la base vectorielle, choisir le modèle d'embedding, configurer le chunking, brancher la recherche sémantique. Si ces mots ne veulent rien dire pour vous, vous avez saisi la différence entre les deux outils. En soi, quand on sait ce que c'est, ce n'est pas plus difficile dans l'absolu. Mais c'est une couche de plomberie supplémentaire qu'on ne voit pas chez le concurrent.

Tester le même cas sur les deux outils ne sert pas à savoir lequel gagne. Ça sert à voir où chacun va vous coûter cher dans six mois.

Cette différence n'est pas un défaut de n8n. C'est exactement ce qu'on attend d'un outil developer-first : il vous laisse choisir. Et c'est exactement ce qui fait peur à un opérationnel non technique. Le critère du rapport au technique, qui paraissait abstrait tout à l'heure, se voit là sans aucun débat possible.

L'idée n'est pas de dire que c'est bien ou non. L'idée est de savoir pour choisir en conscience.

Ma méthode pour décider en deux semaines

Une fois qu'on sait ça, le processus de décision tient ensuite en trois étapes simples.

Première étape : partir d'un cas d'usage réel. Pas d'un appel d'offres tooling, pas d'une comparaison abstraite. On prend un irritant concret du quotidien (une relance commerciale, un reporting fastidieux, un workflow d'onboarding) et on en fait l'objet du test. Sans cas d'usage issu du réel, l'évaluation ne fait que valider des choix qu'on avait faits en amont, de manière abstraite.

Deuxième étape : tester les deux plateformes sur ce cas, cinq jours, en parallèle. Une vraie donnée, un vrai utilisateur, deux comptes d'essai. Pas de slides éditeur, pas de webinaires marketing, pas de comparateurs SaaS. Juste construire la même chose deux fois, et observer où ça frotte.

Troisième étape : impliquer la personne qui maintiendra. Celle qui aura vraiment les mains dans le cambouis. Pas uniquement son patron, même si c'est bien souvent celui qui vous paye. La main qui mettra vraiment les scénarios à jour dans dix-huit mois doit valider le choix. Si elle ne le fait pas, le projet est mort à terme.

Avec ça, votre décision est toujours claire, réfléchie et construite. Vous évitez ainsi le piège du choix sur catalogue : signer pour un outil qui répond à 95% des besoins théoriques, puis découvrir six mois plus tard que personne en interne ne sait le manipuler.

Pour aller plus loin

Make ou n8n : le palmarès des fonctionnalités n'a jamais été le vrai sujet. Le vrai sujet : le coût de maintenance à dix-huit mois, la souveraineté des données, le profil de la personne qui va vivre avec l'outil tous les jours. Quatre critères, deux semaines de test, une décision qui tient.

Pour le consulting d'automatisation No-Code, voir la page Automatisation No-Code & IA. Pour former des équipes à Make, n8n ou aux deux, voir Formation No-Code & IA en entreprise. Deux études de cas illustrent les deux scénarios : CROEC Normandie pour un déploiement Make pur où l'équipe pilote en autonomie, et Automatisation de contenus pour un cas où Make et n8n coexistent dans une même chaîne.