Auteur : Thierry LEBOUCQ

Thierry LEBOUCQ est le président de GREENSPECTOR, qu'il a fondé en 2010. Auteur et conférencier, il est extrêmement actif et joue un rôle de pionnier dans le secteur des technologies de l'information verte en France. Il a été un contributeur majeur en France et en Europe aux préoccupations d'écoconception de logiciels. Il a dirigé plusieurs projets de R & D sur les logiciels verts et plusieurs initiatives sur l'étiquetage vert pour les applications Web, mobiles et IoT.

Rencontrons-nous au Lab d’Innovation d’Orange à Viva Technology 2018

Reading Time: 2 minutes

GREENSPECTOR sera présent à Viva Technology 2018 le 24 mai prochain, au sein du Lab Innovation d’Orange.

Nous sommes fiers d’avoir été sélectionnés par Orange, partenaire de l’évènement. Avec plus de 80 000 participants, 8 000 startups et 103 pays représentés, Viva Technology est le rendez-vous incontournable de l’innovation digitale pour les startups et investisseurs. Le Lab Orange fait partie de l’ADN de l’évènement, c’est un lieu d’échange, d’innovation et de rendez-vous entre les industries et les startups. Une opportunité pour nous de présenter notre solution d’efficience des applications web, mobiles et IoT et ses bénéfices en termes de performance, d’autonomie des appareils et d’expérience utilisateur.

Thierry LEBOUCQ, Président de GREENSPECTOR
Après avoir remporté le prix Orange Award au Mobile World Congress 18, c’est une fierté d’être à nouveau choisi par Orange pour représenter la dimension “efficience énergétique” des services numériques lors de cette seconde édition de VivaTech. Plusieurs collaborations ont permis aux équipes de travailler ensemble sur des projet mobiles et IoT. Une collaboration en R&D a permis en 2015-2016 notamment de décrire un guide méthodologique sur l’Analyse Cycle de vie des logiciels basé sur un cas d’utilisation dans le smartHome. Depuis, notre travail partenarial s’est concentré sur des projets mobile à forte valeur business. Intégrer le contrôle et l’amélioration des consommation de ressources dans les projets devient un avantage concurrentiel pour Orange. Et en intégrant cette dimension et Greenspector dans son outillage,… Orange passe au Vert !

Retrouvez-nous sur place (Stand J09-047) le Jeudi 24 Mai, nous répondrons à toutes vos questions. Contactez-nous dès maintenant pour planifier un rendez-vous.

[11 au 12 Décembre] Greenspector se mobilise lors de la semaine mondiale de la transition à Tech for Planet et aux World Efficiency Solutions à Paris

Reading Time: 2 minutes

Du 11 au 14 Décembre, Paris sera la capitale mondiale de la transition, accueillant le One Planet Summit ainsi que plusieurs autres évènements en parallèle tels que le Tech for Planet (le 11 décembre) ou les World Efficiency Solutions (du 12 au 14 décembre). GREENSPECTOR participe et se mobilise pour cette semaine Green.

Continue reading “[11 au 12 Décembre] Greenspector se mobilise lors de la semaine mondiale de la transition à Tech for Planet et aux World Efficiency Solutions à Paris”

[Retour d’expérience] Le projet ETG du Groupe La Poste

Reading Time: 3 minutes

La Poste est devenu opérateur national pour le passage du code de la route depuis 2016. Cet examen appelé ETG (Examen Technique Général) se traduit par la mise à disposition d’une tablette dans une salle d’examen d’un bureau de poste et d’une série de questions posées à chaque candidat. Chaque bureau de poste est donc équipé de tablette de type Galaxy Tab A.

Continue reading “[Retour d’expérience] Le projet ETG du Groupe La Poste”

Fin de vie : obsolescence et déchets liés aux logiciels ?

Reading Time: 3 minutes

La phase de fin de vie d’un logiciel est également difficile à appréhender et fait donc ici l’objet d’un article dédié, clôturant notre série sur l’ACV des logiciels.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Les logiciels se cachent pour mourir (fin de vie & obsolescence)

La phase de fin de vie d’un logiciel est particulièrement délicate à envisager dans l’analyse de cycle de vie, notamment pour les deux raisons suivantes :

1) Il n’existe pas d’obsolescence intrinsèque à un logiciel. Un logiciel est théoriquement utilisable à l’infini, tant qu’il existe des matériels pour le faire fonctionner. Le logiciel ignore l’usure et ne risque pas de tomber en panne parce qu’il est lui-même devenu trop vieux. On ne peut donc pas déterminer une durée de vie d’un logiciel qui serait liée au fait que ses composants vont se dégrader au cours du temps. Les seules raisons qui rendent un logiciel obsolète sont extérieures au produit lui-même :

  • décision de l’utilisateur de le supprimer,
  • politique de maintenance d’une version,
  • obsolescence des matériels supportant le logiciel,
  • obsolescence des autres logiciels en interaction avec le logiciel (système d’exploitation, bases de données…),
  • disparition du besoin utilisateur
  • etc.

