veza/veza-docs/audit/AUDIT_05_ROADMAP_v1.0.md

# AUDIT_05_ROADMAP_v1.0.md -- Roadmap Exhaustive vers la v1.0

**Date** : 2026-03-11
**Auditeur** : Claude Opus 4.6

---

## 0. PRINCIPES DE CETTE ROADMAP

Cette roadmap remplace la section TODO du `VEZA_VERSIONS_ROADMAP.md` existant. Elle est construite a partir du diagnostic Phase 4 et couvre **tous les ecarts identifies** entre le code actuel et les specifications ORIGIN, organises par priorite.

**Regle cardinale** : Rien ne passe en v1.0 tant que tous les criteres GO/NO-GO ne sont pas satisfaits.

**Ordre de priorite** :
- **P0** : Bloquants securite — sans resolution, aucun deploiement possible
- **P1** : Features manquantes bloquant v1.0 — versions TODO du roadmap + tests ethiques
- **P2** : Conformite — ecarts spec/code qui n'empechent pas le fonctionnement mais violent les ORIGIN
- **P3** : Polish — features partielles et ameliorations d'experience
- **P4** : Nice-to-have — optionnel pour v1.0, peut etre reporte en v1.1+

---

## 1. TABLEAU DE BORD — ETAT AVANT ROADMAP

```
VERSIONS EXISTANTES
  DONE  : 27 versions (v0.9.1 → v0.12.6.1)
  TODO  : 3 versions (v0.12.7, v0.12.8, v1.0.0)

ECARTS DIAGNOSTIQUES
  P0 Bloquants securite     :  3 ecarts  (~5j)
  P1 Features bloquantes    :  7 ecarts  (~15j)
  P2 Conformite             :  8 ecarts  (~14j)
  P3 Polish                 : 10 ecarts  (~20j)
  P4 Nice-to-have           :  5 ecarts  (~10j)

  TOTAL ECARTS              : 33
  EFFORT TOTAL ESTIME       : 50-65 jours-dev

CRITERES NON COCHES DANS VERSIONS DONE
  v0.9.1  : 1 (staging deploy)
  v0.9.2  : 1 (pentest partiel)
  v0.9.5  : 1 (tests pass)
  v0.9.8  : 1 (coverage 70%)
  v0.10.0 : 2 (perf, staging)
  v0.10.1 : 1 (test biais)
  v0.10.2 : 1 (test 0-plays)
  v0.11.0 : 1 (Lighthouse)
  v0.12.6 : 1 (3 HIGH findings)
  TOTAL   : 10 criteres non coches
```

---

## 2. NOUVELLES VERSIONS — VUE D'ENSEMBLE

| # | Version | Nom | Priorite | Effort | Prerequisite | GO/NO-GO |
|---|---------|-----|----------|--------|--------------|----------|
| 1 | v0.12.6.1 | Correctifs Pentest (30/30 findings) | P0 | 5-8j | v0.12.6 | ✅ DONE 2026-03-12 |
| 2 | v0.12.6.2 | Correctifs Securite Spec | P0 | 1.5j | v0.12.6 | Securite |
| 3 | v0.12.6.3 | Nettoyage Code Fantome | P1 | 1-2j | v0.12.6 | Ethique |
| 4 | v0.12.7 | Internationalisation (i18n) | P1 | 3-4j | v0.12.5 | Qualite |
| 5 | v0.12.8 | Documentation & API Publique | P1 | 3-4j | v0.12.6 | Qualite |
| 6 | v0.12.9 | Tests Ethiques & Coverage CI | P1 | 2-3j | v0.12.6.3 | Ethique+Qualite |
| 7 | v0.13.0 | Conformite Features Partielles | P2 | 5-7j | v0.12.9 | Qualite |
| 8 | v0.13.1 | Conformite Audio & Player | P2 | 4-5j | v0.13.0 | Qualite |
| 9 | v0.13.2 | Consolidation Design System | P2 | 2-3j | v0.13.0 | Qualite |
| 10 | v0.13.3 | Polish Securite Avancee | P3 | 3-4j | v0.13.0 | Securite |
| 11 | v0.13.4 | Polish Audio & Player | P3 | 3-4j | v0.13.1 | — |
| 12 | v0.13.5 | Polish Marketplace & Compliance | P3 | 3-4j | v0.13.0 | Business |
| 13 | v0.14.0 | Validation Runtime & Staging | P0-P1 | 3-5j | v0.13.2 | Stabilite+Perf |
| 14 | v1.0.0-rc1 | Release Candidate 1 | — | 2-3j | Tout | Tout |
| 15 | v1.0.0 | Release Stable | — | 1-2j | v1.0.0-rc1 | Tout |

**Effort total estime : 40-55 jours-dev**
**Duree calendaire estimee (1 dev) : 10-14 semaines**
**Duree calendaire estimee (2 devs) : 6-8 semaines**

---

## 3. DETAIL DES VERSIONS

---

### v0.12.6.1 — Correctifs Pentest (30/30 findings)

**Priorite** : P0 — BLOQUANT SECURITE
**Statut** : ✅ DONE
**Complete le** : 2026-03-12
**Effort** : 3-5 jours
**Prerequisite** : v0.12.6
**GO/NO-GO** : `Securite → Pentest externe valide (0 finding critique/haut ouvert)` ✅

**Contexte** : Le pentest v0.12.6 a identifie 30 findings (2 CRIT, 10 HIGH, 12 MEDIUM, 6 LOW). Tous les 30 ont ete corriges dans 4 commits. La matrice de remediation (REMEDIATION_MATRIX_v0.12.6.md) montre 30/30 corriges.

