Catégorie : Numérique responsable

TL;DR

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

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

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

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

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

---

1. Amélioration des datacenters

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

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

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

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

On peut voir aussi cela sur le cas des US : 

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

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

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

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

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

---

2. Amélioration des réseaux

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

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

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

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

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

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

---

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

---

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

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

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

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

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

---

3. Amélioration des terminaux

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

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

---

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

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

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

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

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

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

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

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

---

5. Technologie logicielle

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

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

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

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

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

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

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

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

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

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

---

Effet rebond

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

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

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

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

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

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

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

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

Les sites e-commerce sont des sites à fort trafic (11 millions par mois) et ont donc un impact renforcé par la volumétrie d’usage et temps d’usage important (visite > 5 minutes). Par ailleurs, tiré par une croissance forte de l’e-commerce, des temps de parcours qui s’allongent et de plus en plus en mobilité, des infrastructures surdimensionnées pour assurer un bon niveau de temps de réponse, le site de e-commerce fait un candidat idéal pour une évaluation Carbone d’un service numérique avec la responsabilité environnementale associée à des services de masse.

Méthodologie

Le périmètre d’évaluation est basé sur l’impact des 100 sites les plus visités en France sur le second semestre 2019. Il n’est donc pas exhaustif puisque les calculs ne prennent en compte tous les sites e-commerce avec un trafic plus faible.

Comment évaluer l’Impact Carbone d’un site e-commerce ?

Pour connaître l’impact Carbone d’un service Web de e-commerce, nous avons travaillé sur une méthode simplifiée basée sur des mesures réelles.

Côté Datacenter et Réseau, nous projetons l’Impact Carbone à partir de la consommation de données échangées avec le device (Méthode OneByte du ShiftProject).

Sur le device Utilisateur, une mesure réelle sur un smartphone Android de moyenne gamme équipé d’un navigateur Chrome est lancée 3 fois et moyennée avant d’être projetée avec un facteur d’impact Carbone tenant compte des hypothèses suivantes : Mix wifi – réseau GPS, luminosité 50 %, usure de batterie du téléphone à 500 cycles complets de charge/décharge.

Impact moyen d’un parcours (=1 visite)

La visite, en moyenne de 5 mn et 28 sec sur un site web e-commerce en France via un smartphone a un impact carbone de 2 grammes EqCO2 équivalent à 18 mètres parcourus d’un véhicule léger. Ou 56 visites sur un site moyen de e-commerce ont un impact 1 km parcouru avec un véhicule léger moyen.

La répartition des sites est assez homogène entre 0,5 et 3 grammes avec quelques valeurs extrêmes. Néanmoins, il existe De gros écarts : de 0,5 g à 34 g EqCO2,-> soit un rapport de X68 entre les 100 sites du Top E-Commerce en France. On peut nuancer ces écarts en prenant en compte que le temps de visite varie d’un facteur 5 (de 3 à 15 minutes).

Quand on projete les impacts sur les visites d’un mois, un site web e-commerce a en moyenne  un impact Carbone de 23,8 Tonnes EqCO2 / mois.

La somme des impacts du top 100 des sites e-commerce, c’est 2380 Tonnes EqCO2 / mois, soit l’équivalent de l’impact de 21 millions de Kms d’une voiture moyenne en France ou 531 tours de la Terre en voiture ou encore 19 636 véhicules moyen circulant en France correspondant au parc d’une agglomération de 40 000 habitants.

Projeté sur une année, c’est 28,6 MégaTonnes EqCO2 !

Impact moyen d’une page

De manière à comparer les sites e-commerce entre eux, le temps de visite ou le nombre d’étapes ou de pages vues durant la visite doivent être isolés. Pour cela, nous revenons à la mesure élémentaire d’une page durant 1 minute.

Une page d’un site web e-commerce en France a un impact moyen de 0,36 g eqCO2.

En projection simple : 1000 pages vues pendant 1 minute sur un smartphone moyen ont un impact carbone moyen équivalent à 3,2 km d’un véhicule léger. Le classement détaillé du Top 100 des sites web e-commerce est disponible ici. Il sera susceptible de varier lors de prochaines mises à jour ou demande de re-mesure.

