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>

features/api/rgpd-compliance/consentement.feature

@@ -0,0 +1,186 @@
+# language: fr
+
+@rgpd @consent
+Fonctionnalité: Gestion du consentement RGPD
+
+  Contexte:
+    Étant donné que je suis un nouvel utilisateur
+    Et que j'accède à l'application pour la première fois
+
+  # 13.1 - Gestion du consentement avec Tarteaucitron.js + PostgreSQL
+
+  Scénario: Affichage du banner de consentement au premier lancement web
+    Étant donné que j'accède à l'application web pour la première fois
+    Quand la page se charge
+    Alors un banner RGPD Tarteaucitron.js s'affiche
+    Et le banner est en français
+    Et le banner propose les options suivantes:
+      | option                   | description                          |
+      | Tout accepter            | Active tous les consentements        |
+      | Tout refuser             | Refuse tous les consentements optionnels |
+      | Personnaliser            | Ouvre le panneau de personnalisation |
+    Et le banner est customisé aux couleurs de RoadWave
+
+  Scénario: Granularité des consentements
+    Étant donné que le banner RGPD est affiché
+    Quand je clique sur "Personnaliser"
+    Alors je vois les catégories de consentements suivantes:
+      | catégorie     | type        | requis |
+      | Fonctionnel   | Nécessaire  | oui    |
+      | Analytique    | Optionnel   | non    |
+      | Marketing     | Optionnel   | non    |
+    Et chaque catégorie a une description claire de son usage
+    Et je peux accepter ou refuser chaque catégorie individuellement
+
+  Scénario: Consentement géolocalisation précise - obligatoire
+    Étant donné que je suis sur l'application mobile
+    Et que l'onboarding est terminé
+    Quand l'application a besoin d'accéder à ma position précise
+    Alors un écran de demande de consentement s'affiche
+    Et le message explique clairement l'usage:
+      """
+      RoadWave utilise votre position GPS pour vous proposer du contenu audio géolocalisé pertinent.
+      Vos données sont anonymisées après 24h.
+      """
+    Et je peux accepter ou refuser
+    Et si je refuse, l'application bascule en mode dégradé (GeoIP uniquement)
+
+  Scénario: Double consentement GPS - banner app + permission OS
+    Étant donné que je veux activer la géolocalisation précise
+    Quand j'accepte le consentement dans l'application
+    Alors l'application demande également la permission au système d'exploitation
+    Et sur iOS, la popup système s'affiche: "Autoriser RoadWave à accéder à votre position ?"
+    Et sur Android, la popup système s'affiche avec les options "Toujours autoriser / Autoriser seulement pendant l'utilisation / Refuser"
+    Et les deux consentements (app + OS) doivent être acceptés pour activer le GPS précis
+
+  # Historique des consentements - PostgreSQL backend
+
+  Scénario: Enregistrement du consentement en base de données
+    Étant donné que j'ai accepté les consentements suivants:
+      | type               | accepté |
+      | Fonctionnel        | oui     |
+      | Analytique         | oui     |
+      | Marketing          | non     |
+      | GPS précis         | oui     |
+    Quand je valide mes choix
+    Alors un enregistrement est créé dans la table `user_consents`
+    Et l'enregistrement contient les champs suivants:
+      | champ          | valeur                           |
+      | user_id        | [mon ID utilisateur]             |
+      | consent_type   | fonctionnel / analytique / gps   |
+      | version        | 1                                |
+      | accepted       | true / false                     |
+      | timestamp      | [date et heure exacte]           |
+    Et chaque type de consentement a un enregistrement séparé
+
+  Scénario: Versioning des consentements
+    Étant donné que j'ai accepté le consentement "Analytique" version 1 le 2025-01-01
+    Et que les CGU sont mises à jour le 2025-06-01
+    Quand je me connecte après la mise à jour
+    Alors un nouveau consentement version 2 m'est demandé
+    Et mon ancien consentement version 1 reste dans l'historique
+    Et je dois accepter la nouvelle version pour continuer à utiliser les analytics
+
+  Scénario: Historique complet conservé pour preuve légale
+    Étant donné que j'ai modifié mes consentements plusieurs fois:
+      | date       | consent_type | accepted | version |
+      | 2025-01-01 | Analytique   | oui      | 1       |
+      | 2025-03-15 | Analytique   | non      | 1       |
+      | 2025-06-01 | Analytique   | oui      | 2       |
+    Quand un auditeur CNIL consulte mon historique de consentements
+    Alors tous les enregistrements sont conservés
+    Et l'historique prouve que chaque consentement a été donné librement
+    Et les timestamps permettent de prouver la conformité à tout moment
+
+  # Consentements requis vs optionnels
+
+  Scénario: Consentement analytique - optionnel
+    Étant donné que je refuse le consentement "Analytique"
+    Quand j'utilise l'application
+    Alors aucun cookie Matomo `_pk_id` n'est déposé
+    Et aucune donnée d'usage n'est envoyée à Matomo
+    Et l'application fonctionne normalement sans analytics
+
+  Scénario: Consentement notifications push - optionnel
+    Étant donné que je refuse le consentement "Notifications push"
+    Quand un créateur que je suis publie un nouveau contenu
+    Alors je ne reçois pas de notification push
+    Mais je peux voir le nouveau contenu dans l'application
+    Et l'application fonctionne normalement
+
+  Scénario: Consentement GPS précis - requis pour fonctionnalités géo
+    Étant donné que je refuse le consentement "GPS précis"
+    Quand j'utilise l'application
+    Alors je peux accéder aux contenus nationaux
+    Mais les contenus géolocalisés précis (Ancré, Contextuel) ne sont pas disponibles
+    Et les audio-guides nécessitent l'activation du GPS
+    Et un banner permanent me rappelle que l'activation du GPS améliore l'expérience
+
+  # Modification des consentements
+
+  Scénario: Révocation d'un consentement depuis les paramètres
+    Étant donné que j'ai accepté le consentement "Analytique"
+    Et que j'utilise l'application depuis 3 mois
+    Quand j'ouvre "Paramètres > Confidentialité > Gérer mes consentements"
+    Alors je vois la liste de tous mes consentements actuels
+    Et je peux révoquer le consentement "Analytique"
+    Quand je révoque le consentement
+    Alors un nouvel enregistrement est créé avec `accepted = false`
+    Et le cookie Matomo est supprimé immédiatement
+    Et les analytics sont désactivées à partir de ce moment
+
+  Scénario: Acceptation d'un consentement précédemment refusé
+    Étant donné que j'avais refusé le consentement "GPS précis"
+    Quand j'ouvre "Paramètres > Confidentialité > Gérer mes consentements"
+    Et que je clique sur "Activer la géolocalisation précise"
+    Alors un nouvel enregistrement est créé avec `accepted = true`
+    Et la permission OS est demandée si ce n'est pas déjà fait
+    Et l'application bascule en mode géolocalisation précise
+    Et les contenus géolocalisés deviennent disponibles immédiatement
+
+  # Preuves légales pour contrôle CNIL
+
+  Scénario: Export de l'historique des consentements pour audit
+    Étant donné qu'un contrôle CNIL est en cours
+    Quand l'équipe RoadWave exporte l'historique des consentements
+    Alors l'export contient pour chaque utilisateur:
+      | champ          | description                        |
+      | user_id        | ID anonymisé                       |
+      | consent_type   | Type de consentement               |
+      | version        | Version des CGU/consentement       |
+      | accepted       | Accepté ou refusé                  |
+      | timestamp      | Date et heure exacte               |
+      | ip_address     | IP (anonymisée) au moment du consentement |
+      | user_agent     | Navigateur/app utilisé             |
+    Et l'export est au format CSV pour analyse
+    Et les données prouvent la conformité RGPD
+
+  Scénario: Conformité recommandations CNIL
+    Étant donné que le système de consentement est implémenté
+    Quand un auditeur CNIL vérifie la conformité
+    Alors le système respecte les critères suivants:
+      | critère CNIL                              | respecté |
+      | Consentement libre                        | oui      |
+      | Consentement spécifique (granulaire)      | oui      |
+      | Consentement éclairé (information claire) | oui      |
+      | Consentement univoque (action positive)   | oui      |
+      | Révocable à tout moment                   | oui      |
+      | Preuve du consentement conservée          | oui      |
+
+  # Opensource et self-hosted
+
+  Scénario: Tarteaucitron.js self-hosted
+    Étant donné que l'application web utilise Tarteaucitron.js
+    Quand je consulte les sources JavaScript chargées
+    Alors le script Tarteaucitron.js est hébergé sur les serveurs RoadWave
+    Et aucun script tiers (CDN externe) n'est chargé
+    Et le code source de Tarteaucitron.js est vérifiable
+    Et aucune donnée n'est envoyée à un tiers lors de l'affichage du banner
+
+  Scénario: Coût de la solution - 0€
+    Étant donné que Tarteaucitron.js est opensource
+    Et que PostgreSQL est utilisé pour le backend
+    Quand on calcule le coût de la solution de consentement
+    Alors le coût est de 0€
+    Et la solution est entièrement maîtrisée (self-hosted)
+    Et aucune dépendance à un service SaaS tiers