Le choix entre webhooks et polling n’est pas une préférence technique. C’est une décision d’exploitation : à quelle vitesse le métier doit-il être prévenu, quel volume doit être absorbé et combien coûte un incident silencieux ?
Un webhook donne une réaction rapide, mais demande une réception robuste. Le polling donne du contrôle, mais consomme des quotas et peut rater les fenêtres critiques si la cadence est mal pensée.
Une intégration API fiable combine parfois les deux : webhook pour l’événement, polling de contrôle pour la réconciliation.
La décision doit être écrite par flux. Un paiement capturé, une commande marketplace, un stock critique et une mise à jour CRM n’ont pas le même coût de retard ni la même tolérance à la perte d’événement.
La bonne question
Il ne faut pas demander “webhook ou polling ?”. Il faut demander “quel retard maximal le métier peut accepter sans perdre argent, confiance ou temps support ?”.
Partir du risque métier
Une commande payée, un stock critique, une facture validée ou un statut marketplace n’ont pas le même niveau d’urgence. Le choix d’architecture doit partir de cette criticité.
Si un retard crée une rupture de stock, une double expédition ou une mauvaise promesse client, l’événement doit être traité comme prioritaire.
Quand les webhooks gagnent
Les webhooks sont adaptés quand un changement doit déclencher une action rapide : commande créée, paiement confirmé, ticket support prioritaire, changement de statut vendeur.
Ils évitent d’interroger une API en boucle et réduisent la latence. En échange, ils imposent signature, validation, file d’attente, idempotence et stratégie de retry.
Quand le polling reste utile
Le polling reste pertinent quand la source ne propose pas de webhook fiable, quand l’API impose une logique d’extraction ou quand l’équipe doit comparer des états complets.
Il est aussi utile pour contrôler qu’aucun événement n’a été perdu. Un polling de vérification peut sauver un flux qui semble fonctionner mais dérive lentement.
Traduire le SLA en architecture
Un SLA de quelques secondes pousse vers webhook, file et workers. Un SLA de quelques heures peut accepter un batch ou un polling planifié.
Le SLA doit être écrit par type de flux, pas globalement. La commande, le stock, la facture et le lead commercial n’ont pas toujours la même urgence.
Mesurer volume et pics
Le volume moyen ne suffit pas. Il faut regarder les pics : soldes, campagnes, imports massifs, synchronisations post-maintenance, rattrapages après incident.
Un webhook peut créer un pic brutal côté réception. Un polling trop agressif peut saturer l’API source. Le design doit absorber la journée exceptionnelle.
Composer avec quotas et limites
Les APIs tierces imposent souvent des quotas, des fenêtres, des limites par endpoint ou par compte. Le polling peut les consommer très vite.
Une bonne stratégie priorise les flux money, espace les contrôles non critiques et ajuste la cadence selon l’état du run.
Sécuriser les rejouages
Un webhook peut être livré plusieurs fois. Un polling peut reprendre une période déjà traitée. Dans les deux cas, l’idempotence empêche les doublons de commande, paiement ou facture.
La clé d’idempotence doit être stable, métier et traçable. Elle permet de rejouer sans peur.
Prévoir la reprise
Le flux doit pouvoir repartir après une panne, un timeout, une réponse 429 ou une donnée invalide. La reprise doit être bornée par date, identifiant ou statut.
Sans reprise claire, l’équipe finit par faire des exports manuels, ce qui augmente le risque d’erreur et le coût support.
Piloter le run
Le run doit suivre latence, backlog, taux d’échec, retries, quotas consommés et écarts détectés. Le sujet n’est pas seulement de recevoir un événement, mais de savoir s’il a produit le bon état métier.
- Classer les flux par criticité.
- Définir un SLA par objet.
- Protéger les endpoints de réception.
- Rendre les traitements rejouables.
- Contrôler les écarts par polling ciblé.
Conclusion : choisir par coût d’incident
Webhooks et polling sont deux outils. Le bon choix dépend du coût d’un retard, du volume, des quotas et de la capacité de reprise.
Pour verrouiller les doublons, poursuivez avec l’idempotence API.
