Catégorie : Zone technique

Dans cet article, nous allons voir plus en détail comment est calculé l’écoscore dans le cas d’un benchmark web réalisé par Greenspector.  

Et dans les autres cas ? 

Comme vous le savez peut-être déjà, Greenspector réalise également des mesures sur applications mobiles. Dans le cas des applications Android, il est possible de réaliser facilement un benchmark. On reste sur une méthodologie standard : mesures sur les étapes de chargement, pauses et référence. L’écoscore est là aussi calculé à partir des écoscores Réseau et Ressources Client. La seule différence notable est que la mise en œuvre des bonnes pratiques n’est pas contrôlée automatiquement et n’entre donc pas dans le calcul.  

Aussi, dans certains cas, il est plus judicieux de mesurer directement un parcours utilisateur afin d’être au plus près du comportement du site dans ses conditions réelles d’utilisation. Que ce soit dans le cas du web ou d’une application mobile, Greenspector réalise les mesures (toujours sur terminaux utilisateurs réels) après automatisation du parcours (via le langage GDSL). L’écoscore est ensuite établi à partir des métriques représentées via 3 écoscores : Données mobiles, Performance et Energie.

Qu’est-ce qu’un benchmark web ? 

Afin d’évaluer les impacts environnementaux des sites web, Greenspector dispose de plusieurs modes opératoires et outils. Le plus simple à mettre en place est le benchmark web. Cette méthodologie standard permet de mesurer n’importe quelle page web et de la comparer avec d’autres pages.

Les mesures sont effectuées sur un smartphone réel disponible sur notre banc de test, le plus souvent en WIFI (même si d’autres modes de connexion, type 3G ou 4G par exemple, sont possibles) et avec le navigateur Chrome.  

Une telle mesure dure 70 secondes et inclut :  

• Le chargement de la page 
• Une étape de pause avec la page affichée au premier plan 
• Une étape de pause avec la page affichée à l’arrière-plan 
• Le scrolling sur la page 

A ceci s’ajoute une mesure de référence sur un onglet vide de Chrome.  

Plusieurs itérations de mesure sont réalisées afin de s’assurer de leur stabilité. 

On récupère ainsi des métriques sur les données transférées mais aussi l’impact sur le terminal de l’utilisateur et en particulier sur la décharge de la batterie. En plus de cela, la bonne mise en œuvre d’une trentaine de bonnes pratiques est vérifiée automatiquement.  

Ensuite, les indicateurs environnementaux sont calculés en tenant compte quand c’est possible des statistiques réelles d’utilisation de la page. Vous trouverez davantage d’informations à ce sujet dans la page dédiée sur le blog Greenspector. 

Une fois toutes ces informations disponibles, il devient facile de comparer différentes pages web, qu’elles soient ou non sur le même site. C’est ce mode opératoire qui est utilisé notamment dans le cadre des classements de sites proposés sur ce blog mais aussi à la demande d’un client afin d’établir un état des lieux sur un ou plusieurs de ses sites web et de proposer un plan d’action. Ce peut aussi être un moyen de construire un benchmark concurrentiel permettant de se positionner par rapport à un échantillon de sites similaires.  

Vous pouvez d’ores et déjà avoir un aperçu de tout ceci via le Mobile Efficiency Index (MEI) mis à disposition par Greenspector afin d’évaluer gratuitement l’impact d’une page web.  

Il ne nous reste pour l’heure qu’à voir comment est calculé l’écoscore dans le cadre d’un benchmark web.  

Calcul de l’écoscore pour un benchmark web 

Tout d’abord, l’écoscore établi pour une page web est la moyenne de deux valeurs :  

• Un écoscore Ressources Client qui reflète la façon dont les ressources client sont gérées du point de vue de la sobriété lors de l’accès à cette page 
• Un écoscore Réseau qui reflète la sollicitation du réseau (et des serveurs)

Ecoscore Ressources Client

L’écoscore Client repose sur 12 contrôles effectués sur les métriques directement récupérées sur le terminal utilisateur (et collectées via son système d’exploitation). Celles-ci concernent entre autres les données transférées mais aussi la décharge de la batterie, le CPU et la mémoire. Pour chacune, 4 à 5 seuils sont définis afin de déterminer les valeurs acceptables. En fonction de ces seuils, une note est calculée. Les notes pour l’ensemble des métriques sont ensuite agrégées afin de calculer l’Ecoscore Client.  

Par exemple : 

• La note maximale concernant les données transférées lors du chargement de la page ne pourra être obtenue que si leur poids total est inférieur à 500 ko 
• Pour la décharge de la batterie, on compare à celle mesurée lors de l’étape de référence décrite précédemment 

Les seuils utilisés sont définis via une base de mesures afin de pouvoir, en fonction de la répartition statistique des mesures précédemment obtenues, déterminer les seuils attendus.

Ecoscore Réseau

Aujourd’hui, la méthodologie Greenspector repose sur des mesures uniquement réalisées sur des terminaux utilisateurs réels. En conséquence, la définition de l’écoscore Réseau est légèrement différente. Elle repose sur deux éléments :  

