Webhook / Polling

Définition

Webhook et polling sont les deux modèles classiques pour informer un client d'un changement d'état côté serveur (paiement réglé, virement reçu, document signé).

• Webhook (push) : le serveur envoie une requête HTTP au client dès qu'un événement se produit.
• Polling (pull) : le client interroge périodiquement le serveur pour voir s'il y a du nouveau.

Le choix est structurant pour toute intégration d'API fintech, avec des implications majeures sur la latence, la fiabilité, la complexité et le coût.

Modèle webhook

Latence faible, charge minimale (un message par événement), mais complexité côté client (endpoint public, signature, retry, idempotence) et endpoint à maintenir disponible 24/7.

Modèle polling

Latence moyenne (N secondes), charge élevée (N requêtes par minute et par ressource), mais complexité client faible (un simple GET) et aucun endpoint à exposer.

Comparaison détaillée

Cas d'usage fintech

• Webhook (préféré) : Stripe, Adyen, Mollie (notifications paiement), Bridge, Tink, TrueLayer (PIS), DocuSign, Yousign (signature), Sumsub, Onfido (KYC).
• Polling : apps mobiles sans backend, ou événement urgent et fréquent (statut blockchain) — rare en production.

Bonnes pratiques webhook

• Sécurité : toujours vérifier la signature (HMAC ou RFC 9421), HTTPS, IP allowlisting, vérification du timestamp (anti-replay).
• Fiabilité : retry exponentiel côté serveur, idempotency key côté client (traiter chaque événement une seule fois), ACK 2xx rapide (sinon mise en queue asynchrone), ordre non garanti.
• Observabilité : logger tous les webhooks, monitorer le taux d'erreur et la latence d'ACK, alerter sur les retries (outils : Hookdeck, Svix).

Bonnes pratiques polling

Backoff exponentiel (ne pas marteler chaque seconde), ETag / If-None-Match (304 si rien ne change), long polling (le serveur tient la connexion jusqu'à 30 s) et pagination par cursor depuis le dernier checkpoint.

Webhook + polling = le meilleur des deux

Beaucoup de fintechs proposent les deux : le webhook comme canal principal, le polling en fallback, et une réconciliation périodique (GET) pour s'assurer qu'aucun événement n'a été manqué. Stripe, Bridge et Adyen recommandent ce pattern hybride.

Alternatives modernes

Server-Sent Events (push one-way), WebSockets (full-duplex, temps réel intensif), gRPC streaming, et MQTT/AMQP/Kafka pour le très haut volume. Les webhooks restent dominants en fintech car simples, REST-compatibles et universellement supportés.

Ce que webhook / polling n'est pas

• Pas un protocole : ce sont des patterns sur HTTP, pas des standards formels.
• Webhook n'est pas un callback : le callback est inline dans une requête, le webhook un appel autonome.
• Polling n'est pas du retry : le polling est régulier, le retry survient en cas d'échec.
• Pas une garantie exactly-once en soi : il faut webhook + idempotence + checkpoint en base.

Dans l'écosystème PSD2 / Open Finance

• PIS : Berlin Group propose une notification_url (webhook) pour signaler la fin d'un paiement.
• AIS : peu de webhooks (les ASPSP poussent rarement), d'où un modèle plutôt polling pour rafraîchir.
• DSP3 / FIDA : devraient standardiser les webhooks (consentement, partage de données).
• VoP : synchrone (request/response).
• Wero / SCT Inst : push notification mobile, proche du modèle webhook côté app.

Exemples concrets

• Stripe : webhooks pour ~200 types d'événements (payment_intent.succeeded, charge.refunded), avec dashboard de configuration et simulation.
• Bridge : webhooks payment.completed, account.refreshed, consent.expiring, signés en HMAC SHA-256.
• Sumsub : webhook applicantReviewed à la fin du KYC.
• Outils : ngrok et RequestBin pour tester en local, Svix et Hookdeck en production.
• Coût : un acteur naïf qui poll 100 K clients toutes les 30 s génère 3,3 M de requêtes/heure — la migration vers le webhook réduit le coût de ~99 %.
• Exactly-once raté : créditer un client à chaque webhook sans idempotence aboutit, après retry, à un double crédit — toujours dédupliquer par event_id.