Webhooks vs polling : deux systèmes en temps réel
Webhooks vs polling : pourquoi demander toutes les cinq minutes est du gaspillage, pourquoi la signature compte et que faire en cas de panne.
Deux systèmes qui doivent travailler ensemble ont deux possibilités. Soit le premier demande régulièrement — « du nouveau ? » —, soit le second se manifeste quand il y a du nouveau. Le premier s’appelle le polling, le second un webhook. La différence paraît technique et décide, en pratique, si une intégration tourne en silence ou réclame de l’attention tous les jours.
Pourquoi le polling est la moins bonne moitié
Avec le polling, votre système interroge à intervalles fixes. Toutes les cinq minutes, toutes les heures, chaque nuit. Cela a trois défauts désagréables.
C’est presque toujours pour rien : sur 288 appels par jour, une douzaine peut-être rapporte quelque chose. Les 276 autres consomment des appels qui comptent sur votre limite.
C’est quand même trop lent : demander toutes les cinq minutes, c’est apprendre les choses avec deux minutes et demie de retard en moyenne. Pour une commande qui part à l’entrepôt, c’est souvent sans conséquence. Pour un encaissement qui libère une livraison, non.
Et c’est fragile dans le détail : il faut se souvenir jusqu’où on a déjà lu. Si ce repère se décale — exécution interrompue, fuseau horaire calculé autrement —, des données manquent et personne ne le remarque.
Ce qu’est réellement un webhook
Un webhook est une adresse que vous enregistrez. Quand quelque chose se produit — un document est créé, une facture change d’état —, le logiciel envoie un message à cette adresse. Pas de question, pas de repère, pas de tours à vide.
Pour que cela tienne en production, il faut trois choses. À demander avant d’acheter.
1. Une signature, sinon on croit n’importe qui
Votre adresse de webhook est joignable depuis l’extérieur. Sans vérification, celui qui la connaît peut envoyer un message inventé — et votre système crée une commande inventée.
Chaque livraison est donc signée : l’expéditeur calcule une somme de contrôle à partir du contenu et d’un secret partagé, et l’envoie avec. Votre système refait le calcul. Si cela ne correspond pas, le message est écarté.
Un détail souvent absent : l’horodatage doit faire partie du contenu signé. Sinon, quelqu’un peut capter un message authentique et le renvoyer plus tard — la signature est toujours valable. Avec l’horodatage signé, la répétition se voit.
2. Des reprises qui s’espacent
Votre serveur sera un jour injoignable. Un redémarrage, un certificat, le réseau : cela arrive. La question est de savoir ce que fait l’expéditeur à ce moment-là.
Réessayer tout de suite ne sert à rien : ce qui redémarre n’est pas davantage là une seconde plus tard. Des intervalles croissants ont du sens — tout de suite, après 30 secondes, après 5 minutes, après une demi-heure, après deux heures. Cela couvre aussi bien le court redémarrage que la panne longue.
Et : une erreur dans votre requête (format incorrect, clé révoquée) n’est pas reprise. Envoyer cinq fois la même chose ne corrige pas un format : cela enterre seulement l’erreur réelle.
3. Une fin, quand plus personne n’écoute
Si une adresse cesse durablement de répondre, l’expéditeur doit finir par s’arrêter et le dire. Sinon les livraisons partent dans le vide jusqu’à ce que quelqu’un s’en aperçoive — souvent des semaines plus tard, quand des données manquent.
Chez Blina Desk, une adresse est suspendue après cinq livraisons épuisées d’affilée et doit être réactivée à la main. « Épuisée » signifie que toutes les reprises sont passées : un simple accroc ne suspend rien.
Ce que doit savoir faire le destinataire
L’autre côté a aussi ses devoirs, et deux sont régulièrement oubliés.
Répondre vite. Acceptez le message, accusez réception, et ensuite traitez-le. Qui calcule d’abord et répond ensuite tombe dans les délais dépassés et reçoit le même message une deuxième fois.
Supporter les doublons. C’est précisément pour cela que le même message peut arriver deux fois. Le destinataire doit l’encaisser sans créer la commande en double : chaque livraison porte un identifiant, et soit vous l’avez déjà vu, soit non.
La règle pratique
Prenez les webhooks pour tout ce qui doit se produire rapidement, et gardez un rapprochement nocturne comme filet en dessous. Le webhook tient les systèmes au même rythme ; le rapprochement rattrape ce qui est resté en route pendant une nuit à mauvaise connexion. Ensemble, ils font une intégration à laquelle on cesse de penser — et pour une intégration, c’est le plus beau compliment qui soit.