Initial commit
This commit is contained in:
jpgiannetti
279
features/premium/multi-devices-detection.feature
Normal file
279
features/premium/multi-devices-detection.feature
Normal file
@@ -0,0 +1,279 @@
|
||||
# language: fr
|
||||
Fonctionnalité: Multi-devices et détection simultanée
|
||||
En tant qu'abonné Premium
|
||||
Je veux utiliser mon compte sur plusieurs appareils
|
||||
Mais limité à 1 seul stream actif à la fois pour éviter le partage abusif
|
||||
|
||||
Contexte:
|
||||
Étant donné que je suis un utilisateur Premium actif
|
||||
Et que mon compte est valide
|
||||
|
||||
# ===== LIMITE 1 STREAM ACTIF =====
|
||||
|
||||
Scénario: 1 seul stream actif autorisé par compte
|
||||
Étant donné que je n'écoute rien actuellement
|
||||
Quand je lance un contenu sur mon iPhone
|
||||
Alors le stream démarre normalement
|
||||
Et Redis enregistre: active_streams:{user_id} = {device_id: "iPhone", started_at: timestamp}
|
||||
|
||||
Scénario: Détection connexion simultanée - Arrêt premier device
|
||||
Étant donné que j'écoute un contenu sur mon iPhone
|
||||
Quand je lance un contenu sur mon iPad
|
||||
Alors le système détecte une session active sur iPhone
|
||||
Et la lecture sur iPhone est arrêtée immédiatement (WebSocket close)
|
||||
Et je vois sur iPhone: "Lecture interrompue : votre compte est utilisé sur un autre appareil"
|
||||
Et la lecture démarre sur iPad normalement
|
||||
|
||||
Scénario: Message explicite sur device interrompu
|
||||
Étant donné que ma lecture sur iPhone vient d'être interrompue
|
||||
Quand je regarde l'écran de mon iPhone
|
||||
Alors je vois une overlay avec le message:
|
||||
"""
|
||||
🔴 Lecture interrompue
|
||||
|
||||
Votre compte Premium est utilisé sur un autre appareil.
|
||||
|
||||
Un seul stream actif est autorisé à la fois pour protéger
|
||||
les revenus des créateurs et éviter le partage de compte.
|
||||
"""
|
||||
Et un bouton "Reprendre ici" est disponible
|
||||
|
||||
Scénario: Reprendre lecture sur device interrompu
|
||||
Étant donné que ma lecture sur iPhone a été interrompue
|
||||
Et que je veux reprendre sur iPhone
|
||||
Quand je clique sur "Reprendre ici"
|
||||
Alors la lecture démarre sur iPhone
|
||||
Et l'iPad est à son tour interrompu avec le même message
|
||||
Et le "ping-pong" entre devices est possible (mais pénible)
|
||||
|
||||
# ===== IMPLÉMENTATION TECHNIQUE REDIS =====
|
||||
|
||||
Scénario: Enregistrement session active dans Redis
|
||||
Étant donné que je lance un contenu sur mon iPhone
|
||||
Quand la lecture démarre
|
||||
Alors une entrée Redis est créée:
|
||||
```
|
||||
Key: active_streams:{user_id}
|
||||
Value: {
|
||||
"device_id": "iPhone-ABC123",
|
||||
"started_at": "2025-06-15T14:30:00Z",
|
||||
"content_id": "xyz789"
|
||||
}
|
||||
TTL: 300 secondes (5 minutes)
|
||||
```
|
||||
|
||||
Scénario: Heartbeat toutes les 30 secondes pour maintenir session
|
||||
Étant donné que j'écoute un contenu sur mon iPhone
|
||||
Quand 30 secondes s'écoulent
|
||||
Alors l'app envoie un heartbeat au serveur
|
||||
Et le serveur refresh le TTL Redis à 300 secondes
|
||||
Et la session reste active
|
||||
|
||||
Scénario: Session considérée morte après 5 minutes sans heartbeat
|
||||
Étant donné que j'écoute un contenu sur mon iPhone
|
||||
Mais que l'app crash ou que le réseau coupe
|
||||
Quand 5 minutes s'écoulent sans heartbeat
|
||||
Alors l'entrée Redis expire automatiquement (TTL atteint)
|
||||
Et je peux relancer sur n'importe quel device sans conflit
|
||||
|
||||
Scénario: Vérification session avant démarrage lecture
|
||||
Étant donné que je veux lancer un contenu sur mon iPad
|
||||
Quand j'appuie sur Play
|
||||
Alors le serveur vérifie Redis: active_streams:{user_id}
|
||||
Et si une session existe sur un autre device, elle est tuée
|
||||
Et la nouvelle session iPad est enregistrée dans Redis
|
||||
|
||||
Scénario: Gestion multi-utilisateurs simultanés
|
||||
Étant donné que 100 000 utilisateurs Premium écoutent simultanément
|
||||
Quand Redis stocke 100 000 entrées active_streams
|
||||
Alors chaque entrée a un TTL de 5 minutes
|
||||
Et Redis gère facilement cette charge (~10 MB de RAM)
|
||||
Et les vérifications sont quasi-instantanées (O(1))
|
||||
|
||||
# ===== EXCEPTIONS ET CAS PARTICULIERS =====
|
||||
|
||||
Scénario: Contenus téléchargés (offline) ne comptent pas comme stream
|
||||
Étant donné que j'ai téléchargé 20 contenus en mode offline
|
||||
Quand j'écoute un contenu téléchargé sur mon iPhone sans réseau
|
||||
Alors aucune session active n'est enregistrée dans Redis
|
||||
Et je peux écouter offline pendant qu'un autre device stream online
|
||||
Car le contenu offline ne consomme pas de bande passante serveur
|
||||
|
||||
Scénario: Transition rapide device <10s tolérée
|
||||
Étant donné que j'écoute dans ma voiture sur mon iPhone
|
||||
Et que j'arrive chez moi
|
||||
Quand je lance la lecture sur mon iPad dans les 10 secondes
|
||||
Alors la transition est considérée comme un changement de device légitime
|
||||
Et aucun message d'erreur n'est affiché sur iPhone
|
||||
Et la lecture reprend exactement où j'étais sur iPad
|
||||
|
||||
Scénario: Détection transition rapide via timestamps
|
||||
Étant donné que la session iPhone a started_at = 14:30:00
|
||||
Quand je lance sur iPad à 14:30:05 (5 secondes après)
|
||||
Alors le serveur détecte: diff = 5s < 10s
|
||||
Et applique une "graceful transition" (pas de message d'erreur iPhone)
|
||||
Et Redis met à jour: active_streams:{user_id} = {device_id: "iPad", ...}
|
||||
|
||||
Scénario: Plusieurs devices disponibles mais 1 seul actif
|
||||
Étant donné que je possède:
|
||||
| device | status |
|
||||
| iPhone | Installé |
|
||||
| iPad | Installé |
|
||||
| MacBook (web) | Connecté |
|
||||
| Android (conjoint)| Installé |
|
||||
Quand je lance un stream sur n'importe quel device
|
||||
Alors seulement 1 peut être actif à la fois
|
||||
Et les autres devices sont en "standby"
|
||||
|
||||
# ===== JUSTIFICATIONS =====
|
||||
|
||||
Scénario: Justification anti-partage compte
|
||||
Étant donné qu'un utilisateur Premium partage son compte avec un ami
|
||||
Quand les 2 personnes essaient d'écouter simultanément
|
||||
Alors la lecture est constamment interrompue sur l'un ou l'autre
|
||||
Et l'expérience devient inutilisable
|
||||
Et cela décourage fortement le partage de compte
|
||||
|
||||
Scénario: Justification protection revenus créateurs
|
||||
Étant donné que 1 abonnement Premium = 4.99€/mois
|
||||
Quand 70% sont reversés aux créateurs (3.49€)
|
||||
Alors les créateurs sont rémunérés pour 1 personne
|
||||
Et si 2 personnes utilisent le même compte simultanément, c'est injuste
|
||||
Et la limite 1 stream protège l'équité du système
|
||||
|
||||
Scénario: Justification UX claire
|
||||
Étant donné qu'un stream est interrompu sur un device
|
||||
Quand l'utilisateur voit le message explicite
|
||||
Alors il comprend immédiatement pourquoi (autre device actif)
|
||||
Et il peut choisir de reprendre sur le device actuel ou l'autre
|
||||
Et il n'y a pas de confusion ou frustration
|
||||
|
||||
Scénario: Comparaison avec Spotify (limite 1 stream)
|
||||
Étant donné que Spotify Premium limite aussi à 1 stream actif
|
||||
Quand RoadWave applique la même règle
|
||||
Alors les utilisateurs connaissent déjà ce comportement
|
||||
Et cela paraît normal et accepté par l'industrie
|
||||
|
||||
Scénario: Comparaison avec Netflix (plusieurs streams selon formule)
|
||||
Étant donné que Netflix permet 1-4 streams selon la formule
|
||||
Quand RoadWave limite à 1 stream pour tous
|
||||
Alors c'est plus strict que Netflix
|
||||
Mais Netflix cible le foyer familial (TV partagée)
|
||||
Alors que RoadWave cible l'individu conducteur (usage personnel)
|
||||
|
||||
# ===== MONITORING ET DÉTECTION ABUS =====
|
||||
|
||||
Scénario: Détection pattern suspect - Changements devices fréquents
|
||||
Étant donné qu'un utilisateur change de device 50 fois en 1 heure
|
||||
Quand le système détecte ce pattern anormal
|
||||
Alors une alerte est générée pour l'équipe modération
|
||||
Et le compte peut être marqué pour surveillance
|
||||
Et si abus confirmé, suspension possible
|
||||
|
||||
Scénario: Logs des changements de device
|
||||
Étant donné que je change de device plusieurs fois par jour
|
||||
Quand les changements sont loggés
|
||||
Alors chaque événement est enregistré:
|
||||
| timestamp | from_device | to_device | content_id |
|
||||
| 2025-06-15 08:30:00 | null | iPhone | abc123 |
|
||||
| 2025-06-15 09:15:00 | iPhone | iPad | def456 |
|
||||
| 2025-06-15 18:30:00 | iPad | iPhone | ghi789 |
|
||||
Et ces logs aident à détecter les partages de compte
|
||||
|
||||
Scénario: Métriques admin - Changements devices par utilisateur
|
||||
Étant donné qu'un admin consulte les métriques de streaming
|
||||
Quand il accède au dashboard
|
||||
Alors il voit:
|
||||
| métrique | valeur |
|
||||
| Utilisateurs Premium actifs | 12,547 |
|
||||
| Changements de device/jour (médiane) | 2 |
|
||||
| Utilisateurs >10 changements/jour | 47 (0.4%) |
|
||||
| Comptes suspects (>20 changements/j) | 3 |
|
||||
|
||||
Scénario: Email d'avertissement si changements excessifs
|
||||
Étant donné que je change de device 30 fois par jour pendant 3 jours
|
||||
Quand le système détecte ce pattern
|
||||
Alors je reçois un email d'avertissement:
|
||||
"""
|
||||
⚠️ Activité inhabituelle détectée sur votre compte
|
||||
|
||||
Nous avons détecté un nombre anormalement élevé de changements de device (30/jour).
|
||||
|
||||
Rappel: Le partage de compte Premium est interdit selon nos CGU.
|
||||
Un seul stream actif est autorisé à la fois.
|
||||
|
||||
Si cette activité continue, votre compte pourra être suspendu.
|
||||
"""
|
||||
|
||||
Scénario: Suspension compte après avertissement ignoré
|
||||
Étant donné que j'ai reçu un email d'avertissement il y a 7 jours
|
||||
Mais que je continue à changer de device 30 fois par jour
|
||||
Quand l'équipe modération examine le compte
|
||||
Alors mon compte Premium peut être suspendu pour partage abusif
|
||||
Et je reçois un email de suspension avec justification
|
||||
|
||||
# ===== SUPPORT UTILISATEUR =====
|
||||
|
||||
Scénario: FAQ - Pourquoi ma lecture s'arrête quand j'utilise un autre device ?
|
||||
Étant donné que je consulte la FAQ Premium
|
||||
Quand je cherche "lecture interrompue"
|
||||
Alors je trouve la réponse:
|
||||
"""
|
||||
Q: Pourquoi ma lecture s'arrête quand j'utilise un autre appareil ?
|
||||
|
||||
R: Votre abonnement Premium autorise 1 seul stream actif à la fois.
|
||||
Si vous lancez la lecture sur un autre appareil, le premier est automatiquement arrêté.
|
||||
|
||||
Pourquoi cette limite ?
|
||||
- Protéger les revenus des créateurs (1 abonnement = 1 personne)
|
||||
- Éviter le partage de compte abusif
|
||||
|
||||
Vous pouvez utiliser autant d'appareils que vous voulez, mais un seul peut lire à la fois.
|
||||
"""
|
||||
|
||||
Scénario: Support - Utilisateur pense être piraté
|
||||
Étant donné qu'un utilisateur voit constamment "Lecture interrompue"
|
||||
Et qu'il pense que son compte est piraté
|
||||
Quand il contacte le support
|
||||
Alors le support vérifie les logs de changements de device
|
||||
Et peut identifier les devices (iPhone, iPad perso vs iPhone inconnu)
|
||||
Et conseille de changer le mot de passe si device inconnu détecté
|
||||
|
||||
Scénario: Changement mot de passe déconnecte tous les devices
|
||||
Étant donné que je pense que mon compte est compromis
|
||||
Quand je change mon mot de passe
|
||||
Alors tous mes devices sont déconnectés immédiatement
|
||||
Et les sessions actives dans Redis sont supprimées
|
||||
Et je dois me reconnecter sur chaque device
|
||||
Et cela sécurise mon compte
|
||||
|
||||
# ===== TESTS TECHNIQUES =====
|
||||
|
||||
Scénario: Test charge - 100 000 vérifications/seconde
|
||||
Étant donné que 100 000 utilisateurs Premium lancent des contenus
|
||||
Quand chaque lancement vérifie Redis (GET active_streams:{user_id})
|
||||
Alors Redis peut gérer facilement 100 000 requêtes/seconde
|
||||
Et le temps de réponse moyen est <1ms
|
||||
Et aucun ralentissement n'est constaté
|
||||
|
||||
Scénario: Test failover Redis
|
||||
Étant donné que le serveur Redis principal tombe en panne
|
||||
Quand le failover automatique vers le replica Redis s'active
|
||||
Alors les sessions actives peuvent être perdues temporairement (max 5 min)
|
||||
Mais les utilisateurs peuvent relancer immédiatement
|
||||
Et l'impact est minimal (pas de perte de données critiques)
|
||||
|
||||
Scénario: Test concurrence - Lancement simultané 2 devices
|
||||
Étant donné que je lance exactement au même instant sur iPhone et iPad
|
||||
Quand les 2 requêtes arrivent en parallèle au serveur
|
||||
Alors Redis utilise un lock (SETNX) pour atomicité
|
||||
Et 1 seul device gagne (par exemple iPhone)
|
||||
Et l'autre device (iPad) reçoit immédiatement une erreur
|
||||
Et l'utilisateur peut retry sur iPad si souhaité
|
||||
|
||||
Scénario: Nettoyage automatique sessions expirées
|
||||
Étant donné que 1000 sessions Redis ont expiré (TTL atteint)
|
||||
Quand Redis supprime automatiquement ces entrées
|
||||
Alors la mémoire est libérée
|
||||
Et les nouveaux streams peuvent démarrer sans conflit
|
||||
Et aucune intervention manuelle n'est nécessaire
|
||||
Reference in New Issue
Block a user