Quatre mois après : que penser du RGESN v.1 2024 de l'ARCEP ?

Le , par Julien Wilhelm - Écoconception

Le 17 mai dernier, au Conseil National des Arts et Métiers à Paris, l’ARCEP officialisait la sortie de la version 1 du RGESN 2024, le Référentiel général de l’écoconception des services numériques. Si vous y étiez, vous m’avez forcément croisé : j’y animais une démonstration sur l’optimisation des images.

La sortie de ce référentiel était un petit évènement pour l’écosystème Numérique Responsable. C’en était un pour Temesis. Notre pôle écoconception s’est toujours beaucoup investi dans ce référentiel ; nous en attendions donc beaucoup.

Trop, peut-être ?
Il est temps de débriefer.

Au sommaire de cet article :

Note : vous ne savez pas ce qu’est le RGESN ni à quoi il sert ? N’hésitez pas à lire nos articles de 2022 sur le sujet : “Sortie du RGESN, le Référentiel Général d’Écoconception de Services Numériques” et “Valider une démarche d’écoconception avec le RGESN ?”.

Pourquoi attendre quatre mois pour parler du nouveau RGESN ?

Il s’est passé quatre mois depuis la sortie du RGESN v.1 2024.

Entretemps, Christophe (Clouzeau) et moi :

  • Avons vu les copains et les copines se réjouir à chaud sur la place publique, puis déchanter dans les couloirs.
  • Avons vu, à l’inverse, bon nombre de personnes pour qui tout semble incroyablement facile.
  • Avons d’ailleurs vu soudain sortir du bois des gens, des entreprises que nous ne connaissions jusque-là ni d’Ève ni d’Adam (mais nous n’avons pas la prétention de connaitre tout le monde, et il y a de la place pour tous).
  • Avons vu passer les premiers résultats (étrangement bons) d’audits, ainsi que les premières déclarations (extrêmement simplifiées) d’écoconception.

Nous avons vu tout cela, souvent, et nous n’avons pas réagi. Pire : nous avons reculé d’un pas, prenant bien soin de ne prendre part à rien. La vérité, c’est qu’il nous a fallu du temps pour véritablement maîtriser ce nouveau référentiel et lui laisser sa chance.

Parce que ce n’était pas gagné.

RGESN v.1 2024 : ces chiffres que vous ne connaissez pas sur la version de l’ARCEP

Avant d’entrer dans le détail de ce qui va et de ce qui ne va pas, voici deux salves de statistiques sur lesquelles m’appuyer par la suite.

Statistiques classiques

  • Nombre total de critères : 78

  • Nombre de critères par famille :

    • Stratégie : 10
    • Spécifications : 10
    • Architecture : 7
    • UX/UI : 15
    • Contenus : 8
    • Frontend : 7
    • Backend : 4
    • Hébergement : 10
    • Algorithmie : 7

  • Nombre de critères selon priorité de mise en oeuvre :

    • Prioritaire : 30
    • Recommandé : 28
    • Modéré : 20

  • Nombre critères selon difficulté de mise en oeuvre :

    • Fort : 16
    • Moyen : 41
    • Faible : 21

Ces statistiques attestent déjà de l’introduction de 3 nouveautés :

  • Famille “Algorithmie”, pour interroger l’usage de l’IA générative, et plus précisément ses phases d’entrainement.
  • Notion de priorisation, pour pouvoir identifier les critères où les impacts environnementaux évités / produits sont plus ou moins importants.
  • Notion de difficulté, pour pouvoir identifier les critères où les objectifs de conformité sont plus ou moins faciles à atteindre.

Statistiques expertes

C’est véritablement grâce au montage de la formation “Auditer la conformité RGESN d’un service numérique” pour laquelle plusieurs sessions sont d’ores et déjà programmées que j’ai pu enfin digérer ce référentiel. Et si je le reconnais, c’est surtout pour insister sur la complexité de ce dernier.

Voici les chiffres que j’en ai tirés :

  • Nombre de critères vraiment pour le Web : 66

  • Nombre de critères selon le type de contrôle principal :

    • Validation : 42
    • Analyse technique : 17
    • Analyse fonctionnelle : 13
    • Analyse technique & fonctionnelle : 6

  • Nombre de critères selon le type de diagnostic :

    • Binaire (c’est bon ou c’est pas bon) : 62
    • Appréciation de l’auditeur (ça dépend) : 16

  • Nombre de critères selon l’environnement de contrôle principal :

    • Déclaration d’écoconception : 33
    • Service numérique : 37
    • Variable : 8

  • Nombre de critères à documenter impérativement  :

    • Oui : 52
    • Non : 24
    • Selon les cas : 2

  • Nombre de critères inédits  : 18

  • Nombre de critères fusionnés  : 19

