RGESN, ce que doivent faire les designers

Le vendredi 17 mai 2024, la nouvelle version du référentiel général d'écoconception de services numériques (RGESN) a été publiée par l’ARCOM-ARCEP, tel que prévu par la loi REEN de 2021.

Comment mettre en place ce référentiel en tant que designer ? Par où commencer parmi les 78 règles ? A quelles bonnes pratiques penser à chaque étape du projet ?

Pourquoi cet article ?

Les critères UX/UI ne sont pas les seuls à concerner des prises de décision design. Certains autres critères plus transverses seront aussi de la responsabilité des Lead, Product ou UX/UI designers. Nous les intégrons donc dans notre sélection.

Lorsque l’on est pris dans son quotidien, cela peut être difficile de trouver le temps de s’approprier un nouveau référentiel. Nous avons donc classé les critères selon les phases de projet ou de sprint concernées. Ainsi vous pouvez ne vous concentrer que sur la sélection qui vous concerne à date.

Les critères du RGESN sont tournés de façon à être généraux et durables dans le temps. Par conséquent, ils sont indépendants d’un choix de technologie (web, application native, logiciel embarqué…) et de versions de logiciel ou de langages de code (non spécifiques à une version de navigateur par exemple). Cela peut donc les rendre difficilement intelligibles et c’est pourquoi nous vous proposons des recommandations pratiques pour l’écoconception de services web.

Quel taux viser ?

100 % bien sûr ! Mais cela peut être difficile à réaliser. Pour information, du côté des audits RGESN réalisés en 2022 par Temesis le meilleur taux de conformité obtenu jusque là est de 80% avec le site de l’ADEME.

La Dinum/Minum privilégie et soutient maintenant toute démarche qui atteindrait au moins le seuil de 70%. https://ecoresponsable.numerique.gouv.fr/posts/guichet-financement-ftap-numerique-ecoresponsable/

Certains appels d’offre publics exigent un taux de 65% minimum.

Ce que doivent faire les designers

A noter :

  • Chaque critère peut impliquer plusieurs tâches et plusieurs métiers. Seules les tâches des designers ont été retenues ci-dessous. Les remplir ne suffit pas nécessairement à valider le critère.
  • Un critère peut impliquer plusieurs tâches à différentes phases. Remplir l’une de ces tâches ne suffit pas à valider le critère.
  • Selon la taille de votre équipe et votre organisation, certaines de ces tâches tombent ou non sous la responsabilité des fonctions Design.

Sommaire :

  1. Recherche
  2. Cadrage design
  3. Prototypage
  4. Développement
  5. Tester et maintenir
  6. Ressources

1. Recherche

La recherche utilisateur fait intrinsèquement partie de l’écoconception comme le prouve l’intégration de plusieurs critères sur ce sujet. Selon les organisations et les sujets, ce terme peut recouvrir la recherche primaire, la phase de « Discovery », un début de Design Sprint, un sprint de recherche, une analyse de l’existant, une analyse de données d’audience…

Identifier l'utilité et la nécessité du service

La recherche utilisateur va dans un premier temps pouvoir venir nourrir la nécessité de prouver l'utilité du service d’un point de vue environnemental et/ou social. Les designers ayant effectué en amont de la recherche utilisateur peuvent ici nourrir l’argumentaire (ex : lutte contre la fracture numérique, accès à l’éducation, etc.) en détaillant les besoins réels justifiant la création du service et la nécessité des fonctionnalités. Les besoins utilisateurs pourront être intégrés dans les Objectifs de Développement Durable. [Critère 1.1]

Pour vous aider à savoir si votre service doit être développé, voir l’arbre de décision.

Nous rappelons que la création d’un service numérique a toujours un impact environnemental négatif, même éco-conçu, et que l’évaluation d’une valeur ajoutée significative pour la société est un pré-requis absolu à son développement. Le service créé doit prouver son utilité par rapport à des solutions analogiques alternatives ou numériques existantes. [Critère 1.2] Les benchmarks et veilles concurrentielles que les Product designers effectuent généralement pourront également alimenter ici l’analyse.

