Référentiel général de l’écoconception des services numériques

Niveau de difficulté : Fort
Niveau de priorité : Prioritaire
Applicable à tous les services
Métiers concernés : Porteur de projet, Responsable RSE/Numérique soutenable

Objectif

Prendre en compte l’utilité du service numérique dès sa conception et son inscription dans au moins l’un des objectifs de développement durable (ODD), l’un des enjeux de limites planétaires ou tout autre référentiel du même type.

Mise en œuvre

Il s’agit de déterminer en amont du projet si l’utilité du service est avérée. Pour l’évaluer, se référer à des référentiels, en particulier :

• Les 17 objectifs de développement durable (ODD) de l’ONU ;
• Les 9 limites planétaires ;
• La Taxonomie européenne sur les activités vertes ;
• La directive CSRD – Corporate Sustainability Reporting Directive ;
• Les normes ISO, en particulier ISO 26000 (non certifiable) ;
• Global Reporting Initiative.

Si l’utilité du service ne s’inscrit pas dans ces référentiels, justifier en quoi le service est utile, participe à l’intérêt général ou est en appui d’une politique publique. Cette analyse devra prendre en compte les bénéfices attendus de la solution numérique évaluée par rapport à une solution alternative, et les risques d’effets rebond le cas échéant.

Vérifier par exemple un ou plusieurs de ces points : la pertinence du service, son utilité, sa création de valeur, son bien-fondé, son service pour l’intérêt général, sa réponse à des besoins essentiels, sa participation à la mise en place de communs numériques, etc.

Il convient d’afficher dans la déclaration d’écoconception les ODD dans lequel le service s’inscrit.

Moyen de test ou de contrôle

Afficher dans la déclaration d’écoconception du service numérique comment a été évalué le service, par exemple dans quels objectifs de développement durable il s’inscrit, quelles sont les réponses apportées aux enjeux de limites planétaires ou autre référentiel utilisé (préciser lequel), et leur pertinence.

Un service numérique valide ce critère s’il fait l’objet d’une étude visant à évaluer et justifier les impacts environnementaux et sociaux.

Le rapport comprendra a minima une réponse aux questions suivantes (source : Designers Éthiques) :

• L’utilisation du numérique pour ce service est-elle nécessaire ?
• Existe-t-il d’autres solutions non numériques pour répondre à ce besoin ?
• Quels sont les réels besoins justifiant la création du service ?
• La valeur ajoutée du service justifie-t-elle la mobilisation des ressources requises pour sa création ? Est-ce qu’on crée plus de valeur qu’on en détruit ?
• Pour chaque fonctionnalité, est-elle vraiment nécessaire ? Peut-on faire autrement ?
• Que se passerait-il si on ne l’avait pas ?

Par ailleurs, cette étude devrait inclure une analyse qualitative des impacts environnementaux directs et indirects potentiels liés au service, qui se traduira par la réalisation d’un arbre de conséquences suivant la méthode Empreinte Projet niveau 1 de l’ADEME.

Niveau de difficulté : Faible

Niveau de priorité : Prioritaire

Applicable à tous les services

Métiers concernés : Porteur de projet, Chef de produit marketing

Objectif

Pour répondre au plus juste aux utilisateurs du service numérique, il est indispensable de connaître ses cibles : leurs usages, leurs besoins et leurs comportements, afin de ne pas surcharger les services numériques en fonctionnalités et contenus, ni les appauvrir au point qu’ils ne répondent pas aux attentes. Sans l’identification des catégories d’utilisateurs primaires et secondaires, il est difficile de dimensionner correctement le service numérique.

Les incertitudes poussent à extrapoler les besoins souvent au-delà des attentes réelles. On peut également ne pas répondre aux « bons besoins » parce que l’on connaît mal ses utilisateurs ou l’on répond juste à ce que demande le commanditaire. Tout cela finit par être un mauvais investissement de ressources, de temps passé et des impacts environnementaux générés. Il faut éviter toute fonctionnalité non essentielle. D’autre part, il est important de vérifier qu’un ou plusieurs services existants répondent déjà au besoin, pour ne pas les dupliquer.

Mise en œuvre

Pour la définition des cibles utilisatrices, il faut mobiliser les outils et composants de la phase de recherche UX (UX research) : étude concurrentielle, analyse de l’existant, définition des personas, réalisation d’entretiens ou de sondages avec les utilisateurs, observation, etc.

Concernant l’identification des besoins métiers et des attentes réelles des utilisateurs-cibles, les étapes suivantes pourront être suivies :

• Entretiens avec les différentes parties prenantes et les métiers concernés ;
• Recherche UX auprès des utilisateurs ciblés ;
• Définir les utilisateurs primaires et secondaires ;
• Pratique alliée : les approches agiles ;
• Observation des statistiques d’usages dans le cas d’un service déjà existant.

Moyen de test ou de contrôle

Donner accès à ces documents de référence de la phase de recherche : entretiens utilisateurs, étude UX, benchmark, personas, étude marketing, etc., permettant de définir précisément les utilisateurs-cibles. Sur la base de ces éléments, des recherches, observations, sondages ou autres devraient également être accessibles, permettant de définir précisément l’expression de besoins métiers ou les attentes réelles des utilisateurs ciblés.

Pour valider ce critère, le profil des cibles utilisatrices ainsi que l’analyse des besoins métiers et des attentes des utilisateurs devraient être clairement renseignés dans la déclaration d’écoconception du service numérique ainsi que les choix effectués en ce sens.

Niveau de difficulté : Fort

Niveau de priorité : Prioritaire

Applicable à tous les services

Métiers concernés : Responsable RSE/Numérique soutenable, Porteur de projet

Objectif

Connaître et réduire l’empreinte environnementale du service numérique. Cela implique d’avoir une vision globale des conséquences du service numérique, à chaque phase (début, usage, fin) et en intégrant les impacts environnementaux des équipements matériels utilisés, dans la production mais aussi dans l’usage de ce service numérique.

Mise en œuvre

Définir les indicateurs environnementaux à suivre, si possible suite à un diagnostic basé sur une méthodologie d’analyse de cycle de vie (ACV) multicritère afin d’identifier les indicateurs permettant de documenter la majorité de l’empreinte environnementale du service ou de l’organisation (se référer aux méthodologies « Product Environmental Footprint » and « Organisation Environmental Footprint » de la Commission européenne, ou aux normes ISO 14040 et ISO 14044). Les indicateurs d’impacts environnementaux à considérer prioritairement – en fonction des données disponibles – sont la consommation d’énergie primaire, les émissions de gaz à effet de serre (GES), la consommation d’eau bleue (c’est-à-dire la consommation directe des eaux de surface ou des eaux souterraines) et l’épuisement des ressources abiotiques (au moins métaux et minéraux). Le périmètre de l’analyse de cycle de vie peut être élargi par exemple en tenant compte des moyens de production : impacts environnementaux des équipements de conception, services en ligne mobilisés (environnement de test, de Quality Assurance (QA)…), déplacements des équipes, etc.

Fixer les objectifs de réduction de l’empreinte environnementale du service numérique (à court, moyen ou long terme) au regard du nombre d’utilisateurs escompté. Les indicateurs suivis doivent concerner prioritairementla consommation d’énergie primaire, les émissions de GES, la consommation d’eau bleue et l’épuisement des ressources abiotiques. Selon le contexte, il convient de préciser s’il s’agit d’indicateurs en valeur absolue (kg CO2e) ou relative (kg CO2e / utilisateur).

Moyen de test ou de contrôle

Des indicateurs ont été identifiés pour renseigner l’empreinte environnementale du service numérique. Si la disponibilité des données le permet, ces indicateurs devront s’appuyer sur la méthodologie ACV. Lors de la revue du document, les questions suivantes requièrent une attention particulière :

• Quels sont les indicateurs définis ? Les indicateurs prioritaires mentionnés dans la partie mise en œuvre devront a minima être intégrés.
• Comment sont suivis ces indicateurs ?
• Sont-ils publiés/ouverts et si oui, où ?
• La méthodologie d’évaluation des indicateurs suivis est-elle accessible publiquement ?

Quel est le rythme d’évaluation ? De plus, des objectifs de réduction d’impacts environnementaux sont fixés pour le service dans le cadre des indicateurs environnementaux suivis. Ceux-ci concernent au moins la consommation d’énergie primaire, les émissions de GES, la consommation en eau et ressources abiotiques (métal/minéral). Ces objectifs peuvent s’inscrire dans une trajectoire fixée au niveau du système ou de l’organisation. Pour certains enjeux environnementaux comme le climat, les trajectoires devraient être alignées avec l’Accord de Paris (en se basant par exemple sur les référentiels de l’initiative Science Based Targets (SBTi) ; ou la recommandation ITU-T L.1470).

Le critère est validé si l’empreinte environnementale du service a été évaluée – avec une méthodologie reconnue, si possible une ACV (multicritère) évaluant les impacts du service sur tout son cycle de vie – et si le service s’est fixé des objectifs de réduction d’impact. Ces éléments doivent faire l’objet d’un suivi régulier et être renseignés dans un document public et auditable, par exemple la déclaration d’écoconception du service.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

Applicable à tous les services

Métiers concernés : Data Scientist, Responsable Juridique

Objectif 

Cette pratique vise à encourager une collecte de données responsable et raisonnée en complément des obligations légales de minimisation prévues par le Règlement général sur la protection des données (RGPD) en ce qui concerne les données personnelles. Comme le souligne le rapport de la CNIL « Données, Empreinte et Libertés » (2023), certains impératifs de respect de la vie privée et objectifs d’écoconception se rejoignent. Il s’agira donc d’œuvrer à réduire la quantité de données collectées, traitées et stockées par le service, y compris les données non personnelles et métadonnées, pour optimiser l'utilisation des ressources informatiques. Afin de limiter le profilage des utilisateurs, consommateur en ressources, le critère vise également à restreindre la collecte et le traitement de métadonnées aux fins de tracking.

Mise en œuvre

Définir clairement les données nécessaires au fonctionnement du service, en cohérence avec les cibles utilisatrices et leurs attentes telles que définies au critère 1.2 du présent référentiel. Si une donnée ne contribue pas directement à l'amélioration de l'expérience utilisateur ou au fonctionnement du service, mieux vaut envisager de ne pas la collecter. La collecte de métadonnées dans une perspective de profilage des utilisateurs devra être évitée.

Pour chaque type de donnée jugée essentielle au fonctionnement du service et aux besoins des utilisateurs, définir les conditions de collecte qui devront expressément respecter les dispositifs du RGPD concernant les données personnelles. Pour les données non personnelles, la durée de conservation devra également être minimisée afin d’éviter leur stockage excessif.

Systématiser la mise en place d’une information complète, le droit de s’opposer et/ou la demande de consentement explicite de l’utilisateur pour l’ensemble des données collectées, y compris pour les données non personnelles.

Moyen de test ou de contrôle

Contrôler le type et la quantité de données collectées, traitées et stockées par le service.

En ce qui concerne les données personnelles, indépendamment des enjeux d’écoconception, la minimisation de la collecte de ces données est un impératif du RGPD et doit être strictement suivie par le responsable de traitement.

De façon plus large, pour l’ensemble des données collectées (y compris non personnelles), justifier dans la déclaration d’écoconception du service le besoin de cette collecte au regard des cibles utilisatrices du service (critère 1.2), la limitation de leur traitement et de la durée de conservation, et documenter les outils de recueil du consentement le cas échéant. En ce qui concerne les données personnelles, un renvoi pourra être fait au registre de traitements des données personnelles tel que prévu par le RGPD.

Ne pas collecter des métadonnées servant au profilage de l’utilisateur, sauf si cette collecte est essentielle aux besoins et cibles utilisatrices du service (critère 1.2) ou au fonctionnement de ce dernier, et si l’utilisateur a donné son consentement explicite et éclairé et qu’il peut désactiver cette collecte à tout moment. Le cas échéant, ces éléments devront être documentés dans la déclaration d’écoconception du service numérique.

Pour aller plus loin

Sources sur la collecte de données personnelles :

• CNIL, Minimiser les données collectées
• CNIL, Registre des activités de traitement

Niveau de difficulté : Moyen

Niveau de priorité : Modéré

N/A si le service n’a pas recours à un mécanisme de chiffrement

Métiers concernés : Expert en sécurité informatique, Responsable de la protection de données

Objectif

Dans la plupart des situations, le recours à des mécanismes cryptographiques est absolument essentiel pour protéger lessystèmes informatiques, ainsi que les données – notamment personnelles – collectées ou traitées. Ces mécanismes ont une empreinte environnementale à considérer. Par exemple, le chiffrement augmente automatiquement la consommation énergétique, d’abord par le calcul nécessaire à cette opération et au déchiffrement, mais aussi par le stockage et la charge pour les réseaux de communication. Néanmoins, ils peuvent dans certains cas permettre d’alléger les systèmes informatiques (par la compression des archives en parallèle du chiffrement, ou en évitant de conserver ou de faire circuler certains fichiers). Cette pratique vise donc à promouvoir la minimisation du coût environnemental du chiffrement, en tenant compte des contraintes de sécurité à respecter. Le chiffrement contribue par ailleurs à la protection et à la sécurité des données, et réduit le risque de faille et de fuite de données, dont les traitements ultérieurs ont une empreinte énergétique.

Mise en œuvre

Chercher, pour un niveau de sécurité donné, les choix optimaux pour la préservation des ressources :

• En réalisant des mesures comparatives de différents algorithmes de chiffrement, afin de sélectionner celui qui introduit la plus faible quantité de ressources processeurs pour une même performance ;
• En évaluant la pertinence du chiffrement au regard de la nature des données et des risques associés ;
• Dans le cas où le chiffrement est envisagé, mettre en œuvre, quand cela est possible, un algorithme et une implémentation qui minimisent l’empreinte environnementale du service (sans préjudice du niveau de sécurité requis).

Avoir recourt à des mécanismes cryptographiques qui permettent de générer des preuves sans nécessité de conserver ou de divulguer le fichier à prouver (par exemple : preuve de fourniture de pièce d’identité, etc.).

Conserver des archives chiffrées et compressées (des outils gratuits comme 7zip ou Zed! fonctionnent sur ce principe).

Moyen de test ou de contrôle

Si le service repose sur des mécanismes de chiffrement, documenter dans la déclaration d’écoconception du service la pertinence du choix de mise en œuvre des mécanismes cryptographiques en fonction des risques de sécurité informatique du service et de la minimisation de l’empreinte environnementale associée.

Niveau de difficulté : Fort

Niveau de priorité : Recommandé

Applicable à tous les services

Métiers concernés : Porteur de projet, Responsable Développement, Responsable Juridique

Objectif

L’open source permet la réutilisation du code pour d’autres projets, évitant ainsi un gaspillage de ressources dédiées. La publication du code source d’un service numérique en format libre permet d’allonger la durée de vie du service en s’appuyant sur la collaboration avec les communautés de développeurs et chercheurs pour pallier d’éventuels défauts ou ajouter de nouvelles fonctionnalités. Elle renforce également son auditabilité et sa transparence, y compris d’un point de vue environnemental.

L’open source est aussi un levier pour allonger la durée de vie du matériel associé à l’utilisation d’un service numérique.

Par exemple, les applications ou pilotes ouverts associés à un objet connecté (enceinte, montre connectée, etc.) ou à un périphérique (imprimante, etc.) permettent de suppléer à la fin de vie de programmes « propriétaires » nécessaires à leur utilisation.

Mise en œuvre

Publier le code source du service numérique en licence libre pour les éléments qui ne sont pas couverts par des obligations de confidentialité, et dans la limite des droits de propriété intellectuelle applicables. Lorsque cela est possible, l’utilisation du code open source est à privilégier pour la conception et le développement du service.

Moyen de test ou de contrôle

Le code source du service numérique est publié en open source lorsqu’il est non soumis à des restrictions de confidentialité ou aux droits de la propriété intellectuelle. Si certaines parties du code du service numérique ne sont pas publiées en open source, les raisons de ce choix devront être justifiées dans la déclaration d’écoconception du service numérique afin d’être auditables par un tiers. Le cas échant, le fournisseur devra faire état d’efforts pour ouvrir tout ou partie de son code source. Lorsque cela est possible, le service numérique devrait utiliser du code open source pour son propre fonctionnement.

Le critère est validé si le code du service est publié en licence libre ou si les choix et efforts effectués en la matière sont justifiés dans la déclaration d’écoconception du service numérique.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

Applicable à tous les services

Métiers concernés : Responsable IT, Développeur

Objectif

L’objectif est de lutter contre l’obsolescence des équipements induite par le logiciel. Tout service numérique qui s’attachera à être le plus stable et pérenne dans le temps permettra l’allongement de la durée pendant laquelle les terminaux restent utilisables. Typiquement, le recours à de nouvelles interfaces de programmation (API) ou de nouveaux standards non supportés par les terminaux plus anciens sont susceptibles de favoriser une obsolescence rapide des terminaux. Ainsi, l’interopérabilité des standards est un vecteur pour allonger la durée d’utilisation et de vie de ces derniers. De même, les applications natives peuvent avoir besoin des dernières versions d’OS (système d’exploitation) ou même les dernières versions des équipements pour fonctionner, ce qui induit une obsolescence des matériels.

Mise en œuvre

Evaluer, bien en amont du développement, la faisabilité de concevoir le service avec des technologies standard (par exemple, web plutôt que des applications natives) pour répondre au besoin des utilisateurs et des métiers. Il s’agit aussi de s’assurer que les API utilisées sont standard et bien supportées (API JavaScript dans les navigateurs web par exemple). S’appuyer sur des technologies interopérables permet de lutter contre l’obsolescence logicielle. De même, construire son service à partir de composants open source permet de garder la main sur la maintenance du code utilisé, par conséquent d’améliorer la durabilité du code et de réduire le risque d’obsolescence induite par le logiciel sur le matériel.

Dans le cas où une application native est nécessaire (par exemple, si le service numérique nécessite des traitements de données particulièrement sensibles), s’assurer qu’elle utilise des standards compatibles avec les principaux systèmes d’exploitation.

Moyen de test ou de contrôle

Vérifier que le service numérique est utilisable par une même interface sur l’ensemble des terminaux pertinents (par exemple : une Web App). Si le service numérique est une application native, évaluer la nécessité d’avoir choisi de développer une application native : contraintes techniques, matériel cible maîtrisé ?

Le critère est validé si le service s’appuie sur des standards interopérables communs aux principaux écosystèmes (terminaux, systèmes d’exploitation, navigateurs...).

Niveau de difficulté : Fort

Niveau de priorité : Recommandé

N/A si le service numérique ne repose pas sur un objet connecté ou un périphérique matériel

Métiers concernés : Responsable IT, Développeur, Architecte Système

Objectif

