Catégorie : Numérique responsable

Les ventes effectuées sur les sites e-commerce progressent chaque année, de plus en plus en mobilité ou depuis un smartphone à la maison. Nous n’avons jamais autant consommé via ces plateformes web qu’aujourd’hui. Un débat persiste entre l’impact écologique du e-commerce en terme logistique en comparaison avec un achat effectué en magasin. Tout dépend de certains paramètres (temps de livraison, situation géographique du magasin, moyens logistiques utilisées…). A cette question logistique, s’ajoute celle de l’impact environnemental du numérique pour l’achat e-commerce. Comment estimer la part que représente ces achats online vis à vis de l’impact environnemental de notre vie de consommateur ?

Pour répondre à cette question sur le e-commerce en France, nous avons pris pour base le classement des plus gros sites e-commerce en France (Top 100 E-Commerce : Étude E-Commerce Nation & SimilarWeb) et nous y ajoutons à votre demande d’autres sites. Nous mesurons les consommations d’énergie et de ressources sur un smartphone de gamme moyenne qui nous permettent d’évaluer les impacts Carbone sur l’ensemble de la chaîne : device (méthodologie Greenspector), réseau et datacenter (Méthode OneByte du ShiftProject). Cette évaluation se fait sur la base de la page d’accueil du site e-commerce et sur la base d’un protocole de 1 minute. L’écoscore Greenspector vient compléter l’évaluation du site à la fois par le respect de bonnes pratiques mais aussi la mesures d’autres métriques de ressources non évaluées dans l’impact Carbone.

Classement de l’impact carbone du Top 100 des sites web E-commerce

Votre site de e-commerce n’est pas dans ce classement, contactez-nous pour réaliser une mesure et apparaître dans ce classement !

Thierry Leboucq

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 !

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 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…

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

Il a été beaucoup question avant et pendant cet évènement Viva Technology 2018 de la notion de #TechForGood. L’idée ? Encourager les « géants de la tech » (et les moins géants) à contribuer, via leurs solutions technologiques, à la réalisation de progrès sociétaux ou environnementaux.

Thomas CORVAISIER

Thomas CORVAISIER est directeur général de GREENSPECTOR. Après une formation d’ingénieur, il a réalisé un parcours de plus de 15 ans en conseil auprès de grands comptes français et internationaux d’abord autour de la production des systèmes d’informations et l’organisation des DSI, puis sur des problématiques de responsabilité sociale et environnementale (comptabilité carbone, management environnemental, Green IT).

Fin de l’année 2017, Apple subit un bad buzz en étant accusé de ralentir intentionnellement les vieux Iphone. Et cela relance le débat sur l’obsolescence programmée. Un débat souvent manichéen : méchant constructeur versus gentil consommateur. Ou même l’inverse (ce qui est surprenant pour ma part) : concept de l’obsolescence qui est crée par les ONG.

Reprenons depuis le début :

Les batteries de nos téléphones sont principalement basées maintenant sur la technologie Litthium-Ion. Le comportement chimique de la batterie se dégrade en fonction du nombre de cycle de charge/décharge. Après 500 cycles, la batterie n’a plus que 80% de sa capacité batterie (l’OS du téléphone recalcule cependant un niveau pour afficher 100%). Cela veut dire que si vous aviez une batterie de 3000mAh, après 500 cycles, vous n’avez plus que 2400mAh.

Le vieillissement de la batterie s’accompagne d’une perte de puissance de la batterie surtout sur la gestion des pics de charge. Vous avez peut être vécu cela, votre téléphone ou PC est à 10% et tout d’un coup le niveau dégringole. Et comme souvent, cela arrive vers le niveau de batterie bas, le téléphone s’éteint rapidement sans vous avertir. C’est ce qu’Apple explique dans son blog.

Pour limiter cela, Apple essaye de limiter les pics de charge en limitant la fréquence du CPU. Il y a normalement moins de pics de charge. Cependant, sur le téléphone, il y a aussi d’autres gros consommateurs (GPS, Cellule radio…). On peut se poser la question si Apple ne ralentit pas d’autres choses.

Mais avant cela, il faut revenir sur cette histoire de cycle. Est-ce une fatalité ? Un cycle est directement lié au niveau de consommation du téléphone qui va lui être dépendant de plusieurs choses :

• La consommation du matériel
• La consommation de l’OS
• Votre usage (nombre d’appel, vidéo…)
• La consommation des applications

Sur les deux premiers points, les constructeurs font généralement des efforts. Sur l’usage, vous êtes le maître. Cependant il y a peu de communication. Sur la consommation des applications, il n’y a pas de fatalité (c’est d’ailleurs l’objectif de GREENSPECTOR)

Avec cela en tête est-ce qu’Apple est responsable de l’obsolescence ? Et si oui, est-ce de l’obsolescence programmée ? Tout d’abord, la cause de l’obsolescence est répartie : Est-ce qu’Apple est responsable de la surconsommation de certaines applications ? Certains constructeurs tentent de résoudre cela en pointant du doigt les applications consommatrices. Sur ce point, Apple ne fait pas vraiment de zèle. 0 pour les concepteurs d’application, 0 pour Apple.

Sur l’usage, Apple fait le strict minimum sur la communication. C’est plus hype de communiquer sur le fait de pouvoir animer un émoticon que cela. En même temps, les utilisateurs préfèrent cela. Les médias aussi : c’est plus intéressant de sortir le marronnier des files d’attente interminables à chaque sortie de nouvelles versions. 0 pour Apple, 0 pour les médias, 0 pour les utilisateurs.

