La Duck Conf 2026 - Comment mener 2000 développeurs vers du numérique plus responsable ?

Lors de l'édition 2026 de la Duck Conf, Romain Taillade, Global CTO chez Decathlon, et Tristan Nitot, en charge de l'anthropocène et des communs numériques chez OCTO Technology, ouvrent le bal sur leurs expériences de plusieurs mois sur le numérique responsable. La présentation mêle des choses qu'on aime, d'autres moins, de la théorie mais aussi de la pratique, le tout saupoudré d'un peu de SF.

L'ivresse du scale et le paradoxe du CTO chez Décathlon

Pour ancrer le sujet, Romain présente le contexte Décathlon au travers du nombre d'appels API dans le SI. Même si ce n'est qu'une unique métrique, elle traduit à la fois l'accélération du numérique et comment elle sert la démocratisation du sport chère à Décathlon. Même si le chiffre d'affaire n'a pas suivi la même courbe, cette progression souligne que le futur pour Décathlon va de pair avec un système numérique performant.

Mais l'IT a également sa face sombre, qu'on ne veut pas toujours regarder en face et que Romain illustre au travers de quelques exemples :

• L'Irlande qui, à force d'attirer les constructeurs de data centers, se retrouve menacée de coupures électriques.
• Le succès du fondeur TSMC qui entraîne une énorme consommation d'eau potable, de l'ordre de la consommation d'une grosse agglomération.
• nVidia qui, grand gagnant de la course à l'IA, voit son bilan carbone exploser.
• Ou encore Microsoft qui, pour sécuriser sa grille électrique, compte rouvrir une centrale nucléaire ayant déjà fait l'object d'un incident grave.

Ces externalités amène une question brutale : les équipes numériques ne seraient-elles pas dans le camp du mal ? Car la mission de Décathlon de démocratiser le sport se heurte à la mise en danger de l'outdoor qui est son premier marché. L'entreprise dans son ensemble prend de nombreuses mesures pour réduire son empreinte environnementale, mais quel rôle ont à jouer les équipes de développement, au plus proche du code ? C'est là où la rencontre avec Tristan a été inspirante.

EROOM ou comment bien faire du logiciel à l'ère du Bloatware

Nous vivons aujourd'hui dans l'ère du Bloatware, rappelle Tristan. Ce que produit l'industrie de l'IT est en grande partie des logiciels consommant sans cesse davantage de ressources. Depuis que Gordon Moore a édicté sa fameuse loi en 1965, le marché a suivi, car il s'agissait au fond d'une loi de programmation industrielle. Les processeurs d'aujourd'hui contiennent plus de 21 millions de fois plus de transistors que leurs ancêtres d'il y a 50 ans. Et suivre cette cadence exponentielle implique de produire toujours plus d'ordinateurs, rendant obsolètes les précédents.

Le matériel double de puissance tous les 24 mois - Loi de Moore

Le corollaire moins glorieux est la loi de Wirth, édictée par Niklaus Wirth, qui déplorait que l'accroissement de puissance matérielle s'accompagnait d'une voracité croissante en ressources des logiciels.

Non, votre ordinateur n'est pas devenu trop lent, ce n'est pas vrai. Par contre, vous mettez de nouvelles versions de logiciels moins efficaces, et qui sont moins adaptées à votre matériel. La lenteur perçue n'est pas due à un ralentissement de la machine, en fait vous déployez la loi de Wirth sur votre machine. - Tristan Nitot

En tant que professionnels de l'IT, on regarde souvent la consommation en ressources à l'utilisation. Mais à y regarder de plus près, c'est la fabrication qui pèse le plus lourd dans la balance.

Tristan illustre les gains potentiels d'optimisation via un entraînement d'algorithme de Machine Learning qui est passé de 15h à 10s. Ce qui semble un gain positif met aussi en exergue qu'avant optimisation, il y avait un important gaspillage de ressources. Donc comment faire mieux et lutter contre la loi de Wirth ?

Tristan nous propose d'inverser la loi de Moore via la loi d'EROOM : optimisons tous les deux ans l'existant logiciel. Ni refonte, ni réécriture, c'est une optimisation ciblée : identifions le code gourmand et améliorons sa consommation. On ne change donc pas de matériel, on continue à produire du logiciel, mais de manière bien plus propre, sur de la ressource libérée.

