Le pourcentage d’avancement d’AICP ne prédit ni le succès ni un arrêt sûr

Résumé

• Publié le 2 septembre 2026, draft-paxton-aicp-00 est un Internet-Draft individuel actif, sans approbation ni statut formel de l’IETF, sans flux RFC, Area Director responsable ou date de téléconférence.
• La progression proposée répertorie les étapes achevées, actives et totales ; elle peut ajouter un pourcentage. Les ensembles d’étapes font foi, le chiffre est indicatif.
• Le texte interdit d’assimiler ce pourcentage à une chance de réussite ou à une frontière d’annulation sûre.
• Phase et état des effets restent indépendants : une opération annulée ou échouée peut laisser des effets partiels, et l’annulation n’est qu’une requête idempotente exécutée au mieux.
• Avant d’arrêter ou de relancer une action conséquente, il faut un reçu séparé qui conserve étapes, phase, effets, état de l’annulation, observations manquantes et obligation de rapprochement.

L’illusion d’une distance restante

La fiche Datatracker présente Agent Infrastructure Control Protocol (AICP) comme la révision 00 d’un Internet-Draft individuel de Tihan-Nico Paxton, actualisé le 2 septembre 2026. La mention « Standards Track » figure comme statut visé par l’auteur ; elle ne constitue pas une approbation actuelle. Aucun flux RFC, aucun Area Director responsable et aucune téléconférence ne sont enregistrés. L’IETF rappelle que chacun peut soumettre un Internet-Draft et que ce document n’acquiert pas, par ce seul dépôt, de statut formel.

Le problème traité n’en est pas moins concret. Une interface de progression donne l’impression de mesurer une distance homogène : chaque pas aurait le même poids et le dernier segment séparerait simplement l’état présent de la réussite. Or une opération peut commencer par la seule étape irréversible, puis consacrer le reste du plan à des contrôles. Une autre peut effectuer quatre lectures sans effet avant une dernière écriture. À 20 % dans le premier cas et 80 % dans le second, le risque d’arrêt peut être exactement l’inverse de ce que suggère la jauge.

La version archivée évite de fabriquer une équivalence. La progression nomme les étapes terminées, les étapes actives et l’ensemble total. Ces listes sont la référence. Un pourcentage peut les accompagner, mais il est indicatif. Le draft ajoute deux interdictions sans ambiguïté : le chiffre n’est ni une probabilité de réussite ni une frontière d’annulation sûre.

Cette prudence laisse une question légitime : comment le pourcentage est-il calculé si les étapes se répètent, se sautent ou se découvrent en cours d’exécution ? La révision 00 ne transforme pas cette question en mesure des effets. En l’absence de règle reliant le nombre d’étapes à la gravité des changements, l’utilisateur ne doit pas inventer ce lien.

Une phase n’est pas un bilan des effets

AICP décrit la vie d’une Operation avec des phases telles que mise en file, attente d’approbation, exécution, vérification, pause, réussite, échec, annulation ou état indéterminé. Il conserve à côté un état des effets : aucun, possible, partiel, complet, inversé ou inconnu.

Cette séparation est structurante. Une opération peut échouer après avoir modifié une ressource. Elle peut être annulée alors qu’un appel extérieur a déjà été accepté. Elle peut réussir et déclarer néanmoins des effets secondaires. Le fournisseur doit réviser l’état des effets avec prudence ; un silence d’observation ne doit pas devenir artificiellement « aucun effet ».

Le résultat terminal suit la même logique. L’Outcome distingue les changements attendus de ceux qui ont été observés, documente les effets secondaires, les preuves et les suites à donner. Chaque critère peut être satisfait, non satisfait, inconnu ou non évalué. Le simple succès des appels vers une API fournisseur ne suffit pas à déclarer l’opération réussie.

Une barre unique écrase donc au moins quatre plans : la place dans le plan, la phase du cycle, la conséquence réelle et la qualité des observations. Dès qu’une couleur ou un nombre prétend les résumer, l’interface édicte une règle de décision qui ne vient pas du protocole.

