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

La redéfinition des objectifs est plus complète et plus claire 👏. On sent un gain de maturité.

Nous sommes beaucoup plus modérés sur la partie d’auto-évaluation. En effet, que le remplissage soit de bonne ou de mauvaise foi, on est loin d’avoir une mesure ou une évaluation de l’état des services numériques.

A Webvert, nous sommes tombés sur pas mal de cas où le ressenti et la situation réelle d’une mesure peuvent être complètement différents et pour cela, il faut des outils de mesure en masse. Le cas classique sont les gros sites d’e-commerce où l’équipe tech gère le rendu du catalogue produit et l’équipe marketing gère la homepage, les présentations de collections et le blog. Au sein d’un même service numérique, on va avoir une grande différence sur un même critère et en fonction de à qui on demande, on n’aura pas le même score.

Nous sommes plus proches d’une checklist de suivi pour des chefs de projets. Le référentiel évoque "indicateur de suivi de mise en œuvre du référentiel".

Ce n’est pas utilisable dans l’intégration continue comme pourrait le souhaiter un directeur ou une directrice technique mais nous sommes avantage dans de la déclaration administrative.

Nous l’avions suggéré lors de la phase de consultation, nous aurions préféré des standards de mesure et d’évaluation que les acteurs open source et propriétaires du marché appliqueront dans leur logiciel.

A part son nom, l’ajout de la partie Algorithmie/IA est une très bonne chose. En effet, si les data-centers sont construits de manière de plus en plus efficiente, la course à l’armement entre Azure, Google, Open AI, Meta, Mistral (et j’en oublie) et la Chine a fortement augmenté la dépense énergétique et l’achat de matériel dans les data centers.

Le point manquant est je pense la mise en place de profils de critères par type de service numérique. C’est un des retours du sondage de Christophe Clouzeau. Des initiatives pour avoir le RGESN dans un format technique (JSON) open source de Bertrand Keller, pourraient permettre de le faire.

Pour finir sur un point positif, le contenu des nouveaux critères est plus complet et plus décrit que sur la version 1.0.

Le cœur de cette partie du référentiel est du product management classique pour un éditeur ou une startup qui a une culture produit. Pour les modes projets à base de cahiers des charges, cela peut être un changement culturel important.

Quelques articles sur les différences entre culture projet et culture produit :

On s’étonnera de la disparition des critères orientés sur le matériel (surtout au vu du mix énergétique en France Métropolitaine). On les retrouvera dans les critères de spécification (Ce qui fait sens).

Dans l’autre sens : le critère Le service numérique a-t-il recours à un niveau de chiffrement adapté à ses besoins ? me semble dangereux d’un point de vue de la sécurité. En effet, depuis la guerre en Ukraine, la guerre cyber s’est intensifiée. Sur le terrain, j’ai davantage vu des défauts de chiffrement par manque de budget que de l’abus de service de chiffrement.

C’est surtout une réorganisation de critères que de réel changement. Cela a l’avantage de regrouper les critères liés à l’obsolescence matérielle en un seul endroit. Cela pourra permettre de contrebalancer les arbitrages du type On arrête de supporter ce type de matériel car c’est moins de 4% des utilisateurs.

DIVULGÂCHER : Critères qui seront complètement oubliés au critère 5.1

Les ajouts viennent mitiger les effets rebonds liés à la qualité des réseaux et la capacité d’ajouter des machines virtuelles très facilement pour les environnements de développement. Les leviers sont importants sur ce dernier tant environnemental que financier (FinOps).

Après globalement, cette partie est très orientée grand public/application mobile. Elle occulte tant de domaines de l’architecture logiciel. Si les DSI ont un nouveau critère sur les environnements de développement, il y en aurait tellement d’autres : règle de backup et de redondance d’architecture, efficience du code, mise en place de test de performance et d’amélioration continue de la performance (sans ajouter de nouveaux serveurs), capacité à monter à l’échelle en partant d’une base d’utilisation des ressources très basse, bonne utilisation des services natifs des services de cloud computing (à contrebalancer avec le locking avec un cloud propriétaire), non-duplication de même code/service interne.

Cette partie était assez riche, quelques réorganisations des critères ont été faites.

Cependant, elle reste toujours très grand public et parlera peu aux DSI et aux éditeurs/startups B2B. Pour ce public, le RGAA (référentiel d’accessibilité) sera beaucoup plus actionnable. En effet, respecter les critères d’accessibilité vous poussera naturellement à faire une interface plus sobre et plus compréhensible.