Webhooks

Pourquoi utiliser un webhook plutôt qu'un trigger natif

Make.com propose deux modes de déclenchement : les triggers schedulés (le scénario va vérifier toutes les X minutes s'il y a du nouveau) et les triggers instantanés via webhook (le scénario se lance dès qu'il reçoit un appel). Le webhook gagne sur trois points :

• Latence quasi nulle : le scénario démarre en moins d'une seconde, contre 1 à 15 minutes pour un polling
• Économie d'opérations : un trigger qui scrute toutes les 5 minutes pour trouver une nouvelle ligne consomme inutilement votre quota Make
• Indépendance du module source : tout outil capable d'envoyer une requête HTTP peut déclencher Make, même sans intégration native

Le seul cas où on garde un trigger schedulé : quand l'outil source ne sait pas envoyer de webhook, ou quand on traite des lots de données accumulés.

Créer un webhook : la procédure complète

Dans le scenario builder Make.com, ajoutez un module Webhooks → Custom webhook. Cliquez sur "Add" pour créer un nouveau webhook, donnez-lui un nom explicite (ex : pipedrive-deal-won), puis copiez l'URL générée. Elle ressemble à :

https://hook.eu1.make.com/abc123def456ghi789

C'est cette URL que vous allez coller dans l'outil source (Pipedrive Webhooks, Typeform Connect, Stripe Webhooks, etc.). Au premier appel reçu, Make va analyser automatiquement la structure JSON entrante et générer un schéma. C'est ce qu'on appelle la phase de data structure determination.

Lire et utiliser le payload reçu

Une fois le webhook configuré, chaque module suivant dans le scénario peut piocher dans le payload reçu. Si Pipedrive envoie un objet de type {"event": "added.deal", "current": {...}, "previous": {...}}, vous pouvez mapper {{1.current.title}}, {{1.current.value}}, etc. dans n'importe quel module en aval.

Pour les payloads imbriqués ou les tableaux, l'opérateur map() et le module Iterator deviennent utiles. Voir le chapitre Itérateurs pour les patterns d'usage.

Webhooks avec réponse synchrone

Par défaut, Make accuse réception d'un webhook avec un 200 OK "Accepted" immédiat puis traite le scénario en arrière-plan. Si l'outil appelant attend une vraie réponse (ex : un formulaire qui veut afficher "Merci, votre demande #1234 est enregistrée"), il faut activer le Webhook Response.

Procédure : à la fin du scénario, ajoutez un module Webhooks → Webhook response, configurez le status code, les headers et le body, puis dans les paramètres avancés du webhook initial cochez "Get request headers" et changez le mode de réponse en Custom response. Le scénario doit alors s'exécuter en moins de 40 secondes (timeout HTTP de Make).

Sécuriser un webhook

L'URL d'un webhook Make est publique : si elle fuite, n'importe qui peut déclencher votre scénario et brûler vos opérations. Trois niveaux de sécurité, du plus simple au plus robuste :

• Token dans l'URL : ajouter un paramètre ?token=xyz et filtrer dès le premier module avec un Router (refuser si absent ou invalide). Suffit pour la plupart des cas internes
• Vérification de signature HMAC : Stripe, GitHub, Shopify signent leurs webhooks avec un secret partagé. Reconstruire la signature côté Make et comparer avant de traiter
• Restriction IP côté outil source : si l'outil le permet, limiter les IP autorisées à appeler le webhook

Cas d'usage concrets

Trois patterns que je déploie régulièrement chez mes clients :

• Pipedrive → Make → Slack/Email : notification interne dès qu'un deal change de stage, avec contexte enrichi (valeur, owner, source)
• Typeform/Tally → Make → Pipedrive : création automatique de lead avec mapping conditionnel selon les réponses (segmentation côté CRM)
• Stripe → Make → Pipedrive + ERP : sur paiement réussi, créer le deal "Won" et déclencher la facturation dans Dolibarr/Sellsy

Pour aller plus loin sur les intégrations CRM, voir le chapitre Intégrations CRM.