Auteur : Olivier PHILIPPOT

Expert Sobriété Numérique Auteur des livres «Green Patterns», «Green IT - Gérer la consommation d’énergie de vos systèmes informatiques», ... Conférencier (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, ...) Fondateur du Green Code Lab, association nationale de l’écoconception des logiciels

Intégrer un service tiers : est-ce dangereux pour la vie privée de vos visiteurs, quel impact pour l’environnement ? Le cas Youtube

Reading Time: 5 minutes

L’intégration de service tiers permet d’ajouter rapidement une fonctionnalité sur un site comme une vidéo ou l’intégration d’un réseau social (voir le cas de l’intégration Twitter). Les fournisseurs de ces outils ont travaillé pour que l’intégration technique soit simple et rapide. Et la technique est au rendez-vous. Mais à quel prix ?


Consommation d’énergie du service tiers Youtube

Nous observons sur nos mesures une augmentation de ce type de service tiers et des surconsommations anormales. C’est le cas de nombreux sites voire même de sites gouvernementaux.  

L’intégration de YouTube est un bon cas d’étude pour expliciter cet effet. En seulement quelques lignes, il est possible d’afficher une vidéo sur n’importe quel site : 

<iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/WoQHxxxxxxx-E?rel=0″ frameborder=”0″ allow=”autoplay; encrypted-media” allowfullscreen></iframe>

Mais quel est le résultat en termes d’impact chez l’utilisateur ? Voici le résultat que nous obtenons en termes de consommation d’énergie sur un smartphone Nexus 6 :

Consommation d'énergie du services tiers Youtube

Référence : Vitesse de décharge en uAh/s du téléphone (OS, Navigateur…)
Loading : Vitesse des 20ères secondes de chargement
Idle Foreground : Vitesse du site inactive en premier plan
Scroll : Vitesse lors que l’utilisateur scroll / défile en bas de page
Idle Background : vitesse de décharge quand le navigateur (et donc le site) est en tâche de fond

Il s’agit d’un site gouvernemental. Les vitesses de décharge dépassent nos seuils pour beaucoup d’étapes. Pour le chargement, la vitesse est plus de 2 fois celle de référence. Pour l’idle foreground ou phase d’inactivité en premier-plan, la consommation devrait être identique à celle de référence. Cette consommation est anormale pour un site qui semble assez léger.

Process CPU du services tiers Youtube

On voit que le process CPU de Chrome monte à 10% toutes les secondes. Cela explique la surconsommation d’énergie. En profilant les appels JavaScript dans les outils de développement, nous observons des traitements issus de base.js qui sont issus du framework YouTube :

Javascript framework Youtube

À noter que ce traitement impacte aussi le scroll et le chargement. Est-ce un fonctionnement attendu ? Un bug ou une mauvaise implémentation ? Nous n’avons pas été jusque-là dans l’analyse.

Quand on regarde le chargement de la page, sur 1,2Mo, près de 600 ko sont utilisés pour le plugin YouTube. 50ko de CSS et 550ko de Javascript. Au traitement nécessaire, il faut ajouter l’usage important de CPU pour parser et exécuter les scripts.

Point notable : Aucune vidéo n’apparait sur cette page. L’intégration du plugin est surement nécessaire pour une autre page. Cela rend le gaspillage encore plus critique, cela est d’autant plus embêtant que le site testé est public et largement utilisé : Impots.gouv !


Bonnes pratiques d’intégration d’une vidéo

1 – Intégrer directement la vidéo sans services tiers

Il est possible d’utiliser des solutions libres et sans plugin. L’intégration via HTML5 est native : Introduction à la balise vidéo de HTML5.

2 – Intégrer une image

Afficher une image avec le même rendu que la vidéo permet de réduire à 1 requête. Si l’utilisateur clique sur la vidéo, alors les scripts seront chargés et la vidéo lancée, du lazy loading en fin de compte.

Nous avons par ailleurs fait l’exercice sur une page de notre site web Greenspector :

Sur l’une de nos pages “Étude de cas” était intégrée une vidéo YouTube. Nous avons remplacé cette intégration par l’affichage d’une image (ci-contre) représentant l’ancienne vidéo intégrée. Cette modification nous a permis de passer d’un écoscore Greenspector de 59/100 à 75/100 caractérisé par un gain en énergie de -12% en étape de chargement, de -10% en Idle et -15% en scroll.

Page avec vidéo intégrée
Page avec image

3 – Intégrer le plugin uniquement sur la page voulue

Une solution pas idéale mais préférable à l’existant, est de faire appel uniquement aux scripts que lorsque la page nécessite une vidéo.

Que cela va-t-il permettre de gagner ?

Tout d’abord la performance. Une grosse partie des traitements liés aux temps d’attente des sites est dédiée aux services tiers. C’est encore plus vrai pour le plugin YouTube. Sur le site audité, la taille peut être diminuée par 2 et le temps de chargement réduit d’au moins 30%.

La consommation d’énergie sera aussi réduite et d’une manière encore plus importante que la taille des données ou la performance. En effet, en plus de l’économie d’énergie du chargement, la consommation en idle ou phase d’inactivité sera réduite.

Bonus : vie privée de l’utilisateur

L’autre problème de ce type de projet est l’usage de tracker et de récupération de données utilisateur. Ne pas intégrer un services tiers permet de résoudre des potentiels problèmes de fuite de données et de non-respect RGPD. Au passage, le plugin YouTube permet une version a priori sans cookie via l’appel à l’URL : https://www.youtube-nocookie.com.

Comme tout service tiers, cela n’est pas si simple. Même avec cette intégration de no-cookie, des données utilisateurs sont stockées :

Données utilisateurs cookies Youtube

Le site audité n’est donc pas compatible RGPD ! Pour gérer cela, il faut demander le consentement à l’utilisateur explicitement :

Fenêtre de consentement

La solution de la vidéo hébergée ou de l’image statique permettra aussi de gérer cela.


Conclusion

Si l’intégration d’une vidéo est nécessaire, réfléchissez-y tranquillement et prenez en compte les impacts sur la consommation de ressources et la RGPD. Il existe des solutions techniques plus respectueuses de l’utilisateur, elles sont dans un premier temps peut-être un peu plus complexes à mettre en place, cependant les solutions vont naturellement devenir plus simples et répandues.

Faut-il limiter les données qui transitent sur internet pour réduire l’impact du numérique ?

Reading Time: 11 minutes

TL;DR

Le débat fait rage actuellement sur l’intérêt ou non de limiter la consommation de données des utilisateurs web. Et derrière cette question, celle de la nécessité de passer ou non à la 5G, celle-ci amenant à des débits plus importants. 

Les défenseurs d’une limitation argumentent que cela réduirait la consommation d’énergie et l’impact du numérique, les défenseurs pour la poursuite des évolutions technologiques (et généralement aussi de la non limitation de la bande passante) argumentent que l’amélioration constante des technologies compenserait les effets négatifs du numérique. 

Comme dans tout débat, les deux parties ont des arguments valides. Tentons d’analyser en quoi la réponse n’est pas si simple ! 

