Et si on mesurait le numérique responsable comme on mesure la fiabilité ?

Et si on mesurait le numérique responsable comme on mesure la fiabilité ?

Jérémy Latorre Numérique responsable, Dev ops 7 novembre 2025 5 min de lecture

Les SLO (Service Level Objectives) ont révolutionné la fiabilité des systèmes. Et si on les appliquait à l’empreinte environnementale du numérique ?

Le paradoxe du numérique responsable

On parle tous de numérique responsable. On signe des chartes, on fait des webinaires, on sensibilise. Et pourtant, dans la plupart des organisations, impossible de répondre à cette question simple :

“Combien de CO2 a émis notre application ce mois-ci ?”

Le numérique responsable reste souvent coincé entre le discours de principe et l’absence d’outils concrets pour piloter. Résultat ? On avance à l’aveugle, en espérant que nos bonnes intentions suffisent.

L’inspiration du SRE

Les ingénieurs en fiabilité (Site Reliability Engineering) ont résolu un problème similaire il y a 15 ans : comment rendre la disponibilité des services mesurable et pilotable ?

Leur solution tient en trois concepts :

  • SLI (Service Level Indicator) : une métrique précise (ex: temps de réponse)
  • SLO (Service Level Objective) : un objectif chiffré (ex: 99,9% de disponibilité)
  • Error Budget : la marge de manœuvre pour innover (ex: 0,1% d’indisponibilité autorisée)

L’idée disruptive ? Transformer la fiabilité d’une contrainte technique en outil de négociation entre équipes produit et tech.

Petit aparté sur le budget error: Le budget error c’est la marge d’erreur qu’on s’autorise vis à vis d’un SLO. Tant que le budget error n’est pas consommé, tout va bien. Lorsque l’on atteint la limite fixée on doit se poser la question du risque (ou de l’impact dans notre cas) que l’on souhaite prendre sur une mise en prod ou d’une modification impactante d’une feature.

Dans le cadre de la disponibilité d’un service par exemple, si mon budget errror a déjà bien été entamé est-ce que je prends le risque de rajouter une feature qui pourrait encore baisser mon SLI sur la fenêtre de temps ciblée? A l’inverse si je n’ai pas encore consommé mon budget error, alors je peux me permettre de rajouter cette feature sans risque car j’avais budgétiser ce temps d’indisponibilité. (évidemment il faut mesurer à l’avance l’impact potentiel). C’est vraiment un outil de pilotage du risque.

Et si on appliquait ça au carbone ?

Imaginons une API critique de votre entreprise. Au lieu de vaguement “essayer de faire mieux”, vous définissez :

SLI : Consommation énergétique par requête
SLO : “95% des jours, consommer moins de 1 kWh / 1000 requêtes”
Budget carbone mensuel : 100 kgCO2eq maximum

Concrètement, ça change quoi ?

Avant (approche classique)

Dev/Métier : "On ajoute cette fonctionnalité ?"
Tech Lead : "Euh... ok, mais pensez à l'éco-conception..."
→ La feature passe, l'impact reste inconnu

Après (avec SLO)

Dev/Métier : "On ajoute cette fonctionnalité ?"
Responsable du SLO : "Ça va consommer 15 kgCO2. On est déjà à 80% du budget."
Options :
1. On reporte à mois prochain
2. On optimise d'abord le service X (-20 kgCO2)
3. On redimensionne cette feature
→ Décision éclairée, impact maîtrisé

Par où commencer ?

Oubliez les grands plans. Commencez petit :

1 - Choisissez UN service, celui qui consomme le plus ou celui sur lequel vous avez le plus de contrôle.

2 - Mettre en place une mesure sur laquelle tout le monde est alignée.Juste mesurez. Installez Cloud Carbon Footprint, Scaphandre, ou CodeCarbon selon votre contexte. Même un tableur fait l’affaire au début. Le tout étant de tracer de manière factuel l’évolution de la métrique.

3 - Identifiez 2-3 “quick wins” évidents (serveurs inutilisés, over-provisioning, data zombies). Implémentez-les. Impact typique : -20 à -30% immédiatement.

4 - Au bout d’un certain temps de mesure (le temps de stabiliser la mesure surtout si l’activité est cyclique), définissez votre premier SLO. Pas parfait, pas ambitieux. Juste un seuil basé sur votre baseline + 10-15% d’amélioration par exemple. L’idée n’est pas de définir un SLO inatteignable mais une cible raisonnable qui ne se met pas dans le rouge systématiquement. Il doit être un outil d’aide à la décision.

5 - Tenez-vous y. Créez un rituel pour analyser les résultats.

6 - Une fois le SLO atteint et stabilisé, vous pouvez soit le conserver car il est raisonnable et conforme aux ambitions, soit le renforcer si vous avez besoin d’atteindre un objectif plus ambitieux.

7 - Une fois le concept maitrisé, vous pouvez le porter à d’autres services.

Le SLO doit notamment servir à atteindre des OKR (Objectifs et Key Results) liés à la durabilité dans le cadre des objectifs définis par l’entreprise.

Les vraies questions que ça pose

Cette approche n’est pas magique. Elle soulève des questions inconfortables :

Question 1 : Êtes-vous prêts à bloquer un déploiement parce que le budget carbone est épuisé ?
(Spoiler: c’est là qu’on commence à rigoler)

Question 2 : Comment arbitrer entre latence et sobriété ?

Question 3 : Qui est responsable ? L’équipe produit ? L’équipe infra ? La Direction ?
Sans ownership clair, ça ne marche pas.

Question 4 : Et les utilisateurs ? Sont-ils prêts à accepter une feature en moins si c’est pour le climat ?

Le piège de la perfection

Le plus gros risque ? Vouloir tout mesurer, tout optimiser, tout de suite. C’est la meilleure façon d’échouer.

Mieux vaut :

  • 1 SLO tenu pendant 6 mois
  • Que 10 SLO définis et abandonnés au bout d’un mois

La vraie victoire, c’est quand vos équipes commencent naturellement à dire :
“Cette requête là, elle coûte combien en carbone ?”

Le numérique responsable ne peut plus se contenter d’être un discours. Il a besoin d’outils opérationnels, de métriques partagées, de rituals d’équipe.

Les SLO “verts” ne sont qu’une approche parmi d’autres. Mais ils ont un avantage : ils fonctionnent pour la fiabilité depuis 15 ans. Pourquoi pas pour la durabilité ?

Débattons : Pensez-vous qu’on puisse vraiment gérer l’impact environnemental comme on gère la disponibilité ? Ou est-ce que ça rate quelque chose d’essentiel ?

Et concrètement, êtes-vous prêts à bloquer un déploiement pour respecter un budget carbone ?

Ressources pour aller plus loin :

:
:

Comment j’ai ressuscité mon vieux laptop de 2016 avec Linux (et pourquoi c’est un acte de numérique responsable)

Comment j’ai ressuscité mon vieux laptop de 2016 avec Linux (et pourquoi c’est un acte de numérique responsable)

Il y a des projets qu’on repousse pendant des années par pure flemme. Pour moi, c’était celui-ci : redonner vie à mon vieux laptop Acer Aspire V 13 de 2016, abandonné depuis des mois à cause d’une batterie HS, d’un chargeur cassé, et d’une lenteur à faire pleurer.

Lire la suite