• La comparaison des métriques liées au transfert de données avec des seuils définis de façon similaire à ceux utilisés pour le calcul de l’écoscore Client 
• La vérification automatique de la mise en œuvre d’une trentaine de bonnes pratiques 

Ainsi, par exemple, on s’assure que les ressources textuelles sont bien compressées côté serveur, que les images ne sont pas retaillées dans le navigateur et qu’il n’y a pas plus de 25 requêtes HTTP en tout. Il s’agit donc ici de bonnes pratiques techniques (plutôt orientées efficience) que l’on retrouve dans la plupart des référentiels de bonnes pratiques d’écoconception ou de conception responsable de services numériques.

Conclusion

Tous ces éléments font du benchmark web un procédé très efficace pour évaluer les impacts d’une page web et la comparer avec d’autres pages web. Il s’agit aussi d’un excellent moyen d’amorcer une analyse plus poussée, notamment en regardant en priorité les pages les plus impactantes d’un site. Dans certains cas, il sera d’ailleurs plus judicieux de commencer par les pages les moins impactantes. Un défaut de conception sur une page plus impactante lui sera souvent propre alors que, sur une page moins impactante, il sera souvent commun à l’ensemble des pages.  

Le benchmark web, entre autres via le calcul de l’écoscore, illustre une fois de plus la nécessité d’utiliser à la fois des mesures et des bonnes pratiques dans une démarche de réduction des impacts environnementaux d’un service numérique.  

Introduction

Request Map Generator est un outil disponible via webpagetest.org pour afficher une visualisation des différents noms de domaine appelés lors du chargement d’une page web. Les objectifs sont multiples :  

• Identifier les services-tiers utilisés sur la page 
• Identifier quels composants appellent ces services-tiers
• Quantifier leur usage et leur impact afin de les challenger 
• Identifier les principaux leviers d’actions

Par exemple, sur cette RequestMap, on constate que l’intégration de Twitter et Linkedin sont responsables du téléchargements de 71 ko de JavaScript. On observe également l’enchainement de requêtes conduisant jusqu’à Google. 

Le problème est que l’outil est mis à disposition pour auditer des sites web. Qu’en est-il des applications mobiles ? Nous proposons une démarche assez simple à mettre en œuvre pour générer la request map d’applications mobiles. 

HAR mapper

Le développeur de RequestMap, Simon Hearne, met également à disposition l’outil HAR mapper qui génère les mêmes request maps à partir de fichiers HAR. Les HAR sont des fichiers JSON qui permettent d’enregistrer le traffic capturé par divers outils d’analyse web comme les DevTools. Ainsi, plutôt que de demander un test entier de la suite webpagetest, on peut très bien choisir, d’enregistrer un fichier d’archive HTTP (.har) sur son propre PC. Cela nous permet de bâtir des RequestMaps plus précise, qui vont au-delà de la page d’accueil, tout en étant plus sobre numériquement. 

L’autre avantage est que l’on est désormais en mesure d’analyser des applications mobiles en utilisant un proxy SSL, sous condition que l’application autorise une certaine configuration réseau (voir Autoriser l’accès au certificat de Charles par l’application). 

CharlesProxy, le couteau-suisse du développeur 

Un proxy est un serveur qui sert d’intermédiaire entre le serveur et le client. Ce dernier envoie les requêtes au proxy qui est ensuite chargé de communiquer avec le serveur. Cela permet au proxy d’observer les différentes requêtes qui sont échangées. En outre, si le client accepte le certificat CA du proxy qui agira ainsi comme une Certificate Authority, le proxy sera capable de déchiffrer les requêtes HTTPS pour inspecter leur contenu. 

Charles Proxy est un serveur proxy dont l’usage est orienté pour les développeurs mobiles. En plus, d’agir comme un Proxy SSL, il propose de réécrire à la volée les headers (ou même le contenu !) des requêtes échangées. Il permet de tester la stabilité d’une application par rapport à des conditions de réseau, ou des problèmes serveur (throttling, répétition des requêtes, pas de cache, etc.). Dans notre cas, ce qui nous intéresse le plus est que Charles permet de sauvegarder les échanges client-serveur enregistrés sous forme de fichier .har. 

Nous proposons d’utiliser Charles Proxy car c’est un outil facile d’utilisation et assez complet mais sachez que d’autres serveurs proxy peuvent servir pour ce cas d’usage. Comme alternatives, il existe notamment mitmproxy, un outil en ligne de commande open-source ou HTTP toolkit très simple d’utilisation en version payante. 

Installer et configurer Charles 

Télécharger Charles et l’installer. Le serveur proxy est configuré automatiquement au lancement de Charles et les requêtes qui passent par lui sont enregistrées.  

Par défaut Charles n’active le SSL proxying uniquement pour une liste restreinte de noms de domaines. Pour changer ce comportement, aller dans Proxy > SSL Proxying settings. Vérifier que le SSL proxying est activé et ajouter une entrée * au tableau Include: 

