Green IT : Decathlon fait de l’optimisation logicielle un sport collectif

« Ne sommes-nous pas dans le camp du mal ? »

Pour autant, impossible pour le CTO et ses équipes (2000 développeurs) de ne pas voir les impacts du numérique sur les humains et la planète. Et de citer des exemples évocateurs. « L’Irlande, qui a fait une grande campagne pour attirer l’installation de data centers, est arrivée à un point où le prochain centre pourrait créer des black-out sur le réseau électrique », affirme Romain Taillade.

En 2021, les autorités locales ont mis en place un moratoire qui a pris fin en décembre 2025. Désormais, les concepteurs de data centers nécessitant 10 MVA ou plus doivent installer leurs moyens de production ou de stockage d’énergies renouvelables.

Le directeur technique cite également la volonté de Microsoft de faire redémarrer un réacteur de la centrale nucléaire de Three Mile Island, fermée en 2019. Elle est plus connue pour l’accident de niveau 5 sur 7 du 28 mars 1979. C’est le plus grave de l’histoire nucléaire civile américaine. Il a entraîné des répercussions techniques à l’international.

 Ce n’est pas tout. Outre le bilan carbone de Nvidia désormais largement dans le rouge, la consommation d’eau potable de TSMC grimpe en flèche, et se rapproche de celle de grosses agglomérations.

Pour l’un des responsables d’une architecture 100 % cloud, « le retour sur Terre est assez dur ». « J’en suis venu à me demander si moi et les gens avec lesquels je travaille tous les jours ne sommes pas dans le camp du mal », lâche-t-il.

« Est-ce que l’impact du numérique ne nuirait pas à “l’outdoor” (les sports en extérieur), le premier marché de Decahtlon ? »

La question est volontairement provocante. Elle est malgré tout réelle. Il y a autre manière de la poser. « Est-ce que l’impact du numérique ne nuirait pas à “l’outdoor” (les sports en extérieur), le premier marché de Decathlon ? », s’interroge Romain Taillade.

Réduire son empreinte carbone n’est pas impossible. De l’usage de matériaux recyclables jusqu’au reconditionnement des ordinateurs, les (petits) gestes à effet boule de neige ne manquent pas, considère le CTO. Et Decathlon y participe déjà.

« Avec l’équipe de développeurs, nous cherchions à mettre en place une solution beaucoup plus proche de nous », témoigne-t-il. « Notre armée de développeurs produit du code. Aujourd’hui, à notre échelle, notre effort de réduction de l’empreinte carbone, c’est l’optimisation de cette production ».

EROOM, un déclencheur pour Decathlon

Avant cela, le directeur technique de Decathlon a croisé la route de Tristan Nitot, directeur associé Communs numériques et Anthropocène chez Octo Technology.

En 2024, Tristan Nitot pose un constat : la loi de Moore est morte. Attribuable à Carver Mead, professeur à CaltTech, il s’agit de l’interprétation d’une prédiction renouvelée en 1975 par Gordon Moore, feu cofondateur et ex-PDG d’Intel. Elle établit que le nombre de transistors gravables sur un wafer double tous les deux ans. Elle est souvent interprétée comme la multiplication par deux des performances des processeurs lors de cet intervalle. C’est à la fois une prophétie autoréalisatrice et une loi de programmation industrielle, juge Tristan Nitot.

Peu importe si la loi de Moore se vérifie encore ou non. Son corollaire, la loi de Wirth, elle, est assurément d’actualité.

Posée en 1995 par Niklaus Wirth, chercheur et inventeur du langage Pascal, cette loi empirique veut qu’en dépit des gains de performances réguliers du matériel, les logiciels s’alourdissent tout aussi vite. « Tout ce qu’Intel vous donne, Microsoft vous le reprend », traduit Tristan Nitot.

« Voyez un peu la puissance CPU et la quantité de mémoire vive nécessaire pour faire tourner Windows et la suite Office au fil des années. S’il y a eu des ajouts, emojis, correcteurs orthographiques, etc., ces logiciels n’ont pas foncièrement changé. Et pourtant, cette consommation de ressources explose ».