Disclaimer : En tant que professionnel de l’IT et de la sobriété numérique, notre objectif est de fournir des données claires et factuelles sur l’impact du numérique et son évolution. Le numérique sert à aider la société sur d’autres domaines mais ce n’est pas une raison pour ne pas optimiser et réduire l’impact du numérique. Plusieurs études montrent qu’il est nécessaire d’agir, sans quoi la tendance pourrait être encore plus néfaste. 

Empreinte carbone de l’électricité des technologies de communication 2010 - 2030

La question n’est pas de savoir si telle ou telle projection est bonne mais comment agir pour être dans le meilleur des cas. 


1. Amélioration des datacenters

Il est prouvé que l’efficacité globale des infrastructures s’est améliorée ces dernières années.

L’étude IEA a été reprise de nombreuses fois sur les réseaux en argumentant que la consommation d’énergie des centre de données est faible et s’est améliorée énormément ce qui a permis d’absorber l’augmentation du trafic. 

Tendances mondiales du trafic Internet, des charges de travail des centres de données et de la consommation d'énergie des centres de données, 2010-2019

Il y a en effet eu énormément d’amélioration de l’efficacité par différentes actions : consolidation et virtualisation, amélioration des flux d’air… Les coûts énergétiques étant fixes, la consommation d’énergie et aussi l’impact de ces infrastructures n’ont pas augmenté. 

Une nouvelle étude confirme cette tendance à l’amélioration mais montre aussi l’augmentation importante en termes de consommation d’énergie qui s’est produit avant 2010 (la fenêtre utilisée par l’IEA) : augmentation de 4% entre 2010 et 2014 mais après une augmentation de 24% les 5 années précédentes et 90% entre 2000 et 2005. 

On peut voir aussi cela sur le cas des US

Consommation d'électricité par composante d'utilisation finale, 2000 à 2006

On peut cependant moduler ce constat car on partait de loin : plus de serveur physique, aucune gestion des flux… Le plus gros des gains a donc été fait ces dernières années. L’amélioration de la capacité ne va pas aller au même rythme et il va certainement y avoir une augmentation nécessaire de la capacité des Datas center. Un exemple, la stagnation du PUE

Les gains d'efficacité énergétique des datacenters se sont stabilisés

Les opérateurs le prennent même en compte via une diminution du rythme d’optimisation plus faible.

evolutions et previsions des consommations d'électricite des data centers orange Gwh

Les projections des études scientifiques montrent des explosions de la consommation des Data center. Même si elles se basent sur des projections qui peuvent être discutées, l’augmentation est bien présente : 

Consommation d'énergie des centres de données dans le monde en milliards de kWh par an

Au final, on peut effectivement dire qu’il y a eu beaucoup d’améliorations mais on a tout à fait le droit de se poser des questions sur certains éléments : 

  • À quel coût CO2 s’est faite cette amélioration ? En effet, la construction de nouveaux Data center et le remplacement des anciens par de nouveaux serveurs plus efficients a eu un coût en termes de fabrication. Les études n’en parlent pas 
  • Il n’y a aucune métrique sur l’efficience des traitements. Quelle est l’évolution de coût côté Data center de l’affichage d’une page web, d’un traitement… ?
  • Ces courbes sont à mettre en face de la consommation de bout en bout (jusqu’à l’utilisateur). C’est ce que nous allons tenter de faire en partie dans la suite de l’article. 

2. Amélioration des réseaux

Il en va de même pour les infrastructures réseaux. Le ratio kWh/Go a largement diminué. Exemple du cas sur le réseau en Finlande.

Réseau Finlande

Il existe des critiques cependant sur ce mode de présentation de l’efficience (les Wh/Go) car la consommation de ces infrastructures est fixe. Consommer plus de données sur le réseau serait gratuit. C’est faux car, pour piloter l’efficience, cette métrique est utile en permettant d’affecter cette consommation à un usage. Et effectivement, plus on va consommer, plus cette métrique va diminuer. Deux conclusions s’imposent sur la base de cette analyse : 

1/ Oui l’efficience du réseau s’améliore 

2/ Oui, plus on utilise le réseau, plus on “rentabilise” la consommation fixe et les impacts environnementaux du matériel. 

Cependant cela pose le problème de la capacité du réseau. Lorsque le réseau est saturé, il est nécessaire d’ajouter des infrastructures. C’est ce qui se passe actuellement sur le réseau 4G. A certaines heures et dans certains lieux, les utilisateurs sont redirigés vers les réseaux 3G. La solution choisie est donc de passer à une autre génération de réseau qui va permettre d’absorber cette charge. 

Donc au final si l’efficience du réseau est vraie, elle ne doit pas être la seule métrique pour analyser le problème. Il est nécessaire de prendre aussi le paramètre de la capacité du réseau (mais aussi de la capacité de chaque réseau unitaire). Car sans cela le bénéfice de l’amélioration de l’efficacité des réseaux est annulé par l’impact du renouvellement trop fréquent de l’infrastructure du réseau. 


“Comme nous recherchons un ordre de grandeur en économie d’énergie, nous supposons que la diminution de 30% du volume de trafic dans le cœur de réseau induit une diminution du même ratio dans le dimensionnement du réseau et par conséquent une diminution de 30% de la consommation d’énergie dans le cœur du réseau IP.” 


Vous pouvez trouver ce raisonnement entre autres dans le projet de recherche Européen CONVINcE sur lequel Greenspector a travaillé avec des acteurs de l’infra et de la vidéo.   

“As we are looking for an order of magnitude in energysaving, we suppose thatdecreasing by 30% the traffic volume in the core network induces a decrease of same ratio in network dimensioning and consequently a decrease of 30% in energyconsumption in the core IP network.” 

Quant à l’impact environnemental du réseau, de la même manière que pour l’étude IEA, une courbe d’une étude ARCEP a été utilisée de nombreuses fois : 

ARCEP Emissions GES des opérateurs francais

C’est positif mais encore une fois, il manque certaines données pour bien analyser cette tendance et surtout elle ne prend pas en compte la tendance où une partie de l’impact environnemental est passée chez l’utilisateur avec l’usage des box internet. 

Car, comme on le verra plus loin, on observe un déplacement des traitements informatiques vers les utilisateurs. 


3. Amélioration des terminaux

De la même manière, les terminaux (PC, Smartphone, TV…) améliorent leur efficacité énergétique. La loi de Koomey le démontre.

Koomeys low graph made by Koomey

Cependant il y a un ralentissement notable (voir paragraphe suivant). Nous l’avons-nous-même constaté sur les smartphones sur la moyenne des sites que nous avons mesurés (6000 mesures depuis 2017). D’une part par ce ralentissement de l’efficience énergétique des processeurs mais aussi par une certaine lourdeur des logiciels. Un exemple dans l’évolution des benchs de processeur (qu’on peut aussi voir sur de nombreux autres types de bench).


4. Limitation de l’amélioration de l’efficience

« En 2016, la société Intel mentionne un ralentissement du rythme de miniaturisation des processeurs et, en conséquence, un écart à la loi de Moore »

L’amélioration de l’efficience qui est formulée par Koomey a une limite. Elle est liée en partie au ralentissement de la loi de Moore. 

« En 2016, la société Intel mentionne un ralentissement du rythme de miniaturisation des processeurs et, en conséquence, un écart à la loi de Moore » écrit le chercheur Jean-Gabriel Ganascia 

