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 car 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.
- Le développement territorial car 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. La numérisation de la musique a bouleversé son mode de consommation. Avec l'accès facile à des millions de titres, la consommation de musique a fortement augmenté. Là où, en 2016, un album CD coûtait environ 10 dollars, 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.
Cette évolution pose des questions écologiques et économiques, on peut se demander:
- si le streaming peut encourager la surconsommation de musique, car on peut désormais écouter des morceaux partout et à tout moment,
- si les fonctionnalités de ces plateformes, telles que les storys des artistes ou les playlistes personnalisées qui encouragent à écouter toujours plus différent, sont utiles.
Il est essentiel de réfléchir à des fonctionnalités plus équilibrées et moins gourmandes en ressources, tout en se questionnant sur leur activation par défaut.
- L'utilisateur se rend sur un site web de streaming en ligne
- Il accepte les cookies
- 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 accepte les cookies
- Il recherche une musique
- Il lance la musique trouvée
Les résultat de la platforme deezer et Musicme : Voir la preview du fichier HTML
Les résultats de la plateforme spotify sont différents, la stucture de la page fait que nous ne pouvons pas utiliser le cli de GreenIT donc nous avons utilisé l'extension chrome et changer le protocole car il fallait absolument créer un compte pour écouter de la musique. On précise que cet outil marche de la manière suivante : il va garder toutes les requêtes qui sont faites dans l'analyse, donc si nous faisons une analyse à chaque étape nous allons mesurer les mêmes requêtes plusieurs fois. Pour y remedier nous allons juste faire l'analyse à la fin du scénario.
- Se rendre sur le site web et se connecter
- Lancer la première musique proposée
- Regarder les autres musiques proposées sur la page d'accueil mais ne rien trouver.
- Se rendre sur le site web et se connecter
- Rechercher une musique précise
- Lancer l'écoute de cette musique
Resultat : 
(le résultat d'en bas est particulièrement désastreux, c'est le premier scénario, le site propose des vidéos et gifs par rapport à l'actualité des artistes ce qui est particulièrement couteux en ressources)
Malheuresement l'outil GreenIT ne mesure que sur l'instant T, donc si on veut mesurer l'impact du streaming sur tout le long de l'écoute d'une musique on va devoir le faire à la main via l'outil debug réseau.
On rappelle que les requêtes quand on clique sur la musique sont prises en compte dans les scénarios différents, ici on cherche juste à voir l'impact du streaming qu'on n'a pas pu calculer auparavant.
Pour spotify on observe une requête de 325 ko toutes les 10 secondes, donc pour une chanson de 3 minutes on a 18 requêtes et 5 850 ko de données transmises.
Pour deezer on observe une requête de 278 octets toutes les 30 secondes, donc pour une chanson de 3 minutes on a 5 requêtes et 1,390 ko de données trransmises.
Pour musicme on observe une requête de 413 octets toutes les 30 secondes, donc pour une chanson de 3 minutes on a 5 requêtes et 2,065 ko de données transmises.
Nous avons vu lors de nos scénarios qu'avoir des playlists personnalisées était une des fonctionnalités particulierement gourmandes. Nous avons donc opté pour un protype qui se base uniquement sur des genres de musiques qui auraient été choisis par l'utilisateur, tout en gardant toute l'usabilité d'un site de streaming de music.
Nous avons retenu deux pages type :
- celle avec les playlist par genre que l'utilisateur a choisi,
- celle d'une playlist (avec les musiques dedans et les artistes de ce genre).
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és 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).
Pour le premier prototype :
- notre base de données reste statique et dans le frontend,
- les fonctionnalités implémentés sont celles uniquement requises pour le 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évelopper une page avec une barre de recherche et une liste de musiques de manière très simpliste.
Fig.2: Prototype de la page de recherche.
Pour l'instant nous avons choisi d'utiliser la librairie lucid-react essentiellement pour sa fonction de recherche qui permet de prototyper rapidement sans se lancer dans la conception d'un algorithme de recherche. Il s'avère que cette librairie permet aussi d'ajouter des élèments graphiques pour des contrôleurs de média, fonctions qui peuvent être assurées de manière minimaliste par le html 5.
On a donc voulu voir quel était l'impact d'utiliser les fonctions qui ne sont pas nécessaire car déjà existante avec l'argument 'controller' que propose la balise ou de html mais qui rend le site plus joli. Les sites de streaming sont avant tout des commerces il est donc évident que ces sites soient épurés et jolis pour qu'ils soient quand même pertinents, donc regardons les différences et ce que ça coûte. Nous utilisons aussi tailwind.css pour le style général de la page pour générer du css personnalisé.
Nous pouvons 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 donc peut-être plus de requêtes, peut-être du code inutile donc un DOM plus grand que nécessaire :
Nous avons donc utilisé simplement l'extension chrome de GreenIT pour voir de manière très simple l'impact de nos choix en mesurant :
- la version dev et build du site web avec l'utilisations 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.
Ce qu'on lit de ces résultats c'est que les versions dev du site web sont déjà assez imposantes pour le peu qu'il y a et la différence entre utliser des librairies pour le design uniquement est significative (autour de 20% de différence).
Cependant une fois build 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 ça 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 se sait 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 :
Voir la preview du fichier html
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 qqu'avec la première version du prototype, nous n'avons qu'une seule requête supplémentaire par page consultée.
Voir la preview du fichier html
Nous nous sommes rendus compte qu'une requête était faite pour chaque musique lorsque nous chargions la mage pour charger le fichier mp3. Nous avons donc modifié notre application pour ne charger le fichier mp3 que lorsque nous lançons la musqique. Nous perdons quelques informations non nécessaires comme la durée de la musique mais nous gagnons un nombre important de requête.