Personnellement, la consultation (sur smartphone et ordinateur portable) d'un quotidien national représente environ 3h par semaine de mon "temps d'écran". Il m'a donc semblé pertinent de veiller à réduire son impact écologique.
Au-delà de mon simple exemple personnel, la presse quotidienne nationale, tous supports confondus, représentait au premier semestre de cette année 8 millions de lecteurs (source : ACPM). Par ailleurs, parmi ces consultations, la part du numérique, oscille entre 30 et 80% selon les titres (source : ACPM).
Les services qui ont le moins d'impact sont bien-sûr ceux qui n'existent pas ou plus. Cependant, dans le cas de la presse, leur utilité sociale est assez indiscutable.
"La liberté de la presse est [...] constitutive de la démocratie". Grâce à elle, "chaque citoyen[ne] peut [...] prendre connaissance des politiques menées, les juger [...], découvrir les propositions alternatives des opposants" (source : Service du Premier ministre). Notons que cette liberté requiert le respect de la déontologie du métier de journaliste : vérification des faits, indépendance face aux groupes de pression. Dans une période où le journalisme traditionnel est concurrencé par des médias qui ne partagent pas forcément la même déontologie, l'utilité sociale du journalisme nous semble encore renforcée.
La numérisation de la presse quotidienne nationale a entraîné une substitution partielle par rapport au papier (entre 30 et 80% comme nous le disions plus haut). Malgré la création de nouveaux titres purement numériques de presse écrite, il ne semble pas qu'il y ait eu d'effet rebond puisqu'au contraire la diffusion totale de la presse en France s'est érodée de 30% en dix ans (source: Rapport du Sénat).
Le bilan en termes d'impact écologique de la substitution du papier par le numérique n'est pas facile à établir. On connaît à peu près l'impact en gaz à effets de serre de la production de l'exemplaire papier d'un quotidien régional : 200g eq. CO2 (source : La Croix), celui d'un quotidien national est sans doute un peu supérieur en raison du transport. L'impact de la consultation d'une page Web est de l'ordre du gramme. Pour un nombre d'articles consultés de l'ordre de la dizaine, on pourrait donc penser que la numérisation réduit l'impact d'un facteur 10. Ceci est grandement à relativiser car le "taux de circulation" varie entre 4 et 8 lecteurs par exemplaire papier (source : Wikipédia). Retenons que dans le cas qui nous occupe le support numérique est potentiellement plus vertueux que le support papier, mais que ce gain risque d'être annulé :
- si le service numérique encourage la consultation d'un nombre élevé d'articles,
- s'il encourage fortement le partage à d'autres lecteurs,
- si l'impact des pages est supérieur à la moyenne.
Nous serons donc particulièrement attentifs à ces trois risques dans la conception et le prototypage qui vont suivre.
Nous faisons l'hypothèse que le journal est lu plusieurs fois dans la journée lors de moments de pause de quelques dizaines de minutes (dans les transports en commun, après le repas de midi, avant de se coucher, etc.). Pour cette raison, nous prendrons en compte dans notre scénario la lecture de deux articles l'un à la suite de l'autre, afin d'apprécier l'effet bénéfique du cache.
Par ailleurs nous distinguerons la lecture des articles du jour et ceux d'une rubrique (Politique, Environnement, etc.), plus spécifiques mais possiblement plus anciens.
- Le lecteur du journal se rend sur la "une" du journal grâce à un favori (donc sans passer par un moteur de recherche). Si nécessaire, il donne son consentement. Puis il consulte les titres.
- Il choisit un des articles et le lit jusqu'au bout.
- Il revient aux titres de la "une" et les consulte.
- Il choisit un autre article et le lit jusqu'au bout.
- Le lecteur du journal se rend sur la "une" du journal grâce à un favori (donc sans passer par un moteur de recherche). Si nécessaire, il donne son consentement.
- Il choisit une des rubriques. Puis il consulte ses titres.
- Il choisit un des articles et le lit jusqu'au bout.
- Il revient aux titres de la rubrique et les consulte.
- Il choisit un autre article et le lit jusqu'au bout.
L'EcoIndex d'une page (de A à G) est calculé (sources : EcoIndex, Octo, GreenIT) en fonction du positionnement de cette page parmi les pages mondiales concernant :
- le nombre de requêtes lancées,
- le poids des téléchargements,
- le nombre d'éléments du document.
Nous avons choisi de comparer l'impact des scénarios sur les services de quotidiens nationaux de diverses sensibilités politiques, économiques et environnementales : Le Figaro, Le Monde, La Croix, Libération, L'Humanité et enfin Reporterre, à titre de comparaison, même si ce n'est pas à proprement parler un quotidien.
| Service | Score (sur 100) | Classe | Détail des mesures |
|---|---|---|---|
| Le Figaro | 33 | E 🟥 | … |
| Le Monde | 47 | D 🟧 | … |
| La Croix | 27 | E 🟥 | … |
| Libération | 35 | E 🟥 | … |
| L'Humanité | 17 | F 🟪 | … |
| Reporterre (à titre de comparaison) | 55 | D 🟧 | … |
Tab.1 : Mesure de l'EcoIndex moyen de services de quotidiens nationaux.
Les mesures de l'impact moyen de ces services (cf. Tab.1) révèlent des classes EcoIndex très faibles pour la plupart (E ou F) et médiocres pour certains (D).
Dans le détail, les pages les plus mal classées sont celles qui incluent :
- une vidéo,
- des traqueurs en très grand nombre (pour la revente de données de consultation à des tiers),
- des publicités en grand nombre.
À l'inverse, le bon classement (B) de certaines pages (rubriques, articles) de Reporterre montre qu'il existe une marge de progression significative à condition d'adopter des pratiques d'éco-conception et un modèle économique permettant de réduire (totalement ou partiellement) le recours à des services tiers de traqueurs et de publicité.
Comme nous l'avons vu dans la section précédente, parmi les choix de conception ayant le plus d'impact environnemental, la plupart sont directement liés au modèle économique du service. C'est pourquoi il est nécessaire à ce stade d'analyser leur modèle économique et de définir notre propre modèle permettant une conception plus frugale.
| Service | Visiteur anonyme | Abonné |
|---|---|---|
| Le Figaro |
|
|
| Le Monde |
|
|
| La Croix |
|
|
| Libération |
|
|
| L'Humanité |
|
|
| Reporterre (à titre de comparaison) |
|
Sans objet (mais dons possibles) |
Tab. 2 : Offre des services de quotidiens nationaux.
Les offres de service numérique des quotidiens nationaux (cf. Tab. 2 ) se sont harmonisées autour d'un modèle dit "freemium" (de free, gratuit, et premium, supplément) :
- un accès gratuit à certains articles (ou en nombre limité), financé par la publicité,
- un accès à l'ensemble des articles, sans publicité, réservé aux abonnés.
Certains acteurs se distinguent en offrant en outre aux abonnées l'accès à d'autres services (événements culturels, musiques en streaming, commentaires), numériques ou non, susceptibles d'augmenter, à des degrés divers, l'impact environnemental de l'offre.
Le seul modèle alternatif, est celui de Reporterre, totalement gratuit mais basé sur des dons. Il est possible que sa fréquence de publication plus basse que celle d'un quotidien (seulement 6 articles par jour en septembre 2025), requière le travail de moins de journalistes à temps plein.
| Source possible de revenus | Montant unitaire | Quantité nécessaire pour financer un salaire1 |
|---|---|---|
| Abonnement | 12€ 2 | 297 |
| Affichage d'une publicité (régie tierce) | 0,00046€ 3 | 7 758 696 |
| Diffusion d'une publicité (régie intégrée) | 10 000€ 4 | 0,35 |
Tab. 3 : Source de revenus possibles pour le service d'un quotidien national.
L'étude de l'offre des quotidiens nous a permis d'identifier les sources de revenu communément utilisées (cf Tab. 2). Associées à un bref état de l'art (cf. Tab.3), nous avons pu établir que :
- le suivi des parcours des visiteurs n'est, apparemment, pas rémunérateur en lui-même mais fait partie de l'affichage des publicités ;
- les deux principaux modèles de revenu concernant la diffusion d'une publicité distribuée par une régie tierce sont le revenu pour mille vues (RPM) et le revenu par clic ; le second se généralisant pour la partie contractuelle, le premier est souvent donné comme une simple estimation basée sur le taux de clic moyen ;
- la diffusion d'une publicité gérée par une régie intégrée à un quotidien existant sous forme numérique et "papier" est incomparablement plus rémunératrice, que par une régie tierce.
- un modèle par abonnement semble adapté à financer les salaires des journalistes d'un quotidien à diffusion nationale.
Par conséquent, pour réduire l'impact écologique du service, nous proposons de :
- de renoncer aux publicités gérées par une régie tierce,
- d'adopter un modèle basé principalement sur les abonnements,
- de le compléter par un bandeau publicitaire (pour les non abonnés) géré par une régie intégrée.
Au vu des différents services comparés, des exigences environnementales exprimées plus haut et des scénarios retenus, nous avons défini pour notre prototype une maquette de l'interface et un échantillon de données réalistes.
Les ressources Web possédant une représentation sur notre application seront de deux types :
- la "une" du journal (avec une HTTP-URI ayant pour chemin
/) ou, plus spécifiquement, d'une rubrique thématique (avec pour chemin/?topic={name}), - un article du journal (avec pour chemin
/{id}).
Fig.1: Maquette de l'interface du prototype : a. type de page pour les "titres" (du jour ou d'une rubrique), b. type de page d'un article.
Dans un objectif de sobriété environnementale, les articles sont pour l'instant limités à ceux du jour et de la veille (soit 20 à 30 articles).
Pour des raisons de respect des droits d'auteurs, nous utilisons des données générées (avec dummy-json).
Bien que fictives, ces données correspondent à la structure des services concurrents : les articles comportent un titre possiblement long, un auteur et une rubrique (voir modèle de données).
Pour cette première version du prototype (v1.0.0) :
- l'échantillon de données est encore chargé dans le code de manière statique,
- les fonctionnalités implémentées ne sont que celles nécessaires pour suivre le scénario prioritaire ("Lire des articles parmi les articles du jour").
Ce scénario nécessite de pouvoir naviguer entre deux types de page : la page des titres et les pages des articles.
Nous avons développé la page des titres (cf. Fig. 2) pour qu'elle affiche l'échantillon de données sous une forme proche de ce que prévoyait la maquette.
Fig.2: Prototype de la page des titres.
Pour l'instant, nous avons choisi un framework de mise en page minimaliste (PicoCSS). Dans la suite du projet, nous verrons si l'impact environnemental du passage à un framework de mise en page plus puissant (comme Bootstrap) est acceptable.
De même, nous avons décidé, contrairement à l'ensemble des services concurrents, de ne pas inclure de photographies dans cette page. Même si ces photographies ont probablement un impact sur l'attention portée à un article, elles ne sont pas strictement requises pour la consultation des titres et ne sont donc pas incluses dans le produit minimum viable. Si une telle fonctionnalité devait par la suite être introduite, il faudrait mettre en balance son utilité et son impact a priori important. En effet, à moins de mettre en place des techniques avancées d'optimisation (et possiblement ambivalentes) comme les sprites en CSS ou le multiplexage dans HTTP/2 (cf. Wikipédia), une requête supplémentaire est nécessaire pour chaque image.
Dans l'état actuel du prototype, il est possible d'avoir une première idée de l'impact environnemental du frontend. Bien entendu, il manque encore le chargement dynamique des données, mais nous pouvons déjà évaluer l'impact de l'affichage des données et du framework (au sens large : React, PicoCSS, DayJS). Cette évaluation de l'impact (cf. Tab.4) est déjà encourageante en mode "développement" mais encore plus en mode "pré-production". Nous mesurons ici l'effet positif de l'adoption d'outils de développement Web intégrant la "minification" (cf. Wikipédia) du code et la concaténation du code d'une part et des feuilles de style d'autre part.
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| Mode "développement" | 75 B 🟩 | 1,5 | 191 | 26 | 2232 |
| Mode "pré-production" | 88 A 🟦 | 1,2 | 190 | 4 | 125 |
Tab.4: Évaluation de l'impact du prototype de la page d'accueil.
Les pages des articles ont pour HTTP-URI /{id}.
Comme l'échantillon de données ne comportait pas d'identifiants pour les articles, nous avons adopté pour l'instant leur horodatage en tant qu'identifiant.
De même que précédemment, nous avons tenté d'implémenter cette page (cf. Fig. 3) conformément à ce que prévoyait la maquette. Notons que nous n'avons pas inclu le choix des rubriques puisque cette fonctionnalité n'est pas incluse dans le scénario prioritaire.
Fig.3: Prototype de la page d'un article.
Avec l'ajout de ce modèle de page et la mise en place de la navigation entre les deux modèles, il devient possible d'exécuter le scénario prioritaire complet et de mesurer son impact.
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| 1. Consulter les titres | 88 A 🟦 | 1,2 | 190 | 4 | 125 |
| 2. Choisir et lire un article | 96 A 🟦 | 1,1 | 24 | 4 | 1 |
| 3. Revenir aux titres et les consulter | 89 A 🟦 | 1,2 | 190 | 4 | 1 |
| 4. Choisir et lire un autre article | 96 A 🟦 | 1,1 | 22 | 4 | 1 |
Tab.5: Évaluation de l'impact du scénario "Lire des articles parmi les articles du jour" dans le prototype v1.0.0.
Ces estimations bien qu'artificiellement basses (puisque les données sont chargées de manière statique) sont tout de même à comparer avec celles des services concurrents vues précédemment.
Si nous arrivons à maintenir les émissions en dessous de 1,3 g par page pour notre produit minimum viable, nous pouvons donc espérer proposer une alternative environ 2 fois moins impactante que les services existants (en incluant pourtant la participation au cycle de vie du terminal).
Pour cette nouvelle version du prototype (v1.0.1), identique du point de vue fonctionnel, les données (toujours statiques) sont désormais chargées par le frontend à travers le réseau immédiatement après un premier affichage à vide.
Ce comportement, plus réaliste, n'a pour effet qu'une requête supplémentaire par page affichée.
Concernant l'évaluation de l'impact environnemental du scénario, par rapport au tableau précédent (cf. Tab.5), à l'exception du nombre de requêtes qui est incrémenté de 1, les résultats sont strictement identiques.
Maintenant que notre prototype est réaliste en termes de nombre de requêtes, nous pouvons simuler les effets du "passage à l'échelle".
Dans le cas qui nous occupe de la presse quotidienne et dans le cadre des fonctionnalités envisagées (consultation d'articles), l'augmentation de la quantité des données à traiter ne viendra ni de l'augmentation du nombre de journalistes ni même de celle des lecteurs. Par contre, il est d'usage sur les applications de presse d'avoir accès aux archives du journal, le but étant d'éclairer l'actualité à la lumière du passé plus ou moins proche. Cette exigence fonctionnelle bien que coûteuse du point de vue environnemental nous semble contribuer grandement à l'utilité sociale de la plateforme. Par conséquent nous adopterons également ce choix de conception.
L'augmentation du volume d'articles est linéaire : à raison de 25 nouveaux articles par jour, la base de données sera de 3000 articles au bout de 4 mois (et ainsi de suite).
Produites désormais de manière automatique lors de l'intégration continue, les mesures nécessaires à la production de l'EcoIndex, avant et après la simulation du passage à l'échelle retraduisent bien (cf. Tab.6) l'augmentation du poids des téléchargements, mais aussi de l'augmentation du nombre d'éléments de la page des titres.
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| 1. Consulter les titres | 29 E 🟥 |
2,4 |
19 014 |
6 | 11 400 |
| 2. Choisir et lire un article | 76 B 🟩 |
1,5 |
30 | 2 | 10 800 |
| 3. Revenir aux titres et les consulter | 30 E 🟥 |
2,4 |
19 014 |
2 | 10 800 |
| 4. Choisir et lire un autre article | 76 B 🟩 |
1,5 |
26 | 2 | 10 800 |
Tab.6: Effet du passage à l'échelle sur l'impact du scénario "Lire des articles parmi les articles du jour" dans le prototype v1.0.1.
On pourrait s'étonner que la baisse de l'EcoIndex soit beaucoup plus forte pour la page des titres que pour la page d'un article alors que l'augmentation du poids des téléchargements est analogue. Ceci s'explique par le fait que l'EcoIndex vise à évaluer un impact global, incluant une part de la fabrication et de la fin de vie des terminaux, et que cette part augmente avec le nombre d'éléments de la page. Pour évaluer plus précisément l'impact de la consultation elle-même nous utiliserons un autre outil de mesure : GreenFrame.
Le logiciel GreenFrame est capable d'estimer, pour les différents composants de l'architecture, la consommation énergétique :
- du CPU (à partir du temps de calcul),
- de la mémoire vive (à partir de la taille des données mémorisées),
- du disque (à partir de la taille des données lues et écrites),
- du réseau (à partir de la taille des données reçues et envoyées),
- pour le navigateur uniquement, de l'écran (à partir du temps d'exécution du scénario).
| (a) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0027 | 0.000058 | 0.0 | 0.062 | 0.069 | 0.13 |
| Serveur Web | 0.000061 | 0.000020 | 0.0 | 0.063 | 0.0 | 0.063 |
| (b) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0035 | 0.000065 | 0.0 | 0.062 | 0.072 | 0.14 |
| Serveur Web | 0.000074 | 0.000021 | 0.0 | 0.063 | 0.0 | 0.064 |
Tab.7: Estimation de la consommation énergétique de la consultation des titres du journal (premier tableau) et d'un article (second tableau).
Par rapport à ce que pouvait laisser penser l'EcoIndex, les résultats (cf. Tab.7) indiquent que la consommation due à la consultation de l'index (avec ses 3000 titres) est équivalente à celle d'un article. Autrement dit, l'affichage en lui même de ces données en grand nombre est négligeable par rapport à la transmission de ces données sur le réseau.
Par contre, l'affichage de ces données a bien un impact indirect : en augmentant le temps de lecture, il a un effet déterminant sur le temps d'éclairage de l'écran. De fait, les trois éléments ayant le plus d'impact (à peu près à égalité, le reste étant négligeable), sont ici :
- l'écran du client,
- le réseau du client,
- le réseau du serveur.
Afin de réduire l'impact énérgétique du réseau, nous stockons désormais les données de l'application (v2.0.0) dans une base de données (CouchDB).
Cette évolution nous permet, lors de l'affichage d'un article, de charger un seul article plutôt que 3000.
| cpu (s) | screen (s) | mem (B) | disk (B) | network (B) | |
|---|---|---|---|---|---|
| Navigateur | 0,0754 |
17,6 | 1,24e+8 |
0,00 | 3,64e+5 |
| Serveur Web | 0,000210 |
0,00 | 5,56e+6 | 0,00 | 3,62e+5 |
| Base de données | 0,0357 |
0,00 | 1,27e+8 |
0,00 | 1,80e+3 |
Tab.8: Effet sur l'utilisation des ressources de l'introduction d'une base de données dans l'application, lors de la consultation d'un article.
Cette amélioration (cf. Tab.8) est assez spectaculaire avec notamment (pour les valeurs significatives) :
- une réduction de 97% de la quantité de données chargées par le client,
- une réduction de 51% de la charge du CPU sur le client,
- une réduction de 24% de la mémoire vive utilisée par le client,
- une utilisation des ressources par la base de données négligeable excepté une consommation très importante de mémoire vive (16 fois la quantité nécessaire pour le serveur Web).
| (a) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0,0027 | 0,000058 | 0,0 | 0,062 | 0,069 | 0,13 |
| Serveur Web | 0,0000043 |
0,0000029 |
0,0 | 0,0019 |
0,0 | 0,0019 |
| Base de données | 0,0033 |
0,000066 |
0,0 | 0,064 |
0,0 | 0,067 |
| (b) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0,00094 |
0,000046 |
0,0 | 0,0019 |
0,072 | 0,075 |
| Serveur Web | 0,0000037 |
0,0000029 |
0,0 | 0,0019 |
0,0 | 0,0019 |
| Base de données | 0,00062 |
0,000065 |
0,0 | 0,0000092 |
0,0 | 0,00070 |
Tab.9: Effet sur la consommation énergétique de l'introduction d'une base de données dans l'application, lors de la consultation des titres du journal (premier tableau) et d'un article (second tableau).
Pour la consultation d'un article, cette forte diminution de l'utilisation des ressources se traduit par une consommation énérgétique estimée (cf. Tab.9b) quasiment minimale puisqu'à peine supérieure à celle de l'écran.
Concernant la consultation des titres (cf. Tab.9a), par contre, l'ajout de la base de données a eu pour seul effet notable de remplacer la consommation du réseau du serveur Web par celle du réseau de la base de données. Pour réduire cette consommation, nous devons maintenant réduire drastiquement la quantité de données chargées par la page des titres du journal.
Dans sa version sur papier, la page des titres d'un journal ne donne accès qu'aux articles du jour (ceux terminés lors du "bouclage"). Cependant, cette stratégie ne peut pas être transposée directement au numérique puisque sur les applications de presse, les articles sont d'ordinaire rendus publics au fur et à mesure qu'ils sont terminés. Dès lors, deux stratégies équivalentes peuvent être envisagées pour donner accès sur la page des titres à un choix d'article équivalent mais en flux continu :
- donner accès aux articles parus dans le numéro papier du jour (écrits donc la veille ou dans la nuit) et ceux déjà écrits, à paraître dans le numéro du lendemain,
- donner accès aux
nderniers articles écrits (oùnserait le nombre habituel d'articles dans un numéro, par exemple 24).
Dans un cas comme dans l'autre, ce filtre nécessite d'indexer préalablement les articles en fonction de leur date et heure de publication en ligne.
Notons que nous choisirons la seconde stratégie qui permet d'éviter plus facilement au lecteur une disparité d'expérience suivant le moment de la journée où il consulterait la page des titres.
Par ailleurs, comme nous l'avions défini au départ, il est d'usage et souhaitable d'avoir accès aux anciens articles. Par conséquent, l'application permettra de charger d'autres titres à la demande de l'usager et de manière progressive.
Fig.4: Chargement progressif (à la demande) des titres du journal (copie d'écran).
| cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) | |
|---|---|---|---|---|---|---|
| Navigateur | 0,00067 |
0,000043 |
0,0 | 0,0019 |
0,069 | 0,072 |
| Serveur Web | 0,0000043 | 0,0000029 | 0,0 | 0,0019 | 0,0 | 0,0019 |
| Base de données | 0,00076 |
0,000066 | 0,0 | 0,000036 |
0,0 | 0,00086 |
Tab.10 : Effet sur la consommation énergétique du chargement progressif (à la demande) lors de la consultation des titres du journal.
L'implémentation de la stratégie en question (v2.0.1, cf. Fig.4) a l'effet attendu (cf. Tab.10) : là aussi, la consommation électrique de l'ensemble des composants se retrouve réduite quasiment à celle de l'écran.
On pourrait bien-sûr opposer le fait que, dès lors, si l'on souhaitait afficher l'ensemble des éléments, la consommation serait supérieure à celle qu'elle était avant la mise en place du chargement progressif. Cependant, la centaine de clics qui serait nécessaire rend ce scénario d'utilisation peu probable, d'autant plus que les titres les plus récents sont affichés en premier.
Pour résumer, le passage à l'échelle de 25 articles de presse à 3000 (correspondant respectivement aux données d'une journée et de 4 mois), avait entraîné un triplement de la consommation électrique. Par des techniques simples de base de données (sélection du document pertinent, projection des attributs nécessaires et pagination des résultats), la consommation électrique est revenue à ses valeurs initiales. En l'état, la consommation électrique est constante par rapport à la volumétrie des articles de journal, et à un niveau si bas que la part due au CPU, à la mémoire et au réseau est négligeable par rapport à celle de l'écran.
L'enjeu dans les améliorations à venir de l'application sera de veiller à conserver cette sobriété.
Maintenant que nous disposons d’un produit minimum viable sobre et passant à l’échelle, il s’agit de continuer à améliorer sa qualité d'usage sans augmenter significativement son impact écologique. Deux contributions ont été prototypées et ont fait l’objet de mesures d’impact :
- une nouvelle fonctionnalité de consultation des titres par rubrique (cf. Fig.5),
- le remplacement (envisagé précédemment) du framework de mise en page (cf. Fig.6) : de PicoCSS, très minimaliste, vers Boostrap, présent sur 15% des sites Web dans le monde (source : W3Techs).
Fig.5 : Prototype de la page d’une rubrique (copie d’écran).
Fig.6 : Prototype de la page des titres avec Bootstrap plutôt que PicoCSS.
Avec l’ajout de la nouvelle fonctionnalité, les mesures (des anciennes fonctionnalités) sont inchangées. La consultation de la page d’une rubrique a par ailleurs la même consommation énergétique que celle des titres. L’ajout de ces pages, possiblement plus en accord avec les centres d’intérêt des lecteurs, pourrait entraîner un temps de lecture global plus long. Cependant, nous ne pensons pas que le seul fait de disposer de quelques rubriques thématiques suffise à mettre le lecteur dans une « boucle addictive » comparable à ce qui est attesté sur les réseaux sociaux. Ce risque est d'autant plus faible si le temps de consultation global est borné par des facteurs extérieurs comme par exemple le temps de transport en commun entre le domicile et le lieu de travail. Pour toutes ces raisons, nous considérons que l’impact écologique de cette nouvelle fonctionnalité est négligeable. Nous validons donc l’ajout de cette fonctionnalité.
| cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) | |
|---|---|---|---|---|---|---|
| Navigateur | 0,0014 |
0,000043 | 0,0 | 0,0030 |
0,069 | 0.074 |
| Serveur Web | 0,0000043 | 0,0000029 | 0,0 | 0,0029 |
0,0 | 0,0029 |
| Base de données | 0,00076 | 0,000066 | 0,0 | 0,000036 | 0,0 | 0,00086 |
Tab.11 : Effet sur la consommation énergétique du remplacement de PicoCSS par Bootstrap.
Concernant le changement de framework de mise en page, les mesures (cf. Tab.11) montrent un doublement de la consommation énergétique du CPU dans le navigateur et une augmentation de 50% de la consommation du réseau entre le navigateur et le serveur Web statique. Si la première est négligeable par rapport à la consommation énergétique globale, la seconde suffit cependant à l’augmenter de 4%. Cette légère dégradation de la sobriété de l’application aurait pu être tolérée si la modification apportée s’était accompagnée d’une amélioration notable de la qualité d’usage. Comme ce n’est pas réellement le cas, nous décidons de ne pas valider cette contribution et donc de ne pas intégrer la branche de développement correspondante.
De ce projet et des estimations ou mesures réalisées avec GreenIT Analysis et GreenFrame, je retiens trois points principaux.
Le premier de ces points est illustré par la différence d’ordre de grandeur entre les émissions de gaz à effets de serre évalués par GreenFrame, d’une part, pour la consultation seulement, et par GreenIT Analysis, d’autre part, pour l’impact global incluant le cycle de vie des équipements. Le fait de réaliser des applications Web plutôt que natives permet aux usagers de conserver des terminaux anciens. Dans l’hypothèse cependant où les usagers ne seraient plus en mesure de mettre à jour leurs navigateurs depuis plus de 2 ans et demi, il faudrait configurer différemment le processus de « transpilation » (source : Vite).
Le second point, mis en évidence par toutes les mesures réalisées avec GreenFrame, est la part significative – pour les applications Web – de l’impact du réseau par rapport à celle des CPU et à plus forte raison de la mémoire. Ce point peut être contre-intuitif pour des ingénieurs logiciels qui ont généralement appris à optimiser l’utilisation de ces deux dernières ressources et non de la première. Dans ce projet, le choix de conception le plus efficace pour réduire le nombre et la taille des requêtes a été de renoncer aux régies publicitaires. Le modèle économique du service a été revu pour être basé principalement sur les abonnements et être complété par quelques rares publicités, en régie interne (pour une meilleure valorisation et pour être en capacité de n’accepter que les publicités pour des services ou produits compatibles avec nos principes de sobriété). Un second choix de conception a été de renoncer aux vignettes couramment associées aux articles (ce qui n’empêche pas ponctuellement d’illustrer un article par une véritable photographie de presse). Du point de vue de l’implémentation, côté-serveur, la sélection des enregistrements pertinents et la pagination a permis de conserver une taille des données échangées, faible et constante malgré une augmentation croissante des données stockées. Enfin, nous avons pu mettre en évidence que le choix des bibliothèques de programmation (PicoCSS plutôt que Boostrap) avait un effet non négligeable sur la taille des téléchargements et donc sur la consommation énergétique.
Le troisième point, également révélé par les mesures de GreenFrame, porte sur la différence de consommation énergétique entre le côté client et le côté serveur et ce essentiellement en raison de la part de la consommation due à l’écran. Dans le cas de notre application Web pour laquelle nous avons choisi de réaliser le rendu côté-client (client-side rendering) et où les données sont indexées côté-serveur par une algorithme Map/Reduce, la consommation énergétique du serveur est 24 fois plus faible que celle du client. Les bonnes performances de cette approche, portée par nos choix techniques (resp. React et CouchDB), nous montrent au passage que la frugalité numérique peut être cherchée et atteinte avec des environnements de développement récents. Il serait intéressant à l’avenir de vérifier si la consommation énergétique globale de l’application Web serait supérieure avec d’autres choix, plus « traditionnels », comme le rendu côté-serveur ou une gestion de base de donnés relationnelle. La consommation de l’écran, pour sa part, ne peut pas être réduite par une mesure technique puisqu’elle ne dépend que de la durée du scénario. Par contre, un certain nombre de choix de conception ont été pris pour éviter une augmentation du « temps d’écran » : les contenus affichés ne nécessitent pas plus de quelques minutes de lecture, le chargement des pages suivantes n’est pas déclenché de manière automatique (par ce que certains appellent le « scrolling infini »), aucune notification n’incite le lecteur à revenir consulter l’application. Au delà de ces quelques principes, l’objectif de la réduction de la consommation énergétique de l’écran ouvre des perspectives aussi nouvelles que déstabilisantes pour le génie logiciel : du point de vue écologique, une bonne application serait soit une application sans affichage soit une application dont le temps d’utilisation serait le plus faible possible…
Footnotes
-
Basé sur le coût total employeur du salaire médian 2025 soit 3569€ environ (source : URSSAF). ↩
-
Basé sur l'abonnement mensuel du Figaro et du Monde (12,99€), de La Croix (12,90€), de Libération (11,90€), de L'Humanité (11€). ↩
-
L'estimation utilisée ici est basée sur le revenu pour mille vues en Allemagne en 2023 (source : AdCPMRates). ↩
-
Basé sur le prix d'un bandeau court à la une d'un numéro de La Croix (source : Bayard) en 80 000 exemplaires papier et 80 000 vues sur le site (source : Bayard). ↩