Écoconception d’un site web : décider avant d’alléger

L’écoconception d’un site web ne consiste pas à poursuivre le poids de page le plus faible ni à afficher un badge après un test automatique. Elle commence plus tôt : vérifier que le service répond à un besoin réel, choisir les parcours qui méritent des ressources, puis réduire ce qu’ils mobilisent sur les terminaux, les réseaux et les serveurs sans dégrader l’action utile.

Le Référentiel général d’écoconception de services numériques (RGESN) fournit une base publique pour organiser cette démarche. Il couvre la stratégie, les contenus, l’architecture, l’expérience, l’hébergement et la durée de vie. La méthode utile consiste à transformer ses critères en décisions attribuées, en scénarios de recette et en preuves datées. Un score localise un écart ; il ne dit pas seul ce qu’il faut supprimer, conserver ou reconstruire.

Qu’est-ce que l’écoconception d’un site web ?

L’écoconception d’un site web est une démarche qui cherche à réduire ses impacts environnementaux sur l’ensemble de son cycle de vie. Elle agit sur l’utilité, les fonctionnalités, les contenus, les équipements nécessaires, les données transférées, les calculs, l’hébergement, la maintenance et la fin d’usage du service.

Le RGESN version 2024 a été élaboré par l’Arcep et l’Arcom avec l’ADEME et d’autres acteurs publics. Il vise notamment à réduire la consommation de ressources informatiques et énergétiques ainsi que la contribution des services à l’obsolescence des équipements.

Ce référentiel n’est pas une étiquette automatique appliquée à toute entreprise. Il sert de grille de conception et d’évaluation. Sa déclaration d’écoconception demande de documenter le périmètre, les chemins critiques évalués, les critères applicables, l’avancement et les actions prévues. Se prévaloir de la démarche suppose donc davantage qu’un test ponctuel.

Le Haut Comité pour le numérique écoresponsable du 15 septembre 2026 a remis le sujet dans l’actualité publique. Ce signal ne crée pas à lui seul une nouvelle obligation générale pour tous les sites. Il rappelle surtout que la conception, l’achat, l’usage et la durée de vie du numérique doivent être traités ensemble.

Pourquoi le poids d’une page ne suffit pas

Le poids transféré, le nombre de requêtes ou le temps de chargement sont utiles. Ils sont faciles à reproduire et peuvent révéler une image disproportionnée, un script tiers envahissant ou un parcours inutilement bavard. Mais ils ne représentent qu’une partie du système.

L’ADEME estime que le numérique représentait 4,4 % de l’empreinte carbone de la France en 2022 et 11 % de sa consommation électrique. Ces valeurs concernent l’ensemble du numérique français, pas un site type. L’analyse publiée par l’ADEME attribue une part importante des impacts aux terminaux et aux centres de données. Elle interdit justement le raccourci qui convertirait quelques mégaoctets en empreinte complète et certaine.

Deux pages de même poids peuvent avoir des conséquences très différentes. L’une fonctionne sur un téléphone ancien, évite une démarche physique et reste stable pendant cinq ans. L’autre impose un appareil récent, déclenche des traitements à chaque mouvement et change de socle tous les dix-huit mois. Le fichier transféré donne une observation. La décision exige de regarder l’usage et la durée.

Un audit de site web peut déjà mesurer performance, accessibilité, contenu et conversion. L’écoconception ajoute une question propriétaire : quelles ressources ce service rend-il nécessaires, pour quelle utilité et pendant combien de temps ?

La matrice Zence : de l’utilité à la décision

Commencez par une ligne pour chaque parcours important, pas par une moyenne de tout le domaine. La matrice relie huit objets qui sont souvent audités séparément.

Objet	Question à documenter	Preuve utile	Décision possible
Utilité	quelle action réelle justifie le service ?	besoin, fréquence, alternative actuelle	conserver, simplifier ou retirer
Parcours	quelle suite minimale permet de terminer cette action ?	étapes, erreurs, reprises, résultat	réduire les écrans ou les dépendances
Terminal	quels appareils et versions doivent rester utilisables ?	données d’audience, test matériel, politique de support	alléger, dégrader proprement ou élargir le support
Donnée	quelles données sont créées, transférées et conservées ?	volume, durée, duplication, fréquence	compresser, mettre en cache, supprimer ou archiver
Calcul	quel traitement est nécessaire, où et quand ?	CPU, mémoire, durée, déclencheur	différer, mutualiser, simplifier ou arrêter
Durée de vie	qu’est-ce qui rend le service maintenable et réversible ?	dépendances, standards, documentation, plan de fin	stabiliser, remplacer ou décommissionner
Preuve	comment vérifier l’amélioration sans déplacer l’impact ?	référence avant/après, scénario, version	accepter, approfondir ou revenir en arrière
Décision	qui agit si le résultat change ?	responsable, seuil, date de revue	livrer, limiter, corriger ou renoncer