Définir les besoins réels de ses utilisateurs

  • Prioriser ses cibles utilisatrices entre primaires et secondaires. [Critère 1.2]
  • S’il y a un existant, effectuer : [Critère 1.2]
    • une analyse des données de suivi d’audience : repérer ce qui n’est jamais utilisé / visité, les allers-retours, les mots les plus cherchés du moteur de recherche…
    • une étude UX de l’expérience actuelle : identifier les stratégies de contournement développées, les difficultés rencontrées sur les parcours prioritaires, les principaux besoins non répondus…
    • une analyse des matériels utilisés : appareil, résolution, version du navigateur et du système d’exploitation… [en lien au Critère 2.1]
  • Réaliser des entretiens utilisateurs, des sondages ou observations auprès des utilisateurs pour relever leurs besoins. Penser à inclure des utilisateurs éloignés du numérique et en situation de handicap.
  • Créer des personas définissant leurs usages, leurs besoins, leurs comportements. NB : vous pouvez ajouter à leur profil les matériels utilisés, par exemple un persona pourrait être éloigné du numérique avec un smartphone de plus de 7 ans ou une connexion ADSL. [en lien avec les Critères 2.1 et 2.3]
  • Identifier les durées requises de conservation des contenus pour les utilisateurs : brouillons, posts, historique... [Critère 5.8]

Définir le produit cible

Définir les unités fonctionnelles et les fonctionnalités principales du service (nécessaire ultérieurement pour le Critère 4.3) : jobs-to-be-done, parcours principaux, fonctionnalités… Voir Unité fonctionnelle. A définir conjointement avec les PM et PO (alimentation du backlog et rédaction des user stories). 

En fonction des contextes d’usage et des profils matériels identifiés des utilisateurs, définir un poids maximum par écran. Le service doit être en effet utilisable en connexion bas débit. Par conséquent on pourra déterminer le poids maximum en se posant la question : en connexion dégradée (3G moyenne par exemple), en combien de secondes maximum ma page doit-elle charger ? (voir Guide) Pour rappel, près d'1/3 des connexions internet à domicile sont encore en ADSL en 2023 (source : Baromètre du numérique 2023). Selon la taille de l’équipe, le poids maximum peut être décidé conjointement avec d’autres métiers. [Critère 6.1]

De la même façon, il peut être intéressant que le Design soit impliqué dans le choix de la limite de requêtes par écran. En effet, cela va impacter le design car tout ce que le designer va venir ajouter sur sa maquette va impacter ce nombre : variations de police, images, plugins… L’impliquer dans cette décision permet de l’acculturer sur ce point technique et ses implications concrètes. [Critère 6.1]

Évaluer et mesurer

Dans le cadre d’un service existant, mesurer les indicateurs techniques des parcours identifiés : nombre de requêtes, poids des ressources téléchargées… Cela permettra de se positionner suite aux évolutions ou refonte à venir. Ce critère est une responsabilité qui peut incomber au référent écoconception ou encore aux profils Tech. [Critères 4.3, 6.1]

2. Cadrage design

En amont du prototypage, il est généralement nécessaire d’échanger avec un ou plusieurs profil(s) technique(s) (Lead Tech, front developer, architecte SI…) afin d’identifier ensemble la meilleure solution technique répondant aux besoins identifiés lors de la phase de recherche utilisateur.

Choisir les solutions techniques sobres

Pour un besoin donné, identifier quel composant répond le mieux au besoin et retenir celui avec l’empreinte environnementale la plus faible. Par exemple, selon le contexte, un annuaire plutôt qu’une carte interactive, des filtres plutôt qu’un moteur de recherche, 3 cartes plutôt qu’un carrousel… Cela nécessite un peu d’expérience et des échanges avec ses développeurs voire des tests de leur part pour identifier les bonnes pratiques. N’hésitez pas à lire des retours d’expérience en la matière et à partager les résultats de vos propres tests ! [Critère 2.9]

Les développeurs devront informer et aider les designers à choisir des composants Open Source et des technologies standard interopérables. Ces dernières viendront en effet directement impacter le Design System et les interfaces haute-fidélité. Par exemple, on privilégiera :

  • Un site web ou une progressive web app plutôt qu’une application native, 
  • Des composants natifs du système d’exploitation plutôt que des librairies personnalisées…)
  • Des animations possibles en CSS plutôt qu’en Javascript

Issu d’une réflexion entre les Lead Tech et le Design, les technologies ou composants les plus pertinents par rapport à l’expérience cible souhaitée ou aux wireframes seront retenus. Les contraintes technologiques seront intégrées en amont de l’UI plutôt que de demander des développements sur-mesure sur la base des interfaces créées. Ainsi on évite de développer une application native si une progressive web app peut suffire. [Critères 1.8, 1.9, 4.5]