Que peut-on dire de tout cela ?

  1. Le RGESN, c’est pour le Web. 85 % des critères sont destinés à nos bons vieux sites et applications : cela laisse très peu de place pour le mobile et l’algorithmie, qui sont approchés, mais pour lesquels il serait — à mon sens — préférable de créer un référentiel spécifique.
  2. Il faut encore plus de compétences techniques qu’auparavant pour réaliser un audit RGESN ! Pour avoir monté une formation à ce sujet, je peux vous l’assurer : être auditeur ne s’improvise pas.
  3. Enfin, 67 % des critères au moins doivent être documentés.

Et c’est là mon premier grief avec le RGESN v1 de 2024.

Le problème avec la déclaration d’écoconception

Avant la reprise du référentiel par l’ARCEP (comprenez par-là : du temps où c’était la DINUM qui s’en occupait), la déclaration d’écoconception relevait du critère suivant :

1.12 : Le service numérique publie-t-il une déclaration ou une politique d’écoconception ?

Ce critère a été supprimé par l’ARCEP. Et pour cause : la déclaration d’écoconception ne fait plus l’objet d’un seul critère, elle devient un prérequis à l’audit RGESN (enfin, dès lors que vous souhaitez obtenir un score décent).

Ce prérequis concerne au moins 52 critères sur les 78 (67 % du total, donc). Pour certains d’entre eux, cela signifie maintenant que si le service numérique est conforme techniquement, mais qu’il ne publie pas de déclaration d’écoconception, ils ne pourront pas être validés.

J’ai pas compris (vous n’êtes pas seul)

Par exemple, pour le critère suivant :

6.2 : 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 ?

Si le service numérique utilise effectivement des mécanismes de mise en cache, sans expliquer en déclaration d’écoconception :

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

Alors le critère ne peut pas être validé.

En quoi c’est un problème ?

J’ai d’abord pensé que cet impératif de transparence était un excellent moyen de partager la connaissance. Au-delà du “montrer patte blanche”, cela pouvait permettre de s’inspirer, de s’emparer de solutions d’autrui pour répondre à ses propres problématiques.

Super !

Il s’avère cependant que les informations que l’on demande de publier ne sont pas toujours pertinentes pour le grand public. Et bien trop nombreuses ! Il y a un équilibre à trouver entre ce qui doit être prouvé à l’auditeur durant un audit et ce qui devrait être communiqué à l’utilisateur. Aujourd’hui, la balance penche du mauvais côté. La recherche de conformité s’en trouve d’autant plus fastidieuse. Pour ne pas dire décourageante.

À ce jour, la mise en application du RGESN n’est (toujours) pas une contrainte légale. C’est dommage, surtout que, conformément à l’article 25 de la loi REEN, il n’y a plus qu’à. En attendant, complexité oblige, il reste plus facile pour les entreprises et le public de se démotiver que de se retrousser les manches.

Quant à ceux qui s’y mettent (bravo à eux)… À date, nous n’avons vu passer aucune déclaration d’écoconception qui serait conforme à ce qui est exigé par l’ARCEP (et nous ne sommes pas les seuls). Conséquence directe : impossible d’obtenir un score très positif. Il me parait opportun de le glisser dans la conversation à l’heure où peuvent sortir des audits avec une conformité élevée. Il y a ici tromperie (ou incompréhension).

Et de l’incompréhension : il y en a déjà.

Un monde d’incompréhensions

Auditer n’est pas facile. Pouvoir se reposer sur la clarté d’un référentiel pour mener au mieux sa mission à bien est le minimum que l’on puisse attendre de ce dernier. Qu’arrive-t-il alors quand, entre experts, on ne parvient plus à s’entendre sur l’interprétation d’un même critère ? Quand nos convictions sont mises à mal ? Pour l’avoir vécu, je peux vous le dire : il s’en dégage de la frustration.

Le diable se cache dans les détails

De but en blanc, si je vous dis…

4.1 : Le service numérique comporte-t-il uniquement des animations, vidéos et sons dont la lecture automatique est désactivée ?

…Et si votre souhait est de valider ce critère 4.1, votre réponse au sujet de la vidéo d’arrière-plan en page d’accueil pourrait être…