Cette limitation est aussi formulée par la loi de Laudauer : il est impossible physiquement d’atteindre une certaine efficience. Nous avons encore relativement une marge mais la tendance au ralentissement est déjà visible. Les tendances annoncées par les opérateurs de Data center (voir plus haut) le montrent bien. 

On voit déjà des limites sur certains composants : 

Cette même étude (issue de l’industrie des semi-conducteurs) annonce une explosion de la consommation d’énergie et une nécessité de continuer cette recherche d’efficience. On le voit cependant même avec cette efficience, la consommation totale due à l’informatique sera relativement importante par rapport à la production d’énergie mondiale. Discours différents par rapport aux personnes qui annoncent une consommation nulle de l’informatique !

L’approche optimiste est de dire que la R&D permettra de trouver des nouvelles approches. Cependant, à quel coût ? Et cela n’empêche pas de réfléchir à rentabiliser les technologies actuelles pour gérer ce futur plateau.  


5. Technologie logicielle

« Les programmes ralentissent plus vite que le matériel accélère » 

L’évolution de la technologie logicielle n’est pas souvent prise en compte dans les approches d’évaluation et de prospection. Le matériel étant le consommateur de ressource. Cependant le lien est faible entre les deux. 

Le logiciel ne suit généralement pas l’évolution du matériel, ou en tout cas, il le suit moins rapidement. C’est ce qu’énonce la loi de Wirth.

On peut le voir sur de nombreuses métriques des logiciels, sur des mesures empiriques mais il existe cependant peu d’étude qui démontre cette loi. Si on prend l’évolution de la taille des pages web ainsi que de la performance depuis 10 ans

Il y a effectivement une tendance à la surcharge. Tendance qu’on pourrait atténuer par rapport à l’amélioration du réseau cité plus haut. Pour calculer l’efficience, nous allons prendre le ratio d’énergie consommée pour transporter 1Mo de data. Nous allons aussi comparer ce ratio avec l’hypothèse de la médiane des pages des sites qui serait restée stable en volume de données par rapport à 2011 (soit 200Ko). Sachant que 200k est assez réaliste pour un site complet et utilisable. On peut même aller plus loin : voir le challenge 10k. On obtient alors : 

L’efficience réelle (matériel + logiciel) ne suit pas l’efficience du matériel. Si les tendances se poursuivent (>2020) alors on pourrait même avoir une efficience énergétique qui commence à se dégrader. 

En prenant la performance des processeurs vu plus haut (Single Threaded Integer Performance), l’évolution du chargement des pages web, et en considérant que la performance des pages web reste à 5 secondes en moyenne), les conclusions sont les mêmes : l’efficience est constante.

Ces analyses sont partielles, il serait nécessaire de prendre des indicateurs plus adaptés mais cela montre en partie que l’amélioration de l’efficience n’est pas si claire. 

La loi de Wirth semble confirmée dans de nombreux cas. Dans certains domaines spécifiques comme le calcul scientifique, la performance des traitements est proche du matériel, cependant dans de nombreux logiciels, on observe un écart. Une des raisons est bien souvent la non-prise en compte de la plateforme matériel lors du développement et le paradigme que les bytes n’ont pas d’impact. C’est faux ! Par exemple, la tendance du web a été d’utiliser énormément de JavaScript pour afficher les pages web. Or ces bytes transférées ont une part importante dans le poids des pages mais aussi dans l’efficience des traitements côté utilisateur. Le JavaScript devient en effet un des goulots d’étranglement de la performance sur mobile. Les CPU même si surpuissant, passent leur temps à charger, parser et exécuter le JavaScript.

JSS Processing for CNN.com

Ce phénomène est très bien expliqué dans l’article The Cost of Javascript. Le résultat est une explosion de l’énergie par un usage intensif de cycle CPU ainsi qu’un ralentissement des performances et un sentiment d’obsolescence de la plateforme par l’utilisateur.


Effet rebond

Nous ne traiterons pas ici de l’effet rebond en termes d’usage. C’est un aspect en effet très discuté qui prend en compte du social, des analyses prospectives… Cependant nous pouvons, d’un point de vue technique, observer un effet rebond issu de l’amélioration des technologies : celle de l’ajout d’informations annexes aux services qui sont purement nécessaire à l’utilisateur. Par exemple, on peut citer : l’ajout de services annexes tels que la publicité, les trackers…  

Effet rebond

La part de JavaScript pris par les services “annexes” est importante et dépasse celle du JavaScript utilisé pour le service primaire. Ceci a été rendu possible, entre autres, par certaines capacités techniques : intégration de script facilitée, bande passante le permettant…

Et alors ?

Afin de prendre les bonnes décisions, il est important de prendre du recul et surtout de regarder les tendances. Il est clair que ces dernières années en informatique ont vu arriver une amélioration notable des infrastructures matérielles, des Data center aux terminaux. Cela a permis de nouveaux usages mais aussi de nouvelles pratiques de développement. La frénésie de développement de solution ne s’est pas forcément accompagnée d’une optimisation, les technologies, offrant de génération en génération plus de puissance, plus de bande passante, l’optimisation semblait pour certains un surcoût inutile. Cette optimisation s’est cependant faite dans beaucoup de cas pour des raisons économiques : réduire la facture électrique du Data center, optimiser l’usage d’une infrastructure réseau. Cette optimisation n’a pas été systémique mais plutôt unitaire, au détriment souvent de certaines parties comme les terminaux.  

Cela a amené un retard entre l’efficience réelle des plateformes et leurs capacités. L’affichage des sites en 5 secondes avec 8 CPU et de la 4G sur des téléphones en est l’exemple. Ce n’est qu’une accélération de la loi de Wirth en fait. Les plus optimistes et je dirais technophiles ont comme position que les évolutions technologiques, associées à des meilleurs outils logiciels permettront de garder une performance suffisante. Cela pourrait être une solution cependant elle a des contreparties : elle va dans le sens d’un renouvellement assez rapide des plateformes, en particulier, côté utilisateur, et donc d’un impact environnemental plus important. Elle ne va pas de plus dans le sens de pratiques vertueuses : les tailles des sites et des logiciels vont continuer de grossir. La performance sera constante voire améliorée sur les nouvelles plateformes et cela exclura les utilisateurs qui veulent garder des anciennes plateformes. A moins de le gérer dans les logiciels (comme par exemple l’apparition de version lite), approche peu probable car coûteuse et applicable uniquement par les Big Tech. L’approche optimiste se base sur des évolutions technologiques futures. Or on le voit avec la loi de Laudaeur, il y a une limite. Nous avons encore peut-être quelques années, mais la dette grandit. 

Dans ce cadre, la 5G ne va pas forcément dans le bon sens car elle va permettre de charger plus de données, plus rapidement et donc de ne pas avoir à optimiser les logiciels et même de rajouter des services tiers. Il est pourtant clair que la 5G a des avantages technologiques qui permettraient en partie d’améliorer l’efficience du système global. Mais sans garde-fou, nous allons continuer comme nous l’avons toujours fait avec les différentes technologies : toujours plus sans penser à l’optimisation

