Définition technique
Mécanisme où un service (e-commerce, CRM, paiement) envoie une requête HTTP à votre URL lorsqu'un événement se produit (nouvelle commande, paiement reçu, lead créé). Vous n'avez pas à interroger en continu (polling) : le partenaire « pousse » l'information. Essentiel pour l'automatisation en temps réel : mise à jour stock, synchro CRM, relances panier abandonné. Votre serveur doit exposer une URL publique, vérifier la signature du webhook et répondre rapidement (200) pour éviter les retries.
Comment ça fonctionne ?
Vous enregistrez une URL auprès du service partenaire. Quand l'événement a lieu, le service envoie une requête POST à cette URL avec un payload (JSON en général). Votre serveur traite la requête (vérification signature, parsing, mise à jour BDD, déclenchement d'actions) et renvoie 2xx. En cas d'échec (timeout, 5xx), le partenaire réessaie selon sa politique.
L'erreur classique à éviter
Ne pas vérifier la signature du webhook (risque de requêtes forgées). Traiter de façon synchrone des actions lourdes (le partenaire attend la réponse). Ne pas gérer les doublons (même événement envoyé plusieurs fois).
Impact business : pourquoi s'en soucier ?
Les webhooks permettent d'enchaîner des actions sans délai : commande → facturation, lead → création de ticket, paiement → envoi d'email. Vital pour l'e-commerce (notifications commande, stock) et le marketing (événements, scoring). Sans webhook, vous dépendez du polling ou d'actions manuelles, ce qui ralentit et alourdit les process.
La règle d'or
Toujours valider la signature (HMAC, secret partagé). Répondre 200 rapidement et traiter en asynchrone si besoin. Rendre l'endpoint idempotent (éviter de dupliquer les effets). Logger les payloads pour le debug.