Résumé

  • Le dossier stratégique 560 du W3C reste ouvert, présente WebMCP comme le changement substantiel de la charte Web Machine Learning et indique une fin d’affinement inconnue.
  • La pull request 829 ajoute l’intégration d’agents dans le navigateur, l’enregistrement d’outils JavaScript et des annotations déclaratives de formulaires HTML ; WebMCP y devient un livrable provisoire.
  • Le correctif ne change pas la liste des coordinations nommées, alors que le dossier lui-même demande l’examen d’acteurs HTML, ARIA, TAG, SING et Privacy.
  • WebKit s’y oppose et conteste le lieu de travail, Mozilla reste neutre, APA ne soutient pas le rapport actuel et la modélisation des menaces continue. Aucun de ces états n’est une décision du W3C.
  • Avant l’Advisory Committee Review, une matrice périmètre-responsable devrait relier chaque couche concernée à un rôle, un canal et un traitement, sans transformer l’examen en droit de veto.

Un ajout de périmètre, pas une décision acquise

Le dossier 560 a été ouvert le 9 juin 2026 et demeure en cours. Il ne donne aucune date attendue de fin d’affinement. La pull request 829 est elle aussi ouverte, non fusionnée et repose sur un unique commit du même jour. L’état vérifiable est donc celui d’un périmètre proposé. Il ne permet de dire ni que la charte a été approuvée, ni que WebMCP a été adopté, ni qu’une norme de navigateur avance déjà sur la voie Recommendation.

L’ampleur du changement est néanmoins lisible dans le diff. La charte active du Web Machine Learning Working Group est centrée sur l’inférence : API WebNN de bas niveau, accès aux accélérateurs de la plateforme et éventuel chargement de modèles. Le correctif passe d’une API Web à plusieurs et ajoute l’intégration native d’agents d’IA dans le navigateur.

Une branche serait impérative : une application pourrait enregistrer, modifier et retirer des fonctions JavaScript comme outils structurés, accompagnés de descriptions et d’entrées définies par schéma. L’autre serait déclarative : des éléments HTML, notamment des formulaires, recevraient des annotations qui rendent leurs actions découvrables par un agent. Le texte ajoute aussi la médiation du navigateur, l’autorisation de l’utilisateur, la frontière de même origine et l’activation directe de fonctions de page.

Le statut « tentative » garde des étapes utiles. Il faut encore des progrès d’incubation, l’intérêt de plusieurs implémenteurs et le consensus des participants avant qu’un document soit adopté comme travail de Recommendation. Mais ce statut ne réduit pas une extension de périmètre à une simple retouche éditoriale.

La liste des coordinations reste sur l’ancien dessin

Le correctif modifie le périmètre et les livrables provisoires. Il ne touche pas la section des coordinations techniques supplémentaires. Le projet public continue de citer le Web Machine Learning Community Group, le GPU for the Web Working Group, le WebAssembly Community Group, le WebRTC Working Group et le TAG. À l’extérieur du W3C, il cite ECMA TC39.

Un paragraphe général impose par ailleurs des examens horizontaux en accessibilité, internationalisation, vie privée, sécurité et architecture. Cette obligation est réelle et interdit de prétendre que le texte ignore toute revue. Mais une revue horizontale et une dépendance nommée ne remplissent pas la même fonction.

Le réviseur horizontal vérifie un document au regard d’exigences transversales. Une entrée de dépendance peut identifier la couche qui appartient à un autre groupe, la pièce concernée et le mécanisme de communication. Coauteur, responsable d’une spécification, groupe consulté et réviseur ne disposent pas de la même autorité. Dès que le projet cartographie des actions sur des formulaires HTML et touche aux sémantiques ARIA ou à l’arbre d’accessibilité, ces rôles devraient être séparés.

Le dossier stratégique connaît déjà les acteurs : il demande des contributions de HTML, ARIA, TAG, SING et Privacy. L’écart est donc documentaire. Le réseau de revue apparaît dans le dossier et dans les commentaires, mais le diff qui accorderait le périmètre ne le transforme pas encore en carte de responsabilités et de communication.

Ne pas fabriquer une « opinion de la communauté »

Les avis publics décrivent quatre états distincts. Les additionner ou les moyenner effacerait l’information.

WebKit a enregistré une opposition. Son analyse critique une surface parallèle pour les agents, rattache certaines lacunes aux couches communes HTML et accessibilité, et estime que le lieu Machine Learning n’est pas approprié pour décider de leur évolution. Un représentant d’Apple a ensuite averti, dans la pull request de charte, qu’une objection formelle était attendue si le correctif était fusionné. C’est une objection majeure et attribuable. Ce n’est ni un veto ni la preuve que tout cas d’usage WebMCP est sans valeur.

Mozilla affiche une position neutre. Son analyse voit une abstraction potentiellement utile, mais aussi des risques, une dénomination trompeuse et trop de questions ouvertes. Les commentaires de fin août montrent que les discussions se poursuivent sur les variantes impérative et déclarative. La neutralité n’est pas un soutien d’implémenteur ; elle n’est pas non plus une opposition.

Le commentaire du 27 août de l’Accessible Platform Architectures Working Group est plus ciblé. Ses participants voient un potentiel expérimental pour de nouvelles technologies d’assistance, mais ne soutiennent pas le rapport du Community Group dans sa forme actuelle. Ils refusent de confondre les informations WebMCP et l’arbre d’accessibilité, craignent un écart entre ce que voient les humains et les agents, et demandent comment une personne découvre, examine, approuve, annule ou défait une action. Ils considèrent la voie déclarative comme un meilleur point de départ, tout en la gardant expérimentale.