Dans ce cadre, la mise en place d’incitation ou de contrainte est nécessaire pour freiner cette course à l’armement. La limitation de la bande passante est une approche intéressante car elle va permettre d’avoir un budget data qui pourrait être répartie. En limitant la taille des sites web par exemple, il sera nécessaire d’optimiser des choses : optimisation technique des librairies, suppression de services tiers, suppression du superflu… La limitation des données est dans ce cadre un axe qui permettra de limiter la consommation d’énergie (en particulier chez l’utilisateur) mais sera surtout un axe pour éviter une obsolescence des plateformes, et au final un axe pour maitriser, voire réduire l’impact du numérique. 

Nous travaillons depuis longtemps avec certains de nos clients dans le sens de l’optimisation en leur offrant des moyens de mesure et d’amélioration sur la réduction de la consommation d’énergie mais aussi de données, de traitement CPU… Cependant la résistance au changement des organisations, l’état de l’art et les pratiques du développement logiciel, les priorisations business… font que ces optimisations ne seront à long terme pas suffisantes pour rattraper le retard que l’on prend au niveau global de l’industrie IT. Les acteurs engagés sont des précurseurs, cependant pour que tout le secteur s’améliore réellement, la contrainte semble inévitable…à moins que la prise de conscience et le passage à l’action arrivent demain

Quels sont les meilleurs navigateurs web à utiliser en 2020 ?

Reading Time: 8 minutes

Le navigateur internet est l’outil primordial sur un appareil mobile. Il est le moteur pour naviguer sur internet. Plus uniquement pour les sites web mais aussi maintenant pour les nouveaux types d’applications basées sur les technologies web (progressive web app, jeux,…).

Dans notre classement des 30 applications mobiles les plus populaires, parmi les catégories mails, messageries directes, réseaux sociaux, navigateurs, etc., la navigation web et les réseaux sociaux sont en moyenne plus consommateurs que les jeux ou les applications multimédia. Le rapport serait même de 1 pour 4 entre les applications les moins et les plus énergivores.

Diminuer l’impact environnemental de sa vie numérique ainsi qu’augmenter l’autonomie de son téléphone passent en partie par le choix d’un bon navigateur. Au même titre que si l’on souhaite réduire l’impact de son mode de transport, il est important de prendre le véhicule le plus efficient.

L’année passée nous avions publié le classement 2018 des navigateurs les moins énergivores, nous vous proposons la nouvelle édition pour 2020, plus complète, réalisée à l’aide de notre laboratoire GREENSPECTOR.

Classement global

La note sur 100 des navigateurs est la suivante :

La moyenne des notes est de 36/100 ce qui est assez médiocre. Elle s’explique par des notes basses pour chacune des métriques.
Les trois navigateurs les moins énergivores sont : Vivaldi, Firefox Preview, Duck Duck Go.

Consommation d’énergie globale (en mAh)

La médiane est de 47 mAh et une grande partie des navigateurs se situent dans cette consommation (8/18 sont dans le 2ème quartile).
À noter que les 3 derniers navigateurs dans le classement se différencient par une consommation 75 % plus élevée que la médiane. Firefox, Qwant et Opera Mini sont en effet très énergivores.

Consommation d’énergie de la navigation (en mAh)

Les 3 derniers navigateurs du classement global (Opera Mini, Firefox et Qwant) ainsi que Mint consomment énormément plus que la moyenne des autres navigateurs (entre 20 et 35 mAh contre 16 mAh).

Autant dire que pour la plupart des navigateurs (mise à part les exceptions précédentes), la navigation pure ne va pas être la raison de la différence de consommation globale. Ceci s’explique principalement sur l’usage des moteurs de visualisation. La plupart des navigateurs utilisent le moteur Chromium. Pour Opera Mini, la spécificité est qu’un proxy est utilisé et permet de compresser la taille des sites. Il semble que cela ne soit pas bon pour l’énergie, en effet la décompression sur le téléphone de l’utilisateur consomme de l’énergie.

Pour Firefox, la surconsommation d’énergie est une chose connue et partagée, c’est l’une des raisons pour laquelle Mozilla est en cours de développement d’un nouveau navigateur. Nom de code interne Fenix et public Preview. Les mesures dans ce classement sont plutôt encourageantes sur la consommation (dans la moyenne).
Pour Qwant, ceci s’explique par l’usage du moteur Firefox ! Les mesures entre Qwant et Firefox sont en effet très proches.

Consommation d’énergie des fonctionnalités (en mAh)

La fonctionnalité principale qui est la navigation sur le web nécessite d’autres fonctionnalités toutes aussi importantes : ouvrir un nouvel onglet, entrer une adresse dans la barre des tâches… À cela se rajoute la consommation d’énergie de la page d’accueil du navigateur. En effet, lorsque l’on ouvre un nouvel onglet, chaque navigateur propose des fonctionnalités différentes : sites web principalement utilisés, dernières actualités, …

Là où les navigateurs se différencient globalement peu sur la navigation pure, on observe des différences importantes dans la consommation d’énergie sur les autres fonctionnalités avec un rapport de plus de 3 (entre 4 mAh et 12 mAh).

À noter que les 3 premiers (Firefox Focus, Firefox Preview et Duck Duck Go) ont une page d’accueil simple. La consommation du navigateur en Idle (inactivité) est alors très faible. La sobriété fonctionnelle en paye les conséquences !

Les consommations lors du lancement des navigateurs sont assez similaires entre-elles. On remarque cependant que l’ouverture d’un onglet et l’écriture d’une URL sont des actions qui sont réalisées plusieurs fois. Si l’on prend une projection journalière de 30 nouveaux onglets et 10 écritures d’URL, on observe encore plus la différence entre les navigateurs et la large avance de Firefox Preview et Focus !

Les fonctionnalités de bases ne sont donc pas négligeables dans la consommation globale du parcours.

Projection d’autonomie (en nombre d’heures)

Si l’on prend ces données d’énergie et qu’on les projette pour une navigation de plusieurs sites web, on identifie le temps maximum que l’utilisateur peut naviguer jusqu’à décharge complète de sa batterie :

Consommation de données (en Mo)

La différence de consommation de données entre navigateurs (8 Mo d’écart) s’explique par la navigation pure et par les différentes fonctionnalités.

Sur la navigation, on explique cette différence :

Certaines applications ne gèrent pas du tout le cache pour des raisons de protection et de confidentialité des données (Firefox Focus) l’usage de proxy qui optimise les données (Opera Mini)une différence d’implémentation de la gestion du cache.

Il est en effet possible que certains navigateurs invalident le cache et que des données soient chargées alors qu’elles sont en cache.

Des consommations de données annexes se poursuivent en tâche de fond (idle des onglets, données en arrière-plan non bloquées…) des différences de performance de téléchargement qui viennent augmenter la durée de la mesure. En effet, si un navigateur est performant, la contrepartie est que beaucoup plus de données sont potentiellement chargées en arrière-plan.

La différence de consommation globale s’explique aussi par la consommation de données des fonctionnalités de base :

Beaucoup de navigateurs sont très consommateurs. On note les 3 Mo de Qwant qui semblent anormaux !
On peut considérer que pour les navigateurs, cette consommation doit être proche de 0. En effet, la principale fonctionnalité d’un navigateur est d’afficher une site web, toute fonctionnalité (et consommation associée) peut être considérée comme une « surconsommation ».
Dans ce cadre, beaucoup de navigateurs consomment des données lors de l’écriture de l’URL. Ceci s’explique principalement par les fonctionnalités de proposition d’URL. Il y a en effet des échanges entre le mobile et les serveurs, soit directement par le navigateur, soit par le moteur de recherche associé.

