Checklist 30 bonnes pratiques d'écoconception web (2026)

Le collectif GreenIT maintient une liste de 115 bonnes pratiques d'écoconception web — un travail de référence qui couvre tous les aspects d'un service numérique sobre. Magnifique d'exhaustivité. Et complètement inutilisable en l'état pour une équipe qui veut juste savoir par où commencer.

Cet article extrait 30 bonnes pratiques parmi les 115, classées par couche (design, contenu, frontend, backend, hébergement). Ce sont celles qui, dans notre expérience d'agence, couvrent 80 % des gains pour 20 % de l'effort. Si votre équipe applique ces 30, elle sera déjà très au-dessus de la médiane française — et atteindra facilement un score EcoIndex B ou A.

À la fin de l'article, vous trouverez la checklist sous forme de tableau récapitulatif à imprimer ou copier dans votre outil de gestion de projet.

Comment lire cette checklist

Chaque pratique est notée selon trois axes :

• Effort : 🟢 facile (< 1 jour) — 🟡 moyen (quelques jours) — 🔴 lourd (semaines+)
• Impact : sur la perf, sur EcoIndex, sur la perception utilisateur
• Public : qui doit l'appliquer (designer / dev / chef de projet / ops)

Les pratiques sont ordonnées par couche, pas par priorité — chacune est un levier indépendant. Pour une approche par priorité, voir notre article 10 actions pour améliorer son score EcoIndex.

Couche 1 — Stratégie & cadrage (4 pratiques)

C'est ici que se gagnent ou se perdent les batailles. Une feature mal cadrée pèse plus lourd qu'une mauvaise optimisation technique.

1. Définir des objectifs métier clairs avant les fonctionnalités

🟢 Effort facile — discipline plus que technique. Avant de discuter "il faut un chat sur le site", on demande quel problème métier ça résout et comment on mesurera le succès. La moitié des features finissent par disparaître à cette étape — et c'est un gain énorme pour la sobriété.

2. Challenger chaque fonctionnalité au cadrage

🟢 Effort facile — méthode. Pour chaque feature : "Si on l'enlève, qu'est-ce qu'on perd ?" Si la réponse est floue, on retire. Le RGESN appelle ça la sobriété fonctionnelle — la feature la plus sobre est celle qu'on ne développe pas.

3. Prioriser le "must have" et reporter les "nice to have"

🟡 Effort moyen — exige de dire non. Méthode MoSCoW : Must / Should / Could / Won't. On livre uniquement les Must en V1, on observe l'usage, on ajoute les Should si vraiment utiles. La V1 minimaliste consomme moins, livre plus vite, et orienté l'évolution sur du data réel.

4. Définir un score EcoIndex cible dès le cadrage

🟢 Effort facile — clause contractuelle. Inscrire au cahier des charges : "Le site livré doit obtenir une note minimale B sur EcoIndex sur les 10 pages les plus visitées." C'est ce qu'on fait par défaut chez Bob. Sans seuil, l'éco passe à la trappe en fin de projet.

Couche 2 — Design & UX (5 pratiques)

Le design oriente toutes les décisions techniques en aval. Un design sobre se livre sobre ; un design surchargé se livre lourd, même avec les meilleures intentions techniques.

5. Privilégier les fonts système ou subsettées

🟢 Effort facile — choix designer. Les fonts custom non optimisées pèsent 200-400 Ko par graisse. Les fonts système (Inter, system-ui, -apple-system) coûtent 0 Ko. Si une font custom est non négociable, la subsetter au caractères latins en woff2 uniquement.

6. Limiter les graisses et styles de fontes utilisés

🟢 Effort facile — discipline. Une seule font, 2 à 3 graisses maximum (regular, semibold, bold). Pas d'italique si on ne s'en sert pas. Chaque variante = un fichier de plus à charger.

7. Concevoir en mobile-first et viewport raisonnable

🟢 Effort facile — méthode. 60 % des visites en France sont mobile, souvent en 4G dégradée. Un design pensé d'abord pour mobile force la sobriété visuelle et technique.

8. Utiliser des palettes simples et limiter les images décoratives

🟡 Effort moyen — choix design. Une page peut être belle avec 3 couleurs, 1 photo et de la typo. La surcharge visuelle (gradients, photos hero pleine largeur, illustrations animées) est un anti-pattern d'écoconception.

