Catégorie : Sobriété du web

Analyse des surconsommations d’un site sobre 

Posted on by Laurent DEVERNAY
Reading Time: 8 minutes

En mai 2024, sur le Slack des Designers Ethiques, Julien-Antoine Boyaval de l’agence web Konfiture partage un site réalisé pour Leroy Merlin. Le site en question (qui contient une seule page) est présenté comme écoconçu : https://lesdesignersdedemain.com/    

À première vue (via les outils du navigateur web), le site apparaît en effet plutôt léger. Toutefois, certains éléments attirent mon attention. Nous y reviendrons. 

Comme à mon habitude, je lance un benchmark avec Greenspector Studio afin d’aller plus loin.  

Analyser les surconsommations d’un site 

Les mesures ont été effectuées sur un téléphone Samsung Galaxy S9, en WIFI (3 itérations). 

Après mesure, les résultats confirment les soupçons initiaux :  

  • EcoScore : 61/100 (Réseau : 82, Client : 40) 
  • Données transférées : 292 ko 
  • Décharge totale de la batterie : 5,28 mAh 
  • Process CPU (1,11 %) 

Les données transférées sont effectivement faibles et, en conséquence, le score côté Réseau est très bon.  

Résultats du site d'origine via Greenspector Studio : Ecoscore à 61/100
Résultats du site d’origine via Greenspector Studio

En revanche, le score côté Client est bas, ce qui est corrélé avec une décharge élevée de la batterie et un impact CPU élevé (surtout pour une page statique et aussi légère). Généralement, ceci peut être dû à des services tiers, des animations voire des calculs (principalement JS) effectués en boucle.  

On commence par regarder ce qui se passe lorsque l’utilisateur est inactif, via Greenspector Studio :  

Observation via Greenspector Studio du CPU et des données transférées sur une étape de pause : 3 pics de données transférées, plusieurs de CPU
Observation via Greenspector Studio du CPU et des données transférées sur une étape de pause 

On remarque 3 pics de données qui sont probablement liés directement à Chrome (qui collecte des métriques d’usage et vérifie régulièrement les fonctionnalités proposées par la version du navigateur).  

Cette hypothèse fut par la suite étudiée via l’utilisation d’un proxy web (car les requêtes en question n’apparaissaient pas dans le navigateur). Ceci permit de confirmer que ces requêtes étaient bien liées à Chrome. 

Sur un site plus lourd, ces requêtes peuvent passer inaperçues mais pas ici.  

La méthodologie utilisée s’inspire de celle décrite ici : https://greenspector.com/fr/auditer-requetes-application-mobile-android/  

Mais il faut surtout s’interroger sur les fluctuations fortes du CPU. Il y a bien quelques animations sur le site mais la plupart ne sont déclenchées qu’au scroll. Elles ne devraient donc pas directement impacter le processeur lorsque l’utilisateur est inactif et les animations non-déclenchées. 

Nous nous replions donc vers l’outil Performance des outils de développeur de Chrome : https://developer.chrome.com/docs/devtools/performance?hl=fr  

Observation via l’outil Performance de Chrome d’une étape de pause : plusieurs solicitations dues aux animations.
Observation via l’outil Performance de Chrome d’une étape de pause 

En regardant ce qui se passe pendant 10 secondes d’inactivité, on constate que le processeur est très sollicité avec de très nombreux événements à traiter en continu. Rapidement, il apparaît de nombreux traitements JS (d’écoute ou d’observation) guettant certaines interactions de l’utilisateur pour déclencher les animations.  

Tout ceci est géré par une librairie très utilisée : GSAP.  

Arrivé là et avant d’aller plus loin, j’ai contacté Julien-Antoine directement afin de planifier un moment pour présenter mes constats à son équipe.  

Après quelques échanges, il apparaît intéressant de travailler ensemble sur ce sujet. L’objectif est de voir comment réduire les impacts de la page via de l’analyse et des mesures. Pour cela, nous décidons de procéder de façon itérative : proposer une première liste de préconisations et les appliquer une par une pour pouvoir estimer l’impact de chacun par de la mesure.  

Expérimentations autour du site 

Dans un premier temps, il faut s’assurer que le badge affiché sur le site, provenant de Website Carbon Calculator n’est pas en cause (ce qui serait un comble). Pour cela, un tel badge est intégré sur une page HTML vide pour être mesuré via un benchmark.  

L’EcoScore est de 95, les données transférées très faibles (un simple script JS de moins de 2 Ko qui récupère en une seule fois tout le nécessaire pour l’affichage) et l’impact sur le processeur négligeable (autour de 0,25% de sollicitation CPU).  

Le badge est donc hors de cause.  

En parallèle, l’équipe côté Konfiture déploie le site que nous voulons étudier sur un serveur à part qui accueillera les différentes versions réalisées. Une première mesure est effectuée pour constituer le point de référence pour la suite, certaines métriques pouvant varier en fonction des conditions d’hébergement du site.  

La première version mesurée s’affranchit de la librairie Lenis qui gère en partie les animations.  

La version 1.0.2 correspond à l’optimisation plus poussée des SVG (images vectorielles). Il en résulte une légère réduction des données transférées. 

La version 1.0.3 ajoute le chargement progressif natif pour les SVG ainsi que la mise en place d’un CDN et de la compression (brotli) des fichers texte (dont SVG). Il en résulte une réduction notable des données transférées.  

La version 1.0.5 supprime toutes les animations. Pour le client final, ceci n’est pas envisageable car les animations sont jugées essentielles afin de rendre le site plus attractif. Mais, une fois les autres éléments optimisés, cette mesure nous donne une cible à atteindre. Ici, on constate une réduction des données transférées (moins de JS nécessaire) mais surtout de la sollicitation CPU (qui reste l’une des métriques les plus affectées par les animations du fait des calculs nécessaires). 

Pour aller plus loin sur ce sujet, je vous renvoie vers deux autres articles du présent blog :  

