Résumé

  • La charte proposée de Browser Testing and Tools prévoit de conduire WebDriver et WebDriver BiDi jusqu’à la Candidate Recommendation avec Snapshots, de les y mettre à jour en continu et de ne pas viser la Recommendation.
  • Ce modèle n’est pas encore adopté. Les deux rapports techniques courants sont des Working Drafts ; la Recommendation WebDriver de 2018 reste un état publié distinct.
  • Le W3C ne donne pas les mêmes garanties à un Candidate Recommendation Snapshot et à un Candidate Recommendation Draft : le second intègre des modifications postérieures qui n’ont pas encore reçu l’examen formel du premier.
  • Toute affirmation vérifiable de compatibilité devrait associer un instantané immuable, son état de maturité, le commit et la sélection des tests, les versions du navigateur, du pilote et du client, la plateforme, la date et les exclusions connues.

Une étape intermédiaire choisie comme destination

WebDriver transforme des intentions comme ouvrir une page, trouver un élément ou déclencher une action en un protocole que des navigateurs différents peuvent mettre en œuvre. WebDriver BiDi ajoute le trajet inverse : le navigateur peut émettre des événements vers l’outil qui le pilote. Leur gouvernance ne reste donc pas enfermée dans un document. Elle traverse les moteurs, les pilotes, les bibliothèques d’automatisation et les milliers de tests qui décident chaque jour si une modification peut être livrée.

Le 18 août 2026, le W3C a soumis une nouvelle charte à son Advisory Committee. La consultation publique court jusqu’au 18 septembre et l’ancien mandat a été prolongé jusqu’au 23 octobre. Le texte n’est pas approuvé à ce stade. Il révèle néanmoins un choix éditorial et institutionnel suffisamment net pour être examiné.

Ses deux spécifications normatives sont WebDriver et WebDriver BiDi. Le groupe entend publier leur état le plus récent comme Candidate Recommendation, avec des Snapshots, puis continuer à les actualiser. Il écrit aussi qu’il n’a pas l’intention de les faire progresser jusqu’à la Recommendation.

Cette phrase ne décrit pas un retard. Elle choisit un régime permanent. Le guide du W3C sur les « living CR » explique l’intérêt possible : un texte nourri par plusieurs bases de code peut rester proche de l’expérience d’implémentation, au lieu d’attendre de rares éditions finales. Des Snapshots revus balisent le chemin ; des Drafts intègrent les évolutions entre deux balises.

La contrepartie est moins visible. Lorsqu’une Recommendation constitue le point stable, un contrat ou un rapport de test peut citer une édition approuvée. Si la série doit vivre au stade Candidate Recommendation, le nom « WebDriver » ne suffit plus à identifier l’objet examiné.

La charte autorise une série, pas un jeu d’octets

Le tableau de la charte proposée désigne la publication WebDriver du 1er avril 2026 et celle de WebDriver BiDi du 19 mars comme les plus récentes. Au 31 août, les pages officielles avaient déjà avancé : WebDriver affichait le Working Draft du 2 juillet, et WebDriver BiDi celui du 25 août.

Il ne s’agit pas d’une accusation d’inexactitude. Une charte se prépare pendant que les éditeurs publient. Les liens restent dans la même histoire documentaire. Mais cet écart fournit une démonstration rare, au sein même du dossier : le mandat porte sur une famille de documents mouvante. Il n’atteste pas les octets utilisés par un test la veille, ni l’algorithme qu’un navigateur distribué six mois plus tôt applique encore.

La coexistence des états ajoute une seconde ambiguïté. Le W3C conserve une Recommendation WebDriver datée de juin 2018 et publie en parallèle un nouveau rapport WebDriver comme Working Draft. Le nom commun n’autorise pas le nouveau texte à emprunter le statut de l’ancien. Inversement, la Recommendation de 2018 ne décrit pas automatiquement les commandes ajoutées ensuite.

L’adresse « latest » est excellente pour lire le travail courant. Elle est insuffisante pour refaire une expérience, car sa cible peut changer sans que le journal de test, le navigateur ou le pilote ne change.

Snapshot et Draft produisent des preuves différentes

Le Processus du W3C sépare deux formes de Candidate Recommendation. Le Snapshot passe par une demande de transition ou de mise à jour vérifiée. Il constitue aussi un Patent Review Draft. Le guide public du W3C lui associe le consensus du groupe, l’examen public, la revue formelle d’autres groupes et les engagements de licence libre de redevances des participants.

Le Candidate Recommendation Draft intègre les changements prévus après le Snapshot. Ses exigences de publication sont allégées afin que le rapport reste à jour. Le W3C précise que ces changements n’ont pas reçu l’examen formel et que le Draft ne fournit pas lui-même l’occasion d’exclusion liée au brevet.