Un objet connecté ou un périphérique interagit avec son environnement via des API (interfaces d'accès dédiées aux programmes), généralement appelées via un programme (« pilote » ou « driver »), ou une application sur un smartphone.

• Lorsque ces API ne sont pas ouvertes, il est souvent impossible de prolonger la durée de vie de l’objet au-delà de celle de l’application ou pilote initialement conçu pour l’objet : si ce logiciel est abandonné, un objet ou un périphérique parfaitement fonctionnel devient inutilisable.
• Lorsque les API sont ouvertes (documentées et d’usage libre), il est possible pour un développeur tiers de développer une application alternative et de prolonger la vie de l’objet ou du périphérique.

Le logiciel libre permet de pallier cette obsolescence à condition que les API et formats soient documentés et ouverts, seul moyen pour des développeurs tiers de logiciels de développer des alternatives afin que ces objets ou périphériques restent utilisables dans le temps. Cela permet également de faire fonctionner l’objet connecté ou le périphérique sur des systèmes d’exploitation non supportés par le concepteur du matériel.

Mise en œuvre

Si le logiciel/pilote est associé à un équipement, terminal ou périphérique, le concepteur doit fournir des API ouvertes et documentées, afin de permettre que d’autres services numériques alternatifs puissent être utilisés sur l’appareil en cas de défaut ou d’abandon du logiciel, afin de prolonger la vie de l'objet ou du périphérique.

Moyen de test ou de contrôle

Si le service numérique repose sur l’utilisation d’un terminal, équipement, appareil, le fournisseur doit rendre disponibles les API nécessaires à l’exploitation de l’objet connecté. Les API du périphérique doivent être documentées et d’usage libre, afin qu’un programme ou pilote alternatif puisse être créé pour prolonger la durée de vie de l’objet ou du périphérique.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

Applicable à tous les services

Métiers concernés : Responsable IT, Responsable RSE/Numérique soutenable, Développeur

Objectif

Un service numérique n’exploitant que des ressources techniques de toute dernière génération peut conduire les utilisateurs à renouveler leurs équipements afin d’y accéder (obsolescence matérielle). Ainsi, certaines utilisations peuvent être contraintes par les terminaux des utilisateurs. Pour permettre un choix plus large d’équipements même anciens et limiter le renouvellement de matériel, il est important de connaître les profils de matériel que les utilisateurs vont pouvoir employer, aujourd’hui et demain : débit minimum de la connexion internet, taille d’écran, vitesse du microprocesseur, nombre de Go de mémoire vive, écran tactile ou non, smartphone, tablette, ordinateur portable, ordinateur de bureau, etc.

Mise en œuvre

Définir le profil des matériels supportés, en assurant la compatibilité avec les équipements aussi anciens que possible, afin d’éviter toute obsolescence matérielle.

Moyen de test ou de contrôle

Le critère est validé si le profil des matériels supportés par le service est établi de façon à privilégier les équipements aussi anciens que possible et le profil matériel minimum est affiché dans la déclaration d’écoconception du service.

Si certaines fonctionnalités requièrent une version plus récente, indiquer les versions minimales avec et sans support de ces fonctionnalités.

Il convient également d’indiquer les éventuelles évolutions à venir sur la configuration matérielle minimum.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

Applicable à tous les services

Métiers concernés : Responsable IT, Responsable RSE/Numérique soutenable, Développeur

Objectif

Selon l’étude ADEME-Arcep, les terminaux représentent 65 à 92 % de l’empreinte environnementale du numérique selon l’indicateur considéré, en particulier leur fabrication. L’allongement de la durée de vie de ces derniers est donc un levier essentiel de réduction des impacts environnementaux du numérique. Le service numérique doit limiter sa contribution à leur obsolescence en fonctionnant sur des équipements aussi anciens que possible.

Mise en œuvre

Pour chaque fonctionnalité, s’assurer que le service numérique est compatible avec des équipements anciens. Par exemple, ce critère peut être ajouté dans les tests ou QA (Quality Assurance).

Quelques précisions concernant le critère :

• Il s’agit de la compatibilité avec un matériel et non avec un système d’exploitation ou tout autre logiciel faisant fonctionner le service numérique (par exemple un navigateur). Il ne s’agit donc pas ici de rendre compatible le service numérique avec des logiciels ou des systèmes d’exploitation dont les mises à jour de sécurité n’ont pas été faites.
• Définition de « utilisable » ici : mode dégradé accepté mais sans perte de fonctionnalité incontournable ou critique ni de contenu pour le service.
• Si le service numérique est une application native : le service numérique doit être utilisable sur les équipements mis sur le marché il y a sept ans ou plus, dans la dernière version du système d’exploitation proposée par cet équipement.
• Si le service numérique fonctionne sur un navigateur web : le service numérique doit être utilisable sur les équipements dotés d’un microprocesseur mis sur le marché il y a dix ans ou plus.
• Pour les autres services numériques, leur utilisation doit être garantie sur des équipements ou périphériques mis sur le marché il y a sept ans ou plus.
• Une durée de compatibilité plus longue est recommandée. Dans ce cas l’objectif est à préciser, par exemple dans la déclaration d’écoconception.
• Ce critère n’exclut pas l’usage de fonctionnalités récentes permettant la réduction des impacts environnementaux à l’usage tant que le service reste disponible sur les anciennes versions (principe d’amélioration progressive).

Moyen de test ou de contrôle

Contrôler la mise en œuvre selon la nature du service en vérifiant les points suivants :

• Si le service numérique est une application native : il convient de tester les fonctionnalités critiques du service numérique sur un équipement ancien (par exemple un smartphone, une tablette ou TV connectée), c’est-à-dire mis sur le marché il y a sept ans ou plus, dans la dernière version du système d’exploitation proposé par cet équipement.
• Si le service numérique fonctionne sur un navigateur web : les fonctionnalités critiques doivent fonctionner sur un PC portable – ou un autre terminal, tant que cela est cohérent avec les terminaux qui sont majoritairement utilisés par les cibles utilisatrices du service définies en suivant le critère 1.2 – équipé d’un microprocesseur mis sur le marché il y a dix ans ou plus.
• Pour les autres services numériques : tester les fonctionnalités critiques du service sur un terminal (exemple : équipements connectés) mis sur le marché il y a sept ans ou plus.

Sont à indiquer dans la déclaration d’écoconception du service les caractéristiques matérielles et logicielles de l’équipement ancien qui permet de faire fonctionner le service.

Tenir compte du moment où l’évaluation est réalisée et non de la date de mise en ligne du service.

Le critère est validé si le service est utilisable dans les conditions susmentionnées.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

Applicable à tous les services

Métiers concernés : Responsable IT, Responsable RSE/Numérique soutenable, Développeur

Objectif

Si le service numérique s’adresse à un large public, le niveau de connectivité n’est pas maîtrisé. Il est nécessaire de veiller à ne pas exclure certains publics qui n’ont pas accès à de hauts débits : en plus de permettre de réduire la fracture numérique, il s’agit d’une bonne pratique pour l’environnement. En effet, les utilisateurs n’ont pas toujours conscience de ce qui ralentit un service numérique : la connexion réseau, le service numérique ou le terminal utilisé ? Un service numérique plus léger a beaucoup moins besoin de ressources réseaux pour fonctionner.

Mise en œuvre

Tester l’utilisabilité du service avec des connexions bas débit, mesurer et améliorer le temps de réponse. Les contenus peuvent être servis en qualité dégradée lorsque cela s’avère nécessaire.

Il est recommandé aux applications natives de prévoir un mode hors ligne sur les fonctionnalités qu'il est techniquement possible de fournir hors ligne.

Moyen de test ou de contrôle

L’utilisabilité du service devra être testée avec des connexions bas débit (3G en mobilité et 512 Kbit/s en fixe) ou hors connexion. Le critère est validé si le service numérique est utilisable sans connexion au réseau ou avec une connexion bas débit. Le débit minimum sera présenté dans la déclaration d’écoconception.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A si le service numérique ne repose pas sur un système d’exploitation ou un navigateur web

Métiers concernés : Responsable IT, Responsable RSE/Numérique soutenable, Développeur

Objectif

L’objectif est de permettre à des systèmes d’exploitation ou navigateurs web anciens d’être utilisés, afin d’allonger leur durée de vie. Les systèmes d’exploitation et les navigateurs étant parfois liés à un terminal, cette pratique peut donc partiellement permettre de réduire la contribution du service numérique à leur obsolescence. Ce critère prend en compte les dispositions européennes visant à garantir la mise à disposition de mises à jour correctives pour les systèmes d’exploitation de cinq ans.

Mise en œuvre

Si le service numérique est une application native, il doit prendre en charge les dernières versions des systèmes d’exploitation supportés et être utilisable sur les versions anciennes de ces systèmes d’exploitation (hors mises à jour correctives), jusqu’à cinq ans, en prenant en compte la première date de mise à disposition en version stable.

Si le service numérique fonctionne sur un navigateur web, il doit prendre en charge les dernières versions des navigateurs web (hors mises à jour correctives) et être utilisable sur les versions anciennes des principaux navigateurs web, jusqu’à deux ans, en prenant en compte la première date de mise à disposition en version stable.

Moyen de test ou de contrôle

Vérifier la mise en œuvre selon la nature du service en vérifiant les points suivants :

• Si le service numérique est une application native : tester les fonctionnalités critiques du service numérique sur les systèmes d’exploitation supportés ayant cinq ans, en prenant en compte la première date de mise à disposition en version stable.
• Si le service numérique fonctionne sur un navigateur web : s’assurer que les fonctionnalités critiques fonctionnent sur les principaux navigateurs web dans une version datée d’au moins deux ans, en prenant en compte la première date de mise à disposition en version stable.

La déclaration d’écoconception du service numérique devrait spécifier :

• Si le service numérique est une application native : les versions minimales des systèmes d’exploitation supportés.
• Si le service numérique fonctionne sur un navigateur web : lister les prérequis logiciels et les versions minimales des navigateurs web compatibles et leur année de sortie. Il est pertinent de rajouter la cause de l’incompatibilité de la version précédente, s’il est possible d’en diagnostiquer la cause.

Si certaines fonctionnalités requièrent une version plus récente, indiquer les versions minimales avec et sans support de ces fonctionnalités.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A si le service numérique ne propose d’interface utilisateur sur écran

Métiers concernés : Développeur, Responsable IT, Designer

Objectif

Le service numérique devrait participer à limiter l’achat de nouveaux terminaux en fonctionnant sur des équipements aux dimensions d’écran variées, dont les plus petites (smartphones anciens par exemple). La possibilité d’un service numérique de s’adapter aux écrans avec une faible définition peut contribuer à lutter contre l’obsolescence des équipements induite par le logiciel.

Mise en œuvre

Uniquement lorsque cela est applicable, rendre l’interface du service numérique adaptable à la taille de l’écran sans perte d’utilisabilité (« responsive design »).

Dans l’objectif d’éviter la multiplication des terminaux pour accéder à différents services, il est recommandé que les services numériques soient adaptatifs et capables de s’afficher parfaitement sur le petit écran d’un mobile comme sur le grand écran d’un PC. Il vaut mieux éviter de dupliquer le service numérique avec une version spécifique pour chaque terminal. Il est également préférable que les menus soient utilisables en mode tactile tout autant que via un clavier.

Lorsque c’est pertinent, le développement du design de la version mobile en premier (mobile first) peut permettre l’adoption d’interface plus sobre.

Moyen de test ou de contrôle

Tester les fonctionnalités critiques du service numérique sur différentes tailles d’affichage (ordinateur de bureau, tablette et mobile) :

• Le service doit adapter son mode d’affichage de manière dynamique selon la taille de l’écran (« responsive web design »).
• Vérifier que les différents composants de type menus soient accessibles via tout type d’interface, y compris tactile ou non, avec ou sans souris.
• S’assurer de l’affichage complet du service dans une zone de visualisation de 1 200 pixels de large (ce qui correspond à la définition des écrans d’ordinateurs standard de 17 pouces au format 5/4 avec 80 pixels utilisés par une barre de lancement).
• Pour les interfaces qui ne permettent pas de faire défiler de haut en bas l’affichage, vérifier l’affichage complet du service dans une zone de visualisation de 720 pixels de hauteur (ce qui correspond à la définition des écrans d’ordinateur de 800 pixels de haut, avec 80 pixels utilisés par une barre de lancement).

Le critère est validé si les conditions susmentionnées sont remplies. Les tests effectués sont à documenter dans la déclaration d’écoconception.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

Applicable à tous les services

Métiers concernés : Architecte Logiciel, Développeur, Responsable RSE/Numérique soutenable

Objectif

Afin d’aboutir à une solution la plus sobre possible tout en répondant au besoin, il faut miser sur l’intelligence collective de toute l’équipe. Et pour cela, il ne suffit pas seulement de valider la conception par la revue de code, une bonne pratique maintenant assez répandue. Il est nécessaire, et cela sera positif pour l’équipe et pour le projet, de réfléchir en amont du développement aux choix de conception et d’architecture, en ayant notamment pour objectif la minimisation des impacts environnementaux.

Mise en œuvre

En impliquant l’ensemble de l’équipe, l’ensemble des métiers, une revue de conception en amont du développement est réalisée pour choisir la solution répondant au besoin tout en minimisant les impacts environnementaux. Puis, si du code a été produit pour implémenter la solution, une revue de code est faite en aval du développement.

Moyen de test ou de contrôle

Quel est le processus de développement mis en place ?

Le critère est validé si :

• Une revue de conception prenant en compte l’empreinte environnementale du service a été réalisée : dès sa conception, l’équipe projet devrait pouvoir définir un arbre des conséquences du service numérique en représentant, par fonctionnalité, les impacts directs et indirects du service numérique pour que toute l’équipe valide les fonctionnalités en connaissance des impacts environnementaux potentiels (voir la méthodologie Empreinte projet de l’ADEME).
• Une revue de code visant à minimiser le coût environnemental du service a été produite en aval de la conception pour les services reposant sur du code informatique.

Ces revues sont – le cas échéant – référencées dans la déclaration d’écoconception du service.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

Applicable à tous les services                      

Métiers concernés : Responsable IT, Architecte Logiciel

Objectif

Mettre au rebut les environnements techniques encore actifs mais qui ne sont plus utilisés : production, QA (Quality Assurance), test, environnement de développement, sauvegarde etc. Ces environnements peuvent occuper de la ressource informatique inutilement. Il s’agit également de prévoir la possible fin de vie de tout ou partie du service.

Mise en œuvre

Définir et mettre à jour régulièrement une stratégie de maintenance et décommissionnement des environnements et des dates de rappel. Plus largement, en cas de non utilisation ou de baisse importante d’utilisation, s’interroger sur l’opportunité d’arrêter des parties du service (ou tout le service) afin de diminuer les impacts de ce dernier, en prenant en compte les équipements sous-jacents à réaffecter pour prolonger leur durée de vie. En cas de décommissionnement, il conviendra de donner une nouvelle vie au matériel et aux ressources libérées (réutilisation, reconditionnement, recyclage…) et d’anticiper l’avenir des données non personnelles collectées pour prévoir, par exemple, leur suppression ou leur mise en open data. En cas de fin de vie d’un service numérique propriétaire, il est recommandé de prévoir une publication en open source du code source du service.

Moyen de test ou de contrôle

Lister les fonctionnalités, les composants et les environnements actifs, en précisant leur état d'utilisation. Le critère est validé si une stratégie de maintenance et de décommissionnement est définie pour le service incluant des dates de rappel pour les éléments non utilisés et les actions prévues pour optimiser la seconde vie ou fin de vie des ressources libérées en cas de décommissionnement. Les résultats doivent être documentés dans la déclaration d’écoconception. En cas de fin de vie de tout ou partie du service, la gestion des données non personnelles et des équipements utilisés pour leur service devra être planifiée, de manière à diminuer les impacts environnementaux associés.

Niveau de difficulté : Fort

Niveau de priorité : Prioritaire

N/A si le service numérique ne repose pas sur l’appel à des fournisseurs extérieurs

Métiers concernés : Responsable Partenariats, Responsable RSE/Numérique soutenable, Porteur de projet

Objectif

Un projet est rarement réalisé avec un périmètre couvert totalement au sein de l’organisation. De nombreuses ressources externes sont mobilisées au cours du projet et se doivent d’être alignées avec la démarche. L’écoconception d’un service numérique devrait s’appuyer sur une responsabilisation environnementale de toute la chaîne de valeur, y compris des fournisseurs externes. Il est essentiel de veiller à ce que les fournisseurs adoptent une approche de réduction de leurs impacts environnementaux.

Mise en œuvre

Identifier les ressources nécessaires et leur associer des exigences environnementales. Le périmètre de la démarche porte sur la conception du service numérique (non sur le fournisseur lui-même).

Se référer aux documents suivants :

• Guide pratique pour des achats numériques responsables (PDF – 2 Mo)
• ISO 20400, Achats responsables – Lignes directrices, norme internationale publiée en avril 2017 par l’ISO, qui donne des recommandations pour atteindre des objectifs de responsabilité sociétale tout le long de la chaîne d’approvisionnement.

Moyen de test ou de contrôle

Le critère est validé si les caractéristiques environnementales des fournisseurs pour la conception du service numérique sont prises en compte dans la politique d’achat ou de partenariat du service, en vue des impacts environnementaux associés et documentés dans la déclaration d’écoconception.

Les recommandations du Guide pratique pour des achats numériques responsables et/ou la norme ISO 20400 pourront en particulier être considérées.

Niveau de difficulté : Fort

Niveau de priorité : Modéré

N/A si le service numérique ne repose pas sur des composants d’interface prêts à l’emploi

Métiers concernés : Designer, Développeur, Responsable IT

Objectif

Connaître les impacts environnementaux des composants d’interface (boutons, formulaires…), des systèmes de design qui sont des surcouches aux interfaces du système d’exploitation, utilisés dans le service numérique.

Mise en œuvre

Comparer les impacts environnementaux des composants d'interface prêts à l'emploi utilisés dans le service numérique afin d’être en mesure d’utiliser les solutions les plus sobres. Par exemple, mesurer et comparer leur poids en termes d’utilisation de ressources (taille des fichiers, quantité de données transférées).

Moyen de test ou de contrôle

Vérifier si les composants d'interface utilisés sont conçus de manière à réduire leurs impacts environnementaux.

Pour cela, prendre en compte ou effectuer, le cas échéant, des mesures comparatives entre les différents composants similaires et choisir ceux qui présentent les meilleures performances environnementales. Les éléments suivants peuvent être considérés : l'utilisation de méthodes de compression efficaces, l'optimisation des ressources, la minimisation des transferts de données, l'utilisation de techniques de conception légère, etc.

Le critère est validé si la majorité des composants d’interfaces utilisés par le service sont estimés performants écologiquement, en prenant notamment en compte les critères susmentionnés lorsque applicables à la fonctionnalité visée. Les choix effectués et la minimisation de l’empreinte environnementale des composants devrait également être documentée dans la déclaration d’écoconception.

Niveau de difficulté : Fort

Niveau de priorité : Prioritaire

N/A si le service numérique ne repose pas sur des services tiers

Métiers concernés : Responsable Partenariats, Architecte Logiciel, Responsable RSE/Numérique soutenable

Objectif

Les services de tiers sont des services proposés par des fournisseurs externes (développeurs, organismes ou entreprises) apportant des fonctionnalités prêtes à l’emploi (par exemple suivi d’audience, lecteur vidéo, fil d’actualité des réseaux sociaux, mécanisme de captcha…) et évitant ainsi de les redévelopper en interne. L’objectif est donc de réduire les impacts environnementaux des services tiers, donc non issus de développement interne.

Mise en œuvre

Le plus souvent, une mesure d’outils analytiques A/B test permet de connaître les impacts environnementaux d’un service tiers afin d’aider à la prise de décision sur le facteur environnemental. Les mesures fournies par le service tiers sont aussi à prendre en compte pour effectuer des évaluations ou comparatifs validant le choix effectué.

Moyen de test ou de contrôle

Contrôler la mise en œuvre. Plus spécifiquement, il pourra être vérifié si les services tiers sur lesquels le service numérique repose valident les critères suivants :

• Pour tous les services tiers fournis, validation des critères 1.4 et 1.5 ;
• De façon complémentaire :
  • Si le service tiers analysé est une vidéo, validation des critères 4.4, 4.11, 4.12, 4.15, 5.3, 5.4 et 5.5 
  • Si le service tiers analysé est un réseau social, validation des critères 4.1, 4.6, 4.9, 4.12, 4.13 et 4.15
  • Si le service tiers analysé est un générateur d’image, validation des critères 4.6, 4.11, 4.12, 4.13 et 4.15.

Les services tiers utilisés sont à lister, en renseignant leur avancement au regard de ces critères (si applicables), dans la déclaration d’écoconception.

Niveau de difficulté : Fort

Niveau de priorité : Prioritaire

N/A si le service ne repose pas sur des composants

Métiers concernés : Architecte Système, Développeur, Responsable RSE/Numérique soutenable

Objectif

Le service numérique peut dépendre d’une architecture, de composants qui ne sont pas développés par la même équipe ou qui sont fournis par des frameworks de production. Il s’agit alors de s’assurer que ces dépendances sont également conçues de manière à réduire leurs propres impacts environnementaux. Certains composants sont particulièrement intensifs en termes de consommation énergétique et en ressources, et devraient être évités (par exemple : minage, réalité virtuelle/augmentée requérant l’acquisition d’un terminal dédié, certains algorithmes d’apprentissage…).

Mise en œuvre

S'assurer que l'architecture, les ressources et les composants utilisés dans le service numérique, notamment les frameworks pour le frontend et backend, sont délibérément conçus pour minimiser leurs impacts environnementaux. Ceux-ci respectent-ils les critères du référentiel ? Plus spécifiquement :

• Évaluation des frameworks : Examiner les frameworks utilisés pour le développement du frontend et du backend en termes d'écoconception. L’analyse pourra notamment prendre en compte : l’utilisation efficace des ressources matérielles et énergétiques, l’utilisation de technique de compression efficace, l’optimisation des requêtes client- serveur.
•  Évaluation des composants : Vérifier si les composants, qu'ils soient internes ou externes, suivent des principes d’écoconception. L’analyse pourra notamment prendre en compte : l’utilisation efficace des ressources matérielles et énergétiques, l’utilisation de technique de compression efficace, l’optimisation des requêtes client-serveur.

Voir aussi les critères 2.9 et 2.10 pour la prise en compte des impacts des composants d’interface et des services tiers.

Moyen de test ou de contrôle

Vérification de la mise en œuvre en analysant et optimisant l'empreinte environnementale pour évaluer la performance énergétique des composants et des frameworks. S’assurer notamment que le service ne s’appuie pas sur des briques technologiques particulièrement énergivores et consommatrices en ressources (apprentissage automatique, minage, métavers en particulier). En cas de recours à ce type de technologie, la solution la plus sobre en termes de consommation en ressources doit être utilisée par défaut, et le choix doit être documenté dans la déclaration d’écoconception du service numérique.

Le choix d'architecture et de composants est à documenter dans la déclaration d’écoconception au regard de l’impact environnemental (en vérifiant notamment la validation par ces éléments des critères 2.9 et 2.10 de ce référentiel), en intégrant un comparatif avec les autres options possibles.

Le critère est validé si le choix de frameworks et composants de l’architecture a été fait en prenant en compte leur empreinte environnementale et l’écoconception, et qu’il est documenté dans la déclaration d’écoconception du service.

Niveau de difficulté : Fort

Niveau de priorité : Recommandé

N/A si le service ne repose pas sur des ressources serveurs

Métiers concernés : Architecte Système, Développeur, Responsable RSE/Numérique soutenable

Objectif

L’objectif est d’éviter une architecture surdimensionnée et de privilégier une architecture capable d'ajuster dynamiquement la quantité de ressources utilisées en fonction de la demande du service, et passer à l’échelle. Cela contribue à optimiser l'efficacité énergétique et à éviter le gaspillage de ressources inutiles.

Mise en œuvre

Dans un premier temps, évaluer finement le besoin, le nombre d’utilisateurs pour adapter les ressources informatiques nécessaires. Dans un second temps, s’assurer que l’architecture peut s'adapter de manière optimale afin que soient allouées les ressources informatiques strictement nécessaires pour répondre à la demande fluctuante du service.

Moyen de test ou de contrôle

Le service numérique fonctionne sur une architecture qui peut adapter les ressources allouées à la demande. Afin de s’en assurer, plusieurs moyens de test peuvent être envisagés, par exemple :

• Suivi de l’évolution du ratio entre ressources allouées et consommées : construire un comparatif entre les ressources allouées et celles consommées sur une période de temps et corriger les défauts existants en termes d’adaptation. Des outils de surveillance des ressources peuvent aussi être mis en place pour collecter des données sur l'utilisation du processeur, de la mémoire, de la bande passante, etc.
• Simulation de montées en charge : vérifier si l'architecture est capable de détecter automatiquement l'augmentation de la demande et d'allouer dynamiquement les ressources nécessaires pour maintenir les performances. Des tests de montée en charge réelle en situation réelle sont également utiles.
• Mécanismes d'auto-ajustement : ces mécanismes se déclenchent automatiquement en fonction des conditions de charge (par exemple : utilisation de mécanismes d'auto-scaling pour créer dynamiquement des instances du service en fonction de la demande).

