doc(regles-metier): ajouter gestion contenus supprimés pendant offline
Crée nouvelle section 11.4 détaillant le comportement quand des contenus sont supprimés par créateurs/modération pendant que l'utilisateur est offline. Décision : Suppression immédiate à la reconnexion (KISS) Processus de synchronisation : - GET /offline/validate retourne valid_ids, deleted_ids, metadata_updates - Suppression immédiate fichiers locaux pour deleted_ids - Renouvellement validité 30j pour valid_ids - Toast notification "X contenus supprimés ont été retirés" Gestion contenu en cours d'écoute : - Message modal explicite "Contenu supprimé... Passage au suivant" - Arrêt lecture + suppression fichier + passage auto après 2s Message récapitulatif : - Popup avec compte total + bouton "Voir la liste" - Historique contenus supprimés conservé 7 jours Justification KISS : - Simplicité technique (pas de grace period) - Respect créateur (volonté immédiate) - Conformité légale (contenu illégal retiré immédiatement) - Cas rare (peu de suppressions après publication) Post-MVP : grace period possible si feedback négatifs, mais attendre feedback réel avant complexité additionnelle. Référence: CLARIFICATIONS-REGLES-METIER.md section 6
This commit is contained in:
@@ -112,22 +112,97 @@ App détecte WiFi + contenus >25 jours
|
||||
- Actions conservées jusqu'à sync réussie (pas de perte)
|
||||
- **Rétention max 7 jours** : après = purge (évite queue infinie)
|
||||
|
||||
**Conflits contenus supprimés** :
|
||||
|
||||
```
|
||||
Backend retourne : {deleted_content_ids: [123, 456]}
|
||||
→ App supprime fichiers locaux
|
||||
→ Si contenu 123 en cours d'écoute :
|
||||
- Attendre fin lecture actuelle
|
||||
- Passage auto suivant après 2s
|
||||
→ Toast : "1 contenu téléchargé a été retiré (violation règles)"
|
||||
```
|
||||
|
||||
**Justification** :
|
||||
- **Pas de conflit possible** : actions unilatérales user (likes/abonnements)
|
||||
- **UX fluide** : pas de blocage offline
|
||||
- **Batch = économie** : requêtes HTTP groupées
|
||||
- **Conformité modération** : contenu illégal disparaît même offline
|
||||
|
||||
---
|
||||
|
||||
### 11.4 Contenus supprimés pendant offline
|
||||
|
||||
**Problème** : Que se passe-t-il si un utilisateur télécharge des contenus, part offline plusieurs jours, et pendant ce temps certains contenus sont supprimés par les créateurs ou la modération ?
|
||||
|
||||
**Décision** : Suppression immédiate à la reconnexion (Option A - KISS)
|
||||
|
||||
#### Processus de synchronisation
|
||||
|
||||
```
|
||||
User se reconnecte (WiFi détecté)
|
||||
↓
|
||||
1. API sync : GET /offline/validate
|
||||
Backend retourne :
|
||||
{
|
||||
"valid_ids": [id1, id2, id3, ...],
|
||||
"deleted_ids": [id10, id12, id15],
|
||||
"metadata_updates": [{id: id5, new_title: "..."}]
|
||||
}
|
||||
|
||||
2. App mobile compare avec contenus locaux :
|
||||
- valid_ids : renouvelle validité 30j
|
||||
- deleted_ids : suppression immédiate fichiers locaux
|
||||
- metadata_updates : mise à jour titre/créateur/tags
|
||||
|
||||
3. Notification user :
|
||||
Toast : "3 contenus supprimés ont été retirés"
|
||||
```
|
||||
|
||||
#### Gestion contenu en cours d'écoute
|
||||
|
||||
**Si contenu supprimé en cours de lecture** :
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────┐
|
||||
│ Contenu supprimé │
|
||||
├────────────────────────────────────────┤
|
||||
│ Ce contenu n'est plus disponible │
|
||||
│ et a été retiré par le créateur. │
|
||||
│ │
|
||||
│ Passage au contenu suivant... │
|
||||
│ │
|
||||
│ [OK] │
|
||||
└────────────────────────────────────────┘
|
||||
|
||||
→ Lecture s'arrête
|
||||
→ Fichier supprimé localement
|
||||
→ Passage automatique au contenu suivant (après 2s)
|
||||
```
|
||||
|
||||
#### Message récapitulatif
|
||||
|
||||
**Si plusieurs contenus supprimés** :
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────┐
|
||||
│ 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] │
|
||||
└────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Bouton "Voir la liste"** :
|
||||
- Affiche titres + créateurs des contenus supprimés
|
||||
- Permet comprendre ce qui a disparu
|
||||
- Historique conservé 7 jours (puis purge)
|
||||
|
||||
**Justification KISS** :
|
||||
- ✅ **Simplicité technique** : pas de grace period complexe, pas de gestion d'états intermédiaires
|
||||
- ✅ **Respect créateur** : si créateur supprime = volonté claire immédiate, pas de diffusion prolongée
|
||||
- ✅ **Conformité légale** : contenu modéré (illégal, violation CGU) retiré immédiatement, pas de risque juridique
|
||||
- ✅ **Cas rare** : peu de créateurs suppriment contenus après publication, impact user limité
|
||||
|
||||
**Post-MVP** : Si feedback négatifs users ("J'étais en train d'écouter et ça s'est coupé brutalement !"), ajouter grace period UNIQUEMENT pour suppression créateur volontaire :
|
||||
- Motif suppression = "modération RoadWave" → Suppression immédiate (sécurité/légalité)
|
||||
- Motif suppression = "créateur volontaire" → Grace period 7 jours + badge "Bientôt retiré"
|
||||
- Motif suppression = "passage Premium" → Si user Premium : conserve accès, si gratuit : grace period 7j
|
||||
|
||||
**Mais attendre feedback réel avant d'ajouter cette complexité.**
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user