Accueil / Le blog

Le regard Quadran · Écoconception

Mesurer l’impact environnemental d’un site web : pourquoi le banc d’essai ne suffit pas

L’équipe Quadran8 min de lecture

Une application web sur roues testée sur un banc à rouleaux, puis sur route avec une remorque chargée de pages et d’images : des tests contrôlés aux usages réels.

Personne ne partirait en vacances avec la consommation relevée sur un banc moteur comme seule garantie de son budget carburant. Le conducteur est différent, la voiture est chargée, la route monte, il fait chaud, la climatisation fonctionne, le trafic ralentit. Même voiture. Autres conditions. Autre consommation.

Deux conducteurs peuvent parcourir exactement le même trajet et obtenir des résultats très différents. Une famille avec trois enfants, les bagages et un coffre de toit ne sollicite pas son véhicule comme une personne seule sur une route dégagée.

Personne n’en déduit que les bancs d’essai ne servent à rien. Ils sont indispensables pour caractériser un moteur, isoler des paramètres, comparer des configurations. Mais il faut arrêter de leur demander ce qu’ils ne savent pas démontrer : la consommation de tous les conducteurs, sur toutes les routes.

En écoconception numérique, cette confusion est encore beaucoup trop fréquente.

L’automobile a compris qu’un banc ne suffisait pas

Une application web sur roues passe sur un banc à rouleaux.
Sur banc : comparer dans des conditions contrôlées.

Les constructeurs disposent d’essais reproductibles en laboratoire. Ils disposent aussi de mesures embarquées et de données de conduite réelle. Et ce n’est pas un caprice méthodologique : l’Union européenne suit explicitement l’écart entre les résultats du cycle WLTP et les consommations observées sur route.

La raison est évidente : un protocole normalisé permet de comparer des véhicules, pas de connaître la répartition exacte des situations vécues par leurs conducteurs.

Dans le numérique, nous avons également besoin de ces différents niveaux d’observation. Pourtant, on voit encore des résultats obtenus sur un scénario contrôlé présentés comme s’ils décrivaient l’empreinte réelle d’un site entier.

Un test représentatif du test n’est pas forcément représentatif des visiteurs.

Les « valises » de nos visiteurs sont invisibles dans un scénario unique

Une application web sur roues tracte une remorque de pages et d’images sur une route sinueuse.
En conditions réelles : les ressources chargées et la durée des parcours varient selon les usages.

Une personne découvre le site pour la première fois. Son navigateur télécharge ses ressources initiales. Une autre revient plusieurs fois dans la journée : une partie de ces ressources est déjà en cache.

Une personne consulte deux pages ; une autre traverse un parcours de douze étapes, revient en arrière, rencontre des erreurs, abandonne puis recommence. Une troisième utilise une application web dont une grande partie des navigations ne recharge pas complètement la page.

Les appareils sont différents, les performances sont différentes, les connexions aussi. Les durées de session varient. Les localisations changent, ainsi que les contextes énergétiques intervenant dans les modèles environnementaux.

On peut tester chacun de ces cas. Mais comment connaître leur poids réel dans l’activité du site sans observer les utilisateurs ?

Combien de visiteurs utilisent vraiment ce parcours ? Combien reviennent avec un cache chaud ? Quels appareils utilisent-ils ? Quels volumes de données sont effectivement transférés et observables ? Combien de temps restent-ils ?

Si ces questions restent sans réponse, une extrapolation reste une hypothèse. La présenter comme la mesure représentative du service est un saut méthodologique injustifié.

Une mesure très précise peut conduire à une conclusion très fausse

Prenons un exemple volontairement fictif, uniquement pour comprendre le mécanisme.

Supposons qu’un test à froid transfère 10 Mo et qu’un retour avec ressources mises en cache ne transfère plus que 0,5 Mo. Si 10 % des visites correspondent au premier cas et 90 % au second, le transfert moyen serait de 1,45 Mo, et non 10 Mo.

Extrapoler le test à froid à toutes les visites surestimerait ici les octets transférés d’environ sept fois. Avec un autre trafic, la conclusion changerait encore.

Ce calcul n’est pas une mesure client et ne signifie pas que l’impact environnemental PEF serait automatiquement sept fois plus élevé. Il révèle précisément le danger : une hypothèse non vérifiée sur les usages peut dominer le résultat avant même l’application des facteurs environnementaux.

Il existe d’autres cas où l’extrapolation sous-estime l’activité, en oubliant les rechargements, les erreurs, les interactions, les parcours longs ou les contenus chargés à la demande.

L’erreur peut aller dans les deux sens.

Trois méthodes utiles. Trois conclusions qu’il faut arrêter de confondre.

Les bancs de tests énergétiques mesurent la consommation d’un terminal ou d’un parcours dans un environnement contrôlé. Ils ont toute leur place pour comparer deux versions d’un composant dans les mêmes conditions. Mais ils ne disent pas combien de visiteurs empruntent ce parcours, sur quels appareils, avec quel cache, combien de temps et à quelle fréquence. Une mesure exacte sur banc ne devient pas, par multiplication, la mesure des usages réels.