Ni l’un ni l’autre ne peut être cité comme une norme W3C. Surtout, la publication d’un Snapshot n’exige pas à elle seule une expérience d’implémentation adéquate. Le guide sur les living CR admet qu’un Snapshot peut encore contenir des fonctions instables, inégalement disponibles, peu interopérables ou dépourvues de tests complets.

Ces limites ne discréditent pas le Snapshot. Elles définissent sa preuve. Il indique un objectif d’implémentation revu et un état de la procédure brevets. Le Draft montre les changements intégrés depuis cet objectif. La Recommendation ajoute l’aval du W3C et une exigence supplémentaire sur l’expérience d’implémentation. Confondre ces états ferait perdre précisément l’information que le Processus a séparée.

Une affirmation de support doit pouvoir être rejouée

La charte contient déjà des garde-fous utiles. Les changements intervenus en Candidate Recommendation, ainsi que les fonctions déployées, devraient disposer de Web Platform Tests. Toute nouvelle fonction devrait susciter l’intérêt d’au moins deux implémenteurs potentiels. Les conséquences pour la sécurité, la vie privée et l’accessibilité doivent être documentées, et les revues horizontales sollicitées lors des grandes transitions.

Chaque élément reste toutefois partiel. L’intérêt n’est pas une implémentation. Un fichier de test ne prouve pas qu’il couvre toute obligation normative. Un résultat vert sur un tableau vivant ne dit rien, sans commit et numéro de version, sur ce qui pourra être reproduit plus tard. Un navigateur peut activer une fonction derrière un drapeau ; un pilote ou une bibliothèque cliente peut n’en exposer qu’une partie.

Pour une décision importante, le dossier minimal devrait réunir :

instantané immuable + type de maturité + commit des tests + sélection exécutée + versions navigateur/pilote/client + plateforme + date + exclusions

Si le texte testé est un Candidate Recommendation Draft, le dossier doit aussi nommer le Snapshot précédent et les changements substantiels concernés. Pour un Snapshot, il doit relier la décision de transition ou de mise à jour et l’état de la revue brevets. Une règle qui vise « latest » doit conserver le moment et la méthode de résolution ainsi que l’URL immuable obtenue.

Ce dossier n’est pas une certification parallèle. Il ne transfère aucune compétence : le W3C décide des publications, le groupe du texte, les projets des versions livrées et l’utilisateur de la version qu’il accepte. Il relie seulement leurs traces.

L’enjeu n’est pas d’exiger une Recommendation

Le dossier public ne permet pas de conclure que WebDriver devrait absolument devenir une Recommendation. Le W3C reconnaît le living CR comme une option légitime. Pour un protocole qui se précise grâce aux moteurs et aux tests, la continuité peut produire plus de vérité qu’une édition finale trop espacée.

Le risque apparaît lorsque cette souplesse voyage sans son identité. Un succès obtenu avec un Draft précis et quelques tests peut être résumé comme « WebDriver est pris en charge ». Une modification ultérieure peut ensuite être projetée à rebours sur un audit ancien. Le nom de la série efface la différence entre les versions et entre les niveaux de revue.

La solution n’est pas d’immobiliser la série. Il faut immobiliser la preuve de chaque résultat. Un nouveau Snapshot, un nouveau commit de tests et un nouveau navigateur produisent un nouvel enregistrement. L’évolution reste possible ; sa trace devient comparable.

Incertitudes

L’Advisory Committee peut approuver, modifier ou refuser la charte. La clause de Candidate Recommendation durable peut évoluer. Aucun des deux livrables n’a encore atteint l’état que le projet décrit, et le texte ne promet aucune date de première transition.

Cette analyse ne note pas l’interopérabilité actuelle et ne transforme pas le tableau WPT en verdict. Le niveau de précision nécessaire dépend aussi de l’usage. Un développeur qui suit la branche principale n’a pas les mêmes obligations qu’un acheteur qui doit refaire une vérification cinq ans plus tard.

La conclusion reste bornée : si la Candidate Recommendation devient le point d’arrivée continu, l’identité exacte de la version fait partie du produit de gouvernance. Le nom indique le chantier. Il ne dit pas ce qui a tourné.

Sources

  1. Annonce W3C sur la charte proposée
  2. Charte proposée de Browser Testing and Tools
  3. Charte actuelle de Browser Testing and Tools
  4. Processus du W3C
  5. Choisir le stade final d’un livrable
  6. Types de documents publiés par le W3C
  7. Rapport technique WebDriver courant
  8. Historique de publication de WebDriver
  9. Rapport technique WebDriver BiDi courant
  10. Historique de publication de WebDriver BiDi
  11. Résultats WPT de WebDriver BiDi
  12. Arbre de tests WPT de WebDriver BiDi