0 pour tout le monde, donc plutôt obsolescence partagée ! Cependant, ce qui est très critiquable dans la prise en compte par Apple du vieillissement de la batterie (qui est bien réel), ce n’est pas le ralentissement, c’est la non communication. L’utilisateur est assez intelligent pour comprendre un message du type « votre batterie devient vieille, nous conseillons un ralentissement de votre téléphone: Oui, Non (je préfère changer de batterie) ». Mais là encore, cela ne va pas dans le sens du « hype » et d’un produit qui pourrait paraitre un peu trop technique (ce qui est la réalité). Et sur ce point, Apple en n’avertissant pas l’utilisateur sur le ralentissement, l’utilisateur ne peut pas être responsable et agir en tout état de cause. Il n’a pas tous les éléments en main pour évaluer la situation. Et probablement, c’est un manque de paramètre qui va le faire potentiellement basculer vers un renouvellement. Et dans ce cas oui, Apple fait de l’obsolescence programmée.

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

La phase de fin de vie d’un logiciel est également difficile à appréhender et fait donc ici l’objet d’un article dédié, clôturant notre série sur l’ACV des logiciels.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Les logiciels se cachent pour mourir (fin de vie & obsolescence)

La phase de fin de vie d’un logiciel est particulièrement délicate à envisager dans l’analyse de cycle de vie, notamment pour les deux raisons suivantes :

1) Il n’existe pas d’obsolescence intrinsèque à un logiciel. Un logiciel est théoriquement utilisable à l’infini, tant qu’il existe des matériels pour le faire fonctionner. Le logiciel ignore l’usure et ne risque pas de tomber en panne parce qu’il est lui-même devenu trop vieux. On ne peut donc pas déterminer une durée de vie d’un logiciel qui serait liée au fait que ses composants vont se dégrader au cours du temps. Les seules raisons qui rendent un logiciel obsolète sont extérieures au produit lui-même :

• décision de l’utilisateur de le supprimer,
• politique de maintenance d’une version,
• obsolescence des matériels supportant le logiciel,
• obsolescence des autres logiciels en interaction avec le logiciel (système d’exploitation, bases de données…),
• disparition du besoin utilisateur
• etc.

2) Un logiciel ne génère pas en apparence de déchets matériels en fin de vie. Lorsqu’on décide de ne plus l’utiliser – ou qu’on ne peut plus l’utiliser – il est simplement supprimé du poste sur lequel il est installé sans que cela ne génère de déchets matériels. Au pire, il reste des fichiers qui occupent inutilement de l’espace disque. Mais en réalité, si l’on y regarde de plus près on trouve des déchets matériels (déchets liés au processus de conception / développement, CD + boîte + Manuel papier (si le logiciel était emballé…)… pris en compte dans d’autres étapes de l’analyse), et surtout des déchets liés au matériel (ordinateur, smartphone, tablette, équipement réseau …) utilisé pour faire fonctionner le logiciel.

En quoi le logiciel contribue-t-il à générer des déchets ? Tout simplement par son impact direct ou indirect sur l’obsolescence du matériel :

Remplacement ou mise à jour logiciel nécessitant de nouveaux équipements :

Pour un même besoin utilisateur, si le logiciel subit une mise à jour majeure ou s’il est remplacé par un autre logiciel, et que cette opération nécessite d’autres ressources matérielles (machines plus puissantes, technologies différentes), alors on peut considérer les anciens matériels comme des déchets causés par le logiciel. C’est le phénomène d’ « obsolescence des matériels » entraîné par le renouvellement des logiciels : c’est donc le logiciel qui est responsable du déchet. Un logiciel mature (sans évolution fonctionnelle) n’a pas de raison d’être à l’origine de déchets… Mais quel logiciel n’évolue pas ? On veillera, a minima, à contrôler les consommations de ressources demandées par les nouvelles versions du logiciel.

Mauvaise désinstallation :

une procédure de désinstallation mal conçue ou mal appliquée peut aussi contribuer à l’obsolescence. En effet, des clés de registre laissées, des fichiers temporaires ; si le logiciel ne laisse pas le système comme il était avant, on crée un empreinte ressource résiduelle qui vient alourdir le fonctionnement du système.

Effet de bord de la désinstallation sur d’autres logiciels :

Il faudra également s’intéresser aux autres logiciels que la désinstallation en fin de vie peut rendre obsolètes : des dépendances peuvent exister qui risquent d’avoir un effet d’obsolescence en cascade (je mets à jour mon logiciel => il exige une nouvelle version de gestionnaire de base de données => ce gestionnaire demande une mise à jour de l’OS => le nouvel OS n’a plus de pilote pour mon imprimante => je change mon imprimante…).

On le voit, la phase de fin de vie d’un logiciel peut s’avérer complexe à appréhender. Toutefois on gagnera lors de l’étude à en faire une première approximation rapide, afin de déterminer si elle représente un poids relatif important ou non par rapport aux autres phases.

Cette série sur l’ACV des logiciels est maintenant terminée, retrouvez sur le blog les précédents articles traitant de ce sujet:

• Pourquoi réaliser une ACV des logiciels ?
• Les spécificités des produits logiciels;
• Le cycle de vie d’un logciel.

Vous pouvez auss retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Thierry Leboucq

L’objectif de cet article est de présenter le cycle de vie d’un logiciel. Pour chacun des problèmes que soulève l’analyse de ce cycle de vie, nous indiquerons l’approche que nous recommandons, notamment pour l’évaluation des impacts environnementaux.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réelle sur l’évaluation des impacts environnementaux d’une application disponible en téléchargement.

