Webhook : définition, fonctionnement et exemples

Un webhook est un message automatique qu'une application envoie à une autre, via une URL, dès qu'un événement précis se produit chez elle. C'est une notification technique qui transporte des données, sans que le destinataire ait eu à demander quoi que ce soit.

Cet article explique ce qu'est un webhook, comment il fonctionne, en quoi il diffère d'une API, du polling et d'un callback, comment le configurer, le tester et le sécuriser — et surtout comment en créer un dans Make, n8n, Zapier ou Discord sans écrire de code.

Qu'est-ce qu'un webhook ?

La définition simple

Un webhook est une requête HTTP envoyée automatiquement par une application vers une URL que vous lui avez indiquée, au moment où un événement se produit. Un client paie sur votre site : Stripe envoie immédiatement un message à l'URL configurée, et votre outil d'automatisation réagit.

Toute la différence tient à un mot : automatiquement. Vous ne demandez rien, vous êtes prévenu.

Les composants d'un webhook

• L'événement (ou trigger) : ce qui déclenche l'envoi. Un paiement encaissé, un formulaire soumis, un contact créé, une tâche terminée.
• L'URL de réception (l'endpoint) : l'adresse qui reçoit le message. C'est vous qui la fournissez à l'application émettrice.
• Le payload : les données transportées, presque toujours au format JSON. Le contenu utile du message.

S'y ajoute souvent une signature, qui permet de vérifier que le message vient bien de l'expéditeur annoncé.

Pourquoi on l'appelle « reverse API »

Dans un usage classique d'API, c'est vous qui posez la question : votre application interroge un service pour obtenir des données. Avec un webhook, l'initiative s'inverse : c'est le service qui vous parle en premier. D'où les surnoms de « reverse API » ou de « HTTP callback ».

Comment fonctionne un webhook ?

Le déclenchement part de l'application source, pas de celle qui reçoit.

Les quatre étapes d'un envoi

En amont, une seule fois : vous créez une URL de réception dans votre outil (Make, n8n, Zapier, votre serveur…), vous la collez dans l'application émettrice et vous cochez les événements qui vous intéressent. Ensuite, à chaque occurrence, le même cycle se répète.

1. L'événement se produit chez l'application source : un paiement est encaissé.
2. Elle prépare un payload JSON qui décrit ce qui vient d'arriver.
3. Elle appelle votre URL de réception, le plus souvent en méthode POST, avec ce payload.
4. Votre endpoint répond un code 2xx, puis le scénario s'exécute : CRM mis à jour, email envoyé, alerte postée.

La méthode POST est la plus courante, mais elle ne définit pas le webhook. Ce qui définit un webhook, c'est le déclenchement par événement et l'inversion de l'initiative, pas le verbe HTTP employé.

Un exemple de payload

Voici le contenu d'un webhook de paiement, tel qu'il arrive réellement — du JSON valide, que vous pouvez copier pour tester votre scénario.

Deux réflexes utiles : ne jamais supposer qu'un champ sera toujours présent, et toujours vérifier l'unité des montants et le format des dates avant de brancher la suite du scénario.

La réponse du serveur et les codes HTTP

Votre endpoint doit répondre à l'émetteur. Cette réponse est le seul signal dont il dispose pour savoir si le message est arrivé.

Règle pratique : répondez vite, en 200, puis traitez le contenu ensuite. Un traitement trop long fait expirer la requête et déclenche des renvois inutiles.

À quoi servent les webhooks ?

Traiter automatiquement un formulaire

Un prospect remplit un formulaire sur votre site. Le webhook transmet les réponses à votre scénario, qui crée le contact dans le CRM, l'ajoute à une séquence email et poste un message dans le canal Slack commercial. Le tout en quelques secondes, sans copier-coller.

Recevoir les événements de paiement

Stripe, GoCardless ou PayPal envoient un webhook à chaque paiement réussi, échoué ou remboursé. C'est le cas d'usage où le webhook est incontournable : personne ne veut découvrir un échec de prélèvement trois jours plus tard.

Mettre à jour un CRM

