Open in app

Sign up

Sign in

Write

Sign up

Sign in

Deez is la tech — S02E05 — Intégrations hardware et partenariats : quels challenges pour avoir Deezer partout, tout le temps

Pauline Munier
Deezer I/O
Published in
33 min readApr 24, 2024

--

Il semble aujourd’hui naturel de pouvoir écouter sa musique quasiment sans interruption de ses écouteurs sans fil à sa télé, de son enceinte connectée à sa voiture, tout en utilisant le même service de streaming. Si les transitions peuvent paraître simples à l’usage, les intégrations techniques et fonctionnelles le sont beaucoup moins !

Dans ce nouvel épisode du podcast Deez is la tech, nous recevons trois membres de l’équipe Partnership Integration de Deezer afin qu’ils nous expliquent le fonctionnement des partenariats et intégrations hardware de Deezer.

Note: This post accompanies the release of the fifth episode of the second season of “Deez is la tech”, a podcast created by Deezer’s Product & Tech teams — in French only for now. You can still find English content on deezer.io though. Go check it out!

Résumé de l’épisode

L’une des promesses de Deezer est d’accompagner en musique chaque utilisateur tout au long de sa journée, de son trajet en voiture le matin à son jogging du midi, à son quart d’heure détente le soir dans son salon. Pour cela, en plus des classiques applications mobiles et site web, le service Deezer se doit d’être disponible sur divers appareils et plateformes.

Comment ces intégrations sont-elles effectuées ? Comment les partenariats sont-ils mis en place et gérés ? Comment appréhende-t-on la multiplicité d’acteurs, de développements et de contraintes ? Et enfin, comment fait-on en sorte que Deezer soit toujours là au bon moment, au bon endroit, et réponde aux attentes de ses utilisateurs ?

Pour explorer le sujet, Loic Doubinine (X) et Vincent Lepot (X) reçoivent Nicolas Pinoteau (VP Product & Engineering — LinkedIn), Hugo Vignaux (Senior Product Manager — LinkedIn) et Camille Blin (Engineering Manager — LinkedIn), tous trois membres du département Partnership Integration de Deezer. Ceux-ci nous dévoilent l’envers du décor, avec ses spécificités et ses challenges techniques, fonctionnels, opérationnels et contractuels.

Épisode disponible également sur Deezer | Apple Podcasts | Spotify | Amazon Music.

Transcription

Vincent (00:02) : Bonjour et bienvenue dans Deez is la tech, le podcast qui ne pète ni les plombs, ni les crons ! Créé et animé par les équipes Product & Tech de Deezer, ce programme aborde des sujets relatifs aux mondes de la tech et du streaming musical, et vous fait occasionnellement découvrir les coulisses de certaines des fonctionnalités phares de Deezer. Rejoignez-nous chaque mois pour une nouvelle discussion entre collègues et pairs, en toute décontraction, mêlant partages d’expériences, bonnes pratiques et réflexions sur les tendances futures. Prêts pour un nouvel épisode ? Chaussez vos écouteurs, ça commence maintenant !

Vincent (00:39) : Vous avez peut-être remarqué que Deezer ne se limite pas à un site web et des applications mobiles et que vous pouvez écouter votre musique dans votre voiture, sur votre télé ou encore via vos enceintes connectées. Mais comment cela est-il rendu possible ? Nous recevons aujourd’hui trois membres de l’équipe Partnership Integration de Deezer afin de découvrir le quotidien d’une équipe dédiée aux partenariats, et le fonctionnement des intégrations hardware en particulier. Quelles intégrations de Deezer existent à l’heure actuelle ? Comment gère-t-on la multiplicité des plateformes et des partenariats et les développements associés ? À quelles contraintes techniques, fonctionnelles et contractuelles est-on confronté ? Et enfin, comment fait-on en sorte que l’expérience Deezer soit disponible sur toujours plus d’appareils ? Vous verrez que c’est plus compliqué qu’il n’y paraît ! Mais laissons tout d’abord nos invités se présenter.

Nicolas (01:29) : Bonjour, je m’appelle Nicolas Pinoteau, je travaille chez Deezer depuis un peu plus de 12 ans. Je suis VP Product and Engineering pour la startup (le département) Partnership Integration. Je suis donc accompagné de deux de mes acolytes.

Loic (01:43) : Hugo ?

Hugo (01:44) : Bonjour, je suis Hugo Vignaux. Je suis arrivé dans la société Deezer il y a cinq ans. Je suis Senior Product Manager et je m’occupe de différentes “verticales”. Il y a la verticale “big screens” donc les écrans — notamment les écrans de télé, les voitures, les wearables et puis d’autres choses dont on parlera plus tard, j’imagine.

Camille (02:07) : Bonjour, moi, c’est Camille Blin. Je suis chez Deezer depuis sept ans maintenant et je suis Engineering Manager. Je m’occupe de l’équipe Android et iOS qui va développer les applications pour tout les hardware, donc tout ce que vient de décrire Hugo — tous les big screens, les wearables, automotive, etc.

Loic (02:25) : Ok. Pour commencer, est-ce que vous pourriez décrire un petit peu votre équipe/startup — puisque c’est comme ça que l’on appelle les départements à Deezer ?

Nicolas (02:35) : Notre startup, c’est Partnership Integration. On fait partie de la division Product & Tech chez Deezer. En gros, on a plusieurs grandes missions. La première, ça va être de doter Deezer des outils et des capacités de mettre en place des partenariats commerciaux — B2B ou B2B2C — au travers de divers mécanismes techniques — des API, des SDK, etc. — et également tout ce qui est customer journey, customer-facing, pour permettre, main dans la main avec les équipes commerciales, de mettre en place des partenariats stratégiques B2B. On réalise aussi des partenariats techniques qui n’ont pas forcément de visée commerciale. On va aussi permettre des interactions entre des comptes utilisateurs Deezer et des écosystèmes tiers, comme par exemple pouvoir utiliser des liaisons entre une app de dating et ton compte Deezer — permettre de mettre en favori des tracks, etc. Et une grosse partie de nos occupations — et c’est le sujet qui nous amène aujourd’hui, ce sont les intégrations hardware, donc dans les objets connectés — ce que Hugo et Camille ont cité précédemment et sur lesquels on va revenir — smart TV, cars, wearables, etc.