9. Désactiver les animations et auto-play par défaut

🟢 Effort facile — option utilisateur. Respecter prefers-reduced-motion au niveau CSS. Désactiver les vidéos auto-play. Proposer un mode "léger" optionnel pour les utilisateurs qui le souhaitent. Critère 4.7 du RGESN.

Couche 3 — Contenu (4 pratiques)

Les contenus représentent souvent 70-80 % du poids d'une page. C'est le levier mécanique le plus puissant.

10. Compresser et convertir les images en WebP / AVIF

🟢 Effort facile — automatisable. WebP réduit de 25-35 % vs JPEG, AVIF de 50 %. Tous les CMS modernes le proposent. Pour Next.js, next/image le fait à la volée.

11. Redimensionner les images à leur taille d'affichage

🟡 Effort moyen — discipline + tech. Servir une image de 4 000 px de large pour l'afficher en 800 px = 4x trop lourd. Utiliser srcset pour responsive, et générer plusieurs tailles automatiquement.

12. Activer le lazy-loading natif sur images et iframes

🟢 Effort facile — loading="lazy". Les images sous la ligne de flottaison ne se chargent qu'au scroll. Aucune lib JS nécessaire, support natif partout.

13. Préférer SVG vectoriel pour les icônes et illustrations simples

🟢 Effort facile — choix asset. Une icône SVG pèse 1-2 Ko, peut être animée, scale parfaitement. Inutile de charger une lib comme Font Awesome (200 Ko+) pour 8 icônes.

Couche 4 — Frontend (8 pratiques)

C'est le terrain de jeu principal d'EcoIndex. La majorité des leviers techniques sont ici.

14. Minifier CSS et JavaScript en production

🟢 Effort facile — config bundler. Tous les bundlers modernes (Vite, Webpack, esbuild) le font par défaut. À vérifier sur les sites legacy ou les sites WordPress non optimisés.

15. Activer la compression Brotli côté serveur

🟢 Effort facile — config hébergeur. Brotli compresse 15-25 % mieux que gzip. Activé par défaut sur Vercel, Netlify, Cloudflare. À vérifier sur OVH mutualisé ou VPS bricolés.

16. Supprimer le CSS et JavaScript non utilisés

🟡 Effort moyen — outil + dev. PurgeCSS ou Tailwind JIT pour le CSS. Tree-shaking activé pour le JS via Webpack ou esbuild. Sur Tailwind v3+, c'est natif.

17. Limiter les bibliothèques tierces (analytics, chat, A/B testing)

🟡 Effort moyen — décision produit. Audit annuel : pour chaque script tiers, "Quelqu'un consulte cette donnée ?" Si non, on retire. Migrer vers des alternatives légères (Plausible vs GA, Crisp vs Intercom).

18. Utiliser le cache navigateur de manière agressive

🟡 Effort moyen — config headers. Cache-Control: public, max-age=31536000, immutable sur les assets avec hash. Le navigateur ne re-télécharge plus ce qui n'a pas changé.

19. Mettre en place un service worker pour le cache offline

🔴 Effort lourd — implémentation custom. Pour les sites où la perf est critique. Workbox simplifie l'écriture. Permet aussi de pré-cacher les ressources critiques.

20. Privilégier le rendu côté serveur ou statique (SSG > SSR > SPA)

🔴 Effort lourd si refonte — choix de stack. Pour un site de contenu non personnalisé : SSG (Astro, Next.js export, Hugo). Pour un site avec personnalisation : SSR avec cache. Éviter les SPA pures pour du contenu public.

21. Réduire la profondeur du DOM (< 1 000 nœuds par page)

🟡 Effort moyen — refacto HTML. Audit avec document.querySelectorAll('*').length. Si > 1 000, supprimer les wrappers inutiles et remplacer les <div> par du HTML sémantique (<article>, <section>, <nav>).

Couche 5 — Backend (4 pratiques)

Le backend pèse moins sur EcoIndex (qui mesure côté client) mais beaucoup sur le bilan énergétique global du site (datacenter).

22. Optimiser les requêtes base de données et indexer correctement

🟡 Effort moyen — DBA discipline. Une requête SQL non indexée peut consommer 100x plus de CPU qu'une requête bien indexée. À auditer sur toute table de plus de 10 000 lignes. EXPLAIN ANALYZE sur PostgreSQL est votre ami.

