TL;DR

  • Le Problème: La conception d'architectures évolutives exige un équilibre entre disponibilité, débit et complexité opérationnelle.
  • L'Essentiel: Carte débutant du streaming vidéo : un cinéaste dépose une bande master, la plateforme fabrique plein de copies de qualités différentes, les stocke près des spectateurs et les sert via un CDN. Pourquoi l'original seul ne suffit pas, et l'intuition du coût en mots simples.
  • Le Résultat: Plan technique avec des objectifs quantitatifs et la gestion des pannes en production.

Tu ouvres une app, tu touches une vidéo, et ça démarre. On dirait de la magie. En dessous, c'est plus proche d'un studio de cinéma avec des entrepôts modernes.

Imagine ceci. Un cinéaste termine un film et dépose une seule bande master à la porte du studio. Le studio ne distribue pas cette unique bande à chaque salon. Il fabrique beaucoup de copies en qualités différentes, les envoie dans des magasins locaux près du public, et quand quelqu'un appuie sur lecture, le magasin voisin donne les prochaines minutes de film. Toute l'idée tient dans une histoire : envoyer, convertir, stocker près des spectateurs, lire.

Ce billet suit ce chemin avec des mots simples. Pas besoin de connaître d'abord les noms des fournisseurs cloud. Si tu suis l'histoire de la bande, tu suis un design style YouTube.

La grande idée en quatre étapes

Étape Sens simple Analogie du studio
Envoyer (upload) Le créateur envoie le gros fichier original Le cinéaste dépose la bande master
Convertir (transcoder) Des machines réécrivent ce fichier en plusieurs tailles et qualités Le studio tire beaucoup de bobines : cinéma net, petit téléphone, réseau faible
Stocker Garder le master et toutes les copies en sécurité Coffre pour le master, rayons pour chaque qualité
Lire via CDN Envoyer de petits morceaux depuis un serveur près du spectateur Magasin local dans chaque ville, pas un seul entrepôt de l'autre côté de l'océan

Un CDN (réseau de diffusion de contenu) est simplement un réseau de magasins locaux pour les fichiers internet. Les spectateurs tirent la vidéo d'un magasin proche pour démarrer plus vite et pour que l'entrepôt principal ne soit pas écrasé par chaque requête.

Étape 1 : Envoyer (déposer le master)

Quand quelqu'un envoie une vidéo, la plateforme ne devrait pas forcer le fichier entier à traverser ses serveurs d'application principaux. Ce serait comme faire passer tous les camions de livraison par l'accueil. L'accueil se bloque.

Un meilleur schéma :

  1. L'app demande à la plateforme : "Je veux envoyer une vidéo. Voici le titre et la taille."
  2. La plateforme crée un enregistrement : "cette vidéo existe, statut en cours d'envoi."
  3. La plateforme donne au créateur un ticket d'upload de courte durée (un lien temporaire) vers un grand entrepôt de fichiers.
  4. Le téléphone ou le navigateur envoie le fichier directement vers cet entrepôt.
  5. Quand l'envoi est fini, la plateforme marque la vidéo comme en traitement et lance la conversion.

Pourquoi un ticket ? Pour que le gros fichier ne traverse pas les petites machines "app", qui ne doivent gérer que titres, connexions et statut.

Les gros fichiers montent souvent par morceaux. Si le réseau meurt à 80 %, le client ne reprend que les morceaux manquants au lieu de tout recommencer. Même idée qu'envoyer un livre chapitre par chapitre.

Pendant que les octets arrivent, le créateur peut encore éditer le titre ou la description. Mais la vidéo n'est pas "prête à regarder" tant qu'au moins une copie lisible n'existe pas.

Étape 2 : Convertir (fabriquer beaucoup de qualités)

Convertir ici veut dire transcoder : prendre l'original et le réécrire dans des formats et débits que téléphones, téléviseurs et navigateurs peuvent lire sans hoquet.

Pourquoi ne pas streamer uniquement le fichier original ?