Vincent (03:46) : Quels genres de partenaires et à peu près combien de partenariats a-t-on chez Deezer ?

Nicolas (03:51) : Au sens large, on a une cinquantaine de gros partenariats B2B stratégiques et on a un peu plus de 80 intégrations sur des objets connectés — ce que l’on appelle le hardware chez nous.

Hugo (04:03) : On a trois grands types de partenariats. On a des partenariats commerciaux. Une première famille sur les Telco : on a Orange, SFR, TIM au Brésil. On a une deuxième partie qui concerne les retailers : Fnac-Darty, Mercado Libre, qui est le leader du e-commerce en Amérique latine et qui, dans son programme d’abonnement, a intégré la musique — du coup, c’est la musique par Deezer, un peu comme Amazon Prime et Amazon Music. La deuxième famille, c’est les intégrations externes ou en marque blanche : avec évidemment RTL, entreprise de médias allemande, où l’on met à disposition, au sein de l’app RTL et en marque blanche, notre savoir-faire à travers des SDK — des kits de développement qui nous permettent d’être intégré à des interfaces externes. Dans une autre mesure, on a le widget de Deezer. Et ensuite, on a une troisième famille dont on va beaucoup parler aujourd’hui, c’est les intégrations en propre de type hardware : pour les différencier, on a les wearables (Apple Watch, Android Wear OS, Garmin, Fitbit), les big screens (avec les connected TV LG et Samsung entre autres, Android TV, Apple TV qui est sortie très récemment), les cars (avec Android Auto, CarPlay et Google Automotive), et les voice assistants (avec Sonos Voice Control et Alexa). C’est un marché très hétérogène qui regroupe des grands acteurs comme Google, Apple, Amazon, Sonos, Samsung, mais aussi des plus petits acteurs ou des acteurs indépendants type Cabasse ou Yamaha.

Vincent (05:37) : Comment arrive-t-on à gérer cette multitude de partenariats ? Parce que j’imagine que c’est compliqué de pouvoir re-tester systématiquement que tout fonctionne correctement sur chaque partenariat dès que l’on fait une mise à jour ?

Nicolas (05:48) : C’est un gros challenge. Ça demande beaucoup de ressources et surtout beaucoup de temps. Quand on parle de partenaires, on parle forcément de contraintes externes — contraintes, pas forcément dans un sens négatif, avec le partenaire. On a la charge à la fois des partenaires commerciaux et des intégrations hardware, du coup, c’est un peu un challenge permanent pour cumuler ces deux verticales. Mais on y arrive plutôt bien, je trouve. Il faut penser aussi au fait que lorsque l’on lance un partenariat, après, il faut quand même être prêt à passer du temps aux évolutions de ce partenariat. Si l’on parle plus précisément du hardware, ça nécessite des évolutions, de suivre les évolutions du hardware aussi. Le risque, c’est que dédier peu de temps aux évolutions inhérentes aux partenariats hardware, c’est aussi prendre le risque de cumuler de la dette technique. Du coup, tout est question de priorisation, de tempo et de re-priorisation. Hugo, tu veux ajouter quelque chose ?

Hugo (06:51) : Oui, sur la partie hardware, on essaye de gérer cette multitude de partenaires en diversifiant les méthodes de développement et de gestion. En gros, on a des partenaires qui nous aident pour la gestion des intégrations “non-stratégiques” au quotidien. Là, par exemple, on travaille avec Airable, qui gère la récupération du contenu Deezer, qui gère le normage et qui le distribue à un maximum d’intégrations. C’est un partenaire qui gère l’interfaçage. L’avantage pour nous, c’est de toucher un maximum d’intégrations pour très peu d’efforts. C’est très scalable. Et de manière générale, on cherche vraiment la scalabilité sur ce genre de sujet sinon ça représente trop d’efforts pour nous. On s’appuie aussi sur des agences de développement. Là, par exemple, pour nos applications LG et Samsung, on a fait appel à une société qui s’appelle Dotscreen, qui est une agence de développement parisienne spécialisée, entre autres, dans les apps télé. On a aussi, des fois, des ressources externes avec, par exemple, notre application Orange TV qui est développée et gérée par des équipes Orange dédiées. Donc il y a des développeurs et un product manager chez eux qui gèrent ça pour nous. Et on a évidemment aussi — on y reviendra plus tard — des équipes de développement en interne, dont Camille est le représentant aujourd’hui. Plus, on a une grosse équipe de “solution managers” qui gèrent ces partenaires au day-to-day.

Loic (08:15) : D’accord. Du coup, tu disais que l’on a un partenaire qui nous sert d’intermédiaire technique. Ça représente quoi comme type d’intégrations, ce genre de partenaire ?

Nicolas (08:24) : On a deux types d’intégration, on va dire. Les intégrations avec des gros partenaires sont gérées en direct chez nous — je pense à Alexa avec Amazon, je pense à Google Home avec Google, etc. Après, on a effectivement cette tierce partie qu’évoquait Hugo, qui va automatiser l’intégration de nos solutions en faisant l’interface entre le fabricant et nous. Eux, ils ont intégré, de façon automatique, nos solutions. Et du coup, là, on parle essentiellement de matériel Hi-Fi de type Denon, Cabasse, etc. On essaye de déléguer toute cette partie-là le plus possible, sur ce que j’appellerais le “tout-venant”, pour rendre Deezer accessible sur le plus de devices possibles. Et quand il s’agit de grosses intégrations sur lesquelles il y a une réflexion produit beaucoup plus poussée, on le fait en interne.

Loic (09:20) : D’accord, donc ça permet d’avoir vraiment une disponibilité quasiment sur tous les devices sans que l’on ait vraiment à intervenir, ni même à se poser la question au final.

Nicolas (09:27) : Sur un maximum, en tout cas, oui.

Loic (09:28) : Sûrement pas tout, évidemment !

Nicolas (09:29) : Mais ça viendra !

Loic (09:31) : Du coup, c’est le partenaire qui doit gérer cette partie d’intégration au niveau des hardware directement ?

Nicolas (09:38) : C’est notre prestataire qui gère ça directement avec les manufacturers, les fabricants, et il est rémunéré pour ça.

Hugo (09:47) : En gros, c’est un business model hyper intéressant pour nous parce que l’on n’a pas la capacité de répondre à des intégrations qui auraient toutes leurs spécificités. Là, il y a le rapport coût/avantage qui rentre en jeu. Sans cet acteur-là, sans cette aide-là, il y a plein d’intégrations que l’on n’aurait pas décidé de viser.

