Comment créer une application de streaming musical : fonctionnalités, processus et tendances

Commencez par une phrase qui explique pourquoi un auditeur en particulier choisirait votre produit.

“ Une meilleure découverte musicale ”, ça ne veut pas dire grand-chose.

“ Un service de streaming dédié aux labels de musique électronique underground, où les fans peuvent suivre les sorties, acheter des éditions limitées et rejoindre des salles d'écoute gérées par les labels ” : voilà un concept solide autour duquel l'équipe peut s'articuler.

Cette phrase sert de filtre pour définir la feuille de route. Les paroles d’une chanson peuvent correspondre. Les playlists collaboratives peuvent correspondre. Les podcasts, en revanche, n’ont peut-être rien à voir avec cette idée. La décision découle du produit lui-même, et non d’un simple tour d’horizon des fonctionnalités de Spotify.

C'est important, car les applications musicales peuvent très vite se diversifier. Un simple lecteur se transforme en listes de lecture, profils sociaux, messagerie, paroles de chansons, recommandations, pages de créateurs, billetterie et bien d'autres fonctionnalités avant même que l'usage principal, à savoir l'écoute, n'ait été testé.

Un produit mieux ciblé permet généralement d'obtenir de meilleures réponses plus rapidement.

La stratégie relative au catalogue doit être définie dès le début, car elle a des répercussions sur la quasi-totalité des couches techniques.

La musique peut provenir de labels, de mises en ligne directes par les artistes, de distributeurs, de votre propre catalogue, d’enregistrements du domaine public ou de plusieurs sources à la fois. Chaque modèle s’accompagne de règles différentes en matière de lecture, de téléchargements, de territoires, de crédits, de rapports et de retrait de contenu.

Cela modifie également le backend.

Un titre peut être disponible dans un pays mais indisponible dans un autre. Une sortie peut arriver à expiration. Un niveau d'abonnement peut autoriser l'écoute hors ligne tandis qu'un autre ne le permet pas. Un label peut autoriser la lecture intégrale mais restreindre les extraits ou les montages créés par les utilisateurs.

La disponibilité n'est donc que rarement une simple question de « oui » ou de « non ». Le système doit souvent déterminer qui peut diffuser un titre, où, dans le cadre de quelle formule et selon quelles conditions de droits.

Ces règles sont beaucoup plus faciles à mettre en place lorsqu'elles font partie intégrante du modèle de données dès le départ.

Le modèle économique doit être logique du point de vue de l'auditeur.

Un abonnement peut donner accès à un catalogue, mais un produit de niche peut proposer des contenus plus spécifiques moyennant un supplément : des sorties en avant-première, des communautés d'artistes, des sessions live, des archives, des pistes séparées, des cours, des outils pour DJ, des adhésions pour les fans ou encore des événements.

Certains produits peuvent combiner plusieurs sources de revenus. Un auditeur peut utiliser l'application gratuitement, souscrire à un abonnement pour soutenir un créateur, acheter une édition limitée et acquérir un billet à partir du même compte.

La question pertinente ici est simple : qu'est-ce qui a suffisamment de valeur pour qu'un utilisateur en comprenne immédiatement le prix ?

Pour un service de streaming à grande échelle, cet atout réside souvent dans l'accès au catalogue. Pour un service plus modeste, il peut s'agir d'une proximité avec une scène artistique, d'une meilleure découverte au sein d'un genre, de contenus rares ou d'une relation directe avec les artistes.

Cette réponse aura des répercussions sur la conception des produits, les paiements, les autorisations, les analyses et même la structure du catalogue.

Un MVP doit permettre de démontrer un comportement que les utilisateurs ont envie de reproduire.

Écrivez ce comportement sous la forme d'une courte séquence.

Découvrir l'artiste → écouter le morceau → enregistrer → suivre → revenir pour la prochaine sortie

Ou bien :

Rejoindre une salle → ajouter un morceau → échanger avec des amis → suivre des personnes → revenir pour la prochaine session

Ou bien :

Commencer la séance d'entraînement → choisir l'intensité → effectuer la série → évaluer la performance → revenir demain

Cet exercice permet généralement de régler les désaccords sur les fonctionnalités plus rapidement qu'un long cahier des charges.

Si la boucle principale est bien définie, vous pouvez évaluer chaque fonctionnalité en fonction de sa compatibilité avec cette boucle. La recherche l'est probablement. La récupération de compte l'est. Une place de marché complète pour les créateurs pourrait n'être intégrée que bien plus tard.

