Le registre WoT du W3C exige deux analyses, pas forcément deux analystes

Résumé

• L'examen par le Comité consultatif de la proposition de charte du groupe Web of Things se termine le 31 août 2026 à 23 h 59 UTC. À l'heure de clôture de cet article, aucune décision n'était encore publiée.
• La charte proposée ajoute un registre des liaisons WoT et prévoit les étapes Registry Draft, Candidate Registry et W3C Registry en 2027.
• Le document public du registre reste un pilote : ses quelques entrées issues du groupe ne peuvent pas encore dépasser l'état Initial, et les soumissions externes n'ouvriront qu'après cette phase.
• Le passage à Current doit donner lieu à deux analyses distinctes, l'une sur le protocole cible, l'autre sur la conformité à WoT. Le texte permet à une personne compétente dans les deux domaines de réaliser les deux examens.
• Current signifie que le dépositaire recommande la liaison pour de nouvelles implémentations et juge l'expérience suffisante. Ce n'est ni une Recommandation W3C, ni une garantie universelle d'interopérabilité.
• Un reçu des rôles et des preuves devrait révéler qui a exercé chaque fonction, ce qui a été testé, les limites communes aux deux analyses et les motifs de la décision du dépositaire.

Une date de clôture n'est pas une approbation

La proposition de charte donne au groupe Web of Things une mission nouvelle. Les chartes précédentes traitaient surtout les liaisons de protocole comme des documents informatifs. Le nouveau texte prévoit un registre structuré, modifiable dans le temps, pouvant accueillir des liaisons élaborées par le W3C ou par des communautés de normalisation extérieures.

Les commentaires publics et l'examen formel courent jusqu'au 31 août. La charte actuelle est prolongée jusqu'au 16 octobre. Il faut conserver cet ordre : l'échéance ferme une période d'examen, elle ne révèle pas son résultat. La page proposée contient encore des dates de début et de fin à compléter. Son calendrier — Registry Draft au premier trimestre 2027, Candidate Registry au deuxième, W3C Registry au troisième — est un projet, pas un état acquis.

Le groupe dispose néanmoins d'un objet concret. Le projet de Binding Registry définit déjà les champs, les conditions de dépôt, les états et les responsabilités. Il précise qu'il n'est pas encore un registre W3C. Pendant le pilote, seules quelques liaisons rédigées par le groupe sont présentes et elles restent Initial. Les contributions extérieures viendront ensuite.

Cette retenue est utile. Elle permet d'éprouver la procédure sans présenter une expérimentation comme une validation institutionnelle.

Le mot Current produit des effets

Le cycle comporte quatre états : Initial, Current, Superseded et Obsolete. Une entrée n'est jamais effacée. Une nouvelle version obtient sa propre ligne ; l'ancienne demeure avec son nouvel état.

Current ne signifie pas simplement « la plus récente ». Dans le projet, le dépositaire recommande alors la liaison pour de nouvelles implémentations et considère qu'elle possède assez d'expérience pratique. Une bibliothèque, une documentation technique ou un cahier des charges peut s'appuyer sur ce signal. Le registre peut donc orienter le déploiement sans être lui-même le protocole.

Le Processus du W3C borne cette influence. Un registre documente des valeurs ; il ne définit pas les exigences d'architecture ou d'interopérabilité. Ces obligations doivent se trouver dans les spécifications qui citent le registre. Un rapport de registre n'est pas couvert par la Politique de brevets du W3C et son statut ne devient pas une Recommandation par capillarité.

La charte proposée ajoute une autre limite. Si le travail sur une liaison révèle qu'il faut modifier le protocole d'origine, le groupe WoT doit s'en remettre à l'organisation compétente. Inscrire une liaison MQTT, Modbus, BACnet ou CoAP ne donne pas au W3C le pouvoir de réécrire ces systèmes.

Le public a donc besoin d'un état précis : ce que Current atteste, et ce qu'il n'atteste pas.

Deux questions peuvent être confiées à une seule personne

Le passage de Initial à Current exige deux regards. Le premier vérifie la fidélité à la spécification cible : les opérations WoT sont-elles correctement traduites en messages du protocole ? Le second vérifie la cohérence avec la Thing Description : un Consumer peut-il comprendre et exécuter les interactions annoncées ?

Le projet indique que le dépositaire devrait désigner au moins deux examinateurs, l'un spécialiste de la spécification cible, l'autre de WoT. La phrase suivante autorise pourtant une même personne, si elle possède les deux compétences, à remplir les deux fonctions. Deux documents séparés restent obligatoires.