2) Un logiciel ne génère pas en apparence de déchets matériels en fin de vie. Lorsqu’on décide de ne plus l’utiliser – ou qu’on ne peut plus l’utiliser – il est simplement supprimé du poste sur lequel il est installé sans que cela ne génère de déchets matériels. Au pire, il reste des fichiers qui occupent inutilement de l’espace disque. Mais en réalité, si l’on y regarde de plus près on trouve des déchets matériels (déchets liés au processus de conception / développement, CD + boîte + Manuel papier (si le logiciel était emballé…)… pris en compte dans d’autres étapes de l’analyse), et surtout des déchets liés au matériel (ordinateur, smartphone, tablette, équipement réseau …) utilisé pour faire fonctionner le logiciel.

En quoi le logiciel contribue-t-il à générer des déchets ? Tout simplement par son impact direct ou indirect sur l’obsolescence du matériel :

Remplacement ou mise à jour logiciel nécessitant de nouveaux équipements :

Pour un même besoin utilisateur, si le logiciel subit une mise à jour majeure ou s’il est remplacé par un autre logiciel, et que cette opération nécessite d’autres ressources matérielles (machines plus puissantes, technologies différentes), alors on peut considérer les anciens matériels comme des déchets causés par le logiciel. C’est le phénomène d’ « obsolescence des matériels » entraîné par le renouvellement des logiciels : c’est donc le logiciel qui est responsable du déchet. Un logiciel mature (sans évolution fonctionnelle) n’a pas de raison d’être à l’origine de déchets… Mais quel logiciel n’évolue pas ? On veillera, a minima, à contrôler les consommations de ressources demandées par les nouvelles versions du logiciel.

Mauvaise désinstallation :

une procédure de désinstallation mal conçue ou mal appliquée peut aussi contribuer à l’obsolescence. En effet, des clés de registre laissées, des fichiers temporaires ; si le logiciel ne laisse pas le système comme il était avant, on crée un empreinte ressource résiduelle qui vient alourdir le fonctionnement du système.

Effet de bord de la désinstallation sur d’autres logiciels :

Il faudra également s’intéresser aux autres logiciels que la désinstallation en fin de vie peut rendre obsolètes : des dépendances peuvent exister qui risquent d’avoir un effet d’obsolescence en cascade (je mets à jour mon logiciel => il exige une nouvelle version de gestionnaire de base de données => ce gestionnaire demande une mise à jour de l’OS => le nouvel OS n’a plus de pilote pour mon imprimante => je change mon imprimante…).

On le voit, la phase de fin de vie d’un logiciel peut s’avérer complexe à appréhender. Toutefois on gagnera lors de l’étude à en faire une première approximation rapide, afin de déterminer si elle représente un poids relatif important ou non par rapport aux autres phases.

Cette série sur l’ACV des logiciels est maintenant terminée, retrouvez sur le blog les précédents articles traitant de ce sujet:

Vous pouvez auss retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Écoconception des logiciels : Quel est le cycle de vie d’un logiciel ?

Reading Time: 5 minutes

L’objectif de cet article est de présenter le cycle de vie d’un logiciel. Pour chacun des problèmes que soulève l’analyse de ce cycle de vie, nous indiquerons l’approche que nous recommandons, notamment pour l’évaluation des impacts environnementaux.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réelle sur l’évaluation des impacts environnementaux d’une application disponible en téléchargement.

La grande majorité des cycles de vie des produits manufacturés étudiés lors des ACV (Analyses de Cycle de Vie) peuvent être considérés comme étant composés des 6 phases suivantes:

  • la conception du produit,
  • l’extraction des matières premières,
  • le processus de fabrication et de conditionnement,
  • le processus logistique et d’acheminement,
  • l’usage du produit,
  • la fin de vie (démontage, transport, tri, recyclage, déchets).

Cependant, si ce cycle de vie est pertinent pour un produit matériel usuel, il l’est moins pour un logiciel. En effet, en tant que « bien immatériel », un logiciel ne nécessite pas directement d’extraction de matières premières.
La phase de fabrication n’est pas envisageable comme un processus de fabrication répété N fois pour produire N exemplaires du produit : il faut plutôt la considérer comme une phase unique permettant d’aboutir à une version du logiciel théoriquement reproductible et réutilisable à l’infini.

Transport amont et distribution

Pour la phase de transport amont (logistique), si le logiciel est conçu à partir de différentes modules développés sur différents sites, il faudra (dans la mesure du possible) prendre en compte l’envoi depuis les différents sites vers le site d’agrégation des différents modules. Dans une première approche ces impacts pourront être considérés comme négligeables car ayant de très grandes chances de représenter moins de 5% des impacts totaux.
Si la distribution vers les utilisateurs finaux est réalisée via un téléchargement sur internet, l’impact environnemental de ce téléchargement devra être pris en compte. Si la distribution se fait par un support matériel (DVD, clef USB…) la fabrication et le transport de ces supports devront être pris en compte.
L’installation du logiciel peut être rattachée à la phase d’usage. La maintenance pourra être modélisée comme étant un surcoût de la phase de fabrication. La fin de vie d’un logiciel semble à première vue inexistante, ou du moins sans impact. Nous verrons plus loin qu’il n’en est rien en réalité. On devra intégrer la désinstallation des programmes et la destruction /récupération des données associées.
Comme proposé au sein du Green Patterns, le manuel de référence d’écoconception des logiciels par le Green Code Lab, on peut donc pour un logiciel simplifier ce cycle de vie en ne retenant que 4 phases: la fabrication, la distribution vers l’utilisateur final, l’utilisation, et la fin de vie/réutilisation/recyclage.

