EcoIndex : un outil de mesure du score environnemental des sites web

En 15 ans, le trafic Internet a été multiplié par environ 500 de 2002 à 2017. Les émissions de CO₂ associées ont été évaluées à 762 millions de tonnes en 2018. Imaginons donc qu’à l’image du Nutri-score, nous disposions, pour mesurer notre empreinte environnementale lorsque nous cliquons sur une page web, d’un outil permettant d’attribuer une note entre A et G à la requête HTTP.

Supposons également que ces requêtes soient archivées, année après année, dans une base de données publique comme le HTTParchive. En explorant régulièrement cette base, nous pourrions suivre l’évolution de l’empreinte environnementale des requêtes HTTP.

Aider le plus grand nombre à prendre conscience de l’impact environnemental d’Internet

C’est l’ambition que poursuit EcoIndex, créé en 2014 et qui fait référence à la fois à un ensemble de bonnes pratiques pour construire un site web et à un outil logiciel qui permet d’évaluer plusieurs facteurs pour une URL donnée : son efficacité environnementale absolue à l’aide d’une fonction de score sur une échelle de 0 à 100 (plus le score est élevé, meilleur c’est) ; sa performance écologique relative à l’aide d’une note allant de A à G comme ce que l’on connaît pour les dispositifs ménagers ou alimentaires (Nutri-Score) ; l’empreinte technique de la page (poids, complexité, etc.) ; et l’empreinte environnementale associée (gaz à effet de serre générés, ressources en eau consommées).

L’objectif de l’EcoIndex est d’aider le plus grand nombre à prendre conscience de l’impact environnemental des requêtes HTTP et de proposer des solutions concrètes pour le réduire. Si ce modèle fondé sur les métriques techniques de la page évoquées précédemment est plutôt simple à comprendre, il a aussi ses limites.

EcoIndex : évaluer l’empreinte environnementale d’une requête HTTP

Tentons d’abord de comprendre en quoi consiste ledit modèle. Il faut savoir qu’estimer l’empreinte carbone des activités humaines ne peut pas se faire directement : la méthode employée repose en général sur un modèle d’activité ciblée, relatif au domaine étudié. C’est le cas pour EcoIndex, qui ne concerne que les requêtes HTTP et pas l’ensemble des activités du web. Cette métrique s’appuie sur le concept « 3-tiers » qui considère trois paramètres : client, serveur et réseau.

La version « historique » d’EcoIndex consiste en un plug-in à installer sur le navigateur et fonctionne de la manière suivante : l’usager fournit une URL à EcoIndex, qui la transfère du côté serveur. Celui-ci retourne au navigateur une page HTML contenant les réponses à la requête. Le plug-in mesure l’empreinte de l’application, en nombre d’éléments de la page web (le nombre de balises HTML, noté dom), en nombre de requêtes dans la page renvoyée (requests) et enfin calcule le nombre d’octets de la page HTML retournée (size) et qui ont transité dans le réseau.

Ces valeurs sont introduites dans l’algorithme d’EcoIndex pour mesurer les performances et l’empreinte environnementale.

Le « modèle 3-tiers » et ses limites

L’analyse complémentaire d’un expert est indispensable pour une évaluation opérationnelle complète et fiable de la performance environnementale. En effet, EcoIndex ne prend pas en compte l’impact de l’ordinateur qui effectue la requête ou d’un parcours utilisateur. Seule une requête isolée de tout usage est analysée, comme le Nutri-score ou les machines à laver.

