Migrer de Make vers n8n : guide complet en 6 étapes (retour d'expérience)

Vous utilisez Make depuis un ou deux ans. Vos workflows tournent, vos automatisations fonctionnent, tout va bien — jusqu’au jour où vous recevez l’email de renouvellement. Le prix a augmenté. Ou votre volume d’opérations a explosé et vous touchez le plafond de votre plan. Ou un client vous demande où transitent ses données, et vous réalisez que la réponse est “quelque part aux États-Unis, chez un éditeur tchèque racheté par Celonis.”

C’est exactement la situation dans laquelle je me suis retrouvé fin 2025. J’avais une quinzaine de workflows Make en production — prospection, facturation, synchronisation CRM, relances automatiques. Le tout pour environ 45 euros par mois. Puis les prix ont bougé, le volume a grimpé, et la facture a commencé à s’approcher de 80 euros mensuels. En parallèle, deux clients m’ont posé la question RGPD.

J’ai migré l’ensemble vers n8n auto-hébergé en trois semaines. Voici le guide que j’aurais aimé avoir avant de commencer.

Pourquoi migrer de Make vers n8n ?

Avant de vous lancer dans une migration, il faut être clair sur les raisons. Migrer “parce que c’est open-source” n’est pas suffisant. Voici les trois raisons concrètes qui justifient l’effort.

Les coûts qui dérivent

Make facture à l’opération. Chaque action dans un workflow consomme une opération. Un workflow de 8 modules exécuté 500 fois par mois, c’est 4 000 opérations. Multipliez par 10 workflows et vous atteignez les 40 000 opérations mensuelles — le plan Core (10 000 opérations) ne suffit plus, il faut passer au plan Pro.

Comparaison sur un usage réel (15 workflows, ~50 000 opérations/mois) :

Sur trois ans, la différence entre Make Pro et n8n self-hosted représente environ 2 800 euros. C’est un argument en soi.

La conformité RGPD

Avec Make, vos données transitent par les serveurs de l’éditeur. C’est parfaitement légal dans la plupart des cas, mais pour certains secteurs — santé, juridique, finance — la question de la souveraineté des données est un sujet. J’accompagne des thérapeutes et des commerces de détail : quand les données patient ou client sont en jeu, pouvoir dire “tout reste sur un serveur européen que je contrôle” change la conversation.

n8n auto-hébergé sur un VPS français (OVH, Scaleway) ou allemand (Hetzner) règle ce problème définitivement.

Les limites fonctionnelles de Make

Make est un excellent outil. Son éditeur visuel est probablement le plus élégant du marché. Mais il a des limites que j’ai rencontrées en production :

• Pas de code natif avancé. Make permet quelques fonctions, mais dès que la logique métier devient spécifique, vous êtes coincé.
• Debugging limité. Quand un workflow plante à 3h du matin, retrouver ce qui a échoué et pourquoi est souvent fastidieux.
• Pas de versioning. Impossible de versionner vos workflows, de faire un rollback propre, ou de maintenir un environnement de test séparé.

Avec n8n, vous avez des nœuds Code (JavaScript/Python), un historique d’exécution détaillé, et la possibilité de tout sauvegarder en JSON versionnable dans Git.

Si au moins deux de ces trois raisons vous parlent, la migration vaut le coup. Sinon, Make reste un bon choix — le comparatif complet est ici.

Étape 1 — Auditer vos workflows Make

Ne migrez pas à l’aveugle. La première étape est de dresser un inventaire complet de ce que vous avez dans Make.

Listez chaque workflow actif avec ces informations :

• Nom et description
• Déclencheur (webhook, schedule, événement applicatif)
• Nombre de modules
• Services connectés (Gmail, Stripe, Notion, Google Sheets, etc.)
• Fréquence d’exécution (quotidien, horaire, événementiel)
• Criticité (critique = panne visible immédiatement, secondaire = peut attendre)

Classez-les en trois catégories :

1. Simple (3-5 modules, logique linéaire) — migration en 30 minutes
2. Moyen (6-12 modules, quelques conditions) — migration en 1-2 heures
3. Complexe (12+ modules, boucles, sous-scénarios, error handlers) — migration en 2-4 heures

Ce classement détermine votre ordre de migration. Vous commencerez par les simples, pas par les complexes.

Un conseil : faites des captures d’écran de chaque workflow Make avant de commencer. L’éditeur visuel de Make est bon pour ça — un screenshot vous donne la vue d’ensemble que vous perdrez une fois le workflow supprimé.

Étape 2 — Choisir votre hébergement n8n

Deux options, avec des implications différentes.

n8n Cloud (la voie rapide)

Vous créez un compte sur n8n.io, vous payez, vous utilisez. Pas de serveur à gérer, pas de mise à jour à faire, pas de certificat SSL à configurer.

Pour qui : ceux qui veulent migrer vite sans se soucier de l’infrastructure. Le plan Starter à 24 euros par mois suffit pour démarrer, le plan Pro à 60 euros pour un usage soutenu.

Limitation : vous restez dépendant d’un hébergeur tiers pour vos données. L’avantage RGPD est moindre (même si n8n héberge en Europe).

n8n Self-hosted (la voie que je recommande)

Vous installez n8n sur un VPS via Docker. Le setup initial prend 2-3 heures si vous suivez un guide, 30 minutes si vous avez déjà fait du Docker.

VPS recommandés :

Pour 15 workflows avec un volume modéré, un serveur à 5-8 euros par mois suffit largement. J’utilise Hetzner pour mes clients : le rapport qualité-prix est imbattable et les serveurs sont en Europe.

Stack que je déploie :

• Docker + Docker Compose
• n8n (image officielle)
• PostgreSQL (base de données pour n8n)
• Nginx en reverse proxy
• Let’s Encrypt pour le HTTPS

Si le setup vous intimide, j’ai écrit un guide de démarrage n8n pour les non-techniques qui couvre l’installation pas à pas. Et si vous préférez déléguer, c’est exactement le type de prestation que je fais — le setup initial prend une demi-journée.

Étape 3 — Mapper les modules Make vers les nœuds n8n

C’est la partie qui inquiète le plus, et c’est pourtant la plus simple. Les concepts sont les mêmes : un déclencheur, des actions, des transformations, des conditions. Seuls les noms changent.

Table d’équivalence Make → n8n :

Les points d’attention :

Le Router de Make est probablement le module qui change le plus dans la migration. Make route visuellement avec des branches. n8n utilise un nœud IF (deux branches, vrai/faux) ou un nœud Switch (branches multiples). Le résultat est identique, mais la construction visuelle est différente.

Les filtres Make (ces petites icônes entre deux modules qui conditionnent le passage des données) n’existent pas tels quels dans n8n. À la place, vous utilisez un nœud IF en amont. C’est un nœud de plus dans le workflow, mais la logique est plus explicite et plus facile à debugger.

Étape 4 — Reconstruire en commençant par les plus simples

Ne migrez pas tout d’un coup. Commencez par un workflow de catégorie “Simple” — celui qui a le moins d’impact si quelque chose ne marche pas.

Méthode de reconstruction :

1. Ouvrez le workflow Make en lecture
2. Créez un nouveau workflow dans n8n
3. Reproduisez le déclencheur (webhook, schedule, événement)
4. Ajoutez les nœuds un par un, en testant chaque étape avec le bouton “Test step”
5. Utilisez les données de test de Make (copiez un exemple d’exécution réussie)
6. Testez le workflow complet avec “Test workflow”

Conseil important : n8n a un bouton “Test step” sur chaque nœud. Utilisez-le systématiquement. La plus grosse erreur que j’ai faite lors de ma première migration, c’est de construire tout le workflow d’un coup et de debugger à la fin. Testez chaque nœud isolément, puis le flux complet.

Pour les workflows de facturation automatisée, prenez le temps de vérifier les montants, les formats de date, et les templates d’email. Ce sont les détails qui divergent le plus entre Make et n8n.

Rythme recommandé :

• Semaine 1 : migrez 3-5 workflows simples
• Semaine 2 : migrez les workflows moyens
• Semaine 3 : migrez les workflows complexes

Ne vous mettez pas de pression. Tant que Make tourne, vos automatisations fonctionnent. Vous avez le temps de bien faire.

Étape 5 — Faire tourner les deux en parallèle

C’est l’étape que la plupart des guides omettent — et c’est pourtant la plus importante.

Pendant deux semaines, faites tourner Make ET n8n en parallèle pour chaque workflow migré.

Concrètement :

• Le workflow Make reste actif et continue de produire
• Le workflow n8n tourne aussi, mais ses actions finales sont désactivées (pas d’envoi d’email, pas d’écriture en base)
• Vous comparez les résultats : mêmes données en entrée, même sortie attendue ?

Ce que j’ai attrapé grâce au run parallèle :

• Un format de date qui différait entre Make et n8n (Make utilise le format ISO par défaut, n8n aussi mais avec un fuseau horaire qui n’était pas le même dans ma config)
• Un workflow de relance qui s’exécutait deux fois dans n8n parce que le trigger webhook était configuré différemment
• Un filtre Make qui excluait silencieusement certains cas — que je n’avais pas reproduit dans le nœud IF de n8n

Deux semaines, c’est le minimum. Si vos workflows ont des cycles mensuels (facturation, reporting), attendez un cycle complet.

Étape 6 — Couper Make et décommissionner

Une fois que vous êtes confiant :

1. Activez les actions finales dans vos workflows n8n (envoi d’email, écriture en base, etc.)
2. Désactivez les workflows Make un par un (ne les supprimez pas encore)
3. Surveillez n8n pendant une semaine — vérifiez les exécutions dans l’historique
4. Exportez vos workflows Make en JSON (sauvegarde, au cas où)
5. Réduisez votre plan Make au minimum ou annulez votre abonnement

Ne supprimez pas votre compte Make immédiatement. Gardez-le actif sur le plan gratuit pendant un mois. Si un workflow n8n a un problème que vous n’aviez pas anticipé, vous pourrez consulter la configuration Make originale.

Au bout d’un mois sans incident, vous pouvez supprimer définitivement.

Ce que j’ai appris (les pièges à éviter)

Après avoir migré une quinzaine de workflows et accompagné trois clients dans la même démarche, voici ce que je retiens.

L’authentification OAuth est le point de friction principal. Chaque service connecté (Gmail, Google Sheets, Notion, Slack) nécessite de reconfigurer l’authentification dans n8n. Pour Google, ça implique de créer un nouveau projet dans la Google Cloud Console et de configurer les credentials OAuth. Comptez 15-20 minutes par service Google la première fois. La bonne nouvelle : une fois fait, c’est réutilisable pour tous vos workflows.

Les webhooks changent d’URL. Si un service externe envoie des données vers un webhook Make, l’URL change quand vous passez à n8n. Pensez à mettre à jour l’URL côté émetteur. J’ai oublié un webhook Stripe lors de ma migration — résultat, les notifications de paiement partaient dans le vide pendant 48h avant que je m’en aperçoive.

Les expressions Make ne sont pas les expressions n8n. Make utilise ses propres fonctions (formatDate, parseJSON, map). n8n utilise une syntaxe différente, plus proche du JavaScript. La logique est la même, mais la syntaxe change. Prévoyez du temps pour adapter les expressions, surtout dans les workflows qui font beaucoup de transformation de données.

Les error handlers fonctionnent différemment. Dans Make, vous attachez un error handler à un module spécifique. Dans n8n, la gestion d’erreur se fait via un workflow séparé déclenché par un Error Trigger, ou via le retry intégré nœud par nœud. L’approche n8n est plus puissante mais demande un changement de mentalité.

Le gain de temps se matérialise après la migration, pas pendant. La migration elle-même prend du temps — comptez 15-25 heures pour 15 workflows. Mais une fois en place, l’absence de limites d’opérations, la possibilité d’ajouter du code, et le debugging avancé font gagner un temps considérable au quotidien.

FAQ

Peut-on importer directement les workflows Make dans n8n ?

Non. Il n’existe pas d’outil d’import automatique entre Make et n8n. Les deux plateformes utilisent des formats de données complètement différents. La migration est manuelle : vous recréez chaque workflow dans n8n en vous appuyant sur la configuration Make existante. C’est pourquoi l’audit de l’étape 1 est indispensable — il transforme une tâche floue en liste de tâches concrètes.

Combien de temps prend une migration complète ?

Comptez environ 1 heure par workflow simple, 2 heures par workflow moyen, 3-4 heures par workflow complexe. Pour 10-15 workflows typiques d’une TPE, prévoyez 15 à 25 heures réparties sur 2-3 semaines. Si vous faites appel à un freelance, c’est 1-2 jours de prestation. L’essentiel du temps passe dans la reconfiguration des authentifications et le test en parallèle, pas dans la reconstruction des flux eux-mêmes.

Et si je ne suis pas technique, est-ce que je peux migrer seul ?

La reconstruction des workflows dans n8n est faisable sans compétences techniques — l’interface est visuelle et les concepts sont les mêmes que Make. En revanche, le setup d’un VPS pour le self-hosting nécessite des bases en administration système. Deux options : prendre n8n Cloud (pas de serveur à gérer, setup en 5 minutes) ou déléguer l’installation à un freelance. Une fois n8n installé et configuré, l’utilisation quotidienne est du même niveau que Make. J’ai écrit un guide n8n pour les non-techniques qui couvre tout le nécessaire.

Faut-il migrer tous les workflows d’un coup ?

Surtout pas. Migrez progressivement, en commençant par les workflows les moins critiques. Le run parallèle (étape 5) est indispensable pour attraper les différences de comportement entre les deux plateformes. Certains de mes clients ont gardé Make pour 2-3 workflows spécifiques pendant plusieurs mois avant de finaliser la migration complète. Il n’y a aucune urgence — mieux vaut une migration propre qu’une migration rapide.