Résumé

  • La charte du WebTransport Working Group entrée en vigueur le 1er septembre 2026 court jusqu’au 31 août 2028. Son historique signale l’ajout de travaux potentiels sur les interactions pair-à-pair.
  • Le texte place le pair-à-pair dans le périmètre sous la forme de mécanismes que le groupe envisage d’incuber. La liste normative ne contient que WebTransport et réserve sa version initiale aux connexions client-serveur.
  • L’issue 590 demeure une question ouverte : réseau local, serveur derrière un NAT, mDNS, ICE, NAT-PMP, UPnP ou QUIC pair-à-pair y sont évoqués sans qu’aucune solution soit retenue.
  • Un avis de sécurité tardif et non bloquant a demandé une revue de haut niveau. La réponse publique a promis une revue précoce et évoqué une session à TPAC, sans adopter de conception.
  • Le Process du W3C distingue périmètre et livrables. Le traitement futur dépendra notamment du rattachement éventuel du mécanisme au livrable WebTransport existant.
  • Un reçu public devra marquer le passage de l’incubation vers une version de WebTransport, un nouveau livrable, un autre groupe, un résultat non normatif ou une clôture.

Une permission de chercher, pas un résultat acquis

Les chartes techniques sont souvent lues comme des catalogues de produits. Celle-ci résiste à cette lecture. La phrase nouvelle dit que le groupe « envisage d’incuber » des mécanismes capables d’assurer du pair-à-pair. Elle n’annonce ni API définitive, ni choix de protocole, ni calendrier propre à cette capacité.

Le contraste avec la section des livrables est explicite. Le seul texte normatif nommé est WebTransport, présenté comme un ensemble d’API ECMAScript faisant circuler des données entre un navigateur et un serveur. La version initiale de ce livrable est limitée aux connexions client-serveur. L’historique de la charte parle, lui, d’un travail potentiel sur les interactions pair-à-pair.

Le W3C a donc ouvert un espace de travail sans présumer de sa sortie. Le périmètre répond à la question « que peut étudier ce groupe ? ». Le tableau des livrables répond à « quel produit normatif est aujourd’hui identifié ? ». Les statuts Working Draft, Candidate Recommendation et Recommendation viendront ensuite qualifier les documents. Les implémentations et l’adoption produiront encore une autre catégorie de preuve.

Cette séparation protège à la fois l’innovation et la lisibilité. Elle évite qu’une expérimentation ait besoin de se prétendre standard pour exister, et qu’une phrase de charte soit vendue comme une fonctionnalité déjà approuvée.

Plusieurs topologies se cachent derrière « P2P »

L’issue WebTransport 590 ne décrit pas un objet unique. Elle part de demandes différentes : faire communiquer un couple client-serveur sur un même réseau local, atteindre un serveur placé derrière un NAT, ou examiner les travaux IETF relatifs à la traversée de NAT et au QUIC pair-à-pair. mDNS, ICE, NAT-PMP et UPnP apparaissent comme pistes possibles.

Ces situations n’ont ni le même modèle de confiance ni les mêmes informations exposées. Découvrir un service dans un réseau administré n’équivaut pas à établir une voie générale entre deux terminaux. Traverser un routeur résidentiel ne transforme pas nécessairement l’API en canal navigateur-à-navigateur. Les politiques d’entreprise, le consentement, l’authentification et la prévention des abus changent selon la topologie.

L’issue reste ouverte et formule une interrogation : quelle approche choisir ? Elle ne contient pas de résolution du groupe et ne sélectionne aucune des techniques citées. Les présenter comme une feuille de route reviendrait à convertir un inventaire de problèmes en engagement de produit.

Une revue du TAG sur la Local Peer-to-Peer API fournit un contrepoint utile. Ce projet distinct était incubé au WICG et son lieu de normalisation restait indéterminé. Un commentaire a demandé un modèle de menace précis portant sur l’abus de fonctionnalité, la découverte, l’empreinte des appareils, le profilage des utilisateurs et des ressemblances avec UPnP. Le relecteur de la charte WebTransport a expressément précisé qu’il ne s’agissait pas de la même proposition.

Ces interrogations peuvent donc orienter une future revue, mais non lui servir de résultat emprunté. Une conception WebTransport devra publier son propre périmètre de risques et sa propre réponse.

La promesse de revue garde le futur ouvert

