Migrer de Make (Integromat) vers n8n : le guide pratique étape par étape

Make (l'ancien Integromat) reste l'un des outils no-code les plus puissants du marché — son canvas visuel avec routeurs, itérateurs et agrégateurs va nettement plus loin qu'un simple Zapier. Mais cette puissance a un prix, littéralement : au-delà d'un certain volume, la facturation à l'opération et les limites de l'éditeur de fonctions intégré poussent de plus en plus d'équipes à franchir le pas vers n8n. La bonne nouvelle : contrairement à un changement de CRM, vos données ne bougent pas — seule la couche d'orchestration change. Voici la méthode pour le faire sans rien casser.

Pourquoi migrer, concrètement

Trois raisons reviennent systématiquement chez les équipes qui font le pas depuis Make :

• Le modèle d'opérations qui punit les scénarios sophistiqués. Make compte une opération à chaque exécution de module. Un scénario avec un itérateur qui déplie 50 lignes, suivi de 3 modules de traitement, consomme d'un coup plus de 150 opérations pour un seul déclenchement. Sur un plan à 10 000 opérations/mois, quelques dizaines d'exécutions quotidiennes d'un scénario riche suffisent à saturer le quota. n8n self-hosted ne facture rien par exécution : le coût marginal d'un workflow qui tourne 10 fois ou 10 000 fois par mois est identique.
• Le contrôle des données. Sur Make, vos données transitent et sont temporairement stockées par une infrastructure tierce (hébergée en UE ou aux US selon la région choisie à la création du compte, sans pouvoir en changer ensuite). En self-hosted sur n8n, elles restent sur votre propre serveur — un point qui compte pour les équipes soumises au RGPD ou à des exigences contractuelles de résidence des données.
• Une logique de code plus complète. L'éditeur de fonctions Make reste limité à des expressions IML dans un cadre contraint. n8n donne accès à un node Code JavaScript ou Python complet, avec accès aux données de tous les nodes précédents, des modules npm en self-hosted, et des sous-workflows réutilisables — utile dès que la logique dépasse la transformation simple.

Avant de commencer : cartographier vos scénarios Make

C'est l'étape que tout le monde a envie de sauter, et c'est justement celle qui évite les mauvaises surprises. Listez, pour chaque scénario actif :

• Le déclencheur exact (webhook, polling, module de déclenchement d'une app tierce) et sa fréquence de planification.
• Les modules en cascade, dans l'ordre, avec une attention particulière aux routeurs (branches multiples) et aux couples itérateur/agrégateur.
• Les filtres appliqués sur chaque route.
• Les Data Stores utilisées, leur structure de colonnes et leur volume actuel.
• Les connexions (credentials) tierces utilisées et leur mode d'authentification.
• La criticité métier : un scénario qui alimente la facturation n'a pas le même niveau de risque qu'une notification Slack informative.

Cette cartographie sert aussi de base de test : une fois le scénario recréé, vous saurez exactement quel comportement vérifier avant de couper l'original.

Les équivalences de modules qu'il faut connaître

La bonne nouvelle : la plupart des blocs Make ont un équivalent n8n direct, souvent plus lisible une fois qu'on a compris le modèle de données par item de n8n.

Make	n8n
Router	Node Switch — route vers plusieurs branches selon la valeur d'un champ, sans empiler les filtres d'un routeur
Filter (sur une route)	Node IF, ou conditions directement dans un node Switch
Iterator	Node Split Out — déplie un tableau en items individuels, un par ligne plutôt qu'un par bundle
Aggregator	Node Aggregate — regroupe N items en un seul, avec les modes « Individual Fields » ou « All Item Data »
Data Store	Une n8n Data Table pour un petit volume interne, ou Postgres/Supabase au-delà de quelques milliers de lignes
Webhooks (module de réception)	Node Webhook en déclencheur
HTTP > Make a request	Node HTTP Request
Text/Function editor (IML)	Node Set pour du formatage simple, node Code (JavaScript ou Python) pour de la logique plus riche
Sleep	Node Wait

Le point d'attention principal concerne le couple itérateur/agrégateur : Make traite les données par « bundles » (chaque passage dans un itérateur produit un bundle traité séquentiellement dans les modules suivants), alors que n8n traite des items qui circulent tous ensemble entre deux nodes, chaque node s'exécutant une fois par item reçu. La logique finale est équivalente, mais la façon de raisonner dessus diffère — notre guide sur Split Out et Aggregate dans n8n détaille précisément ce modèle et évite les pièges classiques (node suivant qui s'exécute N fois de manière inattendue, par exemple).

Migrer scénario par scénario, pas tout d'un coup

Recréer tous les scénarios d'un coup est tentant — et c'est la meilleure façon de multiplier le risque. Une erreur de mapping ou de comptage devient difficile à isoler si dix automatisations basculent le même jour.

La méthode qui fonctionne :

1. Classez vos scénarios par criticité, et commencez par les moins risqués (notifications internes, synchronisations non bloquantes).
2. Recréez un scénario à la fois dans n8n, en vous appuyant sur la cartographie initiale.
3. Testez-le en isolation avec des données réelles mais un déclencheur manuel, avant de l'activer en continu.
4. Une fois validé, passez au suivant.

Pour les scénarios qui combinent plusieurs logiques distinctes (par exemple un routeur avec cinq branches différentes), découper le résultat en sous-workflows facilite aussi bien les tests que la maintenance — voir notre guide sur découper des workflows n8n complexes en sub-workflows.

Coexistence : faire tourner les deux en parallèle

Avant de désactiver un scénario Make, laissez-le tourner en parallèle de son équivalent n8n pendant une période de quelques jours à quelques semaines selon la criticité. Comparez les résultats produits par les deux systèmes sur les mêmes événements : mêmes données envoyées, mêmes actions déclenchées, mêmes champs remplis dans l'outil cible.

Cette période de coexistence est le meilleur filet de sécurité de toute la migration — elle transforme un pari en une vérification. Pour éviter les doublons pendant cette phase, une astuce courante consiste à faire écrire les deux systèmes dans des champs ou des identifiants distincts, puis à unifier une fois n8n validé.

Les pièges classiques spécifiques à Make

• Bundles vs items. Un scénario Make qui manipule des bundles un par un peut donner l'impression, une fois recréé dans n8n, qu'« il manque des données » — en réalité elles sont toutes présentes, mais regroupées différemment tant qu'un Aggregate n'a pas été inséré au bon endroit.
• Gestion d'erreurs par route dédiée disparue. Make permet d'attacher un gestionnaire d'erreur directement sur un module (Break, Resume, Ignore, Commit). n8n ne le fait pas nativement au niveau du node : il faut mettre en place un Error Workflow global ou des branches de gestion explicites, sans quoi une erreur qui était absorbée silencieusement sur Make peut arrêter net une exécution n8n.
• Limites de taux non gérées. Make absorbe une partie de la gestion des limites d'API des services tiers de façon assez opaque. En migrant vers n8n, cette responsabilité revient à vous — notre guide sur le rate limiting des appels API dans n8n couvre les patterns à mettre en place (Loop Over Items, Wait, lecture du header retry-after).
• Data Store à réexporter, pas à recréer à l'identique. Le plafond par défaut de 10 000 lignes d'une Data Store Make pousse souvent à des structures de contournement (plusieurs Data Stores pour un même besoin). En migrant vers Postgres ou Supabase, c'est l'occasion de revenir à un schéma propre plutôt que de reproduire le contournement.

Migrer les connexions et clés API

Make ne permet pas d'exporter les connexions stockées dans un scénario — jetons OAuth, clés API, mots de passe. Chaque credential doit être recréé directement dans n8n :

• Pour une clé API simple (la plupart des SaaS), récupérez la valeur depuis le compte du fournisseur et créez un credential n8n dédié.
• Pour une connexion OAuth2 (Google Workspace, Slack, HubSpot), il faut refaire l'autorisation depuis n8n — la connexion Make existante ne se transfère pas.
• Profitez de cette étape pour appliquer une gestion propre dès le départ : voir notre guide sur sécuriser les credentials et clés API dans n8n pour la structuration par projet et la rotation des clés.

Ce que dit la recherche sur le passage à des outils plus ouverts

L'argument n'est pas propre à n8n : une étude de Zhaohang Yan (Université de Toronto, 2021) sur l'impact du développement low-code/no-code note que ces plateformes accélèrent effectivement la livraison, mais créent une dépendance forte au fournisseur — une contrainte qui pèse de plus en plus lourd à mesure que les scénarios gagnent en complexité et en volume d'exécution (lire l'étude sur arXiv, également indexée sur Google Scholar). C'est exactement la bascule que décrivent les équipes qui quittent Make pour n8n une fois le volume et la complexité au rendez-vous : garder la puissance du no-code visuel, sans la dépendance à un moteur d'exécution fermé et facturé à l'opération.

Check-list finale avant de désactiver les scénarios Make

• Le scénario équivalent tourne dans n8n depuis au moins quelques jours sans erreur.
• Les résultats produits par les deux systèmes ont été comparés sur des cas réels, pas seulement des tests synthétiques.
• Un Error Workflow ou une politique de retry est en place pour les étapes critiques, à la place des gestionnaires d'erreur par module de Make.
• Toutes les Data Stores nécessaires ont été exportées et réimportées, avec une structure vérifiée plutôt que copiée à l'identique.
• Toutes les connexions ont été recréées et testées dans n8n.
• Le scénario Make original est mis en pause (pas supprimé immédiatement) pendant une dernière semaine de filet de sécurité avant suppression définitive.

Pour aller plus loin

Une fois vos scénarios Make recréés dans n8n, les briques les plus fréquemment demandées — tri et priorisation d'emails par IA, assistant documentaire RAG, questionnaires d'audit conversationnels — existent déjà prêtes à l'emploi plutôt qu'à reconstruire de zéro : le Pack Inbox IA (79 €), le Pack Assistant RAG (119 €) et le Pack Conformité & Audit (149 €) couvrent ces cas d'usage avec des workflows n8n directement importables. Pour situer précisément où Make garde un avantage et où n8n prend le relais, notre comparatif n8n vs Make vs Zapier reste la référence à consulter avant de trancher.