Sortie du Référentiel Général d’Ecoconception de Services Numériques de l’ARCEP : un document à connaître.

La loi REEN du 15 novembre 2021 prévoyait que l’ADEME, l’ARCEP et l’ARCOM construiraient et mettraient à disposition un Référentiel Général d’écoconception de Services Numériques (RGESN). La version finale de celui-ci est sortie ce vendredi 17 mai. C’est l’ARCEP qui a mené le travail.

Ce document a pour but de rassembler des pratiques et des questionnements afin de permettre aux équipes de création d’éco concevoir leurs services numériques. Il existait déjà plusieurs compilations de ce type, notamment le référentiel d’écoconception web de Green IT (les 115 bonnes pratiques), le GR 491 de l’INR ou encore le RGESN de la DiNum. Le référentiel de l’ARCEP a pour point différenciant d’avoir été créé suite à une loi. Il s’agit d’une mise à jour majeure du référentiel de la DiNum, dont on retrouve certaines parties.

Dans le cadre de la rédaction de ce document, une consultation publique a été réalisée et de nombreux acteurs ont pu relire une première version du RGESN et partager leurs commentaires. J’ai eu le privilège d’en faire partie, avec d’autres membres du collectif Green IT.

Un point important à noter est que, bien que commandé par un travail législatif, le RGESN ne se veut pas opposable, dans le sens où tester une conformité de façon « binaire » serait possible. Il ne sera pas possible de dire qu’un service numérique est « conforme » ou « non conforme » au référentiel.  L’ARCEP le présente comme  une « base de connaissances et recommandations commune permettant d’accompagner les démarches volontaires d’écoconception » et comme un « Outil d’action et de sensibilisation ». Cela contraste avec d‘autres documents comme le RGAA ou les recommandations de la CNIL, où il est possible de dire qu’un site n’est pas accessible ou bien qu’il ne respecte pas la loi. Elle est cependant tout à fait compréhensible dans la mesure où des critères absolus sont difficiles à établir dans le cas présent.

Le référentiel se veut général, applicable à tous les services numériques. Pourtant, les contraintes d’un firmware d’objet connecté, du site vitrine d’un restaurant, d’une application mobile de jeu d’échecs ou encore d’un modèle de machine learning pour une assurance sont très différentes. Une approche pragmatique serait de créer plusieurs référentiels, ou bien des « sous référentiels » plus contextualisés. Nous avions fait cette suggestion en octobre lors de notre relecture. Le document final est resté général mais stipule qu’il « ne fait pas obstacle à l’existence de documents d’écoconception complémentaires, plus exhaustifs ou spécifiques à certaines catégories de produits ou services numériques » et « vise à créer un socle commun pouvant être décliné selon les spécificités du service numérique conçu ou évalué ».

Une formule est donnée pour estimer la maturité de l’équipe : une simple somme des critères validés divisés par la somme des critères applicables, avec une pondération par priorité. Pour se prévaloir publiquement du l’utilisation du RGESN il faut mettre à disposition une déclaration d’écoconception contenant ce score, les critères validés ou encore le plan d’avancement. Des modèles sont fournis sous différents formats.

Le référentiel final comprend 78 critères répartis en 9 catégories (Stratégie, Spécifications, Architecture, UX/UI, Contenus, Frontend, Backend, Hébergement, Algorithmie). Chacun de ces critères est détaillé dans une fiche. Celui-ci contient un titre, une description, des niveaux de difficultés et de priorité, ou encore les métiers concernés (Développeur, Concepteur UX / UI, Responsable Produit, …). Des moyens de tests ou de contrôle sont fournis pour s’assurer de la mise en œuvre de la pratique. Ainsi dans la plupart des cas, des objectifs chiffrés sont encouragés.

Beaucoup des critères présentés sont génériques, c’est à dire applicables à tous les services numériques, (exemple : « Le service numérique a-t-il défini la liste des profils de matériels que les utilisateurs vont pouvoir employer pour y accéder ? ») mais certains sont spécifiques à un type d’implémentation. Souvent le contexte d’une application Web apparaît en filigrane comme référence (avec des mentions de requêtes, d’HTTP, etc.). Il y a aussi des critères focalisés sur la blockchain (« Le service numérique s’appuie-t-il sur un mécanisme de consensus qui minimise sa consommation de ressources ? ») et sur le Machine Learning (toute la section algorithmie) qui ne seront pas applicables dans beaucoup de cas.

Les points importants de l’écoconception de services numériques sont bien sûr et sans surprise, présents dans les critères de ce RGESN : assurer la compatibilité avec les appareils et logiciels « anciens », réduire la consommation de ressources numériques, bien choisir ses technologies, ne pas utiliser de dark pattern UX,  ne pas collecter plus de données que nécessaire, supprimer les donnés non utilisées, optimiser les fichiers multimédias, utiliser des infrastructures élastiques pour coller à la charge, etc.

De même, les critères explicitent bien qu’il faut partir du besoin, valider la pertinence du service ou de la fonctionnalité à partir des demandes des utilisateurs mais aussi au regard des limites planétaires, des objectifs de développement durable et dans le contexte des engagements RSE de l’entreprise. Les partenaires (fournisseurs, sous traitants, services tiers) ne sont pas oubliés.

Quelques-uns ne sont pas directement de l’écoconception mais plutôt des points d’organisation d’entreprise et/ou de gestion de projet. Par exemple, « Le service numérique réalise-t-il régulièrement des revues pour s’assurer du respect de sa démarche d’écoconception ? », qui est un moyen de valider les critères plus qu’un critère d’écoconception. Ou encore « Le service numérique a-t-il au moins un référent identifié en écoconception numérique ? » qui traite de l’organisation de l’équipe et qui n’est pas nécessaire ni suffisant. 

Il y a aussi quelques imperfections. Des pratiques pourraient être regroupées, comme la prise en compte des PUE et WUE qui est répartie sur deux critères. D’autres, qui contiennent deux règles assez différentes, comme le critère « Le service numérique s’astreint-il à un poids maximum et une limite de requêtes par écran ? » qui inclut les réponses d’API, ce qui a du sens pour le poids mais pas pour le nombre de requêtes. Il est probable que des mises à jour ultérieures corrigent ces problèmes. Certains points pourront aussi mener à des discussions, comme l’encouragement des énergies renouvelables ou la limitation du niveau de chiffrement.

Ce document ayant pour vocation de devenir une référence dans les projets de services numériques, vous le verrez certainement apparaître dans vos entreprises prochainement. En prendre connaissance dès maintenant vous donnera un avantage !

Notons qu’une version anglaise est déjà disponible. Il est donc possible d’utiliser ce travail dans des projets internationaux. Cet effort d’internationalisation est une excellente chose, cela permettra de diffuser plus facilement les actions et pratiques de l’écoconception de services numériques en Europe et dans le monde.