RGESN pour les développeurs, les critères front-end à appliquer (v2)

L'essentiel

• Le RGESN 2024 compte 78 critères en neuf thématiques, et seule une partie se joue dans le code.
• Il n'est pas obligatoire pour une entreprise privée, mais un site qui dit le respecter doit pouvoir le prouver.
• Côté front-end, les critères portent surtout sur les médias, les images, les polices, le cache et la compression.
• Une partie se vérifie à chaque déploiement dans la CI, le reste demande un travail de déclaration.

Si vous développez un site ou une application en France, vous avez sans doute déjà croisé le sigle RGESN dans un cahier des charges, une demande de client ou un article sur l’éco-conception. Ce guide s’adresse à celles et ceux qui écrivent le code. Nous y expliquons d’où vient ce référentiel, ce qu’il impose réellement (et c’est moins que ce qu’on lit parfois), puis, critère par critère, ce que les points qui touchent le front-end demandent concrètement dans un projet web.

Ce qu’est le RGESN, et qui l’a publié

Le RGESN est le Référentiel général d’écoconception de services numériques. Dans sa version 2024, il a été publié le 17 mai 2024 par l’Arcep et l’Arcom, avec l’ADEME, la DINUM et la CNIL, d’après le communiqué de l’Arcep. Le portail interministériel ecoresponsable.numerique.gouv.fr donne pour sa part le 28 mai 2024, et nous retenons la date du communiqué, puisque c’est la source la plus directe. Les listes de partenaires cités ne se recoupent pas non plus tout à fait d’une page à l’autre, donc nous ne les détaillons pas ici.

Sa base légale est l’article 25 de la loi du 15 novembre 2021, dite loi REEN. La version 2024 est la deuxième, la première datant de 2022 d’après une source secondaire, et c’est elle qu’on appelle parfois « RGESN v2 ». Le PDF officiel reste la référence si vous voulez le lire en entier.

Comment il est construit

La version 2024 compte 78 critères répartis en neuf thématiques, selon l’Arcep. On y trouve la stratégie, les spécifications, l’architecture, l’UX/UI, les contenus, le front-end, le back-end, l’hébergement et l’algorithmie. Chaque critère est formulé comme une question, du genre « le service numérique comporte-t-il uniquement des animations, vidéos et sons dont la lecture automatique est désactivée ? ».

Ce découpage compte pour un développeur, parce que seule une partie du référentiel se joue dans le code. Les premières thématiques (stratégie, spécifications, architecture) relèvent plutôt de la conduite de projet, et l’hébergement ou l’algorithmie dépendent souvent d’autres choix que ceux du développeur. Dans la pratique, le gros de ce qu’on peut faire depuis un éditeur de code se trouve dans l’UX/UI, les contenus et ce que le référentiel appelle le front-end. Pour les quatre premières thématiques, le portail compte 10 critères pour la stratégie, 10 pour les spécifications, 7 pour l’architecture et 15 pour l’UX/UI.

À qui il s’impose

La réponse demande un peu de nuance. Le RGESN lui-même est un document non contraignant, comme le précise le portail dans sa page sur la réglementation. Aucun texte ne dit à une entreprise privée « vous devez appliquer le RGESN sous peine d’amende », et celui qui cherche « RGESN obligatoire » trouvera plutôt un référentiel qu’on adopte par choix, ou parce qu’un client, une collectivité ou un appel d’offres le demande.

Il y a toutefois deux choses à garder en tête. La première, c’est que certaines structures publiques, les collectivités notamment, semblent avoir des obligations propres (une stratégie numérique responsable par exemple), dont le détail et les seuils ne sont pas confirmés par une page officielle (un seuil de population circule dans des sources secondaires, sans confirmation). Si vous travaillez pour une collectivité, il vaut mieux vérifier auprès d’elle ce qui s’applique à elle.

