Éco-conception web : 10 leviers pour diviser par 3 l'empreinte carbone de votre site

#Le numérique brûle — et le web en est le moteur

Selon le rapport ADEME-Arcep 2024 sur l'empreinte environnementale du numérique en France, les usages numériques génèrent 2,5 % des émissions nationales de GES, soit environ 17,2 millions de tonnes équivalent CO2. À l'échelle mondiale, le chiffre atteint 4 % des émissions totales — davantage que l'aviation civile internationale (2,8 %).

Le collectif GreenIT.fr estime que le Web mondial consomme chaque année 520 TWh d'électricité, soit l'équivalent de la consommation électrique annuelle de la France multipliée par 1,3. Un chargement de page moyen en 2025 représente 2,5 Mo de données transférées, contre 700 Ko en 2012. Cette inflation silencieuse a un coût carbone réel.

La bonne nouvelle : contrairement à d'autres secteurs, le web peut améliorer son empreinte sans sacrifier la valeur délivrée. Les leviers suivants sont classés par ordre d'impact carbone décroissant, chacun quantifié sur la base des données GreenIT.fr et des mesures terrain Nehos.

#Les 10 leviers classés par impact carbone

#Levier 1 — Optimisation des images (impact : -35 à -50 % du poids page)

Les images représentent en moyenne 55 % du poids total d'une page web (HTTPArchive 2025). C'est le levier à activer en premier.

Actions concrètes :

• Formats modernes : migrer de JPEG/PNG vers WebP (-30 % de poids à qualité visuelle équivalente) puis vers AVIF (-50 % vs JPEG pour les visuels complexes). La balise <picture> avec fallback JPEG assure la compatibilité universelle.
• Lazy loading natif : loading="lazy" sur toutes les images hors viewport initial. Le LCP (Largest Contentful Paint) ne doit porter que loading="eager" et fetchpriority="high".
• Responsive images : attributs srcset et sizes pour servir la résolution exacte selon le viewport. Éviter de charger une image 2400 px sur un mobile 390 px — gain moyen de 60 % sur le volume transféré.
• CDN avec optimisation à la volée : Cloudflare Images, Cloudinary ou imgix transforment et redimensionnent côté serveur. Le navigateur reçoit uniquement la taille nécessaire.
• Compression agressive : cibler un poids maximal de 80 KB par image décorative, 200 KB par visuel hero. Outils : Squoosh (manuel), sharp (pipeline CI).

Gain CO2 estimé : -30 à -45 g CO2e par visite sur un site à forte densité d'images.

#Levier 2 — Réduction du JavaScript (impact : -20 à -35 % du temps CPU)

Un bundle JavaScript volumineux génère trois coûts environnementaux : le transfert réseau, le parsing et la compilation, puis l'exécution. La consommation CPU est directement proportionnelle aux émissions des terminaux utilisateurs — qui représentent 70 % de l'empreinte carbone d'un site web selon GreenIT.

Actions concrètes :

• Tree-shaking : configurer Webpack, Rollup ou Vite pour éliminer le code mort (exports non utilisés). Attention aux bibliothèques sans ESM natif qui résistent au tree-shaking.
• Code splitting : ne charger que le code nécessaire à la page courante. En React/Next.js, React.lazy() + Suspense ou les import dynamiques (import()) permettent un splitting automatique par route.
• Audit des dépendances : npm ls --depth=0 puis analyse avec Bundlephobia. Une librairie de 80 KB pour formater une date peut être remplacée par 3 lignes de Intl.DateTimeFormat.
• Suppression des polyfills inutiles : Babel avec @babel/preset-env ciblant uniquement les navigateurs réellement utilisés (couverture 98 %) élimine les polyfills pour des navigateurs marginaux.
• Différer le non-critique : attribut defer sur les scripts analytics, type="module" pour les scripts applicatifs (parsing différé natif).

Gain CO2 estimé : -15 à -25 g CO2e par visite sur une SPA standard.

#Levier 3 — Mise en cache agressive (impact : -40 à -70 % des requêtes réseau)