Loic (10:06) : Parce que c’est trop niche, il n’y a pas assez de cas.

Hugo (10:09) : Oui, exactement, c’est ça.

Loic (10:09) : En gros, peut-être que le petit fabricant qui doit avoir sa manne de clients, je ne sais pas, au Brésil uniquement, ça permet de le gérer tout en étant loin des problématiques purement techniques.

Hugo (10:23) : Oui, ça permet ça. Et donc mis bout à bout, ça finit par faire une part de gâteau assez intéressante. Avec une vue unitaire, non.

Vincent (10:34) : Et par rapport aux plus gros partenaires, on leur propose quel genre d’intégration ? Quel genre de service ? Comment fonctionne-t-on avec eux ? Tu citais, par exemple, RTL ou Mercado Libre. Comment on travaille avec eux ? Qu’est-ce qu’on leur propose ?

Nicolas (10:47) : Ce sont deux types de partenariats différents. Mercado Libre, ça va être un partenariat de distribution. En gros, eux, ils se positionnent comme l’équivalent d’Amazon au LATAM, en Amérique latine. En souscrivant à l’équivalent de l’Amazon Prime local, Meli+, tu bénéficies d’une période de gratuité de Deezer. Donc en souscrivant à leur plan Prime, tu vas avoir tout un tas de services associés dont fait partie Deezer, et il y a aussi des services de SVOD, etc. Pour nous, c’est de la distribution à grande échelle, c’est du coût partagé avec le partenaire et c’est surtout une grosse empreinte pour Deezer dans les pays d’Amérique latine concernés — il y en a quatre. Pour RTL, c’est complètement différent. Eux, ils ont fait le choix de proposer ce qu’ils appellent une “multi-purpose app”, c’est-à-dire de proposer au sein d’une même application plein de contenus différents. On parle, là, de VOD — puisque c’est le cœur de métier de l’app RTL+, on parle de musique et d’audiobooks avec Deezer, on parle de podcasts et on parle de presse également. Ils ont agrégé un certain nombre de contenus différents au sein d’une même application. Et du coup, le principe, c’est que pour une seule facture, un seul abonnement, leur client allemand — c’est en Allemagne — peut bénéficier de toute cette couverture de contenus.

Loic (12:16) : D’un point de vue technique, pour nous, quelle va être la différence entre de l’intégration hardware — que ce soit via des partenaires ou même en direct — et des partenariats moins hardware — on citait RTL tout à l’heure ? Quelles implications ont, d’un point de vue technique, ces deux types de partenariats ?

Camille (12:34) : Ces deux partenariats sont un peu différents, en effet. Quand on va faire les grosses intégrations chez nous, c’est vraiment les partenariats avec Google, Apple, etc. Là, on va vraiment avoir un gros développement de notre côté. La plupart du temps, il va s’agir de développer sur les nouvelles plateformes qui viennent de sortir — Wear OS ou alors Apple TV, Android TV, etc. Alors que pour un partenariat comme RTL, on va leur donner accès à un SDK que l’on a déjà développé en amont et ça va leur permettre de créer leur propre application. Comme on en a parlé tout à l’heure, c’est la “multi-purpose app”. En gros, on va leur donner ce qu’on appelle le SDK, qui est une brique de player Deezer qui permet de jouer de la musique sur leur application. Ce sont eux qui vont intégrer tout ça. Nous, on est juste là en support : on va les aider à intégrer s’ils ont des questions, s’ils ont des bugs qui sont remontés, on va corriger tout ça, etc., mais on est vraiment sur du support. Alors qu’en effet, quand on arrive plus sur les grosses intégrations chez nous, là, c’est toute une équipe qu’on a dans la startup Partnership. On a une équipe Android, une équipe iOS, une équipe Web qui vont s’atteler à créer le produit Deezer de A à Z pour ces grosses intégrations.

Loic (13:40) : Et d’un point de vue purement hardware, ce sont les mêmes SDK que l’on fournit pour l’intégration dans une voiture, par exemple ?

Camille (13:46) : Ça va dépendre. Les intégrations sur les voitures sont assez différentes entre les plateformes. Sur les voitures, on en a deux. On en a une sur Android et une sur Apple — on va dire ça comme ça. On a CarPlay sur Apple, qui est juste une application de mirroring, c’est-à-dire que c’est l’application mobile qui est connectée à l’autoradio qui va donner les informations, et l’interface qui va être affichée dans la voiture. Ça se passe comme ça sur Apple. Par contre, sur Android, on va avoir deux intégrations qui sont différentes. On va avoir Android Auto, qui ressemble à peu près à ce qu’il y a sur CarPlay. Et on a aussi développé tout ce qui va être Android Automotive OS. Là, c’est une application qui est totalement “standalone”, qui marche toute seule, comme une application mobile ou comme une application TV. C’est une application que l’on a développée “from scratch”, qui est spécifique à ce système-là.

Loic (14:35) : Que l’on a fait chez nous, nous-mêmes.

Camille (14:36) : C’est quelque chose que l’on a fait chez nous, nous-mêmes, par l’équipe Android. Et là, en effet, le SDK que l’on donne à nos partenaires, on l’utilise aussi pour ce genre d’application. Ce SDK, en gros, est créé pour trois plateformes. On l’a créé pour Android, on l’a créé pour Apple et on l’utilise aussi sur le Web. Sur Android, en effet, on l’a utilisé sur Automotive OS et on l’utilise aussi sur notre application de montre. Sur Apple, on va l’utiliser sur l’application de montre et sur notre application de TV. Il y a vraiment cette brique commune qui est utilisée — le player — entre toutes nos intégrations.

Vincent (15:10) : Là, on est dans un cas où l’on peut fournir l’application complètement par rapport à un contexte donné. Est-ce que quand on est sur des intégrations de type enceintes connectées ou des choses dans ce genre-là, on agit exactement de la même manière ? Ou est-ce que l’on a des contraintes différentes ?

