La taverne du testeur

Défis écologique: la consommation d’énergie!

Dans notre vie de tous les jours, nous entendons de plus en plus parler d’écologie et de consommation d’énergie.

Les principaux secteurs « dans le viseur » sont le secteur du transport (particulièrement les avions) et du textile.

Néanmoins, beaucoup de personnes ont bien compris qu’influer sur ces éléments étaient très compliqué (voire impossible) à leur échelle. C’est pourquoi, en suivant le principe du colibri, de plus en plus de personnes agissent à leur niveau pour limiter leur empreinte carbone. On voit par exemple de plus en plus de potager, le développement du Bio et même un objectif « 0 déchet« .

En suivant cet exemple nous pouvons nous pencher sur notre industrie: l’industrie logicielle et ses impacts.

Quel est l’impact de l’industrie logicielle ?

Au premier abord, on peut penser que l’industrie logicielle ne pollue pas. En effet, nous ne produisons « que » du code et donc rien de matériel. De même le transport est quasiment inexistant avec la dématérialisation qui est maintenant une généralité.

Néanmoins, quand on cherche, on voit rapidement que les logiciels conçus ne sont pas « neutre » et génèrent de la pollution.

En effet, les logiciels utilisés sont la cause directe:

  • d’une consommation de serveurs (et donc d’énergie) particulièrement importante pour garder en mémoire des données et exécuter les logiciels. On commence d’ailleurs à entendre parler de la consommation des data center.
  • d’une demande de puissance des machines les exécutants toujours plus importante (aucune comparaison possible entre la puissance d’une Game Boy et la Switch… Pourtant il n’y a que 30 ans d’écart)
  • d’une consommation importante d’énergie pour les développer et les tester

Au final, il y a sûrement des leviers sur lesquels nous pouvons (devons?) influer, d’autant plus que l’évolution des logiciels sur les 50 dernières années n’a pas forcément été été que dans l’amélioration de la qualité… Surtout si l’on parle du critère de performance.

La performance: critère de qualité défaillant!

Pour être honnête, je trouve que le critère de qualité « Performances » (autre que le temps de réponse) est particulièrement mauvais par rapport à ce qui était fait dans les années 60 ou même 80 et 90.

En effet, la puissance de calcul pour aller sur la lune en 1969 est comparable à celle d’une calculette scientifique actuelle. De nos jours, pour retourner sur la lune il nous faudra utiliser de multiples processeurs!

Mario bros 3 tournait sur une NES (8 bits), si on devait le recoder je serai surpris de pouvoir le faire tourner avec 16 bits!

On peut expliquer ce constat pour plusieurs raisons (liste non exhaustive):

  • A l’époque la puissance de calcul était beaucoup plus limitée. Pourquoi optimiser la consommation de ressource alors que le produit fonctionne parfaitement sans le faire ? C’est une question légitime à laquelle beaucoup de personnes doivent répondre: « On s’en fout » car cela fait « perdre du temps » en ré-écriture.
  • Le souhait d’avoir des solutions toujours plus génériques et accessibles. Attention, je ne considère pas qu’avoir des solutions génériques et accessibles soient une mauvaise chose en soit. Néanmoins il ne faut pas pour autant continuer à penser à l’optimisation des ressources comme c’était le cas jusque dans les années 90.
  • Les nouveaux langages, plus haut niveaux sont moins optimisés au niveau de la mémoire. On doit maintenant, avec la même fonction, être capable de courir un marathon (peu d’énergie à long terme) et un sprint (beaucoup d’énergie à court terme). La seule solution est d’avoir accès à énormément d’énergie long terme.
  • Les échanges de données se multiplient. Ainsi que leur duplication… Pour être honnête je m’énerve toujours quand on me demande des informations alors que je les ai déjà données à un service de la même société.
  • Le besoin de réactivité et de nouveautés pour les utilisateurs. On le voit par exemple avec le DevOps et le déploiement continu…

Au final, quelles solutions ?

Le constat est malheureusement assez alarmant, d’autant plus que notre consommation de données ne cesse de s’accroitre de façon quasi exponentielle.

Il y a cependant plusieurs solutions qui permettraient de nous améliorer sur ce point:

  • Former et sensibiliser les développeurs et autres ingénieurs informatiques sur le sujet de la performance
  • Intégrer au plus tôt les notions de performances dans le cycle de développement. Oui, c’est simplement le principe tester tôt et donc du shift left appliqué aux performances (plus généralement à faire pour le non-fonctionnel).
  • Valoriser les application peu gourmande en énergie. (moins de dépenses d’électricité, moins de dépences en flux de données pour le Cloud, plus d’application en parallèle, plus d’autonomie…)
  • Mutualiser les données. Prenons l’exemple de l’état. Plutôt qu’avoir 100 bases de données différentes avec des données redondantes, autant en avoir une seule avec des permissions suivant les services!
  • L’oubli. Ne conserver les données qu’un certain temps.
  • Collecter uniquement des données utiles. Cela peu sembler creux mais cela me parait évident. Je trouve cela inutile (et énervant) de devoir entrer ses données de carte bancaire pour un produit gratuit (bonjour l’apple store!)…

Conclusion

Le défi écologique est particulièrement important dans le logiciel. Contrairement à ce que l’on pourrait penser, notre secteur est extrêmement impactant (et encore plus avec la dématérialisation), d’autant plus que nous avons beaucoup régressé sur le sujet des performances dans les dernières décennies.

Fort heureusement, des solutions existent, certaines se trouvent même dans notre passé proche!

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

conférence

La ParisTestConf, la conférence des artisans testeurs

En 2018, sur le slack de la Test Communauté, quelques passionnés du test logiciel échangent sur les conférences testing en France et font le constat qu’ils ne trouvent pas ce dont ils ont besoin pour évoluer dans leur quotidien. Ils se lancent donc dans le pari un peu fou de

Lire la suite »
Agilité

Vous avez dit DevOps ?

Les DevOps tel qu’il est (souvent) mal perçu On parle régulièrement de DevOps. Ce mot est devenu un mot « valise » derrière lequel on met beaucoup de choses toutes plus merveilleuses les unes que les autres. Le plus souvent ce qui est « sous-entendu » par DevOps est une chaîne d’intégration continue, une

Lire la suite »
Agilité

Livre CFTL – Rex – Echec d’un projet/produit agile

Dans ce chapitre, nous nous attarderons sur un projet agile qui fût un « échec ». Par échec, je ne veux pas dire pas que le produit n’a jamais vu le jour mais plutôt que le projet, ou devrais-je dire le produit, a :  Explosé les coûts prévus  Explosé le temps prévu (près

Lire la suite »