Migration d'outil d'automatisation : checklist complète

Tu as décidé de quitter Zapier pour n8n. Ou de partir de Make pour passer en self-hosted. Ou l’inverse, peu importe. La migration d’outil d’automatisation est un projet à part entière, pas un copier-coller géant. J’ai mené plus de 30 migrations depuis 2021, et celles qui se passent mal ont toujours un point commun : pas de méthode, pas de checklist, on fonce.

Cet article est la checklist exacte que j’utilise sur chaque migration. Si tu la suis, tu réduis tes risques de casse de production de 80%. Si tu l’ignores, tu vas apprendre dans la douleur. Tu choisis.

Phase 1 : audit avant migration

Avant de toucher quoi que ce soit, passe 1 à 2 jours en audit complet de ton existant. C’est l’étape que tout le monde veut sauter, et c’est précisément celle qui détermine la réussite.

Inventorier tous les workflows actifs

Liste exhaustive : nom, fonction métier, fréquence d’exécution, volume mensuel d’opérations, criticité (1 à 5), date de dernière modification, propriétaire interne. Tu vas découvrir des workflows zombies que personne n’a regardé depuis 18 mois, qui tournent quand même et consomment du quota. Décision à prendre : on migre, on archive, ou on supprime ?

Sur mes derniers audits, 30 à 40% des workflows actifs étaient soit obsolètes soit redondants. Ne migre jamais un workflow inutile, c’est de la dette technique gratuite.

Cartographier les intégrations utilisées

Pour chaque workflow, liste les services tiers connectés : Slack, Stripe, HubSpot, Airtable, Notion, etc. C’est crucial parce que la disponibilité native d’un connecteur diffère entre outils. Zapier a 6000+ connecteurs, n8n en a 500+ natifs. Pour les manquants, il faudra des appels HTTP custom — c’est faisable mais ça change l’estimation.

Note aussi les versions d’API utilisées. Certaines intégrations Zapier utilisent en interne des endpoints v1 dépréciés, et tu ne peux pas le savoir tant que tu n’as pas creusé.

Identifier les dépendances cachées

Les pièges classiques :

• Webhooks externes pointés vers ton outil actuel (URLs Zapier ou Make)
• Cron jobs déclenchés depuis l’outil
• Variables d’environnement stockées dans l’outil et utilisées par plusieurs workflows
• Stockage interne (Storage chez Zapier, Data Stores chez Make) qui contient des données métier

Chacune de ces dépendances doit être migrée séparément, et leur ordre de migration compte.

Mesurer les volumes réels

Combien d’opérations par jour, par workflow ? Tu vas baser tout ton dimensionnement (VPS, plan SaaS, etc.) là-dessus. Triple le volume actuel pour ton dimensionnement cible — la croissance et les retries surprises font exploser les compteurs.

Phase 2 : choisir la cible

Sur le papier tu sais où tu vas. En pratique, valide encore avant de t’engager.

Tester sur 1 à 3 workflows pilotes

Choisis 3 workflows représentatifs : un simple (déclencheur + 2-3 actions), un moyen (avec logique conditionnelle), un complexe (boucles, API custom). Reconstruis-les intégralement dans la nouvelle plateforme sans rien casser dans l’ancienne. Tu vas découvrir :

• Quelles intégrations manquent
• Quels comportements diffèrent (ex : gestion des dates, fuseaux horaires, encodages)
• Quelle est la courbe d’apprentissage réelle pour ton équipe

Si après ces 3 pilotes tu n’es pas convaincu, arrête tout. Mieux vaut perdre 2 jours d’audit que 3 mois de migration ratée. J’ai eu des clients qui ont changé d’avis à cette étape et c’est sain.

Vérifier le pricing à volume réel

Sur n8n cloud, le pricing est par exécution, mais une exécution peut contenir plusieurs étapes. Sur Make, c’est par opération individuelle. Sur Zapier, par task. Ces unités ne sont pas comparables. Refais le calcul avec ton volume réel avant de signer.

J’ai vu une PME persuadée d’économiser en migrant de Zapier à Make. Calcul à la volée : 50% d’économie. Calcul détaillé sur volume réel : 12% seulement, parce que les itérations comptaient comme opérations multiples sur Make. Différence pas négligeable dans la décision.

Mon comparatif détaillé n8n vs Make vs Zapier reprend les vrais prix à volume équivalent.

Anticiper les contraintes infra

Si tu migres vers n8n self-hosted, tu prends en charge :

• Le serveur (VPS, AWS, Hetzner) : 5 à 30 €/mois selon le dimensionnement
• Les sauvegardes automatiques de la DB
• Les certificats SSL (Caddy ou Let’s Encrypt)
• Les mises à jour de version (mensuelles a minima)
• Le monitoring (Uptime Kuma, Healthchecks.io)

Ce n’est pas de la dépense mais de la responsabilité. Si personne en interne ne sait gérer un Linux, prends du n8n cloud ou un prestataire en infogérance.

Phase 3 : préparer la migration

Geler l’ancien environnement

Plus aucune nouvelle modif dans Zapier/Make pendant la phase de migration. Tu ne fais que corriger les bugs critiques de prod. Sinon tu te retrouves avec deux environnements qui divergent et impossible à reconnecter. Communique clairement cette règle à toute l’équipe.

Préparer les credentials

Toutes les API keys, tokens OAuth, secrets : prépare-les en avance dans la nouvelle plateforme. Pour OAuth, anticipe que certains services exigent de re-valider côté provider (Google, Microsoft notamment, qui demandent des scopes spécifiques par application appelante).

Stocke les credentials dans un vault dédié (Bitwarden, 1Password, ou la gestion native n8n). Ne les écris jamais dans un Notion partagé.

Provisionner la nouvelle infrastructure

