Webhooks Zapier : connectez vos outils et transférez vos données

Vous voulez qu'une demande reçue dans un outil apparaisse ailleurs sans que personne ne la ressaisisse. Entre deux applications, le webhook est l'un des moyens d'y parvenir, et Zapier peut jouer deux rôles : récepteur ou émetteur. Les ressources de cette page se fondent sur la documentation officielle de Zapier ; les écrans et les conditions d'accès évoluent, donc vérifiez-les sur votre compte.

À quoi sert un webhook dans Zapier ?

Une notification qui transporte des données

Selon la documentation officielle de démarrage, le plus simple est de voir un webhook comme une notification : un outil prévient un autre qu'il s'est passé quelque chose et joint les informations utiles (nom, e-mail, montant, etc.).

Trois termes suffisent :

• Zap : l'automatisation dans Zapier.
• Déclencheur : l'événement qui lance le Zap.
• Action : ce que le Zap fait ensuite.

Le webhook intervient dans l'un des deux sens :

• Vers Zapier : Outil source → URL fournie par Zapier → Zap → action dans l'outil final.
• Depuis Zapier : un événement quelconque → Zap → action webhook → URL du service destinataire.

Quand examiner l'intégration native en priorité

Les connexions natives évitent souvent de gérer soi-même l'URL et les formats. Le webhook devient intéressant lorsqu'une application n'a pas d'intégration Zapier : la documentation le décrit alors comme un contournement fréquent. Ce n'est ni toujours préférable à l'intégration native, ni une garantie de traitement immédiat. Il faut aussi que l'application sache émettre ou recevoir ce type de requête, ce qui peut demander l'aide de son éditeur ou d'une personne technique.

Préparer l'échange avant de configurer Zapier

Définir l'événement et le résultat attendu

Prenons un exemple illustratif : un outil de formulaire reçoit une demande de devis, et vous voulez qu'une fiche soit créée dans votre outil de suivi.

• Émetteur : l'outil de formulaire.
• Récepteur : Zapier, puis l'outil de suivi via une action.
• Résultat attendu : une fiche contenant le nom, l'e-mail et le besoin du prospect.

Formulez toujours le résultat attendu en termes métier. C'est lui que vous contrôlerez à la fin.

Réunir les paramètres nécessaires

Pour un envoi depuis Zapier, ces éléments se trouvent dans la documentation du service destinataire. Pour une réception, regardez si l'application émettrice propose un réglage « webhook » et quels événements elle sait signaler : cela dépend de l'outil, de ses droits d'accès et de son activation.

Recevoir un événement dans Zapier

Créer le déclencheur de réception

Dans un nouveau Zap, choisissez Webhooks by Zapier comme déclencheur, puis Catch Hook. D'après l'article officiel sur les webhooks, ce déclencheur accepte des requêtes GET, POST ou PUT. Zapier génère alors une URL de réception propre à ce Zap.

Renseigner l'URL dans l'application émettrice

Copiez cette URL, puis collez-la dans le champ « URL de webhook » des paramètres de l'application qui émet l'événement. Ne la collez pas dans l'outil final : c'est l'émetteur qui doit savoir où envoyer sa notification.

Traitez cette URL comme un mot de passe. La documentation de démarrage le demande explicitement. Si vous ne trouvez pas le réglage dans l'application émettrice, c'est un signal pour demander de l'aide à son éditeur ou à un prestataire technique, plutôt que pour insister.

Envoyer un exemple et associer les champs

Provoquez un événement dans l'application émettrice (soumettez par exemple un formulaire de test avec des données fictives), puis lancez le test du déclencheur dans Zapier. Si un exemple apparaît, la réception fonctionne.

Ajoutez ensuite l'action de votre choix et associez les champs reçus à ceux de l'outil final : l'e-mail reçu va dans le champ e-mail de la fiche, le nom dans le champ nom, et ainsi de suite. Ce n'est pas encore une preuve que la fiche sera créée correctement, d'où la section sur les tests plus bas.

Envoyer des données depuis un Zap

Partir d'un déclencheur et de la documentation du destinataire

Ici, Zapier est l'émetteur. Votre Zap démarre sur un événement (une nouvelle ligne, un nouveau paiement…), puis une action Webhooks by Zapier envoie les données vers l'URL du service. L'URL seule ne suffit pas : le guide officiel d'envoi suppose que vous connaissiez la méthode, le format et les conditions d'accès attendus par le destinataire.

Configurer l'action et les données transmises

Le guide propose GET, POST, PUT ou Custom Request, une requête personnalisée qui n'est pas une méthode au même titre que les trois autres. N'en retenez aucune par défaut : c'est la documentation du service destinataire qui tranche. Deux cas se présentent. Avec GET, POST ou PUT, vous renseignez les champs proposés par l'action. Avec Custom Request, vous construisez vous-même un corps brut, que Zapier ne met pas en forme automatiquement : suivez à la lettre l'exemple de la documentation du destinataire. Pour une action simple, renseignez :

1. l'URL du destinataire ;
2. les données, en indiquant à gauche le nom du champ attendu (la clé) et à droite sa valeur, prise dans les étapes précédentes du Zap ;
3. le format, via le menu « Payload Type » lorsqu'il est proposé dans l'action choisie, celui qu'attend le destinataire ;
4. si nécessaire, l'authentification et des en-têtes spécifiques.

Pour Custom Request, ces correspondances clé/valeur ne s'appliquent pas de la même façon : le contenu brut doit respecter exactement la structure documentée par le destinataire.

