Résumé

  • Le 14 août, le groupe Devices and Sensors du W3C a proposé de retirer WebHID, Web NFC, WebUSB, Web Bluetooth et Web Serial d’une charte encore proposée. La consultation demandait de signaler toute préoccupation avant le 28 août.
  • Intel a répondu dans les délais qu’il avait des réserves sur le retrait des cinq API. Le 31 août, le coprésident a indiqué que des réserves avaient été formulées et que, par conséquent, le consensus n’était pas atteint.
  • Le Steering Group du WHATWG avait choisi une autre bifurcation : ouvrir son workstream avec les cinq spécifications s’il n’y avait pas d’objection à la CfC du W3C, et avec Web Serial seul dans le cas contraire.
  • Le 29 août, le WHATWG a fusionné la proposition à cinq spécifications. Le commentaire de fusion dit à la fois qu’aucune objection n’avait été reçue et que les réserves d’Intel étaient reconnues.
  • Un reçu de prédicat inter-organismes devrait publier la proposition de chaque côté, les mots de réponse admis, la règle de classement, l’échéance, l’auteur de la décision et l’effet produit, sans faire circuler l’autorité avec le lien.

Le point de départ n’était pas une norme approuvée

Le projet de charte Devices and Sensors porte toujours la mention [PROPOSED] au moment de cette enquête. Il ajoute cinq travaux périphériques à la rubrique des livrables éventuels : Web Bluetooth, Web Serial, WebUSB, Web NFC et WebHID. Tous sont présentés comme Draft Community Group Reports. Leur inscription aurait ouvert un espace de travail sur la Recommendation Track ; elle n’aurait pas validé leur architecture ni promis leur accession au statut de Recommendation.

Le 12 juin, le W3C a demandé un examen jusqu’au 17 juillet. Le message reconnaissait que certaines observations substantielles restaient sans résolution consensuelle. Une Formal Objection rendue publique le 23 juillet a demandé le retrait des cinq API. À défaut, elle réclamait une barrière explicite : répertorier les classes d’exploitation alléguées, définir des mesures normatives vérifiables, obtenir les revues horizontales et publier le traitement de chaque classe de risque.

Ces affirmations de sécurité restent celles de l’auteur de l’objection. Ni leur publication ni leur reprise dans la discussion ne les transforme en constat technique du W3C. Le fait vérifiable ici est la manière dont deux procédures ont utilisé les réactions suscitées par cette demande.

La Call for Consensus du 14 août visait un objet précis : résoudre la Formal Objection en supprimant les cinq noms de la charte. Elle invitait les participants à répondre avant le 28 août s’ils avaient « any concerns » et assimilait le silence au consentement. Le mot choisi n’était donc pas seulement objection ; la procédure sollicitait toute réserve sur le retrait.

La liste a conservé plusieurs degrés de désaccord

La réponse de Microsoft montre pourquoi une simple colonne oui/non aurait été trompeuse. Microsoft préférait conserver les livrables et traiter les risques documentés, mais annonçait qu’il ne bloquerait pas le consensus en faveur du retrait. L’existence du workstream WHATWG proposé faisait, selon ce message, du retrait un changement de lieu plutôt qu’un arrêt du travail. Le même texte rappelait qu’un livrable éventuel ne constituait ni une approbation du design actuel ni une garantie de Recommendation.

Will Morgan souhaitait, lui, un maintien conditionné à une revue du modèle de menace. Il suggérait un retrait suivi d’une réadoption si le workstream n’existait pas dans six mois. François Daoust a fixé la limite institutionnelle : une telle réadoption imposerait une nouvelle charte. La continuité éditoriale ne suffit pas à recréer une compétence de Recommendation Track.

Le 28 août, Anssi Kostiainen a écrit au nom d’Intel, en précisant qu’il retirait sa casquette de président. Intel avait des réserves sur le retrait de chacune des cinq API, principalement parce qu’il jugeait les revues larges et horizontales du W3C utiles à une adoption mondiale. Le message a été reçu à 12 h 24 UTC, pendant la date indiquée par la consultation.

Le 31 août, Kostiainen a ensuite clos la CfC comme coprésident. Des réserves avaient été formulées ; en conséquence, le consensus n’était pas atteint. Le texte ne désigne pas le message d’Intel comme cause unique. Il ne tranche pas non plus la Formal Objection, n’approuve pas la charte et ne certifie aucune API. Il remet la préparation de la suite à l’équipe du W3C.

Le statut correct est donc : pas de consensus sur la proposition de retrait. Ce n’est pas encore une décision définitive de maintien.

Le WHATWG avait déjà écrit sa propre condition

Le WHATWG ne décidait pas de la charte du W3C. Sa pull request 264, ouverte depuis avril, proposait un Peripheral APIs Workstream pour les cinq mêmes familles d’accès local. Le débat avait envisagé un périmètre limité à Web Serial, un périmètre complet, une coopération avec le W3C et la prise en charge de risques de sécurité.