La fabrication

Ce processus de conception et de développement est considéré donc comme une phase unique permettant de produire le logiciel. Cette phase intègre tout le processus de conception du logiciel :

  • analyse des besoins,
  • conception,
  • programmation,
  • test,
  • stabilisation,
  • déploiement.

Les ressources associées aux maintenances correctives (correction de bug) et les enrichissements fonctionnels, sont à inclure dans cette phase.
Un logiciel est souvent et en partie constitué de composants tels que des frameworks, bibliothèques, librairies. Dans ce cas, on pourra considérer que la fabrication de ces composants a un impact négligeable au regard du nombre de copies (réutilisations) qui en sont effectuées.

La distribution/copie vers l’utilisateur final

Différents scénarios sont possibles, ici seuls 3 sont rapidement présentés (d’autres sont possibles).

  • Téléchargement : le logiciel ainsi que la documentation sont distribués par voie électronique. Il faudra ici prendre en compte le périmètre de l’émetteur du programme (serveurs de téléchargement) mais également le récepteur (les ordinateurs des utilisateurs finaux) ainsi que l’infrastructure qui a permis de véhiculer les fichiers électroniques (réseau, routeurs, …) en prenant une quote-part de la construction du matériel et de l’énergie nécessaire au téléchargement du logiciel en fonction de la ressource utilisée.
  • Le logiciel ainsi que la documentation sont packagés et envoyés par courrier postal, il faudra prendre en compte le support (CD-ROM, DVD, clef USB, documentation), l’emballage et le transport postal associé.
  • L’utilisateur peut récupérer la licence et la notice d’utilisation dans un commerce ou par courrier postal et télécharger le logiciel. Il faut donc prendre en compte l’étape de packaging (fabrication & transport) ainsi que le téléchargement du logiciel. Dans ce cas particulier, les impacts liés au déplacement de l’utilisateur peuvent être forts et peuvent écraser les autres impacts. Des ACV précédentes, menées par le groupe Orange sur des terminaux, mobiles, modem, CD-ROM, ont montré que les déplacements des client pouvaient être très variés et très impactants, notamment s’ils ont lieu en voiture (plusieurs kg de CO2e)

L’utilisation du logiciel par l’utilisateur final débute par la phase d’installation sur son matériel (mise en service) suite au téléchargement (distribution) par exemple et couvre toute la phase d’usage du logiciel sur le matériel adéquat de l’usager. Le périmètre intègre :

  • le matériel nécessaire ou prérequis pour utiliser le logiciel. Dans ce cas, on prend en compte la quote-part de :
    • la fabrication du matériel (l’équipement de l’utilisateur, accès réseau, accès serveur),
    • l’utilisation de l’énergie en phase d’usage du matériel (l’équipement de l’utilisateur avec éventuellement l’accès réseau et serveur) et qui peut intégrer par défaut la consommation des logiciels prérequis ;
    • les logiciels prérequis intégrant leurs consommations de ressources (OS, machines virtuelles, …). On peut isoler la consommation de ressources de ces logiciels prérequis en établissant une valeur étalon appelée « Idle » qui correspond à la consommation de ressources du matériel et de ses logiciels prérequis, avant toute exécution du logiciel étudié ; cette valeur peut-être décomposée en autant de valeurs si on souhaite isoler l’OS du navigateur par exemple ;
  • le logiciel étudié intégrant sa consommation d’énergie :
    • les données nécessaires pour utiliser le logiciel ou créées par le logiciel et stockées sur les différentes ressources de matériel de l’application ;
    • la consommation d’énergie associée à ces données est intégrée par défaut dans l’équipement.

Par exemple dans le cas d’une page Web, les prérequis matériels et logiciels pour afficher la page côté utilisateur sont : un ordinateur/tablette/smartphone, un OS (Android, Windows, iOS…), le navigateur (Firefox, Chrome, Edge, Safari…) et les plugins éventuels.

La fin de vie / réutilisation / recyclage

On fait l’hypothèse qu’en fin de vie un logiciel est effacé ou désinstallé côté usager / côté éditeur du logiciel. Il y a plusieurs points à prendre en compte pour cette étape : la fin de vie du matériel support et la fin de vie des données générées par le logiciel.

  • Fin de vie du matériel support : on revient ici à une problématique habituelle de fin de vie d’un support matériel électronique donc complexe et polluant, classé en DEEE (Déchet d’Équipement Électrique et Électronique)
  • Fin de vie des données : on pourra considérer la bonne désinstallation du logiciel selon une procédure qui supprime tous les fichiers de configuration sur le poste client. On doit prendre également en considération dans cette phase les données générées par le logiciel et qui ont été créées volontairement ou non par l’utilisateur. Plusieurs cas se présentent :
    • l’utilisateur ne souhaite pas récupérer les données qu’il a produites ;
    • l’utilisateur souhaite récupérer ces données pour les utiliser avec un autre outil comparable et un processus de conversion est prévu ; ce processus a été pris en compte dans ce nouvel outil dans le cadre de sa phase de fabrication ;
    • l’outil ne permet pas le processus de récupération et de conversion des données pour une nouvelle utilisation ; on devra alors estimer l’impact de la conversion pour l’utilisateur dans cette phase de fin de vie.