Les ordinateurs, les serveurs, les smartphones ne deviennent pas plus lents (en tout cas pas aussi rapidement que le pensent les utilisateurs, LeMagIT y reviendra). « En revanche, les nouvelles versions de logiciels sont plus grosses et moins efficaces », souligne Tristan Nitot. L’on parle d’obésiciels, ou de bloatware en très mauvais français.

Plus que la consommation d’énergie de l’appareil ou de l’équipement, c’est sa fabrication qui pollue réellement. « 88 % de la consommation d’eau, c’est pendant la fabrication d’un équipement IT. C’est vrai aussi pour les émissions de gaz à effet de serre », martèle Tristan Nitot.

Or, les obésiciels, toujours plus dodus en fonctionnalités, poussent à la multiplication des équipements ou à leur renouvellement prématuré. Pour Tristan Nitot, il faut prendre le contrepied de ce schéma : inverser la loi de Moore.

« Après tout, la loi de Moore, c’est une loi de programmation industrielle pour produire des équipements plus capacitifs tous les deux ans. Faisons l’inverse : tous les deux ans, optimisons d’un facteur 2 l’existant logiciel. »

« Après tout, la loi de Moore, c’est une loi de programmation industrielle pour produire des équipements plus capacitifs tous les deux ans. Faisons l’inverse : tous les deux ans, optimisons d’un facteur 2 l’existant logiciel », affirme le directeur associé. « Sans refondre ou réécrire les architectures, identifions ce qui ne va pas et corrigeons-le ».

En faisant mieux avec moins, « libérons de la puissance de calcul pour de nouveaux usages », scande le dirigeant.

Moore à l’envers, cela fait EROOM, pour « Effort Radicalement Organisé d’Optimisation en Masse ». Avec des collaborateurs d’Octo Technology et des bénévoles de l’association Boavizta, Tristan Nitot a contribué à en faire une méthodologie open source (sous licence CC BY-SA 4.0).

Il s’agit avant tout d’un diagnostic visant à identifier « les principaux leviers d’optimisations ».

Si un diagnostic rapide existe, la méthodologie couvre l’ensemble des composantes : produit, architecture, infrastructure, algorithmes, code, stockage de données et les processus associés (tests, flux CI/CD, métriques de performances, documentations, etc.).

« Il s’agit d’optimiser des éléments critiques, sur des systèmes très utilisés. L’on ne veut pas opérer des refontes, mais mener des frappes chirurgicales sur 2 à 3 % du code », précise le directeur associé. « Et l’on fait attention de ne pas prendre ce chemin qui mène à un code certes plus performant, mais moins lisible et moins maintenable, par effort de sur-optimisation ».

Internaliser la méthode et en faire une routine

Pour Romain Taillade, c’était un point de départ. Il fallait faire de ce diagnostic un rendez-vous régulier, en prenant en compte les spécificités de Decathlon. « Entre un diagnostic effectué à t0 et un autre à t+1, plusieurs choses vont se produire : du nouveau code va être injecté dans les systèmes, de nouveaux clients vont se connecter, etc. Tout cela va avoir un impact sur les ressources consommées », décrit le CTO.

Par ailleurs, la notion de consommation de ressources n’était pas une métrique suffisante. « Le moyen ultime pour consommer moins de ressources, tout le monde le connaît : arrêter de travailler. Ce n’est pas très audible par nos décideurs », plaisante-t-il.

D’où l’élaboration d’une équation qui prend en compte une dimension tangible pour les directions métiers et la DSI. « L’enjeu n’est pas de faire moins, mais mieux avec ce que l’on a », nuance Romain Taillade. Cela a donné naissance à une métrique nommée ORI, pour Operational Ressource Intensity.

« C’est la somme des ressources utilisées pour faire fonctionner un logiciel divisé par les opérations métiers », explique Romain Taillade. « Par exemple, chez Decathlon, cela pourrait être le CPU, la RAM et le réseau consommé par un microservice du système de paiement par rapport au volume de commandes ».

