f6a5b9afce
Ajoute/modifie tests Gherkin pour couvrir les 7 sections clarifiées : 1. Algorithme recommandation (scoring intérêts nuls) : - Ajout scénarios scoring-recommandation.feature - Cas contenu géo-ancré proche avec intérêts nuls = recommandable - Comparaison scores géo vs intérêts 2. Audio-guides mode voiture (système double clic) : - Nouveau fichier systeme-double-clic-sortie.feature - Premier clic : passage mode manuel + séquence suivante - Deuxième clic <10s : sortie audio-guide - Détection hors itinéraire + reprise 3. Monétisation créateurs (soldes dormants + DAS2) : - Nouveau fichier soldes-dormants-inactifs.feature - Conservation indéfinie si actif - Emails 12/18 mois + versement forcé 18 mois + 30j - Exception soldes <10€ avec proposition don - Modification obligations-fiscales.feature - DAS2 systématique tous montants (même <1200€) 4. Skip et abonnement (neutralisation pénalités) : - Nouveau fichier skip-abonnes-neutralisation.feature - Skip <10s non-abonné : -0.5% - Skip <10s abonné : 0% (neutre) - Métriques engagement : abonnés ne pénalisent pas - Anti-raid naturel (sources non pertinentes) 5. Premium multi-devices (KISS) : - Nouveau fichier multi-devices-dernier-priorite.feature - Règle simple : dernier device prend toujours priorité - Offline connecté vs déconnecté - Détection abus post-MVP (pas automatique) 6. Mode offline (contenus supprimés) : - Nouveau fichier contenus-supprimes-pendant-offline.feature - Suppression immédiate à reconnexion - Modal si contenu en cours d'écoute - Popup récapitulative si 2+ contenus supprimés 7. Publicités (ciblage horaire + fuseaux horaires) : - Nouveau fichier ciblage-horaire-fuseaux-horaires.feature - Ciblage horaire = heure locale utilisateur - France entière = Métropole + DOM - Détection fuseau GPS/device/IP - Cas d'usage restaurant Guadeloupe, assureur national Couverture complète de toutes les règles métier clarifiées.
243 lines
10 KiB
Gherkin
243 lines
10 KiB
Gherkin
# language: fr
|
|
Fonctionnalité: Gestion des contenus supprimés pendant offline
|
|
En tant qu'utilisateur offline
|
|
Je veux être informé des contenus supprimés à la reconnexion
|
|
Afin de comprendre pourquoi certains contenus ont disparu
|
|
|
|
Contexte:
|
|
Étant donné qu'un utilisateur a téléchargé 50 contenus offline
|
|
Et que l'utilisateur part offline pendant 7 jours
|
|
|
|
# Processus de synchronisation
|
|
|
|
Scénario: Reconnexion WiFi - Validation des contenus locaux
|
|
Étant donné que l'utilisateur se reconnecte au WiFi
|
|
Quand l'application détecte la connexion internet
|
|
Alors une requête API est envoyée: GET /offline/validate
|
|
Et l'API retourne:
|
|
"""json
|
|
{
|
|
"valid_ids": [1, 2, 3, 5, 7, 8, ...],
|
|
"deleted_ids": [4, 6, 10],
|
|
"metadata_updates": [
|
|
{"id": 9, "new_title": "Nouveau titre", "creator": "CreateurA"}
|
|
]
|
|
}
|
|
"""
|
|
|
|
Scénario: Traitement réponse validation - Suppression fichiers locaux
|
|
Étant donné que l'API retourne deleted_ids = [4, 6, 10]
|
|
Quand l'application traite la réponse
|
|
Alors les fichiers locaux des contenus 4, 6, 10 sont supprimés immédiatement
|
|
Et les métadonnées locales SQLite sont mises à jour
|
|
Et un compteur de suppressions est incrémenté
|
|
|
|
Scénario: Renouvellement validité contenus valides
|
|
Étant donné que l'API retourne valid_ids = [1, 2, 3, 5, 7, 8, ...]
|
|
Quand l'application traite la réponse
|
|
Alors la validité de ces contenus est renouvelée pour 30 jours
|
|
Et la date d'expiration est mise à jour: today + 30 jours
|
|
|
|
Scénario: Mise à jour métadonnées modifiées
|
|
Étant donné que l'API retourne metadata_updates avec un nouveau titre
|
|
Quand l'application traite la réponse
|
|
Alors la base SQLite locale est mise à jour:
|
|
| content_id | nouveau_titre | nouveau_creator |
|
|
| 9 | Nouveau titre | CreateurA |
|
|
Et les fichiers audio restent inchangés
|
|
|
|
# Gestion contenu en cours d'écoute
|
|
|
|
Scénario: Contenu supprimé en cours de lecture - Arrêt immédiat
|
|
Étant donné que l'utilisateur écoute le contenu 4 (à 1:30 sur 3:00)
|
|
Et que l'API retourne deleted_ids = [4]
|
|
Quand la synchronisation détecte que contenu 4 est supprimé
|
|
Alors la lecture s'arrête immédiatement
|
|
Et une modal s'affiche:
|
|
"""
|
|
Contenu supprimé
|
|
|
|
Ce contenu n'est plus disponible
|
|
et a été retiré par le créateur.
|
|
|
|
Passage au contenu suivant...
|
|
|
|
[OK]
|
|
"""
|
|
Et le fichier audio est supprimé localement
|
|
Et après 2 secondes, le contenu suivant démarre
|
|
|
|
Scénario: Contenu supprimé PAS en cours - Suppression silencieuse
|
|
Étant donné que l'utilisateur écoute le contenu 1
|
|
Et que l'API retourne deleted_ids = [4, 6, 10]
|
|
Quand la synchronisation traite les suppressions
|
|
Alors les fichiers 4, 6, 10 sont supprimés silencieusement
|
|
Et aucune interruption de lecture ne se produit
|
|
Et un toast récapitulatif est affiché à la fin de la lecture actuelle
|
|
|
|
# Message récapitulatif
|
|
|
|
Scénario: Plusieurs contenus supprimés - Popup récapitulative
|
|
Étant donné que 3 contenus ont été supprimés (4, 6, 10)
|
|
Quand la synchronisation est terminée
|
|
Alors une popup s'affiche:
|
|
"""
|
|
Contenus supprimés
|
|
|
|
3 contenus téléchargés ne sont plus
|
|
disponibles et ont été retirés.
|
|
|
|
Les créateurs peuvent supprimer ou
|
|
modifier leurs contenus à tout moment.
|
|
|
|
[Voir la liste] [OK]
|
|
"""
|
|
|
|
Scénario: Bouton "Voir la liste" - Affichage détails
|
|
Étant donné que la popup récapitulative est affichée
|
|
Quand l'utilisateur clique sur [Voir la liste]
|
|
Alors une nouvelle vue s'affiche avec:
|
|
| Contenu | Créateur | Raison |
|
|
| Podcast Auto Episode 4| CreateurA | Retiré créateur |
|
|
| Musique Classique | CreateurB | Modération |
|
|
| Audio-guide Paris | CreateurC | Retiré créateur |
|
|
Et l'historique est conservé 7 jours puis purgé
|
|
|
|
Scénario: Bouton "OK" - Fermeture popup
|
|
Étant donné que la popup récapitulative est affichée
|
|
Quand l'utilisateur clique sur [OK]
|
|
Alors la popup se ferme
|
|
Et l'utilisateur continue normalement
|
|
Et l'historique des suppressions reste accessible pendant 7 jours
|
|
|
|
# Toast notification
|
|
|
|
Scénario: Toast simple si 1 seul contenu supprimé
|
|
Étant donné qu'un seul contenu a été supprimé (4)
|
|
Quand la synchronisation est terminée
|
|
Alors un toast s'affiche pendant 5 secondes:
|
|
"""
|
|
1 contenu supprimé a été retiré
|
|
"""
|
|
Et aucune popup n'est affichée (toast suffit)
|
|
|
|
Scénario: Popup si 2+ contenus supprimés
|
|
Étant donné que 2 ou plus contenus ont été supprimés
|
|
Quand la synchronisation est terminée
|
|
Alors une popup complète est affichée (pas juste un toast)
|
|
Car l'utilisateur doit être informé clairement
|
|
|
|
# Motifs de suppression
|
|
|
|
Scénario: Contenu supprimé par créateur volontairement
|
|
Étant donné que le créateur a supprimé le contenu 4 volontairement
|
|
Quand l'API retourne deleted_ids = [4] avec motif "creator_deleted"
|
|
Alors le contenu est retiré immédiatement (pas de grace period MVP)
|
|
Et la raison affichée est: "Retiré par le créateur"
|
|
|
|
Scénario: Contenu supprimé par modération (violation CGU)
|
|
Étant donné que le contenu 6 a été modéré pour violation CGU
|
|
Quand l'API retourne deleted_ids = [6] avec motif "moderation"
|
|
Alors le contenu est retiré immédiatement
|
|
Et la raison affichée est: "Retiré pour modération"
|
|
|
|
Scénario: Contenu passé en Premium (créateur change statut)
|
|
Étant donné que le contenu 10 est passé en "Premium exclusif"
|
|
Et que l'utilisateur est gratuit
|
|
Quand l'API retourne deleted_ids = [10] avec motif "premium_only"
|
|
Alors le contenu est retiré immédiatement
|
|
Et la raison affichée est: "Réservé aux abonnés Premium"
|
|
|
|
# Justification KISS
|
|
|
|
Scénario: Comparaison avec grace period - Simplicité MVP
|
|
Étant donné qu'on compare la suppression immédiate vs grace period
|
|
Quand on évalue les avantages KISS
|
|
Alors les avantages suppression immédiate sont:
|
|
| avantage | description |
|
|
| Simplicité technique | Pas de gestion états intermédiaires complexes |
|
|
| Respect créateur | Volonté immédiate respectée |
|
|
| Conformité légale | Contenu illégal retiré immédiatement |
|
|
| Cas rare | Peu de créateurs suppriment contenus après publi |
|
|
|
|
# Post-MVP : Grace period (si feedback négatifs)
|
|
|
|
Scénario: Post-MVP - Grace period 7 jours pour suppression créateur volontaire
|
|
Étant donné qu'on implémente la grace period post-MVP
|
|
Et que le contenu 4 est supprimé volontairement par le créateur
|
|
Quand l'API retourne deleted_ids = [4] avec motif "creator_deleted"
|
|
Alors le contenu est marqué "Bientôt retiré" avec badge
|
|
Et l'utilisateur peut encore l'écouter pendant 7 jours
|
|
Et après 7 jours, le contenu est supprimé
|
|
|
|
Scénario: Post-MVP - Pas de grace period pour modération
|
|
Étant donné qu'on implémente la grace period post-MVP
|
|
Et que le contenu 6 est modéré (illégal, violation CGU)
|
|
Quand l'API retourne deleted_ids = [6] avec motif "moderation"
|
|
Alors le contenu est supprimé immédiatement (pas de grace period)
|
|
Car sécurité/légalité prime
|
|
|
|
Scénario: Post-MVP - Grace period si user Premium et contenu devient Premium
|
|
Étant donné qu'on implémente la grace period post-MVP
|
|
Et que le contenu 10 passe en "Premium exclusif"
|
|
Et que l'utilisateur a un abonnement Premium
|
|
Quand l'API retourne deleted_ids = [10] avec motif "premium_only"
|
|
Alors l'utilisateur Premium conserve l'accès (pas supprimé)
|
|
Mais l'utilisateur gratuit perd l'accès après 7 jours
|
|
|
|
# Cas limites
|
|
|
|
Scénario: Tous les contenus offline supprimés - Message spécifique
|
|
Étant donné que l'utilisateur avait 5 contenus offline
|
|
Et que les 5 contenus ont été supprimés pendant offline
|
|
Quand la synchronisation retourne deleted_ids = [1, 2, 3, 4, 5]
|
|
Alors une popup spécifique s'affiche:
|
|
"""
|
|
Tous vos contenus offline ont été supprimés
|
|
|
|
Les 5 contenus téléchargés ne sont plus disponibles.
|
|
|
|
Téléchargez de nouveaux contenus pour écouter offline.
|
|
|
|
[Parcourir contenus] [OK]
|
|
"""
|
|
|
|
Scénario: Contenu supprimé puis utilisateur re-télécharge
|
|
Étant donné que le contenu 4 a été supprimé pendant offline
|
|
Et que l'utilisateur a vu la notification
|
|
Quand l'utilisateur se reconnecte et browse les contenus
|
|
Alors le contenu 4 n'apparaît plus dans la liste
|
|
Et l'utilisateur ne peut pas le re-télécharger (supprimé définitivement)
|
|
|
|
Scénario: Historique suppressions conservé 7 jours
|
|
Étant donné que 3 contenus ont été supprimés le 1er février
|
|
Quand l'utilisateur consulte l'historique des suppressions le 7 février
|
|
Alors l'historique est toujours visible
|
|
Quand l'utilisateur consulte l'historique le 9 février (7+ jours)
|
|
Alors l'historique a été purgé automatiquement
|
|
|
|
# Statistiques côté API
|
|
|
|
Scénario: API - Comptabilisation contenus supprimés pendant offline
|
|
Étant donné que 1000 utilisateurs étaient offline pendant 7 jours
|
|
Et que 150 contenus ont été supprimés pendant cette période
|
|
Quand l'API génère les métriques de synchronisation
|
|
Alors les statistiques affichent:
|
|
| métrique | valeur |
|
|
| Utilisateurs reconnectés | 1000 |
|
|
| Contenus supprimés détectés | 4500 |
|
|
| Moyenne contenus supprimés/user | 4.5 |
|
|
| Users affectés (≥1 suppression) | 850 |
|
|
|
|
# Performance
|
|
|
|
Scénario: Requête GET /offline/validate - Performance optimisée
|
|
Étant donné qu'un utilisateur a 50 contenus offline
|
|
Quand l'API reçoit GET /offline/validate avec la liste des 50 IDs
|
|
Alors la requête SQL vérifie l'existence des contenus en batch:
|
|
"""sql
|
|
SELECT id FROM contents WHERE id IN (1,2,3,...,50) AND deleted_at IS NULL
|
|
"""
|
|
Et la réponse est générée en <200ms
|
|
Et Redis cache les résultats pour éviter requêtes répétées
|