La plupart des DSI et CTO ne manquent pas d’intérêt pour le sujet de l’écoconception, mais ils manquent de temps. « A quel point mes applications consomment-elles plus qu’elles ne le devraient ? » reste malheureusement une question sans réponse dans beaucoup de roadmaps.

Dans la majorité des cas, ce n’est pas un problème de budget mal négocié, c’est un problème de conception (des applications qui sollicitent les ressources bien au-delà de ce que les usages réels justifient).

L’écoconception logicielle n’a pas besoin d’un label RSE à afficher, mais d’un diagnostic technique qui révèle où votre stack consomme inutilement, et ce que ça vous coûte.

Pourquoi ce sujet finit-il souvent dans la colonne « à faire plus tard » ?

Le raisonnement est connu, la roadmap est chargée et l’équipe tient le rythme. Les sujets de fond comme l’impact du logiciel sur les ressources infra passent après les features produit et après la sécurité. L’écoconception peut donner l’impression d’un chantier de plus, avec un ROI difficile à chiffrer et une pression externe qui ne se fait pas encore vraiment sentir.

C’est précisément dans ce cas qu’un audit apporte de la valeur, avant que les inefficacités ne se renforcent dans l’architecture, pas après. Non pas parce que la réglementation l’impose aujourd’hui (la loi REEN, en vigueur depuis janvier 2025, ne s’applique pour le moment qu’aux services numériques de l’État et des collectivités), mais parce que chaque sprint qui passe sans adresser ces points les ancre un peu plus dans la base de code.

Ce que le monitoring ne voit pas

Un outil de monitoring du SI mesure ce qui se passe. Un audit d’écoconception logicielle analyse pourquoi ça se passe comme ça, si ce comportement est justifié, et quels sont les impacts sur les parties généralement non supervisées : les devices utilisateurs ou les environnements hors production.

Les constats les plus fréquents :  

• Des environnements de staging qui tournent en continu sur des machines surdimensionnées pour des usages ponctuels,
• Des pipelines CI/CD qui déclenchent des builds complets à chaque commit, y compris sur des branches jamais déployées.
• Des APIs qui retournent des payloads entiers alors que les clients n’en consomment qu’une fraction.
• Des bases de données dont les volumes ont doublé en deux ans sans qu’aucune politique de rétention n’ait été définie.

Aucun de ces points n’est visible dans un dashboard. Ils apparaissent lorsqu’un expert analyse le fonctionnement réel de l’application et de son écosystème, couche par couche : architecture applicative, implémentation backend et frontend, gestion des données, cycle de vie DevOps.

RGESN 2024, le référentiel qui structure l’audit

Le RGESN 2024 (Référentiel Général d’Ecoconception des Services Numériques) définit 78 critères couvrant l’ensemble du cycle de vie d’un service numérique. Co-piloté par la DINUM, l’ADEME, et l’Arcep, c’est le cadre de référence en France pour évaluer l’impact environnemental d’un logiciel. Il est complété par les 115 bonnes pratiques GreenIT pour la couche frontend (poids des pages, requêtes inutiles, rendu côté client).

C’est ce référentiel qui structure notre audit et le plan d’actions. Il garantit une grille d’analyse cohérente, indépendante de la stack technique et dont les résultats sont directement comparables d’un projet à l’autre.

Trois livrables, un plan d’action directement exploitable

À l’issue de la mission, trois livrables sont remis :

• Un rapport technique classé par axe et par priorité de remédiation, à destination des équipes,
• Une présentation synthétique avec radar par dimension, conçue pour les arbitrages de direction,
• Un plan d’action structuré, directement intégrable dans une roadmap ou un budget trimestriel.

Ce que ça change pour un CTO

Un audit écoconception bien conduit doit produire trois résultats exploitables immédiatement.  

• Des économies infra identifiées et chiffrées avec les actions de rightsizing ou de nettoyage à mener en priorité.  

• Des arguments techniques solides pour les arbitrages de roadmap : quand une recommandation de refactoring peut être présentée avec un impact positif environnemental ET financier, elle a plus de chances de passer en comité.  

• Une base de travail pour la démarche numérique responsable de l'entreprise : reporting RSE, engagement vis-à-vis des clients, préparation à une réglementation qui s'étendra progressivement au-delà du secteur public.  

L’urgence n’est pas forcément réglementaire, elle est technique

Pour les acteurs privés, la pression viendra des donneurs d’ordre, des appels d’offres ou des engagements RSE de l’organisation. Mais l’argument principal pour agir maintenant est ailleurs… Il se situe dans une architecture jamais auditée sous l’angle de la sobriété numérique, et dans le coût croissant que cela représente à chaque sprint.

Inefficacités environnementales et inefficacités de conception partagent souvent les mêmes causes, des choix d’architecture non revus, des pipelines jamais (ou presque) optimisés, des données jamais purgées. Plus tôt elles sont adressées, moins elles coûteront à corriger.