Automatisations à migrer depuis Zapier

Ce que Zapier stocke (et ce qu’il ne stocke pas)

Zapier n’est pas une base de données métier. Votre compte Zapier contient des automatisations, des configurations de connexion et optionnellement des données dans Zapier Tables. Vos données métier (clients, commandes, factures) sont dans les applications que Zapier connecte, pas dans Zapier lui-même.

Ce que Zapier stocke :

• Les Zaps : définitions d’automatisations (trigger + actions + logique), exportables en JSON
• L’historique des tâches : log des 90 derniers jours d’exécution, non exportable, non migrable
• Les connexions d’applications : tokens OAuth et API Token, non exportables
• Zapier Tables (si vous en utilisez) : données légères stockées dans Zapier, exportables en CSV
• Zapier Interfaces (si vous en utilisez) : formulaires et pages construits dans Zapier

La migration depuis Zapier est donc principalement une reconstruction d’automatisations, pas une migration de données au sens traditionnel.

---

Exporter vos Zaps depuis l’interface Zapier

L’export des Zaps est disponible depuis les paramètres du compte.

Procédure d’export

1. Ouvrez vos Paramètres du compte (Settings)
2. Dans le menu latéral, section “My account”, sélectionnez Security and data
3. Dans la section “Data management”, cliquez sur l’icône de téléchargement à côté de Download my Zaps
4. Le fichier JSON se télécharge directement sur votre ordinateur

Export de tous les Zaps du compte (propriétaires et super admins)

Si vous êtes propriétaire du compte ou super admin, vous pouvez exporter les Zaps de tous les utilisateurs en cliquant sur Download private and shared Zaps. Zapier envoie alors le fichier JSON par email à l’adresse de votre compte.

Disponibilité selon le plan

Plan	Export de ses propres Zaps	Export de tous les Zaps du compte
Free	Non (uniquement pendant la période d’essai)	Non
Professional	Non	Non
Team	Oui	Oui (propriétaire et super admin)
Enterprise	Oui	Oui (propriétaire et super admin)

Sur les plans Free et Professional, l’export JSON n’est pas disponible. Un audit manuel des Zaps depuis l’interface reste nécessaire pour documenter les automatisations à reconstruire.

---

Structure d’un Zap exporté (JSON)

Chaque Zap dans le fichier JSON exporté contient :

• Nom et description du Zap
• Statut : actif ou inactif
• Étapes (steps) : liste ordonnée des opérations du Zap
  • L’étape 0 est le trigger (déclencheur)
  • Les étapes suivantes sont les actions (avec leurs paramètres d’entrée)
  • Les étapes de type filter correspondent aux Filtres
  • Les étapes de type router correspondent aux Paths
  • Les étapes de type code correspondent aux Code Steps

Le JSON ne contient pas les credentials (tokens OAuth, API Token) des applications connectées. Ces authentifications doivent être recréées séparément sur le nouveau logiciel.

---

Triggers : polling vs webhook

Le type de trigger détermine la stratégie de reconstruction native.

Triggers en polling

Zapier interroge l’API de l’application source à intervalles réguliers pour détecter de nouveaux événements :

Plan	Fréquence
Free	Toutes les 15 minutes
Professional	Toutes les 2 minutes
Team	Toutes les 1 minute
Enterprise	Toutes les 1 minute

Un trigger en polling avec 15 minutes de délai est acceptable pour des tâches batch sans contrainte de temps. Pour les processus où la latence compte (notification client, alerte stock, validation de commande), ce délai est problématique.

Reconstruction native : le trigger polling est remplacé par un événement applicatif déclenché directement dans votre logiciel au moment où l’action se produit. La latence passe de quelques minutes à quelques millisecondes.

Triggers en webhook (Catch Hook)

Zapier crée une URL unique. Votre application (ou une autre source) envoie un POST vers cette URL quand l’événement se produit. Le Zap démarre immédiatement à la réception.

Reconstruction native : si le webhook provenait d’un logiciel sur mesure, ce point d’entrée est remplacé par un appel direct en interne. Si le webhook provenait d’un outil tiers, le nouveau logiciel expose un endpoint qui reçoit directement cet événement.

---

Actions : ce que les Zaps font

Chaque action dans un Zap appelle un endpoint API d’une application tierce pour créer, mettre à jour ou envoyer des données. Les types d’actions les plus courants à reconstruire :

Type d’action Zapier	Reconstruction native
Créer un enregistrement (CRM, tableur)	Insert SQL ou appel API depuis le logiciel
Mettre à jour un enregistrement	Update SQL ou appel API
Envoyer un email	Service email applicatif (Symfony Mailer)
Envoyer une notification Slack/Teams	Webhook sortant vers l’API Slack/Teams
Générer un document (PDF, Google Doc)	Génération de document native dans le logiciel
Appeler un webhook sortant	Appel HTTP depuis le logiciel

La reconstruction native présente deux avantages concrets : pas de délai de traitement Zapier (exécution synchrone) et pas de consommation de tâches (coût fixe, indépendant du volume).

---

Filtres et Paths : la logique conditionnelle

Filtres

Un Filtre arrête l’exécution d’un Zap si une condition n’est pas remplie (ex : “continuer seulement si le statut est égal à Gagné”). Simple à modéliser, mais combiné à plusieurs conditions, un filtre Zapier devient difficile à lire et à maintenir.

Paths

Les Paths permettent d’exécuter des actions différentes selon des conditions (ex : si le montant dépasse 10 000€, notifier le directeur commercial ; sinon, envoyer une confirmation standard). Limités à quelques niveaux d’imbrication dans Zapier.

