Make : déclencher un scénario avec un webhook — guide avancé
Par l'équipe Growth Loupe · 17 juin 2026 · 6 min
Rédigé avec l'assistance de l'IA · édité par Growth Loupe
En bref
Dans Make, un webhook custom est une URL unique générée par Make qui reçoit instantanément un payload JSON envoyé par un outil externe — formulaire, paiement, API maison — sans polling. Contrairement aux modules natifs Make qui interrogent une API toutes les 15 minutes, le webhook custom se déclenche en temps réel dès que l'événement se produit. La mise en place suit trois étapes : créer le webhook dans Make, coller l'URL dans l'outil source, déclencher un événement de test pour que Make reconnaisse la structure des données. Ensuite tu filtres les événements non pertinents entre modules, et tu chaînes avec n'importe quel module Make : Airtable, Notion, HTTP, Slack. C'est le socle de tout flow production-ready en automatisation no-code.
Webhook custom vs trigger natif Make : ce que ça change vraiment
Make propose des déclencheurs natifs pour des centaines d'outils : "Nouveau formulaire Typeform", "Nouveau paiement Stripe", etc. Dans la majorité des cas, c'est suffisant. Mais ces modules font du polling — ils interrogent l'API toutes les 15 minutes sur les plans standards. Ce n'est pas du temps réel.
Un webhook custom inverse la logique : c'est l'outil émetteur qui pousse l'information à Make dès que l'événement se produit. Zéro délai. Et ça ouvre des cas que les modules natifs ne couvrent pas : les outils sans module Make, les APIs maison, les formulaires non standard.
Trois situations concrètes où le webhook custom s'impose : l'outil n'existe pas dans le catalogue Make, tu as besoin d'un déclenchement instantané, ou tu veux contrôler exactement les données qui entrent dans ton scénario.
- →Module natif Make : simple à brancher, zéro config, mais polling toutes les 15 minutes et dépendance à Make pour maintenir l'intégration.
- →Webhook custom Make : instantané, fonctionne avec n'importe quel outil capable d'envoyer une requête HTTP POST, tu contrôles la structure des données.
- →Règle de décision : si le délai de 15 minutes pose problème ou si l'outil n'a pas de module Make, prends le webhook custom.
Configurer le webhook custom dans Make : les étapes exactes
Ouvre Make, crée un nouveau scénario. Comme premier module, cherche "Webhooks" et choisis "Custom webhook". Make génère une URL unique — c'est l'adresse à laquelle les événements vont arriver. Copie-la.
Tu dois maintenant envoyer un premier événement de test pour que Make reconnaisse la structure du payload. C'est l'étape que les débutants ratent. Sans ça, Make ne sait pas quels champs existent dans les données et tu ne peux pas les mapper dans les modules suivants.
Concrètement : colle l'URL dans Tally, Stripe, ton formulaire ou ton outil source, et déclenche un événement de test. Make va recevoir le payload et afficher "Successfully determined" avec la liste des champs détectés. À partir de là, tu accèdes à chaque valeur dans tes modules suivants.
- →Étape 1 : Nouveau scénario > premier module > Webhooks > Custom webhook > Create a webhook.
- →Étape 2 : Copier l'URL générée par Make.
- →Étape 3 : La coller dans l'outil source (Tally, Stripe, ton API) comme URL de destination.
- →Étape 4 : Déclencher un événement de test depuis l'outil source.
- →Étape 5 : Cliquer "Re-determine data structure" dans Make jusqu'à voir les champs apparaître.
- →Point critique : ne lance jamais le scénario en prod avant d'avoir déterminé la structure. Sinon les données arrivent mais Make ne sait pas les lire.
Parser le payload JSON et filtrer les événements inutiles
Le payload que tu reçois n'est pas toujours propre. Stripe, par exemple, envoie des dizaines de types d'événements sur le même webhook : paiements réussis, échoués, remboursements, disputes. Si tu ne filtres pas, ton scénario se déclenche pour tout — et agit au mauvais moment.
Dans Make, les filtres se placent entre deux modules. Clique sur la petite clé entre le webhook et le module suivant, ajoute une condition. Exemple pour ne traiter que les paiements Stripe réussis : condition sur le champ `type` égal à `payment_intent.succeeded`. Tout le reste passe à travers le filtre sans déclencher la suite du scénario.
Pour le parsing JSON : quand Make a déterminé la structure du payload, il expose automatiquement chaque champ dans les modules suivants. Tu cliques sur un champ de saisie, Make te propose les variables disponibles. Si le payload contient des objets imbriqués — un objet `customer` avec un champ `email` dedans — Make les expose en notation pointée : `customer.email`. Pas besoin de parser manuellement.
Un cas qui bloque souvent les gens : si tu reçois un tableau d'éléments (un panier avec plusieurs produits, par exemple), tu as besoin du module "Array iterator" pour boucler sur chaque élément. Les tutos débutants ignorent ce point et ça bloque dès le premier cas réel.
Trois cas d'usage concrets : du webhook au flow production-ready
Voici trois flows que tu peux construire aujourd'hui. Les deux premiers sont sans code. Le troisième nécessite de lire une documentation API, mais pas d'écrire une ligne.
- →Tally vers Notion : configure Tally pour envoyer les réponses à ton webhook Make. Dans Make, filtre sur le champ `formId` si tu as plusieurs formulaires sur le même endpoint. Ensuite, module Notion > Create a database item, mappe chaque champ Tally vers la propriété Notion correspondante. Résultat : chaque soumission crée une fiche Notion instantanément.
- →Stripe vers Slack : webhook Stripe configuré dans le dashboard Stripe (Developers > Webhooks > Add endpoint). Dans Make, filtre sur `type = payment_intent.succeeded`. Module Slack > Create a message, écris le texte avec les variables `amount`, `currency`, `customer.email`. Tu reçois une notification Slack à chaque vente, sans délai.
- →Site web vers CRM via HTTP : ton site custom envoie un POST à ton webhook Make quand un visiteur remplit un formulaire. Dans Make, tu reçois les champs, tu filtres pour enlever les soumissions de test (condition sur l'email : ne contient pas `@test`), puis tu utilises le module HTTP > Make a request pour appeler l'API de ton CRM et créer le contact. Ce flow fonctionne avec n'importe quel CRM qui dispose d'une API REST.
Ce qui fait tenir un flow en production — et ce qui le casse
Un scénario Make avec webhook custom qui tourne en prod, c'est un scénario qui gère les cas limites. Voici les erreurs les plus fréquentes chez les gens qui débutent.
La gestion des erreurs. Par défaut, si un module échoue, Make arrête l'exécution et la note en erreur sans te prévenir. Active les notifications d'erreur dans les paramètres du scénario. Encore mieux : ajoute un gestionnaire d'erreur sur les modules critiques — une route alternative qui t'envoie un message Slack si Airtable ou Notion renvoie une erreur.
Les doublons. Un webhook peut se déclencher deux fois si l'outil source retry après un timeout. Avant de créer un enregistrement dans Airtable ou Notion, vérifie d'abord si la fiche existe déjà (module Search records). Si elle existe, fais un update plutôt qu'un create. Cette logique upsert empêche les doublons même si le webhook arrive deux fois pour le même événement.
La documentation du payload. Note quelque part la structure exacte des données que tu reçois et ce que chaque champ signifie. Dans trois mois, quand tu modifies le scénario, tu ne te souviendras plus pourquoi tu avais filtré sur tel champ.
Si tu veux aller plus loin sur les automatisations Make, Zapier et la logique de flux en no-code, la formation Automatisation de Growth Loupe couvre ces patterns de A à Z, avec des cas réels.
FAQ
Comment créer un webhook dans Make ?
Dans Make, crée un nouveau scénario et ajoute le module Webhooks > Custom webhook comme premier module. Make génère une URL unique. Copie-la, colle-la dans l'outil source (Tally, Stripe, ton API), déclenche un événement de test, puis clique sur Re-determine data structure dans Make pour qu'il reconnaisse les champs du payload JSON. Sans cette étape de détermination de structure, tu ne peux pas mapper les données dans les modules suivants.
Quelle différence entre un webhook custom et un trigger natif dans Make ?
Un trigger natif Make (module Stripe, Typeform, etc.) interroge l'API de l'outil de façon périodique — toutes les 15 minutes sur les plans standards. Un webhook custom dans Make reçoit les données instantanément dès que l'événement se produit côté outil source. Pour du temps réel, le webhook custom est la seule option viable. Il fonctionne également avec des outils qui n'ont pas de module Make dédié, à condition qu'ils puissent envoyer une requête HTTP POST.
Comment filtrer les événements dans Make pour ne traiter que certains types de webhooks ?
Clique sur la petite clé entre le module webhook et le module suivant pour ajouter un filtre. Tu poses une condition sur un champ du payload — par exemple, pour Stripe, le champ `type` égal à `payment_intent.succeeded`. Tout événement qui ne correspond pas à la condition s'arrête là sans déclencher la suite du scénario. C'est indispensable quand un même endpoint reçoit plusieurs types d'événements.
Comment éviter les doublons quand un webhook Make se déclenche plusieurs fois pour le même événement ?
Avant de créer un enregistrement dans Airtable, Notion ou un autre outil, commence par chercher si une fiche existe déjà avec le même identifiant — module Search records. Si elle existe, fais un update. Si elle n'existe pas, crée-la. Cette logique upsert empêche les doublons même si le webhook arrive deux fois pour le même événement, ce qui arrive quand l'outil source retry après un timeout.