Résumé

  • Le W3C a ouvert le 7 août 2026 la phase formelle de mise au point d’une nouvelle charte WebAppSec, prévue approximativement jusqu’au 4 septembre, et a prolongé la charte actuelle jusqu’au 30 octobre.
  • La liste normative compte 17 spécifications : 16 portent la mention Expected completion: Undetermined ; Fetch Metadata doit rejoindre WHATWG Fetch, mais sans échéance.
  • Cette absence de date ne prouve ni retard, ni abandon, ni manque de ressources. Le Processus du W3C demande des jalons attendus lorsqu’ils sont disponibles.
  • Une charte autorise un périmètre. La page des publications, les dépôts, les tests, les signaux d’implémentation et les états issus de la politique de brevets décrivent d’autres étapes.
  • Un registre par livrable devrait conserver la valeur « inconnue » tout en nommant la prochaine décision compétente, la dépendance, le responsable de la prévision et la date de sa dernière révision.

Dix-sept lignes, mais pas dix-sept trajectoires visibles

La phase annoncée le 7 août porte sur un projet. Elle cherche à résoudre les commentaires avant les étapes institutionnelles suivantes. La prolongation jusqu’au 30 octobre, elle, maintient les pouvoirs du groupe existant. Enfin, le nouveau texte propose une durée de deux ans à compter d’un futur appel à participation. Ces trois repères ne sont pas interchangeables.

Le projet énumère dix-sept spécifications normatives. Seize indiquent explicitement que leur date d’achèvement est indéterminée. La ligne consacrée aux en-têtes Fetch Metadata prévoit leur intégration dans WHATWG Fetch ; elle donne une destination, pas un rendez-vous.

Le décompte ne comprend pas les trois livrables qualifiés de provisoires, ni les activités non normatives. Il ne mesure pas non plus la santé technique des travaux. Trusted Types, Content Security Policy Level 3, Device Bound Session Credentials ou Web Cryptography Level 2 ne partagent ni la même maturité, ni les mêmes dépendances, ni le même passé de publication.

Dire que seize travaux sont « en retard » serait donc infondé : aucune échéance n’est inscrite dans ces seize cases. Mais réduire la mention Undetermined à une simple formule administrative serait tout aussi insuffisant. Une charte de deux ans rassemble un portefeuille important sans permettre au lecteur de savoir, ligne par ligne, si l’inconnu dépend d’un autre organisme, d’une preuve d’implémentation, d’une décision interne ou de l’absence d’une prévision publique.

La charte joue ici son rôle principal : elle dessine le champ de l’autorité. Elle ne constitue pas, à elle seule, un calendrier d’exécution.

La mise au point ne vaut pas adoption

Le dossier public de stratégie, ouvert en avril, reste au stade de la mise au point de la charte. Il décrit notamment l’ajout de Web Cryptography Level 2 et de Device Bound Session Credentials parmi les livrables normatifs, une utilisation de DBSC pour l’authentification unique parmi les travaux provisoires, ainsi qu’une coordination élargie avec l’IETF et le CFRG.

Les étiquettes de revue horizontale terminée documentent un travail réel. Elles ne constituent pas une décision finale. De même, la fusion d’une modification dans le dépôt public de la charte rend le texte traçable ; elle ne lui confère pas l’autorité d’une charte approuvée.

Le dossier conserve une ancienne estimation qui visait le 1er août. L’avis formel ultérieur fixe l’état public le plus récent, autour du 4 septembre. Ce décalage révèle la révision d’un calendrier de préparation ; il ne suffit pas pour conclure à une violation du Processus.

Pour un changement majeur, le Processus du W3C distingue la mise au point, l’examen par l’Advisory Committee, puis la décision du W3C. L’appel à examen doit mettre en évidence les modifications importantes et présenter le traitement des commentaires. L’appel à participation vient ensuite matérialiser le nouveau mandat.

La prolongation de la charte actuelle évite donc une rupture de pouvoir. Elle ne transfère pas automatiquement les nouveaux livrables dans le mandat existant. C’est une décision de continuité, non un raccourci vers l’approbation.

Cinq états que le mot « jalon » ne doit pas confondre

La charte dit ce que le groupe peut entreprendre, pendant combien de temps, selon quel mode de décision, avec quelles dépendances et quels engagements de participation et de propriété intellectuelle. Le Processus exige des dates de jalon attendues lorsqu’elles existent. Il laisse ainsi une place légitime à l’incertitude.

La page publique des publications indique la maturité actuelle des documents. Les dépôts montrent l’activité éditoriale et les questions ouvertes. Les tests et les intentions d’implémentation éclairent la faisabilité d’une transition. Les revues horizontales consignent les préoccupations spécialisées.

La politique de brevets ajoute encore une autre chronologie. Une date d’Adopted Draft ou d’Exclusion Draft peut ouvrir ou fermer une possibilité d’exclusion et déterminer des engagements. Ce repère juridique et procédural n’est pas une promesse de livraison.

Le projet renvoie lui-même vers la page de publication et vers les dépôts pour ces informations. Cette architecture répartie respecte l’autonomie des travaux. En revanche, elle impose à celui qui veut comprendre le portefeuille de reconstituer dix-sept historiques distincts.

Cette fragmentation nourrit deux récits opposés. Le premier transforme l’inscription dans une charte de deux ans en engagement de livraison. Le second lit toute absence de date comme un échec. Les sources publiques ne justifient ni l’un ni l’autre.

Un registre où « inconnu » reste une réponse

Le remède n’est pas de remplir les cases par des dates artificielles. Il consiste à relier la charte à un registre compact, une ligne par livrable. Chaque ligne identifierait la spécification stable, son dépôt, sa maturité, sa dernière transition formelle, son état pertinent au regard des brevets et la prochaine décision appartenant réellement au groupe ou à une autre instance.

Le registre préciserait également les dépendances, l’état des revues, les éléments d’implémentation et de test, ainsi qu’une classe de prévision : datée, fenêtre, liée à une dépendance, maintenance ou inconnue. Toute prévision aurait un responsable et une date de dernière vérification. Une modification conserverait l’état précédent et sa justification.

Fetch Metadata offre le cas le plus simple. L’intégration dans WHATWG Fetch est une dépendance et une destination. Le registre pourrait nommer l’acte attendu dans cet autre espace, la dernière observation et la prochaine révision, sans attribuer au W3C la maîtrise du calendrier de WHATWG.

En fin de charte, une disposition fermerait chaque ligne : transition réalisée, maintenance poursuivie, transfert vers un autre organisme, nouveau mandat proposé, retrait du périmètre ou état encore inconnu. L’incertitude deviendrait alors révisable et attribuable, sans se transformer en promesse.

Sources

  1. Avis formel de mise au point de la charte WebAppSec
  2. Projet public de charte WebAppSec 2026
  3. Dossier public de renouvellement WebAppSec
  4. Charte WebAppSec actuelle
  5. Processus du W3C
  6. Publications du groupe WebAppSec
  7. Modification publique du projet de charte
  8. Politique de brevets du W3C
  9. Heng Lu, The Policy Mirror