L’écoconception d’un service numérique consiste à réduire son empreinte environnementale dès sa conception, sur tout son cycle de vie. En France, la référence est le RGESN, publié en mai 2024 par l’Arcep et l’Arcom avec l’ADEME : 78 critères répartis en 9 thématiques, de la stratégie à l’hébergement. Il n’est pas obligatoire, mais il fournit une grille commune, un score d’avancement et un modèle de déclaration publique. Pour une application métier, son apport principal est simple : concevoir un outil utile, léger et durable, qui fonctionne bien sur du matériel ancien.
Ce guide traduit le référentiel en décisions concrètes pour une PME ou une ETI qui fait développer une application web.
Qu’est-ce que le RGESN, et d’où vient-il ?
Le référentiel général de l’écoconception des services numériques découle de l’article 25 de la loi du 15 novembre 2021 visant à réduire l’empreinte environnementale du numérique en France, dite loi REEN. Elle confie à l’Arcep et à l’Arcom, en lien avec l’ADEME, la définition de critères de conception durable des services numériques. La DINUM, la CNIL et l’Inria ont également contribué au texte, publié le 17 mai 2024.
Son périmètre est large : sites web, API, applications installées ou en mode SaaS, plateformes vidéo, outils reposant sur l’intelligence artificielle. Selon la nature du service, certains critères sont simplement non applicables.
Le référentiel poursuit quatre objectifs, détaillés dans le document officiel :
- allonger la durée de vie des terminaux, en rendant les services utilisables sur des équipements anciens ;
- limiter les stratégies de captation de l’attention (défilement infini, lecture automatique, notifications intempestives) ;
- diminuer les ressources mobilisées sur tout le cycle de vie, y compris le trafic de données et la sollicitation des serveurs ;
- accroître la transparence sur l’empreinte environnementale du service.
Pourquoi une PME ou une ETI devrait-elle s’y intéresser ?
Le RGESN rappelle, en citant l’étude ADEME-Arcep, que le numérique représente 2,5 % de l’empreinte carbone de la France, et que les terminaux, en particulier leur fabrication, en constituent la majeure partie : 65 % à 90 % de l’empreinte environnementale du numérique selon le référentiel. Autrement dit, le levier principal n’est pas le serveur, mais l’ordinateur ou le smartphone que l’on renouvelle trop tôt parce qu’une application devient trop lourde.
Pour une entreprise, l’intérêt dépasse l’environnement :
- Durée de vie du parc : une application qui reste fluide sur des postes et des téléphones de quelques années évite des renouvellements forcés.
- Usage terrain : un outil léger fonctionne mieux en zone mal couverte, sur un chantier ou dans un entrepôt.
- Coûts d’exploitation : moins de données transférées et stockées, c’est un hébergement plus sobre.
- Appels d’offres : un donneur d’ordre ou un acheteur public peut intégrer des critères de sobriété numérique à sa consultation ; une démarche documentée devient alors un argument.
- Qualité : l’écoconception rejoint la performance et l’accessibilité. Les mêmes choix servent les trois.
Les 9 thématiques appliquées à une application métier
Les critères suivent les étapes du cycle de vie d’un service. Voici, pour chaque thématique, des exemples de critères du RGESN et leur traduction concrète dans un projet d’application métier.
| Thématique | Exemple de critère du RGESN | Traduction dans une application métier |
|---|---|---|
| Stratégie | 1.1 Le service a-t-il été évalué favorablement en termes d’utilité ? | Chaque fonctionnalité répond à un besoin observé, pas à une envie |
| Spécifications | 2.2 Le service est-il utilisable sur d’anciens modèles de terminaux ? | Tester sur les postes et téléphones réellement utilisés par les équipes |
| Architecture | 3.2 L’architecture adapte-t-elle les ressources à l’usage ? | Serveurs dimensionnés selon la charge réelle, extinction des environnements de test la nuit |
| UX / UI | 4.2 Le service affiche-t-il des contenus sans défilement infini ? | Listes paginées et filtres efficaces plutôt que chargement continu |
| Contenus | 5.3 Chaque vidéo a-t-elle une définition adaptée ? | Tutoriels vidéo courts, en définition raisonnable, sans lecture automatique |
| Frontend | 6.1 Le service s’astreint-il à un poids maximum et une limite de requêtes par écran ? | Budget de poids par écran suivi à chaque livraison |
| Backend | 7.1 Le service a-t-il recours à un cache serveur pour les données les plus utilisées ? | Tableaux de bord et calculs lourds mis en cache au lieu d’être recalculés à chaque affichage |
| Hébergement | 8.3 L’hébergement minimise-t-il son PUE ? | Hébergeur transparent sur son efficacité énergétique |
| Algorithmie | 9.1 La nécessité d’une phase d’entraînement a-t-elle été interrogée ? | Utiliser un modèle d’IA existant plutôt qu’en entraîner un, si cela suffit |
Le critère 6.1 donne un ordre de grandeur parlant : pour une page web de 2 Mo, viser 1 Mo ; pour un site, moins de 30 requêtes par page plutôt que 100. Ces exemples ne sont pas des seuils réglementaires, mais ils fixent une ambition mesurable.
Par quels critères commencer ?
Le référentiel classe ses critères en trois niveaux de priorité : 30 « Prioritaire », 28 « Recommandé » et 20 « Modéré ». Les critères prioritaires sont ceux qui ont une portée systémique ou qui agissent sur les terminaux. Pour une application métier, cinq d’entre eux font l’essentiel du chemin :
- Utilité (1.1) et cibles (1.2) : définir précisément les utilisateurs, leurs besoins réels et renoncer aux fonctionnalités qui n’y répondent pas. C’est la logique du MVP.
- Objectifs de réduction (1.5) et revues régulières (1.4) : fixer quelques indicateurs (poids des écrans, nombre de requêtes, volume stocké) et les suivre.
- Terminaux anciens (2.2) et anciennes versions de navigateur (2.4) : définir une liste de matériels cibles et tester dessus.
- Maintenance et décommissionnement (2.7) : prévoir dès le départ comment l’application sera maintenue, puis retirée, avec ses données.
- Hébergement responsable (8.1 à 8.3) : choisir un hébergeur qui documente sa démarche, sa gestion du matériel et son efficacité énergétique, sujet développé dans notre article sur l’hébergement des applications métier.
Les critères d’algorithmie, presque tous classés prioritaires, deviennent centraux dès qu’une fonctionnalité d’IA est envisagée. Bien souvent, la solution la plus sobre est aussi la moins coûteuse à l’usage, ce que nous détaillons dans notre article sur la maîtrise des coûts de l’IA.
Score d’avancement et déclaration d’écoconception
Le RGESN propose deux outils pour piloter et communiquer.
Le score d’avancement mesure la maturité de la démarche. Chaque critère applicable validé rapporte des points pondérés : 1,5 pour un critère prioritaire, 1,25 pour un critère recommandé, 1 pour un critère modéré. Le score est le rapport entre les points obtenus et le total des points applicables, multiplié par 100. Le référentiel précise deux règles importantes : un critère partiellement validé n’est pas validé, et les critères marqués « applicables à tous les services » ne peuvent pas être déclarés non applicables.
La déclaration d’écoconception est un document public, daté et régulièrement mis à jour, idéalement à chaque évolution significative. Elle liste les critères validés et non validés, le score actuel et visé, le plan d’action et les parcours évalués. Sa publication est un prérequis pour se prévaloir du référentiel. Elle peut figurer à côté de la déclaration d’accessibilité. Un modèle et un tableur d’autoévaluation sont proposés sur le site de la mission interministérielle numérique écoresponsable.
Attention à la communication : le référentiel rappelle que toute allégation fondée sur son application doit respecter le cadre des allégations environnementales, c’est-à-dire être fiable, transparente et vérifiable. Le score n’est pas une mesure d’impact : présenter une application comme « verte » sur la seule base de ce score serait trompeur.
Les bonnes pratiques qui changent vraiment la donne
Au-delà de la grille, certaines décisions pèsent beaucoup plus que d’autres dans une application de gestion.
- Supprimer plutôt qu’optimiser. Une fonctionnalité non développée ne consomme rien. Les ateliers de cadrage sont le meilleur moment pour l’écoconception.
- Des parcours courts. Moins d’écrans pour accomplir une tâche, c’est moins de requêtes et moins de temps passé, un objectif partagé avec l’UX des applications métier.
- Paginer, filtrer, ne pas tout charger. Les listes de plusieurs milliers de lignes chargées d’un coup pèsent lourd pour un usage rare.
- Séparer données chaudes et froides (critère 8.8) et fixer des durées de conservation (critère 7.2) : archiver ce qui n’est plus consulté sur un stockage moins sollicité, et supprimer ce qui n’a plus à être conservé.
- Limiter les services tiers : chaque outil de mesure d’audience, police de caractères ou script externe ajoute du poids et des requêtes.
- Fonctionner en connexion dégradée (critère 2.3) : une application web progressive peut continuer à fonctionner hors ligne et synchroniser plus tard.
- Mesurer à chaque livraison : poids et nombre de requêtes des écrans principaux, intégrés aux contrôles automatiques, pour éviter la dérive.
Comment lancer la démarche sur votre projet
Pour une nouvelle application, intégrez une dizaine de critères prioritaires au cahier des charges, définissez les terminaux cibles et un budget de poids par écran, puis vérifiez-les à chaque démonstration de sprint. Pour une application existante, commencez par une autoévaluation avec le tableur officiel sur deux ou trois parcours critiques : elle révèle en général quelques gains rapides (images, scripts tiers, listes non paginées) et des chantiers plus structurels à planifier.
Vous souhaitez concevoir une application sobre dès le départ ou évaluer celle que vous utilisez déjà ? Décrivez votre projet dans notre diagnostic en ligne, nous intégrerons ces critères à notre analyse.
