Résolution des incohérences #10, #11, et #12 de l'analyse d'architecture. ## Phase 1 : Réorganisation Features BDD (Point #10 - RÉSOLU) - Créer structure features/{api,ui,e2e} - Déplacer 83 features en 3 catégories via git mv (historique préservé) - features/api/ : 53 features (tests API backend) - features/ui/ : 22 features (tests UI mobile) - features/e2e/ : 8 features (tests end-to-end) Domaines déplacés : - API : authentication, recommendation, rgpd-compliance, content-creation, moderation, monetisation, premium, radio-live, publicites - UI : audio-guides, navigation, interest-gauges, mode-offline, partage, profil, recherche - E2E : abonnements, error-handling ## Phase 2 : Mise à jour Documentation ### ADR-007 - Tests BDD - Ajouter section "Convention de Catégorisation des Features" - Documenter règles api/ui/e2e avec exemples concrets - Spécifier step definitions (backend Go, mobile Dart) ### ADR-024 - Stratégie CI/CD Monorepo (NOUVEAU) - Créer ADR dédié pour stratégie CI/CD avec path filters - Architecture workflows séparés (backend.yml, mobile.yml, shared.yml) - Configuration path filters détaillée avec exemples YAML - Matrice de déclenchement et optimisations (~70% gain temps CI) - Plan d'implémentation (~2h, reporté jusqu'au développement) ### ADR-016 - Organisation Monorepo - Simplifier en retirant section CI/CD détaillée - Ajouter référence vers ADR-024 pour stratégie CI/CD ### INCONSISTENCIES-ANALYSIS.md - Point #10 (Tests BDD synchronisés) : ✅ RÉSOLU - Catégorisation features implémentée - ADR-007 mis à jour avec convention complète - Point #11 (70/30 Split paiements) : ✅ ANNULÉ (faux problème) - ADR-009 et Règle 18 parfaitement cohérents - Documentation exhaustive existante (formule, SQL, comparaisons) - Point #12 (Monorepo path filters) : ⏸️ DOCUMENTÉ - Architecture CI/CD complète dans ADR-024 - Implémentation reportée (projet en phase documentation) - Métriques mises à jour : - MODERATE : 6/9 traités (4 résolus + 1 annulé + 1 documenté) - ADR à jour : 100% (19/19 avec ADR-024) ## Phase 3 : Validation - Structure features validée (api/ui/e2e, aucun répertoire restant) - Historique Git préservé (git mv, renommages détectés) - 83 features total (API: 53, UI: 22, E2E: 8) Closes: Point #10 (résolu), Point #11 (annulé), Point #12 (documenté) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
336 lines
14 KiB
Gherkin
336 lines
14 KiB
Gherkin
# language: fr
|
||
Fonctionnalité: Validité et renouvellement contenus offline
|
||
En tant qu'utilisateur
|
||
Je veux que mes contenus téléchargés restent valides un certain temps
|
||
Afin de garantir la légalité et la fraîcheur du contenu
|
||
|
||
Contexte:
|
||
Étant donné que je suis connecté à l'application RoadWave
|
||
Et que j'ai des contenus téléchargés
|
||
|
||
# ===== DURÉE DE VALIDITÉ =====
|
||
|
||
Scénario: Validité de 30 jours après téléchargement
|
||
Étant donné que je télécharge un contenu le 1er juin 2025
|
||
Quand le téléchargement est terminé
|
||
Alors le contenu est valide jusqu'au 1er juillet 2025 (30 jours)
|
||
Et la date d'expiration est stockée en local
|
||
|
||
Scénario: Affichage date expiration sur contenu téléchargé
|
||
Étant donné que j'ai téléchargé un contenu il y a 20 jours
|
||
Quand je consulte les détails du contenu
|
||
Alors je vois "Expire dans 10 jours"
|
||
Et je sais combien de temps il reste avant expiration
|
||
|
||
Scénario: Standard industrie aligné (Spotify, YouTube, Deezer)
|
||
Étant donné que Spotify, YouTube Music et Deezer utilisent 30 jours
|
||
Quand RoadWave fixe également 30 jours
|
||
Alors c'est le standard accepté par les utilisateurs
|
||
Et il n'y a pas de confusion avec les autres plateformes
|
||
|
||
Scénario: Justification 30 jours - Force reconnexion régulière
|
||
Étant donné qu'un utilisateur ne se connecte jamais
|
||
Quand ses contenus expirent après 30 jours
|
||
Alors il est obligé de se reconnecter pour les renouveler
|
||
Et le système peut vérifier:
|
||
| vérification |
|
||
| Abonnement Premium toujours actif|
|
||
| Contenus non modérés/supprimés |
|
||
| Métadonnées à jour |
|
||
|
||
Scénario: Justification 30 jours - Évite stockage obsolète
|
||
Étant donné qu'un contenu a été modéré après téléchargement
|
||
Quand le contenu expire après 30 jours maximum
|
||
Alors le contenu illégal est automatiquement supprimé
|
||
Et ne reste pas indéfiniment sur le device
|
||
|
||
# ===== RENOUVELLEMENT AUTOMATIQUE =====
|
||
|
||
Scénario: Détection WiFi et contenus >25 jours
|
||
Étant donné que j'ai des contenus téléchargés il y a 26 jours
|
||
Quand l'app détecte une connexion WiFi
|
||
Alors une requête GET /offline/contents/refresh est envoyée
|
||
Et le backend vérifie chaque contenu
|
||
|
||
Scénario: Vérification abonnement Premium toujours actif
|
||
Étant donné qu'un contenu téléchargé en Premium est à renouveler
|
||
Quand le backend vérifie le statut
|
||
Et que l'abonnement Premium est toujours actif
|
||
Alors la validité est renouvelée à 30 jours supplémentaires
|
||
|
||
Scénario: Abonnement Premium expiré - Contenu non renouvelé
|
||
Étant donné qu'un contenu Premium téléchargé est à renouveler
|
||
Quand le backend vérifie le statut
|
||
Et que l'abonnement Premium a expiré
|
||
Alors le contenu n'est pas renouvelé
|
||
Et il sera supprimé à l'expiration (J-0)
|
||
Et l'utilisateur voit "Contenu Premium expiré (abonnement inactif)"
|
||
|
||
Scénario: Vérification contenu pas modéré/supprimé
|
||
Étant donné qu'un contenu téléchargé est à renouveler
|
||
Quand le backend vérifie le statut
|
||
Et que le contenu a été modéré ou supprimé entre temps
|
||
Alors le contenu n'est pas renouvelé
|
||
Et sera supprimé immédiatement du device
|
||
Et l'utilisateur voit "1 contenu retiré (violation règles)"
|
||
|
||
Scénario: Mise à jour métadonnées lors du renouvellement
|
||
Étant donné qu'un contenu téléchargé est renouvelé
|
||
Quand le backend traite le renouvellement
|
||
Alors les métadonnées sont mises à jour:
|
||
| métadonnée | mise à jour si changée |
|
||
| Titre | ✅ |
|
||
| Nom créateur | ✅ |
|
||
| Description | ✅ |
|
||
| Tags | ✅ |
|
||
| Statut Premium | ✅ |
|
||
Et l'utilisateur voit les infos à jour
|
||
|
||
Scénario: Pas de re-téléchargement audio si fichier OK
|
||
Étant donné qu'un contenu est renouvelé
|
||
Quand le fichier audio local est intact
|
||
Alors seules les métadonnées sont mises à jour
|
||
Et le fichier audio n'est pas re-téléchargé
|
||
Et cela économise la bande passante
|
||
|
||
Scénario: Re-téléchargement audio si fichier corrompu
|
||
Étant donné qu'un contenu est renouvelé
|
||
Quand le fichier audio local est corrompu (checksum invalide)
|
||
Alors le fichier audio est re-téléchargé entièrement
|
||
Et le nouveau fichier remplace le corrompu
|
||
|
||
Scénario: Renouvellement silencieux si WiFi régulier
|
||
Étant donné que je me connecte en WiFi tous les jours
|
||
Quand mes contenus atteignent 25-30 jours
|
||
Alors ils sont automatiquement renouvelés en arrière-plan
|
||
Et je ne vois aucune notification (processus transparent)
|
||
Et mes contenus restent valides indéfiniment
|
||
|
||
Scénario: Renouvellement batch de plusieurs contenus
|
||
Étant donné que j'ai 30 contenus à renouveler
|
||
Quand le renouvellement automatique se déclenche
|
||
Alors une requête batch est envoyée:
|
||
```json
|
||
POST /offline/contents/refresh
|
||
{
|
||
"content_ids": ["abc123", "def456", "ghi789", ...]
|
||
}
|
||
```
|
||
Et le backend traite les 30 contenus en une seule requête
|
||
Et cela économise les requêtes HTTP
|
||
|
||
Scénario: Temps de traitement renouvellement
|
||
Étant donné que 30 contenus sont à renouveler
|
||
Quand la requête batch est traitée
|
||
Alors le backend répond en <2 secondes
|
||
Et les métadonnées sont mises à jour localement
|
||
Et l'utilisateur ne remarque aucun ralentissement
|
||
|
||
# ===== NOTIFICATIONS EXPIRATION =====
|
||
|
||
Scénario: Notification J-3 avant expiration
|
||
Étant donné que j'ai 15 contenus qui expirent dans 3 jours
|
||
Quand le système vérifie les expirations
|
||
Alors je reçois une notification:
|
||
"""
|
||
⚠️ 15 contenus expirent dans 3 jours
|
||
|
||
Connectez-vous en WiFi pour les renouveler automatiquement.
|
||
"""
|
||
Et je peux agir avant l'expiration
|
||
|
||
Scénario: Pas de notification si connexion WiFi régulière
|
||
Étant donné que je me connecte en WiFi tous les jours
|
||
Et que mes contenus sont automatiquement renouvelés
|
||
Quand le système vérifie les expirations
|
||
Alors aucune notification J-3 n'est envoyée
|
||
Car les contenus sont déjà renouvelés silencieusement
|
||
|
||
Scénario: Notification uniquement si contenus non renouvelés
|
||
Étant donné que j'ai 20 contenus dont 15 renouvelés et 5 non renouvelés
|
||
Quand le J-3 arrive pour les 5 non renouvelés
|
||
Alors je reçois "5 contenus expirent dans 3 jours"
|
||
Et seuls les contenus à risque sont mentionnés
|
||
|
||
Scénario: Action utilisateur après notification J-3
|
||
Étant donné que je reçois la notification J-3
|
||
Quand je clique sur la notification
|
||
Alors l'app s'ouvre sur la page Téléchargements
|
||
Et je vois les contenus qui vont expirer en rouge
|
||
Et je peux me connecter en WiFi pour les renouveler
|
||
|
||
Scénario: Suppression automatique J-0 (expiration)
|
||
Étant donné qu'un contenu n'a pas été renouvelé
|
||
Quand le jour d'expiration arrive (J-0)
|
||
Alors le fichier est automatiquement supprimé du device
|
||
Et l'espace disque est libéré
|
||
Et le compteur est décrémenté (ex: 45/50 → 44/50)
|
||
|
||
Scénario: Toast après suppression automatique J-0
|
||
Étant donné que 15 contenus viennent d'expirer
|
||
Quand l'utilisateur ouvre l'app
|
||
Alors il voit un toast:
|
||
"""
|
||
🗑️ 15 contenus expirés ont été supprimés
|
||
|
||
Reconnectez-vous en WiFi régulièrement pour éviter les expirations.
|
||
"""
|
||
|
||
Scénario: Liste contenus supprimés après expiration
|
||
Étant donné que 15 contenus ont expiré
|
||
Quand je consulte l'historique des suppressions
|
||
Alors je vois la liste des 15 contenus supprimés:
|
||
| titre | créateur | date expiration |
|
||
| Mon épisode préféré | JeanDupont | 15 juin 2025 |
|
||
| Road trip Bretagne | MarieLambert| 15 juin 2025 |
|
||
| ... | ... | ... |
|
||
Et je peux les re-télécharger si je veux
|
||
|
||
Scénario: Re-téléchargement après expiration
|
||
Étant donné qu'un contenu a expiré et été supprimé
|
||
Quand je retrouve ce contenu dans l'app
|
||
Alors le badge ✅ "Offline" n'est plus affiché
|
||
Et je peux le re-télécharger normalement
|
||
Et la validité repart à 30 jours
|
||
|
||
# ===== CAS PARTICULIERS =====
|
||
|
||
Scénario: Utilisateur ne se connecte jamais pendant 30 jours
|
||
Étant donné que je télécharge 50 contenus le 1er juin
|
||
Mais que je ne me connecte jamais en WiFi pendant 30 jours
|
||
Quand le 1er juillet arrive
|
||
Alors tous les 50 contenus expirent
|
||
Et sont automatiquement supprimés
|
||
Et je n'ai plus aucun contenu offline
|
||
|
||
Scénario: Utilisateur en zone blanche 30+ jours
|
||
Étant donné que je télécharge 50 contenus avant de partir en zone sans réseau
|
||
Et que je reste 45 jours sans connexion
|
||
Quand les contenus expirent après 30 jours
|
||
Alors ils sont supprimés même si je ne peux pas me connecter
|
||
Et je perds l'accès à mes contenus offline
|
||
|
||
Scénario: Recommandation téléchargement avant zone blanche longue
|
||
Étant donné que je prépare un road trip de 60 jours
|
||
Quand je consulte la FAQ
|
||
Alors je vois la recommandation:
|
||
"""
|
||
⚠️ Road trips >30 jours
|
||
|
||
Les contenus téléchargés expirent après 30 jours.
|
||
Pour les longs voyages sans connexion:
|
||
• Téléchargez de nouveaux contenus tous les 25 jours si possible
|
||
• Ou planifiez une reconnexion WiFi tous les 25 jours
|
||
"""
|
||
|
||
Scénario: Changement statut Premium en gratuit pendant validité
|
||
Étant donné que je suis Premium et j'ai téléchargé 200 contenus
|
||
Quand mon abonnement Premium expire
|
||
Et que je repasse en gratuit
|
||
Alors au prochain renouvellement, seulement 50 contenus sont conservés
|
||
Et les 150 autres sont supprimés (limite gratuit)
|
||
Et je vois "Limite gratuit (50 contenus) appliquée. 150 contenus supprimés."
|
||
|
||
Scénario: Sélection automatique 50 meilleurs contenus si passage gratuit
|
||
Étant donné que je repasse en gratuit avec 200 contenus téléchargés
|
||
Quand le système applique la limite de 50
|
||
Alors les 50 contenus les plus récemment écoutés sont conservés
|
||
Et les 150 autres sont supprimés
|
||
Et cela maximise les chances de garder les contenus que j'aime
|
||
|
||
Scénario: Contenus Premium exclusifs supprimés si abonnement expire
|
||
Étant donné que j'ai téléchargé 20 contenus Premium exclusifs
|
||
Quand mon abonnement Premium expire
|
||
Alors les 20 contenus Premium sont immédiatement supprimés
|
||
Car ils ne sont accessibles qu'aux abonnés Premium actifs
|
||
Et je vois "20 contenus Premium supprimés (abonnement expiré)"
|
||
|
||
# ===== STATISTIQUES ET MONITORING =====
|
||
|
||
Scénario: Affichage temps restant avant expiration
|
||
Étant donné que j'ai 45 contenus téléchargés
|
||
Quand je consulte la page Téléchargements
|
||
Alors je vois pour chaque contenu:
|
||
| contenu | temps restant |
|
||
| Mon épisode (récent)| Expire dans 28 jours |
|
||
| Road trip (ancien) | Expire dans 3 jours |
|
||
Et je sais lesquels sont prioritaires pour renouvellement
|
||
|
||
Scénario: Tri par date expiration
|
||
Étant donné que j'ai 45 contenus avec différentes dates d'expiration
|
||
Quand je trie par "Expiration"
|
||
Alors les contenus qui expirent le plus tôt apparaissent en premier
|
||
Et je peux voir rapidement lesquels nécessitent une reconnexion urgente
|
||
|
||
Scénario: Badge rouge si expiration <3 jours
|
||
Étant donné qu'un contenu expire dans 2 jours
|
||
Quand je consulte la liste des téléchargements
|
||
Alors le contenu a un badge rouge "⚠️ Expire bientôt"
|
||
Et il est visuellement mis en avant
|
||
|
||
Scénario: Statistiques utilisateur - Taux de renouvellement
|
||
Étant donné que j'accède à mes statistiques
|
||
Quand je consulte la section Téléchargements
|
||
Alors je vois:
|
||
| métrique | valeur |
|
||
| Contenus actuels | 45 |
|
||
| Contenus expirés depuis début | 87 |
|
||
| Contenus renouvelés (auto) | 234 |
|
||
| Taux renouvellement automatique | 73% |
|
||
|
||
Scénario: Statistiques admin - Taux expiration global
|
||
Étant donné qu'un admin consulte les métriques offline
|
||
Quand il accède au dashboard
|
||
Alors il voit:
|
||
| métrique | valeur |
|
||
| Contenus téléchargés actifs | 1,234,567 |
|
||
| Expirations ce mois | 45,678 |
|
||
| Taux expiration | 3.7% |
|
||
| Renouvellements automatiques/mois | 234,567 |
|
||
|
||
Scénario: Alerte admin si taux expiration >10%
|
||
Étant donné que le taux d'expiration mensuel dépasse 10%
|
||
Quand le système détecte cette anomalie
|
||
Alors une alerte est envoyée:
|
||
"""
|
||
⚠️ Taux d'expiration anormal: 12.3%
|
||
|
||
Nombre expirations ce mois: 152,345
|
||
Causes possibles:
|
||
- Utilisateurs ne se connectent plus en WiFi
|
||
- Problème renouvellement automatique ?
|
||
- Churn utilisateurs augmenté ?
|
||
|
||
Action recommandée: Enquête technique + email rappel utilisateurs
|
||
"""
|
||
|
||
Scénario: Email rappel si pas de connexion WiFi depuis 20 jours
|
||
Étant donné que je n'ai pas connecté l'app en WiFi depuis 20 jours
|
||
Et que j'ai 45 contenus téléchargés
|
||
Quand le système détecte cette inactivité WiFi
|
||
Alors je reçois un email:
|
||
"""
|
||
📡 Connectez-vous en WiFi pour conserver vos téléchargements
|
||
|
||
Vous n'avez pas connecté RoadWave en WiFi depuis 20 jours.
|
||
Vos 45 contenus téléchargés expireront dans 10 jours si non renouvelés.
|
||
|
||
Connectez-vous en WiFi avant le 30 juin pour les renouveler automatiquement.
|
||
"""
|
||
|
||
Scénario: Performance renouvellement avec 10 000 utilisateurs simultanés
|
||
Étant donné que 10 000 utilisateurs se connectent en WiFi simultanément
|
||
Quand chacun demande le renouvellement de 50 contenus
|
||
Alors le serveur traite 500 000 vérifications
|
||
Et grâce au cache Redis et index PostgreSQL, le temps de réponse reste <3s
|
||
Et les serveurs gèrent la charge sans problème
|
||
|
||
Scénario: Logs audit renouvellements
|
||
Étant donné qu'un contenu est renouvelé
|
||
Quand l'opération se termine
|
||
Alors un log est enregistré:
|
||
| timestamp | user_id | content_id | action | résultat |
|
||
| 2025-06-15 14:30:00 | abc123 | xyz789 | renew | success (+30d) |
|
||
| 2025-06-15 14:30:01 | abc123 | def456 | renew | failed (deleted)|
|
||
Et ces logs aident à débugger les problèmes
|