La seconde, c’est qu’une déclaration d’éco-conception est facultative, mais que toute communication publique qui se réfère au RGESN s’expose à une vérification. Dire « notre site respecte le RGESN » est donc une affirmation qu’il faut pouvoir appuyer, ce qui rejoint ce que nous expliquons dans notre guide sur la directive 2024/825 et les sites web.

Les critères qui touchent le front-end

Nous passons ici en revue les critères dont l’intitulé parle de choses qu’on contrôle dans le code ou dans la configuration des ressources. Chacun renvoie vers le critère officiel, et les numéros suivent la forme 4.8, 6.3, etc.

Médias, animations et polices

Le critère 4.1 demande que les animations, vidéos et sons n’aient pas de lecture automatique. Côté code, cela veut dire pas d’attribut autoplay sur un <video> ou un <audio>, et un lancement qui part d’une action de la personne qui visite la page.

<video controls preload="none" poster="/img/demo.webp" src="/media/demo.mp4"></video>

Dans la même zone, le 4.2 vise le défilement infini (on préfère une pagination ou un bouton « voir plus »), le 4.6 n’accepte que des vidéos, sons et animations qui portent une information, et le 4.7 demande de choisir entre texte, image, audio ou vidéo l’option la plus sobre selon le besoin. Un schéma en SVG ou une phrase suffit souvent là où on aurait mis une vidéo décorative.

Le critère 4.8 limite le nombre de polices téléchargées. En pratique, on garde une famille pour les titres et une pour le texte, avec les graisses dont on a besoin, et on les sert depuis son propre domaine plutôt que depuis un service tiers.

Requêtes, scripts tiers et composants

Le 4.4 demande que l’utilisateur décide de l’activation d’un service tiers (une carte, une vidéo intégrée, un widget de réseau social). On charge alors l’élément seulement après un clic, avec une image de remplacement en attendant. Le 4.9, que nous reformulons, cherche à éviter les requêtes client-serveur inutiles, comme une autocomplétion qui interroge le serveur à chaque touche, ou des scripts et polices tiers chargés sans raison. Un debounce de quelques centaines de millisecondes sur un champ de recherche règle déjà une bonne partie du problème.

Le 6.6, reformulé lui aussi, demande de prévenir et de recueillir le consentement avant d’activer un capteur de l’appareil, comme la géolocalisation.

Images

Trois critères parlent des images. Le 5.1 demande un format adapté au contenu et au contexte de chaque image (WebP ou AVIF pour une photo, SVG pour un logo). Le 5.2 porte sur un niveau de compression adapté pour les images matricielles, et le 6.4 veut que les dimensions d’origine correspondent à celles de l’affichage. C’est le cas typique d’une image de 3000 pixels de large affichée dans une colonne de 400 pixels, et srcset avec sizes permet au navigateur de prendre la bonne taille.

<img
    src="/img/photo-800.webp"
    srcset="/img/photo-400.webp 400w, /img/photo-800.webp 800w"
    sizes="(min-width: 60rem) 400px, 100vw"
    width="800"
    height="600"
    loading="lazy"
    alt=""
/>

Le 5.3 fait le même travail pour la définition des vidéos.

Poids, cache, compression et chargement

Le critère 6.1 demande de s’astreindre à un poids maximum et à une limite de requêtes par écran. C’est un budget, qu’on fixe en équipe et qu’on suit dans le temps. Le 6.2 concerne le cache des contenus transférés dont on a le contrôle, et on y répond avec un en-tête Cache-Control à longue durée sur les fichiers dont le nom change quand leur contenu change. Le 6.3 demande une compression des ressources, ce qui veut dire Brotli ou gzip activé sur le serveur pour le HTML, le CSS et le JavaScript.

Le 6.5 demande d’éviter de charger des ressources inutilisées pour chaque fonctionnalité, ce qui passe par loading="lazy" sur les images hors du premier écran, par le découpage du JavaScript par page, et par l’abandon des bibliothèques dont on n’utilise qu’une fonction. Enfin le 6.7 veut que les ressources statiques dont on est l’émetteur soient hébergées sur un même domaine.

