IDEMPOTENCY

La propriété d'un traitement de produire le même résultat — sans effet secondaire — quel que soit le nombre d'exécutions avec une requête donnée.

Définition

L'idempotence (idempotency en anglais) est définie par la RFC 9110 (HTTP Semantics, juin 2022) comme : « a request method is considered idempotent if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request ».

En EDI, l'idempotence n'est pas garantie nativement : si un AS2 expéditeur ne reçoit pas son MDN signé dans son délai, il réémet le message. Si le destinataire avait bien traité la première copie mais que son MDN s'est perdu en retour, l'application reçoit deux fois la même commande — et risque de la doubler. Trois techniques courantes pour rendre une chaîne EDI idempotente :

1. Déduplication par identifiant : identifiant unique porté par le message (BGM en EDIFACT, BEG03 en X12, ID en UBL, Message-ID en MIME). Le destinataire maintient une table {`identifiant, premier traitement`} et rejette ou ignore les doublons.
2. Hash de contenu : calcul d'un hash SHA-256 du contenu canonicalisé. Deux messages identiques produisent le même hash, donc le destinataire reconnaît qu'il a déjà traité.
3. État de transition : l'opération métier ne devient effective qu'après un commit verrouillé par identifiant + état attendu. Une seconde transition tentée pour le même identifiant est rejetée.

Origine

Le terme « idempotent » vient des mathématiques (Benjamin Peirce, 1870) : une opération f est idempotente si f(f(x)) = f(x). Le concept est repris en informatique par les premiers protocoles distribués (CCITT X.25 dans les années 1970, RPC Sun ONC dans les années 1980), puis par HTTP/1.1 (RFC 2616, 1999) qui distingue formellement les méthodes idempotentes (GET, PUT, DELETE) des non-idempotentes (POST, PATCH). En EDI, l'idempotence devient une exigence d'industrialisation à mesure que les volumes augmentent et que les retransmissions automatiques se généralisent — typiquement, AS2 retry et OFTP2 restart-at-offset.

Exemple en contexte

Un fournisseur envoie un INVOIC à un client. Le client reçoit, traite, mais son MDN AS2 ne revient pas (timeout réseau). L'expéditeur AS2 réémet automatiquement après 60 minutes. Le client reçoit le même fichier une seconde fois. Si le système est idempotent — déduplication par le BGM/1004 (n° facture) couplé au DUNS du fournisseur — l'INVOIC n° F-2026-0512 est reconnu comme déjà reçu, un nouvel MDN signé est émis, mais aucune écriture comptable n'est dupliquée.

Termes liés

• Acknowledgement — l'élément qui déclenche les retries.
• MDN — l'accusé AS2 dont la perte cause les réémissions.
• Audit trail — la trace qui rend la déduplication auditable.
• BGM — porte l'identifiant naturel d'un message EDIFACT.