Catégorie : Numérique responsable

Optimiser l’énergie des smartphones pour réduire l’impact du numérique et éviter l’épuisement des ressources naturelles

Reading Time: 6 minutes

Introduction

La durée de vie d’un smartphone est en moyenne de 33 mois à l’échelle mondiale. Sachant qu’un smartphone contient plus de 60 matériaux, dont des terres rares et que son empreinte carbone est située entre 27 et 38 kg eqCO2, le rythme actuel de remplacement des smartphones est trop rapide.

Différentes raisons peuvent expliquer ce rythme de renouvellement. La perte d’autonomie et les problèmes batterie en sont les raisons principales (smartphone : un changement sur trois à cause de la batterie). Augmenter la capacité des batteries est une solution qui semble intéressante mais qui ne résoudrait pas le problème. En effet, les données échangées continuent à augmenter et cela a un impact sur la puissance des smartphones. Les sites web sont toujours aussi lourds, voir de plus en plus lourds… Alors est-ce un problème irrésolvable ? Quel est le lien entre l’autonomie concrète que nous vivons à titre personnel et ce constat sur l’impact du numérique ?  

Méthodologie

Nous sommes partis d’une analyse via le biais de la consommation web. En effet, les mobinautes passent en moyenne 4,2h par jour à naviguer sur le web.

Lors d’une précédente étude sur l’impact des navigateurs web Android, nous avons mesuré la consommation de 7 sites web différents sur plusieurs applications de navigation web et ce depuis un smartphone milieu de gamme, un Samsung Galaxy S7. Cela nous permet de projeter cette consommation sur une consommation mondiale et d’appliquer des hypothèses d’optimisation pour identifier les marges de manœuvre. 

Même si les incertitudes sont élevées (diversité de mobile, diversité d’usage…), cette action nous permet d’identifier les marges de manœuvre pour améliorer le cycle de vie des smartphones. Le choix du Galaxy S7 permet d’avoir un smartphone proche (à 1 an près) de l’âge moyen des smartphones mondiaux (18 mois).

Quelle est la consommation annuelle de la navigation web sur mobile ? 

Voici nos hypothèses de départ : 

La consommation annuelle des smartphones estimée est de 2 774 milliards d’ampères-heures. Pas très concret ? Si l’on considère qu’une batterie moyenne de 3000 mAh peut effectuer 500 cycles de charges/décharges complets avant de commencer à être inutilisable et que1 850 millions de batterie sont utilisées chaque année pour naviguer sur le web. Ce chiffre vous parait exagéré ? Il y a 5,66 milliards de smartphones dans le monde, cela correspondrait à un problème qui toucherait 36% du parc mondial chaque année. Si l’on considère que 39% des utilisateurs vont changer leur smartphone pour des raisons de batterie et qu’uniquement 26% des utilisateurs vont remplacer les batteries en cas d’usure, on obtient le chiffre de 1 200 millions de batteries, ce qui corrobore nos chiffres. Pas incohérent au final, quand on observe les cycles de renouvellement des téléphones et de batterie. 

Est-ce que réduire la consommation des navigateurs aurait un impact ? 

Les navigateurs web sont des moteurs importants dans la consommation du web. Nos mesures montrent des différences importantes de consommation d’énergie entre les navigateurs. Ces différences s’expliquent par des implémentations et des performances hétérogènes. Dans le graphique suivant, la consommation de la navigation sur 7 sites, incluant le lancement du navigateur, l’usage de fonctionnalité comme l’écriture d’URL et la navigation elle-même est visualisée.

Nous partons sur une hypothèse des éditeurs optimisant les navigateurs. En considérant une consommation hypothétique de tous les navigateurs égale à celle du plus sobre (Firefox Focus), on obtient une réduction de la consommation totale annuelle qui permet, avec les mêmes hypothèses sur la durée de vie, d’économiser 400 millions de batteries par an. Sachant qu’il se vend 1 500 millions de smartphones par an, en prenant les mêmes hypothèses que précédemment sur les taux de remplacement et de réparation, cela ferait une économie de 7% du parc de téléphone vendu chaque année.  

Est-ce que réduire la consommation des sites aurait un impact ? 

Il est également possible que les sites web soient beaucoup plus sobres. Nous avons pris l’hypothèse d’une consommation proche de celle de Wikipédia. De notre point de vue, pour avoir audité et mesuré de nombreux sites, c’est possible mais en engageant des actions importantes : optimisation des fonctionnalités, réduction des publicités et du tracking, optimisation technique…    

