Qu’est-ce qu’un webhook ? La différence entre API et webhooks
Un webhook envoie automatiquement une notification HTTP à un autre système lors d’un événement, par exemple un paiement terminé ou une nouvelle commande.
Que contient cet article ?
Un webhook envoie automatiquement une notification HTTP à un autre système lors d’un événement, par exemple un paiement terminé ou une nouvelle commande.
Ce modèle peut être plus rapide et économe en ressources que des interrogations API répétées à la recherche de changements.
Comment fonctionne un webhook ?
Le destinataire fournit une URL de callback. La source y envoie les données lors de l’événement.
Différence avec l’interrogation périodique d’une API
Avec le polling, le client interroge régulièrement le système. Avec un webhook, la source avertit le client lors d’un changement.
Charge utile Webhook
La charge utile peut contenir type d’événement, ID de ressource, horodatage et données associées. Une autre approche courante envoie l’ID et récupère les détails par API.
Vérification de signature
Un endpoint webhook étant accessible sur Internet, vérifiez que les requêtes viennent du prestataire attendu. Les signatures HMAC sont une méthode courante.
Mécanisme de nouvelles tentatives
Si le destinataire est temporairement indisponible, la source peut renvoyer le webhook. Documentez le nombre de tentatives et la stratégie de backoff.
Événements en double
Le même webhook peut venir plus d'une fois. Le traitement en double doit être évité à l'aide de l'identification d'événement ou de la clé d'affaires.
Utiliser des files d’attente
L’endpoint peut valider la charge et la mettre en file au lieu d’exécuter les traitements lourds pendant la requête. Cela permet un accusé de réception rapide.
Suivi Webhook
- Nombre d'événements échoués
- Nombre de nouvelles tentatives
- Latence de traitement
- Événement en double
- Échec de vérification de signature
- Tâches en attente dans la file
Liste de contrôle des intégrations en production
En production, il faut intégrer au fonctionnement opérationnel les éléments suivants : le fonctionnement des webhooks, les différences avec le polling et les charges utiles. Définissez pour chaque intégration les systèmes source et cible, le responsable des données, l’authentification, les correspondances et le responsable des erreurs. Un endpoint fonctionnel ne suffit pas s’il met à jour le mauvais enregistrement de produit, de client ou de commande.
Prévoyez en production les délais dépassés, limites de fréquence, coupures réseau temporaires, requêtes en double et réponses inattendues. Ne relancez que les échecs temporaires et utilisez l’idempotence lorsque répéter une opération peut avoir des effets financiers ou opérationnels. Une file d’attente découple les requêtes utilisateur des performances des services externes et permet de retraiter les tâches échouées de façon contrôlée.
Surveillez les résultats métier, pas seulement les codes HTTP. Une API peut renvoyer HTTP 200 sans qu’aucune commande n’arrive dans l’ERP. Affichez nombre de requêtes, taux d’erreur, latence P95, nouvelles tentatives, tâches en attente et dernière synchronisation réussie avec les volumes de commandes, stocks ou clients transférés. Les identifiants de corrélation et journaux structurés permettent de suivre une opération entre services lors d’un incident.
- Authentification et gestion des secrets
- Correspondance des données et validation des schémas
- Politique de délais d’expiration et de nouvelles tentatives
- Idempotence et contrôle des doublons
- Gestion des limites de fréquence des requêtes
- Journaux structurés et identifiants de corrélation
- Rapprochement des données métier
- Alerte et tableau de bord
Contrat API, mode de défaillance et cohérence des données
Ne concevez pas uniquement le parcours requête-réponse réussi. Établissez un contrat API clair pour les éléments suivants : le fonctionnement des webhooks, les différences avec le polling et les charges utiles. Précisez champs obligatoires, types, valeurs enum, authentification, délais, codes d’erreur et changements incompatibles. Définissez les réponses entraînant une nouvelle tentative, un arrêt ou une intervention humaine pour rendre le comportement plus prévisible.
Prévoyez, outre l’indisponibilité totale d’un service, les réponses lentes, données partielles, événements en double ou désordonnés, limites de fréquence et échecs temporaires d’authentification. Les nouvelles tentatives peuvent utiliser un backoff exponentiel et, si nécessaire, du jitter. L’idempotence ou des clés métier uniques réduisent les doublons lors du retraitement des commandes, paiements, stocks ou clients.
Une réponse API réussie ne suffit pas à établir la cohérence des données. Rapprochez périodiquement source et destination par nombre d’enregistrements, montant total, dernière synchronisation ou identifiant métier pour détecter les écarts. Journaux structurés, identifiants de corrélation et suivi centralisé des erreurs aident à localiser le service en échec. La connexion devient ainsi une composante opérationnelle vérifiable et durable.
- Validation des schémas de requête et de réponse
- Matrice des délais d’expiration et nouvelles tentatives
- Idempotence ou clés métier uniques
- Limites de fréquence et gestion des capacités
- Identifiants de corrélation et journalisation structurée
- Contrôles de rapprochement entre source et destination
- Politique de versionnement et de changements incompatibles
L’approche d’intégration de B10 Digital Agency
B10 Digital Agency aborde l’intégration comme une architecture système, au-delà de la connexion API : contrats de données, sécurité, nouvelles tentatives, files, observabilité, rapprochements et opérations sont conçus ensemble.
- Intégrations API et systèmes
- Logiciels sur mesure et applications mobiles
- Veille des marketplaces et suivi e-commerce
- Développement web et infrastructure sécurisée
Questions fréquentes
Webhook est en temps réel ?
La livraison est généralement proche de l’événement, mais réseau et nouvelles tentatives peuvent empêcher une garantie de temps réel absolu.
Avez-vous besoin d'une API pour Webhook ?
Pas toujours. Dans de nombreuses architectures, une API complète les webhooks pour récupérer les détails après l’événement.
Comment rendre Webhook sûr?
Utilisez TLS, vérification de signature, contrôle d’horodatage et autorisation adaptée.
Webhook peut venir deux fois ?
Oui. Le système destinataire doit donc être conçu pour un traitement idempotent.
Articles connexes
- Développement API-first : découpler le backend et rendre les applications multicanales
- CMS headless, GraphQL et Schema : bonnes pratiques pour le SEO et la structure des contenus
- Le web en temps réel : WebSockets, Server-Sent Events et Streams API
Combinez vos systèmes avec un flux de données fiable
Découvrez les intégrations API et systèmes de B10 Digital Agency pour planifier l’architecture reliant ERP, CRM, marketplaces, logiciels sur mesure et services tiers.
Sources et documents associés
Ces documents servent de références pour les méthodes et règles abordées dans cet article.