Le procès-verbal du Steering Group du 25 août transforme ce débat en branche exécutable. Trois représentants sur quatre retiennent l’option 2 : démarrer le vendredi avec les cinq spécifications s’il n’existe aucune « objection à la CfC du W3C » ; sinon, démarrer avec Web Serial seulement.

Ce critère importait un résultat extérieur sans importer mot pour mot le questionnaire extérieur. La CfC du W3C demandait des concerns. La condition du WHATWG cherchait des objections. Rien n’obligeait les deux termes à produire le même effet, mais la liaison avait besoin d’une règle de correspondance.

Le 29 août, la pull request a été fusionnée. Son commentaire de clôture affirme qu’il n’y avait pas eu d’objection à la CfC avant la fin de journée, heure du Pacifique. Dans la même phrase, il reconnaît les réserves d’Intel. Le commit immuable 7eb413b ajoute à db.json le workstream Peripheral APIs et les cinq entrées WebBluetooth, WebHID, WebNFC, WebSerial et WebUSB.

Cette précision évite une fausse disparition de la réserve. Le WHATWG ne dit pas qu’Intel n’a rien signalé. Il dit que la condition formulée en termes d’objections est remplie malgré la réserve reconnue.

Le commentaire promet aussi d’ouvrir des issues pour ces préoccupations lors de la création du dépôt du workstream. Le commit prouve donc une modification du registre et un périmètre initial. Il ne prouve pas que tous les dépôts, issues, examens ou correctifs existent déjà.

Deux compétences peuvent produire deux états légitimes

La succession n’établit pas une violation. Le W3C avait compétence sur sa charte, ses participants et sa CfC. Le Steering Group du WHATWG avait compétence sur la naissance d’un workstream WHATWG. La Workstream Policy accorde en outre un sens propre aux objections substantielles de ses Workstream Participants ; une réserve envoyée sur une liste du W3C ne devient pas automatiquement cet objet formel.

La succession n’établit pas davantage un transfert d’autorité. L’absence de consensus du W3C n’autorise pas le workstream du WHATWG. La fusion du WHATWG ne résout pas la Formal Objection, ne modifie pas la charte du W3C et n’oblige aucun navigateur à implémenter les API.

Le problème est documentaire. Lorsqu’une institution B écrit « agir si aucune objection n’apparaît dans le processus A », elle doit dire comment elle classe les sorties réelles de A. Une réserve non bloquante vaut-elle objection ? Une réserve sans cette précision ? Un soutien demandant des modifications ? Une abstention ? Le silence ? Sans table publique, la décision reste peut-être régulière, mais son déclencheur ne peut pas être reproduit.

La discipline proposée par Lu Heng dans The Multi-Stakeholder Mirage est utile à cette échelle : une participation, un avertissement ou une objection apporte une preuve, pas l’autorité de l’organe qui décide. Intel n’ordonnait rien aux deux institutions. En revanche, chacune devait laisser voir l’usage fait de cette preuve.

Le contenu d’un reçu inter-organismes

Le reçu commencerait par l’objet amont : version exacte de la charte, proposition de retirer cinq livrables, message d’ouverture, canal admis, date de clôture et vocabulaire « any concerns ». Il conserverait ensuite chaque réponse dans sa nuance, avec son Message-ID, son heure et l’éventuelle mention « ne bloquera pas ».

Le résultat amont nommerait le coprésident, l’heure de clôture, la formule consensus was not reached, le motif annoncé et l’acteur compétent pour la suite. Une future charte serait liée comme événement successeur, sans effacer l’état du 31 août.

La partie aval reproduirait la branche du WHATWG : cinq spécifications s’il n’y a pas d’objection, Web Serial sinon. Elle préciserait le fuseau PDT, l’interprète du critère et la règle qui transforme ou non une concern du W3C en objection pour le WHATWG. Puis elle pointerait vers la pull request, le merge et le commit immuable.

Enfin, une ligne interdirait l’héritage implicite : aucune décision du W3C n’est une décision du WHATWG, et réciproquement. Le lien sert à l’audit, pas à fabriquer une autorité commune.

Limite des preuves

Au moment du relevé, la page publique du groupe W3C indiquait encore « Chartered until 31 August 2026 », tandis que la nouvelle charte restait proposée. Cette combinaison mérite une surveillance ; elle ne démontre ni la fermeture du groupe ni une décision finale dissimulée.

La controverse technique demeure également hors verdict. L’objection réclame des mesures précises ; d’autres participants pensent que le travail peut les produire dans l’un ou l’autre organisme. Créer un workstream n’est pas certifier la sécurité. Ne pas parvenir à un consensus de retrait n’est pas approuver la sécurité.

Le constat défendable tient en une phrase : le W3C a sollicité des réserves et a invoqué leur existence pour ne pas constater de consensus ; le WHATWG a sollicité l’absence d’objections pour sa propre branche, a reconnu une réserve d’Intel et a estimé sa condition remplie. La différence peut être légitime. Elle ne devrait pas rester implicite.

Sources