Camille (15:27) : Les enceintes connectées, c’est un autre système. Les enceintes connectées, c’est vraiment du hardware qui est propre à chaque partenaire. On ne va pas forcément leur donner de SDK parce qu’il va y avoir des systèmes qui sont totalement différents, avec des langages totalement différents, et on n’a pas la capacité de créer un SDK par hardware de ce type. Donc on va surtout leur donner accès à nos médias, à un service qui va leur donner la possibilité de récupérer des médias chez Deezer. Il y a tout un système d’API qui permet de récupérer ces médias de façon sécurisée avec tout ce qui est chiffrage, etc. Donc eux, ils vont pouvoir récupérer tous ces médias-là et les jouer sur leurs enceintes connectées s’ils veulent. Ça peut être ça, mais c’est aussi un peu différent au niveau des voice assistants. Ça, c’est encore quelque chose de différent.

Loic (16:24) : Qu’est-ce qui est différent entre travailler avec un partenaire et travailler avec des équipes en interne ? D’un point de vue décisions produit peut-être, ou d’un point de vue… On a parlé de choix techniques, mais on peut aussi parler de : qu’est-ce qu’on fait avec la musique ? Qu’est-ce que le partenaire va faire avec la musique ? Qu’est-ce qui va être différent entre un partenaire hardware, les autres types de partenaires, voire des équipes internes, par exemple ?

Hugo (16:50) : Je ne sais pas si je réponds vraiment à la question, mais je vais essayer d’apporter des clés de compréhension. Il y a des grosses contraintes fonctionnelles. La UI et la UX peuvent être très particulières. Exemple sur la voiture — Camille en parlait : on se doit de respecter les interfaces qui nous sont imposées et qui sont là pour favoriser la sécurité. Il y a plein de choses que l’on aimerait faire, mais que l’on ne peut pas faire. Idem sur les wearables où l’on doit favoriser l’accessibilité sur un tout petit écran. Donc ce que l’on ne peut pas faire, ce serait répliquer l’expérience Deezer sur ces interfaces-là. Ce n’est pas permis, et ce n’est pas permis parce que ce n’est pas souhaité. Donc il y a des grosses contraintes de UI et de UX.

Vincent (17:34) : Tu aurais un exemple de choses que l’on aurait voulu faire mais que l’on ne peut pas faire ? Sur l’auto, par exemple ?

Hugo (17:39) : Oui, sur la voiture, l’idée d’avoir une Flow wheel nous est rapidement venue à l’esprit. Mais en fait, ce sont des choses qui ne sont pas du tout autorisées. Par exemple, sur Automotive, ce qui se fait beaucoup sur iOS et sur Android, ce sont des “cards”, des rectangles qui nous permettent d’afficher des playlists, des albums, des tracks, etc., mais tout ce qui serait relatif à une vue custom, ce qu’est vraiment la Flow wheel, ce n’est juste pas permis.

Vincent (18:07) : Pour ceux qui prendraient le podcast en cours de route, la Flow wheel, c’est cette roue que l’on peut trouver sur l’appli mobile pour orienter Flow selon tel ou tel mood, ou tel ou tel genre. Donc ok, ce genre de choses, on ne peut pas et on le proposerait donc plutôt sous forme de “card” en disant : j’ai une card “Motivation”, une card “Chill”, une card…

Hugo (18:29) : Exactement, c’est ça. Et sur la watch, un autre exemple. On a récemment développé une application pour les Google smartwatches sous Wear OS 3, qui est le dernier OS développé par Google. On avait deux possibilités. C’était soit de réutiliser les libs qui sont fournies par Google, et donc être hyper respectueux du design system de Google. L’avantage, c’était que c’était très rapide pour nous. L’inconvénient, c’est que l’on avait potentiellement moins d’identité par rapport à des concurrents. L’autre solution, c’était de repartir sur un autre design system, etc. Là, pour des raisons logiques de praticité, de temps, etc, on est parti sur la lib de Google, qui permet moins de choses mais qui est plus rapide à intégrer. Parfois on n’a pas le choix, parfois on a le choix mais on fait le choix d’utiliser ce qui nous est offert pour des raisons de praticité.

Nicolas (19:16) : Et puis, tu as aussi des contraintes techniques inhérentes à une smartwatch par exemple, avec des capacités de CPU ou de RAM qui sont toutes petites, qui t’obligent à tailler dans le gras aussi un peu.

Vincent (19:26) : Un peu comme on faisait dans les premières expériences mobiles où l’on devait avoir des trucs très simples.

Nicolas (19:32) : Absolument.

Hugo (19:33) : La testabilité, c’est aussi un sujet assez relatif au hardware. Je pense, par exemple, à tester une interface dans une voiture. On a des émulateurs qui nous permettent de tester les interfaces CarPlay, etc. Des fois, c’est plus compliqué. On aurait besoin d’une vraie voiture et ça nous est arrivé de nous déplacer chez des partenaires pour tester les intégrations. Ça, c’est aussi un enjeu. La voice aussi est un enjeu puisque l’on doit penser des parcours sans écrans sur lesquels on pourrait cliquer…

Loic (20:02) : Comme les assistants vocaux, au final.

Hugo (20:05) : Exactement, c’est ça. C’est un enjeu qui est hyper intéressant pour nous mais qui rajoute quand même une couche de complexité. Et au-delà de ces contraintes fonctionnelles, les partenariats induisent certaines spécificités, notamment dans la gestion de projet où l’on doit gérer, quelque part, du “co-management” — donc une équipe dans une entreprise A, Deezer, et une équipe dans une entreprise B. On doit travailler ensemble, on doit faire du reporting, on doit, chacun, s’adapter aux méthodologies de l’autre. Ce n’est pas évident. On est soumis aux mêmes règles que les autres entreprises mais c’est vrai que, sur cette partie-là, le timing est clé. On a très souvent des dates qu’il faut scrupuleusement respecter. Je pense, par exemple, à des release dates de devices ou des release dates d’OS. Par exemple, quand on a un nouvel OS qui sort, ou un Apple Vision qui sort, ou un Apple HomePod, etc. Être prêts le jour J, c’est hyper important pour nous parce que ça nous permet de bénéficier de toute la stratégie de communication et de marketing du partenaire qui, en général, est un gros partenaire qui n’a pas lésiné sur les moyens.

Loic (21:17) : Ce n’est pas très gros, Apple.

Hugo (21:20) : Ça nous est souvent arrivé de vouloir absolument être prêts le jour J pour bénéficier de cette force de frappe. Et dans le cadre de ces partenariats, on a aussi très souvent des dates de lancement qui sont imposées par le partenaire, et en général, on ne peut pas y échapper.

