Summary

  • La version du 27 octobre d’un projet individuel présenté à l’IETF attribue une clé à chaque opération voulue par un agent. Une relance conserve cette clé ; un second paiement en reçoit une autre.
  • Dans son exemple, 300 livres sont déjà dépensées sur 500 et 120 sont réservées. La relance reste à 420 ; une nouvelle dépense de 120 ferait monter l’engagement à 540.

Le premier message est parti, mais sa réponse s’est perdue. L’agent renvoie donc « payer 120 livres ». Pour l’équipe qui tient le plafond, c’est une reprise : la somme est déjà réservée. Puis arrive un autre ordre « payer 120 livres », réellement voulu comme deuxième paiement. Même montant, mêmes paramètres, même empreinte du message. Le budget, lui, n’a pas le droit de faire semblant de ne voir qu’un seul achat.

C’est la faille que relève la nouvelle version du projet d’audit. La version précédente reconnaissait une reprise grâce à l’empreinte de la requête. Or cette empreinte décrit le contenu de l’action, ses arguments et la ressource visée. Deux paiements voulus séparément peuvent partager ces éléments. La révision du 27 octobre introduit decision.operationKey : une clé pour l’opération envisagée, inscrite dans la requête signée. Une tentative répétée garde sa clé ; une autre intention en prend une nouvelle.

Le registre de l’IETF classe toujours le texte parmi les projets individuels. Il ne décrit ni une règle entrée en vigueur ni un incident bancaire. Son exemple chiffré montre pourtant très bien le problème. Le plafond délégué est de 50 000 pence. Les paiements soldés ont consommé 30 000 pence. Une autorisation de 12 000 attend encore son résultat. Quand la même opération revient avec sa clé, le calcul reste à 42 000. Quand une seconde opération de 12 000 arrive, le calcul passe à 54 000 et sort du plafond.

La nouvelle clé n’est pas un simple numéro décoratif. Elle est liée au digest du document fixant le plafond. Chaque autorisation en attente figure dans une liste held avec sa clé, l’empreinte de sa requête et son montant ; ces montants doivent correspondre au total réservé. Le vérificateur peut ainsi recalculer withinLimit à partir du consommé, du réservé et de la nouvelle demande. Le texte antérieur laissait précisément la ressemblance entre les deux requêtes masquer leur différence comptable.

Une réponse perdue ne vide pas la colonne des réservations. L’autorisation y demeure jusqu’à ce qu’un enregistrement de la même opération confirme l’effet ou son absence. Le projet propose aussi de confronter les révisions successives de l’état : une décision prise sur une version trop ancienne peut avoir ignoré un montant déjà réservé. L’auditeur dispose alors d’une histoire à vérifier, jusque dans les ratés. Un permis accordé au-delà du plafond n’est pas effacé de la trace ; il reste un fait gênant, et utile.

La question de gouvernance dépasse la syntaxe. Dès qu’un agent peut engager l’argent d’autrui, « ce message ressemble au précédent » n’est pas une preuve suffisante de ce qui a été autorisé une seule fois.