concevoir stratégie Finops Greenops

FinOps et GreenOps : construisez une stratégie alignée

Auteur : Thomas Bénézech, Expert Green IT
Thomas Bénézech Expert Green IT
13 mins
13 mars 2024
Dans cet article :
  1. Définir le GreenOps
  2. Sobriété et efficacité : les clefs de l’optimisation GreenOps
  3. Le Green IT n’est pas (que) GreenOps
  4. Définir et comprendre le périmètre et les impacts GreenOps
  5. Méthodologie d’un GreenOps 360 ou GreenOps intégré
  6. Indicateurs et objectifs GreenOps
  7. Conclusion

Tracté par la croissance de l’intérêt pour le FinOps au sein de la communauté « Cloud », le GreenOps gagne petit à petit du terrain. Toutefois, si le FinOps semble une notion claire et communément admise, le GreenOps reste encore mal défini. Bien souvent, il est assimilé au « FinOps du développement durable ».

Approfondissons ensemble la relation FinOps / GreenOps, les différences et les points de concordance entre ces démarches. Pour aller plus loin, on vous dévoile les bonnes pratiques pour mettre en place cette démarche.

Définir le GreenOps

Le GreenOps peut être défini simplement comme une approche opérationnelle qui comprend l’ensemble des efforts de réduction de l’empreinte carbone des ressources utilisées dans le cloud. Quand le modèle du FinOps vise la performance financière et doit permettre aux équipes de comprendre l’impact financier de leurs décisions, le GreenOps vise la performance environnementale et doit aussi permettre d’en avoir la compréhension. Ces deux notions possèdent également une méthodologie qui leur est propre.

La différence et la séparation entre ces deux notions peuvent donc paraître claires. L’une positionnée sur le terrain financier, et l’autre sur celui du développement durable, ou RSE, au sein des entreprises. La définition des objectifs et l’adoption d’indicateurs de performance peuvent toutefois très rapidement rebattre les cartes et laisser entrevoir qu’à définitions différentes, principes identiques.

2cta Livre Blanc Greenops

Sobriété et efficacité : les clefs de l’optimisation GreenOps

La notion même de cloud fait reposer tout processus d’optimisation sur une utilisation moins importante de l’infrastructure. Elle doit être ajustée au plus près des besoins réels et potentiels, tout autant en situation « normale » que de crise. Une réduction de l’utilisation de l’infrastructure réduit naturellement son coût, ce dernier étant grossièrement le corollaire de l’utilisation.

Par définition, une baisse d’utilisation signifie une baisse d’énergie nécessaire, et toute baisse du besoin en énergie tend à diminuer les émissions de gaz à effet de serre qui en découlent. Ainsi, moins d’utilisation de l’infrastructure équivaut à moins de coûts et moins de gaz à effet de serre. Jusque là, le FinOps rejoint le GreenOps, et la différence se limiterait à l’objectif sous-jacent de la démarche.

Oui mais…

Le Green IT n’est pas (que) GreenOps

Comme indiqué plus haut, le GreenOps est une pratique émergente au sein de la communauté cloud. La migration vers le cloud d’applications hébergées et gérées en intra est déjà définie comme une démarche à double effet bénéfique, tant économique qu’en terme de pression carbone.

Selon les études et résultats étudiés tant par les entreprises du Cloud comme AWS ou Microsoft que par des experts de la transition vers le cloud tels que Synapsys, l’impact d’une migration sous-tendrait une réduction de 30% à 40% des émissions de gaz à effet de serre, à périmètre identique. Le potentiel serait même jusqu’à 98% de réduction des émissions, avec les meilleures pratiques associées à ce processus.

Ainsi donc, cela signifierait 30%, 40%, voire 98% de réduction des émissions de l’IT ? L’impact d’une telle démarche est indéniable, mais le raccourci est ici trop séduisant.

Définir et comprendre le périmètre et les impacts GreenOps

Tout projet GreenOps gagne à être resitué :

  • à l’échelle des émissions des infrastructures des applications,
  • elles-mêmes intégrées aux émissions totales IT (hébergement, réseaux, utilisation et fabrication des terminaux)
  • ces dernières devant être relativisées à l’échelle des émissions totales d’une organisation.

L’hébergement représente environ 20% des émissions. Ainsi, si les seules données recueillies sont issues des cloud providers, ne pourra jamais être estimée une réduction des émissions totales que de 7% environ dans le scenario le plus communément admis. Il pourrait certes monter à une réduction de 19,5% du total dans les projections les plus optimistes des professionnels du cloud. Là se pose la question du coût des optimisations nécessaires à l’atteinte de la performance maximale, tout autant que celle des indicateurs pris en compte.

