Une commande apparaît deux fois dans le logiciel de préparation, alors que le client n’a payé qu’une fois. Le problème peut venir d’un événement technique reçu plusieurs fois. Un webhook transmet une information à votre application ; il ne promet pas, par son seul nom, qu’elle arrivera une seule fois et dans l’ordre attendu.

Un accusé de réception peut se perdre

Imaginez un service qui annonce un paiement. Votre application reçoit l’événement, crée une commande, puis rencontre une interruption avant de confirmer la réception. Le service émetteur peut alors recommencer l’envoi. Ce comportement aide à ne pas perdre l’information, mais votre application doit savoir reconnaître qu’elle a déjà traité l’action.

La solution n’est pas de refuser toutes les tentatives répétées au hasard. Il faut distinguer un nouvel événement légitime d’une nouvelle livraison du même événement. Les fournisseurs exposent souvent un identifiant d’événement ; sa forme et ses garanties doivent être vérifiées dans leur documentation.

Enregistrer une décision, puis produire les effets

Une clé d’idempotence sert à reconnaître une opération qui ne doit pas être appliquée plusieurs fois. La logique métier peut, par exemple, identifier le paiement et la transition concernée. Le contrôle doit être suffisamment robuste pour deux livraisons presque simultanées : une simple lecture « la commande existe-t-elle ? » suivie d’une création peut laisser passer les deux demandes.

Le développeur doit donc expliquer où se trouve la protection contre cette concurrence. Une contrainte d’unicité ou un traitement transactionnel peut faire partie de la réponse, selon l’architecture. Il ne s’agit pas de choisir une recette universelle, mais de démontrer que deux traitements ne produiront pas deux effets commerciaux.

La commande n’est pas le seul effet à protéger.

L’email de confirmation, l’ordre d’expédition et l’ajout de points de fidélité peuvent eux aussi être répétés. Une intégration qui évite les doublons dans la base mais envoie trois emails au client reste imparfaite. Il faut dresser la liste des conséquences déclenchées par chaque événement.

La signature prouve autre chose

Vérifier la signature du webhook aide à confirmer l’origine et l’intégrité du message selon le mécanisme du fournisseur. Cela ne remplace pas la détection des répétitions : un message authentique peut être livré plusieurs fois.

Un système peut aussi recevoir des événements dans un ordre différent de celui imaginé. Une annonce tardive ne doit pas ramener une commande déjà expédiée dans un état ancien. Le traitement doit vérifier l’état métier et, si nécessaire, consulter la ressource actuelle chez le fournisseur.

Cette discipline complète la gestion des accès à un logiciel SaaS : une connexion autorisée doit également produire des changements contrôlés. L’authentification et la cohérence des effets répondent à deux questions distinctes.

Un scénario de recette à demander au prestataire

  • Envoyer deux fois exactement le même événement de démonstration.
  • Rejouer les deux livraisons presque simultanément.
  • Interrompre le traitement après la création, avant sa confirmation.
  • Contrôler les emails, les mouvements de stock et les commandes obtenues.

Le compte rendu doit montrer un résultat métier unique et une trace compréhensible des répétitions. Le journal peut indiquer « reçu à nouveau, déjà traité » sans transformer cela en panne.

Enfin, prévoyez la récupération d’un événement qui échoue réellement. Une file d’attente et une liste des traitements en erreur peuvent aider, à condition qu’une personne les surveille. Une relance manuelle doit respecter les mêmes protections que l’envoi initial. La robustesse se voit surtout quand le réseau cesse d’être parfaitement poli.