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.
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 !
Webp est le nouveau format d’image proposé par Google, qui promet une réduction de 30% à 80% de la taille de transfert. De plus, le format serait plus adapté aux processeurs actuels. Mais qu’en est-il de la consommation d’énergie sur l’appareil de l’utilisateur ?
Le format Webp
Webp est un format matriciel comme le PNG ou le JPEG. Il supporte des compressions sans perte (lossless) comme le PNG mais aussi avec perte (lossy) comme le JPEG. Ce format est actuellement pris en compte par Chrome, Chrome pour Android, et Opera. Cependant la controverse vient de la fondation Mozilla qui considère que le format n’offre pas autant d’avantages qu’annoncé.
Au passage, Mozilla travaille de son côté sur une optimisation du JPEG : MozJPEG. Voici un lien pour comprendre comment gérer ces problèmes d’implémentation : Google WebP Mais qu’en est-il effectivement de l’efficience de ce nouveau format ? La mesure de l’énergie consommée pour afficher ces images va permettre de répondre à cette question !
METHODOLOGIE DE MESURE
Pour cela j’utilise mon outil favori (ce n’est pas une surprise), à savoir le service Power Test Cloud de GREENSPECTOR.
La méthodologie est la suivante :
La mesure est faite sur un smartphone réel, un Nexus 6, hébergé et géré par GREENSPECTOR ;
On lance Chrome et on accède aux exemples d’images donnés par Google ;
On itère 2 fois, parce que 2 mesures valent mieux qu’une.
Avant d’aller plus loin, nous pouvons émettre nous-mêmes quelques critiques sur notre protocole :
On utilise les images de Google : sont-elles vraiment représentatives ? On supposera que oui.
On évalue le coût unitaire d’affichage des images et non pas leur intégration dans une page web plus globale. En même temps, on est là pour ça.
Comparaison des formats : Webp (lossless et lossy) versus PNG
Pour cet test, nous avons pris les 3 premières images de la galerie Google. Vérifions d’abord la taille des images :
Le résultat est très net : les images Wbep sont en moyenne 27% plus légères que le PNG, et même 70% pour le lossy. Les promesses sont pour l’instant au rendez-vous. Mais regardons l’énergie consommée sur le smartphone pour lorsqu’il affiche ces images dans le navigateur :
Aïe. En moyenne, il y a WebP engendre 1,5% de consommation d’énergie supplémentaire. Il y a un gain uniquement pour l’image 3 – et encore, en comparons le Webp lossy au PNG. Pour l’image 1 on a une perte de 3,8%. Enfin on constate que le Webp lossy avec transparence est encore plus consommateur que le Webp lossless. C’est surprenant !
Au final, le PNG est plus intéressant pour la consommation d’énergie. Si vous vous focalisez uniquement sur les gains réseaux, alors WebP est plus intéressant. Le constat est encore plus fort pour le Webp lossy avec transparence. Cela peut s’expliquer par un algorithme de rendu moins efficient que le PNG, qui annule tous les gains d’énergie apportés par la réduction de l’impact réseau.
Comparaison des formats « lossy » : Webp versus JPEG
Pour ce test, nous avons testé les 5 images de la galerie de Google Vérifions d’abord la taille des images.
Là aussi la promesse est tenue : le gain de taille apporté par Webp est en moyenne nos 30%. Vérifions maintenant la consommation d’énergie.
Dans 4 cas sur 5, les gains apportés par Webp par rapport à JPEG sont intéressants (entre 2% et 8%). A cause du cas particulier de l’image 4, la moyenne des gains s’établit à 2,4%.
Si on regarde plus précisément les courbes de consommation d’énergie, on constate effectivement que le pic de consommation est plus bas pour Webp :
On remarque globalement que Webp sollicite moins la batterie que JPEG.
CONCLUSION
Il est clair que le format Webp permet d’obtenir une taille d’image plus faible que les autres formats. C’est bénéfique pour le réseau internet en général, les opérateurs telecom en particulier, et les utilisateurs finaux tout spécialement.
Nous avons aussi identifié des gains d’énergie allant jusqu’à 8% pour les images lossy par rapport à du JPEG. Cependant dans certains cas minoritaires pour le lossy et dans tous les cas pour le lossless, nous avons identifié des consommations d’énergie plus importantes pour Webp que pour les formats traditionnels. Si vous voulez des images lossless (par exemple pour des logos, des images avec du texte…), alors le PNG reste meilleur en termes d’énergie.
Explication : comme les images sont plus légères, il semble que la cellule radio soit moins sollicitée et donc qu’il y ait moins d’énergie consommée. Cependant quand on regarde l’occupation CPU, Chrome passe du temps dans le traitement pour la décompression du Webp. Sur un smartphone, les gains sur le réseau sont donc limités, voire annihilés, par le coût du traitement CPU supplémentaire.
Conclusion de la conclusion : Les gains de taille apportés par le Webp sont réels pour le réseau. Associés à une réduction – certes faible – de la consommation d’énergie, ils font de WebP un format intéressant pour l’efficience en tant qu’alternative au JPEG. En revanche, pour l’alternative au PNG, il faudra attendre.
Enfin notons que dans ce domains les travaux sont nombreux. Ainsi pour l’alternative au JPEG, une convergence vers d’autres améliorations technologiques comme le HTTP2, pourrait permettre des gains plus importants encore.
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.
