Créer son premier Zap : automatiser une tâche avec Zapier

Vous recopiez chaque semaine les mêmes informations d'un outil à l'autre : une demande reçue par formulaire, puis saisie dans un tableur, par exemple. Zapier sert à confier ce type de transfert à un enchaînement automatique. Reste à choisir une tâche qui s'y prête, à la configurer sans surprise et à contrôler ce qu'elle produit réellement. Cet article suit un exemple volontairement simple, que vous pourrez transposer à vos propres applications.

Comprendre le fonctionnement d'un Zap

Une automatisation Zapier s'appelle un Zap. Selon le guide de démarrage officiel, il se compose d'un déclencheur, l'événement qui lance le Zap, et d'une ou plusieurs actions. Les données reçues au départ peuvent alimenter les actions qui suivent.

Pour décrire votre besoin, utilisez la formule : lorsque cet événement survient, alors effectuer cette action. Exemple : lorsqu'une personne soumet le formulaire de contact, ajouter une ligne dans le tableur de suivi des demandes.

Deux notions à ne pas confondre :

• le déclencheur est l'événement de départ (une soumission reçue) ;
• l'action est le résultat attendu (une ligne créée).

Les données circulent de l'un à l'autre : le nom saisi dans le formulaire peut devenir le contenu de la colonne « Nom ».

Choisir et préparer une première tâche

Partir d'un transfert répétitif et facile à contrôler

Zapier indique dans son guide de prise en main que les meilleurs candidats à l'automatisation sont généralement des processus déterministes, où l'on déplace régulièrement une information d'une application à une autre. Un transfert formulaire vers tableur en est un bon exemple pédagogique : les règles sont explicites et le résultat se vérifie d'un coup d'œil.

Le critère « facile à contrôler » est un conseil éditorial, pas une exigence du produit. Il vous protège : si vous pouvez comparer en dix secondes ce qui est entré et ce qui est sorti, vous repérez vite une erreur. À l'inverse, une décision qui demande du jugement (qualifier un prospect, arbitrer une réclamation) ne se traite pas comme une copie de données. Gardez-y une validation humaine.

Décrire le résultat avant de configurer

Vérifier que le scénario est réalisable

Contrôler les événements et les actions disponibles

C'est l'étape que l'on saute le plus souvent. Voir le nom de votre application dans le catalogue ne prouve pas que l'opération voulue existe. D'après le guide de prise en main, les événements de déclenchement et d'action varient selon les applications.

Comment vérifier : listez l'événement exact dont vous avez besoin côté source (« nouvelle soumission ») et l'opération côté destination (« ajouter une ligne »). Cherchez-les dans la configuration de chaque application. Si l'un des deux manque, ne contournez pas à tout prix : simplifiez le scénario ou gardez l'étape manuelle. Ce constat est une information de faisabilité, pas un échec de votre part.

Vérifier les accès et les conditions de compte

Pour relier une application, il faut disposer des permissions adéquates. Si vous n'êtes pas administrateur de l'outil, demandez en amont à la personne qui l'est, plutôt que de partager des identifiants.

Vérifiez les droits et quotas de votre compte Zapier et des applications connectées. Un Zap comportant plusieurs actions nécessite un essai ou un forfait payant ; pour un scénario à une seule action, contrôlez aussi l'accès à chaque application.

Enfin, ne transmettez que les champs utiles au besoin défini. Cette précaution réduit l'exposition des données, mais elle ne prouve pas la conformité de votre traitement. Si le flux manipule des données personnelles de clients ou de salariés, faites valider le cadre par votre délégué à la protection des données ou un conseil juridique.

Décision : si les événements, les accès et le forfait sont réunis, continuez. Sinon, simplifiez le scénario ou conservez l'étape manuelle.

Configurer le déclencheur et associer les champs

L'ordre ci-dessous suit la logique décrite dans l'aide pour configurer le déclencheur et l'action. Les libellés exacts de l'interface peuvent évoluer : suivez ce qui s'affiche à l'écran.

Sélectionner la source et récupérer un échantillon

1. Choisissez l'application source, puis l'événement déclencheur.
2. Sélectionnez le compte à utiliser. Si un compte est déjà connecté, vérifiez que c'est le bon. Sinon, lancez la connexion d'un nouveau compte, connectez-vous avec le compte autorisé, examinez les accès demandés avant de les accepter, puis confirmez que le compte affiché est bien celui voulu. Si les autorisations manquent, sollicitez l'administrateur de l'outil.
3. Renseignez les paramètres demandés.
4. Récupérez un échantillon de données.

Attention : certaines applications ne renvoient qu'un échantillon générique pendant le test, et non les données réelles de votre compte. Si les valeurs affichées ne ressemblent pas à votre soumission fictive, ce n'est pas forcément un défaut : vérifiez que les champs ont le bon nom et la bonne signification. L'association reste possible, mais le contrôle des valeurs devra se faire sur une nouvelle soumission fictive après publication.

Définir l'action dans le tableur

Choisissez l'application destinataire et l'opération disponible (ajouter une ligne, par exemple). Pour le compte, procédez comme pour la source : réutilisez un compte déjà connecté ou reliez-en un nouveau, après avoir examiné les accès demandés. Sélectionnez ensuite le tableur et la feuille concernés. Un modèle prêt à l'emploi peut accélérer cette étape, mais vous devrez toujours connecter vos comptes et confirmer chaque étape.

Relier chaque donnée à la bonne colonne