Pour terminer cette série sur l’ACV des logiciels, le prochain article du blog traitera de l’obsolescence programmée des logiciels. En effet, la phase de fin de vie d’un logiciel étant difficile à appréhender, cela fera l’objet d’un article dédié

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Écoconception des logiciels : Spécificités des produits logiciels

Reading Time: 4 minutes

L’objectif de cet article est de présenter les caractéristiques propres aux logiciels lors d’une analyse de cycle de vie (ACV). Pour chacun des problèmes que soulèvent ces spécificités, nous indiquerons l’approche que nous recommandons pour l’évaluation des impacts environnementaux.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réelle sur l’évaluation des impacts environnementaux d’une application disponible en téléchargement ici.

Logiciel : bien matériel ou immatériel ?

Le logiciel est un bien particulier :

• Il ne génère pas de déchet physique direct

• Il n’est pas directement branché à une source d’alimentation et n’est donc pas perçu comme « consommateur ».

• Il a néanmoins un impact sur l’environnement à travers une consommation de ressources et d’énergie due au matériel nécessaire à son développement et à son utilisation.

L’ACV a pour but d’évaluer les impacts environnementaux de biens manufacturés, services et procédés. Mais où se situent les logiciels parmi ces trois types de produits ?

À première vue, les logiciels s’apparentent fortement à des biens matériels tels que ceux créés par l’industrie traditionnelle puisqu’ils sont matérialisés par un ensemble de données informatiques (code source et / ou exécutable) que l’on peut échanger, posséder et utiliser pour satisfaire un besoin précis. Mais il faut bien distinguer le support de stockage et les interfaces physiques d’interaction du logiciel lui-même : le logiciel n’est en réalité rien de plus qu’un état du support de stockage (constitué par une suite bien définie et unique de 0 et de 1), un état du réseau transportant ces données, un ensemble d’états de l’écran affichant la représentation graphique du logiciel, etc. Devrions-nous donc considérer le logiciel plutôt comme un bien « immatériel » ?

Pour répondre à ces questions, il convient de bien faire la distinction entre le logiciel lui-même et le service qu’il rend. Ainsi, on peut effectivement considérer un logiciel comme un bien immatériel qui rend un ou plusieurs services particuliers (ses fonctionnalités ou contenus). En tant que bien immatériel, ses impacts environnementaux résulteront de l’utilisation de ressources (humaines, physiques/matériels…) nécessaires à la mise en œuvre des différentes phases de son cycle de vie : fabrication/développement, fonctionnement, distribution, fin de vie.

Faut-il isoler un logiciel de son environnement de fonctionnement ?

Il est évident qu’un logiciel ne fonctionne jamais seul, mais toujours dans un écosystème avec d’autres logiciels dont il dépend, à commencer par l’OS (système d’exploitation), ou avec lesquels il est en communication ou en interaction. Ainsi, mesurer les impacts générés par le seul logiciel étudié en phase d’utilisation est compliqué.

L’impact du logiciel est indissociable du matériel et de l’OS avec lequel il fonctionne : il n’est pas possible lors d’une ACV d’identifier directement les impacts environnementaux liés à l’OS ou au matériel. Ces impacts peuvent malgré tout être obtenus au travers d’ACV comparatives, c’est-à-dire en comparant par exemple les ACV de deux configurations bien spécifiques : par exemple Logiciel A sur équipement X avec OS1 versus Logiciel A sur équipement X avec OS2 ; c’est ainsi qu’il sera possible d’identifier le delta d’impacts entre les OS1 et OS2. D’autres analyses de sensibilité permettraient d’évaluer les deltas d’impact liés aux différents matériels par exemple.

Un équipement informatique ne fonctionne pas uniquement pour le logiciel étudié. Généralement d’autres applications/logiciels fonctionnent en parallèle sur le même équipement et donc consomment des ressources. Aussi la totalité de la puissance consommée par l’équipement ne peut pas être attribué au logiciel considéré. La stratégie prise dans le cadre du projet de recherche Web Energy Archive pour attribuer au logiciel l’énergie qu’il consomme, est de retrancher la consommation d’énergie due à l’OS et aux services tels que l’antivirus (on parle de consommation en mode idle), à la consommation totale de l’équipement.

Logiciel : quel périmètre considérer?

L’une des principales difficultés à laquelle on se heurte lorsque l’on réfléchit à l’évaluation des impacts environnementaux d’un logiciel est que ce dernier évolue régulièrement au travers des différentes versions (correctrices ou fonctionnelles) et peut avoir une architecture modulaire, voire fonctionner simultanément sur différents équipements.

Un logiciel évolue sans cesse.

Un logiciel se décline la plupart du temps en une multitude de versions et sous-versions qui comprennent des ensembles de fonctionnalités différents. On peut être tenté de dire que cela ne pose pas de problème majeur car les versions sont très espacées dans le temps… mais c’est rarement le cas. Suite à la sortie par un éditeur d’une « release » officielle de version bien identifiée, le logiciel peut très rapidement faire l’objet de patchs correctifs ou de modules complémentaires qui peuvent devenir très nombreux et fréquents. Cette approche de releases fréquentes s’est nettement accentuée ces dernières années.

Il faut donc différencier les évolutions mineures, des évolutions majeures d’un logiciel :

• Les évolutions majeures apportent de nouvelles fonctionnalités, voire restructurent complètement une application.

• Les évolutions mineures apportent principalement des corrections de bugs ou des ajouts de fonctionnalités secondaires.

