Votre application doit réagir à un événement dans un système tiers. Un paiement confirmé chez Stripe, une commande créée dans un ERP, un ticket fermé dans un outil de support. Deux approches s'offrent à vous : aller chercher l'information régulièrement (polling), ou se faire notifier quand elle arrive (webhooks).
Le choix entre les deux n'est pas anodin. Il conditionne la latence de vos intégrations, la charge sur vos serveurs, la complexité de votre code et la fiabilité de l'ensemble. Cet article décortique les deux modèles, leurs forces, leurs faiblesses, et les architectures qui en tirent le meilleur.
Le polling : interroger périodiquement
Le polling est le modèle le plus intuitif. Votre application envoie une requête à intervalles réguliers pour vérifier si quelque chose a changé. Toutes les 30 secondes, toutes les minutes, toutes les heures — selon la fraîcheur requise.
Concrètement, un cron ou un scheduler
déclenche un appel GET /orders?updated_since=2024-01-01T12:00:00Z.
S'il y a des nouveautés, on les traite.
Sinon, on attend le prochain cycle.
Les avantages
- Simplicité d'implémentation — un script, un cron, une requête HTTP. Pas besoin d'exposer un endpoint public, pas de configuration réseau particulière
- Prévisibilité — vous contrôlez la fréquence, le volume et le moment des appels. Pas de surprise, pas de pic de charge inattendu
- Pas de dépendance réseau entrante — votre application initie toutes les connexions. Pas de firewall à ouvrir, pas de reverse proxy à configurer, pas de certificat TLS à exposer
- Tolérance aux pannes — si le service distant est temporairement indisponible, le prochain cycle rattrapera les données manquées
Les inconvénients
- Latence incompressible — entre deux cycles, les événements s'accumulent sans être traités. Avec un polling toutes les 5 minutes, la latence moyenne est de 2,5 minutes. Pour certains cas d'usage, c'est inacceptable
- Charge réseau et serveur — la majorité des requêtes ne ramènent rien de nouveau. Sur une API externe avec rate limiting, vous gaspillez votre quota. Sur votre propre infrastructure, vous consommez des ressources pour des réponses vides
- Scalabilité limitée — quand le nombre de sources à surveiller augmente, le nombre de requêtes de polling explose proportionnellement
Les webhooks : notification push
Les webhooks inversent le modèle. Au lieu d'aller
chercher l'information, c'est le système source
qui vous la pousse. Quand un événement se produit,
une requête HTTP POST est envoyée
vers une URL que vous avez enregistrée au préalable.
C'est le modèle adopté par Stripe, GitHub, Slack, Shopify et la plupart des plateformes modernes. L'événement arrive en temps réel, avec son payload complet ou un identifiant permettant de récupérer les détails.
Les avantages
- Temps réel — l'événement est traité dès qu'il se produit. Pas d'attente, pas de latence artificielle
- Économie de ressources — pas de requêtes inutiles. Votre serveur ne travaille que quand il y a quelque chose à traiter
- Découplage temporel — le système source notifie et passe à autre chose. Le traitement est asynchrone par nature
Les inconvénients
- Complexité de réception — il faut exposer un endpoint public, sécurisé, disponible, capable de traiter les requêtes entrantes rapidement et de manière idempotente
- Sécurité — n'importe qui peut envoyer une requête POST à votre endpoint de webhook. Sans validation de signature, vous acceptez des données potentiellement falsifiées
- Fiabilité — si votre serveur est down au moment de la notification, l'événement est perdu. Les systèmes sérieux implémentent des retries, mais tous ne le font pas, et les politiques de retry varient considérablement
- Debugging complexe — quand un webhook ne fonctionne pas, le problème peut venir du réseau, du firewall, du certificat TLS, de la validation de signature, du format du payload ou du traitement métier. Le diagnostic est rarement immédiat
Comparaison sur six critères
- Latence — le polling introduit une latence proportionnelle à l'intervalle. Les webhooks offrent une latence proche de zéro, limitée uniquement par le temps de transit réseau
- Charge serveur — le polling consomme des ressources à chaque cycle, même sans données. Les webhooks ne sollicitent votre serveur que lors d'un événement réel
- Fiabilité — le polling est naturellement résilient : le prochain cycle compense les échecs. Les webhooks dépendent des mécanismes de retry du système source, qui ne sont pas toujours fiables
- Complexité — le polling est trivial à implémenter. Les webhooks nécessitent un endpoint public, une validation de signature, un traitement asynchrone et une gestion d'idempotence
- Sécurité — le polling n'expose rien. Les webhooks exposent un endpoint qui doit être protégé contre les requêtes frauduleuses
-
Debugging — le polling est transparent :
vous voyez les requêtes et les réponses.
Les webhooks nécessitent des logs détaillés
et souvent un tunnel de développement
(
ngrok,localtunnel) pour tester en local
Architecture d'un récepteur de webhooks robuste
Si vous optez pour les webhooks — et dans la majorité des cas, c'est la bonne décision — la qualité du récepteur détermine la fiabilité de l'intégration. Voici les composants essentiels.
Endpoint dédié
Créez un endpoint spécifique par source de webhooks.
/webhooks/stripe, /webhooks/github.
Pas un endpoint générique qui tente de deviner
la provenance. Chaque source a son format de payload,
sa méthode de signature, ses headers spécifiques.
Validation de la signature HMAC
Avant tout traitement, vérifiez la signature
du webhook. La plupart des fournisseurs signent
le payload avec un secret partagé via HMAC-SHA256.
Le header contient la signature, votre serveur
recalcule le hash et compare. Si ça ne correspond pas,
rejetez la requête avec un 401.
C'est la seule protection fiable contre les requêtes frauduleuses. Sans validation de signature, votre endpoint est une porte ouverte.
Réponse immédiate, traitement asynchrone
Répondez 200 OK immédiatement
après validation de la signature. Stockez le payload
dans une file d'attente (RabbitMQ, Redis, base de données)
et traitez-le en arrière-plan. Si votre traitement
prend 10 secondes et que le fournisseur attend
un retour en 5, il va considérer la livraison
comme échouée et retenter.
Idempotence via identifiant unique
Les webhooks peuvent être livrés plusieurs fois. Un retry après timeout, un doublon réseau, un rejeu manuel. Chaque événement porte un identifiant unique (fourni par le système source). Stockez les identifiants traités et ignorez les doublons. Sans idempotence, un paiement peut être crédité deux fois, une commande traitée en double.
Retry avec backoff exponentiel
Quand votre traitement asynchrone échoue, ne retentez pas immédiatement. Utilisez un backoff exponentiel : 1 seconde, puis 2, puis 4, puis 8… avec un plafond. Ajoutez du jitter (variation aléatoire) pour éviter que tous les retries tombent au même moment.
Dead letter queue
Après un nombre défini de tentatives échouées (5 à 10 selon la criticité), déplacez le message dans une dead letter queue. C'est une file de secours où les événements non traitables sont conservés pour analyse manuelle. Sans DLQ, les messages en erreur bloquent la file principale ou disparaissent silencieusement.
Le polling intelligent
Le polling brut — une requête identique à intervalles fixes — est le cas le plus simple mais aussi le moins efficace. Plusieurs techniques permettent de l'optimiser significativement.
Long polling
Le long polling consiste à maintenir la connexion HTTP ouverte jusqu'à ce que le serveur ait des données à envoyer, ou jusqu'à un timeout. Le client reçoit la réponse dès qu'un événement se produit, puis rouvre immédiatement une connexion. C'est un compromis entre le polling classique et les webhooks, avec une latence quasi nulle mais sans nécessiter d'endpoint public.
Requêtes conditionnelles
Utilisez les headers ETag
et If-None-Match pour éviter
de retransférer des données inchangées.
Quand le serveur retourne un 304 Not Modified,
le coût réseau et le temps de traitement
sont négligeables.
Intervalle adaptatif
Au lieu d'un intervalle fixe, adaptez la fréquence au volume de changements. Beaucoup de nouveautés : réduisez l'intervalle. Plusieurs cycles sans données : augmentez-le progressivement. C'est un backoff exponentiel inversé, appliqué au polling lui-même.
Stratégie hybride
En production, l'approche la plus fiable combine les deux modèles. Les webhooks assurent le temps réel : chaque événement est traité dès sa réception. Le polling assure la réconciliation : un job périodique vérifie qu'aucun événement n'a été manqué.
Cette stratégie hybride couvre les cas où un webhook est perdu (serveur down, erreur réseau, bug dans le retry du fournisseur), où un événement est créé avant que le webhook ne soit configuré, ou où un traitement asynchrone échoue sans possibilité de rejeu.
Le polling de réconciliation tourne à basse fréquence — toutes les heures, voire une fois par jour — et compare l'état local avec l'état distant. Les écarts sont corrigés automatiquement. Le coût est minimal, mais la garantie de cohérence est maximale.
Exemple concret
Un système de facturation intégré à Stripe.
Les webhooks traitent les événements
invoice.paid et invoice.payment_failed
en temps réel. Un job de réconciliation
tourne toutes les 6 heures, liste les factures
Stripe des dernières 24 heures via l'API,
et vérifie que chacune a bien été traitée localement.
Les écarts sont signalés et corrigés.
Résultat : la latence normale est de quelques secondes (webhook). La latence maximale en cas de perte est de 6 heures (réconciliation). Aucun événement ne passe entre les mailles.
Choisir la bonne approche
Le choix dépend de votre contexte. Si le système source ne propose pas de webhooks, le polling est votre seule option. Si la latence n'est pas critique (synchronisation de catalogue quotidienne), le polling suffit et simplifie l'architecture. Si le temps réel est un requis métier (notification de paiement, alerte de sécurité), les webhooks sont incontournables.
Dans la majorité des intégrations professionnelles, la stratégie hybride est la réponse. Elle apporte le temps réel sans sacrifier la fiabilité. C'est plus de code au démarrage, mais infiniment moins de problèmes en production.
Chez x10, nous concevons des architectures d'intégration robustes, avec des récepteurs de webhooks sécurisés, des mécanismes de retry et des jobs de réconciliation. Besoin d'un accompagnement sur votre développement sur mesure ou votre architecture applicative ? Parlons-en.