Voici pour exemple la représentation de la consommation d’énergie du site l’Equipe. On voit que le chargement va consommer jusqu’à 3 fois la consommation de référence. La marge d’optimisation est énorme dans ce cas précis sachant que de nombreux sites arrivent à un facteur inférieur à x2. 

Dans le cas d’une sobriété des sites web, en prenant les mêmes hypothèses et méthodes de calcul que pour la sobriété des navigateurs, on pourrait économiser 294 millions de batteries par an, soit réduire le renouvellement du parc annuellement de 5%

Est-ce que réduire la consommation de l’OS est possible et aurait un impact ? 

La question sur l’impact du matériel et de l’OS se pose souvent. Pour prendre en compte cet impact nous avons plusieurs données à notre disposition. Une donnée importante est la consommation de référence du smartphone. C’est la consommation du matériel et de l’OS. Pour le Galaxy S7, cette consommation est de 50µAh/s.  

En prenant les mêmes hypothèses que celles prises pour calculer la consommation totale (2 774 Milliard Ah), la consommation annuelle attribuée à la part matérielle et OS serait de 1 268 milliards d’ampère-heure soit 45% de la consommation totale.  

Est-ce donc le plateau de verre de l’optimisation ? Non pas vraiment car il existe beaucoup de pistes d’optimisation envisageables : Android lui-même par exemple. Nous avons réalisé une expérimentation qui montre qu’il est possible de réduire de façon importante la consommation des fonctionnalités Android. Les surcouches des constructeurs sont aussi une piste de réduction de la consommation. 

Selon notre expérience, nous estimons qu’une réduction de 5% de la consommation est totalement possible. Ceci permettrait d’économiser 350 millions de batteries soit 6% du parc

Quels gains environnementaux espérer ? 

L’application de la sobriété numérique à différents niveaux permettrait de réduire de plus de la moitié le nombre mondial de batteries usées par an

Même dans l’hypothèse où les utilisateurs ne renouvellent pas systématiquement leurs smartphones pour des raisons de perte d’autonomie ou remplacent uniquement leur batterie usée, on pourrait réduire de 17% le renouvellement annuel de smartphone

Dans le meilleur des cas, si l’on projette que la plupart des utilisateurs remplaceront leur batterie, les gains potentiels seraient de 2 millions de T eqCO2. Mais les gains pourraient être beaucoup plus importants si l’on considère que les pratiques de remplacement ne changent pas assez vite et que les utilisateurs changent les smartphones plutôt que les batteries : 47 millions de TeqCO2

En étant optimiste sur une augmentation des capacités des batteries, une non-augmentation de l’impact des logiciels, et un impact non augmenté des plus grosses batteries, le nombre de batteries utilisées pourrait être divisé par deux, de la même manière l’impact environnemental par deux. Mais est-ce encore suffisant ? Plutôt aller sur une augmentation de la capacité des batteries et une diminution de la consommation d’énergie et alors obtenir un gain de 4 sur l’impact en multipliant la capacité par deux ! 

L’énergie sur smartphone, des petites gouttes mais un impact au final énorme 

Nous avons l’impression que l’énergie est illimitée, il suffit juste de recharger notre smartphone. Néanmoins, même si l’énergie était illimitée et sans impact, les batteries elles, sont des consommables. Plus nous les utilisons, plus nous les usons et plus nous utilisons des ressources non-renouvelables comme des terres rares, sans compter les autres coûts environnementaux, sociaux et géopolitiques. Nous pouvons attendre des évolutions technologiques pour améliorer les capacités et améliorer la remplaçabilité des batteries, cependant les puits d’économies sont gigantesques. Le remplacement des batteries n’est en effet pas la solution miracle car même si on prolonge la durée de vie du smartphone, la batterie est à jeter ou à recycler, et le recyclage du Lithium n’est pas encore assuré (P.57). Gigantesque car nous utilisons nos smartphones de nombreuses heures. Gigantesques car nous sommes des milliards d’utilisateurs.  

L’exercice que nous avons réalisé est totalement prospectif, il faudrait que tous les éditeurs de navigateurs intègrent la sobriété, que tous les sites soient éco-conçus. Cela montre cependant que l’optimisation de l’énergie des applications et des sites web a un sens dans l’empreinte environnementale du numérique. Certains voyant uniquement l’énergie du rechargement négligent cet aspect. Cependant on le voit dans cette projection, les gains environnementaux sont beaucoup plus importants. 

