Catégorie : Bonnes Pratiques

Décryptage : l’éco-conception des logiciels

Depuis plusieurs années, les médias et des institutions relaient des contrevérités concernant les principaux enjeux et solutions du Green IT. Ces contrevérités vous amènent à vous concentrer sur l’arbre qui cache la forêt plutôt que sur la forêt.

Nous profitons de ce début d’année pour démonter ces contrevérités une à une, afin de vous amener à vous concentrer sur les solutions les plus efficaces pour réduire l’empreinte environnementale des technologies de l’information et de la communication.

Dans les trois premiers articles de cette série, nous avons abordé :

  • L’électricité, les économies d’énergie et le CO2 : http://greenit.fr/article/bonnes-pratiques/numerique-et-environnement-en-finir-avec-les-idees-recues-13-5598
  • Le web, le cloud, et les centres de données : http://greenit.fr/article/bonnes-pratiques/numerique-et-environnement-en-finir-avec-les-idees-recues-23-5600
  • La dématérialisation : http://www.greenit.fr/article/bonnes-pratiques/numerique-et-environnement-en-finir-avec-les-idees-recues-33-5613

Aujourd’hui, nous nous intéressons à l’écoconception logicielle (que vous pouvez aussi écrire « éco-conception des logiciels » ou « software eco-design » en anglais). Cette démarche, que nous avons lancée en 2009 [1], consiste à appliquer la méthodologie de l’écoconception aux logiciels, c’est-à-dire d’identifier les leviers de réduction d’impacts environnementaux les plus forts à chaque étape du cycle de vie d’un logiciel : conception, réalisation, exécution.

Nous décrivons cette démarche en détail dans ce dossier, dans cette rubrique dédiée à l’écoconception logicielle depuis 7 ans, et dans ce livre sur l’écoconception web paru en septembre 2015 et écrit avec le soutien des principaux experts du sujet.

1. C’est une démarche centrée sur le code

La plupart des articles parus dans la presse laissent penser que l’écoconception logicielle est un truc de développeur. En réduisant les occurrences d’anti-pattern / motifs de conception défectueux, on améliorerait l’efficience du logiciel. C’est vrai. Mais cette vision étriquée passe complètement à côté du sujet…

Les principaux leviers de l’écoconception logicielle se situent en amont et en aval de la phase de développement. Comme son nom l’indique, l’écoconception logicielle porte surtout sur la conception fonctionnelle, graphique, ergonomique, et technique. La phase de développement ne représente qu’environ 10 à 20 % des gains potentiels. Pour une raison simple : vous pouvez toujours optimiser le code d’une fonctionnalité qui ne sera jamais utilisée, cela restera du gras numérique. Du gras « bio » s’il est éco-conçu, mais du gras quand même !

Idée à retenir : Plus on intervient tôt dans le cycle de vie, notamment lors des phases de conception, et plus les leviers sont importants. Il ne faut surtout pas se concentrer sur la phase d’écriture du code.

2. C’est la fabrication du logiciel qui concentre les impacts

On a souvent tendance à croire que l’étape du cycle de vie la plus impactante est celle de la fabrication du logiciel. Inconsciemment, on imagine des dizaines de geek barbus qui boivent des hectolitres de café devant des écrans 27 pouces dernier cri. Mais c’est pourtant l’utilisation du logiciel qui concentre les impacts. Elle écrase littéralement les autres étapes. Au point que lors du calcul d’empreinte environnementale d’un logiciel, on ne s’intéresse souvent qu’à la phase d’utilisation. La raison est simple : il y a souvent un écart de 1 à 10 000 (et jusqu’à 1 million) entre le temps total passé devant un ordinateur par les développeurs et celui des utilisateurs. Pour la même raison, sur la phase d’utilisation, ce sont surtout les utilisateurs du logiciel qui concentrent les impacts, pas les serveurs (voir notre démonstration pour le web)

Idée à retenir : La phase d’utilisation et les utilisateurs qui concentrent les impacts.

3. L’écoconception vise à fabriquer des logiciels qui consomment moins d’énergie

Non. Ce n’est pas le premier objectif. L’écoconception logicielle vise d’abord à réduire la quantité de ressources informatiques – serveurs, bande passante, puissance des terminaux utilisateurs, etc. – nécessaires pour une unité fonctionnelle [2] donnée.

En réduisant la couverture et la profondeur fonctionnelle, en évitant la sur-qualité, etc. on réduit mécaniquement la puissance informatique nécessaire au fonctionnement du logiciel. Et, comme il y a désormais plus d’énergie dans la fabrication des équipements utilisateurs (« énergie grise » / « embodied energy ») que dans leur utilisation, on fait plus d’économie d’énergie en réduisant l’empreinte ressource. D’autant qu’en réduisant la gourmandise des logiciels, on favorise l’allongement de la durée de vie des terminaux utilisateurs (et des serveurs).

Idée à retenir : On cherche d’abord à réduire la puissance informatique nécessaire au fonctionnement du logiciel. Il en découle d’intéressantes économies d’énergie.

4. On chercher à fabriquer des logiciels plus performants

Non. Ce n’est qu’une heureuse conséquence. L’écoconception logicielle vise surtout à produire des logiciels efficients, c’est-à-dire qui consomment le moins possible de ressources informatiques par unité fonctionnelle. Parce qu’ils nécessitent moins de ressources informatiques, à configuration matérielle identique, ils vont plus vite que des logiciels non éco-conçus.

Idée à retenir : On cherche avant tout à créer des logiciels plus sobres, moins gras, plus frugaux, centrés sur l’essentiel. La performance naît de l’efficience.

Conclusion

L’éco-conception porte avant tout sur la conception – fonctionnelle, graphique, ergonomique, technique, etc. – et vise en priorité à réduire la quantité de ressources informatiques nécessaires au fonctionnement du logiciel / site web / service en ligne. Cette démarche s’intègre dans une démarche plus large d’écoconception numérique qui s’intéresse aussi à l’infrastructure matérielle sous-jacente.

[1] avec Frédéric Lohier et le soutien de nombreux contributeurs de GreenIT.fr (Lionel Laské, Aurélien Probst, Denis Meudec, Laurent Alliod, François Aubriot, et bien d’autres) et partenaires tels que Octo Technology et Breek (Jérémy Chatard et Stéphane Bordage).

[2] Le terme « unité fonctionnelle » décrit le processus étudié : réserver un billet de train, interroger l’inventaire des produits en stock, consulter la fiche d’un client, afficher un article, effectuer une recherche sur un moteur, etc.

Source : GreenIT.fr

Frédéric Bordage

Expert Green IT et numérique responsable, j'ai créé GreenIT.fr en 2004 et lancé le sujet de l'écoconception logicielle en 2009 avec Frédéric Lohier. Je conseille des organisations privées et publiques sur ces sujets.

Site web - Twitter - Facebook - Linked In