**Taches**

- [x] **TASK-PFIX-001** : Corriger CRIT-001 — IDOR conversations privees (CVSS 9.1)
- [x] **TASK-PFIX-002** : Corriger CRIT-002 — Metriques de popularite publiques (CVSS 5.3)
- [x] **TASK-PFIX-003** : Corriger les 10 findings HIGH
- [x] **TASK-PFIX-005** : Corriger les 12 findings MEDIUM
- [x] **TASK-PFIX-006** : Corriger les 6 findings LOW

**Criteres d'acceptation**
- [x] Les 2 findings CRITIQUES corriges (IDOR + metriques publiques)
- [x] Les 10 findings HIGH corriges (race conditions, TrustedProxies, RGPD, RTMP, etc.)
- [x] Les 12 findings MEDIUM corriges (CSP, pagination, WebSocket, k-anonymity, etc.)
- [x] Les 6 findings LOW corriges (password policy, Docker pins, dotenv, Elasticsearch, context)
- [x] 0 finding critique ou haut ouvert

---

### v0.12.6.2 — Correctifs Securite Spec

**Priorite** : P0 — BLOQUANT SECURITE
**Effort** : 1.5 jours
**Prerequisite** : v0.12.6
**GO/NO-GO** : `Securite → JWT RS256 en production` + regles ORIGIN

**Contexte** : Deux ecarts de conformite securite identifies entre le code et ORIGIN_SECURITY_FRAMEWORK.md.

**Taches**

- [ ] **TASK-SFIX-001** : Forcer MFA pour roles admin et moderator
  - Modifier le middleware auth pour exiger MFA sur les roles `admin` et `moderator`
  - Ajouter un ecran de setup MFA obligatoire au premier login admin/moderator
  - Ref: ORIGIN_SECURITY_FRAMEWORK.md Regle 5
  - Fichiers: `backend/internal/middleware/auth_middleware.go`, `backend/internal/auth/mfa_enforcement.go`

- [ ] **TASK-SFIX-002** : Aligner refresh token TTL sur la spec (30j → 7j)
  - Modifier la configuration JWT pour fixer le refresh token TTL a 7 jours
  - Invalider les refresh tokens existants avec TTL > 7j (migration)
  - Ref: ORIGIN_SECURITY_FRAMEWORK.md Regle 4
  - Fichiers: `backend/internal/auth/jwt_service.go`, `backend/configs/`

- [ ] **TASK-SFIX-003** : Tests de validation securite spec
  - Test: MFA est requis pour tout endpoint admin/moderator
  - Test: refresh token expire apres 7 jours exactement
  - Test: access token expire apres 15 minutes

**Criteres d'acceptation**
- [ ] Connexion admin sans MFA → redirige vers setup MFA obligatoire
- [ ] Connexion moderator sans MFA → redirige vers setup MFA obligatoire
- [ ] `jwt_service.go` : refresh token TTL = 7 jours (604800 secondes)
- [ ] Tests unitaires passent pour les 2 correctifs

**Risques**
- Impact sur les admins existants qui n'ont pas encore configure MFA
- Migration des tokens existants a gerer proprement

---

### v0.12.6.3 — Nettoyage Code Fantome

**Priorite** : P1
**Effort** : 1-2 jours
**Prerequisite** : v0.12.6
**GO/NO-GO** : `Ethique → Aucune donnee comportementale`, `Ethique → Audit UX anti-dark-patterns`

**Contexte** : Le diagnostic a identifie 9 modules "fantomes" — du code present dans le repo mais non specifie dans les ORIGIN. Certains (`contest`, `voting_system`, `production_challenge`) pourraient constituer de la gamification interdite. `playback_abtest_service.go` pose un probleme ethique potentiel.

**Taches**

- [ ] **TASK-GHOST-001** : Auditer les modules fantomes
  - Verifier si `contest/`, `sound_design_contest/`, `production_challenge/`, `voting_system/` sont actifs (routes enregistrees? appeles quelque part?)
  - Si actifs et gamification → desactiver/supprimer
  - Si inactifs → supprimer le code mort
  - Fichiers: `backend/internal/api/contest/`, `backend/internal/api/sound_design_contest/`, `backend/internal/api/production_challenge/`, `backend/internal/api/voting_system/`

- [ ] **TASK-GHOST-002** : Evaluer et traiter `playback_abtest_service.go`
  - Verifier si le A/B testing audio est actif
  - S'il manipule l'experience utilisateur sans consentement → supprimer
  - S'il est desactive → supprimer le code mort
  - Ref: ORIGIN_UI_UX_SYSTEM.md §13 anti-dark-patterns

- [ ] **TASK-GHOST-003** : Traiter les modules non-spec utiles
  - `listing/handler.go` et `offer/handler.go` : determiner si lies au marketplace (F226-F275)
  - `graphql/handler.go` : ORIGIN ne specifie que REST → documenter ou supprimer
  - `grpc/handler.go` : spec dans ORIGIN section 9 → conserver, documenter

- [ ] **TASK-GHOST-004** : Verifier absence de code mort residuel
  - Confirmer 0 traces AI/ML, blockchain, gamification apres nettoyage
  - grep final sur les termes interdits

**Criteres d'acceptation**
- [ ] Aucun module de gamification actif dans le code
- [ ] `playback_abtest_service.go` traite (supprime ou desactive avec documentation)
- [ ] Code mort fantome supprime ou documente
- [ ] grep confirme 0 traces des categories ethiquement exclues

**Risques**
- Certains modules fantomes pourraient etre utilises par des routes actives → regression possible

---

### v0.12.7 — Internationalisation (i18n)

