Intervention de Cinchéo à “Tech4Climate?” – L’éco-conception logicielle : quelques constats et conseils pour démarrer

Le 9 juin 2022, j’étais invité à intervenir dans l’atelier “Les acteurs du numérique au service de la transition” de l’événement “Tech4Climate?” organisé par le groupe Constellation.

Pour celles et ceux qui n’ont pas eu la chance d’y assister, voici quelques photos et le résumé des messages que j’ai fait passer.

Quelques constats

Le logiciel joue un rôle majeur dans notre maîtrise de l’empreinte environnementale de l’IT en général, car il est en début de chaîne. Plus le logiciel est lourd (consommateur de ressources), plus il faudra un hardware puissant et consommateur d’énergie, et plus sa fabrication aura un impact important sur les resources naturelles et les émissions de GES.

Le problème ne date pas d’hier, puisque déjà en 1995, Nicklaus WIRTH, le créateur du language Pascal, alertait sur la dérive des logiciels obèses avec son plaidoyer pour les logiciels sobres/sveltes (en opposition aux logiciels obèses).

Malheureusement, force est de constater que WIRTH n’a pas été écouté.

Pour preuve, entre 1998 et 2019, la consommation en ressources de la suite Office de Microsoft a été multiplié par 171 pour la mémoire, et par 60 pour le CPU. Cela signifie que si vous vouliez utiliser la suite Office actuelle, sur votre PC datant de 1998, il faudrait dans votre bureau au minimum 60 ordinateurs.

Si vous vouliez utiliser la suite Office actuelle, sur votre PC datant de 1998, il faudrait dans votre bureau au minimum 60 ordinateurs.

Constat basé sur l’analyse de l’évolution des besoins en resources de la suite Microsoft Office entre 1998 et 2019

D’un certain point de vue, c’est une bonne nouvelle : cela veut dire que le matériel que l’on fabrique est de plus en plus puissant, et donc potentiellement de plus en plus efficient. Mais d’un autre point de vue, c’est une très mauvaise nouvelle, car cela veut dire que les améliorations d’efficacité du matériel sont annulées par l’augmentation permanente de la consommation en resources des logiciels, et pas seulement pour ajouter des fonctionnalités utiles.

Cette loi de compensation avait été prédite par Nicklaus WIRTH en 1995, et elle s’est malheureusement avérée tout à fait exacte : la lourdeur des logiciels augmente largement aussi vite que la puissance du matériel, annulant ainsi les effets positifs de son efficience.

L’obésité logicielle peut s’expliquer par la conjonction de plusieurs facteurs. Par exemple, on utilise des outils de développement extrêmement puissants, comme les gestionnaires de dépendances, qui engendrent des effets rebonds. Autre exemple, la big data et le ML ont entériné un sentiment de resources sans limites, avec des systèmes de stockage pour conserver l’information “au cas où”, et une utilisation de cet amas de données, qu’on n’a pas hésité à qualifier de “nouvel or noir”.

Depuis des décennies, les mentalités nous poussent collectivement à empiler le plus possible de fonctionnalités et de données plutôt que se demander de quoi on a vraiment besoin.

Quelques conseils pour démarrer avec l’éco-conception 

L’éco-conception logicielle est une activité qui consiste à maximiser l’utilité d’un service logiciel tout en minimisant les resources (CPU, mémoire, réseau, disque, …) nécessaires à son bon fonctionnement.

On pourrait croire qu’il s’agit d’un investissement coûteux pour l’entreprise, et que la plupart n’ont pas les moyens de faire de l’éco-conception. En réalité, l’éco-conception est très souvent synonyme d’un investissement rentable avec des effets immédiats qui peuvent être spectaculaires. En 2014, Frédéric Bordage (GreenIT) a communiqué quelques exemples concrets pour démontrer le win/win entre l’éco-conception logicielle et la rentabilité d’un service numérique.

Un premier exemple consiste à s’appuyer sur les innovations technologiques, comme Facebook en 2010, qui a divisé par 2 le nombre de serveurs nécessaires pour faire tourner son réseau social (économies : 1 data center de 100 Millions de dollars) en développant un compilateur de PHP vers C++.

