Spotify supprime des fonctionnalités de l'API Web en invoquant des problèmes de sécurité

Les API de développement ne font généralement pas l'objet d'un article principal de Music Ally, mais certains changements annoncés par Spotify concernant son API Web cette semaine semblent importants.

Il s'agit de l'une des API utilisées par les développeurs créant des services et des applications qui accèdent à Spotify pour la musique et d'autres données. Mais désormais, moins de ces derniers.

« Alors que nous continuons d'examiner l'expérience offerte sur Spotify aux développeurs, nous avons décidé de déployer un certain nombre de mesures dans le but de créer une plate-forme plus sécurisée », c'est ainsi que Spotify a encadré les changements.

À partir d'hier (27 novembre), les nouveaux « cas d'utilisation » de l'API Web (c'est-à-dire les nouvelles applications enregistrées ainsi que celles en développement mais pas encore lancées) ne pourront plus accéder aux divers « points de terminaison et fonctionnalités » de Spotify.

Ceux-ci incluent ses artistes associés, ses recommandations, ses fonctionnalités audio et son analyse audio, ses listes de lecture algorithmiques et éditoriales appartenant à Spotify, ainsi que les URL d'aperçu de 30 secondes dans les réponses « multi-get ».

« Nous souhaitons réitérer le message principal du blog, à savoir que nous nous engageons à fournir un environnement sûr et sécurisé à toutes les parties prenantes de Spotify », a réitéré le modérateur du fil de discussion ouvert par Spotify sur son forum de développeurs pour recueillir des commentaires. Et comme on pouvait s’y attendre, les réponses ont été très critiques.

« Un changement majeur, éliminant fondamentalement la plupart des principaux cas d'utilisation de l'API », a écrit un développeur. « Je pense qu'il ne s'agit pas d'une question de sécurité mais plutôt d'un moyen de limiter la concurrence », suggère un autre. « Avec l'avènement des modèles de transformateurs, il y a probablement un risque que les gens forment de nouveaux modèles pour imiter le(s) modèle(s) de Spotify », a avancé un troisième.

Il existe un discours populaire autour des services numériques et des API pour les applications tierces. Il soutient qu’au début de ces services, l’ouverture était à la mode. API, programmes de développement, journées de piratage, pizza gratuite pour tous… jusqu'à ce qu'ils deviennent plus grands, plus protecteurs et commencent à fermer leurs portes.

Cela dit, comme l’a suggéré le troisième intervenant ci-dessus, nous SOMMES dans une époque où les entreprises sont encore plus conscientes des données qui peuvent être récupérées à l’aide de leurs API, en particulier à mesure que les technologies d’IA continuent de se développer. Dans le cas de Spotify, c'est un sujet sur lequel ses partenaires titulaires de droits sont également de plus en plus attentifs, ce qui peut être un facteur ici – ils sont après tout des « parties prenantes ».

Le changement de Spotify peut donc être compréhensible dans ce contexte, même si plus de préavis pour les développeurs – et peut-être un peu plus de flexibilité pour ceux qui ont déjà passé des mois à travailler sur leurs projets – auraient été les bienvenus.

Dans le passé, nous aurions pu suggérer que Spotify extrayant des éléments de son API était une opportunité pour un rival de capitaliser en ouvrant davantage ses propres plates-formes et en accueillant les développeurs à bras ouverts.

Mais aujourd’hui, quels concurrents semblent en réalité désireux de nourrir un écosystème de développeurs capables de surpasser leurs propres équipes en matière d’innovation ? La direction du streaming musical en streaming est différente depuis un certain temps.