Référentiel général d'écoconception de services numériques - version 1.0

Objectif

Éviter le service numérique inutile : si le service numérique ne s’inscrit pas 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, l’intégralité des impacts environnementaux qu’il génère est futile, donc à éviter.

Mise en œuvre

Pour évaluer l’utilité du service, se référer à des référentiels et déterminer en amont du projet si son utilité est avéré, comme par exemple :

• les 17 ODD de l’ONU
• les 9 limites planétaires
• autre ?

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 à une politique publique.

Afficher dans la déclaration d’écoconception (se référer aux critères dédiés) ou dans les mentions légales, les ODD dans lequel le service s’inscrit. Vérifier par exemple un ou plusieurs de ces points : sa pertinence, son utilité, sa création de valeur, son bien fondé, son service pour l’intéret général, sa réponse à des besoins essentiels, sa participation à la mise en place de commun numérique, etc.

Objectif

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

Mise en œuvre

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.

Objectif

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és 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

• Entretiens avec les différentes parties prenantes et les métiers concernés,
• Recherche UX auprès des utilisateurs cibles,
• 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éja existant

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 les renouvellements de matériels, il est important de connaître les profils de matériel que les utilisateurs vont pouvoir employer, aujourd’hui et demain : taille d’écran, écran tactile ou non, smartphone, tablette, ordinateur portable, ordinateur de bureau, etc.

Mise en œuvre

Définir le profil des matériels supportés, le plus ancien possible afin d’éviter toute obscolescence matérielle.

Objectif

Les gains d’énergie des nouveaux matériels ne permettent pas de contrebalancer les impacts liés à leur fabrication. Le service numérique doit limiter sa contribution à leur obsolescence en fonctionnant sur des équipements les plus anciens possibles.

Mise en œuvre

S’assurer pour chaque fonctionnalité, 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). 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 ni de contenu pour le service.
• Il s’agit de 5 ans “glissants” c’est à dire qu’il faut tenir compte du moment où l’audit est réalisé et non de la date de mise en ligne du service.
• Une durée de compatibilité plus longue est recommandée. Préciser dans ce cas, l’objectif, 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).

Objectif

Le service numérique doit participer à limiter l’achat de nouveaux terminaux en fonctionnant sur des équipements aux dimensions d’écrans variées, dont les plus petites (smartphones anciens par exemple).

Mise en œuvre

Uniquement si applicable, rendre l’interface du service numérique adaptable à la taille de l’écran sans perte d’utilisabilité (“Responsive design”). De plus, il vaut mieux éviter de dupliquer le service numérique avec une version spécifique pour chaque terminal.

Objectif

L’objectif est de lutter contre l’obsolescence des équipements induite par le logiciel. Par exemple, les applications natives ont 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. Peu d’applications natives fonctionnent sur des équipements au-delà de 7 ans. Alors que des services numériques web par exemple sont a priori disponibles dans tout navigateur et pour tout type d’équipement. Ce qui leur assure une bonne interopérabilité et une bonne longévité.

Mise en œuvre

Bien en amont du développement, évaluer la faisabilité avec des technologies standard (par exemple, web plutôt que des applications propriétaires) 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 sont bien supportés (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 améliorer la durabilité du code et de réduire le risque d’obsolescence induite par le logiciel sur le matériel.

Objectif

L’écoconception numérique adresse un très large périmètre, qu’il est difficile d’appréhender complètement dans chaque phase projet. Il est indispensable que les professionnels intervenant sur le projet puissent s’appuyer à tout moments sur une ou des personnes référentes afin de les assister dans les meilleures pratiques à déployer.

Mise en œuvre

Le ou les référents, internes ou externes, s’assurent de l’acculturation des équipes projet à l’écoconception de service numérique afin d’encourager sa prise en compte dans les projets.

Objectif

Connaître les impacts environnementaux du service numérique. 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 et dans l’usage de ce service numérique.

Mise en œuvre

Faire un diagnostic basé sur une méthodologie ACV, une analyse de cycle de vie (screening, simplifiée ou ISO) multicritère. Les indicateurs d’impacts environnementaux à considérer à minima la consommation d’énergie primaire, les émissions GES, la consommation d’eau bleue et l’épuisement des ressources abiotiques. Le périmètre de l’analyse de cycle de vie peut être élargi par exemple en tenant compte des moyens de productions : impacts environnementaux des équipements de conception, les services en ligne mobilisés (environnement de test, de QA…), les déplacements des équipes, etc.

Objectif

Minimiser l’empreinte environnementale du service numérique.

Mise en œuvre

Fixer les objectifs en matière d’empreinte environnementale du service numérique en au regard du nombre d’utilisateurs escomptés. Les indicateurs suivies doivent à a minima être la consommation d’énergie primaire, les émissions 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).