La grande majorité des cycles de vie des produits manufacturés étudiés lors des ACV (Analyses de Cycle de Vie) peuvent être considérés comme étant composés des 6 phases suivantes:

• la conception du produit,
• l’extraction des matières premières,
• le processus de fabrication et de conditionnement,
• le processus logistique et d’acheminement,
• l’usage du produit,
• la fin de vie (démontage, transport, tri, recyclage, déchets).

Cependant, si ce cycle de vie est pertinent pour un produit matériel usuel, il l’est moins pour un logiciel. En effet, en tant que « bien immatériel », un logiciel ne nécessite pas directement d’extraction de matières premières.
La phase de fabrication n’est pas envisageable comme un processus de fabrication répété N fois pour produire N exemplaires du produit : il faut plutôt la considérer comme une phase unique permettant d’aboutir à une version du logiciel théoriquement reproductible et réutilisable à l’infini.

Transport amont et distribution

Pour la phase de transport amont (logistique), si le logiciel est conçu à partir de différentes modules développés sur différents sites, il faudra (dans la mesure du possible) prendre en compte l’envoi depuis les différents sites vers le site d’agrégation des différents modules. Dans une première approche ces impacts pourront être considérés comme négligeables car ayant de très grandes chances de représenter moins de 5% des impacts totaux.
Si la distribution vers les utilisateurs finaux est réalisée via un téléchargement sur internet, l’impact environnemental de ce téléchargement devra être pris en compte. Si la distribution se fait par un support matériel (DVD, clef USB…) la fabrication et le transport de ces supports devront être pris en compte.
L’installation du logiciel peut être rattachée à la phase d’usage. La maintenance pourra être modélisée comme étant un surcoût de la phase de fabrication. La fin de vie d’un logiciel semble à première vue inexistante, ou du moins sans impact. Nous verrons plus loin qu’il n’en est rien en réalité. On devra intégrer la désinstallation des programmes et la destruction /récupération des données associées.
Comme proposé au sein du Green Patterns, le manuel de référence d’écoconception des logiciels par le Green Code Lab, on peut donc pour un logiciel simplifier ce cycle de vie en ne retenant que 4 phases: la fabrication, la distribution vers l’utilisateur final, l’utilisation, et la fin de vie/réutilisation/recyclage.

La fabrication

Ce processus de conception et de développement est considéré donc comme une phase unique permettant de produire le logiciel. Cette phase intègre tout le processus de conception du logiciel :

• analyse des besoins,
• conception,
• programmation,
• test,
• stabilisation,
• déploiement.

Les ressources associées aux maintenances correctives (correction de bug) et les enrichissements fonctionnels, sont à inclure dans cette phase.
Un logiciel est souvent et en partie constitué de composants tels que des frameworks, bibliothèques, librairies. Dans ce cas, on pourra considérer que la fabrication de ces composants a un impact négligeable au regard du nombre de copies (réutilisations) qui en sont effectuées.

La distribution/copie vers l’utilisateur final

Différents scénarios sont possibles, ici seuls 3 sont rapidement présentés (d’autres sont possibles).

• Téléchargement : le logiciel ainsi que la documentation sont distribués par voie électronique. Il faudra ici prendre en compte le périmètre de l’émetteur du programme (serveurs de téléchargement) mais également le récepteur (les ordinateurs des utilisateurs finaux) ainsi que l’infrastructure qui a permis de véhiculer les fichiers électroniques (réseau, routeurs, …) en prenant une quote-part de la construction du matériel et de l’énergie nécessaire au téléchargement du logiciel en fonction de la ressource utilisée.
• Le logiciel ainsi que la documentation sont packagés et envoyés par courrier postal, il faudra prendre en compte le support (CD-ROM, DVD, clef USB, documentation), l’emballage et le transport postal associé.
• L’utilisateur peut récupérer la licence et la notice d’utilisation dans un commerce ou par courrier postal et télécharger le logiciel. Il faut donc prendre en compte l’étape de packaging (fabrication & transport) ainsi que le téléchargement du logiciel. Dans ce cas particulier, les impacts liés au déplacement de l’utilisateur peuvent être forts et peuvent écraser les autres impacts. Des ACV précédentes, menées par le groupe Orange sur des terminaux, mobiles, modem, CD-ROM, ont montré que les déplacements des client pouvaient être très variés et très impactants, notamment s’ils ont lieu en voiture (plusieurs kg de CO2e)

L’utilisation du logiciel par l’utilisateur final débute par la phase d’installation sur son matériel (mise en service) suite au téléchargement (distribution) par exemple et couvre toute la phase d’usage du logiciel sur le matériel adéquat de l’usager. Le périmètre intègre :

• le matériel nécessaire ou prérequis pour utiliser le logiciel. Dans ce cas, on prend en compte la quote-part de :
  • la fabrication du matériel (l’équipement de l’utilisateur, accès réseau, accès serveur),
  • l’utilisation de l’énergie en phase d’usage du matériel (l’équipement de l’utilisateur avec éventuellement l’accès réseau et serveur) et qui peut intégrer par défaut la consommation des logiciels prérequis ;
  • les logiciels prérequis intégrant leurs consommations de ressources (OS, machines virtuelles, …). On peut isoler la consommation de ressources de ces logiciels prérequis en établissant une valeur étalon appelée « Idle » qui correspond à la consommation de ressources du matériel et de ses logiciels prérequis, avant toute exécution du logiciel étudié ; cette valeur peut-être décomposée en autant de valeurs si on souhaite isoler l’OS du navigateur par exemple ;
