La décision de migrer de Zapier vers n8n, ou plus généralement de changer d'outil d'automatisation, se prend presque toujours pour une bonne raison : la facture au volume qui s'emballe, un besoin d'hébergement maîtrisé, ou un plafond fonctionnel atteint. La migration, elle, échoue rarement sur le fond technique. Elle échoue sur ce que personne n'avait inventorié.
Un scénario d'automatisation n'est pas un objet isolé. Il porte des identifiants de connexion créés par une personne qui a quitté l'entreprise, des adresses de réception configurées dans un service tiers qu'on ne maîtrise pas, un historique de déduplication qui l'empêche de retraiter d'anciens éléments, et parfois des dépendances entre scénarios que le schéma visuel ne montre pas.
Cet article donne le déroulé complet d'une migration de workflows : inventaire, repérage des dépendances cachées, traitement des secrets, période de double exécution et bascule progressive. Il ne compare pas les outils, sujet déjà couvert dans notre comparatif des orchestrateurs. Il traite le passage de l'un à l'autre.
Étape 1 : l'inventaire, plus long qu'annoncé
Personne ne connaît le nombre exact de ses automatisations. Comptez une à deux journées pour un parc de 30 à 60 scénarios, et démarrez par l'export de la liste complète depuis l'outil source, y compris les scénarios désactivés.
Pour chaque scénario, six informations suffisent :
- Le déclencheur exact : planification, appel entrant, sondage périodique, événement d'un service tiers.
- Les services appelés, avec le compte utilisé pour chacun.
- Le volume mensuel d'exécutions et la date de la dernière exécution réussie.
- La criticité métier, sur trois niveaux seulement.
- Le propriétaire, une personne nommée.
- Les scénarios amont et aval, s'il y en a.
Cet inventaire produit systématiquement le même résultat : entre 20 et 40 % des scénarios n'ont pas tourné depuis des mois, ou tournent à vide. Ne les migrez pas. Une migration est la seule occasion politiquement acceptable de supprimer des automatisations, saisissez la. Le travail d'inventaire ressemble beaucoup à celui décrit dans documenter ses automatisations, et si cette documentation existe déjà, vous venez de gagner une semaine.
Étape 2 : les dépendances cachées
Ce sont elles qui font les migrations douloureuses. Cinq catégories reviennent systématiquement.
Les adresses d'appel entrant
Un scénario déclenché par un appel entrant possède une adresse unique, générée par l'outil. Cette adresse est configurée ailleurs : dans un formulaire, dans un logiciel de caisse, chez un partenaire, parfois dans un service dont plus personne n'a les accès. Changer d'outil change l'adresse. Recensez chaque endroit où elle est déclarée avant de commencer, et prévoyez, quand c'est possible, une redirection depuis un domaine que vous maîtrisez : cela vous évitera de revivre le même exercice à la prochaine migration.
L'état de déduplication
Un scénario qui surveille une boîte de réception ou une feuille de calcul mémorise ce qu'il a déjà traité. Ce marqueur reste dans l'outil source. Au premier démarrage sur le nouvel outil, tout est neuf : sans précaution, vous renvoyez trois mille courriels ou recréez huit cents lignes. Chaque nouveau scénario doit démarrer avec un filtre de date explicite, positionné à l'heure de bascule.
Les identités techniques
Beaucoup de connexions ont été créées avec le compte personnel de quelqu'un. La migration est le moment de basculer sur des comptes de service dédiés, avec des droits limités au strict nécessaire. C'est du travail supplémentaire immédiat, et c'est ce qui évite qu'un départ ne casse la moitié du parc.
Les traitements en cours
Un scénario long, ou en attente d'une réponse humaine, peut être à mi parcours au moment de la bascule. Recensez ces cas et laissez les se terminer sur l'ancien outil. Ne migrez jamais une exécution en cours.
Les limites d'appel des services tiers
Pendant la double exécution, vous appelez chaque service deux fois. Si vous êtes déjà proche d'un plafond, vous le franchirez et les deux dispositifs tomberont en même temps. Vérifiez les marges avant, et étalez la bascule si nécessaire.
Étape 3 : les secrets, à ne jamais migrer tels quels
Les clés d'interface et les jetons stockés dans l'outil source ne se récupèrent pas en clair, et c'est heureux. La règle est simple : on ne migre pas un secret, on en émet un nouveau.
La séquence recommandée :
- Créer un nouveau jeu d'identifiants pour chaque service, sur un compte de service dédié.
- Les enregistrer dans le nouvel outil, avec des droits d'accès restreints aux personnes qui en ont besoin.
- Basculer les scénarios progressivement, les deux jeux coexistant.
- Une fois la migration terminée et validée, révoquer explicitement les anciens. C'est l'étape systématiquement oubliée : des jetons actifs restent en circulation pendant des mois après l'arrêt de l'ancien outil.
Prévoyez également, dès la mise en place du nouvel environnement, la séparation entre configuration de test et configuration de production. Migrer directement en production sans environnement de recette est possible sur un parc de dix scénarios, très risqué au delà de trente.
Étape 4 : la bascule progressive et la double exécution
La bascule en une nuit est tentante et presque toujours une erreur. La méthode qui tient consiste à faire tourner les deux dispositifs en parallèle, par vagues, avec un des deux en mode observation.
| Phase | Ancien outil | Nouvel outil | Durée type |
|---|---|---|---|
| Observation | Actif, écrit | Actif, n'écrit pas : journalise ce qu'il aurait fait | 1 à 2 semaines par vague |
| Bascule | Désactivé sur la vague | Actif, écrit | Le jour J |
| Filet | Prêt à réactiver | Actif, sous surveillance renforcée | 2 semaines |
| Clôture | Supprimé, secrets révoqués | Seul actif | Après validation |
La phase d'observation est le cœur de la méthode. Le nouveau scénario s'exécute réellement, avec les mêmes entrées, mais ses actions d'écriture sont remplacées par une journalisation. Vous comparez ensuite ligne à ligne ce que les deux dispositifs ont produit. Les écarts révèlent en général deux ou trois différences de comportement auxquelles personne n'avait pensé : un format de date interprété autrement, un champ vide traité différemment, un arrondi.
Ordonnez les vagues par criticité croissante : d'abord les scénarios internes et peu fréquents, ensuite les scénarios à fort volume, en dernier ceux qui touchent au client ou à la facturation. Trois à cinq vagues sur six à dix semaines constituent un rythme réaliste pour un parc de cinquante scénarios.
Le critère d'arrêt
Décidez avant de commencer ce qui déclenche un retour arrière : par exemple, plus de deux écarts non expliqués sur une vague, ou un incident client. Sans critère écrit, la décision se prend sous pression, et généralement dans le mauvais sens.
Étape 5 : ce qu'il faut reconstruire, pas transposer
Une migration réussie ne reproduit pas l'ancien à l'identique. Trois choses gagnent à être reprises au passage.
- La gestion des erreurs. Beaucoup de scénarios historiques échouent en silence. Profitez du portage pour ajouter une reprise sur erreur et une alerte nominative, principe détaillé dans gérer les erreurs de ses workflows automatisés.
- Le découpage. Les scénarios de quarante étapes construits par accumulation gagnent à être scindés en unités testables séparément.
- La journalisation. Un identifiant d'exécution propagé et un enregistrement par traitement rendent le diagnostic possible, ce que l'ancien outil ne permettait souvent pas.
À l'inverse, résistez à la tentation d'ajouter des fonctionnalités pendant la migration. Un périmètre qui bouge rend la comparaison impossible et vous prive de votre seul instrument de contrôle. Les évolutions viennent après la clôture.
Migrer de Zapier vers n8n : combien de temps, et pour quel gain
Repères constatés pour un parc de 40 à 60 scénarios actifs : deux jours d'inventaire, une semaine de préparation d'environnement et de secrets, puis trois à quatre jours de portage par vague. Au total, six à dix semaines calendaires pour une charge réelle de 15 à 25 jours, à condition que quelqu'un porte le sujet en continu.
Le gain, lui, ne se limite pas à la facture. Une migration bien menée produit trois effets durables : un parc réduit d'un tiers, des accès techniques propres, et une documentation à jour, souvent pour la première fois. Si votre motivation initiale est le coût ou la maîtrise de l'hébergement, la comparaison des modèles est traitée dans auto hébergé ou service en ligne pour ses automatisations.
Un dernier conseil : décidez dès maintenant de ce que vous ferez pour ne pas revivre cet exercice. Adresses d'appel entrant derrière un domaine à vous, comptes de service dédiés, scénarios exportés et versionnés en dehors de l'outil. Ces trois habitudes ne coûtent presque rien à tenir, et elles transforment la prochaine migration en formalité.
Laisser un commentaire