Ce que Grammage vérifie, et à quel critère cela se rattache

Grammage ouvre une page dans un vrai navigateur et vérifie quinze règles de bonnes pratiques, dont neuf citent dans leur colonne de références l’un des huit critères du RGESN 2024 (la liste complète est dans l’analyse du code et dans la méthode). Quand le lien est net, voici ce que cela donne.

Règle vérifiée par Grammage	Critère RGESN	Ce que ça veut dire
text-compression	6.3	Au moins 95 % des octets de texte de plus de 1 Ko arrivent compressés en Brotli, gzip ou zstd.
static-cache	6.2	Chaque image, police, feuille de style, script ou média a une durée de cache.
image-resized	6.4	Aucune image matricielle n’est plus de deux fois plus large que son affichage.
image-lazy	6.5	Chaque image matricielle hors du premier écran porte loading="lazy".
font-families	4.8	Deux familles de polices téléchargées au plus.
no-autoplay	4.1	Aucune vidéo ni aucun son ne se lance tout seul.

Trois autres règles ne recouvrent qu’une partie du critère. image-formats (plus de trois images sur quatre en WebP ou en AVIF) se rattache au 5.1, qui demande un format adapté à chaque image et pas seulement ces deux-là. domains (cinq domaines au plus) se rattache au 6.7, qui est plus strict puisqu’il vise un seul domaine pour les statiques dont on est l’émetteur. Quant à no-infinite-animation, elle se rattache au 4.1 mais celui-ci vise la lecture automatique, pas les boucles en tant que telles. Les autres règles de Grammage (http2, redirects, http-errors, font-woff2, meta-description) n’ont pas de lien clair avec un critère, et nous ne leur en inventons pas.

Ce que Grammage ne vérifie pas

Grammage mesure des signaux techniques sur une page, il ne remplit pas un référentiel à votre place. Dans le périmètre front-end, il ne contrôle donc ni le défilement infini (4.2), ni l’activation des services tiers à la demande (4.4), ni la sobriété du choix entre texte, image, audio et vidéo (4.6 et 4.7), ni le niveau de compression des images (5.2), ni la définition des vidéos (5.3), ni le consentement avant l’usage d’un capteur (6.6). Le critère 4.9 n’est couvert qu’en partie, par la règle no-polling, que Grammage ne rattache pas formellement à ce critère. Pour le 6.1, il mesure bien le poids et le nombre de requêtes, mais il les compare à des repères et n’applique pas de plafond que vous auriez fixé.

Les thématiques de stratégie, de spécifications, d’architecture, de back-end, d’hébergement et d’algorithmie sortent de ce qu’une mesure de page peut dire. Une note de Grammage n’est donc pas une déclaration de conformité au RGESN, et elle ne remplace pas la déclaration d’éco-conception, qui porte sur le service tout entier. Elle donne en revanche des faits mesurés, à joindre à votre travail de réponse aux critères.

L’intégrer à une CI

L’intérêt d’un référentiel comme celui-ci, c’est qu’il ne se perde pas entre deux versions. Si on le vérifie une fois par an, une image oubliée ou un script ajouté en urgence suffit à défaire ce qui avait été gagné. On le branche donc plutôt sur le déploiement, comme on le ferait pour un test ou un linter.

Avec l’intégration CI/CD, Grammage audite le site en ligne et analyse son code source à chaque déploiement, puis il valide les scores d’éco-conception selon les critères fixés, ce qui permet de voir tout de suite quand une règle recule. Le format --format rgesn reprend les critères du RGESN que touchent les règles, sous la forme d’une aide à la déclaration. Pour savoir où vous en êtes avant de brancher quoi que ce soit, l’audit passe le site page par page et indique ce qu’il y a à corriger en premier. Et si vous voulez montrer le résultat à vos clients, l’attestation donne un résultat signé par Grammage, qui reste une mesure attestée et non une certification, puisque Grammage n’est pas un organisme accrédité.