Guide Complet de l'Éco-conception Web
Le guide de référence francophone pour concevoir des sites et applications web sobres, performants et respectueux de l'environnement. De la théorie à la pratique, tous les outils et méthodes pour réduire l'empreinte numérique de vos projets web.
Guide Complet de l’Éco-conception Web
Temps de lecture estimé : 45 minutes
Ce guide exhaustif vous accompagne dans la conception de services web respectueux de l’environnement. Que vous soyez développeur, designer, chef de projet ou décideur, vous y trouverez les connaissances théoriques et les outils pratiques pour réduire l’empreinte numérique de vos projets.
1. Fondamentaux de l’éco-conception web
1.1 Qu’est-ce que l’éco-conception web ?
L’éco-conception web est une démarche qui vise à réduire l’impact environnemental des services numériques dès leur conception, tout au long de leur cycle de vie. Elle s’inscrit dans une approche plus large de numérique responsable qui prend en compte les dimensions environnementales, sociales et économiques.
Définition formelle
Selon l’ADEME, l’éco-conception consiste à “intégrer l’environnement dès la conception d’un produit ou service, et lors de toutes les étapes de son cycle de vie”. Appliquée au web, cette définition implique de :
- Questionner le besoin : Chaque fonctionnalité est-elle vraiment nécessaire ?
- Optimiser les ressources : Minimiser les transferts de données, le temps de calcul, le stockage
- Prolonger la durée de vie : Concevoir des services accessibles sur des équipements anciens
- Faciliter la fin de vie : Permettre la portabilité des données, éviter le vendor lock-in
Les trois piliers de l’éco-conception web
| Pilier | Description | Exemples |
|---|---|---|
| Sobriété fonctionnelle | Moins de fonctionnalités, mais plus utiles | Supprimer les features non utilisées, simplifier les parcours |
| Efficience technique | Code optimisé, ressources minimisées | Compression, cache, lazy loading |
| Durabilité des usages | Compatible avec équipements anciens, évolutif | Support de navigateurs anciens, responsive |
1.2 Impact environnemental du web : état des lieux
Les chiffres clés du numérique mondial
Le numérique représente aujourd’hui une part significative et croissante de l’empreinte environnementale mondiale :
| Indicateur | Valeur | Source |
|---|---|---|
| Part du numérique dans les émissions mondiales de GES | 3-4% | The Shift Project, 2024 |
| Croissance annuelle du trafic internet | +25% par an | Cisco, 2023 |
| Poids moyen d’une page web | 2,4 Mo | HTTP Archive, 2024 |
| Évolution du poids des pages depuis 2010 | ×6 | HTTP Archive |
| Part de la vidéo dans le trafic internet | 82% | Sandvine, 2024 |
| Nombre d’équipements numériques dans le monde | 34 milliards | GreenIT.fr, 2024 |
Répartition de l’impact par composant
L’impact environnemental d’un service web se répartit entre trois tiers :
1. Fabrication des équipements (70-80% de l’impact total)
C’est le poste le plus important, souvent méconnu :
- Extraction des matières premières (plus de 70 matériaux différents dans un smartphone)
- Métaux rares et terres rares (lithium, cobalt, tantale…)
- Processus industriels très énergivores (fonderies de semi-conducteurs)
- Transport mondial des composants (plusieurs tours du monde pour un appareil)
2. Utilisation des équipements et services (15-25%)
- Consommation électrique des terminaux utilisateurs
- Consommation des data centers (serveurs, refroidissement, réseau)
- Consommation des équipements réseau (routeurs, antennes, câbles)
3. Fin de vie (5-10%)
- Collecte et tri des déchets électroniques (DEEE)
- Recyclage, souvent partiel (moins de 20% des métaux récupérés)
- Enfouissement ou incinération des déchets non recyclables
- Exportation illégale vers des pays en développement
Pourquoi l’éco-conception web est essentielle
Bien que l’impact direct du code soit modeste (il agit principalement sur la phase d’utilisation), l’éco-conception web a un effet multiplicateur considérable :
L’effet domino de la sobriété :
- Un site léger → Compatible avec des équipements anciens
- Compatible avec des équipements anciens → Prolonge leur durée de vie
- Durée de vie prolongée → Moins de fabrication de nouveaux appareils
- Moins de fabrication → Réduction massive de l’impact (70-80% de l’empreinte)
Calcul d’impact type :
Une page web de 3 Mo visitée 100 000 fois par mois :
- Transfert annuel : 3 Mo × 100 000 × 12 = 3,6 To
- Équivalent CO2 : environ 1,8 tonne par an (0,5g CO2/Mo en moyenne)
En optimisant à 500 Ko :
- Transfert annuel : 0,5 Mo × 100 000 × 12 = 600 Go
- Équivalent CO2 : environ 300 kg par an
- Économie : 1,5 tonne de CO2 par an (83% de réduction)
1.3 Cycle de vie d’une requête web
Pour comprendre où agir, il est essentiel de comprendre ce qui se passe lorsqu’un utilisateur charge une page web.
Anatomie d’une requête HTTP
Lorsqu’un utilisateur tape une URL ou clique sur un lien, voici ce qui se passe :
- Résolution DNS : Le navigateur demande l’adresse IP du domaine
- Connexion TCP : Établissement de la connexion avec le serveur
- Handshake TLS : Négociation du chiffrement (HTTPS)
- Requête HTTP : Le navigateur envoie la requête
- Traitement serveur : Logique métier, base de données, génération HTML
- Réponse HTTP : Le serveur renvoie le contenu
- Téléchargement : Le navigateur reçoit les données
- Parsing HTML : Analyse du document, découverte des ressources
- Requêtes secondaires : CSS, JS, images, fonts…
- Rendering : Construction de l’arbre de rendu
- Exécution JS : Interactivité
- Affichage : Premier contenu visible, puis page complète
Points d’impact environnemental
| Étape | Consommation | Optimisation possible |
|---|---|---|
| Résolution DNS | Faible | Cache DNS, réduire domaines tiers |
| Connexion réseau | Moyenne | HTTP/2, HTTP/3, keep-alive |
| Transfert données | Élevée | Compression, cache, réduction poids |
| Traitement serveur | Variable | Code optimisé, cache applicatif |
| Traitement client | Élevée | JS sobre, CSS optimisé, DOM léger |
| Affichage | Moyenne | Éviter repaints, animations GPU |
1.4 Le principe fondamental : la sobriété
“Le code le plus écologique est celui qui n’existe pas.”
Ce principe fondamental guide toute démarche d’éco-conception. Avant d’optimiser, il faut d’abord questionner la nécessité.
Hiérarchie des actions (par ordre de priorité)
- ÉVITER : Ne pas créer de besoin inutile, supprimer les fonctionnalités non utilisées
- RÉDUIRE : Simplifier les fonctionnalités restantes, minimiser les données collectées
- OPTIMISER : Améliorer l’efficience technique, compresser, mettre en cache
- COMPENSER : En dernier recours uniquement, ne résout pas le problème à la source
Questions à se poser systématiquement
Au niveau stratégique :
- Ce service numérique est-il vraiment nécessaire ?
- Existe-t-il une alternative non numérique ?
- Peut-on mutualiser avec un service existant ?
- Quelle est la durée de vie prévue ?
Au niveau fonctionnel :
- Cette fonctionnalité répond-elle à un besoin réel et fréquent ?
- Les utilisateurs l’utilisent-ils vraiment ? (vérifier avec les analytics)
- Peut-on la simplifier ?
- Quel est son coût (développement + maintenance + impact) vs sa valeur ?
Au niveau technique :
- Cette bibliothèque est-elle indispensable ?
- Cette image est-elle nécessaire ?
- Cette animation apporte-t-elle de la valeur ?
- Ce tracking est-il vraiment utilisé ?
1.5 Bénéfices de l’éco-conception web
L’éco-conception n’est pas qu’une contrainte environnementale. Elle génère de nombreux co-bénéfices qui justifient l’investissement.
Performance et expérience utilisateur
| Métrique | Impact de l’éco-conception |
|---|---|
| Temps de chargement | Réduit de 40-70% |
| Time to Interactive | Amélioré significativement |
| Core Web Vitals | Scores optimisés |
| Taux de rebond | Réduit (corrélation prouvée) |
| Taux de conversion | Augmenté (+7% par seconde gagnée selon Google) |
Études de cas :
- Pinterest : -40% temps de chargement → +15% inscriptions
- BBC : +1 seconde de chargement → -10% utilisateurs perdus
- Amazon : +100ms de latence → -1% de ventes
Accessibilité
Un site éco-conçu est naturellement plus accessible :
- Fonctionne sur des connexions lentes (zones rurales, pays en développement)
- Compatible avec des équipements anciens ou peu puissants
- Interface simplifiée, plus facile à naviguer
- Moins de JavaScript = meilleure compatibilité avec les technologies d’assistance
Économies financières
| Poste | Économie potentielle |
|---|---|
| Hébergement | -30 à -60% (moins de bande passante) |
| Infrastructure | Serveurs moins sollicités, scaling réduit |
| Maintenance | Code plus simple = moins de bugs |
| SEO | Meilleur référencement (Core Web Vitals) |
Conformité réglementaire
- Loi REEN (France) : Obligations d’éco-conception pour les services publics
- RGAA : Accessibilité obligatoire pour le service public
- RGPD : Minimisation des données collectées
- CSRD : Reporting extra-financier incluant le numérique (2024-2025)
2. Audit et mesure de l’impact
2.1 Pourquoi mesurer ?
“On ne peut améliorer que ce que l’on mesure.” — Peter Drucker
La mesure est le point de départ de toute démarche d’éco-conception. Elle permet de :
- Établir un état des lieux : Connaître la situation actuelle objectivement
- Identifier les priorités : Cibler les optimisations à fort impact
- Suivre les progrès : Mesurer l’efficacité des actions entreprises
- Communiquer : Objectiver les résultats auprès des parties prenantes
- Comparer : Se positionner par rapport aux bonnes pratiques et concurrents
2.2 Les indicateurs clés
Indicateurs techniques de base
| Indicateur | Description | Cible éco-conception | Mesure |
|---|---|---|---|
| Poids de page | Taille totale transférée | < 500 Ko (idéal), < 1 Mo (acceptable) | DevTools, WebPageTest |
| Nombre de requêtes | Requêtes HTTP pour charger la page | < 25 (idéal), < 50 (acceptable) | DevTools |
| Éléments DOM | Nombre de nœuds dans le DOM | < 800 (idéal), < 1500 (acceptable) | DevTools, Lighthouse |
| Temps de chargement | DOMContentLoaded | < 1,5s | DevTools |
| Time to Interactive | Délai avant interactivité complète | < 3s | Lighthouse |
EcoIndex : l’indicateur de référence
L’EcoIndex est un score de 0 à 100 (A à G) qui évalue l’empreinte environnementale d’une page web. Développé par le collectif GreenIT.fr, il est devenu la référence en France.
Formule de calcul :
| |
Le score est calculé à partir de trois métriques pondérées :
- DOM : Nombre d’éléments dans le DOM (complexité de la page)
- Requêtes : Nombre de requêtes HTTP (sollicitation réseau)
- Poids : Taille totale transférée en Ko (volume de données)
Grille d’évaluation EcoIndex :
| Note | Score | Interprétation | Objectif |
|---|---|---|---|
| A | 80-100 | Excellent | Sites vitrines, blogs |
| B | 65-79 | Très bien | Cible recommandée |
| C | 50-64 | Bien | Acceptable pour sites riches |
| D | 35-49 | Moyen | À améliorer |
| E | 20-34 | Insuffisant | Problèmes majeurs |
| F | 5-19 | Mauvais | Urgence à agir |
| G | 0-4 | Très mauvais | Site potentiellement inutilisable |
Équivalences environnementales :
L’EcoIndex fournit également une estimation de :
- Émissions de GES : en grammes de CO2 équivalent (gCO2e) par page vue
- Consommation d’eau : en centilitres par page vue
Exemple : Une page avec un EcoIndex de 50 (C) génère environ 2g de CO2 et consomme 3cl d’eau par visite.
2.3 Méthodologie d’audit complète
Phase 1 : Préparation (1-2 jours)
1. Définir le périmètre
Questions à se poser :
- Quelles pages auditer ? (toutes, les plus visitées, un parcours type)
- Quel est le trafic de chaque page ? (prioriser par impact)
- Quel environnement ? (production, préproduction)
- Quelles conditions de test ? (réseau, appareil simulé)
Recommandation : Commencer par les 10-20 pages les plus visitées (souvent 80% du trafic).
2. Préparer l’environnement de test
Pour des mesures reproductibles :
| |
3. Documenter le contexte
Créer un document de référence avec :
- Version du site testée (commit, date de déploiement)
- Date et heure de l’audit
- Outils et versions utilisés
- Conditions de test (réseau, appareil)
- Évaluateur
Phase 2 : Mesure (1-3 jours selon le périmètre)
Outils à utiliser :
| Outil | Ce qu’il mesure | Gratuit | URL |
|---|---|---|---|
| EcoIndex.fr | Score environnemental | Oui | ecoindex.fr |
| GreenIT Analysis | EcoIndex + bonnes pratiques | Oui | Extension Chrome/Firefox |
| Lighthouse | Performance, accessibilité, SEO | Oui | Intégré Chrome |
| WebPageTest | Performance détaillée, waterfall | Oui | webpagetest.org |
| GTmetrix | Performance, recommandations | Freemium | gtmetrix.com |
| Website Carbon | Estimation CO2 | Oui | websitecarbon.com |
| WAVE | Accessibilité | Oui | wave.webaim.org |
Processus de mesure pour chaque page :
| |
Tableau de collecte des données :
| Page | URL | Poids | Requêtes | DOM | EcoIndex | LH Perf | LH A11y |
|---|---|---|---|---|---|---|---|
| Accueil | / | ||||||
| Produits | /produits | ||||||
| Détail | /produit/1 | ||||||
| Contact | /contact |
Phase 3 : Analyse (2-3 jours)
1. Calculer les scores globaux
| |
Pondérer par le trafic pour refléter l’impact réel.
2. Identifier les problèmes principaux
Pour chaque page problématique :
- Analyser le waterfall (quelles ressources sont les plus lourdes ?)
- Lister les requêtes les plus lentes
- Identifier les erreurs JavaScript
- Repérer les ressources non utilisées
- Vérifier la configuration du cache
- Noter les problèmes d’accessibilité
3. Catégoriser les problèmes
| Catégorie | Exemples | Impact typique |
|---|---|---|
| Images | Non compressées, mauvais format, pas de lazy loading | 40-60% du poids |
| JavaScript | Librairies inutilisées, code non minifié | 20-30% du poids |
| CSS | Code mort, pas de critical CSS | 5-10% du poids |
| Fonts | Trop de variantes, pas de subset | 5-15% du poids |
| Tiers | Analytics multiples, widgets, pixels | Variable |
Phase 4 : Priorisation et recommandations
Matrice impact/effort :
| |
Quick wins typiques (fort impact, faible effort) :
- Compression des images (WebP, optimisation)
- Activation du cache navigateur
- Activation de la compression Gzip/Brotli
- Lazy loading des images
- Suppression des scripts de tracking inutilisés
Projets majeurs (fort impact, effort important) :
- Migration vers un générateur de site statique
- Refonte de l’architecture frontend
- Changement d’hébergeur
- Réécriture du système de gestion des médias
2.4 Outils de mesure détaillés
GreenIT Analysis (Extension navigateur)
Installation :
- Chrome : Chrome Web Store → Rechercher “GreenIT Analysis”
- Firefox : Addons Mozilla → Rechercher “GreenIT Analysis”
Utilisation :
- Naviguer vers la page à analyser
- Ouvrir les DevTools (F12)
- Onglet “GreenIT Analysis”
- Cliquer sur “Lancer l’analyse”
- Attendre quelques secondes
Lecture des résultats :
| |
Lighthouse (Chrome DevTools)
Accès :
- DevTools (F12) → Onglet “Lighthouse”
- Ou en ligne de commande :
npx lighthouse https://example.com
Configuration recommandée :
| |
Métriques clés à surveiller :
| Métrique | Description | Cible | Poids dans le score |
|---|---|---|---|
| FCP | Premier contenu visible | < 1.8s | 10% |
| LCP | Plus grand élément visible | < 2.5s | 25% |
| TBT | Temps de blocage total | < 200ms | 30% |
| CLS | Décalage de mise en page | < 0.1 | 25% |
| SI | Vitesse de remplissage | < 3.4s | 10% |
WebPageTest
URL : https://www.webpagetest.org
Configuration recommandée :
| |
Éléments à analyser :
Waterfall chart : Visualise le chargement de chaque ressource
- Identifier les ressources bloquantes
- Repérer les longues chaînes de dépendances
- Voir l’impact du cache (Repeat View)
Content Breakdown : Répartition par type
- Quel pourcentage représentent les images ?
- Le JavaScript est-il disproportionné ?
Domains : Requêtes par domaine
- Combien de domaines tiers ?
- Lesquels sont les plus lents ?
2.5 Automatiser la mesure
Intégration CI/CD avec GitHub Actions
| |
Configuration Lighthouse CI
| |
3. Conception UX/UI responsable
3.1 Sobriété fonctionnelle
La sobriété fonctionnelle est le premier levier de l’éco-conception. Elle consiste à questionner chaque fonctionnalité pour ne garder que l’essentiel.
Le syndrome du “feature creep”
Le feature creep (ou scope creep) est la tendance naturelle des projets à accumuler des fonctionnalités au fil du temps :
| |
Constat : La plupart des applications souffrent de surcharge fonctionnelle. Des études montrent que 50 à 70% des fonctionnalités d’un logiciel sont rarement ou jamais utilisées.
Les coûts cachés de chaque fonctionnalité :
- Développement initial
- Tests et QA
- Documentation
- Formation utilisateurs
- Maintenance continue
- Dette technique
- Impact environnemental
Méthode MoSCoW pour prioriser
| Catégorie | Description | Action |
|---|---|---|
| Must have | Indispensable, le service ne fonctionne pas sans | Conserver |
| Should have | Important mais pas critique | Évaluer l’usage réel |
| Could have | Bonus, améliore l’expérience | Souvent à supprimer |
| Won’t have | Hors périmètre pour cette version | Ne pas développer |
Analyser l’usage réel
Avant de concevoir ou de conserver une fonctionnalité, vérifiez son usage :
| |
Questions à poser aux données :
- Quel % des utilisateurs utilise cette fonctionnalité ?
- À quelle fréquence ?
- Sur quel parcours critique se trouve-t-elle ?
- Peut-on la simplifier ou la supprimer ?
La règle des 80/20 :
80% des utilisateurs n’utilisent que 20% des fonctionnalités. Concentrez vos efforts sur ces 20%.
3.2 Design minimaliste
Principes du design sobre
1. Moins d’éléments visuels
| Design classique | Design sobre |
|---|---|
| Hero image plein écran (1-2 Mo) | Titre clair sur fond uni |
| Slider avec 5 images en autoplay | Une seule image pertinente |
| Animations partout | Animations ciblées et utiles |
| Pop-up newsletter, chatbot, cookies… | Interventions minimales |
| 2,5 Mo, 87 requêtes | 200 Ko, 15 requêtes |
2. Hiérarchie visuelle claire
- Un seul élément principal par écran
- Espaces blancs généreux (pas besoin d’images de fond)
- Typographie expressive plutôt que décorations graphiques
- Couleurs utilisées avec parcimonie et intention
3. Navigation intuitive
- Menus simples et peu profonds (max 2-3 niveaux)
- Chemins de navigation évidents
- Recherche efficace plutôt que navigation exhaustive
- Fil d’Ariane quand nécessaire
Système de design sobre
Créer un système de design avec des contraintes volontaires :
| |
3.3 Parcours utilisateur optimisés
Réduire le nombre d’étapes
Chaque page supplémentaire = requêtes supplémentaires = impact supplémentaire.
Exemple : Formulaire de contact
| |
Principes d’optimisation des parcours
1. Tunnel de conversion e-commerce
| Étape classique | Optimisation sobre |
|---|---|
| Panier sur page dédiée | Mini-panier en overlay |
| 4-5 étapes de checkout | Checkout one-page |
| Création compte obligatoire | Achat en guest |
| Récapitulatif sur nouvelle page | Récapitulatif inline |
2. Formulaires efficaces
- Mono-colonne : Plus rapides à remplir
- Validation temps réel : Évite les rechargements
- Auto-complétion : Réduit les erreurs
- Champs conditionnels : Ne montrer que ce qui est pertinent
- Auto-save : Évite la perte de données
3.4 Accessibilité et éco-conception
L’accessibilité et l’éco-conception sont naturellement complémentaires. Un site accessible est souvent plus sobre.
Synergies accessibilité / éco-conception
| Pratique accessible | Bénéfice éco-conception |
|---|---|
| Texte plutôt qu’images de texte | Réduction du poids |
| Structure HTML sémantique | DOM plus léger, meilleur parsing |
| Contrastes suffisants | Pas besoin d’effets graphiques complexes |
| Navigation clavier possible | Moins de JavaScript |
| Alternatives textuelles aux médias | Option de ne pas charger les médias |
| Pas de contenu en autoplay | Économie de bande passante |
Checklist accessibilité-sobriété
| |
4. Optimisation des images et médias
Les images représentent en moyenne 50% du poids d’une page web. C’est le premier levier d’optimisation et souvent le plus rapide à mettre en œuvre.
4.1 Diagnostic initial
Avant d’optimiser, analysez la situation actuelle :
| |
Pour chaque image, relevez :
- Format actuel (JPEG, PNG, GIF, WebP, AVIF)
- Dimensions réelles (largeur × hauteur en pixels)
- Poids du fichier
- Dimensions d’affichage réelles
- Usage (décoration, contenu, logo)
Exemple de diagnostic :
| Image | Format | Dimensions fichier | Affiché à | Poids | Économie potentielle |
|---|---|---|---|---|---|
| hero.jpg | JPEG | 2400×1600 | 1200×800 | 1,2 Mo | 80% (resize + WebP) |
| logo.png | PNG | 800×200 | 200×50 | 185 Ko | 95% (SVG) |
| photo-1.jpg | JPEG | 1920×1080 | 400×300 | 380 Ko | 70% (resize + WebP) |
| icon-1.png | PNG | 64×64 | 24×24 | 12 Ko | 90% (SVG sprite) |
4.2 Choisir le bon format
Comparatif des formats
| Format | Compression | Transparence | Animation | Support | Cas d’usage |
|---|---|---|---|---|---|
| JPEG | Avec perte | Non | Non | 100% | Photos (fallback) |
| PNG | Sans perte | Oui | Non | 100% | Graphiques avec transparence |
| GIF | Limité | Oui (1 bit) | Oui | 100% | À éviter (utiliser vidéo) |
| WebP | Les deux | Oui | Oui | 97% | Recommandé pour tout |
| AVIF | Avec perte | Oui | Oui | 92% | Meilleur mais support limité |
| SVG | Vectoriel | Oui | Oui | 100% | Icônes, logos, illustrations |
Arbre de décision
| |
4.3 Compression des images
Niveaux de qualité recommandés
| Type d’image | Qualité WebP | Qualité JPEG | Justification |
|---|---|---|---|
| Hero/Banner | 75-80 | 80-85 | Grande taille, détails visibles |
| Photos produit | 75-80 | 80-85 | Détails importants pour conversion |
| Vignettes | 60-70 | 70-75 | Petite taille affichée |
| Arrière-plans | 50-60 | 60-70 | Souvent flouté ou sous du texte |
| Avatars | 65-75 | 75-80 | Petite taille, visages reconnaissables |
Outils de compression
En ligne (sans installation) :
- Squoosh (squoosh.app) : Le meilleur, comparaison visuelle avant/après
- TinyPNG (tinypng.com) : Simple et efficace pour PNG/JPEG/WebP
- SVGOMG (jakearchibald.github.io/svgomg/) : Optimisation SVG
Ligne de commande :
| |
Script Node.js avec Sharp :
| |
4.4 Images responsives
Servir la bonne taille d’image selon l’appareil évite de transférer des pixels inutiles.
Attribut srcset
| |
Explication :
srcset: Liste les images disponibles avec leur largeur intrinsèquesizes: Indique la taille d’affichage selon la viewport- Le navigateur calcule automatiquement quelle image télécharger
widthetheight: Évitent le CLS (Cumulative Layout Shift)
Élément picture (formats multiples)
| |
4.5 Lazy loading
Le lazy loading diffère le chargement des images jusqu’à ce qu’elles soient proches de la zone visible.
Lazy loading natif (recommandé)
| |
Règles importantes :
loading="lazy"sur toutes les images below the fold- Ne PAS mettre lazy sur les images visibles immédiatement (LCP)
- Toujours spécifier
widthetheightpour éviter le layout shift decoding="async"permet un décodage non-bloquant
4.6 Optimisation des vidéos
Les vidéos sont le contenu le plus lourd. Chaque décision compte.
Règle d’or : éviter si possible
Avant d’ajouter une vidéo, demandez-vous :
- Cette vidéo est-elle vraiment nécessaire ?
- Une image ou un GIF court suffirait-il ?
- Une animation CSS peut-elle remplacer ?
- Le texte peut-il suffire ?
Si la vidéo est nécessaire
1. Pas d’autoplay (sauf cas spécifiques)
| |
2. Preload minimal
| |
3. Compression vidéo
| |
Remplacer les GIF par des vidéos
Les GIF animés sont très inefficaces. Une vidéo peut être 80-95% plus légère.
| |
| |
4.7 SVG et système d’icônes
Quand utiliser SVG
- Logos (scalables, nets à toute taille)
- Icônes (légers, stylables en CSS)
- Illustrations simples (graphiques, diagrammes)
- Tout ce qui peut être dessiné avec des formes géométriques
Optimisation SVG
| |
| |
Système d’icônes optimal
Option 1 : SVG inline (pour 1-5 icônes)
| |
Option 2 : Sprite SVG (pour beaucoup d’icônes)
| |
| |
À éviter : Icon fonts
Les polices d’icônes (Font Awesome, etc.) chargent souvent des centaines d’icônes inutilisées. Préférez toujours les SVG.
5. Optimisation du code frontend
5.1 HTML sémantique et léger
Structure HTML optimale
| |
Réduire la taille du DOM
Chaque élément DOM consomme de la mémoire et ralentit les manipulations JavaScript.
Objectifs :
- < 800 éléments DOM (idéal)
- < 1500 éléments DOM (acceptable)
- Profondeur maximale : 15 niveaux
Techniques de réduction :
| |
| |
5.2 CSS performant
Principes de CSS sobre
1. Utiliser les propriétés modernes
| |
2. Éviter les sélecteurs complexes
| |
3. Propriétés raccourcies
| |
Critical CSS
Le CSS critique est le CSS nécessaire pour afficher le contenu visible immédiatement (above the fold).
| |
Purger le CSS inutilisé
Les frameworks CSS incluent des milliers de classes. PurgeCSS supprime celles non utilisées.
Configuration PurgeCSS avec PostCSS :
| |
Résultats typiques :
| Framework | Taille originale | Après purge | Réduction |
|---|---|---|---|
| Tailwind CSS | 3,5 Mo | 10-30 Ko | 99% |
| Bootstrap 5 | 230 Ko | 20-50 Ko | 75-90% |
| Bulma | 200 Ko | 15-40 Ko | 80-92% |
5.3 JavaScript sobre
Le coût du JavaScript
Le JavaScript a un coût triple :
- Téléchargement : Transfert réseau
- Parsing : Analyse du code par le navigateur
- Exécution : Utilisation du CPU
Sur un appareil mobile milieu de gamme, 1 Mo de JavaScript peut prendre 3-4 secondes à traiter.
Techniques de réduction
1. Tree shaking (imports sélectifs)
| |
2. Code splitting (chargement à la demande)
| |
3. Remplacer les librairies lourdes
| Librairie lourde | Alternative légère | Économie |
|---|---|---|
| Moment.js (290 Ko) | date-fns (13 Ko sélectif) | 95%+ |
| Moment.js | Temporal API (natif, futur) | 100% |
| Lodash (70 Ko) | Vanilla JS ES6+ | 100% |
| jQuery (90 Ko) | Vanilla JS | 100% |
| Axios (13 Ko) | fetch natif | 100% |
| Chart.js (200 Ko) | uPlot (35 Ko) | 82% |
4. Vanilla JS moderne
| |
Optimisation du chargement
| |
5.4 Frameworks et alternatives légères
Coût des frameworks
| Framework | Taille (gzip) | Temps de parsing (mobile) |
|---|---|---|
| React 18 + ReactDOM | ~45 Ko | ~150ms |
| Vue 3 | ~34 Ko | ~100ms |
| Angular 17 | ~90 Ko | ~300ms |
| Svelte | ~2 Ko (runtime) | ~10ms |
| Preact | ~4 Ko | ~15ms |
| Alpine.js | ~15 Ko | ~50ms |
| Vanilla JS | 0 Ko | 0ms |
Quand utiliser un framework ?
| |
Alternatives recommandées
Pour sites avec peu d’interactivité :
- Générateurs statiques : Hugo, 11ty, Astro
- Zéro JavaScript quand possible
- Vanilla JS pour les interactions simples
Pour applications interactives :
- Preact : Compatible React, 4 Ko
- Alpine.js : Interactivité déclarative, 15 Ko
- Svelte : Compile vers vanilla JS, runtime minimal
6. Optimisation backend et serveur
6.1 Architecture sobre
Principes fondamentaux
1. Calculer moins
- Mettre en cache les résultats coûteux
- Éviter les calculs redondants
- Optimiser les algorithmes critiques
2. Stocker moins
- Ne conserver que les données nécessaires
- Compresser les données archivées
- Purger régulièrement
3. Transférer moins
- Paginer les résultats
- Permettre le filtrage côté serveur
- Compresser les réponses
Static Site Generation (SSG)
Pour la plupart des sites, le SSG est l’architecture la plus sobre :
| |
Avantages du SSG :
- Pas de serveur d’application → économie d’énergie
- CDN proche de l’utilisateur → moins de latence
- HTML pré-généré → pas de calcul par requête
- Sécurité renforcée → pas de base de données exposée
Outils recommandés :
- Hugo (Go, très rapide)
- 11ty (JavaScript, flexible)
- Astro (JavaScript, composants partiellement hydratés)
6.2 Stratégies de cache
Le cache est le levier le plus puissant pour réduire la charge serveur.
Cache navigateur (HTTP Cache)
| |
Configuration Nginx :
| |
Cache applicatif
| |
| |
6.3 Compression
Gzip vs Brotli
| Algorithme | Taux de compression | Vitesse | Support |
|---|---|---|---|
| Gzip | Bon | Rapide | 100% |
| Brotli | Excellent (+15-20%) | Plus lent | 97% |
Recommandation : Utiliser Brotli en priorité avec fallback Gzip.
Configuration Nginx :
| |
6.4 Optimisation base de données
Requêtes efficaces
| |
Indexation
| |
Éviter le problème N+1
| |
6.5 APIs efficaces
Pagination obligatoire
| |
Filtrage côté serveur
| |
7. Hébergement responsable
7.1 Critères de choix
Matrice d’évaluation d’un hébergeur
| Critère | Poids | Questions à poser |
|---|---|---|
| Énergie | 30% | Quelle source d’électricité ? % renouvelable ? PPA signé ? |
| Efficience | 25% | Quel PUE ? Quelle technologie de refroidissement ? |
| Localisation | 20% | Où sont les serveurs ? Proximité des utilisateurs ? |
| Certifications | 15% | ISO 14001 ? ISO 50001 ? Autres labels ? |
| Transparence | 10% | Rapports publics ? Données vérifiables ? |
Indicateurs data center
PUE (Power Usage Effectiveness)
| |
CUE (Carbon Usage Effectiveness)
| |
7.2 Hébergeurs recommandés
France / Europe
| Hébergeur | Énergie | PUE | Points forts |
|---|---|---|---|
| Infomaniak | 100% renouvelable | 1.1 | Suisse, très engagé, certifié ISO 14001/50001 |
| Scaleway | 100% renouvelable | 1.2 | Français, refroidissement adiabatique |
| OVHcloud | 80%+ renouvelable | 1.1-1.3 | Watercooling propriétaire, grande capacité |
| o2switch | Renouvelable | - | Hébergeur mutualisé français |
| PlanetHoster | 100% renouvelable | - | Compensé carbone |
International (cloud)
| Fournisseur | Objectif énergie | PUE | Outils carbone |
|---|---|---|---|
| Google Cloud | 100% renouvelable (atteint) | 1.1 | Carbon Footprint dashboard |
| Microsoft Azure | 100% d’ici 2025 | 1.18 | Sustainability Calculator |
| AWS | 100% d’ici 2025 | ~1.2 | Customer Carbon Footprint |
7.3 Impact du mix électrique
Le mix électrique local influence fortement l’empreinte carbone.
| Pays/Région | gCO2e/kWh | Note |
|---|---|---|
| Islande | 0 | Géothermie |
| Suède | 13 | Hydro + nucléaire |
| France | 56 | Nucléaire + hydro |
| Canada (Québec) | 2 | Hydro |
| Norvège | 8 | Hydro |
| Allemagne | 350 | Charbon + renouvelable |
| USA (moyenne) | 380 | Variable selon état |
| Pologne | 650 | Charbon |
| Australie | 650 | Charbon |
Recommandation : Privilégier les régions à électricité bas carbone (Scandinavie, France, Québec) pour vos serveurs.
7.4 Configuration serveur optimale
Nginx optimisé pour l’éco-conception
| |
8. Cas pratiques et retours d’expérience
8.1 Méthodologie de refonte éco-conçue
Planning type d’une refonte
| Phase | Durée | Activités |
|---|---|---|
| 1. Audit | 1-2 semaines | Mesure initiale, identification des problèmes |
| 2. Quick wins | 2-4 semaines | Optimisations rapides (images, cache, compression) |
| 3. Optimisations profondes | 1-3 mois | Refonte CSS/JS, architecture, hébergement |
| 4. Intégration continue | Ongoing | Tests automatisés, formation, suivi |
Exemple de résultats
Cas : Site vitrine d’entreprise
| Métrique | Avant | Après | Amélioration |
|---|---|---|---|
| Poids de page | 3,2 Mo | 380 Ko | -88% |
| Requêtes | 87 | 18 | -79% |
| EcoIndex | E (25) | A (82) | +57 points |
| Temps de chargement | 4,2s | 0,9s | -78% |
| Score Lighthouse | 34 | 96 | +62 points |
Actions réalisées :
- Remplacement du slider par une image unique
- Conversion des images en WebP
- Mise en place du lazy loading
- Remplacement de jQuery par vanilla JS
- Suppression de 4 trackers sur 6
- Configuration du cache navigateur
8.2 Erreurs courantes à éviter
| Erreur | Problème | Solution |
|---|---|---|
| Optimiser sans mesurer | Pas de baseline, impossible de prouver les gains | Toujours mesurer avant/après |
| Se focaliser sur les détails | Perdre du temps sur des micro-optimisations | Prioriser par impact |
| Ignorer le mobile | Test uniquement sur desktop fibre | Tester sur mobile 3G/4G |
| Négliger le cache | Ressources rechargées à chaque visite | Configurer Cache-Control |
| Tracker tout | Scripts analytics lourds et multiples | Un seul outil, configuré sobrement |
| Oublier l’accessibilité | Site rapide mais inutilisable pour certains | Tester avec WAVE, clavier |
9. Intégration dans les projets
9.1 Éco-conception en méthode agile
Definition of Done éco-responsable
Ajouter ces critères à votre DoD :
| |
Checklist par phase
Sprint Planning
| |
Code Review
| |
Retrospective
| |
10. Référentiels et conformité
10.1 RGESN (Référentiel Général d’Écoconception)
Le RGESN est le référentiel officiel français avec 79 critères répartis en 8 thématiques :
- Stratégie (10 critères) : Besoins, objectifs, indicateurs
- Spécifications (12 critères) : Fonctionnalités, accessibilité
- Architecture (11 critères) : Infrastructure, modularité
- UX/UI (13 critères) : Parcours, design, médias
- Contenus (6 critères) : Textes, images, vidéos
- Frontend (13 critères) : HTML, CSS, JavaScript
- Backend (8 critères) : Code serveur, cache
- Hébergement (6 critères) : Serveurs, énergie
Obligations légales (Loi REEN) :
- Obligatoire pour les services publics depuis 2024
- Déclaration environnementale à publier
- Objectifs de conformité progressifs
10.2 GR491 (Les 491 bonnes pratiques)
Le référentiel le plus complet, publié par GreenIT.fr :
- 491 bonnes pratiques détaillées
- Organisé par phase du cycle de vie
- Scoring d’impact pour chaque pratique
10.3 Conformité simplifiée
Niveau Bronze (minimum) : 50% des critères RGESN
- Fonctionnalités essentielles uniquement
- Images optimisées
- Cache configuré
Niveau Argent (recommandé) : 75% des critères
- Architecture sobre
- JavaScript minimal
- Hébergement responsable
Niveau Or (excellence) : 90%+ des critères
- Toutes les optimisations appliquées
- Monitoring continu
- Formation des équipes
Conclusion
L’éco-conception web n’est pas une contrainte, c’est une opportunité de créer des services numériques meilleurs : plus rapides, plus accessibles, moins coûteux et plus durables.
Les 10 commandements de l’éco-concepteur web
- Tu questionneras le besoin avant de développer
- Tu mesureras l’impact avant et après chaque action
- Tu optimiseras les images systématiquement
- Tu éviteras le JavaScript superflu
- Tu configureras le cache correctement
- Tu compresseras les transferts
- Tu choisiras un hébergeur responsable
- Tu penseras accessibilité dès la conception
- Tu documenteras et formeras tes équipes
- Tu amélioreras continuellement
Ressources pour aller plus loin
Communautés :
- GreenIT.fr (France)
- ClimateAction.tech (International)
- Green Software Foundation
Outils :
- EcoIndex / GreenIT Analysis
- Lighthouse
- Website Carbon
Formations :
- La Fresque du Numérique
- MOOC INRIA Numérique Responsable
- Certificat INR
Ce guide est maintenu à jour régulièrement. Les technologies et bonnes pratiques évoluent : consultez les sources originales pour les informations les plus récentes.