Écoconception numérique : 16 mesures inscrites au référentiel de l’État

Ne charger les éléments qu’à leur affichage. C’est le principe du lazy loading. Il en est question dans un référentiel que le Gouvernement vient de publier, à l’issue d’une phase de consultation publique. Sujet : l’écoconception de services numériques.

Disponible sous licence Etalab v2, ce RGESN s’ajoute, entre autres, aux RGAA (accessibilité numérique), RGS (sécurité), RGI (interopérabilité), R2GA (gestion des archives) et RGPD. Il se divise en huit thématiques. Les voici ; avec, pour chacune, deux des points qu’elles englobent.

Stratégie

« Le service numérique est-il utilisable sur des terminaux âgés de 5 ans ou plus ? »
On parle là de compatibilité avec un matériel ; pas avec un OS ou tout autre logiciel. « Utilisable » sous-entend « mode dégradé accepté, mais sans perte de fonctionnalité incontournable ni de fonctionnalité pour le service ».

« Le service numérique a-t-il été conçu avec des technologies standard interopérables plutôt que des technologies spécifiques et fermées ? »
Le constat : peu d’apps natives fonctionnent sur des équipements au-delà de 7 ans. Alors que des services numériques web « sont a priori disponibles dans tout navigateur et pour tout type d’équipement ». On s’assurera aussi que les API sont standard.

Spécifications

« Le service numérique a-t-il prévu une stratégie de décommissionnement pour ses fonctionnalités, ses composants ou ses environnements non utilisés ? »
Il s’agit ici de tous les environnements techniques actifs mais qu’on n’utilise plus : production, QA, test, dev… Solution envisageable : définir une stratégie avec des dates de rappel.

« Le service numérique a-t-il pris en compte les impacts environnementaux des services tiers utilisés lors de leur sélection ? »
Le message : attention à l’empreinte de ces services tiers qui vont du suivi d’audience aux lecteurs vidéo en passant par les captchas.

Architecture

« Le service numérique a-t-il pris en compte l’évolution technique des protocoles ? »
Deux exemples. D’une part, les navigateurs qui « tendent vers le blocage de HTTP et l’obligation d’utiliser HTTPS ». De l’autre, la pénurie d’IPv4 et la généralisation d’IPv6. Sur ce dernier, on pourra définir une stratégie incluant des tests depuis un équipement sans connectivité IPv4… et déceler les fonctionnalités ainsi inopérantes.

« Le service numérique utilise-t-il un protocole d’échange adapté aux contenus transférés ? »
Pour la vidéo, plutôt HLS ? RMTP ? WebRTC ? Pour les API, REST, SOAP ou GraphQL ? On fera en sorte de choisir les protocoles qui limiteront ou réduiront les transferts de données.

UX / UI

« Le service numérique optimise-t-il le parcours de navigation pour chaque fonctionnalité principale ? »
L’idée : minimiser le temps que l’utilisateur passe sur le service. Dans cette optique, on mettra en place un système d’analyse – « non intrusif et respectueux de la vie privée » – des parcours-types. Sur lesquels on mesurera des indicateurs techniques (nombre de requêtes, poids des ressources téléchargées…) qu’on traduira en indicateurs environnementaux.

« Le service numérique utilise-t-il majoritairement des polices de caractères du système d’exploitation ? »
Le RGESN recommande de n’utiliser au maximum que deux polices et quatre variantes. Tout en vérifiant leur compression et, dans un contexte de site web, leur mode de chargement.

Contenus

« Le service numérique propose-t-il des images dont le niveau de compression est adapté au contenu et au contexte de la visualisation ? »
Parmi les mesures que liste le RGESN :
– La compression JPEG à 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

« Le service numérique a-t-il une stratégie d’archivage et de suppression, automatiques ou manuelles, des contenus obsolètes ou périmés ? »
Il en va ici d’une logique d’allègement des bases de données et des serveurs physiques. Recommandation : automatiser avec des dates d’expiration.

Front-end

« Le service numérique utilise-t-il des mécanismes de mise en cache pour la totalité des contenus transférés dont il a le contrôle ? »
Message : mettre en place un mécanisme de cache côté utilisateur… en l’adaptant évidemment au contexte d’application et au scénario d’usage.

« Le service numérique se limite-t-il au chargement des composants utilisés au sein des bibliothèques lorsque cela est possible ? »
Recommandation : lorsque c’est possible, c’est-à-dire lorsque les bibliothèques permettent un usage unitaire de leurs composants, ne charger que le nécessaire.

Back-end

« Le service numérique a-t-il recours à un système de cache serveur pour les données les plus utilisées ? »
Même réflexion que sur le front-end. On identifiera les données, les entrées API et autres ressources les plus utilisées. Puis on les mettra en cache pour éviter de les régénérer.

« Le service numérique informe-t-il l’utilisateur d’un traitement en cours en arrière-plan ? »
Problème : l’utilisateur, s’il ne sait pas que son action est en cours de prise en compte, peut provoquer des requêtes simultanées. Solution : rendre indisponible l’action en question et informer l’utilisateur que le traitement est en cours. Éventuellement avec une durée approximative.

Hébergement

« Le service numérique utilise-t-il un hébergement dont la localisation géographique est en cohérence avec celle de ses utilisateurs et de ses activités ? »
Il s’agit ici de réduire la distance que les données parcourent. Et donc l’infrastructure réseau mobilisée.

« Le service numérique duplique-t-il les données uniquement lorsque cela est nécessaire ? »
Consigne : éviter de dupliquer systématiquement. On réservera ce traitement aux données critiques ou très sollicitées, par exemple. Une question que le RGESN pose aussi pour la redondance.

Photo d’illustration générée par IA