Objectif

Selon le contexte, un service numérique peut évoluer : équipe qui change, ajout de contenu par les utilisateurs, traitements de plus en plus gourmands, … Pour veiller à ce que la démarche d’écoconception dure dans le temps, il est important de réaliser régulièrement une revue.

Mise en œuvre

Revue, audit ou auto-audit régulier, tous les mois ou tous les ans selon le contexte et la taille du projet, en appliquant ce référentiel. De plus, réaliser des audits de performances et tests de charge au sein de l’application/composant/microservice avec identification des bottlenecks, des ressources utilisées, …

Objectif

Communiquer la stratégie mise en place afin de réduire les impacts environnementaux du service numérique, notamment la réduction de la contribution à l’obsolescence induite sur les terminaux.

Mise en œuvre

Cette déclaration d’une démarche volontaire, à afficher par exemple dans les mentions légales, aux côtés de la déclaration d’accessibilité ou bien sur une page dédiée, contiendra par exemple :

• Objectifs de Développement Durable (ODD), réponses aux enjeux des limites planétaires ou tout autre référentiel (à préciser) dans lequel s’inscrit ce service numérique.
• Versions logicielles du terminal utilisateur supporté (navigateur, système d’exploitation, etc.). Exemple : “iOS 11 minimum, Android année 2015 minimum…”
• Type, année de construction ou versions cibles des équipements utilisateurs supportés (type de smartphone, taille écran, etc.). Exemple : “iPhone 5 / Samsung Galaxy S3 minimum” ou bien “Tout équipement mobile datant de 2014 minimum”.
• Connexion minimum pour accéder au service. Exemple : “2G en mobile / 512 Kbs en connexion fixe”.
• Adaptation à différentes tailles d’écran : oui / non. Si oui, indiquer la taille minimum de l’écran.
• Stratégie mise en œuvre et objectifs en matière de réduction ou de limitation des impacts environnementaux : indiquer les actions mises en œuvre pour réduire la consommation de ressources, par exemple le nombre de requêtes serveurs maximum, le poids des ressources par écran ou pour un parcours utilisateur donné.
• Date de publication ou de mise à jour de cette déclaration.

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 pour un des objectifs la minimisation des impacts environnementaux.

Mise en œuvre

En impliquant l’ensemble de l’équipe, l’ensemble des métiers, une revue 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 faites en aval du développement.

Objectif

L’objectif est de décommisionner les environnements techniques encore actifs mais qui ne sont plus utilisés : Production, QA (Quality assurance), Test, environnement de développement, etc. Ces environnements occupent de la ressource informatique inutilement.

Mise en œuvre

Définir une stratégie de décomissionnement des environnements et des dates de rappel.

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.

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 au Guide pratique pour des achats numériques responsables .

Objectif

Connaitre les impacts environnementaux des composants d’interface (bouton, 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

Mesurer par exemple le poids de ces composants d’interface pour mieux faire un choix.

Objectif

Réduire les impacts environnementaux des services tiers, donc non issus de développement interne.

Mise en œuvre

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és des réseaux sociaux, mécanisme de captcha…) et évitant ainsi de les re-développer en interne. Une mesure d’outils analytics A/B test permet de connaitre les impacts environnementaux de celui-ci afin d’aider à la prise de décision sur le facteur environnemental.