Cette chaîne empêche trois confusions. Une fonction utilisée reste questionnable si une variante plus simple rend le même service. Une page rapide n’est pas forcément durable si elle exclut les terminaux plus anciens. Une infrastructure efficace ne compense pas automatiquement une fonctionnalité sans utilité démontrée.

Appliquer le RGESN à une refonte en six étapes

1. Nommer l’unité fonctionnelle

Une unité fonctionnelle décrit le service rendu dans un contexte précis : « trouver une offre et demander un échange », « renouveler un abonnement » ou « consulter une facture ». Elle est plus utile que « visiter la page d’accueil », car elle relie les ressources à une action terminée.

Écrivez aussi l’alternative. Si le besoin peut être satisfait par deux lignes de texte, une vidéo décorative n’a pas à devenir le prix d’entrée du parcours. Si une fonction rare impose une application entière, un canal plus simple mérite d’être comparé.

2. Sélectionner les chemins critiques

Le RGESN demande de rendre visible le périmètre évalué. Choisissez les parcours qui portent l’utilité principale, les volumes importants ou les risques de rupture. Pour un site de service, cela peut inclure la découverte d’une offre, la lecture d’une preuve, la demande de contact et la confirmation.

Ajoutez au moins un état imparfait : réseau lent, contenu absent, erreur de formulaire, refus d’un service tiers ou reprise après interruption. Une interface légère dans le scénario idéal peut devenir très coûteuse si chaque échec provoque une nouvelle saisie ou plusieurs rechargements.

3. Établir une référence plurielle

Conservez une version, une date et le scénario mesuré. Relevez ensuite seulement les signaux qui peuvent modifier une décision : octets transférés, requêtes, travail CPU, mémoire, durée serveur, dépendances tierces, compatibilité des terminaux et fréquence d’usage.

Les Core Web Vitals d’un parcours web restent une preuve d’expérience, pas une mesure environnementale complète. De même, une estimation de consommation n’est pas une analyse de cycle de vie. Présentez chaque donnée avec son périmètre au lieu de les additionner dans un score qui paraît scientifique.

4. Prioriser les réductions à la source

Traitez d’abord ce qui évite durablement une ressource : retirer une fonction sans valeur, raccourcir le parcours, limiter une collecte, réutiliser une donnée, supprimer un média décoratif ou prolonger le support d’un terminal. L’optimisation technique arrive ensuite : formats adaptés, cache, chargement conditionnel, calcul proportionné et architecture dimensionnée au besoin.

Cette priorité rejoint la doctrine Zence : construire moins ne signifie pas livrer moins bien. Une fonctionnalité retirée doit laisser une expérience complète. Le visiteur doit comprendre, agir, corriger une erreur et obtenir une confirmation sans dépendre d’un effet décoratif ou d’un appareil récent.

5. Recetter l’effet et les garde-fous

Comparez le même parcours, sur le même contexte, avant et après le changement. Vérifiez aussi ce qui ne doit pas se dégrader : compréhension, accessibilité, conversion utile, sécurité, protection des données et continuité opérationnelle.

Une image plus petite qui devient illisible n’est pas une amélioration. Un cache très long qui affiche un prix obsolète déplace le coût vers le support et la confiance. Un calcul reporté sur le navigateur peut réduire la charge serveur tout en excluant les terminaux modestes.

6. Publier une déclaration et organiser la revue

La déclaration d’écoconception rend le périmètre, la méthode, l’état d’avancement et les actions compréhensibles. Elle doit rester datée et être revue après une modification significative du service. L’Arcep présente le RGESN comme un outil mobilisable par l’ensemble des métiers du numérique, pas comme une affaire réservée au développement.

Attribuez donc chaque action : contenu, design, produit, développement, infrastructure ou achats. Une déclaration sans responsable ni prochaine date devient vite un inventaire figé.

Exemple fictif : refondre un site de réservation

Imaginons un site qui permet de choisir une prestation, un créneau et de confirmer une réservation. L’audit initial montre une vidéo en lecture automatique, un calendrier chargé dès l’arrivée, trois outils de suivi, des images identiques téléchargées en plusieurs tailles et un support limité aux téléphones récents.

La décision ne consiste pas à compresser tout uniformément. L’équipe conserve les photos qui aident à choisir, remplace la vidéo décorative par une image, charge le calendrier seulement après sélection de la prestation, réduit les événements de mesure à ceux qui pilotent une décision et teste le parcours sur un appareil plus ancien.