Le 29 juillet, alors que la charte était déjà examinée par l’Advisory Committee, un commentaire de sécurité tardif et qualifié de non bloquant a relié le nouveau périmètre à l’issue 590. Il demandait au moins une revue de haut niveau de l’incubation P2P. La réponse du 24 août indiquait que toute capacité nouvelle ferait l’objet d’une revue précoce et qu’une session dédiée devrait se tenir à TPAC.

Ce choix du moment est judicieux : une analyse menée avant la cristallisation d’une API coûte moins cher qu’un correctif après déploiement. Mais la conjugaison reste au futur. Les documents consultés ne montrent ni tenue de la session, ni modèle de menace accepté, ni consensus technique, ni intégration dans une spécification.

L’issue de stratégie a été close comme achevée le 1er septembre, avec un bref message annonçant la charte et renvoyant vers une archive réservée aux membres. L’état vérifiable publiquement se trouve désormais dans la charte finale et sur la page du groupe : début le 1er septembre 2026, fin le 31 août 2028.

Le bref passage d’une étiquette de comptage des bulletins et la proximité des horodatages ne révèlent pas le nombre de voix ou d’objections. Il n’est pas nécessaire de spéculer. Le fait public est suffisant : le droit d’explorer est acquis, le choix technique ne l’est pas.

Le jalon de février ne préjuge pas du contenu

La charte prévoit un First Public Working Draft de la prochaine version de WebTransport en février 2027. Ce rendez-vous pourrait accueillir des travaux P2P, mais le texte ne l’affirme pas. La prochaine version peut porter d’autres fonctions ; le pair-à-pair peut devenir un livrable séparé, rester dans des cas d’usage non normatifs, rejoindre une autre enceinte ou être abandonné.

Le Process du W3C donne à cette qualification une conséquence formelle. Une charte doit exposer séparément son périmètre et la nature de ses livrables. Ajouter un livrable de la voie Recommendation qui ne relève pas du périmètre d’un livrable existant constitue un changement majeur. À l’inverse, le renommage ou la restructuration d’un livrable déjà dans le périmètre peut être mineur.

Il serait donc prématuré d’affirmer qu’une nouvelle charte sera forcément nécessaire. Il serait tout aussi excessif de considérer que la phrase de périmètre valide d’avance n’importe quel texte P2P. La voie dépendra de la proposition concrète et de son rapport au livrable WebTransport existant.

Rendre visible l’acte qui change l’état

La pièce manquante est un reçu de transition public, associé au dossier d’incubation. Il devrait nommer le problème traité, le dépôt de travail, le responsable de la qualification suivante, les revues de sécurité, de vie privée et d’architecture, la coordination avec l’IETF, la décision qui change le statut, puis le document ou l’organisation qui reprend le travail.

Il devrait permettre de distinguer sans enquête rétrospective : l’intégration à la prochaine version de WebTransport ; la création d’un livrable normatif séparé ; un transfert ; un résultat seulement expérimental ou informatif ; enfin un report ou une clôture.

Ce reçu n’a pas à choisir aujourd’hui. Il doit empêcher qu’un commit d’éditeur, une réunion ou un prototype soit confondu demain avec l’acte d’autorité qui fait entrer une proposition dans la filière normative.

La lecture inspirée par la primauté du code en fonctionnement de Lu Heng est ici précise. Une institution peut autoriser l’étude ; le code peut tester une hypothèse ; un document public peut fixer un engagement. Aucun de ces éléments ne prouve à lui seul les autres. Problème, incubation, décision, statut documentaire, interopérabilité et adoption doivent rester dans cet ordre.

La nouvelle charte a franchi une étape nette : le pair-à-pair appartient désormais au champ légitime d’exploration de WebTransport. Elle n’a pas créé un produit normatif distinct. La prochaine épreuve de gouvernance consistera à publier exactement quand, comment et par qui cette identité change.

Sources

  1. W3C — charte 2026 du WebTransport Working Group
  2. W3C — page du WebTransport Working Group
  3. W3C — historique des chartes WebTransport
  4. W3C Strategy, issue 537 — charte WebTransport
  5. Demande de sécurité tardive et non bloquante pour une revue P2P
  6. Réponse publique promettant une revue précoce et évoquant TPAC
  7. WebTransport, issue 590 — réseau local et serveur derrière un NAT
  8. W3C TAG, design review 932 — Local Peer-to-Peer API
  9. Commentaire de sécurité du TAG sur la proposition distincte
  10. Process du W3C, édition du 18 août 2025
  11. W3C — avis public de revue par l’Advisory Committee
  12. W3C — WebTransport Candidate Recommendation Snapshot
  13. Commit de la charte ayant introduit le périmètre P2P
  14. Lu Heng — Running-Code Primacy