Configurer le smartphone 

Il reste désormais à configurer notre smartphone Android pour se connecter à Charles. Le téléphone doit être dans le même réseau local que le PC sur lequel Charles est lancé. Dans les paramètres Wi-Fi, dans la configuration du réseau, définir le Proxy comme “Manual”. Rentrer l’adresse IP du PC sur lequel tourne Charles et définir le port de Charles (8888 par défaut). 

Si tout se passe bien, dès que le smartphone échange avec le réseau, Charles nous demande d’accepter ou de refuser la connexion au proxy. 

En acceptant, Charles devrait commencer à intercepter les échanges réseaux des applications. Néanmoins, les requêtes ne se font pas correctement. En effet, il nous reste à installer le certificat de Charles sur le téléphone. 

Installer le certificat de Charles 

Ouvrir le navigateur du smartphone, et visiter chls.pro/ssl. Le téléchargement du certificat se fait automatiquement. Si le fichier est ouvert, Android propose de l’installer, sous condition qu’un code PIN verrouille le téléphone. 

Attention à partir d’Android 11, la procédure est rendue plus compliquée. (Visiter l’aide de Charles pour installer le certificat sur d’autres systèmes). 

Il nous est désormais possible de transférer les requêtes émises par le processus de Chrome mais pas celles d’autres applications. En effet, pour raison de sécurité par défaut les applications Android n’acceptent que les certificats “système” (Ce n’est pas le cas pour iOS qui propose d’ailleurs une application Charles sur l’App Store). 

Autoriser l’accès au certificat de Charles par une application Android 

Trois cas de figure se présentent: 

1. Vous disposez du code source de l’application. 
   
   Dans ce cas, il vous est facile d’autoriser l’usage de certificats CA “utilisateur”. Pour cela, ajouter un fichier `res/xml/network_security_config.xml` définissant les règles de configurations réseaux de l’application: 

<?xml version="1.0" encoding="utf-8"?> 

<network-security-config> 

<base-config cleartextTrafficPermitted="true"> 

<trust-anchors> 

<certificates src="system" /> 

<certificates src="user" overridePins="true" /> 

</trust-anchors> 

</base-config> 

</network-security-config> 

Il faut également spécifier son chemin dans le AndroidManifest.xml: 

<?xml version="1.0" encoding="utf-8"?> 

<manifest ... > 

<application android:networkSecurityConfig="@xml/network_security_config" ... > 

... 

</application> 

</manifest> 

Penser à ne garder cette configuration seulement pour l’application de debug, car elle peut engendrer des problèmes de sécurité MAJEURS. Voir la documentation officielle pour plus de détails. 

2. Vous ne disposez que de l’apk de l’application. 

Dans ce cas il vous faudra décompiler l’application, utiliser la même méthode qu’en 2. et recompiler l’application et signer l’apk résultant. Pour cela certains outils (apk-mitm ou patch-apk) pourront vous aider dans le processus. La méthode n’est cependant pas garantie de fonctionner car l’application peut implémenter une vérification de la signature de l’apk. 

Attention ! En France, la décompilation d’un logiciel est strictement encadrée par la loi qui définit dans quels cas elle est légale. Dans le doute, assurez-vous d’obtenir l’autorisation de l’éditeur au préalable !

3. Le smartphone de test est rooté. 

Dans ce cas, vous pouvez installer le certificat dans les certificats root du téléphone. 

Une fois que le certificat peut être utilisé par l’application, nous sommes en mesure d’inspecter les échanges entre le smartphone et le serveur. Pour générer un fichier .har, sélectionner toutes les requêtes, clic droit dans Charles sur les échanges réseaux > Export Session… et exporter en HAR.

Importer le fichier dans HAR Mapper, et nous avons notre Request Map ! 

Méthodologie d’évaluation d’empreinte environnementale

Notre approche

La modélisation choisie s’appuie sur les principes d’Analyse du Cycle de Vie (ACV), et principalement par la définition donnée par l’ISO 14040. ​​

Elle se compose d’une partie Inventaire du cycle de vie (ICV) complète et d’une Analyse du cycle de vie (ACV) simplifiée. L’ICV est prépondérant dans notre modèle. Il va permettre de s’assurer d’avoir des données fiables et représentatives. De plus, l’ICV ainsi obtenu peut le cas échéant être intégré dans des ACV plus poussées.

Nous évaluons l’impact environnemental des services numériques sur un ensemble limité de critères :

Les Emissions de Gaz à Effet de Serre (GES)

exprimée en g eqCO2,

telles que couramment utilisées, indiquent l’intensité de l’impact sur le changement climatique

La ressource en Eau

exprimée en Litres,

telle que définie par le water footprint network, est un indicateur reflet de la consommation en eau (eau bleue) mais aussi la quantité de polluants utilisés (eau grise). Il ne tient pas compte de la rareté locale des ressources mais il est un indicateur parlant.

L’occupation des sols

exprimée en m2,