La métrique ne vit pas seule. Elle s’intègre dans un framework intitulé « Tech Performance Framework ».

« Ce framework est une manière de répondre à la question : “quelle est la bonne manière de concevoir des logiciels modernes en 2026 ?” », résume le CTO. « C’est un audit permanent de tous nos systèmes sur différents piliers, comme le code ou l’architecture ».

L’optimisation du code est devenue le pilier Green IT, un indicateur de performance pour les développeurs intégré dans un framework plus général. « En tant que développeurs, quand vous êtes “élites” en optimisation du code, c’est aussi bien que d’être élite en production ou en sécurité du code », illustre Romain Taillade.

« Le secret, c’est que c’est automatique. Nous ne demandons pas d’effort supplémentaire aux développeurs pour obtenir ce score », souligne-t-il.

Et de prendre l’exemple d’un service sur lequel la méthodologie a été implantée. Le diagramme présenté par le CTO montre dans un premier temps une progression négative de la consommation de ressources, signe que les optimisations fonctionnent. Aux environs de Noël, la consommation a repris de plus belle. L’équipe s’en est inquiétée. Sur cette période, elle n’avait pas poussé de code ou de modifications. La surconsommation provenait en réalité d’appels API. « Un nouveau consommateur de nos API est apparu et il ne faisait pas de la meilleure des manières. Cet apporteur assez marginal d’activité économique est ainsi devenu un des tops consommateurs de ressources de notre système », relate le directeur technique.

Romain Taillade suppose que les développeurs n’avaient pas lu la documentation en entier, qu’elle n’était pas suffisamment claire ou qu’ils répondaient à une demande urgente des métiers. « Une manière beaucoup plus économique et efficace de faire ce qu’ils voulaient faire était décrite dans le deuxième chapitre de cette documentation ».

En quelques jours, la consommation de ressources est repassée à la normale. « C’est un problème que nous n’aurions pas vu sans la métrique ORI », note-t-il.

Outre l’identification de surconsommations, l’initiative permet une forme d’émulsion chez les développeurs, une « gamification » des pratiques GreenOps.

« Nous ne cherchons pas à sanctionner [les développeurs]. La méthodologie EROOM nous permet d’établir un plan de jeu et des stratégies. [...] »

Pas question, pour autant, de distribuer des cartons rouges. « Nous ne cherchons pas à sanctionner [les développeurs]. La méthodologie EROOM nous permet d’établir un plan de jeu et des stratégies : en cas de mauvais diagnostic, la réponse est l’apprentissage, la formation pour comprendre ce qui ne va pas et faire mieux. Avant même de se mettre à l’optimisation, il faut se mettre en jambe », affirme Romain Taillade. « À l’inverse, s’il est difficile d’optimiser un système déjà très efficient, il faut jouer la défense de territoire ».

« Effet néon » et autres découvertes

Une « business unit » entière – 150 personnes responsables d’une cinquantaine de microservices et services logiciels – a déjà déployé la méthodologie depuis la fin de l’année 2025. En quelques mois, le directeur technique fait état de plusieurs constats.

« Par exemple, nous avons découvert ce que nous appelons en interne l’effet néon », évoque le responsable. Le grand-père de Romain Taillade lui recommandait de ne pas éteindre systématiquement les lampes à néon quand il quittait une pièce pour revenir quelques minutes plus tard. Il affirmait que cela coûtait plus cher de l’éteindre et de le rallumer. Si c’est un mythe, il s’avère que cette affirmation est vraie dans le cas des applications de Decathlon.

Partant d’une bonne intention, un devOps a eu l’idée d’installer une librairie pour éteindre les pods Kubernetes quand ils n’étaient pas utilisés.

« Nos environnements applicatifs sont majoritairement bâtis autour de Spring Boot [Un framework Java open source, maintenu principalement par VMware, N.D.L.R.] », informe-t-il. « Le démarrage à froid de Spring Boot consomme beaucoup de ressources ».

