Une situation qui AMPire

Ça fait longtemps que je voulais écrire ce genre d’article, et Ethan Marcotte l’a bien mieux fait que moi dans AMPersand. En voilà donc une traduction.

Si vous avez déjà regardé le projet « Accelerated Mobile Pages » (AMP [1]) de Google, je suis sûr que vous serez d’accord : c’est génial d’entendre l’équipe d’AMP expliquer combien l’usage de leur framework (et l’hébergement des sites produits sur des serveurs possédés ou approuvés par Google) permet d’avoir des sites plus rapides et des utilisateurs plus satisfaits. Peu de corporations ont fait autant que Google pour souligner l’importance de la performance des pages dans la conception des sites, et le travail fait par l’équipe d’AMP ne fait pas exception à la règle.

Mais dans mon expérience, les seules voix à promouvoir les bénéfices de performance d’AMP viennent de chez Google. La plupart des compagnies à qui j’ai parlé ne voient pas « des utilisateurs plus satisfaits » ou « des pages plus rapides » comme étant le business case [2] pour AMP (en fait, certains ont même découvert que les pages AMP sont moins performantes que leur propre site).

[Note de traduction : une vidéo qui montre des résultats dans Google. On clique sur un lien mis en évidence, on n’atteint pas le site d’origine mais sa version AMP, hébergée chez Google.]

Pour les éditeurs de sites, choisir de négliger AMP signifie sacrifier une très forte visibilité dans les résultats de recherche de Google — dans les faits, ça revient à dire qu’ils sont forcés d’utiliser le format AMP de Google. En fait, un grand nombre de compagnies à qui j’ai parlé disent qu’ils constatent qu’une partie importante de leur trafic mobile vient d’AMP. Et ce nombre va très certainement augmenter, vu la position d’AMP dans les résultats de recherche mobile de Google.

Je ne suis vraiment pas sûr qu’AMP aurait été aussi largement adopté sans le bâton la carotte le bâton la carotte brandie par Google d’une meilleure visibilité dans les résultats de recherche. En fait, le placement d’AMP dans les résultats de Google crée un différentiel de pouvoir très, très faussé, entre ceux qui défendent l’usage d’AMP et ceux qui publient leur travail sur le Web ouvert. Et sachant que le revenu de la publicité en ligne baisse régulièrement depuis un moment, la plupart des compagnies qui s’appuient sur du contenu drainé par la publicité ne sont pas vraiment en capacité de s’opposer à Google.

De plus, la portée de AMP s’étend. On parle d’une variante en cours de préparation appelée « Stamp », une extension du framework qui fournirait une expérience de type Snapchat, favorable aux médias pour les éditeurs (et leurs publicitaires). Mais j’ai de bonnes raisons de croire que Google va positionner AMP en tant que framework générique de développement de sites, dans la lignée de Bootstrap ou de Foundation. Plutôt que de créer un flux séparé d’articles publiés au format AMP, hé bien, vous créeriez un site entier avec des CSS et un HTML estampillé AMP. Pour voir un exemple en action, jetez un œil sous le capot du site même du projet AMP. Si vous regardez sa source, vous noterez qu’il est plein d’éléments spécifiques à AMP, avec des balises comme <amp-sidebar>, <amp-accordion>, et <amp-img>. Chacun de ces éléments est stylé par CSS, décoré par Javascript, et mis en page par un design responsive (assez joli) — mais ils sont tous exprimés dans un standard de marquage propriétaire, défini presque exclusivement par les équipes de Google.

J’ai eu quelques conversations avec des membres de l’équipe Google AMP, et je crois sincèrement qu’ils veulent améliorer le Web. Mais vu comme les pages AMP sont privilégiées dans les résultats de Google, le bénéfice net du travail important et sérieux qu’a fourni l’équipe n’est perçu que comme une tentative de Google de réécrire le HTML à leur image. Maintenant, je ne sais pas si cette nouvelle mouture d’AMP aura du succès auprès des éditeurs. Mais ce que je sais, c’est qu’aucune compagnie ne devrait être en situation d’avoir autant d’influence sur l’évolution du Web.

Je ne suis pas le premier à exprimer des inquiétudes envers AMP. Et, franchement, mes réserves disparaîtraient si AMP n’était pas visible dans les résultats de Google même, comme le suggérait récemment Yehuda Katz. Cela mis à part, je ne peux m’empêcher de regretter que Google n’ait pas entrepris son « Projet Pages Mobiles Accélérées » différemment, par exemple sous forme de recommandations. Plutôt que de créer un langage HTML parallèle, et de tirer avantage des résultats de recherche de Google pour forcer son adoption, j’aurais aimé qu’AMP définisse un jeu de critères qu’on aurait pu valider avec, par exemple, le projet Lighthouse du même Google. Ce faisant, Google aurait donné aux éditeurs de sites les outils nécessaires pour s’assurer que leur travail est au niveau de ce que Google considère comme étant une expérience rapide et orientée mobile — sans pour autant sacrifier les standards, la décentralisation, la gouvernance autonome qui rendent le Web ouvert si puissant.

Je veux être bien clair : je pense qu’AMP est un framework qui a été conçu avec de bonnes intentions, pensé pour résoudre le vrai problème d’un Web devenu bien trop lent pour ses utilisateurs. Mais utiliser AMP ? Le prix pour le Web, et pour ceux qui y gagnent leur vie, est vraiment, vraiment trop important.

Remerciements à Mat Marquis, Jeff Lembeck, Karen McGrane et Scott Jehl pour avoir relu des ébauches de cet article.


AMPersand, original article by Ethan Marcotte, translated with authorisation. AMPersand, article original d’Ethan Marcotte, traduit avec son autorisation.

Notes

[1AMP : Pages Mobiles Accélérées.

[2Business case : raison d’être commerciale.

Commentaires

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides. Tous les liens sortants comporteront un attribut rel="nofollow". Merci de ne pas spammer.