L'éco-design avec GreenSpector

En 2030, le fonctionnement d’Internet dépensera à lui seul la même quantité d’énergie que toute la consommation mondiale, toutes activités confondues, de 2008. De 5% de la quantité totale produite en 2016, Internet consommera en 2030, plus de 20% de la production mondiale.

Bien que le logiciel soit une ressource immatérielle, de nombreux équipements électroniques sont nécessaires pour son fonctionnement. La fabrication, l’utilisation et le recyclage de ces derniers ont un impact négatif direct sur l’environnement.

Réduire les besoins en ressources matérielles des logiciels, tous supports confondus, est donc une obligation pour diminuer leur consommation énergétique notamment leur besoin en électricité. Les effets bénéfiques collatéraux de ces changements entraineront la réduction des émissions de gaz à effet de serre et permettront d’allonger leur durée de vie active.

C’est le premier objectif du mouvement Greent IT : diminuer l’empreinte écologique des supports informatiques, et à ce titre, celle amenée par la couche logicielle. Il s’agit de l’éco-design (ou éco conception) des logiciels.

Mais alors, comment mesurer la consommation de nos applications ? Et surtout, comment la réduire ? Dans quelle mesure un logiciel est-il énergivore ?

Il existe peu d’outils sur le marché capable d’évaluer et d’analyser la consommation électrique des logiciels, dont GreenSpector, éditée par la société du même nom et leader en France de ce marché. Après nous être rapprochés, nous avons décidé d’évaluer l’outil dans sa capacité à mesurer l’efficience de nos produits immatériels.

Notre cas concret concerne une application Android de transport en commun. Dans un premier temps pour évaluer son efficience suivant les différents scénarios fonctionnels, mais aussi pour essayer d’améliorer cette efficience en suivant les recommandations proposées.

Identifier et suivre sa consommation de ressource

 Notre point d’entrée dans la mesure est le « testrunner », solution fournie dans le package GreenSpector, qui permet d’effectuer des tests de base (lancement de l’application, mise en arrière-plan, etc…) sur une application de manière très rapide.

Le résultat obtenu permet d’obtenir plusieurs constats et métriques : autonomie, des violations sur le dépassement de seuil… Ces résultats sont encore plus pertinents s’ils sont comparés avec une autre version de la même application ou a une autre application (de préférence, équivalente).

testrunner

Dans l’approche fonctionnelle, grâce à la sonde GreenSpector et aux outils d’automatisations de tests Android, nous mettons en place différents scénarios d’exécution. Ceux-ci correspondent aux parcours classiques des utilisateurs sur notre application de transport en commun (consultation d’horaires, info trafic, etc…).

Cette analyse nous permet d’identifier le, ou les, cas d’utilisations qui utilisent le plus de ressources, et donc de focaliser nos efforts de correction.

Dans cet exemple, c’est le « compostage d’un ticket » qui sollicite le plus l’appareil (colonne Charge Plateforme)

compostage d'un ticket

En parallèle de la consommation énergétique (décharge, utilisation du processeur, etc…) l’outil nous permet également d’estimer le volume de données transitant pour chaque scénario. Cette information, qui n’est pas forcément liée aux mesures énergétiques (dans notre exemple, c’est l’ouverture une fiche info trafic qui va faire transiter le plus de données), va nous offrir une seconde piste d’optimisation.

volume de données

L’outil GreenSpector nous permet d’obtenir des informations détaillées sur la consommation énergétique de notre application, selon des cas de test précis. Mais il nous offre aussi une vision d’ensemble de l’application, en mutualisant les résultats des tests de mesures sur nos scénarios, et ceux de l’analyse du code source. Cette synthèse nous est présentée par le biais de différentes notes sur le tableau de bord, notamment l’éco-score.

informations consommation énergétique

L’éco-score est une note globale qui évalue l’application en se basant sur la conformité relative à des règles d’efficience. Elle est divisible par domaine d’impact : réseau, ressources et code. Comme les autres informations, son évaluation doit se faire en référence avec celle des autres applications. Dans l’approche fonctionnelle, c’est surtout les résultats par scénarios qui vont nous intéresser, et nous donner des pistes d’amélioration.

Les recommandations pour « verdir » son code  

L’analyse statique du code source met en avant des pratiques de codage sur-consommatrices de ressources. Dans notre cas d’étude, un ensemble d’améliorations est ainsi proposé :

analyse statique du code source

