Résumé

  • W3C a approuvé le 20 août 2026 le nouveau mandat du WebAssembly Working Group, valable jusqu’au 27 août 2028.
  • Le mandat couvre les révisions des spécifications Core, JavaScript Interface et Web API, ajoute Code Metadata et trois spécifications consacrées aux extensions anciennes, mais traite le Component Model comme un livrable conditionnel.
  • La condition est l’arrivée de la proposition à la phase 4 du processus du WebAssembly Community Group. Le registre public figé avant la date d’observation la classe toujours en phase 1.
  • Cette phase 1 ne signifie pas absence de technologie : le dépôt du Component Model décrit les Developer Previews WASI 0.2.0, 0.3.0 et 0.3.1 et leur usage hors navigateur dans des contextes de production afin de recueillir des retours.
  • La phase 4 exige notamment des implémentations, des tests, une spécification et un interpréteur de référence complets ainsi qu’un consensus du Community Group. Le Working Group doit ensuite prendre sa propre décision et suivre le parcours W3C.
  • Un dossier de promotion à deux clés devrait relier la preuve technique au vote du Community Group, puis enregistrer séparément la réception, le consensus et l’état de publication du Working Group.

Ce que W3C a réellement approuvé

L’annonce du 20 août clôt la revue du mandat et ouvre une période institutionnelle précise. Le WebAssembly Working Group dispose d’un mandat du 20 août 2026 au 27 août 2028. Deux présidents, un contact de l’équipe W3C, un périmètre et une politique de décision sont nommés. Il ne s’agit donc ni d’un brouillon de mandat ni d’une simple intention de poursuivre les travaux.

Les livrables ne se trouvent pourtant pas tous dans le même état. Le groupe doit produire de nouvelles révisions du noyau WebAssembly, de l’interface JavaScript et de l’API Web. Il reçoit aussi quatre nouveaux objets : une spécification des métadonnées de code et trois textes destinés aux extensions dépréciées mais susceptibles d’être encore utilisées.

Pour le Component Model, la formulation change. Le groupe vise une spécification normative seulement si la proposition atteint la phase 4 selon le processus du Community Group. Le mandat dessine donc un couloir d’admission. Il ne constate pas que la proposition a déjà franchi le seuil.

Cette nuance protège la portée du vote de recharte. Les représentants et W3C peuvent décider qu’un sujet appartiendra au Working Group lorsqu’il sera suffisamment mûr, sans certifier à l’avance les implémentations, les tests ou le consensus qui doivent prouver cette maturité. Le mandat de 2023 comportait déjà cette condition. Celui de 2026 la reconduit au lieu de la faire disparaître par simple ancienneté.

Le registre public indique encore la phase 1

Le dépôt WebAssembly/proposals classe les propositions actives par phase. La révision publique la plus récente avant notre date d’arrêt, validée le 10 août, distingue clairement les phases 1 à 5. Certaines propositions sont déjà en phase 4 ou 5 ; d’autres se trouvent en phase 2 ou 3. Le Component Model figure dans la liste de phase 1.

Ce classement a une valeur institutionnelle : il indique l’état officiellement exposé par le processus. Il n’a pas la prétention de résumer l’intégralité de la technique. La phase 1 signifie que le Community Group reconnaît un sujet pertinent, plausible et digne d’un travail de proposition. Elle ne mesure ni le nombre de contributeurs, ni le volume du dépôt, ni les systèmes déployés.

Il serait donc faux d’en déduire que le Component Model n’existe qu’à l’état d’idée. Il serait tout aussi faux de supposer qu’un dépôt actif a automatiquement dépassé le registre. Une discussion postérieure, une décision non encore intégrée ou un travail interne peuvent exister ; les sources examinées ne permettent pas de l’exclure. La conclusion vérifiable reste plus étroite : à la date retenue, le tableau public épinglé n’affiche pas de promotion au-delà de la phase 1.

Deux institutions se partagent la montée en maturité

Le processus WebAssembly organise une progression qui commence dans le Community Group et se termine dans le Working Group. Après la phase 0, chaque passage de phase doit être inscrit à l’ordre du jour d’une réunion du Community Group. Celui-ci vérifie les conditions d’entrée et se prononce.

