C’est quoi un webhook
Quand la requête vient de l'extérieur
Tout ce que vous avez appris jusqu'ici suit le même schéma : votre app envoie une requête à un service externe, et le service renvoie une réponse. Votre app demande à Stripe "montre-moi les factures de ce client", et Stripe répond.
Mais parfois, le flux s'inverse. Quelque chose se passe du côté de Stripe (un paiement réussit, un abonnement est annulé), et votre app doit le savoir. Pas dans cinq minutes. Tout de suite.
Comment votre app l'apprend-elle ? Deux options.
Option A : votre serveur demande sans cesse à Stripe "est-ce que quelque chose a changé ?" toutes les quelques secondes. Comme si vous rafraîchissiez une page de suivi de livraison encore et encore, en espérant une mise à jour.
Option B : vous dites à Stripe "appelez-moi quand quelque chose se passe." Comme si vous donniez votre numéro au restaurant pour qu'ils vous envoient un SMS quand votre table est prête, au lieu de les rappeler toutes les deux minutes.
L'option A s'appelle le polling. L'option B s'appelle un webhook. Ce chapitre porte sur l'option B.
Le polling : l'approche par force brute
Le polling signifie que votre serveur appelle l'API du service externe à intervalle régulier : "De nouveaux paiements ? Non ? OK, je redemande dans 30 secondes."
Ça fonctionne, mais la plupart du temps la réponse est "rien n'a changé." Votre serveur gaspille des requêtes, de la bande passante et des limites d'API pour rien. Et si quelque chose se passe vraiment, vous ne le découvrez qu'au prochain check, pas au moment où c'est arrivé.
Les webhooks : "ne nous appelez pas, on vous appellera"
Un webhook inverse la direction. Au lieu que votre serveur demande des mises à jour au service externe, le service externe appelle votre serveur quand quelque chose se passe.
Voici comment ça marche : vous donnez à Stripe une URL sur votre serveur (appelée webhook URL). Vous dites : "chaque fois qu'un paiement réussit, envoie un message à cette URL." À partir de là, Stripe appelle automatiquement votre serveur chaque fois qu'un paiement est validé. Pas de polling. Pas de requêtes gaspillées. Vous recevez les données exactement quand ça compte.
Le point essentiel : les webhooks concernent toujours un service externe qui envoie des données à votre app. Stripe vous informe des paiements. Shopify vous informe des commandes. C'est toujours un système extérieur qui contacte le vôtre pour dire "hé, il vient de se passer ça."
Vous avez déjà vu ce schéma
Les webhooks sont derrière la plupart des fonctionnalités temps réel que vous utilisez chaque jour. Le schéma est toujours le même : quelque chose se passe sur un service externe, et ce service notifie votre app.
- Stripe → votre app. Un client paie un abonnement. Stripe envoie un webhook pour que votre app débloque instantanément les fonctionnalités premium. Sans cela, l'utilisateur paierait et ne verrait rien se passer tant que votre serveur n'a pas vérifié auprès de Stripe.
- Shopify → votre entrepôt. Un client passe une commande sur votre boutique en ligne. Shopify envoie un webhook à votre système de préparation pour que l'emballage commence immédiatement, pas la prochaine fois que quelqu'un consulte le dashboard.
- Twilio → votre outil de support. Un client répond à un SMS que vous avez envoyé. Twilio transmet le message à votre serveur via webhook pour qu'il apparaisse dans votre boîte de support en temps réel. Remarquez le schéma : c'est toujours Service externe → Votre app. Les webhooks sont le mécanisme que les services externes utilisent pour pousser des informations dans votre produit au moment où quelque chose se passe de leur côté.
Polling vs. webhooks côte à côte
| Polling | Webhooks | |
|---|---|---|
| Qui initie ? | Votre serveur demande en boucle | Le service externe vous prévient |
| Timing | Vous l'apprenez au prochain check (décalé) | Vous l'apprenez immédiatement |
| Requêtes gaspillées | Beaucoup (la plupart des checks ne trouvent rien) | Zéro (se déclenche uniquement quand quelque chose se passe) |
| Mise en place | Facile (appeler l'API à intervalle régulier) | Nécessite d'enregistrer une webhook URL |
| Analogie | Rafraîchir la page de livraison toutes les 5 min | Recevoir une notification push |
Le polling est plus simple à mettre en place, mais il ne passe pas à l'échelle. Si vous vérifiez 10 services toutes les 30 secondes, ça fait 20 requêtes par minute qui ne servent à rien. Les webhooks sont plus efficaces : zéro requête tant que rien ne se passe, puis une notification avec toutes les données dont vous avez besoin.
La webhook URL
Pour recevoir des webhooks, vous devez fournir au service externe une URL où il peut envoyer des messages. C'est votre webhook URL (parfois appelée webhook endpoint ou callback URL).
Elle ressemble à n'importe quelle autre URL :
https://yourapp.com/webhooks/stripe
Quand vous configurez les webhooks dans le dashboard de Stripe (ou de n'importe quel service), vous collez cette URL et sélectionnez les événements que vous souhaitez recevoir. Stripe la stocke et envoie une requête POST à cette URL chaque fois qu'un de ces événements se produit.
C'est votre équipe technique qui met ça en place. Mais en tant que PM, vous verrez ce concept revenir dans les discussions d'intégration. Quand quelqu'un dit "on doit mettre en place un webhook pour les paiements", ça signifie : enregistrer une URL auprès de Stripe pour que votre serveur soit notifié automatiquement.
Points clés
- Le polling consiste à demander "du nouveau ?" en boucle. Ça fonctionne mais gaspille des ressources.
- Les webhooks inversent le modèle : le service vous notifie quand quelque chose se passe.
- Vous enregistrez une webhook URL auprès du service externe. Il envoie les données à cette URL automatiquement.
- Les webhooks alimentent les fonctionnalités temps réel : confirmations de paiement instantanées, mises à jour de commandes, déclenchements de déploiement.
- Vous n'avez pas besoin de construire des webhooks vous-même. Vous devez comprendre le concept pour avoir des conversations productives avec votre équipe technique.