Puisqu’il est difficile de parler de version « finie » d’un logiciel, nous proposons de limiter l’étude à la « dernière version stable la plus largement diffusée et utilisée ». Quoiqu’il en soit, la version étudiée devra figurer clairement dans les hypothèses de l’étude.
L’impact des versions correctives et/ou fonctionnelles, qu’elles soient mineures ou majeures ne pourra être pris en compte qu’au travers d’une analyse de sensibilité. C’est-à-dire que l’on modélisera l’impact d’une correction de bug et une évolution fonctionnelle par l’ajout de ressources supplémentaires (RH, consommation de papier, matériel…) lors de la phase de fabrication/développement ou au travers d’une nouvelle phase spécifique (maintenance).

Un logiciel est souvent modulaire.

Un logiciel peut être lui-même découpé en plusieurs modules que l’on peut choisir d’installer ou non, ou bien il peut offrir la possibilité d’être étendu par des plugins ou add-ons (comme la plupart des navigateurs web par exemple).
La notion de modularité d’un logiciel ne pourra pas être modélisée comme telle au travers d’une ACV, car il sera difficile voire impossible d’identifier les ressources spécifiques nécessaires au développement de tels ou tels module. Il faudra donc considérer la configuration la plus standard possible, puis des analyses de sensibilité pourront être faites pour évaluer les impacts liés à des ressources nécessaires pour le développement de modules particuliers (RH, matériels…).

Pour poursuivre cette série sur l’ACV des logiciels, nous traiterons dans le prochain article du blog du cycle de vie. En effet, ci celui-ci est pertinent pour un produit matériel usuel, il l’est beaucoup moins pour un logiciel et nous découvrirons pourquoi.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Écoconception des logiciels : pourquoi réaliser une ACV des logiciels ?

Reading Time: 5 minutes

L’écoconception, qui consiste à tenir compte des impacts environnementaux et sanitaires lors de la conception ou l’amélioration d’un produit (bien ou service), s’impose progressivement dans tous les secteurs économiques comme une démarche créatrice de valeur. Ceci parce que les entreprises sont de plus en plus sensibles à la responsabilité qu’elles ont vis-à-vis de notre planète et des générations futures, mais surtout parce qu’elles prennent conscience des multiples bénéfices qu’elles peuvent tirer de la mise en œuvre d’une telle démarche.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Pourquoi réaliser une analyse du cycle de vie des logiciels ?

Il est cependant un domaine où l’écoconception n’en est qu’à ses balbutiements : il s’agit du monde du logiciel, dans lequel la plupart des méthodes et bonnes pratiques en la matière sont encore à inventer. Pourtant, comme dans tous les autres secteurs économiques, les avantages que peuvent en retirer les différents acteurs du monde du logiciel sont nombreux :

Réduction des coûts

En veillant à réduire les ressources ou matières premières nécessaires à la fabrication d’un produit, l’écoconception permet du même coup de réduire les coûts de fabrication. Cela est bien entendu aussi valable pour un logiciel : dans la phase de production d’un logiciel, réduire les fonctionnalités à développer, le nombre de postes de travail à déployer, le nombre d’impressions qui seront générées, la quantité d’énergie nécessaire à son fonctionnement, sont autant de moyens de réduire les pollutions engendrées par cette activité mais également de réduire les coûts de fabrication du logiciel.

Anticipation des réglementations environnementales

De plus en plus de normes sont imposées aux entreprises pour rendre les produits et l’économie en général plus vertueux au plan environnemental. On pense par exemple aux directives qui visent les Equipements Electriques et Électroniques (EEE) RoHS et WEEE, REACH ou ErP visant à rendre les produits moins polluants. Mais également aux tentatives actuelles ou à venir des pouvoirs publics d’intégrer à notre économie les coûts de la dégradation de l’environnement qui ne sont pas aujourd’hui assumés par les entreprises (externalités négatives) : droits d’émission de CO2, taxe carbone etc. Face à l’arrivée de ces nouvelles réglementations, nul ne doute que les entreprises ayant déjà mûri la problématique de l’écoconception en tireront un avantage concurrentiel.

Différenciation du produit :

Éco-concevoir, c’est aussi créer un produit de meilleure qualité, plus robuste, plus durable et plus économe pour l’utilisateur, puisque ces qualités sont intimement liées à la réduction de l’impact du produit sur l’environnement et/ou à l’allongement de sa durée de vie active. L’utilisateur y trouve alors son compte. La consommation d’énergie est par exemple un souci bien réel pour le responsable d’un datacenter, qui verra ainsi un logiciel moins consommateur d’électricité avec un œil plus favorable, surtout à l’ère où les « opérateurs Cloud » fleurissent et ont intérêt à optimiser l’utilisation de leurs ressources. De même, l’autonomie des plates-formes mobiles est un enjeu essentiel pour les fabricants et utilisateurs de smartphones et tablettes, et les consommations de batterie engendrée par le logiciel est à prendre en compte.

Facteur d’innovation :

Le ministère de l’écologie, du développement durable et de l’environnement affirme sur son site web : « L’écoconception est un aiguillon pour l’innovation, aussi bien en ce qui concerne la fonction du produit que les différentes étapes de son cycle de vie. Un regard nouveau pour optimiser les consommations (matière et énergie) et pour réduire les pollutions débouche parfois sur des idées entièrement nouvelles sur les composants du produit, son fonctionnement ou les technologies auxquelles il fait appel. ». Ce constat est valable aussi bien pour les logiciels que pour tout autre type de produit.

