Le client appuie deux fois. Le réseau coupe après la réservation. L'automatisation ne reçoit pas la confirmation et réessaie. Trois situations normales qui créent deux rendez-vous sans protection.
Une intention reçoit un identifiant stable
Créez un ID unique pour l'opération. Si la même commande revient, le système cible vérifie cet ID et renvoie le résultat existant au lieu de recommencer.
| Action | Mauvaise clé | Meilleure clé |
|---|---|---|
| Rendez-vous | Nom | ID de demande plus créneau |
| Facture | Montant | ID de commande plus type |
| Destinataire | Dossier plus type de message |
Ce n'est pas au modèle de le garantir
Reconnaître une même opération relève d'une règle métier. L'agent extrait les champs; le code attribue la clé et le système cible l'impose. La correction financière ne doit pas dépendre d'une interprétation probabiliste.
- Créer la clé avant la première écriture externe.
- Enregistrer le résultat sous cette clé.
- Journaliser les répétitions.
- Si le statut est incertain, vérifier avant de renvoyer.
Le mode dégradé a besoin de cette protection. Le rapprochement vérifie ensuite les deux systèmes.
Sources
FAQ
Qu'est-ce que l'idempotence?
Répéter la même demande ne déclenche pas deux fois le même effet.
Évite-t-elle tous les doublons?
Seulement si tous les chemins d'écriture appliquent une clé stable.
L'e-mail peut-il servir de clé?
Généralement non, car une personne peut créer plusieurs opérations légitimes.
Où contrôler la clé?
Au plus près du système qui exécute ou enregistre l'action finale.