La semaine dernière, Google annonçait de nouvelles règles unifiées pour la lecture automatique de contenus (autoplay) dans Chrome. Mais derrière la bonne volonté affichée, le géant du Net fait des choix qui ne sont pas forcément dans l'intérêt de ses utilisateurs.

Nous évoquions récemment l'arrivée d'une nouvelle fonctionnalité dans Chrome permettant de couper le son de tous les sites de manière assez simple, ou encore la volonté des équipe de Google de commencer à bloquer la publicité sur les sites qui ont des mauvaises pratiques en la matière.

En complément, nous avons désormais droit à un plan de bataille pour ce qui est de la lutte contre une pratique plus spécifique : la lecture automatique de contenus multimédia. Qu'il s'agisse de son ou de vidéo, celle-ci énerve les utilisateurs mais est utilisée de manière assez large et parfois abusive par les éditeurs.

Avant le blocage des publicités, fin de la partie pour l'autoplay dans Chrome (ou pas)

On apprend ainsi que dès Chrome 64, attendu pour le 23 janvier prochain, le navigateur « va mieux aligner la lecture automatique avec les attentes de l'utilisateur et va leur donner plus de contrôle concernant l'audio ». Qu'est-ce que cela signifie ? Que de nouvelles règles vont être mises en place, notamment pour que le son soit désactivé par défaut à moins que l'utilisateur ait manifesté un intérêt. Mais surtout, cela va être unifié au sein des interfaces (mobiles ou non).

Chrome 63, attendu pour le 5 décembre en version stable, intègrera l'option permettant de désactiver l'audio pour l'ensemble des sites que nous évoquions récemment. Cela devra préparer le terrain aux nouvelles règles. De quoi ruiner un peu plus la prochaine année des éditeurs et des publicitaires ? Pas forcément.

Car s'arrêter aux quelques annonces du billet de blog et à la bonne volonté affichée de Google serait une erreur. À y regarder de plus près, ces nouvelles règles se focalisent surtout sur le blocage du son, alors que la lecture automatique des vidéos ressort, elle, renforcée.

Des règles plus souples qu'il n'y parait

Pour s'en rendre compte, il suffit d'analyser les choses dans le détail. Cela tombe bien, les équipes de Chromium ont largement pensé et documenté leur plan de bataille. Il sera d'ailleurs intéressant de voir comment les autres navigateurs dérivés de ce projet vont intégrer ces nouvelles fonctionnalités.

Commençons par la page dédiée à la question de l'autoplay dans la documentation de Chromium. Elle confirme tout d'abord les trois objectifs de base qui sont de donner plus de contrôle à l'utilisateur, d'unifier le comportement au sein des différentes versions de Chrome et surtout de n'autoriser que des usages considérés comme légitimes.

Une fois les nouvelles règles en place, un site ne pourra proposer de la lecture automatique que dans certains cas :

• Le contenu ne contient pas de son ou celui-ci est désactivé
• L'utilisateur a tapé ou cliqué quelque part sur le site pendant sa session de surf
• Sur mobile, l'utilisateur a ajouté le site à son écran d'accueil
• Sur ordinateur, le système se basera sur le Media Engagement Index (MEI)

Si vous voyez fleurir une multitude de bannières « ajoutez-nous à votre écran d'accueil Chrome » sur mobile, vous saurez désormais pourquoi. L'équipe précise que les iFrames pourront uniquement jouer des vidéos sans son ou avec le son désactivé. Pour transmettre « l'autorisation » éventuellement accordée au domaine à l'iFrame, les développeurs devront utiliser un attribut spécifique dans sa déclaration : gesture=media.

Blocage de la lecture automatique sur mobile : c'est terminé

On apprend aussi l'arrivée de deux modifications dans Chrome mobile afin de préparer le terrain, et pas des moindres : la fin de l'option permettant de couper la lecture automatique à tel ou tel site, tout comme la fin du blocage automatique lorsque le mode d'économie de données est activé.

Dès lors, on peut penser que l'utilisateur est perdant dans cette affaire. En effet, la lecture de vidéo automatique est autorisée de manière constante et l'option qui permettait de la bloquer sur mobile disparait, plutôt que d'être généralisée. Un problème pour les utilisateurs qui ont un petit forfait, ou dans une situation où ils ont besoin de limiter les données téléchargées.

Apple et Google continuent d'avoir des pratiques différentes, quid de Mozilla ?

Ces éléments vont à l'encontre du constat de départ mis en avant par Google. Ils rendent par ailleurs les choix d'Apple bien encore plus pertinents quand il s'agit de privilégier l'utilisateur au marché publicitaire.

En effet, il est possible dans macOS High Sierra de bloquer la lecture automatique des vidéos sur base d'une liste blanche ou d'une liste noire. Reste désormais à Mozilla à se positionner, la fondation ayant été plutôt silencieuse sur ces sujets ces derniers mois. Espérons qu'après l'arrivée de Firefox 57 et des WebExtensions, cela changera.

Dans une présentation détaillée datant de cet été (voir ci-dessus), on a confirmation de ces différents points. Dans une analyse des changements entre l'ancienne façon de faire et la nouvelle, on constate en effet que les cas interdisant totalement la lecture automatique disparaissent.

Ceux qui permettent de jouer automatiquement du son sont désormais plus limités sur Chrome dans sa version pour ordinateurs, alors que des cas où cela était interdit sur mobile sont désormais autorisés. L'équipe donne quatre exemples plutôt précis et qui montrent toute la permissivité du système mis en place :