• le logiciel étudié intégrant sa consommation d’énergie :
  • les données nécessaires pour utiliser le logiciel ou créées par le logiciel et stockées sur les différentes ressources de matériel de l’application ;
  • la consommation d’énergie associée à ces données est intégrée par défaut dans l’équipement.

Par exemple dans le cas d’une page Web, les prérequis matériels et logiciels pour afficher la page côté utilisateur sont : un ordinateur/tablette/smartphone, un OS (Android, Windows, iOS…), le navigateur (Firefox, Chrome, Edge, Safari…) et les plugins éventuels.

La fin de vie / réutilisation / recyclage

On fait l’hypothèse qu’en fin de vie un logiciel est effacé ou désinstallé côté usager / côté éditeur du logiciel. Il y a plusieurs points à prendre en compte pour cette étape : la fin de vie du matériel support et la fin de vie des données générées par le logiciel.

• Fin de vie du matériel support : on revient ici à une problématique habituelle de fin de vie d’un support matériel électronique donc complexe et polluant, classé en DEEE (Déchet d’Équipement Électrique et Électronique)
• Fin de vie des données : on pourra considérer la bonne désinstallation du logiciel selon une procédure qui supprime tous les fichiers de configuration sur le poste client. On doit prendre également en considération dans cette phase les données générées par le logiciel et qui ont été créées volontairement ou non par l’utilisateur. Plusieurs cas se présentent :
  • l’utilisateur ne souhaite pas récupérer les données qu’il a produites ;
  • l’utilisateur souhaite récupérer ces données pour les utiliser avec un autre outil comparable et un processus de conversion est prévu ; ce processus a été pris en compte dans ce nouvel outil dans le cadre de sa phase de fabrication ;
  • l’outil ne permet pas le processus de récupération et de conversion des données pour une nouvelle utilisation ; on devra alors estimer l’impact de la conversion pour l’utilisateur dans cette phase de fin de vie.

Pour terminer cette série sur l’ACV des logiciels, le prochain article du blog traitera de l’obsolescence programmée des logiciels. En effet, la phase de fin de vie d’un logiciel étant difficile à appréhender, cela fera l’objet d’un article dédié

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Thierry Leboucq

L’objectif de cet article est de présenter les caractéristiques propres aux logiciels lors d’une analyse de cycle de vie (ACV). Pour chacun des problèmes que soulèvent ces spécificités, nous indiquerons l’approche que nous recommandons pour l’évaluation des impacts environnementaux.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réelle sur l’évaluation des impacts environnementaux d’une application disponible en téléchargement ici.

Logiciel : bien matériel ou immatériel ?

Le logiciel est un bien particulier :

• Il ne génère pas de déchet physique direct

• Il n’est pas directement branché à une source d’alimentation et n’est donc pas perçu comme « consommateur ».

• Il a néanmoins un impact sur l’environnement à travers une consommation de ressources et d’énergie due au matériel nécessaire à son développement et à son utilisation.

L’ACV a pour but d’évaluer les impacts environnementaux de biens manufacturés, services et procédés. Mais où se situent les logiciels parmi ces trois types de produits ?

À première vue, les logiciels s’apparentent fortement à des biens matériels tels que ceux créés par l’industrie traditionnelle puisqu’ils sont matérialisés par un ensemble de données informatiques (code source et / ou exécutable) que l’on peut échanger, posséder et utiliser pour satisfaire un besoin précis. Mais il faut bien distinguer le support de stockage et les interfaces physiques d’interaction du logiciel lui-même : le logiciel n’est en réalité rien de plus qu’un état du support de stockage (constitué par une suite bien définie et unique de 0 et de 1), un état du réseau transportant ces données, un ensemble d’états de l’écran affichant la représentation graphique du logiciel, etc. Devrions-nous donc considérer le logiciel plutôt comme un bien « immatériel » ?

Pour répondre à ces questions, il convient de bien faire la distinction entre le logiciel lui-même et le service qu’il rend. Ainsi, on peut effectivement considérer un logiciel comme un bien immatériel qui rend un ou plusieurs services particuliers (ses fonctionnalités ou contenus). En tant que bien immatériel, ses impacts environnementaux résulteront de l’utilisation de ressources (humaines, physiques/matériels…) nécessaires à la mise en œuvre des différentes phases de son cycle de vie : fabrication/développement, fonctionnement, distribution, fin de vie.

Faut-il isoler un logiciel de son environnement de fonctionnement ?

Il est évident qu’un logiciel ne fonctionne jamais seul, mais toujours dans un écosystème avec d’autres logiciels dont il dépend, à commencer par l’OS (système d’exploitation), ou avec lesquels il est en communication ou en interaction. Ainsi, mesurer les impacts générés par le seul logiciel étudié en phase d’utilisation est compliqué.

L’impact du logiciel est indissociable du matériel et de l’OS avec lequel il fonctionne : il n’est pas possible lors d’une ACV d’identifier directement les impacts environnementaux liés à l’OS ou au matériel. Ces impacts peuvent malgré tout être obtenus au travers d’ACV comparatives, c’est-à-dire en comparant par exemple les ACV de deux configurations bien spécifiques : par exemple Logiciel A sur équipement X avec OS1 versus Logiciel A sur équipement X avec OS2 ; c’est ainsi qu’il sera possible d’identifier le delta d’impacts entre les OS1 et OS2. D’autres analyses de sensibilité permettraient d’évaluer les deltas d’impact liés aux différents matériels par exemple.

