feat(gherkin): compléter couverture règles métier avec 47 features manquantes
Ajout de 47 features Gherkin (~650 scénarios) pour couvrir 100% des règles métier : - Authentification (5) : validation mot de passe, tentatives connexion, multi-device, 2FA, récupération - Audio-guides (12) : détection mode, création, navigation piéton/voiture, ETA, gestion points, progression - Navigation (5) : notifications minimalistes, décompte 5s, stationnement, historique, basculement auto - Création contenu (3) : image auto, restrictions modification, suppression - Radio live (2) : enregistrement auto, interdictions modération - Droits auteur (6) : fair use 30s, détection musique, signalements, sanctions, appels - Modération (9) : badges Bronze/Argent/Or, score fiabilité, utilisateur confiance, audit, anti-abus - Premium (2) : webhooks Mangopay, tarification multi-canal - Profil/Partage/Recherche (5) : badge vérifié, stats arrondies, partage premium, filtres avancés, carte Tous les scénarios incluent edge cases, métriques de performance et conformité RGPD. Couverture fonctionnelle MVP maintenant complète.
This commit is contained in:
jpgiannetti
@@ -0,0 +1,205 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @navigation @ui @mvp
|
||||
Fonctionnalité: Affichage avancé distance, direction et ETA
|
||||
|
||||
En tant qu'utilisateur
|
||||
Je veux voir la distance, la direction et le temps d'arrivée estimé vers les points d'intérêt
|
||||
Afin de planifier mon déplacement et anticiper les prochaines séquences
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système affiche les informations suivantes:
|
||||
| Information | Format | Mise à jour |
|
||||
| Distance | Mètres / Kilomètres | Temps réel |
|
||||
| Direction | Boussole + Flèche | Temps réel |
|
||||
| ETA | Minutes / Heures | Dynamique |
|
||||
| Vitesse utilisateur | km/h (mode voiture) | Temps réel |
|
||||
|
||||
Scénario: Affichage de la distance en mètres pour proximité < 1km
|
||||
Étant donné un utilisateur "alice@roadwave.fr" en mode piéton
|
||||
Et elle se trouve à 450m du Panthéon
|
||||
Quand elle consulte l'écran de l'audio-guide
|
||||
Alors la distance affichée est: "450 m"
|
||||
Et la précision de la distance est de ±10m
|
||||
Et un événement "DISTANCE_DISPLAYED" est enregistré avec unité: "meters", valeur: 450
|
||||
Et la métrique "distance.displayed.meters" est incrémentée
|
||||
|
||||
Scénario: Affichage de la distance en kilomètres pour distance > 1km
|
||||
Étant donné un utilisateur "bob@roadwave.fr" en mode voiture
|
||||
Et il se trouve à 12.5 km du Château de Chambord
|
||||
Quand il consulte l'écran de l'audio-guide
|
||||
Alors la distance affichée est: "12.5 km"
|
||||
Et la précision de la distance est de ±100m
|
||||
Et un événement "DISTANCE_DISPLAYED" est enregistré avec unité: "kilometers", valeur: 12.5
|
||||
Et la métrique "distance.displayed.kilometers" est incrémentée
|
||||
|
||||
Scénario: Mise à jour en temps réel de la distance pendant le déplacement
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" en mode piéton
|
||||
Et il marche vers la Sainte-Chapelle initialement à 800m
|
||||
Quand il marche à une vitesse de 5 km/h
|
||||
Alors la distance est mise à jour toutes les 2 secondes:
|
||||
| Temps | Distance affichée |
|
||||
| T+0s | 800 m |
|
||||
| T+30s | 760 m |
|
||||
| T+60s | 720 m |
|
||||
| T+90s | 680 m |
|
||||
Et la barre de progression visuelle se remplit progressivement
|
||||
Et un événement "DISTANCE_UPDATED" est enregistré toutes les 10 secondes
|
||||
Et la métrique "distance.real_time_updates" est incrémentée
|
||||
|
||||
Scénario: Affichage de la direction avec boussole et flèche
|
||||
Étant donné un utilisateur "david@roadwave.fr" en mode piéton
|
||||
Et il se trouve face au nord
|
||||
Et le Panthéon est au sud-est de sa position
|
||||
Quand il consulte l'écran de l'audio-guide
|
||||
Alors une boussole s'affiche avec:
|
||||
| Élément | Affichage |
|
||||
| Orientation boussole | Nord en haut |
|
||||
| Flèche vers POI | Pointe vers 135° (sud-est) |
|
||||
| Angle cardinal | "SE" (sud-est) |
|
||||
| Rotation dynamique | Suit l'orientation du téléphone|
|
||||
Et la flèche est colorée selon la distance:
|
||||
| Distance | Couleur |
|
||||
| < 100m | Vert |
|
||||
| 100m - 500m | Orange |
|
||||
| > 500m | Bleu |
|
||||
Et un événement "DIRECTION_DISPLAYED" est enregistré avec angle: 135
|
||||
Et la métrique "direction.displayed" est incrémentée
|
||||
|
||||
Scénario: Mise à jour de la direction en temps réel lors de la rotation
|
||||
Étant donné un utilisateur "eve@roadwave.fr" en mode piéton
|
||||
Et elle se trouve face au nord avec le Panthéon au sud-est
|
||||
Quand elle tourne son téléphone vers l'est
|
||||
Alors la boussole pivote dynamiquement
|
||||
Et la flèche vers le POI reste fixée sur la direction réelle (135°)
|
||||
Et l'affichage est fluide à 60 FPS
|
||||
Et un événement "COMPASS_ROTATED" est enregistré
|
||||
Et la métrique "compass.rotations" est incrémentée
|
||||
|
||||
Scénario: Calcul de l'ETA en mode piéton (vitesse moyenne 5 km/h)
|
||||
Étant donné un utilisateur "frank@roadwave.fr" en mode piéton
|
||||
Et il se trouve à 600m du Jardin du Luxembourg
|
||||
Quand le système calcule l'ETA avec vitesse piéton moyenne: 5 km/h
|
||||
Alors l'ETA affiché est: "7 min"
|
||||
Et le calcul utilise la formule: temps = distance / vitesse_moyenne_pieton
|
||||
Et un événement "ETA_CALCULATED" est enregistré avec mode: "pedestrian", eta: 7
|
||||
Et la métrique "eta.calculated.pedestrian" est incrémentée
|
||||
|
||||
Scénario: Calcul de l'ETA en mode voiture avec vitesse réelle
|
||||
Étant donné un utilisateur "grace@roadwave.fr" en mode voiture
|
||||
Et elle se trouve à 15 km du Château de Chenonceau
|
||||
Et elle roule actuellement à 80 km/h
|
||||
Quand le système calcule l'ETA
|
||||
Alors l'ETA affiché est: "11 min"
|
||||
Et le calcul utilise la vitesse réelle actuelle
|
||||
Et un événement "ETA_CALCULATED" est enregistré avec mode: "car", vitesse: 80, eta: 11
|
||||
Et la métrique "eta.calculated.car" est incrémentée
|
||||
|
||||
Scénario: Recalcul dynamique de l'ETA en fonction des changements de vitesse
|
||||
Étant donné un utilisateur "henry@roadwave.fr" en mode voiture
|
||||
Et l'ETA initial vers le Château d'Amboise est: "15 min" (vitesse: 70 km/h)
|
||||
Quand il ralentit à 40 km/h à cause d'un bouchon
|
||||
Alors l'ETA est recalculé et mis à jour: "22 min"
|
||||
Et une notification discrète s'affiche: "ETA mis à jour : +7 min"
|
||||
Quand il accélère à nouveau à 90 km/h
|
||||
Alors l'ETA est recalculé: "12 min"
|
||||
Et un événement "ETA_UPDATED" est enregistré avec ancienETA: 22, nouveauETA: 12
|
||||
Et la métrique "eta.recalculated" est incrémentée
|
||||
|
||||
Scénario: Affichage du temps d'arrivée absolu en mode voiture
|
||||
Étant donné un utilisateur "iris@roadwave.fr" en mode voiture
|
||||
Et il est 14h30
|
||||
Et l'ETA vers le prochain point est: "25 min"
|
||||
Quand elle active l'option "Afficher l'heure d'arrivée"
|
||||
Alors l'affichage change de "25 min" à "Arrivée à 14h55"
|
||||
Et les deux formats peuvent être basculés par un tap sur l'ETA
|
||||
Et un événement "ETA_FORMAT_CHANGED" est enregistré avec format: "absolute_time"
|
||||
Et la métrique "eta.format.absolute" est incrémentée
|
||||
|
||||
Scénario: Affichage groupé distance + direction + ETA sur une carte compacte
|
||||
Étant donné un utilisateur "jack@roadwave.fr" en mode piéton
|
||||
Et il se trouve à 450m du Panthéon au sud-est
|
||||
Quand il consulte la carte de l'audio-guide
|
||||
Alors une carte compacte s'affiche pour chaque point d'intérêt:
|
||||
| Point d'intérêt | Distance | Direction | ETA |
|
||||
| Panthéon | 450 m | SE ↗ | 5 min |
|
||||
| Jardin Lux. | 1.2 km | SO ↙ | 14 min |
|
||||
| Sorbonne | 320 m | E → | 4 min |
|
||||
Et les points sont triés par distance (plus proche en premier)
|
||||
Et un événement "POI_LIST_DISPLAYED" est enregistré
|
||||
Et la métrique "poi_list.displayed" est incrémentée
|
||||
|
||||
Scénario: Indication visuelle "Vous y êtes !" à l'arrivée
|
||||
Étant donné un utilisateur "kate@roadwave.fr" en mode piéton
|
||||
Et elle approche du Panthéon
|
||||
Quand elle entre dans un rayon de 10m du point d'intérêt
|
||||
Alors l'affichage change de "15 m" à "🎯 Vous y êtes !"
|
||||
Et une animation de succès est jouée
|
||||
Et une notification sonore subtile est jouée
|
||||
Et l'audio de la séquence démarre automatiquement
|
||||
Et un événement "POI_ARRIVED" est enregistré avec précision: 8m
|
||||
Et la métrique "poi.arrived" est incrémentée
|
||||
|
||||
Scénario: Affichage du trajet à vol d'oiseau vs trajet routier
|
||||
Étant donné un utilisateur "luke@roadwave.fr" en mode voiture
|
||||
Et il se trouve à 12 km à vol d'oiseau du Château de Chambord
|
||||
Mais le trajet routier est de 18 km (détours)
|
||||
Quand il consulte l'ETA
|
||||
Alors la distance affichée est celle du trajet routier: "18 km"
|
||||
Et l'ETA est calculé sur le trajet routier: "15 min"
|
||||
Et un bouton "Itinéraire" permet de voir le trajet détaillé
|
||||
Et un événement "ROUTE_DISPLAYED" est enregistré avec routeDistance: 18, airDistance: 12
|
||||
Et la métrique "route.displayed" est incrémentée
|
||||
|
||||
Scénario: Mode d'économie de batterie avec mise à jour moins fréquente
|
||||
Étant donné un utilisateur "mary@roadwave.fr" avec batterie < 20%
|
||||
Et le mode économie d'énergie est activé
|
||||
Quand elle utilise l'audio-guide
|
||||
Alors la fréquence de mise à jour des distances est réduite:
|
||||
| Mode normal | Mode économie |
|
||||
| Toutes les 2s | Toutes les 10s|
|
||||
Et la précision GPS est réduite (précision: ±30m au lieu de ±10m)
|
||||
Et un événement "BATTERY_SAVER_ENABLED" est enregistré
|
||||
Et la métrique "battery_saver.enabled" est incrémentée
|
||||
|
||||
Scénario: Affichage de la vitesse actuelle en mode voiture
|
||||
Étant donné un utilisateur "nathan@roadwave.fr" en mode voiture
|
||||
Et il roule à 75 km/h
|
||||
Quand il consulte l'écran de l'audio-guide
|
||||
Alors sa vitesse actuelle est affichée: "75 km/h"
|
||||
Et la vitesse est mise à jour en temps réel
|
||||
Et un événement "SPEED_DISPLAYED" est enregistré avec vitesse: 75
|
||||
Et la métrique "speed.displayed" est incrémentée
|
||||
|
||||
Scénario: Alerte de dépassement de limite de vitesse (optionnel)
|
||||
Étant donné un utilisateur "olive@roadwave.fr" en mode voiture
|
||||
Et elle a activé l'option "Alertes de vitesse"
|
||||
Et la limite de vitesse sur sa route est 80 km/h
|
||||
Quand elle roule à 95 km/h
|
||||
Alors une alerte visuelle discrète s'affiche: "⚠️ 95 km/h (limite: 80)"
|
||||
Et l'alerte disparaît quand elle ralentit en dessous de 85 km/h
|
||||
Et un événement "SPEED_LIMIT_EXCEEDED" est enregistré avec vitesse: 95, limite: 80
|
||||
Et la métrique "speed.limit_exceeded" est incrémentée
|
||||
|
||||
Scénario: Indication de zones à forte densité de points d'intérêt
|
||||
Étant donné un utilisateur "paul@roadwave.fr" en mode piéton
|
||||
Et il se trouve dans une zone avec 5 points d'intérêt dans un rayon de 200m
|
||||
Quand il consulte la carte
|
||||
Alors une indication s'affiche: "Zone dense : 5 points à proximité"
|
||||
Et les marqueurs sont regroupés en cluster pour éviter la surcharge visuelle
|
||||
Et en zoomant, le cluster se décompose en marqueurs individuels
|
||||
Et un événement "HIGH_DENSITY_ZONE_DETECTED" est enregistré avec count: 5
|
||||
Et la métrique "zones.high_density" est incrémentée
|
||||
|
||||
Scénario: Métriques de précision de la localisation GPS
|
||||
Étant donné un utilisateur "quinn@roadwave.fr" utilisant l'audio-guide
|
||||
Quand les métriques de précision GPS sont collectées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur cible |
|
||||
| Précision GPS moyenne | ±10m |
|
||||
| Précision GPS en mode économie | ±30m |
|
||||
| Fréquence de mise à jour GPS | 1-2 Hz |
|
||||
| Taux d'erreur de positionnement | < 5% |
|
||||
| Latence de calcul ETA | < 100ms |
|
||||
Et les métriques sont exportées vers le système de monitoring
|
||||
Et des alertes sont déclenchées si précision > ±50m
|
||||
247
features/api/audio-guides/creation-wizard-complet.feature
Normal file
247
features/api/audio-guides/creation-wizard-complet.feature
Normal file
@@ -0,0 +1,247 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @content-creation @mvp
|
||||
Fonctionnalité: Wizard complet de création d'audio-guide multi-séquences
|
||||
|
||||
En tant que créateur de contenu
|
||||
Je veux créer un audio-guide avec plusieurs séquences géolocalisées
|
||||
Afin de proposer une expérience guidée immersive aux utilisateurs
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système supporte les limites suivantes:
|
||||
| Paramètre | Valeur |
|
||||
| Nombre max de séquences par guide | 50 |
|
||||
| Taille max fichier audio | 100 MB |
|
||||
| Formats audio acceptés | MP3, M4A, WAV |
|
||||
| Durée max par séquence | 15 minutes |
|
||||
| Rayon min d'un point d'intérêt | 10 mètres |
|
||||
| Rayon max d'un point d'intérêt | 500 mètres |
|
||||
|
||||
Scénario: Création d'un audio-guide - Étape 1: Informations générales
|
||||
Étant donné un créateur "alice@roadwave.fr" connecté
|
||||
Quand le créateur clique sur "Créer un audio-guide"
|
||||
Alors le wizard s'ouvre sur l'étape 1 "Informations générales"
|
||||
Et le créateur remplit le formulaire:
|
||||
| Champ | Valeur |
|
||||
| Titre | Visite guidée du Quartier Latin |
|
||||
| Description courte | Découvrez l'histoire du quartier étudiant |
|
||||
| Description longue | Plongez dans 2000 ans d'histoire... |
|
||||
| Catégorie | Tourisme |
|
||||
| Langues disponibles | Français, Anglais |
|
||||
| Durée estimée | 2 heures |
|
||||
| Difficulté | Facile |
|
||||
| Accessibilité PMR | Oui |
|
||||
Et le créateur clique sur "Suivant"
|
||||
Alors les données sont validées et enregistrées en brouillon
|
||||
Et un événement "AUDIO_GUIDE_CREATION_STARTED" est enregistré
|
||||
Et la métrique "audio_guide.creation.step1_completed" est incrémentée
|
||||
|
||||
Scénario: Création d'un audio-guide - Étape 2: Image de couverture
|
||||
Étant donné un créateur "bob@roadwave.fr" à l'étape 2 du wizard
|
||||
Quand le créateur upload une image de couverture:
|
||||
| Propriété | Valeur |
|
||||
| Fichier | quartier-latin-cover.jpg |
|
||||
| Taille | 1920x1080 px |
|
||||
| Format | JPEG |
|
||||
| Poids | 2.5 MB |
|
||||
Alors l'image est uploadée vers le stockage S3
|
||||
Et une miniature est générée automatiquement (300x200 px)
|
||||
Et un aperçu de l'image est affiché
|
||||
Et le créateur peut recadrer l'image via un éditeur intégré
|
||||
Et le créateur clique sur "Suivant"
|
||||
Alors l'image est associée au brouillon
|
||||
Et un événement "AUDIO_GUIDE_COVER_UPLOADED" est enregistré
|
||||
Et la métrique "audio_guide.creation.step2_completed" est incrémentée
|
||||
|
||||
Scénario: Création d'un audio-guide - Étape 3: Ajout de séquences via carte
|
||||
Étant donné un créateur "charlie@roadwave.fr" à l'étape 3 du wizard
|
||||
Quand le créateur voit une carte interactive centrée sur Paris
|
||||
Et clique sur "Ajouter un point d'intérêt" sur la carte
|
||||
Et place un marqueur à la position: 48.8534, 2.3488 (Notre-Dame)
|
||||
Alors un formulaire de séquence s'ouvre:
|
||||
| Champ | Valeur par défaut |
|
||||
| Nom du point | [Vide] |
|
||||
| Position GPS | 48.8534, 2.3488 |
|
||||
| Rayon de déclenchement| 50 mètres |
|
||||
| Ordre dans le parcours| 1 |
|
||||
| Fichier audio | [Non uploadé] |
|
||||
Et le créateur remplit les informations:
|
||||
| Champ | Valeur |
|
||||
| Nom du point | Cathédrale Notre-Dame de Paris |
|
||||
| Rayon de déclenchement| 100 mètres |
|
||||
| Ordre dans le parcours| 1 |
|
||||
Et le créateur upload un fichier audio "notre-dame.mp3" (12 MB, 8min 30s)
|
||||
Et le créateur clique sur "Enregistrer le point"
|
||||
Alors la séquence 1 est créée et affichée sur la carte
|
||||
Et un événement "AUDIO_GUIDE_SEQUENCE_ADDED" est enregistré
|
||||
Et la métrique "audio_guide.sequences.added" est incrémentée
|
||||
|
||||
Scénario: Ajout de plusieurs séquences consécutives
|
||||
Étant donné un créateur "david@roadwave.fr" avec 1 séquence créée
|
||||
Quand le créateur ajoute 4 nouvelles séquences:
|
||||
| Ordre | Nom | Position GPS | Rayon | Audio |
|
||||
| 2 | Sainte-Chapelle | 48.8555, 2.3450 | 80m | chapelle.mp3 |
|
||||
| 3 | Panthéon | 48.8462, 2.3464 | 100m | pantheon.mp3 |
|
||||
| 4 | Jardin du Luxembourg | 48.8462, 2.3371 | 150m | jardin.mp3 |
|
||||
| 5 | Sorbonne | 48.8487, 2.3431 | 70m | sorbonne.mp3 |
|
||||
Alors les 5 séquences sont affichées sur la carte avec des marqueurs numérotés
|
||||
Et une ligne de parcours relie les points dans l'ordre
|
||||
Et la distance totale du parcours est calculée: 3.2 km
|
||||
Et la durée totale des audios est calculée: 42 minutes
|
||||
Et un panneau latéral liste les séquences avec possibilité de réorganiser
|
||||
Et un événement "AUDIO_GUIDE_SEQUENCES_BATCH_ADDED" est enregistré
|
||||
Et la métrique "audio_guide.sequences.count" est mise à jour: 5
|
||||
|
||||
Scénario: Réorganisation de l'ordre des séquences par drag & drop
|
||||
Étant donné un créateur "eve@roadwave.fr" avec 5 séquences créées
|
||||
Quand le créateur utilise le panneau latéral
|
||||
Et fait glisser la séquence #3 "Panthéon" vers la position #2
|
||||
Alors l'ordre des séquences est mis à jour:
|
||||
| Nouvel ordre | Nom |
|
||||
| 1 | Cathédrale Notre-Dame |
|
||||
| 2 | Panthéon |
|
||||
| 3 | Sainte-Chapelle |
|
||||
| 4 | Jardin du Luxembourg |
|
||||
| 5 | Sorbonne |
|
||||
Et la ligne de parcours sur la carte est recalculée
|
||||
Et la distance totale est recalculée: 3.5 km
|
||||
Et un événement "AUDIO_GUIDE_SEQUENCES_REORDERED" est enregistré
|
||||
Et la métrique "audio_guide.sequences.reordered" est incrémentée
|
||||
|
||||
Scénario: Modification d'une séquence existante
|
||||
Étant donné un créateur "frank@roadwave.fr" avec 5 séquences créées
|
||||
Quand le créateur clique sur le marqueur #2 "Panthéon" sur la carte
|
||||
Alors le formulaire d'édition s'ouvre avec les données actuelles
|
||||
Et le créateur modifie:
|
||||
| Champ | Ancienne valeur | Nouvelle valeur |
|
||||
| Rayon de déclenchement| 100m | 120m |
|
||||
| Fichier audio | pantheon.mp3 | pantheon-v2.mp3 |
|
||||
Et le créateur clique sur "Enregistrer les modifications"
|
||||
Alors la séquence est mise à jour
|
||||
Et le nouveau fichier audio remplace l'ancien
|
||||
Et l'ancien fichier est supprimé du stockage S3
|
||||
Et un événement "AUDIO_GUIDE_SEQUENCE_UPDATED" est enregistré
|
||||
Et la métrique "audio_guide.sequences.updated" est incrémentée
|
||||
|
||||
Scénario: Suppression d'une séquence
|
||||
Étant donné un créateur "grace@roadwave.fr" avec 5 séquences créées
|
||||
Quand le créateur clique sur l'icône de suppression de la séquence #3
|
||||
Alors un dialogue de confirmation s'affiche: "Supprimer cette séquence ?"
|
||||
Et le créateur confirme la suppression
|
||||
Alors la séquence #3 est supprimée
|
||||
Et le fichier audio associé est marqué pour suppression différée (30 jours)
|
||||
Et les séquences suivantes sont renumérotées automatiquement:
|
||||
| Ancien ordre | Nouveau ordre | Nom |
|
||||
| 4 | 3 | Jardin du Luxembourg |
|
||||
| 5 | 4 | Sorbonne |
|
||||
Et la ligne de parcours est recalculée
|
||||
Et un événement "AUDIO_GUIDE_SEQUENCE_DELETED" est enregistré
|
||||
Et la métrique "audio_guide.sequences.deleted" est incrémentée
|
||||
|
||||
Scénario: Validation de la distance minimale entre séquences
|
||||
Étant donné un créateur "henry@roadwave.fr" avec 2 séquences créées
|
||||
Quand le créateur tente d'ajouter une 3ème séquence à 5 mètres de la séquence #1
|
||||
Alors un message d'erreur s'affiche: "Ce point est trop proche d'un point existant (min: 20m)"
|
||||
Et le marqueur est affiché en rouge sur la carte
|
||||
Et la séquence n'est pas enregistrée tant que le créateur ne déplace pas le marqueur
|
||||
Et un événement "AUDIO_GUIDE_SEQUENCE_TOO_CLOSE" est enregistré
|
||||
Et la métrique "audio_guide.validation.sequence_too_close" est incrémentée
|
||||
|
||||
Scénario: Création d'un audio-guide - Étape 4: Configuration avancée
|
||||
Étant donné un créateur "iris@roadwave.fr" à l'étape 4 du wizard
|
||||
Quand le créateur configure les options avancées:
|
||||
| Option | Valeur |
|
||||
| Prix (gratuit ou payant) | Gratuit |
|
||||
| Visibilité | Publique |
|
||||
| Mode de lecture | Séquentiel obligatoire |
|
||||
| Autoriser les avis utilisateurs | Oui |
|
||||
| Autoriser le téléchargement | Non |
|
||||
| Activer les sous-titres | Oui |
|
||||
Et clique sur "Suivant"
|
||||
Alors les options sont enregistrées
|
||||
Et un événement "AUDIO_GUIDE_CONFIG_COMPLETED" est enregistré
|
||||
Et la métrique "audio_guide.creation.step4_completed" est incrémentée
|
||||
|
||||
Scénario: Création d'un audio-guide - Étape 5: Prévisualisation et publication
|
||||
Étant donné un créateur "jack@roadwave.fr" à l'étape 5 du wizard
|
||||
Quand le créateur voit la prévisualisation complète:
|
||||
| Section | Contenu |
|
||||
| Informations | Titre, description, durée |
|
||||
| Image | Aperçu de la couverture |
|
||||
| Parcours | Carte avec 5 séquences |
|
||||
| Audio | Liste des 5 fichiers audio |
|
||||
| Configuration | Prix, visibilité, options |
|
||||
Et clique sur "Tester le parcours en simulation"
|
||||
Alors une simulation GPS est lancée avec lecture des audios
|
||||
Et le créateur peut naviguer dans le parcours virtuel
|
||||
Et après validation, le créateur clique sur "Publier l'audio-guide"
|
||||
Alors l'audio-guide passe du statut "brouillon" à "publié"
|
||||
Et l'audio-guide devient visible dans les recherches et recommandations
|
||||
Et un événement "AUDIO_GUIDE_PUBLISHED" est enregistré
|
||||
Et la métrique "audio_guide.published" est incrémentée
|
||||
Et un email de confirmation est envoyé au créateur
|
||||
|
||||
Scénario: Sauvegarde automatique du brouillon pendant la création
|
||||
Étant donné un créateur "kate@roadwave.fr" en train de créer un audio-guide
|
||||
Quand le créateur remplit des informations à chaque étape
|
||||
Alors le brouillon est automatiquement sauvegardé toutes les 30 secondes
|
||||
Et un indicateur "Sauvegardé automatiquement à 14:32" s'affiche
|
||||
Et en cas de fermeture accidentelle, le créateur peut reprendre la création
|
||||
Et un événement "AUDIO_GUIDE_DRAFT_AUTOSAVED" est enregistré toutes les 30s
|
||||
Et la métrique "audio_guide.drafts.autosaved" est incrémentée
|
||||
|
||||
Scénario: Récupération d'un brouillon après interruption
|
||||
Étant donné un créateur "luke@roadwave.fr" qui a commencé un audio-guide hier
|
||||
Et le brouillon a été sauvegardé automatiquement à l'étape 3
|
||||
Quand le créateur clique sur "Créer un audio-guide"
|
||||
Alors un message s'affiche: "Vous avez un brouillon en cours. Reprendre la création ?"
|
||||
Et le créateur clique sur "Reprendre"
|
||||
Alors le wizard s'ouvre directement à l'étape 3
|
||||
Et toutes les données saisies sont restaurées
|
||||
Et un événement "AUDIO_GUIDE_DRAFT_RESUMED" est enregistré
|
||||
Et la métrique "audio_guide.drafts.resumed" est incrémentée
|
||||
|
||||
Scénario: Import d'un parcours GPX pour créer automatiquement les séquences
|
||||
Étant donné un créateur "mary@roadwave.fr" à l'étape 3 du wizard
|
||||
Quand le créateur clique sur "Importer un parcours GPX"
|
||||
Et upload un fichier "parcours-paris.gpx" avec 10 waypoints
|
||||
Alors le système extrait les coordonnées GPS de chaque waypoint
|
||||
Et crée automatiquement 10 séquences avec positions GPS pré-remplies
|
||||
Et les marqueurs sont affichés sur la carte
|
||||
Et le créateur doit ensuite ajouter les fichiers audio et noms pour chaque séquence
|
||||
Et un événement "AUDIO_GUIDE_GPX_IMPORTED" est enregistré
|
||||
Et la métrique "audio_guide.gpx.imported" est incrémentée
|
||||
|
||||
Scénario: Validation de la qualité audio avant publication
|
||||
Étant donné un créateur "nathan@roadwave.fr" qui tente de publier un audio-guide
|
||||
Quand le système analyse les fichiers audio uploadés
|
||||
Et détecte que le fichier "sequence-3.mp3" a un bitrate de 32 kbps (trop faible)
|
||||
Alors un avertissement s'affiche: "Le fichier 'sequence-3.mp3' a une qualité audio faible. Recommandé: 128 kbps minimum"
|
||||
Et le créateur peut choisir de:
|
||||
| Action | Conséquence |
|
||||
| Ignorer et publier quand même | Publication autorisée |
|
||||
| Remplacer le fichier | Retour à l'édition |
|
||||
Et un événement "AUDIO_GUIDE_LOW_QUALITY_WARNING" est enregistré
|
||||
Et la métrique "audio_guide.quality.warnings" est incrémentée
|
||||
|
||||
Scénario: Limitation du nombre de brouillons par créateur
|
||||
Étant donné un créateur "olive@roadwave.fr" avec 10 brouillons en cours
|
||||
Quand le créateur tente de créer un 11ème audio-guide
|
||||
Alors un message s'affiche: "Vous avez atteint la limite de 10 brouillons. Veuillez publier ou supprimer des brouillons existants."
|
||||
Et un lien vers la liste des brouillons est affiché
|
||||
Et la création est bloquée jusqu'à suppression d'un brouillon
|
||||
Et un événement "AUDIO_GUIDE_DRAFT_LIMIT_REACHED" est enregistré
|
||||
Et la métrique "audio_guide.drafts.limit_reached" est incrémentée
|
||||
|
||||
Scénario: Métriques de performance du wizard de création
|
||||
Étant donné que 1000 audio-guides sont créés par mois
|
||||
Quand les métriques de création sont collectées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur cible |
|
||||
| Taux de complétion du wizard | > 65% |
|
||||
| Temps moyen de création | < 45 min |
|
||||
| Nombre moyen de séquences par guide | 5-8 |
|
||||
| Taux d'abandon à chaque étape | < 15% |
|
||||
| Taux d'utilisation de l'autosave | 100% |
|
||||
Et les métriques sont exportées vers le système de monitoring
|
||||
Et des optimisations UX sont proposées si taux d'abandon > 20%
|
||||
@@ -0,0 +1,223 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @car-mode @geolocation @mvp
|
||||
Fonctionnalité: Déclenchement GPS automatique des audio-guides en mode voiture
|
||||
|
||||
En tant qu'utilisateur en voiture
|
||||
Je veux que les audio-guides se déclenchent automatiquement à l'approche des points d'intérêt
|
||||
Afin de profiter d'une expérience guidée sans interaction manuelle pendant la conduite
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système de déclenchement en mode voiture respecte:
|
||||
| Paramètre | Valeur |
|
||||
| Rayon de déclenchement | 200-500m |
|
||||
| Vitesse max pour déclenchement | 90 km/h |
|
||||
| Ordre de séquences | Strict |
|
||||
| Notification visuelle | Minimale |
|
||||
| Notification audio | Prioritaire |
|
||||
| Auto-play | Obligatoire |
|
||||
|
||||
Scénario: Démarrage d'un audio-guide en mode voiture
|
||||
Étant donné un utilisateur "alice@roadwave.fr" en mode voiture
|
||||
Et elle roule à 50 km/h sur l'autoroute A6
|
||||
Quand elle lance l'audio-guide "Route des Châteaux de la Loire"
|
||||
Alors l'audio de la séquence d'introduction démarre automatiquement
|
||||
Et l'interface minimaliste en mode voiture s'affiche:
|
||||
| Élément | État |
|
||||
| Carte | Simplifiée, zoom automatique |
|
||||
| Notifications visuelles | Minimales |
|
||||
| Prochain point | Château de Chambord - 25 km |
|
||||
| ETA | Arrivée dans 18 minutes |
|
||||
| Contrôles audio | Gros boutons [Pause] [Skip] |
|
||||
Et un événement "AUDIO_GUIDE_STARTED_CAR_MODE" est enregistré
|
||||
Et la métrique "audio_guide.started.car_mode" est incrémentée
|
||||
|
||||
Scénario: Déclenchement automatique à l'approche d'un point d'intérêt
|
||||
Étant donné un utilisateur "bob@roadwave.fr" en mode voiture à 60 km/h
|
||||
Et il écoute l'audio-guide "Route des Châteaux de la Loire"
|
||||
Et il approche du Château de Chambord
|
||||
Quand il entre dans un rayon de 400m du château (configuré par le créateur)
|
||||
Alors l'audio en cours se termine en fondu (3 secondes)
|
||||
Et l'audio de la séquence "Château de Chambord" démarre automatiquement
|
||||
Et une notification audio est jouée: "À votre droite, Château de Chambord"
|
||||
Et une notification visuelle minimale s'affiche brièvement (2s):
|
||||
| Élément | Contenu |
|
||||
| Titre | Château de Chambord |
|
||||
| Direction | → À droite |
|
||||
| Distance | 400m |
|
||||
Et un événement "SEQUENCE_AUTO_TRIGGERED_CAR" est enregistré
|
||||
Et la métrique "audio_guide.sequence.car.triggered" est incrémentée
|
||||
|
||||
Scénario: Calcul de l'ETA dynamique basé sur la vitesse réelle
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" en mode voiture
|
||||
Et il approche du prochain point d'intérêt à 15 km
|
||||
Et il roule à 80 km/h
|
||||
Quand le système calcule l'ETA
|
||||
Alors l'ETA affiché est: "Arrivée dans 11 minutes"
|
||||
Quand il ralentit à 50 km/h (bouchon)
|
||||
Alors l'ETA est recalculé en temps réel: "Arrivée dans 18 minutes"
|
||||
Et un événement "ETA_RECALCULATED" est enregistré
|
||||
Et la métrique "audio_guide.eta.updated" est incrémentée
|
||||
|
||||
Scénario: Notification vocale d'approche 2km avant le point
|
||||
Étant donné un utilisateur "david@roadwave.fr" en mode voiture à 70 km/h
|
||||
Et il écoute l'audio-guide "Route des Châteaux de la Loire"
|
||||
Quand il est à 2 km du Château de Chenonceau
|
||||
Alors une notification vocale est jouée par-dessus l'audio actuel:
|
||||
"Dans 2 kilomètres, vous découvrirez le Château de Chenonceau"
|
||||
Et le volume de l'audio actuel est réduit de 50% pendant la notification (ducking audio)
|
||||
Et après la notification, le volume reprend normalement
|
||||
Et un événement "POI_ADVANCE_NOTIFICATION" est enregistré avec distance: 2000m
|
||||
Et la métrique "audio_guide.advance_notification" est incrémentée
|
||||
|
||||
Scénario: Gestion du dépassement d'un point d'intérêt sans déclenchement
|
||||
Étant donné un utilisateur "eve@roadwave.fr" en mode voiture à 90 km/h
|
||||
Et elle approche du Château d'Amboise (séquence #3)
|
||||
Mais elle a manqué la séquence #2 (Château de Chaumont)
|
||||
Quand elle entre dans le rayon du Château d'Amboise
|
||||
Alors l'audio de la séquence #2 est automatiquement joué d'abord
|
||||
Et un message vocal indique: "Séquence précédente: Château de Chaumont"
|
||||
Et après la fin de la séquence #2, la séquence #3 démarre
|
||||
Et un événement "SEQUENCE_CATCH_UP" est enregistré
|
||||
Et la métrique "audio_guide.sequence.catch_up" est incrémentée
|
||||
|
||||
Scénario: Marquage automatique d'une séquence comme "manquée"
|
||||
Étant donné un utilisateur "frank@roadwave.fr" en mode voiture à 100 km/h
|
||||
Et il a dépassé le Château de Chaumont sans entrer dans son rayon
|
||||
Et il s'éloigne maintenant à plus de 5 km
|
||||
Alors la séquence "Château de Chaumont" est marquée comme "Manquée"
|
||||
Et elle reste disponible dans la liste pour écoute manuelle ultérieure
|
||||
Et un événement "SEQUENCE_MISSED" est enregistré avec raison: "too_fast"
|
||||
Et la métrique "audio_guide.sequence.missed" est incrémentée
|
||||
|
||||
Scénario: Pause automatique lors d'un appel téléphonique
|
||||
Étant donné un utilisateur "grace@roadwave.fr" en mode voiture
|
||||
Et elle écoute l'audio-guide à la position 3min 20s
|
||||
Quand elle reçoit un appel téléphonique via CarPlay
|
||||
Alors l'audio-guide se met automatiquement en pause
|
||||
Et la position de lecture est sauvegardée: 3min 20s
|
||||
Et un événement "AUDIO_PAUSED_PHONE_CALL" est enregistré
|
||||
Quand l'appel se termine
|
||||
Alors l'audio-guide reprend automatiquement à 3min 20s
|
||||
Et un événement "AUDIO_RESUMED_AFTER_CALL" est enregistré
|
||||
Et la métrique "audio_guide.interruption.phone" est incrémentée
|
||||
|
||||
Scénario: Intégration avec CarPlay pour affichage sur écran véhicule
|
||||
Étant donné un utilisateur "henry@roadwave.fr" en mode voiture
|
||||
Et son iPhone est connecté via CarPlay
|
||||
Quand il lance l'audio-guide "Route des Châteaux de la Loire"
|
||||
Alors l'interface CarPlay s'affiche sur l'écran du véhicule:
|
||||
| Élément | Affichage |
|
||||
| Carte simplifiée | Vue routière optimisée |
|
||||
| Prochain point | Nom + distance + ETA |
|
||||
| Contrôles audio | Gros boutons tactiles |
|
||||
| Progression | Barre 3/10 séquences |
|
||||
| Commandes vocales | "Dis Siri, suivant" |
|
||||
Et les contrôles au volant du véhicule fonctionnent (lecture/pause)
|
||||
Et un événement "CARPLAY_SESSION_STARTED" est enregistré
|
||||
Et la métrique "audio_guide.carplay.used" est incrémentée
|
||||
|
||||
Scénario: Commandes vocales Siri pour contrôle sans les mains
|
||||
Étant donné un utilisateur "iris@roadwave.fr" en mode voiture
|
||||
Et elle écoute l'audio-guide via CarPlay
|
||||
Quand elle dit "Dis Siri, mets en pause"
|
||||
Alors l'audio-guide se met en pause
|
||||
Quand elle dit "Dis Siri, reprends la lecture"
|
||||
Alors l'audio-guide reprend
|
||||
Quand elle dit "Dis Siri, séquence suivante"
|
||||
Alors la séquence suivante démarre
|
||||
Et un événement "VOICE_COMMAND_EXECUTED" est enregistré avec commande: "next"
|
||||
Et la métrique "audio_guide.voice_commands.used" est incrémentée
|
||||
|
||||
Scénario: Adaptation du volume en fonction de la vitesse du véhicule
|
||||
Étant donné un utilisateur "jack@roadwave.fr" en mode voiture
|
||||
Et il écoute l'audio-guide avec volume configuré à 70%
|
||||
Quand il roule à 50 km/h
|
||||
Alors le volume reste à 70% (bruit ambiant faible)
|
||||
Quand il accélère à 130 km/h sur autoroute
|
||||
Alors le volume augmente automatiquement à 85% (compensation du bruit)
|
||||
Et un événement "VOLUME_AUTO_ADJUSTED" est enregistré avec vitesse: 130, volume: 85
|
||||
Et la métrique "audio_guide.volume.auto_adjusted" est incrémentée
|
||||
|
||||
Scénario: Désactivation temporaire en cas de vitesse excessive
|
||||
Étant donné un utilisateur "kate@roadwave.fr" en mode voiture
|
||||
Et elle écoute l'audio-guide sur autoroute
|
||||
Quand elle dépasse les 110 km/h
|
||||
Alors l'audio continue de jouer normalement
|
||||
Mais aucune nouvelle séquence ne se déclenche automatiquement
|
||||
Et un message vocal indique: "Déclenchements automatiques suspendus à haute vitesse"
|
||||
Quand elle ralentit en dessous de 90 km/h
|
||||
Alors les déclenchements automatiques sont réactivés
|
||||
Et un événement "AUTO_TRIGGER_SPEED_LIMITED" est enregistré
|
||||
Et la métrique "audio_guide.speed.limited" est incrémentée
|
||||
|
||||
Scénario: Mode nuit avec interface sombre automatique
|
||||
Étant donné un utilisateur "luke@roadwave.fr" en mode voiture
|
||||
Et il est 22h30 (nuit)
|
||||
Quand il utilise l'audio-guide
|
||||
Alors l'interface passe automatiquement en mode nuit:
|
||||
| Élément | Mode nuit |
|
||||
| Fond d'écran | Noir |
|
||||
| Texte | Blanc/Gris clair |
|
||||
| Carte | Thème sombre |
|
||||
| Luminosité | Réduite de 40% |
|
||||
Et les notifications visuelles sont encore plus discrètes
|
||||
Et un événement "NIGHT_MODE_AUTO_ENABLED" est enregistré
|
||||
Et la métrique "audio_guide.night_mode.enabled" est incrémentée
|
||||
|
||||
Scénario: Connexion automatique via Android Auto
|
||||
Étant donné un utilisateur "mary@roadwave.fr" avec téléphone Android
|
||||
Et son téléphone est connecté via Android Auto
|
||||
Quand elle lance l'audio-guide "Route des Châteaux de la Loire"
|
||||
Alors l'interface Android Auto s'affiche sur l'écran du véhicule
|
||||
Et les fonctionnalités sont identiques à CarPlay:
|
||||
| Fonctionnalité | Disponible |
|
||||
| Carte simplifiée | Oui |
|
||||
| Contrôles audio | Oui |
|
||||
| Commandes vocales | Oui (Google Assistant) |
|
||||
| Notifications | Oui |
|
||||
Et un événement "ANDROID_AUTO_SESSION_STARTED" est enregistré
|
||||
Et la métrique "audio_guide.android_auto.used" est incrémentée
|
||||
|
||||
Scénario: Gestion de la perte de signal GPS temporaire
|
||||
Étant donné un utilisateur "nathan@roadwave.fr" en mode voiture
|
||||
Et il écoute l'audio-guide dans un tunnel
|
||||
Quand le signal GPS est perdu pendant 2 minutes
|
||||
Alors l'audio en cours continue de jouer normalement
|
||||
Et la position estimée est calculée selon la vitesse et direction précédentes
|
||||
Et un message discret s'affiche: "Signal GPS perdu - Position estimée"
|
||||
Quand le signal GPS est retrouvé
|
||||
Alors la position est recalculée immédiatement
|
||||
Et les déclenchements automatiques sont réactivés
|
||||
Et un événement "GPS_SIGNAL_RESTORED" est enregistré
|
||||
Et la métrique "audio_guide.gps.signal_lost" est incrémentée
|
||||
|
||||
Scénario: Statistiques de fin de parcours en mode voiture
|
||||
Étant donné un utilisateur "olive@roadwave.fr" en mode voiture
|
||||
Et elle vient de terminer l'audio-guide "Route des Châteaux de la Loire"
|
||||
Quand elle arrive à destination
|
||||
Alors un écran de statistiques s'affiche:
|
||||
| Métrique | Valeur |
|
||||
| Séquences écoutées | 9/10 |
|
||||
| Séquences manquées | 1 (trop rapide) |
|
||||
| Distance parcourue | 142 km |
|
||||
| Temps total | 2h 15min |
|
||||
| Temps d'écoute | 1h 05min |
|
||||
| Vitesse moyenne | 63 km/h |
|
||||
| Badge débloqué | Voyageur des châteaux |
|
||||
Et un bouton "Partager mon voyage" est disponible
|
||||
Et un événement "AUDIO_GUIDE_COMPLETED_CAR" est enregistré
|
||||
Et la métrique "audio_guide.completed.car_mode" est incrémentée
|
||||
|
||||
Scénario: Métriques de performance du mode voiture
|
||||
Étant donné que 50 000 utilisateurs ont utilisé l'audio-guide en mode voiture
|
||||
Quand les métriques d'usage sont collectées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur cible |
|
||||
| Taux de déclenchement automatique | > 90% |
|
||||
| Taux de séquences manquées | < 15% |
|
||||
| Temps moyen entre déclenchements | 8 minutes |
|
||||
| Précision du calcul ETA | ±3 minutes |
|
||||
| Utilisation de CarPlay/Android Auto | 65% |
|
||||
| Utilisation de commandes vocales | 45% |
|
||||
Et les métriques sont exportées vers le système de monitoring
|
||||
239
features/api/audio-guides/detection-mode-deplacement.feature
Normal file
239
features/api/audio-guides/detection-mode-deplacement.feature
Normal file
@@ -0,0 +1,239 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @geolocation @mvp
|
||||
Fonctionnalité: Détection automatique du mode de déplacement
|
||||
|
||||
En tant qu'utilisateur
|
||||
Je veux que l'application détecte automatiquement mon mode de déplacement
|
||||
Afin d'adapter l'expérience audio-guide (voiture, piéton, vélo, transports)
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système utilise les capteurs suivants pour la détection:
|
||||
| Capteur | Utilisation |
|
||||
| GPS (vitesse) | Vitesse de déplacement |
|
||||
| Accéléromètre | Détection de la marche |
|
||||
| Gyroscope | Détection de mouvements |
|
||||
| Bluetooth | Connexion CarPlay/Android Auto |
|
||||
| Activité (CoreMotion) | walking, running, cycling, automotive |
|
||||
|
||||
Scénario: Détection automatique du mode voiture
|
||||
Étant donné un utilisateur "alice@roadwave.fr" en déplacement
|
||||
Quand le système détecte les indicateurs suivants:
|
||||
| Indicateur | Valeur |
|
||||
| Vitesse GPS | 45 km/h |
|
||||
| Accélération longitudinale | Typique d'une voiture|
|
||||
| Bluetooth connecté | CarPlay |
|
||||
| Activity Recognition | automotive |
|
||||
| Stabilité du mouvement | Haute |
|
||||
Alors le mode de déplacement "voiture" est sélectionné avec confiance: 95%
|
||||
Et l'interface passe en mode voiture:
|
||||
| Caractéristique | État |
|
||||
| Notifications visuelles | Minimales |
|
||||
| Notifications audio | Prioritaires |
|
||||
| Affichage des distances | Mètres + temps ETA |
|
||||
| Auto-play au point d'intérêt | Activé |
|
||||
Et un événement "TRAVEL_MODE_DETECTED_CAR" est enregistré
|
||||
Et la métrique "travel_mode.detected.car" est incrémentée
|
||||
|
||||
Scénario: Détection automatique du mode piéton
|
||||
Étant donné un utilisateur "bob@roadwave.fr" en déplacement
|
||||
Quand le système détecte les indicateurs suivants:
|
||||
| Indicateur | Valeur |
|
||||
| Vitesse GPS | 4 km/h |
|
||||
| Accéléromètre | Pattern de marche |
|
||||
| Fréquence de pas | 110 pas/min |
|
||||
| Activity Recognition | walking |
|
||||
| Bluetooth connecté | Non |
|
||||
Alors le mode de déplacement "piéton" est sélectionné avec confiance: 92%
|
||||
Et l'interface passe en mode piéton:
|
||||
| Caractéristique | État |
|
||||
| Notifications visuelles | Complètes |
|
||||
| Navigation libre | Activée |
|
||||
| Affichage carte | Complet |
|
||||
| Auto-play publicité | Autorisé |
|
||||
Et un événement "TRAVEL_MODE_DETECTED_WALKING" est enregistré
|
||||
Et la métrique "travel_mode.detected.walking" est incrémentée
|
||||
|
||||
Scénario: Détection automatique du mode vélo
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" en déplacement
|
||||
Quand le système détecte les indicateurs suivants:
|
||||
| Indicateur | Valeur |
|
||||
| Vitesse GPS | 18 km/h |
|
||||
| Accéléromètre | Vibrations régulières|
|
||||
| Pattern de mouvement | Cyclique |
|
||||
| Activity Recognition | cycling |
|
||||
| Variations de vitesse | Moyennes |
|
||||
Alors le mode de déplacement "vélo" est sélectionné avec confiance: 88%
|
||||
Et l'interface passe en mode vélo:
|
||||
| Caractéristique | État |
|
||||
| Notifications visuelles | Limitées |
|
||||
| Notifications audio | Prioritaires |
|
||||
| Affichage des distances | Mètres |
|
||||
| Auto-play au point d'intérêt | Optionnel |
|
||||
Et un événement "TRAVEL_MODE_DETECTED_CYCLING" est enregistré
|
||||
Et la métrique "travel_mode.detected.cycling" est incrémentée
|
||||
|
||||
Scénario: Détection automatique du mode transports en commun
|
||||
Étant donné un utilisateur "david@roadwave.fr" en déplacement
|
||||
Quand le système détecte les indicateurs suivants:
|
||||
| Indicateur | Valeur |
|
||||
| Vitesse GPS | 35 km/h avec arrêts |
|
||||
| Pattern d'arrêts | Régulier (stations) |
|
||||
| Accéléromètre | Stationnaire par moments|
|
||||
| Précision GPS | Variable (tunnels) |
|
||||
| Activity Recognition | automotive + stationary |
|
||||
Alors le mode de déplacement "transports" est sélectionné avec confiance: 80%
|
||||
Et l'interface passe en mode transports:
|
||||
| Caractéristique | État |
|
||||
| Notifications visuelles | Complètes |
|
||||
| Auto-play aux stations | Activé |
|
||||
| Affichage carte | Complet |
|
||||
| Prise en compte des tunnels | Activée |
|
||||
Et un événement "TRAVEL_MODE_DETECTED_TRANSIT" est enregistré
|
||||
Et la métrique "travel_mode.detected.transit" est incrémentée
|
||||
|
||||
Scénario: Changement dynamique de mode détecté (voiture → piéton)
|
||||
Étant donné un utilisateur "eve@roadwave.fr" en mode voiture
|
||||
Et il roule à 50 km/h
|
||||
Quand l'utilisateur se gare et sort de la voiture:
|
||||
| Temps | Vitesse | Activity | Bluetooth |
|
||||
| T+0s | 50 km/h | automotive | CarPlay |
|
||||
| T+30s | 0 km/h | stationary | CarPlay |
|
||||
| T+60s | 0 km/h | stationary | Déconnecté|
|
||||
| T+90s | 4 km/h | walking | Non |
|
||||
Alors le mode bascule automatiquement de "voiture" à "piéton"
|
||||
Et une notification discrète s'affiche: "Mode piéton activé"
|
||||
Et l'interface s'adapte instantanément au mode piéton
|
||||
Et un événement "TRAVEL_MODE_CHANGED" est enregistré avec transition: "car_to_walking"
|
||||
Et la métrique "travel_mode.transition.car_to_walking" est incrémentée
|
||||
|
||||
Scénario: Changement dynamique de mode détecté (piéton → vélo)
|
||||
Étant donné un utilisateur "frank@roadwave.fr" en mode piéton
|
||||
Et il marche à 4 km/h
|
||||
Quand l'utilisateur monte sur un vélo:
|
||||
| Temps | Vitesse | Activity | Pattern |
|
||||
| T+0s | 4 km/h | walking | Marche |
|
||||
| T+10s | 8 km/h | cycling | Cyclique |
|
||||
| T+20s | 15 km/h | cycling | Cyclique |
|
||||
| T+30s | 18 km/h | cycling | Cyclique stable|
|
||||
Alors le mode bascule automatiquement de "piéton" à "vélo"
|
||||
Et une notification s'affiche: "Mode vélo activé"
|
||||
Et les paramètres audio sont ajustés pour réduire les notifications visuelles
|
||||
Et un événement "TRAVEL_MODE_CHANGED" est enregistré avec transition: "walking_to_cycling"
|
||||
Et la métrique "travel_mode.transition.walking_to_cycling" est incrémentée
|
||||
|
||||
Scénario: Détection ambiguë avec faible confiance
|
||||
Étant donné un utilisateur "grace@roadwave.fr" en déplacement
|
||||
Quand le système détecte des indicateurs contradictoires:
|
||||
| Indicateur | Valeur |
|
||||
| Vitesse GPS | 12 km/h |
|
||||
| Activity Recognition | unknown |
|
||||
| Accéléromètre | Pattern irrégulier |
|
||||
| Confiance de détection | 45% |
|
||||
Alors le mode actuel est conservé (pas de changement)
|
||||
Et une icône d'interrogation s'affiche discrètement
|
||||
Et l'utilisateur peut forcer manuellement le mode via un menu rapide
|
||||
Et un événement "TRAVEL_MODE_UNCERTAIN" est enregistré
|
||||
Et la métrique "travel_mode.uncertain" est incrémentée
|
||||
|
||||
Scénario: Forçage manuel du mode de déplacement
|
||||
Étant donné un utilisateur "henry@roadwave.fr" en mode auto-détecté "piéton"
|
||||
Mais il est en réalité en voiture (passager)
|
||||
Quand l'utilisateur ouvre le menu rapide et sélectionne "Mode voiture"
|
||||
Alors le mode "voiture" est forcé manuellement
|
||||
Et l'auto-détection est temporairement désactivée pour 30 minutes
|
||||
Et un événement "TRAVEL_MODE_FORCED_MANUAL" est enregistré avec ancienMode: "walking", nouveauMode: "car"
|
||||
Et la métrique "travel_mode.manual_override" est incrémentée
|
||||
Et après 30 minutes, l'auto-détection se réactive automatiquement
|
||||
|
||||
Scénario: Mode stationnaire détecté (arrêt prolongé)
|
||||
Étant donné un utilisateur "iris@roadwave.fr" en mode voiture
|
||||
Et il est arrêté à un feu rouge depuis 2 minutes
|
||||
Quand le système détecte:
|
||||
| Indicateur | Valeur |
|
||||
| Vitesse GPS | 0 km/h |
|
||||
| Activity Recognition | stationary |
|
||||
| Durée d'immobilité | 120 secondes |
|
||||
| Bluetooth connecté | CarPlay |
|
||||
Alors le mode reste "voiture" (pas de changement)
|
||||
Mais un flag "stationary" est activé
|
||||
Et l'audio en cours continue de jouer normalement
|
||||
Et aucun nouveau contenu n'est déclenché automatiquement
|
||||
Et un événement "TRAVEL_MODE_STATIONARY" est enregistré
|
||||
Et la métrique "travel_mode.stationary" est incrémentée
|
||||
|
||||
Scénario: Reprise du mouvement après mode stationnaire
|
||||
Étant donné un utilisateur "jack@roadwave.fr" en mode "voiture stationary"
|
||||
Et il est arrêté depuis 3 minutes
|
||||
Quand le système détecte:
|
||||
| Temps | Vitesse | Activity |
|
||||
| T+0s | 0 km/h | stationary |
|
||||
| T+5s | 10 km/h | automotive |
|
||||
| T+10s | 30 km/h | automotive |
|
||||
Alors le flag "stationary" est désactivé
|
||||
Et le mode "voiture" normal est restauré
|
||||
Et la logique de déclenchement automatique des audio-guides est réactivée
|
||||
Et un événement "TRAVEL_MODE_RESUMED" est enregistré
|
||||
Et la métrique "travel_mode.resumed" est incrémentée
|
||||
|
||||
Scénario: Gestion des permissions de localisation et capteurs
|
||||
Étant donné un utilisateur "kate@roadwave.fr" qui lance l'application
|
||||
Quand les permissions suivantes sont refusées:
|
||||
| Permission | État |
|
||||
| Localisation GPS | Refusée |
|
||||
| Motion & Fitness | Refusée |
|
||||
Alors l'auto-détection du mode est désactivée
|
||||
Et un message s'affiche: "Pour bénéficier de l'expérience optimale, activez les permissions de localisation et mouvement"
|
||||
Et un bouton "Activer les permissions" redirige vers les Réglages
|
||||
Et l'utilisateur doit sélectionner manuellement son mode de déplacement
|
||||
Et un événement "TRAVEL_MODE_PERMISSIONS_DENIED" est enregistré
|
||||
Et la métrique "travel_mode.permissions_denied" est incrémentée
|
||||
|
||||
Scénario: Optimisation de la batterie avec détection adaptative
|
||||
Étant donné un utilisateur "luke@roadwave.fr" avec batterie < 20%
|
||||
Quand le mode économie d'énergie est activé
|
||||
Alors la fréquence de détection du mode est réduite:
|
||||
| Mode normal | Mode économie d'énergie |
|
||||
| Toutes les 5s | Toutes les 30s |
|
||||
Et l'utilisation du GPS est optimisée (requêtes moins fréquentes)
|
||||
Et l'accéléromètre et gyroscope sont consultés moins souvent
|
||||
Et la précision de détection peut être légèrement réduite
|
||||
Et un événement "TRAVEL_MODE_BATTERY_SAVER" est enregistré
|
||||
Et la métrique "travel_mode.battery_saver.enabled" est incrémentée
|
||||
|
||||
Scénario: Historique des modes de déplacement pour statistiques
|
||||
Étant donné un utilisateur "mary@roadwave.fr" qui utilise l'application depuis 1 mois
|
||||
Quand l'utilisateur accède à "Mon compte > Statistiques > Modes de déplacement"
|
||||
Alors l'utilisateur voit un graphique avec répartition:
|
||||
| Mode | Temps total | Pourcentage |
|
||||
| Voiture | 15h 30min | 45% |
|
||||
| Piéton | 12h 10min | 35% |
|
||||
| Vélo | 5h 20min | 15% |
|
||||
| Transports | 1h 40min | 5% |
|
||||
Et des insights sont affichés: "Vous utilisez principalement RoadWave en voiture"
|
||||
Et les données sont conservées de manière agrégée pour respecter le RGPD
|
||||
|
||||
Scénario: Métriques de performance de la détection
|
||||
Étant donné que le système traite 100 000 détections de mode par heure
|
||||
Quand les métriques de performance sont collectées
|
||||
Alors les indicateurs suivants sont respectés:
|
||||
| Métrique | Valeur cible |
|
||||
| Temps de détection du mode | < 100ms |
|
||||
| Précision de détection (voiture) | > 95% |
|
||||
| Précision de détection (piéton) | > 90% |
|
||||
| Précision de détection (vélo) | > 85% |
|
||||
| Taux de transitions incorrectes | < 5% |
|
||||
| Consommation batterie par détection | < 0.01% |
|
||||
Et les métriques sont exportées vers le système de monitoring
|
||||
Et des alertes sont déclenchées si la précision < 80%
|
||||
|
||||
Scénario: A/B testing des algorithmes de détection
|
||||
Étant donné que le système teste 2 algorithmes de détection:
|
||||
| Algorithme | Description |
|
||||
| A | Basé sur CoreMotion uniquement |
|
||||
| B | Combinaison capteurs + ML |
|
||||
Quand un utilisateur "nathan@roadwave.fr" est assigné au groupe B
|
||||
Alors l'algorithme B est utilisé pour la détection
|
||||
Et les métriques de précision sont tracées séparément par algorithme
|
||||
Et les événements incluent le tag "algorithm_version: B"
|
||||
Et après analyse, l'algorithme le plus performant est déployé à 100%
|
||||
191
features/api/audio-guides/gestion-point-manque.feature
Normal file
191
features/api/audio-guides/gestion-point-manque.feature
Normal file
@@ -0,0 +1,191 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @navigation @mvp
|
||||
Fonctionnalité: Gestion des points d'intérêt manqués
|
||||
|
||||
En tant qu'utilisateur
|
||||
Je veux pouvoir gérer les points d'intérêt que j'ai manqués
|
||||
Afin de compléter mon expérience audio-guide même après avoir dépassé certains points
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système de gestion des points manqués respecte:
|
||||
| Paramètre | Valeur |
|
||||
| Distance max pour considérer "manqué" | 1 km |
|
||||
| Temps max pour considérer "manqué" | 10 minutes |
|
||||
| Possibilité de retour arrière | Oui |
|
||||
| Lecture différée autorisée | Oui |
|
||||
|
||||
Scénario: Détection automatique d'un point manqué en mode voiture
|
||||
Étant donné un utilisateur "alice@roadwave.fr" en mode voiture à 90 km/h
|
||||
Et elle suit l'audio-guide "Route des Châteaux de la Loire"
|
||||
Et le prochain point d'intérêt est le Château de Chaumont
|
||||
Quand elle dépasse le château sans entrer dans son rayon de déclenchement (400m)
|
||||
Et elle s'éloigne à plus de 1 km du point
|
||||
Alors le système marque le point comme "Manqué"
|
||||
Et une notification discrète s'affiche: "Point manqué : Château de Chaumont"
|
||||
Et le point apparaît dans la section "Points manqués" de la liste
|
||||
Et un événement "POI_MARKED_AS_MISSED" est enregistré avec raison: "out_of_range"
|
||||
Et la métrique "poi.missed.out_of_range" est incrémentée
|
||||
|
||||
Scénario: Affichage de la liste des points manqués
|
||||
Étant donné un utilisateur "bob@roadwave.fr" qui a manqué 3 points sur 10
|
||||
Quand il ouvre la liste des séquences
|
||||
Alors il voit une section dédiée "Points manqués (3)":
|
||||
| Point d'intérêt | Distance actuelle | Actions |
|
||||
| Château de Chaumont | 15 km en arrière | [Écouter] [Y retourner] |
|
||||
| Musée de Cluny | 8 km en arrière | [Écouter] [Y retourner] |
|
||||
| Rue Mouffetard | 2 km en arrière | [Écouter] [Y retourner] |
|
||||
Et un compteur global affiche: "7/10 points visités"
|
||||
Et un événement "MISSED_POIS_LIST_VIEWED" est enregistré
|
||||
Et la métrique "missed_pois.list_viewed" est incrémentée
|
||||
|
||||
Scénario: Écoute différée d'un point manqué sans retour physique
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" qui a manqué le Château de Chaumont
|
||||
Et il est maintenant à 20 km du château
|
||||
Quand il clique sur "Écouter" dans la liste des points manqués
|
||||
Alors l'audio du Château de Chaumont démarre immédiatement
|
||||
Et un bandeau indique: "Écoute différée - Vous n'êtes pas sur place"
|
||||
Et le point reste marqué comme "Manqué mais écouté"
|
||||
Et un événement "MISSED_POI_LISTENED_REMOTE" est enregistré
|
||||
Et la métrique "missed_poi.listened.remote" est incrémentée
|
||||
|
||||
Scénario: Navigation de retour vers un point manqué
|
||||
Étant donné un utilisateur "david@roadwave.fr" qui a manqué le Musée de Cluny
|
||||
Et il est à 5 km du musée
|
||||
Quand il clique sur "Y retourner" dans la liste des points manqués
|
||||
Alors l'application lance la navigation GPS vers le Musée de Cluny
|
||||
Et un itinéraire est calculé et affiché
|
||||
Et l'ETA est affiché: "12 min en voiture"
|
||||
Et un événement "NAVIGATION_TO_MISSED_POI_STARTED" est enregistré
|
||||
Et la métrique "missed_poi.navigation_started" est incrémentée
|
||||
|
||||
Scénario: Retour physique et déclenchement automatique d'un point manqué
|
||||
Étant donné un utilisateur "eve@roadwave.fr" qui a manqué le Château de Chaumont
|
||||
Et elle a cliqué sur "Y retourner"
|
||||
Quand elle arrive dans le rayon de déclenchement du château (400m)
|
||||
Alors l'audio du château démarre automatiquement
|
||||
Et le point passe du statut "Manqué" à "Visité"
|
||||
Et une notification de succès s'affiche: "✓ Point complété : Château de Chaumont"
|
||||
Et un événement "MISSED_POI_COMPLETED" est enregistré
|
||||
Et la métrique "missed_poi.completed" est incrémentée
|
||||
|
||||
Scénario: Proposition automatique de retour pour points manqués à proximité
|
||||
Étant donné un utilisateur "frank@roadwave.fr" qui a manqué la Rue Mouffetard
|
||||
Et il continue son parcours et arrive près d'un autre point
|
||||
Quand le système détecte qu'il est à 800m de la Rue Mouffetard
|
||||
Alors une notification proactive s'affiche: "Point manqué à proximité : Rue Mouffetard (800m). Y aller ?"
|
||||
Et deux boutons sont proposés: [Oui, y aller] [Non, continuer]
|
||||
Et un événement "MISSED_POI_PROXIMITY_SUGGESTION" est enregistré
|
||||
Et la métrique "missed_poi.proximity_suggestion" est incrémentée
|
||||
|
||||
Scénario: Ignorance volontaire d'un point manqué
|
||||
Étant donné un utilisateur "grace@roadwave.fr" qui a manqué le Musée de Cluny
|
||||
Et elle ne souhaite pas y retourner
|
||||
Quand elle fait glisser le point vers la gauche dans la liste
|
||||
Et clique sur "Ignorer définitivement"
|
||||
Alors le point est retiré de la liste des points manqués
|
||||
Et il passe au statut "Ignoré"
|
||||
Et il ne sera plus proposé dans les suggestions
|
||||
Et un événement "MISSED_POI_IGNORED" est enregistré
|
||||
Et la métrique "missed_poi.ignored" est incrémentée
|
||||
|
||||
Scénario: Réinitialisation d'un point ignoré
|
||||
Étant donné un utilisateur "henry@roadwave.fr" qui a ignoré le Musée de Cluny
|
||||
Quand il accède aux paramètres de l'audio-guide
|
||||
Et clique sur "Voir les points ignorés (1)"
|
||||
Alors il voit la liste: "Musée de Cluny - Ignoré"
|
||||
Quand il clique sur "Réactiver"
|
||||
Alors le point repasse en statut "Manqué"
|
||||
Et il réapparaît dans la liste des points manqués
|
||||
Et un événement "MISSED_POI_REACTIVATED" est enregistré
|
||||
Et la métrique "missed_poi.reactivated" est incrémentée
|
||||
|
||||
Scénario: Marquage automatique comme manqué après délai en mode piéton
|
||||
Étant donné un utilisateur "iris@roadwave.fr" en mode piéton
|
||||
Et elle est à 150m du Panthéon depuis 15 minutes (stationnaire)
|
||||
Et elle n'a pas déclenché le point d'intérêt
|
||||
Quand elle reprend sa marche et s'éloigne à plus de 500m
|
||||
Alors le point est marqué comme "Manqué"
|
||||
Et une notification s'affiche: "Point manqué : Panthéon. Voulez-vous y retourner ?"
|
||||
Et un événement "POI_MARKED_AS_MISSED" est enregistré avec raison: "timeout_stationary"
|
||||
Et la métrique "poi.missed.timeout" est incrémentée
|
||||
|
||||
Scénario: Statistiques des points manqués en fin de parcours
|
||||
Étant donné un utilisateur "jack@roadwave.fr" qui a terminé un audio-guide
|
||||
Et il a visité 7 points sur 10, manqué 2 points et ignoré 1 point
|
||||
Quand il consulte l'écran de fin de parcours
|
||||
Alors il voit les statistiques:
|
||||
| Métrique | Valeur |
|
||||
| Points visités | 7/10 (70%) |
|
||||
| Points manqués | 2 (Chaumont, Cluny) |
|
||||
| Points ignorés | 1 (Rue Mouffetard) |
|
||||
| Taux de complétion | 70% |
|
||||
| Badge obtenu | Explorateur Bronze |
|
||||
Et un bouton "Compléter les points manqués" est proposé
|
||||
Et un événement "AUDIO_GUIDE_STATS_VIEWED" est enregistré
|
||||
|
||||
Scénario: Reprise d'un audio-guide pour compléter les points manqués
|
||||
Étant donné un utilisateur "kate@roadwave.fr" qui a terminé un audio-guide avec 2 points manqués
|
||||
Quand elle clique sur "Compléter les points manqués"
|
||||
Alors l'audio-guide est réactivé en mode "Rattrapage"
|
||||
Et seuls les 2 points manqués sont actifs sur la carte
|
||||
Et les points déjà visités sont grisés
|
||||
Et la navigation se concentre uniquement sur les points manqués
|
||||
Et un événement "AUDIO_GUIDE_CATCH_UP_MODE" est enregistré
|
||||
Et la métrique "audio_guide.catch_up.started" est incrémentée
|
||||
|
||||
Scénario: Badge de complétion "Perfectionniste" pour 100% de complétion
|
||||
Étant donné un utilisateur "luke@roadwave.fr" qui a visité 10/10 points
|
||||
Et il a initialement manqué 2 points mais y est retourné
|
||||
Quand il termine l'audio-guide avec 100% de complétion
|
||||
Alors un badge spécial "Perfectionniste" est débloqué
|
||||
Et une animation de célébration est affichée
|
||||
Et un événement "BADGE_PERFECTIONIST_UNLOCKED" est enregistré
|
||||
Et la métrique "badges.perfectionist.unlocked" est incrémentée
|
||||
|
||||
Scénario: Notification push après 24h pour rappel des points manqués
|
||||
Étant donné un utilisateur "mary@roadwave.fr" qui a terminé un audio-guide hier
|
||||
Et elle a manqué 3 points sur 10
|
||||
Quand 24 heures se sont écoulées depuis la fin du parcours
|
||||
Alors une notification push est envoyée:
|
||||
"Vous avez manqué 3 points lors de votre visite du Quartier Latin. Voulez-vous les découvrir ?"
|
||||
Et un lien direct vers la liste des points manqués est inclus
|
||||
Et un événement "MISSED_POIS_REMINDER_SENT" est enregistré
|
||||
Et la métrique "missed_pois.reminder_sent" est incrémentée
|
||||
|
||||
Scénario: Mode "Rattrapage intelligent" avec optimisation de l'itinéraire
|
||||
Étant donné un utilisateur "nathan@roadwave.fr" avec 3 points manqués:
|
||||
| Point | Position actuelle | Distance |
|
||||
| Château de Chaumont | 48.8475, 2.3450 | 12 km |
|
||||
| Musée de Cluny | 48.8505, 2.3434 | 8 km |
|
||||
| Rue Mouffetard | 48.8429, 2.3498 | 5 km |
|
||||
Quand il clique sur "Itinéraire optimisé pour rattrapage"
|
||||
Alors le système calcule l'itinéraire le plus court pour visiter les 3 points:
|
||||
| Ordre | Point | Distance cumulée |
|
||||
| 1 | Rue Mouffetard | 5 km |
|
||||
| 2 | Musée de Cluny | 8.5 km |
|
||||
| 3 | Château de Chaumont | 20.5 km |
|
||||
Et l'ETA total est affiché: "1h 15min en voiture"
|
||||
Et un événement "OPTIMIZED_CATCH_UP_ROUTE_CALCULATED" est enregistré
|
||||
Et la métrique "missed_pois.optimized_route" est incrémentée
|
||||
|
||||
Scénario: Désactivation de la détection automatique des points manqués
|
||||
Étant donné un utilisateur "olive@roadwave.fr" qui préfère une expérience libre
|
||||
Quand elle active l'option "Désactiver la détection des points manqués"
|
||||
Alors les points ne sont jamais marqués comme "Manqués"
|
||||
Et aucune notification de point manqué n'est affichée
|
||||
Et l'utilisateur peut toujours écouter tous les points manuellement
|
||||
Et un événement "MISSED_POIS_DETECTION_DISABLED" est enregistré
|
||||
Et la métrique "missed_pois.detection_disabled" est incrémentée
|
||||
|
||||
Scénario: Métriques de performance de la gestion des points manqués
|
||||
Étant donné que 10 000 utilisateurs ont terminé des audio-guides
|
||||
Quand les métriques sont collectées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur moyenne |
|
||||
| Pourcentage de points manqués par parcours| 18% |
|
||||
| Taux de retour aux points manqués | 35% |
|
||||
| Taux d'écoute différée (sans retour) | 55% |
|
||||
| Taux d'ignorance définitive | 10% |
|
||||
| Taux de complétion après rattrapage | 92% |
|
||||
Et les métriques sont exportées vers le système de monitoring
|
||||
@@ -0,0 +1,91 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @cycling @transit @mvp
|
||||
Fonctionnalité: Modes vélo et transports en commun complets
|
||||
|
||||
En tant qu'utilisateur à vélo ou en transports
|
||||
Je veux une expérience adaptée à mon mode de déplacement
|
||||
Afin de profiter des audio-guides en toute sécurité
|
||||
|
||||
Contexte:
|
||||
Étant donné les caractéristiques des modes:
|
||||
| Mode | Vitesse moyenne | Notifications | Auto-play |
|
||||
| Vélo | 15-20 km/h | Audio priority| Optionnel |
|
||||
| Transports | 30-40 km/h | Visuelles OK | Aux arrêts|
|
||||
|
||||
Scénario: Mode vélo avec notifications audio prioritaires
|
||||
Étant donné un utilisateur "alice@roadwave.fr" en mode vélo à 18 km/h
|
||||
Quand elle approche d'un point d'intérêt
|
||||
Alors une notification audio est jouée (sécurité)
|
||||
Et les notifications visuelles sont minimales
|
||||
Et l'auto-play est optionnel (configurable)
|
||||
Et un événement "CYCLING_MODE_POI_NOTIFICATION" est enregistré
|
||||
|
||||
Scénario: Mode transports avec détection des arrêts/stations
|
||||
Étant donné un utilisateur "bob@roadwave.fr" en mode transports
|
||||
Quand le système détecte un arrêt prolongé (station)
|
||||
Alors l'audio-guide peut se déclencher à la station
|
||||
Et les informations visuelles sont complètes
|
||||
Et un événement "TRANSIT_STOP_DETECTED" est enregistré
|
||||
|
||||
Scénario: Adaptation du rayon de déclenchement en mode vélo
|
||||
Étant donné un créateur "charlie@roadwave.fr" avec rayon adaptatif activé
|
||||
Quand un utilisateur en mode vélo approche du POI
|
||||
Alors le rayon est augmenté de 50% (anticipation)
|
||||
Et le déclenchement se fait plus tôt
|
||||
Et un événement "CYCLING_RADIUS_ADAPTED" est enregistré
|
||||
|
||||
Scénario: Gestion des tunnels en mode transports
|
||||
Étant donné un utilisateur "david@roadwave.fr" en métro
|
||||
Quand il entre dans un tunnel (perte GPS)
|
||||
Alors la position est estimée selon la ligne de métro
|
||||
Et les séquences continuent de se jouer normalement
|
||||
Et un événement "TRANSIT_TUNNEL_MODE" est enregistré
|
||||
|
||||
Scénario: Sécurité en mode vélo - pause automatique si danger
|
||||
Étant donné un utilisateur "eve@roadwave.fr" en mode vélo
|
||||
Quand une accélération brusque est détectée (freinage)
|
||||
Alors l'audio se met en pause automatiquement
|
||||
Et reprend quand la vitesse se stabilise
|
||||
Et un événement "CYCLING_SAFETY_PAUSE" est enregistré
|
||||
|
||||
Scénario: Mode transports avec synchronisation aux horaires
|
||||
Étant donné un utilisateur "frank@roadwave.fr" en bus
|
||||
Quand le système détecte les arrêts réguliers
|
||||
Alors les séquences sont synchronisées aux stations
|
||||
Et l'ETA est calculé selon les arrêts
|
||||
Et un événement "TRANSIT_SCHEDULE_SYNC" est enregistré
|
||||
|
||||
Scénario: Statistiques spécifiques au mode vélo
|
||||
Étant donné un utilisateur "grace@roadwave.fr" qui termine un audio-guide à vélo
|
||||
Alors il voit des statistiques adaptées:
|
||||
| Métrique | Valeur |
|
||||
| Distance parcourue | 12.5 km |
|
||||
| Temps de trajet | 45 min |
|
||||
| Vitesse moyenne | 16.7 km/h |
|
||||
| Dénivelé positif | 120m |
|
||||
Et un événement "CYCLING_STATS_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Détection automatique changement vélo → transports
|
||||
Étant donné un utilisateur "henry@roadwave.fr" en mode vélo
|
||||
Quand il monte dans un bus avec son vélo
|
||||
Alors le mode bascule automatiquement en "transports"
|
||||
Et l'expérience s'adapte instantanément
|
||||
Et un événement "MODE_SWITCH_CYCLING_TO_TRANSIT" est enregistré
|
||||
|
||||
Scénario: Mode vélo électrique avec détection
|
||||
Étant donné un utilisateur "iris@roadwave.fr" sur un vélo électrique
|
||||
Quand la vitesse moyenne est > 25 km/h (VAE)
|
||||
Alors le système adapte les rayons de déclenchement
|
||||
Et l'ETA est calculé avec vitesse VAE
|
||||
Et un événement "EBIKE_MODE_DETECTED" est enregistré
|
||||
|
||||
Scénario: Métriques de performance modes vélo et transports
|
||||
Étant donné que 10 000 parcours ont été effectués en vélo/transports
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Vélo | Transports |
|
||||
| Taux d'utilisation | 15% | 10% |
|
||||
| Taux de complétion | 82% | 75% |
|
||||
| Vitesse moyenne | 17km/h| 35km/h |
|
||||
| Satisfaction utilisateur | 4.3/5 | 4.1/5 |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
221
features/api/audio-guides/pieton-pub-autoplay.feature
Normal file
221
features/api/audio-guides/pieton-pub-autoplay.feature
Normal file
@@ -0,0 +1,221 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @advertising @pedestrian @mvp
|
||||
Fonctionnalité: Auto-play publicités en mode piéton uniquement
|
||||
|
||||
En tant qu'utilisateur piéton
|
||||
Je peux recevoir des publicités audio en auto-play à proximité de commerces
|
||||
Afin que les commerçants puissent promouvoir leurs offres de manière contextualisée
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système de publicité respecte les règles suivantes:
|
||||
| Règle | Valeur |
|
||||
| Auto-play autorisé uniquement en mode | Piéton |
|
||||
| Durée max d'une publicité | 30 secondes |
|
||||
| Fréquence max par commerce | 1 par jour |
|
||||
| Distance min entre 2 pubs différentes | 200 mètres |
|
||||
| Nombre max de pubs par heure | 3 |
|
||||
| Possibilité de skip après | 5 secondes |
|
||||
|
||||
Scénario: Déclenchement automatique d'une publicité en mode piéton
|
||||
Étant donné un utilisateur "alice@roadwave.fr" en mode piéton
|
||||
Et elle marche dans la rue avec l'application active
|
||||
Quand elle passe à 30 mètres du café "Le Parisien" avec publicité active
|
||||
Alors la publicité audio "Café Le Parisien - 10% de réduction" démarre automatiquement
|
||||
Et une notification visuelle s'affiche:
|
||||
| Élément | Contenu |
|
||||
| Icône | Logo du café |
|
||||
| Titre | Publicité - Le Parisien |
|
||||
| Distance | À 30m de vous |
|
||||
| Action | [Passer] disponible après 5s |
|
||||
| Durée | 0:25 |
|
||||
Et l'audio en cours (si existant) est mis en pause
|
||||
Et un événement "AD_AUTOPLAY_TRIGGERED" est enregistré
|
||||
Et la métrique "ads.autoplay.triggered" est incrémentée
|
||||
|
||||
Scénario: Aucun auto-play en mode voiture
|
||||
Étant donné un utilisateur "bob@roadwave.fr" en mode voiture
|
||||
Et il roule à 40 km/h avec l'application active
|
||||
Quand il passe à 30 mètres d'un commerce avec publicité active
|
||||
Alors aucune publicité n'est déclenchée automatiquement
|
||||
Et la publicité peut être affichée dans la liste "Publicités à proximité"
|
||||
Et l'utilisateur peut choisir manuellement de l'écouter
|
||||
Et un événement "AD_SKIPPED_CAR_MODE" est enregistré
|
||||
Et la métrique "ads.skipped.car_mode" est incrémentée
|
||||
|
||||
Scénario: Aucun auto-play en mode vélo
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" en mode vélo
|
||||
Et il roule à 15 km/h avec l'application active
|
||||
Quand il passe à 30 mètres d'un commerce avec publicité active
|
||||
Alors aucune publicité n'est déclenchée automatiquement
|
||||
Et la sécurité de l'utilisateur à vélo est préservée
|
||||
Et un événement "AD_SKIPPED_CYCLING_MODE" est enregistré
|
||||
Et la métrique "ads.skipped.cycling_mode" est incrémentée
|
||||
|
||||
Scénario: Skip d'une publicité après 5 secondes
|
||||
Étant donné un utilisateur "david@roadwave.fr" en mode piéton
|
||||
Et une publicité a démarré automatiquement il y a 6 secondes
|
||||
Quand l'utilisateur clique sur le bouton "Passer"
|
||||
Alors la publicité s'arrête immédiatement
|
||||
Et l'audio en cours précédent reprend (si existant)
|
||||
Et un événement "AD_SKIPPED_BY_USER" est enregistré avec temps_ecoute: 6s
|
||||
Et la métrique "ads.skipped.by_user" est incrémentée
|
||||
Et le commerçant est facturé pour 6 secondes d'écoute seulement
|
||||
|
||||
Scénario: Bouton "Passer" désactivé pendant les 5 premières secondes
|
||||
Étant donné un utilisateur "eve@roadwave.fr" en mode piéton
|
||||
Et une publicité vient de démarrer
|
||||
Quand l'utilisateur clique sur le bouton "Passer" à T+2 secondes
|
||||
Alors le bouton est grisé et non cliquable
|
||||
Et un message s'affiche: "Disponible dans 3 secondes"
|
||||
Et un compteur à rebours est visible: 3... 2... 1...
|
||||
Alors à T+5 secondes, le bouton devient actif
|
||||
Et un événement "AD_SKIP_ATTEMPTED_TOO_EARLY" est enregistré
|
||||
Et la métrique "ads.skip.too_early" est incrémentée
|
||||
|
||||
Scénario: Publicité écoutée en entier
|
||||
Étant donné un utilisateur "frank@roadwave.fr" en mode piéton
|
||||
Et une publicité de 25 secondes a démarré automatiquement
|
||||
Quand l'utilisateur écoute la publicité jusqu'à la fin sans cliquer sur "Passer"
|
||||
Alors la publicité se termine naturellement
|
||||
Et l'audio en cours précédent reprend automatiquement
|
||||
Et un événement "AD_COMPLETED" est enregistré avec temps_ecoute: 25s
|
||||
Et la métrique "ads.completed" est incrémentée
|
||||
Et le commerçant est facturé pour la publicité complète (tarif plein)
|
||||
|
||||
Scénario: Limitation à 3 publicités par heure
|
||||
Étant donné un utilisateur "grace@roadwave.fr" en mode piéton
|
||||
Et elle a déjà écouté 3 publicités dans la dernière heure:
|
||||
| Commerce | Temps écoulé |
|
||||
| Café Le Parisien | Il y a 10min |
|
||||
| Boulangerie Paul | Il y a 30min |
|
||||
| Restaurant Tokyo | Il y a 50min |
|
||||
Quand elle passe à 30 mètres d'un 4ème commerce avec publicité
|
||||
Alors aucune publicité n'est déclenchée automatiquement
|
||||
Et un compteur s'affiche discrètement: "Prochaine pub disponible dans 10 min"
|
||||
Et un événement "AD_RATE_LIMITED" est enregistré
|
||||
Et la métrique "ads.rate_limited" est incrémentée
|
||||
|
||||
Scénario: Limitation à 1 publicité par commerce par jour
|
||||
Étant donné un utilisateur "henry@roadwave.fr" en mode piéton
|
||||
Et il a déjà écouté la publicité du "Café Le Parisien" ce matin à 10h
|
||||
Quand il repasse devant le même café à 16h
|
||||
Alors aucune publicité n'est déclenchée automatiquement
|
||||
Et le café n'apparaît pas dans la liste "Publicités à proximité"
|
||||
Et un événement "AD_ALREADY_SHOWN_TODAY" est enregistré
|
||||
Et la métrique "ads.deduplication.same_day" est incrémentée
|
||||
|
||||
Scénario: Distance minimale de 200m entre 2 publicités différentes
|
||||
Étant donné un utilisateur "iris@roadwave.fr" en mode piéton
|
||||
Et elle vient d'écouter une publicité du "Café Le Parisien" il y a 1 minute
|
||||
Quand elle marche et passe à 50 mètres de la "Boulangerie Paul" (150m du café)
|
||||
Alors aucune publicité n'est déclenchée automatiquement
|
||||
Et un événement "AD_TOO_CLOSE_TO_PREVIOUS" est enregistré
|
||||
Et la métrique "ads.skipped.too_close" est incrémentée
|
||||
Quand elle continue et passe à 250 mètres de la "Librairie Gibert" (250m du café)
|
||||
Alors la publicité de la librairie peut être déclenchée
|
||||
|
||||
Scénario: Désactivation complète des publicités (utilisateur Premium)
|
||||
Étant donné un utilisateur "jack@roadwave.fr" Premium en mode piéton
|
||||
Et il a désactivé les publicités dans ses paramètres
|
||||
Quand il passe à 30 mètres de commerces avec publicités actives
|
||||
Alors aucune publicité n'est jamais déclenchée
|
||||
Et aucune publicité n'apparaît dans la liste "Publicités à proximité"
|
||||
Et un événement "AD_BLOCKED_PREMIUM" est enregistré
|
||||
Et la métrique "ads.blocked.premium" est incrémentée
|
||||
|
||||
Scénario: Mise en pause de l'audio en cours lors du déclenchement d'une pub
|
||||
Étant donné un utilisateur "kate@roadwave.fr" en mode piéton
|
||||
Et elle écoute un podcast "Histoire de Paris" à la position 12min 30s
|
||||
Quand une publicité se déclenche automatiquement
|
||||
Alors le podcast est mis en pause immédiatement
|
||||
Et la position de lecture est sauvegardée: 12min 30s
|
||||
Et la publicité démarre
|
||||
Quand la publicité se termine (skip ou écoute complète)
|
||||
Alors le podcast reprend automatiquement à la position 12min 30s
|
||||
Et un événement "AD_CONTENT_PAUSED_RESUMED" est enregistré
|
||||
Et la métrique "ads.content.paused_resumed" est incrémentée
|
||||
|
||||
Scénario: Ciblage géographique précis de la publicité
|
||||
Étant donné un commerçant "Le Parisien" avec publicité active
|
||||
Et il a configuré un rayon de déclenchement de 50 mètres
|
||||
Et un utilisateur "luke@roadwave.fr" en mode piéton
|
||||
Quand l'utilisateur est à 60 mètres du commerce
|
||||
Alors aucune publicité n'est déclenchée
|
||||
Quand l'utilisateur marche et arrive à 45 mètres du commerce
|
||||
Alors la publicité se déclenche automatiquement
|
||||
Et un événement "AD_GEO_TRIGGERED" est enregistré avec distance: 45m
|
||||
Et la métrique "ads.geo.triggered" est incrémentée
|
||||
|
||||
Scénario: Publicité contextuelle basée sur les intérêts de l'utilisateur
|
||||
Étant donné un utilisateur "mary@roadwave.fr" en mode piéton
|
||||
Et ses jauges d'intérêts sont:
|
||||
| Catégorie | Niveau |
|
||||
| Gastronomie | 85% |
|
||||
| Culture | 60% |
|
||||
| Sport | 20% |
|
||||
Et deux commerces ont des publicités actives à proximité:
|
||||
| Commerce | Catégorie | Distance |
|
||||
| Restaurant Le Gourmet | Gastronomie | 40m |
|
||||
| Salle de sport FitClub| Sport | 35m |
|
||||
Quand l'utilisateur passe à proximité des deux commerces
|
||||
Alors la publicité du restaurant est priorisée et déclenchée
|
||||
Et la publicité de la salle de sport est ignorée (faible intérêt)
|
||||
Et un événement "AD_INTEREST_MATCHED" est enregistré avec categorie: "gastronomie", score: 85
|
||||
Et la métrique "ads.interest_matching.applied" est incrémentée
|
||||
|
||||
Scénario: Affichage d'informations complémentaires pendant la publicité
|
||||
Étant donné un utilisateur "nathan@roadwave.fr" en mode piéton
|
||||
Et une publicité du "Café Le Parisien" est en cours de lecture
|
||||
Quand l'utilisateur consulte l'écran
|
||||
Alors il voit les informations suivantes:
|
||||
| Élément | Contenu |
|
||||
| Logo du commerce | [Image] |
|
||||
| Nom du commerce | Café Le Parisien |
|
||||
| Type d'établissement | Café-Brasserie |
|
||||
| Distance | À 30m de vous |
|
||||
| Itinéraire | [Bouton "Y aller"] |
|
||||
| Offre spéciale | 10% de réduction avec ce code: ROADWAVE10|
|
||||
| Horaires | Ouvert maintenant - Ferme à 22h |
|
||||
| Note | 4.5/5 (230 avis) |
|
||||
Et l'utilisateur peut cliquer sur "Y aller" pour lancer la navigation
|
||||
Et un événement "AD_INFO_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Tracking de la conversion (visite effective du commerce)
|
||||
Étant donné un utilisateur "olive@roadwave.fr" en mode piéton
|
||||
Et elle a écouté la publicité du "Café Le Parisien" il y a 5 minutes
|
||||
Quand elle clique sur "Y aller" et se rend au café
|
||||
Et entre dans un rayon de 10 mètres du café
|
||||
Alors un événement "AD_CONVERSION_VISIT" est enregistré
|
||||
Et la métrique "ads.conversions.visits" est incrémentée
|
||||
Et le commerçant voit cette conversion dans ses statistiques
|
||||
Et une notification discrète s'affiche: "Profitez de votre réduction avec le code ROADWAVE10"
|
||||
|
||||
Scénario: Métriques de performance des publicités pour les commerçants
|
||||
Étant donné un commerçant "Le Parisien" avec publicité active depuis 7 jours
|
||||
Quand le commerçant consulte ses statistiques
|
||||
Alors il voit les métriques suivantes:
|
||||
| Métrique | Valeur |
|
||||
| Nombre d'impressions (déclenchements)| 450 |
|
||||
| Taux d'écoute complète | 35% |
|
||||
| Taux de skip moyen | 65% |
|
||||
| Durée moyenne d'écoute | 12s |
|
||||
| Nombre de clics "Y aller" | 25 |
|
||||
| Nombre de visites confirmées | 18 |
|
||||
| Taux de conversion | 4% |
|
||||
| Coût total | 45€ |
|
||||
| Coût par visite | 2.50€ |
|
||||
Et les métriques sont mises à jour en temps réel
|
||||
|
||||
Scénario: A/B testing des publicités pour optimisation
|
||||
Étant donné un commerçant "Le Parisien" avec 2 versions de publicité:
|
||||
| Version | Description | Durée |
|
||||
| A | Voix masculine, tonalité formelle | 25s |
|
||||
| B | Voix féminine, tonalité décontractée | 25s |
|
||||
Quand le système diffuse aléatoirement les 2 versions (50/50)
|
||||
Alors les métriques sont collectées séparément:
|
||||
| Métrique | Version A | Version B |
|
||||
| Taux d'écoute complète | 32% | 42% |
|
||||
| Taux de conversion | 3.5% | 5.2% |
|
||||
Et le commerçant peut choisir de diffuser uniquement la version B
|
||||
Et un événement "AD_AB_TEST_COMPLETED" est enregistré
|
||||
111
features/api/audio-guides/publicites-complet.feature
Normal file
111
features/api/audio-guides/publicites-complet.feature
Normal file
@@ -0,0 +1,111 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @advertising @mvp
|
||||
Fonctionnalité: Système de publicités complet
|
||||
|
||||
En tant que plateforme
|
||||
Je veux gérer un système publicitaire équilibré et non intrusif
|
||||
Afin de monétiser la plateforme tout en préservant l'expérience utilisateur
|
||||
|
||||
Contexte:
|
||||
Étant donné les règles publicitaires:
|
||||
| Règle | Valeur |
|
||||
| Durée max publicité | 30s |
|
||||
| Fréquence max par heure | 3 |
|
||||
| Skip autorisé après | 5s |
|
||||
| Mode auto-play | Piéton only |
|
||||
| Premium sans pub | Oui |
|
||||
|
||||
Scénario: Insertion intelligente de publicité entre séquences
|
||||
Étant donné un utilisateur "alice@roadwave.fr" Free en mode piéton
|
||||
Quand elle termine l'écoute d'une séquence
|
||||
Et marche vers la suivante (temps de trajet: 5 min)
|
||||
Alors une publicité peut être insérée pendant le trajet
|
||||
Et elle ne coupe jamais une séquence en cours
|
||||
Et un événement "AD_INSERTED_BETWEEN_SEQUENCES" est enregistré
|
||||
|
||||
Scénario: Ciblage géographique et contextuel des publicités
|
||||
Étant donné un utilisateur "bob@roadwave.fr" près de restaurants
|
||||
Et ses intérêts incluent "Gastronomie" à 80%
|
||||
Quand une publicité doit être affichée
|
||||
Alors le système priorise les restaurants à proximité
|
||||
Et match les intérêts de l'utilisateur
|
||||
Et un événement "AD_TARGETED" est enregistré avec score_match: 95
|
||||
|
||||
Scénario: Format publicitaire audio + visuel
|
||||
Étant donné une publicité pour le "Café Le Parisien"
|
||||
Quand elle est diffusée
|
||||
Alors l'audio est joué (max 30s)
|
||||
Et une carte visuelle s'affiche avec:
|
||||
| Élément | Contenu |
|
||||
| Logo | Image du commerce |
|
||||
| Offre spéciale | -10% avec code ROAD10 |
|
||||
| Distance | À 50m |
|
||||
| Bouton CTA | [Y aller] [Sauvegarder]|
|
||||
Et un événement "AD_DISPLAYED_FULL" est enregistré
|
||||
|
||||
Scénario: Facturation au CPM et CPC pour annonceurs
|
||||
Étant donné un commerce "Le Parisien" avec budget pub
|
||||
Quand sa publicité est diffusée 1000 fois (impressions)
|
||||
Alors il est facturé selon le modèle CPM: 5€ pour 1000 impressions
|
||||
Quand 50 utilisateurs cliquent sur "Y aller"
|
||||
Alors il est facturé selon le CPC: 0.50€ par clic
|
||||
Et un événement "AD_BILLING_CALCULATED" est enregistré
|
||||
|
||||
Scénario: Dashboard annonceur avec statistiques détaillées
|
||||
Étant donné un annonceur "Restaurant Tokyo" connecté
|
||||
Quand il consulte son dashboard
|
||||
Alors il voit les métriques en temps réel:
|
||||
| Métrique | Valeur |
|
||||
| Impressions (7 jours) | 2 450 |
|
||||
| Taux d'écoute complète | 38% |
|
||||
| Clics "Y aller" | 125 |
|
||||
| Visites confirmées | 45 |
|
||||
| Taux de conversion | 1.8% |
|
||||
| Budget dépensé | 42.50€ |
|
||||
| Coût par visite | 0.94€ |
|
||||
Et un événement "AD_DASHBOARD_VIEWED" est enregistré
|
||||
|
||||
Scénario: A/B testing automatisé des créatives publicitaires
|
||||
Étant donné un annonceur avec 3 versions de publicité
|
||||
Quand le système diffuse les pubs
|
||||
Alors chaque version est diffusée à 33% du trafic
|
||||
Et les performances sont comparées après 1000 impressions
|
||||
Et la meilleure version est automatiquement privilégiée
|
||||
Et un événement "AD_AB_TEST_WINNER_SELECTED" est enregistré
|
||||
|
||||
Scénario: Limite de fréquence stricte pour éviter la saturation
|
||||
Étant donné un utilisateur "charlie@roadwave.fr"
|
||||
Et il a déjà entendu 3 pubs dans la dernière heure
|
||||
Quand le système tente d'insérer une 4ème pub
|
||||
Alors elle est bloquée
|
||||
Et l'utilisateur voit: "Prochaine pub dans 25 min"
|
||||
Et un événement "AD_FREQUENCY_CAP_REACHED" est enregistré
|
||||
|
||||
Scénario: Publicités Premium sponsorisées prioritaires
|
||||
Étant donné un annonceur "Musée du Louvre" avec campagne premium
|
||||
Quand un utilisateur passe à proximité
|
||||
Alors sa publicité est priorisée sur les autres
|
||||
Et elle a un format étendu (45s autorisées)
|
||||
Et un badge "Partenaire officiel" s'affiche
|
||||
Et un événement "AD_PREMIUM_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Sauvegarde d'offres publicitaires pour utilisation ultérieure
|
||||
Étant donné un utilisateur "david@roadwave.fr" qui entend une pub
|
||||
Quand il clique sur "Sauvegarder l'offre"
|
||||
Alors l'offre est ajoutée à "Mes offres sauvegardées"
|
||||
Et il peut la consulter plus tard
|
||||
Et la validité de l'offre est affichée: "Valable jusqu'au 31/03"
|
||||
Et un événement "AD_OFFER_SAVED" est enregistré
|
||||
|
||||
Scénario: Métriques de performance du système publicitaire
|
||||
Étant donné que 100 000 pubs ont été diffusées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Taux de skip moyen | 62% |
|
||||
| Taux d'écoute complète | 38% |
|
||||
| CTR (Click-Through Rate) | 5.2% |
|
||||
| Taux de conversion (visites) | 3.1% |
|
||||
| Revenu moyen par utilisateur | 2.40€/an |
|
||||
| Satisfaction utilisateurs | 3.8/5 |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
123
features/api/audio-guides/rayon-configurable-createur.feature
Normal file
123
features/api/audio-guides/rayon-configurable-createur.feature
Normal file
@@ -0,0 +1,123 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @content-creation @mvp
|
||||
Fonctionnalité: Rayon de déclenchement configurable par le créateur
|
||||
|
||||
En tant que créateur de contenu
|
||||
Je veux configurer le rayon de déclenchement de chaque point d'intérêt
|
||||
Afin d'adapter l'expérience selon le type de lieu et le contexte
|
||||
|
||||
Contexte:
|
||||
Étant donné que les rayons configurables respectent:
|
||||
| Paramètre | Valeur |
|
||||
| Rayon minimum | 10 mètres |
|
||||
| Rayon maximum | 500 mètres |
|
||||
| Rayon par défaut | 100 mètres |
|
||||
| Ajustement | Par pas de 10m |
|
||||
|
||||
Scénario: Configuration du rayon lors de la création d'une séquence
|
||||
Étant donné un créateur "alice@roadwave.fr" qui ajoute un point d'intérêt
|
||||
Quand elle place un marqueur pour "Cathédrale Notre-Dame"
|
||||
Alors un slider de rayon s'affiche avec:
|
||||
| Élément | Valeur |
|
||||
| Rayon actuel | 100m (défaut) |
|
||||
| Rayon minimum | 10m |
|
||||
| Rayon maximum | 500m |
|
||||
| Visualisation | Cercle sur la carte |
|
||||
Et elle peut ajuster le rayon à 150m
|
||||
Alors le cercle sur la carte s'agrandit à 150m de rayon
|
||||
Et un événement "POI_RADIUS_CONFIGURED" est enregistré avec rayon: 150
|
||||
Et la métrique "poi.radius.configured" est incrémentée
|
||||
|
||||
Scénario: Rayon petit pour monuments précis (10-50m)
|
||||
Étant donné un créateur "bob@roadwave.fr" qui crée un audio-guide urbain
|
||||
Quand il configure un point pour une statue spécifique
|
||||
Et définit le rayon à 20m
|
||||
Alors le déclenchement sera très précis (proximité immédiate)
|
||||
Et le système valide que le rayon est suffisant
|
||||
Et un événement "POI_RADIUS_SMALL" est enregistré
|
||||
Et la métrique "poi.radius.small" est incrémentée
|
||||
|
||||
Scénario: Rayon large pour zones étendues (200-500m)
|
||||
Étant donné un créateur "charlie@roadwave.fr" qui crée un audio-guide de parc
|
||||
Quand il configure un point pour "Jardin du Luxembourg"
|
||||
Et définit le rayon à 300m
|
||||
Alors le déclenchement sera anticipé (approche du parc)
|
||||
Et le système valide que le rayon n'est pas excessif
|
||||
Et un événement "POI_RADIUS_LARGE" est enregistré
|
||||
Et la métrique "poi.radius.large" est incrémentée
|
||||
|
||||
Scénario: Visualisation en temps réel du rayon sur la carte
|
||||
Étant donné un créateur "david@roadwave.fr" qui ajuste un rayon
|
||||
Quand il déplace le slider de 100m à 250m
|
||||
Alors le cercle sur la carte s'agrandit en temps réel
|
||||
Et la zone de déclenchement est colorée en semi-transparent
|
||||
Et le rayon en mètres est affiché sur la carte
|
||||
Et un événement "POI_RADIUS_VISUALIZED" est enregistré
|
||||
|
||||
Scénario: Suggestions de rayon basées sur le type de lieu
|
||||
Étant donné un créateur "eve@roadwave.fr" qui ajoute un POI
|
||||
Quand elle sélectionne le type "Monument"
|
||||
Alors le système suggère un rayon de 50m
|
||||
Quand elle sélectionne le type "Parc/Jardin"
|
||||
Alors le système suggère un rayon de 200m
|
||||
Quand elle sélectionne le type "Vue panoramique"
|
||||
Alors le système suggère un rayon de 100m
|
||||
Et un événement "POI_RADIUS_SUGGESTED" est enregistré
|
||||
|
||||
Scénario: Test de simulation du déclenchement
|
||||
Étant donné un créateur "frank@roadwave.fr" qui configure un rayon de 150m
|
||||
Quand il clique sur "Tester le déclenchement"
|
||||
Alors une simulation GPS démarre
|
||||
Et il peut voir à quelle distance le point se déclencherait
|
||||
Et ajuster le rayon si nécessaire
|
||||
Et un événement "POI_RADIUS_TESTED" est enregistré
|
||||
|
||||
Scénario: Modification du rayon après publication
|
||||
Étant donné un créateur "grace@roadwave.fr" avec audio-guide publié
|
||||
Et elle constate que le rayon de 50m est trop petit (retours utilisateurs)
|
||||
Quand elle modifie le rayon à 120m
|
||||
Alors la modification prend effet immédiatement
|
||||
Et tous les futurs déclenchements utilisent le nouveau rayon
|
||||
Et un événement "POI_RADIUS_UPDATED" est enregistré
|
||||
|
||||
Scénario: Détection de chevauchements entre rayons
|
||||
Étant donné un créateur "henry@roadwave.fr" avec 2 points proches
|
||||
Quand les cercles de rayon se chevauchent à plus de 50%
|
||||
Alors un avertissement s'affiche: "Attention: chevauchement détecté"
|
||||
Et une suggestion est proposée: "Réduire les rayons ou espacer les points"
|
||||
Et un événement "POI_RADIUS_OVERLAP_DETECTED" est enregistré
|
||||
|
||||
Scénario: Rayons adaptatifs selon le mode de déplacement
|
||||
Étant donné un créateur "iris@roadwave.fr" qui configure un point
|
||||
Quand elle active "Rayons adaptatifs"
|
||||
Alors le système configure automatiquement:
|
||||
| Mode | Rayon suggéré |
|
||||
| Piéton | 80m |
|
||||
| Vélo | 120m |
|
||||
| Voiture | 300m |
|
||||
Et les utilisateurs bénéficient du rayon optimal selon leur mode
|
||||
Et un événement "POI_RADIUS_ADAPTIVE" est enregistré
|
||||
|
||||
Scénario: Statistiques d'efficacité des rayons
|
||||
Étant donné un créateur "jack@roadwave.fr" avec audio-guide publié
|
||||
Quand il consulte les statistiques de ses POI
|
||||
Alors il voit pour chaque point:
|
||||
| Point | Rayon | Taux déclenchement | Taux manqué |
|
||||
| Notre-Dame | 100m | 95% | 5% |
|
||||
| Sainte-Chapelle| 50m | 78% | 22% |
|
||||
| Panthéon | 150m | 98% | 2% |
|
||||
Et des suggestions d'optimisation sont proposées
|
||||
Et un événement "POI_RADIUS_STATS_VIEWED" est enregistré
|
||||
|
||||
Scénario: Métriques de performance des rayons configurés
|
||||
Étant donné que 5000 POI ont été configurés
|
||||
Quand les métriques sont collectées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur moyenne |
|
||||
| Rayon moyen configuré | 125m |
|
||||
| Rayon le plus petit utilisé | 15m |
|
||||
| Rayon le plus grand utilisé | 450m |
|
||||
| Taux d'ajustement après tests | 35% |
|
||||
| Taux de déclenchement réussi | 88% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
103
features/api/audio-guides/reprise-progression-complet.feature
Normal file
103
features/api/audio-guides/reprise-progression-complet.feature
Normal file
@@ -0,0 +1,103 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @progression @mvp
|
||||
Fonctionnalité: Reprise de progression complète
|
||||
|
||||
En tant qu'utilisateur
|
||||
Je veux reprendre un audio-guide là où je l'ai laissé
|
||||
Afin de continuer mon expérience sans perdre ma progression
|
||||
|
||||
Contexte:
|
||||
Étant donné que la sauvegarde de progression inclut:
|
||||
| Donnée | Persistance |
|
||||
| Séquences écoutées | Permanente |
|
||||
| Position dans l'audio | 7 jours |
|
||||
| Points manqués | Permanente |
|
||||
| Progression globale | Permanente |
|
||||
|
||||
Scénario: Sauvegarde automatique de la progression
|
||||
Étant donné un utilisateur "alice@roadwave.fr" qui écoute une séquence
|
||||
Quand elle ferme l'application à 3min 20s
|
||||
Alors la progression est sauvegardée automatiquement
|
||||
Et la position exacte dans l'audio est conservée
|
||||
Et un événement "PROGRESS_AUTO_SAVED" est enregistré
|
||||
|
||||
Scénario: Reprise après fermeture de l'application
|
||||
Étant donné un utilisateur "bob@roadwave.fr" qui rouvre l'application
|
||||
Et il avait un audio-guide en cours (5/10 séquences)
|
||||
Quand il accède à l'écran d'accueil
|
||||
Alors une carte "Reprendre votre visite" s'affiche:
|
||||
| Élément | Contenu |
|
||||
| Titre audio-guide | Visite du Quartier Latin |
|
||||
| Progression | 5/10 séquences (50%) |
|
||||
| Dernière position | Panthéon - 3min 20s |
|
||||
| Bouton | [Reprendre] |
|
||||
Et un événement "RESUME_CARD_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Reprise exacte de la position audio
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" qui reprend un audio-guide
|
||||
Et il était à 3min 20s dans la séquence "Panthéon"
|
||||
Quand il clique sur "Reprendre"
|
||||
Alors l'audio reprend exactement à 3min 20s
|
||||
Et aucune seconde n'est perdue
|
||||
Et un événement "AUDIO_POSITION_RESTORED" est enregistré
|
||||
|
||||
Scénario: Synchronisation multi-appareils de la progression
|
||||
Étant donné un utilisateur "david@roadwave.fr" qui écoute sur iPhone
|
||||
Et il a complété 3 séquences
|
||||
Quand il passe sur son iPad
|
||||
Alors la progression est synchronisée automatiquement
|
||||
Et il peut reprendre là où il s'était arrêté
|
||||
Et un événement "PROGRESS_SYNCED_CROSS_DEVICE" est enregistré
|
||||
|
||||
Scénario: Historique des audio-guides en cours
|
||||
Étant donné un utilisateur "eve@roadwave.fr" avec 3 audio-guides en cours
|
||||
Quand elle accède à "Mes audio-guides en cours"
|
||||
Alors elle voit la liste:
|
||||
| Audio-guide | Progression | Dernière activité |
|
||||
| Quartier Latin | 5/10 (50%) | Il y a 2 heures |
|
||||
| Châteaux de la Loire | 3/8 (37%) | Il y a 3 jours |
|
||||
| Montmartre | 1/6 (16%) | Il y a 1 semaine |
|
||||
Et elle peut reprendre n'importe lequel
|
||||
Et un événement "IN_PROGRESS_LIST_VIEWED" est enregistré
|
||||
|
||||
Scénario: Expiration de la position audio après 7 jours
|
||||
Étant donné un utilisateur "frank@roadwave.fr" avec audio-guide en pause
|
||||
Et 8 jours se sont écoulés depuis la dernière écoute
|
||||
Quand il reprend l'audio-guide
|
||||
Alors la progression globale est conservée (séquences écoutées)
|
||||
Mais la position exacte dans l'audio est réinitialisée
|
||||
Et un message s'affiche: "La séquence redémarre depuis le début"
|
||||
Et un événement "AUDIO_POSITION_EXPIRED" est enregistré
|
||||
|
||||
Scénario: Badge "Explorateur assidu" pour reprises régulières
|
||||
Étant donné un utilisateur "grace@roadwave.fr" qui reprend 10 audio-guides
|
||||
Quand il complète chacun d'eux après les avoir repris
|
||||
Alors un badge "Explorateur assidu" est débloqué
|
||||
Et un événement "BADGE_PERSISTENT_EXPLORER_UNLOCKED" est enregistré
|
||||
|
||||
Scénario: Notification push de rappel après 3 jours d'inactivité
|
||||
Étant donné un utilisateur "henry@roadwave.fr" avec audio-guide en pause
|
||||
Et 3 jours se sont écoulés sans activité
|
||||
Quand le système envoie des rappels
|
||||
Alors une notification push est envoyée:
|
||||
"Vous avez laissé 'Visite du Quartier Latin' en suspens (5/10). Reprendre ?"
|
||||
Et un événement "RESUME_REMINDER_SENT" est enregistré
|
||||
|
||||
Scénario: Mode hors ligne avec sauvegarde locale
|
||||
Étant donné un utilisateur "iris@roadwave.fr" en mode hors ligne
|
||||
Quand elle écoute un audio-guide sans connexion
|
||||
Alors la progression est sauvegardée localement
|
||||
Et synchronisée automatiquement lors de la reconnexion
|
||||
Et un événement "PROGRESS_SYNCED_AFTER_OFFLINE" est enregistré
|
||||
|
||||
Scénario: Métriques de reprise de progression
|
||||
Étant donné que 10 000 audio-guides ont été mis en pause
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Taux de reprise dans les 24h | 42% |
|
||||
| Taux de reprise dans les 7j | 68% |
|
||||
| Taux d'abandon définitif | 32% |
|
||||
| Temps moyen avant reprise | 2.5 jours|
|
||||
| Taux de complétion après reprise| 78% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
@@ -0,0 +1,75 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @sync @mvp
|
||||
Fonctionnalité: Sauvegarde et synchronisation de progression
|
||||
|
||||
En tant qu'utilisateur
|
||||
Je veux que ma progression soit sauvegardée et synchronisée
|
||||
Afin d'accéder à mon historique sur tous mes appareils
|
||||
|
||||
Scénario: Sauvegarde en temps réel dans le cloud
|
||||
Étant donné un utilisateur "alice@roadwave.fr" connecté
|
||||
Quand elle complète une séquence
|
||||
Alors la progression est sauvegardée dans le cloud immédiatement
|
||||
Et un indicateur "Synchronisé" s'affiche
|
||||
Et un événement "PROGRESS_CLOUD_SAVED" est enregistré
|
||||
|
||||
Scénario: Synchronisation automatique au changement d'appareil
|
||||
Étant donné un utilisateur "bob@roadwave.fr" sur iPhone
|
||||
Quand il se connecte sur iPad
|
||||
Alors la progression est téléchargée automatiquement
|
||||
Et synchronisée en arrière-plan (< 2s)
|
||||
Et un événement "PROGRESS_SYNCED_DEVICE_SWITCH" est enregistré
|
||||
|
||||
Scénario: Résolution de conflits de synchronisation
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" avec 2 appareils
|
||||
Et il écoute hors ligne sur les deux simultanément
|
||||
Quand les deux se reconnectent avec progressions différentes
|
||||
Alors le système fusionne intelligemment les données
|
||||
Et conserve la progression la plus avancée
|
||||
Et un événement "SYNC_CONFLICT_RESOLVED" est enregistré
|
||||
|
||||
Scénario: Indicateur de statut de synchronisation
|
||||
Étant donné un utilisateur "david@roadwave.fr"
|
||||
Alors il voit l'icône de statut sync:
|
||||
| État | Icône | Couleur |
|
||||
| Synchronisé | ✓ | Vert |
|
||||
| En cours de sync | ↻ | Orange |
|
||||
| Non synchronisé | ⚠ | Rouge |
|
||||
Et un événement "SYNC_STATUS_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Sauvegarde locale en mode hors ligne
|
||||
Étant donné un utilisateur "eve@roadwave.fr" sans connexion
|
||||
Quand elle écoute un audio-guide hors ligne
|
||||
Alors toutes les données sont sauvegardées localement
|
||||
Et marquées "En attente de synchronisation"
|
||||
Et synchronisées automatiquement lors de la reconnexion
|
||||
Et un événement "OFFLINE_PROGRESS_QUEUED" est enregistré
|
||||
|
||||
Scénario: Export de l'historique de progression
|
||||
Étant donné un utilisateur "frank@roadwave.fr"
|
||||
Quand il demande un export de ses données (RGPD)
|
||||
Alors il reçoit un fichier JSON avec:
|
||||
| Donnée | Format |
|
||||
| Audio-guides écoutés | Liste |
|
||||
| Séquences par guide | Détail |
|
||||
| Timestamps | ISO 8601 |
|
||||
| Positions GPS visitées | Lat/Lon |
|
||||
Et un événement "PROGRESS_EXPORTED" est enregistré
|
||||
|
||||
Scénario: Suppression de progression sur demande
|
||||
Étant donné un utilisateur "grace@roadwave.fr"
|
||||
Quand elle supprime un audio-guide de son historique
|
||||
Alors toutes les données associées sont supprimées
|
||||
Et la synchronisation propage la suppression
|
||||
Et un événement "PROGRESS_DELETED" est enregistré
|
||||
|
||||
Scénario: Métriques de fiabilité de la synchronisation
|
||||
Étant donné que 100 000 synchronisations ont eu lieu
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur cible |
|
||||
| Taux de succès de sync | > 99.5% |
|
||||
| Temps moyen de synchronisation| < 2s |
|
||||
| Taux de conflits | < 0.5% |
|
||||
| Taux de résolution automatique| > 95% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
200
features/api/authentication/appareil-confiance-2fa.feature
Normal file
200
features/api/authentication/appareil-confiance-2fa.feature
Normal file
@@ -0,0 +1,200 @@
|
||||
# language: fr
|
||||
|
||||
@api @authentication @2fa @security @mvp
|
||||
Fonctionnalité: Appareils de confiance et authentification à deux facteurs
|
||||
|
||||
En tant qu'utilisateur soucieux de la sécurité
|
||||
Je veux gérer mes appareils de confiance et activer l'authentification à deux facteurs
|
||||
Afin de protéger mon compte contre les accès non autorisés
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système supporte les méthodes 2FA suivantes:
|
||||
| Méthode | Disponibilité | Recommandée |
|
||||
| Application TOTP | Oui | Oui |
|
||||
| SMS | Oui | Non |
|
||||
| Email | Oui | Non |
|
||||
| Clés de sécurité USB | Phase 2 | Oui |
|
||||
|
||||
Scénario: Activation de l'authentification à deux facteurs par TOTP
|
||||
Étant donné un utilisateur "alice@roadwave.fr" sans 2FA activé
|
||||
Quand l'utilisateur accède à "Mon compte > Sécurité > Authentification à deux facteurs"
|
||||
Et clique sur "Activer l'authentification à deux facteurs"
|
||||
Alors le système génère un QR code avec secret TOTP
|
||||
Et affiche le secret en texte clair pour saisie manuelle
|
||||
Et affiche les instructions: "Scannez ce QR code avec Google Authenticator, Authy ou Microsoft Authenticator"
|
||||
Et l'utilisateur scanne le QR code avec son application TOTP
|
||||
Et saisit le code à 6 chiffres généré par l'application
|
||||
Alors le 2FA est activé
|
||||
Et 10 codes de récupération à usage unique sont générés
|
||||
Et les codes de récupération sont affichés avec avertissement: "Conservez ces codes en lieu sûr"
|
||||
Et un événement "2FA_ENABLED" est enregistré
|
||||
Et un email de confirmation est envoyé
|
||||
Et la métrique "auth.2fa.enabled" est incrémentée
|
||||
|
||||
Scénario: Connexion avec 2FA depuis un nouvel appareil
|
||||
Étant donné un utilisateur "bob@roadwave.fr" avec 2FA activé
|
||||
Et aucun appareil de confiance enregistré
|
||||
Quand l'utilisateur se connecte depuis un iPhone avec email/mot de passe corrects
|
||||
Alors une page de vérification 2FA s'affiche
|
||||
Et l'utilisateur saisit le code à 6 chiffres de son application TOTP
|
||||
Et coche l'option "Faire confiance à cet appareil pour 30 jours"
|
||||
Alors la connexion est réussie
|
||||
Et l'iPhone est enregistré comme appareil de confiance
|
||||
Et un token d'appareil de confiance est stocké localement (durée: 30 jours)
|
||||
Et un événement "2FA_SUCCESS_NEW_TRUSTED_DEVICE" est enregistré
|
||||
Et un email est envoyé: "Nouvel appareil de confiance ajouté: iPhone"
|
||||
Et la métrique "auth.2fa.trusted_device.added" est incrémentée
|
||||
|
||||
Scénario: Connexion depuis un appareil de confiance existant
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" avec 2FA activé
|
||||
Et un iPhone enregistré comme appareil de confiance il y a 10 jours
|
||||
Quand l'utilisateur se connecte depuis cet iPhone avec email/mot de passe corrects
|
||||
Alors la connexion est réussie immédiatement sans demander le code 2FA
|
||||
Et un événement "LOGIN_TRUSTED_DEVICE" est enregistré
|
||||
Et la date de dernière utilisation de l'appareil de confiance est mise à jour
|
||||
Et la métrique "auth.2fa.trusted_device.used" est incrémentée
|
||||
|
||||
Scénario: Expiration automatique d'un appareil de confiance après 30 jours
|
||||
Étant donné un utilisateur "david@roadwave.fr" avec 2FA activé
|
||||
Et un iPad enregistré comme appareil de confiance il y a 31 jours
|
||||
Quand l'utilisateur se connecte depuis cet iPad avec email/mot de passe corrects
|
||||
Alors une page de vérification 2FA s'affiche
|
||||
Et l'utilisateur doit saisir le code TOTP
|
||||
Et un message s'affiche: "Votre appareil de confiance a expiré après 30 jours. Veuillez vous authentifier à nouveau."
|
||||
Et l'ancien token d'appareil de confiance est révoqué
|
||||
Et un événement "TRUSTED_DEVICE_EXPIRED" est enregistré
|
||||
Et la métrique "auth.2fa.trusted_device.expired" est incrémentée
|
||||
|
||||
Scénario: Gestion de la liste des appareils de confiance
|
||||
Étant donné un utilisateur "eve@roadwave.fr" avec 2FA activé
|
||||
Et 3 appareils de confiance enregistrés
|
||||
Quand l'utilisateur accède à "Mon compte > Sécurité > Appareils de confiance"
|
||||
Alors l'utilisateur voit la liste suivante:
|
||||
| Appareil | Ajouté le | Dernière utilisation | Expire le | Actions |
|
||||
| iPhone 14 Pro | 2026-01-15 | Il y a 2 heures | 2026-02-14 | [Révoquer] |
|
||||
| iPad Air | 2026-01-10 | Il y a 5 jours | 2026-02-09 | [Révoquer] |
|
||||
| MacBook Pro | 2026-01-05 | Il y a 10 jours | 2026-02-04 | [Révoquer] |
|
||||
Et un bouton "Révoquer tous les appareils de confiance" est disponible
|
||||
Et un compteur affiche "3 appareils de confiance actifs"
|
||||
|
||||
Scénario: Révocation manuelle d'un appareil de confiance
|
||||
Étant donné un utilisateur "frank@roadwave.fr" avec 2FA activé
|
||||
Et un MacBook Pro enregistré comme appareil de confiance
|
||||
Quand l'utilisateur clique sur "Révoquer" pour le MacBook Pro
|
||||
Alors l'appareil de confiance est immédiatement révoqué
|
||||
Et le token d'appareil de confiance est invalidé
|
||||
Et un événement "TRUSTED_DEVICE_REVOKED_MANUAL" est enregistré
|
||||
Et un email est envoyé: "Vous avez révoqué l'appareil de confiance: MacBook Pro"
|
||||
Et lors de la prochaine connexion, le code 2FA sera demandé
|
||||
Et la métrique "auth.2fa.trusted_device.revoked" est incrémentée
|
||||
|
||||
Scénario: Utilisation d'un code de récupération en cas de perte de l'application TOTP
|
||||
Étant donné un utilisateur "grace@roadwave.fr" avec 2FA activé
|
||||
Et l'utilisateur a perdu l'accès à son application TOTP
|
||||
Et il possède ses codes de récupération
|
||||
Quand l'utilisateur se connecte avec email/mot de passe corrects
|
||||
Et clique sur "Utiliser un code de récupération"
|
||||
Et saisit l'un des 10 codes de récupération
|
||||
Alors la connexion est réussie
|
||||
Et le code de récupération utilisé est marqué comme consommé
|
||||
Et il reste 9 codes de récupération disponibles
|
||||
Et un événement "2FA_RECOVERY_CODE_USED" est enregistré
|
||||
Et un email d'alerte est envoyé: "Un code de récupération a été utilisé. Il vous reste 9 codes."
|
||||
Et l'utilisateur est invité à reconfigurer son 2FA
|
||||
Et la métrique "auth.2fa.recovery_code.used" est incrémentée
|
||||
|
||||
Scénario: Régénération des codes de récupération
|
||||
Étant donné un utilisateur "henry@roadwave.fr" avec 2FA activé
|
||||
Et 3 codes de récupération ont été utilisés
|
||||
Quand l'utilisateur accède à "Mon compte > Sécurité > Codes de récupération"
|
||||
Et clique sur "Régénérer les codes de récupération"
|
||||
Alors un message d'avertissement s'affiche: "Les anciens codes seront invalidés. Êtes-vous sûr ?"
|
||||
Et après confirmation, 10 nouveaux codes de récupération sont générés
|
||||
Et les anciens codes sont invalidés immédiatement
|
||||
Et les nouveaux codes sont affichés une seule fois
|
||||
Et un événement "2FA_RECOVERY_CODES_REGENERATED" est enregistré
|
||||
Et un email est envoyé avec les nouveaux codes (chiffrés)
|
||||
Et la métrique "auth.2fa.recovery_codes.regenerated" est incrémentée
|
||||
|
||||
Scénario: Désactivation du 2FA avec vérification renforcée
|
||||
Étant donné un utilisateur "iris@roadwave.fr" avec 2FA activé
|
||||
Quand l'utilisateur accède à "Mon compte > Sécurité > Authentification à deux facteurs"
|
||||
Et clique sur "Désactiver l'authentification à deux facteurs"
|
||||
Alors un message d'avertissement s'affiche: "Cela réduira la sécurité de votre compte"
|
||||
Et l'utilisateur doit saisir son mot de passe actuel
|
||||
Et l'utilisateur doit saisir un code 2FA valide
|
||||
Et l'utilisateur doit confirmer par email via un lien sécurisé
|
||||
Alors le 2FA est désactivé
|
||||
Et tous les appareils de confiance sont révoqués
|
||||
Et tous les codes de récupération sont invalidés
|
||||
Et un événement "2FA_DISABLED" est enregistré
|
||||
Et un email de confirmation est envoyé
|
||||
Et la métrique "auth.2fa.disabled" est incrémentée
|
||||
|
||||
Scénario: Authentification 2FA par SMS en méthode de secours
|
||||
Étant donné un utilisateur "jack@roadwave.fr" avec 2FA par TOTP activé
|
||||
Et l'utilisateur a également configuré un numéro de téléphone de secours
|
||||
Quand l'utilisateur se connecte et clique sur "Recevoir un code par SMS"
|
||||
Alors un code à 6 chiffres est envoyé au numéro +33612345678
|
||||
Et l'utilisateur saisit le code reçu par SMS
|
||||
Alors la connexion est réussie
|
||||
Et un événement "2FA_SMS_FALLBACK_USED" est enregistré
|
||||
Et un email d'alerte est envoyé: "Vous avez utilisé la méthode SMS de secours"
|
||||
Et la métrique "auth.2fa.sms.used" est incrémentée
|
||||
|
||||
Scénario: Limitation des tentatives de codes 2FA
|
||||
Étant donné un utilisateur "kate@roadwave.fr" avec 2FA activé
|
||||
Quand l'utilisateur se connecte avec email/mot de passe corrects
|
||||
Et saisit 5 codes 2FA incorrects consécutivement
|
||||
Alors le compte est temporairement bloqué pour 15 minutes
|
||||
Et un message s'affiche: "Trop de tentatives échouées. Veuillez réessayer dans 15 minutes."
|
||||
Et un email d'alerte est envoyé: "Multiples tentatives échouées de codes 2FA détectées"
|
||||
Et un événement "2FA_TOO_MANY_ATTEMPTS" est enregistré avec niveau "HIGH"
|
||||
Et la métrique "auth.2fa.blocked.too_many_attempts" est incrémentée
|
||||
|
||||
Scénario: Détection de connexion suspecte malgré 2FA valide
|
||||
Étant donné un utilisateur "luke@roadwave.fr" avec 2FA activé
|
||||
Et toutes ses connexions habituelles sont depuis la France
|
||||
Quand l'utilisateur se connecte avec email/mot de passe corrects depuis la Russie
|
||||
Et saisit un code 2FA valide
|
||||
Alors la connexion est réussie mais marquée comme suspecte
|
||||
Et l'utilisateur reçoit immédiatement un email: "Connexion inhabituelle depuis Russie"
|
||||
Et une notification push est envoyée sur tous les appareils de confiance
|
||||
Et l'accès aux fonctionnalités sensibles (paiement, changement de mot de passe) est temporairement bloqué
|
||||
Et l'utilisateur doit confirmer son identité par email avant accès complet
|
||||
Et un événement "2FA_SUSPICIOUS_LOCATION" est enregistré avec niveau "HIGH"
|
||||
Et la métrique "auth.2fa.suspicious_login" est incrémentée
|
||||
|
||||
Scénario: Révocation de tous les appareils de confiance en cas de compromission
|
||||
Étant donné un utilisateur "mary@roadwave.fr" avec 2FA activé
|
||||
Et 5 appareils de confiance enregistrés
|
||||
Et l'utilisateur suspecte une compromission de son compte
|
||||
Quand l'utilisateur clique sur "Révoquer tous les appareils de confiance"
|
||||
Alors tous les appareils de confiance sont immédiatement révoqués
|
||||
Et tous les tokens d'appareils de confiance sont invalidés
|
||||
Et toutes les sessions actives sont fermées (sauf la session actuelle)
|
||||
Et un événement "ALL_TRUSTED_DEVICES_REVOKED" est enregistré avec niveau "HIGH"
|
||||
Et un email de confirmation est envoyé
|
||||
Et l'utilisateur devra saisir un code 2FA à chaque nouvelle connexion
|
||||
Et la métrique "auth.2fa.trusted_device.bulk_revoked" est incrémentée
|
||||
|
||||
Scénario: Métriques de sécurité pour le 2FA
|
||||
Étant donné que le système gère 50 000 utilisateurs avec 2FA activé
|
||||
Quand les métriques de sécurité sont collectées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur cible |
|
||||
| Pourcentage d'utilisateurs avec 2FA | > 60% |
|
||||
| Taux de succès de validation 2FA | > 98% |
|
||||
| Temps moyen de saisie du code 2FA | < 15s |
|
||||
| Nombre d'appareils de confiance par user | Moyenne: 2.5 |
|
||||
| Taux d'utilisation des codes de récup. | < 0.5% |
|
||||
Et les métriques sont exportées vers le système de monitoring
|
||||
Et des alertes sont déclenchées si le taux de succès < 95%
|
||||
|
||||
Scénario: Badge de sécurité pour utilisateurs avec 2FA activé
|
||||
Étant donné un utilisateur "nathan@roadwave.fr" avec 2FA activé depuis 30 jours
|
||||
Quand l'utilisateur consulte son profil public
|
||||
Alors un badge "Compte sécurisé" s'affiche sur son profil
|
||||
Et le badge indique: "Cet utilisateur a activé l'authentification à deux facteurs"
|
||||
Et le badge améliore la visibilité et la crédibilité du créateur de contenu
|
||||
Et la métrique "profile.badge.2fa_secured" est visible
|
||||
171
features/api/authentication/limite-tentatives-connexion.feature
Normal file
171
features/api/authentication/limite-tentatives-connexion.feature
Normal file
@@ -0,0 +1,171 @@
|
||||
# language: fr
|
||||
|
||||
@api @authentication @security @mvp
|
||||
Fonctionnalité: Limitation des tentatives de connexion
|
||||
|
||||
En tant que système de sécurité
|
||||
Je veux limiter les tentatives de connexion échouées
|
||||
Afin de protéger les comptes utilisateurs contre les attaques par force brute
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système est configuré avec les limites suivantes:
|
||||
| Paramètre | Valeur |
|
||||
| Tentatives max avant blocage | 5 |
|
||||
| Durée de blocage temporaire | 15 min |
|
||||
| Tentatives max avant blocage 24h | 10 |
|
||||
| Durée de blocage prolongé | 24h |
|
||||
| Fenêtre de temps pour reset | 30 min |
|
||||
|
||||
Scénario: Connexion réussie réinitialise le compteur de tentatives
|
||||
Étant donné un utilisateur "alice@roadwave.fr" avec 3 tentatives échouées
|
||||
Quand l'utilisateur se connecte avec les bons identifiants
|
||||
Alors la connexion est réussie
|
||||
Et le compteur de tentatives échouées est réinitialisé à 0
|
||||
Et un événement de sécurité "LOGIN_SUCCESS_AFTER_FAILURES" est enregistré
|
||||
|
||||
Scénario: Blocage temporaire après 5 tentatives échouées
|
||||
Étant donné un utilisateur "bob@roadwave.fr" avec 4 tentatives échouées
|
||||
Quand l'utilisateur tente de se connecter avec un mauvais mot de passe
|
||||
Alors la connexion échoue avec le code d'erreur "ACCOUNT_TEMPORARILY_LOCKED"
|
||||
Et le message est "Votre compte est temporairement verrouillé pour 15 minutes suite à de multiples tentatives échouées"
|
||||
Et un email de notification de sécurité est envoyé à "bob@roadwave.fr"
|
||||
Et un événement de sécurité "ACCOUNT_LOCKED_TEMP" est enregistré
|
||||
Et la métrique "security.account_locks.temporary" est incrémentée
|
||||
|
||||
Scénario: Tentative de connexion pendant le blocage temporaire
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" bloqué temporairement
|
||||
Et il reste 10 minutes avant la fin du blocage
|
||||
Quand l'utilisateur tente de se connecter avec les bons identifiants
|
||||
Alors la connexion échoue avec le code d'erreur "ACCOUNT_TEMPORARILY_LOCKED"
|
||||
Et le message contient "Votre compte reste verrouillé pour 10 minutes"
|
||||
Et le temps de blocage restant est indiqué en minutes
|
||||
Et la tentative ne rallonge pas la durée du blocage
|
||||
|
||||
Scénario: Connexion autorisée après expiration du blocage temporaire
|
||||
Étant donné un utilisateur "david@roadwave.fr" bloqué temporairement il y a 16 minutes
|
||||
Quand l'utilisateur tente de se connecter avec les bons identifiants
|
||||
Alors la connexion est réussie
|
||||
Et le compteur de tentatives échouées est réinitialisé à 0
|
||||
Et le statut de blocage est levé
|
||||
Et un événement de sécurité "ACCOUNT_UNLOCKED_AUTO" est enregistré
|
||||
|
||||
Scénario: Blocage prolongé après 10 tentatives échouées sur 24h
|
||||
Étant donné un utilisateur "eve@roadwave.fr" avec historique:
|
||||
| Tentatives échouées | Quand |
|
||||
| 5 | Il y a 2 heures |
|
||||
| Blocage 15min levé | Il y a 1h30 |
|
||||
| 4 | Il y a 30 minutes |
|
||||
Quand l'utilisateur tente une nouvelle connexion échouée
|
||||
Alors la connexion échoue avec le code d'erreur "ACCOUNT_LOCKED_24H"
|
||||
Et le message est "Votre compte est verrouillé pour 24 heures suite à de multiples tentatives suspectes"
|
||||
Et un email urgent de sécurité est envoyé avec un lien de déblocage sécurisé
|
||||
Et une notification SMS est envoyée (si configuré)
|
||||
Et un événement de sécurité "ACCOUNT_LOCKED_24H" est enregistré avec niveau "HIGH"
|
||||
Et la métrique "security.account_locks.prolonged" est incrémentée
|
||||
|
||||
Scénario: Blocage différencié par adresse IP
|
||||
Étant donné un utilisateur "frank@roadwave.fr" avec 3 tentatives échouées depuis IP "1.2.3.4"
|
||||
Quand l'utilisateur se connecte avec succès depuis IP "5.6.7.8"
|
||||
Alors la connexion est réussie
|
||||
Et le compteur de tentatives échouées pour IP "1.2.3.4" reste à 3
|
||||
Et le compteur de tentatives échouées pour IP "5.6.7.8" est à 0
|
||||
Et un événement de sécurité "LOGIN_FROM_NEW_IP" est enregistré
|
||||
|
||||
Scénario: Alerte de sécurité sur pattern suspect multi-IP
|
||||
Étant donné un utilisateur "grace@roadwave.fr"
|
||||
Quand 5 tentatives échouées sont détectées depuis 5 IP différentes en 10 minutes:
|
||||
| IP | Tentatives | Timestamp |
|
||||
| 1.2.3.4 | 2 | Il y a 10 min |
|
||||
| 5.6.7.8 | 1 | Il y a 8 min |
|
||||
| 9.10.11.12 | 1 | Il y a 5 min |
|
||||
| 13.14.15.16| 1 | Il y a 2 min |
|
||||
Alors le compte est immédiatement bloqué pour 24h
|
||||
Et un email d'alerte critique "POSSIBLE_CREDENTIAL_STUFFING_ATTACK" est envoyé
|
||||
Et l'équipe de sécurité est notifiée via webhook
|
||||
Et toutes les sessions actives sont révoquées
|
||||
Et la métrique "security.attacks.credential_stuffing.detected" est incrémentée
|
||||
|
||||
Scénario: Déblocage manuel par l'utilisateur via email sécurisé
|
||||
Étant donné un utilisateur "henry@roadwave.fr" bloqué pour 24h
|
||||
Et il a reçu un email avec un lien de déblocage sécurisé à usage unique
|
||||
Quand l'utilisateur clique sur le lien dans les 2 heures suivant l'email
|
||||
Et confirme son identité via un code envoyé par SMS
|
||||
Alors le compte est débloqué immédiatement
|
||||
Et l'utilisateur est invité à changer son mot de passe
|
||||
Et un événement de sécurité "ACCOUNT_UNLOCKED_MANUAL" est enregistré
|
||||
Et la métrique "security.account_unlocks.user_initiated" est incrémentée
|
||||
|
||||
Scénario: Réinitialisation automatique du compteur après période d'inactivité
|
||||
Étant donné un utilisateur "iris@roadwave.fr" avec 3 tentatives échouées
|
||||
Et aucune nouvelle tentative depuis 35 minutes
|
||||
Quand l'utilisateur tente de se connecter avec un mauvais mot de passe
|
||||
Alors le compteur de tentatives est réinitialisé à 1
|
||||
Et le message d'erreur est standard sans mention de blocage imminent
|
||||
Et un événement de sécurité "ATTEMPT_COUNTER_RESET" est enregistré
|
||||
|
||||
Scénario: Protection contre les attaques par timing
|
||||
Étant donné un utilisateur "jack@roadwave.fr"
|
||||
Quand l'utilisateur effectue 10 tentatives de connexion échouées
|
||||
Alors chaque réponse HTTP prend entre 800ms et 1200ms (temps constant)
|
||||
Et les messages d'erreur ne révèlent pas si l'email existe
|
||||
Et la métrique "security.timing_protection.applied" est incrémentée
|
||||
Et les logs n'exposent pas de patterns de timing exploitables
|
||||
|
||||
Scénario: Escalade des notifications avec tentatives répétées
|
||||
Étant donné un utilisateur "kate@roadwave.fr" Premium
|
||||
Quand les événements suivants se produisent:
|
||||
| Événement | Notification |
|
||||
| 3 tentatives échouées | Aucune notification |
|
||||
| 5 tentatives (blocage) | Email standard |
|
||||
| 10 tentatives (24h) | Email + SMS + notification app|
|
||||
| Tentative pendant 24h | Email urgent + alerte support |
|
||||
Alors chaque niveau de notification est proportionnel à la gravité
|
||||
Et l'utilisateur peut configurer ses préférences de notification
|
||||
Et la métrique "security.notifications.escalated" est incrémentée
|
||||
|
||||
Scénario: Whitelist d'IP pour utilisateurs de confiance
|
||||
Étant donné un utilisateur "luke@roadwave.fr" avec IP de confiance "1.2.3.4"
|
||||
Et la whitelist est configurée pour autoriser 10 tentatives au lieu de 5
|
||||
Quand l'utilisateur effectue 7 tentatives échouées depuis "1.2.3.4"
|
||||
Alors le compte n'est pas bloqué
|
||||
Et un avertissement est affiché "3 tentatives restantes avant blocage"
|
||||
Et un événement de sécurité "TRUSTED_IP_EXTENDED_ATTEMPTS" est enregistré
|
||||
|
||||
Scénario: Logs de sécurité détaillés pour audit
|
||||
Étant donné un utilisateur "mary@roadwave.fr" avec tentatives échouées
|
||||
Quand un audit de sécurité est effectué
|
||||
Alors les logs contiennent pour chaque tentative:
|
||||
| Champ | Exemple |
|
||||
| Timestamp | 2026-02-03T14:32:18.123Z |
|
||||
| User ID | uuid-123-456 |
|
||||
| Email | mary@roadwave.fr |
|
||||
| IP Address | 1.2.3.4 |
|
||||
| User Agent | Mozilla/5.0 (iPhone...) |
|
||||
| Failure Reason | INVALID_PASSWORD |
|
||||
| Attempts Count | 3 |
|
||||
| Geolocation | Paris, France |
|
||||
| Device Fingerprint| hash-abc-def |
|
||||
Et les logs sont conservés pendant 90 jours minimum
|
||||
Et les logs sont conformes RGPD (pas de mots de passe en clair)
|
||||
|
||||
Scénario: Métriques de performance du système de limitation
|
||||
Étant donné que le système traite 1000 tentatives de connexion par minute
|
||||
Quand les métriques de performance sont collectées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur cible |
|
||||
| Temps de vérification du compteur | < 50ms |
|
||||
| Latence ajoutée par le rate limiting | < 100ms |
|
||||
| Pourcentage de tentatives bloquées | < 2% |
|
||||
| Faux positifs (utilisateurs légitimes) | < 0.1% |
|
||||
| Temps de déblocage automatique | < 1s |
|
||||
Et les métriques sont exportées vers le système de monitoring
|
||||
Et des alertes sont déclenchées si les seuils sont dépassés
|
||||
|
||||
Scénario: Compatibilité avec authentification multi-facteurs
|
||||
Étant donné un utilisateur "nathan@roadwave.fr" avec 2FA activé
|
||||
Et il a 4 tentatives échouées (mot de passe correct mais code 2FA incorrect)
|
||||
Quand l'utilisateur tente une 5ème connexion avec mot de passe correct et mauvais code 2FA
|
||||
Alors le compte est bloqué temporairement
|
||||
Et le message précise "Blocage suite à de multiples erreurs de code 2FA"
|
||||
Et le compteur 2FA est distinct du compteur de mot de passe
|
||||
Et un événement de sécurité "2FA_LOCK_TRIGGERED" est enregistré
|
||||
191
features/api/authentication/multi-device-sessions.feature
Normal file
191
features/api/authentication/multi-device-sessions.feature
Normal file
@@ -0,0 +1,191 @@
|
||||
# language: fr
|
||||
|
||||
@api @authentication @sessions @mvp
|
||||
Fonctionnalité: Gestion des sessions multi-appareils
|
||||
|
||||
En tant qu'utilisateur
|
||||
Je veux gérer mes sessions actives sur plusieurs appareils
|
||||
Afin de contrôler l'accès à mon compte et améliorer la sécurité
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système supporte les sessions suivantes:
|
||||
| Paramètre | Valeur |
|
||||
| Nombre max de sessions simultanées | 5 |
|
||||
| Durée de vie d'une session | 30 jours |
|
||||
| Durée d'inactivité avant expiration | 7 jours |
|
||||
| Durée du token de refresh | 90 jours |
|
||||
| Taille max du stockage de session | 10 KB |
|
||||
|
||||
Scénario: Création d'une nouvelle session avec empreinte d'appareil
|
||||
Étant donné un utilisateur "alice@roadwave.fr" non connecté
|
||||
Quand l'utilisateur se connecte depuis un iPhone 14 Pro avec iOS 17.2
|
||||
Alors une nouvelle session est créée avec les métadonnées:
|
||||
| Champ | Valeur |
|
||||
| Device Type | mobile |
|
||||
| OS | iOS 17.2 |
|
||||
| App Version | 1.2.3 |
|
||||
| Device Model | iPhone 14 Pro |
|
||||
| Browser | N/A |
|
||||
| IP Address | 1.2.3.4 |
|
||||
| Geolocation | Paris, France |
|
||||
| Created At | 2026-02-03T14:32:18Z |
|
||||
| Last Activity | 2026-02-03T14:32:18Z |
|
||||
Et un token JWT avec durée de vie de 30 jours est généré
|
||||
Et un refresh token avec durée de vie de 90 jours est généré
|
||||
Et un événement "SESSION_CREATED" est enregistré
|
||||
Et la métrique "sessions.created" est incrémentée
|
||||
|
||||
Scénario: Connexion simultanée sur plusieurs appareils
|
||||
Étant donné un utilisateur "bob@roadwave.fr" connecté sur:
|
||||
| Appareil | OS | Dernière activité |
|
||||
| iPhone 13 | iOS 16.5 | Il y a 5 min |
|
||||
| iPad Pro | iPadOS 17.1 | Il y a 2 heures |
|
||||
| MacBook Pro | macOS 14.2 | Il y a 1 jour |
|
||||
Quand l'utilisateur se connecte depuis un Samsung Galaxy S23
|
||||
Alors une nouvelle session est créée
|
||||
Et l'utilisateur a maintenant 4 sessions actives
|
||||
Et toutes les sessions précédentes restent valides
|
||||
Et un événement "NEW_DEVICE_LOGIN" est enregistré
|
||||
Et une notification push est envoyée sur tous les appareils: "Nouvelle connexion depuis Samsung Galaxy S23"
|
||||
|
||||
Scénario: Limitation du nombre de sessions simultanées
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" avec 5 sessions actives
|
||||
Quand l'utilisateur se connecte depuis un 6ème appareil
|
||||
Alors la session la plus ancienne est automatiquement révoquée
|
||||
Et une nouvelle session est créée pour le nouvel appareil
|
||||
Et l'utilisateur reçoit une notification: "Votre session sur [Ancien Appareil] a été fermée automatiquement"
|
||||
Et un événement "SESSION_EVICTED_MAX_LIMIT" est enregistré
|
||||
Et la métrique "sessions.evicted.max_limit" est incrémentée
|
||||
|
||||
Scénario: Liste des sessions actives dans les paramètres du compte
|
||||
Étant donné un utilisateur "david@roadwave.fr" avec 3 sessions actives
|
||||
Quand l'utilisateur accède à "Mon compte > Sécurité > Appareils connectés"
|
||||
Alors l'utilisateur voit la liste suivante:
|
||||
| Appareil | Localisation | Dernière activité | IP | Actions |
|
||||
| iPhone 14 Pro | Paris, France | Actif maintenant | 1.2.3.4 | [Cet appareil]|
|
||||
| iPad Air | Lyon, France | Il y a 2 heures | 5.6.7.8 | [Déconnecter] |
|
||||
| MacBook Pro | Marseille, FR | Il y a 3 jours | 9.10.11.12| [Déconnecter] |
|
||||
Et la session actuelle est clairement identifiée
|
||||
Et un bouton "Déconnecter tous les autres appareils" est disponible
|
||||
|
||||
Scénario: Révocation manuelle d'une session spécifique
|
||||
Étant donné un utilisateur "eve@roadwave.fr" avec 4 sessions actives
|
||||
Et il consulte la liste de ses appareils depuis son iPhone
|
||||
Quand l'utilisateur clique sur "Déconnecter" pour la session "MacBook Pro"
|
||||
Alors la session "MacBook Pro" est immédiatement révoquée
|
||||
Et le token JWT associé est invalidé dans Redis
|
||||
Et le refresh token est révoqué
|
||||
Et l'utilisateur sur le MacBook Pro est déconnecté lors de sa prochaine requête
|
||||
Et un événement "SESSION_REVOKED_MANUAL" est enregistré
|
||||
Et une notification est envoyée: "Vous avez été déconnecté de votre MacBook Pro"
|
||||
|
||||
Scénario: Déconnexion de tous les autres appareils
|
||||
Étant donné un utilisateur "frank@roadwave.fr" avec 5 sessions actives
|
||||
Et il suspecte un accès non autorisé
|
||||
Quand l'utilisateur clique sur "Déconnecter tous les autres appareils" depuis son iPhone
|
||||
Alors toutes les sessions sauf la session actuelle (iPhone) sont révoquées
|
||||
Et 4 tokens JWT sont invalidés
|
||||
Et 4 refresh tokens sont révoqués
|
||||
Et un événement "SESSIONS_REVOKED_ALL_OTHER" est enregistré
|
||||
Et une notification est envoyée sur tous les appareils déconnectés
|
||||
Et un email de confirmation est envoyé: "Vous avez déconnecté tous vos autres appareils"
|
||||
Et la métrique "sessions.revoked.bulk" est incrémentée
|
||||
|
||||
Scénario: Détection de connexion suspecte depuis un nouveau pays
|
||||
Étant donné un utilisateur "grace@roadwave.fr" avec sessions habituelles en France
|
||||
Quand l'utilisateur se connecte depuis une IP en Russie
|
||||
Alors une alerte de sécurité est déclenchée
|
||||
Et un email est envoyé: "Connexion détectée depuis Russie - Est-ce bien vous ?"
|
||||
Et une notification push est envoyée sur tous les appareils de confiance
|
||||
Et la session est créée mais marquée comme "suspecte"
|
||||
Et un événement "SUSPICIOUS_LOCATION_LOGIN" est enregistré avec niveau "HIGH"
|
||||
Et l'utilisateur doit confirmer son identité par code SMS avant d'accéder aux fonctionnalités sensibles
|
||||
|
||||
Scénario: Expiration automatique d'une session inactive
|
||||
Étant donné un utilisateur "henry@roadwave.fr" avec une session sur iPad
|
||||
Et la session n'a pas été utilisée depuis 8 jours
|
||||
Quand le job de nettoyage des sessions s'exécute
|
||||
Alors la session iPad est automatiquement révoquée
|
||||
Et le token JWT est invalidé
|
||||
Et le refresh token est révoqué
|
||||
Et un événement "SESSION_EXPIRED_INACTIVITY" est enregistré
|
||||
Et un email est envoyé: "Votre session sur iPad a expiré suite à 8 jours d'inactivité"
|
||||
Et la métrique "sessions.expired.inactivity" est incrémentée
|
||||
|
||||
Scénario: Rafraîchissement automatique du token avant expiration
|
||||
Étant donné un utilisateur "iris@roadwave.fr" avec une session active
|
||||
Et le token JWT expire dans 2 minutes
|
||||
Quand l'application mobile effectue une requête API
|
||||
Alors l'API détecte que le token expire bientôt
|
||||
Et un nouveau token JWT est généré automatiquement
|
||||
Et le nouveau token est retourné dans le header "X-Refreshed-Token"
|
||||
Et l'application mobile stocke le nouveau token
|
||||
Et un événement "TOKEN_REFRESHED" est enregistré
|
||||
Et la métrique "tokens.refreshed" est incrémentée
|
||||
|
||||
Scénario: Révocation de toutes les sessions lors d'un changement de mot de passe
|
||||
Étant donné un utilisateur "jack@roadwave.fr" avec 4 sessions actives
|
||||
Quand l'utilisateur change son mot de passe depuis son iPhone
|
||||
Alors toutes les sessions sauf la session actuelle (iPhone) sont révoquées
|
||||
Et tous les tokens JWT sont invalidés
|
||||
Et tous les refresh tokens sont révoqués
|
||||
Et un événement "SESSIONS_REVOKED_PASSWORD_CHANGE" est enregistré
|
||||
Et un email est envoyé: "Votre mot de passe a été modifié. Toutes vos autres sessions ont été déconnectées."
|
||||
Et des notifications push sont envoyées sur tous les appareils déconnectés
|
||||
|
||||
Scénario: Persistance de la session avec "Se souvenir de moi"
|
||||
Étant donné un utilisateur "kate@roadwave.fr" qui se connecte
|
||||
Quand l'utilisateur coche l'option "Se souvenir de moi"
|
||||
Alors la durée de vie du token JWT est étendue à 90 jours
|
||||
Et la durée de vie du refresh token est étendue à 180 jours
|
||||
Et la session persiste même après fermeture de l'application
|
||||
Et un cookie sécurisé "remember_token" est stocké (pour web)
|
||||
Et un événement "LONG_SESSION_CREATED" est enregistré
|
||||
Et la métrique "sessions.remember_me.enabled" est incrémentée
|
||||
|
||||
Scénario: Détection de vol de token et révocation automatique
|
||||
Étant donné un utilisateur "luke@roadwave.fr" avec une session active
|
||||
Et le token JWT a été volé et utilisé depuis une IP différente
|
||||
Quand le système détecte une utilisation simultanée du même token depuis 2 IP différentes
|
||||
Alors toutes les sessions de l'utilisateur sont immédiatement révoquées
|
||||
Et tous les tokens sont invalidés
|
||||
Et un email d'alerte critique est envoyé: "Activité suspecte détectée - Toutes vos sessions ont été fermées"
|
||||
Et une notification push urgente est envoyée sur tous les appareils
|
||||
Et l'utilisateur doit réinitialiser son mot de passe avant de se reconnecter
|
||||
Et un événement "TOKEN_THEFT_DETECTED" est enregistré avec niveau "CRITICAL"
|
||||
Et l'équipe de sécurité est alertée via webhook
|
||||
|
||||
Scénario: Synchronisation des informations de session en temps réel
|
||||
Étant donné un utilisateur "mary@roadwave.fr" connecté sur 3 appareils
|
||||
Quand l'utilisateur révoque une session depuis son iPhone
|
||||
Alors la liste des sessions est mise à jour en temps réel sur tous les appareils via WebSocket
|
||||
Et l'appareil déconnecté reçoit immédiatement une notification de déconnexion
|
||||
Et l'UI est rafraîchie automatiquement sur tous les appareils connectés
|
||||
Et la métrique "sessions.realtime_sync" est incrémentée
|
||||
|
||||
Scénario: Métriques de performance de gestion des sessions
|
||||
Étant donné que le système gère 100 000 sessions actives
|
||||
Quand les métriques de performance sont collectées
|
||||
Alors les indicateurs suivants sont respectés:
|
||||
| Métrique | Valeur cible |
|
||||
| Temps de création de session | < 50ms |
|
||||
| Temps de validation de token | < 20ms |
|
||||
| Temps de révocation de session | < 100ms |
|
||||
| Latence de synchronisation temps réel | < 500ms |
|
||||
| Taux de succès du refresh automatique | > 99.9% |
|
||||
Et les métriques sont exportées vers le système de monitoring
|
||||
Et des alertes sont déclenchées si les seuils sont dépassés
|
||||
|
||||
Scénario: Stockage sécurisé des sessions dans Redis
|
||||
Étant donné un utilisateur "nathan@roadwave.fr" avec une session active
|
||||
Quand la session est stockée dans Redis
|
||||
Alors les données suivantes sont chiffrées:
|
||||
| Champ | Chiffrement |
|
||||
| User ID | Hash |
|
||||
| Refresh Token | AES-256 |
|
||||
| Device Info | Non |
|
||||
| IP Address | Hash |
|
||||
Et la clé Redis a un TTL correspondant à la durée de vie de la session
|
||||
Et les données sensibles ne sont jamais loggées en clair
|
||||
Et les accès à Redis sont audités
|
||||
Et la métrique "sessions.storage.encrypted" est incrémentée
|
||||
@@ -0,0 +1,187 @@
|
||||
# language: fr
|
||||
|
||||
@api @authentication @security @mvp
|
||||
Fonctionnalité: Récupération et réinitialisation avancée du mot de passe
|
||||
|
||||
En tant qu'utilisateur ayant oublié son mot de passe
|
||||
Je veux pouvoir récupérer l'accès à mon compte de manière sécurisée
|
||||
Afin de reprendre l'utilisation de l'application
|
||||
|
||||
Contexte:
|
||||
Étant donné que le système de récupération est configuré avec:
|
||||
| Paramètre | Valeur |
|
||||
| Durée de validité du lien de reset | 1 heure |
|
||||
| Nombre max de demandes par heure | 3 |
|
||||
| Nombre max de demandes par jour | 10 |
|
||||
| Longueur du token de reset | 64 chars |
|
||||
| Délai de cooldown entre demandes | 5 minutes |
|
||||
|
||||
Scénario: Demande de réinitialisation de mot de passe
|
||||
Étant donné un utilisateur "alice@roadwave.fr" qui a oublié son mot de passe
|
||||
Quand l'utilisateur clique sur "Mot de passe oublié ?" sur l'écran de connexion
|
||||
Et saisit son adresse email "alice@roadwave.fr"
|
||||
Alors un email de réinitialisation est envoyé avec:
|
||||
| Élément | Contenu |
|
||||
| Sujet | Réinitialisation de votre mot de passe RoadWave |
|
||||
| Lien sécurisé | https://roadwave.fr/reset?token=abc123... |
|
||||
| Durée de validité | Ce lien expire dans 1 heure |
|
||||
| Warning sécurité | Si vous n'êtes pas à l'origine de cette demande... |
|
||||
Et un événement "PASSWORD_RESET_REQUESTED" est enregistré
|
||||
Et la métrique "auth.password_reset.requested" est incrémentée
|
||||
Et un message s'affiche: "Si cette adresse est enregistrée, vous recevrez un email de réinitialisation"
|
||||
|
||||
Scénario: Protection contre l'énumération d'adresses email
|
||||
Étant donné une adresse email "inexistant@roadwave.fr" non enregistrée
|
||||
Quand un utilisateur demande la réinitialisation pour cette adresse
|
||||
Alors le même message de confirmation s'affiche: "Si cette adresse est enregistrée, vous recevrez un email"
|
||||
Et aucun email n'est envoyé
|
||||
Et le temps de réponse est identique à une demande valide (800-1200ms)
|
||||
Et un événement "PASSWORD_RESET_UNKNOWN_EMAIL" est enregistré
|
||||
Et la métrique "auth.password_reset.unknown_email" est incrémentée
|
||||
Et les logs n'exposent pas l'information de l'existence ou non de l'email
|
||||
|
||||
Scénario: Limitation du nombre de demandes de réinitialisation
|
||||
Étant donné un utilisateur "bob@roadwave.fr"
|
||||
Et il a déjà effectué 3 demandes de réinitialisation dans la dernière heure
|
||||
Quand l'utilisateur effectue une 4ème demande
|
||||
Alors la demande est refusée avec le message: "Trop de demandes de réinitialisation. Veuillez attendre 1 heure."
|
||||
Et aucun email n'est envoyé
|
||||
Et un événement "PASSWORD_RESET_RATE_LIMITED" est enregistré
|
||||
Et la métrique "auth.password_reset.rate_limited" est incrémentée
|
||||
|
||||
Scénario: Utilisation du lien de réinitialisation valide
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" ayant demandé la réinitialisation
|
||||
Et il a reçu un email avec un token valide il y a 30 minutes
|
||||
Quand l'utilisateur clique sur le lien dans l'email
|
||||
Alors il est redirigé vers la page de réinitialisation
|
||||
Et le formulaire de nouveau mot de passe s'affiche
|
||||
Et le token est validé côté serveur
|
||||
Et un événement "PASSWORD_RESET_TOKEN_ACCESSED" est enregistré
|
||||
Et la session est sécurisée avec CSRF protection
|
||||
|
||||
Scénario: Définition du nouveau mot de passe avec validation
|
||||
Étant donné un utilisateur "david@roadwave.fr" sur la page de réinitialisation
|
||||
Et il a un token valide
|
||||
Quand l'utilisateur saisit un nouveau mot de passe "SecurePass2026!"
|
||||
Et confirme le mot de passe
|
||||
Alors le mot de passe est validé selon les règles de sécurité
|
||||
Et le mot de passe est hashé avec bcrypt (cost: 12)
|
||||
Et le mot de passe est enregistré dans la base de données
|
||||
Et toutes les sessions actives sont révoquées
|
||||
Et tous les tokens d'accès sont invalidés
|
||||
Et un événement "PASSWORD_RESET_COMPLETED" est enregistré
|
||||
Et un email de confirmation est envoyé: "Votre mot de passe a été modifié avec succès"
|
||||
Et la métrique "auth.password_reset.completed" est incrémentée
|
||||
Et l'utilisateur est redirigé vers la page de connexion
|
||||
|
||||
Scénario: Tentative d'utilisation d'un token expiré
|
||||
Étant donné un utilisateur "eve@roadwave.fr" ayant demandé la réinitialisation
|
||||
Et il a reçu un email avec un token valide il y a 2 heures
|
||||
Quand l'utilisateur clique sur le lien expiré
|
||||
Alors un message d'erreur s'affiche: "Ce lien de réinitialisation a expiré. Veuillez faire une nouvelle demande."
|
||||
Et un bouton "Demander un nouveau lien" est affiché
|
||||
Et un événement "PASSWORD_RESET_TOKEN_EXPIRED" est enregistré
|
||||
Et la métrique "auth.password_reset.token_expired" est incrémentée
|
||||
|
||||
Scénario: Tentative d'utilisation d'un token déjà utilisé
|
||||
Étant donné un utilisateur "frank@roadwave.fr" ayant réinitialisé son mot de passe
|
||||
Et le token a déjà été utilisé il y a 10 minutes
|
||||
Quand l'utilisateur tente de réutiliser le même lien
|
||||
Alors un message d'erreur s'affiche: "Ce lien a déjà été utilisé. Si vous avez besoin de réinitialiser à nouveau, faites une nouvelle demande."
|
||||
Et un événement "PASSWORD_RESET_TOKEN_REUSED" est enregistré avec niveau "MEDIUM"
|
||||
Et un email d'alerte est envoyé: "Tentative de réutilisation d'un ancien lien de réinitialisation"
|
||||
Et la métrique "auth.password_reset.token_reused" est incrémentée
|
||||
|
||||
Scénario: Détection de tentative d'attaque par force brute sur les tokens
|
||||
Étant donné un attaquant qui tente de deviner des tokens de réinitialisation
|
||||
Quand 10 tokens invalides sont testés depuis la même IP en 5 minutes
|
||||
Alors l'IP est bloquée temporairement pour 1 heure
|
||||
Et tous les tokens valides pour cette IP sont invalidés
|
||||
Et un événement "PASSWORD_RESET_BRUTE_FORCE_DETECTED" est enregistré avec niveau "CRITICAL"
|
||||
Et l'équipe de sécurité est alertée via webhook
|
||||
Et la métrique "security.password_reset.brute_force" est incrémentée
|
||||
|
||||
Scénario: Réinitialisation avec validation 2FA pour comptes sensibles
|
||||
Étant donné un utilisateur "grace@roadwave.fr" avec 2FA activé
|
||||
Et il a demandé la réinitialisation de son mot de passe
|
||||
Quand l'utilisateur clique sur le lien de réinitialisation
|
||||
Alors une étape supplémentaire de vérification 2FA s'affiche
|
||||
Et l'utilisateur doit saisir un code TOTP ou un code de récupération
|
||||
Et après validation 2FA, le formulaire de nouveau mot de passe s'affiche
|
||||
Et un événement "PASSWORD_RESET_2FA_VALIDATED" est enregistré
|
||||
Et la métrique "auth.password_reset.with_2fa" est incrémentée
|
||||
|
||||
Scénario: Notification de sécurité sur tous les appareils
|
||||
Étant donné un utilisateur "henry@roadwave.fr" connecté sur 3 appareils
|
||||
Quand l'utilisateur réinitialise son mot de passe
|
||||
Alors une notification push est envoyée sur tous les appareils:
|
||||
| Message |
|
||||
| Votre mot de passe a été modifié |
|
||||
| Si ce n'est pas vous, contactez immédiatement le support |
|
||||
Et un email est envoyé avec détails:
|
||||
| Détail | Valeur |
|
||||
| Date et heure | 2026-02-03 14:32:18 |
|
||||
| Adresse IP | 1.2.3.4 |
|
||||
| Localisation | Paris, France |
|
||||
| Appareil | iPhone 14 Pro |
|
||||
| Navigateur | Safari 17.2 |
|
||||
Et un lien "Ce n'était pas moi" permet de bloquer le compte immédiatement
|
||||
|
||||
Scénario: Historique des modifications de mot de passe
|
||||
Étant donné un utilisateur "iris@roadwave.fr"
|
||||
Quand l'utilisateur accède à "Mon compte > Sécurité > Historique"
|
||||
Alors l'utilisateur voit l'historique des modifications:
|
||||
| Date | Action | IP | Appareil | Localisation |
|
||||
| 2026-02-03 14:32 | Réinitialisation mot de passe | 1.2.3.4 | iPhone 14 | Paris, FR |
|
||||
| 2026-01-15 10:20 | Changement mot de passe | 5.6.7.8 | MacBook Pro | Lyon, FR |
|
||||
| 2025-12-01 08:15 | Création du compte | 9.10.11.12| iPad Air | Marseille, FR |
|
||||
Et les événements sont conservés pendant 90 jours minimum
|
||||
Et les logs sont conformes RGPD
|
||||
|
||||
Scénario: Réinitialisation impossible pour compte bloqué ou suspendu
|
||||
Étant donné un utilisateur "jack@roadwave.fr" dont le compte est suspendu
|
||||
Quand l'utilisateur demande la réinitialisation de son mot de passe
|
||||
Alors un message s'affiche: "Votre compte est actuellement suspendu. Veuillez contacter le support."
|
||||
Et aucun email de réinitialisation n'est envoyé
|
||||
Et un événement "PASSWORD_RESET_ACCOUNT_SUSPENDED" est enregistré
|
||||
Et un lien vers le support est fourni
|
||||
Et la métrique "auth.password_reset.blocked_account" est incrémentée
|
||||
|
||||
Scénario: Vérification de l'unicité du nouveau mot de passe
|
||||
Étant donné un utilisateur "kate@roadwave.fr" sur la page de réinitialisation
|
||||
Quand l'utilisateur tente de définir le même mot de passe que l'ancien
|
||||
Alors une erreur s'affiche: "Veuillez choisir un mot de passe différent de l'ancien"
|
||||
Et le mot de passe n'est pas enregistré
|
||||
Et un événement "PASSWORD_RESET_SAME_PASSWORD" est enregistré
|
||||
Et la métrique "auth.password_reset.same_password" est incrémentée
|
||||
|
||||
Scénario: Vérification contre les mots de passe compromis
|
||||
Étant donné un utilisateur "luke@roadwave.fr" sur la page de réinitialisation
|
||||
Quand l'utilisateur tente de définir un mot de passe "Password123!"
|
||||
Et ce mot de passe figure dans la base de données Have I Been Pwned
|
||||
Alors une erreur s'affiche: "Ce mot de passe est connu et a été compromis. Veuillez en choisir un autre."
|
||||
Et le mot de passe n'est pas enregistré
|
||||
Et un événement "PASSWORD_RESET_COMPROMISED_PASSWORD" est enregistré
|
||||
Et la métrique "auth.password_reset.compromised_blocked" est incrémentée
|
||||
|
||||
Scénario: Cooldown entre demandes successives de réinitialisation
|
||||
Étant donné un utilisateur "mary@roadwave.fr"
|
||||
Et il a fait une demande de réinitialisation il y a 2 minutes
|
||||
Quand l'utilisateur fait une nouvelle demande de réinitialisation
|
||||
Alors la demande est refusée avec le message: "Veuillez attendre 5 minutes entre chaque demande"
|
||||
Et un compteur affiche "Vous pourrez faire une nouvelle demande dans 3 minutes"
|
||||
Et un événement "PASSWORD_RESET_COOLDOWN" est enregistré
|
||||
Et la métrique "auth.password_reset.cooldown_hit" est incrémentée
|
||||
|
||||
Scénario: Métriques de sécurité pour la réinitialisation de mot de passe
|
||||
Étant donné que le système traite 1000 demandes de réinitialisation par jour
|
||||
Quand les métriques de sécurité sont collectées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur cible |
|
||||
| Taux de complétion des réinitialisations | > 75% |
|
||||
| Taux de tokens expirés avant utilisation | < 20% |
|
||||
| Temps moyen de complétion | < 5 min |
|
||||
| Taux de détection de mots de passe compromis | > 5% |
|
||||
| Nombre de tentatives de brute force bloquées | Visible |
|
||||
Et les métriques sont exportées vers le système de monitoring
|
||||
Et des alertes sont déclenchées si anomalies détectées
|
||||
250
features/api/authentication/validation-mot-passe.feature
Normal file
250
features/api/authentication/validation-mot-passe.feature
Normal file
@@ -0,0 +1,250 @@
|
||||
# language: fr
|
||||
|
||||
@api @authentication @security @mvp
|
||||
Fonctionnalité: Validation des règles de mot de passe
|
||||
|
||||
En tant que système d'authentification
|
||||
Je veux valider la complexité des mots de passe
|
||||
Afin de garantir la sécurité des comptes utilisateurs
|
||||
|
||||
Contexte:
|
||||
Étant donné un utilisateur souhaite créer un compte ou modifier son mot de passe
|
||||
|
||||
# ============================================================================
|
||||
# VALIDATION LONGUEUR MINIMALE (8 CARACTÈRES)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Mot de passe valide avec 8 caractères minimum
|
||||
Étant donné l'utilisateur saisit le mot de passe "Azerty123"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Et aucune erreur ne doit être affichée
|
||||
|
||||
Scénario: Mot de passe trop court (7 caractères)
|
||||
Étant donné l'utilisateur saisit le mot de passe "Azert12"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit échouer
|
||||
Et le message d'erreur doit être "Le mot de passe doit contenir au moins 8 caractères"
|
||||
Et le champ doit être marqué en rouge
|
||||
|
||||
Scénario: Mot de passe très court (3 caractères)
|
||||
Étant donné l'utilisateur saisit le mot de passe "Ab1"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit échouer
|
||||
Et le message d'erreur doit être "Le mot de passe doit contenir au moins 8 caractères"
|
||||
|
||||
# ============================================================================
|
||||
# VALIDATION MAJUSCULE REQUISE
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Mot de passe valide avec au moins 1 majuscule
|
||||
Étant donné l'utilisateur saisit le mot de passe "Monpass123"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Et le critère "majuscule" doit être validé avec une coche verte
|
||||
|
||||
Scénario: Mot de passe sans majuscule
|
||||
Étant donné l'utilisateur saisit le mot de passe "monpass123"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit échouer
|
||||
Et le message d'erreur doit être "Le mot de passe doit contenir au moins 1 majuscule"
|
||||
|
||||
Scénario: Mot de passe avec plusieurs majuscules
|
||||
Étant donné l'utilisateur saisit le mot de passe "MonPASSword123"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Car au moins 1 majuscule est présente
|
||||
|
||||
# ============================================================================
|
||||
# VALIDATION CHIFFRE REQUIS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Mot de passe valide avec au moins 1 chiffre
|
||||
Étant donné l'utilisateur saisit le mot de passe "Monpass1"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Et le critère "chiffre" doit être validé avec une coche verte
|
||||
|
||||
Scénario: Mot de passe sans chiffre
|
||||
Étant donné l'utilisateur saisit le mot de passe "Monpassword"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit échouer
|
||||
Et le message d'erreur doit être "Le mot de passe doit contenir au moins 1 chiffre"
|
||||
|
||||
Scénario: Mot de passe avec plusieurs chiffres
|
||||
Étant donné l'utilisateur saisit le mot de passe "Monpass123456"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Car au moins 1 chiffre est présent
|
||||
|
||||
# ============================================================================
|
||||
# VALIDATION COMBINÉE DES 3 CRITÈRES
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Mot de passe valide respectant tous les critères
|
||||
Étant donné l'utilisateur saisit le mot de passe "SecurePass2024!"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Et tous les critères doivent être validés :
|
||||
| critère | statut |
|
||||
| longueur | ✓ |
|
||||
| majuscule | ✓ |
|
||||
| chiffre | ✓ |
|
||||
|
||||
Scénario: Mot de passe échouant sur plusieurs critères
|
||||
Étant donné l'utilisateur saisit le mot de passe "pass"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit échouer
|
||||
Et les messages d'erreur suivants doivent être affichés :
|
||||
| Le mot de passe doit contenir au moins 8 caractères |
|
||||
| Le mot de passe doit contenir au moins 1 majuscule |
|
||||
| Le mot de passe doit contenir au moins 1 chiffre |
|
||||
|
||||
Scénario: Mot de passe long mais sans majuscule ni chiffre
|
||||
Étant donné l'utilisateur saisit le mot de passe "monmotdepasse"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit échouer
|
||||
Et les messages d'erreur suivants doivent être affichés :
|
||||
| Le mot de passe doit contenir au moins 1 majuscule |
|
||||
| Le mot de passe doit contenir au moins 1 chiffre |
|
||||
|
||||
# ============================================================================
|
||||
# VALIDATION TEMPS RÉEL (FRONTEND)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Affichage progressif des critères pendant la saisie
|
||||
Étant donné l'utilisateur commence à saisir son mot de passe
|
||||
Quand l'utilisateur tape "m"
|
||||
Alors les critères suivants doivent être affichés :
|
||||
| critère | statut |
|
||||
| longueur | ✗ |
|
||||
| majuscule | ✗ |
|
||||
| chiffre | ✗ |
|
||||
Quand l'utilisateur tape "Mon"
|
||||
Alors les critères doivent être mis à jour :
|
||||
| critère | statut |
|
||||
| longueur | ✗ |
|
||||
| majuscule | ✓ |
|
||||
| chiffre | ✗ |
|
||||
Quand l'utilisateur tape "Monpass1"
|
||||
Alors les critères doivent être mis à jour :
|
||||
| critère | statut |
|
||||
| longueur | ✓ |
|
||||
| majuscule | ✓ |
|
||||
| chiffre | ✓ |
|
||||
|
||||
Scénario: Feedback visuel temps réel
|
||||
Étant donné l'utilisateur saisit progressivement son mot de passe
|
||||
Quand un critère est validé
|
||||
Alors une coche verte ✓ doit apparaître à côté du critère
|
||||
Et le texte du critère doit passer en vert
|
||||
Quand un critère n'est pas validé
|
||||
Alors une croix rouge ✗ doit apparaître
|
||||
Et le texte du critère doit rester en gris ou rouge
|
||||
|
||||
# ============================================================================
|
||||
# VALIDATION BACKEND (SÉCURITÉ)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Validation backend en plus du frontend
|
||||
Étant donné l'utilisateur contourne la validation frontend
|
||||
Et envoie directement le mot de passe "weak" via API
|
||||
Quand le backend reçoit la requête
|
||||
Alors la validation backend doit rejeter le mot de passe
|
||||
Et retourner une erreur HTTP 400 Bad Request
|
||||
Et le message doit être :
|
||||
"""
|
||||
{
|
||||
"error": "invalid_password",
|
||||
"details": [
|
||||
"Le mot de passe doit contenir au moins 8 caractères",
|
||||
"Le mot de passe doit contenir au moins 1 majuscule",
|
||||
"Le mot de passe doit contenir au moins 1 chiffre"
|
||||
]
|
||||
}
|
||||
"""
|
||||
|
||||
Scénario: Validation backend avec mot de passe valide
|
||||
Étant donné l'utilisateur envoie le mot de passe "SecurePass123"
|
||||
Quand le backend valide le mot de passe
|
||||
Alors la validation backend doit réussir
|
||||
Et le mot de passe doit être hashé avec bcrypt (coût 12)
|
||||
Et le hash doit être stocké dans la base de données
|
||||
|
||||
# ============================================================================
|
||||
# CAS LIMITES ET CARACTÈRES SPÉCIAUX
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Mot de passe avec caractères spéciaux (acceptés)
|
||||
Étant donné l'utilisateur saisit le mot de passe "MonP@ss123!"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Car les caractères spéciaux sont autorisés (mais non obligatoires)
|
||||
|
||||
Scénario: Mot de passe avec espaces (acceptés)
|
||||
Étant donné l'utilisateur saisit le mot de passe "Mon Pass 123"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Car les espaces sont autorisés
|
||||
|
||||
Scénario: Mot de passe avec accents (acceptés)
|
||||
Étant donné l'utilisateur saisit le mot de passe "MônPàss123"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Car les caractères accentués comptent comme des lettres
|
||||
|
||||
Scénario: Mot de passe avec émojis (acceptés)
|
||||
Étant donné l'utilisateur saisit le mot de passe "MonPass123🔒"
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Car les émojis sont autorisés
|
||||
|
||||
Scénario: Mot de passe vide
|
||||
Étant donné l'utilisateur laisse le champ mot de passe vide
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit échouer
|
||||
Et le message d'erreur doit être "Le mot de passe est requis"
|
||||
|
||||
# ============================================================================
|
||||
# MODIFICATION MOT DE PASSE
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Changement de mot de passe avec validation
|
||||
Étant donné un utilisateur authentifié veut changer son mot de passe
|
||||
Et l'utilisateur saisit son ancien mot de passe "OldPass123"
|
||||
Et l'utilisateur saisit le nouveau mot de passe "NewSecure456"
|
||||
Quand le système valide le nouveau mot de passe
|
||||
Alors la validation doit réussir
|
||||
Et le nouveau mot de passe doit respecter les mêmes règles
|
||||
Et l'ancien mot de passe doit être vérifié avant le changement
|
||||
|
||||
Scénario: Nouveau mot de passe identique à l'ancien (autorisé)
|
||||
Étant donné un utilisateur veut changer son mot de passe
|
||||
Et l'utilisateur saisit le nouveau mot de passe identique à l'ancien
|
||||
Quand le système valide le mot de passe
|
||||
Alors la validation doit réussir
|
||||
Car il n'y a pas de règle interdisant la réutilisation
|
||||
|
||||
# ============================================================================
|
||||
# MESSAGES D'AIDE ET UX
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Affichage des règles avant saisie
|
||||
Étant donné l'utilisateur accède au formulaire d'inscription
|
||||
Quand le champ mot de passe reçoit le focus
|
||||
Alors une info-bulle doit s'afficher avec les règles :
|
||||
"""
|
||||
Votre mot de passe doit contenir :
|
||||
• Au moins 8 caractères
|
||||
• Au moins 1 majuscule
|
||||
• Au moins 1 chiffre
|
||||
"""
|
||||
|
||||
Scénario: Indicateur de force du mot de passe
|
||||
Étant donné l'utilisateur saisit progressivement son mot de passe
|
||||
Quand l'utilisateur tape "Weak1"
|
||||
Alors l'indicateur de force doit afficher "Faible" en orange
|
||||
Quand l'utilisateur tape "Medium12"
|
||||
Alors l'indicateur de force doit afficher "Moyen" en jaune
|
||||
Quand l'utilisateur tape "VeryStrong123!"
|
||||
Alors l'indicateur de force doit afficher "Fort" en vert
|
||||
59
features/api/content-creation/fair-use-30s-musique.feature
Normal file
59
features/api/content-creation/fair-use-30s-musique.feature
Normal file
@@ -0,0 +1,59 @@
|
||||
# language: fr
|
||||
|
||||
@api @content-creation @copyright @mvp
|
||||
Fonctionnalité: Fair use 30 secondes musique
|
||||
|
||||
En tant que créateur
|
||||
Je veux utiliser jusqu'à 30 secondes de musique protégée
|
||||
Afin d'enrichir mon contenu dans le cadre du fair use
|
||||
|
||||
Scénario: Détection automatique de musique dans l'upload
|
||||
Étant donné un créateur "alice@roadwave.fr" qui upload un audio
|
||||
Quand le fichier contient de la musique
|
||||
Alors le système détecte via fingerprinting audio (ACRCloud)
|
||||
Et identifie les morceaux présents
|
||||
Et mesure la durée de chaque extrait
|
||||
Et un événement "MUSIC_DETECTED" est enregistré
|
||||
|
||||
Scénario: Validation automatique si < 30 secondes
|
||||
Étant donné un audio avec 25 secondes de musique protégée
|
||||
Quand la validation automatique s'exécute
|
||||
Alors le contenu est approuvé (fair use)
|
||||
Et un badge "Fair use" est appliqué
|
||||
Et un événement "FAIR_USE_APPROVED" est enregistré
|
||||
|
||||
Scénario: Blocage automatique si > 30 secondes
|
||||
Étant donné un audio avec 45 secondes de musique protégée
|
||||
Quand la validation s'exécute
|
||||
Alors le contenu est bloqué
|
||||
Et le créateur voit: "Extrait musical trop long (45s). Max: 30s"
|
||||
Et il peut éditer et re-uploader
|
||||
Et un événement "FAIR_USE_REJECTED" est enregistré
|
||||
|
||||
Scénario: Liste des morceaux détectés avec durée
|
||||
Étant donné un créateur "bob@roadwave.fr" avec musique détectée
|
||||
Alors il voit la liste:
|
||||
| Morceau | Artiste | Durée | Statut |
|
||||
| Bohemian Rhapsody | Queen | 28s | ✓ OK |
|
||||
| Imagine | John Lennon | 15s | ✓ OK |
|
||||
Et la durée totale: 43s
|
||||
Et un avertissement si total > 30s
|
||||
Et un événement "MUSIC_DETECTION_RESULTS_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Suggestions de musique libre de droits
|
||||
Étant donné un créateur "charlie@roadwave.fr"
|
||||
Quand son audio dépasse les 30s de musique protégée
|
||||
Alors le système suggère des alternatives libres:
|
||||
| Morceau | Licence | Style |
|
||||
| Acoustic Breeze | CC BY | Acoustique |
|
||||
| Epic Cinematic | Royalty-free| Épique |
|
||||
Et un lien vers une bibliothèque musicale
|
||||
Et un événement "FREE_MUSIC_SUGGESTED" est enregistré
|
||||
|
||||
Scénario: Limitation cumulative par audio-guide
|
||||
Étant donné un créateur "david@roadwave.fr" avec audio-guide de 10 séquences
|
||||
Quand il utilise de la musique protégée
|
||||
Alors chaque séquence peut contenir max 30s
|
||||
Mais le total cumulé est limité à 3 minutes par audio-guide
|
||||
Et un compteur affiche: "2min 15s / 3min utilisés"
|
||||
Et un événement "CUMULATIVE_MUSIC_LIMIT_TRACKED" est enregistré
|
||||
41
features/api/content-creation/image-couverture-auto.feature
Normal file
41
features/api/content-creation/image-couverture-auto.feature
Normal file
@@ -0,0 +1,41 @@
|
||||
# language: fr
|
||||
|
||||
@api @content-creation @media @mvp
|
||||
Fonctionnalité: Génération automatique d'image de couverture
|
||||
|
||||
En tant que créateur
|
||||
Je veux générer automatiquement une image de couverture
|
||||
Afin de gagner du temps et avoir un visuel professionnel
|
||||
|
||||
Scénario: Génération automatique depuis position GPS
|
||||
Étant donné un créateur "alice@roadwave.fr"
|
||||
Quand il crée un audio-guide centré sur "Notre-Dame"
|
||||
Alors le système propose une image de Notre-Dame via API (Unsplash/Pexels)
|
||||
Et 5 suggestions d'images sont affichées
|
||||
Et le créateur peut choisir ou uploader la sienne
|
||||
Et un événement "COVER_AUTO_GENERATED" est enregistré
|
||||
|
||||
Scénario: Ajout automatique de texte sur l'image
|
||||
Étant donné un créateur "bob@roadwave.fr" qui valide une image
|
||||
Quand l'image est sélectionnée
|
||||
Alors le titre de l'audio-guide est ajouté automatiquement
|
||||
Et un filtre sombre est appliqué pour lisibilité
|
||||
Et le texte est centré et optimisé
|
||||
Et un événement "COVER_TEXT_OVERLAY_ADDED" est enregistré
|
||||
|
||||
Scénario: Templates prédéfinis par catégorie
|
||||
Étant donné un créateur "charlie@roadwave.fr"
|
||||
Quand il sélectionne la catégorie "Tourisme"
|
||||
Alors des templates touristiques sont proposés
|
||||
Et il peut personnaliser couleurs et polices
|
||||
Et un événement "COVER_TEMPLATE_USED" est enregistré
|
||||
|
||||
Scénario: Optimisation automatique pour mobile et web
|
||||
Étant donné un créateur "david@roadwave.fr" qui valide une couverture
|
||||
Alors 3 versions sont générées:
|
||||
| Format | Dimensions |
|
||||
| Mobile | 1080x1920 |
|
||||
| Tablette | 2048x2732 |
|
||||
| Web | 1920x1080 |
|
||||
Et toutes sont optimisées en WebP
|
||||
Et un événement "COVER_OPTIMIZED" est enregistré
|
||||
@@ -0,0 +1,53 @@
|
||||
# language: fr
|
||||
|
||||
@api @content-creation @rules @mvp
|
||||
Fonctionnalité: Restrictions de modification de contenu publié
|
||||
|
||||
En tant que plateforme
|
||||
Je veux restreindre les modifications après publication
|
||||
Afin de maintenir l'intégrité du contenu et des statistiques
|
||||
|
||||
Scénario: Modification limitée du contenu après publication
|
||||
Étant donné un créateur "alice@roadwave.fr" avec contenu publié
|
||||
Quand il tente de modifier le contenu
|
||||
Alors il peut modifier:
|
||||
| Champ modifiable | Restrictions |
|
||||
| Titre | Max 1 fois par mois |
|
||||
| Description | Illimité |
|
||||
| Image de couverture | Max 3 fois par an |
|
||||
| Fichiers audio | Impossible après 100 écoutes|
|
||||
| Prix | Max 1 baisse par trimestre |
|
||||
Et un événement "CONTENT_MODIFICATION_RESTRICTED" est enregistré
|
||||
|
||||
Scénario: Blocage de modification des séquences très écoutées
|
||||
Étant donné un créateur "bob@roadwave.fr"
|
||||
Et une séquence avec 1000+ écoutes
|
||||
Quand il tente de remplacer le fichier audio
|
||||
Alors la modification est bloquée
|
||||
Et un message explique: "Contenu verrouillé après 1000 écoutes"
|
||||
Et il peut créer une nouvelle version à la place
|
||||
Et un événement "AUDIO_MODIFICATION_BLOCKED" est enregistré
|
||||
|
||||
Scénario: Historique des modifications
|
||||
Étant donné un créateur "charlie@roadwave.fr"
|
||||
Quand il consulte l'historique
|
||||
Alors il voit toutes les modifications:
|
||||
| Date | Champ modifié | Ancienne valeur | Nouvelle valeur |
|
||||
| 2026-02-01 | Titre | Visite Paris | Visite Paris 2026|
|
||||
| 2026-01-15 | Prix | 5€ | 3€ |
|
||||
Et un événement "MODIFICATION_HISTORY_VIEWED" est enregistré
|
||||
|
||||
Scénario: Délai de modération avant republication
|
||||
Étant donné un créateur "david@roadwave.fr"
|
||||
Quand il modifie substantiellement un contenu publié
|
||||
Alors le contenu repasse en modération
|
||||
Et reste accessible pendant la modération
|
||||
Et un événement "CONTENT_REMODERATION_QUEUED" est enregistré
|
||||
|
||||
Scénario: Versioning automatique des contenus
|
||||
Étant donné un créateur "eve@roadwave.fr"
|
||||
Quand il publie une modification importante
|
||||
Alors une nouvelle version (v2) est créée
|
||||
Et les utilisateurs ayant commencé v1 la terminent
|
||||
Et les nouveaux utilisateurs obtiennent v2
|
||||
Et un événement "CONTENT_VERSION_CREATED" est enregistré
|
||||
62
features/api/content-creation/suppression-marquage.feature
Normal file
62
features/api/content-creation/suppression-marquage.feature
Normal file
@@ -0,0 +1,62 @@
|
||||
# language: fr
|
||||
|
||||
@api @content-creation @deletion @mvp
|
||||
Fonctionnalité: Suppression et marquage de contenu
|
||||
|
||||
En tant que créateur ou modérateur
|
||||
Je veux pouvoir supprimer ou marquer du contenu
|
||||
Afin de gérer le cycle de vie du contenu sur la plateforme
|
||||
|
||||
Scénario: Suppression douce avec période de grâce de 30 jours
|
||||
Étant donné un créateur "alice@roadwave.fr"
|
||||
Quand il supprime son audio-guide
|
||||
Alors le contenu est marqué "Supprimé" (soft delete)
|
||||
Et reste dans la base pendant 30 jours
|
||||
Et disparaît des recherches immédiatement
|
||||
Et peut être restauré dans les 30 jours
|
||||
Et un événement "CONTENT_SOFT_DELETED" est enregistré
|
||||
|
||||
Scénario: Suppression définitive après 30 jours
|
||||
Étant donné un contenu supprimé il y a 31 jours
|
||||
Quand le job de nettoyage s'exécute
|
||||
Alors le contenu est définitivement supprimé (hard delete)
|
||||
Et tous les fichiers associés sont supprimés de S3
|
||||
Et les statistiques sont archivées
|
||||
Et un événement "CONTENT_HARD_DELETED" est enregistré
|
||||
|
||||
Scénario: Restauration d'un contenu supprimé
|
||||
Étant donné un créateur "bob@roadwave.fr"
|
||||
Et un contenu supprimé il y a 10 jours
|
||||
Quand il accède à "Contenus supprimés"
|
||||
Et clique sur "Restaurer"
|
||||
Alors le contenu redevient actif immédiatement
|
||||
Et réapparaît dans les recherches
|
||||
Et un événement "CONTENT_RESTORED" est enregistré
|
||||
|
||||
Scénario: Marquage de contenu obsolète
|
||||
Étant donné un créateur "charlie@roadwave.fr"
|
||||
Quand il marque un contenu comme "Obsolète"
|
||||
Alors un badge "⚠️ Contenu obsolète" s'affiche
|
||||
Et il reste accessible mais avec avertissement
|
||||
Et n'apparaît plus dans les recommandations
|
||||
Et un événement "CONTENT_MARKED_OBSOLETE" est enregistré
|
||||
|
||||
Scénario: Blocage par modération
|
||||
Étant donné un modérateur qui détecte un contenu problématique
|
||||
Quand il bloque le contenu
|
||||
Alors il devient immédiatement invisible
|
||||
Et le créateur est notifié avec raison
|
||||
Et peut faire appel de la décision
|
||||
Et un événement "CONTENT_BLOCKED_BY_MODERATION" est enregistré
|
||||
|
||||
Scénario: Statistiques avant suppression définitive
|
||||
Étant donné un créateur "david@roadwave.fr"
|
||||
Quand il consulte un contenu avant suppression définitive
|
||||
Alors il voit les statistiques finales:
|
||||
| Métrique | Valeur |
|
||||
| Total écoutes | 1,234 |
|
||||
| Note moyenne | 4.2/5 |
|
||||
| Revenus générés | 156€ |
|
||||
| Période active | 8 mois |
|
||||
Et peut exporter ces données
|
||||
Et un événement "DELETION_STATS_VIEWED" est enregistré
|
||||
@@ -0,0 +1,62 @@
|
||||
# language: fr
|
||||
|
||||
@api @content-creation @copyright @mvp
|
||||
Fonctionnalité: Validation et détection automatique de musique
|
||||
|
||||
En tant que plateforme
|
||||
Je veux détecter automatiquement la musique protégée
|
||||
Afin de respecter les droits d'auteur
|
||||
|
||||
Scénario: Analyse audio automatique lors de l'upload
|
||||
Étant donné un créateur upload un fichier audio
|
||||
Quand le fichier est uploadé sur S3
|
||||
Alors une tâche asynchrone d'analyse est lancée
|
||||
Et l'audio est comparé à la base ACRCloud
|
||||
Et les résultats sont disponibles en < 30 secondes
|
||||
Et un événement "MUSIC_ANALYSIS_STARTED" est enregistré
|
||||
|
||||
Scénario: Identification précise avec métadonnées
|
||||
Étant donné un audio analysé
|
||||
Quand de la musique est détectée
|
||||
Alors le système retourne:
|
||||
| Métadonnée | Exemple |
|
||||
| Titre | Bohemian Rhapsody |
|
||||
| Artiste | Queen |
|
||||
| Album | A Night at the Opera |
|
||||
| ISRC | GBUM71029604 |
|
||||
| Timestamp | 00:02:15 - 00:02:43 |
|
||||
| Durée | 28 secondes |
|
||||
| Confiance | 98% |
|
||||
Et un événement "MUSIC_IDENTIFIED" est enregistré
|
||||
|
||||
Scénario: Faux positifs - validation manuelle
|
||||
Étant donné un audio avec détection incertaine (confiance < 80%)
|
||||
Quand le créateur conteste la détection
|
||||
Alors une review manuelle est déclenchée
|
||||
Et un modérateur écoute et valide
|
||||
Et un événement "MUSIC_MANUAL_REVIEW_REQUESTED" est enregistré
|
||||
|
||||
Scénario: Mise en queue pendant l'analyse
|
||||
Étant donné un créateur qui upload un audio
|
||||
Quand l'analyse est en cours
|
||||
Alors le statut affiche "Analyse en cours..."
|
||||
Et le créateur peut continuer la création
|
||||
Et est notifié quand l'analyse est terminée
|
||||
Et un événement "MUSIC_ANALYSIS_PENDING" est enregistré
|
||||
|
||||
Scénario: Détection de musique transformée (pitch, tempo)
|
||||
Étant donné un audio avec musique modifiée (accélérée/ralentie)
|
||||
Quand l'analyse s'exécute
|
||||
Alors le système détecte quand même le morceau original
|
||||
Et applique les mêmes règles de fair use
|
||||
Et un événement "MODIFIED_MUSIC_DETECTED" est enregistré
|
||||
|
||||
Scénario: Statistiques de détection pour la plateforme
|
||||
Étant donné que 10 000 audios ont été analysés
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Taux de détection de musique | 35% |
|
||||
| Taux de conformité fair use | 88% |
|
||||
| Taux de faux positifs | 2% |
|
||||
| Temps moyen d'analyse | 18s |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
42
features/api/moderation/appel-droits-auteur.feature
Normal file
42
features/api/moderation/appel-droits-auteur.feature
Normal file
@@ -0,0 +1,42 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @copyright @appeal @mvp
|
||||
Fonctionnalité: Procédure d'appel pour droits d'auteur
|
||||
|
||||
En tant que créateur sanctionné
|
||||
Je veux faire appel d'une décision
|
||||
Afin de contester une sanction injuste
|
||||
|
||||
Scénario: Dépôt d'un appel
|
||||
Étant donné un créateur "alice@roadwave.fr" sanctionné
|
||||
Quand il fait appel dans les 15 jours
|
||||
Alors un dossier d'appel est créé
|
||||
Et il doit fournir des preuves (fair use, licence, etc.)
|
||||
Et un événement "COPYRIGHT_APPEAL_FILED" est enregistré
|
||||
|
||||
Scénario: Examen de l'appel par comité
|
||||
Étant donné un appel déposé
|
||||
Quand le comité l'examine (3 modérateurs)
|
||||
Alors une décision est prise dans les 7 jours
|
||||
Et le créateur est notifié du résultat
|
||||
Et un événement "COPYRIGHT_APPEAL_REVIEWED" est enregistré
|
||||
|
||||
Scénario: Appel accepté - Annulation de la sanction
|
||||
Étant donné un appel validé
|
||||
Alors la sanction est annulée
|
||||
Et le contenu est rétabli
|
||||
Et le compteur d'infractions n'est pas incrémenté
|
||||
Et un événement "COPYRIGHT_APPEAL_ACCEPTED" est enregistré
|
||||
|
||||
Scénario: Appel rejeté - Maintien de la sanction
|
||||
Étant donné un appel rejeté
|
||||
Alors la sanction est maintenue
|
||||
Et le créateur ne peut plus faire appel pour ce cas
|
||||
Et un événement "COPYRIGHT_APPEAL_REJECTED" est enregistré
|
||||
|
||||
Scénario: Délai de prescription des infractions
|
||||
Étant donné une infraction datant de > 2 ans
|
||||
Et aucune nouvelle infraction depuis
|
||||
Alors l'infraction est retirée de l'historique
|
||||
Et ne compte plus dans le système de sanctions progressives
|
||||
Et un événement "COPYRIGHT_INFRACTION_EXPIRED" est enregistré
|
||||
76
features/api/moderation/audit-trimestriel.feature
Normal file
76
features/api/moderation/audit-trimestriel.feature
Normal file
@@ -0,0 +1,76 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @audit @governance @mvp
|
||||
Fonctionnalité: Audit trimestriel du système de modération
|
||||
|
||||
En tant que responsable de la plateforme
|
||||
Je veux un audit trimestriel de la modération
|
||||
Afin d'assurer transparence et amélioration continue
|
||||
|
||||
Scénario: Génération automatique du rapport d'audit
|
||||
Étant donné la fin d'un trimestre (31 mars 2026)
|
||||
Quand le système génère le rapport
|
||||
Alors il contient:
|
||||
| Section | Détails |
|
||||
| Statistiques globales | Signalements, taux de traitement|
|
||||
| Performance modérateurs | Temps moyen, précision |
|
||||
| Contenus bloqués | Par catégorie |
|
||||
| Appels et contestations | Taux d'acceptation |
|
||||
| Améliorations proposées | Recommandations |
|
||||
Et un PDF est généré et archivé
|
||||
Et un événement "QUARTERLY_AUDIT_GENERATED" est enregistré
|
||||
|
||||
Scénario: Publication transparente des métriques
|
||||
Étant donné le rapport d'audit trimestriel
|
||||
Quand il est publié
|
||||
Alors une page publique affiche:
|
||||
| Métrique | Q1 2026 | Q4 2025 |
|
||||
| Signalements traités | 15,234 | 12,876 |
|
||||
| Temps moyen de traitement | 8h | 12h |
|
||||
| Taux de précision automatique | 85% | 82% |
|
||||
| Appels acceptés | 18% | 22% |
|
||||
| Comptes bannis | 234 | 198 |
|
||||
Et un événement "AUDIT_PUBLICLY_PUBLISHED" est enregistré
|
||||
|
||||
Scénario: Analyse des tendances sur 4 trimestres
|
||||
Étant donné 4 rapports trimestriels
|
||||
Alors un graphique d'évolution est affiché:
|
||||
| Métrique | Tendance |
|
||||
| Signalements totaux | +12% par tri |
|
||||
| Temps de traitement | -25% |
|
||||
| Taux de faux positifs | -5% |
|
||||
Et des insights sont générés automatiquement
|
||||
Et un événement "AUDIT_TRENDS_ANALYZED" est enregistré
|
||||
|
||||
Scénario: Recommandations d'amélioration
|
||||
Étant donné le rapport d'audit
|
||||
Quand le système analyse les données
|
||||
Alors des recommandations sont proposées:
|
||||
| Recommandation | Priorité |
|
||||
| Recruter 2 modérateurs supplémentaires| Haute |
|
||||
| Améliorer modèle ML de détection | Moyenne |
|
||||
| Revoir processus d'appel | Basse |
|
||||
Et un plan d'action trimestriel est établi
|
||||
Et un événement "AUDIT_RECOMMENDATIONS_GENERATED" est enregistré
|
||||
|
||||
Scénario: Audit externe annuel
|
||||
Étant donné la fin de l'année (31 décembre)
|
||||
Quand un audit externe est commandé
|
||||
Alors un cabinet indépendant analyse:
|
||||
| Aspect | Conformité |
|
||||
| Respect RGPD | Oui |
|
||||
| Transparence des décisions | Oui |
|
||||
| Impartialité de la modération | Oui |
|
||||
| Temps de réponse | Acceptable |
|
||||
Et un certificat de conformité est délivré
|
||||
Et un événement "EXTERNAL_AUDIT_COMPLETED" est enregistré
|
||||
|
||||
Scénario: Métriques d'impact des audits
|
||||
Étant donné 4 audits trimestriels effectués
|
||||
Alors l'impact est mesuré:
|
||||
| Métrique | Amélioration |
|
||||
| Temps de traitement | -30% |
|
||||
| Satisfaction utilisateurs | +15% |
|
||||
| Taux de faux positifs | -40% |
|
||||
| Coûts de modération | -10% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
76
features/api/moderation/badges-system.feature
Normal file
76
features/api/moderation/badges-system.feature
Normal file
@@ -0,0 +1,76 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @gamification @mvp
|
||||
Fonctionnalité: Système de badges de modération
|
||||
|
||||
En tant qu'utilisateur modérateur
|
||||
Je veux gagner des badges pour ma contribution
|
||||
Afin d'être reconnu et motivé à modérer
|
||||
|
||||
Scénario: Badge Bronze - 10 signalements validés
|
||||
Étant donné un utilisateur "alice@roadwave.fr" qui a 10 signalements validés
|
||||
Quand le 10ème signalement est confirmé
|
||||
Alors le badge "Modérateur Bronze" est débloqué
|
||||
Et affiché sur son profil
|
||||
Et +50 points de réputation
|
||||
Et un événement "BADGE_BRONZE_MODERATOR_UNLOCKED" est enregistré
|
||||
|
||||
Scénario: Badge Argent - 50 signalements validés
|
||||
Étant donné un utilisateur avec 50 signalements validés
|
||||
Alors le badge "Modérateur Argent" est débloqué
|
||||
Et il obtient des privilèges supplémentaires
|
||||
Et +200 points de réputation
|
||||
Et un événement "BADGE_SILVER_MODERATOR_UNLOCKED" est enregistré
|
||||
|
||||
Scénario: Badge Or - 200 signalements validés
|
||||
Étant donné un utilisateur avec 200 signalements validés
|
||||
Alors le badge "Modérateur Or" est débloqué
|
||||
Et il devient "Utilisateur de confiance"
|
||||
Et ses signalements sont traités en priorité
|
||||
Et +500 points de réputation
|
||||
Et un événement "BADGE_GOLD_MODERATOR_UNLOCKED" est enregistré
|
||||
|
||||
Scénario: Badge Diamant - 1000 signalements + 95% de précision
|
||||
Étant donné un utilisateur avec 1000 signalements validés
|
||||
Et un taux de précision > 95%
|
||||
Alors le badge "Modérateur Diamant" est débloqué
|
||||
Et il peut devenir modérateur officiel
|
||||
Et +2000 points de réputation
|
||||
Et un événement "BADGE_DIAMOND_MODERATOR_UNLOCKED" est enregistré
|
||||
|
||||
Scénario: Perte de badge si précision < 70%
|
||||
Étant donné un utilisateur avec badge Silver
|
||||
Quand son taux de précision tombe < 70%
|
||||
Alors le badge est révoqué temporairement
|
||||
Et il doit retrouver 80% de précision pour le récupérer
|
||||
Et un événement "BADGE_REVOKED_LOW_ACCURACY" est enregistré
|
||||
|
||||
Scénario: Badges spéciaux pour expertise
|
||||
Étant donné un utilisateur spécialisé
|
||||
Alors il peut obtenir des badges thématiques:
|
||||
| Badge | Condition |
|
||||
| Expert droits d'auteur | 100 signalements copyright validés|
|
||||
| Expert contenu offensant | 100 signalements haine validés |
|
||||
| Expert spam | 100 signalements spam validés |
|
||||
Et un événement "EXPERT_BADGE_UNLOCKED" est enregistré
|
||||
|
||||
Scénario: Classement des meilleurs modérateurs
|
||||
Étant donné tous les utilisateurs modérateurs
|
||||
Alors un leaderboard est affiché:
|
||||
| Rang | Utilisateur | Signalements | Précision | Badge |
|
||||
| 1 | alice | 1,234 | 98% | Diamant |
|
||||
| 2 | bob | 876 | 96% | Or |
|
||||
| 3 | charlie | 543 | 94% | Or |
|
||||
Et le top 10 reçoit des récompenses mensuelles
|
||||
Et un événement "MODERATOR_LEADERBOARD_VIEWED" est enregistré
|
||||
|
||||
Scénario: Récompenses mensuelles pour top modérateurs
|
||||
Étant donné le top 10 du mois
|
||||
Quand le mois se termine
|
||||
Alors chacun reçoit:
|
||||
| Rang | Récompense |
|
||||
| 1-3 | 6 mois Premium gratuit |
|
||||
| 4-6 | 3 mois Premium gratuit |
|
||||
| 7-10 | 1 mois Premium gratuit |
|
||||
Et un badge "Top modérateur du mois"
|
||||
Et un événement "MONTHLY_MODERATOR_REWARDS_DISTRIBUTED" est enregistré
|
||||
84
features/api/moderation/detection-patterns-suspects.feature
Normal file
84
features/api/moderation/detection-patterns-suspects.feature
Normal file
@@ -0,0 +1,84 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @ml @security @mvp
|
||||
Fonctionnalité: Détection de patterns suspects par ML
|
||||
|
||||
En tant que système de sécurité
|
||||
Je veux détecter automatiquement les comportements suspects
|
||||
Afin de prévenir les abus et fraudes
|
||||
|
||||
Scénario: Détection de signalements coordonnés
|
||||
Étant donné 5 utilisateurs qui signalent le même contenu en 10 minutes
|
||||
Et leurs comptes ont été créés la même semaine
|
||||
Quand le système analyse le pattern
|
||||
Alors une alerte "Brigade de signalement" est déclenchée
|
||||
Et les signalements sont mis en quarantaine
|
||||
Et un modérateur vérifie manuellement
|
||||
Et un événement "COORDINATED_REPORTING_DETECTED" est enregistré
|
||||
|
||||
Scénario: Détection de compte bot de signalement
|
||||
Étant donné un compte avec pattern suspect:
|
||||
| Indicateur | Valeur |
|
||||
| Signalements par jour | 50 |
|
||||
| Intervalle régulier | Exactement 120s |
|
||||
| Diversité de contenus | Faible |
|
||||
| Interaction humaine | Aucune |
|
||||
Quand le système ML analyse
|
||||
Alors le compte est identifié comme "Probable bot"
|
||||
Et suspendu automatiquement
|
||||
Et un événement "BOT_ACCOUNT_DETECTED" est enregistré
|
||||
|
||||
Scénario: Détection de vendetta personnelle
|
||||
Étant donné un utilisateur A qui signale systématiquement l'utilisateur B
|
||||
Et 15 signalements en 1 semaine, tous rejetés
|
||||
Quand le système détecte le pattern
|
||||
Alors une alerte "Harcèlement par signalements" est déclenchée
|
||||
Et l'utilisateur A est bloqué de signaler B
|
||||
Et un événement "VENDETTA_PATTERN_DETECTED" est enregistré
|
||||
|
||||
Scénario: Détection d'usage d'IA pour contenu offensant déguisé
|
||||
Étant donné un contenu avec texte subtil généré par IA
|
||||
Quand l'analyse NLP détecte des marqueurs d'IA toxique
|
||||
Alors le contenu est mis en quarantaine
|
||||
Et un modérateur expert vérifie
|
||||
Et un événement "AI_GENERATED_TOXIC_DETECTED" est enregistré
|
||||
|
||||
Scénario: Analyse des métadonnées EXIF suspectes
|
||||
Étant donné une image uploadée avec métadonnées:
|
||||
| Métadonnée | Valeur suspect |
|
||||
| GPS Location | Corée du Nord |
|
||||
| Device Model | Connu pour bots |
|
||||
| Timestamp | Futur (2027) |
|
||||
Quand le système analyse
|
||||
Alors l'image est marquée "Métadonnées suspectes"
|
||||
Et un événement "SUSPICIOUS_METADATA_DETECTED" est enregistré
|
||||
|
||||
Scénario: Score de risque ML combiné
|
||||
Étant donné un contenu analysé par ML
|
||||
Alors un score de risque global est calculé:
|
||||
| Facteur | Poids | Score |
|
||||
| Contenu textuel | 30% | 0.8 |
|
||||
| Métadonnées image | 20% | 0.3 |
|
||||
| Comportement utilisateur | 30% | 0.9 |
|
||||
| Patterns de signalement | 20% | 0.1 |
|
||||
| **Score global** | 100% | **0.65** |
|
||||
Et si score > 0.7, mise en quarantaine automatique
|
||||
Et un événement "ML_RISK_SCORE_CALCULATED" est enregistré
|
||||
|
||||
Scénario: Apprentissage continu du modèle ML
|
||||
Étant donné 10 000 contenus modérés manuellement
|
||||
Quand les décisions humaines sont collectées
|
||||
Alors le modèle ML est réentraîné mensuellement
|
||||
Et la précision s'améliore de 2-3% par itération
|
||||
Et un événement "ML_MODEL_RETRAINED" est enregistré
|
||||
|
||||
Scénario: Métriques de performance de la détection ML
|
||||
Étant donné que 50 000 contenus ont été analysés
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Précision de détection | 87% |
|
||||
| Rappel (contenus détectés) | 82% |
|
||||
| Faux positifs | 8% |
|
||||
| Temps moyen d'analyse | 250ms |
|
||||
| Économie de temps modérateurs | 60% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
51
features/api/moderation/limite-temporelle-anti-abus.feature
Normal file
51
features/api/moderation/limite-temporelle-anti-abus.feature
Normal file
@@ -0,0 +1,51 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @anti-abuse @mvp
|
||||
Fonctionnalité: Limites temporelles anti-abus de modération
|
||||
|
||||
En tant que plateforme
|
||||
Je veux limiter les signalements abusifs
|
||||
Afin de prévenir le spam et les abus du système
|
||||
|
||||
Scénario: Limitation à 20 signalements par jour
|
||||
Étant donné un utilisateur "alice@roadwave.fr" qui a fait 20 signalements aujourd'hui
|
||||
Quand il tente un 21ème signalement
|
||||
Alors le signalement est bloqué
|
||||
Et un message s'affiche: "Limite quotidienne atteinte (20 signalements). Réessayez demain."
|
||||
Et un événement "REPORT_DAILY_LIMIT_REACHED" est enregistré
|
||||
|
||||
Scénario: Limite augmentée pour utilisateurs de confiance
|
||||
Étant donné un utilisateur de confiance
|
||||
Alors sa limite quotidienne est de 50 signalements
|
||||
Et un événement "TRUSTED_USER_HIGHER_LIMIT" est enregistré
|
||||
|
||||
Scénario: Cooldown de 5 minutes entre signalements
|
||||
Étant donné un utilisateur qui vient de faire un signalement
|
||||
Quand il tente un nouveau signalement 2 minutes après
|
||||
Alors le signalement est bloqué
|
||||
Et un message affiche: "Attendez 3 minutes avant le prochain signalement"
|
||||
Et un événement "REPORT_COOLDOWN_ACTIVE" est enregistré
|
||||
|
||||
Scénario: Détection de signalements en masse suspects
|
||||
Étant donné un utilisateur qui fait 10 signalements en 10 minutes
|
||||
Quand le système détecte le pattern
|
||||
Alors une alerte modérateur est déclenchée
|
||||
Et l'utilisateur passe en review manuelle
|
||||
Et un événement "MASS_REPORTING_DETECTED" est enregistré
|
||||
|
||||
Scénario: Blocage temporaire pour abus répétés
|
||||
Étant donné un utilisateur avec 10 signalements rejetés en 24h
|
||||
Quand le 10ème est rejeté
|
||||
Alors l'utilisateur est bloqué de la modération pour 7 jours
|
||||
Et un message explique: "Trop de signalements invalides. Blocage temporaire."
|
||||
Et un événement "REPORTING_SUSPENDED_ABUSE" est enregistré
|
||||
|
||||
Scénario: Métriques de détection d'abus
|
||||
Étant donné que 1000 utilisateurs ont tenté d'abuser
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Tentatives de spam détectées | 1,234 |
|
||||
| Utilisateurs bloqués | 156 |
|
||||
| Faux positifs | 2% |
|
||||
| Taux de récidive après blocage | 15% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
56
features/api/moderation/reduction-premium-badge-or.feature
Normal file
56
features/api/moderation/reduction-premium-badge-or.feature
Normal file
@@ -0,0 +1,56 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @premium @rewards @mvp
|
||||
Fonctionnalité: Réduction Premium pour badge Or
|
||||
|
||||
En tant qu'utilisateur avec badge Or
|
||||
Je veux obtenir une réduction sur l'abonnement Premium
|
||||
Afin d'être récompensé de ma contribution
|
||||
|
||||
Scénario: Réduction automatique à l'obtention du badge Or
|
||||
Étant donné un utilisateur "alice@roadwave.fr" qui débloque le badge Or
|
||||
Quand il consulte la page Premium
|
||||
Alors une réduction de 20% est automatiquement appliquée
|
||||
Et le prix passe de 4.99€/mois à 3.99€/mois
|
||||
Et un événement "PREMIUM_DISCOUNT_GOLD_APPLIED" est enregistré
|
||||
|
||||
Scénario: Cumul avec autres réductions
|
||||
Étant donné un utilisateur avec badge Or ET statut Trusted
|
||||
Alors les réductions se cumulent:
|
||||
| Réduction | Montant |
|
||||
| Badge Or | -20% |
|
||||
| Utilisateur confiance| -10% |
|
||||
| Total | -30% |
|
||||
Et le prix final: 4.99€ - 30% = 3.49€/mois
|
||||
Et un événement "PREMIUM_DISCOUNTS_STACKED" est enregistré
|
||||
|
||||
Scénario: Badge Diamant - Premium gratuit à vie
|
||||
Étant donné un utilisateur avec badge Diamant
|
||||
Alors l'abonnement Premium est gratuit à vie
|
||||
Et aucun paiement n'est requis
|
||||
Et un badge spécial "Premium Lifetime" s'affiche
|
||||
Et un événement "PREMIUM_LIFETIME_GRANTED" est enregistré
|
||||
|
||||
Scénario: Perte de la réduction si perte du badge
|
||||
Étant donné un utilisateur avec badge Or et réduction active
|
||||
Quand le badge Or est révoqué (précision < 70%)
|
||||
Alors la réduction est supprimée au prochain renouvellement
|
||||
Et l'utilisateur est notifié 7 jours à l'avance
|
||||
Et un événement "PREMIUM_DISCOUNT_REVOKED" est enregistré
|
||||
|
||||
Scénario: Code promo automatique pour badge Or
|
||||
Étant donné un utilisateur "bob@roadwave.fr" avec badge Or
|
||||
Quand il s'abonne à Premium
|
||||
Alors un code promo "GOLD20" est automatiquement appliqué
|
||||
Et visible dans la facture
|
||||
Et un événement "PREMIUM_PROMO_CODE_APPLIED" est enregistré
|
||||
|
||||
Scénario: Statistiques d'impact des réductions
|
||||
Étant donné que 200 utilisateurs ont badge Or
|
||||
Alors les métriques montrent:
|
||||
| Métrique | Valeur |
|
||||
| Utilisateurs avec réduction | 200 |
|
||||
| Taux de conversion Premium (Or) | 45% |
|
||||
| Taux de conversion Premium (standard)| 12% |
|
||||
| Revenus générés malgré réduction | +35% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
42
features/api/moderation/sanctions-abus-progressives.feature
Normal file
42
features/api/moderation/sanctions-abus-progressives.feature
Normal file
@@ -0,0 +1,42 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @sanctions @mvp
|
||||
Fonctionnalité: Sanctions progressives pour abus de signalement
|
||||
|
||||
En tant que plateforme
|
||||
Je veux sanctionner les abus de signalement progressivement
|
||||
Afin de dissuader le spam et les faux signalements
|
||||
|
||||
Scénario: Premier abus - Avertissement
|
||||
Étant donné un utilisateur avec 3 faux signalements en 24h
|
||||
Quand le 3ème est confirmé comme faux
|
||||
Alors un avertissement est envoyé
|
||||
Et un message explique les règles
|
||||
Et un événement "ABUSE_WARNING_ISSUED" est enregistré
|
||||
|
||||
Scénario: Deuxième abus - Limitation temporaire
|
||||
Étant donné un utilisateur avec 2ème série de faux signalements
|
||||
Alors il est limité à 5 signalements par jour pendant 7 jours
|
||||
Et un événement "ABUSE_LIMITED_REPORTING" est enregistré
|
||||
|
||||
Scénario: Troisième abus - Suspension 30 jours
|
||||
Étant donné un utilisateur avec 3ème série d'abus
|
||||
Alors il perd le droit de signaler pendant 30 jours
|
||||
Et tous ses badges modération sont révoqués
|
||||
Et un événement "ABUSE_SUSPENDED_30D" est enregistré
|
||||
|
||||
Scénario: Quatrième abus - Bannissement définitif
|
||||
Étant donné un utilisateur avec 4ème série d'abus
|
||||
Alors il est définitivement banni de la modération
|
||||
Et ne peut jamais récupérer ce droit
|
||||
Et un événement "ABUSE_PERMANENT_BAN" est enregistré
|
||||
|
||||
Scénario: Métriques de sanctions
|
||||
Étant donné que 500 sanctions ont été appliquées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Sanction | Nombre | % |
|
||||
| Avertissements | 320 | 64% |
|
||||
| Limitations | 120 | 24% |
|
||||
| Suspensions 30j | 50 | 10% |
|
||||
| Bannissements | 10 | 2% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
43
features/api/moderation/sanctions-droits-auteur.feature
Normal file
43
features/api/moderation/sanctions-droits-auteur.feature
Normal file
@@ -0,0 +1,43 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @copyright @sanctions @mvp
|
||||
Fonctionnalité: Sanctions progressives pour violations droits d'auteur
|
||||
|
||||
En tant que plateforme
|
||||
Je veux appliquer des sanctions progressives
|
||||
Afin de dissuader les violations répétées
|
||||
|
||||
Scénario: Première infraction - Avertissement
|
||||
Étant donné un créateur "alice@roadwave.fr" première infraction
|
||||
Quand la violation est confirmée
|
||||
Alors un avertissement formel est envoyé
|
||||
Et le contenu est retiré
|
||||
Et aucune sanction sur le compte
|
||||
Et un événement "COPYRIGHT_WARNING_ISSUED" est enregistré
|
||||
|
||||
Scénario: Deuxième infraction - Suspension 7 jours
|
||||
Étant donné un créateur avec 2ème infraction
|
||||
Alors le compte est suspendu 7 jours
|
||||
Et tous les contenus sont masqués temporairement
|
||||
Et un événement "COPYRIGHT_SUSPENSION_7D" est enregistré
|
||||
|
||||
Scénario: Troisième infraction - Suspension 30 jours
|
||||
Étant donné un créateur avec 3ème infraction
|
||||
Alors le compte est suspendu 30 jours
|
||||
Et perte de tous les badges
|
||||
Et un événement "COPYRIGHT_SUSPENSION_30D" est enregistré
|
||||
|
||||
Scénario: Quatrième infraction - Bannissement définitif
|
||||
Étant donné un créateur avec 4ème infraction
|
||||
Alors le compte est définitivement banni
|
||||
Et tous les contenus sont supprimés
|
||||
Et l'email/IP sont blacklistés
|
||||
Et un événement "COPYRIGHT_PERMANENT_BAN" est enregistré
|
||||
|
||||
Scénario: Réhabilitation après bonne conduite
|
||||
Étant donné un créateur suspendu depuis 6 mois
|
||||
Et aucune nouvelle infraction
|
||||
Quand il demande une réhabilitation
|
||||
Alors son historique peut être effacé
|
||||
Et il repart avec un compteur à zéro
|
||||
Et un événement "COPYRIGHT_REHABILITATION_GRANTED" est enregistré
|
||||
82
features/api/moderation/score-fiabilite-priorisation.feature
Normal file
82
features/api/moderation/score-fiabilite-priorisation.feature
Normal file
@@ -0,0 +1,82 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @scoring @mvp
|
||||
Fonctionnalité: Score de fiabilité et priorisation des signalements
|
||||
|
||||
En tant que système de modération
|
||||
Je veux prioriser les signalements selon la fiabilité du rapporteur
|
||||
Afin d'optimiser le traitement par les modérateurs
|
||||
|
||||
Scénario: Calcul du score de fiabilité
|
||||
Étant donné un utilisateur "alice@roadwave.fr" avec historique:
|
||||
| Signalements totaux | Validés | Rejetés | Taux de précision |
|
||||
| 50 | 48 | 2 | 96% |
|
||||
Alors son score de fiabilité est: 96/100
|
||||
Et un événement "RELIABILITY_SCORE_CALCULATED" est enregistré
|
||||
|
||||
Scénario: Priorisation haute pour utilisateurs fiables
|
||||
Étant donné un utilisateur avec score 95+
|
||||
Quand il fait un signalement
|
||||
Alors le signalement est marqué "Priorité haute"
|
||||
Et traité en < 2 heures
|
||||
Et un événement "HIGH_PRIORITY_REPORT_QUEUED" est enregistré
|
||||
|
||||
Scénario: Priorisation normale pour nouveaux utilisateurs
|
||||
Étant donné un nouvel utilisateur sans historique
|
||||
Quand il fait un signalement
|
||||
Alors le signalement est marqué "Priorité normale"
|
||||
Et traité en < 24 heures
|
||||
Et un événement "NORMAL_PRIORITY_REPORT_QUEUED" est enregistré
|
||||
|
||||
Scénario: Priorisation basse pour utilisateurs peu fiables
|
||||
Étant donné un utilisateur avec score < 60
|
||||
Quand il fait un signalement
|
||||
Alors le signalement est marqué "Priorité basse"
|
||||
Et traité en < 72 heures
|
||||
Et nécessite une vérification renforcée
|
||||
Et un événement "LOW_PRIORITY_REPORT_QUEUED" est enregistré
|
||||
|
||||
Scénario: Augmentation du score après signalements validés
|
||||
Étant donné un utilisateur avec score 70
|
||||
Quand 10 signalements consécutifs sont validés
|
||||
Alors le score passe à 85
|
||||
Et il monte de catégorie (basse → normale)
|
||||
Et un événement "RELIABILITY_SCORE_INCREASED" est enregistré
|
||||
|
||||
Scénario: Diminution du score après faux signalements
|
||||
Étant donné un utilisateur avec score 90
|
||||
Quand 5 signalements consécutifs sont rejetés
|
||||
Alors le score passe à 75
|
||||
Et il redescend de catégorie (haute → normale)
|
||||
Et un avertissement est envoyé
|
||||
Et un événement "RELIABILITY_SCORE_DECREASED" est enregistré
|
||||
|
||||
Scénario: Réinitialisation du score après inactivité
|
||||
Étant donné un utilisateur inactif pendant 6 mois
|
||||
Quand il refait un signalement
|
||||
Alors son score est réinitialisé à 50 (neutre)
|
||||
Et il doit reconstruire sa réputation
|
||||
Et un événement "RELIABILITY_SCORE_RESET" est enregistré
|
||||
|
||||
Scénario: Affichage du score dans le profil
|
||||
Étant donné un utilisateur "bob@roadwave.fr"
|
||||
Quand il consulte son profil
|
||||
Alors il voit:
|
||||
| Métrique | Valeur |
|
||||
| Score de fiabilité | 87/100 |
|
||||
| Signalements validés | 145 |
|
||||
| Taux de précision | 87% |
|
||||
| Catégorie | Haute |
|
||||
Et un graphique d'évolution du score
|
||||
Et un événement "RELIABILITY_SCORE_VIEWED" est enregistré
|
||||
|
||||
Scénario: Métriques de performance de la priorisation
|
||||
Étant donné que 10 000 signalements ont été traités
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Temps moyen de traitement (haute) | 1.5h |
|
||||
| Temps moyen de traitement (normale) | 18h |
|
||||
| Temps moyen de traitement (basse) | 48h |
|
||||
| Taux de validation (haute) | 92% |
|
||||
| Taux de validation (basse) | 65% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
@@ -0,0 +1,53 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @copyright @mvp
|
||||
Fonctionnalité: Signalement musique a posteriori
|
||||
|
||||
En tant qu'ayant-droit ou utilisateur
|
||||
Je veux signaler une utilisation musicale non conforme
|
||||
Afin de faire respecter les droits d'auteur
|
||||
|
||||
Scénario: Signalement par un ayant-droit
|
||||
Étant donné un ayant-droit "Universal Music"
|
||||
Quand il signale un contenu avec sa musique
|
||||
Alors un formulaire DMCA est pré-rempli
|
||||
Et le contenu est immédiatement suspendu (safe harbor)
|
||||
Et le créateur est notifié
|
||||
Et un événement "COPYRIGHT_CLAIM_FILED" est enregistré
|
||||
|
||||
Scénario: Vérification du signalement par modérateur
|
||||
Étant donné un signalement reçu
|
||||
Quand un modérateur l'examine
|
||||
Alors il écoute le contenu
|
||||
Et vérifie si fair use (< 30s)
|
||||
Et prend une décision dans les 48h
|
||||
Et un événement "COPYRIGHT_CLAIM_REVIEWED" est enregistré
|
||||
|
||||
Scénario: Contre-signalement du créateur
|
||||
Étant donné un créateur "alice@roadwave.fr" dont le contenu est suspendu
|
||||
Quand il fait un counter-claim avec preuve
|
||||
Alors le dossier est transmis à l'ayant-droit
|
||||
Et celui-ci a 14 jours pour répondre
|
||||
Et un événement "COPYRIGHT_COUNTER_CLAIM_FILED" est enregistré
|
||||
|
||||
Scénario: Rétablissement du contenu si fair use validé
|
||||
Étant donné un contenu suspendu
|
||||
Quand le modérateur confirme le fair use
|
||||
Alors le contenu est rétabli
|
||||
Et le signalement est rejeté
|
||||
Et le créateur est notifié
|
||||
Et un événement "COPYRIGHT_CLAIM_REJECTED" est enregistré
|
||||
|
||||
Scénario: Sanctions pour abus de signalement
|
||||
Étant donné un ayant-droit qui abuse des signalements
|
||||
Quand 3 signalements consécutifs sont rejetés
|
||||
Alors son compte est suspendu temporairement
|
||||
Et un événement "COPYRIGHT_CLAIMANT_SUSPENDED" est enregistré
|
||||
|
||||
Scénario: Historique des signalements pour un créateur
|
||||
Étant donné un créateur "bob@roadwave.fr"
|
||||
Alors il voit ses signalements:
|
||||
| Date | Ayant-droit | Statut | Issue |
|
||||
| 2026-02-01 | Sony Music | Résolu | Fair use OK|
|
||||
| 2026-01-10 | Warner | Confirmé | Contenu retiré|
|
||||
Et un événement "COPYRIGHT_HISTORY_VIEWED" est enregistré
|
||||
63
features/api/moderation/utilisateur-confiance.feature
Normal file
63
features/api/moderation/utilisateur-confiance.feature
Normal file
@@ -0,0 +1,63 @@
|
||||
# language: fr
|
||||
|
||||
@api @moderation @trust @mvp
|
||||
Fonctionnalité: Statut utilisateur de confiance
|
||||
|
||||
En tant qu'utilisateur méritant
|
||||
Je veux obtenir le statut "Utilisateur de confiance"
|
||||
Afin de bénéficier de privilèges et reconnaissance
|
||||
|
||||
Scénario: Critères d'obtention du statut
|
||||
Étant donné un utilisateur "alice@roadwave.fr" qui remplit:
|
||||
| Critère | Requis | Actuel |
|
||||
| Compte actif depuis | 6 mois | 8 mois |
|
||||
| Signalements validés | 100 | 150 |
|
||||
| Taux de précision | 90% | 94% |
|
||||
| Badge modération | Or | Or |
|
||||
| Aucune sanction | Oui | Oui |
|
||||
Quand les critères sont remplis
|
||||
Alors le statut "Utilisateur de confiance" est accordé
|
||||
Et un événement "TRUSTED_USER_STATUS_GRANTED" est enregistré
|
||||
|
||||
Scénario: Privilèges de l'utilisateur de confiance
|
||||
Étant donné un utilisateur de confiance
|
||||
Alors il bénéficie de:
|
||||
| Privilège | Détail |
|
||||
| Signalements traités en priorité | < 1h au lieu de 24h |
|
||||
| Modération de commentaires | Peut masquer spam/haine |
|
||||
| Badge profil "Trusted" | Visible publiquement |
|
||||
| Réduction Premium -20% | Sur abonnement annuel |
|
||||
| Accès beta features | Nouvelles fonctionnalités |
|
||||
Et un événement "TRUSTED_USER_PRIVILEGES_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Badge "Trusted" visible sur le profil
|
||||
Étant donné un utilisateur de confiance
|
||||
Quand son profil est consulté
|
||||
Alors un badge bleu "✓ Utilisateur de confiance" s'affiche
|
||||
Et une tooltip explique le statut
|
||||
Et un événement "TRUSTED_BADGE_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Révocation du statut pour inactivité
|
||||
Étant donné un utilisateur de confiance inactif 6 mois
|
||||
Quand le système vérifie les statuts
|
||||
Alors le statut est révoqué automatiquement
|
||||
Et l'utilisateur est notifié
|
||||
Et peut le retrouver en redevenant actif
|
||||
Et un événement "TRUSTED_STATUS_REVOKED_INACTIVITY" est enregistré
|
||||
|
||||
Scénario: Révocation du statut pour baisse de précision
|
||||
Étant donné un utilisateur de confiance
|
||||
Quand son taux de précision passe < 85%
|
||||
Alors le statut est révoqué temporairement
|
||||
Et il doit retrouver 90% pour le récupérer
|
||||
Et un événement "TRUSTED_STATUS_REVOKED_LOW_ACCURACY" est enregistré
|
||||
|
||||
Scénario: Statistiques des utilisateurs de confiance
|
||||
Étant donné que 500 utilisateurs ont le statut
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Nombre d'utilisateurs de confiance| 500 |
|
||||
| % de la base utilisateurs | 0.5% |
|
||||
| Temps moyen pour obtenir statut | 8 mois |
|
||||
| Taux de rétention du statut | 92% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
234
features/api/navigation/auto-switching-modes.feature
Normal file
234
features/api/navigation/auto-switching-modes.feature
Normal file
@@ -0,0 +1,234 @@
|
||||
# language: fr
|
||||
|
||||
@api @navigation @mode-detection @mvp
|
||||
Fonctionnalité: Basculement automatique entre modes voiture et piéton
|
||||
|
||||
En tant que système de navigation
|
||||
Je veux détecter automatiquement le mode de déplacement de l'utilisateur
|
||||
Et basculer entre mode voiture et mode piéton selon la vitesse GPS
|
||||
Afin d'optimiser l'expérience utilisateur sans action manuelle
|
||||
|
||||
Contexte:
|
||||
Étant donné un utilisateur authentifié avec l'application active
|
||||
Et la géolocalisation est activée et autorisée
|
||||
Et les permissions de géolocalisation en arrière-plan sont accordées
|
||||
|
||||
# ============================================================================
|
||||
# DÉTECTION INITIALE DU MODE AU DÉMARRAGE
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Démarrage application à vitesse piéton (0-4 km/h)
|
||||
Étant donné l'utilisateur ouvre l'application
|
||||
Et les 3 premières lectures GPS montrent des vitesses de [0, 2, 3] km/h
|
||||
Quand le système détermine le mode initial
|
||||
Alors le mode "piéton" doit être activé par défaut
|
||||
Et les notifications push géolocalisées doivent être activées
|
||||
Et un rayon de détection de 200m doit être appliqué
|
||||
|
||||
Scénario: Démarrage application en mouvement (≥5 km/h)
|
||||
Étant donné l'utilisateur ouvre l'application
|
||||
Et les 3 premières lectures GPS montrent des vitesses de [30, 35, 32] km/h
|
||||
Quand le système détermine le mode initial
|
||||
Alors le mode "voiture" doit être activé par défaut
|
||||
Et les notifications in-app avec compteur 7s doivent être activées
|
||||
Et l'ETA doit être calculé pour les contenus géolocalisés
|
||||
|
||||
Scénario: Démarrage avec GPS instable - mode par défaut
|
||||
Étant donné l'utilisateur ouvre l'application
|
||||
Et les lectures GPS sont erratiques : [0, 45, 2, 60, 1] km/h
|
||||
Quand le système ne peut pas déterminer le mode avec confiance
|
||||
Alors le mode "piéton" doit être activé par défaut (mode le plus sûr)
|
||||
Et une modal doit demander à l'utilisateur de confirmer son mode
|
||||
Et le choix utilisateur doit être mémorisé pour la session
|
||||
|
||||
# ============================================================================
|
||||
# BASCULEMENT VOITURE → PIÉTON (vitesse <5 km/h soutenue)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Arrêt prolongé déclenche basculement piéton
|
||||
Étant donné l'utilisateur est en mode voiture
|
||||
Et la vitesse moyenne sur 2 minutes est de 2 km/h (embouteillage ou arrêt)
|
||||
Quand le système détecte cette condition pendant 2 minutes consécutives
|
||||
Alors le mode doit basculer automatiquement vers "piéton"
|
||||
Et une notification toast doit informer : "Mode piéton activé"
|
||||
Et les notifications push géolocalisées doivent être activées
|
||||
Et le cooldown voiture actif doit être annulé
|
||||
|
||||
Scénario: Stationnement confirmé (vitesse = 0 pendant 2 minutes)
|
||||
Étant donné l'utilisateur est en mode voiture
|
||||
Et la vitesse GPS est de 0 km/h pendant 2 minutes consécutives
|
||||
Et la précision GPS est <20m (pas de perte signal)
|
||||
Quand le système détecte l'arrêt prolongé
|
||||
Alors le mode doit basculer vers "piéton"
|
||||
Et une notification doit proposer : "Voulez-vous activer le mode piéton ?"
|
||||
Et si l'utilisateur ne répond pas, le basculement doit être automatique après 30 secondes
|
||||
|
||||
Scénario: Embouteillage prolongé (vitesse <5 km/h mais en mouvement)
|
||||
Étant donné l'utilisateur est en mode voiture à 35 km/h
|
||||
Et la vitesse chute à 3 km/h et oscille entre 0-4 km/h
|
||||
Et cette condition dure 3 minutes
|
||||
Quand le système détecte un mouvement résiduel (pas totalement arrêté)
|
||||
Alors le mode "voiture" doit être maintenu temporairement
|
||||
Mais le calcul ETA doit passer en mode "vitesse lente"
|
||||
Et après 5 minutes <5 km/h, le mode piéton doit être proposé
|
||||
|
||||
Scénario: Feu rouge ou arrêt temporaire ne déclenche PAS de basculement
|
||||
Étant donné l'utilisateur est en mode voiture à 50 km/h
|
||||
Et la vitesse chute à 0 km/h pendant 45 secondes (feu rouge)
|
||||
Quand le système évalue les conditions
|
||||
Alors le mode "voiture" doit être maintenu
|
||||
Car la durée <2 minutes (seuil de basculement)
|
||||
Et aucune notification ne doit être affichée
|
||||
|
||||
# ============================================================================
|
||||
# BASCULEMENT PIÉTON → VOITURE (vitesse ≥5 km/h soutenue)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Démarrage voiture déclenche basculement automatique
|
||||
Étant donné l'utilisateur est en mode piéton
|
||||
Et la vitesse passe de 0 km/h à 15 km/h en 10 secondes
|
||||
Et la vitesse reste ≥10 km/h pendant 30 secondes
|
||||
Quand le système détecte une accélération soutenue
|
||||
Alors le mode doit basculer automatiquement vers "voiture"
|
||||
Et une notification toast doit informer : "Mode voiture activé"
|
||||
Et les notifications in-app avec ETA doivent être activées
|
||||
Et les notifications push piéton doivent être désactivées
|
||||
|
||||
Scénario: Course à pied ou vélo lent ne déclenche PAS de basculement voiture
|
||||
Étant donné l'utilisateur est en mode piéton
|
||||
Et la vitesse monte à 8 km/h et oscille entre 6-10 km/h
|
||||
Quand le système évalue les conditions
|
||||
Alors le mode "piéton" doit être maintenu
|
||||
Car la vitesse reste <15 km/h (seuil de confiance pour voiture)
|
||||
Et l'utilisateur peut basculer manuellement si nécessaire
|
||||
|
||||
Scénario: Trajet en bus ou vélo rapide (15-25 km/h)
|
||||
Étant donné l'utilisateur est en mode piéton
|
||||
Et la vitesse passe à 20 km/h et reste stable
|
||||
Quand le système détecte une vitesse ≥15 km/h pendant 1 minute
|
||||
Alors une notification doit proposer : "Passer en mode véhicule ?"
|
||||
Et si l'utilisateur accepte, basculer en mode "voiture"
|
||||
Et si l'utilisateur refuse, mémoriser le choix pour 30 minutes
|
||||
|
||||
Scénario: Sortie de transport en commun
|
||||
Étant donné l'utilisateur est en mode piéton
|
||||
Et la vitesse était de 0 km/h (dans le bus)
|
||||
Et la vitesse monte soudainement à 40 km/h (bus démarre)
|
||||
Puis retombe à 2 km/h après 5 minutes (descente du bus)
|
||||
Quand le système détecte ce pattern
|
||||
Alors le mode "piéton" doit être maintenu
|
||||
Et aucun basculement automatique ne doit être déclenché
|
||||
Car les transports en commun sont ambigus
|
||||
|
||||
# ============================================================================
|
||||
# BASCULEMENT AVEC AUDIO-GUIDE EN COURS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Basculement voiture → piéton pendant audio-guide voiture
|
||||
Étant donné l'utilisateur écoute un audio-guide en mode voiture
|
||||
Et l'utilisateur se gare (vitesse = 0 km/h pendant 2 minutes)
|
||||
Quand le système bascule en mode piéton
|
||||
Alors l'audio-guide doit continuer en mode piéton
|
||||
Et les séquences restantes doivent s'adapter au mode piéton :
|
||||
| voiture | piéton |
|
||||
| Déclenchement automatique GPS | Navigation manuelle |
|
||||
| Distance affichée en mètres | Distance masquée |
|
||||
| Flèche direction | Pas de flèche |
|
||||
Et une notification doit informer : "Audio-guide adapté au mode piéton"
|
||||
|
||||
Scénario: Basculement piéton → voiture pendant audio-guide piéton
|
||||
Étant donné l'utilisateur écoute un audio-guide en mode piéton
|
||||
Et l'audio-guide est configuré pour "piéton uniquement"
|
||||
Et l'utilisateur monte en voiture (vitesse passe à 30 km/h)
|
||||
Quand le système bascule en mode voiture
|
||||
Alors l'audio-guide doit être mis en pause automatiquement
|
||||
Et une notification doit proposer : "Mettre l'audio-guide en pause ?"
|
||||
Et si confirmé, sauvegarder la progression pour reprise ultérieure
|
||||
|
||||
# ============================================================================
|
||||
# GESTION DES TRANSITIONS ET EDGE CASES
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Basculement rapide voiture → piéton → voiture (indécision)
|
||||
Étant donné l'utilisateur est en mode voiture
|
||||
Et la vitesse oscille : 40 km/h → 0 km/h (1 min) → 35 km/h → 0 km/h (1 min)
|
||||
Quand le système détecte une instabilité de mode
|
||||
Alors le mode "voiture" doit être maintenu par défaut
|
||||
Et un délai de stabilisation de 3 minutes doit être appliqué
|
||||
Et aucune notification de basculement ne doit être envoyée
|
||||
|
||||
Scénario: Tunnel ou perte GPS ne déclenche PAS de basculement
|
||||
Étant donné l'utilisateur est en mode voiture à 90 km/h
|
||||
Et le signal GPS est perdu pendant 2 minutes (tunnel)
|
||||
Quand le système détecte l'absence de signal GPS
|
||||
Alors le mode "voiture" doit être maintenu
|
||||
Et la dernière vitesse connue doit être utilisée
|
||||
Et aucun basculement ne doit être déclenché
|
||||
|
||||
Scénario: Utilisateur force le mode manuellement
|
||||
Étant donné l'utilisateur est en mode voiture automatique
|
||||
Et l'utilisateur bascule manuellement en mode piéton via l'interface
|
||||
Quand le basculement manuel est effectué
|
||||
Alors le mode manuel doit être prioritaire pendant 30 minutes
|
||||
Et les basculements automatiques doivent être désactivés pendant cette période
|
||||
Et un flag "manual_override" doit être loggé
|
||||
|
||||
Scénario: Reprise après override manuel
|
||||
Étant donné l'utilisateur a forcé le mode piéton il y a 35 minutes
|
||||
Et la vitesse actuelle est de 60 km/h depuis 5 minutes
|
||||
Quand la période d'override (30 min) expire
|
||||
Alors le système doit reprendre la détection automatique
|
||||
Et basculer en mode voiture car vitesse ≥5 km/h
|
||||
Et notifier l'utilisateur du basculement
|
||||
|
||||
# ============================================================================
|
||||
# IMPACT SUR LES AUTRES FONCTIONNALITÉS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Basculement annule le cooldown notification voiture
|
||||
Étant donné l'utilisateur est en mode voiture
|
||||
Et un cooldown de 10 minutes est actif (notification ignorée)
|
||||
Quand le mode bascule vers piéton
|
||||
Alors le cooldown doit être immédiatement annulé
|
||||
Et les notifications piéton doivent être activées
|
||||
Car les mécanismes de notification sont différents entre modes
|
||||
|
||||
Scénario: Basculement adapte le rayon de détection géolocalisée
|
||||
Étant donné l'utilisateur est en mode voiture
|
||||
Et le rayon de détection pour contenus géolocalisés est adaptatif (basé sur vitesse)
|
||||
Quand le mode bascule vers piéton
|
||||
Alors le rayon de détection doit être fixé à 200m
|
||||
Et les contenus hors rayon doivent être retirés de la file d'attente
|
||||
Et une nouvelle recherche géospatiale doit être effectuée
|
||||
|
||||
Scénario: Quota notifications indépendant du mode
|
||||
Étant donné l'utilisateur a reçu 4 notifications en mode voiture (quota 4/6)
|
||||
Quand le mode bascule vers piéton
|
||||
Alors le compteur de quota doit être conservé (toujours 4/6)
|
||||
Car le quota de 6/heure s'applique globalement (tous modes confondus)
|
||||
|
||||
# ============================================================================
|
||||
# MÉTRIQUES & ANALYTICS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Logging des basculements de mode pour analytics
|
||||
Étant donné l'utilisateur bascule de voiture à piéton
|
||||
Quand le basculement est effectué
|
||||
Alors un événement analytics doit être loggé :
|
||||
| event_type | mode_switch |
|
||||
| from_mode | car |
|
||||
| to_mode | pedestrian |
|
||||
| trigger | speed_threshold |
|
||||
| speed_kmh | 1.5 |
|
||||
| duration_previous_mode | 1800 |
|
||||
| manual_override | false |
|
||||
| timestamp | 2026-02-03 14:30:00 |
|
||||
Et ces métriques doivent alimenter le dashboard de monitoring
|
||||
|
||||
Scénario: Détection pattern utilisateur (majoritairement piéton vs voiture)
|
||||
Étant donné l'utilisateur utilise l'application depuis 30 jours
|
||||
Et 80% du temps d'écoute est en mode piéton
|
||||
Quand le système analyse le comportement
|
||||
Alors un flag "primary_mode: pedestrian" doit être défini
|
||||
Et le mode par défaut au démarrage doit être "piéton"
|
||||
Et l'algorithme de recommandation doit favoriser les audio-guides piétons
|
||||
56
features/api/navigation/decompte-5s-transition.feature
Normal file
56
features/api/navigation/decompte-5s-transition.feature
Normal file
@@ -0,0 +1,56 @@
|
||||
# language: fr
|
||||
|
||||
@api @navigation @transitions @mvp
|
||||
Fonctionnalité: Décompte 5 secondes pour transitions séquences
|
||||
|
||||
En tant qu'utilisateur
|
||||
Je veux un décompte avant le début d'une nouvelle séquence
|
||||
Afin de me préparer mentalement à l'écoute du nouveau contenu
|
||||
|
||||
Scénario: Décompte visuel et audio avant nouvelle séquence
|
||||
Étant donné un utilisateur "alice@roadwave.fr" qui termine une séquence
|
||||
Quand la suivante est sur le point de démarrer
|
||||
Alors un décompte de 5 secondes est affiché: "5... 4... 3... 2... 1..."
|
||||
Et un son subtil accompagne chaque seconde
|
||||
Et un événement "TRANSITION_COUNTDOWN_STARTED" est enregistré
|
||||
|
||||
Scénario: Possibilité de skip le décompte
|
||||
Étant donné un utilisateur "bob@roadwave.fr" pendant un décompte
|
||||
Quand il appuie sur "Passer"
|
||||
Alors la séquence suivante démarre immédiatement
|
||||
Et le décompte est interrompu
|
||||
Et un événement "TRANSITION_COUNTDOWN_SKIPPED" est enregistré
|
||||
|
||||
Scénario: Annulation du décompte si utilisateur s'éloigne
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" avec décompte en cours
|
||||
Quand il s'éloigne du point d'intérêt pendant le décompte
|
||||
Alors le décompte est annulé
|
||||
Et la séquence ne démarre pas
|
||||
Et un événement "TRANSITION_COUNTDOWN_CANCELLED" est enregistré
|
||||
|
||||
Scénario: Prévisualisation du prochain point pendant le décompte
|
||||
Étant donné un utilisateur "david@roadwave.fr" pendant un décompte
|
||||
Alors il voit une carte de prévisualisation:
|
||||
| Élément | Contenu |
|
||||
| Nom de la séquence| Panthéon |
|
||||
| Durée | 8 min 30s |
|
||||
| Distance | Vous y êtes |
|
||||
| Image | Photo du Panthéon |
|
||||
Et un événement "TRANSITION_PREVIEW_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Désactivation du décompte dans les paramètres
|
||||
Étant donné un utilisateur "eve@roadwave.fr"
|
||||
Quand elle désactive "Décompte de transition" dans les paramètres
|
||||
Alors les séquences démarrent immédiatement
|
||||
Sans décompte de 5 secondes
|
||||
Et un événement "TRANSITION_COUNTDOWN_DISABLED" est enregistré
|
||||
|
||||
Scénario: Métriques d'utilisation du décompte
|
||||
Étant donné que 10 000 transitions ont eu lieu
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Taux de skip du décompte | 25% |
|
||||
| Taux de complétion du décompte| 70% |
|
||||
| Taux d'annulation | 5% |
|
||||
| Satisfaction utilisateur | 4.2/5 |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
163
features/api/navigation/eta-calculation.feature
Normal file
163
features/api/navigation/eta-calculation.feature
Normal file
@@ -0,0 +1,163 @@
|
||||
# language: fr
|
||||
|
||||
@api @navigation @geolocation @mvp
|
||||
Fonctionnalité: Calcul ETA et notification contenus géolocalisés
|
||||
|
||||
En tant que système de recommandation
|
||||
Je veux calculer le temps d'arrivée estimé (ETA) pour les contenus géolocalisés
|
||||
Afin de déclencher la notification au bon moment (7 secondes avant)
|
||||
|
||||
Contexte:
|
||||
Étant donné un utilisateur authentifié en mode voiture
|
||||
Et la géolocalisation est activée et autorisée
|
||||
|
||||
# ============================================================================
|
||||
# CALCUL ETA VITESSE NORMALE (≥5 km/h)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Calcul ETA avec vitesse constante 50 km/h
|
||||
Étant donné un contenu géolocalisé situé à 300m de l'utilisateur
|
||||
Et l'utilisateur se déplace à 50 km/h en direction du point
|
||||
Quand le système calcule l'ETA
|
||||
Alors l'ETA estimé doit être d'environ 21 secondes
|
||||
Et la notification doit être déclenchée dans 14 secondes (21s - 7s)
|
||||
|
||||
Scénario: Recalcul ETA en temps réel avec variation de vitesse
|
||||
Étant donné un contenu géolocalisé situé à 500m
|
||||
Et l'utilisateur se déplace initialement à 70 km/h
|
||||
Et l'ETA initial est de 25 secondes
|
||||
Quand l'utilisateur ralentit à 30 km/h
|
||||
Alors l'ETA doit être recalculé à 60 secondes
|
||||
Et le délai de notification doit être ajusté en conséquence
|
||||
|
||||
Scénario: Notification déclenchée exactement 7 secondes avant l'arrivée
|
||||
Étant donné un contenu géolocalisé situé à 150m
|
||||
Et l'utilisateur se déplace à 60 km/h
|
||||
Et l'ETA calculé est de 9 secondes
|
||||
Quand l'ETA atteint 7 secondes
|
||||
Alors une notification push doit être envoyée
|
||||
Et la notification doit contenir un compteur visuel de 7 à 1
|
||||
Et un son de notification doit être joué
|
||||
|
||||
Scénario: Pas de notification si l'utilisateur dévie de la trajectoire
|
||||
Étant donné un contenu géolocalisé situé à 200m au nord
|
||||
Et l'utilisateur se déplace à 50 km/h en direction du contenu
|
||||
Et l'ETA est de 14 secondes
|
||||
Quand l'utilisateur change de direction vers l'est
|
||||
Et la distance au contenu commence à augmenter
|
||||
Alors la notification ne doit pas être déclenchée
|
||||
Et l'ETA doit être invalidé
|
||||
|
||||
# ============================================================================
|
||||
# CAS VITESSE LENTE (<5 km/h)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Notification immédiate si vitesse <5 km/h et distance <50m
|
||||
Étant donné un contenu géolocalisé situé à 30m
|
||||
Et l'utilisateur se déplace à 3 km/h (piéton ou embouteillage)
|
||||
Quand le système détecte la vitesse <5 km/h
|
||||
Alors la notification doit être déclenchée immédiatement
|
||||
Et le message doit indiquer "Contenu disponible à proximité"
|
||||
|
||||
Scénario: Pas de notification si vitesse <5 km/h mais distance >50m
|
||||
Étant donné un contenu géolocalisé situé à 80m
|
||||
Et l'utilisateur se déplace à 4 km/h
|
||||
Quand le système évalue les conditions de notification
|
||||
Alors aucune notification ne doit être envoyée
|
||||
Et le système doit attendre que la distance soit <50m ou vitesse ≥5 km/h
|
||||
|
||||
Scénario: Basculement vitesse normale → lente avec recalcul
|
||||
Étant donné un contenu géolocalisé situé à 100m
|
||||
Et l'utilisateur se déplace à 40 km/h (ETA = 9s, notification dans 2s)
|
||||
Quand l'utilisateur ralentit brutalement à 2 km/h (embouteillage)
|
||||
Et la vitesse reste <5 km/h pendant 5 secondes
|
||||
Et la distance est maintenant 85m
|
||||
Alors le mode de calcul ETA doit basculer en "vitesse lente"
|
||||
Et la notification immédiate ne doit pas être envoyée (distance >50m)
|
||||
|
||||
Scénario: Notification immédiate en approche lente continue
|
||||
Étant donné un contenu géolocalisé situé à 60m
|
||||
Et l'utilisateur se déplace à 3 km/h
|
||||
Quand l'utilisateur atteint 45m du point (distance <50m)
|
||||
Alors la notification doit être déclenchée immédiatement
|
||||
Et le compteur visuel doit afficher "À proximité"
|
||||
|
||||
# ============================================================================
|
||||
# GESTION TRAJECTOIRES COMPLEXES
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Route sinueuse avec distance GPS ≠ distance réelle
|
||||
Étant donné un contenu géolocalisé situé à 250m à vol d'oiseau
|
||||
Mais la route sinueuse fait 400m de trajet réel
|
||||
Et l'utilisateur se déplace à 50 km/h
|
||||
Quand le système calcule l'ETA
|
||||
Alors l'ETA doit utiliser la distance GPS (250m) par défaut
|
||||
Et l'ETA estimé doit être d'environ 18 secondes
|
||||
Et une marge d'erreur de ±3 secondes doit être tolérée
|
||||
|
||||
Scénario: Contenu sur autoroute parallèle non accessible
|
||||
Étant donné un contenu géolocalisé sur une autoroute parallèle à 100m
|
||||
Et l'utilisateur roule sur une route secondaire sans accès direct
|
||||
Et la distance GPS est de 100m mais l'accès réel est à 2 km
|
||||
Quand le système détecte que l'utilisateur s'éloigne après 10 secondes
|
||||
Alors la notification ne doit pas être déclenchée
|
||||
Et le contenu doit être retiré de la file d'attente
|
||||
|
||||
# ============================================================================
|
||||
# EDGE CASES & ERREURS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: GPS imprécis (précision >50m)
|
||||
Étant donné un contenu géolocalisé situé à 150m
|
||||
Et la précision GPS actuelle est de 65m
|
||||
Quand le système calcule l'ETA
|
||||
Alors l'ETA doit être calculé avec une marge d'erreur élevée
|
||||
Et la notification doit être différée de 2 secondes supplémentaires
|
||||
Et un flag "low_accuracy" doit être ajouté aux métriques
|
||||
|
||||
Scénario: Vitesse nulle (stationnement) avec contenu proche
|
||||
Étant donné un contenu géolocalisé situé à 25m
|
||||
Et l'utilisateur est à l'arrêt (vitesse = 0 km/h) depuis 10 secondes
|
||||
Quand le système évalue les conditions
|
||||
Alors aucune notification ne doit être envoyée automatiquement
|
||||
Et le contenu doit être affiché dans la file d'attente manuelle
|
||||
Et l'utilisateur peut le sélectionner manuellement
|
||||
|
||||
Scénario: Perte signal GPS pendant le calcul ETA
|
||||
Étant donné un contenu géolocalisé avec ETA de 12 secondes
|
||||
Et une notification prévue dans 5 secondes
|
||||
Quand le signal GPS est perdu (tunnel)
|
||||
Alors le calcul ETA doit être gelé à la dernière valeur connue
|
||||
Et la notification doit être déclenchée selon l'ETA gelé
|
||||
Et un fallback de 10 secondes max doit être appliqué
|
||||
|
||||
Scénario: Vitesse erratique (GPS instable)
|
||||
Étant donné un contenu géolocalisé situé à 200m
|
||||
Et les lectures GPS montrent : 50 km/h → 5 km/h → 60 km/h → 10 km/h en 10 secondes
|
||||
Quand le système détecte une instabilité GPS
|
||||
Alors l'ETA doit être calculé avec une moyenne mobile sur 5 secondes
|
||||
Et la notification ne doit être déclenchée qu'avec une confiance >70%
|
||||
|
||||
# ============================================================================
|
||||
# MÉTRIQUES & LOGS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Logging des calculs ETA pour analytics
|
||||
Étant donné un contenu géolocalisé avec notification déclenchée
|
||||
Quand la notification est envoyée
|
||||
Alors un événement analytics doit être loggé avec :
|
||||
| distance_meters | 180 |
|
||||
| speed_kmh | 55 |
|
||||
| eta_seconds | 11.7 |
|
||||
| notification_offset | 7 |
|
||||
| gps_accuracy_meters | 12 |
|
||||
| calculation_method | standard_eta |
|
||||
Et la timestamp de notification doit être enregistrée
|
||||
|
||||
Scénario: Comparaison ETA prédit vs ETA réel
|
||||
Étant donné un contenu géolocalisé avec ETA prédit de 15 secondes
|
||||
Et une notification déclenchée à 8 secondes avant
|
||||
Quand l'utilisateur atteint réellement le point
|
||||
Alors l'ETA réel doit être calculé et comparé
|
||||
Et l'écart doit être loggé pour amélioration de l'algorithme
|
||||
Et si l'écart >5 secondes, un flag "prediction_error" doit être levé
|
||||
58
features/api/navigation/historique-geo-contenu.feature
Normal file
58
features/api/navigation/historique-geo-contenu.feature
Normal file
@@ -0,0 +1,58 @@
|
||||
# language: fr
|
||||
|
||||
@api @navigation @history @mvp
|
||||
Fonctionnalité: Historique géolocalisé des contenus écoutés
|
||||
|
||||
En tant qu'utilisateur
|
||||
Je veux consulter l'historique de mes écoutes avec localisation
|
||||
Afin de me souvenir de mes découvertes et parcours
|
||||
|
||||
Scénario: Enregistrement automatique de l'historique
|
||||
Étant donné un utilisateur "alice@roadwave.fr" qui écoute un contenu
|
||||
Quand l'écoute est terminée
|
||||
Alors l'historique enregistre:
|
||||
| Donnée | Exemple |
|
||||
| Contenu | Audio-guide Quartier Latin |
|
||||
| Date/heure | 2026-02-03 14:30 |
|
||||
| Position GPS | 48.8534, 2.3488 |
|
||||
| Durée d'écoute | 42 min |
|
||||
Et un événement "HISTORY_ENTRY_CREATED" est enregistré
|
||||
|
||||
Scénario: Visualisation de l'historique sur une carte
|
||||
Étant donné un utilisateur "bob@roadwave.fr"
|
||||
Quand il accède à "Mon historique"
|
||||
Alors une carte affiche tous les points écoutés
|
||||
Et chaque marqueur est cliquable pour voir les détails
|
||||
Et un événement "HISTORY_MAP_VIEWED" est enregistré
|
||||
|
||||
Scénario: Filtrage de l'historique par période
|
||||
Étant donné un utilisateur "charlie@roadwave.fr"
|
||||
Quand il filtre par "Ce mois-ci"
|
||||
Alors seuls les contenus du mois courant sont affichés
|
||||
Et un compteur indique: "23 contenus écoutés ce mois"
|
||||
Et un événement "HISTORY_FILTERED" est enregistré
|
||||
|
||||
Scénario: Export de l'historique pour souvenirs
|
||||
Étant donné un utilisateur "david@roadwave.fr"
|
||||
Quand il exporte son historique
|
||||
Alors il reçoit un fichier GPX avec tous ses parcours
|
||||
Et peut l'importer dans d'autres applications
|
||||
Et un événement "HISTORY_EXPORTED" est enregistré
|
||||
|
||||
Scénario: Suppression d'entrées d'historique
|
||||
Étant donné un utilisateur "eve@roadwave.fr"
|
||||
Quand elle supprime une entrée
|
||||
Alors elle est retirée de l'historique
|
||||
Et ne compte plus dans les statistiques
|
||||
Et un événement "HISTORY_ENTRY_DELETED" est enregistré
|
||||
|
||||
Scénario: Statistiques annuelles basées sur l'historique
|
||||
Étant donné un utilisateur "frank@roadwave.fr" en fin d'année
|
||||
Alors il voit son "Rétrospective RoadWave 2026":
|
||||
| Métrique | Valeur |
|
||||
| Contenus écoutés | 142 |
|
||||
| Distance parcourue | 523 km |
|
||||
| Villes visitées | 18 |
|
||||
| Pays visités | 3 |
|
||||
| Top catégorie | Tourisme |
|
||||
Et un événement "YEARLY_RETROSPECTIVE_VIEWED" est enregistré
|
||||
52
features/api/navigation/mode-stationnement.feature
Normal file
52
features/api/navigation/mode-stationnement.feature
Normal file
@@ -0,0 +1,52 @@
|
||||
# language: fr
|
||||
|
||||
@api @navigation @parking @mvp
|
||||
Fonctionnalité: Mode stationnement et pause automatique
|
||||
|
||||
En tant qu'utilisateur conducteur
|
||||
Je veux que l'application détecte quand je me gare
|
||||
Afin d'adapter l'expérience et proposer la suite à pied
|
||||
|
||||
Scénario: Détection automatique du stationnement
|
||||
Étant donné un utilisateur "alice@roadwave.fr" en mode voiture
|
||||
Quand la vitesse passe à 0 km/h pendant plus de 2 minutes
|
||||
Et le Bluetooth CarPlay se déconnecte
|
||||
Alors le mode "Stationnement" est activé
|
||||
Et un événement "PARKING_MODE_DETECTED" est enregistré
|
||||
|
||||
Scénario: Proposition de basculement en mode piéton
|
||||
Étant donné un utilisateur "bob@roadwave.fr" en mode stationnement
|
||||
Quand il sort de la voiture (détecté par capteurs)
|
||||
Alors une notification propose: "Continuer à pied ?"
|
||||
Et deux options: [Mode piéton] [Rester en voiture]
|
||||
Et un événement "PEDESTRIAN_MODE_SUGGESTED" est enregistré
|
||||
|
||||
Scénario: Mémorisation de la position de stationnement
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" qui se gare
|
||||
Quand le mode stationnement est activé
|
||||
Alors la position GPS est sauvegardée
|
||||
Et un marqueur "Votre voiture" est placé sur la carte
|
||||
Et un événement "PARKING_LOCATION_SAVED" est enregistré
|
||||
|
||||
Scénario: Navigation retour vers la voiture
|
||||
Étant donné un utilisateur "david@roadwave.fr" qui a fini sa visite à pied
|
||||
Quand il clique sur "Retour à ma voiture"
|
||||
Alors un itinéraire piéton est calculé
|
||||
Et la distance est affichée: "650m - 8 min"
|
||||
Et un événement "NAVIGATION_TO_PARKING_STARTED" est enregistré
|
||||
|
||||
Scénario: Alerte d'expiration du stationnement payant
|
||||
Étant donné un utilisateur "eve@roadwave.fr" en stationnement
|
||||
Et elle a configuré une durée de stationnement: 2 heures
|
||||
Quand il reste 10 minutes
|
||||
Alors une notification push est envoyée: "Stationnement expire dans 10 min"
|
||||
Et un événement "PARKING_EXPIRY_WARNING" est enregistré
|
||||
|
||||
Scénario: Statistiques de stationnement
|
||||
Étant donné un utilisateur "frank@roadwave.fr"
|
||||
Alors il peut voir dans ses stats:
|
||||
| Métrique | Valeur |
|
||||
| Nombre de stationnements | 45 |
|
||||
| Durée moyenne | 1h 30min |
|
||||
| Distance voiture-POI moyen | 320m |
|
||||
Et un événement "PARKING_STATS_VIEWED" est enregistré
|
||||
@@ -0,0 +1,76 @@
|
||||
# language: fr
|
||||
|
||||
@api @navigation @car-mode @ui @mvp
|
||||
Fonctionnalité: Notifications minimalistes en mode voiture
|
||||
|
||||
En tant qu'utilisateur conducteur
|
||||
Je veux des notifications visuelles minimales et audio prioritaires
|
||||
Afin de rester concentré sur la route en toute sécurité
|
||||
|
||||
Scénario: Affichage minimal des notifications visuelles
|
||||
Étant donné un utilisateur "alice@roadwave.fr" en mode voiture
|
||||
Quand une notification est déclenchée
|
||||
Alors elle s'affiche pendant 3 secondes maximum
|
||||
Et occupe < 20% de l'écran
|
||||
Et disparaît automatiquement
|
||||
Et un événement "CAR_NOTIFICATION_MINIMAL_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Notifications audio prioritaires sur visuel
|
||||
Étant donné un utilisateur "bob@roadwave.fr" en mode voiture
|
||||
Quand un point d'intérêt approche
|
||||
Alors une notification audio est jouée
|
||||
Et la notification visuelle est optionnelle
|
||||
Et l'audio contient toutes les informations nécessaires
|
||||
Et un événement "CAR_AUDIO_NOTIFICATION_PRIORITY" est enregistré
|
||||
|
||||
Scénario: Pas de popups ou modales en mode voiture
|
||||
Étant donné un utilisateur "charlie@roadwave.fr" en mode voiture
|
||||
Quand une action nécessite une confirmation
|
||||
Alors aucune modale bloquante n'apparaît
|
||||
Et la confirmation est reportée ou faite par commande vocale
|
||||
Et un événement "CAR_MODAL_PREVENTED" est enregistré
|
||||
|
||||
Scénario: Gros boutons tactiles espacés pour conduite
|
||||
Étant donné un utilisateur "david@roadwave.fr" en mode voiture
|
||||
Alors tous les boutons ont une taille minimale de 60x60 pixels
|
||||
Et un espacement minimal de 20 pixels entre boutons
|
||||
Et sont facilement accessibles d'une main
|
||||
Et un événement "CAR_UI_TOUCH_OPTIMIZED" est enregistré
|
||||
|
||||
Scénario: Mode nuit automatique pour réduire éblouissement
|
||||
Étant donné un utilisateur "eve@roadwave.fr" en mode voiture la nuit
|
||||
Quand le capteur de luminosité détecte l'obscurité
|
||||
Alors l'interface passe en mode nuit (fond noir)
|
||||
Et la luminosité est réduite de 50%
|
||||
Et un événement "CAR_NIGHT_MODE_AUTO" est enregistré
|
||||
|
||||
Scénario: Notifications groupées pour éviter la surcharge
|
||||
Étant donné un utilisateur "frank@roadwave.fr" en mode voiture
|
||||
Quand plusieurs événements se produisent en 30 secondes
|
||||
Alors une seule notification résume les événements
|
||||
Et les détails sont accessibles après l'arrêt
|
||||
Et un événement "CAR_NOTIFICATIONS_GROUPED" est enregistré
|
||||
|
||||
Scénario: Intégration CarPlay avec notifications système
|
||||
Étant donné un utilisateur "grace@roadwave.fr" avec CarPlay
|
||||
Quand une notification RoadWave arrive
|
||||
Alors elle utilise le système de notification CarPlay natif
|
||||
Et respecte les guidelines Apple pour sécurité
|
||||
Et un événement "CARPLAY_NOTIFICATION_NATIVE" est enregistré
|
||||
|
||||
Scénario: Commandes vocales pour interactions sans les mains
|
||||
Étant donné un utilisateur "henry@roadwave.fr" en mode voiture
|
||||
Quand il dit "Dis Siri, mets en pause"
|
||||
Alors l'audio-guide se met en pause sans interaction tactile
|
||||
Et aucune confirmation visuelle n'est requise
|
||||
Et un événement "CAR_VOICE_COMMAND_EXECUTED" est enregistré
|
||||
|
||||
Scénario: Métriques de sécurité des notifications
|
||||
Étant donné que 50 000 notifications ont été affichées en mode voiture
|
||||
Alors les indicateurs suivants sont respectés:
|
||||
| Métrique | Valeur cible |
|
||||
| Temps d'affichage moyen | < 3s |
|
||||
| Taux d'utilisation audio vs visuel| 80% audio |
|
||||
| Taille moyenne des notifications | < 20% écran |
|
||||
| Taux d'accidents rapportés | 0 |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
226
features/api/navigation/quota-cooldown.feature
Normal file
226
features/api/navigation/quota-cooldown.feature
Normal file
@@ -0,0 +1,226 @@
|
||||
# language: fr
|
||||
|
||||
@api @navigation @anti-spam @mvp
|
||||
Fonctionnalité: Quota et cooldown pour contenus géolocalisés
|
||||
|
||||
En tant que système de navigation
|
||||
Je veux limiter les notifications géolocalisées à 6 par heure
|
||||
Et appliquer un cooldown de 10 minutes après refus
|
||||
Afin d'éviter le spam et préserver l'expérience utilisateur
|
||||
|
||||
Contexte:
|
||||
Étant donné un utilisateur authentifié en mode voiture
|
||||
Et la géolocalisation est activée
|
||||
|
||||
# ============================================================================
|
||||
# QUOTA 6 NOTIFICATIONS / HEURE (fenêtre glissante)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Première notification de l'heure sans quota atteint
|
||||
Étant donné l'utilisateur n'a reçu aucune notification géolocalisée dans les 60 dernières minutes
|
||||
Et un contenu géolocalisé déclenche une notification (ETA = 7s)
|
||||
Quand la notification est envoyée
|
||||
Alors le compteur de quota doit être incrémenté à 1/6
|
||||
Et un timestamp doit être enregistré pour cette notification
|
||||
Et la notification doit être affichée normalement
|
||||
|
||||
Scénario: Notifications multiples sous le quota
|
||||
Étant donné l'utilisateur a reçu 3 notifications dans les 60 dernières minutes :
|
||||
| timestamp | contenu_id |
|
||||
| 2026-02-03 14:10:00 | content-1 |
|
||||
| 2026-02-03 14:25:00 | content-2 |
|
||||
| 2026-02-03 14:40:00 | content-3 |
|
||||
Et il est maintenant 14:50:00
|
||||
Et un nouveau contenu géolocalisé déclenche une notification
|
||||
Quand la notification est évaluée
|
||||
Alors le compteur doit afficher 4/6
|
||||
Et la notification doit être envoyée normalement
|
||||
|
||||
Scénario: 6ème notification - dernière autorisée
|
||||
Étant donné l'utilisateur a reçu 5 notifications dans l'heure
|
||||
Et un nouveau contenu géolocalisé déclenche une notification
|
||||
Quand la notification est envoyée
|
||||
Alors le compteur doit afficher 6/6
|
||||
Et la notification doit être affichée normalement
|
||||
Et un flag "quota_limit_reached" doit être ajouté aux métriques
|
||||
|
||||
Scénario: 7ème notification - quota dépassé
|
||||
Étant donné l'utilisateur a reçu 6 notifications dans les 60 dernières minutes
|
||||
Et un nouveau contenu géolocalisé déclenche une notification
|
||||
Quand le système évalue le quota
|
||||
Alors la notification ne doit PAS être envoyée
|
||||
Et le contenu doit être ajouté silencieusement à la file d'attente
|
||||
Et un événement "notification_blocked_quota" doit être loggé
|
||||
Et l'utilisateur ne doit voir aucun indicateur visuel de blocage
|
||||
|
||||
Scénario: Fenêtre glissante - libération progressive du quota
|
||||
Étant donné l'utilisateur a reçu 6 notifications :
|
||||
| timestamp | contenu_id |
|
||||
| 2026-02-03 13:00:00 | content-1 |
|
||||
| 2026-02-03 13:15:00 | content-2 |
|
||||
| 2026-02-03 13:30:00 | content-3 |
|
||||
| 2026-02-03 13:45:00 | content-4 |
|
||||
| 2026-02-03 14:00:00 | content-5 |
|
||||
| 2026-02-03 14:10:00 | content-6 |
|
||||
Et il est maintenant 14:05:00 (la 1ère notification a >60 min)
|
||||
Et un nouveau contenu déclenche une notification
|
||||
Quand le système calcule le quota sur les 60 dernières minutes
|
||||
Alors seules 5 notifications doivent être comptées (13:15 à 14:10)
|
||||
Et le compteur doit afficher 6/6 (5 + nouvelle = 6)
|
||||
Et la notification doit être envoyée
|
||||
|
||||
Scénario: Reset complet après 60 minutes sans notification
|
||||
Étant donné l'utilisateur a reçu 6 notifications entre 12:00 et 12:50
|
||||
Et il est maintenant 13:55 (>60 min après la dernière)
|
||||
Quand un nouveau contenu déclenche une notification
|
||||
Alors le compteur doit être reset à 1/6
|
||||
Et la notification doit être envoyée normalement
|
||||
|
||||
# ============================================================================
|
||||
# EXCEPTION AUDIO-GUIDES (1 quota = toutes les séquences)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Audio-guide multi-séquences compte pour 1 seul quota
|
||||
Étant donné l'utilisateur a reçu 5 notifications normales dans l'heure
|
||||
Et l'utilisateur démarre un audio-guide avec 8 séquences géolocalisées
|
||||
Quand la 1ère séquence de l'audio-guide déclenche une notification
|
||||
Alors le quota doit être incrémenté à 6/6
|
||||
Quand les 7 séquences suivantes déclenchent des notifications
|
||||
Alors le quota doit rester à 6/6
|
||||
Et toutes les notifications d'audio-guide doivent être envoyées
|
||||
Et un flag "audio_guide_exception" doit être loggé
|
||||
|
||||
Scénario: Audio-guide suivi de contenus normaux bloqués
|
||||
Étant donné l'utilisateur a reçu 5 notifications normales
|
||||
Et l'utilisateur a terminé un audio-guide de 6 séquences (compte pour 1 quota)
|
||||
Et le quota est maintenant 6/6
|
||||
Quand un contenu normal déclenche une notification
|
||||
Alors la notification doit être bloquée (quota dépassé)
|
||||
Et le contenu doit être ajouté à la file d'attente
|
||||
|
||||
Scénario: Plusieurs audio-guides dans l'heure
|
||||
Étant donné l'utilisateur a démarré 3 audio-guides dans l'heure :
|
||||
| timestamp | audio_guide_id | sequences |
|
||||
| 2026-02-03 13:00:00 | guide-1 | 5 |
|
||||
| 2026-02-03 13:30:00 | guide-2 | 8 |
|
||||
| 2026-02-03 14:00:00 | guide-3 | 4 |
|
||||
Quand le système calcule le quota
|
||||
Alors chaque audio-guide doit compter pour 1 quota
|
||||
Et le compteur doit afficher 3/6
|
||||
Et 3 contenus normaux supplémentaires peuvent être notifiés
|
||||
|
||||
# ============================================================================
|
||||
# COOLDOWN 10 MINUTES APRÈS REFUS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Notification ignorée déclenche cooldown de 10 minutes
|
||||
Étant donné une notification géolocalisée est affichée à 14:00:00
|
||||
Et le compteur de 7 secondes se termine sans action utilisateur
|
||||
Quand le délai de 7 secondes expire
|
||||
Alors un cooldown de 10 minutes doit être activé
|
||||
Et un timestamp "cooldown_until: 14:10:00" doit être enregistré
|
||||
Et la notification doit disparaître
|
||||
|
||||
Scénario: Notifications bloquées pendant le cooldown
|
||||
Étant donné un cooldown est actif jusqu'à 14:10:00
|
||||
Et il est maintenant 14:05:00
|
||||
Et 3 contenus géolocalisés déclenchent des notifications
|
||||
Quand le système évalue les conditions
|
||||
Alors aucune notification ne doit être affichée
|
||||
Et les 3 contenus doivent être ajoutés silencieusement à la file d'attente
|
||||
Et un événement "notification_blocked_cooldown" doit être loggé pour chacun
|
||||
|
||||
Scénario: Fin du cooldown - reprise normale
|
||||
Étant donné un cooldown actif jusqu'à 14:10:00
|
||||
Et il est maintenant 14:10:05 (cooldown expiré)
|
||||
Et un contenu géolocalisé déclenche une notification
|
||||
Quand le système évalue les conditions
|
||||
Alors le cooldown doit être considéré comme expiré
|
||||
Et la notification doit être envoyée normalement
|
||||
Et le flag "post_cooldown" doit être ajouté aux métriques
|
||||
|
||||
Scénario: Validation notification pendant le countdown annule le cooldown
|
||||
Étant donné une notification affichée avec compteur à 4 secondes restantes
|
||||
Quand l'utilisateur appuie sur "Écouter maintenant"
|
||||
Alors le contenu doit démarrer
|
||||
Et aucun cooldown ne doit être appliqué
|
||||
Et la prochaine notification peut être envoyée normalement (sous réserve du quota)
|
||||
|
||||
Scénario: Cooldown + Quota simultanés
|
||||
Étant donné l'utilisateur a reçu 6 notifications dans l'heure (quota atteint)
|
||||
Et la dernière notification a été ignorée (cooldown actif pour 10 min)
|
||||
Et il est maintenant 5 minutes plus tard
|
||||
Quand un nouveau contenu déclenche une notification
|
||||
Alors la notification doit être bloquée pour les 2 raisons :
|
||||
| raison | statut |
|
||||
| quota_exceeded | true |
|
||||
| cooldown_active | true |
|
||||
Et le contenu doit être ajouté à la file d'attente
|
||||
Et les deux raisons doivent être loggées
|
||||
|
||||
# ============================================================================
|
||||
# CAS LIMITES & EDGE CASES
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Cooldown ne s'applique pas en mode piéton
|
||||
Étant donné l'utilisateur est en mode piéton
|
||||
Et une notification push géolocalisée est ignorée
|
||||
Quand la notification expire
|
||||
Alors aucun cooldown ne doit être appliqué
|
||||
Car en mode piéton les notifications sont opt-in et moins intrusives
|
||||
|
||||
Scénario: Changement de mode pendant cooldown (voiture → piéton)
|
||||
Étant donné un cooldown actif en mode voiture jusqu'à 14:20:00
|
||||
Et il est maintenant 14:12:00 (cooldown encore actif)
|
||||
Quand l'utilisateur bascule en mode piéton
|
||||
Alors le cooldown doit être immédiatement annulé
|
||||
Et les notifications piéton doivent être activées normalement
|
||||
|
||||
Scénario: Déconnexion/reconnexion pendant cooldown
|
||||
Étant donné un cooldown actif jusqu'à 15:30:00
|
||||
Quand l'utilisateur se déconnecte puis se reconnecte à 15:20:00
|
||||
Alors le cooldown doit être persisté (Redis ou DB)
|
||||
Et le cooldown doit toujours être actif jusqu'à 15:30:00
|
||||
Et les notifications doivent rester bloquées
|
||||
|
||||
Scénario: Quota reset à minuit vs fenêtre glissante
|
||||
Étant donné le système utilise une fenêtre glissante de 60 minutes
|
||||
Et l'utilisateur a reçu 6 notifications entre 23:30 et 23:55
|
||||
Quand minuit passe et il est 00:05
|
||||
Alors le quota doit toujours être calculé sur les 60 dernières minutes
|
||||
Et les 6 notifications doivent encore être comptées
|
||||
Et aucune notification supplémentaire ne peut être envoyée avant 00:30
|
||||
|
||||
# ============================================================================
|
||||
# MÉTRIQUES & ANALYTICS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Logging des blocages quota pour optimisation
|
||||
Étant donné le quota est atteint (6/6)
|
||||
Et 5 contenus tentent de déclencher une notification dans l'heure suivante
|
||||
Quand ces notifications sont bloquées
|
||||
Alors un événement analytics doit être loggé pour chacune :
|
||||
| event_type | notification_blocked_quota |
|
||||
| content_id | content-xyz |
|
||||
| user_quota_current | 6 |
|
||||
| user_quota_max | 6 |
|
||||
| timestamp_blocked | 2026-02-03 14:30:00 |
|
||||
| added_to_queue | true |
|
||||
Et ces métriques doivent alimenter le dashboard de monitoring
|
||||
|
||||
Scénario: Métriques de cooldown par utilisateur
|
||||
Étant donné un utilisateur ignore 3 notifications dans la journée
|
||||
Quand le système analyse le comportement
|
||||
Alors les métriques suivantes doivent être calculées :
|
||||
| cooldowns_triggered_today | 3 |
|
||||
| avg_cooldown_per_user | 2.1 |
|
||||
| ignore_rate | 50% |
|
||||
Et ces données doivent être utilisées pour ajuster l'algorithme de recommandation
|
||||
|
||||
Scénario: A/B testing - quota 6 vs 8 vs 10 par heure
|
||||
Étant donné l'utilisateur est dans le groupe de test "quota_8"
|
||||
Et le système teste différentes valeurs de quota
|
||||
Quand le système évalue les notifications
|
||||
Alors le quota max doit être de 8 au lieu de 6
|
||||
Et le groupe de test doit être loggé dans les événements
|
||||
Et les métriques d'engagement doivent être comparées entre groupes
|
||||
223
features/api/premium/stream-conflict-detection.feature
Normal file
223
features/api/premium/stream-conflict-detection.feature
Normal file
@@ -0,0 +1,223 @@
|
||||
# language: fr
|
||||
|
||||
@api @premium @multi-device @mvp
|
||||
Fonctionnalité: Détection et gestion des conflits de streaming multi-device Premium
|
||||
|
||||
En tant qu'abonné Premium
|
||||
Je peux écouter sur plusieurs appareils (iPhone, iPad, Android, Web)
|
||||
Mais un seul stream audio peut être actif à la fois
|
||||
Afin de respecter les conditions d'abonnement Premium individuel
|
||||
|
||||
Contexte:
|
||||
Étant donné un utilisateur avec abonnement Premium actif
|
||||
Et plusieurs appareils enregistrés sur le compte :
|
||||
| device_id | platform | nom | last_seen |
|
||||
| iphone-123 | iOS | iPhone de Jean | 2026-02-03 14:00:00 |
|
||||
| ipad-456 | iOS | iPad Pro | 2026-02-03 12:30:00 |
|
||||
| android-789 | Android | Samsung Galaxy | 2026-02-02 18:00:00 |
|
||||
| web-abc | Web | Chrome MacBook | 2026-02-03 10:00:00 |
|
||||
|
||||
# ============================================================================
|
||||
# DÉTECTION STREAM ACTIF ET CONFLIT
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Premier stream - aucun conflit
|
||||
Étant donné aucun stream n'est actuellement actif sur le compte
|
||||
Quand l'utilisateur démarre la lecture sur "iPhone de Jean"
|
||||
Alors le stream doit démarrer normalement
|
||||
Et une session active doit être enregistrée dans Redis :
|
||||
| user_id | user-123 |
|
||||
| device_id | iphone-123 |
|
||||
| started_at | 2026-02-03 14:00:00|
|
||||
| content_id | content-xyz |
|
||||
| stream_token | token-abc123 |
|
||||
Et le TTL Redis doit être de 2 heures
|
||||
|
||||
Scénario: Tentative de stream simultané sur second appareil
|
||||
Étant donné un stream actif sur "iPhone de Jean" depuis 10 minutes
|
||||
Quand l'utilisateur tente de démarrer la lecture sur "iPad Pro"
|
||||
Alors une réponse HTTP 409 Conflict doit être retournée
|
||||
Et le message doit indiquer :
|
||||
"""
|
||||
Un contenu est déjà en cours de lecture sur "iPhone de Jean".
|
||||
Voulez-vous arrêter la lecture sur cet appareil et continuer ici ?
|
||||
"""
|
||||
Et les options proposées doivent être :
|
||||
| option | action |
|
||||
| Continuer ici | kill_previous_session |
|
||||
| Annuler | cancel_new_session |
|
||||
|
||||
Scénario: Utilisateur choisit "Continuer ici" - kill de l'ancienne session
|
||||
Étant donné un stream actif sur "iPhone de Jean"
|
||||
Et l'utilisateur tente de lire sur "iPad Pro"
|
||||
Et le conflit est détecté
|
||||
Quand l'utilisateur choisit "Continuer ici"
|
||||
Alors l'ancienne session sur "iPhone de Jean" doit être terminée immédiatement
|
||||
Et un message WebSocket doit être envoyé à "iPhone de Jean" :
|
||||
"""
|
||||
{"type": "stream_stopped", "reason": "playback_started_on_other_device", "device": "iPad Pro"}
|
||||
"""
|
||||
Et la lecture sur "iPhone de Jean" doit s'arrêter avec notification :
|
||||
"""
|
||||
Lecture arrêtée : un autre appareil utilise votre compte Premium.
|
||||
"""
|
||||
Et le nouveau stream sur "iPad Pro" doit démarrer normalement
|
||||
|
||||
Scénario: Utilisateur choisit "Annuler" - maintien de la session actuelle
|
||||
Étant donné un stream actif sur "iPhone de Jean"
|
||||
Et l'utilisateur tente de lire sur "iPad Pro"
|
||||
Et le conflit est détecté
|
||||
Quand l'utilisateur choisit "Annuler"
|
||||
Alors la session sur "iPhone de Jean" doit continuer normalement
|
||||
Et aucun stream ne doit démarrer sur "iPad Pro"
|
||||
Et l'utilisateur doit être redirigé vers l'écran d'accueil sur "iPad Pro"
|
||||
|
||||
# ============================================================================
|
||||
# GESTION AUTOMATIQUE DES SESSIONS EXPIRÉES
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Session expirée automatiquement après pause prolongée
|
||||
Étant donné un stream actif sur "iPhone de Jean"
|
||||
Et l'utilisateur met en pause à 14:00:00
|
||||
Et le TTL Redis est configuré pour expirer après 30 minutes de pause
|
||||
Quand il est 14:35:00 (>30 min de pause)
|
||||
Alors la session Redis doit expirer automatiquement
|
||||
Et l'utilisateur peut démarrer un nouveau stream sur n'importe quel appareil
|
||||
Et aucun conflit ne doit être détecté
|
||||
|
||||
Scénario: Heartbeat maintient la session active pendant la lecture
|
||||
Étant donné un stream actif sur "iPhone de Jean"
|
||||
Quand l'application envoie un heartbeat toutes les 30 secondes
|
||||
Alors le TTL Redis doit être renouvelé à 2 heures à chaque heartbeat
|
||||
Et la session doit rester active tant que les heartbeats continuent
|
||||
Et si 3 heartbeats consécutifs échouent, la session doit expirer
|
||||
|
||||
Scénario: Fermeture propre de l'application libère la session
|
||||
Étant donné un stream actif sur "iPhone de Jean"
|
||||
Quand l'utilisateur ferme proprement l'application (swipe kill ou logout)
|
||||
Alors une requête "end_session" doit être envoyée à l'API
|
||||
Et la session Redis doit être immédiatement supprimée
|
||||
Et l'utilisateur peut démarrer un stream sur un autre appareil sans délai
|
||||
|
||||
# ============================================================================
|
||||
# CAS LIMITES ET EDGE CASES
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Crash application sans fermeture propre
|
||||
Étant donné un stream actif sur "iPhone de Jean"
|
||||
Quand l'application crash sans envoyer "end_session"
|
||||
Alors la session Redis reste active avec son TTL
|
||||
Et après 2 minutes sans heartbeat, la session doit être marquée "stale"
|
||||
Et un nouveau stream peut être démarré après 2 minutes sans heartbeat
|
||||
Ou l'utilisateur peut forcer le kill via le conflit modal
|
||||
|
||||
Scénario: Connexion réseau perdue pendant stream
|
||||
Étant donné un stream actif sur "iPhone de Jean"
|
||||
Quand la connexion réseau est perdue pendant 5 minutes
|
||||
Alors les heartbeats échouent mais l'app continue en buffer
|
||||
Et après 3 heartbeats manqués (90 secondes), la session est considérée "stale"
|
||||
Et un autre appareil peut démarrer un stream après 90 secondes
|
||||
|
||||
Scénario: Deux appareils tentent de démarrer simultanément (race condition)
|
||||
Étant donné aucun stream actif
|
||||
Quand "iPhone de Jean" et "iPad Pro" tentent de démarrer un stream à la même milliseconde
|
||||
Alors le premier à obtenir le lock Redis doit réussir
|
||||
Et le second doit recevoir un conflit 409
|
||||
Et un mécanisme de lock distribué (Redis SET NX) doit être utilisé
|
||||
|
||||
Scénario: Utilisateur bascule rapidement entre appareils (<10s)
|
||||
Étant donné un stream sur "iPhone de Jean"
|
||||
Quand l'utilisateur kill la session et démarre sur "iPad Pro"
|
||||
Et tente de redémarrer sur "iPhone de Jean" 5 secondes après
|
||||
Alors le système doit détecter le conflit avec "iPad Pro"
|
||||
Et proposer à nouveau de kill la session iPad
|
||||
Et un délai de grâce de 5 secondes doit être respecté pour éviter les boucles
|
||||
|
||||
# ============================================================================
|
||||
# GESTION UTILISATEUR GRATUIT (pas de multi-device)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Utilisateur gratuit tente de streamer sur 2 appareils
|
||||
Étant donné un utilisateur avec abonnement gratuit (pas Premium)
|
||||
Et un stream actif sur "iPhone de Jean"
|
||||
Quand l'utilisateur tente de lire sur "iPad Pro"
|
||||
Alors une réponse HTTP 403 Forbidden doit être retournée
|
||||
Et le message doit indiquer :
|
||||
"""
|
||||
Le multi-device nécessite un abonnement Premium.
|
||||
Actuellement en lecture sur "iPhone de Jean".
|
||||
Passez à Premium pour écouter sur plusieurs appareils.
|
||||
"""
|
||||
Et un bouton "Passer à Premium" doit être proposé
|
||||
|
||||
# ============================================================================
|
||||
# INTERFACE ADMIN & GESTION DES CONFLITS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Dashboard admin - voir sessions actives par utilisateur
|
||||
Étant donné un administrateur connecté au dashboard
|
||||
Quand l'admin recherche l'utilisateur "user-123"
|
||||
Alors les sessions actives doivent être affichées :
|
||||
| device_id | platform | started_at | content_id | duration |
|
||||
| iphone-123 | iOS | 2026-02-03 14:00:00 | content-xyz | 15:30 |
|
||||
Et l'admin doit pouvoir "Terminer la session" manuellement
|
||||
|
||||
Scénario: Support client - résolution conflit bloqué
|
||||
Étant donné un utilisateur signale ne pas pouvoir lire sur aucun appareil
|
||||
Et une session "fantôme" existe dans Redis (crash + heartbeat bloqué)
|
||||
Quand le support client force la suppression de la session Redis
|
||||
Alors la clé Redis "active_stream:user-123" doit être supprimée
|
||||
Et l'utilisateur doit pouvoir redémarrer immédiatement
|
||||
|
||||
# ============================================================================
|
||||
# MÉTRIQUES & MONITORING
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Logging des conflits pour analytics
|
||||
Étant donné un conflit est détecté entre "iPhone de Jean" et "iPad Pro"
|
||||
Quand le conflit est résolu par kill de session
|
||||
Alors un événement analytics doit être loggé :
|
||||
| event_type | stream_conflict_resolved |
|
||||
| user_id | user-123 |
|
||||
| previous_device | iphone-123 |
|
||||
| new_device | ipad-456 |
|
||||
| resolution | kill_previous |
|
||||
| previous_session_duration | 900 |
|
||||
| timestamp | 2026-02-03 14:15:00 |
|
||||
Et ces métriques doivent être disponibles dans le dashboard
|
||||
|
||||
Scénario: Alerte monitoring - taux de conflits élevé
|
||||
Étant donné le système monitore les conflits de stream
|
||||
Quand le taux de conflits dépasse 15% des nouvelles sessions sur 1 heure
|
||||
Alors une alerte Slack doit être envoyée à l'équipe technique
|
||||
Et le message doit indiquer :
|
||||
"""
|
||||
⚠️ Taux de conflits stream élevé : 18% (seuil : 15%)
|
||||
Sessions impactées : 234 sur 1300
|
||||
Action recommandée : vérifier expiration Redis et heartbeats
|
||||
"""
|
||||
|
||||
# ============================================================================
|
||||
# COMPATIBILITÉ AVEC D'AUTRES FEATURES
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Radio live avec conflit de stream
|
||||
Étant donné un utilisateur écoute une radio live sur "iPhone de Jean"
|
||||
Quand l'utilisateur démarre un stream sur "iPad Pro" et kill la session iPhone
|
||||
Alors la radio live doit s'arrêter sur iPhone
|
||||
Et le nouveau stream sur iPad peut être une radio live ou contenu normal
|
||||
Et la progression audio-guide (si applicable) doit être sauvegardée
|
||||
|
||||
Scénario: Mode offline ne déclenche PAS de conflit
|
||||
Étant donné un stream actif en ligne sur "iPhone de Jean"
|
||||
Quand l'utilisateur écoute un contenu téléchargé en mode offline sur "iPad Pro"
|
||||
Alors aucun conflit ne doit être détecté
|
||||
Car le mode offline ne consomme pas de stream en ligne
|
||||
Et les deux lectures peuvent coexister
|
||||
|
||||
Scénario: Multi-device avec partage familial (post-MVP)
|
||||
Étant donné la fonctionnalité de partage familial est activée (post-MVP)
|
||||
Et le compte principal a 3 profils famille
|
||||
Quand chaque profil démarre un stream sur son appareil
|
||||
Alors jusqu'à 3 streams simultanés doivent être autorisés
|
||||
Et la détection de conflit doit s'appliquer par profil (1 stream/profil)
|
||||
57
features/api/premium/tarification-multi-canal.feature
Normal file
57
features/api/premium/tarification-multi-canal.feature
Normal file
@@ -0,0 +1,57 @@
|
||||
# language: fr
|
||||
|
||||
@api @premium @pricing @mvp
|
||||
Fonctionnalité: Tarification différenciée multi-canal
|
||||
|
||||
En tant que plateforme
|
||||
Je veux différencier les tarifs selon le canal d'acquisition
|
||||
Afin d'optimiser la monétisation et les marges
|
||||
|
||||
Scénario: Tarif standard sur le web
|
||||
Étant donné un utilisateur sur roadwave.fr (web)
|
||||
Quand il consulte les tarifs Premium
|
||||
Alors il voit:
|
||||
| Offre | Prix mensuel | Prix annuel |
|
||||
| Premium | 4.99€ | 49.90€ |
|
||||
Et aucun frais de plateforme
|
||||
Et un événement "PRICING_WEB_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Tarif majoré sur iOS (In-App Purchase)
|
||||
Étant donné un utilisateur sur l'app iOS
|
||||
Quand il consulte les tarifs Premium
|
||||
Alors il voit:
|
||||
| Offre | Prix mensuel | Prix annuel |
|
||||
| Premium | 5.99€ | 59.99€ |
|
||||
Et la majoration compense la commission Apple (30%)
|
||||
Et un événement "PRICING_IOS_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Tarif majoré sur Android (Google Play)
|
||||
Étant donné un utilisateur sur l'app Android
|
||||
Alors il voit:
|
||||
| Offre | Prix mensuel | Prix annuel |
|
||||
| Premium | 5.99€ | 59.99€ |
|
||||
Et la majoration compense la commission Google (15-30%)
|
||||
Et un événement "PRICING_ANDROID_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Redirection vers le web pour optimiser le coût
|
||||
Étant donné un utilisateur sur mobile
|
||||
Quand il clique sur "S'abonner"
|
||||
Alors un message suggère: "Économisez 1€ en vous abonnant sur notre site web"
|
||||
Et un lien direct vers roadwave.fr/premium
|
||||
Et un événement "WEB_SUBSCRIPTION_SUGGESTED" est enregistré
|
||||
|
||||
Scénario: Gestion des abonnements multi-plateformes
|
||||
Étant donné un utilisateur abonné via iOS
|
||||
Quand il se connecte sur Android
|
||||
Alors son abonnement est reconnu et actif
|
||||
Et synchronisé automatiquement
|
||||
Et un événement "CROSS_PLATFORM_SUBSCRIPTION_SYNCED" est enregistré
|
||||
|
||||
Scénario: Métriques de conversion par canal
|
||||
Étant donné que 1000 abonnements ont été souscrits
|
||||
Alors la répartition par canal est:
|
||||
| Canal | Abonnements | Taux conversion | Revenu moyen |
|
||||
| Web | 450 (45%) | 8% | 49.90€ |
|
||||
| iOS | 350 (35%) | 6% | 59.99€ |
|
||||
| Android | 200 (20%) | 5% | 59.99€ |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
83
features/api/premium/webhooks-retry-paiement.feature
Normal file
83
features/api/premium/webhooks-retry-paiement.feature
Normal file
@@ -0,0 +1,83 @@
|
||||
# language: fr
|
||||
|
||||
@api @premium @payment @mvp
|
||||
Fonctionnalité: Webhooks et retry automatique des paiements
|
||||
|
||||
En tant que système de paiement
|
||||
Je veux gérer les échecs de paiement avec retry intelligent
|
||||
Afin de maximiser les conversions et minimiser le churn
|
||||
|
||||
Scénario: Webhook Mangopay de paiement réussi
|
||||
Étant donné un abonnement Premium en cours
|
||||
Quand Mangopay envoie un webhook "PAYIN_NORMAL_SUCCEEDED"
|
||||
Alors le système enregistre le paiement
|
||||
Et l'abonnement est prolongé de 30 jours
|
||||
Et un email de confirmation est envoyé
|
||||
Et un événement "PAYMENT_SUCCESS_WEBHOOK_RECEIVED" est enregistré
|
||||
|
||||
Scénario: Webhook de paiement échoué
|
||||
Étant donné un abonnement Premium
|
||||
Quand Mangopay envoie un webhook "PAYIN_NORMAL_FAILED"
|
||||
Alors le système programme un retry automatique
|
||||
Et l'utilisateur est notifié: "Échec de paiement. Nous réessayerons dans 3 jours."
|
||||
Et un événement "PAYMENT_FAILED_WEBHOOK_RECEIVED" est enregistré
|
||||
|
||||
Scénario: Retry automatique après 3 jours
|
||||
Étant donné un paiement échoué il y a 3 jours
|
||||
Quand le système tente un retry automatique
|
||||
Alors une nouvelle tentative de prélèvement est lancée
|
||||
Et l'utilisateur reçoit un email: "Nouvelle tentative de paiement en cours"
|
||||
Et un événement "PAYMENT_RETRY_ATTEMPTED" est enregistré
|
||||
|
||||
Scénario: Série de retries intelligents (3, 7, 14 jours)
|
||||
Étant donné un premier échec de paiement
|
||||
Alors le système programme:
|
||||
| Retry | Délai | Statut abonnement |
|
||||
| 1 | J+3 | Actif |
|
||||
| 2 | J+7 | Actif |
|
||||
| 3 | J+14 | Suspendu |
|
||||
Et après le 3ème échec, l'abonnement est annulé
|
||||
Et un événement "PAYMENT_RETRY_SERIES_CONFIGURED" est enregistré
|
||||
|
||||
Scénario: Suspension de l'abonnement après 3 échecs
|
||||
Étant donné 3 tentatives de paiement échouées
|
||||
Quand le 3ème retry échoue
|
||||
Alors l'abonnement est suspendu
|
||||
Et l'utilisateur repasse en mode Free
|
||||
Et un email explique comment mettre à jour la carte
|
||||
Et un événement "SUBSCRIPTION_SUSPENDED_PAYMENT_FAILURE" est enregistré
|
||||
|
||||
Scénario: Webhook de carte expirée
|
||||
Étant donné un abonnement avec carte expirant ce mois
|
||||
Quand Mangopay envoie un webhook "CARD_EXPIRING"
|
||||
Alors une notification est envoyée 30 jours avant
|
||||
Et rappelée 7 jours avant
|
||||
Et le jour de l'expiration
|
||||
Et un événement "CARD_EXPIRY_WARNING_SENT" est enregistré
|
||||
|
||||
Scénario: Mise à jour de carte et reprise de l'abonnement
|
||||
Étant donné un utilisateur avec abonnement suspendu
|
||||
Quand il met à jour sa carte bancaire
|
||||
Alors un paiement est immédiatement tenté
|
||||
Et si succès, l'abonnement est réactivé
|
||||
Et les jours perdus sont récupérés pro-rata
|
||||
Et un événement "SUBSCRIPTION_REACTIVATED_AFTER_PAYMENT" est enregistré
|
||||
|
||||
Scénario: Webhooks de remboursement
|
||||
Étant donné un utilisateur qui annule son abonnement
|
||||
Et demande un remboursement (satisfait ou remboursé 30j)
|
||||
Quand Mangopay envoie "PAYOUT_NORMAL_SUCCEEDED"
|
||||
Alors le remboursement est enregistré
|
||||
Et l'utilisateur reçoit confirmation
|
||||
Et un événement "REFUND_WEBHOOK_PROCESSED" est enregistré
|
||||
|
||||
Scénario: Métriques de performance des retries
|
||||
Étant donné que 1000 paiements ont échoué
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Taux de succès au 1er retry (J+3)| 45% |
|
||||
| Taux de succès au 2ème retry (J+7)| 25% |
|
||||
| Taux de succès au 3ème retry (J+14)| 10% |
|
||||
| Taux de récupération global | 80% |
|
||||
| Taux d'annulation définitive | 20% |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
90
features/api/profil/badge-verifie.feature
Normal file
90
features/api/profil/badge-verifie.feature
Normal file
@@ -0,0 +1,90 @@
|
||||
# language: fr
|
||||
|
||||
@api @profile @verification @mvp
|
||||
Fonctionnalité: Badge compte vérifié pour créateurs authentiques
|
||||
|
||||
En tant que créateur officiel
|
||||
Je veux obtenir un badge vérifié
|
||||
Afin de prouver mon authenticité et gagner la confiance
|
||||
|
||||
Scénario: Demande de vérification par un créateur
|
||||
Étant donné un créateur "MuseeDuLouvre" avec 1000+ abonnés
|
||||
Quand il demande la vérification via "Paramètres > Demander la vérification"
|
||||
Alors un formulaire de demande s'affiche:
|
||||
| Champ requis | Exemple |
|
||||
| Nom officiel | Musée du Louvre |
|
||||
| Type d'organisation | Institution culturelle |
|
||||
| Document officiel | KBIS / Statuts |
|
||||
| Preuve d'identité | Carte d'identité |
|
||||
| Site web officiel | louvre.fr |
|
||||
| Compte social officiel | @MuseeLouvre (Twitter) |
|
||||
Et la demande est soumise pour review
|
||||
Et un événement "VERIFICATION_REQUEST_SUBMITTED" est enregistré
|
||||
|
||||
Scénario: Vérification par l'équipe RoadWave
|
||||
Étant donné une demande de vérification reçue
|
||||
Quand un modérateur examine le dossier
|
||||
Alors il vérifie:
|
||||
| Critère | Validation |
|
||||
| Documents officiels | Authentiques |
|
||||
| Correspondance identité | Confirmée |
|
||||
| Site web officiel | Vérifié (DNS) |
|
||||
| Réseaux sociaux | Cross-vérifiés |
|
||||
| Activité sur RoadWave | Régulière (3+ mois) |
|
||||
Et prend une décision dans les 7 jours
|
||||
Et un événement "VERIFICATION_REVIEWED" est enregistré
|
||||
|
||||
Scénario: Attribution du badge vérifié
|
||||
Étant donné une demande acceptée
|
||||
Quand le badge est attribué
|
||||
Alors un badge bleu "✓ Vérifié" s'affiche:
|
||||
| Emplacement | Affichage |
|
||||
| À côté du nom de profil | ✓ Musée du Louvre |
|
||||
| Dans les résultats | Badge visible |
|
||||
| Dans les commentaires | Badge visible |
|
||||
Et une notification est envoyée: "Félicitations ! Votre compte est maintenant vérifié"
|
||||
Et un événement "VERIFICATION_BADGE_GRANTED" est enregistré
|
||||
|
||||
Scénario: Avantages du compte vérifié
|
||||
Étant donné un créateur vérifié
|
||||
Alors il bénéficie de:
|
||||
| Avantage | Détail |
|
||||
| Badge bleu visible | Crédibilité accrue |
|
||||
| Priorité dans les recherches | Meilleur ranking SEO |
|
||||
| Statistiques avancées | Analytics détaillées |
|
||||
| Support prioritaire | Réponse < 24h |
|
||||
| Contenu mis en avant | Page "Créateurs vérifiés" |
|
||||
Et un événement "VERIFIED_BENEFITS_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Révocation du badge pour violation
|
||||
Étant donné un créateur vérifié "InstitutionX"
|
||||
Quand il viole les CGU (contenu inapproprié)
|
||||
Alors le badge est révoqué immédiatement
|
||||
Et un email explique la raison
|
||||
Et il peut faire appel de la décision
|
||||
Et un événement "VERIFICATION_BADGE_REVOKED" est enregistré
|
||||
|
||||
Scénario: Renouvellement annuel de la vérification
|
||||
Étant donné un créateur vérifié depuis 12 mois
|
||||
Quand l'anniversaire de la vérification arrive
|
||||
Alors une review automatique est lancée
|
||||
Et des documents à jour peuvent être demandés
|
||||
Et le badge reste actif pendant la review
|
||||
Et un événement "VERIFICATION_RENEWAL_STARTED" est enregistré
|
||||
|
||||
Scénario: Badge spécial pour partenaires officiels
|
||||
Étant donné un partenaire stratégique (Offices du Tourisme, Musées nationaux)
|
||||
Alors un badge or "✓ Partenaire Officiel" est attribué
|
||||
Et des privilèges supplémentaires sont accordés
|
||||
Et un événement "OFFICIAL_PARTNER_BADGE_GRANTED" est enregistré
|
||||
|
||||
Scénario: Statistiques des comptes vérifiés
|
||||
Étant donné que 150 comptes sont vérifiés
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Comptes vérifiés | 150 |
|
||||
| % de la base créateurs | 1.5% |
|
||||
| Demandes en attente | 45 |
|
||||
| Taux d'acceptation | 65% |
|
||||
| Temps moyen de vérification | 5 jours |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
@@ -0,0 +1,63 @@
|
||||
# language: fr
|
||||
|
||||
@api @radio-live @replay @mvp
|
||||
Fonctionnalité: Enregistrement et publication de replays radio live
|
||||
|
||||
En tant que créateur radio
|
||||
Je veux enregistrer mes lives et les publier en replay
|
||||
Afin d'étendre la durée de vie de mon contenu
|
||||
|
||||
Scénario: Enregistrement automatique du live
|
||||
Étant donné un créateur "alice@roadwave.fr" qui lance un live
|
||||
Quand le live démarre
|
||||
Alors l'enregistrement démarre automatiquement
|
||||
Et est stocké sur S3 en temps réel (streaming)
|
||||
Et un événement "LIVE_RECORDING_STARTED" est enregistré
|
||||
|
||||
Scénario: Publication automatique du replay après le live
|
||||
Étant donné un créateur "bob@roadwave.fr" qui termine son live
|
||||
Quand le live se termine
|
||||
Alors le replay est disponible immédiatement
|
||||
Et apparaît dans "Replays récents"
|
||||
Et conserve les métadonnées du live (titre, description)
|
||||
Et un événement "REPLAY_AUTO_PUBLISHED" est enregistré
|
||||
|
||||
Scénario: Édition du replay avant publication
|
||||
Étant donné un créateur "charlie@roadwave.fr" avec un replay enregistré
|
||||
Quand il accède au replay
|
||||
Alors il peut:
|
||||
| Action | Disponible |
|
||||
| Couper le début/fin | Oui |
|
||||
| Supprimer des passages | Oui |
|
||||
| Ajouter des chapitres | Oui |
|
||||
| Modifier le titre | Oui |
|
||||
Et republier après édition
|
||||
Et un événement "REPLAY_EDITED" est enregistré
|
||||
|
||||
Scénario: Conversion automatique en podcast
|
||||
Étant donné un créateur "david@roadwave.fr" avec replay
|
||||
Quand il active "Convertir en podcast"
|
||||
Alors le replay devient un podcast téléchargeable
|
||||
Et est ajouté au flux RSS du créateur
|
||||
Et compatible avec Apple Podcasts / Spotify
|
||||
Et un événement "REPLAY_CONVERTED_TO_PODCAST" est enregistré
|
||||
|
||||
Scénario: Durée de rétention des replays configurab le
|
||||
Étant donné un créateur "eve@roadwave.fr"
|
||||
Quand il configure la rétention des replays
|
||||
Alors il peut choisir:
|
||||
| Durée | Coût stockage |
|
||||
| 7 jours | Gratuit |
|
||||
| 30 jours | 1€/mois |
|
||||
| 1 an | 5€/mois |
|
||||
| Permanent | 10€/mois |
|
||||
Et un événement "REPLAY_RETENTION_CONFIGURED" est enregistré
|
||||
|
||||
Scénario: Statistiques des replays vs live
|
||||
Étant donné un créateur "frank@roadwave.fr"
|
||||
Alors il voit les comparaisons:
|
||||
| Métrique | Live | Replay |
|
||||
| Auditeurs uniques | 234 | 567 |
|
||||
| Durée moyenne écoute | 42min | 28min |
|
||||
| Taux de complétion | 65% | 48% |
|
||||
Et un événement "REPLAY_STATS_COMPARED" est enregistré
|
||||
@@ -0,0 +1,52 @@
|
||||
# language: fr
|
||||
|
||||
@api @radio-live @moderation @mvp
|
||||
Fonctionnalité: Interdictions et modération des lives
|
||||
|
||||
En tant que plateforme
|
||||
Je veux modérer les lives en temps réel
|
||||
Afin de prévenir les contenus inappropriés
|
||||
|
||||
Scénario: Détection automatique de mots interdits
|
||||
Étant donné un live en cours avec transcription automatique
|
||||
Quand un mot interdit est détecté
|
||||
Alors une alerte est envoyée aux modérateurs
|
||||
Et le segment est marqué pour review
|
||||
Et un événement "LIVE_FORBIDDEN_WORD_DETECTED" est enregistré
|
||||
|
||||
Scénario: Coupure immédiate du live par modérateur
|
||||
Étant donné un modérateur qui détecte du contenu inapproprié
|
||||
Quand il clique sur "Couper le live"
|
||||
Alors le live est stoppé immédiatement
|
||||
Et les auditeurs voient "Live interrompu par modération"
|
||||
Et le créateur reçoit une notification avec raison
|
||||
Et un événement "LIVE_CUT_BY_MODERATOR" est enregistré
|
||||
|
||||
Scénario: Suspension temporaire du droit de faire des lives
|
||||
Étant donné un créateur "alice@roadwave.fr" qui enfreint les règles
|
||||
Quand un modérateur applique une sanction
|
||||
Alors le créateur ne peut plus lancer de live pendant X jours
|
||||
Et ses replays restent accessibles (si conformes)
|
||||
Et un événement "LIVE_SUSPENSION_APPLIED" est enregistré
|
||||
|
||||
Scénario: Signalement en temps réel par les auditeurs
|
||||
Étant donné un auditeur qui détecte du contenu problématique
|
||||
Quand il clique sur "Signaler"
|
||||
Alors le signalement est envoyé immédiatement aux modérateurs
|
||||
Et inclut le timestamp exact du problème
|
||||
Et un événement "LIVE_REPORTED_BY_USER" est enregistré
|
||||
|
||||
Scénario: Délai obligatoire de 7 secondes (broadcast delay)
|
||||
Étant donné un live en cours
|
||||
Alors un délai de 7 secondes est appliqué
|
||||
Et permet de couper le flux si nécessaire
|
||||
Et les auditeurs ne perçoivent pas le délai
|
||||
Et un événement "LIVE_BROADCAST_DELAY_ACTIVE" est enregistré
|
||||
|
||||
Scénario: Historique des infractions du créateur
|
||||
Étant donné un modérateur qui évalue un créateur
|
||||
Alors il voit l'historique:
|
||||
| Date | Infraction | Sanction |
|
||||
| 2026-01-15 | Langage inapproprié | Avertissement |
|
||||
| 2025-12-10 | Spam | Suspension 3j |
|
||||
Et un événement "CREATOR_INFRACTION_HISTORY_VIEWED" est enregistré
|
||||
325
features/api/search/geolocation-search.feature
Normal file
325
features/api/search/geolocation-search.feature
Normal file
@@ -0,0 +1,325 @@
|
||||
# language: fr
|
||||
|
||||
@api @search @geolocation @mvp
|
||||
Fonctionnalité: Recherche géographique de contenus avec Nominatim
|
||||
|
||||
En tant qu'utilisateur de RoadWave
|
||||
Je veux rechercher des contenus audio dans une zone géographique spécifique
|
||||
En utilisant un nom de lieu (ville, monument, région) et un rayon de recherche
|
||||
Afin de découvrir des contenus avant de me déplacer ou planifier un trajet
|
||||
|
||||
Contexte:
|
||||
Étant donné un utilisateur authentifié
|
||||
Et l'API Nominatim est accessible
|
||||
|
||||
# ============================================================================
|
||||
# GEOCODAGE AVEC NOMINATIM (lieu → coordonnées GPS)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Recherche par nom de ville (cas simple)
|
||||
Étant donné l'utilisateur saisit "Paris" dans la recherche géographique
|
||||
Quand le système interroge Nominatim avec la requête "Paris, France"
|
||||
Alors Nominatim doit retourner les coordonnées :
|
||||
| lat | 48.8566 |
|
||||
| lon | 2.3522 |
|
||||
| type | city |
|
||||
| bbox | (48.815, 48.902, 2.224, 2.470) |
|
||||
Et le système doit utiliser ces coordonnées comme centre de recherche
|
||||
|
||||
Scénario: Recherche par monument ou POI (Point of Interest)
|
||||
Étant donné l'utilisateur saisit "Tour Eiffel"
|
||||
Quand le système interroge Nominatim
|
||||
Alors Nominatim doit retourner :
|
||||
| lat | 48.8584 |
|
||||
| lon | 2.2945 |
|
||||
| display_name| Tour Eiffel, Paris, France |
|
||||
| type | tourism |
|
||||
Et ces coordonnées doivent être utilisées pour la recherche de contenus
|
||||
|
||||
Scénario: Recherche avec ambiguïté (plusieurs résultats)
|
||||
Étant donné l'utilisateur saisit "Montmartre"
|
||||
Quand le système interroge Nominatim
|
||||
Alors plusieurs résultats doivent être retournés :
|
||||
| display_name | lat | lon |
|
||||
| Montmartre, Paris 18e, France | 48.8867 | 2.3431 |
|
||||
| Montmartre, Saskatchewan, Canada | 49.3000 | -106.0 |
|
||||
| Montmartre-de-Bretagne, Ille-et-Vilaine | 48.1867 | -1.1833|
|
||||
Et l'utilisateur doit choisir dans une liste déroulante
|
||||
Et le choix par défaut doit être le résultat français si détecté
|
||||
|
||||
Scénario: Recherche avec contexte géographique (biais local)
|
||||
Étant donné l'utilisateur est actuellement à Lyon (GPS actif)
|
||||
Et l'utilisateur saisit "Bellecour"
|
||||
Quand le système interroge Nominatim avec viewbox="Lyon area"
|
||||
Alors Nominatim doit prioriser les résultats proches de Lyon
|
||||
Et "Place Bellecour, Lyon" doit apparaître en premier
|
||||
Avant "Bellecour, Jura" ou d'autres homonymes
|
||||
|
||||
Scénario: Recherche par code postal
|
||||
Étant donné l'utilisateur saisit "75001"
|
||||
Quand le système interroge Nominatim
|
||||
Alors Nominatim doit retourner le centre du 1er arrondissement de Paris
|
||||
Et un rayon par défaut de 1km doit être appliqué
|
||||
|
||||
Scénario: Recherche invalide ou introuvable
|
||||
Étant donné l'utilisateur saisit "Azertyuiopqsdfghjklm"
|
||||
Quand le système interroge Nominatim
|
||||
Alors Nominatim doit retourner 0 résultat
|
||||
Et un message d'erreur doit être affiché :
|
||||
"""
|
||||
Aucun lieu trouvé pour "Azertyuiopqsdfghjklm".
|
||||
Essayez un nom de ville, monument ou adresse.
|
||||
"""
|
||||
|
||||
# ============================================================================
|
||||
# RAYON DE RECHERCHE CONFIGURABLE
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Recherche avec rayon par défaut (5 km)
|
||||
Étant donné l'utilisateur cherche "Louvre, Paris"
|
||||
Et Nominatim retourne les coordonnées (48.8606, 2.3376)
|
||||
Et aucun rayon n'est spécifié
|
||||
Quand le système effectue la recherche de contenus
|
||||
Alors un rayon par défaut de 5 km doit être appliqué
|
||||
Et une requête PostGIS doit être exécutée :
|
||||
"""
|
||||
SELECT * FROM contents
|
||||
WHERE ST_DWithin(location::geography, ST_MakePoint(2.3376, 48.8606)::geography, 5000)
|
||||
"""
|
||||
|
||||
Scénario: Recherche avec rayon personnalisé (slider 1-50 km)
|
||||
Étant donné l'utilisateur cherche "Lyon"
|
||||
Et l'utilisateur ajuste le slider de rayon à 15 km
|
||||
Quand le système effectue la recherche de contenus
|
||||
Alors une requête PostGIS avec rayon 15000m doit être exécutée
|
||||
Et tous les contenus dans un rayon de 15 km autour de Lyon doivent être retournés
|
||||
|
||||
Scénario: Rayon minimum (1 km) - recherche ultra locale
|
||||
Étant donné l'utilisateur cherche "Place de la Concorde"
|
||||
Et l'utilisateur définit le rayon à 1 km (minimum)
|
||||
Quand le système effectue la recherche
|
||||
Alors seuls les contenus très proches (<1 km) doivent être retournés
|
||||
Et le nombre de résultats peut être très faible (0-10)
|
||||
|
||||
Scénario: Rayon maximum (50 km) - recherche large
|
||||
Étant donné l'utilisateur cherche "Versailles"
|
||||
Et l'utilisateur définit le rayon à 50 km (maximum)
|
||||
Quand le système effectue la recherche
|
||||
Alors tous les contenus dans un rayon de 50 km doivent être retournés
|
||||
Et cela peut inclure Paris, banlieue et zones périphériques
|
||||
Et un avertissement "Résultats nombreux, affinez votre recherche" peut s'afficher si >500 résultats
|
||||
|
||||
Scénario: Mise à jour temps réel du rayon avec slider
|
||||
Étant donné l'utilisateur visualise les résultats pour "Bordeaux" avec rayon 10 km
|
||||
Quand l'utilisateur ajuste le slider de 10 km à 20 km
|
||||
Alors une nouvelle requête API doit être déclenchée automatiquement
|
||||
Et les résultats doivent être mis à jour en temps réel
|
||||
Et la carte (si affichée) doit ajuster le cercle de rayon
|
||||
|
||||
# ============================================================================
|
||||
# FILTRES COMBINÉS AVEC RECHERCHE GÉO
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Recherche géo + filtre catégorie
|
||||
Étant donné l'utilisateur cherche "Marseille" avec rayon 10 km
|
||||
Et l'utilisateur filtre par catégorie "Tourisme"
|
||||
Quand le système effectue la recherche
|
||||
Alors seuls les contenus touristiques dans le rayon doivent être retournés
|
||||
Et la requête SQL doit combiner :
|
||||
"""
|
||||
WHERE ST_DWithin(...) AND category_id IN (SELECT id FROM categories WHERE name = 'Tourisme')
|
||||
"""
|
||||
|
||||
Scénario: Recherche géo + filtre type de contenu
|
||||
Étant donné l'utilisateur cherche "Strasbourg" avec rayon 5 km
|
||||
Et l'utilisateur filtre par type "Audio-guides"
|
||||
Quand le système effectue la recherche
|
||||
Alors seuls les audio-guides dans le rayon doivent être retournés
|
||||
Et les podcasts et radios live doivent être exclus
|
||||
|
||||
Scénario: Recherche géo + filtre durée
|
||||
Étant donné l'utilisateur cherche "Nice" avec rayon 15 km
|
||||
Et l'utilisateur filtre par durée "Court (<10 min)"
|
||||
Quand le système effectue la recherche
|
||||
Alors seuls les contenus de <10 minutes dans le rayon doivent être retournés
|
||||
|
||||
Scénario: Recherche géo + mode Kids actif
|
||||
Étant donné l'utilisateur cherche "Disneyland Paris" avec rayon 5 km
|
||||
Et le mode Kids est activé (utilisateur 13-15 ans)
|
||||
Quand le système effectue la recherche
|
||||
Alors seuls les contenus "Tout public" doivent être retournés
|
||||
Et les contenus 16+ et 18+ doivent être exclus automatiquement
|
||||
|
||||
Scénario: Recherche géo + filtre politique désactivé
|
||||
Étant donné l'utilisateur cherche "Assemblée Nationale" avec rayon 2 km
|
||||
Et l'utilisateur a désactivé les contenus politiques dans ses préférences
|
||||
Quand le système effectue la recherche
|
||||
Alors les contenus taggés "politique" doivent être exclus
|
||||
Même s'ils sont géographiquement pertinents
|
||||
|
||||
# ============================================================================
|
||||
# AFFICHAGE DES RÉSULTATS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Résultats triés par distance croissante
|
||||
Étant donné l'utilisateur cherche "Arc de Triomphe" avec rayon 3 km
|
||||
Quand les résultats sont retournés
|
||||
Alors ils doivent être triés par distance croissante :
|
||||
| contenu | distance |
|
||||
| Balade sur les Champs | 0.1 km |
|
||||
| Histoire de l'Arc | 0.2 km |
|
||||
| Quartier de l'Étoile | 0.5 km |
|
||||
| Secrets du 16e | 2.8 km |
|
||||
Et la distance doit être affichée pour chaque résultat
|
||||
|
||||
Scénario: Affichage carte avec marqueurs de contenus
|
||||
Étant donné l'utilisateur cherche "Toulouse" avec rayon 10 km
|
||||
Quand les résultats sont affichés en mode "Carte"
|
||||
Alors une carte Leaflet doit être affichée
|
||||
Et un marqueur doit être placé pour chaque contenu :
|
||||
| contenu | lat | lon | icone |
|
||||
| Capitole de Toulouse | 43.6045 | 1.4442 | pin-tourisme |
|
||||
| Bords de Garonne | 43.5986 | 1.4330 | pin-nature |
|
||||
Et un cercle représentant le rayon de 10 km doit être affiché
|
||||
Et le centre doit être le point géocodé de Toulouse
|
||||
|
||||
Scénario: Clustering de marqueurs si résultats nombreux
|
||||
Étant donné l'utilisateur cherche "Paris" avec rayon 20 km
|
||||
Et la recherche retourne 350 contenus
|
||||
Quand la carte est affichée
|
||||
Alors les marqueurs proches doivent être groupés en clusters :
|
||||
| cluster_center | nb_contenus |
|
||||
| Centre Paris | 120 |
|
||||
| La Défense | 45 |
|
||||
| Bois de Vincennes | 18 |
|
||||
Et en cliquant sur un cluster, le zoom doit s'approcher
|
||||
Et révéler les marqueurs individuels
|
||||
|
||||
Scénario: Affichage liste + carte simultanés (vue hybride)
|
||||
Étant donné l'utilisateur cherche "Nantes" avec rayon 8 km
|
||||
Quand l'utilisateur active la vue "Hybride"
|
||||
Alors la liste de résultats doit s'afficher à gauche (60% écran)
|
||||
Et la carte doit s'afficher à droite (40% écran)
|
||||
Et en cliquant sur un résultat dans la liste, le marqueur doit être highlighté sur la carte
|
||||
Et vice-versa
|
||||
|
||||
# ============================================================================
|
||||
# PERFORMANCES & OPTIMISATIONS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Cache résultats recherche géo fréquente (Paris, Lyon, Marseille)
|
||||
Étant donné l'utilisateur cherche "Paris" avec rayon 5 km
|
||||
Quand la requête est exécutée pour la 1ère fois
|
||||
Alors les résultats doivent être mis en cache Redis pendant 10 minutes
|
||||
Et les requêtes suivantes identiques doivent utiliser le cache
|
||||
Et un header "X-Cache: HIT" doit être retourné
|
||||
|
||||
Scénario: Index PostGIS pour performances requêtes spatiales
|
||||
Étant donné la table "contents" contient 100 000 contenus
|
||||
Quand une recherche géo est exécutée avec ST_DWithin
|
||||
Alors un index GIST sur la colonne "location" doit être utilisé
|
||||
Et le temps de réponse doit être <100ms (p95)
|
||||
|
||||
Scénario: Pagination résultats nombreux
|
||||
Étant donné l'utilisateur cherche "Île-de-France" avec rayon 50 km
|
||||
Et la recherche retourne 1200 contenus
|
||||
Quand les résultats sont affichés
|
||||
Alors seuls les 50 premiers résultats doivent être chargés initialement
|
||||
Et un scroll infini doit charger les résultats suivants par batch de 50
|
||||
Et le total "1200 contenus trouvés" doit être affiché en haut
|
||||
|
||||
# ============================================================================
|
||||
# EDGE CASES & ERREURS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Nominatim API indisponible (fallback)
|
||||
Étant donné l'utilisateur cherche "Lille"
|
||||
Quand l'API Nominatim retourne une erreur 503 (service unavailable)
|
||||
Alors un message d'erreur doit être affiché :
|
||||
"""
|
||||
Le service de recherche géographique est temporairement indisponible.
|
||||
Veuillez réessayer dans quelques instants.
|
||||
"""
|
||||
Et l'utilisateur doit pouvoir utiliser la recherche textuelle classique
|
||||
|
||||
Scénario: Recherche géo sans connexion Internet
|
||||
Étant donné l'utilisateur est en mode offline
|
||||
Quand l'utilisateur tente une recherche géographique
|
||||
Alors un message doit indiquer :
|
||||
"""
|
||||
La recherche géographique nécessite une connexion Internet.
|
||||
Vous pouvez parcourir les contenus téléchargés.
|
||||
"""
|
||||
|
||||
Scénario: Rate limiting Nominatim (1 req/s)
|
||||
Étant donné Nominatim impose un rate limit de 1 requête/seconde
|
||||
Et l'utilisateur tape rapidement "Par" → "Pari" → "Paris"
|
||||
Quand le système détecte plusieurs requêtes rapides
|
||||
Alors un debounce de 500ms doit être appliqué
|
||||
Et seule la dernière requête ("Paris") doit être envoyée à Nominatim
|
||||
|
||||
Scénario: Recherche avec caractères spéciaux ou injection SQL
|
||||
Étant donné l'utilisateur saisit "Paris'; DROP TABLE contents; --"
|
||||
Quand le système traite la requête
|
||||
Alors les caractères spéciaux doivent être échappés
|
||||
Et aucune injection SQL ne doit être possible
|
||||
Et Nominatim doit retourner 0 résultat (lieu invalide)
|
||||
|
||||
# ============================================================================
|
||||
# SAUVEGARDE DES RECHERCHES (max 5)
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Sauvegarde automatique d'une recherche géo
|
||||
Étant donné l'utilisateur effectue une recherche "Bordeaux" avec rayon 10 km
|
||||
Quand la recherche est validée
|
||||
Alors elle doit être sauvegardée dans l'historique :
|
||||
| search_query | Bordeaux |
|
||||
| radius_km | 10 |
|
||||
| lat | 44.8378 |
|
||||
| lon | -0.5792 |
|
||||
| timestamp | 2026-02-03 14:30:00 |
|
||||
Et l'utilisateur peut la rappeler via "Recherches récentes"
|
||||
|
||||
Scénario: Limite de 5 recherches sauvegardées (FIFO)
|
||||
Étant donné l'utilisateur a déjà 5 recherches sauvegardées
|
||||
Quand l'utilisateur effectue une 6ème recherche "Montpellier"
|
||||
Alors la recherche la plus ancienne doit être supprimée
|
||||
Et "Montpellier" doit être ajoutée en 1ère position
|
||||
Et la limite de 5 recherches doit être respectée
|
||||
|
||||
Scénario: Rejouer une recherche sauvegardée
|
||||
Étant donné l'utilisateur a une recherche sauvegardée "Lyon - 15 km"
|
||||
Quand l'utilisateur clique sur cette recherche dans l'historique
|
||||
Alors la recherche doit être ré-exécutée avec les mêmes paramètres
|
||||
Et les résultats actualisés doivent être affichés
|
||||
Et le rayon slider doit être positionné à 15 km
|
||||
|
||||
# ============================================================================
|
||||
# MÉTRIQUES & ANALYTICS
|
||||
# ============================================================================
|
||||
|
||||
Scénario: Logging des recherches géographiques pour analytics
|
||||
Étant donné l'utilisateur effectue une recherche "Grenoble" avec rayon 12 km
|
||||
Quand la recherche est exécutée
|
||||
Alors un événement analytics doit être loggé :
|
||||
| event_type | geo_search_executed |
|
||||
| search_query | Grenoble |
|
||||
| radius_km | 12 |
|
||||
| results_count | 87 |
|
||||
| response_time_ms | 145 |
|
||||
| cache_hit | false |
|
||||
| user_id | user-123 |
|
||||
| timestamp | 2026-02-03 14:30:00 |
|
||||
Et ces données doivent alimenter le dashboard de monitoring
|
||||
|
||||
Scénario: Top recherches géographiques (analytics)
|
||||
Étant donné le système analyse les recherches sur 30 jours
|
||||
Quand le dashboard analytics est consulté
|
||||
Alors les lieux les plus recherchés doivent être affichés :
|
||||
| lieu | nb_recherches |
|
||||
| Paris | 12450 |
|
||||
| Lyon | 5632 |
|
||||
| Marseille | 4521 |
|
||||
| Toulouse | 3890 |
|
||||
| Nice | 3124 |
|
||||
Et ces données doivent guider la création de contenus ciblés
|
||||
Reference in New Issue
Block a user