C'est la question qu'un débutant doit se poser, et la réponse est le coeur du design.

  1. Taille. Un enregistrement brut de téléphone peut être énorme. Streamer ce seul gros fichier brûlerait les forfaits data et ferait buffer sans fin sur un réseau lent.
  2. Les appareils diffèrent. Un téléphone dans le métro en 4G faible et une TV du salon en fibre ont besoin de "bobines" différentes. Un seul master ne convient pas bien aux deux.
  3. Le réseau change en cours de lecture. Le lecteur doit pouvoir descendre vers une copie plus légère quand le signal se dégrade, puis remonter quand il revient. Il faut une échelle de qualités prête à l'avance.
  4. Compatibilité. Téléphones, navigateurs et TV ne parlent pas tous le même "langage" vidéo. La conversion produit les versions que chaque client comprend.

Donc le studio n'envoie pas l'unique bande master à chaque maison. Il prépare beaucoup de copies : 360p grossier pour les mauvais réseaux, 720p normal, 1080p ou plus pour les liens solides, plus les pistes audio et une petite liste de lecture (manifeste) qui énumère ces options.

Le lecteur lit la liste, choisit une qualité de départ et demande de courts segments (quelques secondes chacun). Ce n'est pas "télécharge tout le film, puis démarre." C'est "garde les prochains segments sous la main."

Tu peux marquer une vidéo prête quand l'échelle minimale utile existe (par exemple une qualité moyenne plus l'audio). Les qualités plus hautes peuvent finir plus tard et rejoindre la liste.

Étape 3 : Stocker (coffre et rayons)

Après conversion tu gardes :

  • L'original (master). Utile s'il faut reconvertir, corriger un bug du pipeline ou ajouter une nouvelle qualité.
  • Les copies converties (segments et listes pour chaque qualité).
  • De petits extras : miniatures, parfois un court aperçu.

Les octets vivent dans un stockage d'objets (un entrepôt géant de fichiers). Les petits faits vivent dans une base de données : titre, propriétaire, durée, statut (uploading → processing → ready ou failed), et où se trouve la liste de lecture.

Le statut compte. Les clients ne doivent pas bloquer sur l'appel d'upload jusqu'à la fin de la conversion. La conversion peut prendre des minutes. L'app interroge ou reçoit une notification : "encore en traitement" puis "prêt."

Étape 4 : Lire (magasin local près du spectateur)

Quand un spectateur appuie sur lecture :

  1. L'app charge les métadonnées via l'API (titre, miniature, est-ce prêt ?).
  2. Le lecteur ouvre l'URL de la liste, souvent depuis le CDN.
  3. Le lecteur demande des segments à un bord CDN proche.
  4. Si ce bord n'a pas encore le segment, il le tire une fois de l'entrepôt principal, puis garde une copie pour le prochain spectateur voisin.

Règle de design : l'API possède tickets, état et politique. Le CDN possède les octets du chemin heureux de lecture. Les serveurs d'app ne doivent pas streamer des multi-gigaoctets vers chaque téléphone.

La qualité peut changer entre segments. C'est le streaming adaptatif (en entretien tu entendras HLS et DASH ; les deux sont des idées "liste plus segments"). Tu n'as pas besoin du RFC. Tu as besoin de l'image : échelle de copies, petits morceaux, bascule quand le réseau change.

Intuition du coût (avant les maths intimidantes)

Oublie les noms de produits un instant. Pense comme le responsable du studio.

