Résumé

  • Le W3C a approuvé la nouvelle charte du Web Performance Working Group le 10 août 2026, pour une période allant jusqu’au 1er août 2028.
  • Avant l’intégration d’une nouvelle fonctionnalité dans une spécification maintenue en Candidate Recommendation, le texte souhaite des marques d’intérêt d’au moins deux implémenteurs.
  • À défaut, la fonctionnalité peut figurer dans un projet de Candidate Recommendation, à condition que son caractère « à risque » soit signalé.
  • Le stade ultérieur attend deux implémentations indépendantes et interopérables par fonctionnalité, vérifiables par une suite de tests ouverte ; le Process du W3C conserve toutefois une exception motivée et publique.
  • Un registre par fonctionnalité devrait conserver séparément intérêt, adoption par le groupe, étiquette à risque, versions implémentées, tests et décision de transition.

Une intention n’est pas un résultat d’essai

La performance du Web se gouverne à travers des objets très concrets : temps de chargement, réaction à une interaction, rendu, mémoire ou échecs d’application. Pourtant, la donnée la plus instructive de la nouvelle charte n’est pas une métrique. C’est le vocabulaire choisi pour décrire la maturité d’une fonctionnalité.

Le 10 août, le W3C a annoncé l’approbation de la charte et un nouvel appel à participation. Le mandat court jusqu’au 1er août 2028. Entre le projet présenté en juin et le texte définitif, le critère relatif au soutien des implémenteurs a été reformulé en « expressions of interest ». Ce choix réduit utilement la portée de l’affirmation.

Une marque d’intérêt peut signifier plusieurs choses : l’organisation reconnaît le problème, souhaite relire les projets, envisage un prototype ou veut conserver une option technique. Elle peut être précieuse sans engager une équipe produit, un calendrier, une mise en service par défaut ni une compatibilité durable. Le registre public ne doit pas lui prêter un engagement que son auteur n’a pas pris.

Le texte prévoit précisément une autre preuve plus tard. Pour dépasser Candidate Recommendation, une spécification normative est censée disposer de deux implémentations indépendantes et interopérables de chaque fonctionnalité, l’interopérabilité étant contrôlée par des tests ouverts. Chaque fonctionnalité doit aussi être couverte par une suite ouverte. L’intérêt porte sur la pertinence et la possibilité d’investir. L’interopérabilité porte sur le comportement observable de systèmes réellement distincts.

Ce ne sont pas deux niveaux d’un même sondage. Ce sont deux catégories de preuve.

Les quatre états visibles dans la charte

Le parcours public comprend au moins quatre moments.

L’incubation vient d’abord. Le Web Platform Incubator Community Group offre un espace où une proposition peut acquérir des cas d’usage, du code et des critiques sans être déjà une œuvre normative du Web Performance Working Group.

Vient ensuite l’adoption par le groupe. La charte indique qu’une proposition incubée au WICG, implémentée et disponible dans au moins un grand navigateur, avec le soutien d’un autre acteur, peut être adoptée par WebPerf. Cette décision attribue un foyer institutionnel au travail. Elle ne démontre ni une deuxième implémentation indépendante ni la réussite des tests de chaque fonctionnalité.

Le troisième état est la présence dans un projet de Candidate Recommendation. Même sans deux marques d’intérêt, une fonctionnalité peut y être introduite si elle porte une annotation « at risk ». Le document peut donc être mûr pour une forme de revue tandis qu’une de ses parties reste explicitement conditionnelle.

Enfin viennent l’expérience d’implémentation et la transition. Le Process du W3C utilise Candidate Recommendation pour recueillir cette expérience. Il distingue notamment le Draft, qui expose des changements destinés à la revue, et le Snapshot, qui possède son propre rôle de transition et de revue de brevets. L’étiquette du document ne suffit donc pas à décrire chaque fonctionnalité.

Une simple colonne « support » écrase ces différences. Elle ne dit pas s’il s’agit d’un commentaire favorable, d’un prototype, d’une fonction cachée derrière une option, d’une adoption formelle, d’une couverture de tests incomplète ou de deux comportements compatibles en production.

La réponse publique de Mozilla fixe sa propre limite

La réponse de Mozilla lors de la revue illustre la manière correcte de lire une intention. L’organisation a soutenu la proposition, que ses modifications soient reprises ou non, et a approuvé le changement de formulation concernant le soutien de deux implémenteurs. Elle a aussi déclaré vouloir examiner les projets, produire des implémentations expérimentales et des retours d’expérience, puis développer des produits fondés sur les travaux.

