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.