Identifier les configurations plus techniques

Certains cas relèvent plutôt d'un profil technique. Selon le même guide, Custom Request sert notamment aux méthodes PATCH ou DELETE, aux tableaux JSON imbriqués ou aux valeurs vides, et les données brutes ne sont pas formatées automatiquement. Les fichiers, eux, demandent POST ou PUT et non Custom Request.

Côté authentification, la comparaison officielle des méthodes d'appel oriente vers API by Zapier lorsque l'application n'a pas d'intégration Zapier et exige OAuth2 ou une clé API. Webhooks by Zapier couvre plutôt l'authentification Basic ou l'absence d'authentification. Si le service vous demande OAuth2, demandez conseil avant de continuer.

Tester le résultat avant la mise en service

Contrôler les données entrantes, sortantes et le résultat métier

Procédez dans cet ordre :

1. Déclencheur : lancez « Test trigger » et choisissez un enregistrement. Observation attendue : les champs que vous aviez listés sont présents.
2. Action : lancez « Test step ». Comparez ce qui entre (Data in) et ce qui sort (Data out).
3. Application finale : ouvrez la fiche créée ou modifiée. Elle doit contenir les bonnes valeurs dans les bonnes cases.

Un statut favorable dans Zapier indique que l'étape s'est exécutée, pas que le résultat métier est correct. C'est la fiche dans l'outil final qui fait foi. Si elle diffère de ce que vous attendez, notez l'écart précis (champ vide, valeur décalée) : c'est l'information la plus utile à transmettre à un technicien.

Publier, puis provoquer un nouvel événement

La publication exige un test réussi du déclencheur et des étapes Filter ou Paths présentes dans le Zap. Testez aussi l'action finale pour vérifier le résultat. Après publication, déclenchez un nouvel événement réel ou fictif, puis ouvrez le Zap History, qui conserve les données entrantes et sortantes de chaque étape. Notez que le Zap publié surveille les nouvelles données : il ne rattrape pas automatiquement le passé.

Que vérifier si le webhook ne fonctionne pas ?

Le dépannage officiel des webhooks permet de procéder par symptôme. Un symptôme n'est pas un diagnostic : commencez par l'étape la plus proche de la source.

Aucune donnée n'arrive

• Vérifiez l'événement : a-t-il bien été provoqué dans l'application émettrice, avec le réglage webhook activé ?
• Vérifiez l'URL : celle de l'émetteur est-elle identique à celle du Zap ? Un changement de propriétaire du Zap peut changer l'URL dans certaines configurations Team ou Enterprise, selon le dépannage officiel. Il faut alors recopier la nouvelle.
• Vérifiez le contenu : la requête ne peut pas être entièrement vide. Un contenu invalide peut être ignoré alors que Zapier répond « Success ».
• Relancez ensuite « Test trigger ». Le test n'affiche que les trois webhooks les plus récents reçus dans l'heure : si votre essai est plus ancien, renvoyez-en un.

Des champs manquent ou contiennent les mauvaises valeurs

Si l'émetteur a modifié sa structure de données, chargez un nouvel exemple dans le déclencheur, puis remplacez les champs obsolètes dans les actions suivantes, comme le recommande la documentation. Si le nouvel exemple ne contient toujours pas le champ, le problème vient probablement de ce que l'émetteur envoie : demandez à son éditeur quelles données sont transmises pour cet événement.

L'action finale ne se produit pas

Consultez l'historique du Zap et lisez le message d'erreur de l'étape concernée. Pour un envoi sortant, le guide de dépannage d'envoi mentionne qu'un récepteur de test comme RequestBin permet d'inspecter ce qui est réellement envoyé. N'y transmettez que des données fictives : ce type d'outil n'est pas fait pour des informations clients.

Pour obtenir de l'aide efficacement, rassemblez : le sens du flux, l'événement, l'étape en échec, le message d'erreur et un exemple de données sans information sensible.

Protéger les accès et vérifier les conditions d'utilisation

Traiter l'URL et les identifiants comme des informations sensibles

Au-delà de l'URL de réception, retenez que les identifiants saisis dans Webhooks by Zapier sont stockés dans des champs lisibles par toute personne ayant accès au Zap. Limitez donc les accès au Zap aux personnes qui en ont besoin. Une URL difficile à deviner ne remplace pas ces précautions. Ce texte ne constitue pas une procédure de conformité : pour des données personnelles ou financières, faites valider le flux par la personne en charge de ces sujets.

Vérifier la formule et les limites du flux choisi

La page tarifaire de Zapier inclut les webhooks dans l'offre Professional. Vérifiez les droits de votre compte ou de votre essai avant de configurer le flux, puis estimez sa consommation à partir des actions exécutées.

Côté taille, le dépannage officiel cite 10 Mo pour les déclencheurs et 5 Mo pour les actions. Selon le catalogue Zapier, Catch Raw Hook fait exception (corps non analysé, en-têtes inclus, 2 Mo maximum). Ces plafonds ne couvrent pas les limites propres aux applications tierces.

Un webhook utile est un échange que vous savez suivre

Utilisez l'intégration native lorsqu'elle couvre votre besoin ; choisissez un webhook pour relier un événement ou une opération qu'elle ne propose pas. Définissez les données, l'authentification et le résultat attendu, puis contrôlez le parcours jusqu'à l'application finale. Avant d'élargir l'usage, prévoyez aussi comment reconnaître un événement déjà traité et qui recevra les alertes d'erreur.