Finary est un service qui permet d’optimiser ses dépenses et de gérer son partimoine.
Cette application permet à la fois d’identifier les dépenses en doublons, abonnement d’un service non utilisé, ou encore investir son argent, pour faire fructifier son patrimoine, sans frais “injustifiés” par les banques et services traditionnels.
Il y’a moins d’une semaine, Finary ont levé 25 millions, et comptabilisent plus de 600k d’utililsateurs (dont nous faisons partis). Ce type de plateforme innovante nous intéresse particulierement, tant sur le volet technologique, que sur les divers impact sociaux et plus largement environnementaux.
Les services de gestion de patrimoine comptabilise aujourd’hui 4 millions d’utilisateurs en France. De manière plus générale, les services bancaires sont devenus partie intégrante de notre quotidien.
L’inflation en France n'a cessé de croitre ces dernières années. D’après l’inserm, +5,9% en 2023, 1,9% en 2024.
C’est dans ce contexte que de plus en plus de personne ont le désir de mieux gérer leur patrimoine, aussi bien leurs dépenses que leurs méthodes d’investissements.
Les services bancaires comme Finary, proposent un accompagnement autonome et personnalisé, pour à la fois aider l’utilisateur à mieux dépenser son argent, et mieux l’investir.
A travers ces divers fonctionnalités, ces applications permettent de redonner du pouvoir d’achat, et de faire gagner du temps.
- Autonomie sur la gestion de ses comptes
- Transparence complète sur tous les frais (bien plus bas que les banques traditionnelles)
- Plateforme tout en un, quoi centralise gestion des comptes et investissement du patriomoine
Ce type de plateforme se revendique avant tout comme un outil tout en un. En quelques clics, l'utilisateur peut connecter l'ensemble de ses services bancaires, et avoir un aperçu global de ses dépenses. Cette capacité de centralisation permet de supprimer le travail chronophage et manuel de consulter ses comptes. D'un point de vue environnemental, ce type de plateforme permet de diminuer le nombre de connexion aux services tiers. Au lieu de se rendre quotidiennement sur 5 applications, Finary permet de visualiser les données souhaitez en un seul click.
Les services bancaires digitaux ont permi de numériser les factures, relevés de comptes, et autre paperasse, ce qui permet une réduction drastique de l'utilisation du papier. En creusant ce point, on peut identifier des avantages environnementaux comme la réduction de l'emprunte carbone de la livraison des lettres.
-
A noter qu'un effet rebond est possible sur l’utilisation excessive à cause de la facilité d’utilisation.
Nous avons identifié plusieurs acteurs qui évoluent dans le même secteur d’activité que Finary. Pour cela nous nous sommes basé sur nos connaissances et les autres applications que nous utilisons.
Nous avons dans un premier temps, dressé un tableau pour nous donner une idée des ressources utilisées par nos différents acteurs.
Sur navigateur (version web), nous avons utilisé l’outil destiné au développeurs “inspect”, qui nous permet de consulter divers types de données. Les éléments qui nous ont semblé être pertinent sont le nombre de requete, le transfert réseau en MB, et les ressources chargées en MB. Nous n'avons donc pas évalué les applications mais bien les versions web de ces services.
| Service | URL | Requêtes | Transfert réseau | Ressources chargées |
|---|---|---|---|---|
| Finary | https://finary.com/fr | 70 | 2.1 MB | 5.9 MB |
| Bankin | https://bankin.com/ | 35 | 1.7 MB | 3.3 MB |
| Linxo | https://linxo.com/ | 42 | 1.8 MB | 7.2 MB |
| Revolut | https://www.revolut.com/fr-FR/ | 95 | 46,2 MB | 49 MB |
Nous allons prendre l’exemple d’un utilisateur quotidien, qui consulte ses investissements et ses comptes plusieurs fois par jours. Nous pouvons estimer qu’il consulte au moins 5 fois par jour la web app, le matin, le midi et plusieurs fois le soir.
Nous verrons donc avec 2 cas d’utilisation:
- La consultation des informations
- L’investissement de son patrimoine (moins quotidien en fonction du type d’utilisateur)
- Il consulte la courbe sur la page d’accueil.
- Il consulte le détail d’un compte (dépenses / revenus)
- Il consulte le détail d'une donnée
- Il retourne sur la page d’accueil
- L’utilisateur charge la page d’accueil
- Il se rend dans la rubrique communauté.
- Il consulte le sommaire des articles les plus récents.
- Il clique sur l’un des articles pour le consulter.
- Il lit l’ensemble de l’article.
- Il retourne sur la rubrique des articles.
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 de notre scénario principal (consultation des comptes) sur les services concurrents de Finary que nous avons identifiés, et réferencés dans la partie “Identification des concurrents”.
| Service | Score (sur 100) | Classe |
|---|---|---|
| Finary | 86 | A 🟩 |
| Bankin | 85 | A 🟩 |
| Linxo | 85 | A 🟩 |
| Revolut | 78 | B 🟩 |
Bankin fonctionne principalement sur un modèle freemium combiné à des services B2B et des partenariats
- L’application de base permet de regrouper tous ses comptes bancaires en un seul espace, gratuitement, pour le grand public
- Un abonnement Premium propose des fonctionnalités avancées comme un meilleur suivi des dépenses, des notifications enrichies et la possibilité de créer des catégories personnalisées
- Bankin propose également des produits et services pour les entreprises (B2B) : par exemple des solutions d’agrégation bancaire et d’enrichissement de données à destination de fintechs, banques, ou assureurs souhaitant intégrer des fonctionnalités de pilotage de comptes pour leurs propres clients
- Des revenus sont générés via des partenariats (ex. cashback, offre de produits financiers partenaires via l’app, etc.)
- Enfin, la société monétise l’accès à des APIs et des solutions Data pour l’analyse de transaction et la catégorisation, proposées en marque blanche
Linxo combine le modèle freemium, les services premium, les partenariats financiers et une offre B2B avec sa filiale Linxo Connect
- L’app gratuite permet d’agréger des comptes et d’obtenir un suivi budgétaire de base, tandis que l’offre Premium apporte la catégorisation personnalisée, la recherche avancée et la prévision du solde
- Linxo génère des revenus additionnels via l’aide à l’épargne, l’exécution de virements bancaires intégrés, et la recommandation de produits financiers partenaires (crédits, assurances, etc.)
- Une part importante du business model est l’offre Linxo Connect qui propose une API d’agrégation bancaire et d’initiation de paiement sous licence de l’ACPR. Cette offre vise les banques, fintechs, experts-comptables et institutionnels qui souhaitent intégrer l’agrégation ou le paiement open banking dans leurs solutions (revenus B2B par abonnement ou usage)
- Linxo bénéficie du soutien d’un grand groupe bancaire français et s’appuie sur la certification ISO 27001 pour rassurer partenaires et clients sur la sécurité
Revolut est une néobanque au business model multi-leviers, à la fois B2C et B2B.
- L’application propose un compte courant gratuit avec IBAN, carte bancaire, transferts, change multi-devises, suivi de budget et analytics.
- Plusieurs formules d’abonnements Premium/Metal (paiement mensuel) donnent accès à des avantages (assurances, plafonds étendus, opérations gratuites, cashback, trading…)
- Les revenus sont aussi générés via les frais d’utilisation (ex : retraits au-delà des plafonds), commissions sur change, investissement et trading (actions, cryptos), cashback sur achats, ventes de services d’assurance, etc.
- Sur le segment B2B, Revolut propose Revolut Business, une solution payante de gestion de comptes professionnels et d’outils pour PME, incluant facturation, cartes d’équipes, paiements internationaux, API, etc.
- Revolut monétise aussi la distribution de produits partenaires financiers au sein de l’app (prêts, assurances, crypto), prenant une commission sur la souscription et l’utilisation
| Entreprise | Modèle principal | Modèles complémentaires | B2B/Partenariats |
|---|---|---|---|
| Bankin | Freemium grand public | Premium, cashback, Data/API | Oui (agrégation, data, API, marque blanche) |
| Linxo | Freemium + Premium | Reco produits, virements intégrés | Oui (Linxo Connect API agrégation, paiement) |
| Revolut | Compte bancaire + abonnement | Commissions, trading, cashback | Oui (Revolut Business, produits partenaires) |
Voici un tableau plus précis sur les divers utilisation des services en fonction des status:
| Service | Visiteur anonyme | Abonné (Premium/Payant) |
|---|---|---|
| Bankin | Consultation de comptes agrégés de base - Vue globale des soldes - Catégorisation automatique standard | Catégorisation personnalisée - Recherche avancée de transactions - Suivi budgétaire avancé - Export de données - Alertes personnalisées - Accès prioritaire au support |
| Linxo | Agrégation multi-comptes bancaire - Visualisation budgétaire simple - Prévision de solde standard - Catégorisation automatique de base | Création de ses propres catégories - Prévisions de solde détaillées - Recherche par montant/date/catégorie illimitée - Suivi précis de l’épargne et des investissements - Virements bancaires directement via l’appli - Support et assistance prioritaire |
| Revolut | Compte bancaire gratuit (IBAN) - Carte virtuelle et physique standard - Paiements et transferts de base - Change multi-devises à tarif standard | Cartes haut de gamme - Plafonds de retrait supérieurs - Assurances premium (voyage, achat, etc.) - Accès à l’investissement (cryptos/actions) sans frais ou à frais réduits - Cashback sur achats - Support prioritaire |
Comme nos concurrents fonctionnent tous sur un model freemium, nous pensons resté sur ce même modèle pour ne pas perdre l’utilisateur.
Bankin propose ses services à 3.33€ / mois, Finary 12€ /mois, Linxo 4€/mois et Revolut 10€/mois.
Nous avons remarqué que tous ces concurrents proposent un large panel de fonctionnalité pour assurer leur rentabilité. Leur offre devient donc beaucoup plus large et parfois moins claire.
Or nous voulons principalement nous concentrer sur la gestion des dépenses, sans ajouter une multitude de produit dans le produit. Nous pensons donc pouvoir nous différencier par la simplicité et le cout plus réduit que nous pouvons proposer, proposer un abonnement à 2.99€.
Il nous faudrait donc 1190 abonnés pour pouvoir verser un salaire.
En nous basant sur le cout salaire median, qui s’élève à 3569€ selon l’URSAF.
Les 2 fonctionnalités sur lesquelles nous allons nous concentrer sont:
- Référencement simple des dépenses
- Identification des doublons & économie possibles, via des conseils donnés aux utilisateurs
Les autres business model, dons, publicité ne nous paraissent absolument pas viable pour notre projet, étant donné que tous nos concurrents proposent déjà ces services à des prix très accéssibles, sans publicité, qui appauvri l’experience utilisateur.
Nous sommes bien conscient que cet objectif peut être compliqué à atteindre.
Nous avons cependant pensé à plusieurs stratégies pour toucher notre marché de Niche:
- Publication de contenu sur les réseaux pour créer une communauté
- Système de parrainage
- Subvention de l’état: Nous pensons que la littératie financière de la population peut être favorable à l’état.
Après avoir défini les différents scénarios d’utilisation , et surtout les fonctionnalités techniques que nous voulons implementer dans notre application, nous avons determiné les ressources web qui seront disponibles:
le ”/” sera le tableau de bord de l’utilisateur, sur lequel il peut voir l’argent qui lui reste, et un rapide aperçu de ses dépenses et revenus.
Nous aurons ensuite les deux ressources: “/income” et “/outcome”, qui afficheront de manière plus détaillées, à l’aide de graphique, les dépenses les revenues, les catégories, les doublons, et une évolution au cours du temps. L’utilisateur pourra aussi ajouter, modifier ou supprimer ces variables.
Maquette du prototype
Fig.1: type de page pour la visualisation du compte / dashboard
Fig.2 : type de page détaillant chanque entité (Income & Outcome)
Dans une démarche plus écoresponsable, les dépenses et revenus sont pour l'instant limités à ceux du du mois courant (entre 30 et 40).
Pour éviter tout problème liés aux droits d'auteurs, nous utilisons des données générées via dummy-json. Ces données correspondent à la structure de nos principaux concurrents : chaque dépense et chaque revenu comportent une catégorie, un montant, une description de taille libre, une date, et un utilisateur associé. Chaque utilisateur dispose alors de deux listes associées, la liste des dépenses et la liste des revenus.
Cette première version qui a été developpée est très simplifiée, et permet simplement d’accéder à des informations de “bases”, que nous estimions les plus importantes pour notre application. Nous avons nommé cette version: v1.0.0
Celle-ci est caracterisée par:
- 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 ("Consultation de ses comptes et ses investissements").
Page d’accueil
Figure 3: Page d’accueil
Pour rappel notre scénario principal était le suivant:
Scénario : "Consultation de ses comptes"
- Il consulte la courbe sur la page d’accueil.
- Il consulte le détail d’un compte (dépenses / revenus)
- Il consulte le détail d'une donnée
- Il retourne sur la page d’accueil
Comme nous nous concentrons plus sur la gestion du patrimoine et non l’investissement, nos pages et le types de ressources restent similaires.
Sur notre page d’accueil l’utilisateur peut consulter les courbes de ces entrées et sorties d’argent. Il peut filtrer de manière temporelle, et peut consulter le détail de toutes ses dépenses et toutes ses entrées d’argent.
Nous pouvons donc réaliser le scénario de manière complétement similaires à nos sites concurrents.
Pour comprendre de manière visuelle les étapes du scénario, nous avons dans la figure 3 la page d’accueil qui affiche les graphiques, avec un filtre qui nous permet de choisir la chronologie des informations à afficher.
Dans un second temps, nous avons les “incomes” et “outcomes”.
Figure 4: Income et outcome
On peut ensuite cliquer sur “view all”.
Puis on peut consulter les détails précis d’une action:
Dans cette première version, nous avons essayé d’être les plus minimalistes possible en terme d’interface, mais nous étions néanmoins obligé d’utiliser des librairies pour afficher les données sous forme de graphiques et tableaux. Nous avons choisie d'utiliser la librairie Chart.js car elle est reconnue comme l'une des plus légère pour la visualisation de données.
Maintenant nous pouvons commencer les mesures.
Tout d’abord sur notre page d’accueil:
| EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (ko) |
|---|---|---|---|---|
| Mode "développement" | 80 A 🟦 | 58 | 29 | 2240 |
| Mode "pré-production" | 93 A 🟦 | 57 | 4 | 160 |
Au départ, nous avions développé notre web app en utilisant un hashRouter, qui permet de faire du rendu par fragment.
Seulement, lorsque nous voulions faire les mesures avec le logiciel ecoIndex App, l’outil ne reconnaissait pas le changement des pages.
Nous avons donc opté pour un router traditionnel.
Après ces modifications, nous avons pu facilement mesuré les données demandées:
| Page | Grade | Ecoindex | Eau (cl) | GES (gCO2e) | Nb de requêtes | Taille de la page (Ko) | Taille du DOM |
|---|---|---|---|---|---|---|---|
| http://localhost:4173/ | A | 93/100 | 17.10 | 1.14 | 4 | 161.120 | 57 |
| http://localhost:4173/incomes | A | 85/100 | 19.60 | 1.30 | 4 | 1.205 | 300 |
| http://localhost:4173/9 | A | 97/100 | 15.90 | 1.06 | 4 | 1.205 | 5 |
| http://localhost:4173/bis | A | 97/100 | 15.90 | 1.06 | 4 | 1.205 | 5 |
Nous précisions que ces mesures concernent les chargement des pages avec des données statiques. Ces résultats sont particulièrement bon car nous n'avons que très peu de texte affiché à l'écran.
Nous avons réalisé l’automatisation des tests, qui créent un rapport html à chaque fois que nous pushons du code sur notre repository.
Nous pouvons maintenant simuler des données des mesures qui collent beaucoup plus à la réalité.
Comme précisé précedemment, nous avons peu de données textuelle à afficher, ce qui explique pourquoi nous obtenons de très bon résultats. De plus nous avons “peu” de données. En effet, pour chaque utilisateur, nous avons entre 5 et 10 dépenses referencées par utilisateurs. Nous allons donc augmenter par 10 le nombre de dépenses par utilisateurs, puisque ce sont ces données qui sont vouées à s’accumuler au cours du temps. Avec ce nouveau mutiplicateur, chaque utlilisateur aura entre 50 et 100 données.
Évolution de l'EcoIndex lors du passage à l'échelle
Voici un tableau qui représente le passage à l’échelle, permettant de comparer les données entre 5 - 10 données par utilsateurs, à 50 - 100.
| Page | Ecoindex | GES (gCO2e) | Taille du DOM | Nb de requêtes | Taille de la page (Ko) |
|---|---|---|---|---|---|
| http://localhost:4173/ | 83 A 🟩 |
1.34 |
87 |
6 |
681.713 |
| http://localhost:4173/incomes | 47 D 🟨 |
2.06 |
2943 |
6 |
10 819.901 |
| http://localhost:4173/9 | 87 A 🟩 |
1.26 |
20 |
5 |
679.973 |
| http://localhost:4173/bis | 87 A 🟩 |
1.26 |
87 |
1 |
144.781 |
Tab.6: Effet du passage à l'échelle sur l'impact du scénario "Consultation de ses comptes" dans le prototype v1.0.1.
Les données sont cohérentes, nous perdons en efficacité. La page qui se dégrade le plus est la page “income”, ce qui est logique puisque c’est celle dans laquelle nous affichons toutes les données textuelles des transactions de l’utillisateur dans un tableau. Pour pallier à ce problème, nous pourrons charger qu’un nombre restreint de données au début du chargement, puis ajouter un bouton “voir plus” pour charger des données plus vieilles.
Pour simuler le fetch des données, nous avons utilisé la librarie fetch, et modifié l’emplacement de notre fichier “data.json” dans le dossier public.
Nous avons donc du adapter le code, pour réellement pouvoir le rendre dynamique. Cette version est donc la v1.0.1.
Le logiciel GreenFrame permet 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).
| cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) | |
|---|---|---|---|---|---|---|
| Navigateur | 0.0063 | 0.000060 | 0.0 | 0.0032 | 0.068 | 0.078 |
| Serveur Web | 0.0000050 | 0.0000029 | 0.0 | 0.0030 | 0.0 | 0.0030 |
Estimation de l’empreinte carbone : 35.828 mg eq. CO₂ ± 0,9 % (81.059 mWh)
| cpu (Wh) | mem (Wh) | disk (Wh) | network (Wh) | screen (Wh) | total (Wh) | |
|---|---|---|---|---|---|---|
| Navigateur | 0.0066 | 0.000059 | 0.0 | 0.0032 | 0.071 | 0.081 |
| Serveur Web | 0.0000047 | 0.0000030 | 0.0 | 0.0030 | 0.0 | 0.0030 |
Estimation de l’empreinte carbone : 36.981 mg eq. CO₂ ± 1,9 % (83.669 mWh)
Par rapport à ce que pouvait laisser penser l’EcoIndex, les résultats indiquent que :
- La consommation réseau (serveur et client) et l’écran du navigateur sont les principaux contributeurs à la consommation énergétique totale.
- L’affichage des graphiques et des détails en lui-même a un impact négligeable sur le CPU, la mémoire et le disque.
- L’impact indirect de l’affichage se manifeste via le temps d’éclairage de l’écran, qui reste le facteur dominant côté client.
Ainsi, les trois éléments ayant le plus d’impact sont :
- Écran du navigateur
- Réseau côté client
- Réseau côté serveur
Le reste des composants (CPU, mémoire, disque) contribue très peu à la consommation énergétique totale.
Consommation cumulée pour les deux scénarios : 72.81 mg eq. CO₂ ± 1,9 % (164.728 mWh)
Dans l'étape précédente nous avons introduis l'utilisation de couch db, qui nous permet de rendre ce service beaucoup plus réaliste. Nous avons fait le choix dans un premier temps de ne plus prendre en compte les utilisateurs. En effet, nous avions dans notre fichier data.json, un object users et un objet expense. Daans cet objet l'id de l'utilisateur est renseigné, ansi que sa date d'occurence, le montant qui peut être négatif ou positif. Dans notre base de données sur couch db, nous avons désormais uniquement les expenses, et nous partons du principe que l'utilisateur est celui ayant l'id n°10. Pour rendre encore plus réaliste les données, nous avons également augmenté le nombre d'expense, passant de 1000 à 5000. Nous avons donc sur couchdb. Nous avons nommé notre base de données "finary". Voici un exemple de document dans cette base de données:
{ "_id": "64b9ae1d85b558f9ff6f977634004c20", "_rev": "1-2dca812452f0f1b3a9095465a4b006f1", "id": "0", "user_id": "10", "created_at": "2024-07-20 15:32", "amount": 1000, "category": "Entertainment" }
Comme nous avions pu le voir précédememnt, les pages qui est la plus à même d'être optimisé sont les pages dépenses et revenues, puisque nous affichons dedans toutes les données de l'utilisateur de manière textuelle dans un tableau, contrairement à la page d'accueil qui affiche des graphiques (ce pourquoi nous observons l'utilisation un peu plus elevé du CPU).
Nous allons donc travailler sur l'optimisation des pages revenues et dépenses. Nous allons suivre les même pratique que tous les sites reconnus, à savoir charger uniquement les données que l'utilisateur a besoin de voir. Il faudra donc faire des requêtes spécifiques en utilisant mango, pour fetch un maximum de 30 dépenses (limite arbitraire) lors du premier chargement. Un bouton "voir plus" sera intégré et permettera de charger 30 élements supplémentaires.
Grâce à cette stratégie de pagination, nous ne chargeons plus toutes les données d'un coup mais seulement une partie (30 éléments initialement). L'utilisateur peut ensuite charger davantage de données via le bouton "voir plus" s'il le souhaite. Cela nous permet d'obtenir des gains significatifs en termes d'EcoIndex :
| Étape | EcoIndex | Eau (cl) | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (Ko) |
|---|---|---|---|---|---|---|
| Chargement de la page - http://localhost/ | 74 B | 2.28 | 1.52 | 88 | 7 | 3809.333 |
| Go to incomes page - http://localhost/incomes | 83 A | 2.01 | 1.34 | 113 | 6 | 543.738 |
| Open first income detail - http://localhost/detail/3982 | 88 A | 1.86 | 1.24 | 20 | 6 | 538.748 |
| Return to dashboard - http://localhost/ | 75 B | 2.25 | 1.5 | 88 | 2 | 3270.055 |
On observe notamment une amélioration significative sur la page /incomes qui passe d'un score de 47 D à 83 A, avec une réduction drastique de la taille du DOM (de 2943 à 113 éléments) et de la taille de la page (de 10 819 Ko à 543 Ko).
Suite à l'implémentation de la stratégie de pagination, nous avons effectué de nouvelles mesures avec GreenFrame pour quantifier l'impact de ces optimisations sur la consommation énergétique réelle.
MEASUREMENTS
┌────────────────────────────┬────────────┬────────────┬───────────────┬───────────┬──────────┬─────────────┐
│ (index) │ cpu (s) │ screen (s) │ totalTime (s) │ mem (B) │ disk (B) │ network (B) │
├────────────────────────────┼────────────┼────────────┼───────────────┼───────────┼──────────┼─────────────┤
│ greenframe-runner │ '0.956' │ '18.4' │ '19.7' │ '1.80e+8' │ '0.00' │ '4.44e+6' │
│ finary-20-static_hosting-1 │ '0.000286' │ '0.00' │ '19.4' │ '5.49e+6' │ '0.00' │ '5.89e+5' │
└────────────────────────────┴────────────┴────────────┴───────────────┴───────────┴──────────┴─────────────┘
ESTIMATES
┌────────────────────────────┬─────────────┬─────────────┬───────────┬──────────────┬─────────────┬────────────┐
│ (index) │ cpu (Wh) │ mem (Wh) │ disk (Wh) │ network (Wh) │ screen (Wh) │ total (Wh) │
├────────────────────────────┼─────────────┼─────────────┼───────────┼──────────────┼─────────────┼────────────┤
│ greenframe-runner │ '0.012' │ '0.000072' │ '0.0' │ '0.023' │ '0.072' │ '0.11' │
│ finary-20-static_hosting-1 │ '0.0000050' │ '0.0000030' │ '0.0' │ '0.0030' │ '0.0' │ '0.0030' │
└────────────────────────────┴─────────────┴─────────────┴───────────┴──────────────┴─────────────┴────────────┘
Estimation de l'empreinte carbone : 48.404 mg eq. CO₂ ± 0,6 % (109.512 mWh)
MEASUREMENTS
┌────────────────────────────┬────────────┬────────────┬───────────────┬───────────┬──────────┬─────────────┐
│ (index) │ cpu (s) │ screen (s) │ totalTime (s) │ mem (B) │ disk (B) │ network (B) │
├────────────────────────────┼────────────┼────────────┼───────────────┼───────────┼──────────┼─────────────┤
│ greenframe-runner │ '0.375' │ '17.5' │ '18.7' │ '1.46e+8' │ '0.00' │ '5.97e+5' │
│ finary-20-static_hosting-1 │ '0.000254' │ '0.00' │ '18.4' │ '5.51e+6' │ '0.00' │ '5.88e+5' │
└────────────────────────────┴────────────┴────────────┴───────────────┴───────────┴──────────┴─────────────┘
ESTIMATES
┌────────────────────────────┬─────────────┬─────────────┬───────────┬──────────────┬─────────────┬────────────┐
│ (index) │ cpu (Wh) │ mem (Wh) │ disk (Wh) │ network (Wh) │ screen (Wh) │ total (Wh) │
├────────────────────────────┼─────────────┼─────────────┼───────────┼──────────────┼─────────────┼────────────┤
│ greenframe-runner │ '0.0047' │ '0.000055' │ '0.0' │ '0.0031' │ '0.068' │ '0.076' │
│ finary-20-static_hosting-1 │ '0.0000045' │ '0.0000029' │ '0.0' │ '0.0030' │ '0.0' │ '0.0030' │
└────────────────────────────┴─────────────┴─────────────┴───────────┴──────────────┴─────────────┴────────────┘
Estimation de l'empreinte carbone : 34.781 mg eq. CO₂ ± 0,8 % (78.689 mWh)
Consommation cumulée après optimisation : 83.185 mg eq. CO₂ ± 0,8 % (188.202 mWh)
En comparant les résultats avant et après optimisation, nous observons des améliorations significatives :
Avant optimisation (données complètes chargées) :
- Consommation cumulée : 72.81 mg eq. CO₂ (164.728 mWh)
- Taille du DOM (page incomes) : 2943 éléments
- Taille de la page (page incomes) : 10 819 Ko
Après optimisation (pagination avec 30 éléments) :
- Consommation cumulée : 83.185 mg eq. CO₂ (188.202 mWh)
- Taille du DOM (page incomes) : 113 éléments
- Taille de la page (page incomes) : 543 Ko
Explication des changements :
Bien que la consommation énergétique totale soit légèrement supérieure après optimisation (+14%), cela s'explique par l'ajout de fonctionnalités supplémentaires (base de données CouchDB, interactions plus complexes) et l'augmentation du volume de données disponibles (passage de 1000 à 5000 transactions).
Les gains réels se manifestent principalement dans :
-
Réduction drastique de la charge initiale : La taille du DOM passe de 2943 à 113 éléments (-96%), ce qui améliore considérablement le temps de chargement initial et la réactivité de l'interface.
-
Optimisation du transfert réseau : La taille de la page incomes diminue de 10 819 Ko à 543 Ko (-95%), réduisant significativement la bande passante consommée lors du premier chargement.
-
Amélioration de l'EcoIndex : La page
/incomespasse d'un score de 47 D à 83 A, démontrant une meilleure efficacité environnementale globale. -
Scalabilité améliorée : Avec la pagination, l'impact environnemental reste stable même si le nombre total de transactions augmente, contrairement à l'approche initiale où tout était chargé d'un coup.
Cette stratégie de pagination permet donc de découpler la consommation énergétique du volume total de données, garantissant une expérience utilisateur fluide et écoresponsable, même avec une base de données en croissance continue.
Pour implémenter cette pagination efficace, nous utilisons une approche basée sur l'ordre temporel des transactions. La logique est implémentée dans le composant incomes.jsx :
-
Premier chargement : Nous récupérons les 30 transactions les plus récentes en triant par date décroissante (
created_at: "desc"). -
Suivi de la dernière date : La variable
lastDateIndexstocke la date de la dernière transaction chargée :setLastDateIndex(docs[docs.length - 1].created_at);
-
Chargement suivant : Lorsque l'utilisateur clique sur "Voir plus", nous effectuons une nouvelle requête qui récupère les 30 transactions suivantes dont la date est strictement inférieure à
lastDateIndex:selector: { _id: { $gt: null }, user_id: "10", created_at: { $lt: lastDateIndex } // Récupère les transactions plus anciennes }, sort: [{ created_at: "desc" }], limit: 30
-
Fusion des données : Les nouvelles données sont ajoutées aux données existantes pour maintenir l'historique complet :
setData({ expenses: [...data.expenses, ...docs] });
Cette approche garantit que nous chargeons toujours les données dans l'ordre chronologique inverse (du plus récent au plus ancien) sans doublons, tout en minimisant la charge initiale sur le navigateur et le réseau.
- A l'aide d'un bouton add sur la page income et outcome on accède à une fenêtre pour créer une nouvelle donnée
- Une nouvelle rubrique implémenter sur la page outcome permettant de voir les dépenses les plus fréquentes et les économies possibles
Fonctionnalité 3 : Filtre détaillé (catégorie, montant, mois) pour trier l'affichage des dépenses et revenus
- Ajout d'un filtre sur la page income et sur la page outcome, permettant de trier les lignes affichées en fonction de plusieurs paramètres : catégorie, montant et date (mois)
Nous avons mesuré deux nouvelles fonctionnalités (le filtre n'ayant aucun impact) sur la page des dépenses (outcomes) :
- Ajout manuel de dépenses : Permet à l'utilisateur d'ajouter une nouvelle dépense via un formulaire
- Dashboard d'économies potentielles : Affiche les 3 catégories de dépenses les plus fréquentes et calcule les économies possibles
MEASUREMENTS
┌────────────────────────────┬────────────┬────────────┬───────────────┬───────────┬──────────┬─────────────┐
│ (index) │ cpu (s) │ screen (s) │ totalTime (s) │ mem (B) │ disk (B) │ network (B) │
├────────────────────────────┼────────────┼────────────┼───────────────┼───────────┼──────────┼─────────────┤
│ greenframe-runner │ '0.458' │ '17.8' │ '19.1' │ '1.50e+8' │ '0.00' │ '6.07e+5' │
│ finary-20-static_hosting-1 │ '0.000255' │ '0.00' │ '18.7' │ '5.57e+6' │ '0.00' │ '5.99e+5' │
└────────────────────────────┴────────────┴────────────┴───────────────┴───────────┴──────────┴─────────────┘
ESTIMATES
┌────────────────────────────┬─────────────┬─────────────┬───────────┬──────────────┬─────────────┬────────────┐
│ (index) │ cpu (Wh) │ mem (Wh) │ disk (Wh) │ network (Wh) │ screen (Wh) │ total (Wh) │
├────────────────────────────┼─────────────┼─────────────┼───────────┼──────────────┼─────────────┼────────────┤
│ greenframe-runner │ '0.0057' │ '0.000058' │ '0.0' │ '0.0031' │ '0.069' │ '0.078' │
│ finary-20-static_hosting-1 │ '0.0000045' │ '0.0000030' │ '0.0' │ '0.0031' │ '0.0' │ '0.0031' │
└────────────────────────────┴─────────────┴─────────────┴───────────┴──────────────┴─────────────┴────────────┘
Estimation de l'empreinte carbone : 35.834 mg eq. CO₂ ± 0.4% (81.072 mWh)
| Étape | URL | EcoIndex | Eau (cl) | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (Ko) |
|---|---|---|---|---|---|---|---|
| Return to dashboard | http://localhost/ | 92 A | 1.74 | 1.16 | 17 | 2 | 0.443 |
| Go to outcomes page | http://localhost/outcomes | 80 A | 2.1 | 1.4 | 215 | 6 | |
| Open add expense dialog | - | 80 A | 2.1 | 1.4 | 215 | 6 | 557.67 |
| Fill expense amount | - | 80 A | 2.1 | 1.4 | 215 | 6 | 557.67 |
| Fill expense category | - | 80 A | 2.1 | 1.4 | 215 | 6 | 557.67 |
| Fill expense date | - | 80 A | 2.1 | 1.4 | 215 | 6 | 557.67 |
| Submit expense | - | 80 A | 2.1 | 1.4 | 215 | 7 | 557.67 |
| Scroll to savings dashboard | - | 79 A | 2.13 | 1.42 | 215 | 8 | 558.278 |
Impact minimal de l'ajout manuel de dépenses :
L'ajout manuel de dépenses n'a pratiquement aucun impact sur la consommation énergétique et l'EcoIndex. Cela s'explique par le fait que cette fonctionnalité envoie des données au serveur plutôt que d'en charger. Les observations clés sont :
-
Taille du DOM stable : Le DOM reste à 215 éléments pendant toute l'interaction avec le formulaire, car nous n'ajoutons que quelques champs de saisie légers (montant, catégorie, date).
-
Requêtes minimales : L'ouverture du dialog et le remplissage des champs ne génèrent aucune requête supplémentaire. Seule la soumission du formulaire envoie une requête POST au serveur (+1 requête passant de 6 à 7).
-
Transfert réseau négligeable : L'envoi d'une nouvelle dépense ne représente que quelques octets de données JSON (id, montant, catégorie, date, user_id), ce qui n'impacte pas significativement la taille de la page.
-
EcoIndex constant : Le score reste à 80 A tout au long du processus d'ajout, confirmant que cette fonctionnalité est très écoresponsable.
Impact du dashboard d'économies potentielles :
Le composant PotentialEconomy calcule et affiche les 3 catégories de dépenses les plus fréquentes côté client, sans requête supplémentaire. L'impact est donc minimal :
- Calcul côté client : L'algorithme d'identification des catégories fréquentes utilise les données déjà chargées, sans fetch additionnel.
- Affichage léger : Le composant n'affiche que 3 lignes de texte avec les catégories et les montants, ajoutant très peu d'éléments au DOM.
- Pas de requête réseau : Aucune requête supplémentaire n'est nécessaire pour cette fonctionnalité.
Comparaison avec la page Incomes :
| Métrique | Page Incomes (après optimisation) | Page Outcomes | Différence |
|---|---|---|---|
| EcoIndex | 83 A | 80 A | -3 points |
| Taille du DOM | 113 | 215 | +102 éléments |
| Taille de la page | 543.738 Ko | 557.67 Ko | +13.93 Ko |
| Requêtes | 6 | 6 | Identique |
La page Outcomes a un score légèrement inférieur (80 A vs 83 A) en raison du dashboard d'économies potentielles qui ajoute des éléments au DOM pour afficher les recommandations. Cependant, cette différence reste minime et le score reste dans la catégorie A.
Les nouvelles fonctionnalités sont très écoresponsables car elles :
- N'ajoutent pas de charge réseau significative
- Réutilisent les données déjà chargées pour les calculs
- Maintiennent un excellent EcoIndex (80 A)
- Et l'envoi de données est beaucoup moins coûteux que le chargement de grandes quantités de données
Cette approche démontre qu'il est possible d'ajouter des fonctionnalités utiles sans dégrader l'impact environnemental de l'application.
Nous faisons donc le choix de garder ces foncitonnalités au vue du faible impact qu'elles peuvent avoir. Le principal risque étant que les utilisateurs passent plus de temps sur notre application avec ces ajouts, ce qui engendrerai une plus consommation plus élevé de l'écran. Cependant notre application dans l'ensemble à un design qui favorise une utilisation succinte à une fréquence plus élevé (exemple : 3 * 2 min par jour). La visualisation des données avec nos graphiques va dans ce sens en facilitant une lecture rapide et globale des dépenses / revenus.
Au cours de ce projet, nous avons développé une application web de gestion de patrimoine en Vite.js qui se concentre sur deux fonctionnalités principales : le référencement simple des dépenses et l'identification des économies possibles.
Durant ce semestre, nous avons du réaliser une application web, qui réponde à une vraie problématique, à un modèle économique viable et une infrastructure technique sobre au niveau energetique.
Ce projet nous a permi d’acquerir de nouvelle connaissance sur le volet technique et de prendre conscience de plusieurs points sur le volet humain:
D’un point de vue technique, nous avions quelques bases en React et quelques connaissance de Github mais nous avons acquis durant ce projet un bon nombre de nouvelle connaissance:
Vite js & Pico :
C’était la première fois que nous utilisions le framework Vite js. Nous avions l’habitude de réaliser nos projets en Next JS. Le premier point qui nous a frappés fut la rapidité d’exécution de la web app en Vite, par rapport aux applications Next JS. Nous nous sommes également rendu compte que le code n’était pas significativement plus long à réaliser de notre côté pour les fonctionnalités basiques que nous avions l’ambition de réaliser. En ce qui concerne le CSS, nous avions l’habitude d’utiliser les frameworks Tailwind ou Bootstrap (vue en LO07), pico CSS a été une petite surprise pour nous, bien plus minimaliste, il n’en est pas moins intéressant pour réaliser des petits projets ne demandant pas énormément d’esthétique.
Ceci nous a fait prendre conscience de l’importance de bien choisir nos outils de développement en fonction de notre besoin, car chaque framework a une utilité spécifique et un impact environnemental plus ou moins fort.
Github CI/CD :
Même si nous en avions entendu parler, c’était la première fois que nous mettions vraiment en pratique un environnement CI/CD autour de notre projet avec GitHub Actions. Nous avons trouvé cette partie très intéressante, voir à quel point il est possible d’automatiser tout ou une partie de l’intégration de notre projet. Cependant ceci ne se fait pas sans effort, nous avons trouvé cela assez difficile à prendre en main car il est nécessaire de maitriser de nombreux outils avec lesquels nous n’étions pas forcément à l’aise (docker par exemple). Voir que les mesures d’impact environnementaux pouvaient aussi être automatisées montre bien l’éventail des possibilités possibles.
GreenFrame & EcoIndex :
C’est également la première fois que nous étions amenés à manipuler des outils pour mesurer l’impact énergétique des applications web. Nous avons trouvé qu’EcoIndex était assez simple d’utilisation avec son application bureau. D’un autre côté GreenFrame est un outil plus complet, mais avec lequel nous avons eu plus de mal, car il n’avait pas d’application similaire à celle d’EcoIndex. Dans tous les cas, nous avons pris conscience qu’il était assez simple d’évaluer l’impact environnemental d’un logiciel, que ce soit pendant le développement ou en production, et que cela pouvait vraiment nous aider à adopter une démarche plus écoresponsable.
D’un point de vue humain, cette démarche de construction d’un service web le plus vert possible, autour d’un modèle économique viable, nous a amenés à plusieurs réflexions.
Premièrement, nous avons pris conscience de toutes les mauvaises pratiques dont nous avons pris l’habitude en tant qu’utilisateurs et de l’ampleur de l’effet rebond.
Pour la majorité des services que nous utilisons, tout est pensé pour garder notre attention, favoriser la rétention et maximiser notre confort. Par exemple, des vidéos de très haute résolution ou encore de nombreuses fonctionnalités « gadgets », qui sont très coûteuses en énergie et qui s’éloignent du produit initial. J’ai pris personnellement conscience que j’écoutais de la musique sur YouTube, mais que je laissais la vidéo en haute résolution alors que je ne la regardais même pas.
L’effet rebond est particulièrement visible avec les services de vidéo. À notre adolescence, les systèmes de connexion n’étaient pas aussi performants, et les plateformes comme YouTube proposaient moins de contenus, avec des vidéos d’une qualité bien moins élevée qu’aujourd’hui. Avec l’avènement de la 5G et des appareils ultra-performants, YouTube, Instagram ou TikTok proposent des contenus avec une qualité vidéo incroyable et sans aucune friction. Sauf qu’au lieu de garder notre fréquence d’utilisation, nous regardons des vidéos en permanence.
Le second point que nous avons réalisé est le manque d’intérêt des grandes entreprises à mettre en place ces bonnes pratiques. Lorsque nous avons analysé les sites de nos concurrents, nous avons réalisé que l’aspect « green » d’un site n’est pas du tout leur axe principal de travail. De prime abord, nous avions eu une réflexion unilatérale, et nous ne comprenions pas pourquoi les applications ne s’efforçaient pas de réduire leur empreinte carbone et de proposer des services plus sobres énergétiquement (ce qui pourrait potentiellement leur faire faire des économies). Mais au fur et à mesure, nous avons pris conscience de la problématique principale de chaque application : le modèle économique et la rentabilité.
Il est, en effet, très compliqué d’allier sobriété énergétique et croissance des revenus. En revisitant les applications de nos concurrents, tout est pensé pour séduire l’utilisateur. Cela passe par un design très poussé et par des services sans aucune friction, sans une seconde d’attente. Cela implique l’utilisation de librairies complexes et coûteuses en énergie, mais qui permettent d’améliorer le taux d’utilisation et le sentiment que l’utilisateur achète un produit de qualité, ce qui, d’un point de vue économique, est bien plus rentable que la baisse de l'utilisation des ressources du site.
De manière complètement transparente, il nous semble impossible que la sobriété des applications soit une priorité au sein du modèle de développement actuel de ces entreprises.
Tout comme les autres secteurs gourmands en énergie, comme l’agriculture ou le transport, nous pensons que ceux qui peuvent minimiser ces impacts sont les institutions réglementaires (soumettre des normes strictes et claires) et les utilisateurs / consommateurs.
Pour améliorer l'application, nous pourrions d'abord implémenter un système d'authentification complet pour gérer plusieurs utilisateurs réels, et affiner l'algorithme de détection des doublons pour proposer des conseils plus personnalisés. À moyen terme, l'ajout d'un service worker permettrait un mode hors-ligne et réduirait les requêtes réseau. Enfin, pour passer à l'échelle, il faudrait tester l'application avec de vrais utilisateurs et envisager l'intégration aux API bancaires pour automatiser l'import des transactions, tout en veillant à ne pas augmenter excessivement l'empreinte environnementale.