Comprendre les causes de surconsommations
MAJ 29 OCT 2025
Construire une évaluation globale
Un survol rapide de chaque section permet d’identifier les problèmes apparents du service mesuré. Une évaluation globale peut en être déduite :
Service lent mais économe en énergie
Service rapide mais gourmand en énergie
Service économe en énergie mais consommation de données élevée
etc.
Identifier les problèmes
L’analyse des résultats dans le SAAS doit permettre d’identifier les leviers d’optimisation. Deux situations sont possibles :
La plupart des étapes ont un mauvais résultat sur une ou plusieurs métrique. L’analyse sera simplifiée avec potentiellement plusieurs problèmes à relever.
Certaines étapes se comportent de manière différente de la moyenne. Nous devons nous assurer qu’il ne s’agit pas d’une erreur de mesure. Nous devons alors procéder à une analyse plus approfondie et nous concentrer sur ces étapes.
Dans un premier temps, sur l'écran “Vision par étape”, vous pouvez déjà repérer les étapes qui sont les plus mal notées (Notation par étape).
Il est également intéressant de lister les étapes les mieux notées. Lors des analyses, elles permettront de regarder de plus près ce qui se passe sur le service numérique dans le cas “optimal”. Ainsi, il peut être plus facile d’identifier des améliorations qui impactent l’ensemble des écrans du parcours. Souvent, il s’agit de repérer des bonnes pratiques techniques qui s’appliqueront à l’ensemble du service numérique (minification, cache, optimisation des images, compression, etc).
Consultez les notes par étape pour les différentes métriques pour identifier les plus mal notées :
Temps d’affichage
Energie
Données réseau
Cela permet déjà de voir si certaines étapes sont mal notées sur plusieurs métriques, ce qui orientera l’analyse.
Ce que le SAAS ne montre pas
Le calcul de l’Ecoscore ne dépend pas du nombre d'étapes, ce qui peut masquer des problèmes d’ergonomie et de conception du parcours. Un trajet comportant de nombreuses étapes bien optimisées aura un bon Ecoscore. Cependant, l’impact sur l’environnement et la durée du parcours seront mauvais.
Ceci rejoint le critère 4.3 du RGESN : Le service numérique optimise-t-il le parcours de navigation pour chaque fonctionnalité principale ?
Données réseau
Les principaux fautifs pour les volumes élevés de données transférées sont de plus en plus :
Images et vidéos
Polices
Fichiers JavaScript (.js)
Images et vidéos
Les images de très nombreux sites ne sont pas optimisées et augmentent le volume de données transférées.
On peut considérer qu’une image de plus de 100 ko doit être optimisée avec une conversion au format WebP/AVIF, des dimensions et une qualité adéquats.
Pour une icône, le seuil serait plutôt autour de 10 ko, facilement atteignable avec un SVG optimisé.
Lorsqu’un site propose de la vidéo, le volume de données augmente considérablement. C’est également le cas pour les intégrations de services tiers tels que Youtube, carte interactive et fils de réseaux sociaux.
Attention : lors d’un benchmark URL, toutes les données transférées ne sont pas prises en compte. Sur la majorité des sites, il faut accepter manuellement l’ensemble des requêtes (bandeau de consentement lié au RGPD) afin de pouvoir visualiser l’ensemble des services tiers utilisés.
Polices
Il faut revenir aux bonnes pratiques :
Utiliser le moins de polices personnalisées possible
Privilégier le format .woff2
Préférer des polices variables afin de limiter le nombre de requêtes
Utiliser un subset afin de télécharger seulement les caractères vraiment utilisés
Javascript
JS est souvent prépondérant pour les données transférées, en plus d’avoir un impact conséquent sur l'énergie et la durée de chargement des pages. Au-delà des recommandations faciles à mettre en oeuvre (minification, externaliser le code), il est généralement plus difficile d’optimiser le code (code non-utilisé, bonnes pratiques de développement, etc) et les résultats sont moins spectaculaires que via les polices ou contenus. Pour ces raisons, ces optimisations apparaissent souvent moins prioritaires dans le plan d’action et on préférera d’autres recommandations plus simples et impactantes, au moins dans un premier temps.
Énergie
L'énergie est fortement corrélée aux impacts environnementaux. Au regard des autres outils d'évaluation des impacts environnementaux, ce facteur est souvent négligé ou sous-estimé.
En général, l’impact sur l'énergie (via le CPU et la vitesse de décharge de la batterie) est lié à l’un des éléments suivants :
Animations
Javascript
Services-tiers
Animations
Les carrousels et autres éléments entraînent une modification presque continu de l’affichage. S’il est possible de créer des animations plus efficientes que d’autres, la recommandation est en priorité de les limiter au strict nécessaire. De tels éléments peuvent également nuire à l’accessibilité du site et sont rarement utiles.
Les animations peuvent être mises en avant via le SAAS. Sur l'écran “Détail d’une étape”, sélectionnez l'étape concernée et affichez Process Data en corrélation avec le Process CPU ou la vitesse de décharge de batterie. Vous verrez souvent des pics de CPU ou de décharge de batterie qui ne sont pas forcément corrélés avec des transferts de données et présentant des patterns répétitifs.
Javascript
Les traitements JS peuvent avoir un impact conséquent, d’autant plus que ce langage est de plus en plus présent sur le web.
Les composants dynamiques, notamment via les frameworks front “réactifs” (React, Angular, VueJS et autres), y contribuent énormément alors qu’ils ne sont pas toujours indispensables. Un facteur aggravant pour l’impact de JS réside dans les services tiers (intégrations via des sites extérieurs, analytics, etc).
Temps d’affichage
Via l’outil Greenspector, l’approche de la performance est essentiellement centrée sur le temps d’affichage. Les outils d'évaluation de la performance usuels (Webpagetest, Lighthouse, etc) sont donc de bons compléments. Sans aller aussi loin qu’un audit de performance, il nous est possible de formuler de premières recommandations mais aussi de repérer des points qui nuisent à la sobriété de certains sites web.
Performance et écoconception se rejoignent dans le domaine de l’efficience mais l'écoconception nécessite d’aller plus loin via la sobriété. Il est intéressant pour l’utilisateur d’avoir un site qui charge plus rapidement. Si ceci est obtenu en différant seulement certains traitements et requêtes qui auront lieu malgré tout, l’intérêt environnemental est limité.
En général, on part du principe qu’une page web doit mettre moins de 3 secondes à charger.
Bonnes pratiques
Les outils visent souvent à vérifier l’application de bonnes pratiques.
Les bonnes pratiques en question sont consultables par ailleurs. On citera par exemple :
Le RGESN [web & mobile]
Le GR491 de l’INR [web & mobile]
Les Web Sustainability Guidelines du W3C [web]
En complément, si possible, vous pouvez lancer un benchmark sur certaines pages du parcours afin de retrouver plusieurs bonnes pratiques techniques dans l'écran “Améliorations”.