Résumé

  • Le Browser Data Portability Community Group veut élaborer des principes d’importation et d’exportation des données de navigateur dans un Community Group Report. Son propre périmètre exclut une norme de mise en œuvre rigide et la publication de Specifications.
  • Les cinq soutiens nécessaires au lancement ne prouvent ni une représentation du secteur ni une adoption. Adhésion, consensus, rapport, transfert vers une Working Group, obligation réglementaire, engagement d’un éditeur et test d’interopérabilité exigent chacun leur propre preuve.
  • Les mécanismes documentés par Apple, Chrome et la Commission européenne montrent des mises en œuvre concrètes liées notamment au DMA. Ils ne donnent pas pour autant au nouveau groupe un mandat réglementaire ou industriel.

L’implémentation précède déjà le débat

La portabilité des données de navigateur n’est pas une idée entièrement abstraite. Dans iOS 27, Apple explique comment exporter des signets, l’historique, des extensions, des cartes bancaires et des mots de passe de Safari vers une archive ZIP. L’entreprise prévient que le fichier n’est pas chiffré et recommande de le supprimer après l’importation. L’aide de Chrome sur iPhone et iPad décrit la sélection de cette archive, l’aperçu des données, le traitement des conflits de mots de passe et l’importation. BrowserKit documente en outre des gestionnaires d’import et d’export au niveau du système.

Ces documents disent ce que certaines versions savent faire. Ils ne démontrent pas qu’un format universel existe, que toutes les directions sont couvertes ou que des navigateurs ont adopté une future position du groupe. Une fonction livrée n’est pas un consensus institutionnel ; un forum institutionnel n’est pas la preuve qu’une fonction a été livrée.

Le groupe nouvellement créé cherche plutôt à réunir développeurs et responsables d’implémentation autour des besoins des utilisateurs. Son objectif annoncé est un rapport énonçant des principes d’importation et d’exportation afin d’obtenir des résultats plus cohérents entre appareils, plateformes et navigateurs. Le texte est tout aussi explicite sur ce qu’il ne fait pas : pas de norme de mise en œuvre rigide, pas de Specifications.

Cette limite définit son utilité actuelle. Le groupe peut clarifier le problème sans prétendre avoir déjà résolu la question de l’autorité.

Cinq soutiens ouvrent une porte, ils ne forment pas une majorité

Tom Fish a proposé le groupe le 11 septembre. L’annonce de lancement cite Dominique Hazaël-Massieux, Johannes Ernst, Bruce Lawson, Chris Riley et Tom Fish parmi les cinq soutiens. Ce nombre correspond au seuil prévu par le W3C pour créer un Community Group.

Il faut s’arrêter au sens exact du seuil. Soutenir la création n’équivaut pas à rejoindre le groupe. Rejoindre à titre individuel n’équivaut pas à parler au nom d’une organisation. Participer ne signifie pas approuver un texte. Une décision du groupe ne vaut pas engagement de déploiement d’un éditeur.

Au 20 septembre, la page publique affichait un participant, Tom Fish, et aucun président. La situation peut évoluer rapidement ; ce constat n’est donc pas une sentence sur l’avenir du groupe. Il empêche toutefois de présenter le lancement comme une coalition achevée. Aucun président, projet de rapport, modèle de données versionné, décision consignée ou programme d’essais n’était alors visible.

L’adhésion requiert un compte W3C mais pas le statut de membre du W3C. L’organisation précise aussi que l’hébergement du groupe ne constitue pas une approbation et que ses travaux ne représentent pas nécessairement ses membres ou son personnel. Une infrastructure institutionnelle n’est pas une délégation de pouvoir illimitée.

Du rapport à la norme : un passage, pas un raccourci

La comparaison officielle des types de groupes indique qu’un Community Group produit principalement des rapports hors filière de normalisation. Il ne crée pas de norme W3C. Pour avancer vers cette filière, le travail devrait être repris par une Working Group disposant du bon périmètre.