ou land use en anglais, telle que définie originellement par Heijungs et al. (1992), est un indicateur reflet de l’impact sur la biodiversité. Il n’est pas le plus exhaustif (indépendant du temps normalement, mais c’est le plus utilisé actuellement).

Cette méthodologie a été revue par le cabinet EVEA – spécialiste en écoconception et analyses de cycle de vie.
Note sur l’eau : L’eau grise et l’eau bleu sont prises en compte sur toutes les étapes du cycle de vie. L’eau verte est ajoutée sur le cycle de fabrication des terminaux et des serveurs. Retrouvez la définition de l’empreinte Eau.

Gestion de la qualité des résultats

La qualité des résultats d’une ACV peut être modélisée de la façon suivante¹ :​​

Qualité des données d’entrée  x  Qualité de la méthodologie  =  Qualité des résultats

Pour améliorer la qualité des données d’entrée, nous mesurons le comportement de votre solution sur des terminaux réels. Cela permet de limiter les modèles qui sont potentiellement sources d’incertitude.​

Pour gérer la qualité des résultats, nous appliquons une approche qui permet d’identifier les sources d’incertitudes et de calculer l’incertitude du modèle. Notre méthode de gestion des incertitudes utilise la logique floue et ses ensembles².

Au final, contrairement à d’autres outils et méthodologies, nous pouvons fournir des marges d’erreurs par rapport aux résultats que nous vous donnons. Cela permet d’assurer une communication de l’impact environnemental plus sereine vers les parties prenantes (utilisateurs, équipes internes, partenaires…)

¹Qualité des resultats : SETAC (Society of Environmental Toxicology and Chemistry 1992)

_²Bien que mentionnée souvent dans la littérature traitant d’incertitudes en ACV, cette approche est peu utilisée. En effet les modèles stochastiques comme les simulations de Monte Carlo sont souvent préférés (Huijbregts MAJ, 1998). Dans notre cas, l’utilisation de la logique floue semble plus pertinente, car elle nous permet de gérer les inexactitudes épistémiques, notamment dues à des estimations d’expert. ​ ​

Étapes de calcul

Phases prises en compte pour le matériel utilisé

« Phases prises en compte dans le cycle de vie des matériels ​qui sont mobilisés en phase d’usage du service numérique »​

Note sur le modèle d’impact de la partie terminal

Les méthodologies classiques d’analyse d’impact prennent comme hypothèse un impact uniforme du logiciel (consommation moyenne quel que soit le logiciel ou l’état du logiciel). Notre approche innovante permet d’affiner cet impact. De plus, nous améliorons la modélisation de l’impact du logiciel sur la phase de fabrication du matériel en prenant en compte l’usure de la batterie.

La batterie des smartphones et PC portables est un consommable, nous modélisons l’impact du logiciel sur celui-ci.​

Données d’entrée de l’Inventaire du Cycle de Vie

Exemple de travail sur les hypothèses :

La méthodologie de propagation des incertitudes nous oblige à identifier précisément la qualité de ces hypothèses. Voici quelques exemples, en particulier l’impact de fabrication du matériel.

L’analyse bibliographique nous permet d’identifier les impacts de différents smartphones et d’associer l’indice de confiance DQI. Ces chiffres sont principalement issus des constructeurs.

L’impact moyen calculé à partir de ces indices de confiance est de 52 kg eq Co2 avec un écart type de 16 kg.

Exemple de restitution

• Dans cet exemple : impact médian de 0,14g eqCO2 principalement sur la partie « Réseau ».​
  
  
• Cet impact correspond à la visualisation d’une page web pendant 20s
  
  
• L’incertitude est calculée par le modèle Greenspector en appliquant le principe de propagation des incertitudes à partir du périmètre et de hypothèses décrits précédemment.

Éléments nécéssaires

Afin de déterminer l’impact de votre solution, nous avons besoin des informations suivantes :​​

• Ratio de visualisation Smartphone/Tablette/PC ​
• Ratio de visualisation France/Monde​
• Localisation des serveurs France/Monde​
• Serveurs simples ou complexes (ou nombre de serveurs de la solution)

Sur devis, nous pouvons réaliser une ACV simplifiée se basant sur ce modèle mais adaptant d’autres éléments à contre cas particulier. Par exemple:​

• Mesure de la consommation d’énergie de la partie serveur (via un partenaire)​
• Précision des hypothèses serveur (PUE, type de serveur)​
• Mesure de la partie PC (via mesure laboratoire)​
• Précision des facteurs d’émissions électriques d’un pays en particulier…

Comparatifs des modèles d’estimation

Les calculs Greenspector sont intégrés dans un webservice actuellement utilisé par nos clients. Retrouvez très prochainement nos calculs d’empreinte environnementale de vos applications mobiles et sites web dans une interface SaaS.

Incertitudes – méthode de calcul

Les méthodes de calcul dans la sobriété numérique sont souvent peu justes et parfois, en même temps, peu fidèles.  Ceci vous amène potentiellement à utiliser des outils qui évaluent mal l’impact de vos solutions. Le risque est de faire travailler vos équipes sur des axes qui n’ont pas d’impact réel sur l’environnement.​