Démontrer dans la déclaration d’écoconception l’adaptation de la consommation en ressources de l’architecture en fonction des besoins du service.

Niveau de difficulté : Moyen

Niveau de priorité : Modéré

N/A si le service numérique n’utilise pas de connexion réseau internet

Métiers concernés : Architecte Système, Développeur, Responsable RSE/Numérique soutenable

Objectif

Le choix des protocoles sous-jacents aux échanges réseaux associés au service numérique développé a un impact sur la sollicitation des infrastructures, mais aussi sur la durée de vie du service numérique. En effet, les évolutions techniques des protocoles non supportées par le service numérique peuvent conduire à des dysfonctionnements de certains modules ou fonctionnalités de celui-ci. Prendre en compte ces risques d’obsolescence pour faire les meilleurs choix en matière de protocole permettra de limiter les mises à jour/modernisations nécessaires, et rendra ainsi le service numérique plus durable et pérenne. L’objectif est donc de limiter l’obsolescence du service induite par l’obsolescence des protocoles utilisés, en tenant compte particulièrement des éléments suivants :

• Protocole d’adressage : face à la pénurie d’IPv4 et la généralisation d’IPv6 (à moyen terme, certains accès à internet ne proposeront plus de connectivité IPv4), un service disponible en IPv6 en assure sa pérennité. Ce choix permet aussi de limiter le nombre de plateformes nécessaires et la consommation d’énergie associée chez les opérateurs ayant recours à du partage d’IPv4 entre clients. L’IPv6 n’a pas besoin de passer par la plateforme CG-Nat qui est coûteuse en matériel et en énergie (voir la présentation vidéo « Adressage et transition IPv6 » de décembre 2023).
• Protocole de chiffrement/d’authentification : les navigateurs tendent vers le blocage du protocole HTTP et l’obligation d’utiliser HTTPS, qui devient donc le choix le plus pérenne. En outre, la couche de chiffrement TLS doit être adaptés à l’évolution de ce protocole puisque les anciennes versions de TLS (TLS v1.0 et TLS v1.1) ne sont plus prises en charge par les navigateurs web.
• Protocole d’échanges de données : s’assurer de l’adéquation entre le choix du protocole et le type des contenus échangés.

Mise en œuvre

Vérifier que le choix des protocoles sous-jacents au service – protocole d’adressage, d’authentification et chiffrement et d’échanges de données – favorisent la pérennité du service. Considérer en particulier les actions suivantes selon les fonctionnalités du service :

• Vérifier que le service est accessible en IPv6 et définir une stratégie de test IPv6 incluant des tests depuis un équipement où la connectivité IPv4 est désactivée. Objectif : déceler du code ou des fonctions qui ne fonctionnent qu’en IPv4-only, qui seront inutilisables à moyen terme, avec le retrait d’IPv4.
• Utiliser le protocole d’authentification et de chiffrement HTTPS. Dans un contexte où l’utilisateur accède au service numérique par son navigateur, il est le plus souvent obligatoire d’utiliser HTTPS au lieu de HTTP (l’utilisation d’un moyen sécurisé pour le transfert de données personnelles est une obligation de l’article 32 du RGPD).
• Pour le protocole de sécurité, la version de TLS utilisée doit prendre en charge la version la plus récente (au moment de la rédaction de ce référentiel : TLS v1.3). Par exemple, avec Apache la ligne de configuration recommandée est « SSLProtocol al -SSLv3 -TLSv1 -TLSv1.1 », ce qui permet d’activer les nouvelles versions de TLS quand elles sont disponibles et de désactiver les versions de TLS problématiques d’un point de vue sécurité.
• Pour les protocoles d’échanges de données, il est recommandé de comparer les protocoles disponibles en fonction des types de contenu et des fonctionnalités recherchées. Cette évaluation devrait prendre en considération des critères tels que l'efficacité de transfert des données, la latence, la compatibilité avec les technologies utilisées, ainsi que l'impact environnemental de chaque protocole. Par exemple :
  • Pour la vidéo : Multicast, HTTP Live Streaming (HLS), Real-Time Messaging Protocol (RTMP), Web Real-Time Communications (WebRTC)…
  • Pour les API : REST, SOAP, GraphQL, Protocol Buffers…

Moyen de test ou de contrôle

Vérifier la mise en œuvre en s’assurant :

• Que les différents composants du service numérique fonctionnent bien :
  • En IPv6 et ne font appel à aucun service tiers IPv4-only.
  • En HTTPS et non en HTTP.
• Que la dernière version de TLS (au moment de la rédaction de ce référentiel : TLS v1.3) est bien supportée.
• De l’adéquation du protocole utilisé par rapport au contenu transféré en tenant compte de son empreinte environnementale, ce qui peut être réalisé en :
  • Analysant les caractéristiques techniques du protocole dans le contexte des besoins du service, voire en réalisant des scénarios-tests ou des comparaisons de performances ;
  • Prenant en compte l'impact environnemental du protocole utilisé, notamment la consommation d'énergie et les ressources informatiques sous-jacentes à son usage.

Le critère est validé si le choix des protocoles nécessaires au fonctionnement du service en assure sa pérennité, en respectant, selon ses fonctionnalités, les conditions susmentionnées. Documenter les protocoles utilisés dans la déclaration d’écoconception.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A pour les services numériques qui ne sont pas commercialisés avec un terminal associé

Métiers concernés : Porteur de projet, Architecte Logiciel, Responsable RSE/Numérique soutenable

Objectif

L’obsolescence du logiciel commercialisé avec un équipement lié à un service numérique (par exemple : système d’exploitation, logiciel d’objet connecté, assistants vocaux…) rend souvent l’équipement inutilisable, alors que sa durée de vie pourrait être prolongée si le logiciel était maintenu plus longtemps. Cela revêt une importance particulière dans le contexte du développement de l'internet des objets (IoT), caractérisé par des équipements connectés nécessitant une maintenance continue pour garantir leur fonctionnement optimal, leur sécurité et leur interopérabilité. L’objectif est donc de limiter la contribution à l’obsolescence des équipements liés au service en assurant la disponibilité de mises à jour correctives tout au long de leur durée de vie prévue.

Mise en œuvre

Maintenir le service numérique pendant toute la durée prévue de l’équipement. Cela implique de prévoir une infrastructure de support appropriée, des ressources techniques et financières, ainsi qu'une planification de la maintenance à long terme – en cohérence avec la durée de vie estimée du matériel. Par exemple, sont visés ici des équipements spécifiques et les objets connectés (IoT).

Moyen de test ou de contrôle

Pour valider ce critère, indiquer la durée de maintenance du service dans la déclaration d’écoconception et vérifier que les mises à jour sont effectivement disponibles tout au long de la durée de vie des équipements associés.

Niveau de difficulté : Moyen

Niveau de priorité : Modéré

N/A si le service numérique ne propose pas de mises à jour évolutives (non essentielles)

Métiers concernés : Architecte Logiciel, Porteur de projet, Responsable Qualité

Objectif

Depuis l’ordonnance n° 2021-1247 en date du 29 septembre 2021 relative à la garantie légale de conformité pour les biens, les contenus numériques et les services numériques, le Code de la consommation prévoit plusieurs obligations concernant les mises à jour logicielles afin de garantir la réception des mises à jour nécessaires à la conformité des biens pendant toute la durée de garantie légale de conformité (deux ans ou plus), ou toute la durée du contrat si la fourniture du bien est garantie au-delà de deux ans. Par ailleurs, plusieurs obligations sont définies pour les vendeurs concernant les mises à jour non nécessaires à la conformité du bien en termes d’information au consommateur et de possibilité de refus et de désinstallation de la mise à jour par ce dernier.

Dans la continuité de ces dispositions, l’objectif de ce critère est donc de limiter la contribution à l’obsolescence des équipements en permettant à l’utilisateur d’opter uniquement pour les mises à jour nécessaires au bon fonctionnement, à la sécurité et à la conformité du service ou de l’appareil. Cette dissociation peut aussi éviter l’ajout de fonctionnalités « de confort » pouvant être inutilisables sur son appareil ou exiger des ressources matérielles ou informatiques supplémentaires susceptibles de favoriser une obsolescence rapide des terminaux.

Ce critère vise également à promouvoir les politiques de support à long terme (« long-term support ») et le fonctionnement du service numérique sur des systèmes d’exploitation d’ancienne génération. Il s’agira également d’accroître la transparence de l’information sur le type de mises à jour installées et de prévenir les risques d’obésiciel (ce terme désigne la surallocation de ressources systèmes ou matérielles pour un service, en particulier avec l’inclusion de nouvelles versions ou de fonctionnalités qui ne sont pas indispensables).

Mise en œuvre

Ce critère est en particulier pertinent pour un service numérique de type API / composants / bibliothèque / framework / outils open source et plus rarement pour un service destiné à des utilisateurs finals.

Il est possible d’installer de façon dissociée les mises à jour correctives, ou toute autre mise à jour essentielle à la conformité et à la sécurité du service numérique ou du terminal de l’utilisateur, et les mises à jour évolutives qui ne sont pas nécessaires à la conformité du bien.

Par ailleurs, la fréquence des mises à jour évolutives non nécessaires doit être suivie. Si la nature du service le permet, il convient de laisser la possibilité d’installer les mises à jour correctives indépendamment des mises à jour évolutives, sur demande de l’utilisateur.

De façon générale, les mises à jour évolutives ne doivent pas empêcher le service numérique de fonctionner sur toute la durée de maintenance des systèmes d’exploitation supportés (sous réserve d’absence de contraintes techniques ou de sécurité). La transparence des changements effectués doit être garantie avec la mise à disposition d’un journal de modifications (ou changelog). De plus, une stratégie de gestion de versions optimale devrait être encouragée, avec par exemple la proposition de versions « long-term support ».

Moyen de test ou de contrôle

Pour valider ce critère :

• Indiquer, dans la description des mises à jour d’une application (changelog ou journal des modifications), s’il s’agit d’une mise à jour de sécurité/maintenance (« corrective ») ou s’il s’agit d’une mise à jour évolutive ajoutant des fonctionnalités.
• S’assurer que les mises à jour évolutives non essentielles à la conformité du service n’empêchent pas le service de fonctionner pendant toute la durée de maintenance des systèmes d’exploitation supportés.
• Garantir, lorsque cela est possible, la possibilité d’installer de façon dissociée les mises à jour essentielles à la conformité et à la sécurité du service numérique ou du terminal de l’utilisateur aux mises à jour évolutives non nécessaires à la conformité du bien.
• Si possible, vérifier la présence d'une stratégie de gestion des versions du service visant à l’optimisation des mises à jour à effectuer, avec par exemple la fourniture de versions du service « Long-term support ».

Niveau de difficulté : Moyen

Niveau de priorité : Modéré

N/A si le service numérique ne propose pas de mise à jour

Métiers concernés : Architecte Logiciel, Porteur de projet, Responsable Qualité, Responsable RSE/Numérique soutenable

Objectif

La mise à jour des applications peut consommer beaucoup de données si l’ensemble du code du service numérique est mis à jour. Ce critère vise à réduire drastiquement la quantité de données nécessaire pour une mise à jour. Cela implique de limiter les mises à jour aux ajouts incrémentaux.

Mise en œuvre

Favoriser les mises à jour incrémentielles (seules les données modifiées sont transférées) ou la séparation du code binaire en petites entités qui ne sont téléchargées que si leur code a changé. L’objectif est de ne pas remplacer tout le code du programme à chaque fois qu'une mise à jour est livrée.

Moyen de test ou de contrôle

Il faut utiliser, lorsque cela est possible, un mécanisme de mise à jour qui ne nécessite pas de remplacer tout le code du programme à chaque mise à jour. Le cas échéant, il est possible de proposer une mise à jour complète du code du programme pour les fonctionnalités de « réinitialisation » ou « d’autoréparation ».

Le critère est validé si les mises à jour incrémentielles sont favorisées pour le service numérique, en dehors des fonctionnalités de « réinitialisation » et « d’autoréparation ».

Niveau de difficulté : Moyen

Niveau de priorité : Modéré

N/A si le service numérique ne repose pas sur l’utilisation de serveur

Métiers concernés : Architecte Système, Architecte Logiciel, Responsable RSE/Numérique soutenable

Objectif

Faire fonctionner des serveurs ou machines virtuelles inutilisés consomme des ressources. Ce critère vise à limiter cette perte en optimisant l’utilisation des environnements de développement, de préproduction ou de test grâce à la mutualisation ou l’extinction de leur fonctionnement sur les plages horaires où ils sont inutilisés.

Mise en œuvre

S’appuyer sur des environnements de développement, de préproduction ou de test mutualisés (par exemple : une machine virtuelle).

Si cela n’est pas possible, désactivez-ces environnements sur les plages horaires où ils sont inutilisés (par exemple la nuit). La remise en service de ces environnements peut se faire automatiquement à une heure donnée, via un signal permettant de savoir qu’ils pourraient être prochainement utilisés, ou manuellement.

Moyen de test ou de contrôle

Le critère est validé si le service s’appuie sur des environnements de développement / préproduction / tests mutualisés, ou bien si ces environnements sont désactivés sur les plages horaires où ils sont inutilisés.

Indiquer dans la déclaration d’écoconception du service numérique les choix réalisés pour limiter les ressources utilisées par les environnements de développement, de préproduction ou de test.

Niveau de difficulté : Faible

Niveau de priorité : Prioritaire

Applicables à tous les services

Métiers concernés : Développeur, Concepteur UX / UI, Responsable Qualité

Objectif

Plus un utilisateur passe de temps sur un site ou une application, plus l’empreinte environnementale associée à cet usage sera élevée, les ressources réseaux et systèmes sur le terminal étant mobilisées plus longtemps. S’il appartient bien entendu à l’utilisateur de décider quel temps il souhaite consacrer à tel ou tel usage, les pratiques de développement du site ou de l’application concernée peuvent avoir un impact direct sur cette durée d’utilisation, en particulier par l’exploitation de pratiques de captation de l’attention.

Le lancement automatique de contenus, en particulier de vidéos, fait partie des mécanismes mis en place pour garder l'utilisateur en état d'attention. Le déclenchement de contenus et leur pré-chargement sans consentement de l’utilisateur doit être évité dans une perspective de sobriété des usages.

Ce critère permet de donner le contrôle à l’utilisateur pour limiter l’usage de ressources non nécessaires.

Mise en œuvre

Désactiver par défaut le chargement et la lecture automatiques de contenus vidéo et/ou sonores dans les paramètres du service. Si ce n’est pas possible, permettre à l’utilisateur de supprimer ces fonctionnalités avec un bouton ou une interface directement accessible et visible.

Autant que possible, ne pas utiliser de graphismes animés non contrôlables, ou encore partiellement contrôlables par l’utilisateur (images gif animées notamment). Les fonds vidéo et/ou audio en lecture automatique devront en particulier être évités, s’ils sont à visée purement esthétique.

Pour les animations jugées essentielles vis-à-vis des fonctionnalités du service, proposer une possibilité à l’utilisateur de mettre en pause ces éléments. 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).

Moyen de test ou de contrôle

Vérifier que le service n’inclut pas de lecture automatique de contenu par défaut. Si ce n’est pas possible, s’assurer que le service numérique donne la possibilité à l’utilisateur de supprimer facilement le chargement ou le lancement automatique de vidéos ou contenus audios. Les possibilités de suppression doivent être mises en évidence dans le service numérique (par exemple, avec un bouton de désactivation apparent dans l’interface utilisateur).

Il conviendra également de limiter au strict nécessaire le nombre d’animations visuelles non contrôlables et de fixer des objectifs quantitatifs à ne pas dépasser. Les animations non contrôlables jugées essentielles vis-à-vis des fonctionnalités du service devront pouvoir être mises en pause par l’utilisateur dès qu’elles dépassent 4 secondes pour l’animation visuelle et 2 secondes pour l’audio.

Le critère est validé si le service ne repose pas sur une fonctionnalité de lecture automatique par défaut et incontrôlée, limite le recours à des animations visuelles, clignotements ou défilements automatiques non contrôlables, en suivant les conditions susmentionnées.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A si le service numérique ne comporte pas d’interaction homme-machine (IHM)

Métiers concernés : Développeur, Designer, Concepteur UX / UI

Objectif

Les « murs de contenu » font partie des stratégies de captation de l’attention de certaines plateformes numériques qui contribuent à l’augmentation de l’empreinte environnementale des services numériques. L’objectif est donc de réduire la conception de services numériques reposant sur un design de « mur de contenus », de liste ou d'enchaînement infini de contenus, ce qui augmente le temps passé sur la page, et donc le poids de cette dernière ainsi que les ressources nécessaires.