Si self-hosted, monte le VPS, installe Docker, déploie n8n, configure le reverse proxy, vérifie le SSL, fais un dump test. Si SaaS, crée le workspace, invite les utilisateurs, configure les rôles. Cette phase prend 1 à 3 jours selon la complexité.

Documenter les workflows actuels

C’est probablement la dernière fois que tu pourras le faire facilement. Capture screenshots de chaque workflow Zapier/Make complet, écris en français ce qu’il fait, ses entrées et sorties. Cette doc va te servir de référence pendant la migration et te sauver des heures de debug. J’en parle en détail dans mon article sur comment documenter ses workflows pour qu’ils survivent au turnover.

Phase 4 : la migration elle-même

Migrer par criticité inverse

Commence par les workflows les moins critiques. Pas les plus simples : les moins critiques. Un workflow simple mais qui envoie tes factures clients est plus critique qu’un workflow complexe qui poste dans un Slack interne. Tu veux apprendre l’outil sur du non-critique avant de toucher au revenu.

Ordre recommandé :

1. Workflows internes (notifications Slack, reporting)
2. Workflows clients non-critiques (welcome emails)
3. Workflows métier (CRM, lead nurturing)
4. Workflows critiques revenu (facturation, paiement)

Faire tourner en parallèle (double run)

Pour les workflows critiques, fais tourner les deux versions en parallèle pendant 7 à 14 jours. L’ancienne reste en prod, la nouvelle reçoit les mêmes événements mais ses actions sortantes sont désactivées ou redirigées vers un environnement de test. Tu compares les outputs et tu valides que tout est identique.

C’est coûteux (double les opérations consommées) mais c’est le seul moyen d’avoir confiance dans le switch final. Sur les workflows revenu, n’économise jamais cette étape.

Basculer en deux temps

Le jour J du switch : tu désactives l’ancien workflow, tu actives le nouveau. Puis tu surveilles en continu pendant 48 heures. Si quoi que ce soit déraille, tu rebascules immédiatement vers l’ancien. C’est pour cette raison qu’on ne supprime jamais l’ancien workflow tout de suite : il reste en standby pendant 30 jours minimum.

Migrer les webhooks externes

Les URLs Zapier ou Make hardcodées chez tes partenaires doivent être mises à jour. Liste-les avant la migration, contacte chaque partenaire, mets à jour, teste. C’est la phase la plus oubliée et la plus dangereuse : un webhook qui pointe encore vers Zapier après désactivation, c’est un workflow qui ne se déclenche plus du tout.

Phase 5 : validation post-migration

Plan de tests systématiques

Pour chaque workflow migré, liste 3 à 5 scénarios de test : nominal, edge case 1, edge case 2, erreur attendue, donnée corrompue. Exécute-les manuellement après la mise en prod. C’est fastidieux, c’est obligatoire.

Monitoring renforcé

Pendant les 30 premiers jours, multiplie par 3 ta fréquence de vérification des logs. Une alerte Slack pour chaque erreur, même mineure. Une review hebdomadaire des exécutions partielles. Cette vigilance accrue rattrape les bugs qui n’apparaissent que sur volume.

Bilan financier réel

Au bout de 60 jours, compare ce qui était promis et ce qui s’est passé. Économies réalisées, temps passé, casses encourues, coûts d’urgence. Ce bilan honnête te servira pour la prochaine migration.

Les 7 erreurs qui plombent une migration

1. Migrer sans audit préalable : tu migres des workflows zombies, tu gaspilles du temps
2. Sous-estimer le mapping des données : les formats diffèrent subtilement entre outils
3. Oublier les webhooks externes : pannes silencieuses pendant des jours
4. Pas de double run : tu découvres les bugs en prod
5. Migrer en période chargée : ne fais pas ça en clôture trimestrielle ou en peak saison
6. Couper l’ancien trop tôt : garde-le actif (mais inactif) 30 jours minimum
7. Pas de doc post-migration : tu te retrouves avec une nouvelle stack opaque

Combien ça coûte, combien ça prend

Pour une PME avec 15 workflows actifs, migration Zapier vers n8n self-hosted :

• Audit + cartographie : 2 à 3 jours
• Pilotes : 2 à 3 jours
• Setup infra n8n : 1 à 2 jours
• Migration des workflows : 0.5 à 1.5 jour par workflow selon complexité, soit 10 à 20 jours
• Validation et stabilisation : 3 à 5 jours

Total : 20 à 35 jours-personne, soit 12 000 à 25 000 € en freelance senior. Sur 3 ans, l’économie de licences peut compenser largement (un client est passé de 14 400 € de licences Zapier annuelles à 1 200 € de n8n cloud, soit 13 200 € d’économie par an).

Si tu hésites encore sur l’outil cible, lis mon comparatif n8n vs Make vs Zapier 2026 avant de te lancer.

Conclusion : la migration est un projet, pas une tâche

La grosse erreur que je vois encore en 2026, c’est de traiter la migration comme une journée de travail un week-end. Ça ne marche jamais. C’est un projet de plusieurs semaines, avec une phase d’audit, une phase de migration, une phase de stabilisation. Si ton prestataire te promet de tout migrer en 3 jours pour 2000 €, fuis.

Une migration bien menée, c’est un changement structurant qui rend ton automatisation plus robuste, plus économique, plus maintenable pour les 3 années à venir. Une migration mal menée, c’est une crise qui dure 6 mois et qui te dégoûte de l’automatisation pour toujours.

Si tu veux un accompagnement sur une migration à venir, je propose des audits d’automatisation qui incluent le plan de migration détaillé. On regarde ton existant, on chiffre le projet précisément, et on te donne le go/no-go avec les vrais coûts. Mieux vaut investir 1 journée d’audit qu’engager une migration aveugle.