Catégorie : Zone technique

Ce document synthétise la méthodologie utilisée par Greenspector pour évaluer l’impact environnemental des applications mobiles et des sites web. Il présente le framework de mesure de Greenspector et les rapports qu’il génère. L’objectif de ce framework est d’évaluer et de réduire l’impact environnemental des applications web et mobiles, en allongeant la durée de vie des batteries des appareils mobiles, en s’attaquant à l’obsolescence technologique et aux bloatwares, mais aussi en limitant leur poids sur les infrastructures réseau et back-end. La méthodologie de Greenspector s’appuie sur l’état de l’art industriel et scientifique, et ses détails techniques sont publiquement accessibles dans le livre blanc et les publications scientifiques de Greenspector. 

Cadre de mesure 

Greenspector évalue les performances des unités fonctionnelles des applications et sites Web, plutôt que les applications et les sites Web dans leur ensemble. Cette granularité permet d’évaluer indépendamment chaque fonctionnalité et chaque usage, et est conforme aux normes existantes (ISO 14040). Ces unités fonctionnelles représentent des parcours utilisateurs, c’est-à-dire un ensemble d’actions effectuées par un utilisateur. Ils sont automatisés avec GDSL, un langage propriétaire permettant des mesures cohérentes et reproductibles. 

Les parcours utilisateurs sont exécutés sur les appareils physiques du banc de test de Greenspector. Ces appareils sont surveillés et stabilisés pour assurer que les résultats de performance sont valides. Leur consommation d’énergie et de données est surveillée tout au long de l’exécution des parcours utilisateur, et les données qui en résultent sont agrégées et fournies dans un rapport.

Plus précisément, chaque parcours reçoit une note évaluant son efficacité énergétique, sa consommation de données et sa durée, ainsi qu’une estimation de ses impacts environnementaux, à l’aide d’une méthode décrite ci-dessous. De plus, les données sont centralisées sur un tableau de bord permettant de suivre les performances de l’application analysée tout au long de son développement. D’autres métriques et indicateurs sont également surveillés, afin de permettre une analyse plus approfondie des résultats. 

Le framework de mesure est résumé dans la figure suivante. L’application à évaluer et les parcours utilisateurs associés sont partagés à notre banc de test soit manuellement depuis un outil en ligne de commande, soit automatiquement à partir d’un  pipeline CI/CD. Notre banc de test exécute les parcours utilisateurs sur des appareils physiques tout en surveillant leurs activité. Les données et les rapports qui en résultent sont fournis sur le portail Web Greenspector Studio. Si le test a été déclenché à partir d’un CI/CD, les notes des parcours peuvent être utilisées comme critère de réussite du pipeline.  

Rapports fournis 

Les 3 principaux indicateurs surveillés sont synthétisés en une seule note : l’Ecoscore. Cette note quantifie la qualité d’un parcours utilisateur donné, sur une échelle de 0 à 100, en fonction de trois critères : la durée de chaque étape du parcours, son utilisation du réseau et sa consommation d’énergie sur le terminal.

L’Ecoscore est fourni dans un rapport contenant des détails supplémentaires sur les performances de chaque étape du parcours étudié. Ce rapport permet de localiser les problèmes techniques et de conception, et de prioriser les corrections et les améliorations. Greenspector récompense les Ecoscores les plus élevés avec des labels d’éco-conception.  

Ce rapport fournit également une estimation de l’impact environnemental des parcours utilisateurs dans sept catégories d’impact, conformément aux recommandations relatives à l’empreinte environnementale des produits (PEF), telles que le changement climatique, l’épuisement des ressources métalliques ou l’écotoxicité de l’eau douce. L’impact environnemental d’un parcours utilisateur est estimé en tenant compte de son impact sur les terminaux des utilisateurs finaux, le réseau et les infrastructures back-end.
Cet impact tient également compte à la fois de la consommation d’énergie et de l‘impact sur le cycle de vie du matériel impliqué dans ces trois couches. Plus précisément, l’impact des appareils de l’utilisateur final est estimé à partir de la consommation d’énergie du parcours utilisateur, tandis que l’impact des infrastructures réseau et back-infrastructure est estimé à partir de l’utilisation des données du parcours. Cet impact permet d’explorer différents scénarios d’utilisation, tels que différents types de connectivité ou un mix électrique différent pour chacune des trois couches. L’impact individuel pour l’exécution d’un parcours utilisateur peut alors être mis à l’échelle du nombre d’exécutions du parcours sur une période donnée. 

Thierry Leboucq

Ces tests sont lancés sur notre banc de test Cloud sur des devices réels pour 30 sites différents : 

Vous retrouverez les noms des étapes suivantes dans tous les résultats : 

• CHRGT_initial : Chargement initial de la page 
• PAUSE_initial : Idle sur la page pendant 30s 
• CHRGT_AfternRGPDAgreement : Chargement de la page suite à l’acceptation des cookies 
• PAUSE_final : Idle sur la page après validation pendant 30s 

Fonctionnement des cookies

Le RGPD demande aux fournisseurs de services de demander le consentement à l’utilisateur quant aux données personnelles qui vont être utilisées. Cela implique donc de mettre en place un mécanisme de notification. Il s’agit généralement d’un bandeau.

L’utilisateur peut accepter ou refuser les cookies non-nécessaires. Il peut aussi, si le fournisseur le permet, refuser ou accepter finement par rapport à une liste. Il peut aussi ne pas donner suite aux notifications. Dans ce cas, si le placement du bandeau le permet, il peut continuer à utiliser le service. 

Si certains services ne sont pas acceptés, cela impliquera que certaines fonctionnalités ne soient pas disponibles pour l’utilisateur par exemple un plugin de chat). Dans la plupart des cas, comme par exemple pour les publicités, le service sera fonctionnel, mais aucune information personnelle ne pourra être utilisée par le service (par exemple pour proposer des publicités ciblées). Certains services « oublient” la réglementation alors qu’ils devraient la gérer (par exemple les Google fonts). 

Certains sites bloqueront le service totalement, on appelle cela un cookie wall. Ce type de notification est répandu dans les sites d’information que nous avons évalués. 

Pour plus d’information sur le RGDP, nous vous invitons à suivre le MOOC CNIL.

Résultats macro

La médiane des données chargées des sites est à 1,3MB (bleu foncé). Ensuite, pour la plupart des sites, l’inactivité n’implique que très peu de données (en orange) ; c’est ce que l’on attend car aucun service ne doit être lancé. On observe cependant certaines “anomalies” (les points au-dessus des moustaches). Il s’agit généralement de vidéos qui sont lancées automatiquement. Ceci est potentiellement une anomalie d’un point de vue RGPD et d’un point de vue sobriété (La lecture automatique des contenus n’est pas recommandée). Cependant, on peut aussi imaginer que le service vidéo qui se lance n’utilise pas de données personnelles et le fera ou non à la suite de la validation. 

Le chargement suite à la validation des cookies implique le chargement supplémentaire de 1Mo de données. C’est un comportement normal, car la validation des cookies devrait enclencher le chargement de certains services. On voit cependant, vu le ratio (1,3Mo avant), on peut supposer que des services sont chargés (et pas nécessairement tous appelés) avant la validation. C’est un gaspillage, car si l’utilisateur ne valide pas les cookies, le chargement d’une librairie n’est pas nécessaire. 

