Webhook

Un webhook est un message automatique qu'une application envoie à une autre dès qu'un événement se produit. Au lieu d'aller demander régulièrement "est-ce qu'il y a du nouveau ?", votre système est prévenu au moment exact où quelque chose se passe.

C'est la différence entre appeler le facteur toutes les dix minutes pour savoir s'il a du courrier, et recevoir une notification quand il dépose une lettre. La seconde méthode consomme moins de ressources et réagit instantanément.

Comment fonctionne un webhook

Le principe tient en trois étapes. Vous fournissez une URL à un service tiers, par exemple votre outil de paiement. Quand l'événement surveille se produit, ce service envoie une requête HTTP POST vers votre URL, avec les détails de l'événement au format JSON. Votre application reçoit ce message et déclenche le traitement correspondant.

L'échange est unidirectionnel et immédiat. Le service émetteur n'attend rien d'autre qu'une confirmation de réception, généralement un code HTTP 200.

À quoi ça sert concrètement

• Paiements : Stripe prévient votre site dès qu'un paiement aboutit ou échoue, ce qui déclenche l'envoi de la facture et la mise à jour de la commande.
• Formulaires : une soumission crée automatiquement une fiche dans le CRM et notifié le commercial concerne.
• Livraison : le transporteur signale chaque changement de statut, votre client reçoit un email sans intervention humaine.
• Outils internes : un ticket ferme dans le support met à jour le tableau de bord et alerte l'équipe sur Slack.
• Automatisation : dans n8n, Make ou Zapier, le webhook est le point de départ le plus courant d'un scénario.

Webhook et API : quelle différence

Une API classique fonctionne sur demande : votre application interroge le service et obtient une réponse. C'est vous qui initiez l'échange, donc vous devez savoir quand demander.

Un webhook inverse le sens. Le service vous contacte de lui-même. On parle parfois d'API inversée ou de reverse API. Les deux se complètent souvent : le webhook signale qu'il s'est passe quelque chose, puis votre application appelle l'API pour récupérer le détail complet.

Les pièges à connaître

• Les doublons. Un même événement peut être envoyé plusieurs fois si l'émetteur n'a pas reçu de confirmation. Votre traitement doit être idempotent : recevoir deux fois le même message ne doit pas créer deux commandes.
• La sécurité. Une URL de webhook est publique. Sans vérification de signature, n'importe qui peut envoyer une fausse notification de paiement. La plupart des services signent leurs messages, cette vérification n'est pas optionnelle.
• Les échecs silencieux. Si votre serveur est indisponible, le message est perdu ou reessaye un nombre limite de fois. Un mécanisme de rejeu et une journalisation sont indispensables dès que le flux compte.
• L'ordre d'arrivée. Rien ne garantit que les événements arrivent dans l'ordre ou ils se sont produits. Un statut "livre" peut précéder un "expédié".