5e5fcf4714
Réorganise la documentation du projet selon les principes du Domain-Driven Design (DDD) pour améliorer la cohésion, la maintenabilité et l'alignement avec l'architecture modulaire du backend. **Structure cible:** ``` docs/domains/ ├── README.md (Context Map) ├── _shared/ (Core Domain) ├── recommendation/ (Supporting Subdomain) ├── content/ (Supporting Subdomain) ├── moderation/ (Supporting Subdomain) ├── advertising/ (Generic Subdomain) ├── premium/ (Generic Subdomain) └── monetization/ (Generic Subdomain) ``` **Changements effectués:** Phase 1: Création de l'arborescence des 7 bounded contexts Phase 2: Déplacement des règles métier (01-19) vers domains/*/rules/ Phase 3: Déplacement des diagrammes d'entités vers domains/*/entities/ Phase 4: Déplacement des diagrammes flux/états/séquences vers domains/*/ Phase 5: Création des README.md pour chaque domaine Phase 6: Déplacement des features Gherkin vers domains/*/features/ Phase 7: Création du Context Map (domains/README.md) Phase 8: Mise à jour de mkdocs.yml pour la nouvelle navigation Phase 9: Correction automatique des liens internes (script fix-markdown-links.sh) Phase 10: Nettoyage de l'ancienne structure (regles-metier/, diagrammes/, features/) **Configuration des tests:** - Makefile: godog run docs/domains/*/features/ - scripts/generate-bdd-docs.py: features_dir → docs/domains **Avantages:** ✅ Cohésion forte: toute la doc d'un domaine au même endroit ✅ Couplage faible: domaines indépendants, dépendances explicites ✅ Navigabilité améliorée: README par domaine = entrée claire ✅ Alignement code/docs: miroir de backend/internal/ ✅ Onboarding facilité: exploration domaine par domaine ✅ Tests BDD intégrés: features au plus près des règles métier Voir docs/REFACTOR-DDD.md pour le plan complet.
271 lines
13 KiB
Gherkin
271 lines
13 KiB
Gherkin
# 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 précis:
|
||
| timestamp | durée | texte problématique | score confiance |
|
||
| 02:15 | 12s | [insulte discriminatoire] | 97% |
|
||
| 03:42 | 18s | [propos haineux] | 95% |
|
||
Et chaque passage problématique a un timestamp de début et de fin
|
||
Et le signalement est classé en priorité CRITIQUE
|
||
Et les timestamps sont utilisés pour générer les marqueurs audio dans le dashboard modérateur
|
||
|
||
# 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
|