Webhook
Un webhook est un message automatique qu'un service envoie à votre application dès qu'un événement survient — un paiement réussi, un email ouvert, un formulaire soumis. Au lieu de demander sans cesse « du nouveau ? », votre application est prévenue en temps réel. C'est une notification poussée de système à système, déclenchée par l'événement lui-même.
Comment fonctionne un webhook ?
Le principe est l'inverse de l'appel classique. Vous indiquez au service une adresse de votre application (une URL) où il doit vous écrire. Quand l'événement choisi se produit, le service envoie automatiquement à cette adresse un message contenant les détails — par exemple « le paiement n°123 a réussi, montant 49 € ». Votre application reçoit ce message et réagit : elle active l'abonnement, envoie un email de confirmation, met à jour la base. Tout cela en temps réel, sans que vous ayez eu à demander quoi que ce soit. Le webhook transforme un événement distant en action immédiate chez vous. C'est ce mécanisme qui rend les produits modernes « vivants » : les choses se mettent à jour toutes seules au bon moment.
Webhook ou API : quelle différence ?
Les deux font dialoguer des logiciels, mais dans des sens opposés, et c'est toute la nuance. Avec une API classique, c'est vous qui interrogez : « y a-t-il du nouveau ? » — vous tirez l'information quand vous le décidez. Avec un webhook, c'est le service qui vous prévient quand quelque chose arrive — l'information vous est poussée. Pour suivre des paiements, demander toutes les minutes « ce paiement est-il passé ? » serait lourd et lent ; un webhook vous le dit à la seconde où ça se produit. On résume souvent : l'API, c'est « appelez-nous quand vous voulez » ; le webhook, c'est « ne nous appelez pas, on vous rappellera ». Les deux coexistent dans la plupart des intégrations.
Pourquoi sécuriser ses webhooks ?
Parce qu'un webhook est une porte d'entrée : une URL publique qui attend des messages et déclenche des actions. Si n'importe qui peut envoyer un faux message « paiement réussi », il pourrait activer un abonnement sans payer. D'où deux protections essentielles. La vérification de signature : le service signe chaque message avec un secret partagé, et votre application refuse tout message dont la signature ne correspond pas — la garantie qu'il vient bien de l'expéditeur attendu. Et l'idempotence : comme un même événement peut être envoyé plusieurs fois (renvois, doublons), votre application doit pouvoir le traiter une seule fois sans effet de bord. Un webhook de paiement traité deux fois, c'est un double débit ou un double accès. Ces deux garde-fous ne sont pas optionnels.
Quels usages concrets pour un fondateur ?
Les webhooks sont partout dès qu'un produit doit réagir à des événements externes. Le paiement, d'abord : Stripe prévient votre SaaS qu'un abonnement a été payé, renouvelé, ou a échoué — votre produit ajuste l'accès en conséquence. Mais aussi l'emailing (savoir qu'un message a été ouvert ou a rebondi), les formulaires (déclencher une notification à chaque nouveau lead), les outils no-code et l'automatisation (relier deux applications qui n'étaient pas faites pour se parler). Pour vous, l'intérêt est concret : votre produit reste synchronisé avec le monde extérieur sans intervention manuelle ni vérification permanente. Bien utilisés, les webhooks remplacent une foule de tâches répétitives par des automatismes fiables.
Comment teste-t-on un webhook ?
Tester un webhook est moins évident qu'un appel classique, puisque c'est un service distant qui doit joindre votre application — souvent en cours de développement, sur votre machine. Trois outils rendent l'exercice simple. D'abord, les « tunnels » locaux, qui exposent temporairement votre environnement de développement sur une adresse publique, pour que le service puisse y livrer ses messages comme en production. Ensuite, les journaux et outils de relecture fournis par la plupart des services (Stripe en tête) : ils montrent chaque message envoyé, sa réponse, et permettent de le renvoyer à volonté pour rejouer un scénario sans reproduire l'événement réel. Enfin, des outils de simulation fabriquent de faux événements signés pour vérifier votre traitement. La bonne pratique : tester explicitement les cas difficiles — message en double, signature invalide, service indisponible — car c'est précisément là que les intégrations fragiles cèdent en production. Un webhook bien testé est un webhook qu'on a fait échouer exprès, avant que la vraie vie ne s'en charge.
| Appel d'API | Webhook | |
|---|---|---|
| Qui déclenche | Vous (à la demande) | Le service (sur événement) |
| Sens | Vous tirez l'info | L'info vous est poussée |
| Idéal pour | Lire une donnée ponctuelle | Réagir en temps réel |
| Image | « J'appelle quand je veux » | « On vous rappellera » |
Les questions fréquentes
Un projet en tête ?
Décrivez-nous votre projet en deux minutes. Réponse sous 24h ouvrées, avec une première lecture concrète.