Analyse critique de la nouvelle version du Référentiel Général d'Éco-conception des Services Numériques (RGESN) - 3/3

Rédigé le 03/06/2024 par Youen Chéné

SENSIBILISATION TECHNIQUE

Avant-propos

Cet article fait partie d’une série et fait suite à :

Cet article est le dernier de la série et couvre les groupes de critères de 6 à 9.

Partie 7 : Critères "Front End"

Ont été fusionnés dans un même critère (6.1) :

6.1 Le service numérique s’astreint-il à un poids maximum par écran ?
6.2 Le service numérique s’astreint-il à une limite de requêtes par écran ?

Ont été fusionnés dans un même critère (6.5) :

6.6 Le service numérique propose-t-il un mécanisme de chargement progressif pour les éléments graphiques et les médias le nécessitant ?
6.7 Le service numérique se limite-t-il au chargement des composants utilisés au sein des bibliothèques lorsque cela est possible ?
6.8 Le service numérique évite-t-il de déclencher le chargement de ressources et de contenus inutilisés pour chaque fonctionnalité ?

A disparu :

6.9 Le service numérique utilise-t-il un stockage côté client de certaines ressources afin d’éviter des échanges réseaux inutiles ?

Notre Avis

Cette partie a été rationalisée pour meilleure lecture.

L’ancien 6.9 relève plus de la solution technique dont la cible est couverte par l’objectif du critère 6.1

En point d’amélioration, le 6.2 sur le cache navigateur aurait bénéficié de critère avec des propositions de réglages par type de service numérique. Dans sa rédaction actuelle, n’importe quel réglage de cache valide le critère.

Partie 8 : Critères "Back End"

A disparu :

7.2 Le service numérique est-il configuré pour transmettre depuis le serveur des contenus compressés au client qui les accepte ?

Ont été fusionnés dans un même critère (7.2) :

7.3 Le service numérique définit-il des durées de conservation sur les données et documents qui le nécessitent ?
7.4 Le service numérique archive-t-il ou supprime-t-il les données et documents après expiration de leur durée de conservation ?

Ajout d’un critère :

7.4 Le service numérique s’appuie-t-il sur un mécanisme de consensus qui minimise sa consommation de ressources ?

Notre Avis

Cette partie a été rationalisée.

La suppression du 7.2 n’est pas choquante, il fait complètement doublon avec le 6.3.

Le nouveau paragraphe ajouté pourrait préciser directement que c’est principalement le consensus de Blockchain qui est visé (Rappel: Ethereum est passé de Proof Of Work à Proof of Stakes qui est beaucoup plus sobre en termes d’énergie nécessaire).

Le principal problème de cette partie est qu’elle est assez vide et trop centrée Web de contenu. Les équipes de développeurs des DSI, éditeurs et startups resteront sur leur faim et n’utiliseront purement et simplement pas le RGESN. Il y a tellement de sujets à traiter (voir la première partie).

Partie 9 : Critères "Hébergement"

Ont été fusionnés dans un même critère (8.1) :

8.1 Le service numérique utilise-t-il un hébergement signataire du Code de Conduite européen sur les Datacentres ?
8.2 Le service numérique utilise-t-il un hébergement ayant une démarche de réduction de son impact écologique ?
Dans une certaine mesure 8.4 Le service numérique utilise-t-il un hébergement qui fournit des indicateurs d’impacts environnementaux liés à son activité ?

Ont été fusionnés dans un même critère (8.9) :

8.10 Le service numérique duplique-t-il les données uniquement lorsque cela est nécessaire ?
8.11 Le service numérique utilise-t-il une redondance uniquement lorsque cela est nécessaire ?

A été ajouté :

8.10 Le service numérique tient-il compte des contraintes externes pour minimiser l’impact environnemental des calculs et transferts de données asynchrones ?

Notre Avis

Cette partie a subi un peu de rationalisation.

