Notre utilisation personnelle de services de lecture et d'écriture en ligne constitue une valeur moyenne horaire de 20h/semaine. Ce qui est une grosse partie de notre consommation en ligne, non pas pour la consommation électrique mais la durée d'utilisation. Nous avons constaté :
- Une augmentation significative d'utilisation de services de lecture en ligne durant la période COVID de lecteurs(ices) en ligne.
- 15 millions d'oeuvres écrites sur le site Archive of our Own
- Pour la culture -> les livres alimentent depuis très longtemps la culture, les meurs et la morale
- Pour la connaissance -> depuis longtemps les livres permettent de partager la connaissance et d'apprendre, d'étudier divers sujets
- Pour le loisir et le bien-être -> les livres peuvent représenter une échappatoire à la dépression ou à un mal-être quelconque, donner des conseils de vie, permettre de relativiser sur notre existence, ou aider avec la confiance en soi
- Pour l'expression de soi et des autres -> les livres permettent de s'exprimer, de découvrir différentes opinions, d'en discuter avec les autres, d'alimenter des débats
- Pour la liberté d'expression -> pour notre chère constitution
- Pour le climat -> réduit l'utilisation de papier, et utilise peut de consommation éléctrique comparer à d'autres divertissements
- Pour les auteurs
- Communautaire
- Évite l'édition chère (contourne les maisons d'éditions)
- Avoir des avis rapidement pour les jeunes auteurs
- Démocratisation de l'écriture -> ouverte à plus de monde
- Pour les lecteurs
- Permettre d'avoir plus de choix
- Découvrir plus facilement de nouveaux auteurs grâce aux avis
- Pouvoir trier, filtrer et donc trouver ce qui nous intéresse plus facilement
- Substituer le papier par le digital
- Manuscripts papier vers le digital, beaucoup moins de gaspillage de papier pour opérer des changements dans les textes mais à voir si c'est rentable d'un point de vue écologique
- Permet d'éviter d'imprimer des manuscripts vers les maisons d'éditions puis qu'on poste directement en ligne
- Avoir une copie papier et une copie numérique
- Plus facile de lire des livres -> donc on en consomme plus
Nous faisons l’hypothèse qu’une personne venant sur Wattpad est là pour découvrir, chercher, lire ou écrire des histoires. Pour le temps limité de la requête, nous estimerons que l’utilisateur ne lis ou écrit qu’un seul chapitre, en moins de quelques minutes (ce n’est évidement pas un reflets de la réalité).
Nous ferons aussi la distinction entre la recherche et la lecture de livre dans deux sénarios distincts ainsi qu’un seul scénario pour l’écriture et un pour l'aspect communautaire avec l’écrit d’un commentaire.
- Le lecteur se connecte
- Le lecteur va sur son profil
- Le lecteur lit la nouvelle publication d’une histoire
- Le lecteur va sur la page d’accueil
- Le lecteur tape sa recherche dans la barre
- Le lecteur filtre sur sa recherche
- Le lecteur scroll (ne peut pas le simuler sur l’ecoindex)
- Le lecteur clique sur une histoire
- L’auteur se connecte
- L’auteur va sur la page d’écriture
- L’auteur remplit son chapitre
- L’auteur publit son histoire
- L’auteur se connecte
- L’auteur consulte une de ses histoire favorite
- L’auteur laisse un j’aime
- L’auteur publie un commentaire
L'EcoIndex d'une page (de A à G) est calculé en fonction du positionnement de cette page parmi les pages mondiales concernant (voir sources) :
Nous avons choisi de comparer l'impact des scénarios sur les services de lecture et écriture en ligne. Nous avons choisi de faire une moyenne selon nos observations des mesures sur la classe finale, en prenant principalement en compte ce qui va être le plus utilisé (la lecture d'un chapitre)
| Service | Score sur 100 | Classe | Détails des mesures |
|---|---|---|---|
| Wattpad | ~20 | ~F | ... |
| AO3 | ~60 | ~C | ... |
| Atelier des auteurs | ~40 | ~D | ... |
Tab.1: Mesure de l'écoindex moyen des services de lecture et écriture en ligne
Écriture et lecture en ligne : oligopole~concurrence / des produits différenciés (on ne retrouve pas les même oeuvre sur les même plateforme) mais homogènes au niveaux des services On peut soit:
- se différencier avec notre esprit “sobre” sur la concurrence et instaurer de la qualité à travers des services, mais il faut trouver plus de fond
- Proposer des changements Wattpad pour qu’ils réduisent leur consommation donc qu’ils deviennent plus sobre ou de les convaincre d’avoir un service pour l’environnement au sein de leur entreprise ⮞ améliorer la qualité ? / vente de formations ? / ajout de donations ?
- Autre pratique de publicités qui ne se base pas sur les données des utilisateurs mais les tag d’une histoire pour savoir sur quoi s’intéresse une personne ⮞ des publicités à générer que sur des tags bien précis / plus facile de les choisir
Masse salariale simplifiée ⮞ montant unitaire ⮞ quantité nécessaire pour financer un salaire Salaire médian 3569€
⮞ ateliers des auteurs / formation vendu à 180€ / ans ⇒ ~238 formations vendu pour un salaire ⮞ Ao3 campagne de don 2024 / https://archive.transformativeworks.org/admin_posts/30235 : 214 698,86 US$ par 6 955 personnes dans 81 pays différents ⇒ ~0,2 de la somme par mois de donation pour un salaire ⇒ 5 personnes ⮞ Wattpad : abonnement premium / qualité donnée par les éditeurs dans le premium gratuite à lire par mois / fonctionnalités supplémentaire dans l’abonnement ⇒ ~6€ par mois / wattpad coins (token) / si l’histoire est finie depuis longtemps, payé pour la lire / / publicités et tracking l’auteur la rend payante, en ayant un contrat avec comission sur la plateforme / Publicité pour l’auteur à rajouté sur ces livres ⇒ / token / wattpadcoins
Publicité par les tags ⮞ moins de ciblage sur la personne mais sur les tags d’une histoire, avec une équipe intégrée pour les publicités (qu’ils aient le choix sur les publicités) ⮞ leur demander d’améliorer leur recherches ⮞ Faire de la formation d’écriture ⮞ des ateliers avec des auteurs agréger sur wattpad ayant déjà un contrat avec eux ⮞ Un systèmes de donations ? difficile vu que ce sont des jeunes sur la plateformes ⮞ Plusieurs types de warning et tags comme Ao3 ⮞ plus un problème d’éthique que d’environnement ⮞ Subvention pour la culture et les livres ⮞ crowdfounding ⮞ pour l’auteur pour continue à écrire ⮞ une partie qui est redonnée à la plateforme ⮞ si aucune publication de chapitre après un certain temps (parce que pas de don, ou autre) pendant trop de temps → histoire déclarée tenue en otage donc plus la possibilité d’utiliser ce moyen de financement jusqu’à retrouver un rythme de publication correcte
Les ressources Web possédant une représentation sur notre application seront de quatre types :
- La page principale comporant la liste des oeuvres et un moyen de faire une recherche dans cette liste (ayant pour chemin
/) - La page d'une oeuvre (ayant pour chemin
/work/{work_id}) - La page de profile d'un auteur (ayant pour chemin
/author/{author_id}) - La page d'un chapitre d'une oeuvre (ayant pour chemin
/work/{})
Fig.1: Maquette de l'interface du prototype
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.1.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 une oeuvre").
Ce scénario nécessite de pouvoir naviguer entre trois types de page : la page des titres, les pages des oeuvres et les pages des chapitres.
Nous avons développé les page des titres, des oeuvres et des chapitres (cf. Fig.2, Fig.3 et Fig.4) pour qu'elles affichent les échantillons de données sous une forme proche de ce que prévoyait la maquette.
Fig.2: Prototype de la page des titres.
Fig.2: Prototype de la page d'oeuvre.
Fig.2: Prototype de la page de chapitre.
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.
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 (Tab.2).
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| 1. Consulter les titres des oeuvres | 70 B 🟩 | 1,59 | 200 | 27 | 6799 |
| 2. Ouvrir une oeuvre | 92 A 🟦 | 1,15 | 51 | 19 | 4 |
| 3. Ouvrir un chapitre | 93 A 🟦 | 1,14 | 37 | 19 | 4 |
| 4. Retourner a la page de l'oeuvre | 92 A 🟦 | 1,15 | 51 | 19 | 4 |
| 5. Ouvrir un autre chapitre | 93 A 🟦 | 1,14 | 37 | 19 | 4 |
Tab.2: Évaluation de l'impact du scénario "Lire une oeuvre" dans le prototype v1.1.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 (Tab.1) vues précédemment.
Si nous arrivons à maintenir les émissions en dessous de 1,5 g par page pour notre produit minimum viable, nous pouvons donc espérer proposer une alternative moins impactante que AO3 et jusqu'à deux fois moins impactante que Wattpad.
Pour cette nouvelle version du prototype (v1.2.0), 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.2), on remarque que l'écoindex est l"=égèrement plus bas partout sauf pour le premier chargement de page. Ce qu'on gagne en ne chanargeant pas les données directement au chargement de la page, on le perd en les chargeant au fur et à mesure.
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| 1. Consulter les titres des oeuvres | 89 A 🟦 | 1,22 | 16 | 3 | 497,57 |
| 2. Ouvrir une oeuvre | 83 A 🟦 | 1,34 | 46 | 1 | 1543,388 |
| 3. Ouvrir un chapitre | 84 A 🟦 | 1,32 | 36 | 1 | 1543,388 |
| 4. Passer au chapitre suivant | 93 A 🟦 | 1,14 | 38 | 0 | 0 |
Tab.3: Évaluation de l'impact du scénario "Lire une oeuvre" dans le prototype v1.2.0.
Maintenant que notre prototype est réaliste en termes de nombre de requêtes, nous pouvons simuler les effets du "passage à l'échelle".
Dans notre cas, l'augmentation de la quantité des données à traiter viendra de l'augmentation du nombre d'utilisateurs, qu'ils soient auteurs ou non (puisqu'il faut gérer leur compte), du nombre d'oeuvres archivées, ainsi que de la quantité de commentaires. La gestion de ces données, bien que coûteuse du point de vue environnemental nous semble contribuer grandement à l'utilité sociale de la plateforme, que cela soit sur l'aspect d'archivage d'oeuvres ou l'aspect communautaire des interactions entre auteurs et lecteurs. Par conséquent notre projet continuera de gérer ces données.
Nous avons mis 100 auteurs et entre 100 et 200 oeuvres pour le passage à l'échelle.
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 des oeuvres | 35 E 🟥 |
2,3 |
1468 |
5 |
10280,453 |
| 2. Ouvrir une oeuvre | 75 B 🟩 |
1,5 |
60 |
1 | 9781,171 |
| 3. Ouvrir un chapitre | 76 A 🟦 |
1,48 |
45 |
1 | 9781,171 |
| 4. Passer au chapitre suivant | 93 A 🟦 | 1,14 | 47 |
0 | 0 |
Tab.4: Effet du passage à l'échelle sur l'impact du scénario "Lire une oeuvre" dans le prototype v1.2.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).
| (Consulter les titres d'oeuvres) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.022 | 0.00011 | 0.0 | 0.057 | 0.11 | 0.19 |
| Serveur Web | 0.000015 | 0.0000046 | 0.0 | 0.057 | 0.0 | 0.057 |
| (Consulter une oeuvre) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0014 | 0.000062 | 0.0 | 0.057 | 0.68 | 0.13 |
| Serveur Web | 0.000015 | 0.0000029 | 0.0 | 0.057 | 0.0 | 0.057 |
| (Consulter un chapitre) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0016 | 0.000062 | 0.0 | 0.057 | 0.69 | 0.13 |
| Serveur Web | 0.000014 | 0.0000029 | 0.0 | 0.057 | 0.0 | 0.057 |
Tab.5: Estimation de la consommation énergétique de la consultation de chaque type de page.
Par rapport à ce que pouvait laisser penser l'EcoIndex, les résultats (cf. Tab.5) indiquent que la consommation due à la consultation de l'index (avec ses 200 titres) est équivalente à celle d'un chapitre. 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'une oeuvre, de charger une seule oeuvre plutôt que 200.
| (Consulter une oeuvre) | cpu (Wh) | mem (Wh) | disk (Wh) | screen (Wh) | network (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0,0013 |
0,000058 |
0,0 | 0,078 |
0,067 |
0,15 |
| Serveur Web | 0,000019 |
0,0000029 |
0,0 | 0,078 |
0,0 | 0,078 |
| Base de données | 0,00066 |
0,000067 |
0,0 | 0,0 | 0,0 | 0,00073 |
Tab.6: Effet sur l'utilisation des ressources de l'introduction d'une base de données dans l'application, lors de la consultation d'une oeuvre.
Cette amélioration (cf. Tab.6) est ne semble pas causer de changement significatifs. On peut cependant noter une utilisation des ressources par la base de données négligeable excepté une consommation très importante de mémoire vive (30 fois la quantité nécessaire pour le serveur Web).
| (Consulter les titres d'oeuvres) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0,031 |
0,00014 |
0,0 | 0,078 |
0,13 |
0,24 |
| Serveur Web | 0,000019 |
0,0000053 |
0,0 | 0,078 |
0,0 | 0,078 |
| Base de données | 0,0012 |
0,00012 |
0,0 | 0,00000013 |
0,0 | 0,0013 |
| (Consulter un chapitre) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0,0013 |
0,000058 |
0,0 | 0,078 |
0,69 | 0,15 |
| Serveur Web | 0,000017 |
0,0000029 |
0,0 | 0,080 |
0,0 | 0,080 |
| Base de données | 0,00059 |
0,000067 |
0,0 | 0,0 | 0,0 | 0,00065 |
Tab.7: Effet sur la consommation énergétique de l'introduction d'une base de données dans l'application, lors de la consultation des titres d'oeuvres (premier tableau) et d'un chapitre (second tableau).
On peut remarquer que l'ajout de la base de données est relativement négligeable puisqu'elle consomme peut et de semble pas causer de changements significatifs.
Il est possible que nos données soient en trop petit nombre pour voir un changement significatif prendre place.
Pour donner accès sur à un nombre limité d'oeuvres sur la page d'accueil, nous décidons de ne faire apparaitre que les 5 oeuvres les plus récentes. Le reste sera accessible en cliquant sur un bouton "Suivant". Pour cela, il faut indexer préalablement les oeuvres en fonction de leur date et heure de publication en ligne.
| (Consulter les titres d'oeuvres) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0,00081 |
0,000044 |
0,0 | 0,0028 |
0,068 |
0,071 |
| Serveur Web | ,0000036 |
0,0000028 |
0,0 | 0,0028 |
0,0 | 0,0028 |
| Base de données | 0,00088 |
0,000064 |
0,0 | 0,000057 |
0,0 | 0,0010 |
Tab.8 : Effet sur la consommation énergétique du chargement progressif (à la demande) lors de la consultation des titres des oeuvres.
L'implémentation de la stratégie en question a l'effet attendu (cf. Tab.10) : 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 oruvres les plus récents sont affichés en premier.
Pour résumer, le passage à l'échelle avait entraîné une augnmentation de la consommation électrique, mais 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 a ses valeurs initiales. En l'état, la consommation électrique est constante par rapport à la volumétrie des articles de oeuvres, 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é.
Nous souhaitons maintenant essayer d'ajouter une fonctionnalité recherchée par les utilisateurs, à savoir la possibilité de voir la liste des oeuvres sur un thème précis, et donc la visualisation par tag. Pour cela, nous avons créé une seconde branche "tag_browsing" dans laquelle la fonctionnalité a été développée et nous allons maintenant comparer la consommation du site avec cette nouvelle fonctionnalité comparée à celle du site de la branche "main".
Voici a quoi cela ressemble sur le site une fois implémenté :
Fig.5: Fonctionnalité de choix de tag
| (Consulter les titres d'oeuvres) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0,0019 |
0,000049 |
0,0 | 0,0029 |
0,068 | 0,073 |
| Serveur Web | 0,0000034 |
0,0000029 |
0,0 | 0,0028 | 0,0 | 0,0028 |
| Base de données | 0,0011 |
0,000067 |
0,0 | 0,00015 |
0,0 | 0,0013 |
Tab.9 : Effet sur la consommation énergétique de l'ajout d'un affichage par tag lors de la consultation des titres d'une oeuvre.
On peut remarquer une petite augmentation, mais pas aussi grande qu'on aurait pu le penser. Nous pensons qu'il est légitime d'ajouter cette fonctionnalité définitivement au projet au vu de son importance fonctionnelle et de son coût faible.
Cependant, on peut se demander si cette fonctionnalité ne causerait pas une augmentation du temps d'écran puisqu'en trouvant un contenu qui plait on reste plus longtemps, et donc une augmentation des ressources utilisées. Nous pensons que c'est un risque probable, mais compensé par la diminution du temps d'écran nécessaire pour trouver le contenu qui nous plairait si cette fonctionnalité n'existait pas.
Nous retenons plusieurs choses de ce projet.
Premièrement, nous avons été étonnées de la consommation des applications web. Nous savions que les sites consommaient des ressources lors de leur visite et pour leur maintien, mais nous ne pensions pas que la visite consommait autant.
De plus, le fait d'avoir fait une application web et non native lui permet d'être plus accessible car permet à des ordinateurs anciens d'y accéder à condition d'avoir un navigateur mis à jour il y a moins de deux ans.
Pour garantir le modèle économique, nous avions pensé à ajouter des publicités ciblées en fonctions des tags lus par la personne, mais au vu des ressources que cela demanderait, nous avons préféré nous appuyer sur les donnations plutôt. Nous savons que c'est possible et faisable grâce à l'exemple d'AO3, et cela permet de ne pas perdre en optimisation pour ajouter des publicités, à condition de mettre en place une campagne de don annuelle.