← Settlens

EXEMPLE FICTIF · FORMAT DE LIVRABLE

Un événement reçu deux fois. Deux tickets créés.

Ce rapport illustre le niveau de détail proposé. Il ne décrit aucune mission client et ses observations sont fictives. Les tests d’une mission réelle sont exécutés uniquement sur le périmètre convenu.

Périmètre de l’exemple

Workflow de démonstration : réception d’un webhook, résumé par un modèle, création d’un ticket dans un CRM de test. Aucun paiement ni donnée réelle.

Constat WF-01 · Doublon d’action métier

Impact envisagé : deux tickets pour une même demande, avec risque de traitement et de relance en double. Priorité à déterminer selon le volume et le processus du client.

Scénario de reproduction

  1. Choisir un identifiant d’événement inédit : demo-001.
  2. Transmettre deux fois simultanément le même événement au webhook du laboratoire.
  3. Attendre la fin des deux exécutions.
  4. Compter les tickets associés à cet identifiant dans le CRM de test.
{"event_id":"demo-001","type":"support.requested","customer":"client-fictif"}

Observation fictive : deux exécutions aboutissent et créent chacune un ticket. Résultat attendu : une seule action métier pour cet événement.

Correction proposée

Réserver atomiquement une clé d’idempotence durable liée à l’action. Utiliser également la clé d’idempotence du CRM s’il la prend en charge. Conserver l’état de traitement et l’identifiant distant. Si la réponse du CRM est perdue, réconcilier son état avant de relancer.

Une simple variable en mémoire ou un contrôle « existe déjà » suivi d’une écriture non atomique ne suffit pas en concurrence. Si l’API distante ne permet ni idempotence ni recherche fiable, isoler les cas incertains pour validation humaine.

Critères d’acceptation

ScénarioRésultat à vérifier
Deux requêtes simultanées identiquesUn seul ticket créé
Nouvel événement distinctUn nouveau ticket créé
Réponse perdue après créationRéconciliation avant nouvelle tentative
Échec définitifTrace exploitable et alerte prévue

Pièces jointes d’une mission réelle

Configuration testée, horodatage et traces expurgées, correctif convenu, tests de non-régression, résultats et procédure de retour arrière. Les résultats sont renseignés après exécution ; aucune couverture totale n’est présumée.

Vous reconnaissez ce risque ?

Décrire votre workflow →