Si maintenant l’organisation se base sur une étude du bilan de gaz à effet de serre de ses activités, et qu’elle a réalisé des analyses de cycle de vie de ses différents projets, l’approche du GreenOps pourra « grignoter » des effets et des réductions d’émissions sur d’autres postes.

Par exemple, si est estimé le poids carbone de la production des terminaux, peut être projetée une estimation de l’impact de l’allongement de leur durée de vie. Ici, on parle de s’attacher à réduire la source d’environ 40% des émissions. De même, une approche de l’impact des fonctionnalités et de leur utilisation réseau permet d’estimer un poids carbone du développement (en plus de celui de l’optimisation du code, d’ailleurs). Si l’on ajoute une approche transverse d’utilisation des infrastructures, soit en réduisant l’allocation de ressources lors des moments de faible utilisation, ou en réattribuant des infrastructures en fonction des pics d’usage, il est encore possible de réduire la pression carbone, ou plutôt de la re-répartir entre les usages et d’en empêcher la croissance inutile.

Différentes notions peuvent nous permettre de dépasser le périmètre opérationnel limité aux émissions de fonctionnement du cloud :

  • sobriété (limiter les fonctionnalités et usages en fonction de leur utilité et de leur impact) ;
  • efficacité (usage adapté des ressources) ;
  • co-construction (intégration élargie des parties prenantes de l’environnement)

Méthodologie d’un GreenOps 360 ou GreenOps intégré

Pour s’inscrire dans une stratégie climat ou bas-carbone d’entreprise sans la subir, et piloter ses impacts et objectifs, une stratégie GreenOps ne peut être décorrélée d’une stratégie Green IT globale, elle-même inscrite dans la stratégie d’entreprise.

Ce que met en place une stratégie Green IT :

  • une cartographie des flux physiques dont dépend l’IT ;
  • une définition des postes d’émission liés ;
  • la construction d’un protocole de réalisation du bilan, incluant les méthodes d’estimation et de calcul des émissions ;
  • une indexation des facteurs d’émission ;
  • un bilan des émissions de gaz à effet de serre ;
  • un cycle de ré-évaluation des émissions (a minima tous les 4 ans) ;
  • des objectifs de réduction des émissions ;
  • un plan opérationnel de réduction des émissions réalistes.

C’est dans cette dernière étape que s’insert un plan d’action ou une action GreenOps.

Ce que peut évaluer le projet GreenOps :

Situé dans une cartographie des flux, le projet GreenOps peut alors évaluer différentes opportunités.

  • des opportunités de diminution des émissions directes (émission de fonctionnement de l’infrastructure, dépendante de la quantité d’énergie nécessaire à son fonctionnement, elle-même dépendante des vecteurs énergétiques employés) ;
  • des opportunités d’externalités positives sur la pression carbone de l’IT (augmentation possible de la durée de vie des terminaux, baisse du besoin réseau, limitation de la croissance du volume de données nécessaires au fonctionnement à moyen/long-terme des applications du cloud, et donc des besoins de sur-dimensionnement de l’infrastructure).

FinOps et GreenOps : objectifs partagés mais qui divergent

En effet, le FinOps se concentre sur les coûts directs de fonctionnement et optimise des réductions alors que le GreenOps intègre les externalités, les impacts indirects des orientations stratégiques des projets et des décisions.

Indicateurs et objectifs GreenOps

Les indicateurs

L’approche des émissions de fonctionnement s’appuie sur quelques indicateurs :

  • consommation d’énergie des infrastructures (kWh et ses multiples) ;
  • facteur d’émission de l’énergie (émissions de CO2e / kWh consommés, dépendants du vecteur énergétique, ou source de production d’électricité) ;
  • émissions de gaz à effet de serre, à relativiser selon l’unité d’œuvre la plus adaptée :
    • le temps (TCO2e/an) ;
    • le volume de données échangées (TCO2e/To) ;
    • le nombre de transactions réalisées ;

La consommation d’énergie est aussi traduite en valeur monétaire, ce qui rejoint – encore – le FinOps. Diminuer la consommation d’énergie entraîne un gain financier. Mais comment inciter au choix d’un vecteur énergétique moins émetteur (passer d’une électricité produite au charbon, au gaz ou au pétrole à une énergie de source renouvelable, par exemple) ?

Un outil peut alors être utile : le prix interne de la TCO2e.

Puisque nous savons que les émissions de CO2e entraînent un dérèglement climatique et que celui-ci a ou aura un impact négatif conséquent sur les activités, on peut alors considérer que chaque TCO2e émise dans l’atmosphère a un coût pour l’entreprise. Ce coût est invisible, tant qu’aucun prix du CO2e n’est fixé.