Elle compare ensuite cinq preuves : action terminée, données transférées, travail du terminal, délai perçu et demandes réellement reçues. Si le chargement différé du calendrier masque des créneaux ou augmente les abandons techniques, la solution doit être corrigée. L’objectif est un service complet avec moins de ressources, pas un meilleur score obtenu au détriment de l’usage.

Cet exemple est fictif. Il ne décrit ni un client ni un résultat observé par Zence.

Huit scénarios à intégrer dans la recette

1. Ouvrir le parcours sur un téléphone ancien encore dans la politique de support.
2. Terminer l’action avec un réseau mobile lent ou instable.
3. Refuser les traceurs non nécessaires et vérifier que le service principal reste utilisable.
4. Charger un contenu long, une image réelle et un état sans donnée sans débordement ni double transfert.
5. Reprendre après une erreur serveur ou une interruption sans recommencer toute la saisie.
6. Mesurer une visite sans dupliquer les événements entre scripts, serveur et outils tiers.
7. Déployer une modification puis comparer le même chemin critique à la référence datée.
8. Décommissionner une fonctionnalité ou un environnement et vérifier les données, accès et dépendances restants.

Ces scénarios ne couvrent pas tous les critères du RGESN. Ils donnent une première preuve complète, assez petite pour être rejouée après une évolution et assez large pour détecter un déplacement d’impact.

Écoconception, performance et accessibilité : trois preuves distinctes

Une bonne démarche crée souvent des bénéfices communs : moins de JavaScript peut améliorer la réactivité, des médias justifiés facilitent la lecture et un support plus large limite l’obsolescence logicielle. Ces convergences ne rendent pas les disciplines interchangeables.

La performance observe la rapidité et la stabilité dans un contexte donné. L’accessibilité vérifie que les personnes peuvent percevoir, comprendre et utiliser le service. L’écoconception questionne les ressources mobilisées sur le cycle de vie. La sécurité et la protection des données ajoutent encore leurs propres critères.

Le guide officiel d’éco-socio-conception de l’ADEME commence lui aussi par l’utilité et le format nécessaire. La priorité n’est pas de cumuler des labels, mais de résoudre les contradictions avec des preuves explicites.

Ce que la démarche ne permet pas d’affirmer

Un audit RGESN n’est pas une analyse de cycle de vie complète. Un score automatique ne mesure ni l’utilité, ni la durée de vie réelle, ni tous les effets indirects. Un hébergement présenté comme moins carboné ne rend pas une fonction inutile souhaitable. Enfin, aucune optimisation ne permet de promettre une empreinte « neutre » sans périmètre, méthode et réduction démontrés.

Les chiffres nationaux doivent rester nationaux. Les facteurs d’impact, les usages et les infrastructures évoluent. Une estimation est utile pour comparer des options dans un périmètre stable ; elle devient trompeuse lorsqu’elle est transformée en équivalent universel par page vue.

Commencer par la plus petite preuve environnementale complète

Pour une première passe, sélectionnez un parcours important, un terminal représentatif, un état imparfait et quatre mesures qui peuvent changer la décision. Documentez l’utilité, retirez une ressource à la source, vérifiez l’action complète, puis consignez la limite et la prochaine revue.

La méthode de refonte web aide à préserver les contenus, URLs et preuves déjà utiles. Le guide de maintenance transforme ensuite les revues, dépendances et responsabilités en continuité d’exploitation. Zence peut relier ces décisions dans une création ou refonte de site web sur mesure, sans imposer une reconstruction lorsque quelques corrections ciblées suffisent.

L’écoconception devient crédible quand elle change une décision : une fonction retirée, un parcours raccourci, un terminal conservé plus longtemps, une donnée non collectée, un calcul évité ou un service arrêté proprement. Le reste doit être présenté comme une hypothèse à vérifier, pas comme une promesse verte.

Sources principales

• Ministère de la Transition écologique — Haut Comité pour le numérique écoresponsable, publié le 14 septembre 2026, événement tenu le 15 septembre 2026.
• Direction générale des Entreprises — retour sur la troisième édition du Haut Comité, publié le 15 septembre 2026.
• Numérique écoresponsable — RGESN version 2024, version 2 mise à jour le 28 mai 2024, avec référentiel, outils d’évaluation et modèles de déclaration.
• ADEME — impact environnemental du numérique en 2022, publié en janvier 2025, données nationales 2022.
• Arcep — présentation du RGESN, mise à jour le 17 mai 2024.