Un deal change d'étape dans le CRM : le webhook déclenche l'envoi du devis, la création d'une tâche pour l'équipe delivery et la mise à jour du tableau de suivi. Le CRM reste la source de vérité, le webhook diffuse l'information.

Connecter deux outils qui ne se parlent pas

C'est l'usage le plus fréquent en pratique. Deux logiciels sans intégration native mais qui exposent l'un un webhook, l'autre une API : un scénario Make ou n8n au milieu suffit à les relier. Si vous mesurez ces événements, cadrez-les d'abord dans un plan de taggage : un événement mal nommé au départ se paie en aval sur tous les outils qui le consomment.

Les webhooks servent aussi de déclencheur à un agent IA : l'événement arrive, l'agent lit le contexte, décide et agit.

Webhook, API, polling et callback : quelles différences ?

Webhook et API : deux logiques complémentaires

Une API est interrogée à l'initiative de l'application cliente ; un webhook envoie automatiquement une notification à l'initiative de l'application source, lorsqu'un événement se produit. Voilà la seule distinction qui compte.

Deux précisions souvent mal comprises. D'abord, une API n'est pas la méthode GET : elle expose plusieurs méthodes (GET, POST, PUT, PATCH, DELETE), GET n'en est qu'une. Ensuite, une API n'est pas synonyme de polling : le polling est une façon d'utiliser une API, en l'interrogeant à intervalles réguliers.

Surtout, les deux ne s'opposent pas. Le webhook signale qu'un changement a eu lieu ; l'API permet d'aller chercher les données complètes associées. La plupart des intégrations sérieuses utilisent les deux.

Webhook et polling

Le polling consiste à demander « du nouveau ? » toutes les cinq minutes ; le webhook, lui, est prévenu. Le polling consomme des appels et introduit un délai égal à sa fréquence ; le webhook est immédiat et gratuit en attente, mais dépend de la disponibilité de votre endpoint.

Webhook et callback

Un callback est une réponse différée à une requête que vous avez initiée : vous lancez un traitement long, le service vous rappelle quand c'est fini. Un webhook, lui, arrive sans que vous ayez rien demandé, à chaque occurrence de l'événement. Le callback est ponctuel et lié à votre appel ; le webhook est permanent et lié à un abonnement.

Utiliser une API et un webhook ensemble

Le schéma le plus robuste : le webhook prévient qu'une commande est passée et transmet son identifiant, puis votre scénario appelle l'API pour récupérer le détail complet et à jour de cette commande. Vous gagnez l'immédiateté du webhook et la fiabilité de l'API.

Tableau comparatif

Trois manières d'obtenir la même information : le webhook la reçoit dès qu'elle existe, l'appel d'API la demande au moment choisi, le polling la cherche à l'aveugle à intervalles fixes. Ce qui les sépare, c'est qui déclenche l'échange — pas la donnée obtenue.

Quand utiliser un webhook ?

Les cas où il s'impose

• L'événement est rare mais urgent : paiement échoué, désinscription, incident.
• Vous voulez du temps réel sans surveiller en boucle.
• Le volume d'événements est faible face au volume de données : inutile de tout relire pour repérer une ligne modifiée.
• L'outil source propose des webhooks natifs et vous n'avez pas de développeur.

Les cas où l'API reste préférable

• Vous avez besoin de l'état complet d'une donnée, pas seulement du fait qu'elle a changé.
• Vous faites de l'import ou de l'export en masse, ponctuel.
• L'outil source n'expose pas de webhook : le polling via API est alors la seule voie.
• Vous ne pouvez pas garantir un endpoint disponible en permanence.

Avantages et limites

Côté avantages : temps réel, économie de ressources côté serveur, configuration événement par événement, et intégration possible entre outils qui n'ont pas été conçus pour dialoguer.

Côté limites : vous dépendez de la disponibilité de votre endpoint, vous devez gérer les doublons et les renvois, le débogage se fait « à l'aveugle » puisque l'appel part de chez l'autre, et un changement d'URL casse silencieusement l'intégration. Ces limites se gèrent toutes, à condition d'y penser au moment de la configuration et de la sécurisation.