L’annulation ne remonte pas le temps

Dans le draft, l’annulation possède sa propre identité de requête et doit être idempotente. Cette propriété empêche qu’une répétition réseau crée plusieurs demandes distinctes. Elle ne garantit pas que l’action principale s’arrêtera. L’exécution se fait au mieux ; une demande qui croise l’achèvement reçoit l’état actuel de l’Operation. La reprise après pause doit, elle, réexaminer autorité, contraintes et préconditions.

Le fournisseur doit publier la phase terminale et l’état des effets obtenus. Il ne doit surtout pas affirmer que cancelled signifie qu’aucun effet n’a eu lieu. Voilà pourquoi « annuler à 35 % » n’est pas une politique de sûreté. L’étape active peut déjà avoir engagé une modification, une étape terminée peut être la plus importante, ou l’observation peut manquer au moment où l’opérateur doit décider.

Inverser ou compenser un effet est encore une action conséquente. Elle réclame sa propre autorisation, peut échouer et peut produire des effets secondaires. Même reversed doit s’appuyer sur une observation du résultat compensatoire ; il ne promet pas le retour métaphysique à un monde identique.

La relance appelle la même retenue. Les effets possibles, partiels ou inconnus ne doivent pas déclencher aveuglément une nouvelle mutation. Le modèle de problème d’AICP peut indiquer si la répétition est sûre et si un rapprochement préalable est requis. Un délai dépassé ou une jauge peu avancée ne remplace pas cette information.

Instituer un reçu d’arrêt

Je propose qu’une décision d’arrêt conséquente produise un reçu différent de l’affichage de progression. Ce reçu n’appartient pas aux exigences de la révision 00 ; c’est une discipline de mise en œuvre destinée à conserver les distinctions que le draft a déjà faites.

Il identifierait l’Operation durable et sa dernière séquence, reproduirait les ensembles d’étapes achevées, actives et totales, puis afficherait séparément phase et état des effets. Il nommerait la requête d’annulation, son propre état, les observations encore attendues et l’obligation éventuelle de rapprochement avant toute relance ou compensation.

Le reçu garderait aussi le couple « attendu/observé ». Si une étape devait supprimer un accès, mais qu’aucune source indépendante n’a confirmé le résultat, la bonne formule est « suppression attendue, effet inconnu ». Elle est moins séduisante qu’un « annulé à 35 % », mais elle décrit ce que l’organisation sait réellement.

Le droit à des registres exacts formulé par Heng Lu fournit ici un repère : le registre décrit le réel, il ne le crée pas. Par analogie, un reçu ne doit pas créer une probabilité ou une sûreté que les observations ne montrent pas. Cette lecture est la mienne ; elle ne transforme pas l’essai de Heng Lu en règle de l’IETF.

Une grammaire à éprouver

La révision 00 comprend une boucle HTTP illustrée et des invariants de protocole. Je n’y ai trouvé aucune section Implementation Status. Les sources examinées n’établissent ni implémentation indépendante, ni déploiement en production, ni résultat d’interopérabilité, ni adoption par l’IETF. La description du parcours des RFC rappelle d’ailleurs qu’un Internet-Draft peut changer, expirer ou ne jamais devenir RFC.

La proposition mérite donc d’être jugée sur des essais capables de conserver ses cas inconfortables : 0 % avec effet possible ; 100 % avec critère non satisfait ; annulation avec effet partiel ; échec avec effet inconnu. L’objectif n’est pas que l’interface trouve toujours une réponse. Il est qu’elle sache afficher l’incertitude sans la convertir en un chiffre propre.

Sources

1. IETF Datatracker : Agent Infrastructure Control Protocol
2. Archive IETF : draft-paxton-aicp-00
3. IETF : présentation des Internet-Drafts
4. RFC Editor : comment sont créés les RFC
5. Heng Lu : The Bill of Rights of Uniqueness Coordination