Un équipement informatique ne fonctionne pas uniquement pour le logiciel étudié. Généralement d’autres applications/logiciels fonctionnent en parallèle sur le même équipement et donc consomment des ressources. Aussi la totalité de la puissance consommée par l’équipement ne peut pas être attribué au logiciel considéré. La stratégie prise dans le cadre du projet de recherche Web Energy Archive pour attribuer au logiciel l’énergie qu’il consomme, est de retrancher la consommation d’énergie due à l’OS et aux services tels que l’antivirus (on parle de consommation en mode idle), à la consommation totale de l’équipement.

Logiciel : quel périmètre considérer?

L’une des principales difficultés à laquelle on se heurte lorsque l’on réfléchit à l’évaluation des impacts environnementaux d’un logiciel est que ce dernier évolue régulièrement au travers des différentes versions (correctrices ou fonctionnelles) et peut avoir une architecture modulaire, voire fonctionner simultanément sur différents équipements.

Un logiciel évolue sans cesse.

Un logiciel se décline la plupart du temps en une multitude de versions et sous-versions qui comprennent des ensembles de fonctionnalités différents. On peut être tenté de dire que cela ne pose pas de problème majeur car les versions sont très espacées dans le temps… mais c’est rarement le cas. Suite à la sortie par un éditeur d’une « release » officielle de version bien identifiée, le logiciel peut très rapidement faire l’objet de patchs correctifs ou de modules complémentaires qui peuvent devenir très nombreux et fréquents. Cette approche de releases fréquentes s’est nettement accentuée ces dernières années.

Il faut donc différencier les évolutions mineures, des évolutions majeures d’un logiciel :

• Les évolutions majeures apportent de nouvelles fonctionnalités, voire restructurent complètement une application.

• Les évolutions mineures apportent principalement des corrections de bugs ou des ajouts de fonctionnalités secondaires.

Puisqu’il est difficile de parler de version « finie » d’un logiciel, nous proposons de limiter l’étude à la « dernière version stable la plus largement diffusée et utilisée ». Quoiqu’il en soit, la version étudiée devra figurer clairement dans les hypothèses de l’étude.
L’impact des versions correctives et/ou fonctionnelles, qu’elles soient mineures ou majeures ne pourra être pris en compte qu’au travers d’une analyse de sensibilité. C’est-à-dire que l’on modélisera l’impact d’une correction de bug et une évolution fonctionnelle par l’ajout de ressources supplémentaires (RH, consommation de papier, matériel…) lors de la phase de fabrication/développement ou au travers d’une nouvelle phase spécifique (maintenance).

Un logiciel est souvent modulaire.

Un logiciel peut être lui-même découpé en plusieurs modules que l’on peut choisir d’installer ou non, ou bien il peut offrir la possibilité d’être étendu par des plugins ou add-ons (comme la plupart des navigateurs web par exemple).
La notion de modularité d’un logiciel ne pourra pas être modélisée comme telle au travers d’une ACV, car il sera difficile voire impossible d’identifier les ressources spécifiques nécessaires au développement de tels ou tels module. Il faudra donc considérer la configuration la plus standard possible, puis des analyses de sensibilité pourront être faites pour évaluer les impacts liés à des ressources nécessaires pour le développement de modules particuliers (RH, matériels…).

Pour poursuivre cette série sur l’ACV des logiciels, nous traiterons dans le prochain article du blog du cycle de vie. En effet, ci celui-ci est pertinent pour un produit matériel usuel, il l’est beaucoup moins pour un logiciel et nous découvrirons pourquoi.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Thierry Leboucq

L’écoconception, qui consiste à tenir compte des impacts environnementaux et sanitaires lors de la conception ou l’amélioration d’un produit (bien ou service), s’impose progressivement dans tous les secteurs économiques comme une démarche créatrice de valeur. Ceci parce que les entreprises sont de plus en plus sensibles à la responsabilité qu’elles ont vis-à-vis de notre planète et des générations futures, mais surtout parce qu’elles prennent conscience des multiples bénéfices qu’elles peuvent tirer de la mise en œuvre d’une telle démarche.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Pourquoi réaliser une analyse du cycle de vie des logiciels ?

Il est cependant un domaine où l’écoconception n’en est qu’à ses balbutiements : il s’agit du monde du logiciel, dans lequel la plupart des méthodes et bonnes pratiques en la matière sont encore à inventer. Pourtant, comme dans tous les autres secteurs économiques, les avantages que peuvent en retirer les différents acteurs du monde du logiciel sont nombreux :

Réduction des coûts

En veillant à réduire les ressources ou matières premières nécessaires à la fabrication d’un produit, l’écoconception permet du même coup de réduire les coûts de fabrication. Cela est bien entendu aussi valable pour un logiciel : dans la phase de production d’un logiciel, réduire les fonctionnalités à développer, le nombre de postes de travail à déployer, le nombre d’impressions qui seront générées, la quantité d’énergie nécessaire à son fonctionnement, sont autant de moyens de réduire les pollutions engendrées par cette activité mais également de réduire les coûts de fabrication du logiciel.

Anticipation des réglementations environnementales

De plus en plus de normes sont imposées aux entreprises pour rendre les produits et l’économie en général plus vertueux au plan environnemental. On pense par exemple aux directives qui visent les Equipements Electriques et Électroniques (EEE) RoHS et WEEE, REACH ou ErP visant à rendre les produits moins polluants. Mais également aux tentatives actuelles ou à venir des pouvoirs publics d’intégrer à notre économie les coûts de la dégradation de l’environnement qui ne sont pas aujourd’hui assumés par les entreprises (externalités négatives) : droits d’émission de CO2, taxe carbone etc. Face à l’arrivée de ces nouvelles réglementations, nul ne doute que les entreprises ayant déjà mûri la problématique de l’écoconception en tireront un avantage concurrentiel.