Ce choix n'est pas en soi une faute. Pour certains protocoles industriels, le petit nombre de personnes connaissant à la fois le système externe et l'abstraction WoT peut rendre un expert transversal particulièrement précieux. Imposer une deuxième signature décorative pourrait ralentir le registre sans ajouter de connaissance.

Mais deux documents ne démontrent pas deux validations indépendantes. Une erreur de version, une hypothèse de test trop favorable ou un cas limite oublié peut se répéter dans les deux textes si la même personne les rédige. À l'inverse, deux personnes peuvent partager le même employeur, le même code et le même banc d'essai. L'indépendance ne se réduit pas au nombre de noms.

Le registre doit donc publier la topologie de l'examen. « Une personne, deux rôles » est un état légitime possible ; ce ne doit pas être un état invisible.

Le socle de test est réel, sa forme exacte reste ouverte

Le pilote ne repose pas sur une simple opinion. Chaque opération définie par la liaison doit être validée automatiquement lors d'un événement de test. Le rapport doit décrire l'environnement, le scénario et la chaîne logique qui mène d'une Thing Description à la communication. Il doit inclure au moins un Consumer et un Exposer capables de couvrir les opérations et fonctions décrites.

Le même document reconnaît toutefois que le contenu exact du Test Report n'est pas encore arrêté. Il renvoie à une issue GitHub ouverte en février 2025. Le vide est donc identifié : il porte sur le schéma de preuve, non sur l'utilité des essais.

La définition finale devra dire si les chemins d'erreur optionnels sont inclus, si deux extrémités d'une même base de code peuvent compter comme deux implémentations, comment déclarer une bibliothèque de test commune, comment conserver les échecs et les corrections, et comment distinguer un échange de messages d'une véritable conformité sémantique.

Mieux vaut résoudre ces questions avant la première soumission extérieure. Sinon, les premiers cas acceptés deviendront une norme de fait que le texte n'aura jamais explicitement choisie.

Un reçu des rôles et des preuves

Le projet utilise déjà des issues publiques, des revues, des pull requests et un délai après examen. Il n'a pas besoin d'un nouvel organe. Il a besoin d'un dossier compact qui relie ces pièces à chaque décision.

Pour un passage à Current, ce reçu devrait fixer la version de la liaison, la spécification cible, la définition du registre et les documents machine. Il devrait séparer les deux fonctions d'analyse, indiquer qui les a exercées, sur quelle expérience pertinente, et dire explicitement si une seule personne a rempli les deux rôles. Les affiliations ou conflits utiles à la décision devraient être déclarés sans transformer le registre en dossier personnel.

La partie probatoire devrait identifier les dates, environnements, Consumer et Exposer, la couverture opération par opération, le code partagé et les chemins non testés. Chaque analyse conserverait ses réserves et demandes de modification. Puis viendraient le délai de commentaires, les objections, la décision motivée et datée du dépositaire, ainsi que la version des règles qui l'autorise.

Enfin, le reçu porterait quatre limites : Current n'est pas une Recommandation W3C ; ne prouve pas une interopérabilité universelle ; ne modifie pas le protocole sous-jacent ; et ne crée pas d'engagement de brevet pour le rapport de registre.

Selon la distinction utile de Heng Lu, l'expertise conseille, le code en fonctionnement fournit des preuves et le dépositaire exerce un mandat limité. Aucun de ces éléments ne doit emprunter l'autorité des deux autres.

Le pilote est le bon moment

Rien dans les sources ne prouve qu'un examen à double rôle a échoué, qu'un acteur a capturé la procédure ou qu'une liaison est déficiente. Aucune soumission extérieure n'a encore été montrée comme passée à Current. La charte reste proposée.

C'est précisément pourquoi la question peut être réglée sans crise. Une fois que les outils et les acheteurs auront adopté Current comme raccourci, reconstituer la provenance deviendra coûteux. Pendant le pilote, il suffit encore de rendre la concentration visible.

Deux analyses peuvent venir de deux personnes ou d'une seule. Le registre gagnera en crédibilité s'il conserve cette vérité au lieu de laisser une cellule verte effacer la manière dont elle a été obtenue.

Sources

1. Avis d'examen de la charte WoT proposée
2. Charte proposée du groupe Web of Things
3. Charte actuelle du groupe Web of Things
4. Projet pilote du WoT Binding Registry
5. Source figée du registre
6. Issue 3 : définir le contenu du Test Report
7. Processus W3C : Registry Track
8. Heng Lu, The Multi-Stakeholder Mirage