10 actions concrètes pour améliorer son score EcoIndex (de C à A)

Vous avez audité votre site sur ecoindex.fr et vous obtenez un C. Ou pire, un D. Vous n'êtes pas seul : la médiane des sites français se situe précisément autour de cette note. Mais la bonne nouvelle, c'est que passer de D à A ne demande ni refonte complète ni budget pharaonique. Une demi-douzaine d'optimisations bien ciblées suffisent dans la plupart des cas.

Cet article est la suite logique de notre guide complet sur EcoIndex. Là où le guide explique le fonctionnement et la méthodologie, celui-ci entre dans le concret : 10 actions techniques détaillées, classées par rapport gain/effort, avec pour chacune le mécanisme expliqué, l'estimation d'impact sur le score, et le code ou la commande à utiliser.

Ce sont les optimisations qu'on applique systématiquement chez Bob le développeur. Avec elles, faire passer un site de D à B est presque mécanique. Aller jusqu'à A demande un peu plus de discipline — mais c'est tout à fait à portée d'une équipe qui sait ce qu'elle fait.

Comprendre ce qu'EcoIndex mesure

Avant de plonger dans les actions, un rappel rapide. EcoIndex évalue trois critères, et tous les leviers d'amélioration agissent sur l'un ou plusieurs d'entre eux :

Le poids transféré (Ko) — taille totale des données chargées sur la page.
Le nombre de requêtes HTTP — chaque ressource chargée compte.
La complexité du DOM — nombre d'éléments HTML rendus.

Une bonne stratégie d'amélioration agit sur les trois en parallèle. Les actions ci-dessous sont classées par impact moyen — celles du haut donnent le plus gros saut de score pour le moins d'effort.

1. Compresser et convertir les images en WebP ou AVIF

Impact estimé : +5 à +15 points de score. C'est le plus gros levier mécanique sur la majorité des sites. Les images représentent 60 à 70 % du poids d'une page web moyenne, et la plupart des sites les servent encore en JPEG ou PNG sans optimisation.

Le mécanisme : WebP réduit la taille de 25-35 % par rapport au JPEG à qualité visuelle équivalente. AVIF, format plus récent, va jusqu'à 50 % de réduction. Les deux sont supportés par tous les navigateurs modernes (>95 % de couverture).

Comment l'appliquer :

# Conversion WebP avec cwebp (Google)
cwebp -q 80 input.jpg -o output.webp

# Conversion AVIF avec sharp (Node.js)
sharp input.jpg -o output.avif --avif --quality 60

En production, utilisez des outils automatiques :

Next.js : next/image génère WebP/AVIF à la volée. Activer dans next.config.js : images: { formats: ['image/avif', 'image/webp'] }.
WordPress : plugins comme ShortPixel, Imagify, ou Optimole.
CDN : Cloudflare Image Resizing, Bunny.net Image Engine.

Gain réel mesuré sur un site type vitrine : poids de page 2,4 Mo → 1,1 Mo. Score EcoIndex : C (45) → B (72). Pour aller plus loin sur la réduction du poids des pages (images, fonts, JS, CSS), voir notre checklist technique dédiée.

2. Activer le lazy-loading natif

Impact estimé : +3 à +8 points. Réduit le nombre de requêtes initiales en chargeant les images uniquement quand elles entrent dans la viewport.

Comment l'appliquer : ajouter loading="lazy" sur toutes les balises <img> situées sous la ligne de flottaison. Aucune lib JavaScript nécessaire — c'est un attribut HTML natif depuis 2019.

<img src="/photo.webp" alt="Description" loading="lazy" width="800" height="600" />

À noter :

Toujours préciser width et height pour éviter les Cumulative Layout Shifts (CLS).
Ne pas mettre loading="lazy" sur l'image hero (au-dessus de la ligne de flottaison) — au contraire, utiliser fetchpriority="high" pour la prioriser.
Pour les iframes (vidéos YouTube embarquées), même attribut : <iframe loading="lazy">.

Gain réel : sur un blog avec 20 images, le nombre de requêtes initiales tombe de 25 à 6. Score : +5 à +8 points.

3. Subsetter les fonts custom (ou passer aux fonts système)

Impact estimé : +3 à +6 points. Une font custom non optimisée pèse 200 à 400 Ko par graisse. Avec 3 graisses (regular, semibold, bold) et 2 jeux de caractères (latin + symboles), on arrive vite à 1 Mo de fonts inutiles.

Trois niveaux d'optimisation :

Subsetter — ne charger que les caractères utilisés. Pour un site français, le subset "latin" suffit (gain 40-60 %).
Format woff2 uniquement — c'est le seul format à utiliser en 2026, supporté partout, plus compressé que woff.
Passer aux fonts système — option radicale mais très efficace : font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;. Zéro requête, zéro Ko, et un rendu natif.

Avec Next.js :

import { Inter } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  weight: ['400', '600'],
  display: 'swap',
});