On peut donc ajouter un coût des émissions de CO2e d’usage. Là encore, le GreenOps a rejoint le FinOps. Ou plutôt : le GreenOps nourri le FinOps avec un outil de pilotage supplémentaire qui traduit des externalités.

Prenons maintenant un peu de hauteur…

L’infrastructure a un impact à la production. Celui-ci n’est pas inclus dans les émissions d’utilisation. Il peut être trouvé dans les ACV (analyses de cycles de vie) des fabricants, dans celles des cloud providers, dans des bases de données publiques comme la base empreinte de l’ADEME, ou estimée grossièrement. Cela fait normalement parti de l’étape de construction du protocole de réalisation du bilan des émissions de gaz à effet de serre, puisque demande des arbitrages :

  • les émissions sont elles si importantes qu’il est acceptable d’y accorder un effort en ressources humaines et financières pour les définir très précisément ?
  • quelles méthodes utiliser pour « diviser » les émissions de fabrication des infrastructures, la répartir entre les utilisateurs/utilisations et dans le temps ?

De même, l’infrastructure a un impact de fin de vie. Le cloud providers ou les fabricants communiquent-ils sur ce sujet ? Quelle fin de vie est prévue ? Et donc quel en sera l’impact ?

Les objectifs

Un projet peut inclure des objectifs d’augmentation de la durée de vie des terminaux utilisateurs, ce qui entraîne une diminution des émissions de ce poste, qui se révèle être le plus important de l’empreinte carbone globale de l’IT. Ces réductions, si elles sont estimées dès l’origine, peuvent être incluses dans les indicateurs projets. Cela nécessite, à l’image du poids carbone de l’énergie via le prix interne du CO2e, l’inscription dans les abaques de facteur de conversion d’une métrique connue et évaluable en un équivalent carbone, ou d’une méthode d’estimation de l’impact carbone de long terme d’un projet.

Un projet peut donc comprendre :

  • une empreinte CO2e d’utilisation ;
  • une empreinte projetée sur 10 ans (avec scenarios de croissance) ;
  • les émissions évitées sur 10 ans (comme par l’augmentation rendue possible de la durée de vie des terminaux utilisateurs) ;
  • les émissions effacées (par rapport au maintien de la situation préalable, dans le cadre de projets de transformation).

On ne doit pas soustraire les émissions évitées aux émissions réelles, mais on obtient tout de même une somme d’indicateurs qui peuvent valoriser tout projet, et qui dépassent l’unique considération financière.

Et si l’on veut retomber sur ces pieds financiers pour faciliter un arbitrage, alors le prix interne du CO2 permet de convertir ces tonnes de CO2e produites, évitées et effacées en k€ de coûts réels, évités et effacés.

Conclusion

GreenOps et FinOps ne diffèrent donc pas uniquement et simplement par la finalité visée. Le GreenOps peut fournir au FinOps des indicateurs supplémentaires de pilotage, en valorisant des externalités invisibles jusque-là. La réciproque est bien moins vraie. Le GreenOps peut donc se révéler un outil très utile pour démontrer la performance de l’IT, et représenter concrètement tant les impacts que l’engagement du service. C’est aussi un autre moyen d’échanger avec les différentes fonctions, tant RSE que de direction générale.

Si le FinOps manipule des k€, ce qui est une unité somme toute très courante, le GreenOps demande de comprendre, utiliser et convertir de nombreuses notions qui peuvent être plus obscures : énergie, émissions de gaz à effet de serre, amortissement financier et des émissions, répartition des usages, etc.

Une démarche de GreenOps a donc comme préambule indispensable la formation et la sensibilisation. C’est à la fois un facteur clef de décision, pour s’assurer de l’engagement d’une direction et de la validation de tels projets, mais aussi un levier d’efficacité de ces démarches. Chaque collaborateur formé et impliqué dans un projet GreenOps apportera une expertise spécifique qui pourra optimiser tant la qualité de la représentation du réel à travers des indicateurs que la sélection d’objectifs et de plan d’actions à mettre en place.

Articles similaires

Green IT

Stratégie numérique responsable : comment structurer sa démarche ?

Déployer une stratégie numérique responsable s’impose comme une priorité croissante pour les entreprises. Mesurer, planifier et acculturer sont les clés...

Green IT

Green Datacenter : améliorer l’impact des infrastructures IT

Green Datacenter : d’où ça vient ? La première raison pour laquelle le sujet du développement durable et plus particulièrement...

Green IT

​​Green Coding : comment développer de façon écoresponsable ?

Qu’est-ce que le Green Coding ? Le Green Coding, ou codage vert, en bon français, est une pratique inventée assez...