37c62206ad
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>
264 lines
12 KiB
Gherkin
264 lines
12 KiB
Gherkin
# language: fr
|
|
Fonctionnalité: Conditions d'activation de la monétisation
|
|
En tant que créateur
|
|
Je veux pouvoir activer la monétisation quand je remplis les critères
|
|
Afin de générer des revenus avec mes contenus
|
|
|
|
Contexte:
|
|
Étant donné que l'API RoadWave est disponible
|
|
Et que je suis connecté en tant que créateur
|
|
|
|
Scénario: Critère 1 - Ancienneté de 3 mois validée
|
|
Étant donné que mon compte a été créé il y a 91 jours
|
|
Quand je consulte les critères de monétisation
|
|
Alors le critère "Ancienneté ≥ 3 mois" est validé ✅
|
|
|
|
Scénario: Critère 1 - Ancienneté insuffisante
|
|
Étant donné que mon compte a été créé il y a 60 jours
|
|
Quand je consulte les critères de monétisation
|
|
Alors le critère "Ancienneté ≥ 3 mois" n'est pas validé ❌
|
|
Et je vois "Encore 30 jours avant d'être éligible"
|
|
|
|
Scénario: Critère 2 - 500 abonnés atteints
|
|
Étant donné que j'ai exactement 500 abonnés
|
|
Quand je consulte les critères de monétisation
|
|
Alors le critère "≥ 500 abonnés" est validé ✅
|
|
|
|
Scénario: Critère 2 - Pas assez d'abonnés
|
|
Étant donné que j'ai 347 abonnés
|
|
Quand je consulte les critères de monétisation
|
|
Alors le critère "≥ 500 abonnés" n'est pas validé ❌
|
|
Et je vois "Encore 153 abonnés nécessaires"
|
|
|
|
Scénario: Critère 3 - 10 000 écoutes complètes atteintes
|
|
Étant donné que mes contenus ont cumulé 10 487 écoutes complètes
|
|
Quand je consulte les critères de monétisation
|
|
Alors le critère "≥ 10 000 écoutes complètes" est validé ✅
|
|
|
|
Scénario: Critère 3 - Écoutes incomplètes non comptabilisées
|
|
Étant donné que mes contenus ont:
|
|
| type écoute | nombre |
|
|
| Écoutes complètes | 8 500 |
|
|
| Écoutes <80% | 3 000 |
|
|
Quand je consulte les critères de monétisation
|
|
Alors seules les 8 500 écoutes complètes comptent
|
|
Et je vois "Encore 1 500 écoutes complètes nécessaires"
|
|
|
|
Scénario: Critère 4 - Aucun strike actif
|
|
Étant donné que je n'ai aucun strike actif
|
|
Et que je n'ai eu aucun contenu modéré dans les 6 derniers mois
|
|
Quand je consulte les critères de monétisation
|
|
Alors le critère "Fiabilité" est validé ✅
|
|
|
|
Scénario: Critère 4 - Strike actif bloque l'éligibilité
|
|
Étant donné que j'ai 1 strike actif pour contenu inapproprié
|
|
Quand je consulte les critères de monétisation
|
|
Alors le critère "Fiabilité" n'est pas validé ❌
|
|
Et je vois "Vous devez résoudre votre strike avant d'être éligible"
|
|
|
|
Scénario: Critère 4 - Contenu modéré dans les 6 derniers mois
|
|
Étant donné que je n'ai pas de strike actif
|
|
Mais qu'un de mes contenus a été modéré il y a 4 mois
|
|
Quand je consulte les critères de monétisation
|
|
Alors le critère "Fiabilité" n'est pas validé ❌
|
|
Et je vois "Attendre 2 mois après le dernier contenu modéré"
|
|
|
|
Scénario: Critère 5 - 5 contenus publiés dans les 90 derniers jours
|
|
Étant donné que j'ai publié:
|
|
| date de publication | titre |
|
|
| Il y a 15 jours | Contenu 1 |
|
|
| Il y a 30 jours | Contenu 2 |
|
|
| Il y a 45 jours | Contenu 3 |
|
|
| Il y a 60 jours | Contenu 4 |
|
|
| Il y a 75 jours | Contenu 5 |
|
|
Quand je consulte les critères de monétisation
|
|
Alors le critère "≥ 5 contenus publiés dans les 90 derniers jours" est validé ✅
|
|
|
|
Scénario: Critère 5 - Contenus trop anciens ne comptent pas
|
|
Étant donné que j'ai publié:
|
|
| date de publication | titre |
|
|
| Il y a 15 jours | Contenu 1 |
|
|
| Il y a 30 jours | Contenu 2 |
|
|
| Il y a 95 jours | Contenu 3 |
|
|
| Il y a 120 jours | Contenu 4 |
|
|
Quand je consulte les critères de monétisation
|
|
Alors seuls 2 contenus comptent (dans les 90 jours)
|
|
Et je vois "Encore 3 contenus à publier dans les 90 prochains jours"
|
|
|
|
Scénario: Tous les critères validés - Bouton disponible
|
|
Étant donné que tous mes critères sont validés:
|
|
| critère | statut |
|
|
| Ancienneté ≥ 3 mois | ✅ |
|
|
| ≥ 500 abonnés | ✅ |
|
|
| ≥ 10 000 écoutes | ✅ |
|
|
| Fiabilité | ✅ |
|
|
| Régularité (5 contenus) | ✅ |
|
|
Quand j'accède à mon profil créateur
|
|
Alors le bouton "Demander la monétisation" est actif
|
|
Et je peux cliquer pour démarrer le KYC
|
|
|
|
Scénario: Critères incomplets - Bouton grisé avec progression
|
|
Étant donné que mes critères sont:
|
|
| critère | statut | progression |
|
|
| Ancienneté ≥ 3 mois | ✅ | 100% |
|
|
| ≥ 500 abonnés | ❌ | 347/500 (69%) |
|
|
| ≥ 10 000 écoutes | ❌ | 8500/10000 (85%) |
|
|
| Fiabilité | ✅ | 100% |
|
|
| Régularité (5 contenus) | ✅ | 100% |
|
|
Quand j'accède à mon profil créateur
|
|
Alors le bouton "Demander la monétisation" est grisé
|
|
Et je vois la progression détaillée de chaque critère
|
|
|
|
Scénario: Vérification automatique SQL lors de la demande
|
|
Étant donné que je clique sur "Demander la monétisation"
|
|
Quand le système vérifie mes critères
|
|
Alors une requête SQL est exécutée:
|
|
```sql
|
|
SELECT
|
|
(created_at <= NOW() - INTERVAL '3 months') AS anciennete_ok,
|
|
(SELECT COUNT(*) FROM subscriptions WHERE creator_id = :creator_id) >= 500 AS abonnes_ok,
|
|
(SELECT SUM(complete_listens) FROM contents WHERE creator_id = :creator_id) >= 10000 AS ecoutes_ok,
|
|
(SELECT COUNT(*) FROM strikes WHERE creator_id = :creator_id AND status = 'active') = 0 AS strikes_ok,
|
|
(SELECT COUNT(*) FROM moderated_contents WHERE creator_id = :creator_id AND moderated_at >= NOW() - INTERVAL '6 months') = 0 AS moderation_ok,
|
|
(SELECT COUNT(*) FROM contents WHERE creator_id = :creator_id AND published_at >= NOW() - INTERVAL '90 days') >= 5 AS regularite_ok
|
|
FROM users WHERE id = :creator_id;
|
|
```
|
|
Et si tous les critères sont TRUE, je suis redirigé vers le KYC
|
|
|
|
Scénario: Notification par email quand critères atteints
|
|
Étant donné que je viens d'atteindre 500 abonnés
|
|
Et que c'était mon dernier critère manquant
|
|
Quand le système détecte l'éligibilité
|
|
Alors je reçois un email:
|
|
"""
|
|
Félicitations ! Vous êtes maintenant éligible à la monétisation.
|
|
Accédez à votre profil pour activer la monétisation et commencer à gagner des revenus.
|
|
"""
|
|
|
|
Scénario: Badge "Éligible monétisation" dans profil
|
|
Étant donné que je remplis tous les critères
|
|
Mais que je n'ai pas encore activé la monétisation
|
|
Quand un utilisateur consulte mon profil
|
|
Alors il voit un badge "Éligible monétisation 💰"
|
|
Et cela renforce ma crédibilité de créateur
|
|
|
|
Scénario: Justification anti-fraude - Délai 3 mois
|
|
Étant donné qu'un compte suspect crée du contenu frauduleux
|
|
Quand le compte est détecté dans les 2 premiers mois
|
|
Alors le compte est banni avant d'atteindre les 3 mois
|
|
Et le créateur n'a jamais été éligible à la monétisation
|
|
Et aucun paiement n'a été effectué
|
|
|
|
Scénario: Justification qualité - 10 000 écoutes
|
|
Étant donné qu'un créateur produit du contenu de mauvaise qualité
|
|
Quand ses contenus ne génèrent que 2 000 écoutes complètes
|
|
Alors il ne peut pas activer la monétisation
|
|
Et seuls les créateurs avec contenu apprécié sont monétisés
|
|
|
|
Scénario: Réduction coût administratif plateforme
|
|
Étant donné que RoadWave a 10 000 créateurs inscrits
|
|
Et que seuls 500 remplissent tous les critères
|
|
Quand le système calcule le coût administratif
|
|
Alors seulement 500 KYC sont à gérer (vs 10 000)
|
|
Et seulement 500 virements mensuels (vs 10 000)
|
|
Et la charge comptable est réduite de 95%
|
|
|
|
Scénario: Statistiques publiques pour transparence
|
|
Quand un utilisateur consulte la page "Devenir créateur"
|
|
Alors il voit les statistiques:
|
|
| métrique | valeur exemple |
|
|
| Nombre créateurs monétisés | 1 247 |
|
|
| Revenus moyens par créateur | 127€/mois |
|
|
| Top créateur (anonymisé) | 2 450€/mois |
|
|
| Critères d'éligibilité à remplir | 5 critères |
|
|
Et cela permet de fixer des attentes réalistes
|
|
|
|
Scénario: Cache Redis pour calcul rapide critères
|
|
Étant donné que je consulte mes critères de monétisation
|
|
Quand le système charge la page
|
|
Alors les compteurs sont récupérés depuis Redis:
|
|
| clé Redis | exemple valeur |
|
|
| creator:[id]:subscribers_count | 347 |
|
|
| creator:[id]:complete_listens_total | 8500 |
|
|
| creator:[id]:recent_contents_count | 7 |
|
|
Et le temps de réponse est <50ms
|
|
|
|
Scénario: Mise à jour temps réel des compteurs
|
|
Étant donné que je viens de publier un nouveau contenu
|
|
Quand un utilisateur écoute ce contenu en entier
|
|
Alors le compteur "complete_listens_total" est incrémenté immédiatement
|
|
Et si je rafraîchis la page critères, je vois la nouvelle valeur
|
|
Et cela encourage les créateurs à continuer de produire
|
|
|
|
Scénario: Historique des tentatives d'activation
|
|
Étant donné que j'ai tenté d'activer la monétisation il y a 2 mois
|
|
Mais que les critères n'étaient pas remplis
|
|
Quand j'accède à mes logs d'activité
|
|
Alors je vois:
|
|
| date | action | résultat | raison |
|
|
| 2025-11-15 | Demande monétisation | Refusée | Seulement 300 abonnés |
|
|
Et cela m'aide à suivre ma progression
|
|
|
|
Scénario: Performance avec 100 000 créateurs
|
|
Étant donné que RoadWave a 100 000 créateurs
|
|
Et que chacun consulte ses critères 1 fois par jour
|
|
Quand le système traite ces requêtes
|
|
Alors la table users est indexée sur created_at
|
|
Et la table subscriptions est indexée sur creator_id
|
|
Et la table contents est indexée sur creator_id et published_at
|
|
Et chaque requête reste <50ms grâce aux index
|
|
|
|
Scénario: Export des critères pour support client
|
|
Étant donné que je contacte le support car je pense être éligible
|
|
Quand l'agent support consulte mon compte
|
|
Alors il voit un export JSON complet:
|
|
```json
|
|
{
|
|
"creator_id": "abc123",
|
|
"monetization_eligible": false,
|
|
"criteria": {
|
|
"account_age_days": 75,
|
|
"account_age_ok": false,
|
|
"subscribers_count": 512,
|
|
"subscribers_ok": true,
|
|
"complete_listens_total": 11234,
|
|
"complete_listens_ok": true,
|
|
"active_strikes": 0,
|
|
"strikes_ok": true,
|
|
"moderated_contents_6m": 1,
|
|
"moderation_ok": false,
|
|
"recent_contents_90d": 8,
|
|
"regularity_ok": true
|
|
},
|
|
"blocking_criteria": ["account_age", "moderation_history"]
|
|
}
|
|
```
|
|
Et l'agent peut expliquer précisément pourquoi je ne suis pas éligible
|
|
|
|
Scénario: Notification 30 jours avant éligibilité probable
|
|
Étant donné que mes critères sont:
|
|
| critère | statut | progression |
|
|
| Ancienneté ≥ 3 mois | ❌ | 60/90 jours |
|
|
| Tous les autres critères | ✅ | 100% |
|
|
Quand il reste exactement 30 jours avant les 90 jours
|
|
Alors je reçois une notification:
|
|
"""
|
|
Plus que 30 jours avant d'être éligible à la monétisation !
|
|
Préparez vos documents KYC (SIRET, RIB, CNI) pour gagner du temps.
|
|
"""
|
|
|
|
Scénario: Pas de bypass possible pour amis/influenceurs
|
|
Étant donné qu'un créateur influent me contacte directement
|
|
Et qu'il demande un bypass des critères
|
|
Quand je consulte la politique RoadWave
|
|
Alors la réponse est "Aucune exception possible, critères automatiques uniquement"
|
|
Et cela garantit l'équité pour tous les créateurs
|
|
|
|
Scénario: A/B test futur sur seuils (post-MVP)
|
|
Étant donné que RoadWave veut tester des seuils différents
|
|
Quand un A/B test est lancé en 2027
|
|
Alors groupe A voit: 500 abonnés, 10 000 écoutes
|
|
Et groupe B voit: 300 abonnés, 5 000 écoutes
|
|
Et les métriques (taux activation, fraude, qualité) sont comparées
|
|
Et le meilleur seuil est déployé définitivement
|