- Supprimer data-export.md (doublon de export-donnees.md)
- Supprimer account-deletion.md (doublon de suppression-compte.md)
- Mettre à jour mkdocs.yml pour supprimer les doublons
- Garder uniquement les versions françaises plus détaillées
- Déplacer TECHNICAL.md vers docs/ pour cohérence
- Renommer docs/index.md en docs/README.md (convention GitHub)
- Créer docs/adr/README.md comme index des ADR
- Supprimer docs/REFACTOR-DDD.md (plan appliqué)
- Supprimer docs/technical.md (doublon)
- Mettre à jour tous les liens internes
- Mettre à jour mkdocs.yml pour nouvelle structure
Structure finale :
- README.md : vue d'ensemble projet (GitHub)
- docs/README.md : page d'accueil documentation (MkDocs)
- docs/TECHNICAL.md : architecture technique
- docs/adr/README.md : index des 25 ADR
Améliorations:
- Orientation LR (Left-Right) au lieu de TB pour meilleur flux
- Ajout icônes émojis pour identification visuelle rapide
- Simplification des connexions (api --> services au lieu de connexions multiples)
- Labels plus courts dans les boîtes
- Styles améliorés avec bordures colorées
- Meilleure organisation des sous-graphes
Le diagramme est maintenant beaucoup plus lisible et professionnel.
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.
Problème : USERS et CONTENTS dupliqués dans chaque diagramme
= maintenance cauchemardesque lors d'évolutions
Solution : Extraction des entités communes
- modele-global.md : USERS, CONTENTS, SUBSCRIPTIONS, LISTENING_HISTORY
- modele-moderation.md : Uniquement entités spécifiques modération
(REPORTS, SANCTIONS, APPEALS, STRIKES, MODERATORS, BADGES)
Avantages :
- Une seule source de vérité pour entités communes
- Diagrammes de domaine focalisés sur leur périmètre
- Maintenance simplifiée (1 fichier à modifier vs N)
- Lien entre diagrammes pour navigation
Les futurs diagrammes de domaine (recommandation, monétisation, etc.)
référenceront modele-global.md et définiront uniquement leurs
entités spécifiques.
Crée nouvelle section 11.4 détaillant le comportement quand des contenus
sont supprimés par créateurs/modération pendant que l'utilisateur est offline.
Décision : Suppression immédiate à la reconnexion (KISS)
Processus de synchronisation :
- GET /offline/validate retourne valid_ids, deleted_ids, metadata_updates
- Suppression immédiate fichiers locaux pour deleted_ids
- Renouvellement validité 30j pour valid_ids
- Toast notification "X contenus supprimés ont été retirés"
Gestion contenu en cours d'écoute :
- Message modal explicite "Contenu supprimé... Passage au suivant"
- Arrêt lecture + suppression fichier + passage auto après 2s
Message récapitulatif :
- Popup avec compte total + bouton "Voir la liste"
- Historique contenus supprimés conservé 7 jours
Justification KISS :
- Simplicité technique (pas de grace period)
- Respect créateur (volonté immédiate)
- Conformité légale (contenu illégal retiré immédiatement)
- Cas rare (peu de suppressions après publication)
Post-MVP : grace period possible si feedback négatifs, mais attendre
feedback réel avant complexité additionnelle.
Référence: CLARIFICATIONS-REGLES-METIER.md section 6
Restructure section 9.5 pour détailler la gestion des soldes créateurs :
Conservation du solde :
- Indéfiniment si créateur actif (>0 écoute/mois OU connexion dashboard)
- Emails préventifs à 12 mois, 18 mois et 18 mois + 30j d'inactivité
- Versement forcé après 18 mois d'inactivité (vs forfeiture chez Twitch)
- Exception soldes <10€ avec proposition de don
- Transparence frais bancaires (1.8% + 0.18€ Mangopay)
Déclaration fiscale DAS2 :
- Systématique pour tous montants (même <1200€/an)
- Conformité maximale et protection juridique plateforme
- Justificatif fourni aux créateurs en janvier N+1
Inspiré de Twitch mais plus équitable (versement au lieu de perte).
Référence: CLARIFICATIONS-REGLES-METIER.md section 3
Ajoute une nouvelle section 16.3.4 décrivant le comportement du bouton
"Suivant" en mode voiture avec système intelligent à double clic :
- Premier clic : désactive GPS auto, passe en mode manuel, séquence suivante
- Deuxième clic (<10s) : sort de l'audio-guide et met en pause
- Clics suivants (>10s) : navigation normale entre séquences
Ajoute également :
- Détection et gestion du hors itinéraire (>1km, >10min)
- Proposition de reprise au retour sur itinéraire (<100m)
- Respect des séquences skippées volontairement
Résout le problème des embouteillages où l'utilisateur reste
30 minutes sans contenu en attendant le prochain point GPS.
Référence: CLARIFICATIONS-REGLES-METIER.md section 2
Ajoute une documentation explicite du cas où un contenu géo-ancré
a un excellent score géographique mais des jauges d'intérêt nulles.
Ce comportement est accepté pour MVP car :
- Le quota 6 contenus géolocalisés/h protège du spam
- L'information peut être utile contextuellement
- La distinction info/divertissement est reportée post-MVP
Référence: CLARIFICATIONS-REGLES-METIER.md section 1
Création de 3 features Gherkin pour les tests backend des jauges d'intérêt:
- evolution-jauges.feature: Tests API pour calculs de jauges (likes auto/manuels,
abonnements créateurs, skips), persistence PostgreSQL, bornes 0-100%, cache Redis
- jauge-initiale.feature: Tests API pour initialisation à 50% lors inscription,
questionnaire optionnel post-MVP, recommandations cold start
- degradation-temporelle.feature: Tests API confirmant absence de dégradation
automatique, réinitialisation manuelle avec snapshot et audit log
Complète les features UI existantes avec les aspects techniques backend.
Ajout de 5 nouveaux scénarios pour couvrir les cas non testés :
- Désabonnement créateur (-5% sur tous ses tags)
- Skip à 30% avec like auto standard déjà appliqué
- Skip tardif entre 30% et 79% (neutre après like auto)
- Désabonnement avec borne minimale (ne descend pas sous 0%)
- Écoute entre 10s et 30% (ni pénalité ni bonus)
Ces scénarios complètent les règles métier 03 (centres d'intérêt et jauges)
et clarifient les comportements limites du système de recommandation.
Améliore les Gherkins de modération API avec détails des règles métier :
- Ajout référence Section 18 pour droits d'auteur (signalement)
- Enrichissement timestamps passages problématiques avec durées et scores (traitement)
- Amélioration template email sanctions avec sections structurées (notifications)
- Détails précis modal découverte badges au 1er signalement (communautaire)
Alignement 100% avec sections 14 et 15 des règles métier.
Remplace toutes les références au SDK Firebase par une implémentation
directe des APIs APNS (iOS) et FCM (Android) pour éliminer le vendor
lock-in et assurer la cohérence avec la stratégie self-hosted.
Modifications :
- ADR-017 : Architecture notifications avec APNS/FCM direct
- ADR-018 : Remplacement firebase.google.com/go par sideshow/apns2 + oauth2
- ADR-020 : Remplacement firebase_messaging par flutter_apns + flutter_fcm
- Règles métier 09 & 14 : Mise à jour références coûts notifications
Avantages :
- Aucun vendor lock-in (code 100% maîtrisé)
- Cohérence avec ADR-008 (self-hosted) et ADR-015 (souveraineté)
- Gratuit sans limite (APNS/FCM natifs)
- APIs standard HTTP/2 et OAuth2
Ajoute moderation-communautaire.feature couvrant la Règle 15/19 :
- Système de badges (Bronze/Argent/Or)
- Score de fiabilité et priorisation
- Modal découverte au 1er signalement
- Réduction Premium -50% pour badge Or
- Limites anti-abus (10 signalements/24h)
- Audit trimestriel automatique
- Sanctions graduées (mineur/modéré/grave)
Les 4 autres fichiers de modération existants (signalement,
traitement, sanctions, préventive) sont déjà conformes à l'ADR-023
et à la Règle 14.
- Corriger règle 1.4 : appliquer logique standard de classification par âge
(13-15 ans: Tout public + 13+, 16-17 ans: + 16+, 18+: tous)
- Mettre à jour classification-age.feature avec nouvelles règles de diffusion
- Mettre à jour inscription.feature pour cohérence avec classification
- Ajouter gestion-compte.feature avec 28 scénarios (déconnexion, changement
mot de passe, changement email, changement pseudo, consultation compte)
Ajout d'une section règles importantes pour spécifier de ne jamais
ajouter "Co-Authored-By: Claude" dans les messages de commit.
Les commits doivent rester propres et professionnels sans attribution IA.
Remplacement de tous les canaux Slack/Discord par Telegram Bot :
- Table stack technique : Webhook Slack/Discord → Telegram Bot
- Diagramme Mermaid : mise à jour nodes et connexions
- Alternatives considérées : ligne tableau mise à jour
- Conséquences : mentions Slack/Discord → Telegram
- Alerting rules : Slack + Email → Telegram + Email
Justification :
- Coût : 0€ (identique)
- Disponibilité : temps réel (identique)
- Intrusivité : moyenne (identique)
- Avantage : API Telegram plus simple et plus flexible
INCONSISTENCIES.md mis à jour en conséquence.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Suppression de tous les exemples de code pour garder uniquement
les descriptions techniques :
- Workflows backend/mobile/shared : descriptions textuelles
au lieu de blocs YAML complets
- Section validation : scénarios décrits au lieu de commandes bash
- Conservation de toute l'information technique sans code concret
ADR reste technique et complet mais plus concis.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Correction référence Règle Métier 05 :
- Avant : "Section 5.2 (Mode Voiture, lignes 16-84)"
- Après : "Section 5.1 (File d'attente et commande Suivant)"
Raison : La Règle 05 ne contient pas de Section 5.2.
La structure réelle est Section 5.1 pour la file d'attente.
Résout dernière incohérence P0 (INCONSISTENCIES.md item 5).
100% des incohérences P0 maintenant corrigées !
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
