RGESN : les 79 critères d'éco-conception numérique expliqués (avec exemples concrets)

#Qu'est-ce que le RGESN et quel est son cadre légal ?

Le Référentiel Général d'Écoconception des Services Numériques (RGESN) est un document de référence co-produit par la DINUM (Direction Interministérielle du Numérique), l'ARCEP, l'ARCOM et l'ADEME. Publié en version 1.0 en décembre 2022, il traduit en critères opérationnels les obligations introduites par la loi REEN (Loi visant à Réduire l'Empreinte environnementale du Numérique en France), promulguée le 15 novembre 2021.

La loi REEN est structurée autour de cinq grands axes : faire prendre conscience de l'impact environnemental du numérique, limiter le renouvellement des appareils, promouvoir des usages frugaux, développer les territoires connectés de façon sobre, et — c'est là qu'intervient le RGESN — promouvoir une conception sobre des services numériques.

Le RGESN ne crée pas à ce jour d'obligation légale directe assortie de sanctions financières pour les entreprises privées, contrairement à d'autres réglementations comme le RGPD ou la directive NIS 2. Son application est cependant obligatoire pour les services de l'État et recommandée pour toutes les organisations. Les évolutions législatives en cours (transcription de la directive européenne sur l'éco-conception des produits numériques) laissent prévoir un durcissement du cadre entre 2026 et 2028.

Pour les entreprises privées, l'enjeu est triple :

1. Conformité anticipée face à un cadre réglementaire qui va se renforcer
2. Performance technique : les critères RGESN sont directement corrélés aux Core Web Vitals et aux temps de chargement
3. Crédibilité RSE : les appels d'offres publics intègrent de plus en plus des critères d'éco-conception dans leurs cahiers des charges

#Les 79 critères : architecture en 8 thématiques

Le RGESN organise ses 79 critères en 8 thématiques qui couvrent l'intégralité du cycle de conception et d'exploitation d'un service numérique. Chaque critère est évalué selon trois niveaux : Fait, Partiel, Non fait.

#Thématique 1 — Stratégie (8 critères)

Cette thématique traite des décisions amont qui conditionnent l'ensemble du projet. Elle interroge l'organisation sur sa politique d'éco-conception, la définition de ses indicateurs de performance environnementale, et la prise en compte des impacts numériques dès la phase d'initialisation.

Critères représentatifs :

• Existence d'une politique d'éco-conception formalisée et partagée en interne
• Désignation d'un responsable de l'éco-conception au sein des équipes
• Définition d'objectifs mesurables de réduction d'impact
• Intégration des critères environnementaux dans les appels d'offres fournisseurs

Exemple de mise en œuvre : une DSI qui intègre un critère «poids de page cible ≤ 500 Ko» dans son cahier des charges UX avant tout démarrage de sprint satisfait au critère stratégique 1.3.

#Thématique 2 — Spécifications (9 critères)

Cette thématique couvre la phase de conception fonctionnelle. Elle vérifie que les besoins utilisateurs réels sont distingués des fonctionnalités superflues, et que les choix fonctionnels sont guidés par un principe de sobriété.

Critères représentatifs :