Par exemple, pour le navigateur Yandex ci-dessous, le détail des échanges de données lors de l’écriture d’une URL montre plus 400 Ko de données échangées.

À l’opposé, ci-dessous, les échanges pour Brave sont frugaux avec moins de 2 Ko.

Performance des navigateurs (en seconde)

Les mesures nous permettent d’évaluer la performance des fonctionnalités :

Lancement du navigateur

Ajout d’un onglet

Écriture d’une URL

Suppression du cache

Bench Mozilla Kraken

NB : Cette étude n’évalue pas la performance d’affichage des sites web. Par contre le Bench Mozilla Kraken le permet en partie en évaluant les fonctionnalités des navigateurs.

Efficience des navigateurs (en mAh/s)

Nous pouvons évaluer l’efficience des navigateurs en prenant la performance du bench Mozilla Kraken et l’énergie associée. L’efficience est la consommation d’énergie par unité de temps :

Samsung, Opera Mini et Opera sont les navigateurs les plus efficients. Ce classement est différent de celui de la consommation d’énergie globale. Pour Samsung Internet, cette première place en terme d’efficience sur un matériel Samsung peut s’expliquer par le lien optimisé que peut avoir le constructeur avec un logiciel pré-installé. Le navigateur Opera a un beau positionnement (2ème pour la consommation globale et 3ème pour celle de l’efficience).

Piste d’améliorations

Il est possible d’améliorer la consommation de la navigation.

Pour l’utilisateur :

Choisir un navigateur efficient

Utiliser les marques-pages ou favoris afin d’éviter de passer par la barre de saisie

Configurer les options d’économie d’énergie des navigateurs (mode ou thème sombre, data server…)

Pour les développeurs de sites :

Éco-concevoir leur site

Tester et mesurer sur différents navigateurs pour identifier des comportements différents et les prendre en compte

Pour les éditeurs de navigateurs :

Mesurer la consommation d’énergie et l’efficience

Éco-concevoir les fonctionnalités

Réduire la consommation de ressources des fonctionnalités récurrentes (écriture d’url, nouvel onglet…)

Rendre la page d’accueil la plus sobre possible.

Protocole de mesure

Les mesures ont été réalisées par le laboratoire GREENSPECTOR sur la base d’un protocole standardisé : Smartphone Samsung S7, Android 8, Wi-Fi, luminosité 50%. Entre 4 et 8 itérations ont été réalisées et la valeur retenue est la moyenne de ces mesures. Les campagnes de mesure respectent un scénario permettant d’évaluer les navigateurs dans différentes situations.

Évaluation des fonctionnalités

Lancement du navigateur

Ajout d’un onglet

Écriture d’une URL dans la barre de recherche

Suppression des onglets et nettoyage du cache

Navigation

Lancement de 6 sites et attente pendant 20 secondes pour être représentatif d’un parcours utilisateur

Benchmark navigateur

Le benchmark Mozilla Kraken permet de tester la performance JavaScript

Évaluation des périodes d’inactivité du navigateur

Au lancement (cela permet d’évaluer la page d’accueil du navigateur)

Après navigation

Après fermeture du navigateur (pour identifier des problèmes de fermeture)

Pour chaque itération, on réalise les tests suivants :

Suppression du cache et des onglets (sans mesure)

Première mesure

Deuxième mesure pour mesurer le comportement avec cache

Suppression du cache et des onglets (avec mesure)

Fermeture système du navigateur (et pas uniquement une fermeture par l’utilisateur pour s’assurer une réelle fermeture du navigateur)

La moyenne de mesure prend donc en compte une navigation avec et sans cache.

Les métriques principales analysées sont les suivantes : performance d’affichage, consommation d’énergie, échange de données. D’autres métriques telles la consommation CPU, la consommation mémoire, des données systèmes… sont mesurées mais ne seront pas affichées dans ce rapport. Contactez GREENSPECTOR pour en savoir plus.

Afin d’améliorer la stabilité des mesures, le protocole est totalement automatisé. Nous utilisons un langage abstrait de description de test GREENSPECTOR qui nous permet une automatisation poussée de ce protocole. Les configurations des navigateurs sont celles par défaut. Nous n’avons changé aucun paramètre du navigateur ou de son moteur de recherche.

Notation

Une notation sur 100 permet de classer les navigateurs entre eux. Elle se base sur la notation de 3 métriques principales :

MétriqueDéfinitionUnité
PerformanceDurée nécessaire au déroulement d’une étape de testsecondes (s)
ÉnergieVitesse de décharge de la batterie constatée sur l’appareil pendant le déroulement de l’étape de test, comparée à la vitesse de décharge de la batterie de l’appareil avant que l’application ne soit lancéeMesures en uAh/s, puis classement en multiples de la vitesse de décharge de référence
DonnéesVolume de données total (émises + reçues) pendant le déroulement de l’étape de testkilo-octets (ko)

Un ratio de pondération est appliqué sur les 5 niveaux des steps (de 5 pour les verts foncés à -1 pour les rouges foncés) comme décrit dans le tableau exemple suivant :

Le score de cette application est alors calculé à 61/100 pour la métrique énergie.
Une fois le score de chacune des trois métriques obtenu sur 100 points, le score total de l’application est calculé avec une pondération égale des trois métriques:
Score total = ( Score Performance + Score Énergie + Score Données ) / 3

Navigateurs évalués

Nom du navigateurVersion
Brave1.5.2
Chrome78.0.3904.108
Duck Duck Go5.32.3
Ecosia39632
Edge42.0.4.4052
Firefox68.3.0
Firefox Focus8.0.24
Firefox Preview2.3.0
KiwiQuadea
Lilo1.0.22
Maxthon5.2.3.3241
Mint37290
Opera54.3.2672.502
Opera Mini44.1.2254.143
Qwant37714
Samsung10.1.01.3
Vivaldi2.7.1624.277
Yandex19.10.2.116

Certains navigateurs ont été écartés car ne permettaient pas l’automatisation des tests. Par exemple les navigateurs UC Browser et Dolphin n’ont pas pu être mesurés. Au-delà de l’automatisation, cela est symptomatique d’un problème d’accessibilité de l’application. En effet pour améliorer l’accessibilité des applications pour les personnes avec des déficiences visuelles (entre autres), il est nécessaire de mettre en place des labels pour les boutons. L’automatisation que nous réalisons se base sur ces informations. Au final, ces navigateurs n’apparaissent pas dans le classement, mais on peut considérer que les problèmes d’accessibilité sont dans tous les cas un problème rédhibitoire.

Note : Le classement 2020 est difficilement comparable à celui de 2018. En effet, notre protocole ayant totalement évolué, les tests sont ainsi plus poussés et automatisés.
Découvrez notre dernière étude : le Playstore Efficiency Report 2019!

Les 12 règles à respecter pour le succès de votre application

Reading Time: 4 minutes

Dans un précédent article sur ce blog, nous vous avions présenté les 5 clés de succès d’une application mobile. Nous vous présentons aujourd’hui les 12 règles par indicateur métier à respecter qui feront le succès de votre application.