Le travail de sécurité se situe ailleurs. Les minutes de juillet décrivent encore la construction d’un modèle de menaces : types d’agents, contenus d’outils, exposition inter-origines, visibilité de l’utilisateur et durée de vie des enregistrements. Elles ne contiennent ni approbation ni rejet final.

Une charte honnête conserve donc quatre lignes : opposition et argument de lieu ; position neutre d’un autre moteur ; non-soutien accessibilité assorti de propositions ; revue de sécurité en cours. Aucune ne doit se faire passer pour le consensus de l’autre.

Ce que le Processus exige de rendre attribuable

Le Processus du W3C demande qu’une charte précise sa mission, son périmètre et ses livrables. Elle doit identifier les dépendances vers et depuis les autres groupes. Lorsque des groupes dépendent de ses livrables, le mécanisme de communication doit être explicite. Avant la revue par l’Advisory Committee, l’examen large doit être achevé et les problèmes déposés contre le projet doivent recevoir une réponse substantielle, avec une disposition qui signale les objections persistantes.

Cette règle ne donne pas un veto à chaque acteur touché. Une liste de coordination ne doit pas devenir une assemblée d’unanimité. Elle permet de savoir qui détient quelle couche, où la discussion se déroule et qui répond de la décision finale.

L’exigence devient décisive quand la portée change. L’ajout d’un livrable Recommendation-track hors de l’ancien périmètre est un changement majeur. Le passage d’une API d’inférence à des outils d’agents, des formulaires HTML et une médiation par le navigateur mérite donc une attribution au niveau du diff.

La charte active reste en vigueur jusqu’au 30 avril 2027. Elle continue d’autoriser WebNN et les travaux d’inférence. La proposition n’annule pas ce mandat et n’en crée pas encore un nouveau. La carte recommandée décrirait le passage éventuel sans anticiper sa décision.

Une matrice périmètre-responsable

Une annexe publique compacte pourrait comporter, pour chaque surface normative :

  • la révision de charte et le patch immuable examinés ;
  • la fonction concernée, par exemple l’enregistrement impératif ou les annotations de formulaires ;
  • la couche touchée : exécution du navigateur, HTML, sémantique d’accessibilité ou sécurité des agents ;
  • l’autorité proposée au Web Machine Learning Working Group ;
  • l’organisme dépendant, responsable, de liaison ou de revue ;
  • son rôle exact : copropriétaire, dépendance, groupe consulté ou réviseur ;
  • le canal public de communication et la demande de revue ;
  • la réponse, l’objection non résolue et son motif ;
  • le déclencheur d’adoption, de transfert ou de réduction du périmètre ;
  • l’état du document et de la politique de brevets ;
  • le prochain acteur responsable et la date de vérification.

La ligne des formulaires déclaratifs pourrait identifier la couche HTML et les organismes dont les spécifications ou mandats d’examen sont touchés, sans prétendre qu’ils coéditent tous WebMCP. La ligne accessibilité séparerait la responsabilité de l’ARIA ou de l’arbre d’accessibilité du rôle horizontal d’APA. La ligne sécurité afficherait « modèle de menaces en cours » plutôt qu’une coche verte. Les positions des moteurs resteraient distinctes du consensus du Working Group et de l’approbation du W3C.

Cette matrice ne décide pas si WebMCP doit rester dans Web Machine Learning, passer à un nouveau groupe, être réparti entre plusieurs lieux ou demeurer en incubation. Elle empêche le mot général « coordination » de masquer cette décision.

La discipline de spécification minimale de Heng Lu fixe la limite : le registre commun ne doit contenir que les jointures nécessaires, et les choix futurs restent chez les acteurs qui les possèdent. Ici, la matrice éviterait qu’un groupe hérite silencieusement de couches adjacentes sans construire une bureaucratie plus épaisse que le problème.

Ce que les pièces ne prouvent pas

L’absence de groupes nommés dans la liste ne prouve pas l’absence de rencontres ou d’échanges privés. L’opposition d’Apple n’est pas un rejet du W3C. La neutralité de Mozilla n’est pas un consensus d’implémentation. Le commentaire d’APA ne ferme pas toute conception future, et les minutes de sécurité ne démontrent pas un danger établi.

WebMCP reste un rapport de Community Group. La pull request reste ouverte. Le livrable serait provisoire, puis soumis à des preuves d’incubation, à l’intérêt de plusieurs implémenteurs et au consensus du groupe. L’Advisory Committee Review, la décision de charte, l’adoption d’un Working Draft, l’interopérabilité et la Recommendation sont encore des états séparés.

Le fait de gouvernance est plus étroit : un diff ouvert ajouterait à un Working Group des surfaces qui nomment HTML et les agents de navigateur, sans mettre à jour sa liste d’interlocuteurs nommés. La revue publique rend désormais les acteurs et les questions visibles. Il reste à attribuer les rôles et les traitements avant que le périmètre ne devienne mandat.

Sources

  1. W3C Strategy — dossier 560 sur la charte Web Machine Learning
  2. W3C charter-drafts — pull request 829
  3. W3C charter-drafts — commit ajoutant WebMCP
  4. W3C — projet public de charte Web Machine Learning
  5. Processus du W3C — contenu d’une charte
  6. W3C — charte Web Machine Learning active
  7. WebKit — position sur WebMCP
  8. Mozilla — position sur WebMCP
  9. WebMCP, dossier 65 — examen accessibilité d’APA
  10. W3C Security Interest Group — minutes du modèle de menaces WebMCP
  11. Web Machine Learning Community Group — rapport WebMCP
  12. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption