Auteur/autrice : 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

Le saviez-vous ? De nombreux mobinautes ne pourront pas utiliser votre application !

Reading Time: 6 minutes

En facilitant l’accès aux solutions numériques, le nombre d’utilisateurs d’applications mobiles va sensiblement augmenter. Mécaniquement le taux d’engagement lié au service offert sera lui aussi en augmentation. Cette métrique est essentielle au succès d’une application. Sans accessibilité, le risque que les utilisateurs n’utilisent pas le service est élevé. Et si le taux d’engagement est faible, les revenus issus de l’application pourraient être lourdement impactés.

Le succès et l’adhésion d’une application sont trop souvent réduits à l’ASO (App Store Optimization ) ou au SEO (Search Engine Optimization). Si l’application est bien classée, alors les utilisateurs seront au rendez-vous. Mais le critère de performance est en réalité que très peu pris en compte par les applications. En effet, on considère que l’ensemble des utilisateurs possède une connexion rapide ainsi qu’un smartphone dernière génération. Mais c’est totalement faux.

Pourquoi avons-nous ce sentiment de vitesse et d’accès par tous ?

Les communications des opérateurs sont nombreuses sur la rapidité et la bonne couverture du réseau. Par exemple, les opérateurs annoncent 98% de couverture de la population pour la 4G. Il s’agit pour eux, d’un argument important de différentiation.

Et les annonces des nouvelles technologies viennent renforcer l’idée que les technologies actuelles sont largement déployées. Les communications sur la 5G rendent en effet la 4G chose acquise. C’est le cas de Xiaomi qui à récemment dévoilé le premier smartphone 5G.

Par ailleurs, le déploiement des technologies actuelles semble n’avoir aucune limite : la 4G est sur la lune

Le sentiment de vitesse de connexion provient aussi du fait que les décideurs et les concepteurs d’application sont dans des zones et dans des conditions de connexion idéales (zone urbaines, locaux avec connexion fibre…). Les outils d’analytics mis en place chez les éditeurs d’applications n’aident pas. En effet, comment savoir qu’un utilisateur existe s’il ne se connecte pas… L’abondance de données rend l’analyse des problèmes de connexion trop difficile à réaliser.

Qu’en est-il réellement du côté des utilisateurs ?

L’ARCEP réalise depuis 2000 un baromètre du numérique qui recense les chiffres du vrai usage du mobile en France. Son édition 2018 présente les constats suivants :

61% des détenteurs de mobile utilisent les réseaux 4G (contre 42% en 2016)

Ce chiffre descends à 51% dans les communes de moins de 2000 habitants.

On observe que nous sommes encore loin de la promesse de couverture à 100%.
Et ce constat est confirmé par OpenSignal qui réalise des mesures réelles via les tests des utilisateurs.

Selon les mesures, la France présente un taux de couverture de 68%. Chiffre intéressant, la vitesse de connexion moyenne à 25 Mbps ne fait pas partie des meilleures. Ceci relève une donnée importante à prendre en compte : la qualité de l’infrastucture (Opérateurs, antennes…). Les pays, les différentes zones même à l’intérieur d’une même ville présente des inégalités en terme de couverture 4G :

Par exemple, voici la carte de couverture réseau du centre-ville de Nantes :

On observe qu’il y a très peu de zones en vert foncé (couleur signifiant une bonne couverture réseau) et beaucoup de zones en rouge (mauvaise couverture).
Au final, la couverture réseau et la vitesse des utilisateurs est très variable. C’est le même constat aussi bien à l’échelle locale qu’au niveau mondial. Globalement, les utilisateurs sont insatisfaits de la connexion 4G.

Le déploiement des technologies s’accélère ainsi tout va rentrer dans l’ordre ?

La croyance en l’évolution des technologies pourrait nous faire croire que cette situation est conjoncturelle et que tout va prochainement rentrer dans l’ordre. C’est le message qui se veut rassurant de la part des opérateurs, pas uniquement en France mais aussi dans des pays qui semble moins avancés en terme de déploiement.

C’est aussi le message des politiques qui annoncent la grande vitesse de connexion accessible à tous. Cependant ce n’est qu’une stratégie et des promesses en l’air. La réalité est beaucoup plus complexe.

D’une part, on le voit même si les nouvelles technologies sont déployées, l’accès pour tous peut prendre plus de temps. Beaucoup d’utilisateurs sont encore en 2G. Et cela pour plusieurs raisons. La couverture à 100% est impossible comme nous l’avons observé mais aussi des zones seront toujours blanches. Les nouveaux bâtiments construits avec plein de métal sont des cages de Faraday qui bloquent les ondes et qui rendent l’accès aux réseaux compliqué. Ce n’est qu’un exemple mais on pourrait citer une multitude de situations similaires.

Et même si l’on obtenait une couverture à 100%, les équipements des utilisateurs devraient suivre la cadence. Il serait nécessaire de s’équiper de smartphones dernières générations. Et ce n’est pas forcément la volonté des utilisateurs de changer aussi souvent. En tout cas, le reconditionnement tends à maintenir des équipements anciennes générations sur le marché. 1 Français sur 3 déclare avoir acheté un téléphone d’occasion. Or peu de chance que ces téléphones intègrent la 5G rapidement.

Les promesses des nouvelles technologies sont aussi bien souvent sur-évaluées. L’arrivée de la 5G est associée à plus de vitesse. Ce n’est cependant pas si simple. La 5G va permettre de nouveaux usages (celui de l’IoT par exemple) et de décongestionner le réseau 4G… Autant dire que si vous comptez atteindre tous les mobinautes, il faut compter sur le fait qu’une grande partie d’entre-eux ne sera pas dans des conditions de connexion idéales.

Quel impact sur le business de votre application ou celui de vos services ?

L’usage du mobile dans différents domaines est devenu très répandu. Par exemple, celui du M-Commerce, selon l’étude ARCEP, 61% des mobinautes effectuent des achats avec leur smartphone. C’est globalement les mêmes statistiques dans les autres pays. En Angleterre, c’est 41%. Le revenu d’une application est généré en fonction du nombre d’utilisateurs. Or si l’utilisateur à une mauvaise expérience ou même qu’il ne peut pas aller au bout de sa volonté d’achat pour cause de mauvaise expérience, les revenus ne seront pas au rendez-vous.

Le manque de performance est un des critères de désengagement des utilisateurs. Comme nous l’avons vu, une grande partie de vos utilisateurs vont se trouver dans des conditions de connexion non-optimales. Dans ce cas, l’application va probablement être moins réactive voir inutilisable dans certains cas. Pour référence, nous avons mesuré avec notre outil GREENSPECTOR des temps de chargement allant jusqu’à 4 minutes pour certaines applications en 2G. Au final, le risque que l’utilisateur désinstalle l’application est élevé. Par ailleurs, le taux de désinstallation à 30 jours est de 28%. Il est encore plus important dans certains pays, comme les pays en voie de développement, pour des raisons d’espace et de lourdeur. Les problèmes de connexion sont dans ce cas très importants pour l’adhésion. Cela rejoint les données observées côté performance web ou 53% des visiteurs abandonnent le site si ce dernier ne se charge pas en moins de 3 secondes (Source : Chrome Dev Summit 2017).

D’autres impacts autres que des impacts économiques ?

Si votre application n’est pas fonctionnelle pour des connexions lentes, certains utilisateurs ne pourront pas utiliser vos services. Vous allez donc exclure involontairement des utilisateurs. Et cette exclusion ne va pas dans le sens du pillier social du développement durable qui, entre autre, demande l’inclusion de toutes les populations.

A ce même titre, si votre application fonctionne mal avec des réseaux moins rapides, elle va consommer d’avantage de batterie. Et là, c’est le pillier environnemental que vous n’allez pas respecter.

Comment agir ?

Il ne faut pas attendre les retours de vos utilisateurs ou ceux de vos outils de monitoring pour agir. Un utilisateur qui ne pourra pas se connecter à votre application ne sera peut-être pas visible ou remonté dans vos données. Il est donc nécessaire d’anticiper et détecter les potentiels problèmes de performance.

1) Lors de la conception et de l’expression du besoin, demandez et spécifiez le fait que votre solution soit utilisable est visible dans des conditions de connexion limitées. Cela peut simplement se résumer à « mon application, ou telle fonction, peut se charger en moins de 3s sur une connexion 2G »

2) Il est nécessaire de tester votre solution dans des connexions limitées (2G, 3G…) soit de façon automatique soit de façon manuelle.

3) Vous pouvez surveiller les performances des utilisateurs via les outils de monitoring. Attention cependant car il est grandement possible que de nombreux utilisateurs ne soient pas du tout visibles depuis ces outils.

Les solutions 1 et 2 sont les solutions que nous préconisons et que nous utilisons chez GREENSPECTOR. La solution 3 est possible avec GREENSPECTOR en mesurant la solution immédiatement après la mise en production.

Le monde du logiciel est en train de se détruire… Manifeste pour un développement plus durable

Reading Time: 21 minutes

Le monde du logiciel va mal et si l’on n’agit pas, on risque de le regretter. Environnement, qualité, exclusion… Software Eats The World (Le logiciel mange le monde…) ? Oui un peu trop.

Le monde du logiciel va mal. Enfin, en surface, tout va bien. Comment un domaine porteur d’autant de promesses économiques pour le bien-être de l’humanité pourrait aller mal ? Se poser la question pourrait être une remise en question de tout cela. Alors tout va bien. On avance, et on ne se pose pas trop de question.

Le monde du logiciel va mal. Pourquoi ? 20 ans d’expérience dans le monde du logiciel en tant que développeur, chercheur ou CTO m’ont donné la chance de côtoyer différents domaines et d’avoir ce sentiment qui se renforce d’année en année. J’ai passé en particulier les 6 dernières années à essayer de pousser des pratiques, des outils de qualité logicielle afin de sensibiliser les développeurs sur l’impact du logiciel sur l’environnement. Il faut être sévèrement motivé pour penser améliorer le monde du logiciel. Les bonnes pratiques ne passent pas aussi facilement que les nouveaux framework Javascript. Le monde du logiciel n’est pas perméable aux améliorations. Ou en tout cas seulement à celles de surface, pas en profondeur.

Le monde du logiciel va mal. Tout est lent, et cela ne va pas dans le bon sens. Certaines voix s’élèvent. Je vous invite notamment à lire “Le désenchantement du logiciel”. Tout est insupportablement lent, tout est ÉNORME, tout finit par devenir obsolète… La taille des sites web explose. Un site web est aussi gros que le jeu Doom. Le phénomène ne touche pas que le Web mais aussi l’IoT, le mobile… Le saviez-vous ? Il faut 13% de CPU pour faire clignoter un curseur

Ce n’est pas le message d’un vieux développeur fatigué par les constantes évolutions et nostalgique du bon vieux temps des disquettes… C’est plutôt un appel à une profonde remise en question de la façon dont nous voyons et développons le logiciel. Nous sommes responsables de cette « non-efficience »(Développeurs, chefs de projet, commerciaux…). Dire que tout va bien ne serait pas raisonnable, mais dire que tout va mal sans proposer de piste d’amélioration le serait d’autant plus.

Disclaimer : Vous allez surement bondir, appeler au FUD, au troll, contredire… en lisant cet article. C’est très bien mais SVP, allez jusqu’au bout !

On grossit (trop)

Tout grossit : la taille des applications, les données stockées, la taille des pages web, la mémoire des téléphones… Les téléphones ont maintenant 2 Go de mémoire, échanger une photo de 10 Mo par mail est maintenant classique… À la limite, cela ne serait peut-être pas un problème si tous les logiciels étaient utilisés, efficaces et performants… Mais cela n’est pas le cas, je vous laisse parcourir l’article “Le désenchantement du logiciel” pour avoir plus de détail. Il est difficile de dire si beaucoup de personnes ont ce sentiment de lourdeur et de lenteur. Et en même temps, tout le monde s’est habitué à cela. C’est l’informatique. Comme les bugs, “votre salaire n’a pas été versé ? Ahh… cela doit être un bug informatique”. L’informatique, c’est lent, et on n’y peut rien. Si on y pouvait quelque chose, c’est sûr, on aurait déjà résolu le problème.

Alors tout le monde se cale sur une lenteur. Tout est uniformément lent. On se cale sur cela et tout va bien. Être performant aujourd’hui, c’est arriver à atteindre un ressenti utilisateur qui correspond à cette lenteur uniforme. On élague les choses qui pourraient être trop visibles. Une page qui met plus de 20 secondes à se charger, c’est trop lent. Par contre, 3 secondes c’est bien. 3 secondes ? Avec les multicoeurs de nos téléphones/PC et les data centers partout dans le monde, le tout relié par des supers technologies de communication (4G, fibre…),c’est un peu bizarre non ? Si on regarde la débauche de ressources pour le résultat obtenu, 3 secondes, c’est énorme. D’autant plus que les bits circulent dans nos processeurs avec des unités de temps du niveau de la nanoseconde. Donc oui, tout est uniformément lent. Et cela convient à tout le monde (du moins, en apparence.) La performance Web (suivez le hashtag #perfmatters) est nécessaire mais c’est malheureusement un domaine qui ne va pas assez loin. Ou peut-être que la réflexion dans ce domaine ne peut pas aller plus loin parce que le monde du logiciel n’est pas assez perméable ni sensibles à ces sujets.

On trouve même maintenant des pratiques pour ne pas résoudre le problème mais le contourner, et c’est un domaine à part entière : travailler sur la « performance perçue » oucomment utiliser la perception du temps par l’utilisateur pour mettre en place des mécanismes pour ne pas trop optimiser. Le domaine est passionnant du point de vue scientifique et humain. Du point de vue performance et efficience logicielle, un peu moins. “Trouvons pleins de mécanismes pour ne pas optimiser trop !”.

Tout cela serait à la limite acceptable dans un monde avec des exigences médiocres sur la performance de nos applications. Le problème est que pour absorber cette non performance, on “scale“. Verticalement en rajoutant des processeurs ultra-puissants et plus de mémoire, horizontalement en rajoutant des serveurs. Vive la virtualisation qui nous a permis d’accélérer cette course à l’armement ! Sauf que sous les bits, il y a du métal et le métal c’est coûteux, et c’est polluant.

Oui, cela pollue : il faut beaucoup d’eau pour construire des puces électroniques, de produits chimiques pour extraire des terres rares, sans parler des allers-retours partout dans le monde… Oui, la lenteur uniforme a quand même un coût certain. Mais nous y reviendrons plus tard.

Il est nécessaire de revenir à plus d’efficience, de « challenger » les besoins en matériel, de redéfinir ce qu’est la performance. Tant que l’on se satisfera de cette lenteur uniforme avec des solutions pour ne pas ralentir plus (comme l’ajout de matériel), nous n’avancerons pas. La dette technique, notion largement assimilée par les équipes de développement, n’est malheureusement pas adaptée à ce problème (on y reviendra). Nous sommes sur une dette de ressources matérielles et de mauvaise adéquation entre le besoin utilisateur et la solution technique. On parle ici d’efficience et non pas uniquement de performance. L’efficience est une histoire de mesure du gaspillage. L’ISO définie l’efficience avec comme domaine : Time behaviour, Resource utilization et Capacity. Pourquoi ne pas pousser plus ces concepts ?

On est (trop) virtuel

Une des problématiques est que le logiciel est considéré comme “virtuel”. Et c’est bien là, le problème.« Virtuel » définit ce qui n’a pas d’effet (“Qui n’est qu’en puissance, qu’en état de simple possibilité par opposition à ce qui est en acte” selon le Larousse). Peut-être que cela vient du début des années 80 où le terme virtuel était utilisé pour parler du Numérique (par opposition au monde du Matériel). « Numérique » est relatif à l’usage des nombres (les fameux 0 et 1). Mais bon, numérique , ce n’est pas assez in et cela inclut un peu trop le matériel. Utilisons le terme Digital ! Digital/Numérique, c’est une discussion en France qui peut sembler idiote mais qui est importante dans la problématique dont nous discutons. En effet, le digital cache encore plus cette partie matérielle.

Or, il ne faut pas le cacher : les services numériques sont bien composés de code et de matériel, de 0 et 1 qui circulent sur du matériel bien réel. On ne peut pas programmer sans oublier cela. Un bit qui va rester sur le processeur ou traverser la terre ne va pas prendre le même temps, ni utiliser les mêmes ressources :

Développez du code Java pour un serveur J2EE ou pour un téléphone Android, ce n’est pas pareil. Des structures spécifiques existent par exemple pour traiter des données en Android mais les structures classiques sont toujours utilisées. Les développeurs ont perdu le lien avec le hardware. C’est malheureux car c’est passionnant (et utile) de savoir comment fonctionne un processeur. Pourquoi : abstraction et spécialisation (nous verrons cela plus loin). Car en perdant ce lien, on perd une des forces du développement. Ce lien est important chez les hackers ou chez les développeurs d’informatique embarquée mais malheureusement de moins en moins présent chez les autres développeurs.

Les pratiques devops pourraient répondre à cette perte de lien. Là, c’est pareil, nous n’allons pas jusqu’au au bout : généralement le devops va se focaliser à bien gérer le déploiement d’une solution logicielle sur une infrastructure mixte (matérielle et un peu logicielle). Il faudrait aller plus loin en remontant par exemple les métriques de consommation, en discutant sur les contraintes d’exécution… plutôt que de “scaler” juste parce que c’est plus simple.

On pourra toujours justifier cet éloignement du matériel : productivité, spécialisation… mais il ne faut pas confondre séparation et oubli. Séparer les métiers et se spécialiser, oui. Mais oublier qu’il y a du matériel sous le code, non ! Une première étape serait de remettre des cours sur le matériel au sein des écoles. Ce n’est pas parce qu’uneécole forme à la programmation qu’une sensibilisation sérieuse au matériel et à son fonctionnement n’est pas nécessaire.

On est (trop) abstrait

On est trop virtuel et éloigné du matériel parce que l’on a voulu s’en abstraire. Les multiples couches d’abstraction ont permis de ne pas se préoccuper des problématiques matérielles, de gagner du temps… Mais à quel prix ? Celui de la lourdeur et de l’oubli du matériel, comme on l’a vu, mais bien plus encore. Comment comprendre le comportement d’un système avec des stacks d’appels supérieurs à 200 ? :

Certaines technologies ont une utilité mais sont maintenant systématiquement utilisées. C’est le cas par exemple des ORM qui sont devenus systématiques. Aucune réflexion n’est faite sur son intérêt en début des projets. Résultat : on a rajouté une surcouche qui consomme, qu’il faut maintenir et des développeurs qui n’ont plus l’habitude d’effectuer des requêtes natives. Cela ne serait pas un problème si chaque développeur connaissait très bien le fonctionnement des couches d’abstraction : comment fonctionne HIBERNATE par exemple ? On s’appuie hélas de façon aveugle sur ces frameworks.

Ceci est très bien expliqué dans la loi de Joel Spolsky “The Law of Leaky Abstractions”

And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder. (…) Ten years ago, we might have imagined that new programming paradigms would have made programming easier by now. Indeed, the abstractions we’ve created over the years do allow us to deal with new orders of complexity in software development that we didn’t have to deal with ten or fifteen years ago (…) The Law of Leaky Abstractions is dragging us down.

On attend (trop) la solution miracle

Le besoin d’abstraction est lié à un autre défaut: nous attendons toujours des outils miracles. La silver bullet qui améliorera encore plus nos pratiques. Le langage idéal, le framework pour aller plus vite, l’outil de gestion miracle des dépendances… C’est la promesse à chaque fois d’un nouveau framework : gagner du temps en développement, être plus performant… Et on y croit, on fonce. On abandonne les frameworks sur lesquels nous avions investi, sur lesquels on avait passé du temps… et on passe au nouveau. C’est le cas actuellement des frameworks JS. L’histoire du développement est pavé de framework oubliés, non maintenus, abandonnés… Nous sommes les champions pour réinventer ce qui existe déjà. Si on le gardait suffisamment longtemps, on aurait le temps de maîtriser un framework, de l’optimiser, de le comprendre. Mais ce n’est pas le cas. Et que l’on ne me dise pas que si on n’avait pas continuellement réinventé la roue, on aurait encore des roues en pierre… Innover serait d’améliorer les frameworks existants .

C’est aussi le cas pour les gestionnaires de paquets : Maven, NPM… Au final, on arrive à un enfer. Le lien avec l’abstraction ? Plutôt que de gérer ces dépendances en dur, on met une couche d’abstraction qu’est le gestionnaire de paquets. Et l’effet de bord : c’est que l’on intègre (trop) facilement du code extérieur que l’on ne maîtrise pas. Là encore, nous y reviendrons.

Sur les langages, c’est la même rengaine. Attention, je ne préconise pas de rester sur l’assembleur et sur le C… C’est le cas par exemple dans le monde Android, pendant plus de 10 ans les développeurs ont pu travailler sur des outils et des frameworks Java. Et comme cela, par magie, le nouveau Langage de la communauté est Kotlin. On imagine l’impact sur les applications existantes (si elles doivent changer), il faut recréer des outils, retrouver des bonnes pratiques… Pour quel gain?

Today the Android team is excited to announce that we are officially adding support for the Kotlin programming language. Kotlin is a brilliantly designed, mature language that we believe will make Android development faster and more fun. Source

On y reviendra sur le “fun“…

Sincèrement, on ne voit aucun ralentissement sur les cycles de renouvellement des technologies. C’est toujours un rythme frénétique. Nous trouverons bien le Graal un jour. Le problème est ensuite l’empilement de ses technologies. Comme aucune ne meurt vraiment et que l’on en maintient toujours des parties, on développe d’autres couches pour s’adapter et continuer à maintenir ces bouts de code ou ces librairies. Le problèmen’est pas le code legacy,, c’est la glue que l’on développe autour qui pêche. En effet, comme le récitait l’article sur « le désenchantement logiciel » :

@sahrizv :

2014 – On doit adopter les #microservices pour résoudre tous les problèmes liés aux monolithes.

2016 – On doit adopter #docker pour résoudre tous les problèmes liés aux microservices.

2018 – On doit adopter #kubernetes pour résoudre tous les problèmes avec Docker.

Au final, on passe du temps à résoudre des problèmes techniques internes, on recherche des outils pour résoudre les problèmes que l’on ajoute, on passe son temps à s’adapter à ses nouveaux outils, on ajoute des surcouches (voir chapitre précédent…) … et on n’a pas améliorer la qualité intrinsèque du logiciel ou les besoins auxquels on doit répondre.

On n’apprend pas (assez)

Au final, le rythme frénétique des changements ne nous permet pas de nous stabiliser sur une technologie. J’avoue qu’en tant que vieux développeur que je suis, j’ai été découragé par le changement Java vers Kotlin pour Android. C’est peut-être pour certains de véritables challenges, mais quand je repense au temps que j’ai passé sur l’apprentissage, sur la mise en place d’outils.. Il faut partir d’assez loin mais pas de 0. Il est normal, dans un métier, de continuellement apprendre et ếtre curieux. Mais cela reste dans le cadre d’itération pour expérimenter et s’améliorer. Ce n’est pas le cas dans la programmation. En tout cas dans certains domaines de la programmation, car pour certaines technologies, les développeurs continuent à expérimenter (.Net, J2EE..). Mais ce n’est effectivement pas fun

Enfin, on apprend : on passe notre temps sur les tutoriels, getting started, les conférences, les meetups… Pour finalement n’en expérimenter que 10% dans un project side ou même un POC, qui deviendra sûrement un projet en production.

Ensuite, comme aucune solution ne meurt vraiment, que de nouvelles arrivent… on se retrouve avec des projets avec des multitudes de technologies à gérer avec les compétences associées aussi… On s’étonne ensuite que le marché du recrutement de développeur soit bouché. Pas étonnant.. Il y a énormément de développeurs mais il est difficile de trouver un développeur React avec 5 ans d’expérience qui connaîsse le Go. Le marché est fractionné, comme les technologies. C’est peut-être bon pour les développeurs car cela crée de la rareté et cela fait monter les prix, mais pas pour le projet !

Pour revenir au chapitre précédent (Recherche des outils miracle…), on le voit dans le monde Javascript avec la “JS fatigue”. Le développeur doit faire son chemin dans le monde du Javascript et des outils associés. C’est le prix de la multitude d’outils. C’est une approche compréhensible (voir par exemple une très bonne explication de cela). Cependant, cet apprentissage continu des technologies pose le problème d’apprentissage de domaines transverses : accessibilité, agilité, performance… En effet, qu’est-ce qui nous prouve que les outils et les langages que nous allons choisir ne vont pas changer dans 4 ans ? Rust, Go… dans 2 ans ? Rien ne tend à donner une tendance.

On s’amuse (trop) et on ne se remet pas (assez) en cause

Enfin, sauf si c’est dans l’objectif de remettre une technologie en cause pour en trouver une autre. Le troll est chose commune dans notre monde (et, je l’avoue, j’en use aussi). Mais ce n’est que pour mettre une technologie en cause pour une autre. Et continuer le cycle infernal du renouvellement des outils et langages. Une vraie remise en cause, c’est se demander avec sincérité : allons-nous dans le bon sens ? Ce que je fais est-il durable ? Est-ce de qualité ? Mais la remise en cause n’est pas chose simple car elle est associée soit à du troll (justement ou injustement) soit à une image rétrograde. Comment critiquer un mode associé à une avancée technologique ?

Les voix s’élèvent peu contre cet état de faits : Le désenchantement du logiciel, Contre le développement logiciel… et c’est dommage car la remise en question est une pratique saine pour un domaine. Elle permet de “performer” encore plus.

On ne se remet pas en question car on veut s’amuser. Le fun est important, car si l’on s’ennuie dans son boulot, on va déprimer. Par contre, on ne peut pas, sous prétexte de vouloir du fun tout le temps, changer nos outils continuellement. Il y a un déséquilibre entre l’expérience du développeur et l’expérience de l’utilisateur. On veut du fun, mais qu’est-ce que cela va réellement apporter à l’utilisateur ? Un produit plus « joyeux » ? Non, nous ne sommes pas des acteurs. On peut aussi critiquer l’effort que l’on met à réduire les temps de build et autre commodités du développeur. C’est important mais il faut toujours équilibrer nos efforts : j’accélère mon temps de build mais ce n’est valable que si j’utilise le temps gagné pour améliorer l’expérience utilisateur. Sinon ce n’est que du tuning pour son propre plaisir.

Il est nécessaire d’accepter la critique, de s’autocritiquer et d’éviter de se cacher dernière des barrières. La dette technique est une notion importante mais si c’est une excuse pour faire du mauvais refactoring et surtout pour changer vers une nouvelle techno à la mode, autant acquérir de la dette. Il faut aussi arrêter les guerres de chapelles. A quoi bon défendre son langage vis-à-vis d’un autre ? Arrêtons de répéter que “l’optimisation prématurée est la cause de tous les maux…” Cela vient de l’informatique des années 70 où tout était optimisé. Or, il n’y a plus d’optimisation prématurée, ce n’est qu’une excuse pour ne rien faire et continuer comme cela.

Nous sommes (mal) gouvernés

On ne se pose pas de question sur l’éthique de notre domaine, sur sa durabilité… Cela vient peut-être du fait que notre domaine n’a pas réellement de code éthique (comme par exemple les médecins ou les avocats). Mais sommes-nous en tant que développeurs réellement libres si l’on ne peut pas avoir une autocritique ? Nous sommes peut être asservis à une cause portée par d’autres personnes ? Le problème n’est pas simple mais nous avons dans tous les cas une responsabilité.
Sans code éthique, c’est le plus fort et le plus malhonnête qui est le plus fort. Le buzz et les pratiques pour manipuler les utilisateurs sont de plus en plus répandus. Sans Dark Pattern ton produit ne sera rien. Les plus gros (GAFA…) n’en sont pas arrivés là pour rien.

Est-ce que la solution est politique ? Il faut légiférer pour mieux gouverner le monde du logiciel. On le voit avec les dernières réponses législatives aux problèmes concrets : RGPD, notification des cookies… la source du problème n’est pas résolue. Peut-être parce que les politiques ne comprennent que très mal le monde du logiciel.

Il serait préférable que le monde du logiciel se structure, mette en place un code d’éthique, s’autorégule… Mais en attendant, c’est la règle du plus fort qui continue … Au détriment d’une meilleure structuration, d’une meilleure qualité, d’une véritable professionnalisation…

Car si cette structuration n’est pas faite, les développeurs vont perdre la main sur ce qu’ils font. Or le manque d’éthique de la profession est critiqué à l’extérieur. Rachel Coldicutt (@rachelcoldicutt) directrice de DotEveryOne, un think tank britannique qui promeut une technologie plus responsable, encourage à former des diplômés non-informaticiens qui traiteraient de ces problèmes (Voir plus précisément dans l’article d’Internet Actu). Pour poursuivre sur ce dernier article, cela serait dans la droite ligne de l’informatique, domaine issu du monde militaire où les ingénieurs et développeurs seraient formés à suivre des décisions et des commandements.

Un propos qui fait écho, notamment, à celui que tenaient David Banks (@da_banks) dans l’insolent « The Baffler ». D.Banks soulignait combien le monde de l’ingénierie est lié à l’autoritarisme. La raison est certainement à chercher du côté de l’histoire. Les premiers ingénieurs étaient d’origine militaire et concevaient des armes de siège, rappelle-t-il rapidement. Ils sont d’ailleurs toujours formés pour « se brancher sur les structures décisionnelles de la chaîne de commandement ». Contrairement aux médecins ou aux avocats, les ingénieurs n’ont pas d’autorités éthiques qui les surveillent ou de serment à respecter. « C’est pourquoi les ingénieurs excellent dans l’externalisation des reproches » : si cela ne marche pas, la faute incombe à tous les autres (utilisateurs, managers…) « On leur enseigne dès le début que la chose la plus morale qu’ils puissent faire est de construire ce qu’on leur dit de construire au mieux de leurs capacités, afin que la volonté de l’utilisateur soit réalisée avec précision et fidélité. »

Avec cette vision, on peut se poser la question : pourrons-nous intégrer des bonnes pratiques et de l’éthique de façon structurelle et interne dans notre domaine ?

Le développement suit (trop) comme toute organisation des décisions absurdes

Le monde du logiciel s’intègre dans un système organisationnel classique. Grands groupes, sous-traitances via des ESN, web agencies… Tous suivent les mêmes techniques de gestion des projets informatiques. Et tout le monde va « dans le mur ». Aucune analyse sérieuse n’est faite sur le coût global d’un logiciel (TCO), sur son impact sur la société, sur son bénéfice, sa qualité… C’est la rapidité de release(Time to Market), la surcharge featurale (fonctionnelle), la productivité immédiate, qui comptent. Premièrement car les gens externes à ce monde ne connaissent que trop peu la technicité du logiciel et son monde. Il est virtuel donc simple (sic). Mais ce n’est pas le cas. Les écoles de commerce et autres usines de managers n’ont pas de cours de développement. Comment peuvent-ils bien diriger et piloter des projets ?

On continue a vouloir chiffrer des projets informatiques comme de simples projets alors que des mouvements comme le no estimate propose des approches innovantes. Les projets continuent d’échouer : le chaos report rapporte que simplement 30% des projets réussissent bien. Et face à cette mauvaise gouvernance, les équipes techniques continuent de se battre sur les technologies. Dommages collatéraux : la qualité, l’éthique, l’environnement… et au final l’utilisateur. Cela ne serait pas si critique si le logiciel n’avait pas un impact aussi fort sur le monde. Software eats the world… et oui, on le « bouffe »…

On peut se poser la question de la bienveillance des entreprises : sont-elles uniquement intéressées par leur profit, quel qu’en soit le prix, et laissent le monde du logiciel dans ce marasme ? La réponse vient peut-être de la sociologie. Dans son livre “Les Decisions Absurdes” Christian Morel explique que les individus peuvent collectivement prendre des décisions qui vont totalement dans le sens contraire du but recherché. En particulier, l’autolégitimation de la solution.

Morel explique ce phénomène avec le “pont de la rivière Kwai” où un héros bâtit un ouvrage avec zèle pour son ennemi avant de le détruire.

Ce phénomène du “Pont de la rivière Kwai”, où l’action est autolégitimée, où l’action est le but ultime de l’action, existe dans la réalité plus qu’on ne pourrait le penser. Il explique que des décisions sont vides de sens parce qu’elles n’ont pas d’autre but que l’action elle-même. “Il s’est fait plaisir” : c’est ainsi que des cadres d’entreprises s’expriment avec humour et pertinence lorsque l’un des leurs a construit un “pont de la rivière Kwai” (…) L’action comme but en soi suppose l’existence de ressources abondantes (…) Mais lorsque les ressources sont abondantes, l’organisation peut supporter le coût de moyens humains et financiers qui tournent dans le seul objectif de fonctionner”. Et, dans le monde du logiciel, elle met globalement les moyens pour fonctionner : levée de fond gigantesque, librairies qui permettent de releaser très rapidement, ressources infinies… Avec cette abondance, nous construisons énormément de Ponts de la rivière Kwai.

Dans ce cadre, le développeur est responsable de cette abondance.

Le développement est (trop) mal piloté

Si ces décisions absurdes arrivent, ce n’est pas uniquement la faute du développeur mais bien de l’organisation. Et qui dit organisation dit management (sous-différente forme). Si l’on revient au livre de Morel, il parle de piège cognitif dans lesquels les managers et les techniciens tombent souvent. C’est le cas de la navette Challenger qui a été quand même lancée malgré la connaissance du problème d’un joint défectueux. Les managers ont sous-évalué les risques et les ingénieurs ne les ont pas prouvés. Chacun a reproché à l’autre de ne pas fournir assez de preuves scientifiques. C’est souvent ce qui se passe dans les entreprises : des warnings sont levés par certains développeurs mais le management ne les prend pas assez au sérieux.

C’est ce qui s’est passé aussi dans beaucoup d’organisations qui ont voulu rapidement développer des applications mobiles universelles. En l’occurrence, la solution miracle (on y revient) adoptée par les décideurs a été le framework Cordova : pas besoin de recruter des développeurs spécialisés iOS et Android, possibilité de récupérer du code Web… Le calcul (ou pas) simple ne montrait que des avantages. Par contre, côté technique, il était clair que les applications natives étaient beaucoup plus simples et efficaces. 5 ans plus tard, les conférences sont pleines de retours d’expériences sur des échecs de ce type de projet et le redémarrage “from scratch” de ceux-ci en natif. Le lien avec Challenger et les pièges cognitifs ? Les équipes de management avaient sous-estimé les risques, le coût réel et n’avaient pas pris en compte les remarques des équipes techniques. Les équipes techniques n’avaient pas assez étayé et prouvé les tenants et aboutissants d’un tel framework.

En même temps, on revient aux causes précédentes (silver bullet, on s’amuse…), il est nécessaire d’avoir une vraie ingénierie et une vraie analyse des technologies. Sans cela, les équipes techniques seront toujours non-écoutées par le management. Des outils et benchmark existent mais ils sont encore trop peu connus. Par exemple, Technologie Radar qui classe les technologies en terme d’adoption.

Il est dans le même temps important que le management des entreprises cesse de penser que les solutions miracles existent (on revient à la cause du “virtuel”). Il faut réellement calculer les coûts, le TCO (Total Cost of Ownership) et les risques sur les choix de technologie. On continue à choisir des solutions BPM et Low-code qui permettent de générer du code. Mais les risques et les coûts cachés sont importants. Selon ThoughtWorks :

Low-code platforms use graphical user interfaces and configuration in order to create applications. Unfortunately, low-code environments are promoted with the idea that this means you no longer need skilled development teams. Such suggestions ignore the fact that writing code is just a small part of what needs to happen to create high-quality software—practices such as source control, testing and careful design of solutions are just as important. Although these platforms have their uses, we suggest approaching them with caution, especially when they come with extravagant claims for lower cost and higher productivity.

On se divise (trop)… pour mieux règner?

Ce phénomène de décision absurde est renforcé par le tissu complexe du développement logiciel : Les sociétés historiquement hors du numérique sous-traitent à des entreprises du numérique, les ESN sous-traitent aux freelances… Le partage de responsabilité technique / management est encore plus complexe et les décisions absurdes plus nombreuses.

Mais cela ne s’arrête pas là. On peut aussi voir l’usage de l’open-source comme une sorte de sous-traitance. Idem pour l’usage de framework. On est juste consommateur passif, on se déleste de plein de problématiques (qui ont un impact sur les ressources, la qualité…).

C’est d’autant plus facile que le domaine est passionnant et que la pratique des sides-projects, du temps passé sur les projets open-source hors des horaires de bureau est chose commune… La recherche de “fun” et le temps passé bénéficient alors plus aux organisations qu’aux développeurs. Difficile dans ce cas de chiffrer le coût réel d’un projet. Et pourtant, cela ne serait pas un problème si on arrivait à des logiciels « au top ». Cela ne change pas la qualité, au contraire, l’organisation étendue qui est composée du gros des groupes, des ESN, des freelances, des communautés n’a plus de limite pour construire les fameux ponts de la rivière Kwai.

Le développeur n’est ici plus un artisan du code, mais plutôt un pion dans un système critiquable du point de vue humain. Cela n’est pas visible, tout va bien et on s’amuse. En apparence seulement, car certains domaines du développement logiciel vont plus loin et rendent beaucoup plus visible cette exploitation : Le domaine du jeux-vidéo où les heures explosent.

Dans ce contexte, une meilleure professionnalisation, un code d’éthique ou toute autre chose serait utile. En effet, ceci permettrait de mettre des garde-fous sur des dépassements ou des pratiques (directement ou indirectement) critiquables. Mais je n’ai jamais entendu parler de la corporation des développeurs ou autre rassemblement qui permettrait cette défense du code.

On perd (trop) souvent le but final : l’utilisateur

Et donc, toutes ces maladresses (logiciel trop lourd, sans qualité…) se retrouvent chez les utilisateurs. Comme on doit releaser au plus vite les logiciels, que l’on ne tente pas de résoudre les inefficiences internes, et que l’on ne met pas plus de ressource pour faire de la qualité, on arrive à des logiciels médiocres. Mais on a tellement d’outils de monitoring et de suivi des utilisateurs pour détecter ce qui se passe directement chez eux qu’au final, on pense que ce n’est pas grave. Cela serait une bonne idée si les outils étaient bien utilisés. Or la multitude d’informations récoltées (en plus des bugs remontés par les utilisateurs) n’est que faiblement utilisée. Trop d’information, difficulté de cibler la vraie source du problème… on s’y perd et au final, c’est l’utilisateur qui trinque. Tous les logiciels sont maintenant en bêta-test. A quoi bon faire de la sur-qualité, autant attendre que l’utilisateur le demande. Et on revient ainsi au premier chapitre : un logiciel uniformément lent … et médiocre.

En prenant un peu de recul, chacun peu le ressentir au quotidien que ce soit au bureau ou la maison. Heureusement, on est sauvé par la non-sensibilisation des utilisateurs au monde du logiciel. C’est un monde effectivement virtuel et magique qu’ils ont l’habitude d’utiliser. On leur a mis en main les outils mais sans notice explicative. Comment évaluer la qualité d’un logiciel, les risques sur l’environnement, les problèmes de sécurité… si l’on n’a pas des notions d’informatique, même rudimentaires ?

L’informatique du 21ème siècle est ce que l’agroalimentaire était pour les consommateurs au 20ème siècle. Pour des raisons de productivité, on a poussé des solutions médiocres avec un calcul court-termiste : mise sur le marché de plus en plus rapide, profit en hausse constante… agriculture intensive, malbouffe, pesticides… avec des impacts importants sur la santé, sur l’environnement… Les consommateurs savent maintenant (de plus en plus) les conséquences désastreuses de ces dérives, l’industrie agroalimentaire doit donc se réinventer, techniquement, commercialement et éthiquement. Pour le logiciel, quand les utilisateurs comprendront les tenants et les aboutissants des choix techniques, l’industrie du logiciel devra gérer les mêmes problèmes. En effet, le retour au bon sens et aux bonnes pratiques n’est pas une chose simple pour l’agroalimentaire. Dans l’IT, on commence à le voir avec ses conséquence sur la vie privée des utilisateurs (mais nous n’en sommes qu’aux balbutiements).

Il est important de réintroduire l’utilisateur dans les réflexions de conception des logiciels (et pas seulement en faisant juste des workshops de réflexion UX et marketing…) Il faut repenser tout le monde du logiciel : la gestion des projets, les impacts du logiciel, la qualité… C’est le but de certains mouvements : software craftmanship, éco-conception, accessibilité… mais les pratiques sont beaucoup trop confidentielles. A qui la faute ? On revient aux causes du problème : on se fait plaisir d’un côté (développement) et on a une recherche uniquement de profit (coté management). Pratique pour bâtir des ponts de la rivière Kwai… où se trouvent les utilisateurs (nous, en fait).

On tue notre industrie (et plus)

On va dans la mauvaise direction. L’industrie de l’informatique a déjà effectué dans les années 70 des erreurs avec des impacts non-négligeables. L’exclusion des femmes de l’informatique en fait partie. Non seulement cela a été fatal pour certaines industries mais on peut se poser la question de comment on peut maintenant adresser des réponses à seulement 50% de la population informatique, avec une représentativité très faible. Le chemin est maintenant difficile à retrouver.

Mais l’impact du monde IT ne s’arrête pas là. La source et le modèle d’une grosse partie de l’informatique sont issus de la Silicon valley. Si l’on écarte les gagnants de la Silicon Valley, les populations locales subissent la montée des prix, le déclassement, la pauvreté… Le livre Mary Beth Meehan met en image cela :

“La fuite vers un monde virtuel dont on peine encore à jauger l’utilité nette, elle, coïnciderait avec l’éclatement des communautés locales et la difficulté à se parler entre voisins. Personne ne peut dire si la Silicon Valley préfigure en miniature le monde qui vient, pas même Mary, qui termine pourtant son ouvrage autour du mot « dystopie ».”

Dans sa lancée vers le progrès technique, le monde du logiciel crée aussi sa dette environnementale

Les exemples sont nombreux mais les voix encore trop faibles. Peut-être que nous allons trouver la silver bullet, que les bénéfices du logiciel vont effacer ses torts… rien ne montre cela pour l’instant, bien au contraire. Car il est difficile en effet de critiquer le monde du logiciel. Comme le dit Mary Beth Meehan :

« mon travail pourrait tout aussi bien être balayé ou considéré comme une propagande de gauche. J’aimerais penser qu’en montrant ce que nous avons décidé d’occulter, nous avons servi à quelque chose, mais je ne suis pas très confiante. Je ne crois pas que les gens qui, en première instance, ne sont pas d’accord avec nous pourraient changer d’avis.».

Par contre, si des voix se font de plus en plus nombreuses, et qu’elles viennent de personnes qui connaissent le logiciel (développeurs, architectes, testeurs…), le système pourra changer. Le développeur n’est ni un artisan, ni un héros : il est juste une cheville ouvrière d’un monde sans sens. Alors, il est temps de bouger…

Pourquoi automatiser les tests de ses applications mobiles ?

Reading Time: 3 minutes

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

Écouter de la musique sur son smartphone sans vider sa batterie c’est possible ?

Reading Time: 5 minutes

Votre batterie de téléphone se décharge trop vite ? Lors de l’achat de votre smartphone, le vendeur vous a promis une autonomie de 3 jours. Au bout d’un mois, vous le rechargez tous les jours (le téléphone, pas le vendeur). Peut-être que le vendeur (voir le constructeur de mèche avec lui) vous a menti sur les capacités réelles du téléphone ? Depuis l’affaire Volkswagen, nous ne sommes plus sûrs de rien… Mais le problème est probablement plus complexe. Vous n’utilisez peut-être pas correctement votre smartphone ou alors vous ne choisissez pas les services les plus adaptés à vos usages.

Article à lire avec quelques pistes à écouter

Musiques associées au thème de l’article et en fonction des goûts (Avec un rapport lointain au sujet, je l’avoue):

Damso – Batterie faible

MattLm – Battery Low

Metallica – Battery

La musique ou l’autonomie du téléphone, il faut choisir !

Il est loin le temps où vous écoutiez de la musique avec un lecteur MP3 ou même un lecteur cassette (pour les plus anciens d’entre nous). Maintenant, comme pour beaucoup d’usages, le smartphone a remplacé les différents lecteurs. On ne recharge plus de pile, mais on recharge la batterie du smartphone. Surtout que les moments sont nombreux au quotidien pour écouter de la musique : dans les transports en commun, au bureau, en voiture, le soir pour s’endormir…

Et les moyens d’écouter de la musique sont multiples : applications telles que Deezer, Live Radio, Youtube, MP3 stocké localement… Mais quel est le moyen le moins consommateur pour votre batterie ?

Protocole de mesure

Cette étude a été réalisée sur un smartphone Samsung Galaxy S7. Certains résultats peuvent varier sur différents devices, cependant ils permettent d’obtenir une tendance sur les services numériques qui ont été évalués.

Je veux choisir le service le moins consommateur

Vous avez donc toujours l’écran allumé et vous aimez particulièrement zapper entre les pistes. Considérons que vous êtes en Wi-Fi et que le volume du son est sur un niveau moyen.

Vous pouvez réduire jusqu’à 3h30 l’autonomie de votre téléphone en fonction du service utilisé. Il est généralement préférable de lire un MP3 que vous aurez stocké sur le téléphone. Vous n’utilisez pas de connexion internet, il y a donc moins de consommation qui en découle. Cependant, on observe que des applications comme Google Play auront tendance à consommer beaucoup plus d’autonomie qu’une lecture de musique sur Internet (Deezer, Spotify, Youtube…). Attention donc au choix du lecteur pour vos fichiers MP3. Android vous indiquera dans tous les cas les applications les plus consommatrices, vous pourrez alors faire votre choix.

La radio sur Internet n’est pas la solution la plus intéressante. On préférera des podcasts téléchargés de façon anticipée. En effet, la connexion internet couplée au navigateur font que les players radio ne ne sont pas les plus efficaces.

Et si je baisse le volume du son ?

Est-ce que le volume du son a une incidence sur la consommation de batterie ?

Oui et non, pour un niveau bas à moyen, la consommation ne varie pas beaucoup. Cependant, si vous utilisez votre smarphone comme une enceinte pour diffuser du son autour de vous, la consommation va être plus élevée (2h20 d’autonomie en moins). Si vous souhaitez écouter le son plus fort, le casque sera plus utile. N’attendez cependant pas à une réduction importante de la consommation avec un casque.

Et si je suis en mobilité avec de la 4G ?

Écouter de la musique dans les transports en commun où il n’y pas de réseau Wi-Fi, c’est bien ?

Et bien cela à un coût, et un coût non négligeable. Il est préférable de se connecter à un Hotspot Wi-Fi.

Le summum de la consommation étant d’écouter de la musique à fond sur l’application Youtube et le tout en 4G.

Et si j’éteins mon écran ?

Certaines applications permettent de passer en mode veille (ou en arrière-plan) et de laisser l’écran s’éteindre. Si c’est le cas, vous allez pouvoir économiser de la batterie. Le classement entre les services ne varie presque pas, vous diminuez “juste” la consommation. Deezer devient en effet le plus consommateur. Il semble que les traitements en tâche de fond ne soit pas assez optimisés au sein de l’application.

Et alors ?

Les usages varient, en fonction des goûts, des habitudes, du smartphone… et les consommations d’énergie aussi. On peut ainsi obtenir une “fourchette” d’autonomie en lecture continue de 4h à 13h.

Il est également possible de modifier ses habitudes pour augmenter l’autonomie. Pour aller plus loin dans cette démarche : identifier les applications consommatrices sur les OS et interpeller les éditeurs en leur demandant de s’améliorer est tout à fait possible.

C’est green ?

Oui, moins consommer d’énergie va permettre de réduire la sollicitation de la batterie, vous allez ainsi effectuer moins de cycles de charge, la longévité de la batterie sera plus élevée (ce sont les cycles de rechargement/déchargement qui l’use), et vous prolongerez ainsi la durée de vie globale de la batterie (qui est très polluante) voir de votre smartphone. CQFD.

Cette étude a été réalisée avec les outils GREENSPECTOR qui permettent de mesurer la consommation d’énergie des applications sur des téléphones. Pour plus d’information sur les méthodologies et les outils, je vous invite à parcours ce blog.

Top 2018 des navigateurs les moins énergivores pour votre smartphone

Reading Time: 5 minutes

Édition 2020 : quels sont les meilleurs navigateurs à utiliser sur mobile ?

Le navigateur internet est l’une des applications les plus critiques de votre smartphone. Il vous permet d’accéder à une multitude de services (Réseaux sociaux, actualités, jeux…). Il l’est d’autant plus lorsque vous ne souhaitez pas télécharger d’application et que vous préférez utiliser plutôt un site mobile. Votre navigateur est donc utilisé quasi en continu sur votre téléphone. Il est donc responsable d’une partie de la baisse de l’autonomie de votre smartphone.

Il est donc important de choisir le meilleur navigateur si vous souhaitez augmenter la durée de vie de votre smartphone.

Classement

Retrouvez la méthodologie de ce classement en fin d’article.

On obtient une autonomie des différents navigateurs qui varie entre 6h15 et 7h26. Cela peut sembler faible comme écart mais sur la durée totale de vie de votre smartphone, vous allez moins solliciter votre batterie et au final éviter l’obsolescence programmée. Sans compter une autonomie prolongée en fin de journée !

Les navigateurs en liste

Top 1 : Brave

Nouveau navigateur sur le marché, Brave souhaite faire de la vie privée un cheval de bataille. Il bloque automatiquement les publicités et les trackers. Cela semble payer sur l’autonomie puisque Brave prend la tête du classement avec 7h26mn d’autonomie estimée pour un usage web en continu.

Top2 : Firefox Focus

Mozilla publie Firefox Focus, un navigateur centré sur le respect de la vie privée : politique de confidentialité par défaut, blocage de tackers… Il semble que tout comme Brave, cette stratégie permet de gagner en autonomie.

Top 3 : Dolphin

Beaucoup moins connu que Chrome ou Firefox, Dolphin est pourtant très téléchargé. Avec des fonctionnalités similaires à Chrome ou Firefox, c’est un challenger à prendre très au sérieux.

Top 4 : Opera

Le navigateur Opera possède un bloqueur de publicité et la possibilité de créer une page d’accueil personnalisée avec un flux d’actualité. Sa version Mini existe mais n’a pas pu être évaluée dans cette étude. L’autonomie est respectable mais inférieure de 30 minutes par rapport à notre top 1 : Brave.

Top 5 : Ecosia

Basé sur Chromium, ce navigateur Allemand finance des actions de développement durable (comme la replantation d’arbre) avec les recherches effectuées par les utilisateurs. Même si l’autonomie n’est pas la pire, il est dommage que ce navigateur qui ne souhaite que le bien de la planète ne soit mieux placé dans le classement !

Top 6 : Samsung internet

Il s’agit du navigateur pré-installé sur tous les téléphones Samsung : Samsung Internet. Une consommation proche de celle d’Ecosia, probablement du au fait que le navigateur se base aussi sur Chromium.

Top 7 : Chrome

Chrome, le navigateur Android de Google, l’un des navigateurs les plus utilisé. La page d’accueil permet de consulter une sélection d’articles de presse. Il est dans le top 3 des pires navigateurs. Une certaine lourdeur provenant potentiellement de l’historique de la solution et de la non-priorité sur la vie privée.

Top 8 : Microsoft Edge

Le nouveau moteur de Microsoft est maintenant disponible sur Android. Peut-être que le bas du classement est du à la non-adaptation du moteur pour Android.

Top 9 : Firefox

Edité par Mozilla, le navigateur annonce une fiabilité sur le respect de la vie privée. Nous sommes cependant déçu de sa place dans ce classement.

Conclusion

Le choix du navigateur ne doit pas uniquement se faire sur l’autonomie, mais il s’agit d’un critère important. On observe que les 3 acteurs historiques et reconnus (Microsoft, Google et Mozilla) sont en bas du classement. Ceci est surement dû à l’ancienneté des applications, et donc à une surcharge pondérale du code (Obésiciel ou bloatware). Mais on peut aussi aller observer une course à la performance qui a été faite au détriment de l’autonomie. Peut-être que la course entre les 3 n’a pas été bénéfique à leur amélioration. On se souvient par exemple du benchmark de Microsoft Edge … avec uniquement Chrome et Firefox. Peut-être que l’arrivée de nouveaux navigateurs sérieux va changer la donne.

On peut noter que les différences d’autonomie entre navigateurs sont aussi liées à certaines fonctionnalités comme les fils d’actualités sur les pages d’accueil par défaut. L’utilisateur a cependant une marge de manoeuvre : désactiver ces fonctionnalités s’il ne les utilise pas.

A noter que la base open source Chromium qui se retrouve dans différents navigateurs (Brave, Samsung Internet, Ecosia…) n’est pas forcément la plus optimisée (On retrouve la plupart des navigateurs en milieu de classement.) Une optimisation du coeur (et potentiellement une meilleur intégration par les éditeurs) permettrait de diminuer la consommation de plusieurs navigateurs. On voit ici le potentiel de l’open source qui n’est pas utilisé pleinement.

Fait marquant de ce benchmark, les nouveaux arrivants sur le marché avec un vrai positionnement sur la vie privée sont au top du classement (Brave et Firefox Focus). Respect de la vie privée et environnement vont dans le même sens. C’est un bon signal pour les utilisateurs.

Méthodologie

Nous effectuons nos mesures de la consommation réélle d’énergie du téléphone avec l’outil GREENSPECTOR. Le smartphone Samsung Galaxy S7 a été utilisé pour ce Benchmark.

La méthodologie vise à réaliser un parcours qui est représentatif de l’usage d’un utilisateur. Nous étudions comment le navigateur se comporte sur le même parcours. Le parcours dure 5 minutes et est réalisé 4 fois pour obtenir des mesures fiables.

Au préalable une préparation du téléphone est réalisée :

Configuration maitrisée (luminosité, Wi-Fi activé(e)…)

Fermeture de toutes les applications et services : Permet de ne pas être pollué par d’autres applications et d’avoir des mesures fiables

Suppression des caches des navigateurs

Accès réseau stabilisé

Le parcours suivant est ensuite réalisé :

Lancement du navigateur sur la page d’accueil configurée à l’installation

Attente de 20 secondes (foreground) : permet de mesurer l’impact de la page d’accueil.

Pour 3 sites de type différents (Wikipedia, lemonde.fr, pinterest) : Lancement de la page, Scroll en bas de page, attente de 20 secondes

Lancement à nouveau des 3 sites pour évaluer l’impact de la mise en cache

Mise en tache de fond du navigateur (background) : permet de voir comment la navigateur se comporte quand il n’est pas en avant sur le téléphone.

On projette ensuite la consommation d’énergie unitaire obtenue sur un usage continu pour obtenir l’autonomie finale.

Pour information, voici les données brutes d’énergie mesurée :

{{< gsp-image title=”” src=”/assets/img/articles/2018-11-19-navigateurs/ConsommationScénario.png” >}}

Faut-il activer le mode nuit pour augmenter l’autonomie de ma batterie ? Le cas de l’application Twitter

Reading Time: 2 minutes

Quelques applications comme Youtube, Google Chrome ou Twitter proposent un fond d’écran non pas blanc mais noir. Ce mode “Nuit” ou thème Dark dédié à une utilisation nocturne, facilite la lecture la nuit, repose vos yeux et surtout vous évite de vous transformer en phare. Cependant qu’en est-il réellement pour votre batterie ?

Nous avons choisi de comparer le mode “Jour” et “Nuit” de l’application Twitter pour cette battle d’efficience.

(Re)découvrez nos autres articles comparatifs sur Twitter & Twitter Lite ainsi qu’Instagram & Instagram Lite.

Mode “Nuit” pour l’application Twitter

Le passage en mode “Nuit” est très simple :

Ouvrez votre application Twitter

Cliquez sur la bulle de votre profil en haut à gauche

Cliquez sur l’icone de croissant de lune en bas à gauche de votre écran

Vous pouvez également activer ou désactiver le mode “Nuit” depuis les Paramètres :
– Allez dans “Paramètres et confidentialité” (Settings and privacy)
– Allez dans “Affichage et Son” (Display and sound)
– Cliquez sur mode “Nuit” (Night mode).

Et voici le résultat du mode “Nuit” versus le mode “Jour” :

Quel gain pour l’énergie ?

Sur 30 secondes, le mode “Jour” va consommer 3,92 mAh et le mode “Nuit” 2,98 mAh. Le mode “Nuit” est donc moins consommateur de -23%. Pourquoi ? La mesure a été effectuée sur un Samsung Galaxy S7 qui possède un écran AMOLED. Ces écrans sont beaucoup moins consommateurs sur des couleurs sombres, retrouvez notre article explicatif à ce propos sur notre blog.

Est-ce que cela fait une différence sur l’autonomie de mon téléphone ? Absolument ! Avec le mode “Jour” activé, 1 heure de réseau social (notamment Twitter) va décharger la batterie de 15% alors qu’en mode “Nuit”, la décharge ne va être que de 11%.

C’est donc une victoire pour le mode “Nuit” !

Note : Les mesures ont été effectuées simplement avec l’outil GREENSPECTOR sur un Samsung Galaxy S7. Je vous invite à parcourir ce blog pour plus d’informations sur les outils et la méthodologie.

Comment estimer l’autonomie d’un smartphone en moins d’une heure chrono ?

Reading Time: 6 minutes

Connaître l’autonomie précise d’un téléphone est important car il s’agit de l’un des premiers critères d’achat des smartphones. Cela est d’autant plus critique pour les flottes de devices (en mode B2B) dans les entreprises. En effet, une mauvaise autonomie va engendrer des baisses de productivité voire des insastisfactions clients. Il est donc nécessaire d’avoir une bonne stratégie pour choisir ses devices ainsi que les applications qui seront hébergées dessus.

Les approches classiques d’estimation de l’autonomie

Une première approche est de se baser sur les données fournies par les constructeurs. Néanmoins, la limite de cette approche est que ces données se basent sur des scénarios d’usage qui ne sont pas forcément représentatifs des vôtres. Le risque est donc d’avoir une réalité d’autonomie très éloignée de ce que vous aurez estimé. D’autant plus que certaines fonctionnalités (comme la prise de photo par exemple..) seront peut être peu optimisées sur un certain type de smartphone et seront très utilisées dans votre usage. Cette critique est aussi valable pour des tests réalisés par des laboratoires externes.

Une seconde approche est de réaliser des tests sur des devices rééls et en effectuant le scénario cible. Des outils existent pour lancer des benchmarks automatiquement mais vous pouvez aussi effectuer manuellement vos tests. L’avantage est d’avoir une autonomie réaliste. Le seul problème est que ces tests sont très chronophages. Et cela ne donne pas le droit à l’erreur. En effet, si vous voulez changer un paramètre sur le smartphone (luminosité…) ou ajouter une application à tester, vous devez relancer toute la campagne de tests.

Une dernière approche consiste à laisser les utilisateurs faire les tests. Vous attendez les retours d’utilisateurs ou bien vous utilisez les outils de déploiement de flotte (MDM) pour remonter les informations. Cela a l’avantage d’être peu couteux, l’inconvénient c’est qu’il existe un coût caché : si il y a un problème, il y aura forcément de l’insatisfaction et de l’improductivité engendrées. Et cela vous oblige a choisir un device qui devra peut-être être remplacé.

L’approche innovante de GREENSPECTOR

Pour répondre à ce besoin de maîtriser l’autonomie des devices (et de choisir au plus tôt le bon device), GREENSPECTOR propose une approche basée sur des mesures réelles mais unitaires avec un algorithme de projection. La démarche se compose de 3 étapes :

  • Mesure des fonctionnalités principales sur les devices à évaluer
  • Configuration d’un scénario cible
  • Projection et analyse des données

Cas d’usage

Nous souhaitons estimer l’autonomie d’un usage classique sur un smartphone Samsung Galaxy S7. L’usage peut être un usage en entreprise mais aussi un usage intensif personnel:

  • 30 minutes de navigation internet
  • 30 minutes de réseau social
  • 30 minutes de conversation téléphonique
  • 30 minutes de prise de photo
  • 10 minutes d’enregistrement vidéo
  • 30 minutes d’e-mail
  • 30 minutes de visioconference
  • 30 minutes de Microsoft Word
  • 10 minutes de réservation de train
  • 30 minutes de géolocalisation

Ce scénario est volontairement générique mais nous pourrions y ajouter une application spécifique ou bien un usage exotique…

Mesure des fonctionnalités

Nous utilisons le module Free Runner de GREENSPECTOR qui permet d’effectuer des tests manuels. Ces actions peuvent être autonomatisées mais dans l’approche de cet article, nous nous concentrons vers des tests rapides orientés tests exploratoires. Si un benchmark de plus grande ampleur est nécessaire, l’automatisation aurait tout son intéret.

Pour chaque étape du scénario (navigation, prise de photo…), nous lançons le module Free Runner et nous effectuons un scénario représentatif d’un usage réél sur 1 minute.
Le module GREENSPECTOR envoie directement les mesures au serveur GREENSPECTOR. Au final cela nous a pris un peu plus de 10 minutes pour obtenir l’ensemble des mesures. Si l’on veut un peu plus de précision (ou de représentativité), nous pouvons relancer quelques itérations.

À cette étape, les fonctionnalités ou applications les plus consommatrices peuvent être identifiées.

Mise en place de la stratégie de budget

Au sein de l’interface GREENSPECTOR sur l’onglet Budget, vous allez pouvoir initier une projection d’autonomie :

Vous allez être guidé dans la configuration du budget. Une première étape est de préciser l’autonomie que vous souhaitez atteindre. Si vous êtes sur une flotte de device, vous voulez probablement que votre utilisateur ai au moins 9 heures d’autonomie pour finir la journée sans avoir à recharger le téléphone.

GREENSPECTOR vous propose alors les étapes possibles du scénario. Elles sont issues des mesures que vous aurez effectué précédemment.

L’étape la plus compliquée pour vous maintenant va être de préciser combien de fois ou combien de temps vous souhaitez que l’action se produise. Par exemple, on se base sur des durées cibles de 30 minutes, il faut donc entrer cette donnée pour chaque étape. Pas d’inquiétude, cela pourra être modifié plus tard .

Vous pouvez ensuite valider et laisser l’algorithme se calculer. Pas le temps de prendre un café, le résultat des projections est immédiat :

Analyse des resultats de l’algorithme

Le premier warning dans la fenêtre signifie que la projection d’autonomie en fonction de votre scénario et des mesures réélles permettent de dire que l’autonomie de 9 heures ne sera pas respectée.

On retrouve cette information dans le graphique de projection :

  • la 1ère barre est la capacité disponible d’énergie utilisable sur 9 heures : La capacité du téléphone S7 soit 3000 mAh.
  • la 2ème barre est la répartition d’énergie (les bugdets unitaires) par fonctionnalité si vous voulez respecter l’autonomie voulue.
  • La 3ème barre est la projection de consommation associée aux mesures réélles.

On le voit, la consommation réelle mesurée est de 3300 mAh alors que la capacité du téléphone est de 3000 mAh. Cela ne passe pas ! Nous verrons plus loin quoi faire pour corriger cela.

La notion de budget unitaire apparait sur le graphique et sur la partie de droite. Il s’agit de la répartition idéale de consommation d’énergie sur chaque fonctionnalité pour respecter l’autonomie. Voici les grands principes de l’algorithme:

  • Afin de rester proche d’un usage réel, l’algorithme ajoute une période d’inactivité qui correspond à ce que l’utilisateur ferait entre ses actions (Idle foreground)
  • Une période de veille profonde est ajoutée qui correspond à une inactivité de longue durée du téléphone (Idle background)
  • Aux périodes d’idle que vous allez définir (par exemple un idle correspondant à une pause le midi) vont être associées un budget qui se base sur la consommation de référence du téléphone
  • Aux actions, vont être affectés un budget qui correspond à une consommation maximum de x2 la consommation de référence.

Au final, le budget unitaire de chaque action est la quantité d’énergie qu’une action unitaire ne doit pas dépasser. Comme ça, vous pouvez vérifier par rapport à la mesure réelle si l’action consomme trop :

On voit ici que la consommation de la navigation est importante et dépasse le budget. Cette fonctionnalité contribue au non-respect de l’autonomie souhaitée.

Au final, vous pouvez analyser les données hors GREENSPECTOR et par exemple visualiser la courbe de décharge batterie :

Comment obtenir une autonomie correcte ?

Un premier axe est de remplacer le téléphone. En effet, vous avec peut être choisi le mauvais device par rapport à votre usage. Idéalement, les projections d’autonomie permettront d’effectuer un benchmark pour éviter un changement trop tardif.

Ensuite, peut-être que le scénario n’est pas réaliste. Il sera alors nécessaire de repenser à l’usage : est-ce que la video conférence via mobile est vraiment viable ? Malheureusement, cette approche est générablement écartée car on veut toujours plus de service numérique sur les devices. Les approches suivantes seront alors plus adaptées.

Le budget unitaire va être utile pour appliquer une meilleure stratégie :

  • Sur des applications du système (caméra par exemple), on étudiera la possibilité de paramètrer différement l’application pour trouver des optimisations et réduire la consommation pour rester dans le budget défini.
  • Pour d’autres applications comme les navigateurs on pourra benchmarker des applications alternatives. Il est probable par exemple que les solutions de visioconférence ne se valent pas toutes en se qui concerne la consommation d’énergie.
  • Pour les applications développées par un tiers et que vous maitrisez, vous pourrez intégrer un critère dans les cahiers des charges pour respecter le budget souhaité.
  • Enfin pour les applications ou sites web développés en interne, vous pourrez intégrer GREENSPECTOR et les budgets dans l’usine logicielle pour optimiser au plus tôt la consommation de vos applications et ainsi, détecter les problèmes d’énergie et de performance avant vos utilisateurs.

Adaptive Battery sous Android 9 Pie : Votre application risque d’être fortement impactée

Reading Time: 4 minutes

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 :

BucketsJobAlarmNetworkFCM
ActivePas de restrictionPas de restrictionPas de restrictionPas de restriction
Working setDécalé jusqu’à 2 heuresDécalé jusqu’à 6 minutesPas de restrictionPas de restriction
FrequentDécalé jusqu’à 8 heuresDécalé jusqu’à 30 minutesPas de restrictionHigh priority: 10/jour
RareDécalé jusqu’à 24 heuresDécalé jusqu’à 2 heuresDécalé jusqu’à 24 heuresHigh priority: 5/jour

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.