Résumé

  • L'IESG a approuvé la charte d'Agentproto le 8 octobre 2026. Le groupe vise l'adoption d'un projet sur les cas d'usage en décembre, puis celle de textes sur l'architecture et les protocoles en 2027.
  • Le projet de cas d'usage révisé le 15 octobre reste une contribution individuelle. Sa présence dans les documents associés au groupe ne constitue pas une adoption.

Confier une tâche à une IA ne revient pas à lui donner carte blanche pour toute la suite. Le problème apparaît dès que le travail dure : un agent peut encore être occupé alors que son droit d'agir doit être limité ou retiré. S'il passe lui-même une partie du travail à un autre service, savoir qui poursuit quoi devient aussi important que recevoir une réponse.

La charte approuvée d'Agentproto prend ces difficultés au sérieux. Elle distingue l'identité de l'agent de celle de l'utilisateur qui l'a mandaté, et prévoit de traiter la limitation des permissions et la révocation indépendante de ses accès. Ce sont des questions très concrètes derrière un intitulé de normalisation austère : garder le fil d'une tâche sans supposer que les mêmes droits valent indéfiniment.

Un projet déjà publié propose notamment le cas d'une tâche déléguée de longue durée avec une étape d'autorisation. Il évoque aussi la collaboration entre agents et l'accès à des outils par des intermédiaires. Ce sont des situations soumises à la discussion, pas des installations dont on aurait démontré le fonctionnement, ni des exigences déjà choisies par le groupe.

La différence est essentielle pour qui veut savoir ce qu'il pourra attendre de ces travaux. Il existe des propositions pour résoudre le problème. Il n'existe pas, dans les documents examinés, de décision faisant de ce projet la réponse commune d'Agentproto.

Garder le fil sans partager toute la mémoire

Une conversation peut survivre à une connexion. Elle peut aussi passer de la voix au texte ou continuer sur un autre appareil. Chaque service doit alors reconnaître les échanges qui vont ensemble. La continuité recherchée est celle du dialogue, pas celle d'un seul écran ou d'une seule session réseau.

Agentproto doit donc produire un protocole commun de gestion du dialogue et une architecture de référence. Le contexte désigne ici les identifiants et les états nécessaires au suivi. Il ne s'agit pas d'envoyer au service suivant toute la mémoire du modèle, ses documents retrouvés ou ses instructions. Reconnaître la même conversation n'impose pas de partager tout son contenu.

Cette limite évite de promettre un langage universel de la pensée artificielle. Le groupe ne doit ni inventer un nouveau transport ni remplacer les protocoles d'agents de la couche applicative. Il doit préciser comment le contexte passe sur des protocoles IETF existants. La mise en œuvre des modèles, leur raisonnement et leur planification, les interfaces utilisateur et la structure des données d'audit restent hors de son périmètre.

Le protocole ne prendra donc pas toutes les décisions de sécurité à la place des applications. Il doit leur permettre de maintenir les liens entre les échanges, y compris à travers des intermédiaires et des frontières de confiance. La présence d'un identifiant ne sera pas, à elle seule, une permission universelle.

Le mandat est acquis, les choix restent ouverts

Le calendrier fixe à décembre 2026 l'adoption d'un projet informatif sur les cas d'usage. Or la liste des documents associés affiche déjà Agentic AI Use Cases and Requirements, révision -04 du 15 octobre. Le fichier est arrivé avant l'échéance ; cela ne suffit pas à remplir celle-ci.

Sa fiche le classe toujours comme Internet-Draft individuel, sans filière RFC attribuée, et rappelle qu'une soumission individuelle n'est pas un soutien de l'IETF. Le champ du statut RFC envisagé y est vide, alors que le texte indique une visée informative. L'intention des auteurs est donc connue. La décision du groupe reste distincte.

L'historique de la charte situe son approbation par l'IESG au 8 octobre. Cette décision autorise le travail dans un périmètre donné. Elle n'approuve ni un projet particulier de cas d'usage ni un protocole futur.

Après décembre, le programme prévoit l'adoption d'un projet d'architecture informatif en février 2027, puis d'un ou plusieurs projets de protocole destinés à la normalisation en mars. Leur soumission à l'IESG comme propositions de normes est visée pour mars 2028. L'historique consigne aussi le passage à une formulation permettant plusieurs projets aux étapes ultérieures de protocole.

Ce sont des objectifs. La révision d'octobre indique que des auteurs travaillent ; elle ne permet pas de cocher à leur place le rendez-vous de décembre. Pour cela, il faudra une décision rattachée à un document et à une version. Un changement de calendrier serait une autre information, à conserver comme telle.

Pour l'utilisateur, l'enjeu final est de pouvoir laisser un travail avancer sans perdre la possibilité d'en limiter la suite. Pour Agentproto, la prochaine étape est plus modeste : choisir le document qui décrira les cas à traiter. Le fichier d'octobre rend la discussion possible ; il ne permet pas encore de promettre que les systèmes sauront tous poursuivre — ou interrompre — le bon dialogue.

Précision du 24 octobre 2026 : le champ de statut non renseigné dans Datatracker est distingué de l'intention informative explicitement indiquée dans le projet. Les échéances citées sont des objectifs ; la révision d'octobre demeure une contribution individuelle dans les documents examinés.