Objectif

Le service numérique peut dépendre 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 soient également conçues de manière à réduire leurs propres impacts environnementaux.

Mise en œuvre

Évaluer la façon dont ont été conçus les composants existants. Sont-ils eux-mêmes soumis à ce référentiel ? Voir aussi les critères 2.4 et 2.5 pour la prise en compte des impacts des composants d’interface et des services tiers.

Objectif

L’objectif est d’éviter une architecture surdimensionnée et de privilégier une architecture capable de passer à l’échelle.

Mise en œuvre

Évaluer finement le besoin, le nombre d’utilisateurs pour adapter les ressources informatiques nécessaires.

Objectif

Limiter l’obsolescence du service induite par l’obsolescence du protocole utilisé, par exemple :

• 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) en garantissant son interopérabilité et sa pérennité,
• les navigateurs tendent vers le blocage du protocole HTTP et l’obligation d’utiliser HTTPS.

Mise en œuvre

Par exemple :

• Définir une stratégie de test IPv6 qui inclut 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,
• Dans un contexte où l’utilisateur accède au service numérique par son navigateur, il est obligatoire d’utiliser HTTPS au lieu de HTTP.

Objectif

Limiter ou réduire le transfert de données en choisissant un protocole adapté aux données à échanger, en répondant le plus sobrement possible aux usages actuels et à venir.

Mise en œuvre

Il s’agit de s’assurer de l’adéquation entre le choix du protocole et le type des contenus échangés, d’analyser les protocoles existants en fonction des contenus et des fonctionnalités en tenant compte de leur empreinte environnementale. Il existe de nombreux protocoles, chacun ayant ses avantages et ses inconvénients. Par exemple,

• pour le streaming vidéo : HTTP Live Streaming (HLS), Real-Time Messaging Protocol (RTMP), Web Real-Time Communications (WebRTC)…
• pour les API : REST, SOAP, GraphQL, Protocol Buffers…

Objectif

Limiter la contribution à l’obsolescence des équipements liés au service.

Mise en œuvre

Maintenir le service numérique pendant toute la durée prévue de l’équipement. Sont visés ici des équipements spécifiques et les objets connectés (IOT).

Objectif

Limiter la contribution à l’obsolescence des équipements utilisateurs. Promouvoir les politiques de support à long terme (“Long term support”).

Mise en œuvre

Ce critère est applicable surtout pour un service numérique de type api / composants / bibliothèque / framework / outils open source et beaucoup plus rarement un produit destiné à des utilisateurs finaux. Par exemple, une stratégie de gestion de versions avec des versions “Long term support” est mise en place et un changelog (journal des modifications) indique-t-il correctement les changements effectués par les mises à jour ?

Objectif

Si le service numérique s’adresse à un large public, vous ne maitrisez donc pas le niveau de connectivité. Il est nécessaire de veiller à ne pas exclure certains publics qui n’ont pas accès à de hauts débits. Tout en permettant de réduire la fracture numérique, il s’agit aussi 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, par conséquent, 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ées lorsque cela s’avère nécessaire.

Objectif

Éviter de précharger des contenus et de les lancer sans consentement de l’utilisateur.

Mise en œuvre

Par exemple, éviter de précharger et de lire automatiquement vidéos, sons, animations, carrousel, etc.

Objectif

Éviter le mur de contenus, la liste infinie, l’enchaînement infini de contenus.

Mise en œuvre

Mettre en place une pagination claire dont le chargement du contenu est à la demande de l’utilisateur et non au défilement du contenu.

Objectif

Minimiser le temps passé par l’utilisateur sur le service numérique.

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. Puis, observer les statistiques de fréquentation et d’usage, couplé aux moyens d’observation UX (expérience utilisateur), afin d’améliorer cette optimisation de parcours. 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 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 et les traduire en indicateurs d’impacts environnementaux.

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 pouvoir visionner la vidéo.

Mise en œuvre

Charger des contenus non indispensables qu’à la demande explicite de l’utilisateur. Ce critère rejoint une des obligations du RGPD sur la demande de consentement avant de charger du contenu tiers.

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.

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.

