Google a commencé à afficher les articles AMP en utilisant le nom de domaine d’origine du site web, et non son propre nom de domaine, alors que c'est bien le géant de la recherche qui héberge le contenu. La nouveauté est très limitée pour le moment : uniquement dans Chrome sur Android, uniquement pour les articles affichés depuis un résultat de recherche Google et uniquement pour les sites qui l’ont mis en place. Mais l’air de rien, ce changement remet en cause un principe fondamental du web.

AMP, pour « Accelerated Mobile Pages », est un projet créé par Google pour accélérer le web mobile avec des pages qui se chargent instantanément, ou presque (lire : AMP : Google veut des articles rapides sur les mobiles). Pour parvenir à un tel résultat, ce projet combine à la fois un langage spécifique qui permet de créer des pages allégées, et un cache qui stocke les articles directement sur les serveurs de Google. Le résultat est un chargement effectivement immédiat avec une bonne connexion internet, et beaucoup plus rapide avec une mauvaise connexion.

À cet égard, le pari de Google est réussi, mais AMP a été beaucoup critiqué ces dernières années, pour de multiples raisons. Bien que ce projet soit open-source, il est essentiellement contrôlé par la firme de Mountain View qui pèse de tout son poids pour forcer la main des publications à utiliser AMP (en modifiant ses résultats de recherche, par exemple), ce qui est un problème. Sur le plan pratique, de nombreux éditeurs se sont plaints du fait que leur nom de domaine était masqué et que celui de Google était affiché dans le navigateur. Google avait déjà répondu en partageant systématiquement l’URL originale, mais cela ne réglait rien en cas de copier/coller de l’adresse dans la barre d’URL du navigateur.

C’est un problème sur lequel Google travaille depuis plus d’un an et la solution va seulement être déployée à partir de maintenant. Il faut dire que c’est un problème difficile à résoudre : les articles AMP sont stockés sur les serveurs de Google, et donc servis avec une URL qui appartient à Google. Jusque-là, cela voulait dire que la page web était fournie par Google, on pourrait dire qu’elle appartient à Google. Sinon, imaginez la faille de sécurité potentielle : si n’importe quel site pouvait afficher le nom de domaine d’un autre site, il serait impossible de vérifier que l’on est sur le site officiel et pas victime de hameçonnage. C’est pourtant exactement ce qui va se passer avec les articles AMP : ils afficheront l’URL du site de base, mais ils seront toujours fournis par Google.

Pour ne pas créer d’énormes failles de sécurité, Google a mis au point une solution complète et complexe. L’idée est de créer une chaîne de confiance entre tous les acteurs impliqués, depuis le serveur qui héberge le contenu d’origine au navigateur qui va l’afficher, en passant par les serveurs intermédiaires qui vont stocker une copie en cache. C’est un petit peu le même principe que les DRM pour le streaming vidéo : tout le monde doit être au même niveau pour que la confiance soit établie et que le navigateur puisse afficher l’URL d’origine, et non celle de l’intermédiaire.

Si Google a pris son temps, c’est aussi parce que la solution proposée sera un nouveau standard du web que tout le monde pourra adopter. Les articles AMP seront fournis sous la forme de Signed HTTP Exchanges, un format qui s’intègre à webpackage. Ce projet du W3C décrit un standard pour empaqueter les sites web, par exemple pour fournir une archive complète d’une page ou d’un site, de quoi consulter son contenu sans connexion internet. Dans ce cadre, un mécanisme permet de vérifier que le paquet provient bien du site d’origine et c’est lui qui est à l’œuvre pour AMP.

Sans entrer dans les détails techniques, disons simplement que ce nouveau mécanisme implique des changements à tous les niveaux. Les navigateurs devront être mis à jour pour gérer correctement ces paquets et s’assurer que le contenu provient bien du site d’origine. Les créateurs de contenus devront également fournir les articles AMP sous la forme d’un paquet signé, ce qui nécessite d’installer un nouvel outil, de fournir son contenu en HTTPS avec un certificat d’un nouveau type¹ et, pour le moment au moins, de disposer de son propre serveur. Enfin, les intermédiaires, comme le cache de Google, devront eux aussi être mis à jour pour fournir les bonnes informations au navigateur.

Pour simplifier les choses et accélérer le déploiement de cette solution, Google a travaillé avec Cloudflare. Si vous êtes un client de ce fournisseur de services pour sites web, vous pouvez bénéficier dès aujourd’hui de ces articles AMP nouvelle génération, gratuitement et en cochant une seule case². L’entreprise va déployer progressivement la fonction au fil des prochaines semaines et ce sera certainement la solution la plus simple pour le moment. Naturellement, il faudra aussi attendre que les navigateurs soient mis à jour et on ne sait pas si Apple compte prendre en charge la nouveauté dans Safari.

AMP évolue sur un autre point, annoncé à l’occasion d’une conférence annuelle qui avait lieu hier au Japon. Outre cette nouveauté de fond sur l’URL présentée par le navigateur, Google va bientôt afficher les stories AMP dans ses résultats de recherche. Inspiré des stories de Snapchat, ce format permet de créer du contenu page par page, avec du texte, photos et autres vidéos.

Google affichera un bloc dédié à ces stories dans ses résultats de recherche mobile, avec une présentation très visuelle qui attirera sans doute beaucoup de visiteurs. Les optimistes y verront une nouvelle manière d’augmenter son trafic, les pessimistes un rouage de plus dans le piège mis en place par Google. Même si, comme tout ce qui concerne AMP, ces stories sont un format open-source que n’importe qui peut réutiliser s’il le souhaite…