Un deuxième exemple insiste sur l’importance de l’adaptation des logiciels aux usages, en expliquant par exemple que pour un moteur de recherche comme BING, les 5 derniers résultats affichés sollicitent 80% des resources, alors que la grande majorité des utilisateurs s’arrêtent aux premiers résultats. En adaptant l’algorithme aux usages, on peut diviser par 5 la quantité de resources nécessaires, sans pour autant dégrader l’utilité du moteur de recherche.

Ainsi, maximiser l’efficacité grâce à une meilleure conception logicielle intégrant mieux les usages peut être synonyme d’économie substantielle, et même d’augmentation du chiffre d’affaire du fait d’une meilleure utilisation des logiciels. En règle générale, la limitation du périmètre fonctionnel implique de facto une meilleure qualité du logiciel, et donc une meilleure utilité.

Ces conseils pour l’éco-conception logicielle reviennent au final à suivre les principes de bonne conception de Dieter RAMS, un designer allemand qui a largement influencé l’industrie allemande ces dernières décennies, avec le succès que l’on sait, et qui démontre encore une fois la compatibilité entre l’éco-conception et la rentabilité.

Quelques principes essentiels de bon design : un bon produit est innovant, intuitif, honnête, durable, écologique et minimaliste

Voir les 10 principes de bon design de Dieter RAMS

Enfin, pour faire de l’éco-conception logicielle, les outils et méthodologies agiles ainsi que les outils de monitoring existants sont actionnables directement et permettent de mettre en place des cycles itératifs courts visant à maximiser l’utilité et la performance des logiciels (donc l’efficacité).

Il ne faut surtout pas utiliser l’agilité pour empiler des fonctionnalités qui sont déjà résolues par d’autres logiciels, ou qui ne seront pas utilisées par la grande majorité des utilisateurs (comme c’est malheureusement trop souvent le cas). Sur ce dernier point, les logiciels Open Source en particulier sont des outils qui nous permettent d’envisager une meilleure réutilisation sans avoir à ré-inventer la roue systématiquement. Les logiciels Open Source doivent donc être intégrés à la stratégie logicielle de l’entreprise responsable, y compris chez les éditeurs.

Et le No-Code/Low-Code alors?

Parmi les questions posées, l’une concernant le No-Code / Low-Code a particulièrement retenu mon attention. Normal, vu que Cinchéo développe actuellement DLite.io, une plateforme low-code Open Source pour le développement d’applications Web. Ma réponse quant à l’intérêt du No-code / Low-code a été en substance la suivante.

  • Le low-code peut permettre de ne pas réinventer la roue, d’éviter de re-coder des composants logiciels complexes et donc d’améliorer la qualité en tirant partie des expériences métiers et/ou techniques déjà disponibles.
  • D’un point de vue de l’éco-conception, il y a donc des effets positifs qui permettent, dans le cadre d’une démarche itérative appropriée, de limiter plus facilement le scope fonctionnel en identifiant et éliminant plus rapidement des fonctionnalités redondantes ou inutiles.
  • Bien sûr, il y a aussi des effets négatifs, vue qu’il y a une montée en abstraction des outils, ce qui peut entraîner des effets rebonds ou des lourdeurs inhérentes. Mais il faut toujours penser en terme d’efficience (en intégrant l’utilité) et non uniquement de performance. Par exemple, même s’il est notoirement connu que le language C est beaucoup moins énergivore que Python, il est aussi quasiment impossible pour le C de rivaliser en terme d’utilité dans le cadre d’algorithmes et de modèles de Data Science et de Machine Learning. Il en va de même pour le low-code, il faut toujours centrer le raisonnement pour adapter les outils aux usages pour maximiser l’efficience. La simple mesure de performance n’est souvent pas représentative si elle n’est pas normalisée par une mesure de l’utilité. Ce raisonnement est valable quelque soit le problème et l’outil envisagé pour le résoudre, et surtout quand on utilise un outil Open Source comme DLite, qui propose en built-in des outils actionnables directement pour l’éco-conception (voir : Inside DLite: low-code components, model-driven tools, local-first and eco-design explained).

Pour aller plus loin

Kanopee (du groupe Constellation) propose des formations à destination des entreprises qui souhaitent addresser la problématique du bas carbone de front. J’ai conçu et j’interviens sur la formation “Eco-conception logicielle pour le numérique responsable” qui rencontre régulièrement l’intérêt des développeurs, mais qui est aussi très bénéfique pour les décideurs, commerciaux, PO, etc.