Éviter de recourir à des capteurs des terminaux utilisateurs. [Critère 6.6] Par exemple :

  • géolocaliser l’utilisateur n’est pas forcément requis si une simple recherche par code postal est disponible ;
  • éviter d’utiliser la webcam pour la double authentification si le SMS peut suffire ;
  • privilégier l’écriture à l’usage du microphone.

Définir des dates d’expiration des contenus

Quoique ce soit généralement de la responsabilité du PO, PM ou encore des Tech de prendre en charge cette question, il arrive que seul le ou la designer soit à même de porter ce sujet : sur les petits projets (en tant qu’indépendant par exemple) ou encore si vous êtes la personne la plus experte en écoconception de votre équipe. En effet, mieux vaut fixer les règles de gestion en amont de la collecte des données. Par exemple si vous créez un espace de connexion, si vous permettez aux utilisateurs de créer des contenus, ou encore si vous migrez des articles de blog vers un nouveau site, c’est le moment de se poser les questions : combien de temps garde-t-on ces données ? quel process mettre en place pour se rappeler de les supprimer à expiration (si manuelle) ? est-ce qu’on les archive ou est-ce qu’on les supprime à terme ? La politique sera bien sûr à définir avec les profils techniques. [Critères 5.8, 7.2]

3. Prototypage

Généralement itératif, le prototypage peut aller du zoning à l’interface haute-fidélité cliquable en passant par l’étape du wireframe.

Bonnes pratiques globales

Prototyper ses écrans en mobile-first de préférence afin de s’assurer que le service soit responsive. Le service doit être intégralement affiché pour des écrans de 1200 px de large minimum. Il faut anticiper une ligne de flottaison à 720 px de haut maximum et donc s’assurer que le défilement vertical est possible au-delà ou que toutes les fonctionnalités de base soient accessibles au-dessus. [Critère 2.5]

Optimiser le parcours de navigation pour chaque fonctionnalité principale. Éliminer les fonctionnalités non essentielles. Voir le chapitre dédié dans le Guide d'écoconceptiond de services numériques [Critère 4.3]

Informer l’utilisateur sur l’impact environnemental de ses usages et lui permettre de réduire son empreinte par la mise à disposition d’un mode d’affichage ou d’usage « sobres » (ex : résolution plus faible des vidéos, affichage des images au clic, actualisation de la boîte de réception espacée…). [Critère 4.15]

Bannir les procédés manipulatoires ou darks patterns(compte à rebours sur une offre, option pré-cochée, parcours labyrinthiques…). Vous pouvez auditer vos wireframes pour vérifier que vous n’avez mis aucun dark pattern. Voir le Guide Concevoir sans Dark Patterns [Critère 4.14]

Sur les interfaces

Animations, vidéos, sons
  • Bannir les fonds vidéo et/ou audio. [Critère 4.1]
  • Privilégier le texte ou l’image au lieu de l’animation, la vidéo ou le son lorsque cela est possible. Choisir la solution au besoin utilisateur la plus sobre possible (texte plutôt qu’image, animation plutôt que vidéo par exemple). [Critère 4.7]
  • N’utiliser que des vidéos, audios et animations porteurs d’information (bannir leur utilisation décorative). Ainsi leur utilisation n’est autorisée que si leur utilisation est requise par les fonctions critiques du service. [Critère 4.6] 
  • En cas d’animation, vidéo ou son, désactiver la lecture automatique par défaut. Si cela n’est vraiment pas possible, permettre à l’utilisateur d’annuler la lecture automatique facilement. Éviter les carrousels automatiques, les parallaxes, les gifs, les boutons qui bougent ou clignotent, et autres animations décoratives non contrôlables… [Critère 4.1]
  • Proposer un mode « écoute seule » pour les vidéos. [Critère 5.5]
Interactions
  • Bannir le défilement ou scroll infini en privilégiant du chargement progressif (bouton « voir plus » par exemple). [Critère 4.2] 
  • Indiquer à l’utilisateur lorsqu’une fonctionnalité à des impacts environnementaux importants (ex : visionnage d’une vidéo en haute définition, export d’un grand volume de données, recherche sur une grande base…). Si des équivalences en impacts environnementaux sont citées par exemple, citer les sources et la méthodologie de calcul. [Critère 4.12]
  • Limiter le recours aux notifications et permettre à l’utilisateur de les contrôler : de les désactiver de façon simple et rapide, de choisir leur fréquence de réception... Elles doivent être dans l’intérêt de l’utilisateur. Se fixer des quantités et fréquences maximales de notifications (ex : 5 par jour maximum) et les suivre. [Critère 4.13] Voir la section Interactions du Guide d'écoconception de services numériques.
  • Informer l’utilisateur lorsqu’un traitement est en cours en arrière-plan : sinon il risque de relancer l’action et de générer des requêtes superflues. Rendre indisponible l'action qui génère le traitement (par exemple un bouton de soumission de formulaire) et informer l'utilisateur que le traitement est en cours, éventuellement en affichant une durée approximative de traitement.