Chaque requête HTTP déclenche une chaîne de consommations énergétiques : terminal, réseau mobile ou fixe, routeurs, serveurs. La mise en cache coupe cette chaîne à la racine.

Actions concrètes :

• Cache-Control optimisé : assets statiques (JS, CSS, fonts, images) avec Cache-Control: public, max-age=31536000, immutable (1 an). Les noms de fichiers incluent un hash de contenu (fingerprinting) pour invalider le cache à chaque déploiement.
• CDN edge : Cloudflare, Fastly ou OVHcloud CDN servent les assets depuis le PoP le plus proche de l'utilisateur. Un visiteur parisien ne devrait jamais aller chercher un fichier statique sur un serveur toulousain.
• Service Workers : pour les PWA ou les sites à forte récurrence, un Service Worker peut mettre en cache l'ensemble de l'application shell et servir les pages offline ou depuis le cache local sans aucune requête réseau.
• Stale-While-Revalidate : stratégie qui sert immédiatement depuis le cache et renouvelle en arrière-plan. Réduit la latence perçue et le nombre de requêtes origin server.

Gain CO2 estimé : -20 à -40 g CO2e par visite retour (visiteur revenant sur le site).

#Levier 4 — Hébergement vert (impact : facteur 3 à 10 sur l'empreinte infrastructure)

L'empreinte carbone d'un serveur dépend de deux variables : le PUE (Power Usage Effectiveness) du datacenter et le mix énergétique de l'électricité consommée.

Actions concrètes :

• Choisir un hébergeur alimenté en énergie renouvelable : Infomaniak (Suisse, 100 % renouvelable), Scaleway (engagements net-zero, énergie renouvelable en France), OVHcloud (programme HEX à Strasbourg avec récupération de chaleur).
• PUE cible : viser un datacenter avec PUE inférieur à 1,3 (meilleurs data centers atteignent 1,1). Un PUE de 2,0 signifie que pour 1 W de compute, 1 W est gaspillé en refroidissement.
• Localisation en France ou UE : réduit la distance physique pour les visiteurs européens, et garantit un mix électrique bas-carbone (le nucléaire français produit ~70 g CO2e/kWh contre 400 g pour le charbon).
• Dimensionnement juste : un serveur fonctionnant à 10 % de charge consomme presque autant d'électricité qu'à 80 %. Le serverless (Levier 8) et l'auto-scaling résolvent ce problème structurellement.
• Label Numérique Responsable : vérifier si l'hébergeur est labellisé NR (INR) ou engagé dans des référentiels comme le GHG Protocol.

Gain CO2 estimé : multiplier par 3 à 10 la différence d'empreinte infrastructure selon le mix énergétique du pays d'hébergement.

#Levier 5 — Optimisation des polices web (impact : -5 à -15 % du poids page)

Les Google Fonts chargées via CDN externe génèrent 2 requêtes DNS, 1 connexion TLS et entre 30 et 200 KB de fichiers de polices. Multiplié par des millions de sites, l'impact agrégé est significatif.

Actions concrètes :

• Auto-hébergement des polices : héberger les fichiers WOFF2 directement sur votre serveur ou CDN. Élimine la dépendance externe et permet un contrôle total du cache.
• Subset Unicode : ne charger que les glyphes réellement utilisés. Un subset latin (U+0020–U+00FF) représente 10 à 20 KB au lieu de 80 KB pour la police complète avec tous les scripts. Outil : glyphhanger ou pyftsubset.
• font-display: swap : affiche une police système pendant le chargement de la police web. Évite le FOIT (Flash of Invisible Text), améliore le LCP et réduit la perception de lenteur.
• <link rel="preload"> : précharger le fichier de police critique dans le <head> avec as="font" crossorigin. La police est disponible dès le premier rendu.
• System font stack en fallback : -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto — pour les sections non critiques, les polices système sont instantanées et sans empreinte réseau.

Gain CO2 estimé : -5 à -12 g CO2e par visite sur un site multi-polices.

#Levier 6 — Réduction des requêtes HTTP (impact : -15 à -25 % de la latence)

Chaque requête HTTP représente une connexion, un échange de headers, une attente serveur. En HTTP/2, le multiplexing réduit le coût marginal, mais chaque requête consomme toujours des ressources CPU côté serveur et terminaux.