Les règles à suivre concernent différents aspects (HTTP, HTML, CSS, JavaScript, PHP, C, Java, Android, GWT, … ) et pour chacune l’interface décrit très clairement la problématique et une solution complète avec un   exemple de code. GreenSpector ayant mesuré la pertinence de chacune de ses règles, il nous donne aussi les règles prioritaires ainsi qu’une indication des gains et difficultés attendues :

indication des gains énergetiques et difficultés attendues

Enfin les mesures des sondes permettent de vérifier l’impact réel des corrections sur l’efficience de  :

les mesures des sondes

Notre appréciation de GreenSpector

Cette mise en situation de l’outil, nous permet de dresser un constat des aspects positifs et négatifs.

Positifs

  • Stabilité de l’outil
  • Documentation claire et bien fournie
  • Installation et configuration simples et guidées
  • Visualisation des tendances et évolutions entre versions

Négatifs

  • Amélioration de l’efficacité énergétique du code très relative sur notre application de test avec l’approche appliquée lors de l’évaluation (uniquement analyse statique et pas recherche des points consommateurs)
  • Certaines règles de développement non pertinentes pour Android (trop proches des profils Sonar Java)
  • Manque de mesure des problématiques de Wake lock (Services, Alarmes, Scheduler) qui deviennent prépondérantes, notamment avec Android 7
  • Conditions de mesures pénalisantes (nombres d’OS / Constructeurs et matériels limités et faibles)
  • Intégration dans l’IDE assez faible (pas de Hint, mais des résultats intégrés a posteriori)
  • Pas de mode projet avec la notion de groupes d’utilisateurs pour le travail en équipe

Sachez-le : cette solution n’est ni open-source, ni gratuite, encore jeune et donc est amenée à évoluer avec les retours des utilisateurs. Ainsi, l’un des freins que nous avons identifiés est la capacité de la solution à intégrer suffisamment de données de références et d’outillages pour toutes les combinaisons de matériel, os et sur couches constructeurs du marché. La fragmentation Android n’aidant pas sur ce point !

Pour répondre à cette problématique, les équipes de GreenSpector vont proposer un banc de test accessible en SaaS (actuellement en béta) à l’instar de solutions telles que GeekBench, banc de test de performances utilisé par quelques grands constructeurs.

De nouveaux défis à intégrer

Dans l’éco-conception, la mesure et son suivi sont primordiaux mais s’avèrent complexes à mettre en œuvre. Celle-ci nécessite en effet une grande rigueur pour être fiable (tests automatisés, sondes étalonnées, environnement maitrisé…). Pour Android, la solution de banc de mesure accessible en SAAS prévu par GreenSpector nous parait donc la bienvenue.

Cette démarche permet de répondre aux attentes des utilisateurs qui souhaitent voir améliorée la rapidité, fluidité et l’autonomie de leur SmartPhone. En revanche, au travers de cette étude concrète elle révèle également qu’elle peut aussi aller à l’encontre de la maintenabilité et engendrer des couts de développements et de tests non négligeables.

La force de GreenSpector est d’arriver à valoriser et matérialiser au travers de l’éco-score les efforts de la DSI dans ce domaine et ainsi identifier le respect de ses engagements RSE (Responsabilité Sociale et Environnementale des Entreprises).

En conclusion, les enjeux relatifs à l’écoconception logicielle doivent être abordés au plus tôt dans la définition du produit et dans la chaine d’intégration continue ce qui permettra d’améliorer l’efficience globale de l’application à moindre coût, de manière progressive, didactique et continue.

La problématique est sans nul doute à adresser et à piloter par les grandes DSI qui seront confrontées dans les 10 ans à venir à un nouveau défi économique et technologique lié aux dépenses d’énergie.

 

 

1 réponse
  1. Frédéric Bordage dit :

    Il est étonnant que vous ne citiez pas les outils de la communauté française. Depuis 2011, plus de 70 organisations ont regroupés leurs efforts pour proposer des outils opérationnels, gratuits, ouverts, et construits en commun. Voir https://collectif.greenit.fr/outils.html.

    Notamment, notre référentiel de 115 bonnes pratiques web et la méthode d’évaluation associée existent depuis 2011 et sont disponibles depuis 2012. La seconde édition de ces outils a été mise au point par les meilleurs experts du sujet en France (plus de 40 entreprises) avec la contribution et le soutien de l’Ademe, Cigref, Afdel, etc. Il me semble préférable pour vous et vos clients de vous appuyer sur le référentiel et sur la méthode d’évaluation de référence plutôt que sur un outil propriétaire que personne n’utilise…

    La communauté française propose en plus des outils en ligne tels que http://www.ecoindex.fr et http://www.ecometer.org.

    Répondre

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

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

Inscription newsletter

Ne manquez plus nos derniers articles !