Documents
  • Informer l’utilisateur sur le format et poids de fichier avant transfert ou téléchargement. Limiter le poids des fichiers uploadés : par exemple à 300 Mo une photo mise en ligne. [Critère 4.11]
  • Proposer un format de fichier adapté à son contenu et au contexte d’utilisation : privilégier les formats les plus légers, éviter par exemple un pdf vertical si le document sera principalement consulté sur écran d’ordinateur en format paysage, un pdf HD destiné à l’impression s’il sera consulté principalement en ligne (résolution 72 dpi recommandée)... [Critère 5.7]
Polices
  • Privilégier les polices nativement disponibles dans le système d’exploitation (polices système). [Critère 4.8]
  • Limiter le nombre de polices à 4 variantes maximum au total ou 400 Ko. [Critère 4.8]Réduire la taille des polices téléchargées (supprimer les glyphes non utilisés, compresser les fichiers…). NB : une police bien compressée en WOFF2 ne pèse que 30 Ko environ. [Critère 4.8]
Plugins, widgets et services tiers

Choisir des composants légers et éco-conçus pour répondre au besoin et éviter au maximum de recourir à des service-tiers (carte interactive, lecteur vidéo, plugins de réseaux sociaux, captcha…). Prototyper des solutions natives ou éco-conçues à la place. Par exemple :

  • si l’incrustation d’une vidéo est nécessaire, privilégier un lecteur vidéo HTML5 plutôt que le plugin Youtube ; 
  • remplacer les plugins des réseaux sociaux par des icones cliquables ;
  • éviter les captchas ;
  • pour un moteur de recherche, prototyper la génération de résultats au lancement de la recherche par l’utilisateur plutôt qu’une mise à jour automatique des résultats à chaque filtre ajouté.

Ces choix de conception nécessitant une certaine connaissance technique et en écoconception : échanger avec les développeurs ou le référent écoconception sur la meilleure façon de répondre au besoin pour valider ce critère. Si cela n’est pas possible, choisir les services les plus éco-conçus possibles. [Critères 2.9, 2.10]

Permettre à l’utilisateur de décider de l’activation d’un service tiers non nécessaire et donc ne charger que ce à quoi il a explicitement consenti (ex : lecteurs vidéo collectant les cookies désactivés en cas de refus de collecte des données personnelles). [Critère 4.4]

Formulaires
  • Limiter les requêtes serveur lors de la saisie utilisateur : éviter l’auto-complétion, les résultats suggérés… [Critère 4.9]
  • Si sa mise en place est justifiée, attendre d'avoir 3 caractères et 500 ms après chaque saisie avant de lancer une requête réseau. [Critère 4.9]
  • Permettre d’activer et désactiver l’auto-complétion. [Critère 4.9]Informer l’utilisateur du format de saisie attendu avant sa validation et indiquer les erreurs de saisie avant soumission du formulaire. [Critère 4.10]

Revue design

Faire une revue de conception avant de développer : présenter les interfaces prototypées aux développeurs et réfléchir aux choix de conception et d'architecture avec toute l’équipe, en ayant pour un des objectifs la minimisation des impacts environnementaux. Choisir la solution répondant aux besoins minimisant le plus les impacts environnementaux. [Critère 2.6]

4. Développement

Selon les projets, les designers peuvent être amenés à alimenter les développeurs en contenu et à faire du design d’interaction sur cette phase.

Images

Choisir le format d’image adapté au contenu et au contexte de visualisation de chaque image : utiliser le format vectoriel comme le SVG lorsque cela est possible (illustrations, icones, logos, graphes...), le format WebP, AVIF ou JPEG XL pour des photos et le format WebP ou JPEG XL pour des illustrations avec aplats de couleurs. 

