Dès qu’on s’intéresse à l’automatisation, le mot webhook apparaît partout : dans Make, n8n, Zapier, Stripe, GitHub, les outils de formulaires… C’est pourtant une idée très simple, et la comprendre ouvre la porte à la plupart des automatisations en temps réel.
À retenir Un webhook, c’est une application qui prévient une autre application dès qu’un événement se produit, en lui envoyant un message à une adresse web convenue à l’avance. Au lieu de demander « Du nouveau ? » toutes les minutes, on est averti immédiatement.
Le principe, avec une analogie
Imaginez que vous attendiez un colis.
- Sans webhook, vous allez vérifier votre boîte aux lettres toutes les heures. C’est ce qu’on appelle l’interrogation régulière (polling) : la plupart des vérifications ne servent à rien, et le colis peut attendre jusqu’à une heure avant que vous le voyiez.
- Avec un webhook, le livreur sonne à votre porte au moment où il arrive. Vous n’avez rien à surveiller, et vous êtes averti tout de suite.
Techniquement, « sonner à la porte » consiste à envoyer une requête HTTP, généralement de type POST, vers une URL que vous avez fournie. Cette requête contient les informations sur l’événement, le plus souvent au format JSON.
Webhook ou API : quelle différence ?
Les deux servent à faire communiquer des applications, mais dans des sens opposés.
| API classique | Webhook | |
|---|---|---|
| Qui prend l’initiative ? | Vous interrogez l’application | L’application vous prévient |
| Quand ? | Quand vous le décidez | Dès que l’événement se produit |
| Exemple | « Donne-moi la liste des commandes » | « Une nouvelle commande vient d’arriver » |
En pratique, on combine souvent les deux : le webhook annonce l’événement, puis on appelle l’API pour obtenir des détails supplémentaires ou pour agir.
À quoi ressemble un webhook
Un webhook réunit trois éléments :
- Un événement déclencheur : un paiement réussi, un formulaire envoyé, un nouveau client, un fichier ajouté…
- Une URL de destination, fournie par l’outil qui doit réagir. Dans n8n ou Make, le module « Webhook » génère cette adresse.
- Un contenu, le payload : les données de l’événement.
Voici à quoi peut ressembler le contenu envoyé quand un formulaire est rempli :
{
"event": "form.submitted",
"created_at": "2026-09-21T10:42:00Z",
"data": {
"name": "Camille Martin",
"email": "camille@example.com",
"message": "Bonjour, je souhaite un devis."
}
}Exemple illustratif : la structure exacte dépend de chaque service et figure dans sa documentation.
L’application qui reçoit le webhook lit ces données et déclenche la suite.
Des exemples d’automatisations
Quelques scénarios courants construits autour d’un webhook :
- Formulaire → tableur → notification : chaque réponse à un formulaire est ajoutée à Google Sheets, et vous recevez un message sur votre messagerie d’équipe.
- Paiement → facture → e-mail : quand un paiement réussit chez le prestataire de paiement, une facture est générée et envoyée au client.
- Code → mise en ligne : quand du code est envoyé sur GitHub, un service reconstruit et publie automatiquement le site.
- Message → IA → classement : un e-mail de support reçu est envoyé à une IA qui le résume et le classe, puis il est transmis à la bonne personne.
Dans des outils comme n8n ou Make, le webhook est souvent le premier module du scénario : c’est lui qui déclenche tout le reste.
Les règles de sécurité à respecter
Une URL de webhook est une porte d’entrée : toute personne qui la connaît peut y envoyer des données. Quelques précautions s’imposent.
- Utiliser HTTPS. Les données circulent alors chiffrées.
- Vérifier la signature. La plupart des services sérieux (Stripe, GitHub…) signent leurs webhooks avec une clé secrète partagée. Le récepteur recalcule la signature et rejette tout message dont la signature ne correspond pas. C’est la protection la plus importante.
- Garder l’URL confidentielle. Ne la publiez pas dans du code public ou sur un forum.
- Valider les données reçues. Ne faites jamais confiance aveuglément au contenu : vérifiez les champs attendus avant de les utiliser.
- Gérer les doublons. Un même webhook peut être envoyé plusieurs fois. Les services renvoient souvent le message en cas d’échec ou de réponse trop lente. Utilisez l’identifiant de l’événement pour ne pas traiter deux fois la même commande.
- Répondre vite. Le récepteur doit renvoyer rapidement un code de succès (
200) puis faire les traitements longs ensuite. Sinon, l’expéditeur peut considérer l’envoi comme échoué et recommencer.
Comment tester un webhook
Avant de brancher une automatisation réelle :
- Utilisez le mode test de votre outil. n8n et Make proposent d’« écouter » le webhook : vous déclenchez l’événement une fois, et l’outil affiche les données reçues. Vous pouvez alors construire la suite du scénario avec de vraies données.
- Consultez l’historique des envois. Beaucoup de services (GitHub, Stripe…) affichent les webhooks envoyés, leur contenu et la réponse obtenue. C’est précieux pour comprendre une erreur.
- Testez avec des données fictives, jamais avec de vraies données clients, surtout si vous passez par un service de test en ligne.
En résumé
Un webhook est une notification automatique : une application en prévient une autre dès qu’un événement se produit, en envoyant les données à une URL. C’est la brique de base des automatisations en temps réel. Retenez surtout les deux réflexes de sécurité : HTTPS et vérification de signature.
Pour choisir l’outil qui recevra vos webhooks, consultez notre comparatif Make ou n8n.