Mise en œuvre

Éviter le « mur de contenus », la proposition infinie ou l’enchaînement infini de contenus pour amoindrir le poids de la page utilisée et optimiser l’expérience utilisateur.

Mettre en place une navigation facile d’utilisation et proportionnée au contexte d’utilisation dont le chargement du contenu est à la demande de l’utilisateur (avec par exemple, un bouton « Voir plus » qui permet de poursuivre la navigation ou une pagination).

Moyen de test ou de contrôle

Le critère est validé si le design du service numérique repose sur un chargement à la demande du contenu proportionné au contexte d’utilisation (notamment la mise en place d’un bouton « Voir plus » pour continuer la navigation ou une pagination), ou peut s’afficher en entier sur un écran.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service ne repose pas sur un parcours de navigation

Métiers concernés : Développeur, Concepteur UX / UI, Responsable Qualité

Objectif

Minimiser le temps passé par l’utilisateur sur le service numérique et maîtriser les impacts environnementaux des fonctionnalités principales du service, tout en améliorant l’expérience utilisateur.

Mise en œuvre

Durant la phase de conception, éliminer les fonctionnalités non essentielles et optimiser le ou les parcours de navigation pour chaque unité fonctionnelle principale du service numérique. Observer ensuite les statistiques de fréquentation et d’usage, couplées aux moyens d’observation UX (expérience utilisateur), afin d’améliorer cette optimisation de parcours. Il s’agira de veiller à l’utilité et l’utilisation de chaque fonctionnalité par l’utilisateur. Par exemple, une unité fonctionnelle principale du service peut être « réserver un billet », « rechercher un terme », « trouver une adresse », « contacter le support », « discuter », etc. Il s’agit d’abord d’une analyse qualitative à mettre en place et pouvant être complétée par une analyse quantitative :

• Bien définir les unités fonctionnelles principales du service (au sens de l’analyse de cycle de vie).
• Exploiter toutes les ressources et tous les outils disponibles en UX afin de comprendre au mieux les usages des utilisateurs, notamment en ce qui concerne leurs parcours de navigation de chaque unité fonctionnelle principale.
• Mettre en place un système d’analyse non intrusif et respectueux de la vie privée afin d’identifier les parcours-type sur le service numérique. Analyser de temps en temps ces statistiques pour pouvoir améliorer l’expérience utilisateur et les impacts environnementaux de ces « chemins critiques ».
• Mesurer également les indicateurs techniques des parcours identifiés : nombre de requêtes, poids des ressources téléchargées.

À partir de l’analyse de ces éléments, concevoir et maintenir un parcours de navigation optimisé et des fonctionnalités véritablement utilisées par les utilisateurs.

Moyen de test ou de contrôle

Vérifier la mise en place d’outils UX de conception, d’optimisation et de contrôle continu : tri de carte, sondage, interviews, enquêtes utilisateurs, tests-U, etc.

Contrôler la mise en place de marqueurs destinés à collecter des informations pour alimenter des statistiques d’usage et à suivre les parcours de navigation des utilisateurs : en s’appuyant par exemple sur des outils d'analyse d'audience qui fournissent des informations sur les pages visitées, le temps passé sur chaque page, les actions effectuées, etc.

Il est important de définir des indicateurs techniques pour les parcours identifiés et de vérifier l’optimisation du parcours de navigation ainsi que des fonctionnalités vis-à-vis des besoins et usages des utilisateurs.

Le critère est validé si (conditions cumulatives) :

• Les parcours de navigation sont optimisés et recentrés autour des fonctionnalités essentielles d’après les outils UX et les statistiques d’usages effectuées ;
• Des indicateurs techniques pour les parcours identifiés ont été ou sont en cours de mise en place pour assurer l’optimisation dans le temps du parcours de navigation, à la lumière des retours récoltés.

Niveau de difficulté : Faible

Niveau de priorité : Recommandé

N/A si le service ne repose pas sur un service tiers

Métiers concernés : Développeur, Responsable Qualité, Responsable de la protection des données

Objectif

Limiter le chargement de services tiers non nécessaires au bon fonctionnement du service. Par exemple, sans activation des cookies, certains lecteurs vidéo sont désactivés et en attente de consentement pour le visionnage la vidéo.

Mise en œuvre

En l’absence de criticité vis-à-vis des fonctionnalités essentielles du service, charger uniquement à la demande explicite de l’utilisateur les services tiers sous-jacents au service numérique.

Si le service tiers nécessite de traiter des données personnelles, ce critère s’inscrit dans la continuité de l’une des obligations du RGPD sur la demande de consentement avant l’éventuel traitement de données personnelles, y compris dans le cadre de la fourniture d’un service tiers.

Moyen de test ou de contrôle

Le critère est validé si l’activation des services tiers intégrés au service numérique est conditionnée au consentement clair et explicite de l’utilisateur, du point de vue de la protection des données lorsque applicable, avec également une information spécifique sur le possible coût environnemental.

Niveau de difficulté : Moyen

Niveau de priorité : Modéré

Applicable à tous les services

Métiers concernés : Développeur, Architecte Logiciel

Objectif

Les composants fonctionnels sont par exemple des composants d’interface (menu, bouton, formulaire…). Généralement, les composants natifs d’un système n’ont besoin que de peu de ressources pour fonctionner, contrairement à des composants développés en surcouche. Dans cette perspective, il peut donc être préférable d’encourager l’utilisation de composants natifs d’un système plutôt que le recours à des composants développés en surcouche.

Mise en œuvre

Privilégier l’utilisation des composants fonctionnels natifs du système d’exploitation, du navigateur ou du langage utilisé pour répondre au besoin.

En complément, il est préférable de ne charger les ressources et les composants que lorsqu’ils sont effectivement utilisés.

Moyen de test ou de contrôle

Le critère est validé si le service favorise le recours à des composants fonctionnels natifs lorsque cela est possible.

De plus, dans l’éventualité du recours à des composants non natifs, il convient d’évaluer la nécessité d’utiliser ces composants (contraintes techniques par exemple) et, le cas échéant, de documenter dans la déclaration d’écoconception les raisons de les utiliser. Leur recours devra être régulièrement suivi en vérifiant le contenu des ressources chargées et leur utilisation effective.

Niveau de difficulté : Faible

Niveau de priorité : Recommandé

Applicable à tous les services

Métiers concernés : Développeur, Designer

Objectif

Une partie importante du trafic sur internet est liée au visionnage de vidéos. Les contenus audio et animés représentent également une taille plus importante que le texte et l’image.

Dans une démarche d’écoconception, il est pertinent de minimiser le recours à des contenus médias lourds ayant un but purement esthétique, pour favoriser des solutions alternatives quand elles sont possibles.

Mise en œuvre

Vérifier la pertinence de l’usage de vidéos, animations et contenus audio, c’est-à-dire que ces médias sont fournis dans le cadre des fonctions critiques du service et/ou sont porteurs d’information. Ne pas recourir à des contenus vidéo, animés ou audio purement décoratifs et n’apportant aucune information à l’utilisateur.

Moyen de test ou de contrôle

Evaluer la pertinence du choix d’afficher une animation ou une vidéo ou encore un contenu audio.

Le critère est validé si le service ne contient pas de contenu vidéo, audio ou d’animation à but purement décoratif, c’est-à-dire ne concernant pas les fonctions critiques du service. Dans la déclaration d’écoconception du service, il faudra documenter le motif d’utilisation des contenus vidéo, animés et audio afin de démontrer qu’ils servent les fonctions critiques du service et/ou apportent de l’information à l’utilisateur.

Niveau de difficulté : Faible

Niveau de priorité : Modéré

Applicable à tous les services

Métiers concernés : Développeur, Designer, Responsable Qualité

Objectif

Réduire la taille des ressources utilisées, sachant qu’une vidéo, même encodée avec le procédé le plus efficace, pèse généralement beaucoup plus lourd qu’un texte contenant des images.

Mise en œuvre

Mettre en question et documenter le besoin d’afficher un média (vidéo, animation ou enregistrement audio). Le cas échéant, choisir la solution la plus sobre possible tout en répondant au besoin de l’utilisateur. À titre indicatif, de façon générale : un texte pèse moins qu’une image, une image pèse moins qu’un audio et un audio pèse moins qu’une vidéo.

Moyen de test ou de contrôle

Évaluer la pertinence du choix d’affichage d’une vidéo, d’une animation ou d’un enregistrement audio.

Le critère est validé si le service n’utilise pas de contenu vidéo, audio ou animé, ou si le recours à la vidéo, à l’audio ou à l’animation a été décidé en optant pour le choix de la solution la plus sobre disponible, au regard des besoins et des fonctionnalités essentiels du service. Les choix effectués sont à justifier dans un document public (par exemple, dans la déclaration d’écoconception). La justification prendra en compte les besoins des cibles utilisatrices (voir le critère 1.2.) et à l’impact environnemental du contenu audiovisuel choisi.

Niveau de difficulté : Faible

Niveau de priorité : Modéré

N/A si le service numérique ne comporte pas texte

Métiers concernés : Développeur, Architecte Logiciel

Objectif

Le téléchargement de polices de caractères peut alourdir un service numérique et les ressources informatiques nécessaires à son fonctionnement. Minimiser le nombre de polices téléchargées permet d’accélérer le chargement du service numérique, de potentiellement diminuer les transferts de données à des tiers et de réduire l’empreinte environnementale du service.

L’objectif est donc de limiter le nombre de polices de caractères utilisées pour privilégier, lorsque cela est possible, des polices nativement disponibles, afin de ne pas avoir besoin d’un téléchargement spécifique de la police utilisée. Il s’agit également de réduire la taille des polices téléchargées.

Mise en œuvre

Se fixer comme objectif de n’utiliser au maximum que deux polices différentes et au maximum quatre variantes au total par page ou « unité d’affichage » si la pagination n’est pas utilisée (ou si un seuil par taille de fichier est plus adapté, viser une taille maximale de 400 Ko pour les polices téléchargées). Vérifier la compression des polices ou l’usage des glyphes nécessaires. Dans un contexte de site web, prêter aussi attention sur le mode de chargement : bloquant, non bloquant…

Moyen de test ou de contrôle

Le nombre et le poids des polices de caractères utilisées sont à évaluer. Le critère est validé si les polices téléchargées pour le service respectent au moins l’une de ces conditions :

• Le nombre de polices téléchargées est limité à deux (avec au maximum quatre variantes au total) par page ou « unité d’affichage » (si la pagination n’est pas utilisée pour le service) ;
• La taille des polices téléchargées ne dépasse pas 400 Ko par page ou « unité d’affichage ».

Difficulté : Faible

Niveau de priorité : Modéré

N/A si le service numérique ne comporte pas d’IHM

Métiers concernés : Développeur, Architecte Logiciel

Objectif

Une partie de l’empreinte énergétique des services numériques est liée à la volumétrie des données échangées sur les réseaux. L’objectif est donc de réduire la volumétrie de données pour le service en évitant de réaliser des requêtes client/serveur inutiles (par exemple dans un contexte de formulaire, de suggestion de résultats, etc.). Dans la plupart des cas, cette réduction pourra se faire sans dégradation de l’expérience utilisateur.

Mise en œuvre

Pour réduire les échanges entre serveurs et utilisateurs, il est important que les services numériques réduisent les appels à des API, scripts, librairies ou polices de caractères tiers.

Il est conseillé de limiter la complétion automatique en ligne. Ces mécanismes d’autocomplétion ou de suggestion qui visent à compléter automatiquement ou suggérer des options nécessitent beaucoup de requêtes vers le serveur. Si un tel mécanisme est mis en place car justifié du point de vue utilisateur, il est préconisé d’attendre par exemple d’avoir trois caractères et 500 ms après chaque saisie avant de lancer une requête réseau. Alternativement, il est possible de laisser le choix à l’utilisateur d’activer l’autocomplétion s’il le souhaite (opt in) via un élément de configuration.

Moyen de test ou de contrôle

Pour valider le critère, s’assurer que le service ne propose pas d’autocomplétion ; dans le cas contraire, vérifier que l’autocomplétion est justifiée du point de vue de l’utilisateur et contrôler périodiquement que l’autocomplétion attend un délai d’au moins 500 ms avant de s’activer et au moins 3 caractères saisis. L’interface utilisateur permet de désactiver l’autocomplétion.

Le nombre de requêtes HTTP entre client et serveur est à contrôler et à suivre dans le temps.

De même, examiner périodiquement l’absence de requêtes identiques et redondantes.

Vérifier que les requêtes externes effectuées en appelant le site (en vidant le cache ou en utilisant une extension appropriée) sont effectivement celles nécessaires à l’exécution du service.

Niveau de difficulté : Faible

Niveau de priorité : Modéré

N/A si le service numérique ne repose pas sur un formulaire

Métiers concernés : Concepteur UX / UI, Développeur

Objectif

Limiter les échanges client/serveur en vérifiant la saisie du côté du terminal utilisateur, réduisant ainsi les erreurs de saisie et les soumissions de formulaires incorrects qui nécessiteraient un retour vers le serveur pour une correction.

Mise en œuvre

Les formats de saisie attendus devraient être définis et indiqués de façon claire et explicite lors de la saisie de l’utilisateur avant la soumission du formulaire (par exemple sous la forme de textes d’aide, d’exemples ou de formats par défaut contraints). En cas d’erreur, le champ concerné et le correctif à effectuer devraient être indiqués de façon précise.

Il convient de valider les saisies et les formats de données obligatoires à la soumission d’un formulaire sans requête serveur lorsque c’est possible. Cela peut être réalisé en utilisant des fonctionnalités de validation intégrées aux langages de programmation web, tels que JavaScript. Attention : prévalider les données côté frontend n’exempte pas la validation côté backend. Une validation supplémentaire côté serveur reste donc nécessaire pour assurer l’intégrité des données.

Moyen de test ou de contrôle

La mise en œuvre est à contrôler en testant le parcours d’utilisation du service ou en effectuant à la conception une revue de son code source afin d’examiner que les indications de format attendu sont correctement spécifiées du côté du terminal de l’utilisateur. Tester le service en remplissant le formulaire avec des données incorrectes ou manquantes et en vérifiant que des messages d'erreur appropriés sont affichés pour indiquer les erreurs de saisie.

Le critère est validé si l’utilisateur est informé des formats de saisie attendus avant la soumission du formulaire. Les saisies et les formats de données obligatoires du service devront également être validés d’abord côté client avant la soumission du formulaire.

Niveau de difficulté : Moyen

Niveau de priorité : Modéré

N/A si le service numérique ne repose pas sur un transfert de fichier client/serveur dans le cadre d’un formulaire

Métiers concernés : Concepteur UX / UI, Développeur, Architecte Logiciel

Objectif

Limiter les échanges client/serveur de fichiers volumineux en informant l’utilisateur des prérequis attendus.

Mise en œuvre

• Fichiers téléchargés : Indiquer clairement à l’utilisateur, au minimum pour les fichiers de plus de 10 Mo et avant le transfert, des poids et des formats de fichier attendus : un type de fichier, une taille maximale d’image, etc.
• Fichiers téléversés (ou upload) : la soumission du formulaire n’est pas possible si les prérequis indiqués de poids et de format de fichier ne sont pas respectés. La limite mise en place doit toutefois prendre en compte tous les usages, y compris ceux nécessitant un envoi des fichiers volumineux, car bloquer la démarche numérique de l’utilisateur serait contreproductif. Il est important également de prendre en charge les nouveaux formats de fichiers (exemple : images WebP et AVIF en plus des images JPEG et PNG) afin d’éviter d’imposer à l’utilisateur de passer par une étape de conversion contreproductive.
  À noter : les limitations devront être définies de façon proportionnée afin de ne pas engendrer d’effet de bord négatif sur l’accessibilité du service, en tenant compte des cibles utilisatrices.

Moyen de test ou de contrôle

Le critère est validé si :

• Fichiers téléchargés : les informations sur les poids et formats de fichier attendus pour le service sont correctement affichées à l'utilisateur avant le transfert, au minimum pour les fichiers de plus de 10 Mo. Un moyen de test peut consister à vérifier cet affichage préalable au transfert de fichier avec différents types et tailles de fichiers.
• Fichiers téléversés ou upload : des limitations de poids et de formats de fichiers sont mises en œuvre et sont affichées clairement pour l’utilisateur du service numérique (hors situation spécifique où de telles limitations nuiraient à l’utilisation du service).

Contrôler la mise en œuvre en vérifiant que les limites de poids et de formats de fichiers sont spécifiées puis correctement appliquées lors de la soumission du formulaire.

Niveau de difficulté : Faible

Niveau de priorité : Recommandé

N/A si le service numérique ne comporte pas d’IHM

Métiers concernés : Concepteur UX / UI, Développeur, Architecte Logiciel, Responsable RSE/Numérique soutenable

Objectif

Matérialiser pour l’utilisateur les impacts environnementaux des actions les plus coûteuses. Informer les utilisateurs en amont des impacts environnementaux avant l’utilisation d’une fonctionnalité, lorsque cette dernière est plus coûteuse par rapport au reste du service.

Mise en œuvre

Pour chaque fonctionnalité du service qui est considérée comme ayant des impacts environnementaux importants, afficher une information préalable à l'utilisateur. Par exemple, pour chaque fichier téléchargeable, vidéo en « haute qualité » ou média consommateurs en ressources consulté, ou pour un traitement long, comme un export de données, une information relative au poids du fichier ou le temps requis pour l’opération est préalablement affichée à l’utilisateur. Proposer, si possible une fonctionnalité substituable avec un plus faible impact (par exemple : mode « écoute seule » au lieu du visionnage d’une vidéo « haute qualité », voir critère 5.5).

Dans l’éventualité où il est possible d’ajouter une information concernant des équivalences en impacts environnementaux, veiller à préciser la source et la méthodologie, et à favoriser une approche multicritère (pas uniquement en équivalent CO₂). L’analyse d’impact décrite au critère 1.5 peut permettre d’identifier les fonctionnalités avec un poids environnemental significatif.

Moyen de test ou de contrôle

Contrôler la mise en œuvre en vérifiant que les fonctionnalités avec un impact environnemental significatif sont identifiées et signalées à l’utilisateur. Cet examen doit être documenté et pouvoir être audité par un tiers : en rendre compte, si possible, dans la déclaration d’écoconception.

Le critère est validé si le service ne comprend pas de fonctionnalités ayant un impact environnemental significatif ou si les informations relatives aux impacts environnementaux sont correctement affichées pour les fonctionnalités spécifiques identifiées comme ayant des conséquences significatives en termes de consommation de bande passante, énergétique ou de ressources informatiques. L’ajout d’une équivalence avec des indicateurs environnementaux dans l’affichage à l’utilisateur n’est pas obligatoire pour valider le critère.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A si le service numérique ne comporte pas d’IHM

Métiers concernés : Concepteur UX / UI, Développeur

Objectif

De nombreuses applications sont configurées par défaut pour adresser à l’utilisateur des notifications sur leur terminal. Il s’agit d’incitations à l’usage du service et du terminal associé (le cas échéant). L’objectif est donc de réduire l’usage de ressources informatiques en évitant d’attirer inutilement l’attention de l’utilisateur ou en consommant inutilement des ressources informatiques.

Il convient donc de minimiser le nombre de notifications, de réfléchir à leur inclusion par défaut dans le design du service numérique et de donner à l’utilisateur la possibilité de les désactiver.

Mise en œuvre

Les notifications envisagées par le service numérique sont dans l’intérêt de l’utilisateur en termes de besoin. Les notifications évitent également la multiplication sur différents canaux redondants (SMS, mail, notification d’application, notification d’interface, pop-in, etc.).

Il s’agit donc de proposer une configuration par défaut limitant les notifications.

L’utilisateur peut désactiver les notifications ou choisir la fréquence de réception de ces notifications.

Moyen de test ou de contrôle

Suivre la fréquence et la quantité des notifications, en se fixant des objectifs chiffrés en la matière.

Documenter les choix faits en matière de réduction au strict minimum des notifications dans la déclaration d’écoconception.

Le critère est validé si le service numérique :