Les calculateurs qui extrapolent une poignée de pages ou de scénarios à l’ensemble du trafic vont encore plus loin. Ils supposent implicitement que les tests représentent les pratiques des visiteurs. Quand cette hypothèse n’est pas vérifiée, ils peuvent produire des résultats spectaculairement éloignés de la réalité. Ce n’est pas un détail de précision : c’est une erreur de périmètre. Et annoncer un chiffre au gramme près ne la corrige pas.

Les bases d’analyse du cycle de vie et les facteurs environnementaux régulièrement actualisés répondent, eux, à un autre besoin : améliorer l’état des connaissances sur les impacts. C’est légitime. Mais lorsqu’on veut prouver qu’un travail d’écoconception a réduit l’empreinte d’un service, comparer un « avant » calculé avec une version de la base à un « après » calculé avec une autre, sans isoler cet effet, ne démontre rien sur la performance du travail réalisé. Une référence de comparaison doit rester stable, ou les deux périodes doivent être recalculées selon les mêmes règles.

Deux sites semblables comparés avec des règles aux graduations différentes.
Changer de référence peut créer un gain ou une régression apparente, sans évolution du service.

Une base ACV très riche n’invente pas les usages absents. Un banc très précis n’invente pas la diversité des visiteurs. Une extrapolation très sophistiquée ne transforme pas des hypothèses non vérifiées en observations.

Le sujet n’est pas d’opposer des outils entre eux. Le sujet est de refuser une confusion qui peut fausser les décisions des clients : caractériser un composant, comparer un scénario et mesurer un service en production sont trois opérations différentes.

Les usages réels, socle de l’évaluation environnementale

Avec appYplanet, les usages observés par le RUM alimentent l’évaluation des impacts environnementaux selon une approche ACV multicritère fondée sur la méthode européenne PEF. Les calculs s’appuient ainsi sur les comportements effectivement observés des visiteurs.

Le Real User Monitoring observe les expériences et contextes réels dans le périmètre où les données sont accessibles : pages et parcours empruntés, appareils, performances, sessions, ressources observables et, selon l’instrumentation, événements métier. Les limites de collecte, notamment sur certaines ressources tierces, doivent être explicitées.

Ces observations ne mesurent pas directement chaque watt, chaque litre d’eau ou chaque kilogramme de CO₂. Les impacts environnementaux restent évalués avec une méthode d’analyse du cycle de vie et ses hypothèses.

Ces observations changent radicalement la qualité de la donnée d’entrée. Plutôt que décider que tous les visiteurs se comportent comme le testeur, on part de la distribution des comportements réellement observés.

Et il faut regarder plus loin que le seul carbone : la méthode européenne PEF couvre 16 catégories d’impacts environnementaux. Mesurer le CO₂ ne suffit pas à caractériser les arbitrages environnementaux d’un service numérique.

À quoi doit servir une mesure environnementale ?

À décider des travaux utiles, puis à déterminer s’ils ont amélioré le service. Pas à produire un joli score dont le périmètre et les hypothèses restent opaques.

Un scénario sur banc est précieux pour tester un correctif dans des conditions identiques. L’observation des usages permet de savoir si ce scénario correspond à un problème fréquent, marginal ou totalement absent de la vie du service. Une ACV multicritère permet ensuite d’évaluer les conséquences environnementales des ressources et activités considérées.

Enfin, pour attribuer des gains aux travaux d’écoconception, la comparaison avant/après doit conserver des conditions de référence cohérentes : périmètre, méthode, facteurs et mix d’usages de comparaison documentés. Si ces références changent, il faut isoler leur effet au lieu de l’attribuer aux équipes.

Une mesure qui change de règles en cours de route ne peut pas, sans retraitement, servir de preuve des efforts réalisés. C’est un autre sujet majeur, auquel nous reviendrons.

La question à poser avant d’acheter un score

La prochaine fois qu’un fournisseur présente l’empreinte environnementale d’un site, demandons-lui simplement :

« Combien de vos hypothèses correspondent aux comportements effectivement observés chez nos visiteurs ? »

S’il ne peut pas répondre, il présente une estimation pour un scénario. C’est parfois utile. Mais ce n’est pas une preuve que ce scénario représente la réalité de votre service.

Pour Quadran, la performance, l’écoconception et l’expérience doivent partir de la même exigence : observer ce que vivent réellement les utilisateurs, modéliser honnêtement ce qui ne peut être observé directement et ne jamais confondre les deux.

Avec appYplanet, les données d’usage réel alimentent une évaluation environnementale multicritère pour identifier les leviers d’amélioration et suivre les gains ou régressions d’écoconception sur une base de comparaison cohérente.

Découvrez appYplanet

Références et approfondissements

Agence européenne pour l’environnement : différence entre résultats des essais WLTP et consommations réelles : https://climate-energy.eea.europa.eu/topics/transport/real-world-emissions/intro

EUR-Lex : procédure WLTP et essais en conditions de conduite réelles (RDE)

Quadran : https://www.quadran.eu/appyplanet/ et https://www.quadran.eu/appyuser/