Webhook pour Zapier et Make

Pourquoi un webhook plutôt qu’une application prête à l’emploi dans Zapier

Jusqu’en avril 2024, il existait une voie officielle : Facebook Groups API, sur laquelle reposaient le déclencheur « New Post in Group » de Zapier et le module correspondant dans Make. Meta l’a désactivée sans rien mettre à la place. L’application Facebook dans Zapier existe toujours, mais elle gère les pages et les publicités — les groupes ont disparu de la liste des déclencheurs et ne reviendront pas, car il n’existe plus d’interface sur laquelle ils pourraient reposer.

LeadScanner lit les groupes publics et les pages Facebook sans compte, comme les voit un passant non connecté, et peut envoyer un événement à l’adresse indiquée après chaque analyse. Du point de vue de Zapier et Make, il s’agit d’un webhook entrant classique — autrement dit, exactement du déclencheur qui manque. Ensuite, vous disposez de tout ce que ces outils font bien : ligne dans une feuille de calcul, fiche dans le CRM, message sur Slack, tâche pour un commercial.

Le canal webhook est disponible avec la formule Growth et les formules supérieures. Il est configuré par le propriétaire ou l’administrateur de l’organisation, dans le panneau, sous Notifications → Canaux.

Configuration dans Zapier

Dans Zapier, créez un nouveau Zap et choisissez comme déclencheur l’application « Webhooks by Zapier », puis l’événement « Catch Hook ». Zapier affichera l’adresse sur laquelle il écoute — copiez-la. Ne fermez pas cet onglet, vous y reviendrez dans un instant.

Dans le panneau LeadScanner, ouvrez Notifications → Canaux et ajoutez un canal Webhook. Collez l’adresse copiée. Si vous souhaitez pouvoir distinguer vos événements des autres de l’autre côté, ajoutez un en-tête d’authentification : un nom (par exemple X-Api-Key) et une valeur que vous définissez vous-même. C’est facultatif, mais peu coûteux, et il vaut mieux le faire immédiatement.

Cochez les événements à envoyer : « Nouveaux leads », « Analyse terminée » ou les deux. Pour l’automatisation commerciale, le premier suffit généralement ; le second est utile si vous voulez journaliser chaque analyse, même vide. Enregistrez le canal et cliquez sur « Envoyer un test ».

Revenez dans Zapier et cliquez sur « Test trigger ». Zapier recevra l’événement de test et le répartira en champs que vous pourrez désormais mapper lors des étapes suivantes : person_name vers la colonne du nom, post_url vers le lien, score vers la priorité. L’événement de test contient le champ test défini sur true et des données d’exemple — n’ajoutez pas cette personne au CRM, car elle n’existe pas.

Configuration dans Make

Dans Make, ajoutez au scénario le module « Webhooks » → « Custom webhook », donnez-lui un nom et copiez l’adresse générée. Make écoute désormais et attend le premier message pour en lire la structure de données.

Les étapes dans le panneau LeadScanner sont les mêmes que pour Zapier : Notifications → Canaux → Webhook, collez l’adresse, ajoutez éventuellement un en-tête d’authentification, choisissez les événements, enregistrez et cliquez sur « Envoyer un test ».

Après le test, Make indiquera qu’il a reconnu la structure. Si ce n’est pas le cas — par exemple parce que le webhook écoutait déjà auparavant et a mémorisé une autre structure — cliquez dans le module sur « Redetermine data structure » et envoyez à nouveau le test. Les champs de la charge utile sont alors disponibles dans chaque module suivant du scénario.

Une remarque pratique pour les deux outils : l’événement « Nouveaux leads » contient une liste, pas un lead unique. Dans Make, divisez-la avec un itérateur ; dans Zapier, utilisez l’étape « Looping by Zapier ».

Événement new_leads : ce qui est envoyé

Chaque événement est une requête POST avec un corps au format JSON. Il contient toujours le même ensemble de champs : event — nom de l’événement, ici new_leads ; version — numéro de version du format, actuellement 1 ; organization_id — identifiant de votre organisation ; sent_at — heure d’envoi au format ISO 8601 ; subject — titre d’une phrase, identique à celui de l’objet de l’e-mail ; leads_count — nombre de leads dans le lot ; leads — liste des leads.

Chaque élément de la liste leads contient : person_name — prénom et nom de l’auteur de la publication, tels qu’ils apparaissent sur Facebook ; score — note de 0 à 100, plus elle est élevée, plus la demande est certaine ; excerpt — extrait du post ou du commentaire dans lequel la question a été posée ; post_url — lien vers la publication ; profile_url — lien vers le profil de l’auteur, s’il était visible, sinon null ; rationale — une phrase expliquant pourquoi cette publication a été considérée comme un lead ; source_name — nom du groupe ou de la page où elle a été publiée.