Objectif

Supprimer le poids des ressources médias téléchargées et utilisées pour l’esthétisme du service.

Mise en œuvre

Vérifier la pertinence sur l’usage de vidéos, animations et audios : ces médias sont-ils porteurs ou non d’une information (VS ces médias ne sont utilisés qu’à des fins décoratifs). S’interroger sur la pertinence d’utiliser des contenus vidéo, d’animation et audio décoratifs. Les micro-animations d’interface non décoratifs et apportant une information à l’utilisateur (UX) sont autorisées.

Objectif

Réduire le poids des ressources utilisées, sachant qu’une vidéo pèse généralement beaucoup plus lourd qu’un texte contenant des images.

Mise en œuvre

Questionner le besoin d’afficher un média (vidéo, animation ou enregistrement audio), très en amont et choisir la solution la plus sobre possible tout en répondant au besoin utilisateur.

Objectif

Donner le contrôle à l’utilisateur pour limiter l’usage de ressources non nécessaires.

Mise en œuvre

Proposer systématiquement une possibilité à l’utilisateur de mettre en pause les animations.

Objectif

Réduire la quantité et le poids des polices personnalisées utilisées. Privilégier l’utilisation des polices systèmes lorsque la personnalisation n’est pas nécessaire.

Mise en œuvre

Par exemple, se fixer comme objectif de n’utiliser qu’au maximum, deux polices différentes et au maximum quatre variantes au total. Vérifier par exemple la compression des polices ou l’usage des glyphes nécessaires. Dans un contexte de site web, faire attention aussi sur le mode de chargement : bloquant, non bloquant…

Objectif

Éviter de réaliser des requêtes clients / serveurs inutiles. Par exemple dans un contexte de formulaire, de suggestion de résultats, etc.

Mise en œuvre

Pour une aide à la saisie (“autocompletion”), attendre par exemple d’avoir 3 caractères et 200 ms après saisie avant de lancer une requête réseau.

Objectif

Limiter les échanges clients / serveurs en vérifiant la saisie du côté du terminal utilisateur.

Mise en œuvre

Vérifier les formats attendus lors de la saisie de l’utilisateur avant soumission du formulaire et indiquer les erreurs de saisie.

Objectif

L’objectif est d’éviter les requêtes serveur inutiles. Dans certains cas il n’est pas possible de vérifier côté client en fin de formulaire, la vérification sera alors du côté serveur.

Mise en œuvre

Valider les saisies et les formats de données obligatoires à la soumission d’un formulaire sans requête serveur lorsque cela est possible. Attention : pré-valider les données côté frontend n’exempt pas la validation côté backend.

Objectif

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

Mise en œuvre

Indiquer à l’utilisateur, avant le transfert, des poids et des formats de fichier attendus : un type de fichier, une taille max. d’image, etc.

Objectif

Limiter les échanges clients / serveurs de fichiers volumineux en imposant des limites à l’utilisateur.

Mise en œuvre

La soumission du formulaire n’est pas possible si les prérequis indiqués de poids et de formats de fichiers ne sont pas respectés. Attention cependant, non applicable dans certains contextes où le fichier demandé peut être potentiellement assez conséquent, par exemple pour une démarche en ligne.

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

Par exemple, pour chaque fichier téléchargeable, vidéo ou média 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. Il n’est pas nécessaire de fournir des équivalences en impacts environnementaux. Si ces dernières sont disponibles, il faut préciser la source et la méthodologie. Toutefois, il faut veiller à ce que ces informations soient en multicritères, pas uniquement en équivalent CO2.

Objectif

Réduire l’usage de ressources informatiques en évitant d’attirer inutilement l’attention de l’utilisateur ou en consommant inutilement des ressources informatiques.

Mise en œuvre

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

Objectif

Réduire l’usage de ressources informatiques en évitant d’attirer inutilement l’attention de l’utilisateur.

Mise en œuvre

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

Objectif

Donner de l’autonomie à l’utilisateur pour limiter les impacts environnementaux de ses usages.