Actions concrètes :

• Bundling intelligent : en HTTP/2+, éviter les bundles monolithiques (1 fichier JS de 2 MB) mais aussi l'extrême granularité (200 modules de 5 KB chacun). Le sweet spot se situe entre 5 et 15 fichiers JS par page.
• CSS critique inliné : extraire le CSS above-the-fold (Critical CSS) et l'inliner dans le <head>. Le reste du CSS est chargé de manière asynchrone. Outil : Critical, critters (Next.js).
• Sprites SVG : regrouper les icônes en un seul sprite SVG référencé par <use>. Réduit 30 requêtes d'icônes à 1 seul fichier mis en cache.
• Prefetch intelligent : <link rel="prefetch"> pour anticiper les ressources des pages suivantes probables (ex. page produit depuis une page liste). <link rel="preconnect"> pour les origines tierces critiques.
• DNS prefetch : <link rel="dns-prefetch"> pour les domaines tiers inévitables (analytics, fonts hébergées). Réduit la latence DNS de 20 à 120 ms par domaine.

Gain CO2 estimé : -8 à -15 g CO2e par visite.

#Levier 7 — Suppression des tiers superflus (impact : -25 à -60 % des ressources bloquantes)

Les scripts tiers sont le principal angle mort de l'éco-conception web. Un site moyen charge 17 scripts tiers selon HTTPArchive 2025 : analytics, pixels publicitaires, widgets de réseaux sociaux, chatbots, heat maps, A/B testing...

Actions concrètes :

• Audit complet des tiers : utiliser WebPageTest ou Chrome DevTools > Network > filter by 3rd party. Lister chaque script, son poids, son impact sur le TTI (Time to Interactive) et sa valeur métier réelle.
• Supprimer les trackers redondants : si Google Analytics et Matomo coexistent, choisir l'un des deux. Si un pixel Facebook n'est plus relié à une campagne active, le supprimer.
• Remplacer les widgets sociaux lourds : les boutons de partage natifs des réseaux sociaux chargent entre 80 et 200 KB de JavaScript. Les remplacer par des liens HTML simples vers l'intent de partage (https://twitter.com/intent/tweet?url=...).
• Chatbot on-demand : ne charger le script du chatbot qu'à la première interaction utilisateur (événement click ou mouseover sur le bouton). Économie : 150 à 400 KB différés.
• Tag Manager audité : Google Tag Manager peut devenir un vecteur d'accumulation de scripts obsolètes. Auditer régulièrement les tags actifs et supprimer les tags sans déclencheur actif depuis 90 jours.

Gain CO2 estimé : -20 à -50 g CO2e par visite sur un site à forte densité de tiers.

#Levier 8 — Architecture serverless et edge computing (impact : infrastructure × 0,3)

Une architecture serverless ne maintient aucun serveur en veille permanente. Le code s'exécute uniquement à la demande, facturation à l'invocation. L'empreinte infrastructure au repos est quasi nulle.

Actions concrètes :