Ce chiffre est important et en même temps faible : 47 Millions de Teq CO2 pour le monde, c’est 6% de l’empreinte française. Cependant, le CO2 n’est pas l’unique métrique à regarder. Autre problématique par exemple non négligeable : la pénurie de Lithium en 2025 mais aussi l’eau.

A tout cela, il faudrait ajouter des problématiques associées aux nouvelles pratiques et nouveaux matériaux : 

… la filière évolue sans cesse, pour répondre à des enjeux tantôt commerciaux, tantôt économiques, tantôt réglementaires. L’exemple de la batterie illustre bien cette tendance. Alors que l’on s’était familiarisé avec les batteries lithium-ion « classiques » qui contiennent principalement du lithium, du carbone, du fluor, du phosphore, du cobalt, du manganèse et de l’aluminium, de nouveaux modèles sont apparus, d’abord les batteries lithium-ion-polymère puis les batteries lithium-métal-polymère. Le cortège métallique possible, déjà conséquent, a donc été considérablement augmenté ; avec le fer, le vanadium, le manganèse, le nickel mais aussi des terres rares (cérium, lanthane, néodyme et praséodyme).

Association SystExt (Systèmes extractifs et Environnements)  https://www.systext.org/node/968 

En prenant en compte les problématiques environnementales, sociales et géopolitiques qu’impliquent les batteries, la division par 2 du nombre de batteries utilisées n’est vraiment pas suffisante ! Cela veut dire que les puits d’optimisations doivent maintenant être activés. Et si l’on veut atteindre des objectifs ambitieux, tous les acteurs, constructeurs, éditeurs d’OS et de navigateurs, acteurs du numérique… ont leur part de travail. Continuer à incanter des réductions magiques issues des technologies, à dire que l’énergie ne doit pas être optimisée, à reporter la faute à d’autres acteurs ou d’autres secteurs, expliquer que se focaliser sur les usages est une erreur… ne fait que décaler le problème. Il est nécessaire de tous se retrousser les manches et de résoudre le problème dès maintenant ! 

 

Quelles ressources réduire dans le cadre de bonnes pratiques d’éco-conception logicielle : Traitements côté serveurs ou côté utilisateurs ?

Reading Time: 3 minutes

Une des premières réponses à la question “quelles ressources” est : toutes ! Mais il est nécessaire d’avoir une réponse plus précise car certaines pratiques vont privilégier une économie côté serveurs, d’autres côté mémoire plutôt que CPU. Il y a des optimisations gagnantes pour tous les domaines mais malheureusement, le comportement des systèmes informatiques est plus capricieux !  

La piste directrice est la prolongation de la durée de vie du matériel, que ce soit pour le terminal ou pour les serveurs. On verra que pour des gains environnementaux, la diminution de l’énergie sera elle aussi une piste. 

Dans un précédent article, nous traitions de la nécessité d’optimiser l’énergie dans le cas des appareils mobiles. Aujourd’hui nous tentons de répondre à la question : quelle architecture mettre en place, et en particulier mettre les traitements côté utilisateurs ou côté serveurs ? 

La réponse est : traitement côté serveur à privilégier…

La réponse est plutôt simple : chargeons les serveurs ! En effet, lorsqu’on prend les ACV et les analyses d’impact, on observe un impact beaucoup plus fort côté utilisateurs (Exemple avec notre étude sur l’impact de la lecture d’une vidéo). Les serveurs sont mutualisés et sont optimisés pour absorber une charge. Le gestionnaire pourra de plus gérer des fluctuations de charge avec du Power Capping (absorption de pic de charge en maintenant une consommation d’énergie maîtrisée). La durée de vie des serveurs pourra elle aussi être gérée (du matériel pouvant aller jusqu’à 10 ans de durée de vie). Le respect d’une politique Green IT pourra aussi être mieux suivi et partagé.

Les terminaux quant à eux, malgré des processeurs puissants, n’ont pas ces avantages. Très peu de maîtrise de la durée de vie, pas de gestion de la santé du système, une fragmentation des puissances et donc des comportements…

…mais attention aux ressources et à la scalabilité