Inclusion

L’application doit être utilisable dans des conditions de réseau dégradées

L’application ne doit pas nécéssiter une version d’OS récente comme Android pour être utilisée. Certains utilisateurs ne suivent pas les mises à jour, volontairement ou à cause de leur plateforme qui ne leur permet pas. D’après notre “PlayStore Efficiency Report 2019“, seules 70% des applications sur le store sont compatibles avec toutes les versions d’Android.

L’application doit respecter les règles d’accessibilité et ne doit pas exclure des utilisateurs présentant des handicaps.

L’application doit aussi bien fonctionner sur des téléphones d’anciennes générations que sur les modèles récents et dernier-cri. Ce critère sera dégradé si vous ne respectez pas celui de la sobriété. 1/4 des applications du Google PlayStore exluent 10% des mobiles les plus anciens. (Source : PlayStore Efficiency Report 2019)

Sobriété

L’application doit limiter sa consommation d’énergie afin de ne pas vider la batterie de l’utilisateur. De plus en cas de consommation trop importante, le système va notifier l’application comme consommatrice à l’utilisateur. Certaines applications trop gourmandes peuvent réduire à moins de 3 heures l’autonomie des batteries. (Source : PlayStore Efficiency Report 2019)

L’application doit limiter sa consommation de ressources (nombre de CPU, mémoire occupée, données échangées) afin d’éviter toute lenteur ou pollution des autres applications (par exemple à cause de la fuite mémoire). 50% des applications du Google PlayStore continuent à effectuer des traitements après la fermeture de l’application. (Source : PlayStore Efficiency Report 2019)

L’application doit limiser sa consommation réseau afin de n’impliquer aucune charge sur les datacenters et ainsi éviter les surcoûts liés aux encombrements inutiles des serveurs.

Performance

Le premier lancement de l’application doit être rapide : sans cela, il est possible que vos utilisateurs n’aillent pas plus loin, le critère d’inclusion ne sera pas non plus respecté.

Les temps de chargement de l’application doivent être acceptables dans toutes les situations réseaux.

Discrétion

L’application ne demande peu voire aucune permission. Avez-vous réellement besoin de consulter la liste des contacts de votre utilisateur ? C’est d’autant plus important d’optimiser cela puisque plus de permissions il y aura, plus l’application consommera des ressources. Ce qui influencera donc de manière négative le critère de performance.

L’application n’intègre peu voire aucun traqueur. L’intégration d’une quantité importante de traqueurs va impliquer une consommation de ressource plus importante mais peut aussi provoquer des bugs. Ce constat est d’autant plus vrai que la connexion sera dégradée.

D’après notre “PlayStore Efficiency Report 2019“, les traqueurs, analytiques et permissions sont omniprésents (44% des applications en possèdent plus de 5).

Écologie

L’application doit respecter le critère de sobriété, l’impact CO2 lié à l’usage sera plus faible tout comme la pression des ressources sur les composants du matériel de l’utilisateur (usure batterie, perte de performance). De ce fait, l’utilisateur sera moins propice à renouveler son matériel, ce qui diminue le risque d’obsolescence. Notre dernière étude à d’ailleurs montré que les applications sur mobiles contribuent au minimum à 6% des émissions de CO2 du numérique.

Quelques pistes pour l’amélioration de son score GREENSPECTOR App Mark

Améliorer directement l’application

Plusieurs métriques sont évaluées par le GREENSPECTOR App Mark et directement améliorables.

Version minimum du SDK : autoriser des versions plus anciennes d’Android évite l’exclusion des utilisateurs possédant des plateformes d’anciennes générations.

Nombre de traqueurss : moins l’application va posséder de traqueurs, plus elle sera respectueuse des données de l’utilisateur ainsi que de la protection de sa vie privée. De plus, les traqueurs via les traitements et les échanges de données viennent augmenter la consommation de l’application.

Taille de l’APK : plus le binaire de l’application est gros, plus le réseau va être solicité et moins l’application sera efficiente. De plus, une taille d’application importante va utiliser l’espace de stockage limité de certains utilisateurs.

Données chargées : nombre de données chargées tout au long du parcours de test. Limiter ces données va permettre de réduire la consommation de ressources à la fois sur le smartphone et sur le réseau.

Données chargées en tâche de fond : lors que l’application n’est pas utilisée, elle doit limiter son impact et envoyer ou recevoir le moins de données possible.

Métriques plus globales

Certaines métriques sont directement liées à l’impact de l’application et à son efficience. Il est possible d’agir dessus via les métriques précédentes, voir par d’autres axes (optimisation fonctionnelle, amélioration du code source…)

CO2 : plus l’application va consommer de l’énergie, plus la batterie va être solicitée et va s’user. Cela risque de mener à un renouvellement prématuré de la batterie voire même du smartphone et donc à un impact environnemental plus élevé.

Surconsommation d’énergie : si l’application surconsomme, elle va augmenter l’impact environnemental mais aussi créer une gêne pour l’utilisateur en particulier sur la perte d’autonomie.

Performance après la première installation : les applications effectuent parfois des traitements supplémentaires lors du premier lancement, le temps de lancement sera donc parfois réduit. Il est nécessaire de limiter ses traitements car cette perte de performance peut être gênante pour l’utilisateur.

Performance : le temps de lancement de l’application est une donnée importante pour l’utilisateur. Il est nécessaire de le réduire au maximum tout en consommant le moins de ressources possible.

Performance en 3G : dans des conditions de réseau dégradées, il est nécessaire de maîtriser la performance. Il est même possible que certains utilisateurs n’aient pas accès à l’application dans le cas d’une performance dégradée.

Et maintenant ?

Vous vous demandez certainement où se situe votre application sur ces 5 axes. Est-elle plutôt vertueuse ? Court-elle des risques ? Comment est-elle classée par rapport à ses concurents ? Avez-vous des pistes de progrès rapides ? Si vous nous le demandez, nous vous le dirons ! Contactez-nous, et nous viendrons vous présenter notre diagnostic inclusif, sobre, rapide, écologique et discret – tout comme votre application très bientôt.

Mesurer la performance des applications mobiles : monitoring synthétique ou real user monitoring ?

Reading Time: 3 minutes

La “digitalisation” des entreprises et particulièrement l’offre de plus en plus importante d’applications numériques, rendent le critère de qualité des applications mobiles de plus en plus nécessaire. La performance est dans ce cadre un critère de contrôle obligatoire. Sans cela, les risques sont nombreux pour les concepteurs d’applications : désinstallations, taux d’attrition en hausse, échec de projet, chiffre d’affaires en baisse…

Mais le fait de tester la performance des applications mobiles n’est pas aussi simple que de tester une application classique comme en avait l’habitude les équipes des DSI. En effet de plus en plus, les applications mobiles sont d’une part exécutées dans un environnement contraint (en termes de batterie, ressources…) et d’autre part, elles intègrent des services tiers qui sont complexes à maîtriser. Au final, avec des serveurs répondant en moins de 200ms, on arrive très souvent à des temps de réponses des applications malheureusement supérieurs à 3s.

Pour répondre à ce problème, il est important de bien comprendre les méthodes utilisées par les outils de ce marché en constante évolution.

