Auteur : Olivier PHILIPPOT

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 Porteur du projet de label Green Code Label Responsable du projet de l’étiquette énergétique WebEnergyArchive

Quels sont les meilleurs navigateurs web à utiliser en 2020 ?

Reading Time: 8 minutes

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

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

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

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

Classement global

La note sur 100 des navigateurs est la suivante :

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

Consommation d’énergie globale (en mAh)

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

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

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

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

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

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

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

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

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

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

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

Projection d’autonomie (en nombre d’heures)

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

Consommation de données (en Mo)

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

Sur la navigation, on explique cette différence :

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

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

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

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

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

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

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

Performance des navigateurs (en seconde)

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

Lancement du navigateur

Ajout d’un onglet

Écriture d’une URL

Suppression du cache

Bench Mozilla Kraken

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

Efficience des navigateurs (en mAh/s)

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

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

Piste d’améliorations

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

Pour l’utilisateur :

Choisir un navigateur efficient

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

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

Pour les développeurs de sites :

Éco-concevoir leur site

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

Pour les éditeurs de navigateurs :

Mesurer la consommation d’énergie et l’efficience

Éco-concevoir les fonctionnalités

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

Rendre la page d’accueil la plus sobre possible.

Protocole de mesure

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

Évaluation des fonctionnalités

Lancement du navigateur

Ajout d’un onglet

Écriture d’une URL dans la barre de recherche

Suppression des onglets et nettoyage du cache

Navigation

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

Benchmark navigateur

Le benchmark Mozilla Kraken permet de tester la performance JavaScript

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

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

Après navigation

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

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

Suppression du cache et des onglets (sans mesure)

Première mesure

Deuxième mesure pour mesurer le comportement avec cache

Suppression du cache et des onglets (avec mesure)

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

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

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

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

Notation

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

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

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

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

Navigateurs évalués

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

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

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

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

Reading Time: 4 minutes

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

Inclusion

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

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

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

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

Sobriété

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

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

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

Performance

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

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

Discrétion

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

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

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

Écologie

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

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

Améliorer directement l’application

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

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

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

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

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

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

Métriques plus globales

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

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

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

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

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

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

Et maintenant ?

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

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

Reading Time: 3 minutes

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

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

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

Outils de monitoring vs outils de développement

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

Avantages :

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

Inconvénients :

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

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

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

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

Avantages :

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

Inconvénients :

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

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

Avantage :

  • Vision réelle de la performance des applications

Inconvénients :

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

Tests techniques vs tests fonctionnels pour les outils de monitoring

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

Avantages :

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

Inconvénient :

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

Avantages :

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

Inconvénient :

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

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

Environnement émulé ou physique

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

Avantage :

  • Mise en place assez rapide

Inconvénient :

  • Performance ne correspondant pas à des devices réels

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

Avantage :

  • Performance identique aux devices réels

Inconvénients :

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

Les conseils des experts GREENSPECTOR

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

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

Le Top 10 des mythes du numérique sobre

Reading Time: 5 minutes


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

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

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

Faux.

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

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

Vrai et Faux

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

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

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

Vrai et Faux

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

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

Un logiciel de mesure sera alors complémentaire 😉

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

Faux

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

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

Vrai et Faux

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

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

Vrai et Faux

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

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

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

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

Faux

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

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

Faux

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

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

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

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

Faux

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

Mythe n°10 – Je compense donc je suis green

Faux

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

Conclusion

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

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

Reading Time: < 1 minute

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

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

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

Reading Time: 2 minutes

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

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

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…