Comment configurer et tester un webhook ?

Créer une URL de réception

Dans un outil NoCode, c'est l'étape la plus simple : vous ajoutez un module webhook, l'outil génère une URL, vous la copiez. Trois règles : l'URL doit être en HTTPS ; elle est publiquement accessible — n'importe qui sur Internet peut l'appeler, sans authentification — et doit donc rester confidentielle, jamais publiée ni partagée hors de l'équipe ; enfin elle doit être notée quelque part avec l'indication du scénario qu'elle alimente. Une URL orpheline est une panne future.

Sélectionner les événements

Dans l'application émettrice, collez l'URL puis cochez uniquement les événements dont vous avez besoin. S'abonner à tout est la première cause de scénarios qui tournent pour rien et consomment vos opérations. Commencez par un seul événement, faites-le fonctionner, puis élargissez.

Envoyer un événement de test

La plupart des plateformes proposent un bouton « envoyer un événement de test ». Utilisez-le avant de construire la suite : vous verrez la structure réelle du payload, qui diffère souvent de la documentation. Dans Make ou n8n, lancez le module en écoute puis déclenchez l'événement pour capturer la structure des données.

Testez ensuite avec un vrai événement, sur une donnée sans conséquence, puis vérifiez le résultat de bout en bout dans l'outil de destination.

Identifier les erreurs

Deux endroits à consulter systématiquement : le journal des envois chez l'émetteur (il indique le code de réponse reçu) et l'historique d'exécution chez le récepteur. Le croisement des deux localise le problème en une minute.

Comment sécuriser un webhook ?

HTTPS et vérification de signature

Une URL de webhook est joignable depuis Internet sans aucune authentification : quiconque la connaît peut vous envoyer de faux messages. Publiquement accessible ne veut donc pas dire publiable — elle reste confidentielle. Deux protections suffisent dans la majorité des cas. D'abord HTTPS, jamais HTTP : les données circulent chiffrées. Ensuite la vérification de signature : l'émetteur ajoute dans l'en-tête une empreinte calculée avec un secret partagé, et vous rejetez tout message dont l'empreinte ne correspond pas.

Sans mécanisme de signature disponible, deux solutions de repli : un jeton secret placé dans l'URL ou dans un en-tête, et le filtrage des adresses IP de l'émetteur quand il les documente.

Gérer les doublons et les nouvelles tentatives

Si votre serveur ne répond pas, l'émetteur réessaie — souvent plusieurs fois, à intervalles croissants. Conséquence : vous pouvez recevoir deux fois le même événement, et donc facturer deux fois le même client.

La parade s'appelle l'idempotence : conservez l'identifiant unique de chaque événement reçu et ignorez ceux déjà traités. En NoCode, une simple table Airtable ou un data store fait le travail. Prévoyez aussi ce qui se passe si un événement est définitivement perdu : la reprise se fait alors par appel API sur la période concernée.

Créer un webhook avec un outil NoCode

C'est ici que le webhook devient accessible sans développeur. Les plateformes d'automatisation fournissent l'URL, décodent le JSON et affichent les champs prêts à être utilisés.

Dans Make

Dans Make, créez un scénario et choisissez le module Webhooks > Custom webhook. Cliquez sur « Add », nommez-le, copiez l'URL générée. Lancez « Run once » : le module passe en écoute. Déclenchez l'événement dans l'application source : Make capture la structure du payload et vous propose ensuite chaque champ dans les modules suivants. Le module Webhook response permet de renvoyer une réponse personnalisée si l'émetteur en attend une.

Dans n8n

Dans n8n, ajoutez le nœud Webhook comme déclencheur. Vous disposez de deux URL distinctes, une de test et une de production : c'est l'un des vrais atouts de l'outil pour travailler proprement. Choisissez la méthode attendue (POST en général), activez « Listen for test event », déclenchez l'événement, puis activez le workflow pour basculer sur l'URL de production. Le nœud Respond to Webhook gère la réponse.

Dans Zapier