Il existe donc plusieurs états : discussion ouverte, rapport du Community Group, norme W3C, obligation réglementaire, engagement d’un éditeur, mise en œuvre puis interopérabilité vérifiée. Chacun possède une autorité, un auteur et une méthode de preuve différents.

Un rapport prouve ce que le groupe a publié dans une version donnée. Une norme requiert une procédure normative. Une obligation provient d’un texte juridique applicable à des entités déterminées. Un engagement doit être formulé par l’éditeur concerné. Une mise en œuvre porte un numéro de produit ou d’API. Enfin, l’interopérabilité n’est établie qu’entre des versions nommées, dans un environnement de test et selon des critères publiés.

Le nom du W3C ne doit pas remplir les cases encore vides.

Le DMA n’est pas le mandat du groupe

L’étude de cas publiée par la Commission européenne en mai 2026 décrit la portabilité entre navigateurs sur iOS et iPadOS comme le résultat de deux années de dialogue réglementaire lié au Digital Markets Act. Le mécanisme est bidirectionnel, d’application à application, avec médiation du système d’exploitation et de l’utilisateur. Il couvre notamment signets, historique, mots de passe, cartes et extensions ; certains navigateurs tiers prennent déjà en charge l’import depuis Safari.

Cette causalité ne doit pas être inversée. L’article 6(9) du DMA impose des obligations de portabilité aux gatekeepers dans un champ juridique défini. Les exigences relatives à l’autorisation de l’utilisateur, à la gratuité des outils et, selon le cas, à l’accès continu ou en temps réel viennent du droit européen et de sa mise en œuvre. Elles ne viennent pas d’un rapport communautaire, et ce rapport ne pourrait pas les rendre mondiales.

La réglementation, le développement d’un produit et l’incubation de principes peuvent converger. Ils ne partagent pas automatiquement la même source d’autorité.

Un reçu d’autorité pour chaque affirmation

Le futur rapport gagnerait à joindre à chaque affirmation un reçu de portabilité et d’autorité. Il préciserait le type de livrable, son état, sa version, son URL immuable et sa date ; les auteurs, soutiens à la création, participants, représentations organisationnelles, intérêts déclarés, président et éditeurs ; ainsi que la procédure de décision, les objections et leur traitement.

Pour l’exécution, il indiquerait la catégorie de données, l’exportateur, l’importateur, le sens et le déclencheur du transfert, puis les limites d’appareil, de système, de navigateur, de profil et de compte. Le format, le chiffrement et la conservation sont décisifs, surtout pour les mots de passe et les données de paiement. Toute référence au droit devrait nommer la base légale, le territoire, l’entité réglementée, l’autorité et la date d’effet. Toute adoption devrait citer l’engagement de l’éditeur et la version du rapport.

Tout succès d’interopérabilité devrait enregistrer l’environnement, les critères, les échecs connus, les conflits, l’annulation et le retour en arrière.

Une information inconnue doit rester inconnue. Elle ne devient pas vraie parce que le groupe est hébergé au W3C ou parce qu’un grand éditeur possède une fonction voisine.

Le but n’est pas de transformer l’incubation en certification. Il est d’empêcher une phrase de changer de statut en circulant. « Le groupe souhaite discuter » ne signifie pas « le groupe a publié ». « Un produit peut importer » ne signifie pas « l’éditeur a promis d’adopter le rapport ». « Un essai a réussi » ne signifie pas « tous les navigateurs sont interopérables ».

Le premier succès crédible du groupe serait donc un rapport précis, versionné et conscient de ses limites. Il pourrait distinguer données sensibles et données ordinaires, import et export, transfert unidirectionnel et bidirectionnel, puis préparer des passages propres vers éditeurs, normalisation, réglementation et tests. Aujourd’hui, le mandat consiste à réunir, délibérer et rapporter. C’est déjà utile, à condition de ne pas le renommer après coup.

Sources