veza/VEZA_VERSIONS_ROADMAP.md
senke d6b614cc42 docs: update VEZA_VERSIONS_ROADMAP [v0.12.6 DONE]
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-11 14:31:54 +01:00

1316 lines
50 KiB
Markdown

# VEZA_VERSIONS_ROADMAP.md
> **Système de versionnage Veza — v1.0 de ce document**
>
> Ce fichier est la source de vérité unique pour le déroulé des versions de développement.
> Il est conçu pour être utilisé avec Cursor : donner simplement "implémente la prochaine version"
> suffit pour déclencher une session de travail complète et ciblée.
>
> **Convention** : Chaque version est atomique, testable, et mergeable indépendamment.
> Une version = un incrément de valeur livrable. Pas de version ouverte en parallèle.
>
> **Référence** : Tous les détails techniques et éthiques sont dans les fichiers ORIGIN/.
> Ce fichier orchestre — les ORIGIN spécifient.
>
> **Dernière mise à jour** : 2026-03-09
> **Auteur** : Architecte principal Veza
---
## 📋 ÉTAT GLOBAL
| Phase | Versions | Statut | Objectif |
|-------|----------|--------|----------|
| **P3.5 — Consolidation & Sécurité** | v0.9.1 → v0.9.9 | 🔴 EN COURS | Stabiliser, sécuriser, dettes techniques |
| **P4R — Social & Live** | v0.10.0 → v0.10.9 | ⏳ À VENIR | Chat complet, feed social, livestream |
| **P5R — Analytics & Recherche** | v0.11.0 → v0.11.9 | ⏳ À VENIR | Analytics créateur, recherche éthique |
| **P6R — Premium & Infrastructure** | v0.12.0 → v0.12.9 | ⏳ À VENIR | Plans premium, distribution, perf |
| **v1.0 — Release Stable** | v1.0.0 | ⏳ À VENIR | GO/NO-GO criteria atteints |
---
## 🔴 PHASE P3.5 — CONSOLIDATION & SÉCURITÉ
> Objectif : avant de construire de nouvelles features, rendre le système fiable, sécurisé, et maintenable.
> Aucune feature P4R ne commence avant que P3.5 soit complète.
---
### v0.9.1 — Vulnérabilités Critiques JWT (TASK-SEC-001 + TASK-SEC-002)
**Statut** : ✅ DONE
**Priorité** : P0 — BLOQUANT
**Durée estimée** : 2-3 jours
**Prerequisite** : Aucun
**Complété le** : 2026-03-05
**Objectif**
Corriger les deux vulnérabilités de sécurité critiques identifiées dans l'audit (VEZA-SEC-001 et VEZA-SEC-002). Sans ces correctifs, aucune autre feature ne peut être déployée en production.
**Tâches**
- [x] **TASK-SEC-001** : Migration JWT HS256 → RS256
- Générer paire de clés RSA 2048-bit (clé privée backend, clé publique publique)
- Modifier le service JWT pour signer avec RS256
- Mettre à jour tous les middleware de validation JWT
- Mettre à jour les variables d'environnement (supprimer `JWT_SECRET`, ajouter `JWT_PRIVATE_KEY_PATH`, `JWT_PUBLIC_KEY_PATH`)
- Invalider tous les tokens existants (migration token_version)
- Référence : ORIGIN_SECURITY_FRAMEWORK.md §0 VEZA-SEC-001, ORIGIN_DEPLOYMENT_GUIDE.md §15
- [x] **TASK-SEC-002** : Supprimer les clés privées committées / secrets exposés
- Audit complet de l'historique git (truffleHog ou équivalent)
- Rotation immédiate de toutes les clés compromises (Stripe, OAuth, JWT, DB)
- Mettre en place `.gitignore` complet pour tous les fichiers `.env`
- Créer `.env.example` documenté avec toutes les variables requises
- Référence : ORIGIN_SECURITY_FRAMEWORK.md §0 VEZA-SEC-002
**Critères d'acceptation**
- [x] Tous les JWT générés utilisent RS256 (ou HS256 fallback dev) et sont vérifiés avec la clé publique / secret
- [x] Aucun secret hardcodé par défaut (veza-common corrigé, procédure audit docs/SECRETS_AUDIT.md)
- [x] `.env.example` et docs/ENV_VARIABLES.md couvrent les variables requises
- [x] Tests d'authentification passent (unit + handler)
- [ ] Déploiement staging valide avec les nouvelles clés (à valider manuellement)
**Fichiers principaux à modifier**
- `backend/internal/auth/jwt_service.go`
- `backend/internal/middleware/auth_middleware.go`
- `.env.example`
- `backend/configs/`
- `docker-compose.yml` (variables d'env)
---
### v0.9.2 — Sécurité Infrastructure (TASK-SEC-003 à 006)
**Statut** : ✅ DONE
**Priorité** : P0 — BLOQUANT
**Durée estimée** : 1-2 jours
**Prerequisite** : v0.9.1 complète
**Complété le** : 2026-03-05
**Objectif**
Fermer les vecteurs d'attaque infrastructure : endpoint `/metrics` exposé, rate limiting manquant, headers de sécurité absents.
**Tâches**
- [x] **TASK-SEC-003** : Rate limiting global
- Implémenter rate limiting middleware sur toutes les routes publiques
- Règles : 100 req/h par IP (non-auth), 1000 req/h (auth)
- Redis comme backend pour le comptage distribué
- Référence : ORIGIN_SECURITY_FRAMEWORK.md, ORIGIN_FEATURES_REGISTRY.md F026
- [x] **TASK-SEC-004** : Security headers HTTP
- `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options`
- `Strict-Transport-Security` (HSTS)
- `Referrer-Policy`
- Middleware centralisé dans HAProxy ou au niveau Go
- [x] **TASK-SEC-005** : Validation et sanitization des inputs
- Audit de tous les endpoints existants (pas de SQL injection, XSS)
- Binding validation exhaustif sur tous les handlers
- Taille max des payloads (1MB par défaut, 500MB pour upload audio)
- [x] **TASK-SEC-006** : Protection endpoint `/metrics`
- Route Prometheus `/metrics` accessible seulement depuis réseau interne
- Authentification bearer token ou IP whitelist
- Référence : ORIGIN_SECURITY_FRAMEWORK.md §0, ORIGIN_IMPLEMENTATION_TASKS.md TASK-SEC-006
**Critères d'acceptation**
- [x] `curl http://api.veza.app/metrics` depuis internet → 403
- [x] 101ème requête depuis une IP non-auth → 429 Too Many Requests
- [x] Headers de sécurité visibles dans les réponses (vérifiable avec `curl -I`)
- [ ] Tests de pénétration basiques (OWASP Top 10) passent sans résultat critique (à valider manuellement)
---
### v0.9.3 — Toolchain et Environnement (TASK-QA-006 à 010)
**Statut** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 1 jour
**Prerequisite** : v0.9.1 complète
**Complété le** : 2026-03-05
**Objectif**
Standardiser l'environnement de développement pour que tous les développeurs (et Cursor) travaillent dans des conditions identiques et reproductibles.
**Tâches**
- [x] **TASK-QA-006** : Créer `.nvmrc` à la racine du monorepo
- Version Node.js fixée (LTS actuel)
- Référence : ORIGIN_QUALITY_METRICS.md §6.4 DT-007
- [x] **TASK-QA-007** : Créer `rust-toolchain.toml` pour le stream server
- Version Rust stable fixée (existe à la racine)
- Référence : ORIGIN_QUALITY_METRICS.md §6.4 DT-008
- [x] **TASK-QA-008** : Compléter `Makefile` racine
- Alias `build` (→ build-all), cible `doctor` vérifiant dépendances
- Référence : make/build.mk, make/tools.mk
- [x] **TASK-QA-009** : Documenter variables d'environnement + script de validation
- `docs/ENV_VARIABLES.md` avec description, type, valeur par défaut, exemples
- `scripts/validate-env.sh` (appelé par `make doctor`)
- [x] **TASK-QA-010** : `docker-compose.dev.yml` fonctionnel
- Infra : Postgres, Redis, RabbitMQ, ClamAV, MinIO
- `make dev-full`, `make dev-backend-api`, `make dev-stream-server` utilisent `infra-up-dev`
- Hot reload pour apps locales (air, cargo-watch)
**Critères d'acceptation**
- [x] `make dev` démarre backend (Docker) + web local
- [x] `make doctor` vérifie dépendances et affiche rapport
- [x] Un développeur peut démarrer l'environnement avec les instructions du README
- [x] README racine à jour avec instructions setup
---
### v0.9.4 — Quality Gates CI/CD (TASK-QA-001 à 005)
**Statut** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 2 jours
**Prerequisite** : v0.9.3 complète
**Complété le** : 2026-03-05
**Objectif**
Mettre en place les quality gates automatisées pour que chaque PR soit validée avant merge. Zéro régression non détectée.
**Tâches**
- [x] **TASK-QA-001** : Pipeline CI GitHub Actions
- Stages : lint (golangci-lint, ESLint, clippy), tests, build
- Référence : ORIGIN_QUALITY_METRICS.md §7.1bis
- [x] **TASK-QA-002** : Coverage gates
- Go backend : coverage ≥ 60% (gate dans ci.yml)
- Frontend React : coverage ≥ 50% (vitest --coverage enforces thresholds)
- PR rejetée automatiquement si coverage descend
- [x] **TASK-QA-003** : Linting strict
- `veza-backend-api/.golangci.yml` (govet, gofmt, goimports)
- `veza-backend-api/package.json` lint → golangci-lint
- `veza-stream-server/package.json` lint → cargo fmt + clippy
- Aucun warning accepté en CI
- [x] **TASK-QA-004** : Tests d'intégration de santé
- E2E job : validation payload `/api/v1/health` (jq .status == "ok")
- Postgres, Redis, migrations, backend startup vérifiés
- [x] **TASK-QA-005** : Notifications de CI
- Badge CI dans README
- Job notify-failure : Slack webhook si SLACK_WEBHOOK_URL défini
**Critères d'acceptation**
- [x] Chaque push sur une branche déclenche le pipeline
- [x] Pipeline complet (sous 10 min si ressources OK)
- [x] Une PR avec tests échoués ne peut pas être mergée
- [x] Coverage visible (Go dans step output, frontend via vitest thresholds)
---
### v0.9.5 — Suppression Code Mort (TASK-DEBT-001 à 005)
**Statut** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 1-2 jours
**Prerequisite** : v0.9.4 complète (les tests protègent contre les régressions)
**Complété le** : 2026-03-05
**Objectif**
Supprimer tout le code mort identifié dans l'audit. Réduire la surface de maintenance et éliminer la confusion architecturale.
**Tâches**
- [x] **TASK-DEBT-001** : Supprimer le répertoire `soundcloud/` (ou équivalent SoundCloud import)
- Confirmer qu'aucun code en production ne l'importe
- Supprimer et nettoyer les imports
- [x] **TASK-DEBT-002** : Supprimer `webrtc.rs` du stream server (si non utilisé)
- Le stream server Rust ne fait pas de WebRTC (voir ADR-002)
- Confirmer dans le code, supprimer si orphelin
- [x] **TASK-DEBT-003** : Supprimer `k8s/chat-server/` (Kubernetes manifests pour le chat Rust obsolète)
- Le chat server est maintenant en Go (ADR-002)
- Référence : ORIGIN_IMPLEMENTATION_TASKS_ARCHIVE.md note T0051-T0065
- [x] **TASK-DEBT-004** : Supprimer ou désactiver tous les endpoints AI/Web3/Gamification
- Rechercher dans le codebase : routes AI, NFT, XP, leaderboard, gamification
- Supprimer le code correspondant
- Référence : ORIGIN_REVISION_SUMMARY.md §1, ORIGIN_FEATURES_REGISTRY.md §29
- [x] **TASK-DEBT-005** : Nettoyer les dépendances inutilisées
- `go mod tidy` et vérification des modules Go
- `npm audit` et suppression des packages inutilisés
- `cargo update` et nettoyage des crates Rust
**Critères d'acceptation**
- [x] `grep -r "soundcloud\|nft\|blockchain\|xp_system\|leaderboard" --include="*.go" --include="*.ts" --include="*.rs"` → aucun résultat dans le code actif
- [x] Taille du bundle frontend réduite (suppression types/types gamification)
- [ ] Tous les tests passent après nettoyage (à valider)
---
### v0.9.6 — Chat Complet : Réactions & Mentions (TASK-CHAT-001 à 003)
**Statut** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.9.2 complète
**Complété le** : 2026-03-06
**Objectif**
Compléter le module Chat (Go) avec les features manquantes : réactions aux messages, mentions @utilisateur, et search dans l'historique.
**Tâches**
- [x] **TASK-CHAT-001** : Réactions aux messages (émojis)
- Backend : endpoint POST/DELETE `/api/v1/chat/messages/{id}/reactions`
- Table `message_reactions` (message_id, user_id, emoji, created_at)
- WebSocket : event `message:reaction_added` / `message:reaction_removed`
- Frontend : picker émoji inline, compteur de réactions
- Référence : ORIGIN_FEATURES_REGISTRY.md F162
- [x] **TASK-CHAT-002** : Mentions @utilisateur
- Backend : parsing des `@username` dans les messages
- Notification push pour les utilisateurs mentionnés
- Frontend : autocomplete @username en cours de frappe
- Référence : ORIGIN_FEATURES_REGISTRY.md F163
- [x] **TASK-CHAT-003** : Recherche dans l'historique des messages
- Backend : endpoint GET `/api/v1/chat/rooms/{id}/messages/search?q=...`
- Elasticsearch ou fulltext PostgreSQL (pg_trgm)
- Frontend : barre de recherche dans le panel chat
- Référence : ORIGIN_FEATURES_REGISTRY.md F165
**Critères d'acceptation**
- [x] Un utilisateur peut réagir à un message avec un émoji, la réaction apparaît en temps réel chez tous les participants
- [x] `@alice` dans un message déclenche une notification pour alice
- [x] La recherche retourne des résultats pertinents en moins de 200ms
- [x] Aucune régression sur les features chat existantes
---
### v0.9.7 — Chat Complet : Fichiers & Threads (TASK-CHAT-004 à 006)
**Statut** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.9.6 complète
**Complété le** : 2026-03-06
**Objectif**
Compléter le module Chat avec l'envoi de fichiers, les threads (réponse à un message), et la gestion des rooms de groupe.
**Tâches**
- [x] **TASK-CHAT-004** : Envoi de fichiers dans le chat
- Backend : endpoint POST `/api/v1/chat/messages/{id}/attachments`
- Types acceptés : audio (mp3, wav, ogg), image (jpg, png), PDF
- Upload S3, URL signée temporaire (24h)
- Taille max : 50MB par fichier
- Référence : ORIGIN_FEATURES_REGISTRY.md F166
- [x] **TASK-CHAT-005** : Threads (réponse à un message)
- Backend : champ `reply_to_message_id` dans la table messages
- Frontend : UI thread avec message parent visible
- Référence : ORIGIN_FEATURES_REGISTRY.md F161
- [x] **TASK-CHAT-006** : Rooms de groupe (invitations, gestion des membres)
- Backend : endpoints CRUD pour la gestion des membres d'une room
- Invitations avec lien unique (expire en 7 jours)
- Rôles dans le groupe : owner, admin, member
- Référence : ORIGIN_FEATURES_REGISTRY.md F155-F160
**Critères d'acceptation**
- [x] Partage d'un fichier audio dans le chat → lecture inline possible
- [x] Thread visible avec message parent
- [x] Invitation par lien fonctionne (flow complet)
- [x] Owner peut kick un membre
---
### v0.9.8 — Réduction Dette Technique Backend (TASK-DEBT-006 à 012)
**Statut** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.9.4 complète
**Complété le** : 2026-03-06
**Objectif**
Corriger les patterns d'erreur identifiés dans l'audit technique (PAT-024 à PAT-028) : propagation de contexte, goroutine leaks, pagination incohérente, error handling non standardisé.
**Tâches**
- [x] **TASK-DEBT-006** : Standardisation error handling Go
- Tous les handlers retournent des erreurs au format `{"error": {"code": "...", "message": "...", "context": {...}}}`
- Créer package `pkg/apierror` avec types d'erreurs standardisés
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-028, ORIGIN_ERROR_PREVENTION_GUIDE.md §2.6
- [x] **TASK-DEBT-007** : Context propagation dans tous les services Go
- Audit : chaque fonction qui fait I/O doit accepter `context.Context` comme premier paramètre
- Deadline et cancellation propagés correctement
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-025
- [x] **TASK-DEBT-008** : Goroutine lifecycle management
- Audit : chaque goroutine a un mécanisme de terminaison propre
- `WaitGroup` ou channels de done utilisés correctement
- Tests de détection de goroutine leaks (goleak)
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-026
- [x] **TASK-DEBT-009** : Pagination cohérente sur tous les endpoints de liste
- Standard : `?page=1&limit=20` sur tous les endpoints de collection
- Response format : `{"data": [...], "pagination": {"page": 1, "limit": 20, "total": 150, "total_pages": 8}}`
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-027, ORIGIN_CODE_STANDARDS.md §3.7
- [x] **TASK-DEBT-010** : JWT mismatch resolution
- Audit de toutes les validations JWT : uniformiser les claims attendus
- Référence : ORIGIN_ERROR_PATTERNS.md PAT-024
- [x] **TASK-DEBT-011** : Logging structuré uniforme
- Tous les logs au format JSON avec champs : `level`, `time`, `msg`, `request_id`, `user_id` (si applicable)
- Niveaux : DEBUG (dev uniquement), INFO (prod), WARN, ERROR
- [x] **TASK-DEBT-012** : Documentation ADR systématique
- Créer `docs/adr/` avec les ADR existants formalisés (ADR-001 à ADR-012)
- Référence : ORIGIN_REVISION_SUMMARY.md §3
**Critères d'acceptation**
- [x] Tous les endpoints de liste ont une pagination cohérente
- [x] `goleak` ne détecte pas de goroutine leaks dans les tests
- [x] Toutes les erreurs API suivent le format standardisé ( RespondWithAppError migré sur handlers principaux)
- [ ] Couverture de tests ≥ 70% sur le package `pkg/apierror` (à valider)
---
### v0.9.9 — Réduction Dette Technique Frontend (TASK-DEBT-013 à 017)
**Statut** : ✅ DONE
**Priorité** : P1
**Durée estimée** : 2-3 jours
**Prerequisite** : v0.9.4 complète
**Complété le** : 2026-03-08
**Objectif**
Nettoyer la dette technique frontend : types TypeScript incomplets, composants non accessibles, bundle non optimisé.
**Tâches**
- [x] **TASK-DEBT-013** : TypeScript strict mode complet
- Activer `"strict": true` dans `tsconfig.json`
- Corriger tous les types `any` et `unknown` non justifiés
- Référence : ORIGIN_QUALITY_METRICS.md §6.4 DT-013
- [x] **TASK-DEBT-014** : Accessibilité WCAG AA (audit et corrections)
- Audit avec axe-core ou Lighthouse
- ARIA labels sur tous les composants interactifs
- Keyboard navigation fonctionnelle (Tab, Enter, Escape)
- Référence : ORIGIN_UI_UX_SYSTEM.md §14, ORIGIN_FEATURE_VALIDATION_STRATEGY.md §7
- [x] **TASK-DEBT-015** : Optimisation bundle (code splitting)
- Lazy loading des routes React (React.lazy + Suspense)
- Bundle initial < 200KB gzipped
- Référence : ORIGIN_PERFORMANCE_TARGETS.md
- [x] **TASK-DEBT-016** : Storybook ou équivalent pour les composants UI
- Documentation des composants du design system SUMI
- Stories pour les états : default, loading, error, empty
- Référence : ORIGIN_UI_UX_SYSTEM.md
- [x] **TASK-DEBT-017** : Tests de régression visuels (optionnel)
- Playwright ou Chromatic pour screenshots de référence
- Référence : ORIGIN_TESTING_STRATEGY.md §13
**Critères d'acceptation**
- [x] `npm run build` sans erreurs TypeScript
- [x] Script `npm run a11y:audit` (axe-core CLI) et ARIA labels sur ChatInput, Sidebar
- [x] Bundle initial < 200KB gzipped (scripts/check-bundle-size.mjs, gate CI)
- [x] Stories Loading/Error/Empty pour LibraryPage, SearchPage, ChatPage ; validation visuelle opérationnelle
---
## 🟡 PHASE P4R — SOCIAL & LIVE
> Prerequisite : **Toutes les versions P3.5 (v0.9.x) sont complètes et validées.**
> La phase P4R est déclenche uniquement après GO/NO-GO sur P3.5 (voir critères en fin de document).
---
### v0.10.0 — Feed Social Chronologique (F186-F200)
**Statut** : DONE (2026-03-08)
**Priorité** : P1
**Durée estimée** : 4-5 jours
**Prerequisite** : v0.9.9 complète
**Objectif**
Implémenter le système de follow/unfollow et le feed chronologique. Le feed est basé sur les follows de l'utilisateur, sans algorithme de rétention.
**Tâches**
- [x] Follow / Unfollow un utilisateur (F186)
- Backend : POST/DELETE `/api/v1/users/{id}/follow`
- Table `follows` (follower_id, following_id, created_at)
- Index pour requêtes rapides dans les deux sens
- [x] Compteurs followers/following sur les profils (F187)
- Dénormalisé dans `user_profiles.follower_count` et `user_profiles.following_count`
- Mis à jour via triggers DB (125_follow_counts_triggers.sql)
- [x] Feed chronologique des artistes suivis (F210)
- Backend : GET `/api/v1/feed?cursor=...&limit=20`
- Pagination par curseur (pas par offset)
- Contenu : nouveaux tracks uploadés par les comptes suivis
- Ordre : chronologique strict (pas d'algorithme de boost)
- Référence : ORIGIN_FEATURES_REGISTRY.md F210, ORIGIN_MASTER_ARCHITECTURE.md §4
- [x] Suggestions de comptes à suivre (F211)
- Basé sur : connexions sociales (amis d'amis), GET /api/v1/users/suggestions
- Pas de collaborative filtering ML
- Référence : ORIGIN_FEATURES_REGISTRY.md §30 (Algorithme de découverte éthique)
- [x] Notifications de nouveaux followers (déjà implémenté dans ProfileHandler.FollowUser)
**Critères d'acceptation**
- [ ] Follow/unfollow en moins de 100ms
- [ ] Feed se charge en moins de 200ms pour 20 items
- [ ] Feed est strictement chronologique (vérifiable)
- [ ] Pagination par curseur fonctionne correctement (pas de doublons)
- [ ] Aucune donnée de comportement utilisateur utilisée pour le ranking
---
### v0.10.1 — Découverte Éthique : Tags & Genres (F351-F360)
**Statut** : DONE (2026-03-08)
**Priorité** : P1
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.10.0 complète
**Objectif**
Implémenter le système de tags déclaratifs et la découverte par genres. C'est le cœur de l'algorithme de découverte éthique.
**Tâches**
- [x] Système de tags déclaratifs sur les tracks (F351)
- Tags créés par l'artiste lui-même
- Validation : max 10 tags par track, longueur max 30 chars
- Table `track_tags`, table `tags` (avec compteur d'utilisation)
- [x] Genres musicaux normalisés (F352)
- Taxonomy fixe (liste fermée, extensible via PR)
- Multi-genre supporté (max 3 genres par track)
- [x] Browse par genre / tag (F353)
- GET `/api/v1/discover/genre/{genre}?sort=recent&cursor=...`
- GET `/api/v1/discover/tag/{tag}?cursor=...`
- Tri : chronologique uniquement (pas de popularité)
- [x] Suivre un genre ou un tag (F354)
- L'utilisateur peut "suivre" des genres/tags
- Le feed inclut les nouvelles sorties dans les genres/tags suivis
- [x] Nouveautés dans les genres suivis (F355)
- Section dédiée dans le feed : "Nouvelles sorties dans vos genres"
- Référence : ORIGIN_FEATURES_REGISTRY.md §30
**Critères d'acceptation**
- [x] Un artiste peut taguer son track avec des tags libres (max 10)
- [x] Un utilisateur peut suivre le genre "jazz" et voir les nouveautés jazz dans son feed
- [x] Browse par genre retourne des tracks triées par date (plus récent en premier)
- [ ] Test de biais : les artistes émergents apparaissent autant que les artistes établis dans les résultats de découverte
---
### v0.10.2 — Recherche Fulltext Elasticsearch (F361-F370)
**Statut** : DONE (2026-03-09)
**Priorité** : P1
**Durée estimée** : 4-5 jours
**Prerequisite** : v0.10.1 complète
**Objectif**
Implémenter la recherche fulltext avec Elasticsearch. Recherche de tracks, artistes, et playlists par mots-clés.
**Tâches**
- [x] Index Elasticsearch pour les tracks (F361)
- Champs indexés : title, artist, tags, genre, description
- Mapping avec analyzer français/anglais
- Synchronisation depuis PostgreSQL (via CDC ou job périodique)
- Référence : ORIGIN_MASTER_ARCHITECTURE.md ADR-012, ORIGIN_TECHNICAL_STACK.md §17
- [x] Index Elasticsearch pour les utilisateurs (F362)
- Champs : username, display_name, bio, genres, location
- [x] Endpoint de recherche unifiée (F363)
- GET `/api/v1/search?q=...&type=tracks,users,playlists&cursor=...`
- Résultats groupés par type
- Highlighting des termes trouvés
- [x] Recherche phonétique (French + English) (F364)
- Tolérance aux fautes de frappe
- Recherche par sonorité (pour les noms d'artistes)
- [x] Suggestions autocomplete (F365)
- GET `/api/v1/search/suggestions?q=...`
- Retourne top 5 suggestions instantanées
- Référence : ORIGIN_TECHNICAL_STACK.md §17
**Critères d'acceptation**
- [x] Recherche "acid jazz" retourne des tracks taggées avec les deux termes séparément
- [x] Résultats en moins de 200ms
- [x] Faute de frappe "jaz" retourne quand même des résultats jazz (fuzziness AUTO)
- [x] Pas de résultats basés sur des métriques d'engagement (pas de boost popularity)
- [ ] Test : recherche d'un artiste avec 0 plays retourne les mêmes résultats de pertinence qu'un artiste populaire pour la même requête (à valider manuellement)
---
### v0.10.3 — Commentaires & Interactions Sociales (F201-F215)
**Statut** : DONE (2026-03-09)
**Priorité** : P2
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.10.0 complète
**Objectif**
Implémenter les commentaires sur les tracks et les likes, sans métriques de popularité visibles publiquement.
**Tâches**
- [x] Commentaires sur les tracks (F201)
- POST `/api/v1/tracks/{id}/comments`
- Commentaires avec timestamp (position dans la piste)
- Modération : filtrage par liste de mots-clés (pas de ML)
- [x] Likes / Unlikes sur les tracks (F202)
- POST/DELETE `/api/v1/tracks/{id}/like`
- Compteur visible uniquement par le créateur dans ses analytics (pas publiquement)
- Référence : ORIGIN_REVISION_SUMMARY.md §2 (anti social validation loop)
- [x] Reposts (partage d'une track dans son profil) (F203)
- [x] Notifications pour les interactions (F204)
- Notification pour le créateur quand quelqu'un commente
- Pas de notification "votre track a atteint X likes" (anti gamification)
**Critères d'acceptation**
- [x] Les likes ne sont pas visibles publiquement (confirmé dans le design)
- [x] Le créateur voit ses stats dans sa section Analytics (privée)
- [x] Commentaire avec timestamp cliquable pour aller à ce moment dans la track
---
### v0.10.4 — Playlists Collaboratives (F136-F150)
**Statut** : DONE
**Priorité** : P2
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.10.0 complète
**Complété le** : 2026-03-09
**Objectif**
Améliorer le système de playlists avec les fonctionnalités collaboratives et la curation manuelle.
**Tâches**
- [x] Playlists collaboratives (plusieurs contributeurs) (F140)
- [x] Playlists curatoriales éditoriales (rôle admin/modérateur) (F141)
- Base de la découverte éthique : playlists créées par humains
- Référence : ORIGIN_FEATURES_REGISTRY.md §30
- [x] Partage de playlists (lien public, embed) (F143)
- [x] Import/export de playlists (M3U, JSON) (F145)
- [x] Playlist "Favoris" automatique par utilisateur (F136)
**Critères d'acceptation**
- [x] Deux utilisateurs peuvent éditer la même playlist simultanément (sans conflit)
- [x] Playlist éditoriale visible dans la section Découverte
- [x] Export M3U fonctionnel
---
### v0.10.5 — Notifications Complètes (F551-F570)
**Statut** : DONE
**Priorité** : P2
**Durée estimée** : 2-3 jours
**Prerequisite** : v0.10.3 complète
**Complété le** : 2026-03-10
**Objectif**
Implémenter le système de notifications complet, respectueux du temps de l'utilisateur, sans FOMO.
**Tâches**
- [x] Notifications in-app en temps réel (WebSocket) (F551)
- [x] Digest hebdomadaire email (opt-in) (F552)
- Nouvelles sorties des artistes suivis (ORIGIN §8.1)
- Pas de recommandations comportementales
- Référence : ORIGIN_BUSINESS_LOGIC.md §8.1
- [x] Préférences de notifications granulaires (F553)
- Contrôle par type (follow, commentaire, message, etc.)
- Quiet hours configurables
- Toggle « désactiver marketing » (likes + commentaires en un clic)
- [x] Groupement de notifications (F554)
- "3 personnes ont commenté votre track" (pas 3 notifications séparées)
- [x] Centre de notifications (page dédiée) (F555)
**Critères d'acceptation**
- [x] Aucune notification "vous avez atteint X likes" (anti gamification)
- [x] Par défaut : notifications push désactivées sauf messages directs et follows
- [x] L'utilisateur peut désactiver toutes les notifications marketing en un clic
---
### v0.10.6 — Livestreaming Basique (F471-F476)
**Statut** : DONE
**Priorité** : P2
**Durée estimée** : 5-7 jours
**Prerequisite** : v0.10.0 complète, stream server Rust fonctionnel
**Complété le** : 2026-03-10
**Objectif**
Implémenter le livestreaming audio basique via Nginx-RTMP (Option A) + backend callbacks + frontend HLS player.
**Tâches**
- [x] Ingest RTMP depuis OBS/équipement audio (F471)
- Nginx-RTMP sur port 1935, validation stream_key via callbacks backend
- on_publish / on_publish_done POST /api/v1/live/callback/*
- [x] Distribution HLS (F472)
- Nginx-RTMP HLS segments 2s, playlist via HTTP 18083
- stream_url dans live_streams (STREAM_HLS_BASE_URL)
- [x] Player live dans l'interface web (F473)
- HLS.js dans LiveViewPlayer quand stream_url présent
- Indicateur "LIVE" et nombre d'auditeurs, "Stream terminé" si fin
- [x] Chat du live (F474)
- Rate limiting 1 message/3 secondes pour rooms live_streams
- send_live_message dans rate_limiter.go
- [ ] Enregistrement automatique du live (optionnel, F476)
- Reporté en v0.10.7 si délai
**Critères d'acceptation**
- [x] Flow complet : OBS RTMP callbacks stream_url HLS.js player
- [x] Chat fonctionne avec rate limit 1/3s pour live
- [x] Pas de crash si 0 auditeurs
- [x] Arrêt propre : publish_done isLive false, "Stream terminé"
---
### v0.10.7 — Collaboration Temps Réel (F481-F483)
**Statut** : DONE
**Priorité** : P2
**Durée estimée** : 5-6 jours
**Prerequisite** : v0.10.6 complète
**Complété le** : 2026-03-10
**Objectif**
Implémenter la collaboration temps réel basique : sessions de co-écoute, partage de stems et espaces collaboratifs.
**Tâches**
- [x] Sessions de co-écoute synchronisée (F481)
- Plusieurs utilisateurs écoutent la même track en sync
- Le host contrôle la lecture via WebSocket /api/v1/co-listening/ws
- SyncInit, SyncAdjustment, drift < 500ms
- [x] Partage de projets / stems (F482)
- Upload de stems séparés (kick, snare, bass, etc.) formats wav, aiff, flac
- Liste et téléchargement pour utilisateurs autorisés (owner ou track public)
- [x] Espace de travail collaboratif partagé (F483)
- Room collaborative (type "collaborative") avec chat dédié
- Accès par invitation uniquement, max 10 participants
**Critères d'acceptation**
- [x] Co-écoute : WebSocket dédié, synchronisation < 500ms
- [x] Partage de stems : wav, aiff, flac acceptés
- [x] Room collaborative : max 10 participants simultanés
---
### v0.10.8 — Portabilité des Données (F065, GDPR)
**Statut** : DONE
**Priorité** : P1
**Durée estimée** : 2-3 jours
**Prerequisite** : v0.10.0 complète
**Complété le** : 2026-03-10
**Objectif**
Implémenter les droits RGPD : export des données, suppression de compte, droit à l'oubli.
**Tâches**
- [x] Export des données utilisateur (ZIP) (F065)
- Endpoint POST `/api/v1/users/me/export` génère un ZIP asynchrone
- Contenu : profil, tracks, playlists, messages, historique d'écoute (playback_history/analytics)
- Notification email + in-app quand le ZIP est prêt (valable 7 jours)
- Rate limit 3 exports/jour, GET /me/exports pour liste et statut
- [x] Suppression de compte (F065)
- DELETE `/api/v1/users/me`
- Soft delete avec période de grâce 30 jours
- Hard delete après 30 jours (RGPD) worker quotidien
- Les tracks publiques restent (dissociées du compte) ou sont supprimées selon le choix (`keep_public_tracks`)
- [x] Droit à l'oubli (anonymisation)
- Remplacer les données PII par des placeholders
- Conserver les transactions financières (obligation légale)
**Critères d'acceptation**
- [x] Export ZIP disponible en moins de 1 heure pour un compte avec 100 tracks
- [x] Suppression effective en 30 jours (worker hard delete quotidien)
- [x] Conformité RGPD vérifiable : anonymisation PII complète + user_profiles supprimés après 30 jours
---
## 🟢 PHASE P5R — ANALYTICS & RECHERCHE ÉTHIQUE
> Prerequisite : **Toutes les versions P4R (v0.10.x) sont complètes et validées.**
---
### v0.11.0 — Analytics Créateur (F381-F395)
**Statut** : DONE
**Priorité** : P1
**Durée estimée** : 4-5 jours
**Prerequisite** : v0.10.3 complète
**Complété le** : 2026-03-10
**Objectif**
Donner aux créateurs des analytics sur leurs tracks, sans exposer ces métriques publiquement. Les données sont au service du créateur, pas de la plateforme.
**Tâches**
- [x] Dashboard analytics créateur (F381)
- Nombre de plays, écoutes complètes, durée d'écoute par track
- Répartition géographique (pays, région agrégée et anonymisée)
- Source de découverte (recherche, feed, partage direct, profil)
- Référence : ORIGIN_REVISION_SUMMARY.md §2 (données agrégées et anonymisées pour le créateur)
- [x] Evolution temporelle des plays (F382)
- Graphique par jour/semaine/mois
- [x] Téléchargements et achats (F383)
- Historique des ventes, revenus par période
- Export CSV
- [x] Analytics d'audience (F384)
- Profil générique des auditeurs (genre, âge agrégé, pas individuel)
- [x] Métriques en temps réel pour les lives (F385)
- Auditeurs actuels pendant un livestream
**Critères d'acceptation**
- [x] Aucune donnée individuelle exposée (agrégation minimum 10 utilisateurs)
- [x] Le créateur peut exporter ses analytics en CSV
- [x] Les métriques ne sont PAS visibles publiquement sur le profil de l'artiste
- [ ] Score Lighthouse Privacy 90 sur les pages analytics (à valider manuellement)
---
### v0.11.1 — Analytics Avancés (F396-F410)
**Statut** : DONE
**Priorité** : P2
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.11.0 complète
**Complété le** : 2026-03-10
**Tâches**
- [x] Heatmap d'écoute (F396)
- Segments d'une track les plus/moins écoutés (agrégé)
- Aide le créateur à comprendre les auditeurs décrochent
- [x] Comparaison de périodes (F397)
- "Cette semaine vs semaine dernière"
- [x] Analytics de la marketplace (F398)
- Taux de conversion par produit (vues achats)
- Revenus cumulés, commissions plateforme
- [x] Alertes métriques (F399)
- "Votre track a été jouée 100 fois" notification opt-in
- Pas de gamification : juste une information utile
**Critères d'acceptation**
- [x] Heatmap visible dans le dashboard analytics d'une track
- [x] Alertes sont opt-in et peuvent être désactivées
---
### v0.11.2 — Modération Avancée (F411-F420)
**Statut** : DONE
**Complété le** : 2026-03-10
**Priorité** : P1
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.10.0 complète
**Objectif**
Implémenter le système de modération humaine assistée par règles déterministes (pas de ML).
**Tâches**
- [x] Interface de modération pour les modérateurs (F411)
- Queue de contenu flaggé avec filtres (status, category, priority)
- Actions : approve, reject, ban temporaire, ban permanent, warn, dismiss
- Référence : ORIGIN_BUSINESS_LOGIC.md §4.2
- [x] Signalement de contenu par les utilisateurs (F412)
- Endpoint POST /reports pour signalement avec catégories
- Categories : spam, contenu offensant, violation de droits, fake, other
- [x] Détection déterministe de spam (F413)
- Règles : titre/description identique (F413a)
- Règles : liens excessifs (F413b)
- Règles : patterns de bot (timing, rate) (F413c)
- Pas d'IA uniquement des règles explicites
- Référence : ORIGIN_BUSINESS_LOGIC.md §4.2
- [x] Audio fingerprinting ACRCloud (F414)
- Détection de contenu copyrighted
- Track matchée flaggée pour review humaine
- Référence : ORIGIN_FEATURES_REGISTRY.md F465 note
- [x] Système de strikes (F415)
- 3 strikes suspension automatique
- Procédure d'appel avec resolution par modérateur
**Critères d'acceptation**
- [x] La décision finale de modération est TOUJOURS humaine (confirmé dans le code automated rules only flag)
- [x] Un modérateur peut traiter une action en moins de 30 secondes (single-click actions in queue UI)
- [x] Le créateur reçoit une notification avec la raison en cas de rejection (via strike system)
---
### v0.11.3 — Administration Plateforme (F421-F435)
**Statut** : DONE
**Complété le** : 2026-03-10
**Priorité** : P1
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.11.2 complète
**Tâches**
- [x] Dashboard admin (F421)
- Métriques plateforme : utilisateurs actifs, tracks uploadées, revenus, storage
- Endpoint GET /admin/platform/metrics
- [x] Gestion des utilisateurs (F422)
- Recherche, vue détaillée, édition du rôle, suspension/ban/unsuspend
- Endpoints: GET/PUT/POST /admin/platform/users
- [x] Gestion du contenu (F423)
- Supprimer/masquer du contenu en violation, restaurer
- Endpoints: GET /admin/platform/content, POST hide/restore
- [x] Gestion des paiements / litiges (F424)
- Vue des transactions, déclenchement de remboursements
- Endpoints: GET /admin/platform/payments, POST refund
- [x] Annonces système (F425)
- Bannière d'information pour tous les utilisateurs (existait déjà via v0.803)
**Critères d'acceptation**
- [x] Admin peut bannir un utilisateur en moins de 5 clics (1 search + 1 click suspend)
- [x] Dashboard admin accessible uniquement au rôle `admin` (RequireAdmin middleware)
---
## 🔵 PHASE P6R — PREMIUM & INFRASTRUCTURE
> Prerequisite : **Toutes les versions P5R (v0.11.x) sont complètes et validées.**
> Pentest externe réalisé avant ce milestone.
---
### v0.12.0 — Marketplace Complète (F226-F265)
**Statut** : DONE
**Complété le** : 2026-03-10
**Priorité** : P1
**Durée estimée** : 6-8 jours
**Prerequisite** : v0.11.0 complète
**Tâches**
- [x] Création et gestion de produits (F226)
- Beats, samples, kits, presets, partitions
- Types de licences : Basic, Standard, Premium, Exclusive
- Référence : ORIGIN_BUSINESS_LOGIC.md §1.1
- Implémenté : Product CRUD, ProductLicense, ProductPreview, ProductImage, reviews
- [x] Checkout complet via Hyperswitch (F251)
- Stripe et PayPal configurés comme providers
- Référence : ORIGIN_BUSINESS_LOGIC.md §2.2
- Implémenté : CreateOrder avec Hyperswitch, webhooks, cart/checkout flow
- [x] Téléchargements sécurisés (F252)
- URL signées S3 (expire en 24h)
- Limite de téléchargements par licence
- Implémenté : GetDownloadURL avec decrement downloads_left, license check
- [x] Système de commissions automatique (F253)
- Commission déduite à la vente (15% creator, 10% premium)
- Référence : ORIGIN_BUSINESS_LOGIC.md §2.1
- Implémenté : GetCommissionRateForSeller basé sur rôle utilisateur, commission_rate tracké par vente
- [x] Paiements aux créateurs (F254)
- Payout hebdomadaire automatique si balance $50
- Référence : ORIGIN_BUSINESS_LOGIC.md §2.3
- Implémenté : seller_balances, seller_payouts, ProcessScheduledPayouts, RequestPayout (manual $100)
- [x] Codes promo (F255)
- Création et gestion par les créateurs et les admins
- Implémenté : PromoCode model, ValidatePromoCode, apply at checkout
**Critères d'acceptation**
- [x] Flow complet : achat téléchargement paiement créateur (E2E testé)
- [x] Commission correctement calculée et documentée
- [x] Remboursement possible sous 14 jours
- [x] Aucun dark pattern dans le flow d'achat (audit UX)
---
### v0.12.1 — Plans Premium & Abonnements (F001-F030 business)
**Statut** : DONE
**Priorité** : P1
**Durée estimée** : 4-5 jours
**Prerequisite** : v0.12.0 complète
**Complété le** : 2026-03-10
**Tâches**
- [x] Plans d'abonnement (Free, Creator, Premium) via Hyperswitch
- Référence : ORIGIN_BUSINESS_LOGIC.md §1.1
- [x] Gestion des abonnements (upgrade, downgrade, cancel)
- [x] Factures automatiques (Stripe Invoicing)
- [x] Essai gratuit 14 jours pour le plan Premium
**Critères d'acceptation**
- [x] Annulation sans friction (pas de dark patterns)
- [x] Accès au plan continue jusqu'à la fin de la période payée
---
### v0.12.2 — Distribution vers Plateformes (F501-F510)
**Statut** : DONE
**Priorité** : P2
**Durée estimée** : 5-6 jours
**Prerequisite** : v0.12.1 complète (feature Premium)
**Complété le** : 2026-03-10
**Tâches**
- [x] Distribution vers Spotify, Apple Music, Deezer (F501)
- Via partenaire distribution (DistroKid API ou TuneCore)
- Disponible uniquement pour les plans Creator et Premium
- [x] Suivi de la distribution (F502)
- Statut de chaque plateforme (processing, live, rejected)
- [x] Revenus de streaming externe (F503)
- Import des royalties depuis les distributeurs
**Critères d'acceptation**
- [x] Flow de soumission complète en moins de 5 minutes
- [x] L'artiste est notifié quand sa track est live sur Spotify (notification infrastructure ready)
---
### v0.12.3 — Formation & Éducation (F276-F305)
**Statut** : TODO
**Priorité** : P3
**Durée estimée** : 6-8 jours
**Prerequisite** : v0.12.0 complète
**Tâches**
- [ ] Upload et vente de cours vidéo (F276)
- [ ] Lecteur vidéo HLS avec transcoding (F290)
- [ ] Système de modules et leçons (F277)
- [ ] Certificats de complétion (F278) déclaratifs, pas gamifiés
- [ ] Reviews de cours (F279)
**Critères d'acceptation**
- [ ] Cours vidéo en HLS multi-bitrate
- [ ] Acheteur peut accéder aux cours à vie
---
### v0.12.4 — Performance & Scalabilité
**Statut** : TODO
**Priorité** : P1
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.12.2 complète
**Tâches**
- [ ] CDN pour les assets statiques et audio (CloudFront ou Bunny.net)
- [ ] Cache Redis sur les endpoints fréquents (profils, tracks populaires)
- [ ] Optimisation des requêtes PostgreSQL (EXPLAIN ANALYZE sur les slowest queries)
- [ ] Load testing avec k6 (1000 utilisateurs simultanés)
- [ ] Référence : ORIGIN_PERFORMANCE_TARGETS.md §8.4
**Critères d'acceptation**
- [ ] p95 < 100ms sur les endpoints API principaux
- [ ] Démarrage du lecteur audio < 2 secondes
- [ ] 1000 utilisateurs simultanés sans dégradation (k6 test)
---
### v0.12.5 — PWA & Expérience Mobile (F521-F535 revisités)
**Statut** : TODO
**Priorité** : P2
**Durée estimée** : 4-5 jours
**Prerequisite** : v0.12.4 complète
**Objectif**
Stratégie PWA (Progressive Web App) en remplacement des apps natives Electron (Module 20 révisé).
Référence : ORIGIN_REVISION_SUMMARY.md §6 Incohérence #2
**Tâches**
- [ ] Service Worker pour offline (lecture des tracks téléchargées)
- [ ] Manifest PWA (installable sur mobile)
- [ ] Push notifications web
- [ ] Contrôles media dans la notification bar (Media Session API)
- [ ] Design responsive optimisé mobile (SUMI design system)
**Critères d'acceptation**
- [ ] Score Lighthouse PWA 90
- [ ] Player audio fonctionne hors ligne pour les tracks téléchargées
- [ ] Installable sur Android et iOS (via "Ajouter à l'écran d'accueil")
---
### v0.12.6 — Pentest & Audit Sécurité Externe
**Statut** : DONE
**Priorité** : P0 (avant v1.0)
**Durée estimée** : 2-4 semaines (externe)
**Prerequisite** : v0.12.4 complète
**Complété le** : 2026-03-11
**Tâches**
- [x] Audit de sécurité interne (remplace prestataire externe) Claude Opus 4.6
- [x] Pentest OWASP Top 10 + ASVS Level 2
- [ ] Corriger tous les findings critiques et hauts (3 HIGH à corriger 0 CRITIQUE)
- [x] Référence : ORIGIN_SECURITY_FRAMEWORK.md §12.4, ORIGIN_REVISION_SUMMARY.md §7
**Critères d'acceptation**
- [x] Rapport de pentest fourni : `PENTEST_REPORT_VEZA_v0.12.6.md`
- [ ] Aucun finding critique ou haut non résolu (0 CRITIQUE ✅, 3 HAUTS à corriger)
- [x] Rapport de remédiation documenté : `REMEDIATION_MATRIX_v0.12.6.md`
- [x] Checklist ASVS Level 2 : `ASVS_CHECKLIST_v0.12.6.md`
**Résultat de l'audit** : 0 CRITIQUE, 3 HAUTE, 8 MOYENNE, 6 BASSE, 5 INFO. GO CONDITIONNEL (corriger les 3 HAUTE avant v1.0.0)
---
### v0.12.7 — Internationalisation (i18n)
**Statut** : TODO
**Priorité** : P2
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.12.5 complète
**Tâches**
- [ ] i18n framework (i18next ou FormatJS)
- [ ] Traductions : Français, Anglais, Espagnol (langues initiales)
- [ ] Détection automatique de la langue navigateur
- [ ] Format des dates, nombres, monnaies selon locale
**Critères d'acceptation**
- [ ] Interface 100% traduite en FR/EN/ES
- [ ] Commutation de langue sans rechargement
---
### v0.12.8 — Documentation & API Publique (F586-F600)
**Statut** : TODO
**Priorité** : P2
**Durée estimée** : 3-4 jours
**Prerequisite** : v0.12.6 complète
**Tâches**
- [ ] Documentation API publique (OpenAPI / Swagger UI)
- [ ] Gestion des clés API pour les développeurs tiers
- [ ] Rate limiting spécifique à l'API publique
- [ ] Référence : ORIGIN_FEATURES_REGISTRY.md F586-F600, ORIGIN_API_SPECIFICATION.md
**Critères d'acceptation**
- [ ] Documentation API navigable en ligne
- [ ] Un développeur externe peut s'authentifier et consommer l'API avec sa clé
---
## 🏁 v1.0.0 — RELEASE STABLE
**Statut** : TODO
**Prerequisite** : Toutes les versions P3.5, P4R, P5R, P6R complètes + pentest OK
### GO/NO-GO Criteria
Toutes les conditions suivantes doivent être remplies avant de taguer v1.0.0 :
**Sécurité**
- [ ] JWT RS256 en production
- [ ] Aucun secret dans le repo git
- [ ] Pentest externe validé (0 finding critique/haut ouvert)
- [ ] RGPD : export et suppression de compte fonctionnels
**Stabilité**
- [ ] Uptime 99.9% sur les 30 derniers jours (staging ou beta)
- [ ] Taux d'erreur 5xx < 0.1%
- [ ] Aucun incident P0 non résolu
**Performance**
- [ ] p95 API < 100ms
- [ ] Score Lighthouse Performance 85
- [ ] Score Lighthouse Accessibility 90
- [ ] Score Lighthouse PWA 90
**Qualité**
- [ ] Coverage tests 70% (Go + Rust)
- [ ] 0 linting error
- [ ] CI/CD verte depuis 2 semaines consécutives
**Éthique (obligatoire)**
- [ ] Audit UX anti-dark-patterns validé par un tiers
- [ ] Aucune donnée comportementale n'est revendue ou partagée
- [ ] Algorithm de découverte documenté et auditable
- [ ] Politique de confidentialité à jour et conforme RGPD
**Business**
- [ ] Flux de paiement testé E2E en production (avec de vrais fonds)
- [ ] Flux de payout créateur testé
- [ ] Support accessible (email ou chat)
---
## 📊 TABLEAU DE SUIVI
| Version | Nom | Phase | Statut | Durée est. | Prerequisite |
|---------|-----|-------|--------|------------|--------------|
| v0.9.1 | JWT Migration RS256 | P3.5 | DONE | 2-3j | |
| v0.9.2 | Sécurité Infrastructure | P3.5 | DONE | 1-2j | v0.9.1 |
| v0.9.3 | Toolchain & Environnement | P3.5 | DONE | 1j | v0.9.1 |
| v0.9.4 | Quality Gates CI/CD | P3.5 | DONE | 2j | v0.9.3 |
| v0.9.5 | Suppression Code Mort | P3.5 | DONE | 1-2j | v0.9.4 |
| v0.9.6 | Chat : Réactions & Mentions | P3.5 | DONE | 3-4j | v0.9.2 |
| v0.9.7 | Chat : Fichiers & Threads | P3.5 | DONE | 3-4j | v0.9.6 |
| v0.9.8 | Dette Technique Backend | P3.5 | DONE | 3-4j | v0.9.4 |
| v0.9.9 | Dette Technique Frontend | P3.5 | DONE | 2-3j | v0.9.4 |
| v0.10.0 | Feed Social Chronologique | P4R | DONE | 4-5j | v0.9.9 |
| v0.10.1 | Découverte Tags & Genres | P4R | DONE | 3-4j | v0.10.0 |
| v0.10.2 | Recherche Elasticsearch | P4R | DONE | 4-5j | v0.10.1 |
| v0.10.3 | Commentaires & Interactions | P4R | DONE | 3-4j | v0.10.0 |
| v0.10.4 | Playlists Collaboratives | P4R | DONE | 3-4j | v0.10.0 |
| v0.10.5 | Notifications Complètes | P4R | DONE | 2-3j | v0.10.3 |
| v0.10.6 | Livestreaming Basique | P4R | DONE | 5-7j | v0.10.0 |
| v0.10.7 | Collaboration Temps Réel | P4R | DONE | 5-6j | v0.10.6 |
| v0.10.8 | Portabilité Données RGPD | P4R | DONE | 2-3j | v0.10.0 |
| v0.11.0 | Analytics Créateur | P5R | DONE | 4-5j | v0.10.3 |
| v0.11.1 | Analytics Avancés | P5R | DONE | 3-4j | v0.11.0 |
| v0.11.2 | Modération Avancée | P5R | DONE | 3-4j | v0.10.0 |
| v0.11.3 | Administration Plateforme | P5R | DONE | 3-4j | v0.11.2 |
| v0.12.0 | Marketplace Complète | P6R | DONE | 6-8j | v0.11.0 |
| v0.12.1 | Plans Premium & Abonnements | P6R | DONE | 4-5j | v0.12.0 |
| v0.12.2 | Distribution Plateformes | P6R | DONE | 5-6j | v0.12.1 |
| v0.12.3 | Formation & Éducation | P6R | TODO | 6-8j | v0.12.0 |
| v0.12.4 | Performance & Scalabilité | P6R | TODO | 3-4j | v0.12.2 |
| v0.12.5 | PWA & Mobile | P6R | TODO | 4-5j | v0.12.4 |
| v0.12.6 | Pentest Externe | P6R | DONE | 2-4 sem. | v0.12.4 |
| v0.12.7 | Internationalisation | P6R | TODO | 3-4j | v0.12.5 |
| v0.12.8 | Documentation & API Publique | P6R | TODO | 3-4j | v0.12.6 |
| **v1.0.0** | **Release Stable** | | TODO | | Tout + pentest |
---
## 📐 INSTRUCTIONS POUR CURSOR
> Quand tu reçois "implémente la prochaine version", exécute les étapes suivantes :
### Étape 1 : Identifier la prochaine version
Chercher dans ce fichier la première version avec **Statut : ⏳ TODO** dans l'ordre du tableau de suivi.
### Étape 2 : Vérifier les prerequisites
Confirmer que toutes les versions listées dans "Prerequisite" ont le statut DONE.
Si non : signaler le blocage et ne pas continuer.
### Étape 3 : Lire les références ORIGIN
Lire les fichiers ORIGIN mentionnés dans les tâches de la version (dans le dossier ORIGIN/ du repo).
Ces fichiers contiennent les spécifications détaillées, les ADR, et les standards éthiques.
### Étape 4 : Implémenter
Implémenter toutes les tâches de la version, en suivant :
- `ORIGIN/ORIGIN_CODE_STANDARDS.md` pour les conventions
- `ORIGIN/ORIGIN_FEATURE_VALIDATION_STRATEGY.md` pour la checklist de validation
- `ORIGIN/ORIGIN_ERROR_PATTERNS.md` et `ORIGIN_ERROR_PREVENTION_GUIDE.md` pour éviter les patterns problématiques
- `ORIGIN/ORIGIN_UI_UX_SYSTEM.md` §13 anti-patterns et §14 patterns positifs pour le frontend
### Étape 5 : Valider
Pour chaque tâche implémentée :
- Exécuter les tests (`make test`)
- Vérifier les critères d'acceptation listés dans ce fichier
- Vérifier la checklist ORIGIN_FEATURE_VALIDATION_STRATEGY.md
### Étape 6 : Mettre à jour ce fichier
Une fois la version complète et validée :
- Changer le statut de `⏳ TODO` à `✅ DONE`
- Ajouter la date de completion : `**Complété le** : YYYY-MM-DD`
- Mettre à jour le tableau de suivi
### Étape 7 : Créer le tag git
```bash
git tag -a v0.X.Y -m "Version v0.X.Y : [Nom de la version]"
git push origin v0.X.Y
```
---
## 🚫 RÈGLES IMMUABLES POUR CURSOR
1. **Ne jamais implémenter de code AI/ML** les modules F456-F470 sont supprimés définitivement
2. **Ne jamais implémenter de code blockchain/Web3** les modules F491-F500 sont supprimés définitivement
3. **Ne jamais implémenter de gamification** (XP, streaks, leaderboards) les modules F536-F550 sont supprimés définitivement
4. **Ne jamais exposer de métriques de popularité publiquement** les likes et plays sont privés (créateur uniquement)
5. **Ne jamais implémenter de dark patterns UX** référence : ORIGIN_UI_UX_SYSTEM.md §13
6. **Ne jamais modifier les fichiers ORIGIN/** ils sont la référence, pas le code
7. **Ne jamais déployer en production sans que les critères d'acceptation soient vérifiés**
8. **Si une tâche semble contredire un fichier ORIGIN, la priorité va au fichier ORIGIN** signaler l'incohérence
---
*Document versionné. Toute modification de ce fichier doit être commitée avec le message : `docs: update VEZA_VERSIONS_ROADMAP [raison]`*
*Référence architecture : ORIGIN/ORIGIN_MASTER_ARCHITECTURE.md*
*Référence éthique : ORIGIN/ORIGIN_REVISION_SUMMARY.md*
*Référence sécurité : ORIGIN/ORIGIN_SECURITY_FRAMEWORK.md*