Nicolas (21:37) : Ça, c’est vraiment une spécificité des partenariats, c’est que les moyens produit et techniques que l’on va mettre en œuvre pour répondre à un partenaire doivent être concomitants avec sa fenêtre de tir, de son côté. Comme le disait Hugo, il y a des deadlines qui font que la différence de fonctionnement avec des équipes à l’interne, c’est que de Deezer à Deezer, on est à peu près libre de définir notre timeline et la deadline de fin de projet, ce qui n’est jamais le cas en partenariat — c’est un peu le principe. Donc, pour ce faire, on a quand même développé une grosse expertise de gestion des partenaires chez Deezer en s’organisant de façon à ce que l’on puisse être assez souples et avoir la puissance de feu nécessaire pour répondre à tous nos partenariats.

Loic (22:23) : Elle se manifeste comment, cette organisation ?

Nicolas (22:27) : On a une startup dédiée qui est intégrée, c’est-à-dire qu’elle a ses propres équipes produit, ses propres équipes de développeurs, une équipe de solution managers qu’Hugo évoquait juste avant, qui vont avoir des compétences à la fois produit, tech et pre-sales, qui vont être capables de travailler à l’interne avec des équipes Legal, avec des équipes en relation avec les labels, avec évidemment les équipes commerciales, etc. Donc, une grosse équipe pluridisciplinaire avec, bien évidemment, les capacités de parler aux bons interlocuteurs côté partenaires.

Vincent (23:03) : Comment ça se passe quand on met en place un partenariat ? Est-ce que ce sont, en général, plutôt les fabricants qui viennent vers nous pour que l’on propose notre service sur leur matos ? Ou est-ce que c’est Deezer qui va voir les fabricants pour essayer d’avoir une plus grande exposition ? Est-ce que c’est un mix des deux ?

Nicolas (23:25) : Je dirais que c’est les deux. Il y a des objets connectés, il y a du hardware sur lequel on ne peut pas faire l’impasse de toute façon, parce qu’il y a une attente du côté de nos utilisateurs, parce que c’est trendy, parce que c’est le hardware du moment… Nous n’avons pas de relations commerciales avec Amazon sur Alexa mais il faut être présent sur Alexa, par exemple. Et on a aussi, de l’autre côté, des fabricants qui font appel à nous. Dans ces cas-là, selon l’ambition, selon l’empreinte du fabricant, selon notre disponibilité, on va ou les rediriger vers un prestataire qui va faire faire l’intégration pour nous ou prendre en compte cette intégration en interne et la réaliser nous-mêmes.

Loic (24:05) : Comment fait-on pour savoir quels sont les hardware “trendy”, justement, où il faut être ?

Nicolas (24:11) : On va à la Fnac !

Loic (24:13) : J’adore cette réponse, ça me va ! D’ailleurs, juste comme ça, si jamais vous n’êtes pas au courant, vous avez trois mois de Deezer d’offerts si vous achetez…

Nicolas (24:21) : “N’oubliez pas de demander votre carte POSA lorsque vous achetez un produit Hi-Fi ou non Hi-Fi” !

Hugo (24:27) : Il y a évidemment une grosse part de veille. Notre avantage, c’est que faire de la veille sur un domaine de l’entertainment est quand même plus facile que de faire de la veille sur une micro-niche. Et comme on est utilisateur de Deezer et qu’on est aussi utilisateur d’autres applicatifs de type hardware — qui relèvent toujours un peu du fun quelque part, c’est beaucoup plus facile de faire cette veille. Donc on la fait tous, plus ou moins. Et puis, on a accès à de la data qui nous permet d’avoir des market shares, etc. L’autre moyen pour nous d’être prêts à temps ou en avance, c’est que l’on a quand même des bonnes relations avec certains grands partenaires. Je pense à Google, avec qui l’on a pris l’habitude de se parler quand même assez fréquemment — on n’est jamais au courant d’infos secrètes mais on a quand même des clés de compréhension sur leur roadmap à court/moyen terme. Souvent, on apprend des choses avant d’aller à la Google I/O. Ça nous permet d’être au courant de features ou de releases de devices et de capter une espèce de tendance d’usage qui est impulsée par un gros acteur. Et on s’imagine que l’impulsion d’un Google va sans doute un peu modifier le marché et qu’on ne va pas se tromper de direction. Donc ça aussi, ça nous aide pas mal.

Nicolas (25:47) : Avec le temps, on a créé une relation de confiance avec des gros partenaires, pas forcément chez les GAFAM mais aussi ailleurs. Ça nous permet également d’avoir accès, en avant-première, à des kits de développement ou à du matériel non sorti encore, ce qui va nous permettre d’en réaliser l’intégration, de pouvoir tester, etc. Bien sûr, sous protection juridique, non-disclosure agreements, etc. On a quand même réussi à tisser des liens forts avec des gros partenaires donc on bénéficie aussi de leur largesse.

Loic (26:22) : Ça veut dire que l’on a pas mal d’équipements disponibles en interne pour découvrir et tester ?

Nicolas (26:27) : Absolument, mais ils sont sous clé.

Loic (26:30) : D’accord. Par contre, je n’ai pas vu le garage avec toutes les BMW.

Nicolas (26:33) : C’est chez moi !

Hugo (26:36) : On a pas mal de devices, oui. On en a chez Deezer. J’allais dire : “on en a chez nous” !

Nicolas (26:46) : C’est important de tester le week-end aussi, oui !

Loic (26:51) : Blague mise à part, ce que l’on appelle le “dogfooding” — terme qui a été popularisé par Google et qui est l’idée de tester ses propres produits — nécessite probablement d’aller au-delà simplement du “de 8h00 à 18h00, je vais jouer avec le nouveau device”. C’est aussi, potentiellement, de le tester dans des conditions réelles. Comme vous le disiez, vous êtes utilisateurs, on est utilisateur de Deezer, donc on va avoir une opinion et un retour qui vont être précieux, aussi bien pour le débogage que pour l’intégration.

Hugo (27:19) : Si tu te limites à utiliser, par exemple, un wearable de trois à quatre heures parce que tu n’as pas de meeting et que tu peux faire une phase de test, c’est vrai que ça va être un peu compliqué. Ce que l’on préconise, c’est quand même de prendre un device, un wearable, de le mettre à son poignet et de le tester comme un vrai utilisateur…