Certaines approches, plus utilisés dans les ACV (et pas dans les outils du marché), améliorent la fidélité mais posent un risque de donner un résultat peu juste (R. Heijungs 2019). ​

Notre approche repose sur une méthode de calcul innovante, l’arithmétique floue, proposée pour la première fois par Weckenmann et al. (2001).​

Cette approche est très performante pour modéliser des données vagues (épistémiques) non-probabilistes, ce qui est souvent le cas de données traitant de sobriété numérique. Nous ciblons de cette manière des résultats justes et fidèles.

Les solutions concurrentes font des choix qui les rendent généralement peu fidèles et peu fiables:​

– Fidélité : Faible maîtrise de l’environnement, pas de méthodologie de gestion des écarts de mesures​

– Justesse : Modèle basé sur des métriques non représentatives comme la consommation de données ou la taille du DOM, pas de mesure d’énergie…

Plus une URL est très couramment consultée, plus réduire son impact numérique est essentiel. Une simple mesure permet de vérifier et réagir face aux changements effectués sur la page : modifications liées à la charte graphique, à des évènements (les sites e-commerce en période de soldes) ou même des modifications techniques. Tous ces changements peuvent avoir un impact fort sur le niveau de sobriété d’une page web.

Quand intégrer la mesure de sobriété numérique d’une URL ?

Ces mesures peuvent être intégrées dans le cadre d’un monitoring quotidien sur n’importe quelle page. Des pages dynamiques dont le contenu est amené à régulièrement évoluer telles que des pages d’accueil e-commerce ou de site d’information presse sont importantes à monitorer. Même des pages moins « dynamiques » pourront être elles-aussi ciblées : la mise à jour d’une librairie CDN peut, par exemple, impacter ce type de site. Dans ce cas, la mesure permettra de s’assurer que le nouvel habillage de la page n’a pas un impact négatif sur le niveau de sobriété du site web : une image trop lourde pour une bannière pourra être facilement repérée.

La mesure peut aussi être utilisée lors de la phase de développement pour tester des choix avant la mise en production ou pour rectifier très tôt des changements trop impactants. Il est souvent difficile de changer le choix d’une technologie ou d’une implémentation une fois qu’un site est mis en production, la mesure d’une URL pendant la phase de développement permet de tester très tôt différentes options et de voir laquelle correspond le mieux en prenant en compte la sobriété numérique comme un des critères.

Exemple d’un suivi quotidien d’une page web

Comment mesurer la sobriété numérique d’une URL ?

Plusieurs possibilités s’offrent à vous chez Greenspector pour mesurer une URL.

Un premier outil nous permet d’effectuer une première mesure simple d’une URL et obtenir des constats rapides : l’outil Benchmark basé sur des tests standardisés.

Pour aller plus loin, nous pouvons effectuer la mesure d’un parcours utilisateur complet sur un site web grâce à App Scan. En général ce genre de mesure est effectuée pour représenter le chemin complet sur un site web ou application mobile, comme un parcours d’achat ou la réalisation d’un virement bancaire. Il permet d’identifier les points sur lesquels se concentrer pour obtenir rapidement une amélioration significative. Dans le cadre d’un App Scan, la mesure d’une URL est également possible via un parcours automatisé ce qui va permettre l’obtention de métriques spécifiques au-delà du benchmark.

Mesure d’URL (via App Scan) vs Benchmark

Voici les différentes étapes mesurées lors d’une mesure URL (via AppScan) vs l’outil Benchmark :

La mesure URL (via App Scan) contient plus d’étapes que le benchmark, nous y reviendrons. Contrairement au benchmark, la mesure URL est plus précise sur les chargements, la durée mesurée étant la durée réelle du chargement contrairement à l’outil benchmark qui réalise les mesures sur une durée fixe de 20 secondes. Une autre différence importante est qu’une mesure URL gère les fenêtres présentes sur la page, en particulier celles qui concernent les cookies, ce que ne fait pas l’outil benchmark.

Enfin, la mesure URL via App Scan par Greenspector permet de réaliser des mesures sur d’autres navigateurs que Google Chrome. L’outil benchmark est limité à ce dernier navigateur mais notre expertise GDSL nous permet de proposer un autre navigateur tel que Firefox par exemple pour aller encore plus loin.

Les étapes d’une mesure d’URL (via App Scan)