Gain réel : page de 2,1 Mo passant à 1,7 Mo après subsetting + format woff2. Et zéro requête bloquante au rendu si on utilise font-display: swap.

4. Supprimer les scripts tiers inutiles

Impact estimé : +5 à +12 points. Les scripts tiers (analytics, chat, marketing automation, A/B testing) s'accumulent au fil des années. Sur un site de 5 ans, on trouve souvent 8 à 15 scripts dont plus personne ne se souvient.

La méthode :

Ouvrir DevTools → onglet Network → filtrer sur JS.
Lister tous les scripts tiers chargés.
Pour chacun, demander : "Quelqu'un consulte-t-il cette donnée ?" Si la réponse est non ou floue, supprimer.
Pour ce qui reste, vérifier les alternatives légères : un Plausible (1 Ko gzippé) à la place de Google Analytics (45 Ko), un Crisp ou tout simplement un email à la place d'un chat lib lourde.

Quick wins fréquents :

Hotjar / Mouseflow → souvent jamais consultés, retirer.
Lib de cookie consent obsolète → migrer vers une alternative légère type Tarteaucitron ou un composant maison.
Tag Manager bourré de tags zombies → audit annuel obligatoire.

Gain réel : un client passé de 12 scripts tiers à 4. Poids de page 3,2 Mo → 1,8 Mo. Score EcoIndex : D (38) → B (74).

5. Passer en Static Site Generation (SSG)

Impact estimé : +5 à +15 points (sur sites éligibles). Si votre contenu n'est pas dynamique par utilisateur (blog, landing, vitrine, doc), le SSG est imbattable.

Pourquoi ça marche : un site SSG est servi en HTML statique pré-généré, depuis un CDN. Aucun calcul serveur entre deux builds, requêtes minimales, pas de base de données interrogée à chaque visite.

Stack recommandée :

Next.js en mode output: 'export' (pour Next.js 13+).
Astro — encore plus optimisé pour les sites de contenu, JS minimal par défaut.
Hugo — pur Go, ultra rapide, parfait pour la doc et les blogs.

À éviter : les sites Next.js / Nuxt avec un Server-Side Rendering systématique alors que le contenu est statique 99 % du temps. C'est un gaspillage de ressources serveur — et un score EcoIndex pénalisé.

Gain réel : refonte d'un blog WordPress (note D) en Astro statique → note A directement, sans autre optimisation.

6. Minifier et compresser (Brotli)

Impact estimé : +2 à +5 points. Compression réseau standard, mais souvent mal configurée.

Deux choses à vérifier :

Minification CSS/JS activée en production — la plupart des bundlers (Vite, Webpack, esbuild) le font par défaut, mais à vérifier sur les sites legacy.
Compression Brotli au lieu de gzip côté serveur. Brotli compresse 15-25 % mieux sur le HTML/CSS/JS textuel.

Comment vérifier : DevTools → Network → cliquer sur une ressource → onglet Headers → chercher content-encoding: br (Brotli activé) ou gzip. Si c'est gzip ou rien, optimiser.

Configuration nginx :

brotli on;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;
brotli_comp_level 6;

Sur Vercel, Netlify, Cloudflare : Brotli est activé par défaut. Sur OVH mutualisé ou un VPS bricolé : à vérifier.

7. Réduire la profondeur du DOM

Impact estimé : +2 à +4 points. Une page avec 1500 nœuds DOM est lente à parser et pénalisée par EcoIndex. La même refactorisée à 600 nœuds est instantanée.

D'où vient la lourdeur :

Wrappers inutiles — <div><div><span><span>... sans raison structurelle. Souvent généré par des outils no-code ou des frameworks CSS comme Bootstrap mal utilisés.
Listes excessives — afficher 200 articles sur la home alors que 12 suffisent.
HTML générique non sémantique — <div> partout au lieu de <article>, <section>, <nav>.

Comment auditer : DevTools → console → document.querySelectorAll('*').length. Si > 1000, il y a du gras.

Bénéfice annexe : un DOM léger améliore aussi l'accessibilité (lecture d'écran), le SEO, et la vitesse de rendu.

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

Impact estimé : indirect, mais réel sur les estimations CO2. EcoIndex n'évalue pas directement l'hébergeur, mais ses estimations dérivées de gCO2 par visite sont calculées sur des moyennes — qu'un hébergeur à mix vert peut améliorer.

Hébergeurs recommandés en France :

Scaleway — refroidissement adiabatique, datacenters européens, bonnes garanties RSE.
Infomaniak (Suisse, mais opère en France) — 100 % renouvelable certifié.
OVH éco — offres orientées sobriété, datacenter français.
PlanetHoster — neutralité carbone, mutualisé adapté aux sites vitrines.

