# language: fr Fonctionnalité: Architecture technique radio live En tant que système Je veux gérer efficacement les flux audio en temps réel Afin d'assurer une diffusion stable et scalable des lives Contexte: Étant donné que l'infrastructure RoadWave est opérationnelle Et que les serveurs Go avec Pion WebRTC sont actifs Scénario: Ingestion WebRTC du flux créateur Étant donné qu'un créateur démarre un live depuis son application mobile Quand le flux audio WebRTC (Opus 48 kbps) arrive sur le serveur Alors le serveur Go avec Pion WebRTC accepte la connexion Et le flux est traité en temps réel Scénario: Conversion temps réel Opus vers segments HLS Étant donné qu'un flux WebRTC Opus est reçu par le serveur Quand le serveur traite le flux Alors FFmpeg convertit en segments HLS (.ts) Et un fichier manifest .m3u8 est généré et mis à jour régulièrement Et les segments ont une durée de 2 secondes chacun Scénario: Distribution via NGINX Cache Étant donné que les segments HLS sont générés Quand un auditeur demande à rejoindre le live Alors le manifest .m3u8 est servi via NGINX Cache (OVH) Et les segments .ts sont cachés sur le cache NGINX Et la distribution est globale avec latence minimale Scénario: Lecture HLS native sur mobile iOS Étant donné qu'un auditeur iOS rejoint un live Quand l'application charge le flux HLS Alors le player natif AVPlayer gère la lecture Et le buffer de 15 secondes est appliqué automatiquement Et la qualité s'adapte selon la connexion Scénario: Lecture HLS native sur mobile Android Étant donné qu'un auditeur Android rejoint un live Quand l'application charge le flux HLS Alors le player natif ExoPlayer gère la lecture Et le buffer de 15 secondes est configuré Et la qualité s'adapte selon la connexion Scénario: Enregistrement parallèle du flux pour replay Étant donné qu'un live est en cours Alors un processus parallèle enregistre le flux Opus raw Et l'enregistrement est stocké temporairement sur le serveur Et l'enregistrement est indépendant de la diffusion HLS Scénario: Traitement post-live asynchrone Étant donné qu'un live vient de se terminer Quand le processus post-live démarre Alors un job asynchrone est créé dans la queue Redis Et un worker Go récupère le job Et le worker exécute FFmpeg pour les conversions Scénario: Conversion Opus raw vers MP3 256 kbps Étant donné qu'un worker traite un job post-live Quand la conversion démarre Alors FFmpeg convertit Opus raw en MP3 256 kbps Et la normalisation audio à -14 LUFS est appliquée Et les silences prolongés (>3 secondes) sont détectés et nettoyés Scénario: Génération segments HLS pour le replay Étant donné que le MP3 256 kbps est généré Quand le worker crée les segments HLS Alors des segments .ts de 10 secondes sont créés Et un manifest .m3u8 est généré Et les segments sont uploadés vers OVH Object Storage Scénario: Publication automatique du replay Étant donné que tous les segments HLS sont uploadés Quand le worker finalise le job Alors une entrée de contenu "replay" est créée en base PostgreSQL Et le titre est "[REPLAY] [Titre live original]" Et le type géographique est "Géo-neutre" Et le replay est immédiatement disponible pour les auditeurs Scénario: Suppression automatique fichier Opus raw après 7 jours Étant donné qu'un replay est publié depuis 7 jours Quand le job de nettoyage quotidien s'exécute Alors le fichier Opus raw est supprimé du stockage Et seul le MP3 256 kbps et les segments HLS sont conservés Et l'espace de stockage est libéré Scénario: Scalabilité horizontale des workers de conversion Étant donné que 50 lives se terminent simultanément Quand les jobs post-live sont créés Alors les workers Go disponibles traitent les jobs en parallèle Et si tous les workers sont occupés, les jobs attendent en queue Redis Et de nouveaux workers peuvent être lancés automatiquement (Kubernetes) Scénario: Limitation du nombre de lives simultanés (MVP) Étant donné que l'infrastructure MVP est configurée pour 100 lives simultanés Et que 100 lives sont actuellement en cours Quand un nouveau créateur essaie de démarrer un live Alors la demande est refusée avec le code erreur 503 Et le message "Capacité maximale atteinte. Veuillez réessayer dans quelques minutes" est retourné Et la demande peut être mise en queue prioritaire si créateur Premium Scénario: Monitoring des ressources serveur en temps réel Étant donné que plusieurs lives sont en cours Alors le système monitore en temps réel: | métrique | seuil alerte | | CPU utilisation | >80% | | Mémoire utilisation | >85% | | Bande passante upload | >80% capacité| | Nombre connexions WebRTC | >90 | | Latence moyenne CDN | >200ms | Et si un seuil est dépassé, une alerte est envoyée à l'équipe technique Scénario: Calcul du coût de bande passante CDN Étant donné qu'un live a 100 auditeurs simultanés Et que la qualité est 48 kbps Opus Quand le live dure 1 heure Alors la bande passante totale est d'environ 2.16 GB Et le coût estimé infrastructure est d'environ 0.02€ Et ces métriques sont enregistrées pour facturation créateur si nécessaire Scénario: Cache NGINX des segments HLS Étant donné qu'un live est diffusé via NGINX Cache Quand un segment .ts est généré Alors le segment est uploadé vers OVH Object Storage origin Et NGINX Cache met en cache le segment Et les auditeurs suivants récupèrent le segment depuis le cache Et la charge sur le serveur origin est réduite de ~90% Scénario: Gestion de la latence WebRTC créateur Étant donné qu'un créateur diffuse avec une connexion 4G Quand la latence réseau augmente ponctuellement Alors le buffer côté serveur absorbe les fluctuations Et la qualité peut être réduite temporairement (48 kbps → 32 kbps) Et un warning est affiché au créateur si la connexion est trop instable Scénario: Détection automatique de la musique protégée (post-MVP) Étant donné qu'un live contient de la musique en arrière-plan Quand le système d'audio fingerprint analyse le flux Alors une empreinte audio est calculée toutes les 30 secondes Et l'empreinte est comparée à une base de données de contenus protégés Et si une correspondance est trouvée, un warning est envoyé au créateur Et si le créateur ne corrige pas sous 30 secondes, le live peut être arrêté Scénario: Stockage des métadonnées de live en PostgreSQL Étant donné qu'un créateur démarre un live Alors les métadonnées suivantes sont enregistrées: | champ | exemple valeur | | live_id | uuid v4 | | creator_id | uuid créateur | | title | "Mon super live" | | started_at | timestamp UTC | | zone_geo | "Île-de-France" | | tags | ["Actualité", "Tech"] | | classification_age | "Tout public" | Et ces données sont indexées pour recherche et analytics Scénario: Cache Redis pour compteurs temps réel Étant donné qu'un live est en cours Alors Redis stocke les compteurs temps réel: | clé Redis | valeur exemple | | live:[live_id]:listeners | 247 | | live:[live_id]:likes | 89 | | live:[live_id]:reports | 0 | Et ces compteurs sont mis à jour toutes les 2 secondes Et les compteurs sont persistés en PostgreSQL toutes les 60 secondes Scénario: Heartbeat auditeurs pour compteur précis Étant donné qu'un auditeur écoute un live Alors l'application envoie un heartbeat toutes les 10 secondes Et le heartbeat met à jour le timestamp dans Redis Et si aucun heartbeat n'est reçu pendant 30 secondes, l'auditeur est retiré du compteur Scénario: Gestion des pannes serveur pendant un live Étant donné qu'un live est en cours sur serveur A Quand le serveur A tombe en panne Alors Kubernetes redémarre automatiquement un pod Mais le live en cours est perdu (pas de failover temps réel en MVP) Et le créateur voit le message "Connexion perdue. Veuillez redémarrer le live" Et les auditeurs voient "Le live est terminé suite à un problème technique" Scénario: Backup automatique des enregistrements live Étant donné qu'un live est enregistré en Opus raw Quand l'enregistrement dépasse 10 minutes Alors un backup incrémental est créé toutes les 10 minutes Et le backup est stocké sur un stockage secondaire (S3-compatible) Et en cas de crash serveur, le live peut être récupéré jusqu'au dernier backup Scénario: Logs et audit trail des lives Étant donné qu'un live démarre, se déroule et se termine Alors tous les événements sont loggés: | événement | détails enregistrés | | Démarrage live | timestamp, creator_id, zone_geo | | Auditeur rejoint | timestamp, user_id, position GPS | | Auditeur quitte | timestamp, user_id, durée écoute | | Signalement | timestamp, user_id, catégorie | | Fin live | timestamp, durée totale, stats finales | Et ces logs sont conservés 90 jours pour analytics et conformité RGPD