• Chargement sans cache : Il s’agit du chargement de l’URL en ayant préalablement vider le cache et supprimer tous les cookies. Cette étape permet de mesurer le chargement de la page web lorsqu’un utilisateur s’y rend sans cache. C’est particulièrement important pour les URLs avec beaucoup de visites uniques.
• Pause après chargement sans cache : La mesure d’une courte pause après le chargement permet de récupérer les échanges de données et autres opérations qui s’effectuent encore alors que l’affichage de l’écran est terminé. L’idéal étant bien entendu de n’avoir rien de tout ça. Dans le cas contraire cela nous permet de faire des constats et de proposer des pistes pour faire disparaitre ou réduire ces traitements. 
• Pause sur la page sans cache : La mesure de pause sur la page représente l’action d’un utilisateur en train de lire le contenu. Aucun mouvement sur l’écran. L’idée de cette étape est de mesurer l’impact de l’affichage continu de la page.  
• Scroll sur la page : Défilement jusqu’en bas de la page permettant de réaliser des constats sur les traitements pendant le scroll. Ici nous pouvons faire des constats sur les possibles échanges de données (pagination, téléchargement d’image, publicité) ainsi que la fluidité associée. 
• Pause sur la page après le scroll : Mesure de pause après le défilement permettant d’observer des traitements qui continuent après la fin des interactions utilisateur.  
• Chargement avec cache : Mesure du chargement de l’URL avec le cache des intéractions précédentes (chargement, scroll). Cette étape permet de constater l’impact de la mise en cache sur le site. C’est important pour les pages amenées à être consultées un grand nombre de fois par des visiteurs connus, comme par exemple une page d’accueil d’un site internet. 
• Pause sur la page avec cache : La mesure de pause sur la page permettant de voir si malgré le cache il y a des traitements après le chargement.

Grâce à nos outils et notre expertise nous pouvons proposer des mesures fiables et pertinentes sur une URL. Que ce soit une mesure simple permettant des premiers constats à l’aide de notre outil de benchmark ou une mesure plus poussée avec notre langage GDSL. Ce monitoring régulier d’URL permet d’améliorer progressivement le niveau de sobriété de son site web. Cette approche par rapport à d’autres approches courament utilisées dans le web (Analyse uniquement du chargement de la page avec Lighthouse ou autres…), apporte plus de finesse sur la connaissance de la consommation de la page.

Qu’est-ce que le GDSL ?

Le terme GDSL signifie Greenspector Domain-Specific Language. Il s’agit d’un langage créé par Greenspector pour simplifier l’automatisation de test sur Android et iOS. Concrètement c’est une surcouche basée sur les frameworks d’automatisation de Google et d’Apple agrémentée de fonctions pour faciliter l’automatisation de test. 

Ce langage est le fruit de l’expertise Greenspector accumulée depuis plusieurs années déjà. Il combine la simplicité d’écriture à la possibilité de mesurer les performances énergétiques d’une application ou d’un site internet. 

Le principe du GDSL est d’être un langage de description des actions qui seront effectuées sur le smartphone. En ce sens il peut être rapproché du Gherkin avec qui il partage la qualité de ne pas nécessiter de formation de développeur pour être lu.

Le GDSL est une suite d’actions qui seront exécutées dans l’ordre par le smartphone. Il dispose des actions basiques que sont les WAIT, CLICK ou encore PAUSE ainsi que d’actions plus complexes comme le lancement d’application ou la gestion du GPS. 

Avec le GDSL il est possible d’automatiser rapidement la plupart des parcours critiques de vos applications ou site web mobile. 

L’équipe Greenspector travaille au quotidien pour améliorer le langage et ajouter des fonctionnalités. L’état actuel permet d’automatiser la plupart des scénarios nécessaires à une campagne de mesure complète d’une application ou d’un site web ainsi que les parcours critiques de la plupart des applications. Dans un prochain article, nous vous parlerons des outils Greenspector permettant l’exécution des tests GDSL.

L’équipe Greenspector est fière d’annoncer la sortie de sa nouvelle release : la version 2.9.0.

Afin de mesurer la consommation des applications et des sites web, vous pouvez exécuter des parcours utilisateurs sur nos fermes de smartphone. Dans ce contexte, nous avons amélioré notre langage de test simplifié (le GDSL) avec par exemple des fonctionnalités de préparation des browsers, prise en compte de Firefox… Contrairement à de nombreux outils qui vous fournissent un impact environnemental uniquement sur la page principale et sur des environnements simulés, ces capacités vous permettront d’évaluer et de suivre précisément l’impact de votre solution numérique !

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 :

• Monitoring synthétique via le benchmark runner sur les devices réels du Power Test Cloud
• Intégration de la mesure de performance dans les tests fonctionnels existants
• Débuggage des problèmes via les tests exploratoires avec le Free Runner Test
• Monitoring en continu lors du build ou du run

L’automatisation des tests est bien souvent considérée comme un surcoût au sein des équipes de développement, et cela pour différentes raisons :

Nécéssite une montée en compétence des équipes sur un outil en particulier

Les temps de rédaction sont plus importants que les temps d’éxécution manuels

Nécéssite un maintien des tests sur la durée

…

Le développement mobile comprenant des coûts projets plus faibles et des temps de développement raccourcis n’aide pas au passage à l’automatisation des tests. Les bénéfices ne sont en effet pas forcément bien évalués vis-à-vis du coût de l’automatisation. Au final, les projets d’automatisation des applications mobiles passent souvent à la trappe ou sont décalés trop tard dans le projet. C’est une erreur car les bénéfices de l’automatisation des tests pour les applications mobiles sont nombreux.

Les applications mobiles sont des applications comme les autres : complexes, techniques…