La phase 2 demande une description précise et complète autour de laquelle un niveau élevé de consensus s’est formé. La phase 3 fait entrer les tests et les implémentations. La phase 4 fixe une barre plus haute : deux machines virtuelles Web ou davantage doivent, lorsque le critère s’applique, implémenter la fonctionnalité et réussir la suite de tests ; au moins une chaîne d’outils doit l’implémenter ; la spécification et l’interpréteur de référence doivent être complets ; l’interpréteur doit passer les tests ; enfin, le Community Group doit considérer la fonctionnalité et sa spécification comme achevées.

À ce moment seulement, la proposition est remise au Working Group. Le passage n’achève pas la normalisation. Les membres du Working Group étudient encore les cas limites, établissent leur propre consensus et accomplissent les obligations du processus W3C. Une modification substantielle renvoie le sujet au Community Group. La phase 5 n’arrive qu’après le consensus du Working Group sur l’achèvement de la fonctionnalité.

Cette architecture possède deux clés. La première valide l’incubation et la preuve de maturité. La seconde engage le parcours normatif W3C. Un vote du Community Group ne peut pas devenir une Recommendation par raccourci. Inversement, le Working Group ne devrait pas faire comme si les conditions d’implémentation et de consensus prévues pour l’incubation étaient facultatives.

La production apporte une preuve, pas un mandat

Le dépôt du Component Model constitue le contrepoint indispensable au tableau de phase. On y trouve des documents de conception, des formats texte et binaire, des règles de liaison, une ABI et une suite de tests en croissance. Le fichier de référence décrit trois Developer Previews WASI : 0.2.0, 0.3.0 et 0.3.1.

Il précise que les fonctions activées dans ces versions sont maintenues stables par les outils producteurs et consommateurs afin d’être utilisées hors navigateur, y compris dans des environnements de production, et de produire un retour d’expérience réel. La 0.2.0 a posé la première version fondée sur le Component Model ; la 0.3.0 a ajouté la concurrence native ; la 0.3.1 a complété les types et annotations.

Voilà pourquoi « phase 1 » ne doit jamais être traduit par « prototype sans utilisateur ». Une communauté technique peut stabiliser un profil, construire des outils et supporter des applications bien avant la fin du parcours W3C. Cette pratique peut améliorer la future norme en révélant des coûts et des comportements que la conception abstraite ne montre pas.

Le même dépôt indique toutefois qu’une spécification formelle et un interpréteur de référence doivent encore être ajoutés. Une version de développement peut donc être suffisamment stable pour un usage défini tout en restant en amont des pièces exigées par la phase 4.

L’erreur inverse consisterait à faire de l’usage le vote manquant. Une compatibilité livrée par des outils ne prend pas la décision du Community Group, ne prouve pas chaque condition d’entrée, ne constate pas le consensus du Working Group et ne publie pas une Recommendation W3C. Le code en fonctionnement est une preuve technique de premier ordre ; il ne devient pas pour autant l’organe constitutionnel.

Un Community Group n’émet pas une norme W3C

W3C présente les Community Groups comme des forums ouverts et gratuits destinés à l’incubation. Le groupe WebAssembly peut accueillir toute personne disposant d’un compte W3C et acceptant l’accord de contribution. Cette ouverture élargit l’expertise et réduit le coût d’entrée.

Elle ne crée pas une délégation universelle. W3C avertit que ces groupes sont conduits par leurs communautés et ne représentent pas nécessairement les vues des Membres ou de l’équipe W3C. Le guide documentaire ajoute que leurs rapports ne relèvent pas de la filière normative et ne sont pas des normes W3C. Ils peuvent devenir la matière première d’un Working Group ; le passage reste identifiable.

Le modèle tire sa force de cette asymétrie. L’incubateur peut évoluer vite, accueillir des non-Membres et expérimenter. Le Working Group peut recevoir un objet mûr avec des engagements de brevet, des revues horizontales, une politique de consensus et des états de publication plus lourds.

Les mots d’état engagent des décisions coûteuses