De même, quand la requête est résolue du côté du serveur dans un centre de données (par exemple chez Google quand l’URL est http://www.google.com, EcoIndex ne prend pas en compte l’impact environnemental de ce serveur au sens classique des analyses de cycle de vie (ACV), ni des différents équipements réseau qui sont traversés entre le terminal utilisateur et le centre de données.

Cependant, il permet de discuter des modèles et de leurs attributs qui caractériseraient de manière significative l’impact environnemental du web, réduit à la dimension des requêtes HTTP. Les autres côtés positifs d’EcoIndex sont que le chargement, la création et l’affichage de la page dans le navigateur ne sont pas simulés et que les trois paramètres dom, requests et size rendent compte d’une architecture qui gouverne le fonctionnement macroscopique d’une requête sur le web, donc EcoIndex fait sens.

Un outil aux calculs imparfaits

Dans le cadre du dispositif, la performance environnementale est calculée sur la base normalisée de valeurs constantes fixées une fois pour toutes et cachées dans le modèle sans tenir compte de variations dans le temps – par exemple d’une période à l’autre comme un confinement, des vacances, etc., ni de la localisation géographique de l’utilisateur.

De plus, ce ne sont pas directement les paramètres dom, requests et size qui sont considérés mais des valeurs correspondant à des quantiles, c’est-à-dire un petit nombre de valeurs qui ont été déterminées en récupérant les trois paramètres sur les URL d’une base de données d’URL qui fait référence, le HTTParchive.

On peut s’interroger sur la stabilité dans le temps de ces quantiles : sont-ils les mêmes en 2023 qu’en 2020, date de leur détermination pour l’EcoIndex historique ? A priori les sites web sont régulièrement revus pour adopter, au fil du temps, de meilleures pratiques d’écoconception – il n’y a pas de raison pour que les quantiles soient fixés une fois pour toutes.

Des notes arbitraires ?

Autre remarque mineure, pour certains sites comme ceux des grands média, qui sont dynamiques, la valeur d’Ecoindex a de grandes chances d’évoluer de jour en jour, mais sans doute pas de manière trop brutale en passant par exemple de la note de A à G.

En effet, un site web, même dynamique, respecte toujours peu ou prou le même gabarit constitué d’éléments modifiables (texte, images, fond, couleurs). On remplace un texte par un autre, une image par une autre, sans modifier fondamentalement les choses… Vis-à-vis de ce phénomène, EcoIndex nous semble robuste car ce « gabarit » ne change pas.

Cependant, les notes A-G correspondent aux plages d’EcoIndex 100-81 pour A, et 10-0 pour G, sans que l’on sache vraiment de quoi il s’agit : comment ces différentes bornes ont-elles été déterminées ? Équivalent-elles aux quantiles pour les mesures d’EcoIndex du HTTParchive ? Elles en sont proches mais ne coïncident pas exactement.

D’autres paramètres à introduire

Enfin, le modèle historique ne se prête pas, a priori, à l’introduction de nouveaux attributs autres que les 3-tiers dans le modèle.

Nous pourrions pourtant envisager d’y ajouter des notions de mix énergétique et proposer un nouvel indicateur EcoIndex+ qui fournit des notes tournées vers A pour les énergies décarbonées utilisées côté client et côté serveur et des notes autour de G si les énergies mises en jeu sont carbonées. Si la requête HTTP passe par un mobile 4/5G, on pourrait également agréger l’impact en CO₂ de l’opérateur, ce qui conduirait à une vision plus riche de l’EcoIndex+.

Pour être plus exhaustif dans les attributs à injecter dans EcoIndex+, il est nécessaire que la communauté s’accorde sur ces nouveaux critères et ensuite d’établir des méthodes de calcul capables de traiter un grand nombre d’attributs à l’aide de l’apprentissage automatique.

Un indicateur qui reste à améliorer

Sous l’angle des métriques d’impact environnemental et des bonnes pratiques d’écoconception des sites web, EcoIndex est une démarche simple qui participe à la compréhension des problématiques relatives à la place du numérique dans le réchauffement climatique. L’indicateur est particulièrement intéressant dans la logique d’amélioration des versions successives des sites web.

Du chemin reste cependant à parcourir pour, d’une part, approfondir nos connaissances et mieux saisir les relations entre les différents modèles de haut niveau de type architecture 3-tiers et les analyses de terrain de type cycle de vie d’un produit ou équipement numérique.

D’autre part, il conviendrait de questionner le modèle initial par des approches de sciences des données, c’est-à-dire, explorer ces dernières, les analyser pour obtenir une nouvelle métrique plus fine.

À propos des auteurs :
Denis Trystram. Professeur des universités en informatique, Université Grenoble Alpes (UGA).
Christophe Cérin. Professeur des universités, Université Sorbonne Paris Nord.
Laurent Lefèvre. Chercheur en informatique, Inria.
Cet article est republié à partir de The Conversation sous licence Creative Commons. Lire l’article original.