La documentation indique que l'on peut saisir des valeurs manuellement ou reprendre des champs d'une étape précédente. Voici un exemple illustratif de correspondance :

Donnée du formulaire	Colonne du tableur	Type de valeur	Remarque
Nom	Nom	Variable (reprise du formulaire)	Champ obligatoire côté formulaire
Adresse électronique	E-mail	Variable	Vérifier le format affiché
Message	Demande	Variable	Peut être long : contrôler l'affichage
(aucune)	Source	Texte fixe : « Formulaire du site »	Identique à chaque exécution

Lecture : trois colonnes changent à chaque soumission, la dernière est constante. La colonne « Source » en texte fixe sert à repérer plus tard l'origine des lignes, sans dépendre du formulaire.

Relisez toutes les associations avant de tester : l'état de réussite du test ne suffit pas à confirmer que chaque valeur arrive dans la bonne colonne. Comparez ensuite le contenu obtenu au résultat attendu.

Tester le résultat avant de publier

Selon l'aide officielle sur le test des étapes, le test est réel et peut modifier votre application. Prévoyez donc des données fictives et un destinataire que vous maîtrisez : un tableur d'essai plutôt que le fichier de suivi réel, si possible.

Contrôler un cas représentatif

Envoyez votre soumission fictive, puis, si l'intégration le permet, récupérez ou sélectionnez cette nouvelle soumission comme échantillon. Vérifiez quelles données alimentent le test d'action avant de le lancer, puis ouvrez le tableur. Comparez avec le résultat attendu que vous aviez noté :

• la ligne est-elle créée au bon endroit ?
• chaque valeur est-elle dans la bonne colonne ?
• le texte est-il complet, sans caractère étrange ?

Si tout correspond, le cas simple est validé. Si une valeur est mal placée, c'est un indice d'association à revoir, pas la preuve d'un dysfonctionnement de Zapier : corrigez, puis retestez.

Examiner les cas qui peuvent poser problème

Un test réussi ne dit rien des situations particulières. Essayez au moins deux cas :

• un champ facultatif laissé vide : la ligne est-elle créée sans décalage ? Si oui, acceptez le résultat ;
• une donnée indispensable manquante : corrigez la collecte ou l'association avant de publier ;
• une même soumission traitée deux fois : comparez les soumissions reçues aux lignes produites.

Si deux lignes apparaissent pour le même événement, comparez la source et l'historique du Zap pour trouver l'origine du doublon. La réponse dépend de votre usage : Un doublon dans un suivi interne se corrige à la main ; dans un envoi automatique de courriel à un client, il coûte davantage et justifie de garder une validation humaine.

Publier puis vérifier une nouvelle soumission

Quand le résultat vous convient, publiez le Zap. Test et mise en service sont deux étapes distinctes. Après publication, le Zap ne surveille que les nouvelles données : l'historique existant n'est pas importé automatiquement. Envoyez donc une nouvelle soumission fictive et vérifiez qu'elle arrive.

Suivre les premières exécutions et prévoir les incidents

Après la mise en service, consultez l'historique des exécutions (Zap History) puis ouvrez l'application destinataire pour vérifier chaque élément créé ou modifié. L'historique indique si le flux s'est exécuté ; seul le tableur confirme que le contenu est correct.

Cette désactivation est documentée : elle peut suivre des erreurs répétées ou une expiration d'essai ou une baisse de forfait. Un courriel peut être envoyé dans certains cas, mais surveillez aussi l'historique pour repérer les erreurs. Ne comptez donc pas sur elle seule.

En cas d'échec constaté :

1. regardez dans l'application destinataire ce qui a déjà été créé, avant toute reprise, pour ne pas dupliquer ;
2. vérifiez les comptes connectés et le forfait ;
3. si la cause reste obscure ou si le flux touche des données sensibles ou la facturation, sollicitez la personne qui administre vos outils ou un prestataire compétent.

Décider de conserver, simplifier ou arrêter le flux

Un flux utile se juge sur quatre éléments : le travail manuel évité, le coût des outils, la consommation et le temps de suivi. Cette comparaison est une méthode de bon sens, pas une démonstration de rentabilité.

Côté consommation, chaque action réussie compte pour une tâche ; les déclencheurs et certaines actions des applications intégrées Zapier ne sont pas comptés. Une exécution ne vaut donc pas toujours une tâche. Intégrez les tests et les reprises à votre suivi de consommation et consultez les règles de votre forfait.

Exemple chiffré, purement illustratif : supposons 40 exécutions dans le mois, chacune comprenant une action réussie et non exemptée. Cela représente alors 40 tâches comptées selon la règle ci-dessus. Avec la même hypothèse et deux actions réussies et non exemptées par exécution, on arriverait à 80. Les échecs, les actions exemptées, les tests et les reprises modifieraient ce décompte. Comparez ce volume estimé aux conditions affichées pour votre forfait réel.

Trois décisions sont possibles :

• conserver le flux s'il fonctionne, s'il est contrôlé et si le suivi reste léger ;
• simplifier s'il demande des corrections fréquentes : moins de champs, moins d'étapes ;
• maintenir une intervention humaine si une erreur coûterait cher ou si le cas exige du jugement.

Votre premier Zap doit vous enlever du travail

Commencez par un transfert fréquent, simple à vérifier et sans conséquence sensible. Connectez les comptes, associez les champs et testez le résultat dans l'application de destination. Après quelques exécutions réelles, conservez le flux s'il vous fait gagner du temps avec peu de suivi ; sinon, simplifiez-le avant d'ajouter des étapes.