S’il est préférable de placer les calculs côté serveurs, cela n’est pas une excuse pour ne pas optimiser l’impact côté serveurs. La scalabilité et la montée en charge est possible mais à surveiller. Car rajouter une instance virtuelle aura un impact sur le futur besoin d’ajout de machine physique et donc viendra alourdir l’impact environnemental.

De plus, limiter la consommation d’énergie sera nécessaire car une forte demande en énergie se transférera en une augmentation de la puissance consommée sur la baie de serveurs et des besoins de refroidissement plus forts.

Et le coût des allers retours des allers-retours réseau dans ce cas ?

La question se pose sur les échanges réseaux si l’on déplace des calculs côté serveurs. Il s’agit actuellement d’un faux problème car les échanges sont trop nombreux. La ressource réseau et serveurs étant vue comme « gratuite” et les architectures allant de plus en plus vers du service / micro service, les traitements côté utilisateurs appellent trop les datacenters. Il faudra plutôt maîtriser le nombre d’échanges réseau, quel que soit le choix d’architecture.

Est-ce le cas actuellement dans les pratiques d’architecture ?

Cela n’a pas été la tendance de ces dernières années. En effet, l’arrivée de plateformes utilisateurs puissantes, i.e. avec des processeurs multicœurs et des connexions réseaux performantes, ont poussé à déplacer beaucoup de traitements côté utilisateur. Les Frameworks de développement, en particulier les Frameworks JavaScript, ont permis cela.

Cependant, la tendance commence à s’inverser. On peut notamment citer le Server-Side Rendering (SSR) avec par exemple next.js ou la génération de blogs statiques avec Hugo. On peut aussi voir les techniques maximisant l’usage des éléments déjà présents sur le terminal de l’utilisateur comme le moteur du navigateur web en utilisant plutôt du CSS que du JS.

Nous tenterons de répondre dans les prochains articles : quelles ressources (CPU, mémoire…) doit-on optimiser en priorité ?

Smartphones utilisateurs : tout savoir sur l’impact environnemental et l’usure des batteries

Reading Time: 4 minutes

Terminaux utilisateurs : l’impact environnemental élevé de la phase de fabrication

Les terminaux utilisateurs sont désormais les plus gros contributeurs à l’impact environnemental du numérique et ce phénomène est amené à se renforcer. Cette tendance s’explique principalement par un équipement de plus en plus important des foyers en smartphones, par une durée de vie réduite de ces équipements et par le fait que ces derniers ont un impact environnemental important. Impact qui est principalement dû à la phase de fabrication du smartphone. La marque Ericson annonce par exemple un impact en usage (i.e. lié à la recharge en énergie de la batterie du smartphone) de 7 kg eqCO2 sur un impact total de 57 kg eqCO2, soit seulement 12% de l’impact total. L’impact total prend en compte les différentes phases du cycle de vie du smartphone : fabrication, distribution, usage, traitement du smartphone en fin de vie.

D’où l’intéret que les constructeurs travaillent sur cette énergie grise en éco-concevant mais aussi en améliorant la possibilité d’augmenter la durée de vie du matériel via la réparabilité mais aussi la durabilité.

Au regard de tous ces constats, il pourrait paraître non-productif du point de vue environnemental de réduire la consommation d’énergie des smartphones. En tout cas, l’approche simpliste serait de mettre cet impact de côté. Mais la réalité est tout autre et les flux électriques qui sont mis en jeu dans la phase d’usage des appareils mobiles sont beaucoup plus complexes que l’on ne pourrait le croire.

Explication du fonctionnement des batteries

Les smartphones actuels sont alimentés par des batteries avec la technologie Lithium-ion. En moyenne les capacités des batteries du marché sont de 3000 mAh. La tendance est à l’augmentation de cette capacité. La batterie peut être considérée comme un consommable, tout comme une cartouche d’imprimante. Elle s’use avec le temps et la capacité initiale que vous possédiez lors de l’achat du smartphone n’est plus totalement disponible. C’est-à-dire que le 100 % indiqué par le téléphone ne correspond plus aux 3000 mAh mais à une capacité moindre. Et cette capacité initiale ne peut alors pas être récupérée.

L’usure de la batterie est principalement créée par les cycles de recharges et décharges complets. Un cycle de recharge/décharge correspond à une batterie vide que l’on rechargerait à 100 %. Je pars de chez moi le matin avec un téléphone chargé à 100 %, la batterie se vide, je recharge mon téléphone le soir à 100 %. Un cycle complet en une journée donc !

