Webhook

Mécanisme par lequel un service appelle automatiquement une URL fournie par un client lorsqu'un événement survient, plutôt que d'attendre une requête de celui-ci.

En clair

Un webhook inverse le sens habituel d'un appel d'API. Au lieu que le client interroge régulièrement un service pour savoir si quelque chose a changé, le client fournit une URL au service ; lorsqu'un événement survient (un paiement, une livraison, une mise à jour), le service appelle lui-même cette URL en y envoyant les détails. On parle parfois d'« API inversée » ou de rappel HTTP : c'est le serveur qui notifie le client, en temps quasi réel. Techniquement, la notification prend la forme d'une requête HTTP, le plus souvent un POST dont le corps décrit l'événement et ses données. La configuration se résume généralement à enregistrer une URL et à choisir les types d'événements auxquels on souhaite s'abonner.

Pourquoi c'est utilisé

Interroger un service en boucle pour détecter un changement (le « polling ») est inefficace : on consomme des ressources pour la plupart du temps découvrir qu'il n'y a rien de neuf, avec un délai entre l'événement et sa détection. Le webhook supprime ce gaspillage : la notification arrive dès que l'événement se produit. C'est le moyen standard d'être prévenu en temps réel par un service tiers. Il allège aussi la charge du service émetteur, qui n'a plus à répondre à des requêtes répétées pour rien. C'est pourquoi la plupart des plateformes de paiement, d'envoi de messages ou d'hébergement de code proposent des webhooks pour signaler leurs événements aux applications qui s'y intègrent.

En mission / dans la pratique

Le consultant met en place des webhooks pour intégrer des services externes : il expose une URL publique, reçoit et valide les notifications, puis déclenche le traitement correspondant. Le quotidien implique de sécuriser l'endpoint (vérification de signature), de répondre vite pour acquitter, et de traiter le contenu de façon asynchrone. C'est un grand classique des intégrations entre systèmes. En phase de développement, on s'appuie souvent sur un tunnel exposant le poste local sur une URL publique pour tester la réception, faute de quoi l'émetteur ne peut pas joindre la machine. Il faut aussi prévoir une trace des notifications reçues : sans journalisation, diagnostiquer un événement manqué ou mal traité devient très difficile.

Pièges & bonnes pratiques

Un webhook peut être rejoué ou livré en double : rendez le traitement idempotent. Vérifiez systématiquement la signature pour vous assurer de l'origine, et acquittez rapidement avant de traiter en arrière-plan. Prévoyez la gestion des échecs côté émetteur (nouvelles tentatives) comme côté récepteur, et n'exposez pas l'endpoint sans contrôle d'authenticité. Méfiez-vous de l'ordre d'arrivée : rien ne garantit que deux événements seront reçus dans la séquence où ils se sont produits, mieux vaut donc se fier à l'état porté par la notification plutôt qu'à son ordre. Un traitement trop lent qui dépasse le délai d'attente de l'émetteur peut aussi déclencher des renvois en cascade, d'où l'intérêt d'accuser réception sans attendre.

À ne pas confondre

Le webhook est l'inverse d'un appel d'API REST classique : ici c'est le serveur qui appelle. À distinguer du message broker, qui transporte des messages en interne via un intermédiaire. Il sert souvent de déclencheur dans une architecture événementielle.

ForTeam IT à vos côtés

Vous recherchez une mission ou un consultant expert sur ce sujet ? ForTeam IT met en relation des consultants IT freelance sélectionnés avec des grands comptes, ETI et scale-ups partout en France. Consultez aussi notre grille des TJM freelance IT et nos expertises par technologie.

Rejoindre la communauté