Webhooks : le maillon faible de vos automatisations
Un webhook est une promesse : « je t'appelle quand quelque chose se produit ». Cette promesse n'a aucune garantie de livraison. Les automatisations qui l'ignorent finissent par perdre des événements — et personne ne le remarque avant longtemps.
Un webhook paraît simple : un système prévient un autre qu'un événement vient d'avoir lieu. Pas de polling, pas de délai, une intégration élégante. C'est ce qu'on lit dans la documentation. Ce qu'elle dit moins souvent, c'est que l'appel peut échouer, arriver deux fois, ou arriver dans le désordre.
Ces trois propriétés — perte, duplication, désordre — sont la norme sur les réseaux. Une automatisation qui ne les traite pas n'est pas fiable, même si elle fonctionne en démonstration.
Les trois défaillances à traiter
1. La perte
Si le destinataire est indisponible au moment de l'appel, l'émetteur peut abandonner. Sans mécanisme de reprise, l'événement est perdu. La solution est un accès à l'historique : le destinataire doit pouvoir interroger la source pour retrouver ce qu'il a manqué.
2. La duplication
Un émetteur qui ne reçoit pas de confirmation renvoie l'événement. Le destinataire le reçoit deux fois. Sans clé d'idempotence, le traitement est appliqué deux fois — un paiement, une facture, un e-mail.
3. Le désordre
Deux événements émis dans un ordre peuvent arriver dans l'autre. Un paiement traité avant sa facture produit une incohérence silencieuse.
Rejouez le même webhook deux fois, dans le désordre, et une fois avec le destinataire coupé. Si le résultat final est identique et unique, votre traitement est robuste. Sinon, il ne l'est pas.
Trois règles à poser
- Une clé d'idempotence par événement : le même événement traité deux fois doit produire le même résultat, une seule fois.
- Un journal des événements reçus : pouvoir constater ce qui est arrivé, quand, et ce qui a été fait.
- Une réconciliation périodique : comparer la source et le destinataire, et corriger les écarts.
Ce qu'il faut retenir
Le webhook est un canal, pas une garantie. Les automatisations qui tiennent ne sont pas celles qui ont le plus d'intégrations : ce sont celles qui ont prévu la perte, la duplication et le désordre. Ce sont trois lignes de conception qui évitent des semaines d'incidents.
« Un événement qui n'arrive qu'une fois sur deux n'est pas un événement. C'est une probabilité. »