Qu’est-ce qu’un webhook ?
Un webhook est un appel HTTP automatique déclenché par un événement. Quand quelque chose se passe dans une application A (un paiement reçu, un formulaire soumis, un commit pushé), elle envoie immédiatement les données à une URL que vous avez configurée dans l’application B.
Pas besoin de vérifier toutes les 5 secondes si quelque chose a changé. Le webhook vous prévient en temps réel.
Comment fonctionne un webhook ?
Le mécanisme est simple :
- Configuration — Vous fournissez une URL de callback à l’application source (ex :
https://mon-serveur.com/webhook/stripe) - Événement — Un événement se produit (un client paie, un ticket est créé)
- Notification — L’application envoie une requête HTTP POST à votre URL avec les données de l’événement en JSON
- Traitement — Votre serveur reçoit les données et exécute la logique souhaitée
{
"type": "payment_intent.succeeded",
"data": {
"object": {
"amount": 2000,
"currency": "eur",
"customer": "cus_ABC123"
}
}
}Webhook vs API : deux approches complémentaires
| Critère | API (pull) | Webhook (push) |
|---|---|---|
| Qui initie ? | Vous (requête) | L’application source |
| Temps réel ? | Non (polling) | Oui |
| Charge serveur | Élevée (requêtes répétées) | Faible (à la demande) |
| Usage typique | Lire des données à la demande | Réagir à des événements |
En pratique, vous utilisez les deux. L’API pour aller chercher des données quand vous en avez besoin. Le webhook pour être notifié quand quelque chose change.
Webhooks et automatisation IA
Les webhooks sont l’un des déclencheurs principaux des workflows d’automatisation. Dans des outils no-code comme n8n ou Make, le schéma classique est :
- Un webhook reçoit un événement (nouveau lead, message, commande)
- Le workflow traite les données avec un LLM (classification, résumé, réponse automatique via un chatbot)
- Une action est déclenchée (envoi d’email, mise à jour CRM, notification Slack)
Exemple concret avec n8n
Un formulaire de contact déclenche un webhook. n8n envoie le message à Claude pour analyser le sentiment et la catégorie. Selon le résultat, le workflow crée un ticket dans Linear (urgent) ou envoie une réponse automatique (question simple).
Bonnes pratiques
- Toujours vérifier la signature — Ne faites jamais confiance aux données d’un webhook sans vérifier leur authenticité via la signature HMAC
- Répondre vite (200 OK) — Renvoyez un code 200 immédiatement, traitez les données en arrière-plan. Les services réessaient si vous mettez trop de temps à répondre
- Gérer les doublons — Un webhook peut être envoyé plusieurs fois. Utilisez un identifiant unique pour éviter de traiter le même événement deux fois
- Logger les payloads — En cas de problème, avoir un historique des données reçues est indispensable pour le debug
Termes associés
Questions fréquentes
Quelle est la différence entre un webhook et une API ?
Une API fonctionne en mode pull : vous envoyez une requête pour obtenir des données. Un webhook fonctionne en mode push : l'application vous envoie les données automatiquement quand un événement se produit. L'API demande, le webhook notifie. Le webhook est plus efficace car il évite de vérifier constamment si quelque chose a changé.
Les webhooks sont-ils sécurisés ?
Par défaut, un webhook est une URL publique qui accepte des requêtes POST. Pour le sécuriser, il faut vérifier la signature HMAC fournie par l'expéditeur, utiliser HTTPS obligatoirement, et éventuellement filtrer par adresse IP source. La plupart des services (Stripe, GitHub, Slack) incluent un mécanisme de signature.
Comment tester un webhook en développement ?
Utilisez un service comme webhook.site ou RequestBin pour inspecter les requêtes reçues. Pour exposer un webhook local sur internet, des outils comme ngrok ou Cloudflare Tunnel créent un tunnel sécurisé vers votre machine. n8n propose aussi un mode test qui affiche les données reçues avant d'activer le workflow.
Que faire quand un webhook échoue ?
Commencez par vérifier les logs de votre serveur pour identifier l'erreur (timeout, code 500, payload malformé). Assurez-vous que votre endpoint répond avec un code 200 en moins de 5 secondes. Si le problème persiste, consultez le tableau de bord du service expéditeur (Stripe, GitHub, etc.) qui conserve un historique des tentatives et permet de renvoyer manuellement un webhook. Mettez en place un système de file d'attente pour traiter les payloads en arrière-plan et éviter les timeouts.