Webhook

Ce qui distingue un webhook d'une API classique

Une API classique fonctionne en mode requête-réponse : une application pose une question, le service répond à ce moment précis. Un webhook inverse ce fonctionnement : c'est le service qui envoie l'information de sa propre initiative, au moment de l'événement, vers une adresse HTTP fournie par l'application destinataire.

Concrètement, Shopify envoie un webhook à chaque nouvelle commande. Stripe envoie un webhook lorsqu'un paiement est confirmé ou échoue. HubSpot en envoie un lorsqu'un contact change de statut ou franchit une étape de pipeline. L'application destinataire reçoit ces notifications et peut déclencher une action immédiatement.

Ce mécanisme est plus efficace qu'un sondage régulier pour les événements rares ou imprévisibles : le système ne consomme pas de ressources entre deux événements, et le délai entre l'événement et la notification est minimal. Il constitue la base technique de la plupart des intégrations en temps réel entre services.

Webhook dans un projet

Les webhooks servent à synchroniser des systèmes sans les faire communiquer en permanence. Une commande Shopify qui met à jour un CRM, un paiement confirmé qui active un accès, une signature électronique qui déclenche un email : ces enchaînements passent typiquement par des webhooks.

Deux points de sécurité s'appliquent à chaque déploiement. L'adresse réceptrice du webhook est publique par nature : n'importe quelle requête HTTP peut l'appeler. Les services sérieux incluent dans chaque notification une signature cryptographique que le récepteur doit vérifier avant tout traitement. Ignorer cette vérification expose à des événements forgés.

La gestion des échecs est l'autre point structurant. Si l'application réceptrice est indisponible au moment de l'envoi, chaque service a ses propres règles de renvoi : nombre de tentatives, délai entre chaque essai, délai maximal avant abandon. Un mécanisme de file d'attente ou un journal des notifications reçues permet de traiter les événements manqués sans doublons ni pertes.

Avant d'utiliser un webhook dans une intégration, trois vérifications s'imposent : la liste des événements disponibles chez le service émetteur, le format du payload envoyé, et la procédure de vérification de signature documentée par le service.

Les webhooks sont aussi au cœur des automatisations entre outils. Dans un projet métier structuré, ils servent de déclencheurs pour des traitements côté serveur : extraction d'informations d'un document reçu, mise à jour d'une base de données, envoi d'un email transactionnel, appel d'un modèle pour analyser l'événement entrant. L'application reçoit l'événement et décide du traitement à appliquer, sans dépendre d'un sondage régulier du service source. Le webhook devient ainsi le point d'entrée d'un flux de traitement dont l'application garde le contrôle total.