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.

features/api/moderation/appel-droits-auteur.feature

@@ -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é

features/api/moderation/audit-trimestriel.feature

@@ -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

features/api/moderation/badges-system.feature

@@ -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é

features/api/moderation/detection-patterns-suspects.feature

@@ -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

features/api/moderation/limite-temporelle-anti-abus.feature

@@ -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

features/api/moderation/reduction-premium-badge-or.feature

@@ -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

features/api/moderation/sanctions-abus-progressives.feature

@@ -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

features/api/moderation/sanctions-droits-auteur.feature

@@ -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é

features/api/moderation/score-fiabilite-priorisation.feature

@@ -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

features/api/moderation/signalement-musique-posteriori.feature

@@ -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é

features/api/moderation/utilisateur-confiance.feature

@@ -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