Résumé

  • Le 10 août, la Team de W3C a ouvert la phase de refinement d’un projet de charte de l’Immersive Web Working Group. Elle a orienté le débat public vers l’issue 564 et indiqué que les Membres pouvaient utiliser la liste confidentielle w3c-ac-forum.
  • La section 4.2 du Process exige que chaque issue déposée contre le projet soit formellement traitée et que sa résolution soit suivie dans un disposition of comments, en signalant les questions non réglées par consensus.
  • Le fil public offre déjà une chaîne observable : un commentaire de sécurité qualifié de bloquant, une réponse et la PR 862 ; des questions de l’APA, des réponses et la PR 865. Au 30 août, les deux PR restaient ouvertes et non fusionnées.
  • Les sections 7.2 et 7.3 protègent les informations réservées aux Membres. Elles permettent aussi à l’autorité compétente de rendre publique une version non attribuée qui communique raisonnablement l’information nécessaire sans rompre la confidentialité d’origine.
  • Un registre commun devrait contenir la classe de question, la section et la version examinées, la réponse, le diff public ou le motif de non-modification, l’état du consensus et la prochaine étape d’autorité. Il ne doit révéler ni identité, ni texte confidentiel, ni nombre de contributions susceptible de réidentifier un Membre.
  • Contribuer n’est pas voter. Les commentaires publics apportent expertise et preuves ; le consensus du refinement, une Team Decision, l’AC Review puis la W3C Decision restent des actes distincts.

Une asymétrie d’accès peut être saine

L’avis du 10 août ne dissimule pas l’architecture de participation. Il invite le public à discuter dans le dépôt Strategy et ouvre aux Membres un forum confidentiel. Il désigne le même Chartering Facilitator et situe approximativement la fin du refinement au 7 septembre. Les portes diffèrent, pas l’objet institutionnel.

Le dépôt public permet de citer une ligne, d’attacher un correctif et de conserver une conversation que l’extérieur peut contrôler. Le canal protégé peut accueillir des contraintes de déploiement non annoncées, des rapports contractuels ou une analyse dont l’attribution produirait elle-même un risque. Supprimer ce canal pourrait réduire la franchise sans améliorer la qualité de la décision.

Il serait donc erroné de déduire une manœuvre cachée de la seule existence d’une liste Member-only. Il serait tout aussi erroné de considérer GitHub comme une scène consultative sans effet. Le point de contrôle se situe après la réception des avis : comment les deux voies laissent-elles une trace cohérente dans l’histoire de la charte ?

Le bon raccord porte sur le statut, pas sur la matière brute. Un courriel peut rester confidentiel tandis qu’une fiche publique indique qu’une classe de problème a concerné une disposition déterminée, reçu une réponse autorisée et abouti à une modification, à un refus motivé ou à un état non résolu.

Le dossier public montre déjà plusieurs états

L’issue 564 n’est pas encore un rapport final. Elle permet néanmoins de voir ce qu’un registre devra éviter d’aplatir.

Lors de la revue de sécurité, un intervenant a relevé que la charte demandait des « sections » sur les implications de sécurité et de confidentialité, alors que le modèle en vigueur parlait de « sections séparées ». Il a explicitement qualifié son commentaire de bloquant et donné le critère de clôture. La réponse a reconnu l’écart et ouvert la PR 862. Le relecteur a alors précisé que la fusion de cette PR lèverait le blocage.

La suite comporte donc quatre étapes : observation, réponse, correction proposée et condition de clôture. À la date de référence, la PR était toujours ouverte. L’existence d’un patch ne permet pas d’écrire que le texte a été corrigé ; son existence interdit également d’affirmer que l’observation a été ignorée.

La revue d’accessibilité a pris une autre forme. L’APA a demandé des précisions sur le chevauchement entre détection de plans et de maillages, sur le calendrier WebGPU et le maintien de WebGL, ainsi que sur CSS Spatial Layout et les vibrations. Les réponses ont explicité des frontières et conduit à la PR 865. L’APA a reconnu que ces réponses traitaient ses premières questions, avant d’ouvrir une nouvelle interrogation sur la cohérence des termes « detection », « tracking » et « sensing ».

