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/moderation/traitement-signalements.feature

@@ -0,0 +1,268 @@
+# language: fr
+
+@moderation @processing
+Fonctionnalité: Traitement des signalements par l'IA et les modérateurs
+
+  # 14.2 - Traitement des signalements
+
+  Contexte:
+    Étant donné que le système de modération est actif
+
+  # 14.2.1 - IA pré-filtre (Whisper + NLP)
+
+  Scénario: Signalement ajouté à la file d'attente asynchrone
+    Étant donné qu'un utilisateur envoie un signalement pour un contenu audio
+    Quand le signalement est reçu
+    Alors le signalement est ajouté à la file d'attente asynchrone
+    Et un worker de traitement est déclenché
+    Et le traitement se fait en arrière-plan sans bloquer l'utilisateur
+
+  Scénario: Transcription automatique avec Whisper large-v3
+    Étant donné qu'un contenu audio signalé dure 5 minutes
+    Quand le worker de traitement démarre
+    Alors le système utilise Whisper large-v3 pour transcrire l'audio
+    Et la transcription est en self-hosted (pas de service cloud)
+    Et le texte transcrit est enregistré en base de données
+    Et le délai de transcription est de 1-3 minutes
+
+  Plan du Scénario: Délai de transcription selon durée audio
+    Étant donné qu'un contenu audio signalé dure <duree> minutes
+    Quand le système transcrit l'audio
+    Alors la transcription prend environ <delai>
+
+    Exemples:
+      | duree | delai         |
+      | 2     | 1-3 minutes   |
+      | 10    | 3-10 minutes  |
+      | 45    | 10-20 minutes |
+
+  Scénario: Analyse automatique du contenu transcrit
+    Étant donné que la transcription audio est terminée
+    Quand le système analyse le texte transcrit
+    Alors les analyses suivantes sont effectuées:
+      | analyse                  | technologie                       |
+      | Analyse de sentiment     | distilbert-base-uncased           |
+      | Détection de haine       | facebook/roberta-hate-speech      |
+      | Mots-clés interdits      | Liste noire FR/EN + regex         |
+    Et chaque analyse génère un score de confiance (0-100%)
+
+  Scénario: Génération du score de confiance IA
+    Étant donné que toutes les analyses sont terminées
+    Quand le système calcule le score final
+    Alors un score de confiance IA entre 0-100% est généré
+    Et le score indique la probabilité que le contenu viole les règles
+    Et la catégorie la plus probable est identifiée
+    Et les timestamps des passages problématiques sont extraits
+
+  Scénario: Détection automatique de contenu clairement inapproprié
+    Étant donné qu'un contenu contient des insultes graves et répétées
+    Quand l'IA analyse la transcription
+    Alors le score de confiance IA est >95%
+    Et la catégorie détectée est "Haine & violence"
+    Et les passages problématiques sont identifiés avec timestamps:
+      | timestamp | texte problématique                |
+      | 02:15     | [insulte discriminatoire]          |
+      | 03:42     | [propos haineux]                   |
+    Et le signalement est classé en priorité CRITIQUE
+
+  # 14.2.2 - Délais de traitement (SLA)
+
+  Plan du Scénario: SLA selon priorité du signalement
+    Étant donné qu'un signalement a une priorité "<priorite>"
+    Quand le signalement entre en file d'attente
+    Alors le délai de traitement cible est "<delai>"
+    Et le responsable du traitement est "<responsable>"
+
+    Exemples:
+      | priorite | delai                  | responsable                    |
+      | CRITIQUE | <2h (24/7)             | Modérateur senior (astreinte)  |
+      | HAUTE    | <24h (jours ouvrés)    | Modérateur junior/senior       |
+      | MOYENNE  | <24h (jours ouvrés)    | Modérateur junior              |
+      | BASSE    | <72h (jours ouvrés)    | Modérateur junior              |
+
+  Scénario: Traitement automatique pour score IA >95%
+    Étant donné qu'un signalement a un score IA de 97%
+    Et que la catégorie détectée est "Spam" (évidente)
+    Quand le système évalue le signalement
+    Alors une action automatique immédiate est déclenchée
+    Et le contenu est retiré automatiquement
+    Et le créateur est notifié de la modération
+    Et le créateur peut faire appel de la décision
+    Et un modérateur senior vérifie l'action a posteriori
+
+  Scénario: Signalement CRITIQUE traité en moins de 2h
+    Étant donné qu'un signalement de priorité CRITIQUE est reçu à 14:00
+    Et que le contenu concerne une menace de violence
+    Quand le signalement est assigné à un modérateur senior d'astreinte
+    Alors le modérateur est alerté immédiatement (push + SMS)
+    Et le signalement est traité avant 16:00 (2h)
+    Et une décision est prise et appliquée
+    Et les autorités peuvent être contactées si nécessaire
+
+  Scénario: Astreinte modérateur 24/7 pour signalements CRITIQUES
+    Étant donné qu'un signalement CRITIQUE est reçu un dimanche à 03:00
+    Quand le signalement est classé en priorité CRITIQUE
+    Alors le modérateur senior d'astreinte est alerté
+    Et le signalement est traité dans les 2h (avant 05:00)
+    Et le service d'astreinte garantit une disponibilité 24/7
+
+  Scénario: Signalement HAUTE priorité traité en moins de 24h
+    Étant donné qu'un signalement de priorité HAUTE est reçu lundi à 10:00
+    Et que le contenu concerne du harcèlement
+    Quand le signalement entre en file d'attente
+    Alors le signalement est assigné à un modérateur (junior ou senior)
+    Et le signalement est traité avant mardi 10:00 (24h jours ouvrés)
+    Et une décision est prise et appliquée
+
+  Scénario: Signalement BASSE priorité traité en moins de 72h
+    Étant donné qu'un signalement de priorité BASSE est reçu lundi à 10:00
+    Et que le contenu concerne des tags incorrects
+    Quand le signalement entre en file d'attente
+    Alors le signalement est traité avant jeudi 10:00 (72h jours ouvrés)
+    Et un modérateur junior peut traiter ce type de signalement
+
+  # 14.2.3 - Priorisation automatique
+
+  Scénario: Calcul du score de priorité
+    Étant donné qu'un signalement a les caractéristiques suivantes:
+      | caractéristique           | valeur |
+      | Score IA                  | 85%    |
+      | Signalements cumulés      | 3      |
+      | Fiabilité du signaleur    | 75%    |
+    Quand le système calcule la priorité
+    Alors la formule appliquée est:
+      """
+      Priorité = (Score_IA × 0.7) + (Signalements_cumulés × 0.2) + (Fiabilité_signaleur × 0.1)
+      """
+    Et le score de priorité est: (85 × 0.7) + (3 × 0.2) + (75 × 0.1) = 67.5
+    Et le signalement est classé en priorité MOYENNE
+
+  Plan du Scénario: Classification selon score de priorité
+    Étant donné qu'un signalement a un score de priorité de <score>
+    Quand le système classe le signalement
+    Alors la priorité assignée est "<priorite>"
+    Et le signalement entre dans la file "<file>"
+
+    Exemples:
+      | score | priorite | file              |
+      | 95    | CRITIQUE | Immédiate         |
+      | 82    | HAUTE    | Prioritaire       |
+      | 55    | MOYENNE  | Normale           |
+      | 25    | BASSE    | Différée          |
+
+  Scénario: Boost de priorité avec signalements cumulés
+    Étant donné qu'un contenu a été signalé par 1 utilisateur avec un score IA de 60%
+    Et que le signalement est classé en priorité MOYENNE (score 42)
+    Quand 5 autres utilisateurs signalent le même contenu
+    Alors le nombre de signalements cumulés passe à 6
+    Et le score de priorité augmente significativement
+    Et le signalement peut passer en priorité HAUTE
+    Et le traitement est accéléré
+
+  Scénario: Impact de la fiabilité du signaleur
+    Étant donné qu'un utilisateur de confiance (90% fiabilité) envoie un signalement
+    Et qu'un utilisateur suspect (20% fiabilité) envoie un signalement similaire
+    Quand le système calcule les priorités
+    Alors le signalement de l'utilisateur de confiance a un score plus élevé
+    Et son signalement est traité en priorité
+    Et le signalement de l'utilisateur suspect est traité plus tard
+
+  Scénario: Évolution du score de fiabilité du signaleur
+    Étant donné qu'un utilisateur a envoyé 10 signalements
+    Et que 8 d'entre eux ont été acceptés par les modérateurs
+    Quand le système calcule son score de fiabilité
+    Alors le score est de 80% (8 acceptés / 10 total)
+    Et ses futurs signalements auront plus de poids
+    Et il peut devenir "utilisateur de confiance"
+
+  # File d'attente intelligente
+
+  Scénario: Files d'attente séparées par priorité
+    Étant donné que 50 signalements sont en attente
+    Quand le système organise la file d'attente
+    Alors les signalements sont répartis dans les files suivantes:
+      | file              | nombre | priorité  |
+      | Immédiate (24/7)  | 5      | CRITIQUE  |
+      | Prioritaire       | 15     | HAUTE     |
+      | Normale           | 20     | MOYENNE   |
+      | Différée          | 10     | BASSE     |
+    Et les modérateurs traitent en priorité la file Immédiate
+
+  Scénario: Modérateurs assignés selon compétences
+    Étant donné qu'un signalement complexe de harcèlement est reçu
+    Quand le système assigne un modérateur
+    Alors un modérateur senior est prioritairement assigné
+    Et les modérateurs juniors peuvent traiter les cas simples (spam, tags)
+    Et les modérateurs seniors traitent les cas complexes (haine, violence, appels)
+
+  # Technologies opensource
+
+  Scénario: Stack technique 100% opensource
+    Étant donné que le système de modération IA est déployé
+    Quand on analyse les technologies utilisées
+    Alors toutes les technologies sont opensource:
+      | composant              | technologie                       | hébergement |
+      | Transcription          | Whisper large-v3                  | Self-hosted |
+      | Analyse sentiment      | distilbert-base-uncased           | Self-hosted |
+      | Détection haine        | facebook/roberta-hate-speech      | Self-hosted |
+      | Mots-clés interdits    | Liste noire FR/EN + regex         | PostgreSQL  |
+    Et aucune dépendance à Google, AWS, Azure
+
+  # Coût infrastructure
+
+  Plan du Scénario: Coût selon phase du projet
+    Étant donné que RoadWave est en phase "<phase>"
+    Quand on calcule le coût de l'infrastructure IA
+    Alors le coût mensuel est "<cout>"
+
+    Exemples:
+      | phase | cout              |
+      | MVP   | 0-50€ (CPU)       |
+      | Scale | 50-200€ (GPU VPS) |
+
+  Scénario: Processing asynchrone en MVP avec CPU
+    Étant donné que RoadWave est en phase MVP
+    Et que le volume est <1000 signalements/mois
+    Quand le système traite les signalements
+    Alors un serveur CPU standard est suffisant
+    Et le coût est de 0€ (serveur existant)
+    Et le processing asynchrone absorbe les pics de charge
+    Et les délais restent acceptables (1-20 minutes)
+
+  Scénario: Scaling avec GPU pour gros volumes
+    Étant donné que RoadWave reçoit >1000 signalements/jour
+    Quand le système nécessite un scaling
+    Alors un VPS avec GPU est requis
+    Et le coût passe à 50-200€/mois
+    Et les délais de transcription sont divisés par 5-10
+    Et le système peut gérer 10 000+ signalements/mois
+
+  # Logs et audit
+
+  Scénario: Logs d'audit pour chaque traitement
+    Étant donné qu'un signalement est traité
+    Quand une action est prise (rejet, acceptation, sanction)
+    Alors un log d'audit complet est créé:
+      | champ                    | description                        |
+      | signalement_id           | ID unique du signalement           |
+      | content_id               | ID du contenu signalé              |
+      | ia_score                 | Score de confiance IA              |
+      | ia_category              | Catégorie détectée par IA          |
+      | priority                 | CRITIQUE / HAUTE / MOYENNE / BASSE |
+      | moderator_id             | ID du modérateur assigné           |
+      | action_taken             | Retiré / Rejeté / Strike           |
+      | processing_time          | Durée du traitement                |
+      | timestamp                | Date et heure de la décision       |
+    Et le log est conservé pour conformité DSA
+    Et les logs sont anonymisés après 3 ans (RGPD)
+
+  # Conformité DSA
+
+  Scénario: Traçabilité complète pour conformité DSA
+    Étant donné que le système de modération est actif
+    Quand un audit DSA est effectué
+    Alors toutes les actions de modération sont tracées
+    Et les délais de traitement sont mesurés et respectés
+    Et les décisions sont justifiées et documentées
+    Et la transparence vis-à-vis des utilisateurs est garantie
+    Et le système est conforme au Digital Services Act