On utilise presque tous le site ou l’application de la SNCF pour regarder les horaires à venir des trains, et plus particulièrement pour acheter ses billets. C'est un service très utilisé ; on note notamment 122 millions de voyageurs ayant pris le TGV en 2023. Le train est très largement considéré comme le moyen de transport longue distance le plus écologique. Dans notre projet, tâcherons de nous intéresser à un aspect ignoré dans le calcul : l'interface web.
Les transports ferroviaires longue distance, majoritairement exploités par la SNCF, contribuent directement à une mobilité plus durable et accessible pour tous.
Accès à l’emploi : un habitant de Romilly peut travailler à Troyes ou même à Paris grâce aux liaisons ferroviaires régulières. Sans ces trajets, certaines carrières seraient tout simplement impossibles.
Accès aux services publics : santé, éducation, administration… tout devient plus atteignable, même quand on vit loin des grandes villes.
Lien entre les territoires : le train connecte des régions parfois isolées, et facilite ainsi les déplacements pour les personnes non motorisées.
Outil de décentralisation : il rend moins nécessaire de vivre dans les grandes métropoles pour avoir les mêmes opportunités.
Les applications ne sont pas nécessaires à l'emploi des solutions de transport. En revanche, elles contribuent fortement à la simplification des démarches :
- Planification simplifiée
- Visibilité des offres de réduction
- Accès aux informations (horaires)
- Achat des billets
- Meilleure compréhension et gain de temps
Ces applications permettent de favoriser l'accès à l'information et aux démarches.
Ainsi, les applications permettent une plus forte fréquentation des services, grâce à la facilitation des démarches liées aux déplacements longue distance
Les applications numériques de la SNCF remplacent en partie les billets papier achetés au guichet ainsi que les informations affichées en gare. Ces alternatives « physiques » existent toujours, mais elles sont désormais utilisées en solution de secours, plutôt qu’en premier réflexe.
Par exemple, de nombreuses gares ont réduit leurs horaires d’ouverture ou fermé certains guichets, obligeant les usagers à passer par l’application ou les bornes automatiques. Dans certaines petites gares, il n’y a même plus besoin de personnel aux guichets. Cela peut avoir des conséquences négatives, et contribue à l'exacerbation de la fracture numérique, par exemple pour les personnes âgées ou souffrant de certains handicaps.
Nous imaginons deux scénarios d'utilisation des applications de réservation de trains : l'achat d'un billet de train et la consultation de son billet. D'autres scénarios peuvent être envisagés, comme la consultation des horaires, mais ce scénario ressemble fortement au scénario de réservation de billet.
- L'utilisateur renseigne ses gares de départ et de destination, ainsi que la date du voyage.
- Ensuite, il sélectionne le voyage de son choix parmi ceux proposés.
- Puis il sélectionne les options de son voyage (seconde ou première classe, option vélo, siège, ...).
- Enfin, il valide le voyage, peut éventuellement sélectionner un deuxième voyage, puis passe au paiement.
- L'utilisateur se connecte à son espace.
- Il sélectionne le voyage à venir concerné.
- Il accède au billet, et peut par exemple le télécharger.
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 plateformes de réservation de train de divers pays, appartenant à des compagnies ou non (SNCF Connect, Deutsche Bahn, 1.2.Train, Omio, Eurostar)
| Service | Score (sur 100) | Classe | Détail des mesures |
|---|---|---|---|
| SNCF Connect | 23 | F 🔴 | ... |
| DB | 32 | E 🟠 | ... |
| 1.2.Train | 82 | A 🔵 | ... |
| Omio | 40 | D 🟡 | ... |
| Eurostar | 15 | F 🔴 | ... |
Tab.1 : Mesure de l'EcoIndex moyen de divers services de réservation de trains.
Les mesures de l'impact moyen de ces services (cf. Tab.1) révèlent des classes EcoIndex très faibles pour la plupart (D à F). Seule la solution 1.2.Train, indépendante des compagnies, se démarque avec un score élevé (A).
Une telle différence peut s'expliquer par la structure volontairement épurée et sans images du site 1.2.Train.
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 | Source de revenus |
|---|---|
| SNCF Connect | Vente de billets |
| DB | Vente de billets |
| 1.2.Train | Commissions |
| Omio | Commissions |
| Eurostar | Vente de billets |
Tab.2 : Offre des services de réservation de billets de train.
Notre marché national semble être structuré en oligopôle : il y a plusieurs offreurs pour acheter le même billet de train. Le billet vendu est le même sur les différentes plateformes mais ces plateformes ne sont pas entièrement identiques : fluidité, interface, expérience utilisateur. Les services de réservation sont substituables entre eux : si l'on ne souhaite pas acheter son billet de train sur SNCF Connect, on peut l'acheter sur 1.2.Train ou sur Omio.
1.2.Train dispose d'un modèle économique fragile qu'il serait pertinent de renforcer, mais le site web est déjà suffisamment sobre pour que l'on ne se penche pas sur ce cas dans le cadre de notre projet. Nous travaillerons donc sur SNCF Connect. Il n'y a pas de publicité sur la plateforme, qui semble uniquement se financer grâce aux revenus des ventes de billets de train (service annexe). Nous voyons donc peu d'autres modèles économiques pertinents, sachant que celui-ci semble largement viable.
| Source possible de revenus | Montant unitaire | Quantité nécessaire pour financer un salaire1 |
|---|---|---|
| Part sur les ventes de billets2 | 0,90€ | 3966 |
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 :
Pour le scénario 1 (prioritaire) :
- Les résultats de recherche de voyage (avec une HTTP-URI ayant pour chemin /trips?depart={gare_depart}&arrivee={gare_arrivee}&date={date}&time={heure})
- Les détails d'un voyage proposé (avec pour HTTP-URI /trips/{id})
- Le panier global (avec pour HTTP-URI /cart)
Pour le scénario 2 (secondaire) :
- L'ensemble des billets liés à son compte (avec pour HTTP-URI /account)
- Les détails d'un billet (avec pour HTTP-URI /account/{id})
Fig.1: Maquette de la page de recherche // Fig.2: Maquette de la page de résultats de recherche
Dans un objectif de sobriété environnementale, les résultats de recherche se limiterons à ceux du jour sélectionné.
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 voyages comportent une gare de départ et d'arrivée, une date, une heure de départ et d'arrivée, et un ou plusieurs tarifs.
Prototypage : Fonctionnalités pour le scénario prioritaire avec données chargées de manière statique
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 ("Acheter un billet de train").
Ce scénario nécessite de pouvoir naviguer entre plusieurs pages :
- la page de recherche de voyage, où il est possible de rechercher des trajets
- la page de résultats, où s'affichent les trajets correspondant aux critères
- la page de détails du trajet, une fois celui-ci sélectionné
- le panier, avant de passer au paiement du ou des billet(s)
La page d'accueil renvoie un formulaire permettant de renseigner ses critères de recherche de voyage.
Fig.3 : Prototype de la page de recherche de voyage
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.
Nous avons également fait le choix de ne pas inclure de photographies, celles-ci n'état pas nécessaires à la réservation d'un billet de train, et risquant d'augmenter substantiellement la consommation de l'application.
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). Cette évaluation de l'impact (cf. Tab.3) 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" | 79 B 🟢 | 1.42 | 81 | 29 | 1873 |
| Mode "pré-production" | 91 A 🔵 | 1.18 | 78 | 6 | 145 |
Tab.3 Mesure de l'EcoIndex moyen de notre prototype, dans le cadre du scénario n°1
La page de résultats de recherche a pour HTTP-URI /trips, et affiche actuellement l'ensemble des données factices de façon statique. À plus long terme, une requête GET sera ajoutée à la suite de /trips afin d'afficher dynamiquement les résultats selon les informations renseignées dans le formulaire de la page précédente.
Depuis cette page, il est possible d'accéder aux détails de l'un des trajets afin de le réserver, ou bien de retourner à la page d'accueil en cliquant sur le titre de la page ("EcoTrain").
Fig.4 Prototype de la page de résultats de recherche
Les pages des voyages ont pour HTTP-URI /trips/{id}. Dans notre jeu de données, chaque voyage dispose d'un ID unique qui est réemployé dans l'URI.
De même que précédemment, nous avons tenté d'implémenter cette page (cf. Fig. 4) conformément à ce que prévoyait la maquette.
Fig.5 Prototype de la page de détails sur le trajet choisi
Fig.6 : Prototype de la page du panier
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| 1. Renseigner les critères de recherche pour son trajet | 91 A 🔵 | 1.18 | 78 | 6 | 145 |
| 2. Consulter les trajets disponibles, et sélectionner celui de son choix | 75 B 🟢 | 1.50 | 43 | 6 | 145 |
| 3. Consulter les détails d'un trajet et l'ajouter au panier | 94 A 🔵 | 1.12 | 47 | 6 | 145 |
| 4. Consulter son panier et accéder au paiement | 94 A 🔵 | 1.13 | 43 | 6 | 145 |
Tab.4: Évaluation de l'impact du scénario "Achat d'un billet de train" dans le prototype n°1 (v1.0.0)
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.2), à l'exception du nombre de requêtes qui augmente légèrement, les résultats sont identiques.
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| 1. Renseigner les critères de recherche pour son trajet | 91 A 🔵 | 1.18 | 81 | 6 | 146 |
| 2. Consulter les trajets disponibles, et sélectionner celui de son choix | 75 B 🟢 | 1.51 | 501 | 9 | 146 |
| 3. Consulter les détails d'un trajet et l'ajouter au panier | 93 A 🔵 | 1.14 | 47 | 9 | 146 |
| 4. Consulter son panier et accéder au paiement | 93 A 🔵 | 1.14 | 43 | 10 | 146 |
Tab.5: Évaluation de l'impact du scénario "Achat d'un billet de train", dans la version 1.0.1
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 des plateformes de trains et des fonctionnalités prévues (consultation des voyages, achat de billet), l'augmentation de la quantité des données à traiter pourrait provenir de la conservation de trajets passés dans la base de données, ainsi que des billets de voyages passés. À raison de 15.000 trains circulant sur le réseau ferré chaque jour, si chacun d'eux effectue un seul trajet, cela augmenterait notre volumes de trajets de 15.000 par jour, soit 450.000 par mois.
Conserver ces données ne semble pas avoir une utilité suffisament importante pour justifier l'impact environnemental qui y serait associé. Ainsi, nous ferons le choix de supprimer automatiquement les trajets passés.
De la même façon, les billets relatifs aux trajets passés ne seront pas conservés.
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.
Le workflow ne semblant pas supporter le passage à l'échelle complet, et pour que la mesure puisse être effectuée dans des délais raisonnables, nous avons fait le choix de n'augmenter le nombre de voyages que d'un facteur 100 (2500 maintenant, contre 25 auparavant et 45 000 en théorie)
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| 1. Renseigner les critères de recherche pour son trajet | 84 A 🔵 | 1,3 | 89 | 6 |
418 |
| 2. Consulter les trajets disponibles, et sélectionner celui de son choix | 45 D 🟡 |
2,1 |
1771 |
1 | 761 |
| 3. Consulter les détails d'un trajet et l'ajouter au panier | 86 A 🔵 |
1,3 |
57 | 1 | 761 |
| 4. Consulter son panier et accéder au paiement | 87 A 🔵 |
1,3 |
50 | 1 | 761 |
Tab.6: Effet du passage à l'échelle sur l'impact du scénario "Achat d'un billet de train" dans le prototype v1.0.1.
On constate que la baisse de l'EcoIndex est la plus importante à l'affichage des résultats de recherche. Cela semble cohérent puisque c'est sur cette page qu'un grand nombre d'éléments (propositions de voyage de la base de données) va apparaître.
Pour évaluer plus précisément l'impact de la consultation des détails d'un trajet, 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.00094 | 0.000049 | 0.0 | 0.0021 | 0.069 | 0.072 |
| Serveur web | 0.0000090 | 0.0000048 | 0.0 | 0.0020 | 0.0 | 0.0020 |
| (b) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0067 | 0.000087 | 0.0 | 0.062 | 0.091 | 0.10 |
| Serveur web | 0.0000096 | 0.0000068 | 0.0 | 0.063 | 0.0 | 0.0062 |
| (c) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0010 | 0.000050 | 0.0 | 0.0062 | 0.069 | 0.077 |
| Serveur web | 0.0000095 | 0.0000052 | 0.0 | 0.0061 | 0.0 | 0.0062 |
Tab.7: Estimation de la consommation énergétique lors de la consultation de la page d'accueil (a), de la page de résultats de recherche (b), et de la page de détails d'un trajet (c).
Dans les résultats (Tab.7), on constate que pour la page d'accueil, sur laquelle les données ne sont pas chargées, la consommation est quasi exclusivement due à l'écran.
Sur les deux autres pages, où les données sont chargées, la consommation due à la consultation des résultats de recherche (plusieurs centaines de trajets), est équivalente à celle des détails d'un trajet (1 seul trajet). Autrement dit, l'affichage des 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 :
- 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 des détails d'un trajet, de ne charger que ce trajet au lieu de plusieurs milliers.
| cpu (s) | screen (s) | mem (B) | disk (B) | network (B) | |
|---|---|---|---|---|---|
| Navigateur Web | 0,0725 | 17,3 | 1,22e+8 | 0,00 | 4,14e+5 |
| Serveur Web | 0,000178 | 0,00 | 5,56e+6 | 0,00 | 3,77e+5 |
| Base de données | 0,0414 | 0,00 | 8,15e+7 | 0,00 | 1,35e+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.
| (a) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0,00093 |
0,000045 |
0,0 | 0,0021 |
0,067 |
0,071 |
| Serveur Web | 0,0000035 |
0,0000028 |
0,0 | 0,0019 |
0 |
0,0019 |
| Base de données | 0,00068 |
0,000042 |
0,0 | 0,0000095 |
0 |
0,00074 |
| (b) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0,00091 |
0,000045 |
0,0 | 0,0021 |
0,067 |
0,070 |
| Serveur Web | 0,0000031 |
0,0000028 |
0,0 | 0,0019 |
0 |
0,0019 |
| Base de données | 0,00072 |
0,000042 |
0,0 | 0,0000069 |
0 |
0,00077 |
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 résultats de recherche (tableau 9.a) et des détails d'un trajet ( tableau 9.b).
Pour la consultation des détails d'un trajet, 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.
Sur notre plateforme de réservation de billets de trains, il n'est pas nécessaire de faire apparaître tous les trajets à venir de la semaine sur une même page de résultats.
Ayant mis à disposition la possibilité de spécifier les gares de départ et d'arrivée, ainsi qu'une date et une heure de départ, nous ferons le choix de limiter les résultats à 10 trajets dans un premier temps, tout en laissant la possibilité de charger des trajets suivants grâce à un bouton en bas de page. À noter qu'il sera également possible de modifier les résultats en changeant l'heure de départ préalablement renseignée dans la zone de recherche.
Cette stratégie permettra à l'utilisateur de visualiser des résultats correspondant d'abord à sa recherche, tout en ayant la possibilité de modifier cette vue.
Fig.7: Chargement progressif (à la demande) des résultats de recherche (capture d'écran).
| cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) | |
|---|---|---|---|---|---|---|
| Navigateur | 0.0020 |
0.000050 |
0.0 | 0.0022 |
0.069 |
0.074 |
| Serveur Web | 0.0000033 |
0.0000029 |
0.0 | 0.0019 |
0.0 |
0.0020 |
| Base de données | 0.00086 |
0.000051 |
0.0 | 0.000026 |
0.0 | 0.00094 |
Tab.10 : Effet sur la consommation énergétique du chargement progressif (à la demande) lors de la consultation des résultats de recherche.
L'implémentation de la stratégie en question (v2.0.1, cf. Fig.4) ne semble pas avoir l'effet attendu (cf. Tab.10) : la consommation électrique n'a pas diminué avec la réduction du nombre de résultats, elle a même légèrement augmenté. Notons qu'elle reste largement négligeable face à la consommation de l'écran.
On pourrait supposer que d'éventuelles modifications dans la structure des données ou sur le frontend ont pu être à l'origine de cette légère augmentation.
Pour résumer, le passage à l'échelle de 25 à 2500 trajets disponibles, 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 a ses valeurs initiales. En l'état, la consommation électrique est constante par rapport à la volumétrie des trajets disponibles, 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é.
Pour améliorer la qualité de la mesure de l'impact énergétique de ce scénario, nous avons modifié le fichier lié à Greenframe afin d'obtenir un tableau unique pour le parcours utilisateur complet (accueil > résultats de recherche > détails d'un trajet > panier).
Voici donc la mesure finale, qui ne peut malheureuselent pas être comparée aux mesures précédentes, mais que nous pourrons additionner à la consommation énergétique du scénario secondaire que nous allons prochainement implémenter.
| (index) | cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0033 | 0.00013 | 0.0 | 0.0075 | 0.19 | 0.20 |
| Serveur web | 0.0000073 | 0.0000079 | 0.0 | 0.0020 | 0.0 | 0.0020 |
| Base de données | 0.0032 | 0.00015 | 0.0 | 0.0053 | 0.0 | 0.0086 |
Empreinte carbone estimée : 94.74 mg eq. co2 ± 0.3% (214.344 mWh).
Tab.11 : Consommation énergétique totale du scénario prioritaire.
Dans cette phase d'amélioration de notre projet, nous souhaitons mettre en oeuvre notre second scénario, qui consiste à permettre aux utilisateurs d'accéder et de télécharger les billets de trains qu'ils auront acheté au préalable.
Pour ce nouveau prototype de notre application web (v2.1.0):
- l'échantillon de données statiques du scénario secondaire sera chargé au travers d'une base de données (CouchDB),
- les nouvelles fonctionnalités implémentées ne sont que celles nécessaires pour suivre le scénario secondaire ("Consultation de billets de train").
Ce scénario nécessite de pouvoir naviguer entre plusieurs pages :
- la page d'accueil
- la page "mes voyages à venir"
- la page de détails d'un voyage prévu, une fois celui-ci sélectionné
Fig.8: Jeu de données utilisé pour les billets des utilisateurs (capture d'écran). Pour faciliter l'implémentation de la fonctionnalité, les informations des voyages en questions (stations, date, ...) ont également été générées dans ce fichier. À terme, ces informations seront directement récupérées depuis la base de données des voyages qui a été créée pour la scénario prioritaire. Elles ne figureront donc plus ici.
La page d'accueil reste quasiment identique à son état précédent. L'unique différence est l'ajout d'un bouton "Mes billets" en bas de page, permettant de se rendre vers les détails de son compte.
Fig.9: Page d'accueil avec le nouveau bouton "Voir mes billets" (capture d'écran)
La page des voyages à venir a pour HTTP-URI /account, et affiche l'ensemble des données factices liées aux voyages à venir d'un utilisateur. Les voyages affichés sont ceux liés au compte de l'utilisateur connecté. Ici, n'ayant pas encore implémenté de système de connexion ou de sélection de compte, nous affichons uniquement les voyages du premier utilisateur de notre jeu de données.
Fig.10: Page des voyages à venir (capture d'écran)
Depuis la page des détails d'un voyage (HTTP-URI /account/:trip_id). Il est possible de recueillir toutes les informations relatives au voyage, ainsi que les informations des passagers concernés (classe, siège, billet). Un bouton permet d'ouvrir le billet de l'utilisateur au format PDF, ce qui permet d'en disposer hors-ligne.
Fig.11: Page des détails d'un voyage prévu (capture d'écran)
Fig.12: Billet PDF (placeholder)
| cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) | |
|---|---|---|---|---|---|---|
| Navigateur | 0.0031 | 0.00013 | 0.0 | 0.0075 | 0.19 | 0.20 |
| Serveur web | 0.0000070 |
0.0000079 | 0.0 | 0.0020 | 0.0 | 0.0020 |
| Base de données | 0.0031 |
0.00038 |
0.0 | 0.0053 | 0.0 | 0.0088 |
Empreinte carbone estimée : 94.74 94.743 mg eq. co2 ± 0.3% (214.351 mWh).
Tab.12 : Consommation énergétique totale du scénario prioritaire suite à l'implémentation du second scénario.
| cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) | |
|---|---|---|---|---|---|---|
| Navigateur | 0.0015 | 0.00010 | 0.0 | 0.0022 | 0.15 | 0.15 |
| Serveur web | 0.0000048 | 0.0000061 | 0.0 | 0.0020 | 0.0 | 0.0020 |
| Base de données | 0.0014 | 0.00030 | 0.0 | 0.000026 | 0.0 | 0.0017 |
Empreinte estimée: 69.335 mg eq. CO₂ ± 0.4% (156.866 mWh).
Tab.13 : Consommation énergétique totale du scénario secondaire.
=> Somme des empreintes estimées des deux scénarios: 164.078 mg eq. CO₂ ± 0.4% (371.216 mWh).
L'implémentation de ce second scénario a provoqué une augmentation parfaitement négligeable de la consommation énergétique du premier scénario (cf. Tab.12). Ceux-si étant majoritairement liés à des pages différentes, cela fait sens. En revanche, on pourrait imaginer que la consommation globale par utilisateur augmente dans les cas où les deux scénarios s'enchaînent (achat du billet puis consultation). Cependant, il fait entièrement sens de proposer un moyen pour les utilisateurs de consulter leurs trajets à venir, et de télécharger leur billets. On pourrait même considérer que cela est une fonctionnalité prioritaire. Pour cette raison, nous conserverons ces nouvelles fonctionnalités dans notre produit final.
Des travaux réalisés au long de ce semestre, je retiens plusieurs points :
D'abord, j'ai beaucoup apprécié les premières séances, consacrées à questionner la valeur ajoutée des potentiels produits informatiques, plus spécifiquement au travers des prismes environnementaux et sociaux. Il s'agit selon moi d'une approche en accord avec la notion / le besoin de décroissance : il faut faire moins, sans pour autant impacter trop négativement notre qualité de vie. D'où la nécessité de questionner la pertinence de chaque projet avant même sa phase de conception.
Ensuite, j'ai été particulièrement surpris par la répartition des impacts du numérique. En effet, la large majorité des impacts est en fait liée aux équipements individuels (ordinateurs, écrans, etc.), plus particulièrement par leur phase de fabrication. Comme vu durant la Fresque du Numérique, ils représentent également une large partie des déchets engendrés, dont une faible partie est en fait réellement recyclée. Dans l'évaluation de la consommation de notre application, GreenFrame a également permis de constater cette différence notable entre les côtés client et serveur, à cause de la consommation liée à 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, la consommation énergétique du serveur est largement plus faible que celle du client. Les bonnes performances de cette approche, portée par nos choix techniques (React et CouchDB), nous montrent que la frugalité numérique peut être cherchée et atteinte avec des environnements de développement récents. 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 peuvent être pris pour éviter une augmentation du « temps d’écran », par exemple grâce à un parcours utilisateur plus fluide.
Enfin, j'ai été étonné de découvrir la part significative de l’impact du réseau par rapport au CPU. 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 images. En effet, le modèle économique de notre plateforme ne nécessitait pas de publicités, et les images relevaient d'un pur arbitrage esthétique. Du point de vue de l’implémentation côté serveur, la sélection des voyages 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.
