37c62206ad
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>
180 lines
8.2 KiB
Gherkin
180 lines
8.2 KiB
Gherkin
# language: fr
|
|
|
|
@error-handling @network-loss
|
|
Fonctionnalité: Gestion de la perte de réseau et buffering adaptatif
|
|
|
|
Contexte:
|
|
Étant donné que je suis un utilisateur connecté
|
|
Et que je suis en mode écoute
|
|
Et qu'un contenu est en cours de lecture
|
|
|
|
# 12.3 - Buffer adaptatif selon type de réseau (cf. TECHNICAL.md et ADR-002)
|
|
|
|
Plan du Scénario: Paramètres de buffer selon le type de réseau
|
|
Étant donné que je suis connecté en "<type_reseau>"
|
|
Quand le système initialise le buffer audio
|
|
Alors le buffer minimum est de <buffer_min> secondes
|
|
Et le buffer cible est de <buffer_cible> secondes
|
|
Et le buffer maximum est de <buffer_max> secondes
|
|
|
|
Exemples:
|
|
| type_reseau | buffer_min | buffer_cible | buffer_max |
|
|
| WiFi | 5 | 30 | 120 |
|
|
| 4G | 10 | 45 | 120 |
|
|
| 5G | 10 | 45 | 120 |
|
|
| 3G | 30 | 90 | 300 |
|
|
|
|
# Phase 1: Connexion instable
|
|
|
|
Scénario: Connexion instable avec latence élevée - aucun message immédiat
|
|
Étant donné que je suis connecté en 4G
|
|
Et que le buffer contient 45 secondes de contenu
|
|
Quand la latence réseau dépasse 500ms
|
|
Alors aucun message n'est affiché immédiatement
|
|
Et la lecture continue normalement sur le buffer
|
|
Et le système tente de continuer le téléchargement en arrière-plan
|
|
|
|
Scénario: Connexion instable pendant plus de 10 secondes - toast discret
|
|
Étant donné que je suis connecté en 4G
|
|
Et que la latence réseau dépasse 500ms depuis 10 secondes
|
|
Quand le système détecte la latence prolongée
|
|
Alors un toast discret s'affiche: "Connexion instable"
|
|
Et le toast disparaît automatiquement après 3 secondes
|
|
Et la lecture continue normalement
|
|
|
|
# Phase 2: Perte totale réseau
|
|
|
|
Scénario: Perte totale de réseau - lecture sur buffer
|
|
Étant donné que je suis connecté en WiFi
|
|
Et que le buffer contient 30 secondes de contenu
|
|
Quand je perds totalement la connexion réseau
|
|
Alors la lecture continue sur le buffer disponible
|
|
Et un toast s'affiche: "Hors ligne, lecture sur buffer (30s restantes)"
|
|
Et un compte à rebours du temps de buffer restant est visible
|
|
|
|
Scénario: Buffer qui s'épuise pendant la perte réseau
|
|
Étant donné que je suis hors ligne
|
|
Et que le buffer contient 30 secondes de contenu
|
|
Quand le contenu continue de jouer
|
|
Alors le compte à rebours diminue en temps réel
|
|
Et le toast affiche "Hors ligne, lecture sur buffer (15s restantes)" après 15 secondes
|
|
Et le toast affiche "Hors ligne, lecture sur buffer (5s restantes)" après 25 secondes
|
|
|
|
# Phase 3: Buffer épuisé sans reconnexion
|
|
|
|
Scénario: Pause automatique après épuisement du buffer
|
|
Étant donné que je suis hors ligne depuis 30 secondes
|
|
Et que le buffer est complètement épuisé
|
|
Quand il n'y a plus de contenu audio à lire
|
|
Alors la lecture se met en pause automatiquement
|
|
Et un overlay s'affiche: "Connexion perdue. Reconnexion en cours..."
|
|
Et le système tente de se reconnecter automatiquement
|
|
|
|
Scénario: Tentatives de reconnexion automatique
|
|
Étant donné que la lecture est en pause suite à l'épuisement du buffer
|
|
Quand le système tente de se reconnecter
|
|
Alors une tentative de reconnexion est effectuée toutes les 5 secondes
|
|
Et un maximum de 6 tentatives sont effectuées (30 secondes au total)
|
|
Et l'overlay affiche "Tentative de reconnexion... (X/6)"
|
|
|
|
# Phase 4: Basculement mode offline après échec reconnexion
|
|
|
|
Scénario: Proposition du mode offline après 30 secondes d'échec
|
|
Étant donné que 6 tentatives de reconnexion ont échoué
|
|
Et que cela fait 30 secondes que je suis déconnecté
|
|
Quand la 6ème tentative échoue
|
|
Alors une popup s'affiche: "Voulez-vous continuer avec vos contenus téléchargés ?"
|
|
Et la popup contient deux boutons:
|
|
| bouton | action |
|
|
| Réessayer | Nouvelle série de 6 tentatives |
|
|
| Mode offline | Bascule sur contenus téléchargés |
|
|
|
|
Scénario: Basculement réussi vers le mode offline
|
|
Étant donné que la popup de mode offline est affichée
|
|
Et que j'ai téléchargé 20 contenus dans ma zone géographique
|
|
Quand je clique sur "Mode offline"
|
|
Alors le système bascule sur les contenus téléchargés
|
|
Et un nouveau contenu téléchargé démarre automatiquement
|
|
Et un bandeau permanent indique "Mode hors ligne - Contenus téléchargés"
|
|
|
|
Scénario: Aucun contenu téléchargé disponible
|
|
Étant donné que la popup de mode offline est affichée
|
|
Et que je n'ai aucun contenu téléchargé
|
|
Quand je clique sur "Mode offline"
|
|
Alors un message s'affiche: "Aucun contenu téléchargé disponible"
|
|
Et je suis invité à me connecter en WiFi pour télécharger du contenu
|
|
Et le bouton "Réessayer" reste la seule option
|
|
|
|
# Reconnexion réussie
|
|
|
|
Scénario: Reprise automatique après reconnexion
|
|
Étant donné que la lecture est en pause depuis 15 secondes
|
|
Et que j'étais à 02:35 du contenu en cours
|
|
Quand la connexion réseau est rétablie
|
|
Alors la lecture reprend automatiquement au point d'arrêt exact (02:35)
|
|
Et un toast s'affiche: "Connexion rétablie"
|
|
Et le toast disparaît après 3 secondes
|
|
Et le buffer se remplit progressivement selon le type de réseau
|
|
|
|
Scénario: Reconnexion avec changement de type de réseau
|
|
Étant donné que j'étais connecté en WiFi
|
|
Et que j'ai perdu la connexion
|
|
Quand je me reconnecte en 4G
|
|
Alors le système ajuste automatiquement les paramètres de buffer
|
|
Et le buffer minimum passe de 5s à 10s
|
|
Et le buffer cible passe de 30s à 45s
|
|
Et la lecture reprend normalement
|
|
|
|
# Cas spécifique: tunnel routier
|
|
|
|
Scénario: Passage dans un tunnel avec perte de signal
|
|
Étant donné que je conduis à 90 km/h sur autoroute
|
|
Et que je suis connecté en 4G avec un buffer de 45 secondes
|
|
Quand j'entre dans un tunnel et perds le signal
|
|
Alors la lecture continue sur le buffer pendant 45 secondes maximum
|
|
Et aucune notification n'est affichée pendant les 10 premières secondes
|
|
Et un toast discret s'affiche après 10 secondes: "Connexion instable"
|
|
|
|
Scénario: Sortie du tunnel avant épuisement du buffer
|
|
Étant donné que je suis dans un tunnel depuis 30 secondes
|
|
Et qu'il reste 15 secondes de buffer
|
|
Quand je sors du tunnel et récupère le signal 4G
|
|
Alors la lecture continue sans interruption
|
|
Et le buffer se remplit à nouveau
|
|
Et un toast s'affiche: "Connexion rétablie"
|
|
|
|
# Handoff réseau (changement de cellule mobile)
|
|
|
|
Scénario: Changement de cellule 4G pendant la lecture
|
|
Étant donné que je conduis et change de cellule mobile toutes les 5-10 minutes
|
|
Et que le buffer contient 45 secondes de contenu
|
|
Quand un handoff de cellule se produit
|
|
Alors la lecture continue sans interruption grâce au buffer
|
|
Et la connexion à la nouvelle cellule se fait de manière transparente
|
|
Et aucune notification n'est affichée si le handoff réussit en moins de 5 secondes
|
|
|
|
# Mode offline préventif avant perte réseau
|
|
|
|
Scénario: Téléchargement préventif en WiFi avant trajet
|
|
Étant donné que je suis connecté en WiFi
|
|
Et que j'ai activé le téléchargement automatique
|
|
Quand le système détecte que je suis à l'arrêt en WiFi
|
|
Alors le système me propose de télécharger du contenu pour mon trajet
|
|
Et je peux sélectionner une zone géographique à télécharger
|
|
Et le téléchargement se fait en arrière-plan
|
|
|
|
# Métriques et monitoring
|
|
|
|
Scénario: Tracking des événements de perte réseau pour amélioration
|
|
Étant donné que je perds la connexion réseau
|
|
Quand l'événement de perte est détecté
|
|
Alors le système enregistre les métriques suivantes:
|
|
| métrique |
|
|
| Type de réseau avant perte |
|
|
| Durée de la coupure |
|
|
| Buffer disponible |
|
|
| Position GPS approximative |
|
|
| Heure de la journée |
|
|
Et ces métriques sont anonymisées et envoyées en batch lors de la prochaine connexion WiFi
|
|
Et les données servent à améliorer les paramètres de buffer
|