37c62206ad
Résolution des incohérences #10, #11, et #12 de l'analyse d'architecture. ## Phase 1 : Réorganisation Features BDD (Point #10 - RÉSOLU) - Créer structure features/{api,ui,e2e} - Déplacer 83 features en 3 catégories via git mv (historique préservé) - features/api/ : 53 features (tests API backend) - features/ui/ : 22 features (tests UI mobile) - features/e2e/ : 8 features (tests end-to-end) Domaines déplacés : - API : authentication, recommendation, rgpd-compliance, content-creation, moderation, monetisation, premium, radio-live, publicites - UI : audio-guides, navigation, interest-gauges, mode-offline, partage, profil, recherche - E2E : abonnements, error-handling ## Phase 2 : Mise à jour Documentation ### ADR-007 - Tests BDD - Ajouter section "Convention de Catégorisation des Features" - Documenter règles api/ui/e2e avec exemples concrets - Spécifier step definitions (backend Go, mobile Dart) ### ADR-024 - Stratégie CI/CD Monorepo (NOUVEAU) - Créer ADR dédié pour stratégie CI/CD avec path filters - Architecture workflows séparés (backend.yml, mobile.yml, shared.yml) - Configuration path filters détaillée avec exemples YAML - Matrice de déclenchement et optimisations (~70% gain temps CI) - Plan d'implémentation (~2h, reporté jusqu'au développement) ### ADR-016 - Organisation Monorepo - Simplifier en retirant section CI/CD détaillée - Ajouter référence vers ADR-024 pour stratégie CI/CD ### INCONSISTENCIES-ANALYSIS.md - Point #10 (Tests BDD synchronisés) : ✅ RÉSOLU - Catégorisation features implémentée - ADR-007 mis à jour avec convention complète - Point #11 (70/30 Split paiements) : ✅ ANNULÉ (faux problème) - ADR-009 et Règle 18 parfaitement cohérents - Documentation exhaustive existante (formule, SQL, comparaisons) - Point #12 (Monorepo path filters) : ⏸️ DOCUMENTÉ - Architecture CI/CD complète dans ADR-024 - Implémentation reportée (projet en phase documentation) - Métriques mises à jour : - MODERATE : 6/9 traités (4 résolus + 1 annulé + 1 documenté) - ADR à jour : 100% (19/19 avec ADR-024) ## Phase 3 : Validation - Structure features validée (api/ui/e2e, aucun répertoire restant) - Historique Git préservé (git mv, renommages détectés) - 83 features total (API: 53, UI: 22, E2E: 8) Closes: Point #10 (résolu), Point #11 (annulé), Point #12 (documenté) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
164 lines
7.2 KiB
Gherkin
164 lines
7.2 KiB
Gherkin
# language: fr
|
|
Fonctionnalité: Paramétrabilité admin et A/B testing
|
|
En tant qu'administrateur RoadWave
|
|
Je veux configurer les paramètres de l'algorithme à chaud
|
|
Afin d'optimiser l'engagement sans redéploiement
|
|
|
|
Contexte:
|
|
Étant donné que l'API RoadWave est disponible
|
|
Et que je suis connecté en tant qu'admin
|
|
|
|
Scénario: Accès au dashboard admin
|
|
Quand j'accède au dashboard admin
|
|
Alors je vois tous les paramètres configurables de l'algorithme
|
|
Et je vois les valeurs actuelles et par défaut
|
|
|
|
Scénario: Modifier le poids géo pour contenu ancré
|
|
Étant donné que le poids_geo_ancre est à 0.7 (défaut)
|
|
Quand je modifie le poids_geo_ancre à 0.8
|
|
Et que je sauvegarde
|
|
Alors la nouvelle valeur est appliquée immédiatement
|
|
Et tous les nouveaux calculs utilisent 0.8
|
|
Et je vois le message "Paramètre mis à jour avec succès"
|
|
|
|
Scénario: Validation des plages de valeurs
|
|
Quand j'essaie de configurer poids_geo_ancre à 1.5 (hors plage 0.5-1.0)
|
|
Alors la modification échoue
|
|
Et je vois le message "Valeur hors plage autorisée (0.5 - 1.0)"
|
|
|
|
Plan du Scénario: Modification de tous les paramètres configurables
|
|
Quand je modifie "<parametre>" à "<nouvelle_valeur>"
|
|
Alors la modification est appliquée immédiatement
|
|
Et la nouvelle valeur respecte la plage "<plage>"
|
|
|
|
Exemples:
|
|
| parametre | nouvelle_valeur | plage |
|
|
| poids_geo_ancre | 0.8 | 0.5 - 1.0 |
|
|
| poids_geo_contextuel | 0.6 | 0.3 - 0.7 |
|
|
| poids_geo_neutre | 0.3 | 0.0 - 0.4 |
|
|
| poids_engagement | 0.3 | 0.0 - 0.5 |
|
|
| part_aleatoire_global | 0.15 | 0.0 - 0.3 |
|
|
| distance_max_km | 150 | 50 - 500 |
|
|
| rayon_gps_point_m | 1000 | 100 - 2000 |
|
|
| seuil_min_ecoutes_engagement | 100 | 10 - 200 |
|
|
|
|
Scénario: Aucun recalcul batch après modification
|
|
Étant donné que le poids_geo_ancre est modifié de 0.7 à 0.8
|
|
Quand la modification est appliquée
|
|
Alors aucun recalcul batch n'est lancé (économie CPU)
|
|
Et seuls les nouveaux calculs utilisent la valeur 0.8
|
|
|
|
Scénario: Versioning des configurations
|
|
Étant donné que je modifie plusieurs paramètres
|
|
Quand je sauvegarde la configuration
|
|
Alors une nouvelle version est créée (ex: v1.2.3)
|
|
Et je peux voir l'historique des versions
|
|
Et je peux comparer deux versions
|
|
|
|
Scénario: Rollback en 1 clic
|
|
Étant donné que la configuration actuelle est v1.2.3
|
|
Et que la version précédente était v1.2.2
|
|
Quand je clique sur "Restaurer v1.2.2"
|
|
Alors tous les paramètres de v1.2.2 sont réappliqués
|
|
Et je vois le message "Configuration restaurée à v1.2.2"
|
|
|
|
Scénario: Créer une variante A/B testing
|
|
Quand je crée une nouvelle variante "Test engagement élevé"
|
|
Et que je configure:
|
|
| parametre | valeur |
|
|
| poids_engagement | 0.4 |
|
|
| poids_geo_ancre | 0.6 |
|
|
Et que je lance le test A/B
|
|
Alors 50% des utilisateurs reçoivent la Config A (défaut)
|
|
Et 50% des utilisateurs reçoivent la Config B (test)
|
|
|
|
Scénario: Split utilisateurs aléatoire pour A/B test
|
|
Étant donné qu'un test A/B est actif
|
|
Quand 1000 nouveaux utilisateurs se connectent
|
|
Alors environ 500 sont assignés à la Config A
|
|
Et environ 500 sont assignés à la Config B
|
|
Et l'assignation est aléatoire et équilibrée
|
|
|
|
Scénario: Utilisateur reste dans la même variante
|
|
Étant donné qu'un utilisateur est assigné à la Config B
|
|
Quand il se reconnecte plusieurs fois
|
|
Alors il reste toujours dans la Config B
|
|
Et il ne change pas de variante pendant le test
|
|
|
|
Scénario: Métriques comparatives A/B testing
|
|
Étant donné qu'un test A/B est actif depuis 7 jours
|
|
Quand je consulte le dashboard A/B testing
|
|
Alors je vois les métriques suivantes pour chaque config:
|
|
| metrique | Config A | Config B |
|
|
| Taux complétion moyen | 68% | 72% |
|
|
| Engagement (likes) | 15% | 18% |
|
|
| Durée session moyenne | 23 min | 27 min |
|
|
| Taux skip rapide (<10s) | 12% | 9% |
|
|
|
|
Scénario: Dashboard graphique temps réel
|
|
Étant donné qu'un test A/B est actif
|
|
Quand je consulte le dashboard
|
|
Alors je vois des graphiques temps réel:
|
|
| graphique | type |
|
|
| Évolution engagement | Ligne |
|
|
| Répartition utilisateurs| Camembert |
|
|
| Taux complétion | Barres |
|
|
| Durée session | Ligne |
|
|
|
|
Scénario: Terminer un test A/B et appliquer la meilleure config
|
|
Étant donné qu'un test A/B montre que Config B est meilleure
|
|
Quand je clique sur "Appliquer Config B pour tous"
|
|
Alors la Config B devient la configuration par défaut
|
|
Et tous les utilisateurs utilisent maintenant Config B
|
|
Et l'ancien test est archivé
|
|
|
|
Scénario: Audit engagement global
|
|
Quand je consulte la section "Audit engagement"
|
|
Alors je vois:
|
|
| metrique | valeur |
|
|
| Temps écoute moyen/session | 25 min |
|
|
| Temps écoute médian/session | 18 min |
|
|
| Taux complétion moyen | 70% |
|
|
| % sessions avec ≥1 like | 35% |
|
|
|
|
Scénario: Graphiques évolution engagement selon config
|
|
Étant donné que plusieurs modifications de config ont été faites
|
|
Quand je consulte les graphiques d'évolution
|
|
Alors je vois l'impact de chaque changement de config
|
|
Et je peux corréler changements config avec métriques
|
|
|
|
Scénario: Export CSV pour analyse externe
|
|
Quand je clique sur "Exporter données"
|
|
Alors je peux télécharger un CSV avec:
|
|
| colonne | exemple |
|
|
| date | 2026-01-21 |
|
|
| version_config | v1.2.3 |
|
|
| taux_completion | 0.72 |
|
|
| engagement_moyen | 0.45 |
|
|
| duree_session_min | 27 |
|
|
|
|
Scénario: Alerte automatique si métrique critique baisse
|
|
Étant donné que le taux de complétion moyen est à 70%
|
|
Quand une nouvelle config fait baisser le taux à 55%
|
|
Alors je reçois une alerte email "Baisse critique du taux de complétion"
|
|
Et je peux rollback rapidement
|
|
|
|
Scénario: Prévisualisation impact avant application
|
|
Étant donné que je modifie poids_geo_ancre de 0.7 à 0.9
|
|
Quand je clique sur "Prévisualiser impact"
|
|
Alors je vois une simulation sur échantillon de 1000 utilisateurs
|
|
Et je vois l'estimation d'impact sur les métriques clés
|
|
|
|
Scénario: Notes et commentaires sur modifications config
|
|
Quand je modifie une configuration
|
|
Alors je peux ajouter une note "Test pour améliorer contenu local"
|
|
Et cette note est visible dans l'historique des versions
|
|
Et l'équipe peut comprendre le contexte des changements
|
|
|
|
Scénario: Permissions admin pour modification config
|
|
Étant donné que je suis un admin junior
|
|
Quand j'essaie de modifier un paramètre critique
|
|
Alors l'accès est refusé
|
|
Et je vois "Permission admin senior requise"
|
|
Et seuls les admins seniors peuvent modifier les paramètres
|