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.
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.
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é
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.
Après Avocado et Broccoli, voici Cucumber ! L’équipe de GREENSPECTOR travaille dur pour vous fournir un outil toujours plus intéressant et complet et c’est avec fierté que nous annonçons la sortie de la nouvelle Release 1.12.0 Cucumber ! Ci-dessous se trouve le détail des features implémentées et mises à jour dans la toute dernière version.
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.
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.
Après la sortie de la version 1.10.0 Avocado le mois dernier, l’équipe de GREENSPECTOR est fière de vous annoncer que sa nouvelle Release est prête ! Découvrez ci-dessous les détails concernant les features mises à jour dans la toute dernière version : 1.11.0 Broccoli.
Le protocole HTTP 1.1 a été mis en place il y a 20 ans. Avec ce protocole basé sur le texte, l’inconvénient principal en termes de performance et efficience est la latence. Chaque fois qu’un élément est demandé par la page web (comme des images, une fonction JavaScript…), une connexion TCP se lance avec le serveur, avec parfois des latences, en fonction du réseau (qui se joue en fonction de nombreux paramètres, notamment la distance entre l’utilisateur et le serveur web).
Cet effet est renforcé par le fait que les navigateurs plafonnent le nombre de connexions simultanées, habituellement à un maximum de cinq. Le protocoleHTTP2 – sorti en milieu d’année 2015 – présente des améliorations, notamment sur ce souci de latence. Comment cela se présente-t-il ? En diffusant et multiplexant des trames binaires plutôt que de gérer des éléments textes. Maintenant, il n’y a plus qu’une seule connexion TCP et les téléchargements se font en parallèle. Nous obtenons donc un résultat sans plus aucun overhead lié aux négociations TLS.
Il est maintenant clair que HTTP2 améliore la performance de sites et applications web. Mais qu’en est-il de l’efficience énergétique ? En effet, meilleure performance n’est pas forcément synonyme de meilleure efficacité et c’est ce que je voulais vérifier. Allez, regardons ça !
Mettre en place un serveur HTTP2 avec @Golang est relativement simple. Un démonstrateur public permet de tester la mise en œuvre et la performance. Pour faire cela, une image composée de 180 carreaux est en place et peut être vue de plusieurs manières différentes, illustrant les différents paramètres de latence :
J’ai mesuré la consommation énergétique nécessaire pour afficher cette page web sur un smartphone Nexus 6, et voici les résultats que j’ai eus :
Nous pouvons y voir que, pour les mêmes valeurs de latence (0s, 30ms, 200ms, 1s), le HTTP2 est plus efficienten termes d’énergie, avec environ 8% de consommation énergétique en moins.
Cette capture écran de GREENSPECTOR montre les différences entre HTTP1 et HTTP2 dans le cas de scenarios de latence d’une seconde. Vous noterez aussi le gain de 8.3% de déchargement de la plateforme à la seconde (Platform Discharge per second).
De plus, quand la latence augmente, HTTP2 permet l’absorption de davantage de perte de performance :
Pour HTTP1 : 4,13 mAh à 4,26 mAh (+3%) quand la latence passe de 0s à 1s
Pour HTTP2 : 4,28 mAh à 4,57 mAh (+6%) quand la latence passe de 0s à 1s
CONCLUSION
En conclusion, HTTP2peut en effet améliorerl’efficacité énergétique d’un site web du côté du client. En tant que propriétaire de site internet, c’est une bonne chose que de faire ça, cela préserve la batterie de vos utilisateurs. Mais il y a encore mieux ! Vu que HTTP2 groupe les requêtes, le serveur est chargé pendant une période de temps réduite : et donc, les ressources du serveur sont libérés plus tôt et donc disponibles plus rapidement pour les autres utilisateurs.
Terminons avec une mise en garde pour ce cas d’usage : cette petite étude n’est qu’un rapide examen et non pas un cas réel, doté de différents éléments ou encore CDN. Le test est donc à poursuivre plus en profondeur. Cela dit, HTTP2 promet de belles choses en termes d’efficience énergétique.
Vous le savez, une application de qualité ne doit pas consommer trop de ressources sur le smartphone de l’utilisateur. C’est nécessaire à son adoption et à son utilisation.
Vous avez donc décidé de vous retrousser les manches et de contrôler cette consommation de ressources (CPU, mémoire, data…), l’énergie, la taille de l’application. Vous maîtrisez les bonnes pratiques et le langage de développement, mais l’enfer est pavé de bonnes intentions ! Quelle est la boîte à outils pour bien commencer ? Passons en revue les meilleurs outils pour le développeur Android.
Android Studio
Android Studio intègre maintenant de nombreux outils pour suivre la consommation de ressources de votre application. L’avantage est l’intégration de l’outil dans votre environnement de développement. On ne peut pas être plus proche de votre travail au jour le jour. Cependant, il faudra aller chercher dans les sous-menus et penser à suivre les métriques.
La dernière version intègre maintenant la possibilité de profiler le réseau et même les librairies comme OKHTTP :
Les outils du SDK : Traceview
Traceview permet de visualiser les appels de méthodes, le temps passé dans chacune… L’outil est très puissant mais vous passerez sûrement du temps à analyser les données. Il est possible que vous vous perdiez dans la hiérarchie des appels. Cependant cet outil est incontournable pour analyser des problèmes de performance (entre autres).
Les outils du SDK : Systrace
Systrace est un autre outil de profiling très puissant. Il permet de visualiser des informations sur le matériel (le travail du CPU avec la répartition sur tous les CPUs) mais aussi des packages d’informations Android (RenderThread, Event…). Comme tout bon outil de profiling, il présente beaucoup d’informations. L’inconvénient est qu’il faut prendre le temps de comprendre toutes ces informations, ce qui peut facilement se révéler assez chronophage.
Les outils du SDK : Dumpsys
Dumpsys est un module en ligne de commande du système Android. De nombreuses informations peuvent être obtenues : informations sur les vues, sur la base … L’inconvénient de cette solution est la complexité des métriques, donc la nécessité de passer du temps pour analyser et relancer les mesures. Par exemple, taper la ligne suivante dans la ligne de commande pour avoir les informations sur les traitements graphiques : adb shell dumpsys gfxinfo
Si vous avez activé le mode développeur, vous aurez des outils qui vous permettent de mesurer certaines métriques comme la performance d’affichage, le CPU… Ce mode est très intéressant mais la nécessité de devoir effectuer des actions manuellement sur le téléphone en limite la puissance.
A noter, la possibilité de mettre en surbrillance des zones qui sont dessinées. Cela permet par exemple d’identifier des redraws trop fréquents.
Les outils Android non intégrés dans le SDK : Battery Historian
Battery historian est un outil qui va visualiser les informations issues de dumpsys batterystats. La décharge batterie est donc visible en parallèle des traitements système et de l’usage des composants. Vous pourrez ainsi détecter des problèmes de fuite d’énergie. La limite est qu’il est nécessaire de faire tourner l’application plusieurs minutes ce qui augmente la complexité d’analyse :on est proche d’un outil de profiling avec la complexité associée.
Les outils d’automatisation : GREENSPECTOR
Évidemment nous ne pouvons pas passer en revue ces outils sans parler de GREENSPECTOR. Les outils dont nous venons de parler sont puissants, mais leur puissance se paie par leur complexité importante, qui demande une expertise certaine pour bien en retirer les informations recherchées. Or très souvent, ces outils ne sont invoqués qu’en cas de crise, quasiment jamais de façon régulière. Pourtant il semble intéressant de réaliser des mesures de consommations de ressources tout au long du développement et pour tous les développeurs. C’est pour cela que GREENSPECTOR est utilisable en intégration continue. Au-delà des métriques usuelles, nous avons intégré une partie des outils experts (comme Dumpsys) directement dans GREENSPECTOR. L’objectif est d’allier la simplicité de l’interface, pour une surveillance en continu, et l’apport d’informations plus « pointues » en cas de besoin.
Voici par exemple une courbe sur les vues Android lors du lancement de l’application suite à un test en intégration continue :
Cette manière de mesurer nous permet de détecter facilement des problèmes de consommation. L’analyse plus poussée pourra ensuite être faite avec les autres outils mentionnés si elle s’avère nécessaire.
Les algorithmes SEO de Google se basent sur 3 domaines :
le crawling qui va permettre à Google d’évaluer vos pages en termes de temps de réponse, de qualité technique ;
l’indexation qui va analyser le contenu (fraîcheur, richesse, qualité…) ;
le ranking pour analyser la popularité de votre site.
Le crawling est une des parties les plus importantes, car c’est la manière dont Google va « afficher » vos pages. Les robots de Google (ou GoogleBots) vont analyser chaque url et les indexer. Le processus est itératif : les bots reviendront régulièrement réanalyser ces pages pour identifier les éventuels changements.
La notion de Crawl budget
L’effort que les bots de Google vont fournir pour analyser votre site va influencer le nombre de pages qui seront référencées, la fréquence des vérifications ultérieures, ainsi que la notation globale de votre site. L’algorithme de Google est en effet dicté par un « effort maximum à fournir » qu’on appelle le « crawl budget« . Google le définit comme ceci:
Crawl rate limit Googlebot is designed to be a good citizen of the web. Crawling is its main priority, while making sure it doesn’t degrade the experience of users visiting the site. We call this the « crawl rate limit » which limits the maximum fetching rate for a given site. Simply put, this represents the number of simultaneous parallel connections Googlebot may use to crawl the site, as well as the time it has to wait between the fetches. The crawl rate can go up and down based on a couple of factors: Crawl health: if the site responds really quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Googlebot crawls less. …
Autrement dit, Google ne veut pas passer trop de temps sur votre site, pour pouvoir consacrer du temps aux autres sites. Donc s’il détecte des lenteurs, l’analyse sera moins poussée. Toutes vos pages ne seront pas indexées, Google ne reviendra pas si souvent, résultat : vous allez perdre en référencement.
Une autre explication à cette logique de budget, est que le crawling coûte de la ressource serveur à Google et que cette ressource a un coût. Google est une entreprise non philanthropique. Il est compréhensible qu’elle veuille limiter ses coûts de fonctionnement tel que celui du crawling. Au passage, cela permet aussi de limiter l’impact environnemental de l’opération, ce qui est un point important pour Google.
Sachez où vous en êtes
Il est donc nécessaire de surveiller le budget crawling et la manière dont Google analyse votre site. Cela peut se faire de différentes manières.
Vous pouvez utiliser la console Google Search Crawl-stat.
La fenêtre d’erreur Crawl-error est importante : elle va vous indiquer les erreurs que le robot a rencontrées lors du crawl.
Plusieurs types d’erreurs sont possibles, mais ce qui est sûr c’est qu’une page trop lente à charger sera mise en erreur (timeout du bot). Je rappelle que Google ne veut pas passer trop de temps à crawler votre site, il a mieux à faire. Vous trouverez ici plus d’explications sur les erreurs.
Voici par ailleurs, la liste des robots qui sont pris en compte dans le budget de crawl de Google Search console.
Enfin, vous pouvez simuler la façon dont Google va « voir » votre page. Toujours dans la console Google Search, utilisez l’option Crawl comme Google.
Voila, vous savez maintenant comment Google crawle et voit votre site ! Bon résultat ou mauvais, le référencement n’est jamais acquis et il faut batailler chaque jour. Nous allons donc voir comment améliorer cela.
Améliorez la performance
Temps de réponse du serveur
Comme vous l’avez compris, GoogleBot se comporte comme un utilisateur : si la page met trop de temps à charger, il abandonne et va sur un autre site. Donc une bonne performance va permettre d’améliorer le nombre de pages crawlées par Google. Un chargement rapide laissera au bot le temps de crawler plus de pages. Indexé plus en profondeur, votre site sera mieux référencé.
Reduce excessive page loading for dynamic page requests. A site that delivers the same content for multiple URLs is considered to deliver content dynamically (e.g. www.example.com/shoes.php?color=red&size=7 serves the same content as www.example.com/shoes.php?size=7&color=red). Dynamic pages can take too long to respond, resulting in timeout issues. Or, the server might return an overloaded status to ask Googlebot to crawl the site more slowly. In general, we recommend keeping parameters short and using them sparingly. If you’re confident about how parameters work for your site, you can tell Google how we should handle these parameters.
C’est la première limite à respecter : ne pas un dépasser un temps trop long sur le serveur. Trop long ? Difficile de mettre un seuil ! Mais vous pouvez au moins mesurer cette performance avec un indicateur tel que le Time To First Byte (TTFB). C’est le temps entre l’émission de la requête côté client et la réception du premier octet en réponse à cette requête. Le TTFB prend donc en compte le temps de transfert sur le réseau et le temps de traitement côté serveur. Le TTFB est mesuré par tous les outils habituels de gestion de la performance. Le plus simple est d’utiliser les outils de développement intégrés aux navigateurs :
Un seuil normal sera entre 200 et 400 ms. Regardez le temps que vous obtenez, et essayez de le réduire. Comment faire ? Plusieurs paramètres sont à prendre en considération :
La configuration du serveur : si vous êtes sur un hébergement mutualisé, difficile d’agir ; amis si vous connaissez le responsable infra demandez-lui !
Le traitement des requêtes. Par exemple si vous être sous un CMS comme WordPress ou Drupal, le temps de génération des pages PHP et d’accès à la base de données ont un impact important. Vous pouvez utiliser les systèmes de cache comme W3cache ou alors un reverse proxy comme Varnish par exemple.
Un code inefficient côté serveur. Analysez votre code et appliquez les bonnes pratiques d’écoconception.
De cette manière, vous allez faciliter l’accès à vos pages pour vos utilisateurs et surtout éviter les erreurs de crawl de Google.
Performance d’affichage
Difficile de dire à quel point les bots de Google prennent en compte la vitesse d’affichage de votre page mais c’est un paramètre important. Si la page prend 10 secondes à charger, les bots auront du mal à la lire en entier. Comment mesurer cela ? Tout comme pour le TTFB, les outils de développeurs sont utiles. Je vous conseille aussi Web Page Test.
L’idée est de rendre la page visible et utilisable le plus rapidement possible à l’utilisateur. Le plus rapidement possible ? Le modèle RAIL donne des temps idéaux :
En particulier, le R (pour Response) indique un temps inférieur à 1 seconde.
Pour améliorer cela, le domaine de la performance web fourmille de bonnes pratiques. Quelques exemples :
Utiliser le cache client pour les éléments statiques comme les CSS. Cela permet lors d’une deuxième visite d’indiquer au navigateur (et aussi aux bots) que l’élément n’a pas changé et qu’il n’est donc pas nécessaire de le recharger.
Concaténer les JS et les CSS ce qui permettra de réduire le nombre de requêtes. Attention, cette bonne pratique n’est plus valide si vous passez en HTTP2.
Limiter globalement le nombre de requêtes. On voit de nombreux sites avec plus de 100 requêtes. C’est coûteux en termes de chargement pour le navigateur.
Nous aurons l’occasion de revenir dans un prochain article sur la performance web. Au final, si vous rendez votre page performante, ce sera bénéfique pour votre référencement mais aussi pour vos visiteurs !
Aller plus loin avec l’écoconception
La limite de la performance pure
Se focaliser uniquement sur la performance serait une erreur. En effet, les bots ne sont pas des utilisateurs comme les autres. Ce sont des machines, pas des humains. La performance web se focalise sur le ressenti utilisateur (affichage le plus rapide). Or les bots voient plus loin que les humains, ils doivent en effet lire tous les éléments (CSS, JS…). Par exemple, si vous vous focalisez sur la performance d’affichage, vous allez potentiellement appliquer la règle qui conseille de déférer certains codes javascript en fin de chargement. De cette manière la page apparaît rapidement et les traitements continuent ensuite. Or comme les bots ont pour objectif de crawler tous les éléments de la page, le fait que les scripts soient déférés ne changera rien pour eux.
Il est donc nécessaire d’optimiser tous les éléments, y compris ceux qui chargeront une fois la page affichée. On fera particulièrement attention à l’usage du javascript. Google Bot peut le parser mais avec des efforts. On utilisera donc chaque technologie avec parcimonie. Par exemple AJAX a pour but de créer des interactions dynamiques avec la page : oui pour les formulaires ou chargements de widgets… mais non si c’est uniquement pour un chargement de contenu sur un OnClick.
Faciliter le travail du GoogleBot revient à travailler sur tous les éléments du site. Moins il y a d’éléments, plus c’est facile à faire. Donc : Keep It Simple !…
L’écoconception à la rescousse du crawl
L’écoconception des logiciels a pour objectif principal de réduire l’impact environnemental des logiciels. Techniquement, cela se traduit par la notion d’efficience : il faut répondre au besoin de l’utilisateur, en respectant les contraintes de performance, mais avec une consommation de ressources et d’énergie qui soit la plus faible possible. La consommation d’énergie causée par les logiciels (dont votre site web) est donc la pierre angulaire de la démarche.
Comme vous l’avez compris depuis le début de l’article, les bots ont un budget issu d’une capacité limitée en temps mais aussi une facture d’énergie à limiter pour les datacenters de Google. Tiens ? Nous retrouvons ici le but de l’écoconception des logiciels : limiter cette consommation d’énergie. Et pour cela, une approche basée sur la performance ne convient pas : en cherchant à améliorer la performance sans maintenir sous contrôle la consommation de ressources induites, vous risquez fort d’obtenir un effet inverse à celui que vous recherchez.
Alors, quelles sont les bonnes pratiques ? Vous pouvez parcourir ce blog et vous en découvrirez 🙂 Mais Je dirais que peu importent les bonnes pratiques, c’est le résultat sur la consommation de ressources qui compte. Est-ce que les Progressive Web App (PWA) sont bonnes pour le crawling ? Est-ce que le lazy loading est bon ? Peu importe, si au final votre site consomme peu de ressource et qu’il est facile à « afficher » par le bot, c’est bon.
La mesure d’énergie pour contrôler la crawlabilité
Une seule métrique englobe toutes les consommations de ressources : l’énergie. En effet la charge CPU, les requêtes réseaux, les traitements graphiques… tout cela va déboucher sur une consommation d’énergie par la machine. En mesurant et contrôlant le consommation d’énergie, vous aller pouvoir contrôler le coût global de votre site.
Voici par exemple une mesure de consommation d’énergie du site Nantes transition énergétique. On voit 3 étapes : le chargement du site, l’idle au premier plan, et l’idle navigateur en tâche de fond. De nombreuses bonnes pratiques d’écoconception ont été appliquées. Malgré cela, un slider tourne et la consommation en idle reste importante, avec une conso totale de 80 mWh.
On le voit ici, la consommation d’énergie est le juge de paix de la consommation de ressources. Réduire la consommation d’énergie va vous permettre de réduire l’effort du GoogleBot. Le budget énergétique idéal pour le chargement d’une page est de 15 mWh : c’est celui qui permet de décrocher le niveau « Or » du Green Code Label. Pour rappel ici, malgré le respect de bonnes pratiques, la consommation était de 80 mWh. Après analyse et discussions entre les développeurs et le maître d’ouvrage, le slide a été remplacé par un affichage aléatoire et statique d’images : la consommation est retombée sous les 15mWh !
Améliorer la consommation et l’efficience de votre page, c’est bien, mais cela risque de ne pas suffire. L’étape suivante est d’optimiser aussi le parcours de l’utilisateur. Le bot est un utilisateur ayant un budget ressources limité et devant parcourir le maximum d’URL de votre site avec ce budget. Si votre site est complexe à parcourir (trop d’URL, une profondeur trop importante…) le moteur ne parcourra pas tout le site, ou alors en plusieurs fois.
Il est donc nécessaire de rendre le parcours utilisateur plus simple. Cela revient encore à appliquer des principes d’écoconception. Quelles sont les fonctionnalités dont l’utilisateur a vraiment besoin ? Si vous intégrez des fonctionnalités inutiles, l’utilisateur et le bot vont gaspiller des ressources au détriment des éléments vraiment importants. Outils d’analytics trop nombreux, animations dans tous les sens… demandez-vous si vous avez vraiment besoin de ces fonctionnalités car le bot devra les analyser. Et cela se fera surement au dépit de votre contenu qui – lui – est important.
Pour l’utilisateur, c’est pareil : si obtenir une information ou un service demande un nombre de clics trop important, vous risquez de le décourager. Une architecture de parcours efficiente va permettre d’aider le bot et aussi l’utilisateur. Aidez-vous du sitemap pour analyser la profondeur du site.
Enfin, l’exercice d’écoconception des pages ne sera pas efficace si vous avez un site complexe. Il est possible par exemple qu’avec des urls dynamiques un nombre important d’url soit détecté par Google. Vous aurez alors des urls en double, du contenu inutile… Un nettoyage de l’architecture du site sera peut-être nécessaire ?
Vous pouvez anticiper la manière dont Google crawle votre site, toujours via la console Search Crawl, avec l’option Fetch as Mobile.
Google propose aussi un site de test pour savoir si votre site est prêt pour le mobile.
La prise en compte de ces contraintes #MobileFirst n’est pas forcément simple pour votre site. Il est probable que cela vous prennent du temps et quelques efforts. Mais c’est le prix à payer si vous voulez avoir un bon référencement dans les prochains mois. En outre, vos visiteurs seront reconnaissants : ils apprécieront que votre site ne décharge plus autant la batterie de leur smartphone.
Pour aller encore plus loin
Reprenons la citation de Google :
Googlebot is designed to be a good citizen of the web.
En tant que développeur ou propriétaire de site, votre ambition doit être de devenir au moins un « aussi bon citoyen du web » que le bot de Google. Pour cela, projetez-vous dans un usage de votre site sur plateforme mobile, mais aussi dans des conditions de connexion bas débit ou d’appareils un peu plus anciens. En réduisant les consommations de ressources de votre site, non seulement vous ferez plaisir au GoogleBot (qui vous récompensera par un meilleur référencement) mais aussi vous donnerez à toute une partie de la population mondiale (y compris dans les pays « riches ») la possibilité d’accéder à votre site. Ne croyez pas que cette approche soit uniquement philantropique. Rappelons que Facebook et Twitter l’appliquent déjà avec les versions « Light » de leurs applis exemple : Facebook Lite.
Un site étant non seulement compatible sur mobile mais prenant en compte toutes les plateformes mobiles et toutes les vitesses de connexion devrait donc normalement être valorisé dans un futur proche par Google. D’autant plus que, plus le site sera léger, moins Google consommera de ressource.
Et comme pour l’utilisateur, la consommation et surtout l’impact sur l’environnement devient de plus en plus important:
Pression des ONG pour réduire ses impacts, par exemple le rapport Greenpeace
Il est certain qu’un site efficient et répondant uniquement au besoin de l’utilisateur sera mieux valorisé dans le classement SEO de Google (et des autres).
Conclusion
Le référencement de votre site web par Google s’appuie en partie sur la notion de crawling : le robot parcourt les pages de votre site. Pour cette opération, il se fixe un budget de temps et de ressources. Si vos pages sont trop lourdes, trop lentes, le crawling ne sera réalisé que partiellement. Votre site sera mal référencé.
Pour éviter cela, commencez par prendre l’habitude d’évaluer la « crawlabilité » de votre site. Puis mettez en place une démarche de progrès. En première approche, regardez ce que vous pouvez obtenir à l’aide des outils de performance classiques.
Puis réfléchissez en termes de MobileFirst : appliquez les principes de l’écoconception à votre site. Simplifiez le parcours utilisateur, enlevez ou réduisez les fonctions inutiles. Mesurez votre consommation d’énergie et mettez-là sous contrôle. Au prix de ces quelques efforts, vous obtiendrez un site mieux référencé, plus performant, apprécié des utilisateurs.
De nombreux sites web ayant cédé à l’obésité (trop de requêtes, des scripts superflus…), il est urgent d’anticiper l’évolution des algorithmes de référencement de Google, qui suivent désormais les mêmes objectifs que les utilisateurs, en demandant plus de performance ET moins de consommation d’énergie : en un mot, de l’efficience.
GREENSPECTOR permet de détecter des comportements des logiciels ayant un impact sur la consommation de ressources (énergie, mémoire….). Nous utilisons pour cela un ensemble de techniques permettant d’être le plus précis dans les constats pour permettre d’obtenir des gains importants et cela avec peu d’effort. L’analyse de code et la détection de patterns consommateurs fait partie de ces techniques.
Généralement, l’analyse de code se focalise à une détection syntaxique (c’est ce que l’on peut voir dans une IDE quand on tape du code et que l’IDE nous propose une autre écriture). Nous avons initialement utilisé ces techniques classiques d’analyse de code mais les résultats ne nous semblaient pas satisfaisants. En effet, nous obtenions trop de violations (le développeur pouvait être noyé dans trop de violations), et parfois des faux positifs. Au-delà de cela, de simples règles syntaxiques ne permettaient pas de détecter des règles poussées (ayant un impact sur la consommation de ressources) comme la détection des Wake lock sur Android. C’est la raison pour laquelle nous avons choisi de partir sur une autre technique d’analyse. Voici notre retour d’expérience.
Dès leur apparition dans les années 50, l’analyse du code source écrit dans un langage fut rapidement perçue comme un enjeu d’importance. En effet, LISP, un des tous premiers langages (1956) est par nature autoréférentiel et permet à un programme de s’analyser lui-même. Dès lors que l’ordinateur personnel s’imposa, il ne fallut qu’une dizaine d’années pour voir apparaitre des IDEs, comme Turbo Pascal de Borland, qui proposa de plus en plus de services d’assistance au programmeur. Pendant ce temps Emacs montrait la voie : analyse de code (grâce au LISP), code en couleur, etc… L’analyse du code source lors de son écriture est maintenant partie intégrante de l’environnement de développement mis en place lors de l’initiation d’un projet : Jenkins, Eclipse propose des services sans cesse plus performants. GREENSPECTOR est l’un de ces assistants qui assiste le développeur à écrire une application plus efficiente en consommation énergétique.
Plonger dans les entrailles du code
GREENSPECTOR propose entre autre d’analyser le code source afin de trouver des formes, des façons d’écrire qui pourraient être améliorées en termes de performances d’exécution, de consommation mémoire ou de consommation réseau, trois facteurs ayant une forte incidence sur la consommation d’un smartphone, permettant à votre client de pouvoir profiter de celui-ci toute la journée.
Hello world de la détection de pattern
Prenons un exemple stupide mais simple. Chacun reconnaitra qu’il est plus malin d’écrire :
var arraySize = myarray.length;
for (var i = 0 ; i < arraySize ; i++) {
aggr += myarray[i];
}
que
for (var i = 0 ; i < myarray.length ; i++) {
aggr += myarray[i];
}
Dans le second exemple, on aura un appel à la méthode length à chaque test de la boucle. Dans un tableau de taille conséquente, cet appel de méthode peut vite devenir coûteux.
AST
Bien évidemment, on ne peut pas analyser le texte brut du code, mais une représentation de données adaptée à la manipulation par programmation. On appelle cette représentation un AST, pour Abstract Syntax Tree. Comme son nom l’indique, un AST est un arbre… On verra plus tard pourquoi c’est important.
L’AST de notre premier bout de code pourrait ressembler à quelque chose dans le genre :
Obtenir cet AST n’est pas évident. En Java, on dispose de JDT, PDT pour respectivement Java et PHP. Ces librairies sont éprouvées, et même si leur fonctionnement est un peu difficile à appréhender et leur logique laisse parfois à désirer, elles restent assez efficaces.
Chez GREENSPECTOR, nous avons choisi d’utiliser Scala pour réaliser notre outil d’analyse de code. Scala, la puissance du fonctionnel, les avantages de la JVM. Afin de réaliser des analyses sur l’AST, nous avons écrit notre propre grammaire en Scala, qui est un mapping des grammaires JDT ou PDT. Cette grammaire, utilisant les cases class de Scala, nous permet de bénéficier du pattern matching que ce langage a piqué à OCaml, lors de sa conception.
Ainsi, une affectation de variable est ainsi définie en Scala :
case class AssignmentJava ( id:Long, vRightHandSide : JavaExpression, vLeftHandSide : JavaExpression, vOperator : JavaAssignmentOp, lne : (Int,Int)) extends JavaExpression
Tandis qu’un pattern-matching (sorte de switch-case au stéroïdes) sur cette structure ressemble à
case AssignmentJava( uid, vRightHandSide, vLeftHandSide, vOperator, lne) => ...
A droite, on peut faire ce qu’on veut des variables uid, vRightHandSide, vLeftHandSide, vOperator, …
Cette façon de faire est très puissante pour analyser un arbre.
Détecter les boulettes
Maintenant que nous avons notre arbre, il va falloir détecter des problèmes qu’on voudrait remonter à l’utilisateur. Problème, on ne sait toujours quel problème on va lui remonter. Donc écrire cette détection dans le programme en Scala, avec le pattern-matching n’est pas très flexible, car il faut sans-cesse changer le programme. De plus, ce n’est pas forcément simple à écrire.
En bon fainéant, nous voici à la recherche d’une méthode moins fastidieuse. En fait, je vous ai menti : pour être fainéant, Scala et son pattern-matching n’est pas adapté. Or, qui dit simplicité, dit requête. Eh bien voilà, il nous faut un langage de requête ! Comme SQL ou les regexp. Un truc où on décrit juste ce qu’on cherche, et paf, le système nous le ramène !
BDD Graphe
Heureusement, le monde sans cesse plus foisonnant de l’Open Source arrive à la rescousse : Neo4j est un serveur de base de données orienté graphe. Même s’il est plus conçu pour analyser qui sont vos amis sur Facebook ou avec qui vous discutez sur Twittter, on peut l’utiliser pour une raison simple : un arbre est un cas particulier d’un graphe ! Mais surtout, Neo4j est doté d’un langage parfait pour un fainéant : Cypher. Cypher est le langage de requête de Neo4j, il est totalement conçu pour trouver n’importe quoi dans un graphe.
D’où l’idée de mettre notre AST dans Neo4j et d’utiliser Cypher pour trouver ce que l’on cherche.
Trouver du code mal écrit
C’est souvent moins de 20% du code qui mobilise 80% du CPU la plupart du temps !
Un AST n’est juste qu’une représentation arborescente d’un texte, la densité d’informations sémantiques restant limitée. Afin de pouvoir analyser plus précisément le code et détecter des motifs intéressants et/ou difficiles à voir, on a besoin d’accroitre la densité sémantique du code. Pour se faire, on va transformer notre arbre en graphe, en créant des liens entre éléments de notre AST. Par exemple, nous allons pouvoir créer des liens entre des nœuds de type ‘Déclaration de fonction’, de sorte que l’on sache quelle fonction appelle quelle fonction. Bien évidemment, chacun de ces appels sera aussi relié à l’endroit où cette fonction est appelée.
On appelle cela le ‘Graphe d’Appel‘ notons que cette construction est plus aisée à faire dans certains langages que d’autres. Ainsi Java, de par sa structure et ses déclarations de type obligatoires nous permet de retrouver plus facilement le graphe d’appel que des langages comme, disons, au hasard, Javascript ou PHP 😉
La difficulté consiste à ne pas se tromper d’appel : combien de méthodes différentes vont s’appeler ‘read’ par exemple ? Potentiellement beaucoup. Il faut donc s’assurer que l’on relie bien les 2 bonnes fonctions, et pour se faire déterminer quel est le type de l’appelant, dans les langages orientés objet.
Connaitre le graphe d’appel, combiné à d’autres analyses, permet de savoir quel partie de code s’exécute le plus souvent, car on en a l’intuition, mais on ne le sait pas toujours, c’est souvent moins de 20% du code qui mobilise 80% du CPU la plupart du temps. En connaissant les parties du code les plus souvent exécutées, on pourra attirer l’attention du développeur sur des optimisations particulières à faire sur des portions critiques du code.
De même pour économiser de la mémoire, il faut utiliser plus intelligemment les variables que l’on déclare. En retrouvant leurs déclarations et les liens avec leur utilisation, on devient capable d’indiquer comment optimiser l’utilisation de la mémoire.
Illustrons ce que nous avons abordé avec un exemple simple, le helloworld de la détection de pattern. On observe souvent, en java, des boucles itérant simplement un tableau, en vérifiant que l’index est strictement inférieur à l’index du tableau. Cet exemple est améliorable, car l’appel à la méthode .size() est couteux et pourrait être mis « en cache » dans une variable.
Le langage cypher dont nous avons parlé tout à l’heure nous permet de détecter à coup sûr ce genre de « forme » de code :
match (n:LoopStatement) where n.loopType = "ForStatementJava" with n match (n)-[:vExpression]->(i:InfixExpression)-[vRightOperand]->(m:MethodInvocation) where m.methodName = "size" return n;
En gros, on lui demande de trouver un for classique en Java, ayant dans l’updater du for, un appel de méthode size()
Conclusion
La représentation sous forme de graphe modifiable offre une grande flexibilité pour l’analyse du code. Elle permet d’analyser le code avec la profondeur d’analyse choisie et d’améliorer sans cesse la qualité d’analyse du code.
Au sein de GREENSPECTOR, de par sa simplicité, sa puissance et son intuitivité, le langage de requête Cypher a vite été adopté et la montée en compétence fut rapide.
Nos règles sont maintenant beaucoup plus cohérentes et avec moins de faux positifs. A vous de le découvrir en lançant une analyse de code avec GREENSPECTOR !
De notre côté, il nous reste encore à explorer toutes les possibilités de cette architecture qui nous permettra à terme de réaliser des analyses de haut niveau.
Greenspector may use cookies to improve your experience. We are careful to only collect essential information to better understand your use of our website.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
