Webhook

Ce qu'est un webhook

Un webhook est un message automatique qu'une application envoie à une autre dès qu'un événement précis se produit. Au lieu de demander sans cesse à un service si quelque chose a changé, vous lui confiez une URL et il vous appelle à l'instant où l'événement survient. Comme le message circule via le protocole HTTP standard, en général sous forme de requête POST transportant un petit bloc de données, presque tout outil capable de recevoir une requête web peut recevoir un webhook. On le décrit souvent comme une API inversée ou une notification poussée entre logiciels : la donnée vient à vous plutôt que d'aller la chercher.

Son intérêt concret est l'immédiateté. Un formulaire est envoyé, un paiement est validé, une fiche est mise à jour, et en une seconde le système récepteur le sait et peut réagir. Cette qualité temps réel fait du webhook le tissu conjonctif de l'automatisation moderne, reliant un site, un CRM, un tableur, un canal de messagerie et bien d'autres outils sans que personne ne touche un clavier.

Comment fonctionne un webhook

Trois éléments le font fonctionner : l'événement, la charge utile et le point de terminaison. L'événement est le déclencheur, ce qui vient de se passer, comme une nouvelle commande ou un abonnement annulé. La charge utile (payload) est la donnée qui décrit cet événement, presque toujours au format JSON, contenant des champs comme l'e-mail du client, le montant ou l'identifiant de la fiche. Le point de terminaison (endpoint) est l'URL côté récepteur qui écoute les requêtes entrantes et sait quoi en faire.

La séquence est simple. Vous enregistrez l'URL de votre endpoint dans le système source. Quand l'événement se déclenche, la source construit la charge utile et envoie une requête HTTP POST vers votre URL. Votre endpoint la reçoit, lit les données et exécute la logique définie : créer une ligne, envoyer un e-mail, mettre à jour une opportunité. Un récepteur bien conçu répond vite avec un code 200 pour confirmer la réception. Sinon, la plupart des émetteurs réessaient plusieurs fois avant d'abandonner, d'où l'intérêt d'accuser réception rapidement et de traiter les tâches lourdes ensuite.

Webhook contre API : pousser contre tirer

On confond souvent webhooks et API car les deux déplacent des données entre systèmes via HTTP, mais ils fonctionnent en sens inverse. Avec une API classique, vous tirez : votre code pose une question au serveur et attend une réponse, et pour obtenir des données fraîches il faut redemander. Avec un webhook, le serveur pousse : il vous contacte uniquement lorsqu'il a du nouveau à signaler.

La différence compte pour l'efficacité. Interroger une API chaque minute pour voir si un formulaire a été rempli gaspille des requêtes et ajoute quand même du délai. Un webhook envoie exactement un message au moment exact où cela importe, rien de plus. La contrepartie est qu'un webhook exige un récepteur toujours joignable, alors que l'interrogation peut se faire quand votre code se réveille. En pratique, les deux sont complémentaires : le webhook vous prévient qu'une chose a changé, et vous appelez souvent une API ensuite pour récupérer les détails complets.

Prenons un site Webflow doté d'un formulaire de contact. Webflow peut déclencher un webhook dès qu'un visiteur l'envoie. Cette requête arrive dans une plateforme d'automatisation comme Make, en transportant le nom, l'e-mail et le message. De là, le scénario se ramifie : il ajoute le prospect à un CRM, publie un résumé dans un canal d'équipe et envoie au visiteur un e-mail d'accusé de réception, le tout en quelques secondes. Personne n'a exporté de fichier, personne n'a recopié un champ. Un seul événement a produit toute une chaîne d'actions parce qu'un webhook a porté la nouvelle à l'instant même.

Sécurité : secrets et vérification

Comme un endpoint de webhook est une URL publique, quiconque la découvre pourrait tenter d'envoyer de fausses requêtes : la vérification est donc essentielle. La protection la plus courante est un secret de signature. L'émetteur utilise une clé secrète partagée pour calculer une signature sur la charge utile et l'inclut dans un en-tête. Votre endpoint recalcule la même signature et n'accepte la requête que si elles correspondent, ce qui prouve que le message provient bien de la source attendue et n'a pas été altéré en chemin.

D'autres mesures de bon sens : servir l'endpoint en HTTPS pour chiffrer la charge utile, vérifier un horodatage afin de rejeter les requêtes rejouées trop anciennes, et valider que les données ont bien la forme attendue avant d'agir. Traiter chaque webhook entrant comme non fiable tant qu'il n'est pas vérifié est la discipline de base, surtout quand l'action déclenchée touche à l'argent, aux comptes ou aux données clients.

Quand utiliser un webhook, et quand s'en passer

Les webhooks brillent lorsque vous devez réagir à des événements en quasi temps réel et lorsque le système source les propose. Ils gardent les outils synchronisés, réduisent le travail manuel et passent bien à l'échelle puisque les messages ne circulent que quand quelque chose se produit vraiment. Si votre flux dépend de la vitesse, le webhook est presque toujours la bonne brique.

Ils conviennent mal dans quelques cas. Si vous avez besoin d'un instantané historique complet plutôt que d'un flux de changements, un appel d'API vaut mieux. Si le système récepteur ne peut pas héberger un endpoint joignable, ou si vous n'avez besoin des données qu'occasionnellement, une interrogation planifiée sera plus simple. Et si les événements sont très fréquents, mieux vaut les regrouper ou les mettre en file pour ne pas saturer l'outil en aval. La règle : le webhook pour réagir, l'API pour demander.

Chez BeBranded

Chez BeBranded, nous considérons les webhooks comme la tuyauterie de presque chaque automatisation que nous construisons. Un montage typique relie un site Webflow ou Framer à une plateforme no-code comme Make ou n8n via un webhook, si bien qu'un envoi de formulaire, un achat ou un changement de statut déclenche aussitôt le bon suivi dans un CRM, une base de données ou un canal Slack. Nous concevons chaque endpoint pour qu'il accuse réception vite, vérifie sa signature et échoue proprement, car un webhook cassé mais silencieux est l'un des problèmes les plus difficiles à repérer. Le résultat, pour nos clients, est une stack qui reste synchronisée d'elle-même, avec moins d'étapes manuelles et moins de place pour l'erreur humaine.