Migrer de Zapier à n8n sans rien arrêter : par vagues, en double exécution, avec un retour arrière

Avant de bouger un seul Zap : l'inventaire qui décide de l'ordre

Presque tous ceux qui cherchent comment migrer de Zapier à n8n commencent pareil : ouvrir n8n et monter le premier flux. Mauvais ordre. Construire n'est pas la première étape. Savoir ce que tu as d'allumé, qui appelle quoi, et dans quel ordre on peut éteindre quelque chose sans que ça fasse tomber autre chose derrière : ça, c'est la première étape.

La décision, tu l'as prise. Si tu en es encore au « je change ou pas ? », ça se règle dans les alternatives à Zapier pour l'entreprise et dans n8n vs Make vs Zapier. Ce guide commence là où ceux-là finissent : tu sais où tu vas, il faut maintenant y arriver sans éteindre la lumière.

L'inventaire n'est pas une liste de noms de Zaps. C'est une fiche courte par flux, six données et pas une de plus :

• Ce qui le déclenche. Un webhook, une planification ou un changement dans une application. Ceux en webhook font le plus mal, et tu verras pourquoi dans un instant.
• Quelles applications il touche, en séparant ce qu'il lit de ce qu'il écrit. Ce qu'il écrit, c'est ce qui met le bazar dans un vrai système si les deux flux tournent en même temps.
• Qui l'appelle depuis l'extérieur. Un formulaire, l'interface d'un autre prestataire, le script de quelqu'un. C'est la colonne que personne ne remplit et celle qui provoque la frayeur.
• Ce qui se passe s'il est arrêté une heure. « C'est important » ne suffit pas : qu'est-ce qu'on perd et qui le remarque.
• Avec quel compte il se connecte à chaque application, et à qui appartient ce compte.
• Qui le comprend, avec un nom et un prénom. Si la réponse est « personne », ce flux ne se migre pas encore : d'abord on le déchiffre.

Le premier obstacle est une histoire d'offre. Zapier permet d'exporter les Zaps en JSON depuis les paramètres du compte, dans la section sécurité et données, mais uniquement sur Team et Enterprise : sur Free et Professional, il n'y a pas de bouton. Si tu es sur Professional —là où vit beaucoup d'entreprises moyennes— l'inventaire se fait à la main, Zap par Zap, et cet après-midi-là entre dans le devis.

Avec l'inventaire sous les yeux, l'ordre s'impose tout seul. On ne migre pas du facile au difficile : on migre du réversible à l'irréversible. Une notification interne peut être mal migrée et réparée en dix minutes. Un flux qui émet une facture ou envoie un mail à un client n'accepte pas le « on corrigera demain ».

Par vagues, pas d'un coup : des morceaux qu'on peut défaire

L'erreur la plus chère d'une migration n'est pas technique, elle est de taille. Déplacer les quarante flux le même week-end, ça veut dire que le lundi, quand quelque chose lâchera, tu déboguera quarante choses à la fois. Migrer par vagues, ce n'est pas aller lentement : c'est pouvoir désigner la cause.

Une vague, c'est un groupe de flux qu'on migre, qu'on observe et qu'on valide ensemble — et qu'on peut rendre à Zapier ensemble. Quatre suffisent en général :

1. Vague zéro : la plomberie. Aucun flux métier. On monte n8n, on connecte les identifiants des applications qui reviennent partout et on construit le flux d'erreurs. La sauter, c'est faire les trois suivantes à l'aveugle.
2. Vague un : le réversible. Notifications internes, rapports, synchronisations qu'on peut relancer. On apprend l'outil avec un coût de l'erreur proche de zéro.
3. Vague deux : le volume. Les flux longs et à fort trafic, ceux qui justifiaient la migration.
4. Vague trois : le client et l'argent. Facturation, contrats, mails qui sortent, écritures dans l'ERP. En dernier, avec une longue double exécution et quelqu'un qui regarde.