Répartition des sites visités

De gros écart : de 0,5 g à 34 g EqCO2, soit un rapport de X 68 entre les 100 sites du top e-commerce en France.

Pour expliquer cette variation importante d’impact, on peut noter que :

• La consommation de données varie de 0,6 Mo à 55 Mo, soit un rapport de X 92, c’est le facteur le plus discriminant expliquant les écarts d’impact.
• la consommation d’énergie sur le device mobile varie d’un facteur X 4,7

C’est la partie réseau qui est la plus impactante avec une part de 69 % de l’impact moyen d’un site e-commerce sur mobile.

Si on remplaçait le mobile par un PC en connexion filaire, la partie « poste Utilisateur serait beaucoup plus importante. Cette répartition d’impact varie bien sûr avec le site e-commerce.

Cas d’un site peu impactant

Respect des bonnes pratiques sur le réseau et faible consommation sur le device

Ecoscore Greenspector : 81/100 , meilleur Ecoscore du Top 100 E-Commerce

Équivalent de 161 675 km d’un véhicule léger pour 24, 5 millions de visites / mois (Source : Similarweb S2 2019)

Cas d’un site impactant

Pas de respect des bonnes pratiques sur le réseau et forte consommation sur le device

Ecoscore Greenspector : 21/100, le plus faible Ecoscore du Top 100 E-Commerce

Equivalent de 44 582 km d’un véhicule léger pour 2, 1 millions de visites / mois.

Des catégories de sites plus impactantes que d’autres ?

Un rapport de 1 pour 3 sur les impacts par page entre catégories

On a en environ 3 fois plus d’impacts Carbone en navigant sur un site e-commerce de mode que sur un site Automobile ou de Loisirs.

Rq : un seul site classé dans la catégorie Bons Plans

Projection de gains :

Si tous les sites étaient alignés sur le site le plus vertueux dans nos mesures, nous pourrions économiser sur une année complète :

• 15177 tonnes d’EqCO2, soit plus de la moitié des impacts
• Soit 53 %  de  réduction d’impact Carbone
• L’équivalent de 4050 tours de la terre en voiture

Les grands leviers d’amélioration :

Des sites e-commerce peuvent réduire la volumétrie sur le réseau

• Adapter le contenu au device / type de connexion & qualité de connexion
• Compression des contenus riches
• Cache utilisateur pour éviter des contenus déjà chargés lors d’une visite précédente
• Limiter le nombre de requêtes (internes, publicité, services externes, …)
• Attention aux pré-chargements non-adaptés

Des sites e-commerce qui peuvent réduire leur consommation d’énergie et de batterie

• Permettre une interaction rapide
• Réduction de la consommation de scripts dans les pages (animation 3D, animation graphique, …)
• Réduction des trackers /monitoring
• Services externes à évaluer/optimiser
• Réduction du temps de parcours
• Un design / graphisme / couleur à optimiser

Analyse de corrélation des données Carbone

Analyse de corrélation entre impact Carbone et performance d’affichage

En prenant 20 valeurs de notre échantillon pour lesquels nous avons collecté la donnée de performance, nous pouvons valider qu’il n’y a pas de corrélation entre impacts Carbone et Performance d’affichage.

Les 2 sites les plus performants sont néanmoins aussi les sites les  moins impactants

L’indicateur Carbone est un indicateur à part entière  de pilotage d’un site web e-commerce

Analyse de corrélation entre Impact Carbone et EcoScore Greenspector

L‘indicateur Carbone estimé ne tient pas compte d’autres paramètres, comme la consommation de mémoire, CPU, Nombre de requêtes, ni du respect des bonnes pratiques, …
L’Ecoscore intègre à la fois la consommation de ressources/énergie mais aussi une note sur le respect des bonnes pratiques.

Il existe une corrélation « satisfaisante » entre l’impact Carbone estimé et l’Ecoscore Greenspector mesuré.

Attention, l’indicateur Carbone ne couvre pas tous les indicateurs environnementaux.

Thierry Leboucq

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