Résumer le tout par « avis favorable » ou « objection » ferait perdre l’information utile. Certaines demandes ont reçu une réponse, une modification restait à fusionner et une question terminologique subsistait.

Le compteur de quatorze commentaires n’apporte aucune mesure de légitimité. Un message peut contenir cinq questions ; plusieurs personnes peuvent travailler sur un même détail. Le silence peut être assentiment, abstention, ignorance du débat ou absence de compétence décisionnelle. Un registre sérieux compte les états, pas des voix imaginaires.

Le Process demande une résolution traçable

Le Process de W3C ordonne le chemin. Pour engager le refinement, la Team publie le projet, explique comment participer, annonce une durée d’au moins vingt-huit jours et nomme un facilitateur. La wide review est menée pendant cette période. Le Chartering Facilitator recherche le consensus entre les participants ; s’il n’en trouve pas, il peut demander une Team Decision, dont la motivation doit être documentée.

La règle décisive est ensuite très concrète : toutes les issues déposées contre le projet doivent être formellement traitées, et leurs résolutions suivies dans un disposition of comments qui met en évidence les points non résolus par consensus.

Cette exigence va au-delà de la preuve qu’une discussion a eu lieu. Elle relie la question à une réponse et à un état. Elle ne commande pourtant pas la publication de chaque phrase reçue. Les règles de confidentialité demeurent applicables.

Avant l’échéance annoncée, la Team doit lancer l’Advisory Committee Review, abandonner la proposition ou prolonger le refinement. La décision doit être annoncée selon la visibilité prescrite, avec une motivation lorsqu’elle n’ouvre pas l’AC Review.

Cette dernière est une phase autonome. Chaque organisation membre remet une seule review par son représentant AC. À ce stade, un dissent doit prendre la forme d’une Formal Objection. Un commentaire GitHub pendant le refinement n’est pas cette review, pas plus qu’une remarque confidentielle ne devient automatiquement une objection formelle ultérieure.

Publier un index sans divulguer le canal protégé

Le Process distingue les niveaux public, Member-only et Team-only. Les personnes habilitées doivent préserver le caractère confidentiel des données réservées. Reproduire un message, nommer son auteur ou donner assez de détails pour identifier son entreprise violerait la frontière que l’outil de gouvernance est censé respecter.

La section 7.3 évite toutefois que confidentialité signifie invisibilité totale. Pour les processus ayant une dimension publique importante, l’information qui pèse sur la décision peut devoir devenir publique. Seule la Team, ou une partie qu’elle autorise, peut changer le niveau. Faute de version fournie par l’auteur, elle peut produire un texte non attribué qui communique raisonnablement ce qui est requis tout en respectant le niveau initial.

Une ligne publique pourrait ainsi porter la mention : « Classe Member-only M-03 : frontière de périmètre d’un deliverable ». Elle indiquerait la section affectée, le commit examiné, l’existence éventuelle d’un changement public et la disposition. Elle omettrait le nom, le nombre de Membres, le produit concerné et toute citation du forum protégé.

Parfois, même la classe du problème suffit à reconnaître son auteur. Le registre doit alors se replier sur le plus petit état procédural publiable. L’agrégation n’est pas une magie qui supprime la réidentification.

Rien dans les sources examinées ne permet d’affirmer qu’un commentaire Member-only a effectivement été envoyé sur cette charte. L’annonce d’un canal ne prouve pas son utilisation. Le registre ne doit pas inventer une entrée confidentielle pour donner l’illusion d’être complet.

Expertise, participation et autorité ne se confondent pas

Le public peut apporter une information décisive. Le Process demande que les vues et objections légitimes venues des participants actifs ou d’autres acteurs, y compris le grand public, soient prises en considération. Un expert en accessibilité, sécurité, privacy ou architecture peut découvrir une ambiguïté qu’un cercle interne n’avait pas vue.

