Aller au contenu principal
Tech & Streaming 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.

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

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.