Où part l'argent pour la vidéo

  1. Déplacer des octets vers les spectateurs coûte souvent le plus. Chaque lecture, ce sont des données qui quittent tes entrepôts vers les gens. Une vidéo à succès se regarde un million de fois ; chaque lecture est un autre trajet depuis un magasin local (ou un tirage froid depuis l'entrepôt central).
  2. Stocker des copies coûte plus que stocker un seul original. Une échelle de qualités multiplie l'espace. Tu paies les rayons, pas seulement le coffre du master.
  3. La conversion coûte du temps CPU. Les fermes d'encodage travaillent fort quand les uploads explosent. Cette facture est réelle, mais à grande échelle le trafic de lecture domine souvent.
  4. Les serveurs d'app pour titres et connexion sont en général la partie bon marché. Ne conçois pas comme si la base de données était la dépense principale d'un produit vidéo.

Pourquoi "stocker près des spectateurs" économise argent et douleur

Si tout le monde tire depuis un seul entrepôt central :

  • Les spectateurs lointains attendent plus longtemps.
  • Le lien central devient un embouteillage.
  • Tu paies pour renvoyer le même film populaire à travers les océans encore et encore.

Les bords CDN locaux gardent les vidéos chaudes près du public. La plupart des lectures touchent une copie proche. Les vidéos froides, rarement regardées, peuvent rester plus loin. La popularité est une longue traîne : peu de vidéos portent la majeure partie du trafic ; la plupart se regardent à peine. Les plateformes malines dépensent l'espace en bordure sur ce que les gens regardent vraiment.

Calcul mental simple (ordre de grandeur, pas un devis)

Suppose des millions de personnes qui regardent quelques vidéos par jour, et chaque stream terminé fait quelques centaines de mégaoctets. Multiplie personnes × vidéos × taille et tu obtiens des pétaoctets de transfert. Même quelques centimes par gigaoctet de données sortantes deviennent une grosse facture quotidienne. C'est pourquoi les entretiens parlent sans cesse du "coût CDN", et pourquoi la conversion (fichiers plus petits, codecs efficaces) et le cache près des spectateurs comptent plus que peaufiner le formulaire d'upload.

Tu n'as pas besoin des grilles de prix exactes. Tu as besoin de la punchline : pour la vidéo, la livraison et le stockage battent souvent le coût de la couche applicative.

Une image de tout le chemin

Téléphone/navigateur du créateur
    |  1. demander un ticket d'upload
    v
API (métadonnées, auth, statut)
    |  2. ticket
    v
Entrepôt de fichiers  <--- 3. le gros original atterrit ici
    |
    v
Workers de conversion (file)  ---> beaucoup de qualités + liste + thumbs
    |
    v
Rayons de l'entrepôt + magasins locaux CDN
    |
    v
Lecteur du spectateur  <--- segments depuis le magasin le plus proche

Trois plans, une phrase chacun :

  • Plan API : qui peut envoyer, quel est le titre, la vidéo est-elle prête.
  • Plan octets : originaux et objets convertis dans les entrepôts.
  • Plan bordure : copies CDN près des gens pour le visionnage réel.

Sécurité en une respiration

  • Les tickets d'upload expirent et pointent vers un seul objet.
  • Les vidéos privées ont besoin de liens de lecture de courte durée, pas d'une URL publique pour toujours.
  • Un contenu mauvais ou bloqué peut passer en retiré ; arrête de servir listes et segments.
  • Le live streaming est un cousin (même famille : ingest, packaging, CDN) mais avec un budget temps plus serré. Ce billet parle de vidéos déjà terminées (à la demande), pas d'un concert en direct.

Récap à raconter à un ami

Le streaming style YouTube n'est pas "poser un fichier sur un serveur et croiser les doigts."

Un créateur envoie un master dans un entrepôt avec un ticket temporaire, pas par l'accueil. Des machines convertissent ce master en beaucoup de qualités pour que téléphones et TV sur n'importe quel réseau puissent lire sans fondre. La plateforme stocke le master et les copies, et suit le statut dans une petite base. Quand quelqu'un appuie sur lecture, un CDN proche sert de courts segments depuis une échelle de qualités, en changeant quand le réseau change.

On ne streame pas seulement l'original parce qu'il est trop gros, trop rigide et trop hostile aux réseaux faibles. Le coût suit l'audience : la livraison d'octets et les rayons pleins de copies comptent en général plus que les serveurs qui stockent les titres. Conçois pour que les gros fichiers évitent la couche app, que la conversion soit asynchrone, et que le trafic heureux de lecture vive en bordure.

Si tu retiens une seule phrase : le cinéaste dépose une bande ; le studio tire beaucoup de bobines et les stocke près du public.