Cette contribution ne crée pas pour autant un mandat flottant. Une observation pèse par sa preuve, sa logique et les conséquences qu’elle révèle, non parce que son auteur reçoit l’étiquette de stakeholder.

Les rôles exécutables restent répartis. Le Facilitator évalue le consensus du refinement. La Team exerce les décisions prévues et détermine la suite. L’Advisory Committee conduit ensuite une revue formelle selon les droits de chaque Membre. Une W3C Decision conclut la phase institutionnelle.

Le registre doit donc répondre à deux questions différentes : quelle contribution est arrivée, lorsque sa source peut être rendue publique ; et quelle autorité a répondu puis fermé l’état. Cette séparation protège l’utilité de la consultation sans la transformer en souveraineté populaire fictive.

Le contenu minimal du registre commun

La couche partagée doit rester plus mince que les deux forums. Pour chaque issue ou classe publiable, elle devrait consigner :

  1. un identifiant stable ;
  2. la catégorie de canal, public ou Member-only, sans identité ni décompte réservé ;
  3. un exposé publiable du problème ;
  4. la section et le commit précis de la charte ;
  5. le rôle ayant répondu et la date ;
  6. la PR, le diff, le texte de remplacement ou le motif de statu quo ;
  7. la disposition : acceptée, partielle, sans changement, remplacée, retirée, différée ou non résolue ;
  8. l’état du consensus requis par le Process ;
  9. la prochaine autorité : refinement, Team Decision, AC Review, prolongation ou abandon ;
  10. la date de clôture, l’événement qui remplace l’état et l’historique des corrections.

Le canal n’est pas une pondération. Une observation Member-only n’est pas supérieure par nature à une revue publique décisive ; une observation publique n’est pas représentative par nature. La catégorie décrit la garde de l’information. La décision se justifie par ses raisons et sa procédure.

La version figée empêche enfin les raccourcis. Une PR ouverte n’est pas une modification fusionnée ; une fusion n’est pas une charte approuvée. La condition du relecteur de sécurité n’est satisfaite que si le texte attendu entre dans la version qui avance.

Ce que le constat ne permet pas de dire

Au 30 août, l’issue 564 et les PR 862 et 865 étaient ouvertes. Le texte 2026 restait un draft. La page publique du groupe indiquait que la charte active courait jusqu’au 25 septembre.

Ces états ne prouvent ni retard fautif, ni non-conformité, ni faiblesse technique. Le refinement sert précisément à traiter des commentaires et des corrections non achevées. Le 7 septembre était une estimation, et une prolongation annoncée est prévue par le Process.

Le lien de répertoire vers privacy est contextuel : il décrit la frontière de confidentialité analysée ici. Il n’identifie ni W3C, ni le groupe Immersive Web, ni WebXR, et ne signifie aucune approbation.

La recommandation reste étroite : garder les deux portes, conserver leurs règles d’accès et publier assez d’état pour rendre vérifiable le parcours d’une seule charte.

Sources

  1. W3C — Ouverture du refinement de la charte Immersive Web, 10 août 2026
  2. W3C — Projet de charte de l’Immersive Web Working Group
  3. w3c/strategy issue 564 — Immersive Web WG 2026 Group Charter
  4. w3c/charter-drafts PR 831 — première version 2026
  5. w3c/charter-drafts PR 862 — alignement du texte de coordination
  6. w3c/charter-drafts PR 865 — alignement des descriptions de spécifications
  7. W3C Process Document, 18 août 2025
  8. W3C — Immersive Web Working Group
  9. W3C — Charte active de septembre 2024
  10. w3c/charter-drafts — historique des commits du projet 2026
  11. w3c/charter-drafts commit 488587ec141b — marquage DRAFT
  12. W3C — Horizontal Review
  13. Heng Lu — On the Multi-Stakeholder Mirage
  14. Heng Lu — On the Reality Layers of Internet Governance