Si vous rechargez plus souvent votre téléphone, vous pourrez faire plus de cycles (plusieurs cycles incomplets sont au final équivalents à un cycle complet).

Plus le nombre de cycles croît, plus la capacité restante diminue. Cette usure amène à la fin de vie de la batterie. Les technologies actuelles permettent d’aller environ jusqu’à 500 cycles.

Arrivée en fin de cycle, la capacité de la batterie n’est plus que de 70 % de la capacité initiale. Au-delà de cette perte gênante d’autonomie, la batterie subit certaines anomalies, comme par exemple le passage rapide d’un niveau de batterie de 10 % à 0 %.

À noter que cet effet va être renforcé par l’intensité de la décharge de la batterie : si le téléphone consomme énormément (par exemple lors d’une lecture de vidéo), alors l’usure de la batterie va être plus importante.

Impact sur l’obsolescence

La perte d’autonomie est une cause de renouvellement par les utilisateurs : 39% en 2018. Phénomène renforcé par le fait que les batteries sont de plus en plus non amovibles, ce qui engendre un remplacement complet du smartphone par l’utilisateur. De plus, même si la baisse de l’autonomie n’est pas l’unique critère de remplacement, il s’additionnera aux autres causes pour créer un ensemble de signes indiquant à l’utilisateur qu’il doit changer son smartphone (effet marketing, puissance, nouvelles fonctionnalités…).

On peut donc facilement faire le lien entre les mAh consommées par les applications et le CO2 dû à la fabrication. En réduisant ces mAh, on réduirait largement l’usure de la batterie, la durée de vie des smartphone serait élargie en moyenne et donc le coût CO2 initial serait davantage rentabilisé. Le mAh du smartphone présente un coût beaucoup plus important sur l’énergie grise du smartphone (fabrication) que sur l’impact de l’énergie pour le recharger.

Par exemple pour un smartphone classique, l’impact en tenant compte  de la fabrication est de 14 mgCO2/mAh, contre seulement 0,22 mgCo2/mAh si on ne considère que l’énergie nécessaire à la recharge ! C’est ce facteur d’émissions (14 mgCO2/mAh) que nous utilisons dans nos évaluations d’impact. Nous vous encourageons à l’utiliser également.

Solution technologique

Résoudre cette problématique peut toujours se voir au travers de l’axe technologique : augmentation des capacités, chargement rapide… Si l’on prend le cas du chargement rapide, cela ne va pas changer le problème, bien au contraire, cela va l’aggraver en augmentant potentiellement les cycles. Ce n’est pas en augmentant le réservoir des voitures que l’on va réduire l’impact de l’automobile. Améliorer les technologies batterie est bénéfique, cependant une diminution de la consommation des smartphones serait encore plus bénéfique pour l’environnement et l’utilisateur.

À noter que l’impact CO2 n’est pas le seul indicateur à prendre en compte, en effet la fabrication des batterie est globalement très couteuse en termes environnemental et social. Sans compter les ressources stratégiques avec des impacts géopolitiques comme le cobalt ou le lithium. Prolonger la durée de vie des batterie est critique.

Sobriété numérique partout, sobriété numérique nulle part ? 7 erreurs à éviter !

Reading Time: 4 minutes

Tout le monde parle de sobriété numérique. Des agences web aux politiques, en passant par les ESN, tous communiquent sur le sujet, sur l’explication de l’impact, sur des bonnes pratiques, sur la volonté d’y aller. Mais qu’en est-il réellement ? 

Nous travaillons sur le sujet au sein de Greenspector depuis 10 ans et nous pouvons en toute modestie donner notre avis sur la réelle situation des acteurs et surtout sur les barrières qu’il va falloir passer pour réellement faire de l’éco-conception et de la sobriété. 

Nous avons sensibilisé des développeurs, des étudiants et des dirigeants. Nous avons accompagné des équipes, appliqué des bonnes pratiques. Nous avons mesuré des applications et sites web. Il en fallait de la motivation pour garder le cap. Car le contexte est différent, et nous sommes heureux de voir autant de communication et d’acteurs concernés. Nous pensons cependant que tout n’est pas gagné ! Voici quelques conseils et analyses d’anciens du domaine, regroupés en 7 erreurs à éviter !  

Associer la sobriété numérique uniquement à un métier