23. Mettre en cache les calculs coûteux et les pages générées

🟡 Effort moyen — Redis / cache applicatif. Une page calculée une fois et servie 1 000 fois depuis le cache économise 999 calculs serveur. Standard sur les CMS sérieux (WordPress avec WP Super Cache, Drupal avec Varnish).

24. Compresser les réponses API (gzip / Brotli)

🟢 Effort facile — config serveur web. Compression activée sur le application/json au même titre que sur le HTML. Souvent oubliée sur les API custom.

25. Limiter la taille des payloads API

🟡 Effort moyen — design API. Une API REST qui renvoie un objet de 200 Ko alors qu'on n'utilise que 3 champs gaspille bande passante et CPU client. Pagination, sparse fieldsets (renvoyer uniquement les champs demandés), GraphQL pour les besoins complexes.

Couche 6 — Hébergement & infrastructure (3 pratiques)

26. Choisir un hébergeur à mix énergétique faible

🟢 Effort facile — décision unique. Pour la France : Scaleway, Infomaniak, OVH éco, PlanetHoster, O2switch. Voir notre comparatif des hébergeurs verts.

27. Servir les assets via un CDN proche des utilisateurs

🟡 Effort moyen — config + coût. Un CDN (Cloudflare, Bunny.net, Fastly) sert les assets statiques depuis un point géographique proche du visiteur. Réduit latence + bande passante datacenter principal. Free tier généreux chez Cloudflare.

28. Activer HTTP/2 ou HTTP/3 sur le serveur

🟢 Effort facile — config TLS. HTTP/2 permet le multiplexage des requêtes (toutes en parallèle sur une connexion). HTTP/3 (basé sur QUIC) est encore meilleur sur réseau dégradé. Activé par défaut sur les CDN modernes.

Couche 7 — Mesure & monitoring (2 pratiques)

29. Auditer EcoIndex et Lighthouse à chaque livraison

🟢 Effort facile — protocole. Avant chaque mise en prod, un audit sur 5-10 pages représentatives. Documenter le score et le rendre visible dans les retro de sprint. Voir notre guide EcoIndex.

30. Intégrer un check EcoIndex dans la CI/CD

🟡 Effort moyen — GitHub Action / GitLab CI. Faire échouer le build si une PR dégrade le score au-delà d'un seuil (ex : −5 points). C'est ce qui empêche la dérive lente sur 2-3 ans.

Tableau récapitulatif (à imprimer)

#	Pratique	Couche	Effort	Public
1	Définir objectifs métier avant fonctionnalités	Stratégie	🟢	Chef de projet
2	Challenger chaque fonctionnalité au cadrage	Stratégie	🟢	Chef de projet
3	Prioriser must-have / reporter nice-to-have	Stratégie	🟡	Chef de projet
4	Définir score EcoIndex cible au cadrage	Stratégie	🟢	Chef de projet
5	Fonts système ou subsettées	Design	🟢	Designer
6	Limiter graisses et styles de fontes	Design	🟢	Designer
7	Mobile-first, viewport raisonnable	Design	🟢	Designer
8	Palettes simples, peu d'images décoratives	Design	🟡	Designer
9	Désactiver animations / auto-play par défaut	Design	🟢	Designer / Dev
10	Compresser images en WebP / AVIF	Contenu	🟢	Dev / Ops
11	Redimensionner images à leur affichage	Contenu	🟡	Dev
12	Lazy-loading natif sur images / iframes	Contenu	🟢	Dev
13	SVG pour icônes et illustrations simples	Contenu	🟢	Designer / Dev
14	Minifier CSS / JS en production	Frontend	🟢	Dev
15	Activer Brotli côté serveur	Frontend	🟢	Ops
16	Supprimer CSS / JS non utilisés	Frontend	🟡	Dev
17	Limiter bibliothèques tierces	Frontend	🟡	Dev / Produit
18	Cache navigateur agressif (Cache-Control)	Frontend	🟡	Ops
19	Service worker pour cache offline	Frontend	🔴	Dev
20	SSG > SSR > SPA	Frontend	🔴	Dev / Architecte
21	DOM < 1 000 nœuds par page	Frontend	🟡	Dev
22	Indexer les requêtes BDD	Backend	🟡	Dev / DBA
23	Cache des calculs et pages générées	Backend	🟡	Dev
24	Compresser réponses API	Backend	🟢	Ops
25	Limiter taille des payloads API	Backend	🟡	Dev
26	Hébergeur à mix énergétique faible	Hébergement	🟢	Décision unique
27	CDN proche des utilisateurs	Hébergement	🟡	Ops
28	HTTP/2 ou HTTP/3 activé	Hébergement	🟢	Ops
29	Audit EcoIndex + Lighthouse à chaque livraison	Mesure	🟢	Dev / QA
30	Check EcoIndex en CI/CD	Mesure	🟡	Dev / Ops