Outils de monitoring vs outils de développement

Tester la performance de son application reste possible et accessible, surtout avec les SDK et les IDE de développement (Xcode, Android Studio…). Pour aller plus loin, de nombreuses solutions sont disponibles en open source. Cependant, cette approche nécessite de lancer des tests manuels sur son téléphone.

Avantages :

  • Mesure de la performance pendant le développement
  • Analyse détaillée possible dès détection d’un problème

Inconvénients :

  • Mesure assez aléatoire et pas forcément reproductible
  • Nécessite un smartphone de test à disposition

Les outils de monitoring permettent d’industrialiser la démarche de mesure de la performance en se basant sur des agents qui prennent la place du développeur.

Outils de monitoring synthétique vs outil de monitoring en usage réel (Real User Monitoring)

Les outils de monitoring synthétique sont des outils qui testent la performance des solutions dans des cas d’usages proches de ceux d’un utilisateur. Pour cela, des agents extérieurs stimulent l’application dans un environnement soit simulé soit réel (Emulateurs ou fermes de devices). L’avantage de cette solution est de surveiller la performance en continu. Cette approche s’applique même avant la mise en production de la solution ou avant que les utilisateurs finaux soient présents.

Avantages :

  • Remontée de la performance avant la mise en production
  • Mesure en continue pour l’identification des problèmes

Inconvénients :

  • Simulation pas nécessairement représentative de l’usage réel de l’application par les utilisateurs finaux
  • Nécessité d’utiliser des devices en continu pour faire tourner le monitoring

Les outils RUM remontent la performance réelle des utilisateurs. Cela nécessite l’intégration d’un agent dans l’application. Cette intégration permet la remontée d’autres métriques : parcours utilisateur, usages de l’application…

Avantage :

  • Vision réelle de la performance des applications

Inconvénients :

  • Impact de l’agent sur la performance de l’application
  • Détection trop tardive des problèmes
  • Trop d’informations lors de l’analyse des problèmes

Tests techniques vs tests fonctionnels pour les outils de monitoring

La simulation de l’application dans les outils de monitoring nécessite des tests automatiques. La solution la plus simple à mettre en œuvre repose sur les tests techniques : Lancement de l’application, ouverture de pages…

Avantages :

  • Mise en œuvre immédiate
  • Tests standards permettent d’identifier facilement des problèmes ou de se comparer avec des applications concurrentes

Inconvénient :

  • Tests pas forcément adaptés aux spécificités et au fonctionnel de l’application
  • Certains outils proposent d’effectuer des tests fonctionnels pour suivre la consommation. Le parcours utilisateur est alors simulé ou réellement effectué. Cela nécessite de scripter les actions de l’utilisateur. Généralement les outils se basent sur des technologies de script standardisés.

Avantages :

  • Simulation proche du parcours réel de l’utilisateur
  • Mutualisation des tests développés pour d’autres usages (tests fonctionnels par exemple)

Inconvénient :

  • Nécessité de développer les tests automatiques au préalable

NB : Des outils permettent de simuler une suite de requête vers les serveurs. Cette pratique issue des technologies serveurs (par exemple Jmeter) permet de tester plus la partie serveur mais est peu adaptée à la mobilité. En effet, elle ne permet pas de prendre en compte la complexité des plateformes mobiles.

Environnement émulé ou physique

Les environnements émulés (ou virtuels) sont identiques aux émulateurs de développement.

Avantage :

  • Mise en place assez rapide

Inconvénient :

  • Performance ne correspondant pas à des devices réels

Les environnements réels sont des téléphones mis à disposition par les outils de monitoring.

Avantage :

  • Performance identique aux devices réels

Inconvénients :

  • Coûts plus importants
  • Difficulté d’être représentatif de l’ensemble des devices des utilisateurs.

Les conseils des experts GREENSPECTOR

La clé est de détecter au plus tôt les problèmes de performance avant qu’ils n’affectent vos utilisateurs finaux. Il est donc nécessaire d’utiliser des outils de monitoring synthétique. Les outils de développement permettront de compléter l’analyse des problèmes de performance. Afin d’être représentatif de l’usage final de l’application, il sera nécessaire de mettre en place la bonne stratégie : tests fonctionnels à minima, exécution sur un échantillon représentatif de devices réels d’utilisateurs, simulation de différentes conditions de communication… Les outils RUM permettront de confirmer et compléter les hypothèses.

Les utilisateurs de GREENSPECTOR ont la possibilité d’appliquer cette stratégie via différents modules :

Le Top 10 des mythes du numérique sobre

Reading Time: 5 minutes


Je travaille depuis plus de 8 ans dans le GreenIT et j’ai pu constater dernièrement que plusieurs études et initiatives se sont lancées. C’est très positif et cela montre qu’il y a une vraie dynamique pour changer l’impact du numérique. Toutes les actions qu’elles soient à petite échelle, comme une simple prise de conscience, ou bien à plus grande échelle comme l’optimisation d’un site avec des millions de visiteurs, est bonne à prendre compte-tenu de l’urgence climatique.

Cependant il est important d’éviter tout phénomène de Greenwashing et de bien comprendre l’impact des bonnes pratiques évoquées (sont-elles vraiment toutes green ?)

Mythe n°1 – Un logiciel performant est un logiciel sobre.

Faux.

Un logiciel performant est un logiciel qui va s’afficher rapidement. Cela ne donne aucune information sur sa sobriété. Au contraire, il est possible que des pratiques soient mises en place pour un affichage rapide et qu’elles aillent à l’encontre de la sobriété. Comme par exemple mettre le chargement des scripts après l’affichage de la page. La page s’affichera rapidement mais de nombreux traitements s’exécuteront en tâche de fond et auront un impact sur la consommation de ressources.

Mythe n°2 – Optimiser la taille des requêtes et le poids de la page, cela rend le logiciel plus sobre.

Vrai et Faux

Vrai car effectivement moins de ressources seront utilisées sur le réseau et les serveurs. Ce qui signifie un impact environnemental moins important. Cela va dans le bon sens.

Faux car l’évaluation d’un logiciel sobre ne va pas uniquement se baser sur ce type de métrique technique. En effet, il est possible que certains éléments aient un impact tout aussi important. Un carrousel sur une page d’accueil pourra par exemple être assez light en termes de poids et de requêtes (pour un carrousel optimisé) mais dans tous les cas possèdera un impact fort en consommation de ressources coté utilisateur (consommation CPU, graphique…).

Mythe n°3 – Le contrôle automatique via des outils me permet d’être Green

Vrai et Faux

Vrai car il est important de mesurer les éléments. Cela va permettre de savoir objectivement où on en est, et de s’améliorer.

Faux car l’évaluation va se faire sur des éléments techniques. Il y a un biais : on ne mesure que ce que l’on peut automatiser. C’est la critique qui peut être faite par exemple sur Lighthouse (outil accessible dans Chrome) sur l’accessibilité On peut faire un site totalement inaccessible en ayant un score à 100. C’est la même critique que l’on peut avoir sur les outils qui sont utilisés dans l’écoconception. Par exemple le site http://www.ecoindex.fr/ est un outil intéressant pour initier la démarche, par contre le calcul de cet outil se base sur 3 éléménts techniques : la taille de la page, le nombre de requête et la taille du DOM. Ce sont des éléments important dans l’impact de la page, cependant plusieurs autres éléménts peuvent être impactant : traitement CPU issus de script, traitement graphique, sollicitation plus ou moins bonne de la cellule radio… Autant d’éléments qui peuvent créer des faux positifs.

