C’est quoi un webhook ? Explication avec des exemples concrets
Un webhook est une notification automatique qu’un service envoie à une URL de votre choix dès qu’un événement précis se produit, sans que vous ayez besoin de l’interroger en permanence. Contrairement à un appel d’API classique déclenché par vous, c’est le service distant qui vous contacte, en quasi temps réel, avec les données de l’événement.
Un webhook, c’est un service qui vous appelle automatiquement dès qu’un événement se produit, au lieu que ce soit vous qui l’appeliez pour savoir si quelque chose a changé.
C’est quoi un webhook exactement ?
Un webhook repose sur une idée simple : plutôt que d’interroger un service à intervalles réguliers pour savoir si quelque chose a changé, on lui indique une adresse où il doit envoyer lui-même la nouvelle. On parle parfois d’« API inversée », même si le mécanisme technique reste une requête HTTP classique.
Concrètement, un webhook se compose de trois éléments qui doivent être définis avant toute connexion.
Le déclencheur surveillé par le service émetteur : un paiement, un push de code, une réponse à un formulaire.
L’adresse de votre serveur ou de votre outil d’automatisation qui va recevoir la notification.
Les données envoyées avec la notification, presque toujours au format JSON.
La documentation officielle du nœud Webhook de n8n définit ce dernier comme un point d’entrée qui écoute des requêtes HTTP entrantes et démarre un workflow dès leur réception. C’est l’un des déclencheurs les plus utilisés pour connecter des outils qui n’ont pas de connecteur natif entre eux.
Comment fonctionne un webhook, étape par étape ?
Le mécanisme reste le même quel que soit le service émetteur. Voici le déroulé habituel entre le moment où l’événement survient et celui où votre outil réagit.
- Vous créez une URL de réceptionDans n8n, Make ou votre propre serveur, une adresse est générée pour accueillir les notifications.
- Vous renseignez cette URL chez le service émetteurDans les paramètres webhook de Stripe, GitHub ou de votre formulaire en ligne.
- L’événement surveillé se produitUn paiement est validé, un commit est poussé, un visiteur envoie un formulaire.
- Le service émetteur envoie une requête POSTAvec les données de l’événement et, idéalement, une signature de vérification.
- Votre outil traite la donnée et déclenche une actionMise à jour du CRM, envoi d’un e-mail, création d’une facture, notification interne.
Le service émetteur attend en général une réponse rapide (souvent un code HTTP 200 en quelques secondes) pour considérer la notification comme livrée. La documentation des webhooks Stripe recommande d’ailleurs de répondre immédiatement, puis de traiter la donnée en arrière-plan si le traitement est long.
Webhook ou appel API classique : quelle différence ?
Les deux mécanismes utilisent le même protocole HTTP, mais l’initiative ne vient pas du même côté. Ce détail change tout pour la charge serveur et la rapidité de réaction.
| Critère | Appel API classique (polling) | Webhook |
|---|---|---|
| Qui initie l’échange | Vous interrogez le service régulièrement. | Le service vous notifie de lui-même. |
| Fréquence des requêtes | Toutes les X minutes, même sans changement. | Uniquement quand un événement survient. |
| Charge inutile | Nombreuses requêtes vides. | Aucune requête si rien ne se passe. |
| Délai de réaction | Dépend de la fréquence d’interrogation choisie. | Quasi immédiat. |
| Exemple type | Vérifier toutes les 5 minutes si un paiement est arrivé. | Être averti à l’instant même du paiement. |
En pratique, les deux approches cohabitent souvent : le webhook déclenche l’action en temps réel, et un appel API classique permet de vérifier ou compléter une donnée au moment du traitement.
Quels sont des exemples concrets de webhooks ?
Les webhooks sont partout dès qu’un outil doit réagir à un événement produit par un autre. Voici quatre usages courants pour une TPE/PME.
Un paiement Stripe validé
Stripe envoie un webhook checkout.session.completed qui déclenche la création d’une facture et l’envoi d’un e-mail de confirmation.
Un push de code sur GitHub
Un webhook GitHub notifie un serveur de déploiement dès qu’une branche reçoit de nouveaux commits.
Une réponse à un formulaire
Un formulaire de contact ou de qualification envoie chaque nouvelle réponse à un workflow qui met à jour le CRM.
Un nouvel article WordPress
La publication d’un article déclenche un webhook qui prépare automatiquement un brouillon de post pour les réseaux sociaux.
Pour comprendre comment ces notifications s’intègrent ensuite dans une chaîne d’étapes plus large, notre article sur ce qu’est un workflow détaille l’enchaînement qui suit la réception d’un webhook.
Comment utilisons-nous les webhooks chez Amari Agency ?
Voici un exemple représentatif de notre méthode, sans donnée client ni chiffre inventé.
Un webhook comme point d’entrée, jamais comme automatisme aveugle
Nous recevons des webhooks (formulaires, WordPress, outils de paiement) directement dans n8n, qui vérifie la charge utile avant toute action. Les données utiles sont stockées dans Supabase, les envois passent par Resend, et un agent Hermes peut intervenir sur les cas qui demandent davantage d’analyse. Toute action sensible reste soumise à une validation avant exécution.
Cette organisation évite qu’une notification mal formée ou inattendue déclenche une action irréversible. Le webhook déclenche, le workflow contrôle.
Comment sécuriser un webhook ?
Une URL de webhook est publique par nature : quiconque la connaît peut, en théorie, lui envoyer une requête. Plusieurs précautions limitent ce risque.
- Vérifier la signature envoyée par le service émetteur avant de traiter la donnée.
- Utiliser une URL longue et imprévisible plutôt qu’un chemin devinable.
- Limiter les actions déclenchées automatiquement aux opérations réversibles ou peu sensibles.
- Journaliser chaque réception pour pouvoir rejouer ou auditer un événement.
Sans contrôle de signature, rien ne prouve qu’une requête reçue provient réellement du service attendu et non d’un tiers qui aurait deviné l’URL.
La plupart des fournisseurs sérieux, dont Stripe et GitHub, fournissent un secret partagé permettant de vérifier cette signature avant tout traitement.
Comment créer et tester son premier webhook ?
Un premier test se met en place rapidement, sans toucher à un système en production.
Si vous préférez déléguer la mise en place de vos connexions entre outils, découvrez nos solutions d’automatisation IA sur mesure. Pour apprendre à construire ces workflows vous-même, notre formation IA générative certifiante couvre les déclencheurs et les agents, avec des financements possibles selon votre statut.
Quels contenus lire ensuite ?
Ces ressources complètent la définition sans cibler la même requête :
Questions fréquentes sur les webhooks
Un webhook peut-il être envoyé plusieurs fois pour le même événement ?
Oui, la plupart des services renvoient une notification si aucune réponse rapide n’a été reçue. Votre outil doit donc pouvoir ignorer un événement déjà traité, en s’appuyant par exemple sur son identifiant unique.
Faut-il savoir coder pour recevoir un webhook ?
Pas nécessairement. Des outils comme n8n ou Make génèrent une URL de réception prête à l’emploi et permettent de traiter la donnée reçue sans écrire de serveur dédié.
Que se passe-t-il si mon serveur est hors ligne au moment de l’envoi ?
La plupart des services retentent l’envoi plusieurs fois selon un calendrier défini, puis abandonnent après un certain nombre d’échecs. Il faut consulter la documentation de chaque émetteur pour connaître sa politique de nouvelle tentative.
Un webhook peut-il transmettre des données personnelles ?
Oui, une charge utile peut contenir des données personnelles selon l’événement (nom, e-mail, montant). Il faut alors appliquer les mêmes règles RGPD que pour tout autre traitement : minimisation, sécurisation et durée de conservation définie.
Quelle est la différence entre un webhook et un webhook.site ?
Un webhook est le mécanisme de notification lui-même. webhook.site est un outil tiers gratuit qui génère une URL temporaire pour inspecter le contenu d’un webhook avant de le connecter à un vrai système.