Les applications mobiles sont considérées comme des applications nécessitant peu de développement, des coûts faibles… Or ce n’est pas toujours le cas. Nous ne sommes plus dans la même situation des dernières années où les projets d’applications mobiles étaient des Proofs Of Concept et autres balbutiements. Les applications mobiles ont maintenant subi l’entropie naturelle de tout projet logiciel : contraintes de sécurité renforcées, librairies et SDK intégrées, architectures modulaires, intéractions multiples avec des serveurs backend…

Cette maturité (mélée à l’entropie des logiciels) ne permet plus de laisser de côté les tests. Une industrialisation des tests, et en particulier l’automatisation, permet d’assurer une qualité nécessaire aux projets mobiles. Sans cela, c’est un échec assuré.

L’échec n’est plus envisageable

Associées à cette complexification des projets mobiles, les applications sont devenues des projets critiques pour les entreprises. En effet, elles sont les nouvelles vitrines des marques et des organisations. Et compte-tenu des cycles de développement rapides, un échec du projet (retards, détection trop tardive de bugs utilisateurs…) peut être fatal à l’image de l’entreprise. D’autant plus qu’une mauvaise expérience vécue par l’utilisateur peut amener tout simplement à la désinstallation, la non-utilisation de l’application ou encore la rédaction d’un avis négatif sur les stores.

Le niveau de qualité doit donc être au rendez-vous et les tests automatisés sont un passage obligé pour contrôler la performance de son application.

Tester c’est douter, le doute est bon

Une équipe de développement de qualité, un processus « carré » et des tests manuels pourraient permettre d’assurer cette qualité. Tester serait mettre en doute les compétences de l’équipe ? Non, car comme le stress du funambule qui lui permet de traverser le ravin, le doute est bon pour la qualité. Un SDK avec un comportement inattendu, une regression non-désirée… Autant assurer avec des tests.

L’automatisation permet de faire du Test Driven Development (TDD)

Anticiper l’automatisation va permettre de plus d’aller vers des pratiques de Test Driven Development. Rédiger les tests avant le développement est tout à fait possible dans les projets mobiles. Avec ou sans outillage, il est intéressant d’automatiser un scénario spécifié et de le lancer en cours de développement.

Et sans parler de Test Driven Development, le fait d’avoir des tests qui suivent de près le développement permettra de détecter au plus tôt des problèmes et autres bugs.

La fragmentation des plateformes ne peut être géré avec des tests manuels

Tester manuellement sur un device uniquement ne permet plus de s’assurer du bon fonctionnement d’une application. La diversité des matériels avec des configurations matérielles et logicielles variées est source de bug. Tailles d’écran différentes, surcouches constructeurs… une automatisation va permettre de lancer des tests en parallèle sur différents devices et de détecter des potentiels bugs. On évitera comme cela de confondre utilisateurs finaux et bêta-testeurs de l’application !

Maîtriser les régressions en maintenance

La sortie de la première release de l’application n’est que le début du cycle de vie de l’application. 80% de la charge de développement correspond à de la maintenance et à l’évolution de l’application. Il est donc nécessaire de se projeter sur la durée. En automatisant, on va ainsi éviter d’ajouter des régressions dans l’application. Le lancement des tests sera systématique à chaque évolution de l’application.

L’automatisation permet d’avoir des métriques de performance

Au final, l’automatisation va permettre de suivre d’autres exigences que les exigences fonctionnelles : les exigences non-fonctionnelles. En effet, associés à des outils des mesures, les tests automatisés vont permettre de remonter de nouvelles métriques : performance, consommation de ressources…

C’est la stratégie que GREENSPECTOR préconise à ses utilisateurs. En intégrant l’API GREENSPECTOR dans les tests automatisés, ils peuvent suivre à chaque campagne de test : l’efficience et la performance de leur développement. Le coût de l’automatisation est alors largement couvert par les bénéfices. CQFD

Android 9 Pie (API level 28) introduit une nouvelle fonctionnalité de gestion de la batterie : l’Adaptive Battery. En fonction de l’usage des applications par l’utilisateur, le système va restreindre certains mécanismes pour ces applications.

Nouveauté Android 9 : Adaptive Battery

Le système priorise l’usage des ressources d’après la fréquence d’usage des applications ainsi que le temps écoulé depuis leur dernière utilisation. 5 classes d’applications (buckets) ont été mises en place :

• Active : L’utilisateur utilise fréquemment l’application. Certains critères d’architecture sont également pris en compte : lancement d’une activité, service foreground [premier-plan], utilisateur qui clique sur une notification…
• Working set : L’application est utilisée fréquemment mais n’est pas tout le temps active. Une application de type réseau social sera par exemple assignée en Working set. Une application utilisée indirectement sera aussi dans cette classe.
• Frequent : L’application est utilisé fréquemment mais pas forcément quotidiennement.
• Rare : Une application utilisée de façon irrégulière. Par exemple une application de réservation de vol d’avion pour un particulier.
• Never : L’application a été installée mais jamais utilisée.

