Une portion non négligeable d'étudiants ont une voiture, et l'utilisent pour aller en cours. Les applications de covoiturage journaliers gagnent en popularité avec par exemple BlaBlaCar daily ou bien Karos (surtout dans le cadre de l'UTT où les trajets Karos sont remboursés par le département de l'Aube). Il nous semble utile de contribuer à cet essor des applications de covoiturage en proposant une application qui non seulement permet à ses utilisateurs de partager leurs trajets, mais est aussi soucieuse de l'impact environnemental de ses services numériques.
En 2017, 74% des actifs en emploi qui déclarent se déplacer pour rejoindre leur lieu de travail utilisent leur voiture (source : Insee). De plus, sur plus d’un million de véhicules passés au crible de mai à juin 2022 sur 13 axes autoroutiers, 14,8 % seulement contenaient plus d’une personne, contre 17,4 % en 2021 (source : roole.fr) L'objectif est donc d'essayer de maximiser les trajets en voiture avec des passagers, en proposant aux conducteurs de prendre des passagers sur leur chemin en échange de rémunération. Augmenter le nombre de passagers moyens par voiture présente de multiples avantages sociaux et environnementaux, notamment :
- les coûts d'opération de la voiture (essence, maintenance, assurance) sont réduits pour le conducteur,
- les personnes sans voiture peuvent profiter de déplacements en voiture, qui peuvent être plus pratiques que les transports en communs ou les mobilités douces comme le vélo,
- le nombre total de voitures est réduit (deux personnes avec voiture peuvent choisir de covoiturer).
De nos jours, la compétition dans le secteur des applications mobiles est rude et les fournisseurs d'application rivalisent de nouvelles fonctionnalités afin de gagner une place dans le téléphone des utilisateurs. Cette course aux fonctionnalités mène bien souvent à une grande augmentation des impacts environnementaux de l'activité de ces applications, on le voit par exemple avec la multiplication des fonctionnalités d'intelligence artificielle dans toutes les applications. D'après les chercheurs d'Open IA, la puissance de calcul requise pour l'entraînement des nouveaux modèles d'IA a doublé tout les 3.4 mois depuis 2012 (source : earth.org). Dans notre cas, nous cherchons donc à développer le minimum de fonctionnalités requises pour permettre au utilisateurs de Blutt de covoiturer correctement, tout en proposant une expérience utilisateur intuitive et agréable.
Les critères pour le développement sont les suivants :
- l'application ne doit pas chercher à remplacer des fonctionnalités déjà fournies par d'autre applications plus établies (exemple : pas de carte interactive, pas de fonctionnalité de messages intégrée...),
- l'application ne doit pas mener à une augmentation de l'usage de la voiture. Les trajets sur une distance aisément parcourue à pied doivent être découragés,
- l'impact général des systèmes numériques de l'application doit être le plus faible possible : pas d'intelligence artificielle pour faciliter les interactions ou d'algorithmes coûteux pour calculer les routes optimales. (On aurait par exemple pu en utiliser pour autoriser des requêtes de trajet en language naturel).
Nous faisons l'hypothèse que les utilisateurs cherchant un trajet sur Blutt recherchent des trajets à effectuer régulièrement. Ils n'iront pas sur l'application tous les jours afin de créer un nouveau trajet. Une fois que le contact a été établi avec leur covoitureur, il feront les démarches en interne, sans passer par l'application. On établit deux scénarios possibles d'utilisation de l'application :
- je suis un conducteur et recherche des passagers, je publie mon trajet régulier sur Blutt,
- je suis passager et recherche un conducteur pour un trajet régulier, je recherche des trajets potentiels en spécifiant les horaires qui m'intéressent, ainsi que mes destinations de départ et d'arrivée.
- L'utilisateur entre sa destination de départ.
- L'utilisateur entre sa destination d'arrivée.
- L'utilisateur entre son horaire de départ souhaitée.
- L'utilisateur lance la recherche de covoiturage en cliquant sur le bouton 'rechercher'.
- L'utilisateur consulte la liste des covoiturages qui ont été trouvés, et en sélectionne un dans la liste.
- L'utilisateur a accès à l'addresse mail du conducteur, et peut initier une démarche pour le contacter.
- L'utilisateur clique sur le bouton 'Passer en mode conducteur'.
- L'utilisateur entre sa destination de départ.
- L'utilisateur entre sa destination d'arrivée.
- L'utilisateur entre son horaire de départ souhaitée.
- L'utilisateur sélectionne le nombre de places disponibles pour des passagers dans sa voiture.
- L'utilisateur publie son trajet en cliquant sur le bouton 'publier mon trajet'.
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 deux solutions de covoiturage en ligne :
Ce sont deux solutions offrant des fonctionnalités similaires et qui ont la particularité de se vouloir des solutions simples et limitées en fonctionnalités contrairement à d'autres solutions plus populaires commme BlaBlaCar ou Karos.
Ainsi, voici les résultats obtenus :
Ainsi, en considérant les scénarios pris en compte dans l'étape précédante, nous avons décidé de créer des maquettes pour modéliser les pages de notre site et nous avons généré un échantillon de données. Concernant les maquettes, nous avons modélisé 4 pages :
Fig.1 : La page d'accueil vue
par un client
Fig.2 La page d'accueil
vue par un conducteur
Fig.3 La page de recherches
vue par le client
Fig.4 La page de
confirmation vue par le conducteur
Prototype n°1 : Fonctionnalités pour le scénario prioritaire avec données chargées de manière statique
Concernant cette première version de notre prototype, on charge nos données directement dans notre site. On ajoute aussi seulement la fonctionnalité principale qui est de trouver un covoiturage en rentrant le lieu de départ, la destination ainsi que la date. Pour cela nous avons besoin de naviguer entre deux pages, la page d'accueil et la page de recherche.
Nous avons developpé un prototype de la page d'accueil (cf. Fig. 2) pour qu'elle permette aux clients de faire une recherche.
Fig.5
: Prototype de la page d'accueil.
Pour l'instant, nous avons essayé de faire une page d'accueil simple et minimaliste avec des élements de CSS basiques. Le but étant de passer à un framework plus puissant à la suite tout en essayant de garder un bon impact environnemental.
Ainsi, contrairement à nos sites concurrents, nous avons opté pour une page sobre sans images, même si elles peuvent attirer l'attention des covoitureurs mais elles ne sont pas obligatoires pour ce type de fonctionnalités.
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) | |
|---|---|---|---|---|---|
| Mode "développement" | 90 A🟢 | 1,1 | 120 | 8 | 234 |
| Mode "pré-production" | 95 A🟢 | 1,0 | 100 | 5 | 43 |
Tab.1 : Évaluation de l'impact du prototype de la page d'accueil.
On remarque donc bien que notre page d'accueil pour l'instant permet de maintenir une empreinte environnementale minimale tout en offrant une interface fonctionnelle et intuitive.
Concernant la page de recherche, nous avons ajouté une liste contenant quelques trajets exemples. De même que pour la page d'accueil, nous avons opté pour une implémentation sobre, avec le minimum de fonctionnalités possibles en essayant de rester conforme avec la maquette. Ainsi, chaque choix comporte le nom, prénom du covoitureur, la date, le nombre de places disponibles ainsi que le prix. Nous n'avons dans cette version pas inclus de filtrage que ce soit au niveau des destinations ou encore du prix, on affiche directement tous les résultats disponibles.
Fig.5 : Prototype de la page de recherche.
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. Chargement de la page | 92 A🟢 | 1,0 | 200 | 10 | 78 |
| 2. Lancement de la recherche de covoiturage | 88 A🟢 | 1,1 | 300 | 15 | 78 |
Tab.2 : Évaluation de l'impact du scénario "Trouver un covoiturage" dans le prototype n°1.
Ces résultats démontrent que le prototype actuel permet d'accomplir les étapes clés du scénario prioritaire tout en maintenant une empreinte environnementale très faible comparée à celle retrouvée dans les sites concurrents. L'objectif pour les prototypes suivants reste d'essayer d'augmenter le minimum possible cet impact avec l'ajout de données réelles.
Prototype n°2 : fonctionnalités pour le scénario prioritaire avec données chargées de manière dynamique
Pour cette deuxième version du prototype, 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 environemental du scénario, par rapport au tableau précédent (cf. Tab.2), à l'exception du nombre de requêtes qui est incrémenté de 1, les résultats sont strictement identiques. D'ailleurs, à partir de cette version, et à moins de changements profonds, l'EcoIndex ne devrait plus évoluer de manière significative. Nous utiliserons désormais un autre logiciel, GreenFrame, qui évalue non pas l'impact "environné" de la consultation (incorporant une participation au cycle de vie du terminal) mais celui de la consultation proprement dite (cf. Tab.3) et de manière beaucoup plus fiable à partir des statistiques d'utilisation des ressources physiques (CPU, mémoire, réseau, disque).
| Impact de la page de publication de covoiturage | Impact de la consultation de la liste des covoiturages (trajet Troyes - Paris) | |
|---|---|---|
| La roue verte | 39mg | 34mg |
| Mobicoop | 62mg | 46mg |
| Blutt | 31mg | 31mg |
Tab.3 : Impact en mg CO2e de la consultation proprement dite des pages des services existants et de notre prototype.
Pour les services existants, sur le graphique présentant l'utilisation dans le temps des ressources (cf. Fig.4), on constate un deuxième pic après le pic de chargement initial, qui est probablement dû au chargement de ressources externes post chargement initial. Ces ressources peuvent inclure des images, des pages supplémentaires ou bien des services externes tels que google analytics, cependant nous avons initialement choisi des services qui étaient déjà relativement légers, par conséquent le deuxième pic conserve tout de même des proportions raisonnables. On peut le voir avec comme exemple la page de création de covoiturage du site Mobicoop
Fig.4 : Consommation de ressources lors de la consultation de
la page de création de covoiturage pour le site Mobicoop.
Fig.5 : Consommation de ressources lors de la consultation de la page de
création de covoiturage pour le site Blutt.
Par ailleurs, il nous est possible désormais d'évaluer l'impact écologique de la partie "serveur", possiblement hébergée par un data center (cf. Fig.6). Réduite au simple hébergement de données statiques sur un serveur Web, cette partie a pour l'instant un impact très faible et quasi négligeable (+2%, 0.5mg eq. CO2) par rapport à la partie "client".
Fig.6 : Consommation de ressources par le serveur Web lors de la
consultation de la page des titres dans notre prototype.
Prototype n°3 : Fonctionnalités pour le scénario prioritaire avec données stockées dans une base de données
Pour la troisième version du prototype, les données sont désormais stockées dans un système de base de données interrogeable à travers une API Web (CouchDB). L'intérêt d'une source de données dynamique est d'une part, à terme, de pouvoir ajouter ou modifier des trajets en covoiturage plus facilement, et d'autre part de déporter sur le serveur le filtrage des données pertinentes (afin de réduire l'impact de notre service pour le client).
Sur ce deuxième enjeu, on n'observe pas de changements significatifs en termes de consommation CPU et utilisation du réseau, ce qui est normal étant donné que nous n'avons pas encore implémenté de fonctionnalité de filtrage. Ces changements nous permettront cependant dans le futur de faire de grosses économies de CO2 alors que l'application fait face à des quantités plus importantes de données.
Fig.5 : Consommation de ressources lors de la consultation de la page de
création de covoiturage pour le site Blutt.
Fig.8 : Profil dans le temps de l'impact de la base de données lors de la
consultation de la page de recherche de covoiturage.
De ces différentes mesures, nous pouvons retenir que l'effet de l'introduction d'une base de données, quoique négligeable, est, pour l'instant, plutôt défavorable d'un point de vue écologique. Le bilan de ce changement devrait cependant rapidement s'inverser avec l'augmentation de la quantité de données gérées, comme nous allons le voir avec le prototype n°4.
Dans le cas qui nous occupe des covoiturages quotidiens et dans le cadre des fonctionnalités envisagées (recherche de trajet, publication de trajet), l'augmentation de données à traiter est directement liée au nombre d'utilisateurs qui utilisent la plateforme. En effet, un nombre accru d'utilisateurs signifie forcément un nombre proportionnellement accru de trajets publiés, et de recherche de trajets. Admettons que les utilisateurs publient au maximum leurs trajets 2 mois à l'avance, il faut à minima stocker tous les trajets à venir pour toutes les destinations possibles jusqu'à 2 mois plus tard. Pour évaluer ce qui serait une augmentation réaliste des données traitées par l'application dans le meilleur des cas, on prends l'exemple de BlaBlaCar, qui reporte 9 628 311 trajets en 2023 (BlaBlaCar : bilan 2023 et enjeux 2024 pour le covoiturage courte distance). On peut diviser par 6 pour obtenir 1 604 718 trajets en deux mois. On considère le fait que seulement certains trajets correspondent à la destination et l'horaire choisie par l'utilisateur, et évalue qu'on aura à traiter au maximum 10 000 trajets compatibles pour une seule recherche de covoiturage.
La figure 9 illustre le passage d'environ 60 covoiturages dans la base de données à environ 10000. On observe :
- une augmentation de 102% de la consommation équivalente totale
- une augmentation de 523% de la consommation de CPU en backend
- une augmentation de 1888% (!!!) de la consommation du réseau pour le navigateur
Fig. 9 : Évolution de l'impact de la recherche de covoiturage en passant de
60 à 10 000 covoiturages disponibles.
Évidemment, cette évolution ne concerne que la page de recherche car c'est elle qui va charger l'entièreté des trajets depuis la base de données. On va maintenant essayer de trouver un système permettant de palier à cette augmentation, et essayer de retomber sur les niveaux de consommation que nous observions précédemment.
Dans notre cas, il nous est important de tout de même laisser à notre utilisateur la possibilité de consulter l'intégralité des trajets en covoiturage qui correspondent à sa recherche. Notre objectif devrait être de proposer les covoiturages dans un ordre censé (plus pertinent au moins pertinent) en laissant la possibilité à l'utilisateur de consulter de plus en plus de trajets, seulement s'il le désire. Pour ce faire, on se calque sur le modèle de Google Search, en paginant les résultats de la recherche, et en offrant à l'utilisateur de charger des pages additionnelles. À chaque changement de page, on remplace les anciennes entrées par les nouvelles, ce qui signifie que la taille de notre DOM ne dépasse jamais un nombre maximal d'objets dictés par le nombre d'items dans une page. Ici, on choisit 10 items par page.
Fig. 10 : Interface de pagination Blutt
La stratégie de pagination a eu l'effet escompté. On observe un retour aux niveaux de consommation du prototype v2. L'application est maintenant capable de gérer une quantité importante de covoiturages sans impact significatif sur le client.
Fig. 11 : Évolution de l'impact de l'application avec l'augmentation de la
quantité de données puis sa prise en compte.
Mieux qu'un simple retour en l'état, on observe même une légère baisse de la consommation sur le réseau en raison du nombre moindre d'items récupéré sur le chargement initial de la page.
Fig. 12 : Résultats de l'impact de la page de recherche de covoiturage
paginée avec 10000 articles.
Pour l'instant, il est plus pénible pour l'utilisateur de devoir cliquer manuellement pour charger la prochaine page de covoiturages par rapport à simplement faire défiler une longue liste d'items pré-chargés. Pour palier à ce problème, il faudrait pouvoir s'assurer que pour la majorité des utilisateurs, le résultat qui les intéresse se trouve sur la première page. Cette fonctionnalité relève plus du côté backend, où un bon système de recommendation avec connaissance d'informations supplémentaires sur l'utilisateur actuel pourrait trier les résultats avant de les envoyer dans la réponse de la requête. Cette fonctionnalité est difficile à implémenter et pourrait représenter un impact environnemental grandement accru côté backend. On choisit donc pour l'instant de se concentrer sur la finalisation des fonctionnalités principales de l'application, avant de s'attaquer à des fonctionnalités supplémentaires.
Comme précédemment, un arbitrage sera réalisé pour chacune de ces fonctionnalités principales pour tenir compte à la fois de leur utilité sociale et de leur
impact environnemental.
Fig.13 : Consommation de ressources par le serveur Web lors de la
consultation de la page des titres dans notre prototype.
Si l'on considère les mesures greenframe effectuées, on se rend compte que l'écran du périphérique représente la majorité de l'impact environnemental de l'utilisation de notre application. Cela veut concrètement dire que l'on aura beau implémenter des optimisations afin de réduire le trafic réseau et l'utilisation CPU, le temps d'affichage à l'écran restera déterminant dans la consommation totale. Sachant cela en tant que développeur, notre but sera donc d'essayer de minimiser le temps passé par l'utilisateur sur l'application, tout en essayant de rester en accord avec un éventuel modèle d'affaires.