Un webhook est une notification HTTP envoyée automatiquement à une URL lorsqu’un événement se produit. Au lieu d’interroger régulièrement un service pour savoir si quelque chose a changé, vous déclarez une URL de réception, puis le service envoie les données au moment de l’événement.
Dans la logique des logiciels d’automatisation clés, le webhook est souvent le déclencheur : un formulaire est soumis, un paiement arrive, un code est poussé, puis un workflow démarre.
Comment fonctionne un webhook
Le service émetteur connaît une URL, une liste d’événements et parfois un secret d’authentification. Quand l’événement survient, il envoie une requête HTTP vers cette URL, généralement avec un corps JSON contenant les données utiles. Le serveur destinataire doit écouter cette URL, vérifier la provenance, lire le contenu, puis décider quoi faire.
GitHub décrit par exemple les webhooks comme un moyen de recevoir automatiquement des données sur un serveur externe lorsqu’un événement se produit, au lieu de faire du polling d’API à intervalles réguliers.
Exemple illustratif
Exemple pédagogique : un dépôt GitHub envoie un webhook après un push. Votre serveur reçoit une requête contenant le dépôt, la branche et le commit. Il peut alors déclencher une intégration continue, envoyer une notification ou enregistrer l’événement dans un journal. Cet exemple illustre le mécanisme ; il ne prouve pas qu’un serveur spécifique est configuré ici.
À ne pas confondre
- Webhook et API REST : une API attend souvent que le client l’appelle ; un webhook pousse l’information vers vous.
- Webhook et polling : le polling demande régulièrement s’il y a du nouveau ; le webhook notifie quand l’événement arrive.
- Webhook et tâche finie : recevoir un webhook ne veut pas dire que tout le traitement déclenché a réussi.
Limites et sécurité
Une URL de webhook peut être appelée par erreur ou par un acteur malveillant si elle est exposée. Il faut donc vérifier l’authentification, contrôler le format reçu, limiter les droits associés et prévoir les doublons. Certains services réessaient une livraison après erreur : sans identifiant d’événement, un même paiement ou une même notification peut être traité deux fois.
La confidentialité compte aussi. Un webhook peut transporter des emails, identifiants de commande ou informations internes. Ne journalisez pas tout en clair et ne partagez pas une URL de production dans une capture publique.
Usage associé
Le webhook devient concret quand il démarre un workflow dans un outil d’automatisation. Le guide pratique associé côté n8n consiste à créer une URL de test, envoyer un POST fictif, vérifier les champs reçus, ajouter une authentification, puis publier le workflow seulement après validation.
Quand l’utiliser dans un projet
Un webhook est pertinent lorsqu’une action doit partir dès qu’un événement arrive : inscription à un formulaire, validation d’un paiement, création d’un ticket, push de code ou alerte de supervision. Il devient moins pertinent si le service émetteur ne sait pas réessayer proprement, si vous ne pouvez pas vérifier la signature ou si le traitement doit être lancé manuellement après contrôle humain.
Avant de le brancher à un outil métier, écrivez la règle de traitement en une phrase : “quand tel événement arrive, créer telle action, avec tel identifiant unique”. Cette phrase évite de confondre réception technique et décision métier. Elle aide aussi à prévoir les cas d’échec : événement incomplet, appel répété, délai trop long ou service temporairement indisponible.
Pour aller plus loin
Passez à la configuration avec le guide du Webhook n8n, du POST de test à la production. Pour comprendre l’autre sens de communication, consultez la définition d’une API REST.
Retrouvez les autres notions dans le lexique IA et automatisation de Gridpak.