Loic (27:39) : Oui, d’aller courir avec.

Hugo (27:40) : …qui a fait l’effort de l’acheter à un certain prix. On prend aussi ça en compte. En général, les users qui ont payé leur device 500 euros, ils attendent de la qualité. Donc oui, il faut une utilisation dans des vraies conditions.

Nicolas (27:51) : Il y a des tests en QA, il y a des tests fonctionnels qui vont s’attacher à tester des workflows, qui vont s’attacher à tester des features dans tous les sens. Et comme l’a dit Hugo, il est aussi important d’avoir une approche un peu plus classique, humaine, de l’utilisation d’un device, parce que ça peut aussi permettre de se rendre compte de choses qui seraient passées au travers du radar de nos tests fonctionnels.

Camille (28:15) : Notre équipe QA revient souvent après le week-end, le lundi, en ayant testé la montre et en disant: “J’ai couru un petit jogging le matin, j’ai trouvé un bug”. Donc ils reviennent, ils nous font un petit ticket le matin directement. Ou alors sur la voiture. C’est pareil, on a beaucoup d’utilisateurs sur les voitures, sur CarPlay ou sur Android Auto, et c’est souvent ça : le week-end, le vendredi soir, ils partent, et des fois, on a des messages directement le vendredi soir parce qu’ils ont eu un problème. C’est vrai que tout le monde utilise nos applications et nos intégrations quasiment tous les jours.

Vincent (29:02) : Est-il arrivé, dans le cadre de la mise en place d’un partenariat pour de l’intégration hardware, que l’on soit obligé de développer ou de nouvelles features ou d’étendre un peu des choses par rapport à ce que l’on propose en actif ?

Nicolas (29:14) : Ça a pu arriver. Je pense notamment à un fabricant de wearables dédiés au sport. De par les contraintes techniques de la smartwatch ou des smartwatches que l’on visait, il a fallu penser une nouvelle façon de délivrer des médias, notamment réencoder nos médias, non pas en MP3 mais dans un autre format, le format SBC. C’était du réencodage à la volée parce qu’il y avait une fonctionnalité de download sur la smartwatch. Du coup, lorsqu’on téléchargeait une playlist, les tracks étaient encodées en SBC à la volée parce que c’est moins lourd, que ça permet pas trop de pertes de qualité et que c’était surtout beaucoup plus concevable dans ce cas d’utilisation-là. Sinon, on a aussi pu faire évoluer certains de nos outils. Je pense notamment à tout ce qui est SDK, voire même le player. Pour le coup, pas pour un partenaire de hardware mais plutôt pour un autre partenaire où l’on faisait de l’intégration média. On a pris cette occasion pour refaire player et SDK. Il se trouve qu’en termes d’applications, on réutilise ces innovations dans des intégrations hardware — je pense notamment à Wear OS.

Camille (30:33) : C’est ça. Le SDK que l’on a redéveloppé pour un partenaire est maintenant utilisé dans toutes les intégrations hardware que l’on développe dans la startup. C’est une base de travail commune qui est vraiment intéressante parce que ça nous permet maintenant de créer des nouvelles applications. Parce qu’à chaque fois qu’il y a une nouvelle intégration hardware, c’est une nouvelle application à créer, donc ça prend quand même pas mal de temps, c’est un nouveau projet “from scratch” à faire. Cette brique qui est commune nous permet d’avoir une petite application qui permet de jouer de la musique en une semaine, deux semaines, donc c’est vraiment intéressant. Après, on n’a quasiment plus qu’à se concentrer sur le produit, créer l’expérience nouvelle de cette nouvelle plateforme, de cette nouvelle surface. C’est ça qui est intéressant, c’est que l’on prend beaucoup moins de temps sur le métier Deezer en tant que tel et on va plus essayer de se focaliser sur ce que l’on peut apporter à l’utilisateur sur cette nouvelle surface.

Loic (31:22) : Est-ce que l’on a des limitations contractuelles vis-à-vis de notre catalogue et de son utilisation, par rapport aux usages faits par des partenaires ?

Nicolas (31:30) : Oui, il y a tout un cahier des charges à respecter. Il faut savoir que chaque partenariat — commercial — doit être validé par nos ayants droit, donc les trois grosses majors et les représentants des autres labels un peu moins importants en termes de taille. Ça, c’est pour nos partenariats commerciaux, B2B. Pour tout ce qui est mise à disposition de ce que l’on appelle dans le langage des “phonogrammes”, donc les morceaux de musique, oui, il y a déjà des contraintes de sécurité à respecter. On va devoir proposer et faire valider des systèmes qui vont permettre la sécurisation des phonogrammes qui sont mis à notre disposition par les ayants droit, qui continuent de les posséder — nous, on utilise un matériel musical qui est mis à notre disposition, en général. C’est audité régulièrement et on se doit d’apporter et de faire évoluer ces solutions qui permettent la sécurisation de ces contenus. Après, en termes de devices que l’on va pouvoir cibler, c’est aussi soumis à des négociations avec nos ayants droit. Il y a certains types d’expériences — je pense, notamment, à des expériences en freemium — que l’on ne peut pas proposer sur certains devices parce qu’elles ne sont pas encore validées par les ayants droit.

Vincent (32:46) : Ok. Du coup, ce que j’en comprends, c’est qu’il y a beaucoup d’applications qui sont générées pour nos intégrations hardware. À chaque fois, c’est une nouvelle application, c’est ce que tu disais, Camille. Comment gère-t-on la maintenance de toutes ces applications en termes de mises à jour, en termes d’évolutions ?