**Priorite** : P1 — BLOQUE v1.0
**Effort** : 3-4 jours
**Prerequisite** : v0.12.5
**GO/NO-GO** : `Qualite → CI/CD verte`

**Contexte** : Version TODO existante dans le roadmap. L'internationalisation n'est pas implementee. Le spec exige FR/EN/ES minimum.

**Taches**

- [ ] **TASK-I18N-001** : Infrastructure i18n frontend
  - Installer et configurer `react-i18next` ou `next-intl`
  - Creer la structure de fichiers de traduction `locales/{fr,en,es}/`
  - Configurer le detection de langue (navigator, cookie, URL param)
  - Fichiers: `apps/web/src/i18n/`, `apps/web/src/locales/`

- [ ] **TASK-I18N-002** : Extraction des chaines
  - Parcourir tous les composants React et extraire les chaines hardcodees
  - Remplacer par des appels `t('key')` ou equivalent
  - Generer les fichiers de traduction FR (source), EN, ES

- [ ] **TASK-I18N-003** : Commutateur de langue
  - Composant UI de selection de langue (dropdown header)
  - Persistence du choix (localStorage / cookie)
  - Commutation sans rechargement de page (reactif)

- [ ] **TASK-I18N-004** : i18n backend (messages d'erreur)
  - Internationaliser les messages d'erreur API (`Accept-Language` header)
  - Messages de validation, emails transactionnels
  - Fichiers: `backend/internal/i18n/`, `backend/pkg/apierror/`

- [ ] **TASK-I18N-005** : Tests i18n
  - Test: toutes les cles de traduction existent dans les 3 langues
  - Test: commutation de langue fonctionne sans rechargement
  - Test: fallback vers EN si cle manquante

**Criteres d'acceptation**
- [ ] Interface 100% traduite en FR/EN/ES
- [ ] Commutation de langue sans rechargement
- [ ] Messages d'erreur API internationalises
- [ ] 0 chaine hardcodee dans les composants React

**Risques**
- Volume de chaines a extraire potentiellement important (~1900 fichiers TSX)
- Traductions ES a faire (ou placeholders acceptables pour v1.0)

---

### v0.12.8 — Documentation & API Publique

**Priorite** : P1 — BLOQUE v1.0
**Effort** : 3-4 jours
**Prerequisite** : v0.12.6
**GO/NO-GO** : `Qualite → CI/CD verte`

**Contexte** : Version TODO existante. Module 24 Developpeurs & API (F586-F600) est tres partiel. ORIGIN exige une documentation API publique navigable.

**Taches**

- [ ] **TASK-APIDOC-001** : Generation OpenAPI / Swagger
  - Annoter les handlers Go existants avec des commentaires Swagger (swag/swaggo)
  - Generer `swagger.json` / `openapi.yaml`
  - Servir Swagger UI sur `/api/docs`
  - Fichiers: `backend/cmd/`, `backend/internal/handlers/`, routes

- [ ] **TASK-APIDOC-002** : Gestion des cles API developpeurs
  - CRUD de cles API pour developpeurs tiers
  - Modele: `api_keys` (id, user_id, key_hash, name, scopes, rate_limit, created_at, expires_at)
  - Middleware de validation de cle API
  - Fichiers: `backend/internal/models/api_key.go`, `backend/internal/handlers/api_key_handler.go`

- [ ] **TASK-APIDOC-003** : Rate limiting API publique
  - Rate limits specifiques par cle API (configurable)
  - Headers `X-RateLimit-*` sur les reponses
  - Ref: ORIGIN_API_SPECIFICATION.md §rate limits

- [ ] **TASK-APIDOC-004** : Page portail developpeurs frontend
  - Page de gestion des cles API
  - Documentation interactive embeddee (Swagger UI)
  - Fichiers: `apps/web/src/pages/developers/`

- [ ] **TASK-APIDOC-005** : Tests API publique
  - Test: Swagger UI accessible et a jour
  - Test: cle API valide → acces OK, cle invalide → 401
  - Test: rate limiting par cle API fonctionne

**Criteres d'acceptation**
- [ ] Documentation API navigable en ligne (`/api/docs`)
- [ ] Un developpeur externe peut creer une cle et consommer l'API
- [ ] Rate limiting par cle API fonctionnel
- [ ] OpenAPI spec generee automatiquement a jour

**Risques**
- Annotation Swagger de ~70+ route files = effort significatif
- Scope de "API publique" a definir (quels endpoints exposer?)

---

### v0.12.9 — Tests Ethiques & Coverage CI

**Priorite** : P1
**Effort** : 2-3 jours
**Prerequisite** : v0.12.6.3
**GO/NO-GO** : `Ethique → Algorithme de decouverte auditable`, `Qualite → Coverage tests >= 70%`

**Contexte** : Les tests de biais ethiques exiges par les specs sont absents. La coverage n'est ni mesuree ni enforcee en CI.

**Taches**

- [ ] **TASK-ETH-001** : Test de biais artistes emergents (v0.10.1 non coche)
  - Ecrire un test qui verifie que la decouverte ne defavorise pas les artistes avec 0 ou peu de contenus
  - Le feed/decouverte doit inclure des artistes emergents proportionnellement
  - Ref: ORIGIN_FEATURES_REGISTRY.md, criteres ethiques
  - Fichiers: `backend/internal/service/discovery_service_test.go`

- [ ] **TASK-ETH-002** : Test recherche artiste 0 plays (v0.10.2 non coche)
  - Ecrire un test qui verifie qu'un artiste avec 0 plays apparait dans les resultats de recherche par nom
  - La recherche ne doit pas filtrer/penaliser par popularite
  - Fichiers: `backend/internal/service/search_service_test.go`

- [ ] **TASK-ETH-003** : Documenter l'algorithme de decouverte
  - Ecrire un document expliquant le fonctionnement de la decouverte
  - Confirmer: chronologique + tags/genres declaratifs, JAMAIS de classement par popularite
  - Fichier: `veza-docs/DISCOVERY_ALGORITHM.md`

- [ ] **TASK-COV-001** : Configurer coverage CI
  - Ajouter `go test -coverprofile` dans le workflow CI
  - Ajouter quality gate: coverage >= 70% sur nouveau code
  - Publier le rapport coverage (badge, artefact)
  - Fichiers: `.github/workflows/ci.yml`

- [ ] **TASK-COV-002** : Augmenter coverage Rust
  - Ajouter des tests unitaires au stream server Rust (actuellement 25 fichiers)
  - Cible: au moins 50% de coverage Rust
  - Configurer `cargo tarpaulin` en CI

- [ ] **TASK-COV-003** : Rapport coverage global
  - Agreger Go + Rust + Frontend dans un rapport unique
  - Quality gate globale >= 70%

**Criteres d'acceptation**
- [ ] Test de biais artistes emergents PASSE
- [ ] Test recherche artiste 0 plays PASSE
- [ ] Algorithme de decouverte documente
- [ ] Coverage mesuree et enforcee en CI (>= 70% Go, >= 50% Rust)
- [ ] Badge coverage visible dans le repo

**Risques**
- La coverage Rust peut etre difficile a monter rapidement (de ~40% a 50%)
- Les tests de biais peuvent reveler des problemes dans la logique de decouverte

---

### v0.13.0 — Conformite Features Partielles

**Priorite** : P2
**Effort** : 5-7 jours
**Prerequisite** : v0.12.9
**GO/NO-GO** : `Qualite → 0 linting error`

**Contexte** : ~83 features sont marquees PARTIEL dans le diagnostic. Cette version cible les features partielles les plus impactantes pour la conformite.

**Taches**

- [ ] **TASK-CONF-001** : Completer 2FA SMS (F020)
  - Implementer l'envoi de codes SMS via un provider (Twilio ou equivalent)
  - Frontend: ecran de saisie du code SMS
  - Ref: ORIGIN_FEATURES_REGISTRY.md F020
  - Fichiers: `backend/internal/auth/sms_service.go`, `apps/web/src/pages/auth/`

- [ ] **TASK-CONF-002** : Implementer CAPTCHA anti-bot (F029)
  - Integrer hCaptcha ou Turnstile (pas Google reCAPTCHA pour la vie privee)
  - Proteger: registration, login, password reset, contact forms
  - Ref: ORIGIN_FEATURES_REGISTRY.md F029
  - Fichiers: `apps/web/src/components/captcha/`, `backend/internal/middleware/captcha_middleware.go`

- [ ] **TASK-CONF-003** : Completer les features auth partielles
  - F010: tester logout all devices completement
  - F013: verifier password history (empecher reutilisation)
  - F014: ajouter validation force password cote backend
  - F018: completer notification changement password
  - F021: tester 2FA backup codes completement
  - F024: implementer notification connexion inhabituelle
  - F026: completer historique connexions avec details

- [ ] **TASK-CONF-004** : Completer les features fichiers partielles
  - F075: verifier integration ClamAV complete
  - F080: evaluer watermarking (si requis pour v1.0)

- [ ] **TASK-CONF-005** : Resoudre la double structure handlers
  - Migrer les handlers restants de `internal/handlers/` vers `internal/core/*/handler.go`
  - Ou documenter la coexistence et nettoyer les doublons
  - Ref: diagnostic §5.1

- [ ] **TASK-CONF-006** : Nettoyer TODO/FIXME frontend
  - Traiter les 43 TODO/FIXME identifies dans le frontend
  - Resoudre ou convertir en issues trackees
  - Cible: < 10 TODO/FIXME restants

**Criteres d'acceptation**
- [ ] F020 2FA SMS fonctionnel de bout en bout
- [ ] F029 CAPTCHA actif sur registration et login
- [ ] Features auth partielles completees (F010, F013, F014, F018, F021, F024, F026)
- [ ] Structure handlers unifiee ou nettoyee
- [ ] TODO/FIXME < 10

**Risques**
- Integration SMS provider necessite un compte et des couts
- Migration handlers peut causer des regressions si routes mal recablees

---

### v0.13.1 — Conformite Audio & Player

**Priorite** : P2
**Effort** : 4-5 jours
**Prerequisite** : v0.13.0
**GO/NO-GO** : `Qualite`

**Contexte** : Plusieurs features du module 4 (Streaming Audio, F106-F150) sont partielles ou absentes.

**Taches**

- [ ] **TASK-AUDIO-001** : Gapless playback (F116)
  - Implementer la lecture sans interruption entre deux tracks
  - Utiliser Web Audio API pour le pre-buffering du track suivant
  - Fichiers: `apps/web/src/components/player/`, stream server

- [ ] **TASK-AUDIO-002** : Crossfade (F117) — si absent
  - Verifier l'etat actuel du crossfade
  - Implementer le fondu enchaine configurable (1-12s)

- [ ] **TASK-AUDIO-003** : Normalisation audio (F118) — si absent
  - Normalisation du volume entre tracks (ReplayGain ou equivalent)
  - Cote serveur (Rust) ou cote client (Web Audio API)

- [ ] **TASK-AUDIO-004** : Completer les features player partielles
  - Verifier F106-F115 (play, pause, seek, volume, queue, shuffle, repeat, progress, waveform)
  - Completer les tests pour chaque feature player

**Criteres d'acceptation**
- [ ] Gapless playback fonctionne entre deux tracks consecutifs
- [ ] Crossfade configurable
- [ ] Pas de saut de volume entre tracks
- [ ] Toutes les features player core testees

**Risques**
- Gapless playback complexe sur mobile/PWA (limitations navigateur)
- Performance Web Audio API a valider

---

### v0.13.2 — Consolidation Design System

**Priorite** : P2
**Effort** : 2-3 jours
**Prerequisite** : v0.13.0
**GO/NO-GO** : `Qualite → 0 linting error`

**Contexte** : Le package `packages/design-system/` est quasi vide (1 fichier). Les composants SUMI sont dans `apps/web/src/components/ui/`. Cela cree de la duplication et empeche la reutilisation entre apps.

**Taches**

- [ ] **TASK-DS-001** : Migrer les composants SUMI vers le design system
  - Deplacer les composants UI de base de `apps/web/src/components/ui/` vers `packages/design-system/src/`
  - Exporter proprement depuis `packages/design-system/`
  - Mettre a jour les imports dans `apps/web/`

- [ ] **TASK-DS-002** : Design tokens
  - Extraire les tokens (couleurs, typo, spacing, shadows, radius) dans le package
  - S'assurer que dark mode et light mode utilisent les memes tokens
  - Ref: ORIGIN_UI_UX_SYSTEM.md §design tokens

- [ ] **TASK-DS-003** : Documentation Storybook
  - Verifier que les stories existantes couvrent les composants principaux
  - Ajouter les stories manquantes pour les composants migres

**Criteres d'acceptation**
- [ ] `packages/design-system/` contient les composants UI de base
- [ ] Design tokens centralises et utilises par toutes les apps
- [ ] Stories a jour pour les composants principaux

**Risques**
- Nombre de composants a migrer potentiellement important
- Risque de casser les imports dans l'app web

---

### v0.13.3 — Polish Securite Avancee

**Priorite** : P3
**Effort** : 3-4 jours
**Prerequisite** : v0.13.0
**GO/NO-GO** : Partiel (`Securite`)

**Taches**

- [ ] **TASK-SECADV-001** : Passkeys/WebAuthn (F022)
  - Implementer l'enregistrement et l'authentification par passkeys
  - Utiliser la Web Authentication API
  - Backend: `backend/internal/auth/webauthn_service.go`
  - Frontend: `apps/web/src/pages/auth/passkeys/`

- [ ] **TASK-SECADV-002** : Password configurable policy (F015)
  - Politique de mot de passe configurable par l'admin
  - Longueur min, complexite, expiration

- [ ] **TASK-SECADV-003** : Geolocalisation connexions (F025)
  - Detection IP → pays via MaxMind GeoIP ou equivalent
  - Notification si connexion depuis un nouveau pays
  - Affichage dans l'historique des sessions

- [ ] **TASK-SECADV-004** : Password expiration (F016) — optionnel
  - Politique d'expiration configurable
  - Notification avant expiration

**Criteres d'acceptation**
- [ ] WebAuthn fonctionnel (enregistrement + login)
- [ ] Geolocalisation des connexions affichee
- [ ] Politique de mot de passe configurable

**Risques**
- WebAuthn complexe a implementer correctement
- GeoIP necessite une base de donnees (licence MaxMind)

---

### v0.13.4 — Polish Audio & Player

**Priorite** : P3
**Effort** : 3-4 jours
**Prerequisite** : v0.13.1
**GO/NO-GO** : —

**Taches**

- [ ] **TASK-APLSH-001** : Picture-in-picture (F121)
  - Implementer le mode picture-in-picture pour le player
  - Utiliser l'API Picture-in-Picture du navigateur

- [ ] **TASK-APLSH-002** : Chromecast support (F124) — optionnel v1.0
  - Integrer le SDK Cast
  - Streaming vers Chromecast

- [ ] **TASK-APLSH-003** : AirPlay support (F125) — optionnel v1.0
  - Streaming vers appareils AirPlay

- [ ] **TASK-APLSH-004** : Spectrogram/Equalizer visualiseurs
  - Visualisation audio temps reel (Web Audio API AnalyserNode)
  - Equalizer graphique basique

**Criteres d'acceptation**
- [ ] Picture-in-picture fonctionne sur les navigateurs supportes
- [ ] Au moins un visualiseur audio basique

**Risques**
- Chromecast/AirPlay dependent des SDKs proprietaires
- Peut etre reporte en v1.1 sans bloquer le GO/NO-GO

---

### v0.13.5 — Polish Marketplace & Compliance

**Priorite** : P3
**Effort** : 3-4 jours
**Prerequisite** : v0.13.0
**GO/NO-GO** : `Business → Flux de paiement teste E2E`

**Taches**

- [ ] **TASK-MKT-001** : KYC vendeurs (F055)
  - Verification d'identite pour les vendeurs marketplace
  - Integration avec un service KYC (Stripe Identity ou equivalent)
  - Fichiers: `backend/internal/service/kyc_service.go`

- [ ] **TASK-MKT-002** : Validation E2E flux de paiement
  - Test complet: creation produit → achat → paiement → download
  - Test avec Hyperswitch en mode test
  - Documenter le flux

- [ ] **TASK-MKT-003** : Validation E2E flux de payout createur
  - Test complet: ventes accumulees → seuil $50 → payout automatique
  - Documenter le flux

- [ ] **TASK-MKT-004** : Page support accessible
  - Page de contact / helpdesk
  - Au minimum: formulaire de contact email
  - Ref: GO/NO-GO `Business → Support accessible`

**Criteres d'acceptation**
- [ ] KYC vendeurs fonctionnel
- [ ] Flux paiement teste E2E
- [ ] Flux payout teste E2E
- [ ] Page support accessible

**Risques**
- KYC necessite un provider externe avec des couts
- Tests E2E paiement necessitent un environnement Hyperswitch fonctionnel

---

### v0.14.0 — Validation Runtime & Staging

**Priorite** : P0-P1
**Effort** : 3-5 jours
**Prerequisite** : v0.13.2
**GO/NO-GO** : `Stabilite`, `Performance`

**Contexte** : De nombreux criteres GO/NO-GO ne peuvent etre valides que sur un environnement live (staging). Cette version est dediee aux validations runtime.

**Taches**

- [ ] **TASK-STAG-001** : Deploiement staging
  - Deployer l'ensemble de la stack sur un environnement staging
  - Verifier que tous les services demarrent correctement
  - Ref: critere non coche v0.9.1

- [ ] **TASK-STAG-002** : Validation performances
  - Executer les tests k6 existants
  - Mesurer: p95 API < 100ms, p99 < 200ms
  - Mesurer: audio stream start < 500ms
  - Mesurer: search results < 500ms

- [ ] **TASK-STAG-003** : Validation Lighthouse
  - Executer Lighthouse sur les pages principales
  - Cibles: Performance >= 85, Accessibility >= 90, PWA >= 90
  - Ref: critere non coche v0.11.0

- [ ] **TASK-STAG-004** : Validation stabilite
  - Monitorer pendant 48h minimum
  - Verifier: taux erreur 5xx < 0.1%
  - Verifier: aucun crash/restart non planifie

- [ ] **TASK-STAG-005** : Validation RGPD
  - Tester export de donnees utilisateur de bout en bout
  - Tester suppression de compte de bout en bout
  - Verifier anonymisation effective

- [ ] **TASK-STAG-006** : Validation bundle size
  - Verifier: bundle JS initial < 200KB gzip
  - Documenter le resultat

**Criteres d'acceptation**
- [ ] Staging deploye et fonctionnel
- [ ] p95 API < 100ms
- [ ] Lighthouse Performance >= 85, Accessibility >= 90
- [ ] Taux erreur 5xx < 0.1% sur 48h
- [ ] RGPD export + suppression fonctionnels
- [ ] Bundle < 200KB gzip

**Risques**
- Infrastructure staging peut ne pas etre disponible
- Les metriques runtime peuvent reveler des problemes non detectes en dev

---

### v1.0.0-rc1 — Release Candidate 1

**Priorite** : —
**Effort** : 2-3 jours
**Prerequisite** : Toutes les versions precedentes
**GO/NO-GO** : Validation finale de tous les criteres

**Taches**

- [ ] **TASK-RC-001** : Checklist GO/NO-GO complete
  - Parcourir chaque critere GO/NO-GO et cocher
  - Documenter les preuves pour chaque critere
  - Fichier: `veza-docs/GO_NO_GO_CHECKLIST.md`

- [ ] **TASK-RC-002** : Audit final anti-dark-patterns
  - Parcours complet de l'UI
  - Verifier: 0 FOMO, 0 gamification, 0 metriques publiques, 0 friction desinscription
  - Documenter le resultat

- [ ] **TASK-RC-003** : Politique de confidentialite
  - Verifier que la politique de confidentialite est a jour
  - Conforme RGPD
  - Ref: GO/NO-GO Ethique

- [ ] **TASK-RC-004** : Documentation decouverte
  - Verifier que le document `DISCOVERY_ALGORITHM.md` est complet et auditable
  - Ref: GO/NO-GO Ethique → Algorithme de decouverte documente

- [ ] **TASK-RC-005** : Freeze du code
  - Branche `release/v1.0.0` creee
  - Seuls les bugfixes critiques acceptes
  - CI/CD verte depuis 2 semaines minimum

- [ ] **TASK-RC-006** : Re-pentest final (optionnel)
  - Si les correctifs pentest sont significatifs, un re-scan peut etre necessaire

**Criteres d'acceptation**
- [ ] 100% des criteres GO/NO-GO coches
- [ ] Branche release creee
- [ ] CI/CD verte

**Risques**
- Des criteres GO/NO-GO peuvent echouer → retour a la version correspondante

---

### v1.0.0 — Release Stable

**Priorite** : —
**Effort** : 1-2 jours
**Prerequisite** : v1.0.0-rc1 validee

**Taches**

- [ ] **TASK-REL-001** : Tag v1.0.0
  - `git tag -a v1.0.0 -m "Version 1.0.0 : Release Stable"`

- [ ] **TASK-REL-002** : Release notes
  - Changelog complet depuis v0.9.1
  - Features highlights
  - Fichier: `CHANGELOG.md`

- [ ] **TASK-REL-003** : Deploiement production
  - Pipeline CI/CD production
  - Validation post-deploiement

**Criteres d'acceptation**
- [ ] Tag v1.0.0 cree
- [ ] Release notes publiees
- [ ] Deploiement production reussi

---

## 4. MAPPING GO/NO-GO ↔ VERSIONS

Chaque critere GO/NO-GO est couvert par au moins une version de cette roadmap.

### Securite

| Critere | Version(s) | Statut actuel |
|---------|-----------|---------------|
| JWT RS256 en production | v0.9.1 (DONE) | ✅ Implemente |
| Aucun secret dans le repo git | v0.9.1 (DONE) | ✅ Implemente |
| Pentest valide (0 CRIT/HIGH ouvert) | v0.12.6.1 (DONE) | ✅ 30/30 findings corriges (0 ouvert) |
| RGPD export + suppression | v0.10.8 (DONE) + **v0.14.0** | ⚠️ Code OK, validation runtime requise |

### Stabilite

| Critere | Version(s) | Statut actuel |
|---------|-----------|---------------|
| Uptime >= 99.9% (30j) | **v0.14.0** | ❌ Non mesure |
| Taux erreur 5xx < 0.1% | **v0.14.0** | ❌ Non mesure |
| Aucun incident P0 non resolu | **v0.14.0** | ⚠️ A verifier |

### Performance

| Critere | Version(s) | Statut actuel |
|---------|-----------|---------------|
| p95 API < 100ms | v0.12.4 (DONE) + **v0.14.0** | ⚠️ Optimise, non mesure runtime |
| Lighthouse Performance >= 85 | v0.12.5 (DONE) + **v0.14.0** | ⚠️ PWA OK, non mesure |
| Lighthouse Accessibility >= 90 | v0.12.5 (DONE) + **v0.14.0** | ⚠️ WCAG AA OK, non mesure |
| Lighthouse PWA >= 90 | v0.12.5 (DONE) + **v0.14.0** | ⚠️ PWA OK, non mesure |

### Qualite

| Critere | Version(s) | Statut actuel |
|---------|-----------|---------------|
| Coverage >= 70% (Go + Rust) | **v0.12.9** | ❌ Non mesuree |
| 0 linting error | v0.9.4 (DONE) + **v0.13.0** | ⚠️ CI lint OK, 43 TODO frontend |
| CI/CD verte 2 semaines | **v1.0.0-rc1** | ❌ A valider |

### Ethique

| Critere | Version(s) | Statut actuel |
|---------|-----------|---------------|
| Audit UX anti-dark-patterns | **v0.12.6.3** + **v1.0.0-rc1** | ⚠️ Code clean, audit formel non fait |
| Aucune donnee comportementale revendue | **v0.12.6.3** | ✅ Pas de code de revente |
| Algorithme decouverte documente | **v0.12.9** | ❌ Non documente |
| Politique confidentialite RGPD | **v1.0.0-rc1** | ❌ A verifier/creer |

### Business

| Critere | Version(s) | Statut actuel |
|---------|-----------|---------------|
| Flux paiement teste E2E | v0.12.0 (DONE) + **v0.13.5** | ⚠️ Code OK, test E2E formel requis |
| Flux payout createur teste | v0.12.0 (DONE) + **v0.13.5** | ⚠️ Code OK, test E2E formel requis |
| Support accessible | **v0.13.5** | ❌ Non implemente |

---

## 5. CRITERES NON COCHES DES VERSIONS DONE — RESOLUTION

Les 10 criteres non coches dans les versions DONE sont resolus par cette roadmap :

| Version DONE | Critere non coche | Resolution |
|--------------|-------------------|------------|
| v0.9.1 | Deploiement staging | **v0.14.0** TASK-STAG-001 |
| v0.9.2 | Pentest partiel | v0.12.6.1 (DONE) — pentest revalide |
| v0.9.5 | Tests pass | Verifier en CI, **v0.12.9** coverage |
| v0.9.8 | Coverage 70% | **v0.12.9** TASK-COV-001 |
| v0.10.0 | Perf metrics staging | **v0.14.0** TASK-STAG-002 |
| v0.10.1 | Test biais emergents | **v0.12.9** TASK-ETH-001 |
| v0.10.2 | Test 0-plays search | **v0.12.9** TASK-ETH-002 |
| v0.11.0 | Lighthouse scores | **v0.14.0** TASK-STAG-003 |
| v0.12.6 | 2 CRIT + 10 HIGH findings | v0.12.6.1 (DONE) — 30/30 corriges |

Tous les 10 criteres sont couverts.

---

## 6. DIAGRAMME GANTT SIMPLIFIE

```
Semaine     S1       S2       S3       S4       S5       S6       S7       S8       S9      S10
           -------- -------- -------- -------- -------- -------- -------- -------- -------- --------

P0 SECURITE
v0.12.6.1  [=====]
v0.12.6.2  [===]

P1 BLOQUANTS
v0.12.6.3     [====]
v0.12.7       [========]
v0.12.8              [========]
v0.12.9              [======]

P2 CONFORMITE
v0.13.0                      [============]
v0.13.1                              [==========]
v0.13.2                              [======]

P3 POLISH
v0.13.3                                      [========]
v0.13.4                                      [========]
v0.13.5                                      [========]

P0-P1 VALIDATION
v0.14.0                                              [==========]

RELEASE
v1.0.0-rc1                                                    [======]
v1.0.0                                                               [====]

JALONS     ^M1                ^M2              ^M3              ^M4          ^M5    ^v1.0
           Secu OK            i18n+API done    Features done    Polish done  RC     RELEASE
```

**Jalons cles** :
- **M1 (fin S2)** : Securite P0 resolue — 0 finding critique/haut, MFA admin, token TTL 7j
- **M2 (fin S4)** : Versions TODO existantes completees (i18n + API docs) + tests ethiques + coverage CI
- **M3 (fin S6)** : Conformite features completee — ecarts spec/code P2 resolus
- **M4 (fin S8)** : Polish termine — securite avancee, audio, marketplace
- **M5 (fin S9)** : Staging valide, metriques runtime OK, RC1 prete
- **v1.0 (fin S10)** : Release stable

---

## 7. CHEMINS CRITIQUES

### Chemin critique principal (bloque v1.0)
```
v0.12.6.1 (pentest) → v0.12.6.2 (MFA/TTL) → v0.12.6.3 (fantomes)
                                                      ↓
v0.12.7 (i18n) ──────────────────────────────→ v0.12.9 (ethique/coverage)
v0.12.8 (API docs) ─────────────────────────→           ↓
                                               v0.13.0 (conformite)
                                                      ↓
                                               v0.13.2 (design system)
                                                      ↓
                                               v0.14.0 (staging/runtime)
                                                      ↓
                                               v1.0.0-rc1 → v1.0.0
```

### Parallelisation possible
```
PARALLELE A (securite)          PARALLELE B (features)
v0.12.6.1                      v0.12.7 (i18n)
v0.12.6.2                      v0.12.8 (API docs)
v0.12.6.3

         \                     /
          → v0.12.9 (ethique) ←
                   ↓
         v0.13.0 (conformite)
              /          \
      v0.13.1 (audio)    v0.13.2 (design)
      v0.13.4 (polish)   v0.13.3 (sec adv)
                          v0.13.5 (marketplace)
              \          /
          → v0.14.0 (staging) ←
                   ↓
             v1.0.0-rc1
                   ↓
              v1.0.0
```

Avec 2 developpeurs, le chemin critique passe de ~10 semaines a ~6-7 semaines grace a la parallelisation des branches securite et features.

---

## 8. FEATURES REPORTEES POST-v1.0

Les features suivantes sont classees P4 et ne bloquent pas la v1.0. Elles seront implementees en v1.1+ :

| Feature | Ref | Effort | Justification report |
|---------|-----|--------|---------------------|
| Chromecast (F124) | Module 4 | 2-3j | SDK proprietaire, complexe |
| AirPlay (F125) | Module 4 | 2-3j | SDK proprietaire, complexe |
| IP whitelisting (F027) | Module 1 | 1j | Feature entreprise, pas consumer |
| Watermarking (F080) | Module 3 | 2j | Nice-to-have, pas bloquant |
| Spectrogram visualiseur | Module 4 | 3j | Cosmetique |
| Equalizer graphique | Module 4 | 2j | Cosmetique |
| Password expiration (F016) | Module 1 | 1j | Optionnel securite |
| Module 9 Gestion Materiel complet | F306-F330 | 5-10j | Scope P3, partiellement implemente |
| Module 17 Collaboration complete | F481-F490 | 5j | Partiellement implemente, avance |

**Total reporte** : ~25-35 jours-dev en v1.1+

---

## 9. ESTIMATION GLOBALE

### Effort par priorite

| Priorite | Versions | Effort total |
|----------|----------|-------------|
| P0 | ~~v0.12.6.1~~ (DONE), v0.12.6.2 | 1.5j restant |
| P1 | v0.12.6.3, v0.12.7, v0.12.8, v0.12.9 | 9.5-13j |
| P2 | v0.13.0, v0.13.1, v0.13.2 | 11-15j |
| P3 | v0.13.3, v0.13.4, v0.13.5 | 9-12j |
| Validation | v0.14.0 | 3-5j |
| Release | v1.0.0-rc1, v1.0.0 | 3-5j |
| **TOTAL** | **15 versions** | **42-59.5j** |

### Scenarios

| Scenario | Equipe | Duree | Date estimee v1.0 |
|----------|--------|-------|--------------------|
| Optimiste | 2 devs | 6 semaines | 2026-04-22 |
| Realiste | 1 dev | 10 semaines | 2026-05-20 |
| Pessimiste | 1 dev + imprevu | 14 semaines | 2026-06-17 |

### Facteurs de risque

| Risque | Impact | Probabilite | Mitigation |
|--------|--------|-------------|------------|
| Findings pentest necessitent refactoring majeur | +2-5j | Moyenne | Identifier tot, isoler les changements |
| Coverage Rust difficile a monter | +2-3j | Haute | Prioriser les tests critiques |
| Infrastructure staging non disponible | +1-2 semaines | Moyenne | Utiliser docker-compose comme staging minimal |
| Traductions ES incompletes | +1-2j | Basse | Accepter placeholders EN pour v1.0 |
| Tests E2E paiement echouent | +2-3j | Moyenne | Tester en mode sandbox Hyperswitch |
| WebAuthn trop complexe pour le calendrier | 0 (report v1.1) | Haute | Declasser en P4 si necessaire |

---

## 10. RECOMMANDATIONS

### Recommandation 1 : Commencer par P0 immediatement
Les 3 findings HIGH du pentest bloquent tout. Il faut les corriger avant toute autre chose. En parallele, un second developpeur peut attaquer v0.12.7 (i18n).

### Recommandation 2 : Ne pas sous-estimer v0.14.0
La validation runtime (staging) est le goulot d'etranglement. Beaucoup de criteres GO/NO-GO ne seront verifiables qu'a ce stade. Preparer l'infrastructure staging le plus tot possible.

### Recommandation 3 : Etre pret a reporter des features P3
Si le calendrier se tend, les features P3 (WebAuthn, Chromecast/AirPlay, spectrogram, KYC) peuvent etre reportees en v1.1 sans affecter la validite du GO/NO-GO.

### Recommandation 4 : Automatiser les validations
Integrer les checks Lighthouse, coverage, et anti-dark-patterns dans la CI pour detecter les regressions automatiquement plutot qu'en validation finale.

### Recommandation 5 : Clarifier le statut des features fantomes
Les modules `contest`, `voting_system`, `production_challenge` doivent etre evalues immediatement. S'ils constituent de la gamification, leur presence est un risque ethique meme s'ils sont desactives.

---

*Fin de la roadmap Phase 5*