• Ne propose pas de notification ou propose par défaut un nombre de notifications limité (un seuil inférieur à cinq par jour devrait être visé) ;
• Donne à l’utilisateur la possibilité de désactiver et de réduire, via son interface, les notifications proposées par le service de façon simple et rapide (par exemple, un bouton directement visible sur l’interface utilisateur). Les possibilités de suppression ou de réduction des notifications doivent être mises en évidence dans le service numérique.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service numérique ne comporte pas d’IHM

Métiers concernés : Concepteur UX / UI, Développeur, Responsable Marketing

Objectif

Prévenir l'utilisation de dark patterns ou procédés manipulatoires dans l'interface utilisateur afin d'assurer le contrôle des utilisateurs de leurs usages numériques. Les dark patterns sont des éléments de conception volontairement mis en place pour tromper ou manipuler les utilisateurs et pour en influencer le comportement. Depuis l’entrée en vigueur du paquet législatif sur les services numériques (le DSA ou « Digital Services Act », règlement 2022/2065) en 2022, la conception ou l’exploitation d’interfaces en ligne trompeuses ou destinées à manipuler le destinataire du service par les fournisseurs de plateformes en ligne est proscrite. Dans la continuité de ces obligations légales, l’objectif de ce critère est d’éviter le recours à des éléments manipulatoires dans l’interface utilisateur susceptibles d’engendrer des surcroîts d’usages en ligne, responsables de coûts environnementaux additionnels.

Mise en œuvre

Il s’agit de prévenir la mise en place de dark patterns dans la conception de l’interface utilisateur. Si le service est en phase d’usage, examiner son interface utilisateur pour identifier et éliminer l’utilisation de dark patterns. Quelques exemples de pratiques de dark patterns à éviter :

• Mise en place de parcours de navigation « labyrinthe » qui complexifie la possibilité des utilisateurs de faire certaines actions (désabonnement, désinscription) ou rend difficile l’accès à des informations sur les mentions légales, l’empreinte environnementale du service par exemple ;
• Affichage de publicité déguisée ou d’exit pop-up publicitaire sans sélection ou choix de l’utilisateur ;
• Définition d’une option présélectionnée pour l'utilisateur, souvent sous la forme d'une case pré-cochée, dans le but de l'inciter à accepter quelque chose qu'il n'aurait peut-être pas choisi délibérément ;
• Affichage un compte à rebours pour une offre spéciale, mais chaque fois que le compte à rebours atteint zéro, il recommence, créant une fausse urgence.

Le guide de l’association Designers Éthiques peut également aider à repérer et corriger les éventuels éléments trompeurs de l’interface utilisateur.

Moyen de test ou de contrôle

Ne pas inclure de dark patterns dans le design du service et effectuer une évaluation régulière de l'interface utilisateur pour détecter et prévenir leur présence. Cette évaluation doit prendre en compte les travaux de la Commission européenne (y compris les lignes directrices publiées en application de l’article 25 du règlement 2022/2065).

Le critère est validé si l'interface utilisateur ne contient pas de dark patterns.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service numérique ne comporte pas d’IHM

Métiers concernés : Concepteur UX / UI, Développeur, Responsable RSE/Numérique soutenable

Objectif

L’objectif est la limitation de l’impact environnemental en donnant de l’autonomie à l’utilisateur pour limiter les impacts environnementaux de ses usages.

Mise en œuvre

Le service numérique devrait informer l’utilisateur sur son temps d’utilisation et sur l’impact environnemental associé à l’usage du service. Cette information, comme toute allégation environnementale, devra utiliser les normes et standards reconnus de quantification et calcul d’impact (par exemple, les « Product Category Rules », développées pour les services numériques par l’ADEME). L’utilisateur devrait également avoir la possibilité, par défaut ou à sa demande, de choisir des modes d’affichage et d’usage « sobres », permettant de réduire les ressources utilisées et la consommation énergétique.

En ce qui concerne les services et contenus vidéo, il est conseillé de se référer à la recommandation article 26 de la loi du 15 novembre 2021 visant à réduire l'empreinte environnementale du numérique (loi REEN), publiée par l’Arcom, en lien avec l’Arcep et l’ADEME, quant à l'information des consommateurs par les services de télévision, les services de médias audiovisuels à la demande et les services de plateformes de partage de vidéos en matière de consommation d'énergie et d'équivalents d'émissions de gaz à effet de serre, sur la consommation de données liée à l'utilisation de ces services.

Moyen de test ou de contrôle

Le critère est validé si le service numérique respecte les conditions cumulatives suivantes :

• Le service affiche sur son interface une information à destination des utilisateurs sur l’empreinte environnementale de l’usage du service.
• Le service numérique propose un mode d’affichage et d’usage sobre, par défaut ou dont l’activation est laissée à la discrétion de l’utilisateur, pour diminuer l’empreinte environnementale associée à son usage. L’utilisateur pourra avoir accès à une information détaillant les paramètres de ce mode « sobriété énergétique » et les gains environnementaux associés.

Documenter les actions mises en place dans la déclaration d’écoconception, en particulier l’information environnementale délivrée à l’utilisateur et le paramétrage du mode de « sobriété énergétique », y compris les gains environnementaux associés.

Niveau de difficulté : Faible

Niveau de priorité : Recommandé

N/A si le service numérique n’utilise pas d’image matricielle (ou images bitmap)

Métiers concernés : Développeur, Architecte Logiciel

Objectif

La réduction des volumes de données transmises associées aux images matricielles (ou images bitmap) est un levier d’optimisation du trafic internet et de minimisation de la consommation en ressources associée. L’objectif est donc d’optimiser le poids des fichiers téléchargés par les utilisateurs en utilisant des formats d’image performants.

Mise en œuvre

Choisir le format image adapté à la typologie d’image et au contexte d’affichage :

• Format vectoriel (exemple SVG) : utiliser ce format lorsque cela est possible (illustrations, icônes, logos, graphes…) ;
• Format matriciel, compression sans perte ou « lossless » (c’est le mode de compression du PNG) : pour des illustrations avec aplats de couleur (remplacer le PNG peu efficace par des images WebP ou JPEG XL, en mode « compression sans perte ») ;
• Format matriciel, compression avec perte (c’est le mode de compression du JPEG) : pour des photos ou des illustrations avec des milliers de couleurs (remplacer le JPEG peu efficace par des images WebP, AVIF ou JPEG XL en mode « compression avec perte »).

Moyen de test ou de contrôle

Vérifier périodiquement que les images matricielles ne sont plus dans les formats JPEG, PNG ou GIF. Utiliser WebP, AVIF, JPEG XL ou un format d’image plus performant pour les images matricielles. Le critère est validé si plus de 75 % des images matricielles utilisées pour le service numérique sont dans un format efficace (WebP, AVIF, JPEG XL ou un format d’image plus performant).

Un service numérique qui propose chaque image dans deux formats (exemple : JPEG XL avec un fallback vers JPEG / PNG pour les navigateurs non compatibles) valide également le critère si un des formats est WebP, AVIF, JPEG XL ou un format d’image plus performant.

Pour aller plus loin

Support des formats d’image selon les navigateurs web :

Une étude de Greenspector, réalisée par Olivier Philippot en 2022, montre que la consommation électrique d’un smartphone (Samsung Galaxy S10 sous Android 10 avec une connexion Wi-Fi) est légèrement plus faible en présence d’image WebP ou AVIF, comparé à la compression JPEG.

• WebP est un format d'image matricielle développé et mis à disposition du public par Google en 2010 (2012 pour la compression sans perte de qualité). Aujourd’hui WebP est supporté par l’ensemble des navigateurs web depuis 2020 et procurerait de 30 à 80 % de réduction d'espace face à JPEG et PNG, sans dégrader la qualité.
• AVIF est un format d'image matricielle développé par le consortium Alliance for Open Media et finalisé en 2019, AVIF est supporté par l’ensemble des navigateurs web depuis janvier 2024. La compression en mode « avec perte » AVIF est plus efficace que celle de WebP, toutefois la compression en mode « lossless » sans perte de qualité est moins efficace que WebP.
• JPEG XL est un format d’image matricielle plus récent et plus efficace en termes de compression que WebP / AVIF en mode avec/sans perte. Contrairement à WebP ou AVIF, JPEG XL n’est pas, à date, supporté par l’ensemble des navigateurs web.
• SVG est un format d’image vectoriel. La principale problématique provient de la façon de gérer les caractères dans les images SVG. Afin de permettre une compatibilité avec toutes les plateformes, il est préférable de convertir le texte en chemin vectoriel, afin de ne pas faire appel à des polices de caractères externes.

Voici un tableau détaillant le support des formats d’image par navigateur, afin d’aider au choix du format à utiliser :

Un service numérique peut choisir d’encoder ses images dans deux formats d’image : JPEG XL avec un fallback en JPEG / PNG ou WebP sera présent, afin de prendre en charge les navigateurs web qui ne supportent pas encore le format JPEG XL.

Difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service numérique n’utilise pas d’image matricielle (ou images bitmap)

Métiers concernés : Développeur, Architecte Logiciel

Objectif

Réduire le poids des images téléchargées par les utilisateurs en augmentant le niveau de compression (et donc en dégradant légèrement la qualité) ou/et en proposant des résolutions multiples.

Mise en œuvre

Lors de la génération d’une image matricielle, en mode compression avec perte (c’est le mode de compression du JPEG), la compression à une qualité de 70 % (JPEG), 72 % (WebP) ou 56 % (AVIF) peut être visuellement acceptable.

Tableau pour faire une conversion approximative de la qualité de compression (en %)  entre JPEG, WebP et AVIF : (source industrialempathy.com)

Les formats de compression sans perte de la qualité de l’image (PNG, WebP en mode « compression sans perte », JPEG XL en mode « compression sans perte ») ne disposent pas de paramétrage de qualité, la compression ne dégradant pas la qualité de l’image. Il est toutefois possible de réduire significativement la taille en réduisant la palette de couleurs de l’image avant compression.

Des résolutions multiples peuvent être pertinentes, via les attributs « srcset » et « sizes », afin de s’adapter automatiquement à la résolution du terminal depuis lequel est consulté le site. Il faut toutefois faire attention que cela n’empêche pas le service d’adopter un « Responsivedesign ».

Moyen de test ou de contrôle

Évaluer la qualité et le poids des images matricielles affichées sur différents types de terminaux.

Pour le mode de compression avec perte, documenter dans la déclaration d’écoconception la politique de paramétrage de la qualité lors de la génération ou conversion des images.

Niveau de difficulté : Faible

Niveau de priorité : Prioritaire

N/A pour la diffusion de vidéos par multicast/broadcast

Métiers concernés : Développeur, Architecte Logiciel, Porteur de projet

Objectif

Il arrive parfois que le contenu vidéo soit en haute définition alors que le contexte de visualisation n’en a pas besoin, ce qui a pour effet d’augmenter la consommation énergétique du terminal et la quantité de données transférées. Il est donc important d’ajuster précisément la définition vidéo par défaut au terminal utilisé et de donner de l’autonomie à l’utilisateur pour limiter les impacts environnementaux de ses usages en lui permettant de réduire ou d’augmenter la définition de la vidéo.

L’objectif est ainsi de limiter les ressources informatiques et la consommation énergétique associée au visionnage de vidéos. Le critère est applicable aux vidéos diffusées en unicast, terme définissant une connexion réseau point à point, c'est-à-dire d'un hôte vers un (seul) autre hôte. C’est le mode de diffusion utilisé sur internet.

Le critère n’est pas applicable au multicast/broadcast, puisque cela engendrerait une multiplication des flux contreproductive. Les diffusions de type multicast/broadcast concernent uniquement certains modes de diffusion TV (par exemple : TNT, certains flux transmis via le décodeur TV) et désigne une forme de diffusion d’un émetteur unique vers un groupe de récepteurs.

Mise en œuvre

La mise en œuvre diffère selon le fait que le service numérique est en mesure ou pas de proposer de multiples définitions vidéo pour un même contenu.

Si le service numérique est en en mesure de proposer de multiples définitions vidéo pour un même contenu :

• Etablir une définition par défaut ne doit pas dépasser les définitions du mode « qualité standard » défini ci-après.
• Définir un mode « sobriété énergétique » (qui peut également être appelé « économie de données ») qui doit être facilement accessible sur l’interface. Son activation baisse la définition, de manière à ne pas dépasser les définitions du mode « sobriété énergétique » défini ci-après. Le service numérique doit être en mesure de mémoriser ce choix et de l’appliquer pour les prochaines lectures de vidéos.
• De manière optionnelle, proposer un mode « haute qualité » =, utilisé uniquement sur demande de l’utilisateur (en l’informant le cas échéant que le recours à ce mode « haute qualité » peut avoir un impact sur la quantité de données transmises et la consommation énergétique).

Définition maximum selon le terminal et le mode :

Si le service numérique unicast qui ne peut pas gérer de multiples définitions vidéo pour un même contenu, choisir la plus faible définition possible sans que cela altère sa compréhension ou l’expérience utilisateur : définition vidéo de 720p pouvant être portée à 1080p pour un contenu difficilement lisible (par exemple : vidéos avec du texte dans une petite police de caractères).

Moyen de test ou de contrôle

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.

Contrôler la facilité d’accès au mode « sobriété énergétique » (qui peut également être appelé « économie de données ») tel que décrit dans la partie « Mise en œuvre ».

Pour valider ce critère, documenter dans la déclaration d’écoconception les définitions proposées selon les types de terminaux, l’action du mode « sobriété énergétique », son emplacement et sa capacité à mémoriser le choix de l’utilisateur.

Pour aller plus loin 

Les différentes définitions à utiliser lors de l’encodage vidéo

Plusieurs leviers peuvent être déployés pour optimiser l’impact environnemental de la vidéo en agissant en particulier sur la définition et l’encodage de la vidéo.

Pour proposer différentes définitions de vidéos au terminal, il faut avoir au préalable encodé chaque vidéo dans différentes définitions.

L’encodage vidéo entraîne deux types de coûts environnementaux :

• Coût processeur pour l’encodage ;
• Coût de stockage.

Un service écoconçu doit limiter le nombre d’encodages. Certains services vidéo proposent plus de 20 encodages d’une même vidéo, afin de couvrir plusieurs codecs et définitions vidéo.

Exemple d’une solution sobre, avec seulement trois définitions :

• Encodage 480p : pour le mode « sobriété énergétique » ;
• Encodage 720p : pour le mode « qualité standard » ;
• Encodage 1080p : pour le mode « haute qualité ».

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A si le service numérique ne propose pas de vidéos

Métiers concernés : Développeur, Architecte Logiciel

Objectif

La majeure partie du trafic sur internet est liée au visionnage de vidéos (la vidéo représente près de 66 % du trafic internet en 2023 selon le rapport de Sandvine The Global Internet Phenomena Report). Or le transport de données numériques s’appuie sur des infrastructures ainsi que l’usage d’équipements et de terminaux qui ont une empreinte environnementale à minimiser. L’emploi d’un codec vidéo efficace (à date : AV1, VP9 et HEVC) permet de réduire significativement la bande passante utilisée.

Par ailleurs, le mode de décodage du codec vidéo par le terminal influe directement sur la consommation énergétique de l’appareil. Si le codec n’est pas accéléré matériellement par le processeur graphique (GPU), la lecture vidéo sera possible, mais via le microprocesseur (CPU). Dans ce cas, la consommation d’énergie du terminal sera plus importante, ce qui va diminuer l’autonomie d’un terminal sur batterie et possiblement sa durée de vie.

L’objectif est donc d’optimiser la taille des flux téléchargés par les utilisateurs et les ressources mobilisées grâce à l’utilisation d’un codec et d’un encodage efficaces.

Mise en œuvre

Les vidéos sont proposées avec au moins un codec performant (à date : AV1, VP9 et HEVC) tenant compte de l’efficacité de compression du codec et son accélération matérielle dans les définitions 720p et au-delà. H.264 peut être proposé en complément du codec performant.

Pour économiser de la bande passante sur les scènes simples à encoder, un encodage à débit variable doit être préféré. Ce mode d’encodage peut dans certains cas être associé à un plafond pour le débit maximal afin d’assurer que les contenus plus complexes restent lisibles avec une connexion internet à bas débit.

Par ailleurs, la qualité d’encodage de la vidéo devrait être adaptée au besoin de l’utilisateur. Par exemple, utiliser le niveau de qualité le plus faible sans dégrader la vidéo visuellement dans le contexte d’utilisation.

La qualité d’encodage des flux audio devrait être adaptée au besoin de l’utilisateur :

• Optimisation du bitrate (débit), du ratio (taux de compression) et de la fréquence d’échantillonnage au sein du format ;
• Choix adapté de nombre de canaux : stéréo pour de la musique ou mono pour des dialogues (voir critère 5.6. dédié à l’audio).

Moyen de test ou de contrôle

Le critère est validé si le service remplit les conditions suivantes :

• Les vidéos sont encodées avec un débit variable, quel que soit le codec vidéo utilisé. Ce mode d’encodage peut dans certains cas être associé à un plafond pour le débit maximal afin d’assurer que les contenus plus complexes restent lisibles avec une connexion internet à bas débit.
• Les vidéos disponibles sur le service numérique ont une définition inférieure à 720p ou sont proposées avec un codec vidéo efficace, à date AV1, VP9 ou HEVC (pour les vidéos encodées en 720p ou plus). Le codec H.264 peut être utilisé en secours, en cas d’incompatibilité, à condition qu’un codec plus performant soit proposé aux terminaux compatibles.
• Le ou les codecs utilisés sont accélérés matériellement par la majorité du parc des terminaux.
• Sont documentés dans la déclaration d’écoconception du service numérique le(s) codec(s) vidéo et audio utilisé(s) pour chaque définition vidéo, le type d’encodage vidéo : débit fixe, variable, variable avec débit maximum/présence de HDR, et le type d’encodage audio : débit, nombre de canaux.

Pour aller plus loin

Liste des codecs vidéo utilisables sur internet, par performance de compression, avec les dates d’introduction de l’accélération matérielle proposée dans les processeurs graphiques des terminaux : 

* Il convient de noter que l’introduction de l’accélération matérielle GPU correspond à l’année de sortie du processeur avec cette accélération matérielle. La date d’introduction de l’accélération matérielle doit être comparée avec la date de lancement du processeur graphique et non du terminal.

Pour la mise à disposition de vidéos sur internet en 2024, quatre codecs vidéo récents sont principalement utilisés : H.264, HEVC (ou H.265), VP9 et AV1.

H.264 AVC : le codec vidéo le plus utilisé

H.264, également appelé MPEG-4 AVC, est utilisé par la quasi-totalité des plateformes proposant de la vidéo sur internet (certaines plateformes proposent leurs vidéos dans plusieurs codecs, mais H.264 est presque systématiquement proposé). Il semble consommer davantage de données que les codecs plus récents à ce jour.

Le codec est bien supporté matériellement et logiciellement. Le codec vidéo H.264 est aussi supporté par l’ensemble des navigateurs web depuis 2015. Cependant les codecs vidéo développés plus récemment présentent des performances plus avancées en termes d’efficacité de compression.

HEVC : le codec de la TNT UHD

HEVC, également appelé H.265, a été spécifié en 2013. HEVC permet un gain en compression sur H.264. Il s’agit d’un codec dont les droits d’utilisation sont payants.

Si HEVC est bien pris en charge dans l’écosystème Apple et sur les box TV, ce n’est pas le cas des navigateurs web, à l’exception de Safari.

VP9 : le codec ouvert le plus répandu

VP9 est un codec vidéo ouvert et sans redevance, développé par Google. VP9 permet, comme HEVC, un gain en compression sur H.264. Autre point qu’il partage avec HEVC : la très grande majorité des terminaux utilisés en France ont une accélération matérielle, permettant une faible consommation d’énergie sur le terminal lors de la lecture de vidéos ayant recours à ce codec.

Le codec VP9 est supporté par tous les navigateurs web depuis 2018, sauf sur Safari sur iPhone et iPad où la version 17.4 de iOS / iPadOS est nécessaire (version proposée depuis avril 2024).

AV1 : le codec le plus récent

AV1 est le codec vidéo présent le plus récent, spécifié en 2018 par l’Alliance for Open Media. Il est ouvert et sans redevance. AV1 semble permettre un gain en compression sur VP9 ou HEVC et un débit divisé par deux par rapport à H.264, sans dégradation de la qualité.