Pour une vision plus globale de la planification et de la mise en œuvre des applications, consultez le guide de Innowise intitulé Types et processus de développement d'applications mobiles.

Un prototype interactif suffit pour tester le déroulement de base avant que l'équipe ne développe le système multimédia complet.

Concentrez-vous sur l'intégration, la page d'accueil, la recherche, le lecteur, le comportement de la file d'attente, les actions sur la bibliothèque, les abonnements et la fonctionnalité qui fait l'identité du produit.

Ce joueur mérite une attention particulière, car les joueurs répètent sans cesse les mêmes actions.

Que se passe-t-il lorsqu'un utilisateur sélectionne un autre morceau ? Où est-il placé dans la file d'attente ? Comment fonctionne la fonction “ Lire ensuite ” ? Que se passe-t-il à la fin d'un album ? L'auditeur peut-il récupérer sa file d'attente après avoir fermé l'application ?

Ces choix peuvent sembler insignifiants sur l'écran de Figma. Au quotidien, ils finissent par devenir un réflexe.

C'est pourquoi l'expérience utilisateur liée à la lecture doit être considérée comme conception de produits, et non comme un cadre décoratif autour d'un fichier audio.

Il est généralement plus facile d'analyser la plupart des produits musicaux lorsque l'infrastructure est divisée en trois grands domaines.

La rubrique « Médias » regroupe les fichiers audio, les versions encodées, les illustrations, les téléchargements et la diffusion.

Les métadonnées portent sur les artistes, les sorties, les genres, les génériques, les labels, les compositeurs, les ambiances, les langues, les versions et les relations entre les entités du catalogue.

Les droits précisent qui peut écouter, où, dans le cadre de quelle formule, pendant combien de temps et à quelles conditions.

Les données musicales deviennent étonnamment vite complexes.

Une chanson peut exister sous forme de version album, de version radio, de version remastérisée, de remix, de version instrumentale, de version censurée, d'enregistrement live, de réédition « deluxe » ou de sortie régionale. Deux artistes peuvent porter le même nom. Un artiste peut changer de nom. Une sortie peut disparaître sur un territoire donné tout en restant disponible partout ailleurs.

Un modèle de données qui reflète ces relations vous évitera bien des tracas lors du nettoyage ultérieur.

Des métadonnées de mauvaise qualité compliquent la recherche de bonne musique.

Les utilisateurs remarquent immédiatement les problèmes. Les pages d'artistes en double sont source de confusion. Des dates de sortie erronées ou mal définies donnent une impression de négligence lors de la consultation du catalogue. Un remix attribué au mauvais artiste nuit à la fois à la recherche et aux recommandations.

Les produits de niche nécessitent souvent des métadonnées plus détaillées que les services grand public.

Une application consacrée à la musique classique peut s'intéresser au compositeur, à l'œuvre, au mouvement, au chef d'orchestre, à l'orchestre, au soliste, à l'époque et à la date d'enregistrement.

Un produit destiné aux DJ peut prendre en compte le BPM, la tonalité, le label, la version du mix, la série de sorties et les liens entre les remixes.

Un service régional peut nécessiter une translittération, des orthographes locales, des noms d'artistes alternatifs et une fonction de recherche spécifique à la langue.

Dans certains produits, le modèle de métadonnées devient l'un des principaux arguments en faveur de l'utilisation de l'application. Il permet aux utilisateurs de parcourir leur musique en se basant sur la façon dont ils la conçoivent déjà.

Un lecteur de musique doit être testé dans les conditions réelles d'utilisation : sur les réseaux mobiles, dans les trains, en voiture, avec une connexion Wi-Fi de faible qualité, avec des écouteurs Bluetooth, en mode arrière-plan et sur des appareils ne disposant pratiquement d'aucun espace de stockage libre.

Passez en revue les dossiers complexes.

Passer du Wi-Fi au réseau mobile en plein milieu d'un morceau. Verrouiller le téléphone. Répondre à un appel. Déconnecter le Bluetooth. Fermer l'application. La rouvrir. Interrompre un téléchargement. Remplir la mémoire de l'appareil.

Vérifiez ensuite ce que voit l'utilisateur.

