Avec les Accelerated Mobile Pages (AMP), Google pousse un standard adapté à la soif insatiable des internautes pour la rapidité d'affichage, contrôlé de façon opaque, qui devra cohabiter avec les normes ouvertes établies par le W3C.

Sommes-nous tous fous ? Nous connaissons une rapidité d’accès à l’information comme jamais l’humanité n’en avait connue, mais nous ne sommes jamais satisfaits. Des informations qui prenaient des semaines à être obtenues il y a quelques siècles, des jours au 19e siècle, des heures au 20e siècle, puis des minutes et désormais des secondes, ne nous parviennent toujours pas assez vite.

Nous n’avons plus besoin d’aller dans une bibliothèque ou dans une librairie pour trouver un livre, accessible en quelques clics. Nous n’avons plus besoin d’attendre que le facteur délivre le journal du matin, nous avons accès aux articles des journalistes dès qu’ils ont fini de les écrire. Nous voulons écouter une chanson d’un groupe de blues de la Nouvelle Orléans que plus personne ne connaît ? Il suffit de lancer Spotify. Nous voulons savoir qui était le ministre des affaires étrangères du Pakistan en 1985 ? Wikipédia. Nous voulons faire savoir que l’on est en bonne santé après un tremblement de terre ou un attentat ? Facebook.

Nous avons déjà toute la rapidité dont nous avons besoin, mais il nous en faut toujours plus. Ce n’était jusque là pas un problème pour Internet. Il suffisait d’augmenter la taille des tuyaux, de diminuer les temps de latence, à coup d’ADSL, de 2G, de 3G, de fibre optique ou de 4G… Mais aujourd’hui, notre impatience menace le Web tel que nous l’avons connu, ouvert et normalisé.

Accelerated Mobile Pages, kézako ?

Google a ainsi donné mercredi le coup d’envoi de la prise en charge du standard AMP (Accelerated Mobile Pages), un format d’écriture et d’interprétation du code source des pages Web qui s’appuie sur le HTML mais le complète, l’optimise, et le bride.



Pour dire les choses relativement simplement, il impose aux éditeurs de décliner dans une version minimaliste très rapide à charger du contenu de leurs pages Web, éventuellement mis en cache dans des CDN (Google en offre un gratuit), en utilisant exclusivement des technologies validées au préalable par le prétendu « AMP Project » — c’est-à-dire par Google et ses partenaires, sélectionnés on ne sait trop comment.

Comme avec Facebook Instant ou Apple News, l’internaute n’aura plus besoin d’attendre pour voir le contenu s’afficher, grâce à toute une série de techniques d’accélération. Les pages seraient en moyenne dix fois moins lourdes et quatre fois plus rapides à charger, ce qui permet à l’internaute d’en consulter toujours plus, toujours plus vite.

Mais le World Wide Web Consortium (W3C), qui a en charge l’élaboration des normes du HTML et dont les travaux sont publics et les décisions consensuelles, est donc mis sur la touche au profit d’un standard parallèle, fait entre soi selon la règle du plus fort. Il y aura désormais d’un côté les pages HTML conformes aux recommandations du W3C, et de l’autre les mêmes pages HTML AMP conformes aux restrictions strictes imposées par le groupe.

Techniquement, ces dernières auront la même URL que les pages HTML normales, mais avec /amp/ à la fin.

Des scripts en liste blanche uniquement

Google ayant déjà commencé à proposer les pages AMP à ses utilisateurs dans les résultats de recherche, il n’est pas difficile d’imaginer que le HTML AMP deviendra vite incontournable, de gré ou de force. La plateforme WordPress.com, qui représente un quart des pages Web du monde, a annoncé aujourd’hui un plug-in pour rendre les pages de ses clients compatibles, et de nombreux sites majeurs ont aussi annoncé leur participation actuelle ou à venir.

Or l’une des caractéristiques techniques fondamentales de AMP est qu’il empêche le chargement de tout script JavaScript, sauf pour les quelques scripts préalablement validés par AMP Project. Il est possible aujourd’hui d’intégrer des messages Twitter, des posts Facebook ou des vidéos YouTube, mais pas encore des vidéos Dailymotion ou des documents Scribd. C’est donc un standard très contrôlé, qui ne permet pas aux éditeurs et aux développeurs d’innover librement.

Un risque que nous faisons prendre, par notre soif constante de gains de rapidité

L’intérêt premier est de limiter la taille des pages Web à charger bien sûr, pour tenter de satisfaire à l’impatience infinie de l’internaute et lui proposer un affichage quasi simultané, comme il peut l’avoir sur Apple News ou Facebook Instant. Mais l’intérêt est aussi voire surtout commercial. C’est une manière de contrôler certains marchés et leurs pratiques.

Ainsi pour afficher dynamiquement des publicités en HTML AMP, et mesurer leur audience, il faut obligatoirement passer par l’une des régies qui bénéficie d’un laisser-passer, parce qu’ils se conforment à des règles (là aussi opaques) : A9, AdReactor, Google AdSense, AdTech, et DoubleClick. Si vous êtes un éditeur Web et souhaitez utiliser votre propre ad-server ou celui d’une petite régie exclue du programme, c’est impossible.

Il est encore difficile de prédire l’impact que pourrait avoir le HTML AMP sur le Web, mais c’est en tout cas un risque certain pour la santé du réseau, et son ouverture. Un risque que nous faisons prendre, par notre soif constante de gains de rapidité. Vite. Toujours plus vite.

Article publié initialement le 25 février 2016

Partager sur les réseaux sociaux Tweeter Partager Partager Partager redditer

La suite en vidéo