L’envoi de test a exactement cette structure, avec des données d’exemple et un champ supplémentaire test défini sur true. C’est le moyen le plus simple de voir un exemple complet : cliquez sur « Envoyer un test » et consultez dans Zapier ou Make ce qui a été reçu.

Événement scan_finished : la même chose, avec l’analyse en plus

L’événement scan_finished contient tous les champs décrits ci-dessus — avec la liste des leads trouvés dans cette analyse, qui peut être vide — ainsi que l’objet scan. Il contient : id — l’identifiant de l’analyse ; source_id, source_name et source_url — quelle source a été vérifiée ; status — comment elle s’est terminée ; mode — le mode, les mots-clés ou l’IA ; scheduled_slot — le créneau de planification auquel l’analyse appartenait ; started_at et finished_at — l’heure de début et de fin ; points_spent — combien de points elle a coûté ; leads_found — combien de leads elle a trouvés ; error et error_code — la description et le code de l’erreur lorsque l’analyse a échoué, sinon null.

Il y a aussi coverage, le bilan de ce que l’analyse a consulté : posts_seen et comments_seen — combien de publications et de commentaires elle a lus ; posts_suppressed — combien de publications elle a ignorées, car leurs auteurs ont demandé la suppression de leurs données ; posts_stale et comments_stale — combien étaient plus anciens que la fenêtre de fraîcheur ; posts_unchanged et comments_unchanged — combien elle connaissait déjà d’un passage précédent et n’a pas réévalués ; graded — combien d’extraits ont été évalués ; leads — combien sont devenus des leads ; rejected — la liste des paires reason et count, soit les motifs de rejet et leur nombre.

Les nombres dans coverage s’additionnent toujours : graded correspond aux publications et commentaires récents, après déduction des anciens et de ceux déjà connus, et leads plus la somme de rejected donne graded. Si vous construisez un tableau de bord sur cette base, vous pouvez vous fier à ces deux identités.

Les motifs dans rejected proviennent toujours de la même liste : no_keyword (aucun mot-clé n’a été mentionné), no_intent (il est impossible de déterminer si l’auteur cherche quelque chose), not_in_market (il parle le langage du secteur, mais n’achète pas — il conseille, raconte ou vend), outside_offer (il achète, mais pas ce que vous proposez ou pas là où vous intervenez), excluded (il demande précisément ce que vous ne faites pas), below_threshold (cela correspond, mais trop peu pour atteindre le seuil), ungraded (le modèle a répondu dans un format illisible). Conservez-les comme dictionnaire, ne les mappez pas à vue d’œil.

Signature HMAC et son alternative

Si vous définissez un secret dans le canal, chaque requête recevra deux en-têtes : X-LeadScanner-Timestamp avec l’heure de signature en secondes Unix et X-LeadScanner-Signature avec la valeur v1=<hex>, où hex est le HMAC-SHA256 de la chaîne « <timestamp>.<ciało> », calculé avec votre secret. Le destinataire calcule la même chose de son côté et compare ; il rejette les signatures datant de plus de cinq minutes. Ainsi, personne connaissant seulement l’adresse ne peut se faire passer pour LeadScanner ni rejouer une requête interceptée une semaine plus tard.

Sans secret, il n’y a pas d’en-têtes de signature — l’événement est envoyé sans signature, comme pour la plupart des intégrations no-code. Zapier et Make ne calculent pas de HMAC sans étape supplémentaire avec du code ; pour eux, une protection plus simple et suffisante est donc l’en-tête d’authentification du panneau : côté automatisation, ajoutez un filtre qui n’autorise que les requêtes avec ce nom et cette valeur.

Deux règles impossibles à désactiver : l’adresse doit être une URL HTTPS publique — le simple http et une adresse de réseau local ne sont pas acceptés — et les redirections sont rejetées. Si votre serveur répond 301 ou 302, la livraison échoue au lieu de basculer discrètement vers une autre adresse, car la signature et l’en-tête d’authentification arriveraient alors ailleurs que prévu.

En cas d’échec de livraison

Une réponse autre que 2xx, un délai d’attente dépassé ou une connexion interrompue indiquent une tentative échouée. Nous ne nous arrêtons pas là : l’événement est renvoyé trois fois, à intervalles croissants — la première relance après une demi-minute, la dernière après quelques minutes. Cela suffit pour attendre le redémarrage d’un serveur ou une limite temporaire côté Zapier, tout en garantissant que la notification qui finit par arriver reste une notification, pas une chronique.

Chaque tentative — réussie ou non — est visible dans le panneau, sous le canal, avec l’heure, le code de réponse et le motif de l’erreur. Après quatre tentatives sans succès, l’événement reste dans cette liste comme échoué : c’est généralement une adresse Zapier qui n’existe plus ou un scénario Make désactivé.