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.
85 lines
3.8 KiB
Gherkin
85 lines
3.8 KiB
Gherkin
# 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
|