Mise en œuvre

Exemples : des fonctions proposant de choisir la définition de l’image à télécharger, des possibilités de choix en résolutions des médias (vidéos, sons, images, documents), de désactiver l’affichage des médias, etc.

Objectif

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

Mise en œuvre

Choisir le format image adapté à la typologie d’image et au contexte d’affichage : utiliser le format vectoriel comme le svg lorsque cela est possible (illustrations, icones, logos, graphes…), le format jpg pour des photos et le format png pour des illustrations avec aplats de couleurs.

Objectif

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

Mise en œuvre

Ex. Lors de la génération d’une image JPEG depuis un logiciel de retouche, la compression à 60 % peut être visuellement acceptable. En PNG la réduction de la palette des couleurs est conseillée.

Aplatir les calques pour générer un format vectoriel SVG. Minifier et optimiser encore plus la compression en utilisant des outils dédiés.

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. L’objectif est de réduire le poids des fichiers téléchargés par les utilisateurs.

Mise en œuvre

Par exemple, éviter les vidéos avec une définition de 1080p ou plus affichées sur le site web quand le terminal cible ou détecté est un smartphone. S’il n’est pas possible de mettre en place cette adaptation selon le terminal cible, utiliser un contenu vidéo avec la plus faible définition possible sans que cela n’altère sa compréhension.

Objectif

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

Mise en œuvre

Par exemple, optimisation du Bitrate (débit) au sein du format.

Objectif

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

Mise en œuvre

Utiliser par exemple le MP3, OGG ou AAC au lieu du FLAC, AIFF ou WAV.

Objectif

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

Mise en œuvre

Exemples :

• optimisation du Bitrate (débit), du Ratio (Taux de compression) et de la Fréquence au sein du format,
• choix adapté Stéréo pour de la musique ou Mono pour des dialogues,
• éviter le ratio poids en mega-octet/durée en minute supérieur à 1.

Objectif

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

Mise en œuvre

Ex : réserver un PDF optimisé web (donc comportant des visuels en 72 dpi) pour une visualisation en ligne et un PDF optimisé impression HD (donc comportant des visuels en 150 ou 300 dpi) pour une utilisation destinée à l’impression HD.

Objectif

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

Mise en œuvre

Exemple : optimiser les paramètres de compression pour générer un PDF en résolution 72 dpi pour tous les médias du document.

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.

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ésigné la réponse du serveur. Définir et suivre un indicateur 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 à 500 Ko. Selon le contexte, cet objectif peut être beaucoup plus bas.

Objectif

Réduire ou limiter les échanges client - serveur.

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ésigné la réponse du serveur. Définir et suivre un indicateur nombre de 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 xemple, pour une site web, il serait intéressant d’avoir moins de 30 requêtes par page au lieu de 100. Attention, le nombre de requêtes seul ne peut être garant de la sobriété du service numérique, puisqu’une seule suffit à charger plusieurs dizaines de mégaoctets. Il faut bien veiller à valider tous les critères de ce référentiel, notamment le critère 6.1 sur la limitation du poids maximum par écran.

Objectif

Réduire le poids des données échangées.

Mise en œuvre

La stratégie de cache doit être adaptée au contexte d’application et au scénario d’usage. La gestion du mode déconnecté (offline) est parfois très pertinent, parfois non. Mettre en place un mécanisme de cache côté utilisateur, en frontend (cache HTTP par exemple).

Objectif

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

Mise en œuvre

Compression, minification des fichiers de scripts par exemple. Attention toutefois à ne pas générer de la consommation de ressource si 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 contre-productif. Ce critère s’applique uniquement aux fichiers texte (HTML, CSS, javascript par exemple). Ne pas confondre avec le critère 5.2 sur la compression des images.

Objectif

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

Mise en œuvre

Par exemple, lors de l’ajout des médias ou des éléments graphiques au service numérique, les dimensions d’affichages sont requises. Autre possibilité, valable surtout pour les images, un redimensionnement est réalisé coté serveur lors de l’ajout du fichier par un contributeur. Exception à cette règle : le cas des images pour écran Retina (l’image affichée dont la taille d’origine est généralement supérieure à son contexte d’affichage car la densité de pixels - device pixel ratio - est supérieure pour les images Retina).