Dans de nombreuses actions que nous avons menées, une composante importante était nécessaire : la prise en compte du problème à toutes les étapes. Développeur, designer, Product Owner, décideur. Et Client.. Sans cela, le projet n’ira pas loin. Un projet non financé, des besoins de recherche d’optimisation non voulus par les devs, des améliorations techniques non acceptées par les Product Owners… Au mieux, les améliorations seront faites mais avec peu de gain. 

La solution, engager une démarche partagée. Cela prend un peu plus de temps (et encore !) mais permet au projet d’être compris par tous et accepté. 

Se focaliser uniquement sur les pratiques de codage 

La solution miracle quand on pense sobriété numérique est de se dire que si les développeurs respectent les bonnes pratiques, tout ira bien. On peut en parler, on a débuté un projet de R&D (Code Vert), il y a plus de 8 ans sur cet axe. C’était nécessaire mais pas suffisant. En effet, il faut également travailler sur les fonctionnalités, le design, les contenus, l’infra…  

La mise en place d’un référentiel sera un axe important mais plus dans un premier temps pour initier une démarche de sensibilisation. Il ne faut surtout pas se dire qu’il faudra appliquer 115 bonnes pratiques sur la quasi-totalité d’un site car l’effort sera énorme et les résultats ne seront pas forcément au rendez-vous.

Ne pas utiliser d’outils professionnels

De nombreux outils ont vu le jour pour évaluer les sites web. En effet, il est assez simple dans le web de surveiller certaines métriques techniques comme la taille des données échangées sur le réseau ou la taille du DOM et de modéliser un impact environnemental. C’est très bien pour sensibiliser et pour identifier des sites beaucoup trop lourds. Par contre le système sur lequel fonctionne le logiciel n’est pas si simple et l’impact peut venir de beaucoup plus d’éléments : Un script JS qui consomme, une animation…  

Passer à l’action avec ce type d’outil permet de lancer la démarche mais dire que le logiciel est sobre par ce qu’on a réduit la taille de données et la taille du DOM est à la limite du greenwashing. 

Nous ne disons pas cela parce que nous sommes éditeurs mais parce que nous sommes convaincus qu’il est nécessaire de professionnaliser les actions.

Se battre sur les définitions et les principes

Nous l’avons vécu ! Nous avons été critiqués pour notre approche sur l’énergie. La naissance d’un domaine amène à la mise en place de nouveaux principes, de nouveaux domaines, de nouvelles définitions… C’est normal et cela nécessite souvent de longues discussions. Mais avons-nous réellement le temps de débattre ? Sont-elles nécessaires quand on s’est mis d’accord sur le fait que nous devons tous réduire l’impact de nos activités ? La complexité du numérique et de l’obésiciel est bien là et se ressent à tous les niveaux. Il est temps d’améliorer globalement nos pratiques, toutes les volontés sont bonnes, tous les axes sont à explorer. 

Chercher les gros consommateurs 

Les constats sur l’impact du numérique sont de plus en plus partagés. Cependant les équipes peuvent être amenées à chercher des excuses ou des responsables et ne pas faire des corrections qui leur semblent plus mineures. Pourquoi optimiser sa solution alors que le bitcoin est un gouffre de consommation ? Pourquoi réduire l’impact du front alors que les éditeurs de librairies ou dépendances ne font rien ?  La priorisation est importante mais elle est souvent une mauvaise excuse pour ne pas rechercher les gains sur son domaine.  

TOUTES les solutions sont beaucoup trop lourdes. 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 multicœurs 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 : Le monde du logiciel est en train de se détruire, manifeste pour un développement plus durable.)

Débutons maintenant les optimisations en ne cherchant pas des coupables ! 

Penser uniquement évolution technologique 

Nous sommes des techniciens, nous cherchons des solutions techniques pour résoudre nos problèmes. Et donc dans le domaine du numérique, nous recherchons des nouvelles pratiques, des nouveaux frameworks. Et les nouveaux frameworks sont plein de promesses en termes de performance, nous les croyons ! Par contre c’est une course à l’armement qui nous coûte des ressources. Cette évolution est surement nécessaire dans certains cas mais il ne faut pas uniquement se focaliser sur cela. Il faut aussi investir les domaines transversaux : accessibilité, test, sobriété, qualité…  Et sur l’humain, car ce sont les équipes qui trouveront les solutions pour des services numériques sobres.   

Ne pas investir  