Et une vague ne se termine pas quand le nouveau flux marche. Elle se termine quand quatre choses sont vraies : il a passé une période convenue à produire le même résultat que l'ancien, ses alertes sont montées et testées, quelqu'un qui ne l'a pas construit sait le lire, et le Zap d'origine est éteint mais pas supprimé. Tant qu'il en manque une, la vague suivante ne démarre pas.

Ce qu'on ne copie pas : le Zap linéaire de trente étapes se repense

Voici la tentation qui ruine des migrations qui se passaient bien : ouvrir le Zap, compter ses étapes et reproduire un par un les mêmes trente nœuds dans n8n. Tu obtiens un flux qui marche le premier jour et que personne ne peut maintenir au sixième mois : tu as traduit littéralement une structure qui n'existait qu'à cause d'une limite de l'outil que tu quittes.

Zapier est une chaîne : un déclencheur et une file d'étapes. Quand il faut deux chemins, l'usage est de découper le processus en plusieurs Zaps enchaînés par un champ intermédiaire. n8n est un canevas avec des branches, des boucles et des sous-flux, et cette collection de Zaps tenue au scotch se réduit souvent à un seul flux à deux branches. C'est la différence entre pouvoir changer quelque chose dans un an ou ne pas oser y toucher.

Attention, tout ne se repense pas. Le flux de deux étapes qui fait une chose et la fait bien se copie tel quel. La règle tient en une ligne : s'il s'explique en une phrase, on copie ; s'il te faut un paragraphe et un « sauf quand », on repense.

Les convertisseurs automatiques : point de départ, jamais livraison

Ni Zapier ni n8n ne proposent de pont officiel entre les deux plateformes. Ce qui existe, ce sont des convertisseurs tiers qui lisent le JSON exporté et rendent un flux n8n approximatif. Ils sont utiles et prennent en charge la partie mécanique : mappage des champs, noms, forme générale. Sers-t'en.

Puis traite-les pour ce qu'ils sont : un brouillon. Un convertisseur traduit la structure, et la structure est précisément ce que tu avais décidé de ne pas copier. Il n'apporte pas les identifiants, ne monte pas la gestion d'erreurs, et ne peut pas voir que ces trois Zaps sont en réalité un seul processus. Livrer la sortie d'un convertisseur, c'est livrer le problème traduit.

Identifiants et OAuth : c'est là qu'est le vrai travail

Demande à n'importe qui ayant fait cette migration ce qui a mangé les heures et il ne dira pas la logique : il dira les accès. Un export emporte la structure du flux, jamais la clé pour entrer dans les applications. Ce n'est pas un manque des convertisseurs : les identifiants vivent dans la connexion, pas dans l'étape.

La documentation de Zapier est claire même dans le cas le plus simple, importer des Zaps dans Zapier : ensuite il faut les allumer et tester les connexions aux applications, en reconnectant celles qui ne sont plus actives. Entre deux plateformes différentes, tout se réauthentifie, une par une, à la main. Trois pièges transforment cet après-midi en semaine :

• Le compte personnel. Une demi-douzaine de connexions sont en général faites avec le compte d'une personne précise. La migration est la seule occasion pas chère de tout basculer sur des comptes de service ; si tu répètes le schéma, tu as juste déplacé la dette.
• Les droits OAuth. Autoriser une nouvelle application sur Google Workspace, Microsoft 365 ou Salesforce n'est pas toujours à la portée de celui qui monte le flux : dans beaucoup d'entreprises, c'est un administrateur qui approuve. Ce n'est pas un clic, c'est un ticket avec un délai que tu ne contrôles pas. Demande-le en vague zéro.
• Les adresses de webhook. Un Zap déclenché par webhook a une URL collée dans des endroits que tu ne contrôles pas. Elle change en migrant. Si personne ne met la source à jour, le nouveau flux ne plante pas : il ne reçoit simplement rien.