Problème, le pod en question était allumé et éteint de manière très régulière.

 « De manière contre-intuitive, nous nous sommes aperçus que le coût de cette opération-là, extinction-allumage de façon trop régulière, est supérieur à celui de l’idle, au fait de le laisser allumer », explique le CTO.

En outre, l’exemple de l’implémentation un peu trop rapide n’est pas isolé. « Force est de constater que nous n’avons pas optimisé notre architecture. Cela dépasse même le cadre du code. Nous avons identifié de potentielles optimisations interservices », renseigne-t-il.

Les équipes de la BU concernée ont également découvert des « micro instabilités ». L’infrastructure 100 % cloud a prouvé son efficacité. Les ingénieurs apprécient notamment la gestion automatique des erreurs des pods Kubernetes. « Or, de temps en temps, des pods se mettent dans une boucle d’erreur au démarrage. Ils se rallument automatiquement, puis retombent en erreur, jusqu’à ce qu’ils se lancent ».

Cela consommerait entre 5 et 10 % des ressources IT totales du système. « Nous voulons obtenir de meilleurs résultats et récupérer de la puissance de calcul », affirme Romain Taillade.

Les travers de l’optimisation ont également fait leur apparition. Pour s’assurer du fonctionnement des éléments optimisés ou des composants qui passeront à l’échelle avant le déploiement en production, certaines équipes ont pendant un temps systématisé les tests de performance. « À un moment, la plateforme de test consommait trois fois plus que l’environnement de production ». Il a été décidé de décaler certains tests de performance. « Cela n’a pas changé fondamentalement l’élasticité de notre système et nous avons drastiquement réduit l’énergie consommée », assure le CTO.

Le Green IT, une autre manière de faire du FinOps

Malgré tout, à l’échelle d’une BU, en quelques mois, Decathlon a déjà économisé l’équivalent de 23 000 kWh. « Cela correspond à peu de choses près aux cycles de machines à laver de la BU de 150 personnes sur 1 an, à raison d’un cycle tous les deux jours », convertit Romain Taillade. « Pour des gens qui travaillent dans un domaine lié au sport, cette métrique est très évocatrice ». C’est aussi la consommation électrique annuelle d’une maison de 140 mètres carrés, d’après les fournisseurs d’énergies. C’est un début et le CTO compte bien poursuivre le déploiement de cette méthodologie. À voir si elle tiendra toutes ses promesses.

Le directeur technique de Decathlon ne le cache pas. Il aurait très bien pu parler d’euros plutôt que de kWh. « Évidemment, dans une entreprise dont le chiffre d’affaires dépasse les 15 milliards d’euros, nous avons une stratégie FinOps. Mais de manière plus ciblée, pour des optimisations de quelques points de pourcentage, la réduction de CO2 est bien plus évocatrice et motivante que d’économiser de l’argent », expose-t-il.

Non, les développeurs et l’IT de Decathlon ne sont pas dans le camp du mal, pense désormais Romain Taillade. « J’ai vu des développeurs se bagarrer pour ne pas cliquer sur le plan supérieur dans la console cloud. Ils ont résisté et tenté d’optimiser leur code. C’est un signal extrêmement positif ».

Et Tristan Nitot d’ajouter que cela ouvre potentiellement la discussion entre les développeurs et les responsables produit, sur la pertinence des fonctionnalités à implémenter en jouant sur ce rapport coût-performance-ROI. Ces conversations sont encore rares chez Decathlon. En tout cas, la métrique permet de constater la pertinence des manières d’implémenter les fonctionnalités et les optimisations.

Et l’IA générative de tout cela ? C’est évidemment une source de pollution et de consommation de budget IT. Malgré tout, Romain Taillade est persuadé qu’elle peut être utile.

« Peut-on téléguider l’IA pour qu’elle produise du code à la fois robuste et optimisé ? », questionne le directeur technique. « Quelque part, c’est un peu la notion de context engineering. Serons-nous capables de lui donner un contexte sur lequel elle pourrait réagir et répondre à nos injonctions parfois contradictoires ? Au vu des capacités des modèles, cette technologie pourrait être une arme assez intéressante pour l’optimisation de notre code dans le futur ».