Différenciation du produit :

Éco-concevoir, c’est aussi créer un produit de meilleure qualité, plus robuste, plus durable et plus économe pour l’utilisateur, puisque ces qualités sont intimement liées à la réduction de l’impact du produit sur l’environnement et/ou à l’allongement de sa durée de vie active. L’utilisateur y trouve alors son compte. La consommation d’énergie est par exemple un souci bien réel pour le responsable d’un datacenter, qui verra ainsi un logiciel moins consommateur d’électricité avec un œil plus favorable, surtout à l’ère où les « opérateurs Cloud » fleurissent et ont intérêt à optimiser l’utilisation de leurs ressources. De même, l’autonomie des plates-formes mobiles est un enjeu essentiel pour les fabricants et utilisateurs de smartphones et tablettes, et les consommations de batterie engendrée par le logiciel est à prendre en compte.

Facteur d’innovation :

Le ministère de l’écologie, du développement durable et de l’environnement affirme sur son site web : « L’écoconception est un aiguillon pour l’innovation, aussi bien en ce qui concerne la fonction du produit que les différentes étapes de son cycle de vie. Un regard nouveau pour optimiser les consommations (matière et énergie) et pour réduire les pollutions débouche parfois sur des idées entièrement nouvelles sur les composants du produit, son fonctionnement ou les technologies auxquelles il fait appel. ». Ce constat est valable aussi bien pour les logiciels que pour tout autre type de produit.

Image de l’entreprise :

A une époque où les consommateurs sont de plus en plus attentifs à la responsabilité sociale et environnementale des entreprises, s’engager activement à appliquer les principes d’écoconception des logiciels bénéficie sans aucun doute à l’image et au prestige de l’entreprise, avec des avantages en termes de retombées économiques.