A notre goût, 3 critères devraient être dans la partie architecture : le 8.8 (données chaude et froide), le 8.9 (redondance) et le 8.10 (traitement en décalés).

Enfin, les parties 8.1 et à 8.5 pourraient avoir des modèles préremplis par les hébergeurs (OVH, Scaleway, Amazon, Google, Microsoft) en fonction des services choisis chez eux. Honnêtement, en étant chez OVH le critère 8.1, il est inutilement long à remplir.

Partie 10 : Critères "Algorithmie"

Le chapitre le plus mal nommé du RGESN. La partie ne concerne que les services numériques reposant sur une intelligence artificielle.

L’algorithmie est plus large, un algorithme de tri sur un ordinateur à 7mhz des années 80, c’est de l’algorithmie.
Intelligence Artificielle (IA) est un mot-valise. Entre un SVM, un Random Forest (des algorithmes d’apprentissage artificiel/machine learning encore très utilisés) et des entraînements en deep learning et sa variante en LLM (Chat GPT et équivalent) nous ne sommes pas du tout dans le même paradigme d’utilisation des ressources informatiques.

Algorithme est-ce que l’on peut faire des crêpes aujourd’hui.

Figure 1. Un algorithme peut être simple et très sobre (source).

Les critères visent directement les réseaux de neurones profonds (Deep Learning) et tout particulièrement l’IA Générative.

Les critères couvrent les différentes phases :

Le besoin : 9.1, 9.2
L’entraînement : 9.2 9.3, 9.4
L’optimisation : 9.5, 9.6
La phase d’usage (les inférences) : 9.7

Notre Avis

Au vu de l’actuelle guerre à l’armement sur le sujet où un maximum d’entreprise ajoute le terme IA pour être à la mode (que l’IA apporte de la valeur ou non), cet ajout, certes mal nommé, est nécessaire.

Elle couvre bien l’ensemble du cycle de vie. Pour nous le plus important sont le 9.1 (en a-t-on vraiment besoin) et le 9.2 (est-ce qu’un modèle déjà entraîné couvre déjà le besoin ou un algorithme de machine learning classique est-il plus efficace ?).

Sur les points d’optimisation, les approches vont rester encore assez expérimentales pendant les 18 prochains mois, peu d’équipes auront la maturité de valider la partie optimisation.

Partie 11 : Conclusion

Pour réaliser un récapitulatif de cette nouvelle version, on va classer les remarques générales en 3 blocs.

Le positif

La définition des objectifs.
Des critères sont bien mieux décrits que dans la version d’il y a 18 mois.
L’ajout de la partie IA/Deep Learning LLM.

Le neutre

Un peu de rationalisation des critères qui peuvent améliorer la lisibilité ou la rendre plus compliquée à lire selon les cas.

Le négatif

Le groupe de critères "5/Contenus" qui a eu une évolution catastrophique en optimisant la consommation électrique par rapport à l’impact de fabrication en provoquant de l’obsolescence d’équipement.
L’usage du terme algorithmie 🤦‍.
Au final, peu de critères pour les équipes qui développent des applications avec une part back-end importante. Les développeurs et développeuses des équipes des DSI, éditeurs et startups vont vraiment rester sur leur faim et au final mettre le RGESN de côté.
Une évaluation très manuelle et très dépendante de l’interprétation de la personne qui audite. Elles seront difficilement comparables et automatisables.

Derniers mots

Une évolution d’un référentiel par petits pas avec une immense régression sur les critères Contenus. Avec un peu de recul, la consultation d’octobre/novembre n’a peu servi. Peu de dialogues ont été engagés avec l’écosystème (je suis aussi membre de Boavizta).

Il a été promis des forums d’échange sur le sujet. Comme on me l’a conseillé à plusieurs reprises, il faut être patient. On le sera sauf sur le groupe de critère 5/Contenus qui est juste à l’opposé de ce que devrait être le RGESN.

En attendant, vous pouvez aller sur le slack des Designers Éthiques venir discuter d’amélioration du référentiel.