• Existence d'une phase de questionnement sur l'utilité de chaque fonctionnalité
• Analyse des usages réels pour ne conserver que les fonctionnalités effectivement utilisées
• Prise en compte des terminaux des utilisateurs cibles (dont les terminaux d'entrée de gamme)
• Définition d'une durée de vie cible pour le service

Exemple de mise en œuvre : supprimer un carrousel d'images sur la page d'accueil après analyse des données analytiques qui montrent 0 % de clics sur les slides 2 à 5 satisfait directement le critère 2.4 (élimination des fonctionnalités inutilisées).

#Thématique 3 — Architecture (10 critères)

La thématique architecture évalue les choix d'infrastructure et de découpage applicatif. Elle vise à minimiser les ressources consommées par les composants techniques sous-jacents.

Critères représentatifs :

• Choix d'une architecture technique adaptée à la charge réelle (pas de sur-dimensionnement)
• Utilisation de formats de données légers dans les échanges inter-services (JSON plutôt que XML verbeux)
• Mise en place d'une politique de cache efficace à tous les niveaux
• Stratégie de fin de vie des données et des composants applicatifs

Exemple de mise en œuvre : migrer des microservices sur-dimensionnés vers une architecture monolithique modulaire lorsque le trafic ne justifie pas la complexité distribuée satisfait le critère 3.2 (adéquation architecture / charge).

#Thématique 4 — UX/UI (13 critères)

Avec 13 critères, c'est l'une des thématiques les plus denses. Elle traite de la conception des interfaces sous l'angle de la sobriété : réduire les animations superflues, limiter les autorisations demandées, concevoir pour des terminaux peu performants.

Critères représentatifs :

• Absence d'animations déclenchées automatiquement et en boucle
• Conception orientée vers les terminaux les plus répandus chez les utilisateurs cibles
• Limitation des permissions d'accès aux ressources matérielles (caméra, micro, géolocalisation) au strict nécessaire
• Accessibilité numérique intégrée dès la conception (réduction des rendus JS complexes pour les technologies d'assistance)
• Interface adaptable aux préférences système de l'utilisateur (mode sombre, réduction des animations)

Exemple de mise en œuvre : respecter la media query prefers-reduced-motion pour désactiver les animations chez les utilisateurs ayant activé cette préférence satisfait le critère UX/UI 4.8.

#Thématique 5 — Contenus (8 critères)

Cette thématique s'intéresse au poids et au format des contenus diffusés : images, vidéos, polices, documents. Elle vise la réduction de la bande passante consommée par les actifs médias.

Critères représentatifs :

• Compression systématique des images avec formats modernes (WebP, AVIF)
• Vidéos non lancées automatiquement et hébergées en externe si possible
• Polices d'écriture limitées en nombre et en variantes (pas plus de 2 familles typographiques)
• Sous-titrage des vidéos pour éviter la rediffusion en cas d'incompréhension

Exemple de mise en œuvre : convertir toutes les images d'un site de JPG vers AVIF avec un ratio de compression ×3 et activer le lazy loading natif (loading="lazy") satisfait les critères contenus 5.1 et 5.2.

#Thématique 6 — Frontend (10 critères)

La thématique frontend évalue le code côté navigateur : JavaScript, CSS, HTML et les ressources tierces. C'est souvent la thématique qui révèle les écarts les plus importants dans les audits.

Critères représentatifs :

• Minification et compression des fichiers CSS et JavaScript
• Suppression du code mort (dead code) non utilisé en production
• Limitation des scripts tiers (analytics, publicité, réseaux sociaux) au strict nécessaire
• Suppression des requêtes bloquantes dans le critical rendering path
• Utilisation du cache navigateur avec des en-têtes Cache-Control appropriés

Exemple de mise en œuvre : remplacer Google Analytics 4 (1,2 Mo de bundle) par Plausible Analytics ou Matomo (< 50 Ko) réduit le poids JavaScript d'une page de 70 % et satisfait le critère frontend 6.5 (réduction des scripts tiers).

#Thématique 7 — Backend (11 critères)

Le backend couvre l'ensemble du traitement serveur : requêtes base de données, API, traitement des données, mise en cache côté serveur.

Critères représentatifs :

• Requêtes base de données optimisées (index, requêtes préparées, limitation du nombre de requêtes par page)
• Mise en cache des résultats de calcul coûteux (résultats d'API, agrégats de données)
• Suppression des données inutilisées dans les réponses API (over-fetching)
• Planification des traitements batch hors des heures de pic de consommation électrique
• Compression des réponses serveur (Gzip, Brotli)

Exemple de mise en œuvre : activer Brotli sur le serveur web (gain de 20 à 26 % par rapport à Gzip sur les fichiers texte) et mettre en cache les réponses d'API stables pendant 5 minutes satisfait les critères backend 7.3 et 7.7.

#Thématique 8 — Hébergement (10 critères)

L'hébergement est la thématique la plus structurelle, car elle conditionne l'impact énergétique de l'infrastructure. Elle évalue le choix du data center, la source d'énergie, l'efficacité du refroidissement (PUE), et la politique de densification des serveurs.

Critères représentatifs :

• Hébergeur disposant d'un PUE (Power Usage Effectiveness) inférieur à 1,5
• Utilisation d'énergie d'origine renouvelable certifiée (label renewable energy certificate)
• Politique de mutualisation des ressources serveurs (virtualisation, conteneurisation)
• Localisation du data center dans un pays à mix électrique sobre
• Politique de renouvellement des serveurs physiques (allongement de durée de vie)

Exemple de mise en œuvre : migrer d'un hébergement mutualisé standard vers OVHcloud Éco (centres de données avec refroidissement à l'eau chaude, PUE moyen de 1,3) ou Scaleway (data centers alimentés à 100 % en énergie renouvelable) satisfait les critères hébergement 8.1, 8.2 et 8.4.

#Les 20 critères les plus impactants

Tous les critères ne génèrent pas le même niveau de gain environnemental. Voici les 20 critères que les audits terrain Nehos identifient systématiquement comme les plus structurants, classés par thématique.

#Frontend (impact technique le plus direct)

F-1 — Minification des ressources statiques : minifier CSS et JS réduit le transfert réseau de 15 à 40 %. Outillage : Webpack, Vite, esbuild.

F-2 — Suppression du code mort : le bundle JavaScript moyen d'un site React contient 40 % de code non utilisé. Outil : Webpack Bundle Analyzer, Coverage DevTools.

F-3 — Limitation des scripts tiers : chaque script tiers (widget, pixel tracking, chat) ajoute 200 à 800 ms de chargement. Audit de chaque script avec Privacy Badger ou uBlock pour identifier les superflus.

F-4 — Cache navigateur : définir des Cache-Control: max-age=31536000 sur les assets versionnés (CSS, JS, images) évite de re-télécharger ces ressources à chaque visite.

F-5 — Réduction du Critical Rendering Path : inliner le CSS critique (above-the-fold) et différer le CSS non critique avec media="print" onload supprime le blocage du rendu initial.

#Contenus (impact bande passante immédiat)

C-1 — Conversion en AVIF/WebP : AVIF offre un rapport qualité/poids 2 à 3 fois supérieur au JPEG. Sur un site e-commerce de 200 pages, le gain peut dépasser 60 % sur le poids total des images.

C-2 — Lazy loading des images : loading="lazy" natif sur toutes les images below-the-fold. Économie mesurable : 30 à 50 % des transferts sur la première visite.

C-3 — Dimensionnement des images : servir des images à la taille exacte d'affichage via srcset et sizes. Ne jamais servir une image 2 000 px pour un rendu de 400 px.

C-4 — Limitation des polices web : chaque famille typographique représente 30 à 120 Ko. Utiliser font-display: swap et ne charger que les variantes nécessaires (weight + style effectivement utilisés).

C-5 — Vidéos non autoplay : une vidéo en autoplay consomme en moyenne 4 Mo à chaque chargement de page, même pour les utilisateurs qui ne la regardent pas.

#Architecture (impact structurel)

A-1 — Cache côté serveur : mettre en cache les pages HTML générées (full-page cache sur Varnish, Redis, ou le CDN) réduit la charge CPU serveur de 70 à 90 % sur les contenus peu dynamiques.

A-2 — CDN et compression Brotli : distribuer les assets via CDN avec compression Brotli réduit la latence et le poids transféré simultanément.

A-3 — Base de données : limitation des requêtes N+1 : le pattern N+1 (une requête par item d'une liste) multiplie les appels base de données. Corriger avec des jointures ou du batching divise le nombre de requêtes par 10 à 100.

A-4 — Dimensionnement infrastructure : une instance cloud sur-dimensionnée de 50 % consomme 50 % d'énergie en plus pour le même service rendu. Rightsizing avec les outils du cloud provider (AWS Compute Optimizer, OVH Advisor).

#UX/UI (impact perception utilisateur + consommation terminal)

U-1 — Suppression des animations inutiles : les animations CSS/JS maintiennent le GPU du terminal actif en permanence. Supprimer les animations décoratives réduit la consommation de la batterie du terminal de l'utilisateur.

U-2 — Mode sombre natif : un écran OLED en mode sombre consomme 60 % moins d'énergie qu'en mode clair. Implémenter prefers-color-scheme: dark sans effort supplémentaire pour les utilisateurs équipés.

U-3 — Conception pour terminaux d'entrée de gamme : tester sur un terminal Android mid-range (processeur Snapdragon 4xx) révèle les goulots d'étranglement JavaScript invisibles sur MacBook.

#Hébergement (impact carbone direct)

H-1 — PUE inférieur à 1,5 : un data center avec un PUE de 2,0 consomme deux fois l'énergie utile pour le refroidissement. Le passage à PUE 1,3 représente 35 % d'économie d'énergie à service rendu équivalent.

H-2 — Énergie renouvelable certifiée : choisir un hébergeur disposant d'un certificat Renewable Energy Certificate (REC) ou Energy Attribute Certificate (EAC) pour la même charge de travail.

H-3 — Allongement de la durée de vie des serveurs : la fabrication d'un serveur représente 50 % de son impact carbone total sur 4 ans. Passer à 6 ans de durée d'utilisation divise l'impact de fabrication par 1,5.

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

#Comment auditer son service numérique avec la grille RGESN ?

La DINUM met à disposition une grille d'évaluation officielle téléchargeable sur numerique.gouv.fr. Elle prend la forme d'un tableur structuré par thématique, avec pour chaque critère :

• L'intitulé du critère
• Le moyen de vérification recommandé
• L'espace pour noter : Fait / Partiel / Non fait / Non applicable
• Un champ commentaire pour documenter les preuves

#Déroulé type d'un audit RGESN en 5 étapes

Étape 1 — Cadrage et périmètre (2 jours) : définir précisément quel service numérique est audité (site web, application mobile, application interne ?), quelles sont les pages ou écrans dans le périmètre, et qui sont les parties prenantes (DSI, UX designer, développeurs, exploitants).

Étape 2 — Collecte des données techniques (3 jours) : utiliser les outils de mesure pour obtenir des données objectives sur le service existant avant de remplir la grille. Les mesures sont effectuées depuis les pages les plus visitées (top 10 du trafic Analytics).

Étape 3 — Évaluation critère par critère (3 à 5 jours) : remplir la grille RGESN thématique par thématique, avec au moins deux intervenants pour chaque thématique (ex : le développeur frontend pour la thématique 6, l'architecte pour la thématique 3).

Étape 4 — Calcul du score et priorisation (1 jour) : calculer le taux de conformité global et par thématique. Identifier les critères «Non fait» qui génèrent le plus d'impact environnemental et sont le plus facilement adressables (matrice impact × effort).

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

Étape 5 — Plan de remédiation (2 jours) : produire un plan d'action priorisé avec responsable, estimation de charge, et indicateur de mesure post-implémentation.

#Les outils de mesure : EcoIndex, Lighthouse, WebPageTest

#EcoIndex

EcoIndex est l'outil de référence développé par le collectif GreenIT.fr pour mesurer l'empreinte environnementale d'une page web. Il produit un score de 0 à 100 (plus c'est élevé, mieux c'est) en s'appuyant sur trois métriques :

• Le nombre de requêtes HTTP
• Le poids total de la page (en Ko)
• Le nombre d'éléments du DOM

EcoIndex convertit ensuite ce score en deux indicateurs concrets : grammes d'équivalent CO₂ par page vue et centilitres d'eau consommés. Ces valeurs permettent de communiquer l'impact en termes non-techniques auprès des décideurs.

Exemple de lecture : une page avec un score EcoIndex de 35 (note D) génère environ 2,7 g de CO₂ par page vue. Avec 100 000 visites par mois, cela représente 270 kg de CO₂ mensuel, soit l'équivalent de 4 allers-retours Paris-Lyon en voiture.

#Google Lighthouse

Lighthouse est l'outil d'audit intégré dans Chrome DevTools (onglet «Lighthouse» ou accessible via lighthouse en CLI). Son rapport de performance est directement corrélé au RGESN sur plusieurs points :

• Score Performance (Core Web Vitals) : LCP, FID/INP, CLS — corroborent les critères frontend et contenus
• Taille des assets : détection automatique des images non compressées, des scripts bloquants, du code inutilisé
• Opportunités : Lighthouse liste les optimisations concrètes avec leur impact estimé en ms de chargement

Lighthouse ne mesure pas directement l'empreinte carbone, mais ses recommandations d'optimisation de performance sont alignées avec les critères RGESN frontend (thématique 6) et contenus (thématique 5).

#WebPageTest

WebPageTest est l'outil le plus complet pour les audits approfondis. Il permet :

• De tester depuis des localisations géographiques réelles (simule la distance réseau)
• De simuler des connexions 3G/4G ou des terminaux mobiles d'entrée de gamme
• D'obtenir la waterfall chart complète (cascade des requêtes HTTP)
• De comparer deux versions d'un service (A/B testing de performance)

La cascade des requêtes de WebPageTest est particulièrement utile pour diagnostiquer les critères d'architecture (thématique 3) et backend (thématique 7) : elle visualise l'ordre de chargement des ressources, les requêtes bloquantes et les délais serveur (Time to First Byte).

#Qui est obligé d'appliquer le RGESN ?

#Obligations actuelles (post loi REEN 2021)

La loi REEN et ses décrets d'application créent des obligations différenciées selon la nature et la taille de l'organisation :

Services de l'État et établissements publics : obligation d'appliquer le RGESN pour tous les nouveaux services numériques en production depuis le 1er janvier 2024. Les services existants doivent être mis en conformité progressivement d'ici 2027.

Grandes entreprises (> 500 salariés, chiffre d'affaires > 1600 M€) : obligation de publier un bilan d'impact environnemental de leurs services numériques (loi REEN, article 25). Le RGESN est recommandé comme référentiel pour structurer ce bilan.

Opérateurs de communications électroniques : soumis à des obligations de reporting spécifiques auprès de l'ARCEP sur leur empreinte environnementale, y compris celle de leurs services numériques.

Services de communication au public en ligne (SCPEL) : toute plateforme ou application web accessible au public est encouragée à respecter le RGESN, même sans obligation légale directe. Certains appels d'offres publics l'exigent désormais comme critère de sélection.

#Horizon 2026-2028 : durcissement attendu

La transposition de la directive européenne sur l'éco-conception des produits durables (ESPR - Ecodesign for Sustainable Products Regulation) devrait introduire des exigences obligatoires pour les services logiciels et numériques commercialisés dans l'Union Européenne d'ici 2027-2028. Les entreprises qui auront déjà mené leur audit RGESN seront en position favorable pour y répondre.

#Calendrier d'application 2024-2026

Pour les organisations non directement soumises à la loi REEN, le RGESN constitue un avantage concurrentiel : les appels d'offres de collectivités territoriales et d'établissements publics mentionnent de plus en plus un critère d'éco-conception dans leurs cahiers des charges techniques.

#Impact concret sur les performances web et les Core Web Vitals

L'un des arguments les plus efficaces pour convaincre en interne d'initier un audit RGESN est la convergence avec les Core Web Vitals Google. Les optimisations qui améliorent le score EcoIndex améliorent simultanément le référencement naturel.

#Tableau de convergence RGESN ↔ Core Web Vitals

Ces gains ont un double effet : l'empreinte environnementale du service diminue et Google améliore le classement du site dans les résultats organiques. Le RGESN est ainsi l'un des rares référentiels où la contrainte réglementaire et l'intérêt commercial convergent.

#La méthodologie Nehos pour l'audit et la mise en conformité RGESN

Nehos a développé une méthodologie d'audit RGESN en quatre phases, déployée depuis 2024 auprès d'organisations publiques et privées.

#Phase 1 — Audit de maturité initial (5 jours)

Objectif : produire une photographie précise de l'état de conformité actuel du service numérique audité.

Méthodologie :

• Mesures automatisées avec EcoIndex (100 % des pages dans le top 20 trafic), Lighthouse (mode mobile, connexion simulée 4G lente) et WebPageTest (depuis Paris, terminal mobile Samsung Galaxy A52)
• Remplissage de la grille RGESN officielle thématique par thématique avec les équipes techniques
• Entretiens avec le responsable produit, le lead développeur et le responsable infrastructure
• Calcul du score de conformité : nombre de critères «Fait» / total des critères applicables

Livrable : rapport d'audit RGESN avec score par thématique, liste des non-conformités et estimation de l'impact environnemental actuel (kg CO₂/mois, consommation eau).

#Phase 2 — Priorisation et plan de remédiation (3 jours)

Objectif : classer les non-conformités selon la matrice impact environnemental × effort de correction.

Méthodologie :

• Scoring de chaque non-conformité : impact estimé sur EcoIndex (−Δ points) et Core Web Vitals (−Δ LCP en ms)
• Estimation de la charge de correction (en jours·développeur)
• Construction d'une feuille de route en trois vagues : Quick Wins (< 1 semaine), Medium Term (1 à 3 mois), Long Term (3 à 12 mois)

Livrable : feuille de route priorisée avec KPI cibles par vague.

#Phase 3 — Accompagnement à l'implémentation (durée variable)

Objectif : garantir que les correctifs sont effectivement déployés et mesurés.

Méthodologie :

• Revues de code hebdomadaires sur les Quick Wins
• Intégration des checks RGESN dans la CI/CD (Lighthouse CI en pipeline GitHub Actions)
• Mesures EcoIndex et Lighthouse avant/après chaque déploiement significatif

#Phase 4 — Rapport de conformité et attestation (2 jours)

Objectif : produire un document de conformité utilisable dans les réponses aux appels d'offres et les rapports RSE.

Livrable : rapport de conformité RGESN signé, avec score final, tableau de progression et méthodologie de mesure — conforme aux exigences de reporting de la loi REEN pour les grandes entreprises.

#Ce que révèlent systématiquement les audits terrain

Sur la vingtaine d'audits RGESN réalisés par Nehos depuis 2024, trois patterns reviennent de façon quasi-systématique, quel que soit le secteur ou la taille de l'organisation :

1. La thématique 6 (Frontend) est la plus défaillante : 80 % des organisations auditées ont un taux de conformité inférieur à 40 % sur la thématique frontend. Les coupables principaux : les scripts tiers accumulés sans inventaire, les bundles JavaScript surdimensionnés et l'absence de politique de cache navigateur.

2. La thématique 8 (Hébergement) est la moins instruite : la plupart des organisations ne connaissent pas le PUE de leur hébergeur ni la provenance de l'énergie utilisée. C'est paradoxalement l'un des leviers les plus impactants en termes de réduction carbone.

3. La thématique 1 (Stratégie) détermine la pérennité des gains : les organisations qui n'ont pas formalisé leur politique d'éco-conception voient leurs gains techniques se dégrader dans les 12 mois qui suivent l'audit, faute de maintien des pratiques dans les cycles de développement.

Ces constats guident directement les Quick Wins que nous priorisons dans chaque mission : corriger le frontend en premier pour les gains immédiats mesurables, qualifier l'hébergement pour les gains carbone structurels, et mettre en place la gouvernance stratégique pour garantir la durabilité des améliorations.