La rubrique publique consacrée au calendrier d’implémentation ne contient aucune date.

Il ne manque rien à la phrase : elle dit exactement ce qu’elle sait. Mozilla signale une volonté générale de participer, pas deux engagements sur une fonctionnalité déterminée. La réponse ne nomme ni API, ni révision, ni version de navigateur, ni échéance. La transformer en preuve d’interopérabilité serait ajouter au document une promesse absente.

La liste des membres appelle la même prudence. La présence d’une entreprise dans le groupe apporte des compétences et un canal de délibération. Elle ne constitue pas un vote silencieux pour chaque ligne de chaque spécification.

« À risque » ne veut pas dire condamné

Dans le langage courant, une fonctionnalité à risque paraît vouée à disparaître. Dans le Process, l’annotation a un usage plus précis. Elle avertit que la fonctionnalité pourra être retirée lors d’une transition ultérieure selon une voie prévue, sans faire croire que le reste du document garantit sa conservation.

Le dispositif permet l’expérimentation sans maquiller l’incertitude. Mais l’étiquette doit rester liée à une fonctionnalité et à une version exactes. Si elle disparaît, l’historique doit dire pourquoi : nouvelle marque d’intérêt, implémentation suffisante, suppression, réduction du périmètre ou simple réorganisation éditoriale.

Les résultats de tests exigent la même discipline de version. « Deux navigateurs réussissent » ne précise pas si les essais couvrent tout le comportement, s’ils reposent sur la même révision de Web Platform Tests, si les fonctions sont actives par défaut ou si les deux produits partagent la même base technique. L’indépendance ne devrait pas être une déduction tirée de deux marques commerciales ; elle nécessite une justification.

Une exception doit aussi être un objet public

La charte parle d’une attente de deux implémentations indépendantes. Le Process général autorise le W3C Team, pour une raison impérieuse, à accepter une transition avec une expérience minimale. Cette décision et sa justification doivent être publiques.

L’exception n’annule pas le critère. Elle crée un autre état de gouvernance. Il faut savoir qui a décidé, sous quelle version du Process, pour quel périmètre, sur quelle base et avec quelle motivation. Une exception bien documentée peut être plus honnête qu’un comptage de deux implémentations dont l’indépendance est artificielle.

La doctrine de Heng Lu sur l’adoption volontaire aide à formuler la frontière : la publication ne remplace pas l’implémentation, la validation et l’usage. Mais la réciproque est vraie dans un processus de normalisation : du code en fonctionnement ne se déclare pas lui-même Recommendation du W3C. La réalité opérationnelle et le statut institutionnel ont des autorités distinctes. Le public doit pouvoir les joindre sans les confondre.

Le registre d’état qui manque

Pour chaque nouvelle fonctionnalité, une fiche versionnée pourrait relier les surfaces déjà publiques. Elle indiquerait :

  • l’identifiant stable de la fonctionnalité et la révision du texte ;
  • la charte et la version du Process applicables ;
  • chaque marque d’intérêt publique, son auteur, sa date, son périmètre et sa source ;
  • la nature expérimentale, planifiée, mise en œuvre, retirée ou non datée de cette déclaration ;
  • la décision d’adoption du Working Group et la révision adoptée ;
  • l’URI, la date et l’historique de l’annotation à risque ;
  • le produit, le moteur et la version de chaque implémentation, ainsi que le motif d’indépendance ;
  • la révision des tests ouverts, leur couverture et leurs résultats datés ;
  • la transition, les objections et toute exception publiée ;
  • le prochain examen, les corrections et les remplacements.

Cette fiche n’exige pas la divulgation de feuilles de route confidentielles. Elle permet au contraire à un implémenteur de dire « intéressé, sans calendrier » et de conserver cette réserve tout au long de la chaîne documentaire.

La charte a posé une frontière saine. Il reste à empêcher les tableaux de bord, les contrats et les annonces de la faire disparaître.

Sources

  1. W3C — annonce d’approbation et appel à participation
  2. W3C — charte approuvée du Web Performance Working Group
  3. W3C — comparaison entre projet et texte approuvé
  4. W3C — annonce publique de la revue du projet
  5. Archives publiques du W3C — réponse de Mozilla
  6. W3C — Process Document
  7. W3C — publications du Web Performance Working Group
  8. W3C — page du Web Performance Working Group
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption