feat(bdd): réorganiser features en catégories api/ui/e2e et créer ADR-024

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>
This commit is contained in:
jpgiannetti
2026-02-01 11:31:41 +01:00
parent 841028d1b2
commit 37c62206ad
88 changed files with 625 additions and 67 deletions

View File

@@ -0,0 +1,142 @@
# language: fr
Fonctionnalité: Pas de dégradation temporelle des jauges
En tant que système de recommandation
Je veux que les jauges n'évoluent que par les actions utilisateur
Afin d'avoir un comportement prévisible et fiable
Contexte:
Étant donné que l'API RoadWave est disponible
Et qu'un utilisateur est connecté
Scénario: Aucune dégradation automatique avec le temps
Étant donné que ma jauge "Économie" est à 80%
Et que je n'écoute aucun contenu pendant 30 jours
Quand je me reconnecte après 30 jours
Alors ma jauge "Économie" est toujours à 80%
Et aucune dégradation temporelle n'a été appliquée
Scénario: Jauges conservées après 6 mois d'inactivité
Étant donné que mes jauges sont:
| catégorie | niveau |
| Automobile | 75% |
| Voyage | 60% |
| Musique | 45% |
Et que je pars en vacances pendant 6 mois sans utiliser l'app
Quand je me reconnecte après 6 mois
Alors mes jauges sont exactement les mêmes:
| catégorie | niveau |
| Automobile | 75% |
| Voyage | 60% |
| Musique | 45% |
Scénario: Évolution naturelle par les actions
Étant donné que j'aimais "Économie" il y a 1 an (jauge 80%)
Et que depuis, je skip tous les contenus "Économie"
Et que j'ai skippé 50 contenus "Économie" en 1 an
Alors ma jauge "Économie" descend naturellement via les skips
Et atteint environ 55% (80% - 50 × 0.5% = 55%)
Et la dégradation vient des actions, pas du temps
Scénario: Pas de cron job de dégradation
Étant donné que le système vérifie les jauges quotidiennement
Quand un utilisateur n'a pas d'activité depuis 90 jours
Alors aucun job de dégradation n'est exécuté
Et les jauges restent inchangées
Et aucune ressource CPU n'est consommée pour la dégradation
Scénario: Comportement prévisible après absence
Étant donné que ma jauge "Sport" était à 70%
Et que je n'utilise pas l'app pendant 1 an
Quand je reviens et demande des recommandations
Alors mes recommandations reflètent toujours mes goûts d'avant
Et je reçois du contenu "Sport" prioritaire
Et le comportement est cohérent et prévisible
Scénario: Réinitialiser manuellement mes centres d'intérêt
Étant donné que je veux repartir de zéro
Quand je vais dans les paramètres
Et que je clique sur "Réinitialiser mes centres d'intérêt"
Et que je confirme l'action
Alors toutes mes jauges reviennent à 50%
Et je vois le message "Vos centres d'intérêt ont été réinitialisés"
Scénario: Confirmation avant réinitialisation
Étant donné que je suis dans les paramètres
Quand je clique sur "Réinitialiser mes centres d'intérêt"
Alors je vois un message de confirmation:
| titre | Êtes-vous sûr ? |
| message | Cette action remettra toutes vos jauges à 50% |
| actions | Confirmer / Annuler |
Scénario: Annuler la réinitialisation
Étant donné que j'ai cliqué sur "Réinitialiser mes centres d'intérêt"
Et que la confirmation est affichée
Quand je clique sur "Annuler"
Alors mes jauges ne sont pas modifiées
Et je reviens aux paramètres
Scénario: Raison de réinitialisation - changement de vie
Étant donné que j'utilisais RoadWave pour mes trajets professionnels
Et que mes jauges reflétaient "Économie" (85%) et "Technologie" (75%)
Et que je change de vie et deviens musicien
Quand je réinitialise mes centres d'intérêt
Alors je peux repartir avec toutes les jauges à 50%
Et découvrir du contenu "Musique" et "Culture" sans biais
Scénario: Pas de suggestion automatique de réinitialisation
Étant donné que je n'ai pas utilisé l'app depuis 1 an
Quand je me reconnecte
Alors aucune suggestion de réinitialisation n'est affichée
Et mes jauges sont conservées telles quelles
Et je garde le contrôle total
Scénario: Historique conservé après réinitialisation
Étant donné que j'ai écouté 500 contenus
Quand je réinitialise mes centres d'intérêt
Alors mes jauges reviennent à 50%
Mais mon historique d'écoute est conservé
Et je peux toujours consulter mes anciens contenus écoutés
Scénario: Évolution future basée sur nouvelles actions
Étant donné que j'ai réinitialisé mes jauges à 50%
Quand j'écoute 5 contenus "Voyage" à >80%
Alors ma jauge "Voyage" monte à 60% (50% + 5 × 2%)
Et l'algorithme recommence à apprendre mes nouvelles préférences
Scénario: Respect de l'historique utilisateur
Étant donné qu'un utilisateur aime "Cryptomonnaie" depuis 2 ans
Et que sa jauge est à 90%
Quand 2 ans s'écoulent sans dégradation temporelle
Alors sa jauge reste à 90%
Car l'historique de ses goûts est respecté
Et le système ne fait pas d'"oubli" artificiel
Scénario: Coût infrastructure zéro
Étant donné qu'aucune dégradation temporelle n'existe
Quand le système calcule les jauges
Alors aucun calcul de date n'est nécessaire
Et aucun batch nocturne ne tourne
Et aucun bug de fuseau horaire ne peut survenir
Et le coût CPU est minimal
Scénario: UX prévisible - jauge = actions
Étant donné qu'un utilisateur consulte sa jauge "Sport" à 65%
Quand il se demande pourquoi elle est à 65%
Alors il peut retracer ses actions:
| action | impact |
| 10 likes automatiques | +10% |
| 3 abonnements Sport | +15% |
| 5 skips de contenu non-Sport| 0% |
Et il comprend que c'est le reflet exact de ses actions
Et il n'y a pas de mystère ou automatisme caché
Scénario: Statistiques affichées sans date
Étant donné que je consulte mes centres d'intérêt
Quand je vois mes jauges
Alors je vois:
| information | affiché |
| Niveau actuel | 75% |
| Évolution depuis début | +25% |
| Dernière mise à jour | |
Et aucune date n'est affichée car non pertinente
Et seules les actions comptent