Éco-conception web : le guide pour développer des sites sobres et performants

L'éco-conception web consiste à intégrer les enjeux environnementaux dès la phase de conception d'un service numérique et tout au long de son cycle de vie. L'objectif : réduire l'empreinte écologique des productions web tout en maintenant, voire en améliorant, la qualité du service rendu à l'utilisateur.

Concrètement, on cherche à faire mieux avec moins : moins de requêtes, moins de poids, moins de ressources serveur, moins de sollicitation des terminaux utilisateurs. Un site éco-conçu n'est pas un site minimaliste par contrainte. C'est un site pensé intelligemment, où chaque élément a une raison d'être.

Le score EcoIndex : mesurer l'empreinte environnementale d'une page web

L'outil de référence pour évaluer l'empreinte environnementale d'une page est EcoIndex (ecoindex.fr), créé par le Collectif GreenIT. Il attribue à chaque page web un score de 0 à 100 et une note de A à G, comme le Nutri-Score ou l'étiquette énergie des appareils ménagers. Plus le score est élevé et la note proche de A, plus la page est sobre.

Les 3 critères du score EcoIndex

Le score est calculé à partir de 3 critères techniques qui représentent chacun un tiers de l'architecture d'un service web :

• Taille du DOM (nombre d'éléments HTML) — poids ×3 dans le score. Représente l'impact sur le terminal utilisateur (CPU, RAM, usure prématurée).
• Nombre de requêtes HTTP — poids ×2. Représente la charge sur les serveurs (images, scripts, CSS, fonts, API tierces).
• Poids de la page (Ko transférés) — poids ×1. Représente la consommation réseau et bande passante.

Les valeurs brutes (nombre d'éléments, nombre de requêtes, Ko) sont comparées à une base de référence issue du HTTPArchive pour situer la page par rapport à la médiane du web. La pondération n'est pas arbitraire : les terminaux utilisateurs sont considérés comme la première source d'impact environnemental du numérique (fabrication, obsolescence), les serveurs en deuxième position et le réseau en troisième.

Au-delà du score : les indicateurs environnementaux

EcoIndex traduit aussi le score en impact concret pour chaque page vue : l'empreinte GES (grammes équivalent CO2) et l'empreinte eau (centilitres d'eau bleue). Quand on multiplie ces valeurs par le trafic réel, on obtient l'impact global du site. Optimiser une page listing vue 50 000 fois par mois a infiniment plus d'impact que peaufiner une page mentions légales.

Pilier 1 — Réduire la taille du DOM (pondération ×3)

C'est le critère qui pèse le plus lourd dans le score. Le DOM est l'arbre de tous les éléments HTML de la page. Plus il y en a, plus le navigateur doit travailler pour parser, calculer le layout et afficher la page.

Les leviers d'action sur le DOM

• Limiter la longueur des pages — Un listing de 200 produits avec 15 éléments HTML chacun génère 3 000+ nœuds. La pagination ou le chargement progressif maîtrisé sont des alliés.
• Simplifier la structure HTML — Éviter les <div> imbriquées inutiles (la « div-itis »). Préférer les balises sémantiques (<section>, <article>, <nav>).
• Questionner les composants UI — Un carrousel à 10 slides avec des flèches, des dots, des animations représente souvent des centaines d'éléments DOM pour un composant que 90 % des utilisateurs ne scrollent pas au-delà de la 2e slide.
• Surveiller le code généré par les CMS — PrestaShop, WordPress et d'autres CMS peuvent générer du HTML verbeux. Il faut surveiller le rendu final, pas juste le template.

Exemple : supprimer la div-itis

Un composant mal structuré peut utiliser 10 nœuds DOM pour afficher un nom de produit et un prix. Multiplié par 48 produits sur un listing, cela représente 480 nœuds. En simplifiant avec des balises sémantiques (<article>, <h3>, <p>), on descend à 3 nœuds par carte, soit 144 nœuds pour le même résultat visuel. Le DOM est divisé par 3, et le code est plus lisible et accessible.

Même logique pour les méga-menus : un menu avec 50 liens et 5 nœuds DOM par lien génère ~250 nœuds. En utilisant une structure plate et sémantique (<nav>, <ul>, <li>, <a>), on passe à ~100 nœuds pour les mêmes liens. L'ouverture et la fermeture se gèrent en CSS pur (:hover, :focus-within).

Un bon repère : viser moins de 800 éléments DOM par page.

Pilier 2 — Réduire le nombre de requêtes HTTP (pondération ×2)

Chaque ressource chargée par le navigateur (image, fichier CSS, fichier JS, font, appel API tiers, pixel de tracking, vidéo embed) génère une requête HTTP. Moins il y en a, moins on sollicite les serveurs.

Les leviers d'action sur les requêtes

• Concaténer les fichiers — Combiner plusieurs fichiers CSS en un seul, idem pour le JS.
• Utiliser des polices système ou variables — Une Google Font avec 4 graisses génère 4 requêtes. Une font variable auto-hébergée n'en génère qu'une seule. Une font système n'en génère aucune.
• Limiter les scripts tiers — Un player YouTube peut générer 15 requêtes supplémentaires. Préférer une image de preview avec chargement au clic (facade pattern).
• Utiliser les sprites CSS ou les SVG inline — Pour les icônes, un sprite ou des SVG inline évitent de multiplier les requêtes.
• Auditer les plugins et modules — Chaque module actif peut ajouter ses propres CSS/JS, même sur les pages qui ne l'utilisent pas.

Exemple : les fonts

5 déclarations Google Fonts séparées génèrent 5 requêtes HTTP plus une dépendance à un serveur tiers. En utilisant une font variable auto-hébergée avec font-display: swap, on passe à 1 seule requête, hébergée localement. Avec une font système (system-ui), le nombre de requêtes tombe à zéro.

Exemple : les vidéos embarquées

Un <iframe> YouTube direct charge environ 15 requêtes HTTP et 800 Ko de données, même si l'utilisateur ne clique jamais sur play. En utilisant une façade légère (image de preview + chargement au clic), on réduit à 1 seule requête pour la miniature WebP. Le player ne se charge que si l'utilisateur le demande.

Le RGESN (Référentiel Général d'Écoconception de Services Numériques) recommande de viser moins de 30 requêtes HTTP par page.

Pilier 3 — Réduire le poids de la page (pondération ×1)

C'est le volume total des données transférées du serveur au navigateur. Même si ce critère a la pondération la plus faible dans EcoIndex, c'est souvent le plus facile à améliorer rapidement.

Les leviers d'action sur le poids

• Optimiser les images — Elles représentent souvent 60 à 80 % du poids total. Convertir en WebP ou AVIF, compresser sans perte visible, dimensionner correctement, utiliser le lazy loading natif.
• Minifier CSS, JS et HTML — Supprimer les espaces, commentaires et caractères inutiles en production. Gain mécanique de 10 à 30 %.
• Activer la compression serveur — Gzip ou Brotli pour compresser les fichiers texte avant transfert.
• Nettoyer le code mort — CSS non utilisé, JS chargé pour des fonctionnalités absentes. PurgeCSS ou le Coverage de Chrome DevTools aident à identifier l'inutile.
• Configurer le cache navigateur — Les en-têtes Cache-Control et Expires évitent de re-télécharger les ressources statiques à chaque visite.

Exemple : les images non optimisées

Une image JPEG de 2000×2000px non compressée pèse environ 1,2 Mo, affichée dans un conteneur de 400px. Le navigateur télécharge 1,2 Mo puis la réduit. En utilisant une image WebP avec srcset, sizes, loading="lazy" et les attributs width/height, on passe à 15-35 Ko selon l'écran.

Exemple : les assets CSS et JS

Un site qui charge Bootstrap entier (~230 Ko), Font Awesome (~100 Ko), jQuery (~90 Ko) et plusieurs plugins cumule facilement 10 requêtes et 695 Ko. En important uniquement les modules SCSS nécessaires, en utilisant PurgeCSS pour éliminer le code mort, en remplaçant Font Awesome par des SVG inline et jQuery par du JS vanilla, on descend à 2 requêtes et ~65 Ko.

Un bon repère : viser moins de 1 Mo par page, idéalement sous les 500 Ko.

Côté back-end : le code invisible qui pèse

L'éco-conception ne s'arrête pas au HTML/CSS/JS. Le back-end a un impact majeur : chaque requête SQL inutile, chaque boucle mal pensée, chaque appel API non optimisé consomme du CPU, de la RAM et de l'énergie côté serveur. Un code back-end inefficace allonge aussi le temps de réponse, donc le terminal de l'utilisateur consomme plus longtemps.

Le problème N+1 en SQL

C'est le cas classique qui plombe les performances et la consommation énergétique. Le principe : on récupère N éléments avec une première requête, puis on exécute 1 requête supplémentaire par élément pour récupérer des données liées. Pour 50 produits, cela donne 101 requêtes SQL (1 + 50 pour le stock + 50 pour le prix).

La solution : utiliser les JOIN SQL pour récupérer toutes les données en une seule requête. Le moteur SQL est optimisé pour les jointures, pas pour des centaines d'allers-retours. Ce pattern se retrouve dans tous les frameworks :

• PrestaShop — Remplacer les boucles foreach avec requête unitaire par un SELECT avec INNER JOIN et LEFT JOIN.
• WordPress — Utiliser update_post_meta_cache() pour pré-charger toutes les metas en une seule passe au lieu de get_post_meta() en boucle.
• Symfony / Doctrine — Utiliser l'eager loading avec DQL (SELECT p, c, s FROM Product p JOIN p.category c JOIN p.stock s) au lieu du lazy loading par défaut.

SELECT * : le réflexe à bannir

Un SELECT * retourne toutes les colonnes d'une table (souvent 60+ colonnes pour un produit), même si on n'en affiche que 3. Sur un listing de 50 produits, cela représente des centaines de Ko de données inutiles chargées en RAM et transférées. Il faut toujours spécifier les colonnes nécessaires.

Le cache applicatif

Des données qui changent rarement (arbre de catégories, menu de navigation) ne doivent pas être recalculées à chaque page vue. Le cache applicatif réduit le nombre de requêtes SQL de plusieurs milliers par jour à quelques-unes par heure :

• PrestaShop — Utiliser la classe Cache avec invalidation manuelle.
• WordPress — Utiliser l'API Transients (get_transient / set_transient) avec invalidation dans les hooks save_post ou edited_term.
• Symfony — Utiliser le composant Cache avec invalidation par tags.

Boucles et appels API : grouper les opérations

Mettre à jour 200 produits en boucle avec 1 GET + 1 PATCH par produit génère 400 appels API. En pré-chargeant toutes les données en un seul GET filtré (équivalent d'un WHERE IN(...)), on passe à 201 appels. Toujours préférer les opérations groupées aux boucles unitaires.

Pagination et traitement par lots

Charger 5 000 produits en RAM d'un coup pour un export risque le dépassement mémoire et surcharge le serveur. En traitant par lots de 100 éléments avec LIMIT et OFFSET, la mémoire reste sous contrôle et le serveur reste disponible pour les autres requêtes.

Index SQL : le levier sous-estimé

Un index bien placé peut diviser le temps d'exécution d'une requête par 100, sans toucher une ligne de code applicatif. Les signaux d'alerte dans un EXPLAIN : type: ALL (full scan), rows très élevé, Extra: Using filesort ou Using temporary. Un index composite ciblé (par exemple sur (id_category, position)) peut faire passer une requête de 120 ms à 2 ms.

Logs : écrire moins, écrire mieux

Logger chaque étape d'un traitement de 200 produits génère 600 écritures en base. Un seul log résumé en fin de traitement avec le détail des erreurs uniquement suffit : 1 ou 2 écritures au lieu de 600, et les informations restent utiles.

Les chiffres clés du numérique et de l'éco-conception

Selon l'ADEME (données 2024), le numérique représente environ 4,4 % de l'empreinte carbone nationale en France, soit ~29,5 MtCO2e par an. En 2020, cette part était estimée à 2,5 %. Les data centers pèsent désormais pour environ 46 % de cette empreinte.

Le Baromètre de l'Éco-Conception Digitale 2025 (Razorfish / GreenIT) a analysé 90 sites majeurs (CAC40 + top 50 e-commerce). La note moyenne d'éco-conception n'est que de 29/100 (note E). 75 % des sites obtiennent une note E ou inférieure. Les sites e-commerce sont les plus mauvais élèves avec un score moyen de 18/100 (note F).

Selon le baromètre sectoriel EY/Fruggr, l'éco-conception peut permettre jusqu'à 50 % de réduction d'empreinte environnementale, +50 % de vitesse de chargement, et environ 12 % d'économies sur les coûts d'hébergement.

Hébergement et infrastructure verte

Un code parfaitement éco-conçu hébergé sur une infrastructure énergivore et surdimensionnée limite les gains. Le choix de l'hébergeur et du dimensionnement est une décision qui impacte chaque page vue pendant toute la vie du projet.

Critères de choix d'un datacenter

• Localisation — Héberger au plus près des utilisateurs réduit la latence et l'énergie de transport. Pour un site ciblant la France, un datacenter français est préférable.
• Mix énergétique — Privilégier les datacenters alimentés en énergies renouvelables et certifiés (ISO 50001, Code of Conduct européen). Un PUE (Power Usage Effectiveness) de 1.2 est excellent, au-dessus de 1.5 c'est médiocre.
• Vérification — La Green Web Foundation maintient une base de données d'hébergeurs verts.

Dimensionnement et CDN

Un serveur dédié 32 Go de RAM qui tourne à 5 % de charge gaspille 95 % de ses ressources énergétiques. Un hébergement mutualisé ou un cloud auto-scalable s'adapte à la charge réelle. Les CDN rapprochent les ressources statiques de l'utilisateur final et réduisent la charge sur le serveur d'origine.

Sobriété design : dark mode et animations CSS

Chaque choix graphique a un impact direct sur le poids des pages et la consommation d'énergie côté terminal.

Dark mode et économie d'écran

Sur les écrans OLED/AMOLED (la majorité des smartphones actuels), chaque pixel noir est un pixel éteint. Un thème sombre peut réduire la consommation d'écran de 30 à 60 %. La déclaration @media (prefers-color-scheme: dark) en CSS applique automatiquement le thème selon les préférences utilisateur, sans JavaScript ni cookie.

Animations : privilégier CSS à JavaScript

Une animation CSS est exécutée par le GPU (accélération matérielle). Une animation JavaScript fait travailler le CPU principal, beaucoup plus énergivore. Les propriétés à privilégier pour les animations : transform, opacity, filter (GPU, pas de reflow). Les propriétés à éviter : width, height, top, left, margin (reflow coûteux au CPU).

Accessibilité : l'alliée naturelle de l'éco-conception

Accessibilité et éco-conception convergent naturellement. Un site qui respecte l'une est souvent bon sur l'autre.

• HTML sémantique — Les bonnes balises (<nav>, <main>, <article>, <button>) remplacent des <div> avec des rôles ARIA bricolés. DOM plus léger et plus propre.
• Pas de dépendance au JS — Un site accessible fonctionne sans JavaScript pour la navigation et les formulaires. Moins de JS = moins de poids, moins de requêtes, moins de CPU.
• Images avec alt — Rédiger des alt pertinents pousse à se demander si l'image est vraiment nécessaire.
• Contrastes suffisants — Pas besoin de fonts grasses ou d'effets visuels lourds pour compenser un texte illisible.

Compatibilité et lutte contre l'obsolescence

Le premier poste d'impact environnemental du numérique est la fabrication des terminaux. Allonger la durée de vie d'un appareil est le geste le plus efficace. Un site éco-conçu doit fonctionner correctement sur un appareil de 5 ans ou plus.

• Progressive enhancement — Le contenu de base fonctionne en HTML/CSS pur. Le JS enrichit l'expérience pour les navigateurs récents sans rien bloquer.
• Budget JS — ~100-150 Ko de JS (gzippé) maximum par page. Au-delà, les appareils de 3-4 ans souffrent sur le parsing.
• CSS avec fallbacks — Utiliser les nouvelles propriétés CSS avec @supports pour les navigateurs plus anciens.
• Test sur du matériel ancien — Garder un vieux smartphone dans l'équipe pour tester.

Le cadre légal : RGESN et loi REEN

L'éco-conception web n'est plus seulement une bonne pratique volontaire. Un cadre réglementaire français se met en place progressivement.

La loi REEN (novembre 2021)

La loi visant à Réduire l'Empreinte Environnementale du Numérique en France impose aux communes de plus de 50 000 habitants d'élaborer une stratégie numérique responsable. Elle encadre aussi l'obsolescence programmée logicielle. Les collectivités soumises à la loi REEN commencent à exiger des critères d'éco-conception dans leurs appels d'offres.

Le RGESN

Publié en mai 2024 par l'Arcep, l'ADEME et l'Arcom, le RGESN est le référentiel institutionnel français. Il couvre la stratégie, les spécifications, l'architecture, l'UX/UI, les contenus, le frontend, le backend et l'hébergement.

Le RWEB (GreenIT, 119 bonnes pratiques) est son complément opérationnel et technique, orienté développeur.

Par où commencer ? Guide pratique

Les quick wins (impact immédiat)

• Optimiser les images — Convertir en WebP, compresser, dimensionner, activer le lazy loading.
• Nettoyer le code — Supprimer les CSS/JS inutilisés, retirer les librairies non utilisées, minifier les assets.
• Auditer avec EcoIndex — Passer les 10 pages les plus visitées sur ecoindex.fr pour un état des lieux.

Les bonnes habitudes au quotidien

• Mesurer avant et après — Comparer le score EcoIndex avant et après chaque modification significative.
• Questionner chaque ajout — Quel est le gain utilisateur vs. le coût en DOM, requêtes et poids ?
• Penser mobile-first — Un site léger pour mobile sera léger pour tout le monde.

Méthodologie de mesure EcoIndex

Pour des mesures fiables et comparables : vider le cache navigateur avant chaque mesure, attendre le chargement complet de la page, comparer des pages du même type entre elles, et faire 3 mesures pour prendre la moyenne.

Les outils pour mesurer et améliorer

• EcoIndex — Score de 0 à 100 (A à G) basé sur les 3 critères. Limité à 10 analyses/jour par domaine en ligne.
• GreenIT-Analysis — Extension Firefox/Chrome. Calcule l'EcoIndex dans le navigateur et vérifie 23 bonnes pratiques du RWEB.
• Lighthouse (Google) — Intégré à Chrome DevTools. Les scores Performance et Best Practices recoupent les enjeux d'éco-conception.
• Website Carbon Calculator — Estimation des émissions CO2 par page vue.

Ressources pour aller plus loin

• Référentiel RWEB — Les 119 fiches de bonnes pratiques du Collectif GreenIT.
• RGESN — Le référentiel institutionnel (Arcep / ADEME / Arcom).
• Collectif GreenIT — Outils, formations et actualités.
• Écoconception web : les 115 bonnes pratiques, 5e édition, Frédéric Bordage & Raphaël Lemaire, Eyrolles, 2025.

Questions fréquentes

Qu'est-ce que le score EcoIndex ?

EcoIndex est un outil créé par le Collectif GreenIT qui attribue à chaque page web un score de 0 à 100 et une note de A à G. Il évalue trois critères : la taille du DOM (pondération x3), le nombre de requêtes HTTP (x2) et le poids de la page (x1). Plus le score est élevé, plus la page est sobre.

L'éco-conception web dégrade-t-elle l'expérience utilisateur ?

Non, au contraire. Un site éco-conçu est plus rapide, plus léger et plus accessible. Les bonnes pratiques d'éco-conception (réduction du DOM, optimisation des images, code propre) améliorent les Core Web Vitals et donc l'expérience utilisateur et le référencement naturel.

L'éco-conception est-elle obligatoire en France ?

La loi REEN (2021) impose aux communes de plus de 50 000 habitants une stratégie numérique responsable. Le RGESN (2024) fournit le référentiel institutionnel. Pour le secteur privé, l'éco-conception n'est pas encore obligatoire mais devient un critère dans les appels d'offres publics et un avantage concurrentiel.

Par où commencer pour éco-concevoir un site web ?

Trois quick wins : optimiser les images (WebP, lazy loading, dimensionnement), nettoyer le code mort (CSS/JS inutilisés) et auditer les pages les plus visitées avec EcoIndex. Ces actions ont un impact immédiat sur le score et les performances.