• Edge Functions : Cloudflare Workers, Vercel Edge Functions ou Netlify Edge permettent d'exécuter la logique applicative au plus près de l'utilisateur, sur le nœud CDN le plus proche. Latence réduite de 60 à 80 % vs un serveur centralisé.
• Static Site Generation (SSG) : les pages générées à la construction (Next.js, Astro, Hugo) sont servies directement depuis le CDN sans compute serveur à chaque requête. Idéal pour les sites éditoriaux, blogs et pages marketing.
• ISR (Incremental Static Regeneration) : en Next.js, les pages sont régénérées à la demande ou selon une fréquence définie. Combine les avantages du SSG et du SSR sans surcharge continue.
• Functions as a Service : les traitements ponctuels (envoi d'email, webhook, traitement de formulaire) migrent vers AWS Lambda, Cloudflare Workers ou OVHcloud Functions. Pas de serveur dédié pour des tâches exécutées 1000 fois par jour.

Gain CO2 estimé : réduction de 50 à 70 % de l'empreinte infrastructure sur une architecture entièrement serverless vs un VPS classique sous-utilisé.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Levier 9 — UX sobre : animations, autoplay, dark mode (impact : -10 à -20 % consommation terminaux)

La consommation d'énergie des terminaux (smartphones, laptops) est corrélée à l'activité CPU/GPU. Les animations complexes, les vidéos en autoplay et les effets visuels lourds sollicitent en permanence le GPU.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

Actions concrètes :

• Désactiver l'autoplay vidéo : une vidéo en autoplay mute consomme entre 0,3 et 2 W supplémentaires selon le terminal. Remplacer par une vignette cliquable avec chargement à la demande (loading="lazy" sur <video>).
• Respecter prefers-reduced-motion : la media query CSS permet de désactiver les animations pour les utilisateurs qui le demandent. Bonne pratique d'accessibilité et d'éco-conception simultanément.
• Dark mode : sur les écrans OLED (majorité des smartphones premium), un fond noir consomme jusqu'à 60 % moins d'énergie qu'un fond blanc. Implémenter le dark mode via prefers-color-scheme est un levier réel sur le parc mobile actuel.
• Animations CSS plutôt que JavaScript : les transitions CSS sont accélérées GPU (via transform et opacity) et évitent le re-layout. JavaScript qui modifie top, left ou width force des reflows coûteux.
• Pas de scroll jacking : les événements de scroll à haute fréquence sollicitent le CPU en permanence. Préférer les animations déclenchées par IntersectionObserver (événements discrets).

Gain CO2 estimé : -5 à -15 g CO2e par session sur les terminaux mobiles OLED.

#Levier 10 — Monitoring continu (impact : maintien des gains dans la durée)

Sans mesure continue, les optimisations régressent. Chaque mise à jour de dépendance, chaque nouveau composant ou chaque script marketing ajouté peut effacer en quelques minutes les gains obtenus en sprints.

Actions concrètes :

• EcoIndex : outil open source de GreenIT.fr, disponible comme extension Chrome et en API. Mesure le score A-G d'une page sur la base du nombre de requêtes HTTP, du poids de la page et du nombre d'éléments DOM. À intégrer dans la CI/CD avec un seuil minimum (ex. : score C obligatoire pour merger).
• Lighthouse CI : Google Lighthouse intégré en pipeline CI (GitHub Actions, GitLab CI). Les scores Performance, Accessibility, Best Practices et SEO évoluent en parallèle des métriques éco-conception.
• Core Web Vitals monitoring : Google Search Console + Vercel Speed Insights ou Sentry Performance. Le LCP, l'INP (Interaction to Next Paint) et le CLS sont corrélés à l'efficacité du code, donc à son empreinte.
• Carbon.txt : standard émergent (proposition W3C Sustainability Working Group) permettant aux hébergeurs de déclarer leur mix énergétique dans un fichier /carbon.txt. Vérifier si votre hébergeur le supporte.
• Budget de performance : définir et enforcer des budgets par type d'asset (max 200 KB de JS, max 500 KB d'images par page) via Webpack Bundle Analyzer ou Bundlesize dans la CI.

#Tableau de gains estimés par levier

Sources : GreenIT.fr Étude 2025, mesures terrain Nehos sur 12 projets ETI (2024-2025).

#Cas client Nehos : ETI e-commerce, EcoIndex E → B en 4 sprints

Un client ETI du secteur retail (450 collaborateurs, boutique en ligne Prestashop hébergée sur un VPS OVH sous-dimensionné) présentait en début de mission un score EcoIndex E (33/100), un poids de page moyen de 4,2 MB et un LCP de 5,8 secondes.

Sprint 1 — Images et JavaScript (3 semaines) Migration des 1 200 visuels produit vers le format WebP avec génération automatique via une commande sharp dans le pipeline déploiement. Audit des dépendances JavaScript : suppression de jQuery (82 KB), remplacement de Moment.js par Day.js (2 KB), code splitting sur les pages catégorie et produit.

Résultat sprint 1 : poids page -52 %, LCP 5,8 s → 3,1 s, score EcoIndex E → D.