Hébergeurs à éviter pour des sites européens : datacenters US ou Asie au mix carboné élevé, sauf si nécessité métier (latence proche d'utilisateurs spécifiques).

Pour un comparatif détaillé, voir notre article Top 5 hébergeurs web verts en France.

9. Mettre en cache de manière agressive

Impact estimé : +3 à +6 points sur les visites récurrentes. Une visite servie depuis le cache, c'est 0 requête serveur.

Trois niveaux :

Headers HTTP — Cache-Control: public, max-age=31536000, immutable sur les assets statiques (avec hash dans le nom de fichier pour le cache busting).
CDN — Cloudflare, Bunny.net, Fastly. La majorité offrent un free tier généreux.
Service worker — pour pré-cacher les ressources critiques côté client. Voir l'API CacheStorage et Workbox pour la mise en œuvre.

Configuration Next.js : les fichiers dans /public sont servis avec un cache long par défaut sur Vercel. Pour les pages, configurer via headers() dans next.config.js.

10. Auditer en continu (CI/CD)

Impact estimé : protège les gains acquis. Un site noté A aujourd'hui peut dériver vers C en 2 ans par accumulation de scripts ajoutés sans contrôle.

La méthode :

Intégrer un check EcoIndex API dans la CI (GitHub Actions, GitLab CI).
Définir un seuil de score minimal par page critique (ex : score ≥ 75).
Faire échouer le build si la PR dégrade le score au-delà du seuil.
Compléter avec Lighthouse CI pour les Core Web Vitals.

Exemple GitHub Action :

- name: EcoIndex check
  run: |
    curl -X POST https://bff.ecoindex.fr/api/v1/ecoindexes \
      -d '{"url": "https://staging.example.com"}' \
      | jq '.score' \
      | awk '$1 < 75 {exit 1}'

Cette discipline est ce qui sépare les sites éco-conçus dans le temps des sites éco-conçus au moment de la livraison — la différence est énorme à 3 ans d'horizon.

Combien de points pouvez-vous espérer gagner ?

Tableau récapitulatif des impacts cumulés selon les optimisations appliquées :

Profil de chantier	Actions	Gain de score moyen
Quick wins (1 jour)	#1, #2, #4 partiel	+8 à +15 points
Refonte technique (1 semaine)	#1, #2, #3, #4, #6	+15 à +25 points
Refonte complète (1 mois+)	Tout, dont #5 et #10	+25 à +40 points

Concrètement : un site noté D (45) peut atteindre B (72) en une semaine de travail bien ciblé. Passer à A demande généralement une refonte de stack (action #5 — SSG) et une discipline d'audit continu (action #10).

Questions fréquentes

Quelle action a le plus d'impact ?

Sur la majorité des sites, la combinaison #1 (compression images) et #4 (nettoyage scripts tiers) représente 60 à 80 % du gain potentiel. Si vous ne deviez en faire que deux, ce sont celles-ci.

Combien de temps pour passer de D à A ?

Pour un site standard : entre 1 semaine et 1 mois de travail technique, selon l'état initial et la stack. Le passage de D à B est rapide et mécanique. Le passage de B à A demande une refonte plus profonde (souvent SSG).

Faut-il refaire le site pour atteindre A ?

Non, pas systématiquement. Beaucoup de sites peuvent passer à B ou A par optimisation incrémentale, sans refonte. La refonte devient nécessaire si la stack initiale est intrinsèquement lourde (CMS surchargé de plugins, framework JS mal exploité).

Ces actions valent-elles aussi pour le SEO ?

Oui, intégralement. Un site qui passe de D à A sur EcoIndex améliore aussi ses Core Web Vitals (LCP, CLS, INP) et donc son ranking Google. C'est le double bénéfice de l'écoconception : moins de CO2 et meilleur SEO.

Comment savoir laquelle de ces actions appliquer en priorité ?

Faites d'abord un audit EcoIndex sur 5 à 10 pages représentatives de votre site. Le rapport détaille les 3 critères (DOM, poids, requêtes) et indique lequel pèse le plus. Vous saurez alors si votre problème principal est les images, les scripts, ou la structure HTML.

En résumé

Les 3 leviers les plus puissants : compression images (#1), suppression scripts tiers (#4), passage en SSG (#5).
Un site type peut gagner +15 à +25 points en une semaine de travail ciblé.
Le passage de D à B est rapide et mécanique. De B à A demande discipline et SSG.
L'audit continu en CI/CD (#10) est ce qui maintient les gains dans la durée.
Les optimisations EcoIndex servent aussi votre SEO (Core Web Vitals).

Si vous voulez auditer votre site et structurer un plan d'action concret, parlons-en. On fait un diagnostic gratuit (score EcoIndex + 3 actions prioritaires identifiées) avant toute estimation. Voir aussi notre guide complet EcoIndex, notre guide RGESN (l'audit qualitatif complémentaire), notre checklist des 30 bonnes pratiques d'écoconception web pour la version exhaustive, 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 et notre guide sur la sobriété numérique en entreprise — sans oublier notre démarche écoconception web.

L'agence d'experts pour votre tech

Accélérez dès maintenant votre innovation grâce à votre équipe de développeurs dédiée !