Camille (33:01) : Ça peut être assez compliqué parce que, même si on l’a moins maintenant, avant, on pouvait avoir des applications qui étaient différentes par store de partenaire — vu que là, on parle quand même d’applications natives. Je ne sais pas si vous savez comment sont distribuées les applications sur la plupart des plateformes, mais on passe par des stores qui appartiennent à Google, Apple, etc., qui valident les applications avant de les distribuer sur leurs appareils. On a l’habitude, justement, du Play Store, de l’Apple Store, sauf qu’on a aussi beaucoup de partenaires qui ont leur propre store. Parfois, on avait aussi des applications qui étaient un peu modifiées sur ces stores-là. Maintenant, on essaye d’avoir une seule application qui est identique pour tous les stores. Du coup, on a beaucoup moins de difficultés de maintenance là-dessus, en tout cas au niveau développement. Par contre, ça veut dire qu’à chaque fois que l’on fait une modification dans l’application, que l’on fait un ajout de fonctionnalités, etc., il va falloir que l’on déploie cette nouvelle application dans tous les stores partenaires. Parfois, c’est plus ça qui va prendre du temps. Après, pour la mise à jour chez les clients, c’est géré par le partenaire donc c’est beaucoup plus facile pour nous. Pour tout ce qui est application native, c’est ça en termes de maintenance. On arrive maintenant à maintenir assez facilement nos applications.

Vincent (34:10) : D’accord. Ça représente à peu près combien de stores à la louche ? Des dizaines ?

Camille (34:16) : C’est surtout sur Android que l’on a cette particularité. Sur iOS, il n’y a pas ce système. En termes de stores, on en a — je dirais — une dizaine, quasiment, à gérer.

Hugo (34:29) : Plus les télés.

Nicolas (34:30) : Oui, plus les smart TV.

Camille (34:30) : Plus les télés, oui.

Vincent (34:31) : Donc, à chaque fois, soumettre l’application, attendre la validation, traiter les retours ?

Camille (34:36) : C’est ça. Ça peut prendre un peu de temps. En gros, de toute façon, on sait très bien que quand on a fait une modification dans une application, on met quasiment un mois pour la mettre dans la main d’un utilisateur. Donc, après nous — la validation de la soumission, que l’on est d’accord avec ce que l’on va soumettre, etc., une fois qu’on l’a soumise dans le store, c’est la vérification de tous ces partenaires qui va peut-être prendre du temps. Des fois, ça prend un jour, des fois, ça peut prendre jusqu’à deux semaines. On ne sait jamais réellement le temps d’attente que l’on va avoir à ce niveau-là. C’est ça qui peut être un peu pénible si on a vraiment un correctif de fix à faire très rapidement. Parfois, on a des bons liens avec les partenaires et ça va nous permettre de leur dire : “On aimerait bien que cette version sorte rapidement”. Donc on peut leur dire. Après, ce sont des jetons que l’on a à l’année, on va dire. On ne peut pas leur dire ça toutes les semaines non plus. Des fois, ils sont assez sympas et ils nous disent: “OK, celle-là, on va la valider rapidement”. Et elle sort assez rapidement. Mais c’est toujours un peu l’inconnu quand on veut faire une maintenance.

Vincent (35:31) : Et vous avez aussi des retours ? J’imagine qu’il y a des retours que vous devez recevoir par les utilisateurs finaux. Est-ce qu’il y a aussi les marques avec lesquelles on travaille qui vous remontent des soucis qu’il faut que l’on traite ?

Hugo (35:43) : Ça nous arrive. On n’a pas des threads constamment ouverts avec ces manufacturers mais, en tout cas, on a un moyen de les contacter assez facilement. C’est réciproque. Quand il y a des alertes, des remarques, des questions, etc., ils nous contactent. Ça rend cette maintenance encore un petit peu plus complexe parce qu’elle est aussi humaine. Il s’agit de parler à des gens dans d’autres entreprises, leur expliquer pourquoi on a fait ce choix-là, leur expliquer que l’on va résoudre le bug d’ici trois, quatre semaines potentiellement, de leur dire aussi que le user peut se tromper. On a le Customer Care au sein de Deezer et on a aussi d’autres Customer Care dans d’autres sociétés.

Vincent (36:27) : Oui, parce que j’imagine que l’utilisateur final ne doit pas toujours savoir s’il faut qu’il remonte le problème à Deezer parce qu’il est en train d’écouter de la musique avec Deezer ou au manufacturer parce qu’il est en train de regarder sur sa télé…

Hugo (36:37) : Et dans le sens inverse, ça nous arrive aussi pas mal de contacter des manufacturers pour leur faire part d’un problème chez eux. Donc là, on est dans le modèle inverse. C’est le user qui vient voir Deezer pour lui remonter un problème. On se rend compte / on sait que ce n’est pas de notre faute, donc là, on contacte le manufacturer pour qu’il corrige le problème lui-même. Et ensuite, on vient contacter le Customer Care pour lui dire que c’est réglé, une fois que l’on a reçu la validation du partenaire. Ce sont des process qui sont parfois un peu farfelus !

Vincent (37:03) : Ce qui est un peu plus compliqué que quand on a nos utilisateurs de l’application Deezer en direct où là, on sait qu’a priori, c’est plutôt chez nous — même si l’on pourrait dire que si c’est sur le téléphone, ça peut être le téléphone qui couine. En gros, on a vraiment un troisième larron qui vient donc ça doit compliquer la communication, j’imagine ?

Hugo (37:22) : Non, c’est un challenge de plus mais c’est intéressant parce que ça nous permet de mieux comprendre l’écosystème du partenaire, des fois, de mieux comprendre comment ça marche et de nous adapter. Mais ça peut être chronophage, oui.

Nicolas (37:37) : La multiplicité des partenaires en augmente la complexité, on va dire.

Hugo (37:43) : C’est pour ça que… Tout à l’heure, on parlait du rapport coût/avantage. On se pose la question avant d’adresser un marché parce que ça ne s’arrête pas au moment où l’on a délivré l’applicatif. Ça continue sur des cycles de trois, quatre ans, des fois plus. Et accumuler de la dette technique sur un applicatif qui est peu stable et qui a une part de marché qui laisse à désirer… Le coût de cette maintenance rentre dans le coût, forcément. Maintenant, on arrive à le quantifier plutôt bien.

Camille (38:12) : Et après, la maintenance est aussi totalement différente en fonction des plateformes. Là, on parle beaucoup de mobile, où c’est assez rapide, et puis les téléphones sont quand même mis à jour assez régulièrement, etc. Les montres, c’est à peu près pareil. Mais dès que l’on va parler de télévision ou dès que l’on va parler de voiture, là, on va être dans des systèmes qui sont beaucoup plus lents. On est sur des grosses entreprises avec des systèmes qui peuvent durer jusqu’à dix ou quinze ans sur une voiture, un système Automotive. Une fois que la voiture est sortie, c’est rarement mis à jour. Je ne sais pas s’il y a beaucoup de personnes qui s’amusent à mettre à jour leur système Automotive. Je suis pas sûr qu’il y en ait beaucoup ! Les télés, c’est pareil : ce sont quand même des choses, une fois qu’on l’a achetée, ça dure quasiment dix ans. On ne peut pas se permettre non plus de dire au bout de deux ans d’utilisation : “Désolé, rachetez une nouvelle télé pour avoir la nouvelle application Deezer”. Donc on est quand même obligé de maintenir, parfois, des applications sur des vieux systèmes. On est un peu obligé de faire ça.