C’est forts de ces constats qu’un groupe d’experts en « Green IT » a fondé le Green Code Lab dont le but est de promouvoir l’écoconception des logiciels et de proposer des outils et méthodes pour aider à sa mise en œuvre. Dans le cadre de la collaboration d’Orange avec GREENSPECTOR, lauréat d’un appel à projet ADEME sur l’écoconception des logiciels, les 2 organisations ont apporté leurs expertises respectives pour poursuivre les travaux, objet du [Guide Méthodologique de l’ACV des logiciels](lien vers le guide). La méthodologie que nous proposons ici pour réaliser une Analyse de Cycle de Vie (ACV) de logiciel s’inscrit pleinement dans un objectif de définition d’une méthodologie à diffuser largement pour initier de futures démarches d’évaluation des impacts de logiciels.
L’ACV est en effet un outil central et incontournable de l’écoconception des logiciels. Il s’agit d’une méthodologie standardisée ([ISO14040]( https://www.iso.org/fr/standard/37456.html) et ISO14044 notamment) qui permet d’évaluer les impacts environnementaux de biens manufacturés, services et procédés, ceci de façon globale et complète. Etudier les pollutions générées à toutes les étapes du cycle de vie d’un produit (conception, fabrication, utilisation, fin de vie), permet de n’en oublier aucune et de mettre en évidence la phase du cycle de vie la plus polluante (là où il faudrait porter l’effort prioritaire). Cet effort sera fonction des décisions de l’entreprise et de ses choix & contraintes stratégiques. Cette vision de toutes les phases permet de s’assurer aussi qu’une solution réduisant l’impact sur l’environnement à une étape ne va pas en générer un plus important à une autre étape du cycle de vie (pour éviter des transferts d’impact et/ou de pollution).
L’objet du [Guide Méthodologique de l’ACV des logiciels](lien vers le guide) est donc de proposer une méthodologie pour réaliser l’ACV d’un logiciel. Définir une méthodologie commune à cette catégorie de produits se justifie par le fait que les logiciels, souvent considérés à tort comme immatériels, présentent des spécificités par rapport aux produits dits « matériels ». Cette immatérialité soulève des questions quant à la meilleure façon de réaliser une telle analyse sur un logiciel.
Notons que l’aspect social, qui est l’un des 3 piliers du développement durable et auquel Green Code Lab prête également une attention particulière, n’est pas traité directement dans ce document (autrement qu’en termes d’impacts sanitaires indirects). Néanmoins, des méthodologies d’ACV sociales existent et dans une large mesure, ce qui est dit ici est tout à fait applicable et transposable à une analyse des impacts sociaux et sociétaux.

Quels objectifs pour une ACV des logiciels ?

Comme nous le verrons plus en détails dans le Guide Méthodologique de l’ACV des logiciels , la première étape d’une ACV des logiciels est la définition des objectifs et du champ de l’étude. C’est une étape essentielle car elle va déterminer de nombreux choix dans la façon de réaliser les étapes suivantes de l’étude, mais également le résultat même de l’étude. C’est pourquoi les ACVs sont dites « goal dependent ». Pour un logiciel, on peut identifier plusieurs objectifs:

• Etudier les impacts environnementaux d’un logiciel donné (déjà réalisé) : consommation de ressources non renouvelables, d’énergie et émissions de polluants (chimiques ou particules) dans l’eau, l’air et les sols.
• Déterminer les phases les plus impactantes de son cycle de vie fabrication/développement, utilisation, transport, fin de vie. Ce type d’étude pourra se restreindre à des catégories de logiciels (logiciels de messagerie, traitements de texte, CMS, page web…)
• Identifier les opportunités d’amélioration et de réduction des impacts sur l’environnement pour de futurs produits. Cet objectif intéressera particulièrement les éditeurs et autres créateurs de logiciels soucieux d’améliorer la qualité environnementale de leurs produits.
• Comparer les impacts environnementaux de plusieurs produits ou solutions logiciels afin de choisir celui ayant le moindre impact environnemental. Les utilisateurs (DSI, particuliers etc.) ou les développeurs / intégrateurs confrontés à des choix technologiques pourront ainsi utiliser cet outil. Dans le cadre d’une ACV comparée (évolution d’un logiciel ou nouveau produit), seules seront calculées les phases qui diffèrent entre les deux produits / services à comparer. La comparaison entre deux ACV est toujours risquée. Pour être crédible celle-ci devra se faire avec le même logiciel, à la même date, avec les mêmes règles de cut-off et de préférence avec le même praticien.

Comme toute ACV de produit et de service, pour être publiée, l’ACV d’un logiciel doit faire l’objet d’une revue critique indépendante. Découvrez quelles sont les spécificités et caractéristiques des produits logiciels dans un prochain article sur le blog.

Retrouvez l’intégralité du Guide Méthodologique de l’ACV des logiciels ainsi qu’une étude de cas réel sur l’évaluation des impacts environnementaux d’une application.

Thierry Leboucq

Le numérique explose ! Nous consommons de plus en plus de services et d’informations via des formats numériques à tout moment dans tous lieux. Ces services et contenus sont de plus en plus nombreux et volumineux. La consommation de ressources qui résulte de cette omniprésence explose non seulement dans les datacenters, mais aussi de manière plus insidieuse et encore plus conséquente dans tous nos matériels déployés comme les ordinateurs, tablettes, smartphones, box, objets connectés … L’université de Dresde a ainsi estimé qu’en 2030, l’internet au sens large consommerait autant d’électricité que toute l’humanité en 2008 !

L’évolution la plus emblématique du numérique est à la fois la masse de données que nous produisons et conservons à chaque instant, mais également la miniaturisation des matériels permettant l’accès aux informations et services correspondants. Pour cela, nous avons continuellement besoin d’embarquer de plus en plus d’intelligence dans un matériel de plus en plus petit. Une telle évolution n’est soutenable que si nous avons recours à de nouvelles optimisations : les composants, les batteries, le refroidissement dans les datacenters,… mais aussi dorénavant le logiciel qu’on y insère ! Car l’entropie naturelle du logiciel existe bel et bien, et on parle d’ « OBÉSICIEL » !

Le phénomène d’ « obésiciel »

En effet, aujourd’hui on ne forme plus nos développeurs à faire attention à la ressource utilisée ; ni à l’école, ni en entreprise. L’objectif principal des équipes de développement est de délivrer dans un planning prédéterminé les fonctionnalités attendues (c’est déjà bien !). Pour être productif, on assemble, on intègre et on réutilise des bibliothèques existantes.

In fine, face à un logiciel trop lent, on choisit toujours d’ajouter de la puissance matérielle pour combler des lacunes d’efficience logicielle… Car rien n’est mesuré tout au long du cycle de développement, ce qui permettrait au moins de réagir suffisamment tôt pour que le coût de la correction ne soit pas rédhibitoire. Cet ajout matériel se fait au détriment des coûts, de l’autonomie, de l’écologie et finalement du bon sens.
Il est même possible d’avoir une lecture globale de ce sujet : c’est une forme de relocalisation du numérique, quand investir dans l’efficience logicielle localement permet de réduire le coût des matériels produits au bout du monde dans des conditions sociales, sanitaires et environnementales pas toujours acceptables par ailleurs.

Le projet Code Vert est né !

En tant qu’entreprise engagée dans un numérique plus vertueux, nous avions eu une intuition : en appliquant les principes de l’écoconception au process de « fabrication » d’un logiciel, il devrait être possible de réduire les consommations de ressources et d’énergie lorsque ce logiciel est utilisé. Encore fallait-il valider cette intuition, et c’est ce que nous avons fait dans le cadre du projet « Code Vert ».

Ce projet, lancé en 2012 a duré 30 mois. Il nous a permis de valider les gains liés à une meilleure utilisation des instructions de code dans un programme informatique (bonne pratiques « vertes » ou « Green Patterns »), et en même temps nous avons pu commencer à préciser les contours de la solution GREENSPECTOR destinée à accompagner le développeur dans sa mise en œuvre concrète de l’écoconception du logiciel. Depuis lors, nous avons étoffé l‘outil avec des capacités de mesure des consommations énergétiques, qui permettent à la fois de montrer les gains réels au développeur (rien de tel pour piloter des progrès que de mesurer ses résultats !), allant ainsi au-delà de l’application « théorique » d’une bonne pratique ; mais aussi de détecter des surconsommations impossibles à percevoir en analysant seulement le code source.

L’engagement des sociétés pour l’écoconception des logiciels

Quel intérêt pour une entreprise à s’engager dans cette voix de la sobriété logicielle ? Les exemples commencent aujourd’hui à se multiplier, et bientôt l’écoconception numérique aura vocation à être rangée dans les bonnes habitudes de travail de toute équipe de développement. Ainsi, Facebook aurait-il trouvé un modèle économique viable, il y a quelques années, s’il n’avait pas divisé par 2 la consommation électrique de ses serveurs, grâce à la mise en œuvre d’une stratégie d’optimisation logicielle lui évitant de construire un nouveau datacenter ?

Ou plus récemment sur son application mobile Facebook Light, destinée aux marchés émergents grâce à la réduction à la fois du volume de données échangées et de l’énergie (donc la batterie) consommée ? Plus près de nous, on commence à voir dans les appels d’offre numériques des grands groupes français des critères d’éco-responsabilité numérique, voire des référentiels de bonnes pratiques comme en entrant du marché.

Les enjeux et gains de l’écoconception des logiciels

Dans un monde où il est aujourd’hui inenvisageable (qui sait, cela changera peut-être un jour) de modérer à bon escient l’usage de nos mobiles, cette démarche répond finalement à une demande pressante du consommateur final que nous sommes tous : l’autonomie de nos matériels mobiles, embarqués, connectés que nous emmenons partout ! L’autonomie est en effet un des tout premiers critères de choix du smartphone. Les derniers arguments des constructeurs début 2017 mettent l’accent sur l’autonomie « la meilleure du marché » de leur dernier mobile. Ici, pas question de gagner de l’argent pour l’usager mais de gagner en mobilité, en productivité, en utilisabilité, bref en expérience utilisateur. L’optimisation du logiciel devient alors un rouage essentiel dans cette quête d’autonomie pour les constructeurs qui souhaitent prendre des parts de marché.

D’autres gains sont encore plus intéressants dans le domaine des objets connectés. L’écoconception des logiciels permet ici de réduire la fréquence de maintenance, d’augmenter la longévité d’un matériel déployé (parfois gourmand en ressources rares) avec un niveau de service supérieur. Le premier service qu’on peut rendre dans ce domaine de l’IoT est de connaître le profil de consommation électrique de l’objet, sur la base de l’usage réel (et non des données constructeur, quand il y en a…) pour l’intégrer de manière concrète dans le modèle économique de la solution. Cela passe obligatoirement par la mesure des ressources (énergie, data, mémoire, …) en fonctionnement réel. Au final, quelle que soit la motivation, on visera un service au moins aussi performant pour son utilisateur, pour un coût d’exploitation moindre, tout en limitant le stress lié aux besoins en énergie et en ressources – trop peu souvent renouvelables.

Ceux qui n’ont pas de gains visibles ou conséquents en regard des coûts potentiels de mise en œuvre pour appliquer cette écoconception numérique, peuvent désormais aussi se conformer à un référentiel de bonnes pratiques Green dans le web pour le moment pour communiquer sur une exemplarité et encourager leur « écosystème ». Nantes Métropole a été la première collectivité à labelliser son site internet dédié à la transition énergétique, afin de communiquer publiquement sur son intérêt pour cette démarche d’écoresponsabilité très concrète des sites web.

Les bonnes pratiques en matière d’écoconception des logiciels !

Comment avons-nous réussi à établir les bases d’une bonne pratique d’efficience de conception et de développement ? Dans le cadre du projet Web Energy Archive, l’association Green Code Lab a mesuré la consommation énergétique de plus de 700 sites web. Elle a pu observer qu’il y avait une corrélation entre la consommation de ressources et la complexité du site (scripts, nombre de requêtes incluses dans la page…). Elle a aussi effectué d’autres observations , qui ont notamment permis de montrer que la consommation moyenne d’une page dans un onglet minimisé, c’est à dire non affiché à l’écran et pas en interaction avec lui, représente 1 Watt de puissance appelée en moyenne sur un poste de travail qui pourtant n’affiche pas cette page (ce qui n’inclut même pas la consommation des requêtes envoyées aux serveurs et alimentant le trafic dans le réseau !). Éviter une telle consommation inutile peut pourtant se faire facilement, en demandant au développeur de prévoir un arrêt des traitements quand l’onglet du navigateur n’est pas visualisé par l’utilisateur.

En 2017, plus de 50 % des accès aux services et informations du Web se font sur appareil mobile, sous contrainte de réseau, de batterie du smartphones, de forfait data parfois limité… De quoi renforcer l’intérêt pour un éditeur de contenus web de faire attention à ses pages sous peine de perdre en route des « consommateurs » en quête d’instantanéité.
Les entreprises commencent ainsi timidement à intégrer cette démarche dans leur usine logicielle avec des gains intéressants qu’elles avaient oubliés ces dernières années. Dans la « digital factory » ou la « mobile factory », l’enjeu est de ne pas manquer la transformation numérique de l’organisation, en fournissant une expérience utilisateur sans faille, (traduire la performance et productivité en mobilité) clé dans la réussite du projet.

Conclusion

Mais rêvons un peu. Ne serait-il pas possible de pousser la logique plus loin, en essayant de « sauver la planète » du danger que le numérique dispendieux non contrôlé lui fait courir ? De quoi redonner du sens au travail du développeur, qui peut ainsi trouver enfin un moyen d’agir et d’œuvrer concrètement à son niveau pour limiter l’impact écologique de sa production, via son travail au quotidien. Un moyen de revaloriser le travail du « pisseur de code » déresponsabilisé et démoralisé ?

Certes, il est vrai que revoir tout le patrimoine applicatif d’une organisation pour réaliser une rétro-écoconception n’a pas toujours de sens économique à court terme. Mais l’histoire numérique ne fait que commencer, et les chapitres que nous allons désormais écrire seront bien plus nombreux que les chapitres déjà écrits. Parions que les entreprises n’auront pas d’autre choix que d’intégrer, pour être « compétitives » dans un monde aux ressources limitées, cette nouvelle dimension de frugalité chez les donneurs d’ordre et chez les maîtres d’œuvre numériques. Comme le propose Pierre Rabhi plus largement dans son ouvrage, on se dirigera alors vers une sobriété « heureuse » aussi pour le numérique !

Thierry Leboucq