Webhook

Un webhook est une notification HTTP que le serveur pousse vers une URL configurée par le client dès qu'un événement se produit : paiement reçu (Stripe), commit poussé (GitHub), formulaire soumis (Typeform), facture émise (Stripe), message reçu (Slack). C'est le miroir d'une API REST : au lieu que le client demande « quoi de neuf ? » en boucle (*polling*), le serveur dit « voilà ce qui vient de se passer » au moment exact où ça arrive. Le payload est presque toujours un POST JSON sur l'endpoint que vous lui avez donné.

Le webhook supprime la latence et la consommation inutile du polling. Un script qui interroge l'API Stripe toutes les minutes pour voir s'il y a un nouveau paiement, c'est 1 440 appels/jour pour rien dans 99 % des cas — un webhook fait 1 appel au moment du paiement, point. C'est pour ça qu'on les retrouve partout : dans un CRM qui notifie l'ERP d'un deal gagné, dans un PIM qui synchronise un changement de prix vers Shopify, dans un outil métier qui réagit à un événement BTP/santé/finance. C'est aussi l'élément qui colle ensemble les briques d'une stack low-code (n8n, Make, Zapier).

Trois choses font la différence entre un webhook qui marche et un qui ramène la production : la signature HMAC (vérifier que le payload vient bien de l'émetteur, pas d'un attaquant qui spamme votre URL publique), l'idempotence (le même événement peut arriver deux fois — votre handler doit pouvoir l'ignorer si déjà traité, via un `event_id`), et le retry exponentiel côté émetteur (Stripe retente pendant 3 jours si votre serveur est down). Pour les architectures avec beaucoup d'événements internes ou des besoins de fan-out, on monte d'un cran vers une vraie archi event-driven avec Kafka ou NATS plutôt que des webhooks point-à-point.