Néanmoins, l’accélération matérielle de ce codec vidéo est limitée à certains terminaux de dernière génération. Toutefois, le parc de terminaux avec un décodage matériel d’AV1 augmente rapidement.

Pour les années 2024 à 2026, le codec VP9 semble l’un des meilleurs compromis en termes d’écoconception (au-delà de 2026, cela pourrait être AV1) :

• Performant : le taux de compression de VP9 semble sensiblement moindre que celui d’AV1, mais il permet aux vidéos d’avoir un gain moyen de 30 % de bande passante sur H.264.
• Faible consommation d’énergie : la prise en charge matérielle de la quasi-totalité des terminaux permet d’avoir une consommation d’énergie très faible. Sur un smartphone ne prenant pas en charge AV1, c’est le codec le plus économe en énergie.
• Pris en charge par tous les navigateurs récents.

Sources :

• Rapport sur l’état de l’internet en France, Arcep, 2023
• Étude « VP9 encoding/decoding performance vs. HEVC/H.264 », Ronald S. Bultje, 2015
• Étude « AV1 beats x264 and libvpx-vp9 in practical use case », Meta, 2018

Niveau de difficulté : Fort

Niveau de priorité : Prioritaire

N/A si le service numérique ne propose pas de contenu vidéo avec piste audio

Métiers concernés : Développeur, Responsable IT

Objectif

Une partie significative du trafic vidéo sur internet est constitué de vidéos qui sont écoutées (source : étude de Chris Priest, de l’université de Bristol au Royaume-Uni sur l’usage d’un bouton « audio-seul » sur l’application YouTube de mai 2019) :

• Vidéos musicales utilisées en fond sonore ;
• Podcasts filmés écoutés et non visionnés ;
• Émissions écoutées pendant une autre activité.

Le premier objectif est de réduire le trafic en permettant à l’utilisateur de couper son flux vidéo via une option « écoute seule », « audio only » , ou « zéro pixel » afin de réduire le trafic généré par la vidéo qui n’est pas regardée.

Le second objectif est de réduire la consommation d’énergie des terminaux en leur permettant d’activer l’écoute de la piste audio d’une vidéo lorsque l’écran est éteint.

Mise en œuvre

Proposer une option permettant à l’utilisateur de basculer en mode « écoute seule » simplement sur le lecteur vidéo (et si possible de repasser en mode vidéo, s’il souhaite regarder de nouveau la vidéo). En mode « écoute seule », le flux vidéo n’est plus téléchargé par le lecteur vidéo, qui se limite au flux audio.

Basculer automatiquement les vidéos en « écoute seule » quand le service numérique détecte que le média n’est plus visualisé ou que l’utilisateur éteint son écran. Par exemple :

• Utilisation de service numérique sur smartphone / tablette / équipement connecté (application native ou via un navigateur web) : le fait d’appuyer sur le bouton de mise en veille doit basculer la vidéo en mode audio seul, de façon à permettre à l’utilisateur de continuer à écouter la vidéo en limitant fortement la consommation d’énergie, l’écran étant éteint et seules les données nécessaires à l’audio étant transférées.
• Si le service numérique est utilisé dans un navigateur web, le fait de passer dans un autre onglet que celui de la vidéo doit déclencher le mode « écoute seule ». Quand l’utilisateur affiche de nouveau l’onglet de la vidéo, celle-ci peut rebasculer en mode vidéo.

Dans le cas d’un service numérique qui utilise une plateforme de vidéo ne proposant pas de mode « écoute seule », une alternative est de proposer sous la vidéo un lien vers la version audio, afin de permettre à l’utilisateur de choisir son mode de diffusion.

Moyen de test ou de contrôle

Le critère est validé si :

• Le service propose un mode « écoute seule » sur les vidéos, activable à la demande de l’utilisateur et qui s’enclenche lorsqu’il peut être détecté que la vidéo n’est pas affichée sur le terminal (par exemple : changement d’onglet dans un navigateur ou d’application sur un terminal, fermeture d’écran, etc.). Dans l’éventualité où les vidéos du service sont déjà hébergées par un service tiers qui ne propose pas ce mode « écoute seule », il est possible de valider le critère en proposant un enregistrement « écoute seule » sous chaque vidéo (sans préchargement de la vidéo associée).
• Sont documentés dans la déclaration d’écoconception du service numérique l’emplacement et le fonctionnement du mode « écoute seule ».

Niveau de difficulté : Faible

Niveau de priorité : Modéré

N/A si le service numérique ne propose pas de contenu audio

Métiers concernés : Développeur, Responsable IT

Objectif

Réduire la taille des contenus audio téléchargés par les utilisateurs et donc les ressources informatiques nécessaires.

Mise en œuvre

Afin de réduire la taille des contenus audio, envisager les actions suivantes :

• Utiliser des codecs audio efficaces (à date : Opus, AAC, HE-AAC, HE-AAC v2, HD-AAC, Dolby E-AC-3 ou Dolby AC-4), en évitant les formats les plus volumineux. L’ensemble des navigateurs web supportent un flux audio seul (sans vidéo accompagnant le flux audio) avec le codec Opus, dans un conteneur WebM et avec le codec AAC, dans un conteneur MP4.
• Optimiser le bitrate (débit), le ratio (taux de compression) et la fréquence d’échantillonnage au sein du format.
• Faire un choix adapté : stéréo pour de la musique ou mono pour des dialogues.
• Éviter le ratio poids en mégaoctet/durée en minute supérieur à 1.

Moyen de test ou de contrôle

Le critère est validé si le service remplit les conditions suivantes :

• Les contenus audio disponibles sur le service numérique sont proposés avec un codec audio efficace, à date Opus, AAC ou Dolby AC-4 (un codec non efficace peut être proposé en fallback, à condition qu’un codec plus performant soit proposé aux terminaux compatibles).
• Le(s) codec(s) audio utilisé(s) et le type d’encodage audio (débit, nombre de canaux) sont documentés dans la déclaration d’écoconception du service numérique.

Niveau de difficulté : Moyen

Niveau de priorité : Modéré

N/A si le service numérique ne repose pas sur l’utilisation de fichiers

Métiers concernés : Développeur, Responsable IT

Objectif

Réduire le poids des fichiers téléchargés par les utilisateurs.

Mise en œuvre

Définir les paramètres de compression des documents afin de générer des fichiers de taille réduite.

Prendre en compte les besoins spécifiques du contenu et du contexte d'utilisation pour déterminer le format de fichier le plus approprié. Par exemple utiliser une image vectorielle si c’est plus pertinent qu’une image matricielle (ou images bitmap), constituée de pixels.

Avoir notamment recourt à un format de fichier optimisé pour une visualisation en ligne, lorsque le document est destiné à être consulté en ligne.

Moyen de test ou de contrôle

Évaluer le poids du document en fonction de son contenu. Le critère est validé si les documents utilisés pour l’opération du service numérique sont compressés de façon à réduire leur poids et à s’adapter au contexte de visualisation, d’utilisation, et à leur contenu. La stratégie de compression des documents doit être documentée et auditable par un tiers, par exemple en étant détaillée dans la déclaration d’écoconception du service numérique.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service ne gère pas de contenu

Métiers concernés : Architecte Logiciel, Data Scientist, Responsable de la sécurité informatique, Responsable Juridique

Objectif

Alléger les bases de données et les serveurs physiques de données non utiles.

Mise en œuvre

Définir une stratégie d’archivage et de suppression des contenus obsolètes, périmés, dépassés ou inutiles à conserver dans le service numérique. Cette stratégie peut être automatique en définissant une date d’expiration et un processus d’archivage et/ou de purge automatique.

De façon complémentaire à des mécanismes d’archivage automatique, prévoir également des mécanismes de suppression manuelle pour les contenus spécifiques qui nécessitent une évaluation humaine.

Cette stratégie est obligatoire pour le sous-ensemble des données personnelles collectées par les services, qui impose de définir et communiquer une durée de conservation des données personnelles (art. 13-2 du RGPD).

Moyen de test ou de contrôle

Pour valider ce critère, vérifier l’existence d’une stratégie d’archivage et de suppression clairement définie, l’existence de mécanismes automatiques et de processus manuels pour les contenus dont le traitement requiert une intervention humaine. Le suivi de cette stratégie pourra être réalisé en évaluant régulièrement le taux d’occupation des bases de données et des serveurs physiques.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service numérique ne repose pas sur l’utilisation d’un écran

Métiers concernés : Développeur, Concepteur UX / UI, Responsable Produit

Objectif

Réduire ou limiter les données téléchargées.

Mise en œuvre

Par écran, il est entendu ici « écran virtuel » et non physique. Si le service numérique est un site web, l’écran désigne la page, pour une API, l’écran désigne la réponse du serveur.

Définir et suivre des indicateurs de :

• Poids maximum par écran, en tenant compte de toutes les ressources téléchargées (composants d’interface, données, contenus, scripts, feuilles de style…). Par exemple pour une page web (avec toutes les ressources chargées) qui pèse 2 Mo, l’objectif serait de descendre à 1 Mo. Selon le contexte, cet objectif peut être beaucoup plus bas.
• Requêtes client/serveur maximum par écran, en tenant compte de toutes les ressources téléchargées (composants d’interface, données, contenus, scripts, feuilles de style…). Par exemple, pour un site web, il serait intéressant d’avoir moins de 30 requêtes par page au lieu de 100.

Moyen de test ou de contrôle

Afficher dans la déclaration d’écoconception :

• Le poids maximum par écran défini et proportionné, et respecter cette limite ;
• Le nombre de requêtes maximum par écran défini, en précisant si la limitation du nombre de requêtes porte sur le seul chargement de la page web ou également sur son fonctionnement (par exemple : pour une page web comportant un formulaire de saisie ; est-ce que le nombre de requêtes intègre les requêtes de contrôle de champs ?).

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service numérique ne repose pas sur l’utilisation d’un serveur

Métiers concernés : Administrateur Système, Développeur, Architecte Logiciel

Objectif

L’objectif est de réduire le poids des données échangées. Une partie de l’empreinte énergétique des services numériques est liée à la volumétrie des données échangées sur les réseaux, en particulier lorsque les données sont transmises sur des réseaux radio (réseaux mobiles par exemple). La réduction de la volumétrie des données échangées sur les réseaux pour une application donnée est donc un axe important d’écoconception. Dans la plupart des cas, cette réduction pourra se faire sans dégradation de l’expérience utilisateur.

Mise en œuvre

La stratégie de cache doit être adaptée au contexte d’application, au type de contenus (images, fichiers CSS, JavaScript, etc.) qui sont transférés fréquemment depuis le serveur vers le client et au scénario d’usage. Mettre en place un mécanisme de cache côté utilisateur, en frontend (cache HTTP par exemple). La gestion du mode déconnecté (offline) est parfois très pertinente, parfois non.

Lorsqu’une même information est susceptible d’être requêtée plusieurs fois, privilégier un stockage temporaire local pour éviter un trafic réseau inutile. Par exemple, il est possible de stocker des données souvent utilisées dans le navigateur web, afin de limiter les échanges avec le serveur.

Vérifier qu’aucune des données destinées à être échangées n’est superflue et que les informations transmises ne sont pas redondantes.

Le critère 6.2 traite du cache côté client. Le cache côté serveur est, quant à lui, traité dans le critère 7.1.

Moyen de test ou de contrôle

Pour valider ce critère, un mécanisme de cache côté utilisateur est mis en place, quand la solution est pertinente. En termes de moyens de test, accéder à plusieurs reprises au service et vérifier si les contenus sont récupérés à partir du cache plutôt que du serveur.

Expliciter dans la déclaration d’écoconception du service la stratégie de cache frontend, y compris son optimisation au regard du type de contenu, du contexte d’application et des scénarios d’usage.

Niveau de difficulté : Faible

Niveau de priorité : Modéré

N/A si le service numérique n’utilise pas de connexion réseau internet

Métiers concernés : Développeur, Administrateur Système, Architecte Logiciel

Objectif

Réduire la quantité de ressources transférées sur le réseau via la compression des données.

Mise en œuvre

Mettre en place la compression, minification (réduction la taille du code) des fichiers de scripts. Attention toutefois à ne pas générer de la consommation de ressources s’il y a besoin de puissance de calcul pour « décompresser » les fichiers : la compression systématique de type « .tgz » par exemple pour des petits fichiers peut être contreproductive. Ce critère s’applique uniquement aux fichiers texte (HTML, CSS, JavaScript par exemple).

Veiller à mettre en place une compression de bout en bout ( exemple : Documentation Mozilla sur la compression dans HTTP). Il faudra faire appel à des mécanismes de compression de flux pour minimiser le volume du trafic échangé. Favoriser, lorsque cela est possible, le mécanisme de compression le plus efficace.

Par exemple, pour HTTP plusieurs protocoles de compression existent, tels en particulier Brotli et GZIP.

Ne pas confondre avec le critère 5.2 sur la compression des images (qui n’aborde pas la compression lors du transfert).

Moyen de test ou de contrôle

Le critère est validé si les requêtes du service numérique utilisent un mécanisme de compression des données au niveau du frontend. Pour le protocole HTTP et la compression HTML, les mécanismes de compression Brotli ou GZIP sont conseillés.

Pour aller plus loin

Comment activer Brotli ?

Ce module est intégré par défaut à la plupart des navigateurs. Plus généralement, les trois serveurs web majeurs à ce jour : Apache, Nginx et Microsoft IIS proposent d’activer Brotli :

• Apache : le module « mod_brotli » permet d’ajouter le support de Brotli ;
• Nginx : le module « ngx_brotli » ;
• Microsoft IIS : extension « IIS Brotli ».

Certains fournisseurs de Content Delivery Network (CDN) proposent d’activer Brotli.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service numérique n’inclut pas de graphiques et/ou médias

Métiers concernés : Développeur, Concepteur UX / UI

Objectif

Réduire ou limiter les données téléchargées en proposant un redimensionnement côté serveur pour les images dans une définition trop importante. Il s’agit également de minimiser la consommation d’énergie du terminal.

Mise en œuvre

Les images matricielles (ou images bitmap) proposées par un service numérique sont soit affichées dans leur taille d’origine, soit proposées dans de multiples définitions, afin de ne pas charger une image avec une définition significativement supérieure à celle du contexte d’affichage utilisé par le client.

Lors de l’ajout des images matricielles au service numérique, les dimensions d’affichage sont requises ou un redimensionnement est réalisé côté serveur, lors de l’ajout du fichier par un contributeur.

Moyen de test ou de contrôle

Pour être valider ce critère, les images du service numérique doivent entrer dans une des trois catégories suivantes :

• Images vectorielles ;
• Images matricielles, affichées dans leur taille d’origine (pas de redimensionnement) ;
• Dans le cas d'images fluides (l'image occupe un pourcentage de la largeur du parent), plusieurs variantes d'images existent avec des définitions différentes, et la meilleure est proposée à l'écran, en fonction du contexte d’affichage.

Si le service numérique permet à un contributeur d’ajouter des images, un redimensionnement doit être réalisé côté serveur pour les images qui dépasseraient une certaine taille (exprimée en pixels ou en octets) ou définition d’image.

Niveau de difficulté : Fort

Niveau de priorité : Recommandé

N/A si le service numérique n’utilise pas d’interface graphique

Métiers concernés : Développeur, Concepteur UX / UI

Objectif

Réduire ou limiter les données téléchargées et optimiser la consommation énergétique des terminaux. Il est souvent plus simple pour l’équipe de développement de charger tous les composants, packagés dans un fichier compressé quelle que soit la fonctionnalité. Il en résulte que l’utilisateur charge des composants qui ne seront pas forcément utilisés. N’utiliser que ce qui est effectivement nécessaire au fonctionnement du service permet d’économiser de la ressource informatique.

Mise en œuvre

Ressources et composants ne doivent être chargés que lorsqu’ils sont effectivement utilisés. Prévoir des mécanismes de chargement progressif pour les éléments graphiques et les médias qui nécessitent un téléchargement. Par exemple : streaming pour la vidéo, chargement uniquement des images ou ressources affichées à l’écran (« lazy loading ») lorsque l'utilisateur les atteint en faisant défiler la page (Illustration : Documentation MDN sur le chargement progressif).

Moyen de test ou de contrôle

Vérifier le contenu des ressources chargées et leur utilisation effective en s'assurant qu'elles correspondent aux fonctionnalités effectivement utilisées : pour valider ce critère, il ne doit pas y avoir de ressources chargées inutilement.

Niveau d difficulté : Moyen

Niveau de priorité : Modéré

N/A si le service numérique fonctionne sans l’usage de capteurs des terminaux des utilisateurs

Métiers concernés : Développeur, Concepteur UX / UI

Objectif

Réduire ou limiter les données échangées, dont des données personnelles (comme la webcam, le micro ou la géolocalisation, par exemple), avec le service numérique.

Mise en œuvre

Prévoir des mécanismes d’alerte, d’information et de consentement et une validation avant tout déclenchement de capteur du terminal par l’utilisateur. Il s’agit de limiter l'activation des capteurs aux moments où ils sont réellement nécessaires au bon fonctionnement du service, ou par l’activation d’une fonctionnalité expressément demandée par l’utilisateur. La définition du « moment où ils sont réellement nécessaires » doit être objectivée pour chaque usage : l’usage des capteurs doit être minimal par défaut, mais peut également être proposé à l’utilisateur un « mode dégradé » permettant de répondre à l’usage essentiel souhaité, optimisant les ressources matérielles et en particulier la batterie, sans aller jusqu’au fonctionnement nominal ou idéal.

Moyen de test ou de contrôle

Vérifier l’affichage de mécanismes d’alerte et de consentement avant tout déclenchement de capteur du terminal accepté par l’utilisateur. Examiner périodiquement que la durée d’utilisation des capteurs des terminaux utilisateurs est minimisée.

Le critère est validé si un mécanisme d’alerte et de consentement s’enclenche pour tout déclenchement de capteur du terminal.

Niveau de difficulté : Faible

Niveau de priorité : Modéré

N/A si le service numérique n’utilise pas le protocole HTTP

Métiers concernés : Administrateur Système, Développeur, Architecte Logiciel

Objectif

Permettre de diminuer la taille des échanges et de requêtes en utilisant HTTP/2 ou HTTP/3 à la place de HTTP/1.1 et en limitant le nombre de domaines différents pour les ressources utilisées. Il s’agit ainsi d’optimiser la sollicitation des serveurs.

Mise en œuvre

Activer HTTP/2 ou HTTP/3 et limiter le nombre de domaines différents pour les ressources utilisées afin notamment de profiter du multiplexage proposé par HTTP/2 ou HTTP/3.

Moyen de test ou de contrôle

Le critère est validé si (conditions cumulatives) :

• L’ensemble de ses ressources prennent en charge HTTP/2 ou HTTP/3 ;
• Les ressources statiques, hors services tiers, sont transférées via un seul nom de domaine à un instant « t ».

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service repose sur des requêtes ne pouvant être mises en cache ou s’il ne s’appuie pas sur la réponse d’un serveur

Métiers concernés : Administrateur Système, Développeur, Architecte Logiciel

Objectif

Limiter la consommation de ressources informatiques.

Mise en œuvre

Identifier les données, entrées API, ressources les plus utilisées à mettre en cache afin d’éviter de les régénérer. Configurer une durée d’expiration pour les rafraîchir par exemple en invalidant automatiquement le cache après une durée déterminée ou en utilisant des mécanismes de purge du cache lorsqu'une mise à jour des données est effectuée.

Le critère 7.1 concerne le cache côté serveur, à ne pas confondre avec le critère 6.2 qui traite du cache côté client.

Moyen de test ou de contrôle

Pour valider ce critère :

• Vérifier la configuration des systèmes de cache serveurs utilisés et s’assurer que les ressources les plus utilisées sont mises en cache ;
• Examiner la présence et les règles d’expiration qui doivent être correctement paramétrées en fonction des caractéristiques de chaque fonctionnalité (ressources statiques, contenu dynamique, données en temps réel, informations personnalisées…) ;
• S’assurer de la présence d’un mécanisme de rafraîchissement du cache.
• Expliquer la stratégie de gestion de cache côté serveur dans la déclaration d’écoconception du service.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service numérique ne repose pas sur l’utilisation d’un serveur

Métiers concernés : Administrateur Système, Développeur, Responsable Produit, Architecte Logiciel

