Migrer de Make ou Zapier vers n8n est rentable quand ta facture suit ton volume ou quand tes données doivent rester chez toi — mais ce n'est jamais un copier-coller : chaque scénario se reconstruit, et une migration réussit ou échoue sur l'inventaire et le double run, pas sur le développement.
La situation revient régulièrement en cadrage : une PME a monté ses automatisations sur Make ou Zapier il y a deux ou trois ans, le volume a augmenté, les scénarios se sont empilés, la facture a suivi — et plus personne ne sait exactement ce qui tourne, ni ce qui casserait si on coupait l'abonnement demain.
Le bouton « exporter vers n8n » n'existe pas. Voici la méthode que nous appliquons chez CZ Multimédia pour migrer sans casser la production.
La réponse directe
Migrer de Make ou Zapier vers n8n se fait en 5 étapes : inventaire, cartographie des dépendances, reconstruction dans n8n, double run (l'ancien et le nouveau flux tournent en parallèle pour comparer leurs sorties), puis bascule flux par flux. Aucun outil officiel ne convertit automatiquement un scénario Make ou un Zap. CZ Multimédia chiffre la migration d'un workflow simple entre 800 et 2 000 € HT et celle d'un parc complet de PME entre 4 000 et 10 000 € HT, 3 mois de maintenance inclus ; l'hébergement self-hosted sur un VPS français coûte ensuite 20 à 60 €/mois.
- Quand migrer, et quand ne pas le faire : la logique de facturation qui fait basculer le calcul
- La méthode en 5 étapes : inventaire, cartographie, reconstruction, double run, bascule
- La table d'équivalences Make / Zapier → n8n, concept par concept
- Les 6 pièges qui cassent une migration en production
- Le budget réel : grille CZ Multimédia 2026, coûts récurrents et deux projets n8n chiffrés
Pour un cadrage sur ton projet : Contactez-nous
Sommaire
- Pourquoi migrer vers n8n, et quand ne pas le faire
- La méthode de migration en 5 étapes
- Équivalences : traduire un scénario Make ou un Zap en workflow n8n
- Les 6 pièges qui cassent une migration vers n8n
- Combien coûte une migration vers n8n ?
- Après la migration : n8n self-hosted ou n8n Cloud ?
- Cas terrain : ce que coûte un workflow n8n en production
Pourquoi migrer vers n8n, et quand ne pas le faire
On migre vers n8n pour trois raisons — une facturation qui ne suit plus le volume, la maîtrise des données, la souplesse technique — et on s'abstient dans trois cas précis.
La facturation : des étapes chez Make et Zapier, des exécutions chez n8n
C'est la première raison des demandes que nous recevons. Make facture à l'opération : chaque module exécuté en consomme une, désormais décomptée en crédits. Zapier facture à la tâche : chaque action réussie compte, le déclencheur non. La facture grandit donc avec le nombre de passages et le nombre d'étapes par passage.
Sur n8n Cloud, une exécution correspond à un passage complet du workflow, qu'il contienne 3 nœuds ou 40. En self-hosted, il n'y a plus de compteur : tu paies le serveur, pas l'usage. Exemple : un scénario Make qui découpe une commande de 50 lignes avec un itérateur, puis fait passer chaque ligne dans quatre modules, consomme plus de 200 opérations par commande. Dans n8n, c'est une exécution. La migration devient donc rentable sur les flux à forte volumétrie — catalogues, lignes de commandes, imports de fichiers — pas sur les petits flux.
Les données : le self-hosted les garde chez toi, avec une nuance
n8n peut s'installer sur ton propre serveur, en France : fiches clients ou factures ne transitent plus par l'infrastructure d'un éditeur tiers. Nuance : le self-hosted ne rend pas un workflow conforme au RGPD par magie. Si le workflow envoie ensuite les données à un CRM américain ou à l'API d'un modèle de langage, elles sortent quand même.
La souplesse : du code quand il faut
n8n permet d'écrire du JavaScript ou du Python dans un nœud Code, d'appeler n'importe quelle API, de découper la logique en sous-workflows et de versionner chaque workflow en JSON. Pour le comparatif complet, lis notre comparatif n8n vs Make vs Zapier, ou les duels n8n vs Make et n8n vs Zapier.
Les trois cas où il vaut mieux ne pas migrer
- Peu de scénarios, peu de volume. Cinq Zaps qui tournent quelques centaines de fois par mois ne justifient pas une migration : la reconstruction ne sera jamais amortie.
- Une équipe non technique, sans support. n8n demande plus de rigueur que Zapier (expressions, items, mises à jour). Sans personne pour maintenir, tu remplaces une facture par un risque.
- Une intégration native introuvable dans n8n. Zapier et Make ont des catalogues plus larges. Un connecteur de niche se reconstruit via HTTP Request et l'API de l'éditeur — faisable, mais à chiffrer avant de décider.
Si ta vraie question est de choisir entre les deux outils que tu utilises déjà, notre page Make vs Zapier pose les critères.
On ne migre jamais un parc entier « par principe ». On commence par l'inventaire, on estime le gain scénario par scénario, et il nous arrive de recommander de garder Zapier pour deux ou trois flux marginaux pendant que les flux lourds passent sur n8n. C'est l'approche que nous appliquons sur nos missions d'agence n8n en France.
La méthode de migration en 5 étapes
Une migration propre suit 5 étapes dans cet ordre — inventaire, cartographie, reconstruction, double run, bascule — et les deux qu'on saute le plus souvent, l'inventaire et le double run, sont celles qui évitent les incidents.
1. Inventaire : lister tout ce qui tourne
L'objectif : une liste exhaustive des scénarios ou des Zaps, actifs et inactifs, avec pour chacun le déclencheur, les applications connectées, le volume mensuel (visible dans les statistiques d'usage de Make comme de Zapier), le propriétaire, la criticité et ce que produit le flux.
Sur nos inventaires, on trouve presque toujours des scénarios désactivés, des doublons « pour tester », et régulièrement un flux branché sur le compte personnel d'un ancien salarié. Chaque scénario reçoit un statut : migrer, simplifier, fusionner ou supprimer. Côté Make, exporte le blueprint JSON de chaque scénario : il ne se convertit pas, mais documente modules, filtres et mappings.
2. Cartographie : repérer ce qui dépend de quoi
Un scénario n'est jamais isolé : le scénario A écrit dans un Google Sheet que lit le scénario B, le formulaire du site appelle un webhook Make. La cartographie liste ces liens : qui déclenche quoi, quelles URL sont appelées depuis l'extérieur, quels identifiants servent à plusieurs flux. Elle fixe l'ordre de migration : d'abord les flux sans dépendance entrante, en dernier ceux appelés par des systèmes que tu ne contrôles pas.
3. Reconstruction : réécrire, pas recopier
Il n'existe pas d'outil officiel qui convertit un scénario Make ou un Zap en workflow n8n. Des scripts communautaires ou des assistants IA le promettent : au mieux, ils produisent un squelette à reprendre nœud par nœud. Tout se reconstruit — c'est le moment de simplifier.
Trois règles : la gestion d'erreurs se construit en même temps que le flux ; les identifiants sont créés sur des comptes techniques de l'entreprise, jamais personnels ; les workflows sont développés sur une instance de test, puis exportés en JSON et versionnés.
4. Double run : l'ancien et le nouveau en parallèle
Le double run fait tourner l'ancien flux et le workflow n8n en même temps, sur les mêmes données réelles, pour comparer leurs sorties : c'est ainsi qu'on détecte une date décalée d'un jour ou un champ vide traité différemment.
Attention aux effets de bord en double : le workflow n8n écrit dans une destination miroir (table de contrôle, boîte mail de test) et seul l'ancien outil agit réellement. Pour alimenter n8n avec les mêmes données, ajoute en tête du scénario Make un module HTTP (ou une action Webhooks by Zapier) qui transmet la charge reçue au webhook n8n. Durée : au moins un cycle métier complet — une semaine pour un flux quotidien, un mois pour un flux de facturation mensuelle.
5. Bascule : couper l'ancien, garder la marche arrière
La bascule se fait flux par flux, jamais en « big bang » : tu actives le workflow n8n, tu mets à jour les émetteurs avec la nouvelle URL de webhook, puis tu désactives le scénario d'origine — sans le supprimer, pour garder un plan de retour. L'historique des exécutions de n8n permet ensuite de suivre chaque passage. Tu ne réduis ton abonnement qu'une fois le parc entier stabilisé.
Équivalences : traduire un scénario Make ou un Zap en workflow n8n
La plupart des concepts se traduisent un pour un ; les itérations et la gestion d'erreurs, elles, se repensent, parce que n8n n'a pas le même modèle d'exécution.
| Make | Zapier | n8n | Point d'attention |
|---|---|---|---|
| Scénario | Zap | Workflow | Plusieurs déclencheurs possibles |
| Module | Étape | Nœud | HTTP Request couvre les API sans nœud natif |
| Webhook personnalisé | Webhooks by Zapier | Nœud Webhook | URL de test et de production distinctes |
| Planification | Schedule by Zapier | Schedule Trigger | Vérifier le fuseau horaire |
| Routeur | Paths | Switch (ou IF) | Switch au-delà de 2 branches |
| Filtre | Filter by Zapier | Filter ou IF | IF garde les deux branches |
| Itérateur | Looping by Zapier | Modèle « items » natif, Split Out | Rarement besoin d'une boucle |
| Agrégateur | Formatter (line items) | Aggregate, Summarize | Regroupe les items en un seul |
| Fonctions de mapping | Formatter by Zapier | Expressions JavaScript, nœud Code | Luxon pour les dates |
| Data store | Storage by Zapier | Base de données (Postgres…) | Reprendre les données existantes |
| Sleep | Delay by Zapier | Wait | — |
| Lancer un scénario | Sub-Zap | Execute Workflow | Mutualise une logique commune |
| Gestionnaires d'erreur | Autoreplay, alertes | Error Workflow, Retry On Fail | Se reconstruit, ne se traduit pas |
Le modèle « items » remplace les itérateurs
Chez Make, un itérateur découpe un tableau en « bundles » qui traversent le scénario un par un. Dans n8n, chaque nœud reçoit une liste d'items et les traite tous : 50 lignes de commande en entrée, le nœud suivant s'exécute pour les 50 sans rien configurer. Split Out transforme un tableau en items, Aggregate fait l'inverse. Loop Over Items ne sert que pour contrôler le rythme (lots avec pause, limite d'API) : reproduire chaque itérateur Make avec une boucle est une erreur classique.
Conséquence subtile : Make fait traverser tout le scénario au premier bundle avant le deuxième, alors que n8n exécute un nœud pour tous les items avant le suivant. Si ton scénario comptait sur cet ordre, vérifie-le au double run.
Les expressions remplacent les fonctions de mapping
Les fonctions Make (formatDate, get, ifempty…) deviennent des expressions JavaScript, avec Luxon pour les dates. Deux différences piègent régulièrement : dans Make, get(tableau; 1) renvoie le premier élément, alors qu'en JavaScript il est à l'index 0 ; et les jetons de date ne sont pas les mêmes (DD/MM/YYYY chez Make, dd/MM/yyyy avec Luxon). Un format recopié tel quel produit une date fausse, sans erreur.
Make : formatDate(1.createdAt; "DD/MM/YYYY")
n8n : DateTime.fromISO($json.createdAt).toFormat('dd/MM/yyyy')
La gestion d'erreurs se reconstruit
Make attache des gestionnaires d'erreur aux modules (Resume, Ignore, Break, Rollback, Commit) et conserve les exécutions incomplètes ; Zapier relance les étapes en échec (Autoreplay). n8n fonctionne sur trois niveaux : Retry On Fail dans les réglages du nœud, On Error pour arrêter, continuer ou router l'item vers une sortie d'erreur, et un Error Workflow démarré par un nœud Error Trigger à chaque échec. n8n permet de relancer manuellement une exécution échouée, mais sans reprise automatique équivalente à celle de Make : si ton scénario en dépendait, conçois une table des items en échec et un workflow de rejeu.
Les 6 pièges qui cassent une migration vers n8n
Les migrations qui tournent mal cassent rarement sur la logique métier : elles cassent sur la plomberie — webhooks, identifiants, erreurs silencieuses, formats, limites d'API et scénarios non documentés.
Piège 1 : les URL de webhooks changent
Chaque système qui appelait l'URL Make ou Zapier — formulaires, CRM, outil de paiement — doit recevoir la nouvelle URL n8n ; un émetteur oublié envoie ses données dans le vide, sans erreur visible. Dans n8n, l'URL de test et l'URL de production sont distinctes, et la seconde ne répond que si le workflow est activé : configurer l'émetteur avec l'URL de test est une erreur classique.
Piège 2 : les identifiants OAuth sont à recréer
Aucun identifiant ne se transfère. En self-hosted, certaines applications exigent en plus ta propre application OAuth : pour Google, il faut déclarer un client OAuth dans la console Google Cloud avec l'URL de redirection de ton instance. Profites-en pour recréer chaque connexion sur un compte technique, avec les droits minimum.
Piège 3 : la gestion d'erreurs n'existe pas encore
Un workflow fraîchement reconstruit n'a aucune alerte par défaut : s'il échoue à 3 h du matin, personne ne le sait. Avant la bascule, chaque workflow doit avoir son Error Workflow, des relances sur les appels d'API et une alerte qui arrive chez quelqu'un qui la lit.
Piège 4 : les formats de dates et de données
Sur nos doubles runs, les fuseaux horaires sont la première source d'écart : n8n utilise le fuseau du workflow ou, à défaut, celui de l'instance (GENERIC_TIMEZONE en self-hosted), et une instance restée en UTC décale planifications et dates d'une ou deux heures. Ajoute jetons de format, index de tableaux, décimales et champs vides : aucun de ces écarts ne déclenche d'erreur, ils produisent des données fausses.
Piège 5 : les limites de débit des API
n8n traitant tous les items d'un nœud d'un coup, 500 contacts peuvent devenir 500 appels d'API en quelques secondes, là où Make les traitait un par un. Résultat : des erreurs 429 (« trop de requêtes »). La parade : l'option de batching du nœud HTTP Request, un Loop Over Items avec un nœud Wait, et un Retry On Fail avec délai.
Piège 6 : les scénarios fantômes
Un Zap créé par un stagiaire qui alimente toujours le tableau de bord commercial, une automatisation trimestrielle qu'on découvre le jour où elle ne tourne plus. Pour les attraper, consulte l'historique d'exécution sur au moins un trimestre.
Résilier Make ou Zapier le jour où le dernier workflow n8n passe au vert. Les flux mensuels, trimestriels ou annuels n'ont pas encore tourné : c'est le jour où ils se déclenchent qu'on découvre qu'ils manquaient à l'inventaire. Garde l'ancien compte actif, scénarios migrés désactivés, jusqu'au prochain cycle long : un flux oublié continuera de tourner au lieu de disparaître en silence.
Contactez-nous si tu veux un inventaire honnête de ton parc Make ou Zapier — on te dit, scénario par scénario, ce qui vaut la peine d'être migré.
Combien coûte une migration vers n8n ?
CZ Multimédia chiffre la migration d'un workflow simple entre 800 et 2 000 € HT, un premier lot (POC) entre 2 000 et 4 000 € HT et un parc complet de PME entre 4 000 et 10 000 € HT, 3 mois de maintenance inclus.
Ce sont les fourchettes de notre grille 2026, détaillée dans notre article sur le prix d'un projet n8n. Une migration se chiffre comme une construction, parce que c'en est une.
| Périmètre | Fourchette CZ Multimédia |
|---|---|
| Migration d'un workflow simple | 800 – 2 000 € HT |
| Premier lot de migration (POC) | 2 000 – 4 000 € HT |
| Parc complet de PME (plusieurs workflows) | 4 000 – 10 000 € HT |
| Workflow intégrant de l'IA | 3 000 – 8 000 € HT |
| Maintenance | 3 mois inclus, puis à partir de 200 €/mois |
| Hébergement self-hosted (VPS français) | 20 – 60 €/mois |
Le prix dépend de ce que révèle l'inventaire : scénarios réellement à migrer après tri, complexité, intégrations sans nœud natif, gestion d'erreurs à concevoir, émetteurs de webhooks à mettre à jour. C'est le cadre de nos missions d'intégration n8n : un devis construit sur l'inventaire, pas à l'aveugle.
Les délais se comptent en cycles métier
La reconstruction n'est pas ce qui allonge une migration : c'est le double run, qui doit couvrir un cycle métier complet de chaque flux critique. Un parc de flux quotidiens se valide vite ; un parc qui inclut la facturation mensuelle attend une clôture. Évite de caler la bascule la semaine d'une clôture comptable.
Quand la migration est-elle rentable ?
Le calcul : coût de migration ÷ (abonnement mensuel actuel − hébergement − maintenance) = nombre de mois avant rentabilité. Côté n8n self-hosted, compte 20 à 60 €/mois d'hébergement, plus une maintenance à partir de 200 €/mois après les 3 mois inclus si tu la délègues. Abonnement faible et stable : seule la maîtrise des données justifie la migration. Abonnement qui grimpe avec le volume : le calcul bascule vite en faveur de n8n.
Une fois les dépendances cartographiées, migre en priorité les scénarios qui consomment le plus d'opérations ou de tâches, pas les plus faciles. Les statistiques d'usage de Make et de Zapier te donnent ce classement en quelques minutes.
Après la migration : n8n self-hosted ou n8n Cloud ?
Le self-hosted est le choix par défaut quand tu veux garder les données chez toi et sortir de la facturation à l'usage ; n8n Cloud reste pertinent si personne ne peut exploiter un serveur.
En self-hosted, n8n tourne sur ton serveur — typiquement un VPS français à 20 à 60 €/mois. En contrepartie, quelqu'un gère mises à jour, sauvegardes, HTTPS et surveillance : notre guide pour déployer n8n avec Docker détaille l'installation et la sécurisation. Point critique : la clé N8N_ENCRYPTION_KEY chiffre tous les identifiants ; la perdre oblige à recréer toutes les connexions.
n8n Cloud est hébergé et maintenu par l'éditeur, avec une facturation à l'exécution bien plus prévisible qu'une facture à l'opération — une option raisonnable pour une équipe sans compétence serveur.
Sur la licence, soyons exacts : n8n n'est pas open source au sens de l'OSI. C'est un logiciel « fair-code » sous Sustainable Use License : code public, auto-hébergement gratuit pour les besoins internes de ton entreprise, mais revente de n8n comme service restreinte, et certaines fonctions sous licence entreprise.
Cas terrain : ce que coûte un workflow n8n en production
Deux projets clients réels donnent l'ordre de grandeur de ce que tu reconstruis en migrant : un workflow à 3 400 € HT qui tourne pour environ 35 €/mois, et une extraction de factures à 7 800 € HT qui revient à environ 320 €/mois tout compris.
PME du bâtiment (8 personnes), devis automatisés : 3 400 € HT. Récurrent : environ 35 €/mois sur un VPS mutualisé, sans forfait de maintenance. Résultat : environ 4 heures par semaine récupérées et zéro demande perdue, un projet remboursé en moins de 6 mois en valorisant l'heure à 40 €.
Cabinet comptable (20 personnes), extraction de factures : 7 800 € HT, dont 1 300 € pour la file de validation humaine. Récurrent : environ 320 €/mois tout compris (VPS dédié ~45 €, API de modèle de langage 60 à 90 €, surveillance 200 €). Résultat : plus de 80 % des factures traitées sans intervention humaine, soit un gain estimé à un mi-temps de saisie.
Ce qu'on en retient : les tests sur données réelles ne sont jamais optionnels, le récurrent dépend surtout de la criticité du flux, et dans nos migrations, la partie la plus longue n'est pas la reconstruction mais l'inventaire et le double run.
Checklist avant de lancer ta migration
Tous les scénarios Make ou Zaps sont inventoriés, actifs et inactifs, avec volume et propriétaire
L'historique d'exécution a été consulté sur au moins un trimestre
Chaque URL de webhook appelée depuis l'extérieur est listée avec son émetteur
Les identifiants sont recréés sur des comptes techniques, pas personnels
Chaque workflow n8n a un Error Workflow et des relances sur les appels d'API
Le fuseau horaire de l'instance et des workflows est vérifié (Europe/Paris)
Le double run couvre un cycle métier complet, sans effets de bord en double
L'ancien compte reste actif, scénarios migrés désactivés, jusqu'au prochain cycle long
FAQ
Peut-on convertir automatiquement un scénario Make ou un Zap en workflow n8n ?
Non. Il n'existe aucun outil officiel de conversion, ni chez Make, ni chez Zapier, ni chez n8n. Scripts communautaires et assistants IA produisent au mieux un squelette à reprendre nœud par nœud : tout se reconstruit, ce qui permet de simplifier au passage.
Combien coûte une migration de Make ou Zapier vers n8n ?
CZ Multimédia chiffre un workflow simple entre 800 et 2 000 € HT, un premier lot (POC) entre 2 000 et 4 000 € HT et un parc complet de PME entre 4 000 et 10 000 € HT, maintenance incluse 3 mois puis à partir de 200 €/mois.
Pourquoi n8n coûte-t-il moins cher que Make ou Zapier à gros volume ?
Make décompte chaque module exécuté et Zapier chaque action réussie : la facture grandit avec le volume et le nombre d'étapes. n8n Cloud compte un passage complet comme une seule exécution, et le self-hosted supprime le compteur : tu paies le serveur, pas l'usage.
Combien de temps dure une migration vers n8n ?
Elle dépend surtout du double run, qui doit couvrir au moins un cycle métier complet : une semaine pour un flux quotidien, un mois pour un flux de facturation mensuelle. La bascule se fait ensuite flux par flux.
Faut-il héberger n8n soi-même après une migration ?
Pas obligatoirement. Le self-hosted garde les données chez toi pour 20 à 60 €/mois sur un VPS français, mais suppose mises à jour, sauvegardes et surveillance ; n8n Cloud évite cette exploitation. n8n reste un logiciel fair-code, pas open source au sens de l'OSI.
Dans quels cas vaut-il mieux ne pas migrer vers n8n ?
Quand tu as peu de scénarios à faible volume, une équipe non technique sans support, ou une intégration native critique absente de n8n. Une migration partielle, limitée aux flux lourds, est alors souvent la meilleure réponse.
Conclusion
- Migrer vers n8n est rentable quand la facture suit le volume ou quand les données doivent rester chez toi — pas pour cinq Zaps peu utilisés.
- Aucun outil officiel ne convertit un scénario Make ou un Zap : tout se reconstruit.
- 5 étapes : inventaire, cartographie, reconstruction, double run, bascule — les incidents naissent d'un inventaire ou d'un double run bâclé.
- Les pièges sont prévisibles : webhooks, identifiants OAuth, gestion d'erreurs, formats, limites d'API, scénarios fantômes.
- CZ Multimédia chiffre un workflow simple 800 – 2 000 € HT et un parc complet de PME 4 000 – 10 000 € HT, puis 20 à 60 €/mois d'hébergement self-hosted.
Commence par l'inventaire : il dit si la migration vaut le coup, dans quel ordre la mener et pour quel budget. Notre équipe d'experts n8n peut le réaliser avec toi.
Contactez-nous — réponse sous 24h, sans engagement, et on te dit honnêtement si ta migration vaut le coup.
Vous voulez savoir si votre site peut vraiment générer plus de clients ?
J’aide les PME à améliorer leur site web et leurs projets digitaux pour générer plus de demandes clients.
Je vous propose un audit gratuit, rapide et sans engagement.
Sans engagement • Recommandations concrètes • Réponse sous 24h