Objectif

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

Mise en œuvre

Exemples : streaming pour la vidéo, chargement uniquement des images ou ressources affichées à l’écran (“lazy loading”)…

Objectif

N’utiliser que ce dont il est nécessaire pour le fonctionnement du service et économiser ainsi de la ressource informatique.

Mise en œuvre

Charger uniquement les composants nécessaires. Certaines bibliothèques rendent disponibles les composants pour une utilisation unitaire (par exemple Bootstrap . Autre exemple, le système de design de l’Etat est disponible sous forme packagée (feuilles de style et scripts) avec tous les composants. Il est rarement nécessaire d’utiliser tous les composants. Il est possible de ne charger que les fichiers CSS et javascript des composants nécessaires.

Objectif

Il est souvent plus simple pour l’équipe de développement de charger tous les composants, packagés dans un fichier compressé quelque 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 dont il est effectivement nécessaire pour le fonctionnement du service permet d’économiser ainsi de la ressource informatique.

Mise en œuvre

Ne charger les ressources et des composants que lorsqu’ils sont effectivement utilisés. Voir aussi critère 6.7 pour les composants d’interface.

Objectif

Réduire ou limiter les échanges client - serveur.

Mise en œuvre

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.

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

Validation de mécanismes d’alerte et de consentement avant tout déclenchement de capteur du terminal accepté par l’utilisateur.

Objectif

Limiter le nombre de domaines différents et donc de serveurs sollicités.

Mise en œuvre

Limiter le nombre de domaines différents pour les ressources utilisées afin notamment de profiter du multiplexing proposé par HTTP/2

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 regénérer. Prévoir une durée d’expiration pour les rafraichir.

Objectif

Réduire la quantité de ressources transférées sur le réseau.

Mise en œuvre

Mettre en place une compression de bout en bout (par exemple : https://developer.mozilla.org/fr/docs/Web/HTTP/Compression )

Objectif

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 cette donnée. Cf critère : 7.4

Objectif

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

Mise en œuvre

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. Cf critère 7.3

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) et informer l’utilisateur que le traitement est en cours, éventuellement une durée approximative de traitement.

Objectif

Favoriser un hébergement qui a des engagements en faveur de l’environnement.

Mise en œuvre

Sélectionner un hébergeur engagé dans cette démarche. Ou demander des engagements à l’hébergeur en ce sens. Proposé par la Commission Européenne, le Code de conduite européen est une initiative volontaire qui a été créée en réponse à l’augmentation de la consommation d’énergie dans les centres de données et à la nécessité de réduire les impacts environnementaux. L’objectif est d’informer et d’encourager les opérateurs et les propriétaires de centres de données à réduire la consommation d’énergie sans entraver la fonction critique des centres de données. Le Code de conduite vise à atteindre cet objectif en améliorant la compréhension de la demande d’énergie au sein du centre de données, en sensibilisant et en recommandant les meilleures pratiques et objectifs en matière d’efficacité énergétique. Les parties signataires doivent suivre ce code de conduite et respecter un ensemble d’engagements. En savoir plus sur le Code de conduite européen (pdf, 2022).

Objectif

Favoriser un hébergement qui a des engagements en faveur de l’environnement, autres que le Code de Conduite européen sur les datacentres.

Mise en œuvre

Sélectionner un hébergeur ayant des engagements environnementaux ou demander des engagements à l’hébergeur en ce sens :

• charte, politique
• certification environnementale : ISO14001, ISO50001, LEED, BREAM, HQE…
• mesure et communication des impacts
• mutualisation des ressources machines
• type de refroidissement utilisant des sources d’énergies renouvelables (eau, air…) ou récupération de la chaleur fatale
• analyse d’impact environnemental du “move to cloud” pour les acteurs ayant leur cloud on premise ? calculettes proposées par les fournisseurs en amont de la migration ?
• comment a été construit le datacenter ? artificialisation des sols
• etc.

Attention au greenwashing lorsqu’il s’agit de communications sur la neutralité carbone, une charte, une politique ou 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.

Objectif

Favoriser un hébergement qui a des engagements en faveur de l’environnement notamment sur 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 demander des engagements à un hébergeur ayant une politique transparente et écologique de sa gestion des équipements. Par exemple, il serait intéressant que l’hébergeur indique une durée de vie totale de ses équipements > 8 ans.

Objectif

Favoriser un hébergement qui mesure et qui rend disponibles les impacts environnementaux liés à son usage.

Mise en œuvre

Sélectionner un hébergeur ou demander des engagements à un hébergeur proposant des métriques environnementales, par exemple les indicateurs standard PUE, WUE, REF…

Objectif

Connaitre le PUE de son hébergement. Réduire ou limiter la consommation d’énergie nécessaire au bon fonctionnement et au refroidissement des serveurs.

Mise en œuvre

Sélectionner un hébergeur qui indique son PUE et la stratégie mise en oeuvre pour le réduire. Le PUE est un indicateur d’efficacité énergétique qui est 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). Plus ce PUE est proche de 1, mieux c’est. Généralement, il est constaté un PUE à 1,1 pour les hyperscalers et de 2 pour les plus vieux centres de données. Un PUE > 2,5 est trop élevé. Cependant, améliorer cet indicateur peut dégrader d’autres indicateurs, sans que cela 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.).