Un logiciel de mesure sera alors complémentaire 😉

Mythe n°4 – Mon logiciel utilise un code open-source et libre, je suis donc green

Faux

Un logiciel libre est un logiciel à part entière. Il subit la même obésité que les autres logiciels. Il sera donc potentiellement aussi consommateur. Par contre, le logiciel libre a une capacité plus forte à intégrer les bonnes pratiques d’efficience. Encore faut-il les implémenter ou au moins commencer à évaluer l’impact de sa solution…

Mythe n°5 – L’impact est plus sur le datacenter, sur les fonctionnalités, sur cela …

Vrai et Faux

Tout logiciel est différent, par son architecture, son usage, son implémentation, ses fonctions… aucune étude sérieuse ne permet de certifier une généralité sur un domaine qui aurait plus d’impacts qu’un autre. Dans certains cas, l’impact sera davantage sur le datacenter (par exemple sur des logiciels de calcul) mais dans d’autres cas il sera côté utilisateur (par exemple les applications mobiles). De la même manière, certains logiciels seront obèses à causes de leurs multiples fonctionnalités alors que d’autres le seront à cause d’un mauvais codage ou d’une librairie externe trop lourde.

Mythe n°6 – L’écoconception nécessite une démarche structurée et globale

Vrai et Faux

Vrai car effectivement il est nécessaire d’impliquer tous les acteurs de l’entreprises (développeur mais aussi Product Owner, Direction métier) et d’avoir une stratégie cohérente.

Cependant, débuter l’amélioration des processus et du produit via des actions unitaires et isolées est très positif. La lourdeur du logiciel est en effet dans un état où n’importe quelle action positive isolée est bonne à prendre.

Les deux approches sont donc complémentaires. Écarter l’application de certaines pratiques en attendant une démarche structurée (qui peut avoir une certaine lourdeur) serait dangereux pour l’optimisation et la compétitivité de vos logiciels.

Mythe n°7- Le green coding n’existe pas, l’optimisation est prématurée…

Faux

C’est un argument qui existe depuis la nuit des temps (du logiciel). Code implémenté, code legacy, librairies… les pistes d’optimisations sont nombreuses. Mes différents audits et accompagnements d’équipes m’ont montré que l’optimisation est possible et les gains importants. Faire croire le contraire serait une erreur. Et au-delà de l’optimisation, apprendre à coder de façon plus green est une démarche d’apprentissage qui est utile à tous les développeurs.

Mythe n°8 – Mon organisation est certifiée green (ISO, numérique responsable, Lucie…), donc mon produit est green.

Faux

Toutes ses certifications vont vous assurer effectivement que vous êtes dans la bonne voie pour produire un logiciel plus respectueux. Loin de moi l’idée de ne dire qu’elles ne sont pas utiles. Cependant il ne faut pas oublier que ce sont des certifications orientées “organisation”. Dans une industrie structurée (comme l’agriculture, une usine…) les livrables de l’entreprise sont très alignés au processus. Certifier une ferme AB va assurer que le produit est bien AB.

Cependant dans le mode du logiciel ce n’est pas si simple, la qualité des livrables est en effet très fluctuante, même si on met en place un processus de contrôle. De plus, une organisation se compose potentiellement d’une multitude d’équipes qui ne vont pas avoir les même pratiques.

Il est donc nécessaire de contrôler les qualités des produits logiciels et cela en continu. C’est une démarche qui sera complémentaire à la certification mais obligatoire. Sans cela on risque de discréditer l’obtention du label (voir d’aller vers du greenwashing).

Mythe n°9 – Optimiser l’énergie ne sert à rien, c’est le CO2 équivalent qu’il est important de traiter

Faux

Le travail d’écoconception se base principalement sur la réduction du CO2 équivalent (ainsi que sur d’autres indicateurs comme l’euthrophisation…) sur l’ensemble du cycle de vie du service numérique. Il est donc important de prendre en compte cette métrique. Sans cela, on risque de passer à côté des impacts de l’IT. Cependant, sur la même idée que les points 5 à 7, aucune optimisation n’est à écarter. Effectivement, il est nécessaire de bien comprendre où se situent les impacts du logiciel. Cependant, l’intégration de la problématique énergétique dans les équipes est urgente. Effectivement, dans certains cas la consommation d’énergie en phase d’usage n’est qu’une partie de l’impact (par rapport à l’énergie grise par exemple). Cependant dans de nombreux cas, la consommation importante d’énergie est un symptôme d’une obésité. De plus, dans les cas des logiciels fonctionnant en mobilité (application mobile, IoT) la consommation d’énergie va avoir un impact direct sur le renouvellement du devices (via l’usure de la batterie).

Mythe n°10 – Je compense donc je suis green

Faux

Il est possible de compenser son impact via différents programmes (financement d’une source d’énergie alternative, reforestation…). C’est une très bonne action. C’est cependant une action complémentaire à un processus d’écoconception. Il est en effet important de séquencer les actions : j’optimise ce que je peux et je compense ce qui reste.

Conclusion

Le numérique sobre est simple car il s’agit de bon sens. Cependant, compte-tenu de la diversité du monde logiciel, les constats et bonnes pratiques ne sont pas si simples. Maisla bonne nouvelle, c’est que vu la lourdeur générale des logiciels et du retard sur l’optimisation qui a été prise, toute action qui sera appliquée sera positive. Donc pas d’inquiétude, commencez les démarches, il est juste nécessaire d’être conscient de quelques pièges. Soyez critiques, évaluez-vous, mesurez vos logiciels !

Découvrez “Pear”, la version 2.5.0 de GREENSPECTOR !

Reading Time: < 1 minute

L’équipe GREENSPECTOR est fière d’annoncer la sortie de sa nouvelle release : version 2.5.0 Pear! Avec cette nouvelle version, vous avez la possibilité de varier le type de connectivité réseau (Wi-Fi, 4G, 3G,2G) lors du lancement de vos tests sur les téléphones du Power Test Bench. Vous pouvez désormais vérifier que votre application est efficiente dans des mauvaises conditions de réseau.

Continue reading “Découvrez “Pear”, la version 2.5.0 de GREENSPECTOR !”

Découvrez “Olive”, la version 2.4.0 de GREENSPECTOR !

Reading Time: 2 minutes

L’équipe GREENSPECTOR est fière d’annoncer la sortie de sa nouvelle release : version 2.4.0 Olive! Avec cette nouvelle version, vous aurez, pour toutes vos étapes de test, des métriques du système Android (en plus des métriques de ressources et d’énergie). Cela vous permet d’analyser plus finement le comportement de l’application et d’identifier les problèmes de conception. Dans cette même perspective, vous aurez avec cette version, plus de finesse dans les données en distinguant celles transmises de celles reçues ainsi que la possibilité de mesurer plusieurs packages. Détails des améliorations ci-dessous.

Continue reading “Découvrez “Olive”, la version 2.4.0 de GREENSPECTOR !”