Tests logiciels durables : comment réduire l'empreinte énergétique de vos pipelines sans sacrifier la qualité

Pourquoi s'intéresser à la durabilité des tests logiciels ?

Les pipelines de tests automatisés tournent en continu dans la plupart des organisations : à chaque commit, chaque merge, chaque déploiement. Cette exécution répétée consomme de l'énergie, du temps machine et de l'argent. Lors de l'OOP Conference, Jochen Joswig a présenté une approche baptisée DevGreenOps (l'intégration des préoccupations environnementales dans les pratiques DevOps), rapportée par InfoQ, qui vise à réduire cette empreinte sans rogner sur la qualité logicielle. Son constat : une grande partie des tests exécutés au quotidien sont tout simplement inutiles dans le contexte d'un changement donné.

Le point de départ : une vraie stratégie de test

Selon Joswig, la durabilité des tests commence par la mise en place d'une stratégie de test rigoureuse. Elle garantit qu'aucun test ni cas de test superflu n'est exécuté, ce qui réduit à la fois la durée des campagnes de tests et leur consommation, en suivant des critères de minimalisme et d'efficacité.

Deux principes structurent cette approche :

• Échouer vite et tôt (fail fast) : dès qu'un test échoue, l'exécution du reste de la suite peut être interrompue. Concrètement, les tests unitaires (rapides et peu coûteux) tournent en premier ; si une erreur y est détectée, il devient inutile de lancer les tests d'intégration, de bout en bout ou d'interface, bien plus gourmands.
• N'exécuter que les tests concernés par le changement : c'est particulièrement pertinent dans les monorepos (dépôts de code uniques regroupant plusieurs applications). Si seul le code frontend change, rien ne justifie de retester le backend, et inversement. On peut même aller plus loin en lançant d'abord une analyse statique du code pour n'exécuter ensuite que les tests réellement affectés.

Mesurer l'énergie consommée par chaque test

Pour aller plus loin, Joswig recommande de suivre la consommation énergétique de chaque test individuel pendant son exécution et d'injecter ces données dans la stack d'observabilité de l'équipe. On peut alors déclencher des alertes lorsque certaines méthodes ou certains runs dépassent des seuils énergétiques, ce qui incite à réusiner (refactorer) les parties du code concernées pour en optimiser la performance.

Si la mesure directe de l'énergie n'est pas possible, des métriques de substitution (proxy) restent exploitables : volume de données transférées en mégaoctets, temps d'exécution, utilisation CPU et mémoire. Ces indicateurs offrent déjà une transparence utile sur les tests les plus coûteux.

Interrogé par InfoQ sur l'intérêt de ce suivi, Joswig souligne qu'il donne aux développeurs une visibilité sur la consommation de chaque partie de l'application et sur les gisements d'amélioration. Il cite un précédent révélateur : c'est en observant un comportement anormal lors de ses tests qu'Andres Freund a découvert, presque par accident, la faille de sécurité critique référencée CVE-2024-3094 dans la base nationale des vulnérabilités du NIST (l'institut américain des standards). Une découverte de cette gravité laissée au hasard illustre, selon lui, tout ce que les équipes peuvent apprendre de leur logiciel en l'instrumentant mieux.

L'analyse statique pour traquer les inefficacités évidentes

Autre levier : l'analyse statique du code (analyse du code source sans l'exécuter), pour repérer les inefficacités faciles à détecter, comme des appels backend ou des requêtes en base de données lancés à l'intérieur d'une boucle.

Joswig cite notamment Creedengo, un plugin open source pour SonarQube (plateforme d'analyse de qualité de code), qui prend en charge Java mais aussi Python, JavaScript et C#. Des alternatives propriétaires existent, potentiellement plus larges en couverture de langages, mais Joswig précise ne pas avoir pu les vérifier lui-même, ces outils étant payants.

Une réserve importante accompagne Creedengo : certaines de ses règles ont un impact négligeable sur la performance et la consommation d'énergie. Il est donc essentiel de sélectionner manuellement un sous-ensemble de règles réellement utiles plutôt que d'activer l'outil en bloc.

« Le code le plus vert est celui qu'on n'écrit jamais »

Guidé par cette devise, Joswig insiste sur l'importance de tester très tôt dans le cycle de développement, avec des maquettes cliquables basse fidélité ou des prototypes papier. L'objectif : s'assurer que les équipes se concentrent sur des fonctionnalités qui apportent réellement de la valeur aux utilisateurs, avant d'investir du développement — et donc de l'énergie — dans des features inutiles.

Le développement logiciel durable est un effort d'équipe auquel chacun peut contribuer, y compris le Product Owner : en spécifiant que le logiciel doit supporter des matériels et systèmes d'exploitation anciens ou moins puissants, puis en demandant à l'équipe de tester la compatibilité et l'utilisabilité sur ces appareils. La durée de vie prolongée du matériel qui en résulte réduit les émissions et les effets néfastes liés à son remplacement. Quant au nombre d'appareils de test à posséder, Joswig recommande d'en avoir le moins possible, mais autant que strictement nécessaire.

Vers une adoption plus large du green software

Interrogé sur l'avenir du développement logiciel durable, Joswig anticipe une hausse de la demande en électricité du secteur dans les prochaines années. Cette hausse pourrait renchérir les coûts : le prix de l'énergie et du matériel restera un facteur déterminant de la rentabilité des innovations, et l'efficacité énergétique pourrait devenir un avantage concurrentiel.

Il s'attend à ce que des individus, institutions, universités, entreprises et projets open source contribuent à sensibiliser et à outiller cette transition. Le secteur marchand pourrait mettre du temps à adopter les bonnes pratiques du green software, mais les gouvernements — en particulier dans l'Union européenne — ont déjà la durabilité IT à l'agenda. Joswig anticipe que les appels d'offres publics intégreront des exigences de durabilité logicielle, créant potentiellement un effet de cascade d'adoption dans toute la chaîne de sous-traitance.