Double exécution : les deux en marche jusqu'à ce qu'éteindre soit ennuyeux

La double exécution, c'est la période où l'ancien flux et le nouveau traitent la même chose en même temps et où tu compares leurs sorties avant d'en éteindre un. Elle transforme la bascule —le moment qui fait peur— en formalité : quand tu éteins le Zap, tu sais déjà, données à l'appui, que le flux n8n fait la même chose.

Il y a un piège à régler avant de commencer : si les deux écrivent au même endroit, tu viens de dupliquer chaque commande et chaque facture. C'est pour ça que le nouveau flux tourne en ombre : il lit la vraie source et écrit dans une destination parallèle. La vraie destination ne lui est confiée que quand la comparaison ne réserve plus de surprises. Et comparer, ce n'est pas « ça a l'air d'aller ». C'est quatre choses :

1. Le décompte. Les mêmes cas sont-ils entrés dans les deux ? Si le nouveau en a traité moins, tu as un déclencheur mal monté ou un filtre de trop.
2. Le contenu champ par champ, sur un échantillon réel. C'est là que sortent les formats de date, les décimales et le champ vide parce qu'il portait un autre nom.
3. Les cas bizarres, exprès. La commande sans client, le mail sans objet, le montant à zéro. Le chemin heureux coïncide toujours ; la migration casse sur la poignée de cas qui ne rentre pas.
4. Le calendrier. Laisse passer la clôture du mois ou le cycle de facturation, ce qui n'arrive que le premier du mois.

Combien de temps dure la double exécution ne se mesure pas en jours : ça se mesure en cas vus. Un flux qui se déclenche mille fois par jour épuise sa variété en une semaine. Un flux qui se déclenche quand un appel d'offres arrive attend qu'un appel d'offres arrive. Fixer une date de bascule, c'est la façon élégante de couper trop tôt.

Alertes et retour arrière : ça se monte avant la bascule, pas après

Un flux migré n'est pas terminé quand il marche. Il est terminé quand tu vas apprendre qu'il a cessé de marcher et que tu peux revenir en arrière sans improviser. Les deux se montent avant d'éteindre quoi que ce soit, parce qu'après plus personne ne les monte : dès que le nouveau flux tourne, l'attention part avec la vague suivante.

Dans n8n, ça porte un nom précis. On crée un flux à part qui commence par le nœud Error Trigger et on le sélectionne comme flux d'erreurs dans les réglages de chaque flux important. Et attention à un détail de la documentation de n8n qui piège beaucoup de monde : ce flux d'erreurs ne peut pas être testé en exécution manuelle, parce que l'Error Trigger ne se déclenche que quand une exécution automatique échoue. Teste-le en provoquant une vraie panne, sinon tu apprendras qu'il ne marchait pas le jour où tu en avais besoin.

Ça couvre ce qui tombe en faisant du bruit. Ce qui meurt en silence —le flux qui ne reçoit plus parce que personne n'a mis à jour l'URL du webhook— aucune alerte ne le détecte, parce qu'il n'y a pas d'erreur : il n'y a rien. Surveiller l'absence est l'autre moitié du travail et c'est développé dans détecter les pannes d'automatisation.

Le plan de retour arrière est la chose la moins chère à écrire et celle que personne n'écrit. Par vague, trois phrases : quel Zap on rallume, quel flux n8n on éteint et où il faut remettre l'URL du webhook. Si ça ne peut pas s'exécuter en cinq minutes sans demander à personne, tu n'as pas un plan : tu as une intention.

Quand la dernière vague se ferme, ce que tu as n'est pas « la même chose mais dans n8n » : ce sont des flux neufs qu'à partir de demain il faut exploiter. C'est là que commence le travail de les maintenir en vie et de gouverner ce qu'ils font. Monter n8n pour qu'il tienne dans une vraie entreprise, c'est dans n8n pour l'entreprise ; la carte complète, dans le guide pour automatiser avec l'IA.