webhooks: API et REST
Les webhooks sont un modèle important dans le monde des API et de REST, et constituent un moyen puissant de permettre une communication en temps réel entre systèmes. Contrairement aux appels d'API traditionnels, où un client doit activement demander de nouvelles données — un processus connu sous le nom de polling — les webhooks envoient des données automatiquement dès qu'un événement déterminé se produit. Ce modèle événementiel assure une communication plus efficace, car les systèmes ne doivent pas continuellement vérifier si de nouvelles informations sont disponibles. Au lieu de cela, le destinataire reçoit les données « whenever those events occur », comme le formule GitHub Docs. Cela signifie que les mises à jour sont transmises directement via une requête HTTP vers une URL prédéfinie, sans que le destinataire doive initier une nouvelle requête pour cela.
Le concept de webhooks n'est pas nouveau, mais depuis son introduction en 2006, il a progressivement pris une place plus importante dans les architectures d'API modernes. Jeff Lindsay est explicitement cité comme la personne qui a introduit le concept de webhooks cette année-là. Son intuition était que les systèmes peuvent réagir plus rapidement et plus efficacement aux changements s'ils ne doivent pas attendre les demandes d'un client, mais sont au contraire informés automatiquement. Cette idée a depuis été adoptée par de nombreuses plateformes et fournisseurs d'API, dont GitHub, Shopify et Autodesk Platform Services. La force des webhooks réside dans leur simplicité : un serveur envoie une requête HTTP POST vers une URL indiquée par le destinataire, dès qu'un événement prédéfini — comme un commit de code, une commande ou une modification de fichier — se produit.
L'un des principaux avantages des webhooks par rapport au polling est la réduction du trafic réseau inutile et de la charge serveur. Avec le polling, un client doit régulièrement vérifier une API pour de nouvelles données, même si rien n'a changé. Cela entraîne une inefficacité, car de nombreuses requêtes sont vides ou redondantes. Les webhooks éliminent ce problème en n'envoyant des données que lorsqu'il y a réellement quelque chose à signaler. Red Hat décrit cela comme « une communication événementielle via HTTP », où le client, après avoir configuré le webhook, ne doit plus entreprendre d'action. Le serveur prend l'initiative et veille à ce que l'information soit transmise « as it happens ». Cela rend les webhooks idéaux pour les applications qui nécessitent des mises à jour en temps réel, comme les systèmes de notification, les pipelines CI/CD ou les intégrations entre différentes plateformes SaaS.
Les webhooks constituent une forme de communication bidirectionnelle, ce qui les distingue du modèle REST classique. Alors que les API REST sont généralement unidirectionnelles — le client demande, le serveur répond — les webhooks offrent un canal par lequel le fournisseur d'API peut activement pousser des données vers le consommateur d'API. La page webhooks d'OpenAPI souligne cela en affirmant que les webhooks permettent des « bi-directional communications » en dehors du modèle REST habituel. Le consommateur s'inscrit ici au préalable en indiquant une URL de callback, après quoi le fournisseur peut y envoyer des requêtes HTTP lors d'événements pertinents. Cette URL de callback est aussi appelée le « webhook endpoint », et est essentielle au fonctionnement du système.
Autodesk Platform Services décrit explicitement les webhooks comme une URL de callback qui est configurée au moment où un webhook est créé. Ce processus se fait généralement via un appel d'API où le développeur indique l'URL, le type d'événement et d'éventuelles données d'authentification. Une fois configuré, le webhook devient actif et le fournisseur réagit automatiquement aux événements définis. Ce modèle est aussi utilisé par GitHub, qui permet aux développeurs de réagir à des événements comme des pushes, des pull requests ou des issues dans un dépôt. Depuis le 30 juin 2021, GitHub offre en outre la possibilité de contrôler et de renvoyer les livraisons de webhooks de manière programmable via l'API REST, ce qui augmente la fiabilité et la facilité de débogage des webhooks.
L'essor des webhooks a conduit à une évolution des spécifications d'API. L'OpenAPI Specification, une norme pour décrire les API RESTful, n'a longtemps pas eu de prise en charge native des webhooks. Ce n'est qu'avec la version 3.1 en 2021 que les webhooks ont été officiellement ajoutés à la spécification. Auparavant, en 2017, OpenAPI avait déjà introduit les callbacks dans la version 3, ce qui constituait une première étape vers des modèles événementiels. L'ajout des webhooks en 2021 a marqué la reconnaissance du fait que les API modernes ne doivent pas seulement pouvoir pull, mais aussi push. Cette extension permet aux développeurs de documenter clairement les webhooks dans leurs spécifications d'API, y compris les événements possibles, les payloads et les méthodes HTTP.
L'utilisation des webhooks comporte toutefois aussi des défis. Comme le fournisseur envoie activement des requêtes vers un serveur géré par le consommateur, ce serveur doit être disponible et correctement configuré pour traiter les messages entrants. En outre, la sécurité est un aspect crucial : un point de terminaison de webhook peut constituer un vecteur d'attaque s'il n'est pas bien sécurisé. De nombreux fournisseurs utilisent donc une authentification via des jetons secrets ou des signatures pour vérifier qu'une requête de webhook provient effectivement de la source attendue. En outre, il est important que les consommateurs puissent tester leurs points de terminaison, les surveiller et résoudre les erreurs. La possibilité offerte par GitHub de contrôler et de renvoyer les livraisons de webhooks, comme annoncé dans le changelog du 30 juin 2021, est un exemple d'outil qui répond à ce besoin.
Le rôle des webhooks dans les écosystèmes d'API modernes continue de croître, y compris dans des secteurs où l'intégration rapide et l'automatisation sont essentielles. Shopify, une grande plateforme de commerce électronique, traite par exemple les webhooks dans le cadre de sa stratégie d'API. Bien que la source à ce sujet porte principalement sur la transition de la REST Admin API vers la GraphQL Admin API — l'API REST étant considérée comme « legacy » à partir du 1er octobre 2024 — il est clair que des modèles événementiels comme les webhooks subsistent en tant que partie de la nouvelle architecture. Cela montre que, tandis que les technologies évoluent, le principe sous-jacent de communication en temps réel via les webhooks conserve sa valeur.
La documentation autour des webhooks continue d'être activement maintenue. GitHub Docs, une source importante pour les développeurs, a mis à jour sa documentation sur les webhooks le 17 avril 2026. Cette mise à jour concerne spécifiquement les points de terminaison de l'API REST pour les webhooks, ce qui indique que le sujet reste actuel et pertinent dans le monde du développement. La continuité de cette documentation souligne l'importance d'informations claires et à jour sur la manière dont les webhooks doivent être configurés, sécurisés et utilisés.
En résumé, les webhooks sont devenus un élément fondamental des architectures d'API modernes, surtout en combinaison avec REST. Ils offrent une alternative efficace et événementielle au polling, permettant aux systèmes de communiquer plus rapidement et de manière plus économe. Introduits par Jeff Lindsay en 2006, ils ont évolué d'un modèle informel vers un élément standardisé des spécifications d'API comme OpenAPI. Des plateformes comme GitHub, Autodesk et Shopify les utilisent pour permettre des intégrations en temps réel, soutenues par des outils de surveillance, de renvoi et de sécurité. Tandis que la technologie continue de se développer, le principe de base reste le même : fournir des données au moment où elles se produisent, et non lorsqu'elles sont demandées.