La version 1.0.6 s’affranchit de tout code JS pour gérer les animations. Le souci qui apparaît alors est que les animations se font en continu. Même si, à l’usage, cette approche est moins impactante pour le processeur (ce qui est aisément vérifiable via l’outil Performance de Chrome), elle dégrade l’expérience utilisateur et pose problème pour l’accessibilité (critère 13.8 du Référentiel Général d’Amélioration de l’Accessibilité : https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/#13.8). 

Après discussion sur le sujet, ce point apparaît rédhibitoire. Si la gestion des animations seulement en CSS est un bon compromis pour les impacts environnementaux, la dégradation de l’accessibilité doit être évitée. 

Les premiers résultats ne correspondent pas exactement à ce qui est attendu. Il est apparu après analyse que le fait d’avoir des animations en continu venait entraver la détection d’inactivité lors des mesures et prolonger artificiellement la durée de scroll.  

En conséquence, la version 1.0.7 propose déjà une première piste : s’appuyer sur le paramètre prefers-reduced-motion du navigateur pour, a minima, désactiver les animations pour les utilisateurs qui le souhaitent. A défaut de pouvoir désactiver la lecture automatique des animations, il faudrait (pour être conforme) réduire leur durée à moins de 5 secondes (voire 4 si on se conforme au critère 4.1 du RGESN : https://www.arcep.fr/mes-demarches-et-services/entreprises/fiches-pratiques/referentiel-general-ecoconception-services-numeriques.html#c36264 ) et/ou proposer un moyen de contrôle afin de les mettre en pause. Ce point reste en discussion. 

Afin d’aller plus loin, la version 1.08 cherche à concilier écoconception et accessibilité. Pour cela, il a été décidé de limiter la durée des animations et, en conséquence, de ne les déclencher qu’au scroll afin de s’assurer qu’elles soient malgré tout visibles.  

Résultats obtenus 

Les résultats suivants sont obtenus via les mesures au fil de l’eau :  

Résultats des mesures : la page sans animations est la moins impctante, suivie par celle où celles-ci sont déclenchées au scroll.
Résultats des mesures pour les différentes versions

Projection environnementale pour les différentes versions : le classement reste sensiblement le même que pour les mesures, le plus avantageux restant de ne pas utiliser d'animations.
Projection environnementale pour les différentes versions 

Au préalable, il convient ici de rappeler que l’impact sur le CPU, la mémoire mais aussi la décharge de batterie dépendent fortement du modèle d’appareil utilisé pour la mesure mais peuvent aussi varier entre deux appareils du même modèle. C’est pour cela que chaque mesure comprend également une étape de référence non-affichée ici. Pour des pages web, cette étape de référence consiste à mesurer ce qui se passe lorsque l’utilisateur est inactif sur un onglet de Chrome affichant une page entièrement noire (impact énergétique minimal, notamment par rapport à l’onglet vide de Chrome qui est très clair donc plus impactant si on utilise un appareil avec un écran OLED).  

Résultats pour la version finale du site (EcoScore à 70/100)
Résultats pour la version finale du site

Les mesures sur des sites aussi légers sont souvent plus compliquées car les écarts et surconsommations peuvent être légers voire difficiles à distinguer d’artefacts de mesure, par exemple. Parfois, il est possible de contourner cela en adaptant la méthodologie. Par exemple, pour mesurer un composant très léger, on l’intègre 100 ou 1000 fois sur la page et on procède de même avec d’autres composants que l’on voudrait comparer. 

L’augmentation de la durée de scroll suite à l’application en continu des animations a provoqué un allongement conséquent de la durée de scroll (17 secondes au lieu de 6), ce qui augmente directement l’impact énergétique et les impacts environnementaux.  

Pour des sites aussi légers, les requêtes “parasite” de Chrome (télémétrie, vérification des variantes) apparaissent d’autant plus impactantes, même si seulement quelques Ko ou dizaines de Ko de données sont transférés.  

Dans le cas qui nous intéresse ici, la meilleure solution pour pouvoir limiter les impacts de l’intégration des animations correspond à la version 1.0.8. Cette dernière bénéficie de l’implémentation des bonnes pratiques suivantes :  

  • Optimisation poussée des SVG (notamment via la compression et le lazy-loading) 
  • Limiter la durée des animations, les stopper pour les utilisateurs en faisant le choix et ne les déclencher qu’au scroll. 

Au global, sur le nombre de requêtes et les volumes de données transférées, les gains sont indéniables (même si le site était à la base très léger). 

Concernant la vitesse de décharge de batterie, les gains ne sont pas négligeables. Même si les impacts environnementaux et la consommation d’énergie apparaissent au global identiques voire légèrement plus élevée (à cause de l’augmentation de la durée de scroll), les résultats sont encourageants.  

Conclusion 

Comme déjà souligné dans l’article sur les sites sobres, l’estimation de la sobriété d’un site est complexe car elle prend en compte de nombreux facteurs mais aussi une méthodologie particulière. Même sur un site annoncé comme sobre, il reste souvent des améliorations à mettre en place (même si toutes ne valent pas forcément le coup).  

Une fois n’est pas coutume, le sujet des animations revient. Parfois utilisées pour compenser la réduction du nombre d’images, elles sont très souvent impactantes, même si les outils gratuits occultent cet impact (en se concentrant sur les transferts de données effectués lors du chargement de la page). Lorsque, comme ici, on veut aller plus loin pour les intégrer de façon aussi efficiente que possible, les résultats ne sont à ce jour pas forcément concluants. La priorité devrait être la frugalité (s’affranchir des animations) puis la sobriété (en réduire le nombre) et enfin l’efficience (optimiser leur intégration). Toutefois, notamment pour des raisons d’accessibilité, leur utilisation devrait être proscrite (mais aussi en s’appuyant sur le critère 4.1 du RGESN).  

Pour ce qui est de l’intégration efficiente des animations, tout reste à faire. Ce chantier est très complexe à aborder car les métriques à prendre en compte sont nombreuses et complexes à mesurer et comparer (CPU, GPU, décharge de batterie, etc). Ajoutez à cela les risques de transfert d’impact (opter pour du CSS plutôt que du JS ou inversement) et vous aboutissez à un sujet technique pour le moins épineux. Toutefois, on note ici que la limitation de leur durée, couplée à des logiques simples pour leur déclenchement, apporte les meilleurs résultats. 

Aujourd’hui, les référentiels et connaissances permettent d’énoncer comment rendre conforme une animation du point de vue de l’accessibilité. Pour l’écoconception, ce n’est pas encore le cas (même si le RGESN propose des pistes). Il n’y a pas (à ma connaissance) de solution universelle pour proposer des animations qui n’entraînent pas de surconsommation. 

D’un point de vue très pragmatique, il convient donc de revenir à une approche simple mais importante : évitez autant que possible l’intégration d’animations, aussi bien pour des raisons d’accessibilité que d’écoconception (et plus généralement d’expérience utilisateur).  

Greenspector Studio et RGESN 

Posted on by Laurent DEVERNAY
Reading Time: 10 minutes

L’arrivée de la version finale du RGESN (Référentiel général d’écoconception de service numérique) pose plus que jamais la question de comment valider les différents critères. Il est parfois reproché à ces derniers d’être trop déclaratifs voire pas assez précis.

Nous aborderons ici les apports des outils de Greenspector Studio sur ces sujets. La possibilité d’intégrer ces outils à une PIC (Plateforme d’Intégration Continue) aide alors à aller vers de l’amélioration continue voire vers l’automatisation (forcément partielle) du contrôle de conformité. La validation exhaustive de la plupart des critères ne pourra pas être automatisée, de même que pour l’accessibilité numérique. Toutefois, il est souhaitable d’automatiser tout ce qui peut l’être, ne serait-ce que pour remonter des alertes en cas de dégradation.

Via cette démarche de vérification de la conformité par la mesure, nous verrons se dessiner une véritable stratégie de mesure.

Nous distinguerons par la suite deux types de critères :

  • Ceux qui nécessitent de la mesure pour être validés
  • Ceux pour lesquels la mesure permet d’aller plus loin et notamment au-delà du simple déclaratif

Préambule

Il est important avant toute chose de bien définir ce qu’est le périmètre de l’audit RGESN. Comme le nom l’indique, il est ici question d’un service numérique. Si cette notion n’est pour l’instant pas précisément définie dans le référentiel, il s’agit a priori d’un applicatif (site web, application mobile ou autre) qui sera audité, ainsi que l’ensemble de ses parcours utilisateurs représentatifs et fonctionnalités.  

Cette précision est importante pour la mesure, afin de savoir s’il faut opter pour une mesure simple d’un échantillon d’écrans ou d’usages représentatifs (de type benchmark) ou pour un parcours utilisateur. 

La définition de cet échantillon s’appuie souvent sur la liste des fonctionnalités mises à disposition ainsi que sur des statistiques d’usage.  

Si un même service (faire des achats en ligne, consulter son compte en banque, regarder des vidéos, etc) se décline en plusieurs applicatifs (site web, application Android, application iOS), chaque applicatif devra faire l’objet d’un audit.  

Si un applicatif comporte plusieurs parcours représentatifs, ils devront tous être pris en compte au cours de l’audit.  

Il est possible de regarder ce qui se fait du côté de l’accessibilité pour aller plus loin sur le sujet de cette constitution d’échantillon : https://accessibilite.numerique.gouv.fr/obligations/evaluation-conformite/  

Critères reposant sur de la mesure 

1.4 – Le service numérique réalise-t-il régulièrement des revues pour s’assurer du respect de sa démarche d’écoconception ? 

Il est question ici de prévoir une revue régulière via le RGESN, accompagnée d’audits de performance et de tests de charge.  

Greenspector Studio permet aussi, en particulier via les mesures de parcours, de suivre la performance (en plus de l’énergie, des données transférées et des indicateurs environnementaux). La mesure d’écrans via l’outil de benchmark permet de vérifier automatiquement le respect de bonnes pratiques techniques. La mesure régulière sur les parcours et écrans identifiés peut donc permettre de valider en partie ce critère.  

1.5 – Le service numérique s’est-il fixé des objectifs en matière de réduction ou de limitation de ses propres impacts environnementaux ?  

Il sera ici possible de lister et suivre régulièrement différents indicateurs environnementaux. La méthodologie d’évaluation est disponible publiquement : https://greenspector.com/wp-content/uploads/2024/05/Methodology_Greenspector_full_EN-Version-202405.pdf [PDF, 1,1 Mo, en anglais] 

Sur chaque projet, les objectifs de réduction sont généralement définis dès les premières mesures, notamment via un budget environnemental. Nous y reviendrons dans un prochain article. 

2.9 – Le service numérique a-t-il pris en compte les impacts environnementaux des composants d’interface prêts à l’emploi utilisés ? 

La mesure des différents composants ou intégrations d’un même composant permet de comparer directement les résultats. Le dashboard proposé via Greenspector Studio ainsi que des fonctionnalités de l’atelier de mesure permettent une comparaison directe selon divers paramètres.  

Il est possible pour cela d’imaginer une méthodologie proche de celle qui avait été utilisée précédemment pour comparer le poids des éléments d’une page web : https://greenspector.com/fr/reduire-poids-page-web-quels-elements-plus-impactants/  

2.10 – Le service numérique a-t-il pris en compte les impacts environnementaux des services tiers utilisés lors de leur sélection ? 

La démarche est ici similaire à ce qui a été présenté ci-dessus pour les critères 2.8 et 2.9. En complément (nous y reviendrons plus loin), l’outil benchmark permet la vérification automatique de certaines bonnes pratiques techniques, ce qui peut être un gain de temps pour la validation de certains critères du RGESN (en particulier lorsqu’il est question de compression, de chargement progressif et autres).  

3.1 – Le service numérique repose-t-il sur une architecture, des ressources ou des composants conçus pour réduire leurs propres impacts environnementaux ? 

Via Greenspector Studio, différents composants ou choix d’intégration peuvent être comparés par la mesure, notamment via du A/B Testing ou du feature flipping.  

4.3 – Le service numérique optimise-t-il le parcours de navigation pour chaque fonctionnalité principale ? 

Comme indiqué dans les moyens de test et de contrôle pour ce critère, des indicateurs techniques doivent être définis pour les parcours identifiés. Il est alors souhaitable de définir un budget environnemental ainsi qu’une fréquence de mesure afin de suivre leur évolution dans le temps.  

4.4 – Le service numérique permet-il à l’utilisateur de décider de l’activation d’un service tiers ? 

La mesure est ici nécessaire pour renseigner le possible coût environnemental d’un service tiers. 

Selon le cas, il sera possible d’automatiser l’activation du service-tiers ou de mesurer ses impacts lors de phases d’inactivité de l’utilisateur. En complément, le feature flipping permet d’isoler l’impact de certains composants et services tiers. 

4.5 – Le service numérique utilise-t-il majoritairement des composants fonctionnels natifs du système d’exploitation, du navigateur ou du langage utilisé ? 

Les composant fonctionnels non-natifs et natifs doivent être comparés et suivis via les ressources chargées et l’utilisation effective de celles-ci.  

4.8 – Le service numérique limite-t-il le nombre des polices de caractères téléchargées ?  

Le nombre des polices chargées et surtout leur poids doivent être vérifiés (et dans l’idéal suivis dans le temps), ce qui est possible via de la mesure. 

4.9 – Le service numérique limite-t-il les requêtes serveur lors de la saisie utilisateur ?   

Via un parcours automatisé, il est possible de reproduire la saisie par un utilisateur et, ainsi, de vérifier par la mesure que les requêtes générées respectent bien les seuils imposés par le RGESN (volume de données transférées et délai entre deux requêtes).  

4.10 – Le service numérique informe-t-il l’utilisateur du format de saisie attendu, en évitant les requêtes serveur inutiles pour la soumission d’un formulaire ?    

Via l’automatisation de la saisie d’un formulaire, il est possible de vérifier que les éléments renseignés sont bien contrôlés côté client avant envoi. 

4.12 – Le service numérique indique-t-il à l’utilisateur que l’utilisation d’une fonctionnalité a des impacts environnementaux importants ?  

Pour pouvoir informer l’utilisateur des impacts environnementaux d’une fonctionnalité, il est nécessaire d’évaluer ceux-ci via de la mesure. 

4.15 – Le service numérique fournit-il à l’utilisateur un moyen de contrôle sur ses usages afin de suivre et de réduire les impacts environnementaux associés ? 

L’affichage des impacts environnementaux ainsi que l’évaluation des gains associés à des possibilités de paramétrage nécessitent de la mesure.  

6.1 – Le service numérique s’astreint-il à un poids maximum et une limite de requête par écran ? 

La mesure est essentielle pour définir les seuils (en se basant sur le service existant et/ou sur des services similaires). En complément, il est important ici de suivre ces valeurs dans le temps. 

Critères pour lesquels la mesure est préférable 

2.1 – Le service numérique a-t-il défini la liste des profils de matériels que les utilisateurs vont pouvoir employer pour y accéder ? 

Afin de valider ce critère, il est a minima attendu une liste des profils en question.  

Toutefois, il est important ici de creuser davantage la notion d’utilisabilité en s’appuyant sur des mesures. En particulier, il peut s’agir de mesurer sur un échantillon de terminaux anciens pour quantifier l’impact sur la performance et l’énergie. Ainsi, la définition d’utilisabilité peut être précisée via ce qu’on considère comme une dégradation acceptable par rapport au cas nominal.  

Ceci peut être fait de façon très basique : “sur tel terminal ancien, le parcours utilisateur peut bien être réalisé de bout en bout”.  

Ou de façon plus poussée : “sur tel terminal ancien, le parcours utilisateur est effectué en moins de X minutes et la décharge de la batterie est inférieure à  X mAh”. 

Ces seuils peuvent être déterminés par rapport au cas nominal. Par exemple, on peut s’imposer que le parcours soit au maximum deux fois plus long ou deux fois plus impactant pour la batterie.  

Greenspector Studio permet cela, notamment via la mise à disposition de terminaux aujourd’hui jugés comme anciens :  

  • Le téléphone Samsung S7 date de 2016, le S9 de 2018 
  • Selon les modèles, la tablette Pixel C date de 2016 ou 2017 

Il est possible d’imaginer une démarche similaire pour les ordinateurs.  

2.2 – Le service numérique est-il utilisable sur d’anciens modèles de terminaux ? 

Voir critère 2.1. 

2.3 – Le service numérique est-il utilisable via une connexion bas débit ou hors connexion ? 

Pour les mesures avec Greenspector Studio, il est possible via le banc de mesure d’utiliser une connexion similaire à de la 3G. 

Il est tout à fait envisageable de s’adapter pour réaliser des mesures hors connexion.  

2.5 – Le service numérique s’adapte-t-il à différents types de terminaux d’affichage ? 

Les mesures via Greenspector Studio permettent de vérifier que le parcours utilisateurs s’effectue correctement sur un ensemble de terminaux. En complément, des captures d’écran sont réalisées au début et à la fin de chaque étape de mesure, ce qui permet de contrôler la qualité de l’affichage. 

2.7 – Le service numérique a-t-il prévu une stratégie de maintenance et de décommissionnement ? 

La mesure permet ici, comme demandé dans le RGESN, de documenter les résultats de la stratégie de maintenance et de décommissionnement (en particulier dans le cas des fonctionnalités) via les gains obtenus selon différentes métriques ou indicateurs. 

2.8 – Le service numérique impose-t-il à ses fournisseurs de garantir une démarche de réduction de leurs impacts environnementaux ? 

La mesure permet de valider les engagements des fournisseurs, en leur transmettant les métriques et indicateurs obtenus, un dashboard détaillé voire les résultats de la vérification automatique de bonnes pratiques techniques (via un benchmark de page). 

4.1 – Le service numérique comporte-t-il uniquement des animations, vidéos et sons dont la lecture automatique est désactivée ? 

Sur les écrans et étapes contenant de tels éléments, l’impact sur les données transférées, la décharge de la batterie et le CPU sont directement identifiables via les outils Greenspector Studio.  

Si nécessaire, des mesures en A/B Testing permettent de quantifier directement les gains liés à la désactivation de la lecture automatique. 

4.2 – Le service numérique affiche-t-il uniquement des contenus sans défilement infini ? 

Voir critère 4.1. 

4.13 – Le service numérique limite-t-il le recours aux notifications, tout en laissant la possibilité à l’utilisateur de les désactiver ? 

Les mesures via Greenspector Studio peuvent permettre de détecter et quantifier les surconsommations liées aux notifications. Les captures d’écran effectuées automatiquement en cours de mesure permettent d’identifier les notifications en question. 

5.1 – Le service numérique utilise-t-il un format de fichier adapté au contenu et au contexte de visualisation de chaque image ? 

La mesure, en particulier des données transférées, permet de détecter les images les plus volumineuses ainsi que l’impact du téléchargement d’un fichier. Partant de là, il est possible d’analyser de façon plus poussée ces surconsommations afin d’identifier si elles sont liées à leur format, leur compression ou leur redimensionnement dans le navigateur. 

5.2 – Le service numérique propose-t-il des images dont le niveau de compression est adapté au contenu et au contexte de visualisation ? 

Voir critère 5.1. 

5.3 – Le service numérique utilise-t-il, pour chaque vidéo, une définition adaptée au contenu et au contexte de visualisation ? 

Les éléments présentés plus haut pour le critère 5.1 peuvent tout à fait s’adapter pour d’autres types de contenus (vidéo et audio), en particulier pour ce qui est du format et du niveau de compression. En complément, pour ces médias, la mesure permet d’identifier les préchargements (qui sont là aussi à éviter, comme stipulé dans le critère 6.5 mentionné plus loin). 

5.4 – Le service numérique propose-t-il des vidéos dont le mode de compression est efficace et adapté au contenu et au contexte de visualisation ? 

Voir critère 5.3. 

5.5 – Le service numérique propose-t-il un mode « écoute seule » pour ses vidéos ? 

Via la mesure, il est possible de quantifier les gains résultant de l’utilisation du mode “écoute seule”. 

5.6 – Le service numérique propose-t-il des contenus audios dont le mode de compression est adapté au contenu et au contexte d’écoute ? 

Voir critère 5.3. 

5.7 – Le service numérique utilise-t-il un format de fichier adapté au contenu et au contexte d’utilisation pour chaque document ? 

Voir critère 5.3. 

En complément, la mesure permet de comparer différentes modalités de mise à disposition d’un document en évaluant les impacts environnementaux selon différents cas d’utilisation possible (ouverture sur téléphone, en connexion dégradée, etc). 

6.2 – Le service numérique utilise-t-il des mécanismes de mise en cache pour la totalité des contenus transférés dont il a le contrôle ? 

Il est ici plus simple de vérifier la stratégie de cache par de la mesure (notamment en comparant les résultats obtenus lors du premier chargement avec les chargements ultérieurs voire lors de la poursuite de navigation sur d’autres pages). En complément, l’outil benchmark de Greenspector Studio vérifie automatiquement l’intégration des entêtes liées au cache.  

6.3 – Le service numérique a-t-il mis en place des techniques de compression pour les ressources transférées dont il a le contrôle ? 

Les surconsommations liées à la non-mise en place de la compression sont détectables via la mesure des données transférées (et indirectement de la performance). Via l’outil benchmark de Greenspector Studio, les éléments non-compressés sont automatiquement détectés et listés.  

Vérification automatique des bonnes pratiques liées à la compression dans l’atelier de mesure Greenspector Studio
Vérification automatique des bonnes pratiques liées à la compression dans l’atelier de mesure Greenspector Studio

6.4 – Le service numérique affiche-t-il majoritairement des images dont les dimensions d’origine correspondent aux dimensions du contexte d’affichage ? 

Les surconsommations liées au redimensionnement des images dans le navigateur sont détectables via la mesure des données transférées (et indirectement de la performance). Via l’outil benchmark de Greenspector Studio, les images concernées sont automatiquement détectées et listées. 

Vérification automatique des bonnes pratiques liées au non-redimensionnement des images dans le navigateur dans l’atelier de mesure Greenspector Studio.
Vérification automatique des bonnes pratiques liées au non-redimensionnement des images dans le navigateur dans l’atelier de mesure Greenspector Studio.

6.5 – Le service numérique évite-t-il de déclencher le chargement de ressources et de contenus inutilisés pour chaque fonctionnalité ? 

Les surconsommations liées au chargement de ressources inutilisées sont détectables via la mesure des données transférées (et indirectement de la performance). En complément, via l’outil benchmark de Greenspector Studio, les images qui ne bénéficient pas du lazy-loading (chargement progressif) sont automatiquement détectées et listées. 

6.7 – Le service numérique héberge-t-il toutes les ressources statiques transférées dont il est l’émetteur sur un même domaine ? 

L’outil benchmark de Greenspector Studio liste automatiquement la liste d’éléments statiques chargés depuis un domaine nécessitant l’envoi de cookies, ce qui facilite l’identification des domaines. 

Construire sa stratégie de mesure 

Dans l’optique d’un audit de conformité au RGESN (et pour son suivi dans temps), il apparaît donc essentiel de mettre en place des mesures. Ceci implique forcément de définir une stratégie de mesure composée des éléments suivants :  

  • Les éléments mesurés : pages ou parcours représentatifs 
    • Pour couvrir l’ensemble des fonctionnalités principales 
    • En se basant sur les statistiques d’usage 
    • Avec un échantillon suffisamment large pour être pertinent 
  • Les indicateurs collectés, en s’assurant d’avoir aussi bien des métriques techniques (mesurées directement) et des indicateurs environnementaux (donc calculés). Tout en mentionnant bien la méthodologie de projection environnementale. 
  • Associés à tout ou partie de ces indicateurs, un budget environnemental avec deux approches complémentaires : 
    •  L’ambition : les valeurs que l’on veut atteindre 
    • Le palier : les valeurs qui permettent d’identifier des régressions via une dégradation trop importante 
  • Les appareils sur lesquels on souhaite mesurer :  
    • Des appareils représentatifs de ceux majoritairement utilisés par les usagers du service audité. Tout en s’assurant si possible de vérifier ainsi l’adaptation du service numérique au terminal d’affichage 
    • Des appareils plus anciens pour les critères liés à l’inclusion 
  • Les types de connexion à internet (avec un cas nominal mais aussi un cas dégradé pour le critère 2.3) 
  • La fréquence de mesure : 
    • Relativement élevée pour les conditions nominales, afin de suivre l’évolution dans le temps, quantifier les améliorations et détecter les dégradations 
    • Éventuellement plus espacés pour les tests sur terminaux anciens et/ou en connexion dégradée

Conclusion 

Comme souvent dans une démarche de vérification de la conformité, il est impossible de vérifier automatiquement tous les critères. Toutefois, sur les 78 critères actuellement présentés dans le RGESN : 

  • 14 nécessitent des mesures 
  • 21 devraient s’appuyer sur des mesures, notamment pour appuyer la déclaration sur des indicateurs chiffrés et vérifiables 

Au total, ce sont donc presque la moitié des critères qui peuvent (ou doivent) s’appuyer sur des mesures.  

Au-delà de la vérification ponctuelle de conformité, ces mesures devraient être automatisées dans une logique d’amélioration continue.  

Tout ceci est évidemment possible avec Greenspector Studio. 

L’arrivée du RGESN et la volonté de l’appliquer aussi largement que possible renforcent notre conviction de concilier bonnes pratiques et mesures afin de réduire les impacts (notamment environnementaux) des services numériques.  

RGESN / loi REEN : de quoi parle-t-on ? 

Posted on by Laurent DEVERNAY
Reading Time: 12 minutes

Le sujet des impacts environnementaux du numérique ne cesse de prendre de l’ampleur depuis quelques années. En particulier en France, où il bénéficie de la mise en place rapide d’un contexte légal structurant. Celui-ci avait été abordé dans un autre article du blog de Greenspector : https://greenspector.com/fr/le-cadre-legislatif-de-lecoconception-de-services-numeriques/  


En tant qu’entreprise cherchant à réduire les impacts environnementaux et sociétaux du numérique, Greenspector a forcément à cœur d’explorer en détail ce sujet. Nous vous proposons donc ici de reprendre brièvement la loi REEN (Réduction de l’empreinte environnementale du numérique) pour ensuite nous intéresser au RGESN (Référentiel général d’écoconception de services numériques). 

Cadre de la loi REEN 

La loi REEN impose aux villes et intercommunalités de plus de 50 000 habitants de définir leur stratégie liée au Numérique Responsable d’ici 2025. Celle-ci inclut nécessairement des éléments liés à l’écoconception de services numériques. Toutefois, les collectivités se retrouvent souvent confrontées à un premier obstacle : le sujet de l’écoconception de services numériques est encore relativement récent. Ainsi, il peut être difficile de s’y retrouver, qu’il s’agisse de choisir un outil de mesure ou un guide ou référentiel permettant d’avancer efficacement sur le sujet.  

C’est pourquoi un autre volet de la loi REEN est attendu de pied ferme par beaucoup : la définition des obligations légales d’écoconception de services numériques. Celle-ci devrait se faire sous la forme de 2 items :  

  • Le RGESN que nous allons voir plus en détail dans cet article 
  • Un décret d’application qui définit qui est soumis à ces obligations et avec quelles contraintes (quels types de services numériques, quels délais pour la mise en œuvre, quels livrables attendus, etc.).  

Le référentiel pour tous les lier : le RGESN 

Ses origines 

En 2020, l’INR (Institution du Numérique Responsable) réunit une centaine (!) d’experts pour travailler sur un référentiel pour l’écoconception des services numériques. L’objectif : offrir des recommandations qui couvrent tous types de services numériques, sur toutes les étapes du cycle de vie et pour toutes les personnes impliquées. Bref, une approche holistique. Le chantier est colossal mais approche de l’arrivée à l’été 2021. Il donnera naissance au GR491, qui compte aujourd’hui 61 recommandations et 516 critères. Il devrait prochainement être une fois de plus mis à jour. Il constitue à ce jour une référence unique au monde sur laquelle s’appuyer.  

Juste avant la mise en ligne de ce référentiel, la DINUM (Direction interministérielle du numérique) intervient. Son objectif est simple et tout à fait pertinent : s’appuyer sur les travaux réalisés pour pouvoir construire son propre référentiel. C’est ainsi que, à l’automne 2021, deux référentiels voient le jour : le GR491 et le RGESN.  

Le RGESN a déjà été décliné en deux versions : la première proposée par la DINUM puis une nouvelle version proposée en consultation publique par l’ARCEP (Autorité de régulation des communications électroniques, des postes et de la distribution de la presse) fin 2023.  

La version finale a été mise à disposition le 17 mai 2024.  

Son rôle 

Les versions existantes du RGESN référentiel soulignent déjà ses spécificités. Dans le cas de l’accessibilité, le RGAA (Référentiel général d’amélioration de l’accessibilité) permet de contrôler l’accessibilité d’un service numérique en s’appuyant sur des critères issus des WCAG (Web Content Accessibility Guidelines) émises par le W3C (World Wide Web Consortium). Le cadre légal français impose de plus d’afficher la conformité notamment via une déclaration d’accessibilité mais aussi de publier un schéma pluriannuel de mise en accessibilité numérique de l’entité. Tous ces éléments sont consultables ici : https://accessibilite.numerique.gouv.fr/  

Dans le cas du RGESN, la notion de déclaration d’écoconception est incluse directement dans le référentiel et son contenu détaillé au fil des critères. En revanche, ce référentiel ne s’appuie pas sur un référentiel international. En effet, les WSG (Web Sustainability Guidelines : Web Sustainability Guidelines (WSG) 1.0 [EN]) ont été publiées par le W3C après le RGESN. En conséquence, les WSG s’appuient en partie sur le RGESN et non l’inverse.  

Dans le cas du RGESN, l’ambition n’est pas tant de “vérifier” qu’un service numérique est écoconçu que de vérifier qu’une démarche d’écoconception a bien été mise en place. Il devient ainsi possible d’embarquer toutes les parties prenantes sur le sujet (y compris l’hébergeur, les fournisseurs de services tiers mais aussi questionner la stratégie voire le modèle économique) et de s’inscrire dans une démarche d’amélioration continue. Cette approche est ambitieuse mais aussi liée au fait qu’il est compliqué voire impossible d’établir factuellement (via des critères purement techniques) si un service numérique est écoconçu ou non. Il s’agit plutôt de s’assurer qu’il s’inscrit bien dans une démarche d’écoconception.  

Son contenu 

La V1 (celle de la DINUM) 

Dans sa première version, le RGESN propose 79 recommandations réparties en 8 familles :  

Chaque recommandation se présente sous la forme suivante :  

  • Objectif 
  • Mise en œuvre 
  • Moyen de test ou de contrôle 

Ainsi, par exemple, la première recommandation du référentiel a pour nom “1.1 Le service numérique a-t-il été évalué favorablement en termes d’utilité en tenant compte de ses impacts environnementaux ?” 

  • Son “Objectif” est de s’assurer que le service numérique que l’on cherche à écoconcevoir contribue bien aux Objectifs de Développement Durable (ODD). 
  • Pour cela, la section “Mise en œuvre” propose quelques pistes pour vérifier cela ainsi que les éléments à préciser dans la déclaration d’écoconception.  
  • Le “Moyen de test ou de contrôle” résume ce sur quoi s’interroger pour s’assurer que ce critère est satisfait.  

On arrive ici sur l’une des limites de cette version du référentiel : l’objectif est louable mais il manque de moyens concrets de vérification et de mise en œuvre.  

D’autres points sont soulevés par des experts du sujet mais l’outil reste important et nombreux sont ceux qui s’en emparent pour le tester sur le terrain.  

Le référentiel définit certains éléments pour structurer la démarche d’écoconception notamment via :  

  • La désignation d’un référent 
  • La rédaction d’une déclaration d’écoconception (avec tous les détails relatifs à son contenu) 
  • La mise en place d’une stratégie de mesure. En particulier, la définition d’un budget environnemental en visant entre autres une compatibilité plus large du service en termes de navigateurs, systèmes d’exploitation, types de terminaux et connectivité. 

Les outils qui accompagnent le référentiel (une extension de navigateur, des templates de tableur Excel comme grille d’audit) sont les bienvenus mais parfois insuffisants sur le terrain. Notamment pour pouvoir mener plusieurs audits sur des services numériques différents ou pour pouvoir construire un plan d’action complet.  

Afin de tenir compte de tout cela, intervient la version du RGESN proposée par l’ARCEP.[PDF, 1,6 Mo] 

La V2 (celle de l’ARCEP d’octobre 2023) 

Cette version a été soumise en consultation publique deux ans après la première version.  

Elle apporte quelques modifications significatives :  

  • On passe de 79 à 91 critères, notamment via l’ajout d’une section “Apprentissage” (relative au machine learning) qui introduit 5 nouveaux critères. 
  • En plus d’”Objectif”, “Mise en œuvre” et “Moyen de test ou de contrôle”, 3 nouveaux attributs apparaissent :  
  • Niveau de difficulté 
  • Niveau de priorité 
  • Critères de non-applicabilité 

Du fait de l’ajout du niveau de priorité, les recommandations sont au préalable regroupées par priorité. 20 d’entre elles sont identifiées comme prioritaires, en particulier toutes celles liées à la nouvelle section Apprentissage. 

Au-delà de ces apports, la nouvelle version se démarque de la précédente en étant davantage opérationnelle : elle vise à fournir des éléments concrets pour faciliter la mise en place des recommandations.  

On retrouve par exemple le même critère 1.1 mais présenté de façon plus complète :  

  • Action identifiée comme prioritaire et facile à mettre en place, pas de cas de non-applicabilité 
  • Objectif plus ou moins identique 
  • Davantage d’informations de contexte pour aller plus loin dans la démarche de vérification des apports du service numérique en termes d’impacts environnementaux (et sociétaux) 
  • Des outils concrets de contrôle : le questionnaire des Designers Éthiques et l’arbre de conséquences tel que formalisé par l’ADEME (Agence de l’Environnement et de la Maîtrise de l’Energie). On retrouve d’ailleurs cet arbre de conséquences par la suite, dans le critère 2.1, dans le cadre des revues de conception.  

Le critère relatif à la déclaration d’écoconception disparaît. Cette dernière n’en reste pas moins essentielle et son contenu défini au fil de différentes recommandations.  

Un autre élément qui se dessine au fil de cette nouvelle version du référentiel est la mise en place d’une stratégie de mesure via la définition d’indicateurs environnementaux (a minima énergie primaire, émissions de gaz à effet de serre, consommation d’eau bleue et épuisement des ressources abiotiques) ainsi que d’une stratégie pour leur réduction et d’un budget environnemental via des seuils. Cette stratégie de mesure devrait également inclure des éléments relatifs à la vérification du bon fonctionnement du service numérique sur des terminaux et systèmes d’exploitation anciens (voire navigateurs anciens) ainsi qu’en connexion dégradée. Via les modifications apportées à la recommandation 4.4, cette stratégie de mesure doit s’étendre à des parcours utilisateurs.  

C’est notamment sur ce sujet de la stratégie de mesure que Greenspector peut intervenir, aussi bien pour la construction de la stratégie que pour sa mise en place. Via la mesure proprement dite mais aussi la définition des indicateurs environnementaux, leur calcul de même que pour la définition des parcours et des terminaux et conditions de connexion. Ainsi, la démarche peut aujourd’hui s’appliquer aussi bien sur les sites web que les applications mobiles et les objets connectés.  

Certains nouveaux critères font le lien avec le RGPD (Réglement général sur la protection des données), le RGS (Référentiel général de sécurité), l’IoT (Internet of Things donc les objets connectés) et l’open source. Aussi, la recommandation 2.6 impose de prendre en compte les impacts environnementaux de briques logicielles telles que l’IA et la blockchain. Ceci dit, cette recommandation aurait tout à fait pu trouver sa place directement dans la section Stratégie. 

La section Contenus apporte de nombreux éléments sur les formats et modalités de compression des contenus, ce qui permet d’aller encore plus loin sur les aspects techniques d’une démarche de sobriété éditoriale. 

De nouveaux critères apportent également des éléments sur la blockchain mais aussi sur le lancement asynchrone de traitements complexes. 

Tout ceci va clairement dans le bon sens. Nul doute que la consultation publique aura permis de récupérer énormément d’éléments pour tendre vers un excellent référentiel mais aussi les outils qui doivent l’accompagner (en améliorant l’extension de navigateur mais surtout le template Excel pour mener les audits de conformité et les suivre dans le temps via un plan d’action).  

Il ressort d’ores et déjà de ces ajouts et précisions que la réalisation d’un audit RGESN prendra davantage de temps qu’avec la V1, ce qui est important pour prendre en compte les critères dans leur ensemble et ainsi lever le plus possible les éventuelles ambiguïtés. Si les intentions du RGESN V1 étaient déjà bonnes, le référentiel se dote dès sa V2 des éléments nécessaires pour faciliter son adoption et sa mise en œuvre. Cette version témoigne également d’une grande maturité sur le sujet et en fait une ressource donc la lecture permet déjà de faciliter la montée en compétences.  

La version finale (celle publiée le 17 mai 2024 par l’ARCEP)

Cette nouvelle version est disponible ici : Environnement | Arcep

On note déjà quelques modifications cruciales par rapport aux versions précédentes :

  • La disponibilité d’une version en ligne (même s’il manque des permaliens pour chaque bonne pratique) : RGESN – en ligne
  • La disponibilité d’une version en anglais [PDF, 2.8 Mo, en anglais]. A noter que cette version a aussitôt ou presque été référencée dans les Web Sustainability Guidelines du W3C (World Wide Web Consortium).
  • Comme annoncé, les réponses à la consultation publique sont également téléchargeables.

A première vue, cette version finale est plutôt proche de cette qui avait été proposée en consultation publique par l’ARCEP. C’est déjà une très bonne nouvelle pour ceux qui avaient déjà commencé à s’emparer du sujet.

La déclaration d’écoconception doit désormais mentionner des éléments sur presque l’ensemble des critères du référentiel. La nouvelle grille d’audit permet le calcul du score d’avancement. Elle est très dense mais aussi très complète. Il est regrettable de ne pouvoir générer la déclaration d’écoconception qu’au format PDF (le format HTML ou un autre format facilement éditable auraient été préférables). L’idéal pourrait être à terme de proposer un outil similaire à celui proposé pour les audits d’accessibilité : https://ara.numerique.gouv.fr/

On retrouve les 9 familles de critères de la version précédente (la famille « Apprentissage » devient « Algorithmie »). On compte au total 78 critères.

En cause ici, la fusion de certains critères. Le risque est alors de complexifier leur validation. C’est notamment le cas du critère 8.1 qui demande que l’hébergeur partage ses indicateurs environnementaux, ses engagements environnementaux et ratifie le Code de Conduite Européen [lien en anglais]. C’est aussi le cas du 6.5 qui incite à charger progressivement les contenus mais aussi le code, ce qui correspond souvent à deux chantiers techniques différents. Le problème est d’avoir en conséquence des critères plus difficiles à valider mais surtout avec un niveau de granularité inapproprié où l’état d’un critère (typiquement « non-validé ») ne permet pas d’estimer (voire de récompenser) finement les efforts réalisés. Pour ceux qui souhaiteraient creuser davantage ce sujet, je vous invite à explorer la façon dont Opquast définit ses règles.

De nouveaux critères font leur apparition :

  • 5.5 – Le service numérique propose-t-il un mode « écoute seule » pour ses vidéos ?
  • 4.14 – Le service numérique évite-t-il le recours à des procédés manipulatoires dans son interface utilisateur ?
  • 9.5 – Le service numérique optimise-t-il l’occurrence de mise à jour et de réentraînement des modèles en fonction de ses besoins et des cibles utilisatrices ?
  • 9.7 – Le service numérique utilise-t-il une stratégie d’inférence optimisée en termes de consommation de ressources et des cibles utilisatrices ?

L’ancien critère 5.5 (format des fichiers audio) disparaît.

En conséquence, certains critères changent de numéro (le 1.8 sur le référent écoconception devient 1.3) en plus de (nombreux) nouveaux détails ajoutés dans le contenu de certains critères. Ainsi, la validation des critères est davantage guidée. A terme, la publication des déclarations d’écoconception ainsi que les éventuelles listes de diffusion dédiées au sujet (au même titre que ce qui est proposé pour le RGAA) devraient permettre de lever les ambigüités restantes.

De même, certains critères sont déplacés. En particulier, les critères liés aux matériels ciblés (dont système d’exploitation et version de navigateur ainsi que design adaptatif) et au type de connexion utilisable sont regroupés dans la famille Spécifications.

Chaque critère se voit doter des mêmes attributs que sur la précédente version (priorité, difficulté, non-applicabilité, Objectifs, Mise en oeuvre et Moyen de test ou de contrôle), auxquels viennent s’ajouter les métiers concernés. On note au passage une nouvelle répartition des priorités avec 30 critères sur 78 identifiés comme prioritaires.

On note également que le calcul du score d’avancement a été légèrement modifié. En particulier, les critères non-applicables ne contribuent plus directement au score. Sur la version précédente, les critères non-applicables étaient ajoutés au même titre que les critères validés. Ils sont désormais directement retirés du total cible.

Plus généralement, l’appui sur la mesure est de plus en marqué, notamment pour de l’A/B testing (comparer par la mesure les impacts de composants, fonctionnalités ou choix d’implémentation).

Au final, si le nombre total de critères diminue, la complexité de validation de certains d’entre eux augmente et certains regroupement de critères apparaissent discutables.

Il n’en reste pas moins que cette nouvelle version apporte son lot de précisions qui sont les bienvenues.

Qu’attendre de la suite ? 

Le RGESN est appelé à évoluer au fil du temps et peut-être même à trouver une déclinaison au niveau de l’Europe. Il s’agira sans nul doute d’un outil essentiel pour structurer les démarches d’écoconception de services numériques. Ainsi, les pratiques de chacun pourront évoluer sur ce sujet.  

Les outils qui l’accompagnent ont bien progressé dans la version finale mais pourraient aller encore plus loin.

Le référentiel impose entre autres la publication d’une déclaration d’écoconception complète, ce qui permet de sensibiliser plus largement mais aussi de confronter les pratiques. Donc de faire évoluer ce domaine d’expertise.  

La grande inconnue reste le décret d’application à venir, qui doit poser le cadre d’application de la loi REEN en s’appuyant sur le RGESN. Il reste à ce propos plusieurs inconnues. Si l’on se base sur ce qui est fait pour l’accessibilité (et en particulier à la suite du décret d’octobre 2023), des questions restent en effet en suspens :  

  • L’utilisation du RGESN sera-t-elle limitée au web ou étendue à d’autres types de services numériques (applications mobiles, mobilier urbain, etc) ? A minima, il serait important d’embarquer les applications mobiles en complément des sites et applications web. 
  • Quelles seront les sanctions ? 
  • Quels seront les délais pour la mise en place ? 
  • Quelles structures seront concernées ? Les structures publiques seront a priori les premières concernées mais, comme pour l’accessibilité, il serait intéressant de viser aussi les entreprises. Certaines, d’ailleurs, ont déjà commencé à s’emparer du sujet car elles ont reconnu l’intérêt de ce référentiel pour guider leurs démarches d’écoconception de services numériques. 
  • Quels seront les moyens mis en place officiellement pour faciliter la prise en main du RGESN (formation, guides, outils, etc.) ? 

D’autres questions plus générales se posent. Notamment, comment certaines entreprises et certains professionnels feront évoluer leurs pratiques et leurs offres, peut-être pour une partie d’entre eux en évoluant vers des rôles d’auditeurs (voire en formant les futurs auditeurs). Il reste également à espérer que la définition plus complète de l’écoconception de services numériques permettra l’émergence de formations certifiantes (donc de référentiels de compétences validés par France Compétences). 

Un point d’inquiétude subsiste sur la nature déclarative des recommandations. L’avantage du RGAA est de proposer une approche technique voire factuelle (même si certains critères restent parfois sujets à interprétation). Dans le cas du RGESN, les critères sont moins factuels et moins faciles à vérifier, ce qui peut parfois les faire reposer sur l’objectivité de l’auditeur. Reste aussi ouverte la question de la définition de méthodes pour valider certains critères par des mesures. Il reste à voir, à terme, comment le suivi dans le temps du référentiel sera assuré (liste de diffusion par exemple). D’ailleurs, la création d’un « Forum des parties prenantes de l’écoconception numérique » piloté par l’ADEME et l’ARCEP a été annoncée. Il reste à espérer que ce moyen de partage du savoir sera disponible en ligne et plus seulement limité au présentiel sur Paris.

Il sera également intéressant de voir comment tous ces éléments trouveront un écho au-delà de la France et comment le RGESN pourra s’articuler avec l’éventuelle mise en place de nouvelles normes et autres référentiels. 

Et Greenspector dans tout ça ? 

Le RGESN s’impose comme un socle inédit mais surtout indispensable pour améliorer nos propres pratiques et accompagner au mieux nos clients. D’autant plus dans la mesure où ils seront bientôt confrontés à l’obligation d’utiliser ce référentiel.  

Pour cela, plusieurs actions ont été menées à bien :  

  • Intégrer la V1 du RGESN dans notre propre référentiel interne de bonnes pratiques. La version finale du référentiel est prise en compte dès maintenant dans nos accompagnements et sera très bientôt intégrée à notre référentiel de bonnes pratiques. 
  • Incorporer le RGESN dans les formations que nous proposons : présenter le référentiel et son contexte et proposer des activités autour de celui-ci, notamment via la mise en œuvre rapide et encadrée d’un audit RGESN. Les autres référentiels sont également présentés afin de les comparer ainsi que leurs cas d’usage. 
  • Nous effectuons régulièrement des audits RGESN pour des clients et centralisons les informations qui nous permettent de tracer les taux de conformité mais aussi leur évolution dans le temps. De plus, ces audits nous permettent de faire évoluer notre utilisation du RGESN. 
  • Nous nous appuyons systématiquement sur le RGESN lors des audits et revues de design. En complément, notre offre Ecobuild évolue. L’objectif de cette offre est à l’origine d’accompagner une équipe projet dès le début via de la formation, des revues de design, des audits, du monitoring et plus largement de l’expertise. Nous proposons désormais d’appuyer cette offre sur le RGESN, ce qui permet d’aller plus loin encore pour mettre en place ou consolider la démarche d’écoconception de nos clients.  
  • Au-delà de l’approche permettant d’utiliser le RGESN pour auditer/améliorer un site, nous l’utilisons également dans le cadre d’un accompagnement sur une solution de création de sites afin d’avoir des leviers plus globaux mais aussi d’amorcer une réflexion autour des critères RGESN qui peuvent être pris en compte directement à ce niveau. Ce type de raisonnement pourrait par la suite s’étendre à d’autres outils comme WordPress, Drupal et autres CMS. L’intérêt ici est multiple :  
    • Sensibiliser les clients et utilisateurs sur le sujet du RGESN 
    • Rassurer les clients en prenant en charge une partie des critères, ce qui pourrait à terme avoir un caractère différenciant (on peut imaginer à terme des clients qui opteraient vers des solutions “conformes au RGESN” afin de répondre plus facilement aux obligations légales sur le sujet) 
    • Mettre en place les moyens pour que des sites moins impactants soient créés par les utilisateurs/clients  

Conclusion 

Le RGESN s’impose déjà comme un incontournable pour l’écoconception de services numériques mais aussi pour structurer les démarches d’écoconception. En tant que tel, il devrait aider chacun à monter en compétences sur le sujet. Il reste à voir en quoi le cadre légal facilitera cette évolution et induira à terme des changements que l’on espère en profondeur dans les structures concernées. 

Analyse environnementale des outils d’Analytics : utilisation, impact et choix responsable 

Posted on by Maëva Rondeau
Reading Time: 12 minutes

Contexte

L’évolution constante des réglementations, telles que le RGPD (Règlement général sur la protection des données) et la loi REEN (Réduction de l’empreinte environnementale numérique), met en évidence un changement de paradigme dans le monde numérique. Les entreprises et les organisations sont de plus en plus conscientes de l’importance de la conformité réglementaire et de la nécessité de réduire leur impact environnemental. Cela a des implications profondes sur les outils et technologies utilisés, notamment en ce qui concerne les solutions d’analyse web.

D’autant qu’aujourd’hui, ces outils sont massivement utilisés pour scruter nos comportements et leurs impacts sont souvent sous-évalués au regard d’autres sujets comme la publicité par exemple. Ce sont des enjeux forts car le tracking est omniprésent dans les parcours et pages des services numériques. De plus, analyser les zones fréquentées par l’utilisateur via l’analytics permet de cibler les points par lesquels l’utilisateur passe souvent et donc ses impacts principaux. Ce tracking favorise également la détermination de l’utilité des fonctionnalités, favorisant la désactivation des éléments fonctionnels non utilisés. Ainsi, une utilisation judicieuse de l’analytique peut présenter des avantages environnementaux en évitant des impacts généralisés. L’optimisation et la modération dans son utilisation sont cruciales pour minimiser les impacts systémiques.

Bien choisir ses outils et adopter une bonne stratégie de tracking semble donc être un axe clé dans une démarche Numérique Responsable de son service numérique. 

Dans cet article, nous allons explorer leurs impacts environnementaux de différentes solutions destinés au tracking dans les pages web (web tracking) afin d’avoir quelques repères sur l’impact généré par ce tracking mais aussi pouvoir faire un choix de manière avisée sur les solutions à implémenter en regard de leur niveau de sobriété. 

Pourquoi utiliser des Analytics ? 

Le web tracking, également connu sous le nom de suivi web, est l’activité de collecte de données sur les interactions des utilisateurs sur Internet, notamment leurs visites de sites web, leurs clics, leurs comportements de navigation et bien plus encore. Il permet aux entreprises et aux organisations d’analyser et de comprendre le comportement des utilisateurs en ligne, de mesurer l’efficacité de leurs campagnes marketing et de personnaliser les expériences utilisateur. 

L’analyse web se concentre sur la mesure et l’interprétation des données d’utilisation des sites web, offrant ainsi aux exploitants une vision détaillée de l’activité en ligne de leurs visiteurs. Cette pratique englobe un large éventail d’informations, telles que : 

  • Le nombre de visiteurs au fil du temps, distinguant les visiteurs réguliers des nouveaux arrivants, ainsi que la durée de leur visite et les pages consultées 
  • Les sources de trafic : qu’il soit direct (lorsqu’un utilisateur saisit directement l’adresse du site), provenant d’autres sites web, de publicités ou via des moteurs de recherche 
  • La localisation géographique des visiteurs 
  • Les détails techniques, tels que le système d’exploitation, la résolution d’écran et la version du navigateur web des visiteurs 
  • Et encore bien d’autres informations, en fonction de l’outil retenu 

L’idée initiale de l’analyse web est de collecter et analyser ces informations pour un certain nombre de motivations :

  • Personnalisation de l’expérience utilisateur : en rassemblant des données collectées dans des profils d’utilisateurs, ceux-ci sont ensuite utilisés pour personnaliser les publicités. Au lieu de montrer des publicités aléatoires aux utilisateurs, les informations de leur profil, par exemple leur âge, leur sexe et les sites qu’ils ont visités dans le passé, sont utilisées pour choisir un contenu correspondant à leurs intérêts. Les annonceurs peuvent ainsi concentrer leur budget sur les consommateurs susceptibles d’être influencés. 
  • Sécurité : les forces de l’ordre et les services de renseignement peuvent utiliser les technologies de suivi du web pour espionner des individus. L’identification unique des individus sur Internet est importante dans la lutte contre l’usurpation d’identité et pour la prévention de la fraude à la carte de crédit par exemple. Ce sujet reste étroitement lié à la notion de vie privée, en raison des dérives possibles. 
  • Tests de convivialité des applications web ou compréhension du comportement utilisateur : en observant les étapes suivies par un individu lorsqu’il essaie de résoudre une certaine tâche sur une page web, les problèmes d’utilisation peuvent être découverts et corrigés. 
  • Mesure de la performance et des objectifs : l’objectif est de maximiser les revenus, par exemple en évaluant les pages qui génèrent le plus de revenus, les bannières publicitaires qui génèrent le plus de trafic ou les étapes du processus de commande au cours desquelles les clients sont perdus. 

Ces motivations aident à la prise de décision basée sur les données. En effet, les données collectées grâce au web tracking aident les entreprises ou autres entités à prendre des décisions fondées sur des statistiques prouvées. Les informations sur le comportement des utilisateurs aident à identifier les problèmes potentiels, à repérer les opportunités d’amélioration et à orienter les décisions relatives aux investissements en marketing, à l’expérience utilisateur et à d’autres aspects de l’activité en ligne. C’est notamment ainsi que l’impact du SEO (Search Engine Optimization) ou du SEA (Search Engine Advertising) peuvent être évalués. 

Cependant, récupérer une telle masse d’informations engendre à la fois du trafic de données et leur stockage pour une analyse quotidienne ou sur la durée mais implique également des traitements du côté de l’utilisateur, que ce dernier utilise ou non le service numérique en question. Cela se fait aussi au risque de bloquer temporairement le chargement d’un site web ou de ne pas respecter le consentement de l’utilisateur.  

Il est donc nécessaire en tant propriétaire exploitant de sites, de réfléchir à l’impact économique, social et environnemental de ces solutions de tracking. 

S’il est important de collecter des données d’utilisation du service numérique, il faut se contenter de l’essentiel (ce qui va dans le sens du RGPD : Règlement général sur la protection des données). 

D’autant que les services externes ont tendance à alourdir les sites, notamment via des scripts non-désirés collectant par exemple des données utilisateurs. On citera par exemple Google Analytics, Google Recaptcha (détection de bots), Google Maps et FontAwesome.

Quels critères pour faire son choix ?

Alors quels critères prendre en compte lors d’un choix d’outil d’analytics? Quelles sont les solutions qui permettent de faire cette collecte éclairée ? 

Nous ne reviendrons pas sur l’ensemble des critères de besoins d’utilisation en termes d’ergonomie, de support technique, de fonctionnalités, etc. Bien sûr, cela reste un point primordial dans ce choix mais qui diffèrent selon les organisations. 

Il est important de prioriser les outils qui respectent rigoureusement les réglementations en matière de protection des données, telles que le RGPD. Les données sensibles des utilisateurs doivent être sécurisées et traitées de manière confidentielle. 

Lors de la sélection d’outils d’analytics, il est crucial de maintenir une expérience d’utilisation fluide et accessible pour tous les utilisateurs. 

Il est également important de tenir compte de l’empreinte écologique de l’outil. Les données collectées correspondent-elles au besoin énoncé ? L’outil doit également pouvoir évoluer avec les avancées technologiques et les changements dans le paysage de l’analytique. Les serveurs et centres de données ont-ils des sources d’énergie renouvelables et sont-ils gérés durablement ?  

Nous avons d’ailleurs publié un article au sujet des engagements environnementaux des offres d’hébergement web. 

Il peut être difficile d’avoir accès à toutes ces informations mais cela peut aider à affiner la recherche de solutions plus respectueuses. Si l’outil est transparent quant à la manière dont il collecte, traite et utilise les données, cela traduit un engagement des valeurs de l’entreprise. Les utilisateurs doivent avoir une compréhension claire de comment sont utilisées leurs données.

Sélection des solutions et définition du périmètre de mesure

Nous avons pris le soin de sélectionner 3 outils analytics qui sont accessibles gratuitement. Voici notre sélection : 

  • Google Analytics 
  • Matomo
  • Plausible

Méthodologie

Choix des solutions étudiées

Le choix des solutions à analyser a été effectué en prenant en compte plusieurs critères clés, tels que la popularité sur le marché ainsi que son coût. L’objectif était de sélectionner des solutions représentatives du paysage actuel de l’analyse web, afin d’obtenir des résultats pertinents et significatifs. 

Il convient de noter que cette étude expérimentale ne vise pas à promouvoir une solution spécifique, mais plutôt à fournir une évaluation objective basée sur des données concrètes. Les résultats de cette étude pourront servir de référence et d’outil d’aide à la décision pour les acteurs du numérique cherchant à optimiser leurs analyses web tout en tenant compte des enjeux environnementaux et de vie privée. 

Selon les statistiques d’utilisation fournies par HTTP Archive et l’outil d’identification de service tiers de Patrick Hulce, les solutions d’analyse web Google Analytics, Matomo et Plausible sont les plus populaires.

 Google Analytics  Matomo Plausible 
Occurrences d’utilisation 9 887 783 11 610 17 628 

Préparation de l’étude

Dans le cadre de cette étude comparative des solutions d’analyse web, une étape nécessaire consiste à mesurer les performances d’une page de référence qui n’a aucune solution d’analyse web implémentée et de mesurer cette même page avec les pages implémentant les solutions de web tracking. Cette approche nous permet d’évaluer l’impact spécifique de chaque solution en termes de performance et de consommation (énergie, data, …) de la page. Il est important de noter que nous avons délibérément exclu les utilisations plus avancées telles que l’utilisation de Tag Manager ou la configuration avancée des données collectées. De plus, nous avons pris en compte au possible la réalité de l’impact du traitement et du stockage des données collectées côté serveurs, celui-ci étant projeté par notre modèle détaillé dans cet article. Exclue également la partie administrative de ces outils et l’analyse des dashboards. 

Il est à noter que Matomo propose également une solution qui tourne uniquement côté serveur, ce qui permet d’éviter les soucis vis-à-vis du RGPD (Règlement général sur la protection des données) en plus de réduire l’impact environnemental sur la partie cliente.  Nous n’avons pas évalué cette solution. 

Nous avons déployé une page web simple de référence ainsi que 3 pages identiques sur lesquelles nous avons implémenté les 3 solutions respectives. La page de référence est un écran noir avec un texte de police standard et dépourvue de script.

Définition du parcours utilisateur

Pour mesurer l’activité des outils d’Analytics, nous avons établi le parcours suivant :

  • Etape 1 : lancement de l’application du navigateur 
  • Etape 2 : lancement de l’url de la page à mesurer 
  • Etape 3 : pause (30 sec) 
  • Etape 4 : scroll de la page 

Le parcours consiste à lancer l’application du navigateur (ici Chrome) et saisir l’url de la page à mesurer (référence ou avec solution implémentée). Ensuite le parcours déroule en faisant une pause de 30 secondes pour mesurer ce qui se passe en cas d’inactivité de l’utilisateur. Enfin, un scroll est effectué pour détecter l’envoi de requêtes supplémentaires décrivant le comportement de l’utilisateur.

Contexte de mesure

  • Samsung S7, Android 10  
  • Réseau : 3G : ici utilisé pour étendre les performances de tests et permettre davantage de points de mesures 
  • Luminosité : 50% 
  • Tests réalisés sur au moins 5 itérations pour fiabiliser les résultats 

Hypothèses retenues pour les projections environnementales

  • Localisation utilisateurs : 2% France, 98% Monde 
  • Localisation serveurs : 100% monde (à défaut d’avoir les informations pour chacune des applications) 
  • Appareils utilisés : 60% smartphone, 38% PC, 2% tablette
 Google Analytics  Matomo Plausible 
Localisation utilisateurs 98% Monde 2% France 
Localisation serveurs 100% Monde 
Appareils utilisés  60% smartphone, 38% PC, 2% tablette 

L’empreinte environnementale dépend de la localisation des serveurs de l’application, de leur type, de la localisation des utilisateurs et du type d’appareils qu’ils utilisent. Nous avons pris le parti d’étudier tous les utilisateurs ce qui correspond à une répartition de 2% en France et 98% pour le reste du monde. Ce ratio est tiré du rapport Digital report de We are Social. Le rapport mondial précise que 5,16 milliards de personnes sont utilisatrices d’internet et l’édition française indique que 53,96 millions de français sont des utilisateurs d’internet. 

Pour la répartition globale des appareils utilisés, le rapport de l’année précédente énonce une répartition d’environ 60% pour les smartphones, 38% pour les PC et 2% pour les tablettes.

Quel impact environnemental ?

En réalisant nos mesures réelles d’impact environnemental pour chacune des solutions d’analyse web, on peut directement faire le calcul avec les statistiques d’utilisation et l’impact unitaire de l’outil seul sur une visite (chargement, pause et scroll) auquel nous avons soustrait l’impact de la page de référence. L’impact unitaire présenté ci-dessous est le delta entre la page présentée noir avec analytics et la page noire de référence sans analytics implémenté.

Solution Impact unitaire par parcours (g CO2e) Impact pour 10 visites/jour de chaque instance sur une année 
Google Analytics 0,069 2 490 T CO2e 
Matomo 0,012 508 kg CO2e 
Plausible 0,039 2,5 T CO2e 

Pour chacune des solutions d’analytics, nous avons pris l’hypothèse que chacun des sites disposant des solutions a une fréquence de visite de 10 par jour. 

Pour Google Analytics, qui produit 0,069 g CO2e par parcours, génère presque 2 500 tonnes de CO2e à l’échelle de ses 9 887 783 occurrences sur une année. 

Plausible, elle a un impact unitaire au chargement de 0,039 g CO2e donc 2,5 T CO2e sur une année pour 17 628 occurrences. 

Enfin, Matomo qui compte 11 610 occurrences avec un impact de 0,012 g CO2e par parcours produit 508 kg CO2e par an. 

On peut spécifier que l’écart est très faible car les pages sont très sobres mais on ne constate que peu d’écart entre une solution très tournée vers le business comme Google Analytics, et Plausible, censée offrir une solution plus légère en termes d’impact environnemental. La plus grosse part de l’impact se fait au niveau du volume d’utilisation des solutions d’analytics. 

Si la différence au niveau des impacts unitaires est très faible, à même taux d’utilisation, certaines solutions sont bien plus sobres écologiquement.  

L’intérêt est donc de limiter l’usage de ceux-ci et de privilégier les solutions à plus faible impact. 

Par exemple, si les services web utilisant Google Analytics transféraient leur usage d’analytics sur Matomo, l’impact environnemental en serait fortement diminué : si les visites des presque 10 millions d’occurrences de Google Analytics ont un impact de 2 490 T CO2e, en utilisant l’alternative Matomo, cet impact serait de 433 T CO2e. C’est 6 fois inférieur à l’impact de Google Analytics ! 

D’autant que Matomo propose une solution server-side. En dehors des bénéfices coté vie privée en n’ayant aucun intermédiaire niveau collecte des données et performance améliorée pour les visiteurs du site web, les émissions de gaz à effet de serre sont elles aussi diminuées.

Pour comparer

Gerry McGovern, expert dans le domaine de l’expérience utilisateur et auteur de plusieurs livres sur la conception digitale et notamment World Wide Waste, fait le calcul du coût environnemental de l’utilisation de Google Analytics. 

Il estime que : 

  • 21,6 ko de données sont transférés à Google par visite 
  • 50 M de sites utilisent Google Analytics d’après Marketing Land en 2015 (ce qui ne correspond pas à nos estimations) 

Pour un total estimé de 10 visites par jour par site web utilisant Google Analytics, cela représente 500M de pages vues et donc près de 10 800Go transférés par jour ou 4M Go/an. 

D’après ses recherches, 1Go = 4,2 g CO2eq. Ainsi la pollution de la solution Google Analytics s’élève à 16556kg/an. 

On note donc que pour un usage au plus simple de l’outil sur une page très sobre, les estimations de Gerry McGovern sont très faibles en comparaison de l’impact que nous avons mesuré. 

Cependant, cette estimation est réalisée en prenant en compte seulement le poids des données pour faire une projection d’impact carbone, ce qui diffère de notre méthodologie. 

Pour aller plus loin… 

Au-delà des considérations générales d’impact environnemental, une analyse technique approfondie des requêtes générées par les outils d’analytics peut fournir des informations sur la manière dont ces solutions opèrent et interagissent avec les sites web (poids des requêtes, chargement différé, services tiers, etc). 

Voici les valeurs des mesures pour du parcours (chargement, pause, scroll) des 3 pages web auquel nous avons soustrait les valeurs de référence : 

 Performance (s) Vitesse de décharge de batterie (µAh/s) Données mobiles (Ko) 
Google Analytics 2,3 21 955 145,9 
Plausible 1,6 3 604 29,1 
Matomo 0,4 15 272 9,2 

Sans grande surprise, c’est Google Analytics le plus consommateur et le moins performant qui est suivi de Plausible puis de Matomo. En effet, sur 150Ko de données échangées sur le parcours, le fichier Javascript chargé d’envoyer la requête vers le serveur de Google pèse plus de 90 ko. C’est 66 fois plus élevé que Plausible. Matomo compte lui, plus de 40ko pour cette requête.

Page avec GA implémenté – Inspecteur Firefox, onglet network
Page avec GA implémenté – Inspecteur Firefox, onglet network 

D’autre part cela laisse penser que plus le fichier JS est volumineux, plus il récupère d’informations sur l’utilisateur même si cela ne constitue pas nécessairement une corrélation directe. D’autres facteurs, tels que les traitements côté client ou l’optimisation du code, peuvent également influencer la performance et la collecte de données.

Ici, un gros volume de données est transmis à la plateforme Google Tag Manager qui n’est pourtant pas implémenté dans le code. L’écart est flagrant avec Matomo qui transfère un faible volume de données par rapport à son concurrent. 

De plus, Google Analytics et Matomo transfèrent tous deux des cookies.

A la base, les cookies ont été conçus pour un simple besoin : conserver les informations de connexion d’un utilisateur sur un site donné, ils ne sont donc pas problématiques en soit, mais ils servent en fait à bien des besoins publicitaires, marketing et autres pour permettre un contenu plus ciblé en fonction du comportement de l’utilisateur.

Ainsi, il est important de regarder la taille et la date d’expiration de ces cookies. Pour Google, les cookies se démarquent facilement avec leur préfixe _ga tandis que les cookies de Matomo se repèrent grâce au préfixe _pk. Les cookies de Google ont une taille totale de 80 octets et expirent seulement 13 mois plus tard ce qui correspond à la date d’expiration des cookies publicitaires. Ceux de Matomo comptent pour 56 octets et un des 2 cookies chargés expire le jour même. Dans les 2 cas on peut questionner la pertinence de ces cookies sur des pages aussi sobres. 

On l’a vu, Google Analytics est la solution la moins performante et la plus impactante écologiquement, d’autant que la requête vers Google Analytics est chargée en asynchrone. Bien que le chargement asynchrone soit une bonne pratique de performance courante pour ne pas retarder l’affichage de la page, cela peut en effet masquer l’impact environnemental réel de cette solution. 

Dans notre processus de mesure, nous avons cherché à obtenir une vue complète du chargement de Google Analytics. Il est important de souligner que Google a mis en place diverses stratégies pour minimiser son impact sur la performance des sites web. Cependant, malgré ces efforts, nos données de mesure révèlent que les impacts en termes d’énergie et de transfert de données restent plus élevés pour GA par rapport à ses concurrents.

Les limites de notre étude 

Les résultats de notre étude présentent des limites. Les pages mesurées sont premièrement très simples en termes de fonctionnalités et de visuels ce qui implique un scénario simple également ce qui n’est pas forcément représentatif des sites web disposant d’outils d’analytics. De plus, de par leur sobriété, ces pages sont très légères et les mesures effectuées peuvent donc entrer dans la marge d’erreur de notre outil de mesure. Enfin, nous n’avons que peu d’informations sur les facteurs variants de l’impact environnemental (localisation des serveurs par exemple). 

Pour conclure 

En conclusion, notre étude sur les différents outils d’analyse web met en évidence des nuances intéressantes quant à leur impact environnemental. Il est important de noter que nos analyses ont été effectuées sur une page sobre et un cas d’utilisation très basique, ce qui limite considérablement les écarts d’impact. Cependant, même dans ce contexte, nous constatons des volumes de données élevés avec des techniques d’efficience différant certains chargements. Ceci pour toujours plus d’analyse du comportement utilisateur avec un fort impact environnemental en prime. 

Sources : 

https://wearesocial.com/fr/blog/2023/01/digital-2023/ :  rapport digital 2023, We are social  

https://wearesocial.com/fr/blog/2023/02/digital-report-france-2023-%f0%9f%87%ab%f0%9f%87%b7/ : rapport digital 2023 France, We are social 

https://wearesocial.com/fr/blog/2022/01/digital-2022-une-nouvelle-annee-de-croissance-exceptionnelle/ : rapport digital 2022, We are social 

https://gerrymcgovern.com/ : Gerry Mc Govern 

https://gerrymcgovern.com/calculating-the-pollution-cost-of-website-analytics-part-1/ : Article Calculating the pollution cost of website analytics 

https://www.thirdpartyweb.today/

Réduire le poids d’une page web : quels sont les éléments les plus impactants ?

Posted on by Laurent DEVERNAY
Reading Time: 12 minutes

Il y a de cela quelques années déjà, j’ai eu la chance de participer à la conception du MOOC de l’INRIA sur les impacts (entre autres environnementaux) du numérique. À cette occasion, une activité avait été créée par Benjamin Ninassi, dans le but de permettre au participant de classer les éléments d’une page web en fonction de leur poids. L’intérêt ici est notamment d’aider les participants à constituer leur propre modèle mental de ce qui constitue une page web et des impacts respectifs de chaque élément qui la compose. Il s’agit là d’une étape essentielle lorsque l’on veut se pencher sur l’écoconception web. C’est d’ailleurs pour cela que j’utilise régulièrement cette activité en formation mais aussi pour sensibiliser à la sobriété éditoriale.

L’objectif premier de cet article est de valider le classement proposé dans cette activité par de la mesure mais aussi d’aller plus loin. Cet article a été réalisé en collaboration avec l’INRIA (merci Benjamin !) et l’activité du MOOC sera modifiée en conséquence prochainement.

Méthodologie

Afin de pouvoir mesurer les différents éléments qui constituent une page web, nous avons commencé par créer une page HTML/CSS aussi basique que possible qui sert de référence pour les mesures. Cette page a un fond entièrement noir. Ensuite, nous avons décliné cette page en autant de versions qu’il y a d’éléments à mesurer. Pour chaque élément à mesurer, une page HTML est donc créée à partir de cette page de référence, à laquelle on ajoute seulement l’élément à mesurer. Le CSS est créé dans un fichier à part, renseignant à minima le fond entièrement noir. Ce fichier n’est pas minifié (suppression des caractères non-nécessaires à l’interprétation du code) car l’apport sur un fichier aussi court est négligeable.

Ensuite, un parcours simple est automatisé en GDSL (le langage d’automatisation de Greenspector) afin de simuler le comportement standard d’un utilisateur, basé sur une utilisation standard du composant mesuré (voir plus loin). Ensuite, une fois les mesures réalisées sur le banc de mesure, nous procédons à la génération d’un dashboard et à la projection environnementale. Ce sont ensuite ces résultats que nous utilisons pour analyser les impacts des différents éléments mesurés et les classer.

Concernant les médias intégrés dans la page à titre d’exemple pour la mesure, nous avons autant que possible repris les éléments utilisés dans l’activité du MOOC. Cette dernière proposait à l’origine un fil Twitter qui apparaît depuis vide. Avec l’INRIA, il a été décidé de le remplacer par un fil Facebook (celui de l’INRIA) à la fois dans l’activité et dans l’échantillon mesuré ici.

Nous avons ici pris le parti de mesurer les éléments choisis en fonction de l’usage qui en est fait :

  • Image (brute et allégée), animation (CSS), image animée (GIF) : chargement et pause
  • Fichier audio, vidéo (BD et HD) : chargement, pause, lecture
  • Fil Facebook, tableau, texte : chargement, pause, scroll, pause
  • Carte interactive : chargement, pause, zoom, pause

L’idée générale est d’aller au-delà du simple chargement de la page pour refléter ce qu’en font les utilisateurs mais aussi d’aller vers d’autres métriques liées aux impacts environnementaux.

Les mesures ont été effectuées sur Samsung Galaxy S9, en WIFI.

Différentes hypothèses ont été prises pour la projection environnementale :

La méthodologie pour la projection environnementale est décrite dans cet article dédié.

Classement des éléments d’une page en fonction leur poids

Attention, cet article contient des spoilers. En effet, il se base sur le résultat attendu pour l’activité “Comparer le poids des éléments d’une page web”. Si vous n’avez pas encore fait cette activité, faites-la dès maintenant.

Dans l’activité du MOOC, le classement proposé est le suivant (du composant ayant le poids le plus élevé à celui ayant le poids le plus faible) :

  1. Vidéo Haute Définition
  2.  Vidéo Basse Définition 
  3. Podcast audio 
  4. Image Brute 
  5. Carte OpenStreetMap 
  6. Un fil de réseau social 
  7. Image allégée 
  8. Texte seul 

A l’issue des mesures que nous avons effectuées, les données transférées lors du chargement des pages correspondantes donnent les résultats suivants : 

Données transférées au chargement des pages pour les éléments de l’activité 

On retrouve donc plus ou moins le classement proposé dans l’activité avec quelques écarts liés aux contenus choisis pour chaque catégorie. Il convient en effet de noter que le poids de ces éléments dépend de plusieurs facteurs et en particulier du réseau social sélectionné ainsi que du contenu intégré ici (message, fil de messages, etc). Il en va de même pour les autres éléments mesurés ici mais l’ordre de grandeur reste donc tout à fait correct.

Nous pouvons donc ici valider le classement du poids des éléments tel que proposé dans l’activité du MOOC de l’INRIA. Nous pourrions tout à fait nous arrêter ici mais voyons maintenant pour aller plus loin. Pour cela, regardons ce qui se passe au-delà du chargement de la page ainsi que d’autres métriques et indicateurs.

Autres impacts des éléments d’une page web

Nous restons donc sur les huit éléments proposés dans l’activité.

Le dashboard généré via Greenspector Studio liste plusieurs autres métriques et indicateurs.  
Le premier score calculé concerne la performance. Toutefois, sur des pages aussi légères, le chargement est trop rapide pour qu’on puisse différencier les éléments de façon significative en raison du “bruit”, notamment le TTFB (Time to First Byte = délai avant réception du premier élément) qui peut légèrement varier d’une itération à l’autre.

Données transférées au-delà du chargement initial

Commençons par regarder les données transférées au-delà du chargement de la page : pause de 30 secondes, scroll en bas de la page puis nouvelle pause de 30 secondes.

Données transférées sur l’ensemble de la mesure pour les éléments de l’activité 

On constate ici que les données transférées en-dehors du chargement ne sont la plupart du temps pas négligeables. En particulier, dans le cas de la lecture de vidéo et d’audio (comme on pourrait s’en douter) mais aussi pour le fil Facebook.

Énergie consommée

Sur l’ensemble des étapes mesurées, l’énergie consommée en fonction des éléments est la suivante :

On constate que l’ordre reste globalement cohérent à quelques exceptions près (nous y reviendrons plus tard) mais surtout le fil Facebook qui, bien que moins impactant que la vidéo, l’est davantage que les autres éléments (notamment le lecteur audio).

Fil Facebook

La page contenant le fil Facebook est parmi les plus impactantes du point de vue de l’énergie. S’il est logique que le scroll et le chargement soient impactants (car ces étapes impliquent à minima une modification de l’affichage), c’est tout de suite plus étonnant pour les pauses. En effet, lorsque l’utilisateur est inactif, l’affichage n’est normalement pas modifié. Il reste donc à regarder si des requêtes “parasites” surviennent. Dans l’interface web de Greenspector Studio, on obtient la représentation suivante : 

Visualisation CPU et données transférées pendant la pause après scroll sur la page contenant le fil Facebook 

Sur une étape de pause “normale”, aucun transfert de données n’a lieu (en-dehors d’éventuelles requêtes liées à la télémétrie du navigateur Chrome). Si, en plus, l’affichage n’est pas modifié, on s’attend à voir une sollicitation CPU stable et basse et aucune donnée transférée. Ce n’est pas le cas ici. En-dehors d’un pic fort de CPU, corrélé à du transfert de données, les pics CPU semblent plutôt être de l’ordre du tracking.

Extrait des requêtes HTTP capturées dans l’onglet Réseau des DevTools de Firefox 

Lors de l’intégration d’un contenu provenant d’un service externe, il est courant que des requêtes soient émises à intervalles réguliers vers le site source pour l’informer du comportement utilisateur et des interactions avec le contenu intégré. On le voit ici dans le cas de Facebook mais sachez que la plupart des réseaux sociaux procèdent ainsi (à ce propos, je vous recommande de tester l’intégration d’un contenu Linkedin…).

Vous pouvez à ce sujet consulter l’article dédié à l’intégration de services tiers sur une page web : https://greenspector.com/fr/service-tiers-youtube/ 

Différences de consommation énergétique pour les contenus

Le texte apparaît plus impactant pour l’énergie que la carte interactive ou les images. Tous ces contenus ne provoquent pas de changement de l’affichage une fois chargés et juste visualisés. En revanche, sur un écran AMOLED (comme celui du S9 utilisé ici), l’affichage du texte est plus impactant que les images et la carte interactive choisis car le fond est noir mais le texte blanc. Sur ce type d’écran (et c’est la raison d’être du mode sombre du point de vue de la consommation d’énergie), un pixel noir est beaucoup moins coûteux à afficher qu’un pixel blanc. Nous sommes donc ici sur un cas limite mais qui permet de comprendre d’où provient l’impact d’une page en consultation seule.

Vous pouvez à ce sujet consulter l’article dédié à l’impact de la couleur sur la consommation énergétique : https://greenspector.com/fr/faut-il-changer-son-fond-decran-pour-consommer-moins-de-batterie/ 

Conclusion intermédiaire

Pour les éléments de l’activité du MOOC, la mesure des données transférées vient confirmer le classement attendu, avec seulement un léger bémol lié au contenu de réseau social intégré (qui apparaît plus impactant que la carte interactive).

Toutefois, si on regarde plutôt l’énergie consommée, on constate qu’une bonne partie de l’impact du fil Facebook intervient après le chargement, via des requêtes régulières à des services tiers. Ceci souligne la nécessité d’aller au-delà de la mesure des requêtes, données transférées et du DOM mais aussi de mesurer ce qui se passe après le chargement initial, au risque de passer entre autres à côté des services tiers (et des éléments dont le chargement est différé, souvent pour des raisons de performance). Aussi, il s’agit là (au risque d’insister) d’être au plus proche du comportement des utilisateurs.

Voyons maintenant pour ajouter à la liste initiale de nouveaux éléments qu’on trouve souvent sur le web.

Autres éléments intégrés dans une page web

En complément des éléments proposés dans l’activité du MOOC, nous nous sommes penchés sur d’autres items : 

La méthodologie de mesure et création des pages de l’échantillon est exactement la même que celle exposée plus haut.

Voyons ici les résultats obtenus.

Données transférées lors du chargement initial

A l’issue des mesures que nous avons effectuées, les données transférées lors du chargement des pages correspondantes donnent les résultats suivants :

Données transférées au chargement des pages pour l’ensemble des éléments 

En complément du classement constaté plus haut pour les éléments issus de l’activité, on note le GIF, assez volumineux en soi (même si cela dépend une fois de plus de l’élément choisi).

Le tableau est moins volumineux que le texte car il contient moins de caractères (moins de phrases de contenu factice ont été introduites dans le tableau que dans la page servant à mesurer l’impact du texte seul). Nous verrons plus loin que la surconsommation, dans le cas du tableau, est ailleurs. L’animation apparaît ici plutôt légère (quelques lignes de HTML et de CSS).

A noter que les éléments ajoutés ici n’entraînent pas de transferts de données additionnels au-delà de l’étape de chargement initial.

Données transférées sur toutes les étapes pour l’ensemble des éléments 

Énergie consommée

Les résultats obtenus ici sont les suivants : 

Énergie consommée sur l’ensemble de la mesure pour les éléments 

Lorsque l’on se limitait aux éléments de l’activité du MOOC, nous avions constaté quelques différences avec le classement initialement proposé. En particulier, le fil Facebook se démarquait nettement comme le plus impactant du point de vue de l’énergie.

Ici, on remarque que l’animation CSS est de loin la plus impactante du point de vue de l’énergie. Après les vidéos, on trouve le fil Facebook puis l’image animée. Cet ordre est notable : en effet, contrairement au GIF animé qui modifie en continu l’affichage, le fil Facebook apparaît plutôt statique lorsque l’utilisateur est inactif. Comme évoqué précédemment, sa surconsommation d’énergie vient plutôt de ce qui ne se voit pas : les requêtes à destination de Facebook et le préchargement des vidéos.

Le tableau HTML natif est légèrement plus impactant que le texte simple du point de vue de l’énergie, même s’il contient moins de caractères. Ainsi, dès l’affichage, le tableau sollicite légèrement plus le CPU (nous y reviendrons plus loin).

Ceci avait déjà été évoqué dans le cadre de l’article sur les sites sobres : https://greenspector.com/fr/un-site-sobre-est-il-necessairement-moche/ 

Lorsqu’un élément sur une page entraîne des modifications en continu ou presque de l’affichage, l’impact énergétique peut être conséquent. Nous verrons dans la dernière partie de cet article en quoi ceci influe sur les impacts environnementaux.

Conclusion intermédiaire

Les trois éléments ajoutés s’intègrent sans surprise au classement initial si l’on s’en tient aux données transférées. Toutefois, du point de vue de l’énergie, l’animation CSS et le GIF animé ont un impact considérable. Ceci souligne une fois de plus la nécessité, pour de la mesure, de ne pas se limiter aux requêtes HTTP, données transférées et au DOM. L’utilité de cette dernière métrique pour la projection environnementale reste discutable. Les cas présentés ici sont d’ailleurs de bonnes illustrations de cas où le DOM est très léger mais où les impacts sont très importants. 

Ceci est détaillé dans un autre article du blog : https://greenspector.com/fr/le-dom-comme-metrique-de-suivi-de-sobriete-du-web/ 

Pour finir, nous allons utiliser une autre méthodologie de mesure et collecter des données afin d’avoir une vision plus globale des différents éléments.

Mesure des pages via un benchmark “classique”

Pour cette nouvelle série de mesures, nous sommes partis du même échantillon de pages mais avons utilisé un benchmark classique. Ainsi, chaque page est mesurée sur une durée de 70s, en utilisant les étapes suivantes : 

  • Le chargement de la page 
  • Une étape de pause avec la page affichée au premier plan  
  • Une étape de pause avec la page affichée à l’arrière-plan  
  • Le scrolling sur la page 

Pour en savoir plus sur le benchmark, consultez cette page : https://greenspector.com/fr/comment-est-calcule-lecoscore-dans-le-cas-dun-benchmark-web-ou-mobile/  

Il en ressort les résultats suivants : 

Agrégation des résultats du benchmark des éléments (classés par quantité de données transférées) 

Pour ce qui est des données transférées, on retrouve ce qui a déjà été observé. Sachant qu’il est plus difficile de départager l’animation CSS, le texte et le tableau HTML car les quantités de données transférées sont très faibles. 

Pour ce qui est du CPU, on note quelques légères variations mais surtout les surconsommations pour l’animation CSS, le GIF et le fil Facebook sont d’autant plus claires. À la suite de ce trio de tête, on trouve le tableau HTML qui, malgré la faible quantité de données nécessaires à son chargement, s’avère être impactant pour le CPU. 

De son côté, Alexander Dawson a commencé à creuser la question de l’impact de différents éléments standard HTML et CSS : https://websitesustainability.com/cache/files/research23.pdf [PDF de 384 ko, EN].

 Pour les requêtes HTTP, on retrouve sans surprise en tête le fil Facebook (de loin) et la carte OpenStreetMap. Il s’agit en effet ici de l’intégration d’éléments dynamiques fournis par des services-tiers, ce qui nécessite davantage de fichiers pour fonctionner. A noter que les requêtes vers et depuis Facebook se font en continu ou presque, jusqu’à atteindre plus de 170 requêtes en tout au bout de quelques minutes d’inactivité de l’utilisateur (comme nous avons pu l’évoquer plus haut).

Concernant les équivalents en émissions de gaz à effet de serre, l’animation et l’image animée sont les plus impactants, suivis par le fil Facebook (en raison de sa forte consommation de données et de CPU). À titre indicatif, l’occupation des sols ainsi que l’eau sont également indiquées (voir à ce propos l’article sur la projection environnementale : https://greenspector.com/fr/methodologie-calcul-empreinte-environnementale/ ). Le classement pour ces deux autres indicateurs, reste globalement identique.

Conclusion intermédiaire

Ces nouvelles mesures, avec une méthodologie légèrement différente, soulignent une fois de plus la nécessite de prendre en compte différentes métriques mais aussi les écarts observables lors de l’évaluation sur plusieurs indicateurs environnementaux.

Conclusion globale

Si l’on reste sur le même périmètre (données transférées lors du chargement initial), les mesures confirment le classement des éléments proposé par l’activité du MOOC de l’INRIA. Le seul point à discuter reste l’intégration d’un élément de réseau social. Sur l’échantillon choisi ici, l’intégration du fil Facebook est plus impactante que la carte interactive issue d’OpenStreetMap (sans même compter les autres impacts identifiés au-delà du chargement initial ou les données liées à l’énergie).

Si l’on va au-delà de ce périmètre de mesure (en regardant également d’autres métriques et indicateurs environnementaux), le classement peut être amené à changer, en particulier à cause des impacts au niveau de l’énergie consommée.

Enfin, l’ajout de nouveaux éléments intégrables sur une page web vient forcément modifier le classement mais permet surtout d’affiner le modèle mental évoqué en introduction du présent article. En particulier, l’animation CSS et le GIF animé (ainsi que le tableau HTML dans une moindre mesure) soulignent l’impact sur des métriques qui ne sont aujourd’hui pas mesurées par la plupart des outils alors qu’elles ont un rôle prépondérant pour les impacts environnementaux. Par exemple, l’impact du CPU sur la décharge de batterie du terminal peut entraîner l’accélération à terme du renouvellement de celui-ci donc les impacts environnementaux majeurs liés à cette opération. Ce constat remet directement en question le modèle mental largement adopté pour les impacts environnementaux du numérique qui conduit certains à “compenser” la diète qu’ils s’imposent sur les données transférées par la mise en place d’animations. Par extension, ceci rejoint notamment les questionnements sur l’impact des différents formats et codecs pour certains contenu (où la réduction de poids peut être compensée par une surcharge de calcul qui vient réduire voire annuler les gains environnementaux).

Même s’il est normal de commencer avec un modèle mental simple, cet article vise également à souligner la nécessité d’affiner celui-ci afin d’avoir tous les éléments en main pour effectuer des choix éclairés. En espérant que certains des résultats présentés ici y contribuent. 

En conclusion, deux classements sont proposés ici. 

Le premier ne s’appuie que sur les données transférées lors du chargement initial, comme prévu initialement dans l’activité (du moins impactant au plus impactant) :

  1. Tableau 
  2. Texte 
  3. Animation 
  4. Image allégée 
  5. Carte interactive 
  6. Intégration d’un contenu de réseau social 
  7. GIF animé 
  8. Fichier audio 
  9. Vidéo basse définition
  10. Image brute  
  11. Vidéo haute définition

Le deuxième classement s’appuie directement sur la projection en termes d’émissions de gaz à effet de serre sur l’ensemble des étapes de mesure (ce qui implique de revenir aux métriques pour expliquer mais aussi d’être transparent sur le modèle de projection environnementale) :  

  1. Texte 
  2. Tableau 
  3. Image allégée 
  4. Carte interactive 
  5. Fichier audio 
  6. Image brute 
  7. Vidéo basse définition 
  8. Vidéo haute définition 
  9. Intégration d’un contenu de réseau social 
  10. GIF animé 
  11. Animation 

Impact environnemental des sites web des exposants au GreenTech Forum 2023

Posted on by Thibault TUFFIN
Reading Time: < 1 minute

À l’occasion du GreenTech Forum 2023, Greenspector a évalué l’écoscore de sobriété et de performance des sites web des partenaires et exposants de l’évènement.

L’ambition du GreenTech Forum est de promouvoir le numérique responsable afin de permettre aux organisations publiques et privées de réduire leur impact environnemental. L’écosystème du numérique des partenaires présentera ses solutions, des retours d’expériences. Mais qu’en est-il de sites web de tous les acteurs partenaires en terme d’impact de la vitrine de l’offre de service ?

Résultats de l’évaluation de la sobriété des sites exposants du GreenTech Forum

En moyenne, un site exposant du GreenTech Forum obtient un impact carbone de 0,33 gEqCO2. 37 / 62 sites web se trouvent en dessous de cette moyenne, ce qui traduit une très bonne tendance générale mais avec une forte variation. Le premier de ce classement consomme 3,5 fois moins que le dernier site.

Métriques évaluées ou mesurées par Greenspector
(60 secondes)		Moyenne
Impact carbone (g eqCO2)0,33 gEqCO2
Ressource en eau (Litres)0,05 Litres
Occupation des sols (cm²)0,61 cm²
Consommation d’énergie (mAh)5,27 mAh
Données échangées (Mo)2,61 Mo
Mémoire consommée (Mo)786 Mo
Nombre de requêtes web55
ClassementversionEcoscoreEnergieDonnées échangéesMémoireRequêtesCarbon Impact (gEqCO2)Empreinte Eau (Litres)Empreinte Sol (cm2)
1https://kleis.ch/894,790,55560,80140,230,040,53
2https://commown.coop/774,410,37781,0680,200,040,49
3https://hubblo.org/fr/774,880,15554,14260,240,040,55
4https://www.specinov.fr/764,530,25680,25160,210,040,50
5http://lewebvert.fr/764,770,20828,38200,230,040,53
6https://fresquedunumerique.org/754,360,89676,91330,240,040,49
7https://thegreencompagnon.com/744,680,47861,89140,220,040,52
8http://laruchequicode.com/744,620,40722,78230,230,040,52
9https://www.treebal.green/744,580,43819,20270,230,040,52
10https://smart-consultant.fr/734,560,65659,92150,220,040,51
11https://greenspector.com/fr/accueil/734,680,42638,41360,250,040,53
12https://www.fruggr.io/735,191,42849,56160,260,050,58
13https://algorila.com/724,810,32769,02180,230,040,53
14https://nuageo.fr/724,870,35853,77210,230,040,54
15https://greenoco.io/714,881,62760,39390,280,050,56
16https://www.appyuser.com/715,342,50690,71520,330,060,61
17https://aguaro.io/fr704,091,09655,25380,240,040,47
18https://infogreenfactory.green/694,590,38784,44220,220,040,51
19https://aeonics.io/694,460,51715,91260,230,040,50
20https://conserto.pro/694,750,33733,29180,230,040,53
21https://evea-conseil.com/fr684,516,48724,53980,420,060,55
22https://www.esaip.org/664,541,11720,32410,260,040,52
23https://www.chg-meridian.fr/665,271,99872,71270,290,050,59
24https://lecko.fr/greet/664,832,46927,45570,320,050,56
25https://www.planet-techcare.green/664,862,14865,60630,320,050,57
26https://groupe-isia.com/654,980,87618,44230,250,050,56
27https://www.wedolow.com/655,051,37873,91420,290,050,58
28https://www.luminess.eu/655,063,02699,61380,310,050,58
29https://mind7.com/645,191,40980,03280,270,050,58
30https://www.cisco.com/site/fr/fr/index.html644,561,80768,97800,320,050,54
31https://mavana.earth/634,750,81691,11530,280,050,55
32https://www.alterway.fr/634,800,70790,25530,280,050,55
33https://connexing.co/634,934,50670,17410,340,050,57
34https://www.fairphone.com/fr/625,103,29836,86700,360,060,60
35https://www.monsitevert.fr/605,261,25797,13240,270,050,59
36https://www.preo-ag.com/fr605,442,32942,09570,340,060,63
37https://carbonscore.fr/595,831,67691,48160,290,050,65
38https://www.apl-datacenter.com/fr/584,831,58855,30750,320,050,57
39http://www.magellan-consulting.eu574,926,75847,681430,500,070,62
40http://ijo.tech/565,251,62885,77300,280,050,59
41https://www.capefoxx.com/565,312,36708,23490,320,050,61
42http://agence-lucie.com/565,532,99558,45990,410,060,66
43https://www.soprasteria.com/fr/accueil555,189,43895,83350,430,060,60
44https://holomea.com/614,962,77964,7934,000,300,050,56
45https://www.formulemagique.com/535,451,05888,90840,350,060,64
46https://www.easyvirt.com/515,552,51900,221020,400,060,66
47https://www.colibris.app/506,822,61894,97590,400,070,78
48https://www.weeedoit.com/495,322,52847,771030,390,060,64
49https://www.fujitsu.com/fr/496,117,54816,09950,510,070,73
50https://www.ecologic-france.com/475,332,15941,95330,300,050,60
51https://www.wecount.io/476,723,15719,61430,390,070,76
52https://sopht.com/465,322,81852,101280,430,070,65
53https://www.sentrysoftware.com/437,9615,15935,47870,710,100,94
54https://www.scaledynamics.com/416,813,77876,22830,450,070,79
55https://www.hp.com/fr-fr/home.html386,332,02774,44720,390,070,73
56https://www.technogroup.com/386,2912,71756,05910,600,080,75
57https://www.escapegameenligne.com/376,223,66819,641340,490,080,76
58https://alternative-group.com/367,606,29772,08880,540,080,89
59https://harington.fr/355,937,05987,21740,460,070,70
60http://www.ecodair.org/347,913,71730,611030,520,090,92
61https://greenly.earth/fr-fr296,475,64944,982450,670,100,85

Pour chacun de ses sites web, mesurés sur un smartphone S9 (Android 10), les mesures ont été réalisées avec Greenspector Studio, permettant la réalisation de tests automatisés. Les mesures ont été réalisées le 15 novembre 2023.

Détail des scénarios :
– Chargement de la page d’accueil du site web
– Inactivité du site web en premier-plan
– Scroll
– Inactivité du site web en arrière-plan

Chaque mesure est la moyenne de 3 mesures homogènes (avec un écart-type faible). Les consommations mesurées sur le smartphone donné selon un réseau de type wifi peuvent être différentes sur un PC portable avec un réseau filaire par exemple. Pour chacune des itérations, le cache est préalablement vidé.

Consultez notre méthodologie d’évaluation de l’impact environnemental.

Quel est l’impact environnemental d’ouvrir ou non les liens dans un autre onglet ?

Posted on by Laurent DEVERNAY
Reading Time: 6 minutes

Introduction

Les plus anciens se souviennent peut-être d’une époque lointaine où les navigateurs ne proposaient pas encore d’ouvrir du contenu dans plusieurs onglets. L’apparition de cette possibilité a fait naître un débat qui n’a jusque-là pas trouvé de réponse définitive : faut-il ou non ouvrir les liens par défaut dans un autre onglet ?

Les chiffres clés

Les résultats obtenus pour l’ouverture des liens dans un autre onglet sont synthétisés ainsi :  
L’impact global est de 1.9 gCO2eq, 0,4 L d’eau consommée et 4.1 cm2 d’occupation des sols.  

Les résultats obtenus pour l’ouverture des liens dans le même onglet sont synthétisés ainsi :  
L’impact global est de 1.8 gCO2eq, 0,3 L d’eau consommée et 3.9 cm2 d’occupation des sols. 

Sur un site web, le comportement par défaut lors du clic sur un lien est de l’ouvrir dans l’onglet où se trouve déjà l’internaute. Pour revenir à la page initiale, le plus simple est donc d’utiliser la fonctionnalité de retour en arrière du navigateur (ou celle du téléphone). Ceci peut être vu par certains internautes comme un désagrément. Au moins deux solutions sont possibles :  

  • Côté utilisateur : garder la touche Ctrl appuyée pour ouvrir le lien dans un autre onglet ou cliquer avec la roulette de la souris ou autre 

Dans tous les cas, target=”_blank” doit s’accompagner d’attributs supplémentaires pour des raisons de sécurité, de la façon suivante :  

<a href=”https://greenspector.com/fr/le-petit-bout-de-la-lorgnette/” target=”_blank” rel=”noopener noreferrer”> 

Les valeurs “noopener” (https://html.spec.whatwg.org/multipage/links.html#link-type-noopener [EN]) et “noreferrer” (https://html.spec.whatwg.org/multipage/links.html#link-type-noreferrer [EN]) permettent de s’assurer des informations de contexte ne sont pas transmises au clic sur le lien. En apparence redondantes, elles sont ici mentionnées ensemble afin de prendre en charge certains navigateurs (très) anciens : https://stackoverflow.com/a/57630677 [EN]. 

La discussion sur le fait d’ouvrir ou non les liens dans un autre onglet (ou dans une autre page) ne date pas d’hier et les arguments sont nombreux. On en retrouve une bonne partie ici : https://www.badsender.com/en/2023/01/27/target-blank-links-email/ [EN] 

Du point de vue des impacts environnementaux, il y a également matière à discussion. Ouvrir dans un autre onglet pourrait conduire à multiplier inutilement les onglets ouverts, donc à augmenter les impacts environnementaux (en sollicitant davantage le terminal). Inversement, ouvrir le lien dans la même page pourrait rallonger le parcours utilisateur sur le site d’origine en risquant de lui faire perdre sa progression après être revenu en arrière (saisie d’informations, lecture en cours d’un article, etc).  

Comme toujours, il est important de revenir aux vraies raisons qui motivent ce choix, notamment s’il s’agit d’améliorer les statistiques de son propre site en le gardant ouvert pendant que l’utilisateur explore d’autres liens (ce qui n’est pas une bonne façon de faire). 

À défaut de trouver la réponse idéale à cette problématique, nous avons décidé d’avoir recours à la mesure pour apporter un éclairage supplémentaire.  

Méthodologie 

Une page de test aussi sobre que possible a été créée. Elle comporte deux liens menant vers la même page. Le premier s’ouvre dans le même onglet, le deuxième dans un autre onglet.  

En vue de la mesure, deux scripts GDSL ont été créés pour automatiser le parcours et effectuer les mesures :  

  • Un script qui consiste à cliquer sur le lien qui s’ouvre dans un autre onglet puis revenir au premier onglet (trois fois de suite) 
  • Un script qui consiste à cliquer sur le lien qui s’ouvre dans le même onglet puis revenir en arrière via le navigateur directement (trois fois de suite) 

Dans chacun de ces parcours, on retrouve les mêmes étapes :  

  1. Chargement de la page de test 
  1. Pause de 30s sur la page de test 
  1. Chargement de la page destination (clic sur le lien) 
  1. Pause de 30s sur la page destination 
  1. Retour en arrière 
  1. Pause de 30s sur la page d’origine 

    Les étapes 3 à 6 sont répétées 3 fois chacune, dans cet ordre.  

Dans tous les cas, la page de destination du lien est la même. L’idée était ici de choisir une page légère mais avec suffisamment de contenu pour que les mesures soient significatives. Nous avons donc choisi un article du blog Greenspector : https://greenspector.com/fr/le-petit-bout-de-la-lorgnette/ Au-delà de la première itération, le cache limite les requêtes effectuées en s’appuyant sur les éléments stockés côté client (comme pour toute page web pour peu qu’elle soit correctement configurée). 

Les mesures sont effectuées sur la dernière version en date du navigateur Chrome sur un téléphone Samsung S9 avec la luminosité réglée à 50%, en WIFI. Une dizaine d’itérations de mesures ont été effectuées pour chaque script.  

Les mesures ont été effectuées entre le 24 et le 29 août 2023. Suite à ces mesures, un dashboardcampagne (agrégation des données issues des outils Greenspector) a été généré, notamment pour pouvoir comparer les étapes de mesure et calculer un Ecoscore global basé sur les scores de Performance, Données transférées et Energie.  

En vue de la projection environnementale, on pose les hypothèses suivantes :  

  • 100 % des utilisateurs et serveurs en France 
  • 100% de serveurs complexes 
  • 51% des utilisateurs sur smartphone, 3% sur tablette, 46% sur PC (stats moyennes pour la France) 

Résultats 

Les résultats obtenus pour l’ouverture des liens dans un autre onglet sont synthétisés ainsi :  

L’impact global est de 1.9 g CO2e, 0,4 L d’eau consommée et 4.1 cm2 d’occupation des sols.  

Les résultats obtenus pour l’ouverture des liens dans le même onglet sont synthétisés ainsi : 

L’impact global est de 1.8 g CO2e, 0,3 L d’eau consommée et 3.9 cm² d’occupation des sols. 

Dans un premier temps, il apparaît donc que l’ouverture des liens dans le même onglet est légèrement plus avantageuse d’un point de vue environnemental. En particulier, il apparaît que le parcours est beaucoup plus court lors de l’ouverture dans le même onglet. En effet, il est plus facile de revenir en arrière via le bouton présent sur les téléphones Android que de passer par la liste des onglets ouverts.  

On peut supposer que le fait de garder des onglets ouverts soit davantage impactant du point de vue de la batterie du téléphone. Creusons désormais cela plus en détail.  

Le diagramme suivant présente la consommation énergétique des différentes étapes :  

En bleu, on trouve l’ouverture de liens dans un autre onglet. En noir, l’ouverture dans le même onglet.  

Les étapes du parcours avec ouverture de liens dans le même onglet sont quasi systématiquement moins impactantes. En particulier, ceci est vrai pour les étapes de pause, ce qui semble confirmer l’impact des onglets multiples ouverts lors d’une pause sur l’onglet courant. On retrouve ici le fait que le retour en arrière est beaucoup plus simple via le bouton du téléphone que via la liste des onglets.  

Pour l’ensemble des étapes mesurées, on constate très peu de données transférées. Toutefois, pour un utilisateur ayant recours au retour en arrière, il est important de bien intégrer le bfcache (https://web.dev/bfcache/ [EN]). Cette optimisation des navigateurs permet de fluidifier les retours en arrière et en avant. 

Conclusion 

Si l’on se base sur les métriques et projections environnementales pour le cas de test choisi ici, il apparaît plus avantageux d’ouvrir par défaut les liens dans le même onglet. Il faut en revanche bien garder en tête qu’il ne faut pas que l’internaute perde ainsi sa progression (saisie en cours ou lecture d’une page longue, par exemple). De plus, en vue d’un retour arrière ultérieur, le bfcache doit être correctement implémenté. Dans ce cas, libre à l’utilisateur s’il le souhaite d’ouvrir malgré tout le lien dans un autre onglet via les raccourcis mis à sa disposition. Il reste néanmoins indispensable d’informer sur le comportement des liens s’il ne s’agit pas du comportement par défaut (ainsi que de la langue de la page destination si elle diffère de la page d’origine). Pour conclure, n’oublions pas que l’accessibilité et la qualité (telle que mise en œuvre via les règles d’Opquast) doivent rester une priorité lors de l’intégration de liens.  

Classement 2023 des impacts environnementaux des sites web de 31 écoles d’informatique

Posted on by Laurent DEVERNAY
Reading Time: 6 minutes

Introduction

En mars 2022, nous vous proposions un classement des sites web des 187 grandes écoles et universités. Concernant les écoles d’ingénieur françaises, il en ressortait les résultats suivants : 

Quitte à se focaliser sur les écoles d’informatique, mentionnons la loi REEN (Réduction de l’empreinte environnementale du numérique) : https://www.vie-publique.fr/loi/278056-loi-15-novembre2021-reen-reduire-empreinte-environnementale-du-numerique#faire-prendre-conscience-de-limpact-environnemental-du-num%C3%A9rique 

Cette loi impose en effet, depuis quelques mois déjà, d’intégrer un module sur l’écoconception de services numériques dans les formations d’ingénieur en informatique. À ce jour, le module en question ne semble pas avoir été intégré dans toutes les écoles mais des ressources peuvent d’ores et déjà y aider :  

Ce sujet est essentiel. Un nombre croissant d’entreprises cherchent spécifiquement à recruter des profils au fait de l’écoconception et la demande est de plus en plus forte chez les étudiants.  

Afin de créer le classement des sites web des écoles d’informatique, nous avons fait le choix de nous appuyer sur le classement suivant : https://etudiant.lefigaro.fr/etudes/ecoles-ingenieurs/classement-informatique/  

Nous sommes donc partis sur un échantillon de 31 sites d’écoles.  

Les mesures ont été effectuées en septembre 2023, via un benchmark sur les pages d’accueil de chacun de ces sites. Ceci ne saurait en aucun cas témoigner des impacts de l’ensemble du site ni des engagements environnementaux des établissements mais permet déjà d’avoir un premier point d’entrée.

Des erreurs sont survenues pour la mesure de deux sites :  

En conséquence, ces sites ont été retirés du classement. Nous avons toutefois noté les éléments suivants :  

  • Le site de l’INSA Toulouse a bénéficié d’une refonte depuis notre classement de 2022. Il en ressort une réduction des données transférées et, a priori, une réduction des impacts sur les terminaux des utilisateurs. Pour autant, a minima, quelques optimisations rapides sont encore possibles.  
  • Le site de Télécom Nancy apparaît plutôt lourd, notamment en raison du manque d’optimisation de certains contenus mais surtout d’un manque de sobriété (dont témoigne par exemple l’intégration de plusieurs contenus de réseaux sociaux).

En savoir plus sur la méthodologie et comment Greenspector évalue l’empreinte environnementale d’un service numérique. 

Différentes hypothèses ont été prises pour la projection environnementale :  

  • 100 % des utilisateurs et serveurs localisés en France 
  • 50% sur smartphone 
  • 3 % sur tablette 
  • 47 % sur PC 

Synthèse et chiffres clés 

Suite aux mesures et à la projection environnementale, nous obtenons le classement suivant (en triant par impact GES) : 

URLEcoscore GlobalRequêtes HTTPEnergie (mAh)Données (Mo)Impact GES (gEqCO2)Empreinte Eau (L)Empreinte sol (cm_)
https://www.cpe.fr/61695,762,130,770,131,46
https://www.cesi.fr/72314,633,350,790,141,54
https://www.efrei.fr/61625,302,130,840,151,62
https://www.insa-centrevaldeloire.fr/fr/58864,523,020,840,141,53
https://www.isima.fr/73754,852,130,850,151,61
https://www.polytech.universite-paris-saclay.fr/62365,072,280,850,151,70
https://www.utt.fr/57455,163,440,870,151,68
https://www.esiee.fr/65945,251,780,890,151,67
https://www.esiea.fr/60555,652,210,900,161,76
https://www.insa-rouen.fr/66814,684,000,920,161,69
https://www.3il-ingenieurs.fr/52325,961,510,930,171,90
https://polytech.univ-cotedazur.fr/53534,976,060,960,161,75
https://www.ensiie.fr/50905,295,920,980,161,72
https://www.insa-lyon.fr/541315,144,010,980,161,71
https://enseirb-matmeca.bordeaux-inp.fr/fr50905,427,121,020,171,77
https://www.polytech-lille.fr/43586,295,901,110,192,07
https://www.enseeiht.fr/fr/index.html381035,476,241,120,191,99
https://www.sup-galilee.univ-paris13.fr/48576,842,041,140,202,28
https://ensimag.grenoble-inp.fr/391005,8011,871,220,202,01
https://www.polytech.sorbonne-universite.fr/42726,424,401,240,222,39
https://isen-mediterranee.fr/471286,2410,591,280,212,11
https://www.ensicaen.fr/40538,023,011,280,232,58
https://www.isep.fr/361106,2619,821,420,222,12
https://polytech.univ-tours.fr/40985,9228,491,520,222,04
http://www.enssat.fr/51645,8239,191,570,211,82
https://www.utbm.fr/262827,5213,731,660,262,49
https://www.utc.fr/2013910,9018,842,060,343,50
https://www.epita.fr/367113,894,892,120,384,30
https://cytech.cyu.fr/46695,9967,852,140,261,97

On remarque ici que les métriques ont tendance à être plutôt élevées. Un calcul rapide des moyennes vient confirmer cela :  

  • Ecoscore global : 48,9 
  • Requêtes HTTP : 83,93 
  • Énergie (mAh) : 6,16  
  • Données transférées (Mo) : 9,83 

Selon le site HTTP Archive (à partir d’un échantillon de plusieurs millions de sites web mesurés régulièrement), la moyenne globale sur mobile est de 67 requêtes HTTP et 2,18 Mo (source : https://httparchive.org/reports/page-weight [EN]). Les moyennes pour les sites mesurés ici sont donc bien au-dessus, en particulier pour le poids moyen des pages qui est dans notre cas 4 fois plus élevé. Il semble donc y a voir un souci global pour ce qui est de l’application des principes de sobriété numérique.

Inversement, la page la plus légère (3IL) nécessite le transfert de 1,51 Mo de données (et 32 requêtes HTTP). Ceci en fait un site tout de même assez lourd.  

Nous verrons dans un premier temps les 3 sites les mieux notés puis les 3 sites les moins bien notés. L’idée n’est pas de les explorer de façon exhaustive mais de fournir quelques éléments raîdes d’analyse.

Le Top 3 

CPE

A première vue, la page d’accueil apparaît plutôt légère et sobre. Elle présente peu d’erreurs d’accessibilité, en-dehors de plusieurs soucis de contraste de couleurs.  

On déplore toutefois l’intégration d’un chatbot qui apparaît au bout de quelques instants sous forme de popup.  

CESI

La volonté de sobriété apparaît clairement à la consultation du site : peu d’images, des aplats de couleurs et un focus sur l’expérience utilisateur.  

Il est d’autant plus regrettable que le manque d’optimisation des images augmente considérablement le poids de la page. En particulier, deux d’entre elles font plus d’1 Mo. Il serait également intéressant, dans un second temps, d’optimiser les polices de caractères. Voir notre article à ce sujet.  

EFREI 

Ce site apparaît plutôt lourd, notamment en termes d’images (qui ne sont pas toutes suffisamment optimisées) et via l’intégration de nombreux fichiers pour les polices. En résumé, même si le site est ici bien classé, il n’est pas exempt de défauts.

Le Flop 3 

CY Tech 

Tout d’abord, on constate que la page met beaucoup de temps à charger.  

Le volume de données transférées fournit déjà une première piste d’explication : quasiment 70 Mo en tout ! En regardant de plus près, on compte 14 images pesant plus d’1 Mo, l’une d’entre elles faisant à elle seule plus de 16 Mo. Des efforts de sobriété (mais aussi d’optimisation des contenus) apparaissent donc indispensables. En particulier, le site est très lourd visuellement et peu optimisé pour le mobile. Certaines animations apparaissent superflues (compteurs, parallaxe, etc).  

EPITA 

Le site apparaît relativement peu lourd par rapport aux autres sites du classement.  

Toutefois, on note une importante sollicitation de la batterie du terminal de mesure. L’ouverture du site sur une vidéo en lecture automatique et en boucle explique cela en grande partie, en plus d’être une très mauvaise pratique du point de vue de l’accessibilité. Une autre explication réside dans le grand nombre de services tiers intégrés sur cette page.  

À noter que les images sont cette fois plutôt légères mais trop nombreuses. D’autant plus que certains fichiers sont chargés plusieurs fois.  

UTC 

L’internaute arrive ici directement sur un carrousel en défilement automatique, ce qui reste à éviter aussi bien pour la sobriété que pour l’accessibilité.  

Lors de la mesure de cette page, la durée est limitée à 70s environ. Lorsque l’on reste suffisamment longtemps sur cette page, on arrive à presque 70 Mo transférés pour plus de 600 requêtes. Les requêtes vers Google et Youtube sont très nombreuses.  On découvre lors du défilement de la page de nombreuses vidéos Youtube intégrées directement, d’autres carrousels en défilement automatique mais aussi une vidéo en lecture automatique.  

Afin de visualiser ces requêtes, on a recours ici à une RequestMap (un outil créé par Simon Hearne : https://simonhearne.com/ [EN]) : 

Les requêtes directement liées aux domaines du site sont regroupées en bleu. Toutes les autres correspondent à des services tiers. Même s’ils ne sont pas prépondérants en poids, les services tiers représentent ici plus de la moitié des requêtes. Il serait donc important d’avoir recours à un audit plus poussé sur le sujet afin d’établir un plan d’action portant aussi bien sur la sobriété (limiter le nombre de services tiers) que sur l’efficience (intégrer les services tiers de la façon la moins impactante possible).

Conclusion 

Les sites d’école d’informatique françaises n’apparaissent donc pas particulièrement sobres. Des bonnes pratiques d’écoconception pourraient permettre d’améliorer progressivement la situation. Alors même que ces écoles sont tenues de former leurs étudiants à l’écoconception de services numériques, ce pourrait être l’occasion d’intégrer durablement cette démarche. Ainsi, l’audit du site existant pourrait être intégré dans le module sur l’écoconception proposé aux élèves. Au-delà du fait de réduire les impacts environnementaux de leurs sites web (et de répondre à une obligation légale), ce serait un bon moyen de préparer encore mieux les étudiants au monde du travail.  

  

Publication des Web Sustainability Guidelines du W3C

Posted on by Laurent DEVERNAY
Reading Time: 2 minutes

Le W3C

Le W3C (World Wide Web Consortium : site officiel https://www.w3.org/ [EN]) est un organisme définissant les standards (tels que les éléments techniques régissant le fonctionnement du langage HTML, par exemple) et lignes directrices du web. Il a été créé par Tim Berners-Lee en 1994. 

Dans le cadre du Numérique Responsable, on connaît notamment le W3C pour la publication des WCAG (Web Content Accessibility Guidelines : https://www.w3.org/WAI/standards-guidelines/wcag/ [EN]). Ces règles pour l’accessibilité des contenus web font référence à l’échelle mondiale. Elles servent en particulier de base pour le RGAA (Référentiel Général d’Amélioration de l’Accessibilité : https://design.numerique.gouv.fr/accessibilite-numerique/rgaa/ ), qui sert lui-même de base pour la mise en place de la réglementation sur ce sujet en France.  

Donner un cadre à la sobriété numérique

La sobriété numérique et l’écoconception de services numériques prennent de plus en plus d’importance mais peinent à définir leur cadre d’application. En France, le contexte législatif se précise de plus en plus, en particulier via la loi REEN (Réduction de l’Empreinte Environnementale du Numérique : https://www.vie-publique.fr/loi/278056-loi-15-novembre2021-reen-reduire-empreinte-environnementale-du-numerique ) et le RGESN (Référentiel Général d’Ecoconception de Services Numériques : https://ecoresponsable.numerique.gouv.fr/publications/referentiel-general-ecoconception/ ).  

Nous reviendrons très prochainement sur ce cadre législatif pour vous en proposer une synthèse ainsi que des perspectives.  

Toujours est-il que nous avons accueilli avec beaucoup d’enthousiasme l’annonce par le W3C de leur intention de travailler sur le sujet de l’écoconception de façon concrète (https://www.w3.org/community/sustyweb/2022/04/19/sustainability-recommendations-working-group/ [EN]). J’ai d’ailleurs eu la chance de prendre part à ce groupe de travail (avec Thierry Leboucq). L’objectif était de produire des guidelines (lignes directrices) pour pouvoir par la suite définir des standards. C’était l’occasion de faire quelques belles rencontres et de confronter les pratiques de sobriété numérique avec des experts du monde entier. Bravo à Tim Frick et Alexander Dawson pour avoir encadré tout cela, ainsi qu’à tous ceux qui ont contribué aux sous-groupes dédiés à des thématiques précises :  

  • UX Design 
  • Web Development 
  • Hosting & Infrastructure (dont j’assurais le suivi) 
  • Product & Business Strategy 
  • Metrics 

La sortie officielle d’une première version des Web Sustainability Guidelines ouvre ces travaux à tous : https://www.w3.org/community/sustyweb/2023/09/07/web-sustainability-guidelines/ [EN]. Vous y trouverez 93 recommandations et 232 critères de succès. Tout ceci s’aligne avec les normes GRI (Global Reporting Initiative : https://www.globalreporting.org/how-to-use-the-gri-standards/gri-standards-french-translations/ ).

Et maintenant ? 

La publication des WSG constitue un jalon historique pour appliquer la sobriété numérique au web. Mais gardons bien en tête que ce n’est que le début. Cette publication a avant tout pour but de récolter les retours des experts puis de voir comment définir ce cadre de façon encore plus précise. Il est aussi souhaitable que ces travaux servent de base pour que le sujet soit adopté plus largement et que des pays puissent s’en servir afin de définir un cadre législatif. Ce socle apparaît également essentiel pour former et sensibiliser sur le sujet mais aussi en tant que support pour des démarches de réduction des impacts environnementaux des sites web.  

Chez Greenspector, nous avons l’intention de continuer à contribuer à ce référentiel, notamment en apportant nos retours, basés sur notre expérience concrète de l’écoconception de services numériques. Très prochainement, ces guidelines seront intégrées aux bonnes pratiques sur lesquelles nous nous appuyons au quotidien, ainsi qu’aux sessions de sensibilisation à l’écoconception que nous proposons.

Ainsi, nous pourrons voir plus en détail comment concilier les WSG avec les référentiels existants (RGESN et RG491 principalement).

 

Bonne pratique : optimiser les polices de caractères

Posted on by Laurent DEVERNAY
Reading Time: 4 minutes

Depuis quelques années, l’utilisation de polices de caractères sur le web a explosé (aussi bien en nombre de polices existantes que de sites y ayant recours).

Comme souvent, le Web Almanac est une mine d’informations, notamment via le chapitre dédié aux polices. On y apprend notamment que les deux principaux fournisseurs de polices web sont Google puis Font Awesome, cette dernière consistant en la mise à disposition d’icônes. Au-delà du coût potentiel sur la performance et les impacts environnementaux, certains pays ont déjà établi que ceci pouvait contrevenir au RGPD (Règlement Général sur la Protection des données).  

Proportion de sites web utilisant des web fonts 

Voyons désormais quelles bonnes pratiques peuvent permettre de réduire l’impact des polices de caractères sur le web.  

Référentiels existants 

Les polices sont mentionnées dans la famille UX/UI du RGESN (Référentiel Général d’écoconception de services numériques) :  

  • 4.10 – Le service numérique utilise-t-il majoritairement des polices de caractères du système d’exploitation ? 

On les retrouve également dans le GR491 (Guide de référence de conception responsable de services numériques) :  

Enfin, les 115 bonnes pratiques d’écoconception web les mentionnent également :  

Bonnes pratiques 

Objectifs 

Afin de réduire les impacts des polices de caractères, plusieurs bonnes pratiques sont applicables :  

  • Privilégier les polices standard/système : ainsi, on évite des requêtes supplémentaires 
  • Utiliser un format de compression optimal (aujourd’hui, il s’agit du format WOFF2). Des outils en ligne comme Everything Fonts peuvent assurer cette conversion. 
  • Limiter le nombre de variantes utilisées ou privilégier une police variable 
  • Ne charger que les caractères réellement utilisés (par exemple via un subset) 

Quand ? 

Ces bonnes pratiques doivent intervenir dès la conception visuelle du service afin de privilégier les polices standard autant que possible. Si ce n’est pas possible, limiter alors le nombre de variantes à charger. Enfin, lorsque les polices sont intégrées, privilégier le format woff2, les polices variables et s’assurer de ne charger que les caractères ou langues réellement utilisés.  

Facilité de mise en œuvre 

Si le site est déjà en ligne, il peut être compliqué de modifier la police utilisée. En revanche, les optimisations techniques sont faciles à mettre en œuvre (format, police variable, Subset).

Gains estimés

Ces bonnes pratiques permettent de diminuer le nombre de requêtes HTTP ainsi que le volume de données transférées.

Cas particuliers 

Google Fonts

Afin d’éviter les problèmes avec le RGPD, il est recommandé d’héberger les polices Google soi-même.
Si des versions variables ne sont pas disponibles pour toutes, certains créateurs proposent ces versions gratuitement. En complément, l’API Google permet directement de créer un Subset avec une requête de ce type : https://fonts.googleapis.com/css?family=Montserrat&subset=latin 

Icônes

Les polices d’icônes sont plutôt répandues. Les utiliser directement peut impliquer de charger de nombreuses icônes qui ne seront pas forcément utilisées. Le mieux dans le cas des icônes est d’utiliser directement chacune d’entre elles au format SVG. Sous cette forme, elles peuvent être intégrées directement dans le HTML (sans requête HTTP supplémentaire). Si une police d’icônes doit être conservée pour des raisons pratiques, limiter le fichier aux icônes réellement utilisées.

Cas d’étude 

Dans le cadre de l’accompagnement des équipes de Docaposte pour leur site institutionnel, les polices de caractères constituent comme souvent un chantier à part entière.  

Les polices utilisées ici sont deux Google Fonts : Montserrat et Barlow. Le site étant déjà en ligne, il est compliqué d’imposer le recours à des polices standard.  

Afin d’éviter de contrevenir au RGPD mais aussi pour améliorer la performance du site, les polices sont hébergées directement sur les serveurs de Docaposte. Dans un second temps, la mise en place d’un sous-domaine dédié pourrait permettre de s’affranchir des cookies.  

L’intégration sous la forme d’une police variable nécessite quelques ajustements supplémentaires, notamment au niveau des feuilles de style. En attendant, il a été décidé d’appliquer deux bonnes pratiques :  

  • Proposer les fichiers au format woff2 plutôt que woff 
  • Le site n’étant proposé qu’en français et en anglais, un Subset a été créé ne conservant que l’alphabet Latin. 

Requêtes initiales 

Requêtes après Subset et conversion au format woff2 

Le format woff2 offre une compression supérieure en moyenne de 30% par rapport au format woff  et encore plus par rapport à d’autres formats comme ttf.  

Ce changement de format, combiné au Subset, a permis de faire passer le poids total des polices d’un peu plus de 400 ko à un peu moins de 90 ko soit une réduction de 78% environ.  

Aller plus loin