Sprint 2 — Cache et tiers (2 semaines) Configuration de Cloudflare Pro avec cache statique 30 jours sur assets fingerprintés. Suppression de 7 scripts tiers inactifs (pixels publicitaires de campagnes terminées, widget météo sur la homepage). Remplacement des boutons de partage social natifs par des liens intent.

Résultat sprint 2 : requêtes HTTP -38 %, TTI -1,8 s, score EcoIndex D → C.

Sprint 3 — Hébergement et polices (2 semaines) Migration du VPS vers Scaleway (datacenter Paris, énergie renouvelable, PUE 1,3). Auto-hébergement des 2 polices web avec subset latin uniquement. Implémentation du font-display: swap.

Résultat sprint 3 : empreinte infrastructure ÷3, poids polices -65 %, score EcoIndex C → C+ (score 58).

Sprint 4 — UX sobre et monitoring (2 semaines) Désactivation des 4 vidéos en autoplay sur la homepage. Implémentation du dark mode. Intégration EcoIndex dans la CI GitHub Actions avec seuil minimum C. Dashboard Lighthouse CI automatisé à chaque déploiement.

Résultat sprint 4 : score EcoIndex B (71/100), LCP 1,9 s (Core Web Vitals : Good), taux de conversion +4,2 % (corrélation performance/conversion confirmée). Émissions CO2 estimées par visite : de 2,1 g à 0,68 g soit -68 % d'empreinte carbone.

#Éco-conception, performance et Core Web Vitals : la convergence

L'éco-conception web n'est pas une contrainte réglementaire supplémentaire. C'est une discipline qui converge naturellement avec les meilleures pratiques de performance web et les exigences de Google.

Le LCP (Largest Contentful Paint) mesure le temps d'affichage de l'élément principal de la page. Il est directement amélioré par l'optimisation des images (levier 1), la réduction du JavaScript bloquant (levier 2) et la mise en cache (levier 3).

L'INP (Interaction to Next Paint, remplacé le FID depuis mars 2024) mesure la réactivité aux interactions. Il bénéficie directement de la réduction du JavaScript long-running (levier 2) et de la suppression des tiers consommateurs de thread principal (levier 7).

Le CLS (Cumulative Layout Shift) est amélioré par la déclaration des dimensions d'images (width/height en HTML) et l'optimisation des polices web (levier 5, font-display: swap avec size-adjust).

Un site sobre est un site rapide. Un site rapide convertit mieux. Google l'a quantifié : chaque seconde de chargement supplémentaire coûte 4,42 % de taux de conversion sur mobile. Les 10 leviers d'éco-conception sont aussi 10 leviers de performance commerciale.

Le RGESN (Référentiel Général d'Éco-conception des Services Numériques), publié par la DINUM et l'ARCEP en 2022 et mis à jour en 2024, définit 79 critères organisés en 9 thématiques (stratégie, spécifications, architecture, UX/UI, contenus, frontend, backend, hébergement, algorithmique). Pour les services publics numériques, la conformité RGESN deviendra progressivement obligatoire. Pour les sites privés, elle constitue un avantage différenciant et un argument crédible dans les appels d'offres publics.

#Ce que Nehos déploie concrètement

Nehos applique ces 10 leviers selon une méthodologie en 4 temps.

Audit EcoIndex + Lighthouse : mesure initiale automatisée sur les 20 pages à plus fort trafic. Score EcoIndex, poids moyen, nombre de requêtes, scripts tiers identifiés, Core Web Vitals par page.

Priorisation impact/effort : matrice 2×2 classant les 10 leviers selon le gain CO2 estimé et la complexité d'implémentation. Les leviers 1, 2 et 7 sont toujours prioritaires (impact fort, effort modéré).

Déploiement en sprints de 2 semaines : chaque sprint cible 2 à 3 leviers, avec mesure avant/après. Les gains sont documentés en g CO2e/visite, en Ko économisés et en ms de chargement gagnées.

Monitoring CI/CD : intégration EcoIndex et Lighthouse dans la pipeline de déploiement. Aucun merge possible si le score passe en dessous du seuil défini. Le gain éco-conception est préservé dans la durée.