Make vs n8n

Si une équipe marketing, commerciale ou opérations construit et modifie elle-même les automatisations, choisissez Make. Son éditeur visuel est le plus lisible, il a plus de connecteurs prêts à l’emploi, et il n’y a rien à héberger.

Si un développeur est à portée de main, si vos données sont sensibles ou si vous lancez des dizaines de milliers d’exécutions par mois, choisissez n8n : vous pouvez l’héberger vous-même, écrire du JavaScript ou du Python dans un workflow, et vous payez à l’exécution plutôt qu’à l’étape.

Entre les deux, la question décisive est rarement une fonctionnalité. C’est de savoir qui maintiendra les automatisations une fois qu’on vous les aura remises.

Make, anciennement Integromat, est une plateforme d’automatisation visuelle. On construit un scénario en posant des modules sur un canevas : un déclencheur, puis les étapes qui lisent, transforment et envoient les données entre vos outils. Les routeurs créent des branches, les filtres décident de ce qui continue, les itérateurs parcourent des listes, sans écrire de code.

Make ne tourne que dans son propre cloud, avec des régions européenne et américaine. Vous payez un volume mensuel d’opérations, et chaque module exécuté compte. Ce modèle est économique pour les scénarios courts et coûteux pour les longs qui tournent souvent. Ses forces : la taille de son catalogue, et la lisibilité d’un scénario pour quelqu’un qui ne l’a pas construit.

n8n est un outil d’automatisation de workflows publié sous licence fair-code. À l’écran, il ressemble à Make, avec des nœuds sur un canevas, mais il est pensé pour les équipes qui veulent garder la main. Vous pouvez utiliser n8n Cloud, ou installer l’édition communautaire sur votre propre serveur et garder toutes vos données dans votre infrastructure.

n8n facture à l’exécution du workflow, pas à l’étape : un workflow de quarante nœuds coûte autant qu’un workflow de trois. Les nœuds de code acceptent JavaScript et Python, n’importe quelle API est accessible par le nœud HTTP, et ses nœuds IA permettent de construire des agents avec le modèle de votre choix, y compris un modèle hébergé chez vous. La contrepartie : il demande plus d’aisance technique et, en auto-hébergement, les mises à jour et les sauvegardes sont à votre charge.

Les neuf critères que nous regardons sur chaque projet d’automatisation. La dernière colonne indique l’outil qui l’emporte, d’après notre expérience sur les projets clients.

Les deux outils ne comptent pas la même chose, et c’est plus important que la grille tarifaire. Make compte des opérations : chaque module exécuté en est une. Un scénario de huit modules lancé 50 000 fois par mois consomme environ 400 000 opérations. n8n compte des exécutions : le même workflow en consomme 50 000, quel que soit son nombre de nœuds. En auto-hébergement, l’édition communautaire n’a pas de limite d’exécutions ; vous payez le serveur.

En pratique, Make est souvent moins cher pour quelques scénarios courts, et n8n le devient à mesure que les workflows s’allongent et que les volumes augmentent. Notre travail, mise en place et maintenance, coûte la même chose sur les deux : c’est la ligne de la plateforme qui fait la différence. Nous relisons les deux pages de prix avant chaque estimation et datons les chiffres que nous vous donnons.

Make traite vos données dans son cloud. Vous pouvez choisir une région européenne et signer son accord de traitement des données, et pour la plupart des flux marketing et commerciaux, cela suffit. Quand les données sont sensibles (santé, finance, RH, ou fichiers clients que votre équipe sécurité veut garder en interne), n8n auto-hébergé est la réponse la plus simple : workflows, identifiants et journaux d’exécution restent sur des serveurs que vous contrôlez, dans la région de votre choix.

L’auto-hébergement n’est pas gratuit en travail. Il faut appliquer les mises à jour, surveiller le serveur, renouveler les identifiants et sauvegarder la base. Quand nous hébergeons n8n pour un client, c’est inclus dans la maintenance ; quand le client l’héberge, nous documentons chaque étape pour que son équipe puisse le faire tourner.

Les deux plateformes permettent désormais de placer un modèle de langage dans une automatisation : classer un e-mail, résumer un appel, rédiger une réponse, extraire des champs d’un PDF. Make propose des modules et des agents IA rapides à mettre en place, efficaces pour des tâches simples et bien définies.

n8n va plus loin quand l’agent doit raisonner sur plusieurs étapes. Ses nœuds d’agents gèrent la mémoire, les outils et la recherche dans vos propres documents, et vous choisissez le modèle, de Claude ou GPT à un modèle ouvert tournant sur votre serveur. Pour un assistant de support appuyé sur votre base de connaissances, ou un agent qui lit un document, vérifie votre CRM et rédige une réponse, nous construisons le plus souvent sur n8n ou en code.

Make a le plus grand catalogue de connecteurs prêts à l’emploi, et chacun expose de nombreuses actions sans configuration. Pour les outils métier courants (CRM, e-mail, tableurs, formulaires, facturation), vous aurez rarement besoin d’autre chose.

n8n a moins d’intégrations natives, mais ses nœuds HTTP et de code atteignent n’importe quelle API, et vous écrivez la transformation exacte dont vous avez besoin en JavaScript ou en Python. Quand une stack contient un outil maison ou un ERP de niche, cette souplesse fait gagner plus de temps qu’une longue liste de connecteurs.

C’est la première question que nous posons. Si les personnes qui modifieront les automatisations le mois prochain travaillent au marketing ou aux opérations, l’éditeur de Make est celui qu’elles liront sans aide, et la plateforme s’occupe de la disponibilité. Si un développeur est disponible, ou si nous maintenons les automatisations pour vous, n8n donne plus de latitude : gestion de versions, tests, relectures, et environnements séparés pour la préproduction et la production.

Dans les deux cas, une automatisation est un petit logiciel. Il lui faut un responsable, un journal lisible et des alertes en cas d’échec. Nous les mettons en place sur les deux plateformes.

Ce que nous avons choisi sur des projets clients récents, et pourquoi.

Les équipes migrent en général quand leur facture Make grandit plus vite que leur volume, ou quand la sécurité demande de l’auto-hébergement. Les scénarios sont reconstruits, pas importés : nous planifions une migration comme un petit projet.

Nos notes tirées des projets que nous menons sur chaque plateforme. Le détail est dans nos fiches Make et n8n.