Plateforme de vente et d'achat de vêtements d'occasion entre particuliers.
Dans notre quotidien, les plateformes d’achat et de revente d’articles de seconde main, comme Vinted, prennent une place importante. En tant qu'utilisatrices régulières de ces services pour acheter et revendre des vêtements et accessoires que nous n'utilisons plus, nous avons constaté qu’elles pouvaient avoir un impact environnemental conséquent malgré leur objectif de promouvoir la réutilisation. Cela est dû à la forte demande en infrastructure numérique et au nombre d'interactions qu'elles nécessitent.
L'essor des plateformes de seconde main s'inscrit dans une dynamique plus large d'économie circulaire. 73 % des Français ont déclaré avoir acheté un produit d'occasion au cours des 12 derniers mois (source : ENOV). Ces services jouent un rôle crucial dans la lutte contre la surconsommation et la réduction des déchets, mais leur impact écologique lié à leur utilisation numérique mérite d’être examiné pour optimiser leurs bénéfices.
Les services de vente et d'échange d'articles de seconde main jouent un rôle social essentiel en réduisant les déchets et en prolongeant la durée de vie des objets. En facilitant les échanges entre particuliers, ces plateformes luttent activement contre la culture du jetable et la surproduction, notamment dans des secteurs à fort impact environnemental comme la mode, où la fast fashion est régulièrement pointée du doigt.
Elles offrent une alternative à la consommation de produits neufs, plus durable et accessible, tout en permettant aux utilisateurs de générer un revenu complémentaire en revendant des articles qu'ils n'utilisent plus. Ces services sont également un levier d’inclusion économique, permettant à un large public d'acquérir des biens de qualité à prix réduits. En favorisant la réutilisation et l'échange, ils soutiennent la transition vers une économie circulaire, où les ressources sont mieux exploitées.
Enfin, ces plateformes renforcent les liens sociaux en créant des communautés d'utilisateurs partageant des centres d'intérêt communs, et en facilitant les échanges locaux, promouvant ainsi des pratiques de consommation plus collaboratives et solidaires.
La numérisation de la vente et de l’échange d’articles de seconde main a permis de démocratiser l'accès à ce type de services et de créer des communautés massives d'acheteurs et de vendeurs. Avant l’ère numérique, la revente d'articles se limitait à des pratiques locales comme les vide-greniers, les marchés de seconde main, ou encore les associations caritatives. Ces échanges restaient limités par les contraintes géographiques et le faible nombre d'acheteurs potentiels. Avec l'essor des plateformes numériques, les transactions se font désormais à grande échelle, ouvrant des possibilités accrues de trouver des acheteurs ou des vendeurs, mais avec un coût écologique amplifié par le trafic en ligne.
Bien que ça n’ait pas été l’objectif, un effet rebond s’est installé : l'échange facilité de biens qualitatifs à coûts dérisoires incite les utilisateurs à consommer plus que jamais. Du côté des vendeurs, il est probable que l'argent obtenu par la vente ne soit pas épargné, mais réinjecté dans des achats, qu’ils soient d'occasion ou neufs, ce qui compromet l'idée d'une véritable économie circulaire. Cette démesure s’illustre sur Vinted par la création de comptes “pro” d’utilisateurs qui capitalisent sur ce commerce (source : Le Parisien).
D’autre part, chaque interaction numérique, qu'il s'agisse de la consultation des annonces, de l'envoi de messages, ou de la gestion des paiements et expéditions, a un coût écologique. L'impact environnemental d'une annonce en ligne peut sembler négligeable au premier abord, mais lorsqu'on considère les millions d'utilisateurs actifs et les multiples images, descriptions et requêtes serveur générées, cela devient significatif. De plus, des mécanismes incitatifs (comme les notifications push et les algorithmes de recommandation) poussent les utilisateurs à passer plus de temps sur la plateforme, augmentant ainsi leur empreinte numérique.
Pour contrer l’effet rebond, Swapp s’efforcera de limiter la stimulation artificielle de l'achat impulsif par une conception éthique de l’interface et de l'expérience utilisateur. Nous viserons un modèle d'interactions responsable, évitant les notifications fréquentes et en réduisant l’encouragement à une consommation excessive, en privilégiant une approche minimaliste et durable.
Enfin, il est essentiel de rappeler que si les plateformes de seconde main ont révolutionné le marché de l'occasion en le rendant accessible, elles doivent aussi trouver un équilibre entre accessibilité et durabilité pour préserver leur impact écologique positif initial.
Nous faisons l'hypothèse que les utilisateurs visitent les plateformes de vente d'articles de seconde main lors de moments opportunistes, que ce soit pendant leurs pauses, dans les transports en commun ou à la maison. Ces visites peuvent être motivées par la recherche d'articles spécifiques, la découverte de bonnes affaires ou la consultation de nouveautés.
Ce scénario répond à l’un des besoins primaires d’un utilisateur qui découvre la plateforme. La présentation d’articles récents ou populaires lui permet d’explorer le catalogue facilement. Cela attire les nouveaux visiteurs et augmente leur engagement initial sans demander un investissement immédiat (comme une inscription), facilitant la découverte de la plateforme.
- L’utilisateur visite le site pour la première fois.
- Il explore une page présentant les articles récents ou mis en avant.
- Il navigue dans le catalogue d’articles, en déroulant ou en parcourant des sections thématiques.
Ce scénario illustre l’expérience utilisateur pour trouver un produit particulier. L’ajout d’un article au panier sans achat immédiat favorise une consommation réfléchie et limite l’impact écologique.
- L’utilisateur utilise une barre de recherche pour trouver un produit spécifique (é.g., “veste en cuir”).
- Il applique des filtres pertinents (prix minimum : 0, prix maximum : 50).
- Il examine les résultats filtrés et sélectionne une annonce pour voir ses détails.
- Il ajoute l’article au panier pour considération ultérieure.
Pour cette étude, nous avons mesuré l’impact environnemental des scénarios 1 et 2 à l’aide de GreenItAnalysis, car ils sont réalisables sans compte utilisateur.
| Scénario | ecolIndex | Part due aux actions | Eau (cl) | GES (gCO2e) | Bonnes pratiques à mettre en œuvre |
|---|---|---|---|---|---|
| Chargement de la page | G 🔴 | 58 | 4.5 | 3 | 9 |
| Cliquer sur la première suggestion | G 🔴 | 17 | 4.5 | 3 | 9 |
| Définir le prix minimum | D ⚪ | 0 | 3.09 | 2.06 | 5 |
| Définir le prix maximum | D ⚪ | 0 | 3.15 | 2.1 | 6 |
Tab1 : GreenIT-Analysis : Impact de Vinted obtenu automatiquement à partir d'un fichier .yml
| Bonne pratique | Effort | Impact | Priorité | Grade |
|---|---|---|---|---|
| Ajouter des expires ou cache-control headers (>= 95%) | 3 | 4 | 4 | ❌ |
| Compresser les ressources (>= 95%) | 9 | 9 | 9 | ✅ |
| Limiter le nombre de domaines (< 3) | 3 | 4 | 3 | ❌ |
| Ne pas retailler les images dans le navigateur | 4 | 4 | 4 | ❌ |
| Éviter les tags SRC vides | 9 | 9 | 9 | ✅ |
| Externaliser les CSS | 4 | 4 | 4 | ✅ |
| Externaliser les JS | 4 | 4 | 4 | ✅ |
| Éviter les requêtes en erreur | 9 | 9 | 9 | ❌ |
| Limiter le nombre de requêtes HTTP (< 27) | 3 | 4 | 4 | ❌ |
| Ne pas télécharger des images inutilement | 9 | 9 | 9 | ❌ |
| Valider le JavaScript | 3 | 3 | 3 | ❌ |
| Taille maximum des cookies par domaine (< 512 Octets) | 9 | 9 | 9 | ✅ |
| Minifier les CSS (>= 95%) | 3 | 4 | 4 | ✅ |
| Minifier les JS (>= 95%) | 3 | 4 | 4 | ✅ |
| Pas de cookie pour les ressources statiques | 9 | 9 | 9 | ✅ |
| Éviter les redirections | 3 | 3 | 3 | ❌ |
| Optimiser les images bitmap | 4 | 4 | 4 | ✅ |
| Optimiser les images SVG | 4 | 4 | 4 | ✅ |
| Ne pas utiliser de plugins | 9 | 9 | 9 | ❌ |
| Fournir une print CSS | 4 | 3 | 3 | ✅ |
| N'utilisez pas les boutons standards des réseaux sociaux | 4 | 4 | 4 | ✅ |
| Limiter le nombre de fichiers CSS (< 3) | 4 | 4 | 4 | ✅ |
| Utiliser des ETags (>= 95%) | 9 | 9 | 9 | ✅ |
| Utiliser des polices de caractères standards | 3 | 4 | 4 | ✅ |
Tab2 : GreenIT-Analysis : tableau des bonnes pratiques de Vinted obtenu automatiquement à partir d'un fichier .yml
| Date | Url | Nombre requêtes | Taille (kb) | Taille du DOM | GES | Eau | ecolIndex | Note | Description de la page mesurée |
|---|---|---|---|---|---|---|---|---|---|
| 10/01/2025 18:59 | https://www.vinted.fr/ | 139 | 5199 | 3010 | 2.76 | 4.15 | 11.75 | F 🟠 | Page d'accueil |
| 10/01/2025 19:00 | https://www.vinted.fr/ | 285 | 10778 | 9362 | 2.90 | 4.35 | 4.96 | G 🔴 | Page d'accueil après avoir scrollé (chargement de nouveaux articles et augmentation du nombre de requêtes) |
| 10/01/2025 19:01 | https://www.vinted.fr/catalog/4-clothing | 237 | 7298 | 10004 | 2.88 | 4.31 | 6.17 | G 🔴 | Page "Voir tout" de la catégorie "Femme" |
| 10/01/2025 19:01 | https://www.vinted.fr/catalog/2984-designer-b | 381 | 12614 | 6897 | 2.90 | 4.35 | 4.92 | G 🔴 | Page "Sacs de créateurs" de la catégorie "Articles de créateurs" |
Tab3 : GreenIT-Analysis Plugin : Impact de Vinted d'après le scénario 1 : consulter les articles sur la page de recherche
| Date | Url | Nombre requêtes | Taille (kb) | Taille du DOM | GES | Eau | ecolIndex | Note | Description de la page mesurée |
|---|---|---|---|---|---|---|---|---|---|
| 10/01/2025 19:14 | https://www.vinted.fr/ | 135 | 9374 | 3014 | 2.78 | 4.16 | 11.17 | F 🟠 | Page d'accueil |
| 10/01/2025 19:14 | https://www.vinted.fr/catalog?search_text=veste+en+cuir | 314 | 8772 | 10296 | 2.90 | 4.35 | 4.95 | G 🔴 | Page après recherche du terme "veste en cuir" |
| 10/01/2025 19:14 | https://www.vinted.fr/catalog?search_text=veste+en+cuir | 408 | 10353 | 10422 | 2.90 | 4.35 | 4.90 | G 🔴 | Page après avoir appliqué les filtres de prix |
| 10/01/2025 19:14 | https://www.vinted.fr/items/5626428632-grun | 71 | 2132 | 1079 | 2.27 | 3.41 | 36.44 | E 🟡 | Page de détails d'un article |
| 10/01/2025 19:15 | https://www.vinted.fr/items/5626428632-grun | 80 | 2230 | 1142 | 2.33 | 3.50 | 33.33 | E 🟡 | N'ayant pas de compte, la page après avoir cliqué "Acheter" correspond à la page d'inscription. |
Tab4 : GreenIT-Analysis Plugin : Impact de Vinted d'après le scénario 2 : rechercher des articles spécifiques et ajouter un article au panier
Nous avons d'abord tenté d'utiliser la version automatisée de GreenIT-Analysis avec un fichier .yml, mais nous avons rencontré plusieurs obstacles, notamment des problèmes liés aux captchas sur les sites analysés. Face à ces limitations, nous avons opté pour une approche manuelle à l'aide du plugin GreenIT-Analysis pour contourner ces problèmes et poursuivre l'étude.
| Date | Url | Nombre requêtes | Taille (kb) | Taille du DOM | GES | Eau | ecolIndex | Note | Description de la page mesurée |
|---|---|---|---|---|---|---|---|---|---|
| 10/01/2025 19:28 | https://www.depop.com/fr/?moduleOrigin=menu | 168 | 3121 | 816 | 2.46 | 3.69 | 27.17 | E 🟡 | Page d'accueil |
| 10/01/2025 19:28 | https://www.depop.com/fr/category/womens/dresses | 235 | 2491 | 1334 | 2.67 | 4.00 | 16.53 | F 🟠 | Page "Robes" de la catégorie "Vêtements pour femmes" |
| 10/01/2025 19:28 | https://www.depop.com/fr/category/womens/dresses | 712 | 6457 | 3966 | 2.89 | 4.34 | 5.30 | G 🔴 | Même page que la précédente mais après avoir scrollé (scroll infini) |
Tab5 : GreenIT-Analysis Plugin : Impact de Depop d'après le scénario 1 : consulter les articles sur la page de recherche
| Date | Url | Nombre requêtes | Taille (kb) | Taille du DOM | GES | Eau | ecolIndex | Note | Description de la page mesurée |
|---|---|---|---|---|---|---|---|---|---|
| 10/01/2025 19:35 | https://www.depop.com/fr/?moduleOrigin=menu | 173 | 2924 | 816 | 2.46 | 3.68 | 27.18 | E 🟡 | Page d'accueil |
| 10/01/2025 19:35 | https://www.depop.com/fr/?moduleOrigin=menu | 324 | 4297 | 1202 | 2.71 | 4.06 | 14.60 | F 🟠 | Page après recherche du terme "veste en cuir" |
| 10/01/2025 19:35 | https://www.depop.com/fr/?moduleOrigin=menu | 457 | 5154 | 1223 | 2.73 | 4.09 | 13.63 | F 🟠 | Page après avoir appliqué les filtres de prix |
| 10/01/2025 19:36 | https://www.depop.com/products/rosavalentina/ | 235 | 3375 | 1199 | 2.67 | 4.00 | 16.64 | F 🟠 | Page de détails d'un article |
| 10/01/2025 19:36 | https://www.depop.com/login?titleKey=Content | 139 | 1676 | 264 | 1.93 | 2.89 | 53.66 | D ⚪ | Page de création de compte. N'ayant pas de compte, la page après avoir cliqué "Acheter maintenant" correspond à cette page. |
Tab6 : GreenIT-Analysis Plugin : Impact de Depop d'après le scénario 2 : rechercher des articles spécifiques et ajouter un article au panier
Les analyses réalisées avec GreenAnalysis mettent en lumière des stratégies distinctes entre Vinted et Depop, ainsi que des impacts environnementaux notables. Vinted utilise un scroll automatique sur sa page d’accueil, ce qui engendre une augmentation modérée du nombre de requêtes et de la taille du DOM à mesure du chargement des contenus. Depop, quant à lui, adopte un scroll infini sur ses pages de recherche ou de catégories d’articles, ce qui provoque une forte hausse des requêtes, du poids des données et de la complexité du DOM, avec un impact environnemental plus marqué sur ces pages. Toutefois, Depop affiche généralement de meilleurs scores EcoIndex que Vinted, notamment sur ses pages d’accueil et de création de compte. Cela montre une meilleure optimisation des ressources pour certaines interactions simples.
Cependant, de manière générale, les deux plateformes affichent des performances environnementales préoccupantes, avec des EcoIndex souvent inférieurs à 20 et des notes faibles (F ou G pour la majorité des pages mesurées). Ces résultats soulignent l’importance d’optimiser davantage la gestion des DOM, de réduire les requêtes inutiles et de limiter la charge induite par les fonctionnalités dynamiques, telles que le scroll infini ou automatique.
Afin de limiter au maximum l'afflux de données inutile, nous avons choisi de mettre en place une page d'accueil sans scroll, dans laquelle il est possible de sélectionner une catégorie ou taper un élément spécifique dans le champ de saisie.
Fig1 : maquette de la page d'accueil
Cette même idée est poursuivie dans la page de recherche. Les items sont donc à minima triés par catégorie, afin de limiter les données à récupérer. Il est possible de pousser la recherche en lançant une recherche par une chaîne de caractères ou en précisant un état, une taille, une couleur, un prix, sa localisation.
Fig2 : maquette de la page de recherche
Le nombre d'images admis par item est de 4, à la taille maximale de 1Mo.
Fig3 : maquette de la page descriptive d'un élément
L'échantillon de données a été créé par dummy-json selon les attributs de catégorie, état, taille, couleur, prix et localisation évoqués préalablement.
Pour ce premier prototype, nous créons les composants nécessaires à notre grille de résultats, à partir de 3 éléments codés en dur dans notre fichier. Aucune recherche ou filtrage n'est fonctionnel.
Fig4 : Prototype 1 - Capture d'écran de la page d'accueil
| Navigateur GreenFrame | Hébergement statique Swapp | Total | |
|---|---|---|---|
| CPU | 1.4 mWh (2%) | 0 mWh (0%) | 1.4 mWh (1%) |
| Réseau | 20 mWh (22%) | 19 mWh (100%) | 40 mWh (36%) |
| Ecran | 68 mWh (76%) | 0 mWh (0%) | 68 mWh (62%) |
| Mémoire | 0.1 mWh (0%) | 0 mWh (0%) | 0.1 mWh (0%) |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) |
| Total énergie | 89.5 mWh | 19 mWh | 109 mWh |
| Total carbone | 40 mg eq. CO₂ | 0.8 mg eq. CO₂ | 48 mg eq. CO₂ |
Tab7 : résultats GreenFrame de la page d'accueil du prototype 1
Fig5 : Prototype 1 - Capture d'écran de la page de recherche
| Navigateur GreenFrame | Hébergement statique Swapp | Total | |
|---|---|---|---|
| CPU | 1 mWh (1%) | 0 mWh (0%) | 1 mWh (1%) |
| Réseau | 1.7 mWh (2%) | 1.1 mWh (2%) | 2.8 mWh (4%) |
| Ecran | 69 mWh (96%) | 0 mWh (0%) | 69 mWh (96%) |
| Mémoire | 0.1 mWh (0%) | 0 mWh (0%) | 0.1 mWh (0%) |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) |
| Total énergie | 71 mWh | 1.1 mWh | 72.1 mWh |
| Total carbone | 32 mg eq. CO₂ | 0.5 mg eq. CO₂ | 32.5 mg eq. CO₂ |
Tab8 : résultats GreenFrame de la page d'articles du prototype 1
Nous observons une différence notable d'énergie nécessaire au réseau entre la page d'accueil et la page de résultats. L'onglet réseau de l'inspecteur nous fait remarquer la taille considérable de l'image de fond au format PNG. Nous supposons que l'impact énergétique est principalement lié à la taille des éléments chargés via le réseau. Nous décidons alors de la changer pour utiliser le format SGV (car le SVG utilise des descriptions vectorielles basées sur le texte pour définir les formes et les couleurs, ce qui permet de réduire la taille du fichier, contrairement au PNG qui stocke chaque pixel individuellement, ce qui augmente la quantité de données nécessaires).
Fig6 : Prototype 1 - Capture d'écran de la page d'accueil et sa nouvelle image de fond
| Navigateur GreenFrame | Hébergement statique Swapp | Total | |
|---|---|---|---|
| CPU | 0.8 mWh (1%) | 0 mWh (0%) | 0.8 mWh (1%) |
| Réseau | 1.7 mWh (2%) | 1.1 mWh (2%) | 2.8 mWh (4%) |
| Ecran | 67 mWh (95%) | 0 mWh (0%) | 67 mWh (95%) |
| Mémoire | 0.1 mWh (0%) | 0 mWh (0%) | 0.1 mWh (0%) |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) |
| Total énergie | 70 mWh | 1.1 mWh | 71.1 mWh |
| Total carbone | 30 mg eq. CO₂ | 0.5 mg eq. CO₂ | 31 mg eq. CO₂ |
Tab9 : résultats GreenFrame de la page d'accueil du prototype 1 avec une nouvelle image de fond
La seule modification de l'image a effectivement permis une réduction de 98% de la dépense en énergie liée au réseau.
Pour ce deuxième prototype, nous mettons à jour dynamiquement la grille de résultats en fonction d'une chaîne de caractères de recherche, à partir de données statiques. Seule la barre de recherche est pour l'instant fonctionnelle.
Nous créons la logique de liste déroulante des filtres à partir de données statiques. Nous permettons la mise à jour des filtres à la fermeture des listes déroulantes. Ainsi, nous permettons une première fonctionnalité de filtrage côté client.
Fig7 : Prototype 2 - Capture d'écran de la page de recherche, liste déroulante ouverte
| Navigateur GreenFrame | Hébergement statique Swapp | Total | |
|---|---|---|---|
| CPU | 0.9 mWh (1%) | 0 mWh (0%) | 0.9 mWh (1%) |
| Réseau | 2 mWh (3%) | 1.4 mWh (100%) | 3.5 mWh (4%) |
| Ecran | 68 mWh (96%) | 0 mWh (0%) | 68 mWh (96%) |
| Mémoire | 0.1 mWh (0%) | 0 mWh (0%) | 0.1 mWh (0%) |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) |
| Total énergie | 71 mWh | 1.4 mWh | 72.4 mWh |
| Total carbone | 31 mg eq. CO₂ | 0.6 mg eq. CO₂ | 32.8 mg eq. CO₂ |
Tab10 : résultats GreenFrame de la page d'articles du prototype 2
La mise à jour dynamique des filtres a augmenté de 25% l'énergie liée au réseau. Les autres dépenses énergétiques restent inchangées.
Dans cette troisième version du prototype, les données sont désormais centralisées dans une base de données CouchDB, accessible via une API Web. L’adoption d’une telle solution offre plusieurs avantages : elle permet d’ajouter, de modifier et de gérer les articles de manière plus fluide, tout en offrant une plus grande flexibilité pour le filtrage et l’accès aux données.
Les bases de données présentent de nombreux avantages par rapport aux fichiers statiques. Elles permettent d'exécuter des requêtes complexes et dynamiques, offrant ainsi un accès plus précis et flexible aux données. De plus, elles optimisent la gestion de l'espace de stockage et les performances, en particulier lorsque les volumes de données sont importants. Enfin, les bases de données facilitent considérablement les modifications et les mises à jour, éliminant la nécessité de manipuler manuellement de grands fichiers, ce qui est souvent source d'erreurs.
Pour ce troisième prototype, nous permettons la recherche fonctionnelle depuis la barre de recherche, mais tout le filtrage reste codé côté client. Ainsi, l’intégralité des articles est toujours récupérée depuis la base de données. La véritable nouveauté ici réside dans leur gestion dynamique et leur accessibilité améliorée par le biais d’une base de données.
| Navigateur GreenFrame | Hébergement statique Swapp | Backend Swapp | Total | |
|---|---|---|---|---|
| CPU | 1 mWh (1%) | 0 mWh (0%) | 1.1 mWh (91%) | 2.1 mWh (3%) |
| Réseau | 2.1 mWh (3%) | 1.4 mWh (100%) | 0.1 mWh (6%) | 3.6 mWh (5%) |
| Écran | 68 mWh (96%) | 0 mWh (0%) | 0 mWh (0%) | 68 mWh (92%) |
| Mémoire | 0.1 mWh (0%) | 0 mWh (0%) | 0 mWh (3%) | 0.1 mWh (0%) |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) |
| Total énergie | 71 mWh | 1.4 mWh | 1.3 mWh | 73.7 mWh |
| Total carbone | 31 mg eq. CO₂ | 0.6 mg eq. CO₂ | 0.6 mg eq. CO₂ | 32.2 mg eq. CO₂ |
Tab11 : résultats GreenFrame de la page d'articles du prototype 3
Il n'y a pas de changement significatif au niveau des performances réseau, mais une augmentation de l'utilisation du CPU a été constatée. Cela s'explique par la création et le déploiement d'un backend, un composant naturellement plus demandant en ressources de calcul.
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 et les requêtes réalisées.
Un problème est relevé : puisque nous avons créé aléatoirement des titres d'articles et les valeurs des catégories, le filtrage, bien que fonctionnel, paraît douteux. En effet, un article pouvait jusqu'alors avoir un titre "Veste en cuir", une catégorie "Robe" et un description "Gilet tout doux". En sélectionnant la catégorie "Robe", obtenir un élément au titre de "Veste en cuir" laisse croire à une erreur de tri.
Par conséquent, nous avons modifié notre sample_data.hbs pour que les titres ne comprennent ni des valeurs possibles de catégorie, de couleur et de matière. Les descriptions sont toutes modifiées pour correspondre à un "lorem ipsum" de 100 mots.
Fig9 : Fichier sample_data.hbs utilisé pour la génération de données
Dans le cadre de notre service, la croissance des données est principalement liée à deux aspects : le volume des annonces et les médias associés (photos). L'évolution de ces données est directement liée à la croissance du nombre d'utilisateurs et au rythme de publication des annonces.
-
Nombre d'utilisateurs Chaque nouvel utilisateur inscrit est susceptible d'ajouter des annonces (texte, photos, descriptions) et d'effectuer des interactions (messages, transactions, évaluations, etc.). L'augmentation est non linéaire puisque le nombre de nouveaux utilisateurs peut croître rapidement grâce au bouche-à-oreille et aux campagnes de marketing.
-
Volume d'annonces
Chaque utilisateur peut publier plusieurs annonces et ces annonces restent dans la base de données (même après la vente ou l'expiration) pour des raisons de traçabilité et d'historique. La croissance est approximativement linéaire en fonction du nombre d'utilisateurs et de leur activité. -
Médias associés (photos)
Chaque annonce inclut plusieurs photos (généralement 3 à 5). Ces fichiers multimédias représentent la majeure partie de l'empreinte en stockage.
| Nombre d'articles | Composant | Navigateur GreenFrame | Hébergement statique Swapp | Backend Swapp | Total |
|---|---|---|---|---|---|
| 15 articles | CPU | 1 mWh (1%) | 0 mWh (0%) | 1,1 mWh (91%) | 2,1 mWh (3%) |
| Réseau | 2,1 mWh (3%) | 1,4 mWh (100%) | 0,1 mWh (6%) | 3,6 mWh (5%) | |
| Écran | 68 mWh (96%) | 0 mWh (0%) | 0 mWh (0%) | 68 mWh (92%) | |
| Mémoire | 0,1 mWh (0%) | 0 mWh (0%) | 0 mWh (3%) | 0,1 mWh (0%) | |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | |
| Total énergie | 71 mWh | 1,4 mWh | 1,3 mWh | 73,7 mWh | |
| Total carbone | 31 mg éq. CO₂ | 0,6 mg éq. CO₂ | 0,6 mg éq. CO₂ | 32,2 mg éq. CO₂ | |
| 3 000 articles | CPU | 2,8 mWh (3%) 📈 +180% | 0 mWh (0%) | 3,3 mWh (22%) 📈 +200% | 6,1 mWh (7%) 📈 +190% |
| 👉 Consulter la comparaison sur GreenFrame | Réseau | 14 mWh (16%) 📈 +567% | 1,4 mWh (100%) | 12 mWh (78%) 📈 +11,900% | 27,4 mWh (31%) 📈 +661% |
| Écran | 69 mWh (81%) 📈 +1.5% | 0 mWh (0%) | 0 mWh (0%) | 69 mWh (62%) 📈 +1.5% | |
| Mémoire | 0,1 mWh (0%) | 0 mWh (0%) | 0,1 mWh (0%) | 0,2 mWh (0%) 📈 +100% | |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | |
| Total énergie | 86 mWh 📈 +21% | 1,4 mWh | 15 mWh 📈 +1,054% | 102,4 mWh 📈 +39% | |
| Total carbone | 38 mg éq. CO₂ 📈 +23% | 0,6 mg éq. CO₂ | 6,8 mg éq. CO₂ 📈 +1,033% | 45,4 mg éq. CO₂ 📈 +41% | |
| 10 000 articles | CPU | 6,9 mWh (6%) 📈 +146% | 0 mWh (0%) | 8,2 mWh (17%) 📈 +148% | 15,1 mWh (9%) 📈 +148% |
| 👉 Consulter la comparaison sur GreenFrame | Réseau | 41 mWh (34%) 📈 +193% | 1,4 mWh (100%) | 39 mWh (83%) 📈 +225% | 81,4 mWh (48%) 📈 +197% |
| Écran | 73 mWh (60%) 📈 +6% | 0 mWh (0%) | 0 mWh (0%) | 73 mWh (43%) 📈 +6% | |
| Mémoire | 0,1 mWh (0%) | 0 mWh (0%) | 0,1 mWh (0%) | 0,2 mWh (0%) | |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | |
| Total énergie | 121 mWh 📈 +41% | 1,4 mWh | 48 mWh 📈 +220% | 170,4 mWh 📈 +66% | |
| Total carbone | 53 mg éq. CO₂ 📈 +39% | 0,6 mg éq. CO₂ | 21 mg éq. CO₂ 📈 +209% | 74,6 mg éq. CO₂ 📈 +64% |
Tab12 : tableau comparatif de la page d'articles du prototype 3 en changeant le nombre d'articles de 15 à 3 000 à 10 0000
L'augmentation de la consommation CPU est notable entre 10 articles et 10 000 articles, avec une hausse de 📈 +146% pour le Navigateur GreenFrame et de 📈 +148% pour le Backend Swapp. Cela s'explique par le fait que, avec un tri côté client, la charge de traitement est déplacée vers le navigateur, qui doit gérer un volume important de données. De son côté, le backend ne traite que les requêtes initiales, ce qui réduit son implication dans les opérations de tri ou de filtrage.
La consommation réseau montre une augmentation drastique, atteignant 📈 +193% pour le Navigateur GreenFrame, 📈 +225% pour le Backend Swapp et 📈 +197% pour le total réseau. Cela s'explique par le fait que l'ensemble des données est envoyé en une seule requête, quel que soit le nombre d'articles, augmentant la bande passante consommée. Le réseau devient ainsi un goulot d'étranglement potentiel, surtout pour des utilisateurs ayant une connexion instable ou limitée.
La consommation énergétique de l'écran reste stable avec une augmentation de 📈 +6% pour 10 000 articles. Cela indique que la visualisation des données n'est pas un facteur déterminant dans l'augmentation de l'énergie consommée, car les interfaces ne changent pas significativement en termes de complexité graphique.
La consommation mémoire reste négligeable, bien qu'elle double en passant de 10 à 3 000 articles. Cela peut devenir problématique pour des volumes encore plus importants de données, surtout sur des appareils avec des ressources limitées.
Pour limiter cette augmentation de l'impact de l'application, nous décidons de mettre en place un système de pagination et de trier côté serveur.
Comme expliqué plus haut, nous récupérions encore une quantité massive d'articles, triés côté client et entièrement affichés, ce qui augmente fortement l'impact lié à l'utilisation du processeur. Nous passons donc à un filtrage côté serveur, en conservant tous les types de filtrage précédemment définis côté client.
Trois modes d'accès aux articles sont actuellement disponibles :
- Recherche par titre : L'utilisateur effectue une recherche, et les résultats sont filtrés pour correspondre uniquement aux titres pertinents, limités à 25 articles ;
- navigation par catégorie : L'utilisateur sélectionne une catégorie spécifique et accède à une liste triée et restreinte à 25 articles maximum ;
- recherche dans une catégorie : En combinant les deux méthodes, l'utilisateur peut affiner davantage les résultats, qui restent plafonnés à 25 articles.
L'intégration d'une limite stricte à 25 articles maximum par affichage a été une décision centrale dans la conception de notre plateforme, en réponse aux enjeux d'optimisation des performances et de réduction de l'impact environnemental. Associée à l'obligation d'utiliser des filtres lors des recherches, cette approche garantit une expérience utilisateur ciblée et écoresponsable.
En cas de dépassement de la limite de 25 articles, nous permettons à l'utilisateur de cliquer sur un bouton pour charger 25 articles suivants. Nous évitons le système de scroll infini pour ne pas décourager l'utilsateur à charger davantage de contenu que le nécessaire.
| Navigateur GreenFrame | Hébergement statique Swapp | Backend Swapp | Total | |
|---|---|---|---|---|
| CPU | 1.1 mWh (2%) | 0 mWh (0%) | 1.3 mWh (93%) | 2.4 mWh (3%) |
| Réseau | 2 mWh (3%) | 1.4 mWh (100%) | 0 mWh (1%) | 3.4 mWh (5%) |
| Écran | 68 mWh (96%) | 0 mWh (0%) | 0 mWh (0%) | 68 mWh (92%) |
| Mémoire | 0.1 mWh (0%) | 0 mWh (0%) | 0.1 mWh (6%) | 0.2 mWh (0%) |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) |
| Total énergie | 71 mWh | 1.4 mWh | 1.4 mWh | 73.8 mWh |
| Total carbone | 31 mg eq. CO₂ | 0.6 mg eq. CO₂ | 0.6 mg eq. CO₂ | 32.2 mg eq. CO₂ |
Tab13 : résultats GreenFrame de la page d'articles du prototype 4 après ajustements
Les bénéfices de cette approche sont clairement mesurables. Avant l'implémentation de cette stratégie, notre page de résultats consommait en moyenne 75 mg par exécution, selon les données de GreenFrame. Après l'application de la limitation et des filtres obligatoires, nous avons atteint une consommation réduite à 32 mg par exécution, soit une réduction de plus de 57 %.
Cette optimisation démontre l'importance d'adopter une conception numérique responsable et sobre, non seulement pour minimiser l'impact environnemental mais également pour améliorer les performances globales du système. Notre démarche illustre comment des choix techniques simples, tels que la limitation des résultats ou l'application de filtres obligatoires, peuvent avoir un impact significatif sur la durabilité des plateformes numériques tout en offrant une expérience utilisateur optimisée et fluide.
Dans ce prototype, nous avons complété le scénario 2 à notre implémentation. Dans le cadre d'une plateforme de vente et d'achat de vêtements d'occasion entre particuliers, il est essentiel de permettre aux utilisateurs d'accéder aux détails d'un article après avoir cliqué sur celui-ci suite à une recherche.
Nous avons donc conçu et développé la page de détails d'un article, conformément à la maquette initiale.
Fig10 : Prototype 5 - Page de détails d'un article
L'ajout de cette nouvelle page entraîne une augmentation de la "Global Estimated Consumption" (= Consommation Énergétique Estimée Globale) de l'application. Cela est dû à l'impact énergétique de la page, notamment en raison des ressources qu'elle nécessite pour être chargée et affichée. Cependant, cette fonctionnalité est indispensable pour le bon fonctionnement de l'application et permet d'offrir des services essentiels aux utilisateurs. En pratique, cette page génère une consommation estimée de 33 mg d'énergie. Comparée à d'autres pages de l'application ou à des scénarios similaires, cette consommation reste raisonnable et ne compromet pas l'efficacité globale de l'application.
| Navigateur GreenFrame | Hébergement statique Swapp | Backend Swapp | Total | |
|---|---|---|---|---|
| CPU | 0.9 mWh (1%) | 0 mWh (0%) | 1.4 mWh (93%) | 2.3 mWh (3%) |
| Réseau | 1.8 mWh (2%) | 1.1 mWh (99%) | 0 mWh (1%) | 2.9 mWh (4%) |
| Écran | 69 mWh (96%) | 0 mWh (0%) | 0 mWh (0%) | 69 mWh (93%) |
| Mémoire | 0 mWh (0%) | 0 mWh (0%) | 0.1 mWh (6%) | 0.1 mWh (0%) |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) |
| Total énergie | 72 mWh | 1.1 mWh | 1.5 mWh | 74.6 mWh |
| Total carbone | 32 mg eq. CO₂ | 0.5 mg eq. CO₂ | 0.6 mg eq. CO₂ | 33.1 mg eq. CO₂ |
Tab13 : résultats GreenFrame de la page de détails d'un articles du prototype 5
Ces données permettent d'identifier l'affichage comme le principal point d'optimisation pour réduire l'empreinte environnementale de cette fonctionnalité.
Les résultats globaux de notre application sont alors les suivants.
| Page d'accueil | Page de résultats | Page d'article | Total | |
|---|---|---|---|---|
| CPU | 2.2 mWh (3%) | 2.3 mWh (3%) | 2.3 mWh (3%) | 6.8 mWh (3%) |
| Réseau | 4.5 mWh (6%) | 3.5 mWh (5%) | 2.9 mWh (4%) | 10.9 mWh (5%) |
| Écran | 67 mWh (91%) | 68 mWh (92%) | 69 mWh (93%) | 204 mWh (92%) |
| Mémoire | 0.1 mWh (0%) | 0.1 mWh (0%) | 0.1 mWh (0%) | 0.3 mWh (0%) |
| Disque | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) | 0 mWh (0%) |
| Total énergie | 73.3 mWh | 73.9 mWh | 74.3 mWh | 222 mWh |
| Total carbone | 32.5 mg eq. CO₂ | 32.2 mg eq. CO₂ | 33.1 mg eq. CO₂ | 98 mg eq. CO₂ |
Tab14 : résultats GreenFrame globaux de notre application
Ce projet a été l'occasion d'explorer les multiples dimensions de l'éco-conception dans les produits numériques. Nous avons constaté que des choix techniques judicieux permettent de réduire l'empreinte écologique d'une application ou d'un site. Ce travail nous a montré l'importance d'adopter une approche intégrée où chaque décision, de la conception à la maintenance, contribue à un numérique plus responsable et durable.
-
Le faible impact des calculs du CPU
Contrairement à ce que nous pensions, les calculs intensifs ne représentent pas la principale source de consommation énergétique.
Ce sont plutôt les requêtes réseau et le volume de données échangées qui ont un impact significatif sur l'empreinte écologique d'une application. -
L’impact significatif des publicités et du tracking
Les publicités et le tracking jouent un rôle prépondérant dans la consommation énergétique.
Ces éléments, souvent perçus comme secondaires, figurent en réalité parmi les principaux contributeurs à une empreinte carbone élevée.
Cette prise de conscience souligne l'urgence de limiter ces pratiques ou d'opter pour des alternatives plus respectueuses de l'environnement. -
Le potentiel des optimisations simples
Une meilleure gestion des requêtes serveur ou une simple compression des images peut réduire de manière significative la consommation de bande passante.
Ces ajustements permettent également de diminuer les émissions de CO2 associées.
Cela démontre qu'une optimisation réfléchie peut avoir un impact considérable, même avec des changements modestes. -
La différence d’impact par rapport aux concurrents
Le projet a mis en évidence une différence d'impact importante entre notre solution et celles des concurrents.
Grâce à notre approche d’éco-conception, notre produit s'est avéré nettement plus performant en termes d’empreinte écologique.
Pour réduire l'empreinte écologique de nos produits numériques, voici les principales pratiques identifiées :
- Mesurer l’impact dès la conception et tout au long du cycle de vie, en utilisant des outils adaptés ;
- limiter et compresser les images, ou mieux, privilégier des formats légers comme le SVG au lieu du PNG ;
- réduire la création de nouvelles pages et opter pour des architectures optimisées avec une pagination claire ;
- bannir le scroll infini, qui encourage une consommation non contrôlée de ressources et nuit à l'expérience utilisateur ;
- supprimer les requêtes superflues et filtrer les données pour ne transmettre que ce qui est réellement nécessaire ;
- limiter les publicités ou opter pour des business plans plus éco-responsables qui ne reposent pas uniquement sur le tracking et la consommation massive de ressources ;
- minimiser le temps passé sur les applications, en concevant des expériences centrées sur l'efficacité et non sur la rétention abusive ;
- utiliser une base de données bien conçue et optimisée pour réduire les temps de réponse et limiter les requêtes inutiles.
En conclusion, ce projet a mis en lumière le rôle clé des développeurs et concepteurs dans la réduction de l'empreinte écologique du numérique. Les technologies actuelles offrent déjà des solutions concrètes pour un numérique plus durable. Il ne nous reste qu'à les appliquer, en veillant à toujours privilégier la simplicité, l'optimisation et l'éthique dans nos choix.