Objectif

Connaitre le WUE de son hébergement, indicateur souvent peu pris en compte. 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). On peut également prendre en compte notamment le stress hydrique local : 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. Cet indicateur est un ratio entre la quantité d’eau consommée et l’énergie totale utilisé par le centre de données. Il est mesuré en L/kWh. 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 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.).

Objectif

Promouvoir la transition vers des énergies renouvelables.

Mise en œuvre

Demander à l’hébergeur sa politique en terme d’achat d’électricité. Les PPA (Power Purchage Agreement), des contrats d’énergie renouvelable de long terme sont considérés 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, Renewable Energy Factor, page 99 . Un indicateur normé peut être suivi : le REF, le Renewable Energy Factor .

Objectif

Réduire la distance parcourue par les données et donc réduire l’infrastructure réseau mobilisée.

Mise en œuvre

Sélectionner un hébergeur dont la localisation de ses serveurs est proche des utilisateurs ou des activités identifiées. Cela ne correspond pas à adopter les technologies Edge Computing mais de choisir un centre de données proches des utilisateurs.

Objectif

Les données chaudes sont des données très utilisées alors que les données froides sont des données archivées. Utiliser des hébergements différents (bases de données différentes par exemple) 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.

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 coûteuse financièrement et environnementalement.

Mise en œuvre

Ne pas systématiquement dupliquer toutes les données. 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).

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 coûteuse financièrement et environnementalement.

Mise en œuvre

Se questionner sur la pertinence de la redondance du service. Est-ce critique si le service numérique 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, c’est par exemple une base de données “mirrorée” / dupliquée mais avec des VMs éteintes, procédé un peu plus cher qu’un Backup & Restore cela fonctionne pour la plupart des applications qui n’ont pas des exigences SLA extrêmes (inférieures à 1 heure).
• Le Warm Standby, c’est lorsque les VMs tournent déjà mais dans une scalabilité limitée, quasiment en temps réel mais potentiellement en qualité légèrement dégradée si incident.
• Le Hot Standby Multi-Site : total résilience pour des SLAs temps réel. Aucune perte de service n’est tolérée, mais forcément cela a un coût.

Objectif

Encourager les initiatives permettant de récupérer l’énergie produite, par exemple pour chauffer des batiments en hiver. Définition de la chaleur fatale selon l’ADEME

Mise en œuvre

Sélectionner un hébergeur ou demander des engagements à un hébergeur de réutiliser la chaleur fatale générée, par exemple, pour chauffer directement les bureaux ou d’autres installations à proximité.