Reconstruction native : filtres et Paths deviennent des conditions if/elseif/else dans le code de votre application. La lisibilité est meilleure, la logique est testée automatiquement à chaque déploiement.

---

Code Steps (Python et JavaScript)

Zapier permet d’insérer des étapes de code Python ou JavaScript dans un Zap pour des transformations de données que les actions standard ne couvrent pas.

Ce que les Code Steps signalent souvent :

• Une logique métier trop complexe pour le no-code
• Un besoin de calcul ou de transformation non couverts par les actions Zapier
• Un workaround face aux limites de la plateforme

Lors de l’audit Zapier : chaque Code Step est examiné individuellement. Le code est récupéré depuis le JSON exporté (ou depuis l’interface si le plan ne permet pas l’export), analysé et intégré directement dans la logique applicative du logiciel sur mesure, avec des tests couvrant les cas limites.

---

Historique des tâches : non migrable

Zapier conserve l’historique des exécutions (Task History) sur une durée de 90 jours (selon le plan). Cet historique n’est pas exportable.

Si vous avez besoin de conserver une traçabilité des automatisations déclenchées dans le passé (à des fins d’audit ou de conformité), il est nécessaire de prévoir un journal applicatif dès la conception du logiciel sur mesure. SmartBooster intègre systématiquement une table de logs dans les logiciels qui automatisent des processus critiques.

---

Zapier Tables : si vous stockez des données dans Zapier

Zapier Tables est une fonctionnalité qui permet de créer des bases de données légères directement dans Zapier. Si certains de vos Zaps lisent ou écrivent dans des Tables, ces données font partie du périmètre de migration.

Export des Tables : chaque Table peut être exportée en CSV depuis l’interface Zapier Tables. Les colonnes correspondent aux champs définis dans la table.

Reconstruction : les Tables sont recréées comme des entités SQL dans le logiciel sur mesure, avec les relations, les validations et les permissions appropriées.

---

Connexions d’applications : à recréer

Les authentifications vers chaque application (OAuth 2.0, API Token, Basic Auth) sont stockées dans Zapier et ne sont pas exportables. Elles doivent être recréées sur le nouveau logiciel.

Ce que cela implique concrètement :

• Pour chaque application connectée dans vos Zaps, un mécanisme d’authentification équivalent doit être configuré dans le nouveau logiciel
• Les tokens OAuth d’applications tierces (Google, Slack, Salesforce) sont régénérés via les procédures d’autorisation standard de chaque outil
• Les API Token (Stripe, Pipedrive, HubSpot) sont à récupérer dans les paramètres de chaque outil et à configurer dans le logiciel sur mesure

SmartBooster documente chaque connexion nécessaire lors de l’audit des Zaps existants et les configure dans l’environnement de recette avant la bascule.

---

Ce qui nécessite une décision avant la migration

Certains Zaps ne peuvent pas être reconstruits à l’identique et nécessitent une décision :

• Zaps qui connectent deux outils SaaS sans logiciel sur mesure impliqué : si le Zap synchronise Mailchimp et Notion sans passer par votre logiciel, il peut rester dans Zapier. La reconstruction native ne s’applique que quand votre logiciel est l’une des deux extrémités.
• Zaps avec des Code Steps complexes : le code est analysé, testé et intégré nativement. Si le Code Step interagit avec des APIs tierces que votre logiciel ne gère pas encore, la portée est à redéfinir.
• Zapier Interfaces : formulaires et mini-applications créés dans Zapier. Selon leur usage, ils sont reconstruits comme des écrans dans votre logiciel ou remplacés par un formulaire intégré à votre site.

Ce qui peut rester dans Zapier

Tous les Zaps n’ont pas vocation à être reconstruits en code natif. Les cas où Zapier reste pertinent après la migration :

• Connexions entre deux SaaS sans implication de votre logiciel sur mesure : synchroniser un formulaire externe avec un outil de newsletter, par exemple.
• Flux très simples et peu fréquents : quelques dizaines d’exécutions par mois avec une logique linéaire. Le ROI d’une reconstruction native est faible dans ce cas.
• Prototypage de nouveaux flux : Zapier reste utile pour valider rapidement la logique d’une automatisation avant de l’intégrer dans le logiciel.

SmartBooster identifie explicitement les Zaps à reconstruire et ceux à conserver lors de l’audit initial.

---

Ce qu’un prestataire sérieux doit faire

Si vous faites appel à un prestataire pour cette migration, voici les questions à poser pour évaluer sa rigueur :

• Inventaire exhaustif des Zaps actifs et inactifs : les Zaps inactifs peuvent contenir des automatisations abandonnées pour une mauvaise raison ou des workflows en cours de conception.
• Cartographie des dépendances : quelles applications chaque Zap connecte-t-il ? Lesquelles font partie du périmètre du logiciel sur mesure et lesquelles sont externes ?
• Traitement des Code Steps : chaque étape de code doit être analysée, testée et intégrée nativement, pas ignorée ou recodée à la va-vite.
• Stratégie de cohabitation : les Zaps restent actifs pendant le développement. Le plan de bascule doit indiquer Zap par Zap quand la désactivation est prévue.
• Tests automatisés des flux natifs : chaque automatisation reconstruite doit être couverte par des tests qui s’exécutent à chaque déploiement.

Chez SmartBooster, ces points font partie du cadrage initial de chaque projet de migration.

---

Références techniques

• Export et import de Zaps (documentation Zapier)
• Zapier Tables : présentation et export
• Historique des tâches Zapier (Task History)
• Plans Zapier et fréquences de polling