Objectif

Le stockage des données n'est ni illimité, ni gratuit, il a un impact environnemental et doit être optimisé. Certains services traitent de grandes quantités de données qui ne sont jamais consultées, car l'utilisateur a cessé d'utiliser le produit (mais n'a, par exemple, pas supprimé le compte) ou parce que les données sont obsolètes depuis longtemps. La limitation des durées de conservation des données personnelles figure d’ailleurs dans les obligations du RGPD.

L’objectif est d’alléger les bases de données et les serveurs physiques de données non utiles.

Mise en œuvre

Définir des dates d’expiration sur les données (fichiers, entrées en base de données…) permettant par la suite d’archiver et/ou de supprimer ces données. Implémenter des fonctionnalités qui aident les utilisateurs à identifier des données obsolètes grâce à des indicateurs et ou des suggestions de localisation où les données peuvent être supprimées.

Mettre en place un processus (de préférence automatique) d’archivage ou de suppression des données (fichiers, entrées en base de données…) dont la durée de conservation est dépassée.

Dans la mesure du possible, archiver les informations rarement consultées et intégrer une interface de « récupération à partir de l'archive » dans les interactions de l'utilisateur. Supprimer les archives inutilisées après une durée communiquée à l’utilisateur.

Déplacer le cas échéant les archives (données froides) sur un autre support que celui utilisé pour les données actives (données chaudes), voir critère 8.8.

Moyen de test ou de contrôle

Pour valider ce critère, définir des dates d’expiration pour les informations obsolètes et mettre en place un mécanisme d’archivage ou de suppression des données dépassant la durée de conservation définie.  Un suivi de l’évolution du poids des fichiers stockés et des bases de données.

Niveau de difficulté : Faible

Niveau de priorité : Modéré

N/A si le service numérique ne fait pas de traitement en arrière-plan

Métiers concernés : Développeur, Responsable Produit

Objectif

Éviter les requêtes simultanées provoquées par l’utilisateur s’il ne sait pas que son action est en cours de prise en compte.

Mise en œuvre

Rendre indisponible l’action qui génère le traitement (par exemple un bouton de soumission de formulaire) lorsqu’elle est initiée par l’utilisateur quand la requête est en cours de traitement. Il conviendra également d’informer l’utilisateur que le traitement est en cours, en précisant éventuellement une durée approximative de traitement.

Moyen de test ou de contrôle

Réaliser des tests fonctionnels permettant de vérifier que lorsqu'une action est en cours de traitement, le bouton ou l'élément déclencheur est désactivé et qu'un indicateur visuel ou un message d'attente est présent pour informer l'utilisateur.

Niveau de difficulté : Fort

Niveau de priorité : Prioritaire

N/A si le service ne repose pas sur un mécanisme de consensus

Métiers concernés : Développeur, Administrateur Système, Architecte Logiciel

Objectif

L’empreinte énergétique des services numériques reposant sur une technologie blockchain publique dépendra essentiellement du mécanisme de consensus choisi. Contrairement aux blockchains privées et de consortium, les blockchains publiques sont ouvertes à tout participant et doivent donc s’appuyer sur un mécanisme de consensus particulièrement sécurisé. La preuve de travail est le mécanisme de consensus utilisé qui consomme le plus d’énergie, car s’appuyant sur le minage. L’objectif est donc de réduire l’impact environnemental de la blockchain en évitant tout algorithme de consensus reposant sur le minage et en choisissant un mécanisme de consensus moins énergivore et, plus généralement, moins consommateur en ressources.

Mise en œuvre

Prendre en compte les critères de performance environnementale dans le choix de la blockchain.

En particulier, choisir un mécanisme de consensus alternatif à la preuve de travail ne reposant pas sur le minage, en s’assurant que l’algorithme de consensus a une consommation énergétique réduite. Par exemple :

• Preuve d’enjeu ;
• Preuve d’enjeu déléguée ;
• Preuve d’autorité.

Si possible, définir les paramètres de la blockchain de manière à minimiser sa consommation en énergie et en ressources matérielles (par exemple : la fréquence des validations ou la gestion de la taille des blocs).

Moyen de test ou de contrôle

Vérifier la consommation d’énergie et en ressources matérielles du mécanisme de consensus utilisé par le service numérique : l’algorithme doit être testé ou reconnu comme pauvre en consommation d’énergie et de ressources. Selon les fonctionnalités du service, choisir l’algorithme de consensus de la blockchain permettant de minimiser la consommation énergétique requise. Il faudra s’assurer que les paramètres de la blockchain minimisent son impact environnemental.

Si le service repose sur une blockchain ayant recours à la preuve de travail ou à un algorithme de consensus reposant sur le minage et, de façon générale, associée à une consommation énergétique et en ressources élevée, le critère n’est pas validé.

Le choix de la blockchain et la pertinence de l’algorithme de consensus choisi au regard des enjeux environnementaux devront être documentés dans la déclaration d’écoconception.

Pour aller plus loin

• Quelques références consultables en ligne Consommation énergétique des technologies blockchain – EcoInfo (cnrs.fr)
• Enjeux technologiques des blockchains (chaînes de blocs) (Dossier législatif en version repliée) - Assemblée nationale (assemblee-nationale.fr)
• Les différents algorithmes de consensus sur la blockchain (coinacademy.fr)
• Promesses et (dés)illusions (openedition.org)

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A si le service ne repose pas sur l’activité d’un centre de données

Métiers concernés : Responsable de l'hébergement, Responsable RSE/Numérique soutenable, Responsable des achats, Administrateur Système

Objectif

Les centres de données représentent environ 15 % de l’empreinte carbone du numérique en France et leur empreinte environnementale ne se limite pas aux émissions de GES (étude ADEME-Arcep). Il est donc important de prendre en compte dans le choix de la solution d’hébergement les pratiques du centre de données en matière environnementale. Il convient de favoriser un hébergement qui suit son empreinte environnementale et a engagé une démarche proactive pour la réduire.

Mise en œuvre

Sélectionner un hébergeur transparent sur son empreinte environnementale et ayant des engagements environnementaux pour la réduire. Une ACV est recommandée, ou a minima, la publication des indicateurs suivants : émissions de GES (market-based et location-based), consommation énergétique, en eau, en ressources abiotiques (minérales/métalliques). Plus précisément, l’hébergeur devra avoir pris des engagements pour minimiser son empreinte environnementale, visant a minima les indicateurs suivants : émissions de GES (market-based et location-based), consommation énergétique, en eau, en ressources abiotiques (minérales/métalliques). Afin de vérifier les engagements environnementaux pris par l’hébergeur, ceux-ci devront se baser sur des cadres ou normes existantes, spécifiquement :

• Code de conduite européen sur les centres de données, établi par la Commission européenne ;
• Norme environnementale : ISO 14001… ;
• Certification environnementale : ISO 14001, LEED, BREEAM, HQE… ;
• Évaluation et communication des impacts via des référentiels reconnus (par exemple : Product Category Rules (PCR), Bilan Carbone/GHG Protocol, ISO14063, normes ITU, Carbon Disclosure Project (CDP), Science Based Targets(SBTi)…) mutualisation des ressources machines ;
• Type de refroidissement minimisant la consommation de l’environnement technique en fluides frigorigènes, en eau et en énergie ;
• Mécanisme de récupération de la chaleur fatale ;
• Mise en place d’efforts d’amélioration de la performance énergétique de l’hébergement via une certification ISO 50001 ;
• Analyse d’impact environnemental du « move to cloud » pour les acteurs ayant leurs serveurs on premise voire calculettes proposées par les fournisseurs en amont de la migration ;
• Politique de construction du centre de données et minimisation de l’artificialisation des sols ;
• Charte, politique RSE certifiée etc.

Il convient de rester vigilant au greenwashing lorsqu’il s’agit de communications sur la neutralité carbone, d’une charte, d’une politique ou d’une feuille de route interne, sans possibilité de vérifier la mise en œuvre ou sans un tiers indépendant qui certifie la mise en œuvre.

Moyen de test ou de contrôle

Sélectionner un hébergeur transparent sur son empreinte environnementale et ses engagements en faveur de l’environnement. Afin de vérifier la véracité des données communiquées par les centres de données, il est conseillé de demander à l’hébergeur les certificats relatifs aux performances environnementales ainsi que les méthodologies utilisées en se basant sur des normes et standards reconnus (ISO, etc.).

Vérifier ou demander des engagements à l’hébergeur pour diminuer son empreinte environnementale – a minima concernant les indicateurs suivants : émissions de GES (market-based et location-based), consommation en énergie, en eau, en ressources abiotiques (minérales/métalliques). S’assurer de la ratification du Code de conduite sur les centres de données par l’hébergeur (se référer, si possible, à la méthodologie de la Commission européenne dans le contexte de l’acte délégué sur la taxonomie climat qui permet d’évaluer le respect de ce Code de conduite par les centres de données) et des actions associées.

Documenter dans la déclaration d’écoconception du service l’empreinte environnementale de l’hébergement et la mise en place d’engagements environnementaux pour la minimiser.

Pour aller plus loin

Des références à consulter en ligne :

• Qu’est-ce que le Code de conduite européen sur les datacentres ?
• Liste des centres de données déclarés signataires du Code de conduite européen sur les datacentres (JRC)

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A si le service n’utilise pas d’hébergement

Métiers concernés : Responsable de l'hébergement, Responsable RSE/Numérique soutenable, Responsable des achats

Objectif

Favoriser un hébergement ayant des engagements en faveur de l’environnement concernant sa gestion des équipements : impacts environnementaux de l’achat de ces équipements, politique d’achat (achat durable, réparable), politique d’usage (upgrade, réparation par exemple) et politique de fin d’usage (réemploi et gestion des DEEE, les déchets d’équipements électriques et électroniques).

Mise en œuvre

Sélectionner un hébergeur ou de demander des engagements à un hébergeur ayant une politique transparente et écologique de sa gestion des équipements : communication sur la durée de vie de ces derniers (serveurs, commutateurs réseau, firewalls, routeurs…) et sur la gestion du cycle de vie de son parc. Par exemple, il serait intéressant que l’hébergeur indique une durée de vie totale de ses équipements de plus de huit ans (ou un objectif en ce sens, si les installations de l’hébergeur ont moins de huit ans).

Moyen de test ou de contrôle

Vérifier la mise en place d’un plan de gestion durable des équipements informatiques par l’hébergeur. Le plan devra couvrir des informations sur la durée de vie des équipements, la politique d’achat durable et les actions mises en place pour minimiser l’empreinte environnementale du cycle de vie du matériel utilisé par l’hébergeur. Pour valider le critère, ce plan devra être référencé dans la déclaration d’écoconception du service numérique.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A si le service n’utilise pas d’hébergement

Métiers concernés : Responsable de l'hébergement, Responsable RSE/Numérique soutenable, Responsable des achats

Objectif

Il s’agit de connaître le PUE de son hébergement et favoriser de la réduction la consommation d’énergie nécessaire au bon fonctionnement et au refroidissement des serveurs nécessaires à l’hébergement.

Mise en œuvre

Il est recommandé de prendre en compte le PUE du centre de données dans le choix de la solution d’hébergement. Pour les hébergements en activité depuis plus de deux ans, le PUE devra être mesuré sur leur valeur dite « réelle » et non « by design » sur la base d’une méthodologie se référant à des normes et standards internationalement reconnus (par exemple normes ISO).

Sélectionner un hébergeur qui indique son PUE et la stratégie mise en œuvre pour le réduire. La communication de cet indicateur s’accompagne de la communication de la méthodologie utilisée pour le mesurer, basée sur des standards internationalement reconnus (par exemple ISO/IEC 30134) et notamment sur le type de PUE qui est mesuré (type 1,2 ou 3).

Le PUE est un indicateur d’efficacité énergétique qui consiste en un ratio entre l’énergie totale consommée par l’ensemble du centre d’exploitation (avec entre autres, le refroidissement, le traitement d’air, les onduleurs…) et la partie qui est effectivement consommée par les systèmes informatiques que ce centre exploite (serveurs, stockage, réseau). Un PUE proche de 1 indique une excellente performance énergétique du centre de données. Généralement, il est constaté un PUE à 1,1 pour les hyperscalers et de 2 pour les plus anciens centres de données. Cependant, améliorer cet indicateur peut dégrader d’autres indicateurs, sans que cela ne réduise ni l’impact global, ni la consommation d’énergie ; d’où l’intérêt de suivre plusieurs indicateurs (consommation d’énergie, consommation d’eau, politique de gestion du matériel, etc. Voir critère 8.1.).

À noter : Les centres de données les plus récents n’ont pas encore le taux de remplissage suffisant pour que le PUE réel soit l’indicateur approprié. Ainsi, en dessous de deux ans d’activité, le PUE by design est un meilleur indicateur auquel se référer, mais dans ce cas uniquement pour éviter les risques d’obsolescence.

Moyen de test ou de contrôle

Quel est le PUE de l’hébergeur du service numérique ?Vérifier la publication de cet indicateur de performance énergétique par  l’hébergeur du service numérique. Pour valider le critère, il faut choisir un hébergeur avec un PUE inférieur à 1,5 en réel (ou un PUE by design inférieur ou égal à 1,3 si les installations de l’hébergeur sont entrées en activité depuis moins de deux ans – en conséquence, le critère devra être réévalué passé ce délai de deux ans d’activité des installations –).

Si possible, fournir un lien ou justificatif incluant le PUE de l'hébergement dans la déclaration d’écoconception du service.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service n’utilise pas d’hébergement

Métiers concernés : Responsable de l'hébergement, Responsable RSE/Numérique soutenable, Responsable des achats

Objectif

Connaître le WUE* de son hébergement, indicateur souvent peu pris en compte., et réduire ou limiter la consommation d’eau nécessaire au refroidissement des serveurs. Éviter le stress hydrique (c’est-à-dire de pénurie d’eau potable). Le stress hydrique local peut également être pris en compte: un WUE élevé dans une zone sans stress hydrique sera moins problématique.

Mise en œuvre

Sélectionner un hébergeur qui indique son WUE et la méthodologie utilisée pour le mesurer, basée sur des standards internationalement reconnus (par exemple ISO/IEC 30134). Cet indicateur est un ratio entre la quantité d’eau consommée et l’énergie totale utilisée par le centre de données. Il est mesuré en L/kWh. Pour les hébergements en activité depuis plus de deux ans, le WUE devra être mesuré – si possible – sur leur valeur dite « réelle » et non « by design » sur la base d’une méthodologie se référant à des normes et standards internationalement reconnus (par exemple normes ISO).

NB : Actuellement, il y a peu ou pas de données ouvertes sur le sujet du stress hydrique local. Comme pour le PUE, améliorer cet indicateur peut dégrader d’autres indicateurs, sans que cela ne réduise ni l’impact global, ni la consommation d’énergie, d’où l’intérêt de suivre plusieurs indicateurs (consommation d’énergie, consommation d’eau, politique de gestion du matériel, etc.).

Moyen de test ou de contrôle

Le critère est validé si l’hébergeur du service numérique démontre une démarche de minimisation de sa consommation d’eau en suivant les indicateurs pertinents, en particulier son WUE. L’objectif d’un WUE inférieur ou égal à 0,4 L/kWh peut être visé (calculer en réel si possible et sinon, considérer le WUE by design, en particulier pour les centres de données qui sont en activité depuis moins de deux ans – le critère est donc à réévaluer passé ce délai de deux ans d’activité des installations –).

La méthodologie de calcul et le type de WUE – réel ou by design – calculé sont précisés avec la valeur communiquée. Si possible, il faut fournir un lien ou justificatif incluant le WUE de l'hébergement dans la déclaration d’écoconception du service.

* La consommation en eau est encore relativement peu documentée au moment de la rédaction du présent référentiel. Il conviendra donc de prendre en compte les spécificités techniques et les possibles évolutions réglementaires en cours dans l’appréciation de ce critère, en particulier concernant l’objectif chiffré du WUE.

Niveau de difficulté : Faible

Niveau de priorité : Recommandé

N/A si le service n’utilise pas d’hébergement

Métiers concernés : Responsable de l'hébergement, Responsable RSE/Numérique soutenable, Responsable des achats

Objectif

L’objectif de ce critère est de promouvoir la transparence sur l’origine de la consommation électrique des centres de données et d’œuvrer à la transition énergétique, en particulier au développement des énergies renouvelables.

Mise en œuvre

Demander à l’hébergeur sa politique en termes d’achat d’électricité. Les PPA (Power Purchase Agreements) des contrats d’énergie renouvelable de long terme sont considérés comme de meilleure qualité que les certificats d’origine de l’électricité.

Voir à ce sujet le rapport Development of the EU Green Public Procurement (GPP) criteria for data centres, server rooms and cloud services. Ainsi, la quantité annuelle d’énergie contractualisée devra être renseignée, en précisent les modalités de fourniture d’énergie renouvelable : via PPA sur le réseau français mais hors site, via autoconsommation donc sur site (potentiellement par PPA ou support complet des coûts de capital et autres) et via des garanties d’origine. Pour les garanties d’origine renouvelable, l’additionnalité doit être prouvée.

Secondairement, un indicateur de performance normé peut être suivi : le REF, Renewable Energy Factor. La part en électricité bas carbone est également une donnée pertinente pour appréhender l’empreinte environnementale du mix énergétique de l’hébergement.

Moyen de test ou de contrôle

S’assurer de la transparence de l’hébergeur en matière d’énergies renouvelables.

Demander des justificatifs sur la provenance de l’électricité consommée par l’hébergeur (PPA en priorité, sinon certificat d’origine de l’électricité).

Le critère est validé si l’hébergeur du service numérique est transparent sur son mix énergétique et documente une politique de recours majoritaire aux énergies renouvelables, ayant un impact effectif sur la réduction de la demande en énergie fossile. Au-delà de l’indicateur REF, l’hébergeur devra renseigner la quantité annuelle d’énergie contractualisée telle que décrite dans la section « Mise en œuvre » pour documenter sa politique de recours aux énergies renouvelables.

La provenance de l’électricité consommée par l'hébergement sera documentée dans la déclaration d’écoconception du service, par exemple en renvoyant vers la documentation détaillée pertinente du fournisseur.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service n’utilise pas d’hébergement

Métiers concernés : Responsable de l'hébergement, Responsable RSE/Numérique soutenable, Responsable Logistique

Objectif

L’objectif est d’abord de privilégier un hébergement dans le pays où l’intensité carbone est peu élevée, et secondairement, dans une région où se situent la majorité des clients, afin de réduire la distance parcourue par les données et donc réduire l’infrastructure réseau mobilisée et son empreinte environnementale.

Mise en œuvre

Privilégier un hébergeur dont les serveurs sont situés dans un pays avec une électricité bas carbone (source : Electricity Maps). Dans la mesure du possible, il est également pertinent de privilégier un hébergeur qui soit proche des utilisateurs ou des activités identifiées (cela ne correspond pas à adopter les technologies Edge Computing mais à choisir un centre de données proche des utilisateurs).

Moyen de test ou de contrôle

Identifier la localisation des utilisateurs et celle des serveurs de l’hébergement. 

Pour valider ce critère, il conviendra de vérifier que l’hébergeur du service numérique est situé dans un pays où l’intensité carbone de la consommation électrique est minimale. Pour cela, vérifier que cette intensité est en dessous du seuil annuel de 100 gCO₂eq/kWh , en lien avec la trajectoire de réduction des émissions de gaz à effet de serre telle que définie par l’initiative Science-Based Targets (SBTi) et conformément aux objectifs de l’Accord de Paris (à partir de 2030, le seuil à respecter est de 80 gCO₂eq/kWh puis 0 gCO₂eq/kWh à partir de 2050 – source : Quick start guide for electric utilities (PDF – 2 Mo)). De façon complémentaire (pas nécessaire pour la validation de ce critère), favoriser le choix d’un hébergement dans le pays où la majorité de ses utilisateurs sont localisés.,.

Documenter dans la déclaration d’écoconception, la localisation (pays, ville) de l’hébergement du service numérique.

Pour aller plus loin

La plateforme Electricity Map met à disposition des données détaillées et ouvertes sur l’intensité carbone de la plupart des pays.

Niveau de difficulté : Fort

Niveau de priorité : Recommandé