Attention : si vous choisissez le format AVIF ou JPEG XL, le service numérique devra encoder ses images dans un deuxième format afin de prendre en charge les navigateurs web qui ne supportent pas encore ces formats (fallback en JPEG / PNG ou WebP). [Critère 5.1]

Compresser les images en fonction du contenu et au contexte de visualisation. On estime qu’un JPEG peut être compressé de 70% tout en restant visiuellement acceptable. [Critère 5.2]

Il est possible de servir différentes tailles d’image en fonction de la résolution du terminal utilisateur, notamment dans le cas d’images fluides, grâce à des attributs « srcset » et « sizes » mais il faut toutefois faire attention que le site reste responsive. [Critères 5.2, 6.4]

Animations, vidéos et son

Adapter la définition des vidéos au contenu et au contexte de visualisation. Idéalement proposer différentes résolutions en fonction de la résolution du terminal utilisateur (par exemple 720p maximum sur smartphone et choix sobre à 420p). Si cela n’est possible, choisir la définition la plus basse possible sans gêner l’utilisateur. [Critère 5.3]

Permettre de mettre en pause les animations essentielles. « Lorsque l’animation visuelle a une durée de plus de 4 secondes ou qu’un son a une durée de plus de 2 secondes, doter systématiquement l’objet multimédia des moyens de contrôle nécessaires : démarrage, arrêt, muet ou volume. Permettre de les désactiver simplement dès lors que ces contenus dépassent 4 secondes et minimiser leur taille (voir critères 5.3, 5.4. et 5.5). » [Critère 4.1]

5. Tester et maintenir

Selon la taille des services, les designers peuvent être amenés à recetter et tester le service.

Tester en pré-prod

S’assurer que le service est utilisable sur une connexion bas débit (3G en mobilité et 512 Kbs en fixe). Les designers peuvent facilement effectuer ce test qui recoupe des enjeux environnementaux, sociaux et d’expérience utilisateur. [Critère 2.3]

S’assurer que le service est bien responsive (par exemple avec les outils de développement du navigateur). Tester notamment sur des résolutions de vieux smartphones (320 px de large). [Critère 2.5]

Remplir les formulaires avec des données erronées et s’assurer que les messages d’erreur soient explicites. [Critère 4.10]

Tester, y compris périodiquement, la lecture des vidéos sur différents terminaux afin de vérifier que ces vidéos en mode « qualité standard » et « sobriété énergétique » ont un format adapté à ces terminaux. [Critère 5.3]

Effectuer des tests utilisateurs avec des personnes éloignées du numérique (appareils anciens, connexion bas-débit, navigateurs non mis à jour…) et s’assurer qu’elles parviennent à finir leur parcours. [Critères 2.2, 2.3, 2.4]

Amélioration continue

Ne collecter que les données de navigation nécessaires à l’analyse de l’expérience utilisateur. Quoique certains outils soient extrêmement puissants et instructifs en matière de suivi, ils collectent potentiellement automatiquement plus de données que nécessaire (ex : enregistrements complets de parcours que l’on peut rejouer). Il incombera notamment aux CDO ou Lead Designers d’estimer quels outils sont pertinents ou de les paramétrer pour ne collecter que le minimum requis. Dans certains cas, quelques simples cookies peuvent permettre de se passer d’un outil de suivi d’audience. [Critères 1.5, 2.10]

Mesurer le temps passé par l’utilisateur pour effectuer une action et le minimiser le plus possible. Identifier les fonctionnalités utilisées ou non. Améliorer en continu les parcours utilisateurs correspondant aux unités fonctionnelles du service par de la recherche utilisateur et l’analyse du suivi d’audience. Poursuivre la recherche utilisateur : tri de carte, sondage, interviews, enquêtes utilisateurs, tests-U, etc. [Critère 4.3]

Identifier les pages / fonctionnalités peu utilisées et étudier leur potentiel décommissionnement. Grâce aux outils d’analyse de la navigation et la connaissance des besoins utilisateurs, identifier si des parties du service peuvent être arrêtées. [Critère 2.7]

Réaliser des revues régulières d’écoconception : audits de performance, auto-évaluation RGESN, identification des points de friction dans le parcours utilisateur... La régularité dépend du service mais devra survenir au moins à chaque « changement significatif » du service. Le designer peut être appelé à contribuer sur ce critère. [Critère 1.4]

Guide d'écoconception de services numériques

Pour vous aider à mettre en place l'écoconception sur vos projets, nous avons écrit un guide complet étape par étape listant et illustrant les bonnes pratiques pour les designers.