Optimiser le logiciel d'un facteur 2 tous les 2 ans - Loi d'EROOM (Effort Radicalement Organisé d'Optimisation en Masse)

Tristan a publié plusieurs articles à ce propos (sur le blog OCTO, sur Linkedin) et a participé à plusieurs conférences qui ont rencontré un franc succès, car faire du numérique proprement grâce à de l'optimisation a retenu l'attention. Afin de diffuser cette approche au sein de nos entreprises, Tristan a mobilisé des collègues chez OCTO, ainsi que le collectif Boavizta pour proposer une méthodologie EROOM disponible en open source. En résumé elle propose de :

1. Continuer à investir dans la montée en compétence des équipes de développement pour qu'elles apprennent à produire du code plus lisible, plus maintenable et plus performant.
2. Ensuite repérer les éléments critiques consommateurs de ressources, qui ne représentent souvent qu'une petite partie du volume de code global, et comprendre pourquoi ils le sont devenus.
3. Optimiser ces éléments grâce aux équipes de développement seniors, qui garantissent lisibilité et maintenabilité via leurs pratiques de software craftsmanship.

Ainsi grâce à cette méthodologie, EROOM passe d'un storytelling séduisant à une approche actionnable, permettant de faire du numérique respectueux des limites planétaires, de faire du travail de meilleure qualité et de continuer à innover.

Mise en pratique chez Décathlon

Il manquait à Décathlon un indicateur de tendance pour passer du diagnostic EROOM à l'action. Ainsi est née la métrique ORI, pour Operational Resources Intensity, dont l'objectif est d'observer les tendances en fonction des événements réels qui affectent le système : nouveaux clients, nouveau code déployé en production…

L'ORI permet de garder le cap en couplant la consommation de ressources avec la valeur business produite, importante aux yeux des décideurs. Le calcul de cette métrique est automatique et n'ajoute pas de tâche aux équipes de développement car il s'intègre dans un framework général : le Tech Performance Framework. Ce dernier évalue de manière globale le code produit et s'inscrit dans ce que Décathlon considère comme l'état de l'art du développement sur les volets sécurité, architecture… et aussi GreenIT.

En pratique, Romain donne l'exemple d'une équipe qui a vu son ORI partir à la hausse alors qu'aucun des autres indicateurs business, de disponibilité, d'incidents… n'avait détecté d'anomalie et qu'aucune release de code n'avait eu lieu. La source était une modification du contexte : un nouveau consommateur d'API faisait des appels de manière sous-optimale. Après échange avec l'équipe concernée, et utilisation d'une meilleure manière de requêter, l'ORI est revenu à un état stable. Cela a montré la valeur de cet indicateur : mesurer, échanger entre équipes et optimiser.

Attention quand on déploie une métrique à ne pas tomber dans la sanction ou dans l'effet Cobra. Romain souligne qu'un point-clé est l'état d'esprit orienté gamification : c'est un jeu intellectuel, et quand il y a des variations, il faut modifier son plan de jeu.

Après quelques mois, des patterns intéressants ont émergé :

1. L'effet "néon", où les équipes ont mesuré que pour leur parc applicatif, s'appuyant en grande partie sur Spring Boot, il valait mieux laisser les instances allumées que les éteindre souvent pour éviter la consommation liée au cold start.
2. "C'était plus facile comme ça…" : la première implémentation n'est pas forcément optimisée. L'approche a permis d'identifier et d'améliorer ces implémentations qui étaient en-dessous des standards.
3. Les micro instabilités : les mécanismes de résilience Kubernetes occasionnaient parfois des redémarrages en boucle de pods qui tombaient systématiquement en erreur. Le suivi de la métrique ORI a permis de détecter et de résoudre ces problèmes.
4. On teste beaucoup quand même : la mesure a montré que la plateforme de tests consommait trois fois plus que celle de production. En réduisant la fréquence d'exécution de certains tests, notamment ceux performance, la consommation a été réduite sans mettre en danger le scaling.

Et concrètement, l'économie sur un an s'élève à 23 000 kWh, ce qui représente tous les cycles de machines à laver le linge de la BU de 150 personnes, un vrai poste de dépense quand on travaille dans le sport.

Takeaways

1. GreenIT > Finops : on aurait pu utiliser le coût en euros comme métrique, mais le sens perçu par les équipes n'est pas le même. Ça donne de l'espoir dans la réponse à la question : "est-ce qu'on est dans le camp du mal ?", et ça fait réfléchir à essayer de faire plus avec moins.
2. Enfin une chance de discuter sur l'utilité de ce qu'on fait, en mesurant objectivement. C'est un outil puissant pour aider à détricoter la loi de Wirth, en remettant sur la table le coût et la valeur apportée par les features mises en production.
3. Méfiez-vous des évidences : le bon sens paysan est parfois une bonne chose, mais tant qu'on ne mesure pas, en réalité on n'en sait rien. On ne peut changer que ce qu'on mesure
4. Ne pas opposer approche ROIste et Optimisation : nous avons tous envie de faire des économies, de consommer moins. Mais la limite peut être ténue entre faire moins et faire mieux. Avec l'approche ORI, on a trouvé une façon de faire mieux et en même temps soutenir le business. Les décideurs comprennent, et les équipes de développement sont contentes.

L'interlude IA

Tenir toute une présentation sans mentionner l'IA est probablement un record en 2026. A quelques minutes de la fin, Romain et Tristan proposent quand même un court avis sur la question : il n'y aura pas vraiment de choix d'y passer ou non, l'IA a un pouvoir incroyable, mais la question est comment bien l'orienter ? Grâce au framework de performance, on la guide sur comment faire du code optimisé, et la consommation engendrée par l’utilisation ponctuelle de l’IA sera largement récupérée par l’optimisation qu’elle permettra.