Une application web de covoiturage transparente sur l'empreinte environnementale des trajets et sur les alternatives existantes.
Le transport est une grande source de pollution. En France, il produit environ 30 % des émissions de CO₂ (source : Ministère de la Transition écologique). La voiture individuelle est le plus gros pollueur, surtout pour les trajets domicile-travail et les déplacements réguliers. Beaucoup de ces trajets se font avec une seule personne, ce qui gaspille de l’énergie et pollue inutilement.
Le covoiturage est une solution intéressante : il permet de mettre moins de voitures sur les routes, de réduire les émissions par personne et de favoriser des transports plus écologiques.
Le covoiturage n’a pas seulement un intérêt écologique, il est aussi utile socialement et économiquement :
- Il favorise le partage et la convivialité, en permettant aux gens de se rencontrer.
- Il diminue le coût des trajets pour les automobilistes, car les frais de carburant et de péage sont partagés.
- Il aide à réduire les embouteillages et la saturation des routes.
Les applications mobiles et web ont rendu le covoiturage plus facile et plus pratique. Les utilisateurs peuvent voir les trajets disponibles, réserver ou proposer un trajet en quelques clics et organiser des itinéraires pour éviter de parcourir trop de kilomètres.
Mais il faut rester vigilant :
- Trop de petits trajets ou de détours peuvent augmenter la pollution.
- L’impact énergétique des serveurs et de l’application, même faible, doit être pris en compte.
Le service EcoVoit doit donc réduire au maximum les émissions de CO₂ tout en étant utilisé de manière responsable et efficace.
Nous avons utilisé l'extension Green IT - Analysis pour calculer les empreintes des différents services. Nous avons sélectionné 3 services de covoiturage pour les comparer :
- BlaBlaCar
- Kombo
- TicTacTrip
Nous avons créé un scénario d'utilisation sur les sites : d'abord charger la page d'accueil, puis chercher un trajet Paris-Lyon pour le jour-même, et ouvrir le premier covoiturage disponible. Voici les résultats que nous avons obtenus pour chaque site (moyenne des 3 pages) :
| Service | Eco Index |
|---|---|
| BlaBlaCar | 42,92 |
| Kombo | 32,95 |
| TicTacTrip | 40,47 |
On voit que les 3 services ont un score similaire, assez bas (en dessous de la moyenne).
Nous avons modifié la façon dont l'application charge les données d'exemple :
- Le fichier de données a été déplacé dans
frontend/public/sample_data.json - Utilisation de
fetch()pour charger les données au lieu d'un import statique - Implémentation avec
useEffectetuseStatede React
Le composant principal utilise maintenant ces hooks React :
// État pour stocker les données
const [data, setData] = useState({ users: [], trips: [], bookings: [] });
// Effet pour charger les données au montage du composant
useEffect(() => {
fetch('/sample_data.json')
.then(response => response.json())
.then(json => setData(json));
}, []); // [] signifie "exécuter une seule fois au montage"
Pourquoi utiliser useEffect ?
- Il permet d'exécuter du code après le rendu du composant
- Le tableau vide
[]garantit que le fetch ne se fait qu'une fois - C'est l'endroit idéal pour les appels API ou le chargement de données
Pourquoi utiliser fetch() ?
fetch() permet de récupérer des données depuis un fichier ou une API de façon dynamique.
- Le flux utilisateur reste le même pour les tests
- La version 6.0.0 d'EcoIndex App pose des problèmes avec les scénarios automatisés
- Recommandation : utiliser la version 5.6.0 pour les évaluations
Notre application sera financé grâce aux commissions prises sur chaque trajet réservé. Nous incluerons également des publicités. Pour finir, nous aimerions toucher des financements publics (Etat, collectivités territoriales), en promouvant l'aspect écoresponsable et la prise en compte des enjeux environnementaux d'EcoVoit.
Il y aura 5 types d'objets métier dans notre application web :
- "/search?dep={ville}&arr={ville}&date={date}" : la page d'accueil permettant de chercher un trajet avec 3 paramètres à remplir: Ville de départ, ville d'arrivée, date. Par défaut les paramètres seront vides. après les avoir rempli, les trajets correspondants s'afficheront sous forme de liste
- "/trip?trip_id={id}" : La page s'affichant après avoir cliqué sur un trajet en particulier. Elle affichera les détails du trjets: Conducteur, heure de départ, lieu de départ exact, heure d'arrivée, véhicule.
- "/booking?trip_id={id}" : La page s'affichant après avoir cliqué sur le bouton permettant de réserver un trajet
- "/user?user_id={id}" : La page affichant le compte de l'utilisateur, avec ses informations personnelles : Nom, prénom, numéro de téléphone, adresse mail, véhicule.
Les mesures ont été réalisées grâce à l'extension EcoIndex.
| Nombre de requêtes | Taille de la page (Ko) | Taille du DOM | GES (gCO2e) | Eau (cl) | EcoIndex | Note | |
|---|---|---|---|---|---|---|---|
| Mode développement | 24 | 1497 | 102 | 1.38 | 2.08 | 80.83 | A |
| Mode préproduction | 9 | 87 | 99 | 1.19 | 1.79 | 90.39 | A |
L'amélioration qu'on observe sur la version de préproduction par rapport à la version de développement s'explique par le processus de minification de React. Il réduit les tailles des noms de variable, supprime les espaces, commentaires, sauts de lignes, et il simplifie les expressions...
Maintenant que notre prototype est fonctionnel, nous pouvons simuler les effets du "passage à l'échelle".
Dans le cas qui nous occupe du covoiturage et dans le cadre des fonctionnalités envisagées (recherche et réservation de trajets), l'augmentation de la quantité des données à traiter ne viendra pas principalement de l'augmentation des fonctionnalités de la plateforme, mais bien de la croissance naturelle de sa base d'utilisateurs et de l'activité qu'ils génèrent.
Les données qui se multiplient avec l'usage sont de trois types :
- Les utilisateurs : Chaque nouvelle inscription ajoute un profil avec avatar, historique de trajets et notes. À raison d'une croissance typique de 10-20 nouveaux utilisateurs par jour pour une plateforme régionale, nous passerions de 3 à environ 1000 utilisateurs en 3 à 6 mois.
- Les trajets proposés : Chaque utilisateur actif propose en moyenne 2 trajets par mois. Avec 1000 utilisateurs dont 20% sont conducteurs réguliers, cela représente environ 400 nouveaux trajets par mois, soit 2000 trajets au bout de 5 mois.
- Les réservations : Chaque trajet génère en moyenne 1,5 réservation. Avec 2000 trajets, nous atteignons donc 3000 réservations, dont seules les 50% les plus récentes (1500) sont conservées dans la base active pour l'affichage.
Cette exigence fonctionnelle bien que coûteuse du point de vue environnemental nous semble contribuer grandement à l'utilité sociale de la plateforme : permettre aux utilisateurs de consulter l'historique complet des trajets et des réservations est essentiel pour établir la confiance et la transparence nécessaires au bon fonctionnement d'une plateforme de covoiturage.
Par conséquent, nous avons simulé un passage à l'échelle avec un facteur multiplicateur d'environ ×333 pour les utilisateurs, ×667 pour les trajets et ×750 pour les réservations, ce qui correspond à une plateforme régionale mature après 5 à 6 mois d'activité.
Valeurs avant le passage à l'index :
| Étape | EcoIndex | Note | Eau (cl) | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (Ko) |
|---|---|---|---|---|---|---|---|
| Chargement de la page | 89 | A | 1.83 | 1.22 | 40 | 3 | 208.953 |
| Attendre le chargement de la page | 89 | A | 1.83 | 1.22 | 40 | 5 | 215.008 |
| Cliquer sur le premier bouton "Voir" | 89 | A | 1.83 | 1.22 | 29 | 5 | 215.008 |
| Consulter les détails du trajet | 89 | A | 1.83 | 1.22 | 29 | 5 | 215.008 |
| Attendre | 89 | A | 1.83 | 1.22 | 29 | 5 | 215.008 |
| Retourner à l'accueil via navigation | 89 | A | 1.83 | 1.22 | 40 | 5 | 215.008 |
Valeurs après le passage à l'index :
| Étape | EcoIndex | Note | Eau (cl) | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (Ko) |
|---|---|---|---|---|---|---|---|
| Chargement de la page | 90 | A | 1.8 | 1.2 | 19 | 3 | 208.948 |
| Attendre le chargement de la page | 37 | D | 3.39 | 2.26 | 6036 | 5 | 1480.695 |
| Cliquer sur le premier bouton "Voir" | 83 | A | 2.01 | 1.34 | 29 | 5 | 1480.695 |
| Consulter les détails du trajet | 83 | A | 2.01 | 1.34 | 29 | 5 | 1480.695 |
| Attendre | 83 | A | 2.01 | 1.34 | 29 | 5 | 1480.695 |
| Retourner à l'accueil via navigation | 37 | D | 3.39 | 2.26 | 6036 | 5 | 1480.695 |
On observe une déterioration de la performance sur les deux actions nécessitant de charger les données. Cela est dû à la taille beaucoup plus importante du dataset suite au passage à l'échelle. Sur les autres actions, la différence est minime.
Dans un but de réduction de l'impact environnemental, nous stockons à présent les données dans une base de données CouchDB. Nous filtrons les données qui nous intéressent du côté du serveur.
| Service | CPU (s) | Screen (s) | Total Time (s) | Memory (B) | Disk (B) | Network (B) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0798 | 17.7 | 18.8 | 1.24e+8 | 0.00 | 3.98e+5 |
| Serveur Web | 0.00137 | 0.00 | 18.4 | 5.58e+6 | 0.00 | 5.80e+5 |
| Base de données | 0.0531 | 0.00 | 18.4 | 8.78e+7 | 0.00 | 1.82e+5 |
Ci-dessus, l'effet sur l'utilisation des ressources de l'introduction d'une base de données dans l'application, lors de la consultation des trajets
L’introduction de la base de données CouchDB a permis de mieux répartir la charge entre les différents services de la plateforme. Le navigateur reste le plus gourmand en ressources, avec une consommation élevée en CPU et en mémoire, principalement due à l’affichage et au traitement des données. Le serveur web, en revanche, est très léger, ce qui montre une bonne optimisation côté backend. La base de données consomme davantage de mémoire que le serveur web, mais son impact sur le CPU reste modéré . Enfin, le réseau est assez peu solicité. Cela s'explique par le fait que les données soient chiffrées, ce qui les rend assez légères.
| Service | CPU (Wh) | Memory (Wh) | Disk (Wh) | Network (Wh) | Screen (Wh) | Total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0010 | 0.000047 | 0.0 | 0.0020 | 0.069 | 0.072 |
| Serveur Web | 0.000024 | 0.0000029 | 0.0 | 0.0030 | 0.0 | 0.0030 |
| Base de données | 0.00093 | 0.000046 | 0.0 | 0.00093 | 0.0 | 0.0019 |
Ci-dessus, l'effet sur la consommation énergétique de l'introduction d'une base de données dans l'application, lors de la consultation des trajets
D’un point de vue énergétique, le navigateur est de loin le plus coûteux, principalement à cause de l’écran, qui domine largement les autres postes de consommation. Le serveur web et la base de données, en revanche, ont un impact minimal. Cela confirme que l’essentiel de l’énergie est dépensée côté client, notamment lors de l’affichage et de l’interaction avec l’interface. Ces résultats soulignent l’importance d’optimiser le rendu côté navigateur pour réduire l’empreinte énergétique globale de la plateforme.
L’intégration de CouchDB a permis de centraliser et optimiser le traitement des données, réduisant ainsi la charge sur le navigateur et améliorant l’efficacité globale du système. Grâce à cette approche, la consommation énergétique et les ressources utilisées côté serveur restent très faibles, ce qui limite l’impact environnemental de la plateforme. Cependant, le navigateur reste le principal poste de consommation, notamment en raison de l’affichage et de la gestion des données. Cette nouvelle version représente donc une avancée significative vers une plateforme plus durable et scalable.
Afin d'améliorer l'expérience utilisateur, nous avons rajouté des fonctionnalités sur notre site web. Sur les détails d'un trajet, nous avons rajouté des informations sur l'impact environnemental du trajet, avec des comparaisons avec d'autres modes de transport (C02 economisé, comparaison avec train et voiture seul).
Nous avons également rajouté un Tableau de Bord administrateur avec des informations diverses (nombre d'utilisateurs, de trajets, de réservations, quantité de CO2 économisée, trajets disponibles, taux de réservation, nombre de réservation par trajet. Il y a également un lien vers la page de la base de données CouchDB, ainsi qu'un bouton d'actualisation des données.
Nous avons ensuite mesuré l'impact environnemental de cette nouvelle version afin de voir l'évolution. Voici les valeurs que nous avons obtenu:
| Service | CPU (s) | Screen (s) | Total Time (s) | Memory (B) | Disk (B) | Network (B) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0817 | 17.7 | 18.8 | 1.26e+8 | 0.00 | 2.77e+5 |
| Serveur Web | 0.000330 | 0.00 | 18.4 | 5.56e+6 | 0.00 | 2.83e+5 |
| Base de données | 0.0376 | 0.00 | 18.4 | 8.91e+7 | 0.00 | 5.82e+3 |
| Service | CPU (Wh) | Memory (Wh) | Disk (Wh) | Network (Wh) | Screen (Wh) | Total (Wh) |
|---|---|---|---|---|---|---|
| Navigateur | 0.0010 | 0.000048 | 0.0 | 0.0014 | 0.069 | 0.072 |
| Serveur Web | 0.0000058 | 0.0000029 | 0.0 | 0.0015 | 0.0 | 0.0015 |
| Base de données | 0.00066 | 0.000046 | 0.0 | 0.000030 | 0.0 | 0.00073 |
Comme on le voit, les nouvelles fonctionnalités ont un impact très limité. La consommation du Navigateur est inchangée, celle du Serveur Web baisse de 50%, et celle augmente de 300% (mais valeurs très faible donc insignifiantes). Il est donc raisonnable de les garder.