L’écoute de la musique en streaming représente une activité quotidienne pour beaucoup d'entre nous, car elle peut facilement être pratiquée en parallèle d’autres tâches comme le travail ou les trajets quotidiens.
Au-delà de cet usage personnel, le streaming musical a connu une adoption massive. Il est devenu l’un des moyens les plus populaires de consommer de la musique, remplaçant largement les formats physiques et offrant une accessibilité mondiale.
La musique en streaming joue un rôle important sur :
-
Le plan médico-social :
L’écoute de la musique peut améliorer le bien-être, aider à gérer le stress et l’anxiété, favoriser la motivation, la concentration, et même contribuer à la méditation. Elle a un impact positif sur la santé mentale et émotionnelle. Article sur l'écoute de la musique -
Le développement territorial :
Le streaming permet aux artistes issus de régions éloignées d’atteindre un public mondial. Cela leur offre des opportunités sans précédent pour se faire connaître, dépassant les limites géographiques traditionnelles.
Un des avantages majeurs du streaming musical pour l'environnement est qu'il a remplacé des technologies plus anciennes comme les CD et les MP3, qui impliquaient une production physique et donc des émissions de plastique. De plus, il se positionne comme une alternative plus respectueuse de l’environnement aux festivals ou concerts, qui génèrent des impacts importants liés aux déplacements.
Cependant, cette substitution aux pratiques anciennes engendre aussi un important effet rebond (article sur l'impact la numérisation) :
- Accessibilité massive : Avec l'accès facile à des millions de titres, la consommation de musique a fortement augmenté.
- Impact économique : Là où, en 2016, un album CD coûtait environ 15 euros, aujourd’hui, pour ce même montant, il est possible d’avoir accès à des millions de titres pendant un mois via une plateforme de streaming.
- Le streaming peut-il encourager la surconsommation de musique, car on peut désormais écouter des morceaux partout et à tout moment ?
- Les fonctionnalités des plateformes (stories des artistes, playlists personnalisées) sont-elles vraiment utiles ou encouragent-elles une écoute toujours plus diversifiée, mais aussi plus gourmande en ressources ?
Analyse du leader du marché : spotify
- L'utilisateur se rend sur un site web de streaming en ligne.
- Il lance la première musique qui lui est proposée.
- Il regarde les autres musiques proposées sur la page d'accueil, mais rien ne l'intéresse. Il stoppe donc sa navigation.
- L'utilisateur se rend sur un site web de streaming en ligne.
- Il recherche une musique.
- Il lance la musique trouvée.
Pour tester les scénarios sur les sites de streaming en ligne. Nous avons dû ajouter une étape "accepter les cookies" dans notre scénario afin de le faire fonctionner. Nous avons utilisé l'outil GreenIT en ligne de commandes pour les services Deezer et MusicMe, qui nous permet de scripter et tester nos scénarios.
Les résultats des plateformes :
- Deezer et MusicMe : Scénario 1 : "Lancer une musique recommandée".
- Spotify : Les résultats diffèrent en raison de la structure de la page et nécessitent l'utilisation de l'extension Chrome GreenIT.
Malheureusement, l’outil GreenIT mesure uniquement à un instant T. Pour évaluer l'impact du streaming sur toute la durée d'écoute, une analyse manuelle via l’outil de débogage réseau est nécessaire.
Dans certains cas, selon le service et la durée de la musique, le fichier audio est directement chargé entièrement, et il n'y a donc pas toujours de streaming à proprement parlé. Dans d'autres cas, le service va effectuer plusieurs requêtes pour récupérer le son par morceaux.
- Spotify : Requêtes de 325 Ko toutes les 10 secondes, soit 5 850 Ko pour une chanson de 3 minutes.
- Deezer : Requête de 278 octets toutes les 30 secondes, soit 1,390 Ko pour une chanson de 3 minutes.
- MusicMe : Requête de 413 octets toutes les 30 secondes, soit 2,065 Ko pour une chanson de 3 minutes.
Lors des scénarios, nous avons constaté qu'avoir des playlists personnalisées était une des fonctionnalités particulièrement gourmandes. Nous avons donc opté pour un prototype basé uniquement sur des genres de musiques choisies par l'utilisateur, tout en gardant l'usabilité d’un site de streaming.
Nous avons retenu deux pages type pour notre application, nous avons ainsi réalisé les maquettes de :
- la page des playlists par genre,
- la page d'une playlist (avec les musiques dedans et les artistes de ce genre).
Fig.1 : Mockup de notre application.
Pour des raisons de respect des droits d'auteurs, nous utilisons des données générées (avec dummy-json). Ces données sont générées aléatoirement et permettent d'identifier une musique, cepandant on ne peut pas générer un fichier audio donc on utilise un URL qui vient de la base de données Pixabay (voir modele de données).
Liens utiles :
- Pixabay : Base de données pour les URL audio.
- Lucid React : Librairie utilisée pour le design et les contrôles média.
Pour le premier prototype :
- La base de données est statique et incluse dans le frontend. voir modèle de données
- Les fonctionnalités implémentées se limitent au scénario 1 (Rechercher une musique et l’écouter).
Ce scénario nécéssite de pouvoir rechercher parmi une liste de musiques et de l'écouter. Nous avons développé une page avec une barre de recherche et la liste des musiques.
Fig.2 : Prototype de la page de recherche.
Lien utile : Dummy JSON pour générer des données aléatoires
Nous avons choisi d'utiliser la librairie lucid-react essentiellement pour les composants graphiques que cette dernière propose pour les contrôleurs de média. Nous utilisons aussi tailwind.css pour le style général de la page pour générer du css personnalisé. Nous pensons en effet que travailler l'interface utilisateur d'un service de streaming est essentiel pour s'assurer que le client apprécie son utilisation et revienne plus tard. On a donc voulu voir quel était l'impact d'utiliser ces librairies plutôt que les balises ou de html.
Nous avons donc ici mesurer l'impact général de la page et donc de nos choix de framework, utiliser react et les librairies pour gagner du temps sur les fonctionnalités et l'esthéthisme font que cela peut manquer d'optimisation.
Pour cette mesure, nous avons utilisé l'extension chrome de GreenIT pour voir de manière très simple l'impact de nos choix en mesurant :
- la version de développement et de production du site web avec l'utilisation des balises html par défaut,
- les mêmes versions avec l'utilisation de lucid-react pour les élèments de contrôle de média et pour la barre de recherche.
Fig.3: Résultat des 4 tests
Sur cette image nous avons les résultats dans l'ordre :
- de la version de production sans lucid-react,
- de la version de développement sans lucid-react,
- de la version de production avec lucid-react,
- de la version de développement avec lucid-react.
Ce qu'on lit de ces résultats c'est que les versions de développement du site web ont déjà un impact significatif. On remarque qu'utiliser des librairies pour le design uniquement a un impact asses significatif (environ 20% de différence).
Cependant une fois compilée la page est déjà beaucoup plus moderée et en plus la différence entre les deux versions ne se voit quasiment pas. On peut donc se dire que cela ne change pas grand chose avec la librairie lucid-react d'utiliser des fonctions importées pour gérer des élements de designs.
Au final on ne connait pas encore toutes les fonctionnalités qu'on utilisera ou n'utilisera pas pour finir le projet mais on peut se dire qu'on peut se sentir libre d'utiliser ou non cette librairie comme on veut car l'impact sera dérisoire.
Nous pouvons donc éxecuter notre scénario principal et voir l'impact de l'utilisation de notre site comparé à nos concurrents.
Scénario 2 : "Rechercher une musique spécifique" - 1ère itération
Prototype n°2 : Fonctionnalités pour le scénario prioritaire avec données statiques chargées de manière dynamique
Dans cette seconde version du prototype, les données sont désormais chargées dynamiquement par le frontend.
En utilisant le même scénario qu'avec la première version du prototype, nous n'avons qu'une seule requête supplémentaire par page consultée.
Scénario 2 : "Rechercher une musique spécifique" - 2ème itération
Nous nous sommes rendus compte qu'une requête était faite pour chaque musique lorsque nous chargions la page pour charger le fichier MP3.
Nous avons donc modifié notre application pour ne charger le fichier MP3 que lorsque nous lançons la musique. Nous perdons quelques informations non nécessaires comme la durée de la musique, mais le nombre de requêtes a fortement diminué, ce qui très positif.
Scénario 2 : "Rechercher une musique spécifique" - 3ème itération
Après avoir discuté de la méthode de calcul qu'utilise GreenIT, nous avons décidé d'utilisé une autre méthode afin de calculer l'impact de notre application. En effet GreenIT vise à calculer l'impact global de l'utilisation d'un site internet, que ce soit l'impact de l'achat ou la production du téléphone utilisé, l'alimentation des serveurs, la construction duréseau, etc. Cependant dans notre cas nous souhaitons plutôt connaître l'impact strictement lié à l'utilisation de notre site. Dans la suite du projet, nous utiliserons donc GreenFrame, un outil qui permet de calculer uniquement l'impact énergétique lié à l'utilisation de notre application web.
On veut donc re-créer un échantillon d'analyse des sites concurrents pour pouvoir comparer ce qui est comparable avec le nouvel outil, voici les résultats de l'analyse simple de la première page du site :
Fig.4: Résultat de Spotify
Fig.5: Résultat de Deezer
Fig.6: Résultat de MusicMe
On remarque ici une consommation très élevée au niveau du CPU, du réseau et de l'écran. Cependant, les impacts de la mémoire et du disque sont quasiment nuls.
On fait ensuite les modifications pour faire les tests de GreenFrame automatiquement à chaque fois que l'on modifie notre dépôt de projet GitHub. On peut voir des résultats qui nous disent que notre site consomme très peu de ressource, essentiellement du temps d'écran, la seule fonctionnalité qui a un impact significatif est celle de la recherche donc très peu de CPU utilisé. Ce sont donc des résultats très concluants par rapport aux concurrents.
Ce qui fait que nos résultats sont bien meilleurs est le fait que nous nous sommes concentrés sur la fonctionnalité essentielle de l'écoute de la musique, et non sur des fonctionnalités superflues. En réalité presque la totalité de notre impact vient de l'écran. On se rend donc ici bien compte que l'affichage des informations est la première barrière à une application écologique.
Fig.7: Résultat de notre prototype V.2
Nous avons ensuite mesuré l'impact de la partie serveur de notre prototype. On peut voir qu'il est insignifant. En effet cela est en partie dû au fait que nous avons décider de charger directement le fichier mp3 au complet. Bien qu'avoir un système de streaming permet de limiter l'impact, ce n'est pas pour les fichiers audio que cela est le plus impactant car un fichier audio n'est pas particulièrement volumineux (contrairement à un film par exemple). L'essentiel est surtout de ne pas charger le fichier tant que le musique n'est pas lue. Nous n'avons pas non plus de transformations ou calcul à faire dans le serveur qui ne fait que relayer les données qui sont stockées. Donc logiquement le seul pic de consommation est au lancement du site.
Fig.8: Résultat de notre prototype V.2 côté serveur
Prototype n°3 : Fonctionnalités pour le scénario prioritaire avec données stockées dans une base de données
Pour la V3 de notre prototype, nous voulons que les données soient stockées dans une base de données en ligne (CouchDB).
L'intérêt d'une base de données dynamique est de pouvoir rajouter facilement des musiques. On pourrait même imaginer, comme on le voulait, un formulaire pour que les gens rajoutent eux-mêmes leur musique dans l'application.
Fig.9: Résultat de notre prototype V.2
Fig.10: Résultat de notre prototype V.3
On n'observe pas de différence dans l'utilisation du réseau via notre scénario GreenFrame. Cela est dû au fait que, dans notre scénario principal, nous récupérons toutes les musiques. Cependant, pour de futurs scénarios, cette base de données nous permettra de faire des requêtes spécifiques (par exemple, pour ne demander qu'une seule musique ou un seul style de musique) et ainsi de réduire le réseau utilisé.
On remarque cependant une augmentation de l'usage du CPU liée au fonctionnement de la base de données sur un Docker. Cette modification de notre prototype a l'air, à priori, néfaste écologiquement mais deviendra à l'avenir une meilleure solution.
Fig.11: Résultat de notre prototype V.3 côté backend
Dans le cas d'une application de streaming de musique, l'augmentation des données se traduit par une augmentation du nombre de musiques. Le poids des musiques ne change pas, mais leur volume total augmente. Il est nécessaire d'avoir une grande base de données pour offrir une liberté de choix compétitive.
Cependant, ce marché étant en pleine expansion, la gestion des données ne sera pas linéaire dans les prochaines années.
La figure ci-dessous illustre l'impact du passage de 10 musiques à 1 000 musiques (multiplié par 100 de manière arbitraire).
Dans un premier temps, au niveau du Temps d’écran, l'augmentation importante due à l'affichage de toutes les musiques sur la page d'accueil.
Pour la Consommation réseau et CPU, il y a une hausse significative liée au traitement des données supplémentaires.
Fig.12 : Évolution de l'impact de la consultation de la page d'accueil en passant de 10 musiques à 1 000 musiques.
Pour résoudre ce problème, nous avons décidé de filtrer les musiques affichées sur la page d'accueil en
- triant les musiques par date de sortie, et seules les plus récentes sont affichées à l’utilisateur,
- indexant la base de données en fonction de l’attribut
release_datepour optimiser cette requête.
Les résultats montrent des effets positifs significatifs après la correction :
- La version corrigée est légèrement plus gourmande qu'avant, car 100 musiques sont affichées au lieu de 10.
- Cependant, nous avons bien 1 000 musiques dans la base de données, prêtes à être utilisées pour de futurs scénarios.
Dans les prochaines versions nous améliorerons notre application pour pouvoir accéder aux 1000 musiques sans pour autant les afficher (notamment en améliorant notre outil de recherche).
Fig.13 : Évolution de l'impact de notre application au cours des dernières versions.
En observant de plus près :
- la consommation écran a une réduction importante grâce au filtrage des musiques,
- l'accès à la base de données est optimisé grâce à l'indexation, réduisant les ressources nécessaires,
- la consommation réseau* est réduite avec seulement 100 musiques affichées.
Fig.14 : Impact de la page d'accueil avec les 100 musiques les plus récentes affichées.
Au cours de notre dernier prototype, où nous avons augmenté la taille de notre BDD, nous avons rencontré un problème.
Avant le changement nous affichions toute la BDD sur notre page d'accueil et avions une fonction de recherche sur les titres affichés. Avec l'augmentation du nombre de titres, il n’était plus possible d’afficher toute la BDD, car cela avait un impact très négatif. Par conséquent, la recherche ne fonctionnait que sur les 100 titres les plus récents affichés, et non pas sur toute la BDD.
La Solution mise en place : Lorsque l'utilisateur écrit quelque chose dans la barre de recherche, l'application envoie une requête spécifique à la base de données pour trouver les titres correspondant au préfixe recherché. Un nouvel index a été créé sur l’attribut "title" pour optimiser cette recherche. Si la barre de recherche est vide, la requête utilise un tri par date grâce à l'index by_date. Sinon, l’index by_title est utilisé.
Les Avantages de cette démarche sont que :
- avec un index simple (plutôt qu’un double index), nous avons un meilleur impact écologique,
- lors du premier chargement de la page, l’utilisateur voit les titres les plus récents,
- lorsqu’il effectue une recherche, il obtient des résultats précis, et la date des titres devient secondaire.
Résultats :
Après analyse, les résultats se sont logiquement améliorés. Le nombre de musiques affichées à l’accueil est passé de 100 à 20, tout en permettant un accès à 1000 musiques via la recherche.
Fig.15 : Impact de la page d'accueil avec la nouvelle fonction de recherche.
Notre algorithme actuel effectuait une recherche à chaque fois qu’un caractère était tapé dans la barre de recherche, ce qui générait beaucoup de requêtes inutiles.
Amélioration apportée :
- La recherche n'est déclenchée que lorsque l'utilisateur appuie sur la touche "Entrée".
Mesure de l'impact :
- L’impact de ce changement ne peut pas être mesuré avec GreenFrame, nous avons donc utilisé l’extension GreenIT pour observer les différences.
Fig.16 : Impact d'une recherche avant changement.
Fig.17 : Impact d'une recherche après changement.
Nous observons qu'avec ce nouveau comportement, nous avons une réduction des requêtes envoyées. Par exemple, en tapant 4 caractères, nous effectuons 1 seule requête au lieu de 4 requêtes, ce qui représente un gain de 3 requêtes.
Contexte : Nous souhaitions proposer à l'utilisateur une musique aléatoire parmi les titres les plus récents.
Mise en place : Parmi les 20 musiques les plus récentes retournées par la requête à la BDD, une est sélectionnée aléatoirement et affichée en bas de la page.
Objectif : Aider l'utilisateur indécis à découvrir une musique facilement.
Impact : Les résultats GreenFrame montrent que cette fonctionnalité a un impact négligeable par rapport à la version précédente.
Fig.18 : Impact GreenFrame de la page d'accueil avec proposition d'une musique aléatoire.
Contexte : Actuellement, les musiques sont triées uniquement par date de sortie.
Améliorations apportées :
- Les musiques sont désormais groupées par genre pour aider l’utilisateur à mieux se repérer.
- L'indexation par genre dans la BDD s’est avérée trop coûteuse en terme d’impact, nous avons donc opté pour un groupement côté frontend après le tri par date et titre avec Mango.
Résultat : Cette méthode présente un impact écologique acceptable, bien que visible.
Fig.19 : Impact GreenFrame de la page d'accueil après groupement par genre.
Objectif : Cette page permet à l'utilisateur d’écouter des musiques d’un genre sélectionné, tout en limitant l’effet rebond discuté en début de projet.
La page contient :
- une liste des musiques liées au genre sélectionné,
- une liste des artistes associés à ce genre.
-
Refactorisation du code : Le code a été décomposé en plusieurs composants réutilisables pour simplifier les futures évolutions.
-
Gestion de plusieurs pages : Utilisation de React Router pour passer d'une page à l'autre.
-
Indexation des données : Un nouvel index a été ajouté sur les genres, car la fonction de recherche n’est pas présente sur cette page.
Résultats GreenFrame :
- Le score général du site a presque doublé, mais cela s’explique par l’ajout d’un nouveau scénario.
- En réalité, la nouvelle page a un impact similaire, voire légèrement inférieur à la page principale.
Fig.20 : Impact GreenFrame de la page principale après modifications.
Fig.21 : Impact GreenFrame de la page pour une catégorie.
Contexte : Un attribut inutile, "duration", était présent dans nos données, bien que cette information soit déjà contenue dans les fichiers MP3.
Action :
Suppression de cet attribut, réduisant la taille des données transmises lors des requêtes.
Résultat : L’impact sur la consommation CPU est très légèrement réduit.
Fig.21 : Impact GreenFrame après suppression de l'attribut "duration."
Problème : Le bouton "mute" ne fonctionnait qu’après le chargement complet de la musique.
Solution : Correction de ce bug, sans impact mesurable sur GreenFrame.
Problème initial : Afficher toutes les musiques d’un genre sur une page consommait trop de ressources (écran et réseau).
Solution :
- La page affiche désormais les 10 premières musiques et leurs artistes associés.
- Une fonctionnalité permet de charger davantage de musiques grâce à l’utilisation du "bookmark" de CouchDB, évitant des requêtes globales inefficaces.
Impact : On ne constate pas d'impact direct sur greenFrame puisque de base on avait paramétré la requete pour ne prendre que 10 musiques et les artistes liées, or maintenant quand on charge la page on n'afiche encore que 10 musiques et les artisrtes liées, or maintenant on peut accèder à toute la base de donnée de manière efficiente et sur demande de l'utilisateur pour convenir à ses besoins. Etant donnée que les scénarios greenframe ne sont pas assez poussé on ne voit pas de changement.
La conception d'applications web durables repose sur plusieurs bonnes pratiques que nous avons mises en place dans le projet EchoStream.
Tout d'abord nous avons analyser les problèmes de nos concurrents afin de ne pas répéter les mêmes erreurs et éviter les fonctionnalités ayant le plus fort impact. Nous avons minimiser les ressources chargées dans notre application pour ne charger une musique que lorsqu'elle est écoutée. Sur le même principe, la pagination est très importante afin de ne récupérer qu'une partie des données de la base et limiter l'utilisation du réseau et du CPU. Il est également important d'optimiser ses requêtes en utilisant notamment des index appropriés (c'est ce que nous avons fait avec release_date et title). Enfin, la suppression des fonctionnalités non essentielles permet de se concentrer sur ce qui est vraiment utile pour l'utilisateur et évite un impact négatif inutile.
Avec le projet EchoStream, nous retenons que des applications performantes peuvent être réalisées sans sacrifier l'éco-responsabilité, en privilégiant des fonctionnalités réellement utiles et la gestion judicieuse des ressources.