Le RGESN (Référentiel général de l’écoconception de services numériques) impose la définition de limites pour la taille d’une page et le nombre de requêtes HTTP sur celle-ci via le critère 6.1 (« Le service numérique s’astreint-il à un poids maximum et une limite de requêtes par écran ? »). Si ces deux métriques permettent d’avoir une idée de l’impact du transfert des éléments sur la page, elles ne reflètent aucunement la complexité ni la durée des traitements engendrés (et il en va de même pour le DOM). Vous trouverez quelques exemples à ce propos dans notre article sur le poids des éléments d’une page.
En conséquence, le critère 6.1 du RGESN gagnerait à être amélioré en se penchant sur la consommation d’énergie. Historiquement, ces éléments ont souvent été laissés de côté en raison de la complexité pour les récupérer via le navigateur mais les choses évoluent.
Dans l’immédiat, voyons déjà comment définir des seuils et limites pour un service numérique.
Définition
Un budget environnemental peut se présenter sous deux formes :
- Des valeurs à atteindre (réduction des impacts environnementaux)
- Des seuils à ne pas dépasser (maîtrise des impacts environnementaux, limiter les régressions)
Il est recommandé de ne pas se baser uniquement sur des indicateurs environnementaux ou sur un score, même si ces indicateurs ont évidemment un intérêt pour le suivi dans le temps. En effet, les modalités de calcul d’une modélisation peuvent différer voire évoluer, ce qui peut nuire au suivi dans le temps. En plus d’inciter à l’optimisation, au risque de dégrader d’autres aspects. Pour toutes ces raisons, mieux vaut s’appuyer sur des métriques de flux ou mesurables.
Avec Greenspector Studio, il est possible de prendre en compte l’Ecoscore calculé mais aussi les autres indicateurs mesurables via le passage en CI/CD. Si certains seuils sont dépassés, il est possible de bloquer la modification incriminée.
Pour fixer les seuils, l’idéal est de s’appuyer sur des premières mesures et sur les marges d’amélioration identifiées. Ainsi, dans le cas d’une refonte, le service numérique initial constitue le point de référence. De même pour la maintenance d’un site ou d’un service numérique. Dans le cas de la création d’un service numérique, la logique est quelque peu différente. Le plus simple est de se baser sur des mesures réalisées sur des services similaires ou concurrents et de définir ses ambitions en fonction (ce qu’on vise, ce qu’on veut éviter, le tout via le budget environnemental).
La difficulté du budget environnemental est de trouver le bon équilibre pour ne pas être décourageant (trop difficile à atteindre) ni démotivant (trop facile à atteindre). Les seuils doivent donc évoluer au fil du temps, en fonction de l’évolution des résultats. En complément, il est intéressant d’établir des jalons en termes de planning, assortis d’un plan d’actions avec priorisation des recommandations.
Métriques
Nous verrons ici les différentes métriques utilisables pour le budget environnemental, en commençant par celles suggérées par le RGESN. Chacune est assortie de suggestions de seuils.
Poids par écran
Site web
Le seuil idéal pourrait être de 500 ko au premier chargement d’une page web, 50 ko pour les autres pages ou le retour sur cette même page (en tenant compte du stockage côté client via le cache).
Application mobile
Le seuil idéal pourrait être de 500ko pour le lancement de l’application puis 50 ko par écran/action.
Requêtes par écran
Attention : pour cet indicateur, les valeurs peuvent très vite augmenter indépendamment du contenu du site. En effet, les services-tiers sont quasiment omniprésents, à la fois sur le web et dans les applications mobiles. C’est pourquoi il est important de prendre ici en compte le scénario nominal (selon si la majorité des utilisateurs a tendance à accepter ou refuser l’ensemble des cookies) ou le pire scénario (acceptation de tous les cookies). En complément, il est important de vérifier que le site fonctionne correctement si l’utilisateur refuse tout (et, si possible, que les choix de l’utilisateur sont bien respectés).
Site web
Le seuil idéal pourrait être de 25 requêtes HTTP au premier chargement d’une page web, 5 requêtes pour les pages suivantes ou le retour sur cette même page (en tenant compte du stockage côté client via le cache).
Application mobile
Le seuil idéal pourrait être de 5 requêtes HTTP par écran/action.
Décharge de batterie
Cette métrique est à rapprocher de la consommation d’énergie et sert notamment de proxy pour l’usure du terminal, en lien direct avec ses impacts environnementaux.
Le fait qu’elle se mesure au niveau du terminal impose qu’il y ait aussi peu d’autres processus en cours. De même, il est important d’avoir une mesure de référence (ce qui se passe lorsque le navigateur tourne seul ou lorsque l’application mobile n’est pas lancée) afin d’avoir un élément de comparaison. En effet, la vitesse de décharge de batterie dépend fortement du terminal de mesure utilisé mais peut également varier au fil du temps.
Site web / application mobile
Afin d’évaluer la décharge de batterie, on la compare à la décharge lors de l’étape de référence (sur le terminal choisi, avec les mêmes modalités de connexion à internet). Quelle que soit l’étape ou la page, la décharge de batterie devrait par exemple être inférieure au double de celle de l’étape de référence. Ceci est en particulier vrai pour les étapes de pause (afin de limiter les sollicitations du terminal lorsque l’utilisateur est lui-même inactif).
Taille de l’APK/IPA
L’APK/IPA ne doit pas faire plus de 25 Mo.
De même, il peut être intéressant de réduire la fréquence des mises à jour ainsi que leur taille, en tenant compte de leur nature (sécurité, fonctionnalité, amélioration de l’expérience utilisateur, etc).
Compatibilité OS
Dans le cas d’une application mobile, il faut que celle-ci soit compatible avec une version d’OS la plus ancienne possible.
Pour Android, cette référence peut aider : https://apilevels.com/ [EN]
Pour iOS, un équivalent est disponible ici : https://iosref.com/ios-usage [EN]
Seuils unitaires
Enfin, il est possible de définir des seuils en termes de taille pour chaque type d’élément que l’on peut trouver sur un écran. Cet article de Temesis fournit de nombreux exemples : https://www.temesis.com/blog/des-seuils-dalertes-pour-la-performance-web-environnementale/
- SVG : 10 ko
- Image : 100 ko
- Fichier de police : 50 ko
- Fichier CSS : 50 ko
- Durée de mise en cache client inférieure à 365 jours
Si la taille d’un fichier est supérieure à ces seuils, c’est généralement signe que des optimisations restent possibles (voir à ce sujet un référentiel de bonnes pratiques d’écoconception). Il convient également (dans tous les cas) d’adapter ces seuils si nécessaire.
Pour les fichiers CSS et JS, ce peut être plus compliqué car le code JS/CSS est souvent découpé en plusieurs fichiers et chargé à différents moments. Une vision plus globale est nécessaire, comme indiqué dans cet article : https://infrequently.org/2024/01/performance-inequality-gap-2024/ [EN]
Conclusion
Il est de plus en plus admis que l’amélioration continue est un aspect essentiel de l’écoconception. Pour cela, il est essentiel de mettre en place un plan d’actions ainsi que d’implémenter la récurrence des audits et des mesures du service numérique dont on veut réduire les impacts environnementaux. Sur ce dernier aspect, le budget environnemental pose les objectifs et identifie ce qui constitue une régression ou une alerte.
Le budget environnemental peut également être utilisé pour cadrer les attendus en termes de livrables de la part d’un prestataire ou d’un service-tiers. Il doit être partagé avec tous les acteurs du projet et peut même intervenir dans la Definition Of Done des tâches voire dans les critères d’acceptance.
Pour conclure, je vous renvoie vers un article qui détaille l’utilisation des budgets pour la performance : https://www.speedcurve.com/blog/performance-budgets/ [EN]
Ainsi, de même que pour l’écologie, tout le monde n’a pas le même niveau de maturité. Si les bonnes pratiques sont toujours une bonne chose, se fixer des limites concrètes permet de mieux cadrer les efforts réalisés et de les suivre dans le temps.
