# 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