N/A si le service n’utilise pas d’hébergement

Métiers concernés : Responsable de l'hébergement, Responsable RSE/Numérique soutenable

Objectif

Encourager les initiatives permettant de diminuer ou de récupérer l’énergie produite, par exemple pour chauffer des bâtiments en hiver. Se reporter à la définition de la chaleur fatale de l’ADEME.

Mise en œuvre

Sélectionner un hébergeur ayant pris des engagements de récupération ou réutilisation la chaleur fatale générée (par exemple, pour chauffer directement les bureaux ou d’autres installations à proximité) ou mettant en place des mécanismes alternatifs permettant de gérer la température de serveurs et de minimiser l’empreinte environnementale de l’hébergement.

Moyen de test ou de contrôle

Le critère est validé si l’hébergeur a mis en place des initiatives assurant la récupération et la réutilisation de la chaleur fatale générée par son installation, et que celles-ci sont documentées dans la déclaration d’écoconception du service numérique. Il est nécessaire que le bilan environnemental global de la réutilisation de la chaleur produite soit positif, en tenant compte de l’investissement initial pour la construction ou de l’adaptation des installations pour la validation du critère.

De façon alternative, le critère peut être validé si le centre de données utilisé pour le service a un PUE inférieur à 1,3 en réel (ou un PUE by design inférieur ou égal à 1,2 si les installations de l’hébergeur sont entrées en activité depuis moins de deux ans – le critère est donc à réévaluer passé ce délai de deux ans d’activité des installations –). Un centre de données avec un PUE faible – bien qu’efficient énergétiquement – peut rendre impossible ou compliquée cette réutilisation de la chaleur fatale.

Niveau de difficulté : Fort

Niveau de priorité : Modéré

N/A si le service numérique repose sur l’hébergement de moins de l’équivalent de 10 To de données

Métiers concernés : Responsable de l'hébergement, Responsable RSE/Numérique soutenable, Architecte de bases de données

Objectif

Les données chaudes sont des données utilisées alors que les données froides sont des données archivées. Utiliser des hébergements différents permettrait de réduire les impacts environnementaux.

Mise en œuvre

Séparer les données chaudes des données froides en utilisant des solutions techniques adaptées au contexte d’utilisation. Il convient d’avoir une réflexion sur le mode de stockage des données froides : il existe plusieurs technologies sur le marché, toutes n’ont pas nécessairement le même impact.

Par exemple les archives et les sauvegardes à conserver dans la durée peuvent être mises dans un stockage « froid ».

Moyen de test ou de contrôle

Vérifier la séparation des données chaudes et froides dans l'architecture du service numérique, par exemple en examinant la configuration des systèmes, en s'assurant qu'ils sont distincts pour les deux types de données.

Pour valider ce critère, s'assurer que des stratégies de stockage appropriées sont mises en place pour les données froides, en prenant en compte leur empreinte environnementale.

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service n’utilise pas d’hébergement

Métiers concernés : Responsable de l'hébergement, Ingénieur en stockage de données, Responsable de la sécurité informatique, Architecte/Ingénieur Systèmes

Objectif

Réduire les ressources informatiques et les ressources de stockage utilisées.

Il s’agit de se poser la question du bon niveau de service sélectionné par rapport au besoin. Plus le taux de disponibilité demandé est haut, plus cela mobilise une infrastructure financièrement et environnementalement coûteuse.

Mise en œuvre

Ne pas systématiquement dupliquer toutes les données mais identifier les données nécessaires à être dupliquées (données critiques ou données très sollicitées par exemple). Un équilibre est à trouver entre sécurisation (pour éviter les pertes de données) et dissémination (en avoir trop partout).

Se questionner sur la pertinence de la redondance du service, pour en établir le bon dosage. Est-ce critique si l’une des fonctionnalités du service n’est pas disponible pendant un certain temps ?

• Le Backup & Restore est ce qu’il y a de moins cher, parfaitement adapté aux applications qui ont un RTO (Recovery Time Objective) ou RPO (Recovery Point Objective) de quelques heures.
• Le Pilot Light, à savoir par exemple une base de données « mirrorée »/dupliquée mais avec des machines virtuelles éteintes. Procédé un peu plus cher qu’un Backup & Restore, il fonctionne pour la plupart des applications qui n’ont pas d’exigences SLA (Service Level Agreement) extrêmes (inférieures à 1 heure).
• Le Warm Standby, lorsque les VMs tournent déjà mais dans une scalabilité limitée, presque en temps réel mais potentiellement en qualité légèrement dégradée s’il y a un incident.
• Le Hot Standby multisite : résilience totale pour des SLAs (Service Level Agreements) temps réel. Aucune perte de service n’est tolérée, mais cela a nécessairement un coût.

Moyen de test ou de contrôle

Pour valider ce critère, vérifier la présence d’un SLA (Service Level Agreement) ajusté selon les besoins.

Niveau de difficulté : Fort

Niveau de priorité : Recommandé

N/A si le service numérique n’inclut pas de calculs ou transferts de données asynchrones

Métiers concernés : Responsable de la programmation, Architecte Logiciel, Responsable RSE/Numérique soutenable

Objectif

Planifier les calculs et transferts de données asynchrones (sauvegardes, mises à jour, entraînement…) énergivores en dehors des pics quotidiens de consommation électrique, pour les algorithmes et traitement consommateurs pouvant être décalés dans le temps.

Ajuster la temporalité des calculs et transferts de données asynchrones pour éviter les moments où les serveurs ou les réseaux sont le plus sollicités, de façon à éviter l’achat de nouveaux équipements pour supporter les « pics ». Préférer les transferts de données d’un terminal mobile lorsque celui-ci est connecté au réseau filaire (qui est moins sensible aux usages que le réseau mobile en termes de ressources et de consommation énergétique).

Mise en œuvre

Configurer les calculs et transferts de données asynchrones en prenant en compte ces paramètres :

• Énergie : Éviter de planifier les calculs ou transferts de données asynchrones au moment des pics quotidiens de consommation électrique (lorsque la production électrique est la plus carbonée) pour les opérations pouvant être décalées dans le temps (par exemple utiliser l’API Ecowatt développée par RTE et l’ADEME).
• Infrastructure : Décaler les calculs et mises à jour importantes lorsque la disponibilité des ressources de calcul est faible (afin d’éviter l’achat de nouveaux équipements).
• Réseau : Il s’agit de décaler les utilisations importantes, en limitant l’utilisation du réseau internet entre 19h00 et 23h00. Par exemple, si une mise à jour volumineuse est prête à être diffusée à 18h00, déclarer sa mise en production à 23h00. De façon complémentaire, Lorsque le service mobile est utilisé sur un terminal mobile ayant la possibilité de se connecter sur un réseau mobile et sur un réseau filaire, reporter les transferts de données non urgentes (par exemple : mises à jour non critiques, sauvegardes, remontées de statistiques) au moment où le terminal est connecté au réseau filaire (WiFi notamment).

Moyen de test ou de contrôle

Le service numérique justifie dans la déclaration d’écoconception de la mise en œuvre de méthodes pour décaler les calculs et transferts de données asynchrones en fonction de la disponibilité de l’énergie électrique (éviter les pics quotidiens de consommation électrique qui impliquent une électricité plus carbonée), de la charge des infrastructures internet, et éventuellement en fonction de la disponibilité des ressources de calcul quand cela est pertinent.

Niveau de difficulté : Faible

Niveau de priorité : Prioritaire

Applicable à tous les services

Métiers concernés : Porteur de projet, Responsable R&D, Responsable RSE/Numérique soutenable, Data Scientist

Objectif

La phase d’apprentissage ou d’entrainement repose sur une infrastructure numérique qui, dans certains cas, peut nécessiter l’utilisation d’un important volume de données et de calculs. Largement répandue dans le domaine de l’intelligence artificielle, la phase d’entraînement peut engendrer une grande consommation d’énergie et de ressources. L’objectif est donc de réduire l’empreinte environnementale de la phase d’apprentissage en évitant de recourir à ces techniques si le besoin n’est pas avéré ou en choisissant une méthode adaptée et proportionnée aux besoins et caractéristiques du service numérique.

Il s’agira donc de s’interroger sur la nécessité d’inclure une phase d’entraînement dans le service numérique.

Mise en œuvre

Ne pas intégrer de phase d’entrainement dans le service tant que le besoin n’est pas avéré. Pour établir ce besoin, identifier les cibles utilisatrices et leurs besoins (voir « Mise en œuvre » du critère 1.2) vis-à-vis du service numérique. Lister les fonctionnalités du service essentielles à ces besoins et se poser la question de la nécessité ou non de l’inclusion d’une phase d’entraînement.

Il conviendra de s’interroger régulièrement sur la valeur ajoutée espérée par la phase d’entraînement : l’ajout d’une phase d’entraînement améliore-t-il significativement le service numérique dans l’atteinte des besoins de ses cibles ? L’amélioration est-elle effectivement perceptible et utile pour l’utilisateur ?

Moyen de test ou de contrôle

Ne pas inclure une phase d’entraînement tant que le besoin n’est pas démontré et le cas échéant, préférer les méthodes de recherches classiques, ou des solutions existantes déjà entraînées.

Pour démontrer le besoin d’une phase d’entrainementt, il s’agira de cibler des publics, les besoins associés et de rendre accessible des documents de référence faisant état des études, entretiens, recherches, personas ayant permis de définir les cibles utilisatrices et leur besoin.

Justifier dans la déclaration d’écoconception le lien avec les fonctionnalités du service et les raisons expliquant la nécessité (si pertinent) de l’inclusion d’une phase d’entraînement dans le service numérique, en particulier en termes de valeur ajoutée pour l’utilisateur. Si les besoins sont clairement établis, il conviendra de définir un niveau de satisfaction suffisant et de choisir une quantité d’entraînement proportionnée.

Le critère est validé si le service n’intègre pas d’apprentissage non justifiée. Dans l’éventualité de la mise en place d’une phase d’apprentissage, les critères de documentation susmentionnés démontrant l’utilité de la phase d’entraînement et son caractère proportionnel au regard de ses cibles ainsi que des fonctionnalités concernées devront également être suivis pour valider le critère.

Niveau de difficulté : Moyen

Niveau de priorité : Prioritaire

N/A si le service numérique n'inclut pas de phase d’entraînement

Métiers concernés : Porteur de projet, Data Scientist, Architecte Logiciel, Responsable RSE/Numérique soutenable

Objectif

Mettre en question le choix de la méthode d’apprentissage pour le service numérique et choisir la méthode d’entraînement la plus frugale, adéquate et proportionnée à l’usage du service.

Mise en œuvre

Faire le choix de la frugalité en privilégiant des méthodes simples, comme une régression ou à défaut des réseaux de neurones simples, à des technologies d’apprentissage profond (deep-learning) plus consommatrices de ressources de calcul.

Moyen de test ou de contrôle

Vérifier la consommation énergétique et en ressources matérielles de la méthode d’entraînement utilisée par le service numérique : cette dernière doit être testée ou reconnue comme pauvre en consommation d’énergie et de ressources.

Si le service ne repose pas sur des méthodes de régression ou autres méthodes peu coûteuses (low-complex, low-cost), justifier dans la déclaration d’écoconception du service le besoin de méthodes plus consommatrices par une référence à un état de l’art précisant la nécessité de méthodes plus complexes pour le cas d’usage cible.

Le critère est validé si le choix de la méthode d’apprentissage est l’alternative la plus sobre disponible selon l’état de l’art et les caractéristiques du service, et que ces choix sont documentés dans la déclaration d’écoconception associée ainsi qu’auditables par un tiers.

Niveau de difficulté : Fort

Niveau de priorité : Prioritaire

N/A si le service numérique n'inclut pas de phase d’entraînement

Métiers concernés : Porteur de projet, Data Scientist, Architecte Logiciel, Responsable RSE/Numérique soutenable

Objectif

Limiter la phase d’entraînement utilisée par le service numérique en choisissant des modèles déjà existants et pré-entraînés. Éviter le surentraînement en maîtrisant la consommation énergétique du mécanisme choisi.

Mise en œuvre

Utiliser un modèle déjà entraîné ou, à défaut, un fine-tuning d’un modèle pré-entraîné.

Mettre en œuvre les outils permettant la production de métriques de consommation de ressources (CPU / GPU / TPU / énergies, etc.) et les mettre en corrélation avec des métriques de qualité (précision, etc.) afin de limiter la consommation au juste nécessaire.

S’assurer de l’utilisation de CPU, de GPU ou de TPU efficaces, dont la localisation géographique est cohérente avec les activités concernées et qui minimise l’empreinte environnementale (en particulier, dans un pays à l’intensité carbone la plus faible possible).

Moyen de test ou de contrôle

Avant la conception du service, faire un état de l’art des modèles existants pouvant s’apparenter à la fonctionnalité visée. Utiliser un modèle pré-entraîné, si nécessaire en ajoutant des composants complémentaires (fine-tuning). Si le service n’utilise pas un modèle préexistant (déjà entraîné ou pré-entraîné), justifier dans la déclaration d’écoconception en quoi le cas d’usage est différent de ce qui existe dans l’état de l’art.

Par ailleurs, pour valider le critère, le service devrait avoir mis en place le suivi d’indicateurs de consommation de ressources et de qualité des fonctions de la phase d’apprentissage pour assurer l’optimisation de la quantité d’entraînement sous-jacente au fonctionnement du service.

Niveau de difficulté : Faible

Niveau de priorité : Prioritaire

N/A si le service numérique n'inclut pas de phase d’entraînement

Métiers concernés : Data Scientist, Architecte Logiciel, Responsable RSE/Numérique soutenable, Responsable de la protection des données, Développeur

Objectif

Il s’agit de s’interroger sur les données collectées et de minimiser les impacts environnementaux associés à leur collecte et à leur traitement pour la phase d’entraînement, en privilégiant des données existantes et en limitant la collecte de nouvelles données. Ce critère est pertinent pour la phase d’apprentissage, caractérisée le plus souvent par une forte obsolescence des bases de données utilisées.

Comme le souligne le rapport de la CNIL « Données, Empreinte et Libertés » (2023), certains impératifs de respect de la vie privée et objectifs d’écoconception se rejoignent.

Mise en œuvre

Veiller à réutiliser, si possible, des données existantes (notamment libres de droit) afin de limiter la collecte de nouvelles données et la puissance de calcul requise pour l’analyse incrémentielle de données. Questionner l’empreinte environnementale de l’acquisition de nouveau matériel de stockage contre celui du téléchargement systématique des données lorsque nécessaire.

Veiller à limiter la captation de nouvelles données pour la phase d’apprentissage.

Appliquer les critères 7.1 et 7.2 pour la mise en place de cache, de compression et de politique de gestion pour les données de la phase d’apprentissage.

Moyen de test ou de contrôle

Utiliser des bases de données existantes pour l’entraînement de son service numérique. Vérifier que la collecte de données est minimisée et mentionner les méthodes mises en œuvre dans la déclaration d’écoconception du service numérique.

Examiner également, la mise en place des critères 7.1 et 7.2 pour la mise en place de cache, de compression et de politique de gestion pour les données utilisées pour la phase d’apprentissage.

Le critère est validé si le service utilise, dès que cela est possible, des bases de données existantes et applique les critères 7.1. et 7.2 pour la phase d’apprentissage tout en documentant sa gestion de données, et l’inclusion des enjeux de sobriété, dans sa déclaration d’écoconception.

Niveau de difficulté : Faible

Niveau de priorité : Prioritaire

N/A si le service numérique n'inclut pas de phase d’entraînement

Métiers concernés : Porteur de projet, Data Scientist, Chef de produit marketing

Objectif

Il s’agit de questionner la fréquence des mises à jour et des réentraînements des modèles sous-jacents au service numérique en fonction des besoins réels du service (en termes de qualité et de vérifiabilité) et des besoins des cibles utilisatrices. Chaque mise à jour ou nouvel entraînement est consommateur en ressources et génère des émissions de gaz à effet de serre.

Mise en œuvre

Etablir dès la conception du service les paramètres de déclenchement d’un réentraînement du modèle. Ces paramètres devront tenir compte des besoins réels du service et des utilisateurs, notamment en termes de qualité, de fiabilité et de vérifiabilité. Analyser les données d'utilisation du service numérique pour ajuster en continu les besoins en termes de mise à jour des modèles. Prendre en compte les retours des utilisateurs, les évolutions technologiques et les changements dans l'environnement concurrentiel pour déterminer la fréquence optimale des mises à jour et de réentraînement. Minimiser autant que possible le réentraînement des modèles algorithmiques du service.

Moyen de test ou de contrôle

Fixer les conditions de déclenchement du réentraînement ou de la mise à jour des modèles algorithmiques du service en se basant sur les besoins réels des utilisateurs ou sur d’éventuelles contraintes légales. Minimiser la fréquence de ces opérations dans une démarche de sobriété. Documenter ces périmètres et les choix effectués dans la déclaration d’écoconception du service, en justifiant la prise en compte des principes d’écoconception.

Le critère est validé s’il est démontré que la fréquence de réentraînement est proportionnelle aux besoins du service et des cibles utilisatrices et est, autant que possible, minimisée grâce au suivi d’indicateurs (de performance, de satisfaction et de consommation en ressources).

Niveau de difficulté : Moyen

Niveau de priorité : Recommandé

N/A si le service numérique n'inclut pas de phase d’entraînement

Métiers concernés : Data Scientist, Architecte Logiciel, Responsable RSE/Numérique soutenable

Objectif

Compresser les modèles d’intelligence artificielle (réduction de complexité des modèles) pour réduire l’impact environnemental.

Mise en œuvre

Compresser les modèles via les méthodes suivantes :

• Sparsification ;
• Pruning ;
• Unification ;
• Local scaling (pour limiter l’impact de la quantification) ;
• Batch norm folding (réduire la redondance de certains paramètres) ;
• Quantification ;
• Distillation ;
• …

Moyen de test ou de contrôle

Le critère est validé si le service numérique justifie de la mise en œuvre de méthodes de compression de modèles, en indiquant les gains réalisés dans la déclaration d’écoconception du service numérique.

Niveau de difficulté : Faible

Niveau de priorité : Prioritaire

N/A si le service numérique n'inclut pas de phase d’inférence

Métiers concernés : Porteur de projet, Data Scientist, Développeur

Objectif

Réduire l’empreinte environnementale des modèles algorithmiques utilisés dans le domaine de l’intelligence artificielle en optimisant le besoin en ressources de leur phase d’inférence. Ce critère est particulièrement important pour l’intelligence artificielle (IA) générative. Si la phase d’entraînement a longtemps été perçue comme la plus consommatrice en énergie, le développement de l’IA générative tend à accroître la part de consommation d’énergie de la phase d’inférence, du fait du nombre de requêtes utilisateurs pour les services massivement consommés par le grand public. L’optimisation de la phase d’inférence est nécessaire pour aboutir à des modèles d’intelligence artificielle plus frugaux.

Mise en œuvre

Définir une stratégie d’inférence qui minimise le besoin en ressources et répond strictement au besoin des cibles utilisatrices. Mettre en place des indicateurs de suivi de consommation d’énergie, besoin en ressources de calcul, nécessaires à la phase d’inférence. Ces métriques sont à analyser par rapport à la satisfaction des utilisateurs. Fixer des objectifs de minimisation de la consommation en ressources, en tenant compte du ratio entre ressources consommées et satisfaction des utilisateurs. S’assurer que la phase d’inférence permet d’optimiser le nombre de requêtes utilisateurs.

Utiliser des CPU, GPU ou des TPU efficaces, dont la localisation géographique est cohérente avec leurs activités et minimise l’empreinte environnementale (en particulier, dans un pays à l’intensité carbone la plus faible possible).

Moyens de test et de contrôle

La stratégie d’inférence du service est adaptée aux cibles utilisatrices en minimisant les ressources nécessaires à son fonctionnement et les requêtes inutiles. Des indicateurs de suivi de consommation en ressources et de satisfaction des utilisateurs sont mis en place pour ajuster la phase d’inférence, avec pour objectif la frugalité du modèle sous-jacent au service.

Le critère est validé si le service numérique démontre dans sa déclaration d’écoconception la mise en place de principes d’écoconception dans sa phase d’inférence, adaptée aux besoins des utilisateurs.