La file d'attente est-elle conservée ? La lecture reprend-elle au bon endroit ? L'application se rétablit-elle après une perte de connexion ? Le message d'erreur est-il utile ? L'auditeur peut-il savoir quels morceaux sont disponibles hors ligne ?

Les règles de mise en mémoire tampon, le cache local, le préchargement, la logique de réessai, les paramètres de qualité et le comportement de téléchargement contribuent tous à façonner cette expérience.

Un écran d'accueil magnifique ne sert pas à grand-chose si la lecture ne cesse de s'interrompre.

Un moteur de recherche performant apporte généralement plus de valeur à un nouveau produit musical qu'un moteur de recommandation ambitieux mis en place trop tôt.

Les utilisateurs doivent pouvoir trouver des artistes même en cas de fautes de frappe. La fonction de recherche doit prendre en compte les titres, les albums, les labels, les playlists, les genres musicaux et tous les éléments du catalogue qui intéressent votre public.

La découverte peut commencer par des indices simples mais utiles : les dernières sorties des artistes que vous suivez, les sélections éditoriales, les liens entre genres, les affiliations entre labels, votre historique d'écoute et les suggestions “ Vous aimerez aussi ”.

Les modèles de recommandation plus complexes prennent tout leur sens dès lors que le produit dispose d'un volume suffisant de données sur les comportements réels à partir desquelles s'appuyer.

Et la durée de la session, à elle seule, constitue un indicateur peu fiable de la qualité d'une recommandation.

Examinez les sauts de piste, les sauvegardes, les écoutes répétées, les abonnements, les masquages, les recherches, et vérifiez si les auditeurs reviennent vers les artistes qu’ils ont découverts via l’application. Ces indicateurs vous en disent bien plus sur l’efficacité réelle de la découverte.

Donnez également aux utilisateurs un certain contrôle. Une simple action du type “ moins comme ça ” peut corriger une mauvaise recommandation plus rapidement qu’une nouvelle couche de logique de classement.

Les applications musicales détectent rapidement les cas limites ; c'est pourquoi les tests d'assurance qualité doivent aller au-delà de la simple lecture normale.

Voyez ce qui se passe lorsque :

• l'abonnement arrive à échéance ;
• une licence de téléchargement arrive à expiration ;
• un titre disparaît du catalogue ;
• un paiement échoue ;
• un utilisateur change de pays ;
• le même compte est actif sur plusieurs appareils ;
• une playlist contient des morceaux indisponibles ;
• un artiste supprime un fichier qu'il a mis en ligne ;
• un auditeur dispose d'une très grande bibliothèque ;
• un téléchargement s'arrête juste avant d'être terminé.

Puis, abordez la question des maltraitances.

Les écoutes frauduleuses peuvent avoir une incidence sur les rémunérations. Le « scraping » peut exposer les données du catalogue. Le spam lié aux mises en ligne peut noyer la musique légitime. L'usurpation d'identité d'artistes engendre des problèmes liés aux droits et à la confiance. Le partage de comptes peut fausser les règles d'abonnement.

Si le produit rémunère des créateurs ou vend un accès à du contenu sous licence, ces cas doivent être pris en compte dans le premier plan de contrôle qualité sérieux.

La première version devrait être destinée aux personnes qui correspondent le mieux possible à l'idée initiale du produit.

Un service destiné aux labels techno indépendants a besoin de la participation d'auditeurs de techno, de DJ, d'artistes et d'équipes de labels pour sa phase bêta.

Un produit destiné à l'apprentissage de la musique doit s'adresser à des musiciens dont le niveau correspond à celui pour lequel l'expérience a été conçue.

Il est beaucoup plus facile de tester une plateforme dédiée aux fans lorsqu'un petit nombre de créateurs dispose déjà d'un public prêt à les suivre sur une nouvelle plateforme.

Observez ensuite le comportement du noyau.

En combien de temps l'utilisateur accède-t-il au premier morceau ? Que recherche-t-il ? Qu'enregistre-t-il ? Quelle fonctionnalité le fait revenir ? À quel moment quitte-t-il la plateforme ? Le cycle d'écoute principal s'installe-t-il naturellement, ou le produit incite-t-il constamment les utilisateurs à y revenir ?

C'est cette dernière question qui importe le plus.

La première version devrait vous permettre de déterminer si l'idée donne lieu à une véritable habitude. Une fois que vous le savez, le reste de la feuille de route devient beaucoup plus facile à justifier.