OK, OK, on bannit la lecture automatique. Autant supprimer la vidéo, d’ailleurs…

Je sens bien la pointe de déception, mais c’est comme ça : en écoconception de services numériques, on propose au lieu d’imposer à l’utilisateur. Le lancement automatique de cette vidéo induit une surconsommation énergétique forte (téléchargement du média, décodage). C’est tout sauf une bonne pratique !

Pas si vite !

En creusant un peu le référentiel, je découvre dans la section “Moyen de test ou de contrôle” du critère 4.1 :

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).

Et, un peu plus loin :

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.

Traduction :

On peut laisser la lecture automatique du moment que l’on pense à proposer un bouton pause.

Oui, vous avez bien lu.

Ce critère est l’exemple type de ce qui pêche trop souvent avec le RGESN actuellement :

  1. Formulation trompeuse : si l’on s’en tient au libellé du 4.1, il parait impensable de maintenir la vidéo automatique. C’est pourtant possible sous conditions. Bien qu’il soit d’usage de potasser son référentiel pour bien cerner ce qui est attendu (difficile d’être toujours exhaustif dans l’intitulé d’un critère), on envoie ici des signaux contraires. Et puisque quelques critères ont été fusionnés par l’ARCEP, mieux vaut redoubler de vigilance.
  2. Nous en avons beaucoup discuté avec Christophe, l’introduction de multiples conditions pour valider un même critère se révèle souvent problématique. Ce n’est pas la notion même de conditions multiples qui est en cause (encore que par moment), mais bien les tournures de phrases avec des “et”, des “ou” et des doubles négations qui compliquent l’interprétation à la mise en œuvre et au contrôle.
  3. Quel recul sur les objectifs ! En écoconception, pour ce 4.1, on encouragera plutôt l’abandon de la lecture automatique pour les raisons évoquées plus tôt. Une telle porte de sortie, c’est incompréhensible.

Des retours tels que ceux-là, nous en avons tout un tableau.

Quelques exemples pour (encore) enfoncer le clou

6.7 : Le service numérique héberge-t-il toutes les ressources statiques transférées dont il est l’émetteur sur un même domaine ?

Auriez-vous pensé qu’il faille (aussi) vérifier que le service numérique n’exploite plus le protocole HTTP/1.1 pour valider ce critère ? Moi non plus.

4.4 : Le service numérique permet-il à l’utilisateur de décider de l’activation d’un service tiers ?

Ici, on ne parle en réalité que du dépôt de cookies. Le respect de la vie privée, c’est important, sauf que là, c’est le RGESN, pas le RGPD. On s’attend plutôt à traiter l’activation à la demande des intégrations tierces, un peu ce que proposent les façades.

D’ailleurs, en creusant le critère suivant :

6.5 Le service numérique évite-t-il de déclencher le chargement de ressources et de contenus inutilisés pour chaque fonctionnalité ?

Parmi les 4 points à vérifier, il est fait mention de ce qu’aurait dû être le 4.4 !

Je m’arrête là, vous aurez saisi l’essentiel : on s’emmêle les pinceaux.

Le RGESN est-il tout simplement devenu… Moins compréhensible ?

La question qui fâche. Imaginez un peu ma position (délicate) en tant qu’auditeur et formateur RGESN après tout ce que je viens d’écrire ! La réponse, je l’ai désormais bien en tête. C’est aussi pour cela que j’ai attendu un moment, le bon moment : pour trouver le juste équilibre entre le fond de ma pensée et le politiquement correct. Pour expliquer les choses sans amertume et satisfaire en toute transparence la demande de formation sur le sujet.

Le RGESN v.1 2024 de l’ARCEP n’est pas mauvais : il est inutilement complexe et parfois à côté de la plaque. Surtout, il doit continuer d’évoluer. Et vite ! N’oublions pas que la version précédente n’était pas exempte de défauts. Celle-ci est pleine de bonne volonté et apporte aussi son lot de positif.

Le RGESN v.1 2024 de l’ARCEP est plus que jamais ambitieux. Complétant les guides et autres bonnes pratiques en interrogeant non plus les résultats seuls, mais bien la démarche dans son ensemble, il peut prétendre à devenir un cadre légal à l’écoconception de services numériques. Un cadre français, mais pas que ! L’Europe, à terme, pourrait aussi être dans le collimateur grâce au BEREC.

Il faut donc rapidement prendre la balle au bond et se mobiliser pour lui co-construire un avenir radieux !