Dans Zapier, le déclencheur s'appelle Webhooks by Zapier, avec l'événement Catch Hook. Zapier génère l'URL, vous la collez chez l'émetteur puis vous demandez un test pour récupérer un échantillon de données. À noter : ce déclencheur nécessite un plan payant.

Avant de trancher entre ces trois plateformes, cette vidéo explique comment choisir son outil d'automatisation en 2026 selon son niveau réel de maîtrise technique.

Pour choisir entre les trois selon votre contexte, volume et budget : Zapier vs Make vs n8n, quel outil d'automatisation choisir. Les autres briques utiles pour bâtir une automatisation complète sont recensées dans notre panorama des outils IA et NoCode.

Quel outil choisir pour brancher un webhook

Le critère utile ici n'est pas la puissance de la plateforme, mais le travail que le webhook doit déclencher une fois reçu — et votre niveau de confort avec les API.

Deux réflexes valent pour les trois. D'abord, ne choisissez pas la plateforme la plus puissante pour votre premier webhook : sans notion d'API, on bloque dès la lecture du payload, et la frustration coûte plus cher que le temps gagné. Ensuite, regardez le modèle de facturation avant d'ouvrir les vannes : un endpoint reçoit tous les événements auxquels vous vous êtes abonné, et une facturation à la tâche ou à l'opération transforme un abonnement trop large en dépense récurrente.

Un dernier point mérite une nuance. La plupart des constructeurs d'agents IA savent parfaitement recevoir un webhook : n8n comme Voiceflow exposent une URL de réception. La question n'est donc pas technique mais fonctionnelle : si l'événement doit surtout mettre à jour des outils métier, une plateforme d'automatisation reste plus lisible et moins coûteuse à maintenir ; si l'événement doit alimenter un raisonnement ou une conversation, l'agent est à sa place.

Créer un webhook Discord pas à pas

Discord est le meilleur terrain d'entraînement : le webhook est ici entrant, c'est-à-dire que vous obtenez une URL à laquelle vos autres outils enverront des messages qui s'afficheront dans un salon.

1. Ouvrez Discord et rendez-vous sur le serveur concerné. Il faut y disposer de la permission « Gérer les webhooks ».
2. Cliquez sur le nom du serveur puis sur Paramètres du serveur.
3. Dans le menu de gauche, ouvrez Intégrations, puis Webhooks.
4. Cliquez sur Nouveau webhook.
5. Renseignez le nom affiché à chaque message, le salon de destination et, si vous le souhaitez, un avatar.
6. Cliquez sur Copier l'URL du webhook. Traitez-la comme un mot de passe : qui l'a peut poster dans votre salon.
7. Cliquez sur Enregistrer.

Pour l'utiliser, collez cette URL dans un module HTTP de Make, n8n ou Zapier et envoyez une requête POST avec un corps JSON contenant un champ content : le texte apparaît dans le salon. Usage typique : recevoir une alerte Discord à chaque nouveau paiement, nouveau lead ou erreur de scénario.

Trois pièges classiques sur Discord. Le webhook est limité en fréquence d'envoi : Discord autorise 5 requêtes par tranche de 2 secondes et par webhook, avec une limite complémentaire de 5 requêtes par 5 secondes et par salon, partagée entre tous les webhooks qui publient dans ce salon ; au-delà, l'API renvoie une erreur 429 et il faut espacer les envois. Le champ content est plafonné à 2 000 caractères : pour un message long, utilisez plutôt un embed. Enfin, supprimer le salon de destination casse le webhook sans avertissement.

Ce qu'il faut retenir

Un webhook n'est pas un sujet de développeur. C'est une URL, un événement et un payload JSON — trois notions qui se maîtrisent en une après-midi et qui changent la façon dont vos outils travaillent ensemble. L'API va chercher l'information ; le webhook vous l'apporte. Les deux ensemble couvrent l'essentiel des besoins d'intégration d'une entreprise.

Si vous voulez construire vous-même vos automatisations plutôt que de les sous-traiter, c'est exactement ce que l'on enseigne à l'Alegria Academy : partir d'un besoin métier et le transformer en scénario qui tourne seul.

Article mis à jour le 30 juillet 2026.