• L'utilisateur visite un site où il lit régulièrement des vidéos, son MEI est élevé, la lecture automatique avec son est autorisée
• L'utilisateur visite un site où il regarde des vidéos occasionnellement, son MEI est faible, la lecture automatique avec son ne sera pas autorisée si l'utilisateur vient d'un site tiers
• L'utilisateur visite un site et passe par sa page d'accueil avant d'arriver sur un article. Une interaction est intervenue, la lecture automatique avec son est autorisée 
• L'utilisateur visite un site et passe par sa page d'accueil avant d'arriver sur une critique de film où une bande-annonce est intégrée via une iFrame. La lecture automatique est autorisée seulement si l'autorisation a été déléguée à travers l'attribut gesture=media

Comme on le voit, dans la majorité des cas évoqués, la lecture est finalement autorisée. La règle la plus permissive étant par exemple celle permettant l'activation du son sous prétexte d'une interaction avec le domaine.

Certes, les équipes du projet Chromium précisent que l'éditeur doit faire attention à ne pas « surprendre » l'utilisateur, et donnent quelques conseils et bonnes pratiques. Mais l'on s'attendait tout de même à des règles plus strictes pour éviter d'avoir à continuer de dépendre du bon vouloir des sites sur ces questions.

Surtout que cela casse tout l'intérêt d'un autre dispositif : le Media Engagement Index.

Media Engagement Index : un score intéressant mais peu utile, sauf à Google ?

Détaillé dans un document complet daté de juin dernier, celui-ci vise à permettre à Chrome de savoir quel est le niveau d'intérêt d'un utilisateur pour tel ou tel site.

Une métrique dont il sera intéressant de savoir si elle sera, à terme, utilisée d'autres manières (notamment dans les résultats de recherche de Google). Certains y verront d'ailleurs une volonté de collecter un peu plus de données sur les habitudes des utilisateurs de Chrome.

Cet index se base sur le nombre de visites effectuée sur le domaine (hors iFrames) et le nombre de lectures significatives effectuées. Pour être jugée comme telle, une lecture doit compter pour au moins sept secondes avec du son, sur un onglet actif et non mis en sourdine. Son format doit être d'au moins 200 x 140 pixels. Des chiffres encore assez faibles, mais qui pourront sans doute être réhaussés avec le temps.

Ainsi, le son sera désactivé par défaut et les sites devront inciter l'utilisateur à l'activer manuellement un certain nombre de fois avant qu'ils puissent opter pour une lecture automatique dans les rares cas qui ne sont pas déjà couverts par une exception. Ces règles ont aussi été établies pour ne pas prendre en compte les sites où l'utilisateur se rend souvent sans jamais y lire de contenu multimédia, les GIF et autres publicités.

Notez que contrairement à une visite, une lecture peut être enregistrée depuis une iFrame, mais elle le sera pour le domaine de la page principale. Ainsi, on peut imaginer que des sites auront tout intérêt à mettre en place des contenus que les utilisateurs vont visionner afin d'avoir ensuite droit à la lecture automatique de manière générale. Un choix qui n'est sans doute pas anodin pour Google et pour YouTube qui est une bonne source de contenus du genre.

Le MEI d'un site est calculé de la manière suivante : 

MEI = nombre de lectures significatives / nombre de visites

Si le nombre de visites est inférieur à 5, le MEI renvoyé sera toujours de 0, sans doute afin d'éviter d'atteindre un score suffisant à la moindre lecture dans les premiers temps. Si un site dépasse un MEI de 0,7, il peut activer la lecture automatique. S'il passe à moins de 0,5, cela ne sera plus le cas. Entre les deux, une zone de flottement est laissée. 

Notez que ces valeurs peuvent changer, il faudra ainsi voir ce qui a été choisi une fois le MEI en place dans Chrome 64. Ces valeurs seront conservées dans les paramètres de contenus, et seront synchronisées avec le profil de l'utilisateur qui retrouvera donc les mêmes paramètres sur l'ensemble de ses appareils.

L'équipe précise qu'en cas de suppressions dans l'historique, ou de nettoyage de celui-ci, le MEI sera adapté afin de ne pas servir de source de fuite d'information concernant la navigation de l'utilisateur. Bien entendu, les visites effectuées en mode incognito ne sont pas non plus conservées.

Un gâchis pour l'utilisateur, espérons que la concurrence s'active

Bref, le dispositif semblait plutôt intéressant, bien que l'on aurait aimé avoir la possibilité de le désactiver, comme la lecture automatique avec ou sans son de manière générale. On a donc bien du mal à comprendre comment Google peut se présenter comme un défenseur de l'utilisateur et ne pas utiliser cet outil de manière plus complète afin de limiter bien plus l'utilisation de la lecture automatique, même avec le son désactivé.

Quoi qu'il en soit, la décision est prise et le calendrier déjà annoncé. Ainsi, dès la version bêta 63 de Chrome, il sera possible de désactiver le son de tous les sites. Le MEI commence pour sa part à être collecté dans les canaux Dev et Canary. Ces versions intègreront les nouvelles règles à compter d'octobre.

Ces règles seront appliquées de manière généralisée dans le canal bêta dès décembre puis dans la version stable de Chrome 64 en janvier. D'ici là, espérons que les concurrents auront montré leur capacité à faire bien mieux, ce qui permettra aux internautes de commencer à se questionner sur la pertinence de Chrome comme navigateur principal.