L’algorithme se base sur l’intelligence artificielle (IA), il est probable que l’apprentissage de l’usage prenne plusieurs jours. Il est probable que beaucoup d’applications seront attribuées à la classe Frequent voire Rare. Les applications system ou Google (Maps, Appareil photo…) seront probablement en Working Set et les applications usuelles (banque, voyage…) risquent d’être classées comme Frequent. L’implémentation pourra aussi dépendre du constructeur du smartphone.

Restrictions liées à l’Adaptive Battery

En fonction des buckets, plusieurs restrictions seront mise en place :

• Job
• Alarm
• Network
• Firebase Cloud Messaging

Cela signifie plusieurs fonctionnalités de vos applications pourraient être impactées :

• Requête réseau pour mettre à jour des ressources
• Téléchargement d’information
• Tâche de fond
• Appel périodique d’API système

Les restrictions seront les suivantes :

Comment améliorer le classement de son application ?

L’une des manières d’éviter d’être déclassé est l’attribution est que l’utilisateur place votre application dans la whitelist Doze. En effet, les applications figurant sur cette liste blanche sont exemptées des restrictions.

• Si votre application n’a pas de launcher activity, il faut penser à en implémenter une si possible.
• Il est important que vos utilisateurs puissent interagir avec les notifications.
• N’encombrez pas votre utilisateur de trop de notifications, sinon ce dernier pourrait les bloquer et votre application serait déclassée.

La difficulté de tester

Il va être difficile de prévoir dans quelle classe votre application sera affectée. Il est probable que l’usage des utilisateurs sera fragmenté et votre application pourra se retrouver dans chacune des 5 classes. Si vous souhaitez connaître la classe de votre application (mais dans le cas de votre usage), vous pouvez utiliser l’API :

Il est cependant nécessaire de tester votre application dans les différents cas. Pour cela vous pouvez placer l’application dans la classe voulue avec ADB :

adb shell am set-standby-bucket packagename active|working_set|frequent|rare

Il est évident que la durée des tests va être plus longue.

À noter que si vous avez une application multi-apk, il est possible que tous les APK n’aient pas la même classe. Il est alors important de réfléchir à une stratégie de test adaptée.

L’Adaptive battery réduit-elle réellement la consommation de batterie ?

Avec l’annonce de cette nouvelle feature (associée au buzzword d’Intelligence Artificielle) de nombreuses spéculations sur le fonctionnement ont été entendues : Android mettrait en mémoire les applications les plus utilisées, permettrait des gains importants en énergie… Google annonçait 30% de gain CPU sur le lancement de l’application. Or ce chiffre correspondait en fait plus à des mesures réalisées dans le contexte Google. On est plus probablement autour de 5% de réduction. L’implémentation de l’Adaptive battery est en effet plus restreint : en fonction de l’usage, certains traitements, surtout en tâche de fond, sont décalés. Cela permet par exemple dans certains cas où l’utilisateur n’aurait plus de batterie de les reporter à une période où l’appareil sera branché. On décale donc le traitement, mais il n’est en aucun cas supprimé. (Source). L’Adaptive battery permettra probablement plus de gain au fur est à mesure que les développeurs utiliseront les alarms et les jobs. L’Intelligence Artificielle qui réduirait drastiquement la consommation d’énergie est une cible pour Android mais nous n’assistons qu’à ces débuts.

On le voit, les différentes versions Android amènent de plus en plus des fonctionnalités de gestion d’énergie (Doze, Adaptive battery…). Les gains pour les utilisateurs sont en revanche difficilement chiffrables. En tout cas, nous n’assistons pas à une explosion de la durée d’autonomie des smartphones. Cependant, cela amène une visibilité supplémentaire pour les applications qui sont détectées en tant que trop consommatrices par le système. Et l’impact est alors fort pour l’application, car l’utilisateur, une fois prévenu, risque tout simplement de la désinstaller.

Au final, que faire ?

Il est difficile de prévoir comment le système va percevoir une application donnée (Fréquemment utilisée, rarement…). Cependant trois axes sont importants :

• Une application efficiente, fluide et bien conçue sera probablement plus souvent utilisée. Au-delà des bonnes pratiques que l’on donne dans cet article, il est important d’avoir un niveau de qualité élevée pour son application. Cela implique plus de test, un contrôle élevé de la qualité, la mesure des métriques de consommation de ressources et d’énergie…
• Les traitements en tâches de fond via Alarmes et Jobs ainsi que les traitements réseaux sont ciblés par Android. Il est important de concevoir une architecture d’application efficace et de tester le comportement de ces tâches. Et cela dans diverses conditions : connexions réseau différentes, plateformes fragmentées….
• Les OS et constructeurs continuent de rechercher des mécanismes pour éviter que les applications n’utilisent trop de batterie. En tant que développeur d’application il est critique d’anticiper cette problématique. En effet, la clé du problème est la conception des applications. Sans un meilleur comportement des applications, les systèmes risquent de continuer à mettre des mécanismes peu efficaces mais contraignants.