Image de l’entreprise :

A une époque où les consommateurs sont de plus en plus attentifs à la responsabilité sociale et environnementale des entreprises, s’engager activement à appliquer les principes d’écoconception des logiciels bénéficie sans aucun doute à l’image et au prestige de l’entreprise, avec des avantages en termes de retombées économiques.

C’est forts de ces constats qu’un groupe d’experts en « Green IT » a fondé le Green Code Lab dont le but est de promouvoir l’écoconception des logiciels et de proposer des outils et méthodes pour aider à sa mise en œuvre. Dans le cadre de la collaboration d’Orange avec GREENSPECTOR, lauréat d’un appel à projet ADEME sur l’écoconception des logiciels, les 2 organisations ont apporté leurs expertises respectives pour poursuivre les travaux, objet du [Guide Méthodologique de l’ACV des logiciels](lien vers le guide). La méthodologie que nous proposons ici pour réaliser une Analyse de Cycle de Vie (ACV) de logiciel s’inscrit pleinement dans un objectif de définition d’une méthodologie à diffuser largement pour initier de futures démarches d’évaluation des impacts de logiciels.
L’ACV est en effet un outil central et incontournable de l’écoconception des logiciels. Il s’agit d’une méthodologie standardisée ([ISO14040]( https://www.iso.org/fr/standard/37456.html) et ISO14044 notamment) qui permet d’évaluer les impacts environnementaux de biens manufacturés, services et procédés, ceci de façon globale et complète. Etudier les pollutions générées à toutes les étapes du cycle de vie d’un produit (conception, fabrication, utilisation, fin de vie), permet de n’en oublier aucune et de mettre en évidence la phase du cycle de vie la plus polluante (là où il faudrait porter l’effort prioritaire). Cet effort sera fonction des décisions de l’entreprise et de ses choix & contraintes stratégiques. Cette vision de toutes les phases permet de s’assurer aussi qu’une solution réduisant l’impact sur l’environnement à une étape ne va pas en générer un plus important à une autre étape du cycle de vie (pour éviter des transferts d’impact et/ou de pollution).
L’objet du [Guide Méthodologique de l’ACV des logiciels](lien vers le guide) est donc de proposer une méthodologie pour réaliser l’ACV d’un logiciel. Définir une méthodologie commune à cette catégorie de produits se justifie par le fait que les logiciels, souvent considérés à tort comme immatériels, présentent des spécificités par rapport aux produits dits « matériels ». Cette immatérialité soulève des questions quant à la meilleure façon de réaliser une telle analyse sur un logiciel.
Notons que l’aspect social, qui est l’un des 3 piliers du développement durable et auquel Green Code Lab prête également une attention particulière, n’est pas traité directement dans ce document (autrement qu’en termes d’impacts sanitaires indirects). Néanmoins, des méthodologies d’ACV sociales existent et dans une large mesure, ce qui est dit ici est tout à fait applicable et transposable à une analyse des impacts sociaux et sociétaux.

Quels objectifs pour une ACV des logiciels ?

Comme nous le verrons plus en détails dans le Guide Méthodologique de l’ACV des logiciels , la première étape d’une ACV des logiciels est la définition des objectifs et du champ de l’étude. C’est une étape essentielle car elle va déterminer de nombreux choix dans la façon de réaliser les étapes suivantes de l’étude, mais également le résultat même de l’étude. C’est pourquoi les ACVs sont dites « goal dependent ». Pour un logiciel, on peut identifier plusieurs objectifs:

  • Etudier les impacts environnementaux d’un logiciel donné (déjà réalisé) : consommation de ressources non renouvelables, d’énergie et émissions de polluants (chimiques ou particules) dans l’eau, l’air et les sols.
  • Déterminer les phases les plus impactantes de son cycle de vie fabrication/développement, utilisation, transport, fin de vie. Ce type d’étude pourra se restreindre à des catégories de logiciels (logiciels de messagerie, traitements de texte, CMS, page web…)
  • Identifier les opportunités d’amélioration et de réduction des impacts sur l’environnement pour de futurs produits. Cet objectif intéressera particulièrement les éditeurs et autres créateurs de logiciels soucieux d’améliorer la qualité environnementale de leurs produits.
  • Comparer les impacts environnementaux de plusieurs produits ou solutions logiciels afin de choisir celui ayant le moindre impact environnemental. Les utilisateurs (DSI, particuliers etc.) ou les développeurs / intégrateurs confrontés à des choix technologiques pourront ainsi utiliser cet outil. Dans le cadre d’une ACV comparée (évolution d’un logiciel ou nouveau produit), seules seront calculées les phases qui diffèrent entre les deux produits / services à comparer. La comparaison entre deux ACV est toujours risquée. Pour être crédible celle-ci devra se faire avec le même logiciel, à la même date, avec les mêmes règles de cut-off et de préférence avec le même praticien.

Comme toute ACV de produit et de service, pour être publiée, l’ACV d’un logiciel doit faire l’objet d’une revue critique indépendante. Découvrez quelles sont les spécificités et caractéristiques des produits logiciels dans un prochain article sur le blog.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

L’écoconception des logiciels : vers une sobriété « heureuse » du numérique

Reading Time: 6 minutes

Le numérique explose ! Nous consommons de plus en plus de services et d’informations via des formats numériques à tout moment dans tous lieux. Ces services et contenus sont de plus en plus nombreux et volumineux. La consommation de ressources qui résulte de cette omniprésence explose non seulement dans les datacenters, mais aussi de manière plus insidieuse et encore plus conséquente dans tous nos matériels déployés comme les ordinateurs, tablettes, smartphones, box, objets connectés … L’université de Dresde a ainsi estimé qu’en 2030, l’internet au sens large consommerait autant d’électricité que toute l’humanité en 2008 !

L’évolution la plus emblématique du numérique est à la fois la masse de données que nous produisons et conservons à chaque instant, mais également la miniaturisation des matériels permettant l’accès aux informations et services correspondants. Pour cela, nous avons continuellement besoin d’embarquer de plus en plus d’intelligence dans un matériel de plus en plus petit. Une telle évolution n’est soutenable que si nous avons recours à de nouvelles optimisations : les composants, les batteries, le refroidissement dans les datacenters,… mais aussi dorénavant le logiciel qu’on y insère ! Car l’entropie naturelle du logiciel existe bel et bien, et on parle d’ « OBÉSICIEL » !

Le phénomène d’ « obésiciel »

En effet, aujourd’hui on ne forme plus nos développeurs à faire attention à la ressource utilisée ; ni à l’école, ni en entreprise. L’objectif principal des équipes de développement est de délivrer dans un planning prédéterminé les fonctionnalités attendues (c’est déjà bien !). Pour être productif, on assemble, on intègre et on réutilise des bibliothèques existantes.

In fine, face à un logiciel trop lent, on choisit toujours d’ajouter de la puissance matérielle pour combler des lacunes d’efficience logicielle… Car rien n’est mesuré tout au long du cycle de développement, ce qui permettrait au moins de réagir suffisamment tôt pour que le coût de la correction ne soit pas rédhibitoire. Cet ajout matériel se fait au détriment des coûts, de l’autonomie, de l’écologie et finalement du bon sens.
Il est même possible d’avoir une lecture globale de ce sujet : c’est une forme de relocalisation du numérique, quand investir dans l’efficience logicielle localement permet de réduire le coût des matériels produits au bout du monde dans des conditions sociales, sanitaires et environnementales pas toujours acceptables par ailleurs.

Le projet Code Vert est né !

En tant qu’entreprise engagée dans un numérique plus vertueux, nous avions eu une intuition : en appliquant les principes de l’écoconception au process de « fabrication » d’un logiciel, il devrait être possible de réduire les consommations de ressources et d’énergie lorsque ce logiciel est utilisé. Encore fallait-il valider cette intuition, et c’est ce que nous avons fait dans le cadre du projet « Code Vert ».

Ce projet, lancé en 2012 a duré 30 mois. Il nous a permis de valider les gains liés à une meilleure utilisation des instructions de code dans un programme informatique (bonne pratiques « vertes » ou « Green Patterns »), et en même temps nous avons pu commencer à préciser les contours de la solution GREENSPECTOR destinée à accompagner le développeur dans sa mise en œuvre concrète de l’écoconception du logiciel. Depuis lors, nous avons étoffé l‘outil avec des capacités de mesure des consommations énergétiques, qui permettent à la fois de montrer les gains réels au développeur (rien de tel pour piloter des progrès que de mesurer ses résultats !), allant ainsi au-delà de l’application « théorique » d’une bonne pratique ; mais aussi de détecter des surconsommations impossibles à percevoir en analysant seulement le code source.

L’engagement des sociétés pour l’écoconception des logiciels

Quel intérêt pour une entreprise à s’engager dans cette voix de la sobriété logicielle ? Les exemples commencent aujourd’hui à se multiplier, et bientôt l’écoconception numérique aura vocation à être rangée dans les bonnes habitudes de travail de toute équipe de développement. Ainsi, Facebook aurait-il trouvé un modèle économique viable, il y a quelques années, s’il n’avait pas divisé par 2 la consommation électrique de ses serveurs, grâce à la mise en œuvre d’une stratégie d’optimisation logicielle lui évitant de construire un nouveau datacenter ?

Ou plus récemment sur son application mobile Facebook Light, destinée aux marchés émergents grâce à la réduction à la fois du volume de données échangées et de l’énergie (donc la batterie) consommée ? Plus près de nous, on commence à voir dans les appels d’offre numériques des grands groupes français des critères d’éco-responsabilité numérique, voire des référentiels de bonnes pratiques comme en entrant du marché.

Les enjeux et gains de l’écoconception des logiciels

Dans un monde où il est aujourd’hui inenvisageable (qui sait, cela changera peut-être un jour) de modérer à bon escient l’usage de nos mobiles, cette démarche répond finalement à une demande pressante du consommateur final que nous sommes tous : l’autonomie de nos matériels mobiles, embarqués, connectés que nous emmenons partout ! L’autonomie est en effet un des tout premiers critères de choix du smartphone. Les derniers arguments des constructeurs début 2017 mettent l’accent sur l’autonomie « la meilleure du marché » de leur dernier mobile. Ici, pas question de gagner de l’argent pour l’usager mais de gagner en mobilité, en productivité, en utilisabilité, bref en expérience utilisateur. L’optimisation du logiciel devient alors un rouage essentiel dans cette quête d’autonomie pour les constructeurs qui souhaitent prendre des parts de marché.

D’autres gains sont encore plus intéressants dans le domaine des objets connectés. L’écoconception des logiciels permet ici de réduire la fréquence de maintenance, d’augmenter la longévité d’un matériel déployé (parfois gourmand en ressources rares) avec un niveau de service supérieur. Le premier service qu’on peut rendre dans ce domaine de l’IoT est de connaître le profil de consommation électrique de l’objet, sur la base de l’usage réel (et non des données constructeur, quand il y en a…) pour l’intégrer de manière concrète dans le modèle économique de la solution. Cela passe obligatoirement par la mesure des ressources (énergie, data, mémoire, …) en fonctionnement réel. Au final, quelle que soit la motivation, on visera un service au moins aussi performant pour son utilisateur, pour un coût d’exploitation moindre, tout en limitant le stress lié aux besoins en énergie et en ressources – trop peu souvent renouvelables.

Ceux qui n’ont pas de gains visibles ou conséquents en regard des coûts potentiels de mise en œuvre pour appliquer cette écoconception numérique, peuvent désormais aussi se conformer à un référentiel de bonnes pratiques Green dans le web pour le moment pour communiquer sur une exemplarité et encourager leur « écosystème ». Nantes Métropole a été la première collectivité à labelliser son site internet dédié à la transition énergétique, afin de communiquer publiquement sur son intérêt pour cette démarche d’écoresponsabilité très concrète des sites web.

Les bonnes pratiques en matière d’écoconception des logiciels !

Comment avons-nous réussi à établir les bases d’une bonne pratique d’efficience de conception et de développement ? Dans le cadre du projet Web Energy Archive, l’association Green Code Lab a mesuré la consommation énergétique de plus de 700 sites web. Elle a pu observer qu’il y avait une corrélation entre la consommation de ressources et la complexité du site (scripts, nombre de requêtes incluses dans la page…). Elle a aussi effectué d’autres observations , qui ont notamment permis de montrer que la consommation moyenne d’une page dans un onglet minimisé, c’est à dire non affiché à l’écran et pas en interaction avec lui, représente 1 Watt de puissance appelée en moyenne sur un poste de travail qui pourtant n’affiche pas cette page (ce qui n’inclut même pas la consommation des requêtes envoyées aux serveurs et alimentant le trafic dans le réseau !). Éviter une telle consommation inutile peut pourtant se faire facilement, en demandant au développeur de prévoir un arrêt des traitements quand l’onglet du navigateur n’est pas visualisé par l’utilisateur.

En 2017, plus de 50 % des accès aux services et informations du Web se font sur appareil mobile, sous contrainte de réseau, de batterie du smartphones, de forfait data parfois limité… De quoi renforcer l’intérêt pour un éditeur de contenus web de faire attention à ses pages sous peine de perdre en route des « consommateurs » en quête d’instantanéité.
Les entreprises commencent ainsi timidement à intégrer cette démarche dans leur usine logicielle avec des gains intéressants qu’elles avaient oubliés ces dernières années. Dans la « digital factory » ou la « mobile factory », l’enjeu est de ne pas manquer la transformation numérique de l’organisation, en fournissant une expérience utilisateur sans faille, (traduire la performance et productivité en mobilité) clé dans la réussite du projet.

Conclusion

Mais rêvons un peu. Ne serait-il pas possible de pousser la logique plus loin, en essayant de « sauver la planète » du danger que le numérique dispendieux non contrôlé lui fait courir ? De quoi redonner du sens au travail du développeur, qui peut ainsi trouver enfin un moyen d’agir et d’œuvrer concrètement à son niveau pour limiter l’impact écologique de sa production, via son travail au quotidien. Un moyen de revaloriser le travail du « pisseur de code » déresponsabilisé et démoralisé ?

Certes, il est vrai que revoir tout le patrimoine applicatif d’une organisation pour réaliser une rétro-écoconception n’a pas toujours de sens économique à court terme. Mais l’histoire numérique ne fait que commencer, et les chapitres que nous allons désormais écrire seront bien plus nombreux que les chapitres déjà écrits. Parions que les entreprises n’auront pas d’autre choix que d’intégrer, pour être “compétitives” dans un monde aux ressources limitées, cette nouvelle dimension de frugalité chez les donneurs d’ordre et chez les maîtres d’œuvre numériques. Comme le propose Pierre Rabhi plus largement dans son ouvrage, on se dirigera alors vers une sobriété « heureuse » aussi pour le numérique !

Power Test Cloud, ou comment un non-expert peut mesurer la consommation énergétique de son application web ou mobile

Reading Time: 4 minutes

Vous êtes Développeur Android ? Web Designer ? Ou non développeuse comme moi ?
Savez-vous combien d’énergie est consommée par votre site web ou votre application mobile ? Et surtout, savez-vous comment les optimiser pour gagner en efficience ?
GREENSPECTOR intègre la fonctionnalité qui vous permet en quelques clics de lancer un test, de mesurer la consommation d’énergie et ainsi d’auditer votre application : le Power Test Cloud.

Continue reading “Power Test Cloud, ou comment un non-expert peut mesurer la consommation énergétique de son application web ou mobile”