Et les 85 autres bonnes pratiques GreenIT ?

Cette checklist couvre 30 pratiques sur les 115 maintenues par GreenIT. Les 85 autres existent — et beaucoup sont pertinentes — mais leur impact est plus marginal ou leur application plus contextuelle. Pour aller plus loin, on recommande :

• La liste officielle sur GreenIT.fr/checklist (lien vers les 115).
• Le livre "Écoconception web" de Frédéric Bordage (Eyrolles), 5e édition, qui détaille chaque pratique avec exemples de code.
• L'audit RGESN complet sur les services à enjeu fort. Voir notre guide RGESN.

L'idée n'est pas de tout cocher — c'est d'avoir une discipline d'amélioration continue. Une équipe qui applique les 30 pratiques de cette checklist + un audit EcoIndex à chaque livraison aura un site qui reste sobre dans la durée.

Questions fréquentes

Combien de pratiques faut-il appliquer pour avoir un bon score EcoIndex ?

Une vingtaine sur les 30 suffit largement à atteindre un score B sur la majorité des sites. Atteindre A demande de cocher la quasi-totalité, plus une stack initiale adaptée (typiquement SSG plutôt que SPA).

Par où commencer si on doit choisir 5 pratiques ?

Les 5 leviers les plus rapides à fort impact : #10 (images WebP/AVIF), #12 (lazy-loading), #15 (Brotli), #17 (suppression scripts tiers), #26 (hébergeur vert). Avec ces 5, beaucoup de sites passent de D à B en quelques jours.

Cette checklist s'applique-t-elle aux applications mobiles ?

Une partie oui (cadrage produit, sobriété UX, optimisation des assets, choix d'hébergement backend). Mais le mobile a ses propres spécificités (gestion notifications, batterie, support offline) qui justifient une checklist dédiée. Le RGESN en couvre une bonne partie.

Quelle est la différence entre cette checklist et le RGESN ?

Le RGESN est un référentiel officiel structurant 78 critères qualitatifs avec une logique d'audit / déclaration. Cette checklist est une synthèse opérationnelle des 30 pratiques les plus impactantes — orientée action plutôt qu'audit. Les deux sont compatibles : on peut auditer son site avec le RGESN et appliquer la checklist comme plan d'action.

Ces pratiques sont-elles compatibles avec le SEO ?

Totalement. Un site qui applique ces 30 pratiques améliore mécaniquement ses Core Web Vitals, son temps de chargement, son accessibilité — tous des signaux Google. L'écoconception et le SEO partagent les mêmes leviers techniques. C'est le double bénéfice.

En résumé

• 30 pratiques réparties sur 7 couches : stratégie, design, contenu, frontend, backend, hébergement, mesure.
• 5 leviers prioritaires : images WebP/AVIF, lazy-loading, Brotli, scripts tiers, hébergeur vert.
• Une équipe qui applique l'ensemble atteint facilement un score EcoIndex B ; le passage à A demande une stack adaptée (SSG).
• À combiner avec un audit EcoIndex à chaque livraison et idéalement un check en CI/CD pour maintenir les gains dans la durée.

Si vous voulez auditer votre site existant ou cadrer un nouveau projet avec cette discipline, parlons-en. On fait un diagnostic en 1 heure et on identifie les 5-10 pratiques prioritaires pour votre contexte. Voir aussi notre démarche écoconception web, notre guide complet EcoIndex, notre méthode en 7 étapes pour éco-concevoir un site (cadre projet complet), notre checklist technique pour diviser par 2 le poids des pages (focus poids transféré) et notre guide sur la sobriété numérique en entreprise (cadre RSE global).