Aller au contenu principal
Tech architecture
Leader du streaming musical

Millions d'auditeurs, des pétaoctets de musique, une ambition mondiale — et une architecture qui n'avait jamais été pensée pour ça

Avant

3 PB

de données sans trajectoire d'évolution claire

Après

2 000

requêtes/seconde

2 000

requêtes/seconde

3 PB

de données gérées

900 j

de chantiers cadrés

Un leader européen du streaming musical prépare l'accélération de son déploiement à l'international. Le service traite en temps réel 2 000 requêtes par seconde sur un patrimoine de 3 pétaoctets de données — catalogues, métadonnées, historiques d'écoute, recommandations. L'architecture, construite au fil des années dans un contexte de croissance rapide, n'a jamais fait l'objet d'une vision globale orientée scalabilité mondiale. L'étude est sponsorisée au plus haut niveau et pilotée directement par le CTO

SITUATION AVANT

Baseline operationnel
Architecture construite au fil des années dans un contexte de croissance rapide — des services C++ critiques aux flux PHP hérités, avec des couplages forts entre services et des modèles de données ne passant pas à l'échelle de nouveaux marchés. Aucune vision globale orientée scalabilité mondiale.
Equipes impactees
L'ensemble de la plateforme et les équipes techniques — mais surtout l'ambition d'expansion internationale bloquée faute de trajectoire technique crédible.
Couts caches
Une API dont le contrat implicite freine toute évolution majeure. Des couplages qui se matérialiseraient en pannes au moment de l'expansion internationale, pas avant.
Pourquoi non resolu avant
L'architecture avait été optimisée pour la croissance rapide sur le marché européen. La question de la scalabilité mondiale ne s'est posée qu'au moment de l'accélération internationale — et le CTO a décidé de la poser en amont des fractures plutôt qu'après.

L'HISTOIRE

Un leader européen du streaming musical veut franchir un cap : accélérer son déploiement à l’international. Des millions d’utilisateurs, des catalogues dans des dizaines de langues, une infrastructure distribuée sur AWS qui traite 2 000 requêtes par seconde et gère 3 pétaoctets de données. La plateforme tourne. Mais personne n’a jamais posé la question qui dérange : est-ce que cette architecture peut tenir le choc d’une expansion mondiale ?

La direction prend la décision de commander une étude de fond. Le CTO en prend le pilotage. L’enjeu n’est pas de réécrire le système — c’est de comprendre où sont les limites, et de tracer une trajectoire réaliste avant que les fractures ne deviennent des pannes

Nobori Partners intervient pour mener cette analyse de bout en bout. Le périmètre est large : des services C++ critiques aux flux PHP hérités, des bases AuroraDB aux fonctions Lambda, en passant par les couches NodeJS qui orchestrent l’ensemble. Deux consultants, six mois, un mandat clair : cartographier, diagnostiquer, recommander

La cartographie révèle ce que les équipes pressentaient sans l’avoir formalisé : des couplages forts entre services, des modèles de données qui ne passent pas à l’échelle de nouveaux marchés, une API dont le contrat implicite freine toute évolution majeure. Le diagnostic est précis, chiffré, sans complaisance

La cible d’architecture est construite autour de trois axes. Côté données : migration vers AuroraDB avec un dimensionnement adapté aux workloads de lecture intensive, et introduction de l’event sourcing pour tracer la totalité du comportement utilisateur sans dégrader les performances. Côté traitement : découplage des chemins lecture/écriture via CQRS, exploitation de Lambda pour absorber les pics d’usage sans surprovisionnement permanent. Côté contenu : adoption d’un CMS Headless pour libérer la production éditoriale du cycle de déploiement technique — un frein identifié dans plusieurs marchés cibles

Les principes de l’API V3 sont formalisés : contrat d’interface stable, versionning explicite, découplage des consommateurs internes et externes. Une fondation pensée pour durer

Au terme de l’étude, 900 jours de chantiers sont cadrés, priorisés et présentés à la direction. Chaque chantier est adossé à un impact mesurable — gain de scalabilité, réduction du risque opérationnel, accélération des déploiements sur de nouveaux marchés. La restitution au CTO marque le début d’une roadmap actionnée, pas d’un rapport classé dans un tiroir

NOTRE APPROCHE

4 étapes pour y arriver

1

Cartographie des points de douleur

Recueil exhaustif des pratiques sur les domaines clés du système d'information : performance, disponibilité, gestion des données, modèles d'intégration entre services. Formalisation de la cartographie du SI, relevé des indices de volumétrie et identification des goulots d'étranglement — des requêtes C++ critiques aux flux PHP hérités

AWSEC2PHPC++
2

Définition de la cible d'architecture

Élaboration de la cible d'architecture pour le déploiement mondial : recommandations de solutions AWS, dimensionnement AuroraDB pour les workloads à forte lecture, stratégie Lambda pour les traitements événementiels. Définition des principes structurants de l'API V3 — contrat d'interface, versionning, découplage consommateurs

AWS AuroraDBEC2LambdaNodeJS
3

Éclairages technologiques et patterns d'agilité

Introduction aux patterns d'architecture favorisant l'agilité à grande échelle : event sourcing pour la traçabilité des actions utilisateurs, CQRS pour séparer les chemins de lecture et d'écriture sur les volumes critiques, CMS Headless pour découpler la production de contenu éditorial du cycle de déploiement technique

Event sourcingCQRSCMS HeadlessNodeJS
4

Priorisation et cadrage des chantiers

Formalisation d'un backlog structuré de 900 jours de chantiers, priorisés selon l'impact sur la scalabilité internationale, le risque opérationnel et la faisabilité à court terme. Restitution directe auprès du CTO, sponsoring de la direction pour engager les équipes sur la trajectoire définie

AWS AuroraDBLambdaEC2

L'ETAPE LA PLUS DURE

Diagnostiquer 3 PB de données et des années d'accumulation technique en 6 mois

Le périmètre était vaste : des services C++ critiques aux flux PHP hérités, des bases AuroraDB aux fonctions Lambda, en passant par les couches NodeJS. L'enjeu n'était pas de tout documenter, mais d'identifier précisément ce qui ne tiendrait pas à l'échelle mondiale.

Ce qu'on a fait

Cartographie systématique des points de douleur, diagnostic précis et chiffré, puis construction d'une cible d'architecture sur trois axes (données, traitement, contenu). 900 jours de chantiers cadrés et priorisés pour donner une trajectoire actionnée.

Ce qui aurait pu echouer

Un diagnostic qui se contente de lister les problèmes sans prioriser et sans trajectoire concrète aurait abouti à un rapport classé dans un tiroir. L'enjeu était de produire une roadmap que la direction s'engage à exécuter.

RÉSULTATS

L'impact mesurable

2 000 requêtes/seconde
3 PB de données gérées
900 j de chantiers cadrés

Cible d'architecture définie pour le déploiement international, principes de l'API V3 formalisés, 900 jours de chantiers cadrés et priorisés — une trajectoire actionnée au niveau direction

Réserver un appel découverte