Résumé

  • Dans un projet individuel de l’IETF, la recommandation d’un agent ne devient une décision de l’entreprise que si un sujet autorisé l’adopte selon une règle explicite. Un jeton valide permet de franchir une porte technique; il ne vote pas à la place de l’entreprise.
  • Le texte exige aussi que délégation, contexte utile, responsable et nature des preuves survivent aux transferts entre agents. L’appel d’un outil, l’acte accompli et son résultat observé restent trois faits différents.

Une recommandation peut voyager sans son patron

Un agent propose de changer de fournisseur. Le suivant reçoit le dossier et prépare l’ordre. Un outil accuse réception. Le tableau de bord affiche un voyant vert. À ce stade, il est tentant de raconter une histoire d’une seule traite: l’entreprise a choisi, changé et gagné. Il manque pourtant la scène la plus importante. Qui a pris la décision au nom de l’entreprise, et selon quelle règle? Le projet individuel consacré au sens des délégations entre agents oblige à poser cette question avant de confondre la vitesse du circuit avec la légitimité de son résultat.

Ce fournisseur est un exemple de lecture, pas un dossier commercial réel. La fiche Datatracker de l’IETF date la version 00 du 19 octobre 2026 et la classe parmi les Internet-Drafts individuels. L’auteur présente des exigences sémantiques pour la délégation; il ne livre ni protocole nouveau ni déploiement mesuré. La question de fond dépasse la tuyauterie: une organisation peut reconnaître chaque machine de la chaîne sans savoir à quel moment elle s’est elle-même engagée.

Une permission d’infrastructure donne à un logiciel le droit d’appeler une interface. L’autorité de décider est autre chose. Le texte la définit par un but, une portée limitée et des exclusions. Chaque transfert doit conserver l’identité de celui qui délègue, le but de la tâche et les limites, tout en transmettant seulement une partie de son autorité. Une clé de salle de réunion ouvre la porte; elle ne fait pas de son porteur un administrateur. La distinction paraît presque moqueuse lorsqu’on la dit ainsi. Dans un réseau d’agents, la clé est souvent prise pour la délibération.

La recommandation est une proposition. La décision est un engagement adopté selon une règle par un acteur habilité. Lorsqu’un agent agit pour l’organisation, le projet demande une référence à cette décision, ou à une règle explicite dispensant d’une décision particulière. La recommandation ne peut tenir lieu de référence. Un simple « approuvé » dans la trace du second agent ne dit pas qui avait le droit de l’écrire. La bonne piste d’audit serait un nom ou une règle datée, puis une décision dont la portée correspond exactement à l’action suivante.

Si cette piste s’arrête à la phrase de la machine, l’entreprise n’a pas perdu un document: elle a perdu le moment de son propre choix. Si une règle permanente autorise certains achats ou changements, il faut la nommer, en montrer les bornes et rattacher chaque action à cette autorisation. Sinon, le vert du tableau de bord décrit l’état d’un outil, pas celui du mandat.

Le reçu de l’outil n’est pas le monde

Le projet sépare encore trois moments que les interfaces aiment regrouper. L’invocation d’un outil est une demande; l’action est une intervention qui a réellement eu lieu; le résultat est un changement constaté ensuite. Une action non autorisée reste une action et doit apparaître dans les archives. Sa réalité et sa légitimité sont deux questions distinctes. Un appel réussi ne prouve pas que le fournisseur a changé, et le récit de l’agent ne constitue pas à lui seul une preuve de l’action.

Les preuves doivent être classées selon leur origine: récit de l’agent, enregistrement de la plateforme ou du système d’exécution, élément vérifiable hors de cette chaîne. Cette séparation évite de demander au même narrateur d’être à la fois acteur et témoin indépendant. Dans les situations risquées, le texte refuse de tenir l’autodéclaration pour preuve suffisante. Le responsable de la chaîne doit pouvoir remonter de la décision vers l’ordre, puis vers l’effet observé, sans remplir les blancs avec une jolie phrase générée après coup.

Le contexte est l’autre pièce qui disparaît en voyage. Le premier agent sait peut-être que le fournisseur proposé ne vaut que pour une région et un trimestre. Le second reçoit un ordre bref avec un jeton valide. Le projet qualifie de matériel le contexte dont la perte change l’interprétation, l’autorisation ou le risque. Celui-là doit franchir le transfert. La confiance accordée au premier agent ne passe pas automatiquement au suivant: il faut justifier de nouveau ce sur quoi le destinataire peut s’appuyer.

Dernier garde-fou, l’histoire ne se réécrit pas. Une information découverte après la décision peut corriger la prochaine décision; elle ne doit pas embellir rétrospectivement ce que le décideur savait au moment d’agir. Le projet distingue ainsi la conformité de conception, visible dans les schémas, de la conformité opérationnelle, qui exige des traces authentiques d’un système en marche. À la fin, la trace doit montrer les transitions, pas seulement un certificat bien rangé.

Sources originales