Les bonnes volontés et les prises de conscience sont nécessaires, par contre il faut financer le changement. Car la sobriété numérique est un changement. Nos organisations, nos outils ne sont nativement pas faits pour la sobriété. Sinon nous n’aurions actuellement pas ce constat sur l’impact du numérique. Il est donc nécessaire d’investir un minimum pour former les gens, pour s’outiller, pour prévoir du temps pour les équipes sur le domaine. Faire un webinar et une formation ne suffisent pas ! 

Ayons des engagements liés au niveau de l’enjeu et des impacts du numérique sur l’environnement ! 

Faut-il limiter les données qui transitent sur internet pour réduire l’impact du numérique ?

Reading Time: 11 minutes

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. 

Empreinte carbone de l’électricité des technologies de communication 2010 - 2030

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. 

Tendances mondiales du trafic Internet, des charges de travail des centres de données et de la consommation d'énergie des centres de données, 2010-2019

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

Consommation d'électricité par composante d'utilisation finale, 2000 à 2006

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 gains d'efficacité énergétique des datacenters se sont stabilisés

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

evolutions et previsions des consommations d'électricite des data centers orange Gwh

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 : 

Consommation d'énergie des centres de données dans le monde en milliards de kWh par an

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.

Réseau 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 : 

ARCEP Emissions GES des opérateurs francais

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.

Koomeys low graph made by Koomey

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.

JSS Processing for CNN.com

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…  

Effet rebond

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…

Et alors ?

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

Les grands chiffres de l’impact Carbone du e-commerce en France

Reading Time: 6 minutes

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.

L’impact carbone du Top 100 des sites web E-Commerce

Reading Time: < 1 minute

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

