Remplace les diagrammes Mermaid par DBML (via kroki-dbml) pour
une meilleure expressivité des schémas de base de données :
- Ajout support notes, contraintes et indexes détaillés
- Migration de tous les schémas d'entités partagées
- Ajout fichier exemple dbml-example.md
- Configuration plugin mkdocs-kroki pour rendu DBML
Réorganise la structure Docker pour plus de cohérence dans le monorepo.
Chaque module (backend, docs) a maintenant ses propres Dockerfiles et scripts.
Changements:
- backend/docker/ : Dockerfile (prod) + dev.Dockerfile (hot reload) + init script
- docs/docker/ : mkdocs.Dockerfile + pdf.Dockerfile
- docs/scripts/ : generate-bdd-docs.py + generate-pdf-docs.py
- Déplace docker-compose.yml dans backend/
- Supprime scripts obsolètes (fix-markdown-*.sh, remove-broken-links.sh)
- Déplace .dockerignore à la racine
- Met à jour Makefile avec nouveaux chemins
Organisation finale:
- backend/ : tout ce qui concerne l'API backend
- docs/ : tout ce qui concerne la documentation
- scripts/ : uniquement setup.sh (scripts généraux du projet)
- Ajouter ADR-018 (librairies Go) dans TECHNICAL.md
- Transformer Shared en menu dépliable dans mkdocs (cohérence avec autres domaines)
- Corriger listes markdown (ajout lignes vides avant listes)
- Corriger line breaks dans génération BDD (étapes "Et" sur nouvelles lignes)
- Ajouter script fix-markdown-lists.sh pour corrections futures
Impacte 86 fichiers de documentation et 164 fichiers BDD générés.
- Fusionner Architecture Technique et ADR sous section Architecture unique
- Fermer les menus de navigation par défaut (retrait navigation.expand)
- Ajouter features BDD manquantes pour domaine Shared :
* Authentication (13 features)
* Profil (3 features)
* Partage (2 features)
* Error Handling (4 features)
- Corriger indentation tableaux dans génération Markdown BDD
(éviter transformation en blocs de code)
- Corriger diagramme séquence authentification
(API → DB au lieu de App Mobile → DB)
- Supprimer fichiers obsolètes et index manuels
Ajout de 2 fichiers de documentation :
MIGRATION.md :
- Liste complète des changements effectués
- Tableau de correspondance ancien → nouveau
- Métriques de la migration (21% → 100% features accessibles)
- Guide de rollback si nécessaire
- FAQ
CONTRIBUTING.md :
- Principes fondamentaux (source unique, français, generated/ read-only)
- Guide ajout feature BDD (étape par étape)
- Guide ajout règle métier
- Guide ajout entité et diagrammes
- Conventions de nommage
- Checklist avant commit
- Format des messages de commit
- Supprimer les 7 fichiers index.md créés manuellement
- Retirer les références 'Vue d'ensemble' dans mkdocs.yml
- Le dossier generated/ doit contenir uniquement les fichiers générés par le script
- Les features BDD restent accessibles directement dans la navigation
- Mise à jour de tous les liens dans les fichiers .md
- Mise à jour de la navigation dans mkdocs.yml
- Tous les chemins pointent vers les nouveaux noms en français
- 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.
