Webhooks ou polling : comment concevoir des intégrations fiables

Quand deux systèmes doivent être informés de ce qui se passe chez l'autre (un paiement confirmé, une commande expédiée, un changement de stock), il y a deux façons de faire.

Webhooks : être prévenu

Le système d'origine envoie une requête HTTP vers une de vos URL quand quelque chose se produit. C'est immédiat et efficace. Les passerelles de paiement l'utilisent (Stripe, Redsys avec sa notification), comme de nombreuses plateformes.

Polling : demander régulièrement

Votre système demande périodiquement « y a-t-il du nouveau depuis la dernière fois ? ». Plus simple et plus robuste face aux pannes, mais avec du retard et plus de charge.

Comment fiabiliser un webhook

• Vérifiez la signature de chaque notification avec le secret partagé. N'acceptez jamais un « paiement confirmé » sans le vérifier.
• Répondez vite (200) et traitez ensuite. Si vous tardez, l'origine renvoie la notification et vous recevrez des doublons.
• Idempotence : enregistrez l'identifiant de chaque événement et ne le traitez pas deux fois.
• Ne dépendez pas uniquement du webhook : un processus de rapprochement périodique rattrape ce qui a pu se perdre.

// Schéma d'un récepteur idempotent
$evento = verificarFirma(file_get_contents('php://input'), $cabecera, $secreto);
if (yaProcesado($evento['id'])) {
    http_response_code(200);
    exit;
}
encolar($evento);
marcarProcesado($evento['id']);
http_response_code(200);

Le meilleur des deux

Dans les intégrations critiques, nous utilisons les deux : le webhook pour l'immédiateté et un polling toutes les heures qui compare et corrige. Ainsi, si une notification se perd, l'écart dure une heure au maximum.