PositionSite webTotal gEqCO2
par page/ minute
Ecoscore
(/100)
Date de mesure
1https://fr.hotels.com/0.116713-03-2020
2https://www.leroymerlin.fr/0.128113-03-2020
3https://www.microsoft.com/fr-fr0.126413-03-2020
4https://www.naturabuy.fr/0.136113-03-2020
5https://www.airfrance.fr/0.137113-03-2020
6https://www.decathlon.fr/0.154813-03-2020
7https://www.veepee.fr0.157813-03-2020
8https://www.norauto.fr/0.156513-03-2020
9https://www.galerieslafayette.com/0.157213-03-2020
10https://www.rueducommerce.fr/0.157813-03-2020
11https://www.thomann.de/fr/index.html0.155813-03-2020
12https://www.zalando-prive.fr/0.164613-03-2020
13https://www.showroomprive.com/0.167113-03-2020
14https://www.groupon.fr/0.165413-03-2020
15https://www.laredoute.fr/0.167813-03-2020
16https://www.oscaro.com/0.175013-03-2020
17https://www.leclercdrive.fr/0.174813-03-2020
18https://www.cultura.com/0.187213-03-2020
19https://www.booking.com/0.184113-03-2020
20https://www.darty.com/0.195813-03-2020
21https://www.ticketmaster.fr/0.196013-03-2020
22https://www.fnac.com/0.195113-03-2020
23https://www.kiabi.com/0.196113-03-2020
24https://www.brandalley.fr/0.206513-03-2020
25https://www.voyage-prive.com0.206413-03-2020
26https://www.gemo.fr/0.205313-03-2020
27https://www.trainline.fr/0.205913-03-2020
28https://www.etsy.com/fr/0.206513-03-2020
29https://www.expedia.fr/0.216513-03-2020
30https://www.manomano.fr/0.216813-03-2020
31https://www.aliexpress.com/0.225913-03-2020
32https://www.leboncoin.fr/0.226813-03-2020
33https://www.ugc.fr/0.226113-03-2020
34https://www.fnacspectacles.com/0.226313-03-2020
35https://www.ryanair.com/fr/fr/0.236013-03-2020
36https://www.feuvert.fr/0.236513-03-2020
37https://www.but.fr/0.234713-03-2020
38https://www.sephora.fr/0.234113-03-2020
39https://fr.bazarchic.com/0.246613-03-2020
40https://www.bricodepot.fr/0.245313-03-2020
41https://all.accor.com/france/index.fr.shtml0.247113-03-2020
42https://www.intermarche.com/0.247613-03-2020
43https://www.boulanger.com/0.254513-03-2020
44https://www.apple.com/fr/0.267313-03-2020
45https://www.fr.lastminute.com/0.264713-03-2020
46https://www.intersport.fr/0.267413-03-2020
47https://fr.gearbest.com/0.264213-03-2020
48https://www.promod.fr/0.265813-03-2020
49https://www.etam.com/0.275413-03-2020
50https://www.blancheporte.fr/0.275913-03-2020
51https://www.asos.fr/0.285213-03-2020
52https://www.zalando.fr/0.284313-03-2020
53https://www.materiel.net/0.287213-03-2020
54https://www.alibaba.com/0.283713-03-2020
55https://www.bricoprive.com/0.294513-03-2020
56https://www.leclercvoyages.com/0.296313-03-2020
57https://www.bonprix.fr/0.296113-03-2020
58https://www.vertbaudet.fr/0.303613-03-2020
59https://www.cdiscount.com/0.305113-03-2020
60https://www.cinemaspathegaumont.com/0.317113-03-2020
61https://www.auchan.fr/0.316613-03-2020
62https://www.ebay.fr/0.315113-03-2020
63https://www.yves-rocher.fr0.313513-03-2020
64https://www.ldlc.com/0.315013-03-2020
65https://fr.shein.com/0.313913-03-2020
66https://www.just-eat.fr/0.325113-03-2020
67https://www.lahalle.com/0.325413-03-2020
68https://www.carrefour.fr/0.323513-03-2020
69https://www.spartoo.com/0.336513-03-2020
70https://www.zooplus.fr/0.343813-03-2020
71https://www.digitick.com/0.342713-03-2020
72https://www.maisonsdumonde.com/FR/fr0.353913-03-2020
73https://www.camaieu.fr/0.363013-03-2020
74https://www.ubaldi.com/accueil/0.364013-03-2020
75https://www2.hm.com/fr_fr/index.html0.366613-03-2020
76https://www.oui.sncf/0.374113-03-2020
77https://www.electrodepot.fr/0.373013-03-2020
78https://www.easyjet.com/fr0.384813-03-2020
79https://www.privatesportshop.fr/0.384413-03-2020
80https://www.sarenza.com/0.386813-03-2020
81https://www.vinted.fr/0.406213-03-2020
82https://www.castorama.fr/0.405713-03-2020
83https://www.instant-gaming.com/fr/0.404213-03-2020
84https://www.ouigo.com/0.426213-03-2020
85https://www.nocibe.fr/0.424113-03-2020
86https://www.amazon.fr/0.444413-03-2020
87https://www.samsung.com/fr/0.462213-03-2020
88https://www.aroma-zone.com/0.464613-03-2020
89https://www.ikea.com/fr/fr/0.473413-03-2020
90https://www.nike.com/fr/0.482713-03-2020
91https://www.conforama.fr/0.494313-03-2020
92https://www.opodo.fr/0.502813-03-2020
93https://fr.shopping.rakuten.com/0.502613-03-2020
94https://www.gifi.fr/0.573813-03-2020
95https://www.airbnb.fr/0.615613-03-2020
96https://www.adidas.fr/0.655313-03-2020
97https://www.backmarket.fr/0.704113-03-2020
98https://www.micromania.fr/0.792113-03-2020
99https://www.wish.com/1.143513-03-2020
100https://www.zara.com/fr/5.713413-03-2020

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

Le Top 10 des mythes du numérique sobre

Reading Time: 5 minutes


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

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

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

Faux.

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

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

Vrai et Faux

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

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

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

Vrai et Faux

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

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

Un logiciel de mesure sera alors complémentaire 😉

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

Faux

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

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

Vrai et Faux

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

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

Vrai et Faux

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

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

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

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

Faux

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

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

Faux

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

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

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

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

Faux

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

Mythe n°10 – Je compense donc je suis green

Faux

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

Conclusion

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

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

Reading Time: 21 minutes

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

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

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

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

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

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

On grossit (trop)

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

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

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

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

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

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

On est (trop) virtuel

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

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

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

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

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

On est (trop) abstrait

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

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

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

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

On attend (trop) la solution miracle

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

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

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

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

On y reviendra sur le « fun« …

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

@sahrizv :

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

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

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

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

On n’apprend pas (assez)

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

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

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

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

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

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

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

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

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

Nous sommes (mal) gouvernés

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

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

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

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

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

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

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

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

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

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

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

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

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

Le développement est (trop) mal piloté

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On tue notre industrie (et plus)

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

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

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

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

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

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

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