On peut noter que certains services de gestion de cookies traitent cela nativement (par exemple https://tarteaucitron.io/fr/).

Avec la validation des cookies, on voit une consommation de données qui augmente, ceci étant normalement dû au chargement des services autorisés. 

Sur francebleu.fr, on voit par exemple juste après le chargement initial et avant la validation, le chargement du widget meteofrance  (plus de 400ko). La validation des cookies n’amène aucun chargement (donc tout a été chargé avant validation). On peut alors se poser la question sur l’usage de données personnelles dans ce cas (voir par exemple l’analyse de Pixel de Tracking) 

À l’opposé, cnews.fr a une consommation de données à 0 ko suite au chargement initial et une consommation importante suite au consentement des cookies.

À noter sur ce dernier cas, si l’on ne consent pas aux cookies, il y a un peu moins de cookies cependant il semble qu’il y ait toujours beaucoup de requêtes (23 versus 27). Cela s’explique que certains services sont totalement bloqués mais que de nombreux services sont lancés (avec normalement aucune donnée personnelle utilisée).

Energie

Concernant l’énergie, nous allons observer deux métriques : l’énergie totale consommée sur l’étape et la vitesse de décharge de l’étape. 

La consommation d’énergie est légèrement plus importante au chargement suite à la validation des cookies. Ceci est  principalement lié au chargement des librairies autorisées avec les cookies et d’autre part à des repaints et reflows de la page suite à ces chargements. Ceci dit, le contenu utile (photo, texte) est généralement chargé initialement, le coût du consentement amène, en termes d’énergie, à un équivalent de deuxième chargement. 

La consommation lors des étapes d’inactivité est plus importante suite à la validation. Le déclenchement de certaines librairies d’analytiques et des vidéos induisent effectivement une surconsommation.

Vitesse de décharge

À noter, la consommation écran inactif suite au chargement initial pourrait être limitée. Par exemple sur Cnews.fr, une animation de type chargement de contenu en arrière-plan fait tripler la consommation de base du téléphone.

Mémoire

La validation du consentement fait augmenter la consommation mémoire. Ceci s’explique pour les librairies qui sont chargées. 

Voici l’exemple du chargement suite à consentement pour leparisien.fr, on observe bien les augmentations de l’utilisation de la mémoire à chaque chargement de librairie : 

Refus du consentement, moins d’impact ? 

Nous avons aussi automatisé le parcours de refus des cookies. Cependant, de nombreux sites n’ont pas pu être mesurés pour différentes raisons : 

• Pas de bouton accessible facilement pour refuser, cela étant bien sûr en désaccord avec la RGPD (Cela aurait été potentiellement possible d’automatiser mais aurait demandé un peu plus de temps, et cela est dans tous les cas représentatifs d’un problème d’UX : les utilisateurs vont difficilement refuser les cookies. 
• Le refus sans un abonnement n’est pas possible 

Exemple d’UX avec un refus possible (même s’il aurait été plus accessible avec un bouton plus visible, il est dans la pop-up initial) :

On peut féliciter les sites qui restent dans la liste, le bouton de refus était accessible facilement !

Dans la plupart des cas, l’énergie consommée est plus faible suite à un refus qu’un consentement. Ceci semble logique par rapport à des chargements moins importants de librairies. 

Dans certains cas comme Cnews, on a vu que le refus n’annulait pas certains services comme les vidéos (ce qui est potentiellement normal si le service n’utilise pas de données personnelles).

Sur la mémoire, on voit vraiment l’impact du consentement.

Concernant les données, le refus du consentement amène encore beaucoup de données, parfois autant que l’acceptation (gris versus bleu ciel). La consommation en inactivité est légèrement plus faible.

Pas de réponse à la notification, moins d’impact ?

Il est clair que si aucune réponse n’est donnée à la notification, l’impact est beaucoup plus faible (c’est uniquement l’impact du chargement initial). On peut moduler cela sur mobile et sur les sites évalués, car il s’agit de pop-up de notification qui ne permet pas une navigation sans réponse.

Analyse de l’impact

Nous allons maintenant utiliser le modèle d’impact Greenspector pour estimer l’impact environnemental des différents états de la validation RGPD. Pour cela, nous prenons l’hypothèse d’une localisation des utilisateurs et des serveurs en France, toutes les phases du matériel étant prises en compte. 

Nous estimons l’impact à chaque fois du chargement de la page et de 30s d’inactivité.

Le chargement initial est beaucoup plus faible que l’étape de validation RGPD (et des 30 secondes d’inactivité). Ceci s’explique par les éléments relevés plus haut (chargement des scripts, repaint, librairies qui fonctionnent…). La borne maximale est à 0,3g eq Co2 en chargement initial alors qu’elle est à 0,55 g pour la validation RGPD.

Quand on prend le panel de sites que l’on a mesuré avec le refus des cookies.

L’impact est relativement plus faible, ce qui normal mais la borne maximale est égale à celle avec validation RGDP. Statistiquement, dans tous les cas, l’impact augmente suite à une validation ou refus RGPD. Cela s’explique par le fait que le refus implique même parfois de scroller pour atteindre les boutons à cliquer afin de valider son choix.

Prise en compte des cookies dans les outils d’évaluation de l’impact 

L’un des biais de la mesure de pages d’un site via la plupart des outils est que l’on simule la navigation par un utilisateur qui n’interagit pas avec la page. Entre autres, aucun choix n’est effectué pour le consentement au recueil des données personnelles. Dans ce cas on évalue qu’un tiers des cas possibles (validation et refus ne sont pas évalués). 

Deux solutions sont possibles :  

• On simule les cookies dans les headers via les outils de mesure 
• On automatise le parcours utilisateurs. 

La deuxième solution est préférable car on sera proche de ce qui se passe chez l’utilisateur. En effet, l’UI de la validation des cookies implique de scroller pour atteindre des boutons et de nombreux boutons sont disponibles, la validation implique le chargement de scripts (et pas la simulation des cookies).  

Exemple d’usage du header pour simuler les cookies sur lighthouse : 

lighthouse <url> --extra-headers "{\"Cookie\":\"cookie1=abc; cookie2=def; \_id=foo\"}"

Comment utiliser Greenspector pour évaluer la validation des cookies sur son service numérique ?

Nous utilisons principalement l’approche d’automatisation pour gérer les cookies. Pour cela nous utilisons le langage GDSL de l’outil qui permet d’automatiser simplement un parcours. 

Il est important en effet de bien gérer les cookies. Si vous testez votre site avec les outils développeurs ou avec des outils de monitoring synthétique, vous risquez d’être toujours dans le même cas (soit cookies jamais validés soit le contraire) 

Nous lançons une première fois l’url et nous attendons la fin du chargement. Le chargement est encadré par measureStart et measureStop, ce qui permet de mesurer différentes métriques sur le chargement : performance, énergie, donnée… 

browserGoToUrl,${URL} 

measureStart,CHRGT_initial 

pressEnter 

waitUntilPageLoaded,40000 

MeasureStop

Nous mesurons ensuite le site inactif, normalement la pop-up de cookies est apparu avec le chargement. 

measureStart,PAUSE_initial 

pause,30000 

MeasureStop 

Nous nous attendons ici à une consommation de donnée faible, car aucun service ne doit être encore autorisé. 

Nous traitons ici un service de gestion de cookies que l’on retrouve dans une grosse partie des sites d’information (Didomi)

if,exists,id,didomi-popup 

measureStart,CHRGT_AfterRGDPAgreement 

swipeDownward 

swipeDownward 

swipeDownward 

clickById,didomi-notice-agree-button 

waitUntilPageLoaded,40000 

measureStop 

Fi

Le if permet d’exécuter la séquence uniquement si la pop-up est présente. Nous scrollons 3 fois pour arriver en bas de page avec swipeDownward et nous cliquons sur le bouton de validation qui est standardisé avec un identifiant didomi-notice-agree-button. 

Nous réalisons ensuite une mesure du site inactif :

measureStart,PAUSE_final 

pause,30000 

MeasureStop 

D’autres lignes de test sont présentes pour gérer d’autres framework de cookies, nous ne rentrerons ici pas dans les détails. Contactez-nous si vous voulez intégrer ce type de test ! 

Bonnes pratiques 

Le processus de notification des cookies a un impact non négligeable. Compte-tenu du fait que cette fonctionnalité se retrouve sur quasiment tous les sites, il est important d’appliquer des bonnes pratiques pour réduire son impact.

Ne pas utiliser de plugin du tout et regarder la préférence de l’utilisateur 

Très peu utilisé mais très pratique, l’utilisateur peut configurer l’option Global Privacy Control dans le navigateur. Ceci impliquera de gérer le header associé.

Ne pas utiliser de plugin du tout en rendant les cookies optionnels inactif  

En effet, les cookies pour certains services ne nécessiteront pas de notification. Ceci nécessitera peut-être une configuration des plugins (voir exemple pour les analytics ici). Cette approche est louable car elle ira dans une démarche de Privacy By Design.

Laisser l’utilisateur naviguer sans validation des cookies 

Ceci permettra d’éviter des traitements inutiles.

Ne pas cacher les services qui utilisent des données personnelles 

Cela va mieux en le disant, il faut éviter les dark patterns qui permettent de récupérer les données personnelles.

Chargement du script de notification au plus tôt 

Afin de réduire l’impact de la notification lors du chargement initial, il faut charger le plugin de gestion des cookies au plus tôt: 

• Charger le script de façon asynchrone avec Async 
• Etablir une connexion au plus tôt avec le site d’origin du cookies avec dns-prefetch ou preconnect 
• Pré-charger le plugin avec preload

Réduire l’impact du plugin de notification 

• Benchmarker les plugins pour identifier les librairies qui ont un impact le plus faible (taille et cpu) 

• Proposer une interface de gestion des différents services simple et efficiente 
• Proposer un bouton visible de refus (au même niveau que l’acceptation) 

Eviter les layout shift du au plugin de notification 

• Utiliser des sticky footer ou des modals pour éviter des layout shift 
• Eviter les animations dans le plugin de notification  

• Limiter la stylisation de la notice (par exemple utiliser les polices systèmes) 

Eviter les animations lors de la notification 

Mettre un placeholder de chargement du contenu en arrière-plan pour indiquer à l’utilisateur l’attente amènera une surconsommation inutile. La pop-up de notification est déjà une information d’attente.

Ne charger les librairies optionnelles qu’à la validation 

Si certaines librairies ne peuvent pas être chargée si pas de consentement, alors il faut prévoir le chargement uniquement au consentement.

Limiter l’impact des librairies chargées à la validation

• Réduire leur taille (ou benchmarker les pour avoir une plus légère) 
• Eviter les impacts sur le shift layout (limiter et regrouper par exemple les modifications du dom) 

Pour les librairies nécessaires mais qui ont une prise en compte du consentement, charger au plus tôt la librairie

Il est nécessaire d’appliquer les mêmes stratégies que pour le chargement de la notification mais de charger la librairie sans gestion de données personnelles. Elles seront prises en compte dynamiquement uniquement si consentement.

Tester votre solution avec différents comportements de consentement 

Les mesures le montrent, l’impact de votre solution va varier énormément en fonction de l’utilisateur : avec consentement, avec refus du consentement ou sans actions de l’utilisateur. Il est important de maîtriser dans ce cas les chargements des différentes librairies et de connaitre le comportement réel. Des améliorations sont sûrement possibles ! 

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

D’après l’étude ADEME/Arcep de 2022, le réseau en France est responsable de 2 à 14% de l’impact environnemntal des activités numériques. Les réseaux fixes génèrent plus d’impacts que les réseaux mobiles (entre 75% et 90%). Cependant compte tenu de l’usage plus important des réseaux fixes, l’impact unitaire, ramené par exemple à un utilisateur ou à un volume de données échangées est plus faible pour le réseau fixe.

De ce constat, en découlent certaines préconisations encourageant l’usage des réseaux fixes plutôt que les réseaux mobiles. Ceci est en phase avec les préconisations sur les 10 bons gestes pour le télétravail de l’ADEME :

Cet impact du réseau se retrouve également dans la loi AGEC. Les opérateurs de communication doivent en effet afficher le coût EqCO₂ lié à la consommation par l’utilisateur.

Evaluation du réseau dans le cas de services numériques

Quand il s’agit d’évaluer les impacts environnementaux d’un service numérique, la prise en compte du réseau est nécessaire. L’approche communément utilisée est l’usage de l’intensité en gEqCO₂/Go (équivalent CO₂ par gigaoctet échangées). Cela part de l’hypothèse d’une linéarité entre l’impact CO₂ et les données échangées.

Pour certaines parties comme la box de l’utilisateur, nous avons utilisé une méthode d’allocation temporelle et non basée sur l’intensité.

Lors de l’évaluation du service numérique, il est aussi nécessaire d’avoir un détail entre les différentes connexions (Wifi, 4G…) 

À travers le rapport de la loi AGEC, nous avons deux métriques intéressantes : 

• 50 gEqCO₂ / Go pour les réseaux mobiles 

• 18 gEqCO₂ / Go pour le réseaux fixes 

Les hypothèses associées ne sont cependant pas assez explicitées. En effet, l’impact du réseau va dépendre de nombreux éléments et hypothèses :

• Scope pris en compte (Scope 3 en prenant en compte les opérations de l’opérateur réseau) 
• Fabrication du matériel ou non 
• Prise en compte de la box de l’utilisateur 
• … 

Si on regarde d’autres sources utilisables directement, Il n’y a pas plus d’information. Par exemple, la base ADEME contient les données Negaoctet et en particulier deux métriques sur le mobile et le fixe :

Même si sourcé, aucune information ne permet d’analyser les données. D’autant plus qu’il est nécessaire quand on veut analyser l’impact du numérique précisément. C’est le cas de la méthodologie Greenspector.

Analyse des données du marché

Afin d’apporter plus de précisions à nos évaluations, nous avons réalisé un travail de R&D pour avoir des facteurs d’émission plus fiables. 

Nous avons modélisé le réseau en plusieurs tiers : 

• Le cœur de réseau (backbone) qui assure l’interconnexion du réseau 
• Le réseau d’accès, plus proche de l’utilisateur avec des architectures spécifiques à chaque type de connexion (3G,Fibre…) 
• Le CPE (Customer Premise Equipement), principalement la box chez l’utilisateur 

Nous avons écarté le terminal utilisateur de la modélisation. Nous verrons en fin d’article comment le traiter spécifiquement. 

Pour les types d’accès, nous avons regroupé : 

• Filaire Fibre 
• Filaire Cuivre (xDSL) 
• GSM “Ancienne génération” (2G et 3G) 
• GSP “Nouvelle génération” (4G et 5G) 
• Wifi Public (hotspot) 
• Lan d’entreprise en Wifi 
• Lan d’entreprise en Ethernet 

Il serait intéressant de descendre plus dans le regroupement (par exemple séparer 4G et 5G) cependant ce regroupement est adapté à la granularité des données disponibles.

Nous avons analysé 35 sources publiques (Rapport RSE opérateurs, papier scientifique, données constructeurs). Chaque donnée identifiée dans les documents a été classée par rapport aux 7 types d’accès, au tiers du réseau, au scope pris en compte (Fabrication/Usage en particulier). 169 données ont été identifiées. Nous en avons retenu 145 (certaines données ne semblaient pas pertinentes). 

La qualité de chaque donnée a été qualifiée selon notre méthodologie. 39 paramètres ont été ainsi qualifié (Cœur de réseau Usage, Cœur de réseau fabrication…) avec un format compatible avec notre méthodologie (Trapèze de détermination utilisable en logique floue). Par exemple pour l’impact d’usage du réseau d’accès fibre, nous avons les valeurs suivantes : 0,1293 / 0,3181 / 0,7891 / 1,9415. Ce qui veut dire que l’impact du réseau d’accès fibre, selon la bibliographie est probablement entre 0,3 et 0,78 Wh/GB. 

Au final, on peut représenter le modèle de la manière suivante :

Ce modèle peut être utilisé dynamiquement en précisant certains paramètres : durée de vie des CPE, mix énergétique… Notre API traite cela automatiquement.

Quel est l’impact probable de chaque réseau ?

En prenant l’unité fonctionnelle “Charger un site de 2 Mo en 1 seconde”, nous obtenons un impact Carbone du réseau suivant :

La fibre est largement moins impactante que les autres types d’accès. Le classement 4G/5G devant l’ADSL semble contre-intuitif, surtout par rapport aux messages que l’on entend régulièrement : « Privilégiez la connexion Filaire à la 4G » comme cité plus haut. Ces affirmations sont fausses pour différentes raisons : 

• L’impact des antennes de base et du réseau d’accès des anciennes technologies GSM est effectivement plus consommatrice. Les chiffres des anciennes études sont basés sur ces constats. Il est important d’adapter les préconisations en fonction des technologies et de l’âge des études. 
• Certaines études parlent de l’impact du réseau sur le terminal. Par exemple la documentation Eco-index annonce “(…)une connexion 4G nécessite jusqu’à 23 fois plus d’énergie pour transporter la même quantité de données qu’une connexion ADSL. (..)” Or la source utilisée est une étude sur l’impact de la connexion LTE sur des smartphones au niveau cellules. Nous reviendrons plus loin sur la réalité sur le smartphone.

On peut observer des marges d’incertitudes pour les réseaux XDSL et GSM ancienne génération :

Ceci provient d’une part des données d’études plus anciennes (et donc pondérées par notre algorithme) et d’autre part par une diversité de technologies plus importantes. 

La part de fabrication est variable en fonction des technologies : 

On peut noter une amélioration de l’efficience énergétique des réseaux nouvelles générations, c’est en effet un argument largement cité pour promouvoir les nouvelles architectures. 

Analyse critique des données d’impact du réseau

• Malgré le modèle qui prend en compte un tri et une qualification des données, le scope de toutes les données n’est pas identifié. On peut trouver des chiffres avec l’impact de fabrication “brute” et potentiellement d’autres avec le scope 3 de l’opérateur (L’impact des bureaux, entre autres de l’opérateur). Ceci est pris en compte dans le modèle via les marges d’incertitude. 
• Le modèle d’intensité du réseau en EqCO₂/GB est utilisé. Il n’est pas totalement représentatif de la réalité. Afin d’améliorer la représentativité, il faudrait plus de source pour avoir une allocation temporelle (Débit des réseaux, consommation par utilisateur…). Nous avons commencé à passer certaines métriques comme les données Box avec ce mode d’allocation.  
• Il existe des éléments communs entre les réseaux, et parfois spécifique. Par exemple il y a des éléments backbones spécifiques pour la 5G. Il serait nécessaire de prendre cela en compte. 
• Même si nous avons un niveau de granularité permettant de prendre en compte le mix énergétique dynamiquement, certaines données intègrent certaines des mix de pays différents. Ce qui pour certaines données, surestime potentiellement la valeur. 

Nous avons comparé nos métriques avec d’autres données du marché (pour 1GB).

Les valeurs Greenspector sont supérieures aux valeurs NegaOctet et Ademe (Les valeurs ARCEP/ADEME sont cependant supérieures au seuil bas Greenspector). Les données Telefonica sont supérieures (pour le fixe) au seuil haut de Greenspector (et identiques pour le mobile). 

Cette différence s’explique probablement par le fait que nous avons intégré de nombreuses valeurs de fabrication du réseau. Une deuxième explication est peut-être une sous-estimation des valeurs pour la France qui positionne ses chiffres dans un seuil bas. Sans entrer dans un débat, ces chiffres sur l’impact du réseau sont souvent surveillés, la tendance est peut-être à la sous-estimation des chiffres plus qu’à la surestimation ! 

Spécificité

Est-ce que les connexions autres qu’une box d’un particulier sont plus sobres ? 

Oui, ceci s’explique par le fait que ce type d’architecture est plus mutualisée. D’une part le matériel a une capacité de bande passante plus importante, donc une allocation par donnée échangée plus faible et d’autre part un impact de fabrication relative faible (pour la capacité). 

A noter on retrouve un impact un peu plus élevé du wifi que de l’éthernet. On retrouve cela sur les box (par exemple +3 Wh/h en plus sur une box orange).

Impact du réseau sur le terminal

Nous mesurons les applications mobiles et sites web tous les jours pour nos clients, nous traitons donc de l’impact du réseau sur le terminal et surtout sur le logiciel. Ce que l’on peut dire “à dire d’expert” mais basé sur des mesures, c’est que l’impact des réseaux GSM n’est pas 23 fois plus important, ni 10 fois plus.  

Voici quelques données de mesures sur une application de streaming (uniquement le lancement et la connexion à l’application, pas le streaming en lui-même) :

On le voit pour la connexion (2ème graphique), il y a quelques données (~700 KB) et la consommation est quasiment la même, voire légèrement supérieure pour la connexion Wifi.  

Pour le chargement de l’application (1er graphique), le Wifi est légèrement moins consommateur. On observe cependant une consommation importante de données (4MB vs 600kB). Ceci s’explique par un comportement différent de l’application en Wifi (chargement de données en plus si connexion Wifi). On voit ici un impact important sur le temps de chargement (passage de 4s à 7s pour la 3G). 

Le réseau va au final avoir un impact, cependant il n’existe pas de règle figée : 

• Si l’application adapte son comportement au type de connexion et à la vitesse, alors on aura potentiellement plus de données chargées sur les connexions avec plus de débit. Et aussi potentiellement plus de CPU pour traiter ces données 
• Pour des connexions type 3G/2G, le temps de chargement sera potentiellement plus long (parfois x2 voir x3) 
• En fonction du regroupement ou non des requêtes, l’impact des réseaux GSM va être plus ou moins important 

Il est nécessaire de mesurer l’application au final pour comprendre son comportement par rapport au réseau. Mettre en place des règles d’estimation dans les modèles est donc complexe et va amener des données incertaines et probablement fausses.

Conclusion

L’évaluation de l’impact environnemental du réseau est complexe. Il est nécessaire d’avoir plus de données des opérateurs et des constructeurs. Ces données doivent être plus fines et plus transparentes. Cependant les données existantes sont utilisables, encore faut-il bien les qualifier et les utiliser. Compte-tenu de ces constats, l’usage de données moyennées n’est pas une approche idéale. C’est pour cela que nous avons adopté une approche avec calcul des incertitudes. Dès qu’on peut, il faut mesurer pour avoir des données contextualisées et plus précises. C’est l’approche que nous appliquons. Ceci apporte des précisions importantes lors des ICV (l’inventaire du Cycle de Vie dans la démarche d’évaluation de ce dernier), des évaluations d’impacts du numérique, ou plus unitairement de l’évaluation de logiciel.  

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

Dans cet article, nous allons voir plus en détail comment est calculé l’écoscore dans le cas d’un benchmark web réalisé par Greenspector.  

Et dans les autres cas ? 

Comme vous le savez peut-être déjà, Greenspector réalise également des mesures sur applications mobiles. Dans le cas des applications Android, il est possible de réaliser facilement un benchmark. On reste sur une méthodologie standard : mesures sur les étapes de chargement, pauses et référence. L’écoscore est là aussi calculé à partir des écoscores Réseau et Ressources Client. La seule différence notable est que la mise en œuvre des bonnes pratiques n’est pas contrôlée automatiquement et n’entre donc pas dans le calcul.  

Aussi, dans certains cas, il est plus judicieux de mesurer directement un parcours utilisateur afin d’être au plus près du comportement du site dans ses conditions réelles d’utilisation. Que ce soit dans le cas du web ou d’une application mobile, Greenspector réalise les mesures (toujours sur terminaux utilisateurs réels) après automatisation du parcours (via le langage GDSL). L’écoscore est ensuite établi à partir des métriques représentées via 3 écoscores : Données mobiles, Performance et Energie.

Qu’est-ce qu’un benchmark web ? 

Afin d’évaluer les impacts environnementaux des sites web, Greenspector dispose de plusieurs modes opératoires et outils. Le plus simple à mettre en place est le benchmark web. Cette méthodologie standard permet de mesurer n’importe quelle page web et de la comparer avec d’autres pages.

Les mesures sont effectuées sur un smartphone réel disponible sur notre banc de test, le plus souvent en WIFI (même si d’autres modes de connexion, type 3G ou 4G par exemple, sont possibles) et avec le navigateur Chrome.  

Une telle mesure dure 70 secondes et inclut :  

• 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 

A ceci s’ajoute une mesure de référence sur un onglet vide de Chrome.  

Plusieurs itérations de mesure sont réalisées afin de s’assurer de leur stabilité. 

On récupère ainsi des métriques sur les données transférées mais aussi l’impact sur le terminal de l’utilisateur et en particulier sur la décharge de la batterie. En plus de cela, la bonne mise en œuvre d’une trentaine de bonnes pratiques est vérifiée automatiquement.  

Ensuite, les indicateurs environnementaux sont calculés en tenant compte quand c’est possible des statistiques réelles d’utilisation de la page. Vous trouverez davantage d’informations à ce sujet dans la page dédiée sur le blog Greenspector. 

Une fois toutes ces informations disponibles, il devient facile de comparer différentes pages web, qu’elles soient ou non sur le même site. C’est ce mode opératoire qui est utilisé notamment dans le cadre des classements de sites proposés sur ce blog mais aussi à la demande d’un client afin d’établir un état des lieux sur un ou plusieurs de ses sites web et de proposer un plan d’action. Ce peut aussi être un moyen de construire un benchmark concurrentiel permettant de se positionner par rapport à un échantillon de sites similaires.  

Vous pouvez d’ores et déjà avoir un aperçu de tout ceci via le Mobile Efficiency Index (MEI) mis à disposition par Greenspector afin d’évaluer gratuitement l’impact d’une page web.  

Il ne nous reste pour l’heure qu’à voir comment est calculé l’écoscore dans le cadre d’un benchmark web.  

Calcul de l’écoscore pour un benchmark web 

Tout d’abord, l’écoscore établi pour une page web est la moyenne de deux valeurs :  

• Un écoscore Ressources Client qui reflète la façon dont les ressources client sont gérées du point de vue de la sobriété lors de l’accès à cette page 
• Un écoscore Réseau qui reflète la sollicitation du réseau (et des serveurs)

Ecoscore Ressources Client

L’écoscore Client repose sur 12 contrôles effectués sur les métriques directement récupérées sur le terminal utilisateur (et collectées via son système d’exploitation). Celles-ci concernent entre autres les données transférées mais aussi la décharge de la batterie, le CPU et la mémoire. Pour chacune, 4 à 5 seuils sont définis afin de déterminer les valeurs acceptables. En fonction de ces seuils, une note est calculée. Les notes pour l’ensemble des métriques sont ensuite agrégées afin de calculer l’Ecoscore Client.  

Par exemple : 

• La note maximale concernant les données transférées lors du chargement de la page ne pourra être obtenue que si leur poids total est inférieur à 500 ko 
• Pour la décharge de la batterie, on compare à celle mesurée lors de l’étape de référence décrite précédemment 

Les seuils utilisés sont définis via une base de mesures afin de pouvoir, en fonction de la répartition statistique des mesures précédemment obtenues, déterminer les seuils attendus.

Ecoscore Réseau

Aujourd’hui, la méthodologie Greenspector repose sur des mesures uniquement réalisées sur des terminaux utilisateurs réels. En conséquence, la définition de l’écoscore Réseau est légèrement différente. Elle repose sur deux éléments :  

• La comparaison des métriques liées au transfert de données avec des seuils définis de façon similaire à ceux utilisés pour le calcul de l’écoscore Client 
• La vérification automatique de la mise en œuvre d’une trentaine de bonnes pratiques 

Ainsi, par exemple, on s’assure que les ressources textuelles sont bien compressées côté serveur, que les images ne sont pas retaillées dans le navigateur et qu’il n’y a pas plus de 25 requêtes HTTP en tout. Il s’agit donc ici de bonnes pratiques techniques (plutôt orientées efficience) que l’on retrouve dans la plupart des référentiels de bonnes pratiques d’écoconception ou de conception responsable de services numériques.

Conclusion

Tous ces éléments font du benchmark web un procédé très efficace pour évaluer les impacts d’une page web et la comparer avec d’autres pages web. Il s’agit aussi d’un excellent moyen d’amorcer une analyse plus poussée, notamment en regardant en priorité les pages les plus impactantes d’un site. Dans certains cas, il sera d’ailleurs plus judicieux de commencer par les pages les moins impactantes. Un défaut de conception sur une page plus impactante lui sera souvent propre alors que, sur une page moins impactante, il sera souvent commun à l’ensemble des pages.  

Le benchmark web, entre autres via le calcul de l’écoscore, illustre une fois de plus la nécessité d’utiliser à la fois des mesures et des bonnes pratiques dans une démarche de réduction des impacts environnementaux d’un service numérique.  

Laurent DEVERNAY

Laurent Devernay Satyagraha est consultant expert chez Greenspector depuis 2021. Il intervient également en tant que formateur, conférencier mais aussi contributeur sur les Web Sustainability Guidelines du W3C, le GR491 de l’INR, les 115 bonnes pratiques de greenit.fr et divers groupes de travail notamment autour du RGESN.

ldevernay.github.io/

Introduction

Request Map Generator est un outil disponible via webpagetest.org pour afficher une visualisation des différents noms de domaine appelés lors du chargement d’une page web. Les objectifs sont multiples :  

• Identifier les services-tiers utilisés sur la page 
• Identifier quels composants appellent ces services-tiers
• Quantifier leur usage et leur impact afin de les challenger 
• Identifier les principaux leviers d’actions

Par exemple, sur cette RequestMap, on constate que l’intégration de Twitter et Linkedin sont responsables du téléchargements de 71 ko de JavaScript. On observe également l’enchainement de requêtes conduisant jusqu’à Google. 

Le problème est que l’outil est mis à disposition pour auditer des sites web. Qu’en est-il des applications mobiles ? Nous proposons une démarche assez simple à mettre en œuvre pour générer la request map d’applications mobiles. 

HAR mapper

Le développeur de RequestMap, Simon Hearne, met également à disposition l’outil HAR mapper qui génère les mêmes request maps à partir de fichiers HAR. Les HAR sont des fichiers JSON qui permettent d’enregistrer le traffic capturé par divers outils d’analyse web comme les DevTools. Ainsi, plutôt que de demander un test entier de la suite webpagetest, on peut très bien choisir, d’enregistrer un fichier d’archive HTTP (.har) sur son propre PC. Cela nous permet de bâtir des RequestMaps plus précise, qui vont au-delà de la page d’accueil, tout en étant plus sobre numériquement. 

L’autre avantage est que l’on est désormais en mesure d’analyser des applications mobiles en utilisant un proxy SSL, sous condition que l’application autorise une certaine configuration réseau (voir Autoriser l’accès au certificat de Charles par l’application). 

CharlesProxy, le couteau-suisse du développeur 

Un proxy est un serveur qui sert d’intermédiaire entre le serveur et le client. Ce dernier envoie les requêtes au proxy qui est ensuite chargé de communiquer avec le serveur. Cela permet au proxy d’observer les différentes requêtes qui sont échangées. En outre, si le client accepte le certificat CA du proxy qui agira ainsi comme une Certificate Authority, le proxy sera capable de déchiffrer les requêtes HTTPS pour inspecter leur contenu. 

Charles Proxy est un serveur proxy dont l’usage est orienté pour les développeurs mobiles. En plus, d’agir comme un Proxy SSL, il propose de réécrire à la volée les headers (ou même le contenu !) des requêtes échangées. Il permet de tester la stabilité d’une application par rapport à des conditions de réseau, ou des problèmes serveur (throttling, répétition des requêtes, pas de cache, etc.). Dans notre cas, ce qui nous intéresse le plus est que Charles permet de sauvegarder les échanges client-serveur enregistrés sous forme de fichier .har. 

Nous proposons d’utiliser Charles Proxy car c’est un outil facile d’utilisation et assez complet mais sachez que d’autres serveurs proxy peuvent servir pour ce cas d’usage. Comme alternatives, il existe notamment mitmproxy, un outil en ligne de commande open-source ou HTTP toolkit très simple d’utilisation en version payante. 

Installer et configurer Charles 

Télécharger Charles et l’installer. Le serveur proxy est configuré automatiquement au lancement de Charles et les requêtes qui passent par lui sont enregistrées.  

Par défaut Charles n’active le SSL proxying uniquement pour une liste restreinte de noms de domaines. Pour changer ce comportement, aller dans Proxy > SSL Proxying settings. Vérifier que le SSL proxying est activé et ajouter une entrée * au tableau Include: 

Configurer le smartphone 

Il reste désormais à configurer notre smartphone Android pour se connecter à Charles. Le téléphone doit être dans le même réseau local que le PC sur lequel Charles est lancé. Dans les paramètres Wi-Fi, dans la configuration du réseau, définir le Proxy comme “Manual”. Rentrer l’adresse IP du PC sur lequel tourne Charles et définir le port de Charles (8888 par défaut). 

Si tout se passe bien, dès que le smartphone échange avec le réseau, Charles nous demande d’accepter ou de refuser la connexion au proxy. 

En acceptant, Charles devrait commencer à intercepter les échanges réseaux des applications. Néanmoins, les requêtes ne se font pas correctement. En effet, il nous reste à installer le certificat de Charles sur le téléphone. 

Installer le certificat de Charles 

Ouvrir le navigateur du smartphone, et visiter chls.pro/ssl. Le téléchargement du certificat se fait automatiquement. Si le fichier est ouvert, Android propose de l’installer, sous condition qu’un code PIN verrouille le téléphone. 

Attention à partir d’Android 11, la procédure est rendue plus compliquée. (Visiter l’aide de Charles pour installer le certificat sur d’autres systèmes). 

Il nous est désormais possible de transférer les requêtes émises par le processus de Chrome mais pas celles d’autres applications. En effet, pour raison de sécurité par défaut les applications Android n’acceptent que les certificats “système” (Ce n’est pas le cas pour iOS qui propose d’ailleurs une application Charles sur l’App Store). 

Autoriser l’accès au certificat de Charles par une application Android 

Trois cas de figure se présentent: 

1. Vous disposez du code source de l’application. 
   
   Dans ce cas, il vous est facile d’autoriser l’usage de certificats CA “utilisateur”. Pour cela, ajouter un fichier `res/xml/network_security_config.xml` définissant les règles de configurations réseaux de l’application: 

<?xml version="1.0" encoding="utf-8"?> 

<network-security-config> 

<base-config cleartextTrafficPermitted="true"> 

<trust-anchors> 

<certificates src="system" /> 

<certificates src="user" overridePins="true" /> 

</trust-anchors> 

</base-config> 

</network-security-config> 

Il faut également spécifier son chemin dans le AndroidManifest.xml: 

<?xml version="1.0" encoding="utf-8"?> 

<manifest ... > 

<application android:networkSecurityConfig="@xml/network_security_config" ... > 

... 

</application> 

</manifest> 

Penser à ne garder cette configuration seulement pour l’application de debug, car elle peut engendrer des problèmes de sécurité MAJEURS. Voir la documentation officielle pour plus de détails. 

2. Vous ne disposez que de l’apk de l’application. 

Dans ce cas il vous faudra décompiler l’application, utiliser la même méthode qu’en 2. et recompiler l’application et signer l’apk résultant. Pour cela certains outils (apk-mitm ou patch-apk) pourront vous aider dans le processus. La méthode n’est cependant pas garantie de fonctionner car l’application peut implémenter une vérification de la signature de l’apk. 

Attention ! En France, la décompilation d’un logiciel est strictement encadrée par la loi qui définit dans quels cas elle est légale. Dans le doute, assurez-vous d’obtenir l’autorisation de l’éditeur au préalable !

3. Le smartphone de test est rooté. 

Dans ce cas, vous pouvez installer le certificat dans les certificats root du téléphone. 

Une fois que le certificat peut être utilisé par l’application, nous sommes en mesure d’inspecter les échanges entre le smartphone et le serveur. Pour générer un fichier .har, sélectionner toutes les requêtes, clic droit dans Charles sur les échanges réseaux > Export Session… et exporter en HAR.

Importer le fichier dans HAR Mapper, et nous avons notre Request Map ! 

Alban RAHIER

Alban RAHIER est consultant numérique responsable chez Greenspector depuis 2021. Diplômé Ingénieur de Centrale Lille, il s’est spécialisé dans l’évaluation de la sobriété des applications Android.

Méthodologie d’évaluation d’empreinte environnementale

Notre approche

La modélisation choisie s’appuie sur les principes d’Analyse du Cycle de Vie (ACV), et principalement par la définition donnée par l’ISO 14040. ​​

Elle se compose d’une partie Inventaire du cycle de vie (ICV) complète et d’une Analyse du cycle de vie (ACV) simplifiée. L’ICV est prépondérant dans notre modèle. Il va permettre de s’assurer d’avoir des données fiables et représentatives. De plus, l’ICV ainsi obtenu peut le cas échéant être intégré dans des ACV plus poussées.

Nous évaluons l’impact environnemental des services numériques sur un ensemble limité de critères :

Les Emissions de Gaz à Effet de Serre (GES)

exprimée en g eqCO2,

telles que couramment utilisées, indiquent l’intensité de l’impact sur le changement climatique

La ressource en Eau

exprimée en Litres,

telle que définie par le water footprint network, est un indicateur reflet de la consommation en eau (eau bleue) mais aussi la quantité de polluants utilisés (eau grise). Il ne tient pas compte de la rareté locale des ressources mais il est un indicateur parlant.

L’occupation des sols

exprimée en m2,

ou land use en anglais, telle que définie originellement par Heijungs et al. (1992), est un indicateur reflet de l’impact sur la biodiversité. Il n’est pas le plus exhaustif (indépendant du temps normalement, mais c’est le plus utilisé actuellement).

Cette méthodologie a été revue par le cabinet EVEA – spécialiste en écoconception et analyses de cycle de vie.
Note sur l’eau : L’eau grise et l’eau bleu sont prises en compte sur toutes les étapes du cycle de vie. L’eau verte est ajoutée sur le cycle de fabrication des terminaux et des serveurs. Retrouvez la définition de l’empreinte Eau.

Gestion de la qualité des résultats

La qualité des résultats d’une ACV peut être modélisée de la façon suivante¹ :​​

Qualité des données d’entrée  x  Qualité de la méthodologie  =  Qualité des résultats

Pour améliorer la qualité des données d’entrée, nous mesurons le comportement de votre solution sur des terminaux réels. Cela permet de limiter les modèles qui sont potentiellement sources d’incertitude.​

Pour gérer la qualité des résultats, nous appliquons une approche qui permet d’identifier les sources d’incertitudes et de calculer l’incertitude du modèle. Notre méthode de gestion des incertitudes utilise la logique floue et ses ensembles².

Au final, contrairement à d’autres outils et méthodologies, nous pouvons fournir des marges d’erreurs par rapport aux résultats que nous vous donnons. Cela permet d’assurer une communication de l’impact environnemental plus sereine vers les parties prenantes (utilisateurs, équipes internes, partenaires…)

¹Qualité des resultats : SETAC (Society of Environmental Toxicology and Chemistry 1992)

_²Bien que mentionnée souvent dans la littérature traitant d’incertitudes en ACV, cette approche est peu utilisée. En effet les modèles stochastiques comme les simulations de Monte Carlo sont souvent préférés (Huijbregts MAJ, 1998). Dans notre cas, l’utilisation de la logique floue semble plus pertinente, car elle nous permet de gérer les inexactitudes épistémiques, notamment dues à des estimations d’expert. ​ ​

Étapes de calcul

Phases prises en compte pour le matériel utilisé

« Phases prises en compte dans le cycle de vie des matériels ​qui sont mobilisés en phase d’usage du service numérique »​

Note sur le modèle d’impact de la partie terminal

Les méthodologies classiques d’analyse d’impact prennent comme hypothèse un impact uniforme du logiciel (consommation moyenne quel que soit le logiciel ou l’état du logiciel). Notre approche innovante permet d’affiner cet impact. De plus, nous améliorons la modélisation de l’impact du logiciel sur la phase de fabrication du matériel en prenant en compte l’usure de la batterie.

La batterie des smartphones et PC portables est un consommable, nous modélisons l’impact du logiciel sur celui-ci.​

Données d’entrée de l’Inventaire du Cycle de Vie

Exemple de travail sur les hypothèses :

La méthodologie de propagation des incertitudes nous oblige à identifier précisément la qualité de ces hypothèses. Voici quelques exemples, en particulier l’impact de fabrication du matériel.

L’analyse bibliographique nous permet d’identifier les impacts de différents smartphones et d’associer l’indice de confiance DQI. Ces chiffres sont principalement issus des constructeurs.

L’impact moyen calculé à partir de ces indices de confiance est de 52 kg eq Co2 avec un écart type de 16 kg.

Exemple de restitution

• Dans cet exemple : impact médian de 0,14g eqCO2 principalement sur la partie « Réseau ».​
  
  
• Cet impact correspond à la visualisation d’une page web pendant 20s
  
  
• L’incertitude est calculée par le modèle Greenspector en appliquant le principe de propagation des incertitudes à partir du périmètre et de hypothèses décrits précédemment.

Éléments nécéssaires

Afin de déterminer l’impact de votre solution, nous avons besoin des informations suivantes :​​

• Ratio de visualisation Smartphone/Tablette/PC ​
• Ratio de visualisation France/Monde​
• Localisation des serveurs France/Monde​
• Serveurs simples ou complexes (ou nombre de serveurs de la solution)

Sur devis, nous pouvons réaliser une ACV simplifiée se basant sur ce modèle mais adaptant d’autres éléments à contre cas particulier. Par exemple:​

• Mesure de la consommation d’énergie de la partie serveur (via un partenaire)​
• Précision des hypothèses serveur (PUE, type de serveur)​
• Mesure de la partie PC (via mesure laboratoire)​
• Précision des facteurs d’émissions électriques d’un pays en particulier…

Comparatifs des modèles d’estimation

Les calculs Greenspector sont intégrés dans un webservice actuellement utilisé par nos clients. Retrouvez très prochainement nos calculs d’empreinte environnementale de vos applications mobiles et sites web dans une interface SaaS.

Incertitudes – méthode de calcul

Les méthodes de calcul dans la sobriété numérique sont souvent peu justes et parfois, en même temps, peu fidèles.  Ceci vous amène potentiellement à utiliser des outils qui évaluent mal l’impact de vos solutions. Le risque est de faire travailler vos équipes sur des axes qui n’ont pas d’impact réel sur l’environnement.​

Certaines approches, plus utilisés dans les ACV (et pas dans les outils du marché), améliorent la fidélité mais posent un risque de donner un résultat peu juste (R. Heijungs 2019). ​

Notre approche repose sur une méthode de calcul innovante, l’arithmétique floue, proposée pour la première fois par Weckenmann et al. (2001).​

Cette approche est très performante pour modéliser des données vagues (épistémiques) non-probabilistes, ce qui est souvent le cas de données traitant de sobriété numérique. Nous ciblons de cette manière des résultats justes et fidèles.

Les solutions concurrentes font des choix qui les rendent généralement peu fidèles et peu fiables:​

– Fidélité : Faible maîtrise de l’environnement, pas de méthodologie de gestion des écarts de mesures​

– Justesse : Modèle basé sur des métriques non représentatives comme la consommation de données ou la taille du DOM, pas de mesure d’énergie…

Olivier PHILIPPOT

Expert Sobriété Numérique
Auteur des livres «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

Plus une URL est très couramment consultée, plus réduire son impact numérique est essentiel. Une simple mesure permet de vérifier et réagir face aux changements effectués sur la page : modifications liées à la charte graphique, à des évènements (les sites e-commerce en période de soldes) ou même des modifications techniques. Tous ces changements peuvent avoir un impact fort sur le niveau de sobriété d’une page web.

Quand intégrer la mesure de sobriété numérique d’une URL ?

Ces mesures peuvent être intégrées dans le cadre d’un monitoring quotidien sur n’importe quelle page. Des pages dynamiques dont le contenu est amené à régulièrement évoluer telles que des pages d’accueil e-commerce ou de site d’information presse sont importantes à monitorer. Même des pages moins « dynamiques » pourront être elles-aussi ciblées : la mise à jour d’une librairie CDN peut, par exemple, impacter ce type de site. Dans ce cas, la mesure permettra de s’assurer que le nouvel habillage de la page n’a pas un impact négatif sur le niveau de sobriété du site web : une image trop lourde pour une bannière pourra être facilement repérée.

La mesure peut aussi être utilisée lors de la phase de développement pour tester des choix avant la mise en production ou pour rectifier très tôt des changements trop impactants. Il est souvent difficile de changer le choix d’une technologie ou d’une implémentation une fois qu’un site est mis en production, la mesure d’une URL pendant la phase de développement permet de tester très tôt différentes options et de voir laquelle correspond le mieux en prenant en compte la sobriété numérique comme un des critères.

Exemple d’un suivi quotidien d’une page web

Comment mesurer la sobriété numérique d’une URL ?

Plusieurs possibilités s’offrent à vous chez Greenspector pour mesurer une URL.

Un premier outil nous permet d’effectuer une première mesure simple d’une URL et obtenir des constats rapides : l’outil Benchmark basé sur des tests standardisés.

Pour aller plus loin, nous pouvons effectuer la mesure d’un parcours utilisateur complet sur un site web grâce à App Scan. En général ce genre de mesure est effectuée pour représenter le chemin complet sur un site web ou application mobile, comme un parcours d’achat ou la réalisation d’un virement bancaire. Il permet d’identifier les points sur lesquels se concentrer pour obtenir rapidement une amélioration significative. Dans le cadre d’un App Scan, la mesure d’une URL est également possible via un parcours automatisé ce qui va permettre l’obtention de métriques spécifiques au-delà du benchmark.

Mesure d’URL (via App Scan) vs Benchmark

Voici les différentes étapes mesurées lors d’une mesure URL (via AppScan) vs l’outil Benchmark :

La mesure URL (via App Scan) contient plus d’étapes que le benchmark, nous y reviendrons. Contrairement au benchmark, la mesure URL est plus précise sur les chargements, la durée mesurée étant la durée réelle du chargement contrairement à l’outil benchmark qui réalise les mesures sur une durée fixe de 20 secondes. Une autre différence importante est qu’une mesure URL gère les fenêtres présentes sur la page, en particulier celles qui concernent les cookies, ce que ne fait pas l’outil benchmark.

Enfin, la mesure URL via App Scan par Greenspector permet de réaliser des mesures sur d’autres navigateurs que Google Chrome. L’outil benchmark est limité à ce dernier navigateur mais notre expertise GDSL nous permet de proposer un autre navigateur tel que Firefox par exemple pour aller encore plus loin.

Les étapes d’une mesure d’URL (via App Scan)

• Chargement sans cache : Il s’agit du chargement de l’URL en ayant préalablement vider le cache et supprimer tous les cookies. Cette étape permet de mesurer le chargement de la page web lorsqu’un utilisateur s’y rend sans cache. C’est particulièrement important pour les URLs avec beaucoup de visites uniques.
• Pause après chargement sans cache : La mesure d’une courte pause après le chargement permet de récupérer les échanges de données et autres opérations qui s’effectuent encore alors que l’affichage de l’écran est terminé. L’idéal étant bien entendu de n’avoir rien de tout ça. Dans le cas contraire cela nous permet de faire des constats et de proposer des pistes pour faire disparaitre ou réduire ces traitements. 
• Pause sur la page sans cache : La mesure de pause sur la page représente l’action d’un utilisateur en train de lire le contenu. Aucun mouvement sur l’écran. L’idée de cette étape est de mesurer l’impact de l’affichage continu de la page.  
• Scroll sur la page : Défilement jusqu’en bas de la page permettant de réaliser des constats sur les traitements pendant le scroll. Ici nous pouvons faire des constats sur les possibles échanges de données (pagination, téléchargement d’image, publicité) ainsi que la fluidité associée. 
• Pause sur la page après le scroll : Mesure de pause après le défilement permettant d’observer des traitements qui continuent après la fin des interactions utilisateur.  
• Chargement avec cache : Mesure du chargement de l’URL avec le cache des intéractions précédentes (chargement, scroll). Cette étape permet de constater l’impact de la mise en cache sur le site. C’est important pour les pages amenées à être consultées un grand nombre de fois par des visiteurs connus, comme par exemple une page d’accueil d’un site internet. 
• Pause sur la page avec cache : La mesure de pause sur la page permettant de voir si malgré le cache il y a des traitements après le chargement.

Grâce à nos outils et notre expertise nous pouvons proposer des mesures fiables et pertinentes sur une URL. Que ce soit une mesure simple permettant des premiers constats à l’aide de notre outil de benchmark ou une mesure plus poussée avec notre langage GDSL. Ce monitoring régulier d’URL permet d’améliorer progressivement le niveau de sobriété de son site web. Cette approche par rapport à d’autres approches courament utilisées dans le web (Analyse uniquement du chargement de la page avec Lighthouse ou autres…), apporte plus de finesse sur la connaissance de la consommation de la page.

Clément DERON

Ingénieur depuis 6 ans, il a commencé en tant que QA automaticien sur Android avant de basculer sur iOS. Ayant travaillé au cours de sa carrière sur plusieurs technologies, l’automatisation mobile n’a plus de secret pour lui.

Qu’est-ce que le GDSL ?

Le terme GDSL signifie Greenspector Domain-Specific Language. Il s’agit d’un langage créé par Greenspector pour simplifier l’automatisation de test sur Android et iOS. Concrètement c’est une surcouche basée sur les frameworks d’automatisation de Google et d’Apple agrémentée de fonctions pour faciliter l’automatisation de test. 

Ce langage est le fruit de l’expertise Greenspector accumulée depuis plusieurs années déjà. Il combine la simplicité d’écriture à la possibilité de mesurer les performances énergétiques d’une application ou d’un site internet. 

Le principe du GDSL est d’être un langage de description des actions qui seront effectuées sur le smartphone. En ce sens il peut être rapproché du Gherkin avec qui il partage la qualité de ne pas nécessiter de formation de développeur pour être lu.

Le GDSL est une suite d’actions qui seront exécutées dans l’ordre par le smartphone. Il dispose des actions basiques que sont les WAIT, CLICK ou encore PAUSE ainsi que d’actions plus complexes comme le lancement d’application ou la gestion du GPS. 

Avec le GDSL il est possible d’automatiser rapidement la plupart des parcours critiques de vos applications ou site web mobile. 

L’équipe Greenspector travaille au quotidien pour améliorer le langage et ajouter des fonctionnalités. L’état actuel permet d’automatiser la plupart des scénarios nécessaires à une campagne de mesure complète d’une application ou d’un site web ainsi que les parcours critiques de la plupart des applications. Dans un prochain article, nous vous parlerons des outils Greenspector permettant l’exécution des tests GDSL.

Clément DERON

Ingénieur depuis 6 ans, il a commencé en tant que QA automaticien sur Android avant de basculer sur iOS. Ayant travaillé au cours de sa carrière sur plusieurs technologies, l’automatisation mobile n’a plus de secret pour lui.