refactor(docs): réorganiser la documentation selon principes DDD
Réorganise la documentation du projet selon les principes du Domain-Driven Design (DDD) pour améliorer la cohésion, la maintenabilité et l'alignement avec l'architecture modulaire du backend. **Structure cible:** ``` docs/domains/ ├── README.md (Context Map) ├── _shared/ (Core Domain) ├── recommendation/ (Supporting Subdomain) ├── content/ (Supporting Subdomain) ├── moderation/ (Supporting Subdomain) ├── advertising/ (Generic Subdomain) ├── premium/ (Generic Subdomain) └── monetization/ (Generic Subdomain) ``` **Changements effectués:** Phase 1: Création de l'arborescence des 7 bounded contexts Phase 2: Déplacement des règles métier (01-19) vers domains/*/rules/ Phase 3: Déplacement des diagrammes d'entités vers domains/*/entities/ Phase 4: Déplacement des diagrammes flux/états/séquences vers domains/*/ Phase 5: Création des README.md pour chaque domaine Phase 6: Déplacement des features Gherkin vers domains/*/features/ Phase 7: Création du Context Map (domains/README.md) Phase 8: Mise à jour de mkdocs.yml pour la nouvelle navigation Phase 9: Correction automatique des liens internes (script fix-markdown-links.sh) Phase 10: Nettoyage de l'ancienne structure (regles-metier/, diagrammes/, features/) **Configuration des tests:** - Makefile: godog run docs/domains/*/features/ - scripts/generate-bdd-docs.py: features_dir → docs/domains **Avantages:** ✅ Cohésion forte: toute la doc d'un domaine au même endroit ✅ Couplage faible: domaines indépendants, dépendances explicites ✅ Navigabilité améliorée: README par domaine = entrée claire ✅ Alignement code/docs: miroir de backend/internal/ ✅ Onboarding facilité: exploration domaine par domaine ✅ Tests BDD intégrés: features au plus près des règles métier Voir docs/REFACTOR-DDD.md pour le plan complet.
This commit is contained in:
jpgiannetti
@@ -0,0 +1,197 @@
|
||||
# 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
|
||||
159
docs/domains/content/features/radio-live/arret-live.feature
Normal file
159
docs/domains/content/features/radio-live/arret-live.feature
Normal file
@@ -0,0 +1,159 @@
|
||||
# language: fr
|
||||
Fonctionnalité: Arrêt du live
|
||||
En tant que créateur
|
||||
Je veux arrêter ma diffusion en direct de manière contrôlée
|
||||
Afin de terminer proprement mon live et générer un replay automatiquement
|
||||
|
||||
Contexte:
|
||||
Étant donné que l'API RoadWave est disponible
|
||||
Et que je suis connecté en tant que créateur
|
||||
Et que je diffuse actuellement un live
|
||||
|
||||
Scénario: Arrêt manuel avec compte à rebours 5 secondes
|
||||
Quand j'appuie sur le bouton "Arrêter live"
|
||||
Alors un compte à rebours de 5 secondes démarre
|
||||
Et je vois le message "Ce live se termine dans 5... 4... 3... 2... 1"
|
||||
Et un bouton "Annuler" est affiché pendant le décompte
|
||||
Et l'audio du compte à rebours est diffusé aux auditeurs
|
||||
|
||||
Scénario: Annulation du compte à rebours
|
||||
Étant donné que j'ai appuyé sur "Arrêter live"
|
||||
Et que le compte à rebours affiche "3 secondes"
|
||||
Quand j'appuie sur "Annuler"
|
||||
Alors le compte à rebours s'arrête
|
||||
Et le live continue normalement
|
||||
Et aucune notification n'est envoyée aux auditeurs
|
||||
|
||||
Scénario: Arrêt effectif après compte à rebours
|
||||
Étant donné que le compte à rebours est à 0
|
||||
Alors le live s'arrête
|
||||
Et la diffusion aux auditeurs se termine
|
||||
Et le message "Live terminé" s'affiche
|
||||
Et le processus de traitement post-live démarre automatiquement
|
||||
|
||||
Scénario: Déconnexion créateur courte (moins de 60 secondes)
|
||||
Étant donné que je diffuse un live
|
||||
Quand ma connexion est perdue pendant 30 secondes
|
||||
Alors les auditeurs voient le message "Connexion créateur perdue, reconnexion en cours..."
|
||||
Et le live continue de bufferer
|
||||
Et quand ma connexion revient, le live reprend normalement
|
||||
|
||||
Scénario: Déconnexion créateur longue (60 secondes ou plus)
|
||||
Étant donné que je diffuse un live
|
||||
Quand ma connexion est perdue pendant 60 secondes
|
||||
Alors le live s'arrête automatiquement
|
||||
Et les auditeurs voient le message "Le live est terminé suite à une coupure de connexion"
|
||||
Et le processus de traitement post-live démarre
|
||||
|
||||
Scénario: Enregistrement automatique pendant le live
|
||||
Étant donné que je diffuse un live
|
||||
Alors mon flux audio est enregistré en continu
|
||||
Et le format d'enregistrement est Opus raw
|
||||
Et l'enregistrement est stocké temporairement sur le serveur
|
||||
|
||||
Scénario: Génération automatique du replay après arrêt
|
||||
Étant donné que mon live vient de se terminer
|
||||
Et que l'option "Publier replay automatiquement" est activée (par défaut)
|
||||
Quand le traitement post-live démarre
|
||||
Alors un job asynchrone est créé
|
||||
Et le job effectue les opérations suivantes:
|
||||
| opération | détail |
|
||||
| Conversion format | Opus raw → MP3 256 kbps |
|
||||
| Génération segments HLS | Segments .ts pour streaming |
|
||||
| Normalisation volume | -14 LUFS |
|
||||
| Détection silences prolongés | Nettoyage automatique |
|
||||
|
||||
Scénario: Publication du replay
|
||||
Étant donné que le traitement post-live est terminé
|
||||
Alors le replay est publié automatiquement sous 5 à 10 minutes
|
||||
Et le titre est "[REPLAY] [Titre live original]"
|
||||
Et la zone de diffusion est la même que le live
|
||||
Et les tags sont identiques au live
|
||||
Et la classification d'âge est identique
|
||||
Et le type géographique est "Géo-neutre" (contenu pérenne)
|
||||
|
||||
Scénario: Notification de disponibilité du replay aux auditeurs
|
||||
Étant donné que le replay de mon live est publié
|
||||
Quand un auditeur qui a écouté le live se reconnecte
|
||||
Alors il voit une notification in-app "Le replay de [Titre] est disponible"
|
||||
|
||||
Scénario: Option désactivation publication automatique replay
|
||||
Étant donné que je configure un nouveau live
|
||||
Quand je désactive l'option "Publier replay automatiquement"
|
||||
Et que je démarre puis arrête le live
|
||||
Alors le live est enregistré
|
||||
Mais le replay n'est pas publié automatiquement
|
||||
Et je peux décider manuellement de le publier plus tard
|
||||
|
||||
Scénario: Suppression manuelle du replay après publication
|
||||
Étant donné que mon live a généré un replay publié
|
||||
Quand j'accède à mes contenus
|
||||
Alors je vois le replay dans ma liste
|
||||
Et je peux le supprimer comme n'importe quel contenu
|
||||
Quand je supprime le replay
|
||||
Alors le fichier source Opus raw est supprimé immédiatement
|
||||
|
||||
Scénario: Conservation fichier source Opus raw
|
||||
Étant donné que mon live est terminé
|
||||
Et que le replay est publié
|
||||
Alors le fichier Opus raw est conservé pendant 7 jours
|
||||
Et après 7 jours, le fichier raw est supprimé automatiquement
|
||||
Et seul le MP3 256 kbps est conservé
|
||||
|
||||
Scénario: Modification du replay interdite
|
||||
Étant donné que mon live a généré un replay publié
|
||||
Quand j'essaie de modifier l'audio du replay
|
||||
Alors l'action est refusée
|
||||
Et je vois le message "Les replays ne peuvent pas être modifiés pour garantir l'intégrité de l'enregistrement"
|
||||
Et je peux uniquement modifier les métadonnées (titre, description)
|
||||
|
||||
Scénario: Statistiques du live disponibles après arrêt
|
||||
Étant donné que mon live est terminé
|
||||
Quand j'accède aux statistiques
|
||||
Alors je vois:
|
||||
| métrique | exemple valeur |
|
||||
| Durée totale | 1h 23min |
|
||||
| Nombre d'auditeurs max | 247 |
|
||||
| Nombre d'auditeurs moyen | 183 |
|
||||
| Nombre de likes | 89 |
|
||||
| Nombre d'abonnements | 12 |
|
||||
| Signalements reçus | 0 |
|
||||
|
||||
Scénario: Live terminé avec signalements en cours
|
||||
Étant donné que mon live a reçu 3 signalements pendant la diffusion
|
||||
Quand le live se termine
|
||||
Alors le replay n'est pas publié automatiquement
|
||||
Et le contenu est en attente de modération
|
||||
Et je vois le message "Votre replay sera publié après vérification suite aux signalements reçus"
|
||||
Et un modérateur doit valider ou refuser le replay sous 24h
|
||||
|
||||
Scénario: Arrêt forcé par un modérateur
|
||||
Étant donné que je diffuse un live
|
||||
Et qu'un modérateur détecte du contenu interdit
|
||||
Quand le modérateur clique sur "Arrêter le live immédiatement"
|
||||
Alors le live s'arrête sans compte à rebours
|
||||
Et je vois le message "Votre live a été interrompu par la modération"
|
||||
Et je reçois une notification détaillant la raison
|
||||
Et le replay n'est pas publié
|
||||
Et le fichier source est conservé 30 jours pour appel
|
||||
|
||||
Scénario: Métriques de bande passante pendant le live
|
||||
Étant donné que je diffuse un live
|
||||
Et que 100 auditeurs écoutent simultanément
|
||||
Alors la bande passante consommée est d'environ 4.8 Mbps via NGINX Cache
|
||||
Et le coût estimé infrastructure est d'environ 0.02€ par heure de diffusion
|
||||
Et je peux voir ces métriques en temps réel dans l'interface créateur
|
||||
|
||||
Scénario: Live sans auditeurs pendant 5 minutes
|
||||
Étant donné que je diffuse un live
|
||||
Et qu'aucun auditeur n'écoute depuis 5 minutes
|
||||
Alors je vois un message d'information "Aucun auditeur actuellement connecté"
|
||||
Mais le live continue normalement
|
||||
Et je peux choisir de continuer ou d'arrêter
|
||||
|
||||
Scénario: Qualité audio du replay supérieure au live
|
||||
Étant donné que mon live était diffusé en Opus 48 kbps
|
||||
Quand le replay est généré
|
||||
Alors le replay est encodé en MP3 256 kbps
|
||||
Et la qualité audio du replay est supérieure au live
|
||||
Et la taille du fichier est optimisée pour le stockage long terme
|
||||
@@ -0,0 +1,275 @@
|
||||
# language: fr
|
||||
Fonctionnalité: Comportement auditeur pendant un live
|
||||
En tant qu'auditeur
|
||||
Je veux écouter un live avec une expérience stable et sécurisée
|
||||
Afin de profiter du contenu en temps réel sans distraction
|
||||
|
||||
Contexte:
|
||||
Étant donné que l'API RoadWave est disponible
|
||||
Et que je suis connecté en tant qu'auditeur
|
||||
Et qu'un créateur diffuse actuellement un live
|
||||
|
||||
Scénario: Buffer de synchronisation 15 secondes
|
||||
Étant donné qu'un créateur parle en direct
|
||||
Quand je rejoins le live
|
||||
Alors j'entends l'audio avec un décalage de 15 secondes
|
||||
Et ce buffer permet une stabilité optimale sur connexion 3G/4G
|
||||
Et le buffer absorbe les fluctuations réseau courtes
|
||||
|
||||
Scénario: Justification buffer 15 secondes vs alternatives
|
||||
Étant donné les différentes options de buffer possibles:
|
||||
| Buffer | Stabilité 3G | Décalage perçu | Décision |
|
||||
| 5s | Faible | Imperceptible | Rejeté |
|
||||
| 10s | Moyenne | Faible | Rejeté |
|
||||
| 15s | Excellente | Acceptable | Choisi |
|
||||
| 20s+ | Très haute | Trop élevé | Rejeté |
|
||||
Alors le buffer de 15 secondes est le meilleur compromis
|
||||
Et la stabilité sur réseau mobile est prioritaire
|
||||
|
||||
Scénario: Continuation du live si sortie de zone géographique
|
||||
Étant donné que j'écoute un live régional "Île-de-France"
|
||||
Et que je suis situé à Paris
|
||||
Quand je me déplace et sors de l'Île-de-France
|
||||
Alors le live continue de jouer normalement
|
||||
Et aucune coupure brutale ne se produit
|
||||
Et l'écoute se termine naturellement
|
||||
|
||||
Scénario: Justification continuation hors zone
|
||||
Étant donné que j'écoute activement un live
|
||||
Quand je sors de la zone géographique ciblée
|
||||
Alors le système ne coupe pas le live
|
||||
Car une coupure brutale dégraderait l'expérience utilisateur
|
||||
Et l'écoute engagée doit pouvoir se terminer naturellement
|
||||
Mais après la fin du live, l'algorithme reprend le fonctionnement normal
|
||||
|
||||
Scénario: Après fin du live, algorithme normal reprend
|
||||
Étant donné que j'ai écouté un live hors zone jusqu'à sa fin
|
||||
Quand le live se termine
|
||||
Alors l'algorithme de recommandation reprend son fonctionnement normal
|
||||
Et je ne reçois plus de contenus hors de ma zone géographique actuelle
|
||||
|
||||
Scénario: Reconnexion rapide après coupure réseau (<90s)
|
||||
Étant donné que j'écoute un live
|
||||
Et que je perds ma connexion réseau pendant 30 secondes
|
||||
Quand ma connexion revient
|
||||
Alors je me reconnecte automatiquement au live
|
||||
Et je reprends l'écoute au moment actuel du live
|
||||
Et je ne reprends pas au buffer ancien (saut temporel transparent)
|
||||
|
||||
Scénario: Reconnexion après coupure réseau de 89 secondes
|
||||
Étant donné que j'écoute un live
|
||||
Et que je perds ma connexion réseau pendant 89 secondes
|
||||
Quand ma connexion revient
|
||||
Alors je me reconnecte au live en cours
|
||||
Et je reprends au moment actuel
|
||||
Car le seuil de 90 secondes n'est pas atteint
|
||||
|
||||
Scénario: Coupure réseau longue (≥90s) - Passage contenu suivant
|
||||
Étant donné que j'écoute un live
|
||||
Et que je perds ma connexion réseau pendant 90 secondes ou plus
|
||||
Quand ma connexion revient
|
||||
Alors je vois le message "Live en cours perdu, passage au contenu suivant"
|
||||
Et l'algorithme me propose un contenu normal (non-live)
|
||||
Et je ne rejoins pas le live précédent
|
||||
|
||||
Scénario: Saut temporel transparent lors de reconnexion
|
||||
Étant donné que j'écoute un live au timestamp 00:05:00
|
||||
Et que je perds ma connexion pendant 45 secondes
|
||||
Quand je me reconnecte
|
||||
Alors je reprends l'écoute au timestamp actuel du live (environ 00:05:45)
|
||||
Et le saut de 45 secondes est transparent
|
||||
Et je ne réentends pas les 45 secondes manquées
|
||||
|
||||
Scénario: Like disponible pendant le live (véhicule arrêté)
|
||||
Étant donné que j'écoute un live
|
||||
Et que mon véhicule est à l'arrêt
|
||||
Quand je clique sur le bouton cœur ❤️
|
||||
Alors un like est enregistré
|
||||
Et mes jauges d'intérêt augmentent de +2% selon les tags du live
|
||||
Et le créateur voit son compteur de likes s'incrémenter en temps réel
|
||||
|
||||
Scénario: Like désactivé pendant le live (véhicule en mouvement)
|
||||
Étant donné que j'écoute un live
|
||||
Et que mon véhicule est en mouvement
|
||||
Quand j'essaie d'accéder aux interactions
|
||||
Alors le bouton cœur est désactivé
|
||||
Et je vois le message "Interactions disponibles uniquement véhicule à l'arrêt"
|
||||
Car la sécurité routière est prioritaire
|
||||
|
||||
Scénario: Abonnement au créateur pendant le live (véhicule arrêté)
|
||||
Étant donné que j'écoute un live d'un créateur non suivi
|
||||
Et que mon véhicule est à l'arrêt
|
||||
Quand je clique sur "S'abonner"
|
||||
Alors l'abonnement est enregistré
|
||||
Et mes jauges d'intérêt augmentent de +5% selon les tags du créateur
|
||||
Et je recevrai des notifications pour ses prochains lives
|
||||
|
||||
Scénario: Skip disponible pendant le live
|
||||
Étant donné que j'écoute un live
|
||||
Quand je clique sur le bouton "Skip" (suivant)
|
||||
Alors je quitte le live immédiatement
|
||||
Et l'algorithme me propose le contenu suivant
|
||||
Et je ne peux pas revenir au live via "Précédent"
|
||||
|
||||
Scénario: Bouton "Précédent" désactivé pendant un live
|
||||
Étant donné que j'écoute un live
|
||||
Quand je regarde les contrôles de lecture
|
||||
Alors le bouton "Précédent" est désactivé (grisé)
|
||||
Car il n'y a pas de sens sur un flux temps réel
|
||||
Et je ne peux pas revenir en arrière dans un live
|
||||
|
||||
Scénario: Chat en direct jamais disponible (décision définitive)
|
||||
Étant donné que j'écoute un live
|
||||
Quand je cherche une fonctionnalité de chat
|
||||
Alors aucun bouton de chat n'est disponible
|
||||
Et aucune interface de messagerie n'est présente
|
||||
Car cette fonctionnalité ne sera jamais implémentée
|
||||
|
||||
Scénario: Message explicatif sur absence de chat
|
||||
Étant donné que j'essaie de chercher comment discuter pendant un live
|
||||
Quand j'accède à l'aide ou aux FAQ
|
||||
Alors je vois le message:
|
||||
"""
|
||||
💬 Les discussions ne sont pas disponibles sur RoadWave pour garantir votre sécurité en voiture et éviter le harcèlement.
|
||||
|
||||
RoadWave privilégie l'écoute passive pour:
|
||||
- Votre sécurité au volant (pas de distraction)
|
||||
- Votre bien-être (pas de harcèlement, toxicité)
|
||||
- Une expérience audio apaisante
|
||||
"""
|
||||
|
||||
Scénario: Réactions emoji jamais disponibles (décision définitive)
|
||||
Étant donné que j'écoute un live
|
||||
Quand je cherche des réactions emoji ou boutons interactifs
|
||||
Alors aucune réaction emoji n'est disponible
|
||||
Car cette fonctionnalité ne sera jamais implémentée
|
||||
Et seuls les likes explicites sont autorisés (véhicule arrêté)
|
||||
|
||||
Scénario: Justification absence chat et réactions
|
||||
Étant donné les raisons de l'absence de chat:
|
||||
| Raison | Justification |
|
||||
| Sécurité routière | Pas de distraction en voiture (focus UX) |
|
||||
| Harcèlement | Évite contenu haineux, insultes, trolling |
|
||||
| Modération | Pas de coût modération temps réel (impossible à scale) |
|
||||
| Simplicité | Écoute passive = expérience uniforme |
|
||||
| Bien-être | Évite toxicité, harcèlement (fléau réseaux sociaux) |
|
||||
| Juridique | Pas de risque contentieux modération chat (DSA EU) |
|
||||
| Différenciation | Positionnement "audio safe" vs plateformes toxiques |
|
||||
Alors cette décision est définitive et non négociable
|
||||
Et RoadWave se positionne comme une plateforme d'écoute passive sécurisée
|
||||
|
||||
Scénario: Compteur d'auditeurs en temps réel visible
|
||||
Étant donné que j'écoute un live
|
||||
Quand je regarde l'interface
|
||||
Alors je vois le nombre d'auditeurs simultanés "247 auditeurs en direct"
|
||||
Et ce compteur se met à jour toutes les 10 secondes
|
||||
Et cela donne une indication de la popularité du live
|
||||
|
||||
Scénario: Indicateur "En direct" clair
|
||||
Étant donné que j'écoute un live
|
||||
Alors je vois clairement un badge rouge "🔴 EN DIRECT"
|
||||
Et je comprends immédiatement que c'est un flux temps réel
|
||||
Et pas un contenu enregistré
|
||||
|
||||
Scénario: Pas de barre de progression sur live
|
||||
Étant donné que j'écoute un live
|
||||
Quand je regarde les contrôles de lecture
|
||||
Alors il n'y a pas de barre de progression
|
||||
Car on ne peut pas se déplacer dans un flux temps réel
|
||||
Et seule la durée écoulée est affichée (ex: "23:45 écoulées")
|
||||
|
||||
Scénario: Transition fluide live vers contenu suivant
|
||||
Étant donné que j'écoute un live
|
||||
Quand le live se termine naturellement
|
||||
Alors le délai de transition habituel de 2 secondes démarre
|
||||
Et le contenu suivant est annoncé normalement
|
||||
Et l'expérience est cohérente avec les contenus classiques
|
||||
|
||||
Scénario: Notification de fin de live
|
||||
Étant donné que j'écoute un live
|
||||
Quand le créateur arrête le live
|
||||
Alors j'entends "Ce live se termine dans 5... 4... 3... 2... 1"
|
||||
Et je vois le message "Live terminé"
|
||||
Et je suis notifié que le replay sera disponible sous peu
|
||||
|
||||
Scénario: Qualité audio adaptative selon connexion
|
||||
Étant donné que j'écoute un live en 4G
|
||||
Et que ma connexion se dégrade vers 3G
|
||||
Quand la bande passante diminue
|
||||
Alors le player HLS natif adapte automatiquement la qualité
|
||||
Et le buffer de 15 secondes absorbe les fluctuations
|
||||
Et l'écoute reste fluide sans coupure
|
||||
|
||||
Scénario: Consommation data pendant écoute live
|
||||
Étant donné que j'écoute un live en Opus 48 kbps
|
||||
Quand j'écoute pendant 1 heure
|
||||
Alors je consomme environ 21.6 MB de data
|
||||
Et cette information peut être affichée dans les paramètres
|
||||
Et l'utilisateur peut être averti si réseau cellulaire
|
||||
|
||||
Scénario: Tunnel ou coupure réseau courte (<15s)
|
||||
Étant donné que j'écoute un live
|
||||
Et que je passe dans un tunnel pendant 10 secondes
|
||||
Quand je ressors du tunnel
|
||||
Alors le buffer de 15 secondes a absorbé la coupure
|
||||
Et l'écoute reprend sans interruption perceptible
|
||||
Et je n'ai même pas remarqué la coupure
|
||||
|
||||
Scénario: Notifications désactivables pour les lives
|
||||
Étant donné que je suis abonné à un créateur
|
||||
Et que je reçois des notifications de ses lives
|
||||
Quand j'accède aux paramètres de notification
|
||||
Alors je peux désactiver spécifiquement les notifications "Live en direct"
|
||||
Et je continue à recevoir les autres notifications
|
||||
Et cela me permet de contrôler les interruptions
|
||||
|
||||
Scénario: Statistiques d'écoute personnelles après un live
|
||||
Étant donné que j'ai écouté un live pendant 45 minutes
|
||||
Quand je consulte mon historique d'écoute
|
||||
Alors je vois l'entrée "[DIRECT] [Titre du live]"
|
||||
Et la durée d'écoute "45 min"
|
||||
Et la date/heure de diffusion
|
||||
Et un lien vers le replay si disponible
|
||||
|
||||
Plan du Scénario: Reconnexion selon durée de coupure
|
||||
Étant donné que j'écoute un live
|
||||
Et que je perds ma connexion pendant <duree_coupure> secondes
|
||||
Quand ma connexion revient
|
||||
Alors le comportement est <comportement>
|
||||
|
||||
Exemples:
|
||||
| duree_coupure | comportement |
|
||||
| 10 | Reconnexion au live en cours |
|
||||
| 30 | Reconnexion au live en cours |
|
||||
| 60 | Reconnexion au live en cours |
|
||||
| 89 | Reconnexion au live en cours |
|
||||
| 90 | Passage au contenu suivant |
|
||||
| 120 | Passage au contenu suivant |
|
||||
|
||||
Plan du Scénario: Actions disponibles selon état véhicule
|
||||
Étant donné que j'écoute un live
|
||||
Et que mon véhicule est <etat_vehicule>
|
||||
Quand j'essaie d'effectuer l'action <action>
|
||||
Alors le résultat est <resultat>
|
||||
|
||||
Exemples:
|
||||
| etat_vehicule | action | resultat |
|
||||
| arrêté | Like | Autorisé |
|
||||
| arrêté | Abonnement | Autorisé |
|
||||
| arrêté | Skip | Autorisé |
|
||||
| en mouvement | Like | Bloqué |
|
||||
| en mouvement | Abonnement | Bloqué |
|
||||
| en mouvement | Skip | Autorisé |
|
||||
|
||||
Plan du Scénario: Interactions jamais disponibles
|
||||
Étant donné que j'écoute un live
|
||||
Quand je cherche l'interaction <interaction>
|
||||
Alors elle est <disponibilite>
|
||||
Car <raison>
|
||||
|
||||
Exemples:
|
||||
| interaction | disponibilite | raison |
|
||||
| Chat en direct | Jamais disponible | Sécurité routière + modération impossible |
|
||||
| Réactions emoji | Jamais disponible | Sécurité routière + distraction |
|
||||
| Précédent | Jamais disponible | Pas de sens sur flux temps réel |
|
||||
| Seek (avancer) | Jamais disponible | Pas de sens sur flux temps réel |
|
||||
@@ -0,0 +1,209 @@
|
||||
# language: fr
|
||||
Fonctionnalité: Comportement auditeur pendant un live
|
||||
En tant qu'auditeur
|
||||
Je veux écouter des lives de manière stable
|
||||
Afin de profiter du contenu en temps réel sans coupures
|
||||
|
||||
Contexte:
|
||||
Étant donné que l'API RoadWave est disponible
|
||||
Et que je suis connecté en tant qu'auditeur
|
||||
Et qu'un créateur diffuse actuellement un live
|
||||
|
||||
Scénario: Rejoindre un live avec buffer de synchronisation 15 secondes
|
||||
Quand je clique sur "Rejoindre le live"
|
||||
Alors la connexion au flux HLS s'établit
|
||||
Et je commence à écouter avec un décalage de 15 secondes par rapport au créateur
|
||||
Et le buffer de 15 secondes garantit une lecture stable
|
||||
|
||||
Scénario: Justification du buffer 15 secondes
|
||||
Étant donné les alternatives de buffer possibles:
|
||||
| buffer | stabilité 3G | stabilité 4G | décalage perceptible | décision |
|
||||
| 5s | Faible | Moyenne | Non | ❌ |
|
||||
| 10s | Moyenne | Bonne | Non | ❌ |
|
||||
| 15s | Bonne | Excellente | Léger acceptable | ✅ |
|
||||
| 20s+ | Excellente | Excellente | Oui | ❌ |
|
||||
Alors le buffer optimal est 15 secondes
|
||||
|
||||
Scénario: Lecture stable sur réseau 3G
|
||||
Étant donné que je suis sur réseau 3G
|
||||
Et que j'écoute un live
|
||||
Quand des micro-coupures réseau surviennent
|
||||
Alors le buffer de 15 secondes absorbe les coupures
|
||||
Et la lecture continue sans interruption perceptible
|
||||
|
||||
Scénario: Lecture stable sur réseau 4G
|
||||
Étant donné que je suis sur réseau 4G
|
||||
Et que j'écoute un live
|
||||
Alors la lecture est fluide
|
||||
Et le buffer de 15 secondes prévient les coupures lors de changement de cellule
|
||||
|
||||
Scénario: Continuation du live en sortant de la zone géographique
|
||||
Étant donné que j'écoute un live régional "Île-de-France"
|
||||
Et que je suis situé en Île-de-France
|
||||
Quand je me déplace et sors du département
|
||||
Alors le live continue de jouer normalement
|
||||
Et je peux écouter jusqu'à la fin naturelle du live
|
||||
Et après la fin du live, l'algorithme propose du contenu correspondant à ma nouvelle position
|
||||
|
||||
Scénario: Abonné dans la zone reçoit notification push
|
||||
Étant donné que je suis abonné au créateur "JeanDupont"
|
||||
Et que je suis situé en Île-de-France
|
||||
Quand "JeanDupont" démarre un live en Île-de-France
|
||||
Alors je reçois une notification push "🔴 JeanDupont est en direct : [Titre du live]"
|
||||
Et quand je tape sur la notification, l'app s'ouvre et le live démarre immédiatement
|
||||
|
||||
Scénario: Abonné hors zone ne reçoit pas de notification
|
||||
Étant donné que je suis abonné au créateur "JeanDupont"
|
||||
Et que je suis situé à Lyon
|
||||
Quand "JeanDupont" démarre un live en Île-de-France
|
||||
Alors je ne reçois pas de notification push
|
||||
Et cela évite la frustration de ne pas pouvoir écouter un live hors zone
|
||||
|
||||
Scénario: Découverte d'un live via l'algorithme de recommandation
|
||||
Étant donné que je suis dans la zone géographique du live
|
||||
Et que je navigue dans l'app avec "Suivant"
|
||||
Quand l'algorithme propose un live en cours
|
||||
Alors je vois l'indicateur "🔴 EN DIRECT"
|
||||
Et je peux choisir de le rejoindre ou de passer au suivant
|
||||
|
||||
Scénario: Reconnexion rapide après coupure réseau (moins de 90 secondes)
|
||||
Étant donné que j'écoute un live
|
||||
Quand je perds ma connexion réseau pendant 45 secondes
|
||||
Et que je retrouve ma connexion
|
||||
Alors je reprends le live au moment actuel (pas au buffer ancien)
|
||||
Et le saut temporel est transparent (pas de message d'erreur)
|
||||
Et je ne rate que quelques secondes de contenu
|
||||
|
||||
Scénario: Reconnexion longue après coupure réseau (90 secondes ou plus)
|
||||
Étant donné que j'écoute un live
|
||||
Quand je perds ma connexion réseau pendant 90 secondes
|
||||
Et que je retrouve ma connexion
|
||||
Alors je vois le message "Live en cours perdu, passage au contenu suivant"
|
||||
Et l'algorithme propose automatiquement le contenu suivant
|
||||
Et je peux manuellement revenir au live s'il est toujours en cours
|
||||
|
||||
Scénario: Interactions disponibles pendant le live - Like
|
||||
Étant donné que j'écoute un live
|
||||
Et que mon véhicule est à l'arrêt
|
||||
Quand je clique sur le bouton "❤️ Like"
|
||||
Alors le like est enregistré immédiatement
|
||||
Et le compteur de likes visible par le créateur s'incrémente
|
||||
Et ma jauge d'intérêt pour les tags du live augmente de +2%
|
||||
|
||||
Scénario: Interactions disponibles pendant le live - Abonnement
|
||||
Étant donné que j'écoute un live
|
||||
Et que je ne suis pas encore abonné au créateur
|
||||
Quand je clique sur le bouton "S'abonner"
|
||||
Alors je m'abonne au créateur
|
||||
Et ma jauge d'intérêt pour tous les tags du créateur augmente de +5%
|
||||
Et je recevrai des notifications pour ses prochains lives
|
||||
|
||||
Scénario: Interactions disponibles pendant le live - Skip
|
||||
Étant donné que j'écoute un live
|
||||
Quand j'appuie sur "Suivant" (ou commande au volant)
|
||||
Alors je quitte le live immédiatement
|
||||
Et l'algorithme propose le contenu suivant
|
||||
Et si j'ai écouté moins de 10 secondes, ma jauge d'intérêt diminue de -0.5%
|
||||
|
||||
Scénario: Commande Précédent désactivée pendant un live
|
||||
Étant donné que j'écoute un live
|
||||
Quand j'appuie sur "Précédent" (ou commande au volant)
|
||||
Alors rien ne se passe
|
||||
Et un message d'information s'affiche brièvement "Précédent non disponible sur les lives"
|
||||
|
||||
Scénario: Chat en direct désactivé (décision définitive)
|
||||
Étant donné que j'écoute un live
|
||||
Alors aucune interface de chat n'est disponible
|
||||
Et je ne peux pas envoyer de messages au créateur
|
||||
Et je ne peux pas voir de messages d'autres auditeurs
|
||||
Et cette fonctionnalité ne sera jamais implémentée
|
||||
|
||||
Scénario: Réactions emoji désactivées (décision définitive)
|
||||
Étant donné que j'écoute un live
|
||||
Alors aucune réaction emoji n'est disponible
|
||||
Et je ne peux pas envoyer d'emoji en temps réel
|
||||
Et cette fonctionnalité ne sera jamais implémentée
|
||||
|
||||
Scénario: Message d'information sur l'absence de chat
|
||||
Étant donné que j'écoute mon premier live
|
||||
Quand j'accède à l'interface du live
|
||||
Alors je vois un bandeau informatif "💬 Les discussions ne sont pas disponibles sur RoadWave pour garantir votre sécurité en voiture et éviter le harcèlement."
|
||||
Et ce bandeau n'apparaît qu'une seule fois (première expérience)
|
||||
|
||||
Scénario: Signalement d'un live en cours
|
||||
Étant donné que j'écoute un live
|
||||
Et que le contenu me semble inapproprié
|
||||
Quand je clique sur le bouton "Signaler"
|
||||
Alors je vois les catégories de signalement:
|
||||
| catégorie |
|
||||
| Haine et violence |
|
||||
| Contenu sexuel |
|
||||
| Illégalité |
|
||||
| Droits d'auteur |
|
||||
| Désinformation dangereuse |
|
||||
| Harcèlement |
|
||||
| Autre |
|
||||
Et quand je sélectionne une catégorie
|
||||
Alors le signalement est envoyé en priorité selon la catégorie
|
||||
Et un modérateur peut écouter le live en temps réel si besoin
|
||||
|
||||
Scénario: Statistiques visibles par les auditeurs pendant le live
|
||||
Étant donné que j'écoute un live
|
||||
Quand je consulte les informations du live
|
||||
Alors je vois:
|
||||
| information | exemple valeur |
|
||||
| Nombre d'auditeurs | 247 personnes |
|
||||
| Durée du live | 1h 23min |
|
||||
| Nom du créateur | @JeanDupont |
|
||||
| Zone de diffusion | Île-de-France |
|
||||
| Tags | Actualité, Société |
|
||||
Mais je ne vois pas les likes ou autres métriques détaillées
|
||||
|
||||
Scénario: Compteur d'auditeurs arrondi pour préserver la vie privée
|
||||
Étant donné que j'écoute un live avec exactement 247 auditeurs
|
||||
Quand je consulte le nombre d'auditeurs
|
||||
Alors je vois "~250 auditeurs" (arrondi à la dizaine supérieure)
|
||||
|
||||
Scénario: Qualité audio adaptative pendant le live
|
||||
Étant donné que j'écoute un live
|
||||
Quand ma connexion passe de 4G à 3G
|
||||
Alors la qualité audio s'adapte automatiquement
|
||||
Et je passe de 48 kbps à 24 kbps Opus
|
||||
Et la transition est transparente sans coupure
|
||||
|
||||
Scénario: Consommation de données pendant un live
|
||||
Étant donné que j'écoute un live en qualité standard 48 kbps
|
||||
Et que j'écoute pendant 1 heure
|
||||
Alors j'ai consommé environ 21.6 MB de données mobiles
|
||||
Et cette consommation est affichée dans les paramètres de l'app
|
||||
|
||||
Scénario: Lecture du replay après la fin du live
|
||||
Étant donné que j'écoute un live depuis 30 minutes
|
||||
Quand le créateur arrête le live
|
||||
Alors je vois le message "Le live est terminé. Le replay sera disponible dans quelques minutes"
|
||||
Et le contenu suivant est automatiquement proposé après 2 secondes
|
||||
|
||||
Scénario: Notification de disponibilité du replay
|
||||
Étant donné que j'ai écouté un live jusqu'à la fin
|
||||
Et que le replay est publié 8 minutes plus tard
|
||||
Quand je rouvre l'application
|
||||
Alors je vois une notification in-app "Le replay de [Titre] est maintenant disponible"
|
||||
Et je peux cliquer pour l'écouter immédiatement
|
||||
|
||||
Scénario: Aucune publicité pendant un live pour utilisateurs gratuits
|
||||
Étant donné que je suis un utilisateur gratuit
|
||||
Et que j'écoute un live
|
||||
Alors aucune publicité n'est insérée pendant le live
|
||||
Et la publicité apparaît seulement entre le live et le contenu suivant
|
||||
|
||||
Scénario: Détection de contexte voiture pendant un live
|
||||
Étant donné que j'écoute un live
|
||||
Et que ma vitesse est supérieure à 10 km/h
|
||||
Alors l'interface tactile est désactivée pour la sécurité
|
||||
Et seules les commandes au volant sont actives (Play/Pause/Suivant)
|
||||
|
||||
Scénario: Détection de contexte piéton pendant un live
|
||||
Étant donné que j'écoute un live
|
||||
Et que ma vitesse est inférieure à 5 km/h
|
||||
Alors l'interface tactile complète est disponible
|
||||
Et je peux liker, m'abonner, signaler via l'écran tactile
|
||||
162
docs/domains/content/features/radio-live/demarrage-live.feature
Normal file
162
docs/domains/content/features/radio-live/demarrage-live.feature
Normal file
@@ -0,0 +1,162 @@
|
||||
# language: fr
|
||||
Fonctionnalité: Démarrage d'un live
|
||||
En tant que créateur
|
||||
Je veux démarrer une diffusion en direct
|
||||
Afin de partager du contenu audio en temps réel avec mes auditeurs
|
||||
|
||||
Contexte:
|
||||
Étant donné que l'API RoadWave est disponible
|
||||
Et que je suis connecté en tant que créateur vérifié
|
||||
Et que j'ai les permissions de diffusion live
|
||||
|
||||
Scénario: Vérifications pré-live réussies
|
||||
Étant donné que ma connexion upload est supérieure à 1 Mbps
|
||||
Et que j'ai autorisé l'accès au microphone
|
||||
Et que j'ai défini une zone de diffusion "Île-de-France"
|
||||
Quand je lance les vérifications pré-live
|
||||
Alors toutes les vérifications sont validées
|
||||
Et je peux démarrer le live
|
||||
|
||||
Scénario: Échec pré-live avec connexion insuffisante
|
||||
Étant donné que ma connexion upload est de 0.5 Mbps
|
||||
Quand je lance les vérifications pré-live
|
||||
Alors je vois un warning "Connexion insuffisante pour garantir une diffusion stable (minimum 1 Mbps)"
|
||||
Et je peux choisir de continuer quand même ou d'annuler
|
||||
|
||||
Scénario: Échec pré-live sans autorisation microphone
|
||||
Étant donné que je n'ai pas autorisé l'accès au microphone
|
||||
Quand j'essaie de démarrer un live
|
||||
Alors je vois le message "Accès au microphone requis pour démarrer un live"
|
||||
Et je suis redirigé vers les paramètres système
|
||||
|
||||
Scénario: Échec pré-live sans zone de diffusion définie
|
||||
Étant donné que je n'ai pas défini de zone de diffusion
|
||||
Quand j'essaie de démarrer un live
|
||||
Alors je vois le message "Veuillez définir une zone de diffusion avant de démarrer"
|
||||
Et je suis redirigé vers le formulaire de configuration du live
|
||||
|
||||
Scénario: Démarrage live avec buffer 15 secondes
|
||||
Étant donné que toutes les vérifications pré-live sont validées
|
||||
Quand j'appuie sur "Démarrer live"
|
||||
Alors je vois le message "Live démarre dans 15s... Testez votre micro"
|
||||
Et un compte à rebours de 15 secondes s'affiche
|
||||
Et mon flux audio est enregistré pendant ces 15 secondes
|
||||
Et le live n'est pas encore visible publiquement
|
||||
|
||||
Scénario: Live devient public après buffer initial
|
||||
Étant donné que j'ai démarré un live
|
||||
Et que le buffer de 15 secondes s'est écoulé
|
||||
Alors le live devient public
|
||||
Et les auditeurs peuvent le rejoindre
|
||||
Et les abonnés dans la zone reçoivent une notification push
|
||||
|
||||
Scénario: Notification push aux abonnés dans la zone géographique
|
||||
Étant donné que j'ai 1000 abonnés au total
|
||||
Et que 300 abonnés sont situés en Île-de-France
|
||||
Et que 700 abonnés sont situés hors Île-de-France
|
||||
Quand mon live en Île-de-France devient public
|
||||
Alors 300 abonnés reçoivent une notification push "🔴 [Mon pseudo] est en direct : [Titre live]"
|
||||
Et 700 abonnés ne reçoivent pas de notification
|
||||
|
||||
Scénario: Configuration métadonnées obligatoires pour un live
|
||||
Quand je configure un nouveau live
|
||||
Alors je dois renseigner:
|
||||
| champ | format | validation |
|
||||
| Titre | 5-100 caractères | Obligatoire |
|
||||
| Tags | 1-3 centres intérêt| Sélection liste prédéfinie |
|
||||
| Classification âge | Enum | Tout public / 13+ / 16+ / 18+ |
|
||||
| Zone diffusion | Geo | Ville / Département / Région / National |
|
||||
|
||||
Scénario: Validation échouée avec titre trop court
|
||||
Quand j'essaie de créer un live avec le titre "Live"
|
||||
Alors la validation échoue
|
||||
Et je vois le message "Le titre doit contenir entre 5 et 100 caractères"
|
||||
|
||||
Scénario: Validation échouée sans tags
|
||||
Étant donné que j'ai rempli tous les champs sauf les tags
|
||||
Quand j'essaie de démarrer le live
|
||||
Alors la validation échoue
|
||||
Et je vois le message "Veuillez sélectionner entre 1 et 3 centres d'intérêt"
|
||||
|
||||
Scénario: Limite de durée 8 heures
|
||||
Étant donné que mon live dure depuis 7 heures et 30 minutes
|
||||
Alors je vois un warning "Votre live se terminera dans 30 min"
|
||||
Et le message est affiché de manière non intrusive
|
||||
|
||||
Scénario: Arrêt automatique à 8 heures
|
||||
Étant donné que mon live dure depuis 8 heures
|
||||
Alors le live s'arrête automatiquement
|
||||
Et je vois le message "Durée maximale atteinte (8 heures). Vous pouvez redémarrer un nouveau live si nécessaire"
|
||||
Et le processus de traitement post-live démarre
|
||||
|
||||
Scénario: Diffusion contenu interdit - Concert en direct
|
||||
Étant donné que je diffuse un concert en direct depuis une salle
|
||||
Et qu'un auditeur signale le contenu pour "Violation droits d'auteur"
|
||||
Quand un modérateur écoute le live
|
||||
Et qu'il confirme la violation
|
||||
Alors le live est arrêté immédiatement
|
||||
Et je reçois un Strike 2 (suspension 7 jours)
|
||||
Et je vois le message "Votre live a été interrompu pour violation des droits d'auteur"
|
||||
Et le replay n'est pas publié
|
||||
|
||||
Scénario: Diffusion contenu interdit - Événement sportif payant
|
||||
Étant donné que je diffuse un match de football avec droits TV
|
||||
Et que le contenu est détecté par l'IA audio fingerprint
|
||||
Quand la détection est confirmée
|
||||
Alors le live est arrêté immédiatement
|
||||
Et je reçois un Strike 2 (suspension 7 jours)
|
||||
|
||||
Scénario: Diffusion contenu violent
|
||||
Étant donné que je diffuse du contenu violent (agression physique)
|
||||
Et que 5 auditeurs signalent le contenu
|
||||
Quand un modérateur vérifie en temps réel
|
||||
Et confirme la violence
|
||||
Alors le live est coupé immédiatement
|
||||
Et je reçois un Strike 3 immédiat (suspension 30 jours)
|
||||
Et le replay n'est pas publié
|
||||
|
||||
Scénario: Diffusion contenu illégal
|
||||
Étant donné que je diffuse du contenu illégal (apologie terrorisme, contenu pédopornographique)
|
||||
Et que des auditeurs signalent le contenu
|
||||
Quand un modérateur vérifie en temps réel
|
||||
Et confirme le contenu illégal
|
||||
Alors le live est coupé immédiatement
|
||||
Et je reçois un Strike 4 (ban définitif)
|
||||
Et mon compte est banni définitivement
|
||||
Et les autorités compétentes sont immédiatement notifiées
|
||||
Et le replay n'est pas publié
|
||||
|
||||
Scénario: Détection musique protégée en arrière-plan
|
||||
Étant donné que mon live contient de la musique protégée en fond
|
||||
Quand l'IA audio fingerprint détecte la violation après 2 minutes
|
||||
Alors je reçois un avertissement en direct "Musique protégée détectée. Veuillez couper le son ou risquez un arrêt du live"
|
||||
Et j'ai 30 secondes pour corriger
|
||||
Et si je ne corrige pas, le live est arrêté avec Strike 1
|
||||
|
||||
Scénario: Signalement pendant un live
|
||||
Étant donné que je diffuse un live
|
||||
Et qu'un auditeur clique sur "Signaler"
|
||||
Quand l'auditeur sélectionne la catégorie "Harcèlement"
|
||||
Alors le signalement est envoyé en priorité HAUTE
|
||||
Et un modérateur peut écouter le live en temps réel
|
||||
Et le live continue pendant l'écoute de vérification
|
||||
|
||||
Scénario: Dépassement nombre de lives simultanés autorisés (limite plateforme)
|
||||
Étant donné que la plateforme héberge actuellement 2000 lives simultanés
|
||||
Et que c'est la limite de l'infrastructure actuelle
|
||||
Quand j'essaie de démarrer un nouveau live
|
||||
Alors je vois le message "Capacité maximale atteinte. Veuillez réessayer dans quelques minutes"
|
||||
Et ma demande est mise en file d'attente prioritaire si je suis créateur Premium
|
||||
|
||||
Scénario: Premier live d'un nouveau créateur
|
||||
Étant donné que je n'ai jamais diffusé de live auparavant
|
||||
Et que j'ai moins de 3 contenus validés
|
||||
Quand j'essaie de démarrer mon premier live
|
||||
Alors je vois le message "Les lives sont disponibles après validation de vos 3 premiers contenus"
|
||||
Et le bouton "Démarrer live" est désactivé
|
||||
|
||||
Scénario: Créateur avec score de confiance faible
|
||||
Étant donné que j'ai 2 strikes actifs
|
||||
Quand j'essaie de démarrer un live
|
||||
Alors je vois le message "Fonctionnalité live temporairement indisponible suite à vos sanctions"
|
||||
Et je dois attendre la fin de ma suspension
|
||||
@@ -0,0 +1,63 @@
|
||||
# language: fr
|
||||
|
||||
@api @radio-live @replay @mvp
|
||||
Fonctionnalité: Enregistrement et publication de replays radio live
|
||||
|
||||
En tant que créateur radio
|
||||
Je veux enregistrer mes lives et les publier en replay
|
||||
Afin d'étendre la durée de vie de mon contenu
|
||||
|
||||
Scénario: Enregistrement automatique du live
|
||||
Étant donné un créateur "alice@roadwave.fr" qui lance un live
|
||||
Quand le live démarre
|
||||
Alors l'enregistrement démarre automatiquement
|
||||
Et est stocké sur S3 en temps réel (streaming)
|
||||
Et un événement "LIVE_RECORDING_STARTED" est enregistré
|
||||
|
||||
Scénario: Publication automatique du replay après le live
|
||||
Étant donné un créateur "bob@roadwave.fr" qui termine son live
|
||||
Quand le live se termine
|
||||
Alors le replay est disponible immédiatement
|
||||
Et apparaît dans "Replays récents"
|
||||
Et conserve les métadonnées du live (titre, description)
|
||||
Et un événement "REPLAY_AUTO_PUBLISHED" est enregistré
|
||||
|
||||
Scénario: Édition du replay avant publication
|
||||
Étant donné un créateur "charlie@roadwave.fr" avec un replay enregistré
|
||||
Quand il accède au replay
|
||||
Alors il peut:
|
||||
| Action | Disponible |
|
||||
| Couper le début/fin | Oui |
|
||||
| Supprimer des passages | Oui |
|
||||
| Ajouter des chapitres | Oui |
|
||||
| Modifier le titre | Oui |
|
||||
Et republier après édition
|
||||
Et un événement "REPLAY_EDITED" est enregistré
|
||||
|
||||
Scénario: Conversion automatique en podcast
|
||||
Étant donné un créateur "david@roadwave.fr" avec replay
|
||||
Quand il active "Convertir en podcast"
|
||||
Alors le replay devient un podcast téléchargeable
|
||||
Et est ajouté au flux RSS du créateur
|
||||
Et compatible avec Apple Podcasts / Spotify
|
||||
Et un événement "REPLAY_CONVERTED_TO_PODCAST" est enregistré
|
||||
|
||||
Scénario: Durée de rétention des replays configurab le
|
||||
Étant donné un créateur "eve@roadwave.fr"
|
||||
Quand il configure la rétention des replays
|
||||
Alors il peut choisir:
|
||||
| Durée | Coût stockage |
|
||||
| 7 jours | Gratuit |
|
||||
| 30 jours | 1€/mois |
|
||||
| 1 an | 5€/mois |
|
||||
| Permanent | 10€/mois |
|
||||
Et un événement "REPLAY_RETENTION_CONFIGURED" est enregistré
|
||||
|
||||
Scénario: Statistiques des replays vs live
|
||||
Étant donné un créateur "frank@roadwave.fr"
|
||||
Alors il voit les comparaisons:
|
||||
| Métrique | Live | Replay |
|
||||
| Auditeurs uniques | 234 | 567 |
|
||||
| Durée moyenne écoute | 42min | 28min |
|
||||
| Taux de complétion | 65% | 48% |
|
||||
Et un événement "REPLAY_STATS_COMPARED" est enregistré
|
||||
@@ -0,0 +1,52 @@
|
||||
# language: fr
|
||||
|
||||
@api @radio-live @moderation @mvp
|
||||
Fonctionnalité: Interdictions et modération des lives
|
||||
|
||||
En tant que plateforme
|
||||
Je veux modérer les lives en temps réel
|
||||
Afin de prévenir les contenus inappropriés
|
||||
|
||||
Scénario: Détection automatique de mots interdits
|
||||
Étant donné un live en cours avec transcription automatique
|
||||
Quand un mot interdit est détecté
|
||||
Alors une alerte est envoyée aux modérateurs
|
||||
Et le segment est marqué pour review
|
||||
Et un événement "LIVE_FORBIDDEN_WORD_DETECTED" est enregistré
|
||||
|
||||
Scénario: Coupure immédiate du live par modérateur
|
||||
Étant donné un modérateur qui détecte du contenu inapproprié
|
||||
Quand il clique sur "Couper le live"
|
||||
Alors le live est stoppé immédiatement
|
||||
Et les auditeurs voient "Live interrompu par modération"
|
||||
Et le créateur reçoit une notification avec raison
|
||||
Et un événement "LIVE_CUT_BY_MODERATOR" est enregistré
|
||||
|
||||
Scénario: Suspension temporaire du droit de faire des lives
|
||||
Étant donné un créateur "alice@roadwave.fr" qui enfreint les règles
|
||||
Quand un modérateur applique une sanction
|
||||
Alors le créateur ne peut plus lancer de live pendant X jours
|
||||
Et ses replays restent accessibles (si conformes)
|
||||
Et un événement "LIVE_SUSPENSION_APPLIED" est enregistré
|
||||
|
||||
Scénario: Signalement en temps réel par les auditeurs
|
||||
Étant donné un auditeur qui détecte du contenu problématique
|
||||
Quand il clique sur "Signaler"
|
||||
Alors le signalement est envoyé immédiatement aux modérateurs
|
||||
Et inclut le timestamp exact du problème
|
||||
Et un événement "LIVE_REPORTED_BY_USER" est enregistré
|
||||
|
||||
Scénario: Délai obligatoire de 7 secondes (broadcast delay)
|
||||
Étant donné un live en cours
|
||||
Alors un délai de 7 secondes est appliqué
|
||||
Et permet de couper le flux si nécessaire
|
||||
Et les auditeurs ne perçoivent pas le délai
|
||||
Et un événement "LIVE_BROADCAST_DELAY_ACTIVE" est enregistré
|
||||
|
||||
Scénario: Historique des infractions du créateur
|
||||
Étant donné un modérateur qui évalue un créateur
|
||||
Alors il voit l'historique:
|
||||
| Date | Infraction | Sanction |
|
||||
| 2026-01-15 | Langage inapproprié | Avertissement |
|
||||
| 2025-12-10 | Spam | Suspension 3j |
|
||||
Et un événement "CREATOR_INFRACTION_HISTORY_VIEWED" est enregistré
|
||||
Reference in New Issue
Block a user