Comment passer du DevOps au DevGreenOps ?
Comment passer du DevOps au DevGreenOps ?
Résumé
La transition du DevOps au DevGreenOps semble indispensable pour répondre au challenge majeur qu’est la réduction de l’impact environnemental du numérique. C’est la mise en place d’une nouvelle démarche outillée mais aussi un changement de culture.
Dans cet article, nous commencerons par définir ce qu’est le DevGreenOps et ce que sont ses fondamentaux dans chaque étape d’un cycle DevOps. Nous verrons ensuite comment l’implémenter dans un framework comme CALMS. Nous identifierons quelques bonnes pratiques pour réussir, et terminerons par les métriques et les outils utiles dans la démarche.
1. Contexte Green et DevOps
1.1. Le contexte Devops
La numérisation croissante des services – la fameuse « transition numérique » – a confronté les équipes informatiques au besoin de livrer plus de produits logiciels, avec plus de fonctionnalités, plus fréquemment… tout en maintenant voire en augmentant la qualité et la sécurité.
Dans ce contexte les pratiques classiques de développement, c’est-à-dire le développement en « cycle en V » ou « waterfall » et la séparation nette entre le développement du logiciel (par la « Direction des Études ») et son hébergement (par la « Direction des Opérations ») ne permettaient pas de répondre à ce challenge.
L’adoption des méthodes agiles, et l’évolution vers une intégration et un déploiement en continu ont permis de répondre à ce besoin. Ainsi, le « DevOps » (mot-valise constitué à partir de « Développement » et « Opérations ») peut être défini comme un ensemble de pratiques de production de logiciels en mêlant développement, assurance qualité, déploiement et monitoring. Cette culture permet aux équipes de délivrer régulièrement – jusqu’à plusieurs fois par heure ! – en maintenant un niveau de qualité et de sécurité élevé.
Grâce à l’accélération des livraisons, le DevOps permet aux structures de mieux s’adapter aux demandes des clients et d’innover plus rapidement.
Selon une étude Atlassian mentionnée par Cisco dans son article The Rise and Rise of DevOps Adoption, 83% des organisations ont adopté des pratiques DevOps, mais 18% seulement ont une démarche totalement intégrée. La tendance générale est au déploiement de ces pratiques.
1.2. Le contexte de l’impact du numérique
La prise de conscience de l’impact environnemental du numérique a amené un besoin d’intégration de bonnes pratiques et d’outillage spécifique dans les usines logicielles. Aux contraintes existantes de maintien de la qualité et de la sécurité, se sont ajoutées celles de calcul, de maintien voire de réduction de l’impact des logiciels. Cette dernière contrainte est parfois antinomique avec l’accélération des releases, les équipes fournissant toujours plus de fonctionnalités mais aussi utilisant un nombre croissant de nouveaux frameworks et de librairies. Le besoin de continuellement mesurer, contrôler et réduire l’impact des solutions numérique, compte-tenu de ce contexte, est aujourd’hui naissant dans les équipes.
Le DevOps amène un risque d’augmentation de l’impact du numérique mais aussi une opportunité de l’améliorer : la mise en place d’une culture DevGreenOps doit permettre de répondre à ce challenge.
Le DevGreenOps est une culture permettant d’intégrer l’aspect environnemental dans le développement des services numérique via des pratiques de mesure et d’amélioration continue de l’impact de l’application.
« DevGreenOps » ou « Green DevOps » ?
Les deux termes se comprennent bien, et s’agissant d’un concept nouveau, il n’existe pas encore de vocable dominant. Nous avons fait le choix d’utiliser le terme DevGreenOps pour deux raisons :
- Il est bâti sur le modèle de « DevSecOps » qui décrit l’intégration des pratiques de sécurité au cœur des process DevOps. Or c’est bien l’intégration de pratiques « green » au cœur du DevOps dont nous parlons ici.
- Il existe déjà une appellation « Blue/Green DevOps » pour désigner une méthode particulière de gestion des déploiements. En parlant de Green DevOps, on risque la confusion avec ce Blue/Green DevOps.
2. Les fondements du DevGreenOps
Le DevGreenOps est une évolution naturelle de la méthodologie DevOps. Les 8 phases de la boucle d’amélioration qui sont utilisées dans le DevOps peuvent être impactées par le DevGreenOps.
Tout au long du cycle, l’objectif va être d’adopter une approche de sobriété (des besoins, des consommations de ressources…) et de contrôle de la « qualité environnementale » du produit logiciel.
Plan
Cette phase de découverte et de planification est cruciale dans l’intégration de la sobriété. Elle doit permettre d’intégrer les contraintes environnementales dans la conception des fonctionnalités, des interfaces et aussi le choix des technologies et librairies.
Lors des ateliers de design et d’idéation, la réflexion sur l’utilité mais aussi sur l’impact de la solution et des fonctionnalités doit être intégrée. Pour aller plus loin, voir le guide des Designers Éthiques.
Lors de la mise en place de l’architecture et du choix des outils, le critère environnemental sera intégré aux côtés des critères de sécurité, de maintenabilité… en intégrant le cycle de vie global du logiciel. Des référentiels comme le RGESN ou celui de l’INR seront utiles dans cette phase.
En particulier, le choix des services tiers et autres librairies externes pourra être challengé. En effet les services tiers sont facilement intégrables mais ont un impact non négligeable dans les logiciels.
La phase de planification est aussi une phase d’amélioration : du process DevGreenOps mais aussi par l’analyse des métriques qui auront été mesurées lors des phases précédentes.
Code
Bien que le code ne soit pas l’unique responsable de l’impact du service, cette phase est importante pour intégrer les bonnes pratiques d’écoconception. L’usage d’un outil d’analyse de code dans l’IDE du développeur permettra d’implémenter au plus tôt ce type de bonnes pratiques.
Le processus de commit sur une PIC permettra de lancer des analyses de code structurée sur des bonnes pratiques Green IT.
Des premières mesures d’impact pourront être faites dans cette phase, à condition que la solution soit déployée en parallèle.
Build
La phase de build permettra en particulier d’intégrer une relecture du code avec une vision « sobriété ». Le build suivi du déploiement sur une instance de staging sera encore l’occasion de lancer des premières mesures d’impact.
Test
Cette phase est critique pour le DevGreenOps. Les exigences de sobriété ou d’impact sont de nouvelles exigences non fonctionnelles, dont il convient de vérifier le respect. Il s’agit d’un nouveau domaine de test qui a toute sa place, comme les tests de performance par exemple.
La stratégie de test mise en place dépendra des conditions du projet. Par exemple, on réalisera des mesures de consommations en conditions stables et régulières, pour suivre les évolutions des indicateurs d’un build à un autre ou d’une release à une autre. En complément, des tests aux extrêmes, en particulier sur des terminaux bas de gamme et des connexions limitées, permettront de vérifier le respect d’exigences spécifiques, et peuvent aider à détecter des anomalies de consommations de ressources.
Release
Le passage des “quality gates” avec des contrôles sur les bonnes pratiques de codage green et les tests de sobriété sont passés. Il est encore temps de refuser une mise en production si un des KPI que l’on avait mis en phase dans le Plan n’est pas respecté.
Deploy
Le déploiement automatique pourra déclencher des tests de consommation de ressources en production. De nombreuses différences peuvent apparaître entre les tests réalisés en phase de test et en production : certains services tiers sont activés, les configurations ne sont potentiellement pas les mêmes… Un contrôle directement suite à la mise en prod permettra de détecter une anomalie de consommation.
Operate
Pendant cette phase, on surveillera les consommations de ressources serveurs. Une bonne connaissance de la dynamique de consommation en fonction de la charge permettra d’éviter de surdimensionner l’architecture et de scaler trop tôt.
Monitor
Cette phase apporte une observabilité du système qui va permettre de détecter des anomalies et d’améliorer la qualité. Le monitoring permettra d’une part d’identifier des fonctionnalités non utilisées (pour une amélioration de la sobriété fonctionnelle), mais aussi des lenteurs ou des surconsommations. De plus une mesure en continu de l’impact de la solution apportera des KPI pour la boucle d’amélioration continue.
On l’a vu, le « Green » infuse dans toutes les étapes d’un process DevOps. Mais comment le mettre en place ? Appuyons-nous par exemple sur le framework CALMS.
3. Framework pour implémenter le devGreenOps : CALMS in Green
Le framework CALMS a été initié par Jez Humble dans le livre The DevOps Handbook. Il permet à une organisation de mesurer sa progression vers le DEVOPS. CALMS est l’acronyme de Culture, Automatisation, Lean, Measure, Share. L’application de CALMS au DevGreenOps permettra, de la même manière, d’évaluer sa progression.
C – Culture
Comme le DevOps, le DevGreenOps implique une nouvelle culture de collaboration entre équipes. La réduction de l’impact environnemental implique de modifier le mode de travail. La culture Agile a permis de préparer ce changement, cependant des changements plus profonds sont nécessaires.
D’une part les objectifs de réduction doivent être partagés entre tous : Product Owner, Designer, Développeur, Ops… On parlera ainsi de nouveaux OKR (Objective & Key Result). Tout choix ou action dans une équipe aura un impact positif ou négatif sur le produit global et donc sur les OKR.
Dans ce cadre, la phase Plan sera utile pour discuter de ces objectifs. Ainsi, un choix de design par les UX pourra être challengé par les développeurs par rapport à une complexité qui amènerait un impact environnemental supplémentaire.
Une collaboration entre Dev et Ops sera nécessaire pour dimensionner au mieux l’infrastructure et donc ne pas gaspiller. De la même manière, la remontée d’information de consommation de ressources et d’énergie par les serveurs et data centers sera utile pour l’équipe de Dev pour améliorer l’observabilité, soit directement, soit via l’usage d’outil de mesure.
Il sera nécessaire aussi d’intégrer de nouveaux types d’acteurs comme l’équipe RSE (Responsabilité Sociale et Environnementale) lors de la définition des objectifs. Plus globalement il faut passer d’une culture techno-solutionniste (répondre à toute demande métier par l’ajout de fonctionnalités) à une culture de sobriété réelle (répondre par des fonctionnalités sélectionnées, dimensionnées et développées au plus juste par rapport au besoin exprimé, en tenant compte de l’impact environnemental).
A – Automation
De la même manière que le DevOps va permettre de passer du “it works on my machine!” à un déploiement automatique sur un environnement distant, le DevGreenOps va permettre, via le déploiement continu, de mesurer des métriques d’impact sur un environnement maitrisé et représentatif. Le profilling de ressources via les IDE ou l’évaluation des performances sur le poste du développeur (Voir “shift right quality” ci-après) est coûteux et non représentatif de l’environnement utilisateur. C’est pour cela que l’automatisation du déploiement et de la mesure de ressources sera nécessaire.
De la même manière, l’automatisation des tests permettra d’obtenir des métriques sur les environnements déployés. Cette automatisation permet de mesurer plusieurs fois le même parcours et donc d’avoir des données plus précises. De plus, avec les méthodologies de déploiement DevOps (A/B, Canary…), les mêmes tests peuvent être lancés à plusieurs reprises dans des conditions différentes, ce qui permet d’étudier les impacts d’un sujet particulier (fonctionnalité, librairie, composant…).
L – Lean
La démarche lean va permettre d’apprendre progressivement quels sont les impacts du service et d’optimiser progressivement. Des référentiels de bonnes pratiques existent et sont utiles. Toutefois compte tenu de la diversité des contextes techniques, et du manque de connaissance sur le gain potentiel apporté par chaque bonne pratique, l’apprentissage par l’expérience et la mise en place d’une boucle de rétroaction sont importants.
L’échec doit être accepté : le fait de désactiver une fonctionnalité qui au finale ne sera pas utile ou bien trop gourmande par rapport aux objectifs généraux du projet, le retour arrière sur un choix technologique non durable… Autant d’actions permettant d’affiner.
La démarche Lean sera aussi très utile sur l’optimisation de la chaine DevOps au global pour éviter tout gaspillage.
M – Measure
La mesure de l’impact de la solution sera clé dans l’amélioration. Sans mesure, la boucle de rétroaction ne sera pas possible, ou en tout cas les actions se feront sans validation d’un réel gain.
La mesure permettra d’obtenir des KPI partageables entre les équipes et d’améliorer la culture de la collaboration. De plus, elle sera juge de paix : par exemple le choix de désactiver ou optimiser une fonctionnalité ou un service tiers sera appuyé par des mesures non discutables.
La mesure apportera aussi des métriques pour l’observabilité du système. Les métriques techniques comme les consommations de CPU et de RAM, existantes dans les pratiques d’observabilité DevOps seront augmentées de la consommation d’énergie. On ajoutera des indicateurs d’impacts environnementaux : au moins les émissions de gaz à effet de serre en CO2e, idéalement un ensemble de métriques variées permettant d’éviter des reports d’impacts.
Enfin, les mesures du comportement du service numérique dans des conditions extrêmes (pas de connexion, terminaux anciens ou bas de gamme…) apporteront des éléments importants pour l’amélioration de la sobriété du service et la validation de son inclusivité sociale.
S – Sharing
Il est nécessaire de changer la façon de développer et en particulier de collaborer. Le partage entre équipes sera nécessaire pour aller vers un OKR commun de réduction de l’impact. Une sensibilisation de tous les acteurs du projet aux notions de Numérique Responsable en général, et d’écoconception des logiciels en particulier, pourra être utile pour partager une culture commune.
Le partage sera nécessaire aussi plus globalement avec les fournisseurs et partenaires. Les relations contractuelles classiques rendent l’optimisation complexe (nécessité de contrat, TMA…). Un changement de culture mais surtout plus de partage en amont des contractualisations sera nécessaire.
Le partage des bonnes pratiques et des expériences sera aussi bénéfique hors de l’organisation. Compte-tenu de la complexité des systèmes et du challenge de réduction, il est nécessaire de collaborer et de faire monter globalement tous les acteurs du numérique.
4. Les bonnes pratiques du DevGreenOps
4.1. Rappel des bonnes pratiques DevOps
Les pratiques Agiles ont amené à ce que les spécifications soient moins formalisées. En parallèle, les déploiements dans le cloud ont apporté une complexification par rapport à un système plus « monolithique ». Ces changements ont rendu nécessaire une modification de la vérification du système. En particulier, il a été nécessaire d’anticiper les tests en amont (shift left) et de repousser des tests en aval (shift right). Le shift left permet aux équipes de développement de lancer des tests pour détecter des problèmes au plus tôt. Le shift right permet de lancer des tests en production pour analyser des anomalies sur le système (plus d’infos).
4.2. Shift right de la qualité
Le contrôle des bonnes pratiques de développement via des analyses de code permettra d’éviter certaines pratiques qui seraient consommatrices de ressources. L’usage de quality gate permettra d’aller jusqu’à bloquer les étapes suivantes (test, déploiement…) si les critères souhaités ne sont pas respectés.
Toutefois, il est important de se focaliser sur des bonnes pratiques ayant un impact notable et prouvé sur la sobriété du produit final. Il serait peu efficace de corriger des violations de bonnes pratiques de code qui n’ont pas d’impact réel. Contrairement aux catégories de qualité de code classiques (maintenabilité, lisibilité…), les bonnes pratiques de sobriété ont l’avantage d’avoir un effet mesurable… pour peu que l’on mesure.
4.3. Shift left et Shift right de la mesure
La mesure d’impact doit être faite au plus tôt pour identifier les « points chauds » (hotspots) de consommation d’énergie ou d’autres ressources matérielles.
Le déploiement du logiciel dès les phases de code et de build sur des environnements dockerisés permettra de lancer des tests automatisés et de mesurer la consommation des API, du backend et même des interfaces. De même on pourra contrôler l’impact des applications mobiles via la compilation des APK et IPA. En testant très en amont (shift left) on pourra identifier plus facilement les causes d’éventuelles surconsommations, car le constat sera fait au plus proche du codage. On pourra donc corriger au plus tôt et maintenir le projet en ligne avec ses objectifs d’impact.
A noter que des tests shift left de type unitaire ne seront pas forcément utiles d’un point de vue DevOps, car ils s’approchent des pratiques de microbenchmarking, avec les biais d’interprétation associés (représentativité du test, nécessité de lancer de nombreuses itérations…).
En aval, on pourra aussi lancer les tests shift right pour détecter des hotspots. L’avantage des tests dans les phases aval, même en production, est de détecter des violations qui ne peuvent pas se produire en environnement de développement : par exemple parce qu’elles sont causées par des services tierce-partie qui ne sont pas présents sur les environnements amont.
4.4. Feature flipping et A/B testing pour l’évaluation des impacts
Les bonnes pratiques de déploiement du DevOps peuvent bien sûr être utilisées en DevGreenOps, notamment dans le cadre de l’apprentissage et des boucles d’amélioration. Déployer des implémentations de bonnes pratiques et utiliser du A/B testing en le couplant à des mesures d’impact, permettra d’identifier les réels gains ou tout simplement le gain ou le coût environnemental associé à une bonne pratique ou un élément. Par exemple, on peut via le feature flipping activer une fonctionnalité, mesurer lors d’un parcours utilisateur, puis désactiver la fonctionnalité et relancer la mesure. La différence entre les deux mesures permettra de connaître l’impact de la fonctionnalité testée.
4.5. Nouvelles métriques et projection environnementale
Dans une approche DevGreenOps, les métriques de CPU, de RAM, de données échangées doivent prendre une place encore plus importante qu’habituellement. Elles sont de bons indicateurs sur des goulots d’étranglement ou des aspects consommateurs du code. Cependant il faut aller plus loin : il est nécessaire de mettre en place des nouvelles métriques moins communes comme la consommation d’énergie. L’énergie sera une métrique très utile pour déterminer l’impact du logiciel pendant sa phase d’usage sur le serveur et sur le terminal. Elle peut également être utilisée pour calculer l’impact sur la phase de fabrication des matériels.
On prêtera une attention particulière au modèle de projection environnementale mis en place pour calculer les impacts du service numérique en CO2e et autres métriques environnementales. Ce modèle d’impact est chargé de convertir les métriques techniques mesurées (énergie, CPU, volume de données transférées…) en impacts environnementaux. Des calculs basés sur des métriques secondaires (nombre de requêtes, taille du DOM, poids de la page…) ou via un modèle d’impact trop simple risquent, en donnant une vision très peu précise des impacts, d’amener à des travaux d’optimisation peu efficaces et à donner une illusion de progrès en passant à côté des points essentiels.
Note sur les métriques :
Dans les métriques surveillées on pourra retenir :
- Energie, pour le terminal utilisateur et le serveur ;
- Gaz à effet de serre en CO2e, par tiers (terminal / réseau / datacenter) et/ou avec répartition par phase de cycle de vie (a minima : fabrication, usage) ;
- Des impacts sur des critères autre que les gaz à effet de serre : voir les RCP (Règles par Catégorie de Produit) édictées par l’Ademe pour le numérique ;
- Tout score d’écoconception intégrant une prise en compte de métrique primaire (énergie, CPU…)
5. L’outillage DevGreenOps
Des outils spécifiques Green seront ajoutés aux outils DevOps existant. Ils devront respecter les bonnes pratiques précédemment énoncées. Ils s’intégreront aux outils de séquencement en place (Jenkins, Gitlab…) et/ou potentiellement aux outils de reporting (Zabbix…).
Nous en citons quelques-uns ici, sans que cette liste soit exhaustive.
| Référentiel NR | Greenspector Studio | Scaphandre | Power API | Carbonifer | Easyvirt | Ecocode | ||
|---|---|---|---|---|---|---|---|---|
| Plan | Guideline pour prise de décision et direction | X | ||||||
| Benchmark de langage et d’architecture | X | |||||||
| Analyse des métriques des boucles précédentes pour amélioration. | X | X | X | X | X | X | ||
| Code | Analyse de bonnes pratiques | X | ||||||
| Mesure si déploiement sur un environnement de stagging | X | X | X | |||||
| Build & test | Mesure sur un environnement de stagging | X | X | X | X | |||
| Release | Usage des métriques pour décision si Go/NOGO | X | X | X | X | X | ||
| Deploy | Mesure en production pour validation suite à mise en production | X | Si solution hébergée | X | ||||
| Operate & Monitor | Mesure en continue pour surveillance | X | X | X |
Note sur les outils de mesure :
Greenspector
Scaphandre de Hubblo
Carbonifer
PowerAPI
EasyVirt
Mesure des sites web et application mobile sur device réel
Mesure des backends sur environnement containerisé ou virtualisé (Mesure du frontend possible sur environnement virtualisé)
Mesure des solutions pour la partie Cloud
Mesure d’environnement virtualisé ou physique (PC, Serveur)
Monitoring des machines virtuelles
6. Les métriques DevGreenOps
Les métriques permettant de piloter la démarche DevGreenOps ne sont pas les métriques techniques ni même des métriques environnementales. Il s’agit des métriques qui vont permettre de mesurer les progrès dans l’amélioration de l’impact du service numérique. Voici 3 propositions de métriques :
6.1. Taux d’équipes (squads/feature teams/projet…) ayant un mis en place un OKR Green
L’intégration du DevGreenOps dans les équipes va se faire progressivement. Il est nécessaire d’avoir le bon outil pour mesurer régulièrement… Chaque équipe, en fonction de son domaine et de sa charge, pourra intégrer des métriques ou des KPI Green, dans une approche OKR (Objective & Key Results). La cible sera bien sûr une couverture de 100% à terme.
6.2. Taux d’amélioration des indicateurs clés
Les budgets environnementaux et KPI qui auront été fixés seront à suivre dans le temps. Une amélioration de ces indicateurs sera à étudier lors des phases Plan : quels objectifs se donner pour la prochaine itération ? On peut suivre la progression de la démarche DevGreenOps en évaluant le taux d’équipes dont les indicateurs clefs (par exemple : l’impact CO2 pour un parcours utilisateur typique) s’améliore.
Attention, l’augmentation du nombre de fonctionnalités ou l’enrichissement de celles-ci ne devra pas être une raison pour justifier une augmentation de ces KPI. Il sera nécessaire de trouver des actions pour maintenir cette métrique, voire la baisser. Nous recommandons également de suivre les impacts unitaires (par page, par transaction, par parcours utilisateur…) mais aussi de suivre l’impact global (impact unitaire x nombre d’utilisations) afin de bien garder l’impact du service numérique sous contrôle et d’éviter des effets rebond.
6.3. Taux de correction du nombre d’anomalies « Green » détectées
L’analyse de code et la mesure vont détecter des violations de bonnes pratiques ou amener à créer des Green bugs. La prise en compte de ces anomalies sera nécessaire pour que la démarche DevGreenOps soit réellement intégrée dans le processus. Le taux de correction de ces anomalies est donc un indicateur intéressant à suivre, et à comparer au taux de corrections d’autres catégories. On peut par exemple calquer le fonctionnement du suivi de cette métrique sur les métriques de sécurité.
7. Les challenges du DevGreenOps
Terminons en évoquant quelques challenges spécifiques que vous risquez de rencontrer lors de la mise en place d’une démarche DevGreenOps.
7.1. Le Green dans la chaîne DevOps elle-même
Réduire l’impact de la solution numérique développée sera l’objectif principal du DevGreenOps. Il sera cependant nécessaire de surveiller l’impact de la chaîne d’outils elle-même. L’accélération des releases ainsi que l’augmentation du nombre d’outils amènera naturellement à un impact plus élevé. Une évaluation ponctuelle de l’impact de l’usine logicielle sera possible pour identifier le rapport entre l’impact du service numérique produit et celui de l’usine – d’autres outils, dédiés à l’évaluation de l’impact du SI, pourront être utiles pour cela. Cette observation pourra permettre d’identifier des actions d’amélioration. Une rationalisation des outils et une réflexion sur le rythme de release sera aussi à prévoir.
7.2. Une professionnalisation et une structuration des outils de mesure
Des outils de mesure et de projection environnementale voient le jour. Leurs promesses sont parfois similaires, mais leurs méthodologies de mesure et de projection d’impact sont souvent très inégales. Il n’existe pas de normalisation sur ces sujets – bien que certains travaux soient en cours, nous y contribuons auprès de l’ISO ou du W3C – mais en attendant il est nécessaire d’être vigilant lors du choix de ses outils.
Les métriques mesurées, les méthodes de mesures, le modèle d’impact appliqué, et bien sûr la compatibilité avec une intégration dans la chaîne DevOps sont à prendre en compte. C’est une exigence demandé par les nouvelles versions du RGESN.
7.3. Une culture de la sobriété à intégrer
Au-delà de l’outillage et la mise en place de métriques de mesures, il est nécessaire d’intégrer réellement la culture de la sobriété. Les solutions pour réduire l’impact ne sont pas uniquement technologiques. Il est parfois nécessaire de conduire des changements radicaux, pouvant aller jusqu’à des changements dans le business model par exemple. De plus, il sera essentiel d’intégrer dans les équipes des nouvelles notions (impacts, énergie, sobriété…) qui n’ont pas été apprises dans les cursus universitaires des équipes actuelles. Au-delà des impacts environnementaux, une réflexion plus générale sur le numérique responsable s’impose.
Sans réel changement de culture au sein de la DSI, il y a un risque élevé que les efforts de mise en place du DevGreenOps ne mènent pas à des améliorations. En cas de décalage entre la communication et les résultats obtenus, il y a même un risque de greenwashing.
Conclusion
La transition du DevOps au DevGreenOps semble indispensable pour répondre au challenge majeur qu’est la réduction de l’impact environnemental du numérique. C’est la mise en place d’une nouvelle démarche outillée mais aussi un changement de culture.
Les projets applicatifs intègrent des exigences nouvelles, exprimées en impacts environnementaux ou autres indicateurs de sobriété, d’où découle le besoin de mesurer de nouveaux indicateurs techniques. Tout au long des cycles projets, il faut donc ajouter la mesure et le contrôle du respect de ces indicateurs. Les métriques collectées permettront initier une boucle d’amélioration de l’impact. Ceci se fera via une collaboration rapprochée entre acteurs actuels du DevOps mais aussi avec de nouveaux acteurs comme les équipes RSE.
Alors, prêt pour le changement de culture ?