Loic (39:02) : Ce n’est pas plus mal aussi parce que d’un point de vue écologie, on doit aussi diminuer au maximum ce que l’on appelle l’”e-waste”, c’est-à-dire le fait de devoir jeter nos appareils électroniques juste pour des raisons un peu absurdes comme “la version de l’OS ne le supporte plus”. Soutenir des applications très vieilles réduit d’une certaine manière cette quantité de déchets, de manière plus ou moins significative — je n’ai pas de chiffres mais dans l’idée, c’est ça. Pour en avoir parlé dans des discussions sur le développement mobile, on essaye de le faire ou on a essayé de le faire aussi pendant très longtemps. C’est pour ça que l’on a encore des très vieilles applications. J’ai vu passer des trucs sur des Blackberry qui marchent encore alors que ce sont des applications que l’on n’a littéralement pas touchées depuis probablement plus de dix ans, ce qui est plutôt une bonne chose ! Ça veut dire que le Blackberry fonctionne et que Deezer fonctionne.

Nicolas (39:55) : Et que l’on contribue à réduire l’e-waste.

Loic (39:58) : Tout à fait.

Vincent (39:59) : D’autant que c’est le gros de l’empreinte carbone de nos sociétés justement, la fabrication des devices. Fabriquer des télés, ce n’est pas neutre, fabriquer des téléphones, des voitures encore moins… C’est effectivement super intéressant.

Nicolas (40:14) : Et puis, on ne change pas de télé tous les ans non plus. Nous, notre but, c’est de participer à tenir la promesse de Deezer qui est d’apporter la musique au bon moment de la journée à l’utilisateur. Du coup, on ne peut pas se permettre de faire fi de son matériel parce qu’il a plus de deux, trois ans.

Vincent (40:33) : Merci ! Je crois que l’on va s’arrêter sur cette jolie considération. Je vous propose de passer à la deuxième partie de l’émission qui est : vos recommandations musicales.

Vincent (40:51) : Est-ce que vous avez une track que vous auriez envie de conseiller, que vous avez écoutée récemment ou pas récemment ? Ce que vous voulez !

Loic (40:59) : Qu’est-ce que vous avez mis dans vos favoris Deezer ?

Nicolas (41:01) : C’est difficile de faire un choix, mais en ce moment, je dirais plutôt “Bish Bash Bosh” de Claimed Choice, qui est un groupe lyonnais qui fait un glam rock assez pushy. Et pourquoi ? Parce que Simon, leur chanteur, est un ami à moi et on a vécu tant de choses ensemble. Je t’embrasse, Simon !

Vincent (41:26) : Hugo ?

Hugo (41:27) : Moi, le groupe, c’est les IDLES. C’est un groupe de rock anglais. Je le sélectionne parce que, pour la petite anecdote, je m’étais déplacé à Copenhague pour les voir et je les avais ratés à cause du Covid, je m’étais déplacé à New York pour les voir et je les avais ratés parce que j’avais pris mon billet sur un site de revente et je n’avais jamais reçu le billet, je les avais ratés à Paris à cause du Covid. J’ai finalement réussi à les voir à Berlin la semaine dernière. Et là encore, j’étais à deux doigts de les rater ! Voilà, je les sélectionne parce que j’ai finalement réussi à les voir en concert.

Vincent (42:03) : Et Camille ?

Camille (42:05) : Je vais vous conseiller un artiste, c’est Little Big. C’est un groupe russe de rave qui, malheureusement, a dû partir de Russie depuis la guerre en Ukraine, vu qu’ils sont contre le système. Il faut vraiment regarder leurs clips musicaux, ils sont vraiment géniaux.

Loic (42:19) : Si possible, les versions longues non-censurées !

Camille (42:20) : Voilà !

Vincent (42:20) : Et toi, Loic ?

Loic (42:23) : Je vais recommander Loreena McKennitt. C’est pas mal, c’est de la musique entre la musique celtique et un peu pop-rock suivant les morceaux. Je vous recommande. Et toi, Vincent ?

Vincent (42:33) : Je me suis refait pas mal de films de Kon Satoshi ces derniers temps et en revoyant Paprika, je me suis repris d’une certaine affection pour un titre qui s’appelle “The Girl in Byakkoya”, qui est un titre de Susumu Hirasawa que je trouve vraiment sympa et qui est l’ouverture du film Paprika.

Loic (42:56) : Cette partie deuxest maintenant terminée !

Vincent (42:58) : Merci à tous les trois !

Nicolas (42:59) : Merci à vous.

Vincent (43:00) : Encore merci pour toutes les infos, et on se retrouve la prochaine fois ! Salut tout le monde !

Nicolas (43:04) : Salut !

Camille (43:04) : Salut !

Hugo (43:04) : Merci !

Vincent (43:06) : Vous venez d’écouter un épisode de Deez is la tech et nous espérons que vous avez passé un bon moment en notre compagnie. N’hésitez pas à nous attribuer quelques étoiles si votre application de podcast le permet, et à nous faire part de vos retours via les réseaux sociaux et notre compte @DeezerDevs. Ceux-ci nous aideront à améliorer notre contenu afin de le rendre plus utile, enrichissant et plaisant à écouter. Enfin, n’oubliez pas que toutes les transcriptions de nos épisodes, ainsi que les coups de cœur de nos invités, sont disponibles sur notre blog deezer.io. À très vite pour un nouvel épisode et d’ici là, ne pétez ni les plombs, ni les crons !

Deez Is La Tech
Hardware Integration
Partnerships
Tech Partnerships
Deezer

--

--

Pauline Munier
Deezer I/O
Follow

Written by Pauline Munier

18 Followers

Knowledge Manager @Deezer

Follow

Help

Status

About

Careers

Blog

Privacy

Terms

Text to speech

Teams