Pour un fournisseur, dire « nous supportons le Component Model » peut masquer la version de Developer Preview et le commit effectivement mis en œuvre. Pour un acheteur, lire « le Component Model est dans le mandat W3C » peut évoquer à tort une Recommendation. Pour un développeur, voir « phase 1 » peut suggérer une volatilité totale que les outils producteurs et consommateurs ont choisi de limiter sur un profil donné.

Ces confusions déplacent aussi les objections. Une question de conception appartient encore au Community Group tant que la proposition y mûrit. Une question sur l’adoption normative doit être tranchée par le Working Group après remise. Une question sur l’état d’un document W3C dépend du parcours de publication, pas du numéro d’une Developer Preview.

L’adoption peut en outre modifier le pouvoir sans texte. Lorsqu’un format, une ABI ou une sémantique de liaison est largement déployé, le coût d’une correction tardive réduit les options du groupe appelé à décider. Les implémenteurs n’ont pas reçu un mandat formel supplémentaire, mais leurs investissements deviennent une contrainte de fait.

La transparence doit rendre cette contrainte visible sans la diaboliser. Un écosystème a besoin d’expérimentation réelle. Il a aussi besoin de savoir à quel moment le retour d’expérience devient une preuve examinée, et à quel moment une institution compétente l’accepte.

Un dossier de promotion à deux clés

Le dossier proposé par Daniel Kade ne remplace aucun groupe. Il relie les états que chacun produit déjà.

La première partie figerait l’identifiant et la révision de la proposition, sa phase, la dernière décision et les critères de la phase demandée. Chaque critère pointerait vers une preuve : implémentations nommées, résultats d’une suite de tests identifiée, chaîne d’outils, état de la spécification formelle, interpréteur de référence et exceptions. Si un critère ne s’applique pas, l’auteur de cette qualification et sa raison seraient publics.

La décision du Community Group indiquerait l’ordre du jour, la méthode de constat du consensus, le résultat, les objections conservées et le périmètre exact promu. Elle ne prétendrait pas qu’un nombre de présents représente tous les utilisateurs de WebAssembly. Elle établirait seulement que le groupe compétent a utilisé sa première clé sur un objet défini.

La seconde partie commencerait à la réception par le Working Group. Elle enregistrerait le commit reçu, la décision ou l’appel à consensus du groupe, les éléments renvoyés à l’incubation, les revues de sécurité, de confidentialité, d’accessibilité et d’internationalisation, l’état des engagements de brevet et le statut de publication W3C.

Une modification substantielle créerait un mouvement de retour, non une retouche silencieuse de la remise initiale. Les promesses faites aux utilisateurs des Developer Previews resteraient versionnées, même lorsqu’une norme ultérieure les remplace.

Ce dossier n’a pas besoin de publier les projets commerciaux, les avis juridiques confidentiels ou chaque échange de réunion. Il suffit de rendre reproductibles l’objet, la preuve, le décideur, le résultat et la transition.

L’état exact au 31 août

Le WebAssembly Working Group possède un mandat approuvé et daté. Le Component Model y est admis comme possibilité conditionnelle. Le registre public de propositions le place en phase 1. Son dépôt expose en parallèle des versions de développement, une promesse de stabilité ciblée et des usages de production hors navigateur.

Les sources ne prouvent ni rejet d’une phase 4, ni retard imposé par W3C, ni contournement par un fournisseur. Elles ne révèlent pas une défaillance de sécurité, de brevet ou d’interopérabilité. Elles ne transforment pas davantage les previews en Recommendation.

La formulation la plus solide tient en trois phrases : la technologie est déjà concrète ; sa promotion institutionnelle n’est pas achevée ; le nouveau mandat conserve la voie permettant de relier les deux. La légitimité viendra moins d’un grand récit communautaire que de deux décisions minces, distinctes et vérifiables.

Sources

  1. W3C — annonce d’approbation du mandat WebAssembly
  2. W3C — mandat du WebAssembly Working Group
  3. WebAssembly — registre des propositions figé au 10 août 2026
  4. WebAssembly — processus de progression par phases
  5. WebAssembly — état du dépôt Component Model
  6. W3C — WebAssembly Community Group
  7. W3C — FAQ des Community et Business Groups
  8. W3C — types de documents publiés
  9. Lu Heng — The Multi-Stakeholder Mirage