veza/docs/ROADMAP_V09XX_TO_V1.md

# ROADMAP v0.9XX → v1.0.0 — Veza

| Champ | Valeur |
|-------|--------|
| **Date** | 2026-02-26 |
| **Auteur** | Claude 4.6 Opus — Architecte senior / Release manager |
| **Version de base** | v0.803 (2026-02-25) |
| **Version cible** | v1.0.0 |
| **Méthodologie** | Basé sur l'audit technique v0.803 et la lecture exhaustive du code source |
| **Classification** | Confidentiel — Usage interne |

---

## Table des matières

1. [Executive Summary](#1-executive-summary)
2. [Timeline Gantt](#2-timeline-gantt)
3. [Phase 0.90X — Corrections sécurité critiques](#3-phase-090x--corrections-sécurité-critiques)
4. [Phase 0.91X — Stabilisation OAuth, auth, paiement](#4-phase-091x--stabilisation-oauth-auth-paiement)
5. [Phase 0.92X — Tests et couverture](#5-phase-092x--tests-et-couverture)
6. [Phase 0.93X — Performance et scalabilité](#6-phase-093x--performance-et-scalabilité)
7. [Phase 0.94X — Consolidation technique](#7-phase-094x--consolidation-technique)
8. [Phase 0.95X — Hardening production](#8-phase-095x--hardening-production)
9. [Phase 0.96X — Documentation et onboarding](#9-phase-096x--documentation-et-onboarding)
10. [Phase 0.97X — Features manquantes pour v1.0](#10-phase-097x--features-manquantes-pour-v10)
11. [Phase 0.98X — Beta et QA](#11-phase-098x--beta-et-qa)
12. [Phase 0.99X — Release candidate](#12-phase-099x--release-candidate)
13. [v1.0.0 — Release commerciale](#13-v100--release-commerciale)
14. [Matrice de dépendances](#14-matrice-de-dépendances)
15. [Checklist v1.0.0 finale](#15-checklist-v100-finale)
16. [Annexe A — Mapping audit → versions](#16-annexe-a--mapping-audit--versions)
17. [Annexe B — Fichiers impactés par version](#17-annexe-b--fichiers-impactés-par-version)
18. [Annexe C — Métriques de suivi](#18-annexe-c--métriques-de-suivi)

---

## 1. Executive Summary

### Vue d'ensemble

| Métrique | Valeur |
|----------|--------|
| **Nombre de sous-versions** | 20 (v0.901 à v0.992) + v1.0.0 |
| **Durée chemin critique** | 57 jours ouvrés (~12 semaines) pour 1 dev senior |
| **Avec buffer 20%** | 69 jours ouvrés (~14 semaines) |
| **Durée séquentielle totale** | 71 jours ouvrés (si aucune parallélisation) |
| **Vulnérabilités à corriger** | 10 (1 critique, 4 élevées, 5 moyennes) |
| **Tests à écrire** | ~80 fichiers de test Rust, ~30 tests d'intégration E2E |
| **Fichiers à refactorer** | ~15 fichiers > 1000 LOC |
| **Migrations à consolider** | 122 → 1 schéma initial |

### Risques majeurs

1. **Rust stream server** — 6 tests pour 109 fichiers. Le passage à > 30% de couverture est l'effort le plus volumineux (~10 jours).
2. **OAuth flow** — Le JWT généré par `OAuthService` est cassé. La correction est simple mais le test E2E requiert des comptes OAuth de test (Google, GitHub).
3. **Hyperswitch E2E** — Le flux de paiement complet nécessite un environnement sandbox Hyperswitch fonctionnel.
4. **Load testing** — L'objectif de 1000 connexions WebSocket simultanées nécessite une infrastructure de test dédiée.
5. **Consolidation migrations** — Squash de 122 migrations en 1 schéma : risque de régression sur les triggers et fonctions. Nécessité de gérer le chemin pour les bases existantes (pas seulement les nouvelles installations).
6. **Migration de données existantes** — Le chiffrement des tokens OAuth (v0.902) nécessite un script de migration one-shot pour les données existantes en clair.

### Structure parallélisable

Après la phase sécurité (v0.903), le graphe de dépendances se divise en **3 tracks parallèles** qui convergent avant la phase Beta. Même avec un seul développeur, cela permet de prioriser dynamiquement et de livrer des incréments indépendants.

```
                    v0.903 (Sécurité complète)
                           │
              ┌────────────┼────────────────┐
              │            │                │
         Track A      Track B          Track C
      (Flux critiques) (Qualité code)  (Ops & Docs)
              │            │                │
          v0.911       v0.921           v0.961
          v0.912       v0.922           v0.962
          v0.923       v0.931           v0.952
              │        v0.941               │
              │        v0.942               │
              │        v0.943               │
              │            │                │
              └────────────┼────────────────┘
                           │
                       v0.951 (Load test — requiert code stabilisé)
                       v0.971 (Features cleanup)
                       v0.981 (Beta)
                       v0.982 (Polish)
                       v0.991 (RC1)
                       v0.992 (RC2)
                       v1.0.0
```

### Priorisation (1 dev, tracks interleaved)

```
Semaines 1-2:   Sécurité (BLOQUANT) — v0.901, v0.902, v0.903
Semaines 3-4:   Auth & Paiement E2E + Monitoring — v0.911, v0.912, v0.952
Semaines 5-6:   Tests Rust + Contrats API — v0.921, v0.923
Semaine 7:      Documentation (Track C, switch contexte) — v0.961, v0.962
Semaines 8-9:   Tests Go + Performance — v0.922, v0.931
Semaines 10-11: Consolidation — v0.941, v0.942
Semaine 12:     Refactoring + Features cleanup — v0.943, v0.971
Semaines 13-14: Hardening + Beta — v0.951, v0.981, v0.982
Semaine 15:     RC + Release — v0.991, v0.992, v1.0.0
```

---

## 2. Timeline Gantt

```mermaid
gantt
    title Roadmap Veza v0.9XX → v1.0.0 (parallélisé)
    dateFormat  YYYY-MM-DD
    axisFormat  %d/%m

    section Sécurité (BLOQUANT)
    v0.901 Ironclad           :s901, 2026-03-02, 2d
    v0.902 Sentinel           :s902, after s901, 3d
    v0.903 Vault              :s903, after s902, 3d

    section Track A — Flux critiques & contrats
    v0.911 Keystone           :s911, after s903, 3d
    v0.912 Cashflow           :s912, after s911, 3d
    v0.923 Contract (API)     :s923, after s912, 3d

    section Track B — Qualité code
    v0.921 Rustproof          :s921, after s903, 5d
    v0.922 Greenlight         :s922, after s921, 5d
    v0.931 Cursor             :s931, after s922, 3d
    v0.941 Cleanup            :s941, after s931, 3d
    v0.942 Compress           :s942, after s941, 6d
    v0.943 Refactor           :s943, after s942, 5d

    section Track C — Ops & Docs
    v0.952 Observe            :s952, after s903, 3d
    v0.961 Playbook           :s961, after s952, 3d
    v0.962 Onboard            :s962, after s961, 2d

    section Convergence
    v0.951 Loadtest           :s951, after s943, 4d
    v0.971 Phantom            :s971, after s951, 2d
    v0.981 Beta               :s981, after s971, 4d
    v0.982 Polish             :s982, after s981, 3d

    section RC
    v0.991 RC1                :s991, after s982, 3d
    v0.992 RC2                :s992, after s991, 2d

    section Release
    v1.0.0 Launch             :milestone, after s992, 1d
```

> **Note sur le parallélisme pour 1 dev** : Avec un seul développeur, les tracks A/B/C sont interleaved (pas réellement parallèles). Le Gantt ci-dessus représente les **dépendances techniques réelles** — pas un planning calendaire. Le développeur peut switcher entre les tracks à chaque version. Avec 2 devs, Track A+C et Track B sont réellement parallèles, réduisant le chemin critique de ~4 semaines.

> **Note sur la numérotation** : v0.923 (Contract) est numérotée 0.92X (phase Tests) mais vit dans Track A car elle dépend de v0.912 (les flux E2E doivent être testés avant de valider les contrats API). La numérotation reflète le *domaine* (92X = tests), pas le *track*. En cas d'ambiguïté, se référer à la matrice de dépendances (section 14), pas au numéro de version.

---

## 3. Phase 0.90X — Corrections sécurité critiques

> **BLOQUANT — Aucune version ultérieure ne peut exister sans la complétion de cette phase.**

---

### v0.901 — "Ironclad"

| Champ | Valeur |
|-------|--------|
| **Durée** | 2 jours ouvrés |
| **Objectif** | Corriger les vulnérabilités CRITIQUE et ÉLEVÉES qui cassent des flux ou exposent des données. |
| **Dépendances** | v0.803 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Corriger `OAuthService.generateJWT`** : remplacer la génération JWT manuelle par un appel à `JWTService.GenerateAccessToken()` + `JWTService.GenerateRefreshToken()`. Créer une session complète via `SessionService.CreateSession()`. Retourner les tokens dans des cookies httpOnly identiques au flow login. | `internal/services/oauth_service.go:585-593`, `internal/services/oauth_service.go:295-316` | OAuth callback retourne des tokens validables par le middleware auth. Test unitaire du flow OAuth callback avec tokens vérifiés par `ValidateToken()`. | M |
| 2 | **Supprimer `PasswordService.GenerateJWT`** : cette méthode morte génère des JWT sans issuer/audience/token_version. Supprimer la méthode et ses tests associés. Vérifier qu'aucun code de production ne l'appelle (vérifié : aucun appel hors tests). | `internal/services/password_service.go:259-267`, `internal/services/password_service_integration_test.go:333-356` | La méthode n'existe plus. `grep -r "GenerateJWT" --include="*.go"` ne retourne que des résultats dans `jwt_service.go`. | S |
| 3 | **Rendre la vérification webhook Hyperswitch obligatoire** : dans `routes_webhooks.go`, supprimer le chemin de code qui skip la vérification quand le secret est vide. Retourner une erreur 500 si le secret n'est pas configuré. Laisser un log error pour le diagnostic. | `internal/core/marketplace/routes_webhooks.go:65-73` | Le handler webhook retourne 500 si `HyperswitchWebhookSecret` est vide, quel que soit l'environnement. Test unitaire avec secret vide → 500. | S |
| 4 | **Connecter `TokenBlacklist` au middleware auth** : dans `authenticate()`, après la validation JWT et avant la validation de session, appeler `TokenBlacklist.IsBlacklisted(tokenString)`. Si blacklisté, retourner 401. | `internal/middleware/auth.go:191-201`, `internal/services/token_blacklist.go` | `TokenBlacklist.IsBlacklisted()` est appelé dans le flow d'authentification. Test unitaire : un token blacklisté retourne 401 même si le JWT est techniquement valide. | S |
| 5 | **Ajouter `ValidateExecPath` dans `waveform_service.go`** : appeler `utils.ValidateExecPath(inputPath)` avant chaque `exec.CommandContext` dans `generateWaveform()` et `generateFallbackWaveform()`. | `internal/services/waveform_service.go:72,82,127` | Chaque appel à `exec.CommandContext` est précédé d'un appel à `ValidateExecPath`. Test unitaire avec un path contenant `..` → erreur avant exec. | S |

#### Critères de release

- [ ] Tous les tests Go passent (`go test ./... -count=1`)
- [ ] Les 5 vulnérabilités CRITIQUE/ÉLEVÉES #1, #2, #3, #6, #7 de l'audit sont corrigées
- [ ] Aucun chemin de code ne permet de bypasser la vérification webhook
- [ ] OAuth callback produit des tokens valides (test unitaire)
- [ ] `grep -r "GenerateJWT" --include="*.go"` dans `password_service.go` ne retourne rien

#### Risques

| Risque | Probabilité | Mitigation |
|--------|------------|------------|
| Régression sur le flow login classique | Faible | Le flow login n'est pas touché. Seul OAuth est modifié. |
| `TokenBlacklist.IsBlacklisted()` ajoute de la latence | Faible | Appel Redis simple (GET). P99 < 1ms. Timeout déjà configuré. |

---

### v0.902 — "Sentinel"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Corriger les vulnérabilités ÉLEVÉES restantes (PKCE, chiffrement tokens OAuth) et les vulnérabilités MOYENNES. |
| **Dépendances** | v0.901 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Implémenter PKCE dans le flux OAuth** : ajouter la génération de `code_verifier` (128 bytes random, base64url) et `code_challenge` (SHA-256 du verifier, base64url). Stocker le verifier dans la DB (colonne `code_verifier` sur `oauth_states`) ou en Redis. Envoyer le `code_challenge` avec `code_challenge_method=S256` dans l'URL d'autorisation. Inclure le `code_verifier` dans l'échange de code. | `internal/services/oauth_service.go:160-180` (authorize URL), `internal/services/oauth_service.go:200-250` (callback), migration pour `oauth_states.code_verifier` si stockage DB | OAuth authorization URL contient `code_challenge` et `code_challenge_method=S256`. Callback inclut `code_verifier` dans l'échange de token. Test unitaire du flow complet PKCE. | L |
| 2 | **Chiffrer les tokens OAuth providers au repos** : créer un service `CryptoService` utilisant AES-256-GCM avec une clé dérivée d'une env var `OAUTH_ENCRYPTION_KEY`. Chiffrer `access_token` et `refresh_token` avant insertion dans `federated_identities`. Déchiffrer à la lecture. Ajouter une migration pour modifier le type de colonne si nécessaire (les tokens chiffrés sont plus longs). | `internal/services/oauth_service.go:567-579`, nouveau `internal/services/crypto_service.go`, migration pour allonger les colonnes token si nécessaire | Les tokens stockés en DB sont chiffrés (vérifiable via requête SQL directe). Le service OAuth les déchiffre correctement à la lecture. `OAUTH_ENCRYPTION_KEY` est requise en production. Test unitaire encrypt/decrypt roundtrip. | M |
| 3 | **Valider l'URL de redirection OAuth** : dans `OAuthService.HandleCallback`, vérifier que l'URL de redirection stockée dans le state correspond à une liste blanche de domaines autorisés (configurée via `OAUTH_ALLOWED_REDIRECT_DOMAINS`). Rejeter les redirections vers des domaines non autorisés. | `internal/services/oauth_service.go:200-250`, `internal/config/config.go` | L'URL de redirection est validée contre une whitelist. Test unitaire : redirection vers `evil.com` → erreur 400. | S |
| 4 | **Sécuriser le `CHAT_JWT_SECRET`** : forcer un secret séparé en production. Dans `ValidateForEnvironment()`, ajouter une validation qui rejette le démarrage si `CHAT_JWT_SECRET == JWT_SECRET` en production. Documenter dans `.env.example`. | `internal/config/config.go:293`, `internal/config/config.go:ValidateForEnvironment()` | En production, `CHAT_JWT_SECRET` doit être différent de `JWT_SECRET`. Le serveur refuse de démarrer si identiques. `.env.example` documenté. | S |

#### Critères de release

- [ ] Tous les tests Go passent
- [ ] PKCE fonctionnel (code_challenge dans l'URL OAuth, code_verifier dans l'échange)
- [ ] Tokens OAuth providers chiffrés en DB
- [ ] Redirection OAuth validée contre whitelist
- [ ] `CHAT_JWT_SECRET` forcé séparé en production
- [ ] Vulnérabilités audit #3, #4, #9, #10 corrigées

#### Risques

| Risque | Probabilité | Mitigation |
|--------|------------|------------|
| Certains providers OAuth ne supportent pas PKCE | Faible | Google et GitHub supportent PKCE. Discord et Spotify aussi. Vérifier la doc de chaque provider. |
| Migration de chiffrement des tokens existants | Moyen | Tâche 5 ci-dessous. |

> **Tâche 5 — Data migration (non listée dans le tableau principal)** :
>
> **Script de migration one-shot pour les tokens OAuth existants** : écrire un outil CLI `cmd/tools/encrypt_oauth_tokens/main.go` qui lit tous les `federated_identities` avec des tokens en clair, les chiffre avec `CryptoService` (AES-256-GCM), et met à jour les lignes. Le script doit être idempotent (ne pas re-chiffrer un token déjà chiffré — détecter via un préfixe ou un flag). Inclure un mode dry-run. **Effort : M (4h-2j). DoD** : le script tourne sans erreur sur un dump staging. Tous les tokens sont chiffrés. Le service OAuth lit les tokens correctement après migration.

---

### v0.903 — "Vault"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Corriger les vulnérabilités MOYENNES restantes et nettoyer les faux positifs de sécurité. |
| **Dépendances** | v0.902 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Renforcer les ORDER BY dynamiques** : dans `core/track/service.go:611` et tout autre service utilisant `fmt.Sprintf` pour ORDER BY, ajouter une whitelist explicite de champs autorisés et un fallback à `created_at DESC`. Vérifier `playback_filter_service.go` (déjà mitigé) et `user_service_search.go` (déjà mitigé — confirmer). | `internal/core/track/service.go:~600-620`, vérifier tous les `fmt.Sprintf.*ORDER` | Chaque ORDER BY dynamique a une whitelist. `go vet ./...` passe. Test unitaire avec un sortBy invalide → fallback. | M |
| 2 | **Inclure login/register dans le rate limiter global** : supprimer `/api/v1/auth/register` et `/api/v1/auth/login` de `excludedRateLimitPaths`. Les endpoint-specific rate limiters s'appliqueront en plus du global. | `internal/middleware/ratelimit.go:49-50` | Login et register sont soumis au rate limiter global (100 req/min par IP) ET aux rate limiters endpoint-spécifiques. Test : envoyer 101 requêtes en 1 minute → la 101ème est rejetée. | S |
| 3 | **Synchroniser le VERSION file** : mettre à jour `VERSION` à la racine pour refléter la version taguée. Ajouter un check dans le Makefile ou CI qui vérifie `VERSION == git describe --tags`. | `VERSION`, `Makefile` ou `.github/workflows/ci.yml` | `cat VERSION` retourne `0.903`. CI vérifie la correspondance VERSION/tag. | S |
| 4 | **Nettoyer les références au chat-server Rust** : supprimer les mentions de `veza-chat-server` dans `.cursorrules`, les docs qui le référencent encore, et vérifier qu'aucun script/Makefile ne tente de le compiler. | `.cursorrules`, `docs/*`, `make/*.mk`, `scripts/*` | `grep -r "veza-chat-server" .` ne retourne aucun résultat hors historique git et CHANGELOG. | S |
| 5 | **Harmoniser Go version** : aligner tous les Dockerfiles, workflows CI et `go.mod` sur Go 1.24. | `veza-backend-api/Dockerfile` (1.23 → 1.24), `.github/workflows/*.yml`, `loadtests/Makefile` | `grep -r "golang:1.23" .` ne retourne aucun résultat. Tous les builds utilisent Go 1.24. | S |
| 6 | **Éliminer les 21 TODO/FIXME/HACK** : résoudre chaque marqueur ou le convertir en issue GitHub avec un lien. Les TODO informatifs (documentation du travail futur) sont acceptables s'ils sont convertis en issues. | Distribués (voir audit : 20 TODO, 1 HACK) | `grep -rn "TODO\|FIXME\|HACK" --include="*.go" --include="*.ts" --include="*.tsx" --include="*.rs" src/ internal/` retourne 0 résultats (hors commentaires de documentation acceptés). | M |

#### Critères de release

- [ ] Tous les tests passent (Go, Frontend, Rust)
- [ ] Zéro TODO/FIXME/HACK dans le code source (hors informatifs convertis en issues)
- [ ] VERSION file = tag git
- [ ] Go 1.24 partout
- [ ] Aucune référence à veza-chat-server
- [ ] Toutes les vulnérabilités de l'audit (10/10) sont adressées

#### Risques

| Risque | Probabilité | Mitigation |
|--------|------------|------------|
| Certains TODO sont légitimes (work futur) | Moyen | Les convertir en issues GitHub plutôt que les supprimer. |
| Changement de Go version casse des tests | Faible | Go 1.23 → 1.24 est mineur. Vérifier avec `go test`. |

---

## 4. Phase 0.91X — Stabilisation OAuth, auth, paiement

---

### v0.911 — "Keystone"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Valider le flux OAuth end-to-end (Google, GitHub) et le flux auth complet avec tests d'intégration. |
| **Dépendances** | v0.903 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Tests d'intégration OAuth Google** : écrire un test d'intégration qui simule le flow complet : redirect → callback avec code mock → JWT valide → session créée → cookies httpOnly settés. Utiliser un mock du provider OAuth (pas d'appel réseau réel). | `tests/integration/oauth_google_test.go` (nouveau) | Le test passe avec `go test -run TestOAuthGoogleFlow -v`. Le JWT retourné est validable par `JWTService.ValidateToken()`. La session existe en DB. | L |
| 2 | **Tests d'intégration OAuth GitHub** : même test pour GitHub. Vérifier que le PKCE est correctement transmis. | `tests/integration/oauth_github_test.go` (nouveau) | Le test passe. PKCE vérifié (code_challenge dans l'URL, code_verifier dans l'échange). | L |
| 3 | **Test E2E token refresh via cookies** : écrire un test qui vérifie que le refresh flow fonctionne via cookies httpOnly : accès avec token expiré → auto-refresh → nouveau token dans cookie → requête réussie. | `tests/integration/token_refresh_test.go` (nouveau) | Le flow refresh fonctionne end-to-end. Le cookie httpOnly est correctement mis à jour. | M |
| 4 | **Test E2E logout + token blacklist** : vérifier que après logout, le token est blacklisté et les requêtes avec l'ancien token sont rejetées (401). | `tests/integration/logout_blacklist_test.go` (nouveau) | Après logout, l'ancien access token retourne 401. Le refresh token est invalidé. | M |

#### Critères de release

- [ ] 4 tests d'intégration auth passent
- [ ] OAuth Google : flow complet fonctionnel (mock provider)
- [ ] OAuth GitHub : flow complet fonctionnel (mock provider)
- [ ] Token refresh via cookies fonctionnel
- [ ] Logout + blacklist fonctionnel

---

### v0.912 — "Cashflow"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Valider le flux de paiement Hyperswitch end-to-end avec tests d'intégration. |
| **Dépendances** | v0.911 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Test E2E payment flow** : écrire un test d'intégration qui simule : création panier → ajout produit → checkout → webhook payment_succeeded → order status updated → licence créée → seller transfer initié. Utiliser un mock Hyperswitch (pas de sandbox réel). | `tests/integration/payment_flow_test.go` (nouveau) | Le test couvre le happy path complet. L'order passe en status "completed". La licence est créée. Le transfer seller est initié. | L |
| 2 | **Test webhook replay protection** : vérifier que le même webhook envoyé 3 fois ne crée pas 3 orders. Tester l'idempotence du handler webhook. | `tests/integration/webhook_idempotency_test.go` (nouveau) | 3 appels identiques au webhook → 1 seul order créé. Pas de duplication. | M |
| 3 | **Test webhook signature rejection** : vérifier qu'un webhook avec une signature invalide est rejeté (401). Vérifier qu'un webhook sans signature est rejeté (500 depuis v0.901). | `tests/integration/webhook_security_test.go` (nouveau) | Signature invalide → 401. Secret vide → 500. Signature valide → 200. | S |
| 4 | **Test refund flow** : simuler un remboursement : order completed → refund request → webhook refund → order status "refunded" → licence révoquée. | `tests/integration/refund_flow_test.go` (nouveau) | Le remboursement met à jour le status de l'order. La licence est révoquée. Le transfer seller est annulé/ajusté. | M |

#### Critères de release

- [ ] 4 tests d'intégration paiement passent
- [ ] Happy path paiement vérifié E2E
- [ ] Idempotence webhook vérifiée
- [ ] Signature webhook vérifiée
- [ ] Flow refund vérifié

---

## 5. Phase 0.92X — Tests et couverture

---

### v0.921 — "Rustproof"

| Champ | Valeur |
|-------|--------|
| **Durée** | 5 jours ouvrés |
| **Objectif** | Augmenter la couverture du Rust stream server de 6 fichiers à > 30%. |
| **Dépendances** | v0.912 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Tests auth module** : tester `AuthManager` (JWT validation, token extraction, role checking), `TokenValidator` (signature validation, expiration, track access). | `src/auth/mod.rs`, `src/auth/token_validator.rs` — nouveaux fichiers tests | 15+ tests unitaires. Couverture auth > 60%. | L |
| 2 | **Tests streaming/websocket** : tester le `WebSocketManager` (connection tracking, message routing, broadcast, cleanup). Mocker les connections WebSocket. | `src/streaming/websocket.rs` — nouveaux tests | 10+ tests unitaires. Couverture websocket > 40%. | L |
| 3 | **Tests error handling** : tester toutes les variantes de `AppError`, les conversions `From`, les réponses HTTP. | `src/error.rs` — nouveaux tests | Chaque variante d'erreur a un test. Couverture error > 80%. | M |
| 4 | **Tests middleware** : tester rate limiter, CORS, logging middleware. | `src/middleware/` — nouveaux tests | 8+ tests unitaires. | M |
| 5 | **Tests config/database** : tester le chargement de configuration et la création du pool de connexions. | `src/config/mod.rs`, `src/database/pool.rs` — nouveaux tests | 5+ tests unitaires. Config invalide → erreur explicite. | S |

#### Critères de release

- [ ] `cargo test` passe sans erreur
- [ ] > 40 nouveaux tests Rust
- [ ] Couverture Rust > 30% (vérifiable avec `cargo tarpaulin`)
- [ ] Aucun `unwrap()` ajouté dans le code de production

#### Risques

| Risque | Probabilité | Mitigation |
|--------|------------|------------|
| Tests WebSocket difficiles à mocker | Moyen | Utiliser `tokio::test` avec des canaux mpsc pour simuler les connexions. |
| SQLx runtime queries empêchent les tests sans DB | Élevé | Utiliser un trait d'abstraction pour le repository ou `sqlx::test` avec un conteneur. |

---

### v0.922 — "Greenlight"

| Champ | Valeur |
|-------|--------|
| **Durée** | 5 jours ouvrés |
| **Objectif** | Réduire les tests Go conditionnellement skippés, augmenter la couverture effective, et atteindre les seuils par package critique. |
| **Dépendances** | v0.921 (Track B) |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Trier les 134 skips Go** : catégoriser chaque `t.Skip` en "légitime" (requiert infra réelle) ou "convertible" (peut être testé avec un mock). Convertir les tests convertibles en tests unitaires avec mocks. Objectif : réduire de 134 à < 50 skips. | Tous les `*_test.go` avec `t.Skip` | < 50 `t.Skip` restants (ceux nécessitant une vraie DB/Redis/S3). Les tests convertis passent sans infra. | XL |
| 2 | **Ajouter des tests pour les handlers non testés** : identifier les handlers sans fichier `_test.go` correspondant et ajouter des tests unitaires pour les cas critiques (happy path + 1 erreur). | `internal/handlers/*.go` sans `*_test.go` correspondant | Chaque handler a au moins 1 test. | L |
| 3 | **Corriger les 12 skips frontend E2E** : examiner les `test.skip` dans les tests Playwright. Corriger ceux qui sont des bugs (pas des limitations d'infra). Garder uniquement les skips pour les tests nécessitant 2FA ou un WebSocket réel. | `apps/web/e2e/*.spec.ts` | < 5 `test.skip` restants. Les tests deskippés passent. | M |

#### Critères de release

- [ ] < 50 `t.Skip` dans le code Go
- [ ] < 5 `test.skip` dans le code frontend E2E
- [ ] Tous les tests passent (`go test ./... -count=1`, `npm test -- --run`)
- [ ] Couverture Go : auth middleware > 80%, core/auth + core/marketplace > 70%, handlers > 50%, global > 55%

---

### v0.923 — "Contract"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Mettre en place des tests de contrat API pour garantir la cohérence frontend/backend. |
| **Dépendances** | v0.922 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Générer l'OpenAPI spec depuis le code** : utiliser les annotations Swagger existantes dans `docs/docs.go` pour générer un `openapi.yaml` propre. Ajouter une commande `make openapi` qui régénère la spec. | `veza-backend-api/docs/`, `Makefile` | `make openapi` produit un `openapi.yaml` valide (vérifiable avec `swagger-cli validate`). | M |
| 2 | **Valider les types TypeScript générés** : vérifier que `apps/web/src/types/generated/api.ts` correspond à l'OpenAPI spec. Ajouter un check CI qui régénère et compare. | `apps/web/src/types/generated/api.ts`, `.github/workflows/ci.yml` | CI échoue si les types TS sont désynchronisés de la spec OpenAPI. | M |
| 3 | **Tests de contrat pour les 10 endpoints critiques** : écrire des tests qui valident la structure des réponses API contre la spec OpenAPI pour : login, register, get tracks, get user, create track, search, create order, get notifications, get conversations, get analytics. | `tests/contract/` (nouveau) | 10 tests de contrat passent. La structure des réponses match la spec. | L |

#### Critères de release

- [x] `openapi.yaml` généré et validé
- [x] Types TS synchronisés avec la spec
- [x] 10 tests de contrat passent
- [x] CI check ajouté

---

## 6. Phase 0.93X — Performance

> **Note** : Redis HA (Sentinel) et PostgreSQL replication sont **reportés à v1.1**. Pour un lancement avec quelques centaines d'utilisateurs, un Redis single instance avec backups réguliers et un PostgreSQL avec WAL archiving suffisent. La HA n'est pas sur le chemin critique de v1.0.

---

### v0.931 — "Cursor"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Implémenter la pagination cursor-based sur les listings à volume et profiler les endpoints critiques. |
| **Dépendances** | v0.922 (Track B) |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Pagination cursor-based pour les tracks** : remplacer la pagination OFFSET sur `GET /tracks` par une pagination par curseur (keyset pagination sur `created_at` + `id`). Maintenir la rétro-compatibilité (accepter `page`/`limit` comme fallback OFFSET). | `internal/core/track/service.go`, `internal/core/track/handler.go` | `GET /tracks?cursor=xxx&limit=20` fonctionne. Le curseur est opaque (base64 encoded). Performances constantes quelle que soit la page. Test avec 10K tracks : page 500 aussi rapide que page 1. | L |
| 2 | **Pagination cursor-based pour les messages** : remplacer OFFSET sur `GET /conversations/:id/history` par cursor-based. Les messages sont naturellement ordonnés par timestamp. | `internal/services/chat_service.go`, `internal/handlers/chat_handler.go` | Pagination par curseur sur les messages. | M |
| 3 | **Pagination cursor-based pour le feed social** : remplacer OFFSET sur `GET /social/feed` par cursor-based. | `internal/services/social_service.go` | Feed paginé par curseur. | M |
| 4 | **Profiling des 5 endpoints les plus lents** : utiliser `pprof` en dev pour identifier les endpoints avec la latence la plus élevée. Documenter les résultats et les goulots d'étranglement. | `docs/PERFORMANCE_BASELINE.md` (nouveau) | Document avec les P50/P95/P99 des 10 endpoints principaux. Goulots identifiés. | S |

#### Critères de release

- [ ] 3 listings convertis en cursor-based pagination
- [ ] Performance baseline documentée
- [ ] Aucune régression sur les tests existants
- [ ] Rétro-compatibilité OFFSET maintenue

#### Risques

| Risque | Probabilité | Mitigation |
|--------|------------|------------|
| Cursor pagination change le contrat API pour les consommateurs existants | Moyen | Maintenir `page`/`limit` comme fallback. Documenter la migration dans les release notes. |
| Performance profiling révèle un problème structurel | Faible | Les indexes manquants sont adressés en v0.951. Les problèmes architecturaux sont documentés pour v1.1. |

> **Reporté à v1.1** : Redis Sentinel, PostgreSQL streaming replication, read-replica routing. Documenté dans `docs/V1_LIMITATIONS.md`. Pour v1.0, le comportement dégradé Redis est vérifié et documenté en v0.961 (runbook incident response) : in-memory rate limiting fallback, CSRF → 503, sessions invalidées → re-login nécessaire.

---

## 7. Phase 0.94X — Consolidation technique

---

### v0.941 — "Cleanup"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Supprimer le code mort, dédupliquer les migrations, nettoyer la structure. |
| **Dépendances** | v0.931 (Track B) |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Dédupliquer le dossier `migrations/`** : le dossier `migrations/` à la racine est un doublon de `veza-backend-api/migrations/`. Supprimer le dossier racine et s'assurer que tous les scripts pointent vers `veza-backend-api/migrations/`. | `migrations/` (racine), `Makefile`, `scripts/` | `ls migrations/` à la racine → n'existe pas. Tous les outils de migration pointent vers `veza-backend-api/migrations/`. | S |
| 2 | **Supprimer le code mort identifié** : supprimer les routes deprecated (`/internal/tracks/:id/stream-ready`, `/internal/stream-events`). Nettoyer les imports orphelins. | `internal/api/routes_core.go` (routes deprecated) | Les routes deprecated n'existent plus. `go build ./...` compile sans warning. | S |
| 3 | **Supprimer le code gamification archivé** : le dossier `internal/api/archive/` contient du code gamification mort. Supprimer ce dossier. | `internal/api/archive/` | Le dossier n'existe plus. `go build` passe. | S |
| 4 | **Nettoyer `packages/design-system`** : marqué comme "sous-utilisé" dans FEATURE_STATUS.md. Si seul le CSS est importé, documenter ou supprimer le package. | `packages/design-system/` | Le package est soit documenté (raison de garder) soit supprimé. | S |
| 5 | **Supprimer les fichiers Swagger générés du repo** : `docs/docs.go` (5482 lignes) devrait être généré par CI, pas versionné. Ajouter à `.gitignore` et générer dans le build. | `veza-backend-api/docs/docs.go`, `.gitignore` | `docs.go` dans `.gitignore`. CI le régénère. Le build fonctionne sans le fichier versionné. | M |

#### Critères de release

- [ ] Pas de dossier `migrations/` à la racine
- [ ] Pas de routes deprecated
- [ ] Pas de code gamification archivé
- [ ] Code mort réduit de ~3700 LOC à < 500 LOC
- [ ] `go build`, `cargo build`, `npm run build` passent

---

### v0.942 — "Compress"

| Champ | Valeur |
|-------|--------|
| **Durée** | 6 jours ouvrés |
| **Objectif** | Consolider les 122 migrations SQL en un schéma propre. Gérer le chemin pour les bases existantes ET les nouvelles installations. |
| **Dépendances** | v0.941 |

> **Attention** : cette version est la plus risquée du roadmap. Les triggers, fonctions PostgreSQL, et indexes composites doivent tous être préservés. Prévoir du temps de validation supplémentaire.

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Générer le schéma complet actuel** : exécuter `pg_dump --schema-only` sur une DB après toutes les migrations. Vérifier manuellement que le schéma est complet : tables, colonnes, types, indexes, constraints, triggers, functions, extensions (`pg_trgm`, `uuid-ossp`), views. | `veza-backend-api/migrations/000_full_schema.sql` (nouveau) | Le fichier contient le schéma complet vérifié. Appliquer ce fichier sur une DB vide produit exactement le même schéma que les 122 migrations. | L |
| 2 | **Archiver les anciennes migrations** : déplacer les 122 fichiers de migration dans `migrations/archive/v0_to_v0803/`. Garder uniquement `000_full_schema.sql` comme point de départ pour les nouvelles installations. | `veza-backend-api/migrations/archive/v0_to_v0803/` (nouveau) | Les anciennes migrations sont archivées avec un README expliquant pourquoi. Les nouvelles migrations partent de 001. | S |
| 3 | **Chemin pour bases existantes** : ajouter un fichier `000_mark_consolidated.sql` qui insère une entrée dans la table de tracking des migrations indiquant que le schéma consolidé a été appliqué. Les bases existantes (qui ont déjà les 122 migrations) doivent simplement exécuter ce fichier de marquage sans modifier le schéma. Documenter la procédure dans `docs/MIGRATION_CONSOLIDATION.md`. | `veza-backend-api/migrations/000_mark_consolidated.sql`, `docs/MIGRATION_CONSOLIDATION.md` (nouveau) | Une base existante peut être marquée comme consolidée sans perte de données. Les nouvelles migrations s'appliquent correctement sur les deux chemins (nouveau + existant). | M |
| 4 | **Mettre à jour l'outil de migration** : ajouter une détection dans `cmd/migrate_tool` : si la DB est vide → appliquer `000_full_schema.sql` ; si la DB existe avec les anciennes migrations → appliquer le marqueur ; si la DB est consolidée → appliquer les migrations incrémentales. | `cmd/migrate_tool/`, `internal/database/database.go` | Les 3 chemins fonctionnent sans intervention manuelle. | L |
| 5 | **Test de parité de schéma** : écrire un test d'intégration (avec testcontainers) qui compare le schéma produit par `000_full_schema.sql` avec celui des 122 migrations appliquées séquentiellement. Comparer : table names, column names/types/nullable, indexes, constraints, triggers, functions. | `tests/migration_parity_test.go` (nouveau) | Le test passe. Les deux chemins produisent un schéma identique (diff vide). | L |

#### Critères de release

- [ ] `000_full_schema.sql` produit un schéma identique aux 122 migrations (test de parité)
- [ ] Anciennes migrations archivées avec README
- [ ] Chemin existant DB documenté et testé (marqueur sans modification schéma)
- [ ] Outil de migration gère les 3 chemins (nouveau, existant, consolidé)
- [ ] Test de migration passe
- [ ] Un nouveau développeur peut setup sa DB en < 30 secondes

#### Risques

| Risque | Probabilité | Mitigation |
|--------|------------|------------|
| Triggers/fonctions manquants dans le schéma consolidé | Élevé | Comparaison automatique avec test de parité. Vérification manuelle des migrations 900-935 qui contiennent les triggers. |
| Bases existantes en staging/prod refusent le marqueur | Moyen | Tester sur un dump de la DB staging avant d'appliquer en prod. Procédure de rollback documentée. |
| GORM AutoMigrate interfère avec le schéma consolidé | Faible | Désactiver AutoMigrate. Utiliser uniquement les fichiers SQL. |

---

### v0.943 — "Refactor"

| Champ | Valeur |
|-------|--------|
| **Durée** | 5 jours ouvrés |
| **Objectif** | Refactorer les fichiers volumineux (> 1000 lignes) en sous-composants. Pas de changement de comportement — uniquement de la structure. |
| **Dépendances** | v0.942 |

> **Principe** : chaque split est un commit atomique. On split un fichier, on vérifie que tous les tests passent, on commit, on passe au suivant. Pas de méga-refactoring transversal.

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Split `core/track/service.go`** (1291 lignes) : extraire la logique de recherche dans `track_search_service.go`, la logique de versioning dans `track_version_service.go`, la logique batch dans `track_batch_service.go`. Attention aux injections GORM et aux dépendances inter-méthodes. | `internal/core/track/service.go` → 3-4 fichiers | Chaque fichier < 500 lignes. Tous les tests passent. L'API publique du service (struct + méthodes exportées) reste identique. Les callers ne changent pas. | L |
| 2 | **Split `core/marketplace/service.go`** (1142 lignes) : extraire orders, reviews, licences en sous-services. | `internal/core/marketplace/service.go` → 3-4 fichiers | Chaque fichier < 500 lignes. Tests passent. | L |
| 3 | **Split `handlers/playlist_handler.go`** (1137 lignes) : extraire collaborators, share, export en sous-handlers. | `internal/handlers/playlist_handler.go` → 3-4 fichiers | Chaque fichier < 400 lignes. Tests passent. | M |
| 4 | **Split `core/auth/service.go`** (1019 lignes) : extraire OAuth, 2FA, password reset en sous-services si pas déjà fait par v0.902 (le travail PKCE a pu restructurer partiellement). | `internal/core/auth/service.go` → 3-4 fichiers | Chaque fichier < 400 lignes. Tests passent. | M |
| 5 | **Refactorer les fichiers Rust > 800 lignes** : split `core/sync.rs` (1183 LOC) et `streaming/websocket.rs` (996 LOC). | `veza-stream-server/src/core/sync.rs`, `src/streaming/websocket.rs` | Chaque fichier < 500 lignes. `cargo test` passe. | M |

#### Critères de release

- [ ] Aucun fichier Go de production > 800 lignes (hors `config.go` qui est acceptable)
- [ ] Aucun fichier Rust > 800 lignes
- [ ] Tous les tests passent sans modification
- [ ] API publique des services inchangée

---

## 8. Phase 0.95X — Hardening production

### Contingency plan — Que faire si Track B dérape ?

Track B (qualité code) contient les versions les plus risquées (v0.942 squash migrations, v0.943 refactoring). Si elle prend du retard, voici les décisions pré-documentées :

| Scénario | Décision | Impact |
|----------|---------|--------|
| **v0.942 dérape de ≤ 3j** | Absorber le retard. Décaler v0.943 et v0.951. Pas d'impact sur la qualité du release. | +3j sur la timeline totale |
| **v0.942 dérape de > 3j** | **Réduire le scope** : archiver les migrations sans le test de parité automatique (vérification manuelle à la place). Le test sera ajouté en v1.0.1. | Risque résiduel faible — le schéma est validé manuellement |
| **v0.943 dérape** | **Reporter le refactoring Rust** (tâche 5) à v1.0.1. Garder uniquement les splits Go. Les fichiers Rust > 800 LOC sont un inconfort, pas un blocage. | -1j sur v0.943, risque Rust acceptable |
| **Track B entière bloquée** | **Lancer la beta (v0.981) sans v0.942/v0.943**. La beta teste les flux utilisateurs, pas la structure interne du code. Le squash et le refactoring sont reportés en v1.0.1 hotfix. Les critères v1.0 "migrations consolidées" et "fichiers < 800 LOC" passent en **conditionnel**. | v1.0 sort avec la dette, correctif en v1.0.1 sous 2 semaines |

---

### v0.951 — "Loadtest"

| Champ | Valeur |
|-------|--------|
| **Durée** | 4 jours ouvrés |
| **Objectif** | Exécuter des tests de charge et valider les seuils de performance v1.0. |
| **Dépendances** | v0.943 (Track B) + v0.923 (Track A) + v0.952 (Track C) — point de convergence |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Script de load test API** : utiliser k6 ou Go custom pour tester 500 req/s sur les endpoints critiques (login, get tracks, search, create order). Mesurer P50/P95/P99. | `loadtests/api_load_test.js` ou `.go` | P99 < 500ms sur tous les endpoints critiques à 500 req/s. Rapport généré. | L |
| 2 | **Test 1000 WebSocket simultanées** : écrire un script qui ouvre 1000 connexions WebSocket et envoie des messages. Vérifier que le serveur reste stable et que les messages sont délivrés. | `loadtests/websocket_load_test.go` | 1000 connexions simultanées stables pendant 5 minutes. Taux de livraison des messages > 99%. Mémoire du serveur reste sous 2GB. | L |
| 3 | **Test upload concurrent** : tester 50 uploads simultanés. Vérifier que le sémaphore de backpressure fonctionne et que les uploads ne corrompent pas les fichiers. | `loadtests/upload_load_test.go` | 50 uploads simultanés terminent avec succès. Le 51ème est queue-ed (pas rejeté). | M |
| 4 | **Benchmark PostgreSQL** : exécuter `EXPLAIN ANALYZE` sur les 10 requêtes les plus fréquentes. Identifier les missing indexes. Ajouter les indexes manquants. | `veza-backend-api/migrations/001_performance_indexes.sql` (nouvelle migration) | Aucune requête fréquente ne fait un sequential scan sur une table > 10K rows. | M |

#### Critères de release

- [ ] P99 < 500ms à 500 req/s
- [ ] 1000 WebSocket stables
- [ ] 50 uploads concurrents réussis
- [ ] Aucun sequential scan sur les requêtes fréquentes
- [ ] Rapport de performance documenté

---

### v0.952 — "Observe"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Compléter le monitoring, l'alerting, et le dashboard Grafana pour la production. |
| **Dépendances** | v0.903 (Track C — peut commencer dès la fin de la phase sécurité, en parallèle des tracks A/B) |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Dashboard Grafana v1.0** : créer un dashboard unifié avec : requêtes/s, latence P50/P95/P99, taux d'erreur, connexions WebSocket actives, queue RabbitMQ, Redis latency, PostgreSQL connections, disk usage, CPU/memory. | `config/grafana/dashboards/v1-overview.json` | Dashboard fonctionnel avec toutes les métriques. Captures d'écran dans la doc. | L |
| 2 | **Alertes Prometheus v1.0** : configurer les alertes pour : API down > 1 min, error rate > 5%, P99 > 1s, Redis unreachable, PostgreSQL connections > 80%, disk > 90%, WebSocket connections > 5000. | `config/prometheus/alert_rules_v1.yml` | Alertes configurées et testables. Notifications Slack/email. | M |
| 3 | **Request ID propagation** : vérifier que le `X-Request-ID` est propagé du frontend au backend, au stream server, et dans les logs. Ajouter le request ID dans les logs structurés si absent. | `internal/middleware/request_id.go`, `internal/middleware/request_logger.go` | `X-Request-ID` présent dans chaque log entry. Corrélation possible entre services. | S |
| 4 | **Health check complet** : vérifier que `GET /health/deep` couvre DB, Redis, S3, RabbitMQ, disk. Ajouter les checks manquants. | `internal/handlers/health.go` | `/health/deep` retourne le status de chaque dépendance. Configurable en K8s readiness probe. | S |

#### Critères de release

- [ ] Dashboard Grafana fonctionnel avec toutes les métriques
- [ ] Alertes Prometheus configurées et testées
- [ ] Request ID propagé dans tous les logs
- [ ] Health check couvre toutes les dépendances

---

## 9. Phase 0.96X — Documentation et onboarding

---

### v0.961 — "Playbook"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Produire la documentation opérationnelle pour le déploiement, le rollback, et la réponse aux incidents. Inclure le comportement dégradé Redis (graceful degradation). |
| **Dépendances** | v0.952 (Track C — les runbooks référencent les dashboards et alertes configurés en v0.952) |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Runbook de déploiement** : documenter la procédure complète de déploiement (build, push images, migrate DB, deploy, verify health, rollback si échec). Inclure les commandes exactes pour blue-green et rolling update. | `docs/runbooks/DEPLOYMENT.md` (nouveau) | Un opérateur peut déployer en suivant le document sans aide externe. Testé sur staging. | L |
| 2 | **Runbook de rollback** : documenter la procédure de rollback (DB migration rollback, image rollback, traffic switch). Inclure les scénarios de rollback partiel (backend seul, frontend seul). | `docs/runbooks/ROLLBACK.md` (nouveau) | Procédure testée sur staging. Temps de rollback < 5 minutes. | M |
| 3 | **Playbook incident response** : documenter les procédures pour les incidents courants (API down, Redis down, DB down, payment webhook failed, DDoS, data breach). Inclure l'arbre de décision et les contacts. | `docs/runbooks/INCIDENT_RESPONSE.md` (nouveau) | Chaque scénario a une procédure. Temps moyen de diagnostic < 10 minutes. | M |
| 4 | **Documentation rotation des secrets** : documenter la procédure de rotation pour JWT_SECRET, CHAT_JWT_SECRET, OAUTH_ENCRYPTION_KEY, HYPERSWITCH_WEBHOOK_SECRET, database passwords. | `docs/runbooks/SECRET_ROTATION.md` (nouveau) | Chaque secret a une procédure de rotation avec zéro downtime. | S |
| 5 | **Graceful degradation Redis** : vérifier et documenter le comportement quand Redis est down (in-memory rate limiting fallback, CSRF → 503, sessions invalidées → re-login, cache miss → DB directe). Tester manuellement en coupant Redis sur un env de dev. | `docs/runbooks/GRACEFUL_DEGRADATION.md` (nouveau) | Document listant le comportement de chaque composant quand Redis est down, avec les actions opérationnelles correspondantes. | S |

#### Critères de release

- [ ] 5 runbooks/docs opérationnels produits
- [ ] Procédure de déploiement testée sur staging
- [ ] Procédure de rollback testée sur staging
- [ ] Rotation des secrets documentée
- [ ] Comportement dégradé Redis vérifié et documenté

---

### v0.962 — "Onboard"

| Champ | Valeur |
|-------|--------|
| **Durée** | 2 jours ouvrés |
| **Objectif** | Finaliser la documentation API, le guide d'onboarding développeur, et les guides de contribution. |
| **Dépendances** | v0.961 (Track C) |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **API documentation finale** : mettre à jour `docs/API_REFERENCE.md` avec tous les endpoints v1.0. Valider contre l'OpenAPI spec générée en v0.923. | `docs/API_REFERENCE.md` | Chaque endpoint public est documenté avec : méthode, path, params, body, response, erreurs, exemple curl. | L |
| 2 | **Guide onboarding v1.0** : mettre à jour `docs/ONBOARDING.md` avec les instructions pour : cloner, installer les dépendances, démarrer les services, lancer les tests, structure du code. Temps cible : < 30 minutes du clone au premier test passant. | `docs/ONBOARDING.md` | Un nouveau développeur peut setup le projet et lancer les tests en < 30 minutes en suivant le guide. | M |
| 3 | **Architecture Decision Records à jour** : s'assurer que les ADRs reflètent les décisions actuelles (chat Rust → Go, PKCE, Redis Sentinel, etc.). | `docs/adr/` | ADRs à jour. Chaque décision architecturale majeure a un ADR. | S |

#### Critères de release

- [ ] API Reference complète et validée
- [ ] Onboarding testable en < 30 minutes
- [ ] ADRs à jour

---

## 10. Phase 0.97X — Nettoyage features et honnêteté produit

---

### v0.971 — "Phantom"

| Champ | Valeur |
|-------|--------|
| **Durée** | 2 jours ouvrés |
| **Objectif** | Supprimer les features fantômes, mettre à jour la documentation produit, et être explicite sur ce que v1.0 fait et ne fait pas. |
| **Dépendances** | v0.951 (convergence) |

> **Décision architecturale : WebRTC TURN/STUN est reporté à v1.1.**
>
> La signalisation WebRTC (CallOffer, CallAnswer, ICECandidate, CallHangup, CallReject) est implémentée et fonctionne en LAN ou avec un NAT simple. Pour fonctionner derrière un NAT symétrique (la majorité des cas en production), il faut un serveur TURN. Configurer Coturn, intégrer les credentials éphémères, tester cross-réseau, et écrire un E2E Playwright pour l'audio — c'est réalistement 5-8 jours de travail, pas 3. Et les appels audio ne sont pas un flux critique pour le lancement commercial de Veza (qui est une plateforme de streaming et de marketplace, pas un outil de communication).
>
> **Pour v1.0** : les appels WebRTC restent derrière un feature flag (`WEBRTC_CALLS`), activé par défaut, avec un avertissement UX "Beta — fonctionne mieux sur le même réseau". Le flag et la signalisation existante restent en place. TURN/STUN arrive en v1.1 avec un test de charge dédié.

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Supprimer les MSW handlers Gamification** : les handlers MSW pour gamification (achievements, leaderboard) donnent l'illusion d'une feature qui n'existe pas côté backend. Supprimer les handlers et tout UI résiduel qui les consomme. | `apps/web/src/mocks/handlers-*.ts`, composants gamification éventuels | Aucun handler MSW pour gamification. Le frontend n'affiche plus de sections gamification. `npm run build` passe. | S |
| 2 | **Ajouter feature flag WebRTC avec avertissement** : s'assurer que les appels audio sont derrière `WEBRTC_CALLS` (feature flag DB). Ajouter un badge "Beta" sur le bouton d'appel. Ajouter un tooltip "Fonctionne mieux sur le même réseau local". | `apps/web/src/features/chat/`, `internal/services/feature_flag_service.go` | Le flag existe en DB. L'UI affiche "Beta". La feature est désactivable par l'admin. | S |
| 3 | **Documenter les limitations v1.0** : créer un document exhaustif listant ce qui n'est PAS dans v1.0 avec la version cible pour chaque élément. | `docs/V1_LIMITATIONS.md` (nouveau) | Document couvrant : WebRTC TURN/STUN (v1.1), 2FA SMS (v1.1), Passkeys (v1.2), Live streaming RTMP réel (v1.2), Gamification (v1.3), Studio (abandonné), Education (abandonné), Mobile app (abandonné), Redis HA (v1.1), PG replication (v1.1). | S |
| 4 | **Définir la politique de versioning API** : documenter que `/api/v1/` est le contrat stable de v1.0. Lister les routes beta (si applicable). Documenter les breaking changes entre v0.803 et v1.0 (si les signatures de réponse ont changé avec cursor pagination, etc.). | `docs/API_VERSIONING_POLICY.md` (nouveau) | Le document définit : routes stables vs beta, politique de dépréciation, headers de version, engagement de rétro-compatibilité pour v1.x. | M |
| 5 | **Mettre à jour FEATURE_STATUS.md et PROJECT_STATE.md** : refléter l'état final v1.0. Supprimer les sections obsolètes. WebRTC listé comme "Beta — LAN only". | `docs/FEATURE_STATUS.md`, `docs/PROJECT_STATE.md` | Les documents reflètent exactement l'état du code v1.0. Score maturité mis à jour. Pas de feature fantôme listée comme opérationnelle. | S |

#### Critères de release

- [ ] Aucune feature fantôme dans le code ou la documentation
- [ ] Limitations v1.0 documentées avec versions cibles
- [ ] Politique de versioning API documentée
- [ ] WebRTC flaggé "Beta" avec avertissement UX
- [ ] FEATURE_STATUS.md et PROJECT_STATE.md à jour

---

## 11. Phase 0.98X — Beta et QA

---

### v0.981 — "Beta"

| Champ | Valeur |
|-------|--------|
| **Durée** | 4 jours ouvrés |
| **Objectif** | Déployer en staging, exécuter un bug bash complet, et vérifier tous les flux critiques end-to-end. |
| **Dépendances** | v0.971 (convergence complète) |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Déploiement staging complet** : déployer tous les services (backend, stream server, frontend, PostgreSQL, Redis, RabbitMQ, MinIO) sur l'environnement staging. Vérifier que tous les health checks passent. | Infrastructure staging | Tous les services up. `GET /health/deep` retourne OK. Frontend accessible. | M |
| 2 | **Bug bash — flux auth** : tester manuellement : register, login, 2FA setup/verify/disable, OAuth Google, OAuth GitHub, logout, token refresh, session list/revoke, password reset, account deletion. | Staging | Chaque flux fonctionne sans erreur. Captures d'écran archivées. | L |
| 3 | **Bug bash — flux commerce** : tester manuellement : browse marketplace, add to cart, apply promo code, checkout (sandbox Hyperswitch), order confirmation, download, review, refund, seller dashboard, transfers. | Staging | Flux paiement complet fonctionnel en sandbox. | L |
| 4 | **Bug bash — flux média** : tester : upload track, transcode HLS, playback, queue, playlist create/share/collab, search, analytics, cloud upload/version/share. | Staging | Upload → transcode → playback fonctionne. Cloud storage fonctionne. | L |
| 5 | **Bug bash — flux social** : tester : create post, like, comment, follow, block, group create/join/leave, notifications, chat messages. Vérifier que les appels WebRTC affichent bien le badge "Beta" et fonctionnent en LAN. | Staging | Social feed et chat fonctionnent. WebRTC fonctionne en LAN avec badge Beta visible. | M |

#### Critères de release

- [ ] Staging déployé et stable
- [ ] Tous les flux critiques testés manuellement
- [ ] Bugs trouvés documentés et priorisés
- [ ] Aucun bug bloquant ouvert

---

### v0.982 — "Polish"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Corriger les bugs trouvés pendant le beta, polish UX, et vérifier l'accessibilité et les performances Lighthouse. |
| **Dépendances** | v0.981 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Corriger les bugs P1/P2** du bug bash. | Variable | Tous les bugs P1 (bloquants) corrigés. Bugs P2 (importants) corrigés ou documentés. | L |
| 2 | **Audit Lighthouse** : exécuter Lighthouse sur les pages principales (login, dashboard, tracks, marketplace, search, profile). Objectif > 90 sur Performance, Accessibility, Best Practices. | Frontend pages | Score Lighthouse > 90 sur Performance et Accessibility pour les pages principales. | M |
| 3 | **Vérifier PWA offline** : tester le mode dégradé offline (service worker). Les pages visitées doivent être accessibles hors ligne. Le player doit maintenir le playback. | `apps/web/public/sw.js` | PWA fonctionne en mode offline dégradé. L'utilisateur voit un message approprié pour les fonctionnalités non disponibles. | S |
| 4 | **Vérifier RGPD/CCPA** : tester `POST /users/me/export` (export données), `DELETE /users/me` (suppression compte), `POST /users/me/privacy/opt-out` (CCPA). Vérifier que les données sont réellement supprimées/anonymisées. | Staging | Export produit un ZIP complet. Suppression anonymise les données et supprime les fichiers S3. Opt-out est enregistré. | M |

#### Critères de release

- [ ] Zéro bug P1 ouvert
- [ ] Lighthouse > 90 Performance et Accessibility
- [ ] PWA mode dégradé fonctionnel
- [ ] RGPD/CCPA vérifié

---

## 12. Phase 0.99X — Release candidate

---

### v0.991 — "RC1"

| Champ | Valeur |
|-------|--------|
| **Durée** | 3 jours ouvrés |
| **Objectif** | Produire la première release candidate avec tous les critères v1.0 vérifiés. Code freeze. |
| **Dépendances** | v0.982 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Exécuter la checklist v1.0 complète** : vérifier chaque critère de la checklist v1.0 (section 15). Documenter le résultat GO/NO-GO pour chaque critère. | `docs/V1_SIGNOFF.md` (nouveau) | Chaque critère a un statut (PASS/FAIL) avec preuve (commande exécutée, screenshot, lien vers test). | L |
| 2 | **Scan de sécurité final** : exécuter `npm audit`, `cargo audit`, `govulncheck`, Trivy sur les images Docker. Corriger toute vulnérabilité CRITICAL. | CI/CD, images Docker | Zéro vulnérabilité CRITICAL. Les ÉLEVÉES sont documentées avec justification (false positive ou accepted risk). | M |
| 3 | **Code freeze** : créer la branche `release/v1.0.0` à partir de `main`. Seuls les bugfix sont autorisés sur cette branche. | Git | Branche `release/v1.0.0` créée. Tag `v0.991-rc1`. | S |
| 4 | **Régénérer toutes les assets** : OpenAPI spec, types TS, docs Swagger, CHANGELOG, VERSION file (0.991). | Multiple | Tous les artefacts générés sont à jour et cohérents. | S |
| 5 | **Docker images production** : builder les images production finales. Scanner avec Trivy. Signer avec cosign. | Dockerfiles, CI | Images taguées `v0.991-rc1`. Scannées. Signées. | M |

#### Critères de release

- [ ] Checklist v1.0 : tous les critères PASS
- [ ] Scan sécurité : zéro CRITICAL
- [ ] Code freeze effectif
- [ ] Images Docker production prêtes

---

### v0.992 — "RC2"

| Champ | Valeur |
|-------|--------|
| **Durée** | 2 jours ouvrés |
| **Objectif** | Corriger les derniers bugs RC1, re-test, sign-off final. |
| **Dépendances** | v0.991 |

#### Tâches

| # | Description | Fichier(s) | DoD | Effort |
|---|------------|-----------|-----|--------|
| 1 | **Corriger les bugs RC1** : corriger tout bug trouvé pendant la validation RC1. Cherry-pick sur `release/v1.0.0`. | Variable | Zéro bug ouvert. | M |
| 2 | **Re-test des corrections** : vérifier que les corrections n'introduisent pas de régression. Relancer la suite de tests complète. | CI | Tous les tests passent. Aucune régression. | M |
| 3 | **Sign-off final** : mettre à jour `docs/V1_SIGNOFF.md` avec le statut final. Obtenir le GO formel. | `docs/V1_SIGNOFF.md` | Tous les critères PASS. Document signé (date, auteur). | S |
| 4 | **Préparer les release notes** : rédiger les release notes v1.0.0 avec : nouvelles features depuis v0.803, corrections de sécurité, améliorations, breaking changes, migration guide. | `RELEASE_NOTES_V1.md` (nouveau) | Release notes complètes et relues. | S |

#### Critères de release

- [ ] Zéro bug ouvert
- [ ] Sign-off documenté
- [ ] Release notes prêtes
- [ ] Tag `v0.992-rc2`

---

## 13. v1.0.0 — Release commerciale

| Champ | Valeur |
|-------|--------|
| **Durée** | 1 jour ouvré |
| **Objectif** | Taguer v1.0.0, déployer en production, annoncer. |
| **Dépendances** | v0.992 |

#### Tâches

| # | Description | DoD | Effort |
|---|------------|-----|--------|
| 1 | **Mettre à jour VERSION** : `1.0.0` | `cat VERSION` → `1.0.0` | S |
| 2 | **Tag git v1.0.0** | `git tag v1.0.0` sur `release/v1.0.0` | S |
| 3 | **Build et push images production** | Images taguées `v1.0.0` dans le registry | S |
| 4 | **Déployer en production** | Services up, health checks OK | M |
| 5 | **Vérification post-déploiement** | Smoke test sur les 5 flux critiques (auth, upload, playback, payment, chat) | M |
| 6 | **Merger `release/v1.0.0` dans `main`** | `main` = v1.0.0 | S |
| 7 | **Publier les release notes** | CHANGELOG.md mis à jour, GitHub release créée | S |

---

## 14. Matrice de dépendances

### Graphe de dépendances techniques réelles

| Version | Dépend de | Track | Commentaire |
|---------|-----------|-------|-------------|
| **v0.901** Ironclad | v0.803 | Sécurité | BLOQUANT pour tout |
| **v0.902** Sentinel | v0.901 | Sécurité | |
| **v0.903** Vault | v0.902 | Sécurité | Point de divergence des tracks |
| | | | |
| **v0.911** Keystone | v0.903 | Track A | OAuth/Auth E2E |
| **v0.912** Cashflow | v0.911 | Track A | Payment E2E |
| **v0.923** Contract | v0.912 | Track A | Contrats API (requiert les flux testés) |
| | | | |
| **v0.921** Rustproof | v0.903 | Track B | Indépendant des tracks A et C |
| **v0.922** Greenlight | v0.921 | Track B | |
| **v0.931** Cursor | v0.922 | Track B | Pagination (requiert les tests en place) |
| **v0.941** Cleanup | v0.931 | Track B | |
| **v0.942** Compress | v0.941 | Track B | |
| **v0.943** Refactor | v0.942 | Track B | |
| | | | |
| **v0.952** Observe | v0.903 | Track C | Monitoring en premier — pas de dépendance sur les docs |
| **v0.961** Playbook | v0.952 | Track C | Runbooks référencent les dashboards/alertes de v0.952 |
| **v0.962** Onboard | v0.961 | Track C | |
| | | | |
| **v0.951** Loadtest | v0.943 + v0.923 + v0.952 | Convergence | Requiert code stabilisé (Track B) + contrats (Track A) + monitoring (Track C) |
| **v0.971** Phantom | v0.951 | Convergence | Features cleanup |
| **v0.981** Beta | v0.971 | Convergence | |
| **v0.982** Polish | v0.981 | Convergence | |
| **v0.991** RC1 | v0.982 | RC | |
| **v0.992** RC2 | v0.991 | RC | |
| **v1.0.0** Launch | v0.992 | Release | |

### Chaîne critique (chemin le plus long)

```
v0.901 → v0.902 → v0.903 → v0.921 → v0.922 → v0.931 → v0.941 → v0.942 → v0.943 → v0.951 → v0.971 → v0.981 → v0.982 → v0.991 → v0.992 → v1.0.0
```

**Durée chemin critique** : 2 + 3 + 3 + 5 + 5 + 3 + 3 + 6 + 5 + 4 + 2 + 4 + 3 + 3 + 2 + 1 = **54 jours** (+ 20% buffer = **65 jours ≈ 13 semaines**).

### Ce qui est parallélisable (même pour 1 dev, en interleaving)

| En parallèle de Track B | On peut faire | Gain |
|--------------------------|--------------|------|
| v0.921 (Rust tests, 5j) | v0.911 (OAuth E2E, 3j) | 3j gagnés |
| v0.922 (Go tests, 5j) | v0.912 (Payment E2E, 3j) | 3j gagnés |
| v0.941-943 (Consolidation, 14j) | v0.961-962 + v0.952 (Docs + Monitoring, 8j) | 8j gagnés |

**Gain total possible** : ~14 jours, ramenant la durée à **~51 jours (≈ 10 semaines)** pour 1 dev avec interleaving agressif.

---

## 15. Checklist v1.0.0 finale

| # | Critère | Version cible | Vérification |
|---|---------|--------------|-------------|
| 1 | Zéro vulnérabilité CRITIQUE ou ÉLEVÉE | v0.903 | `govulncheck`, `cargo audit`, `npm audit`, audit manuel |
| 2 | Flux OAuth fonctionnel E2E (Google, GitHub) | v0.911 | Test d'intégration OAuth |
| 3 | Flux paiement Hyperswitch vérifié E2E | v0.912 | Test d'intégration paiement |
| 4 | Couverture tests Go — **par package critique** | v0.922 | Voir seuils par package ci-dessous |
| 5 | Couverture tests Frontend > 50% global | v0.922 | `vitest --coverage` |
| 6 | Couverture tests Rust > 30% global | v0.921 | `cargo tarpaulin` |
| 7 | Tous les tests passent sans skip conditionnel (hors infra) | v0.922 | `go test -short ./...` avec < 50 skips |

**Seuils de couverture Go par package critique** (v0.922) :

| Package | Seuil minimum | Justification |
|---------|--------------|---------------|
| `internal/middleware/auth*` | > 80% | Flux d'authentification, surface d'attaque #1 |
| `internal/services/jwt_service*` | > 80% | Tokens, revocation, validation |
| `internal/services/password_service*` | > 80% | Hashing, reset, validation |
| `internal/core/auth/*` | > 70% | OAuth, 2FA, sessions |
| `internal/core/marketplace/*` | > 70% | Paiement, orders, transfers |
| `internal/handlers/*` | > 50% | Happy path + 1 error case minimum par handler |
| `internal/services/*` | > 50% | Logique métier |
| Global `./...` | > 55% | Moyenne pondérée acceptable |

La mesure globale "60% Go" est remplacée par ces seuils granulaires. Un package auth à 20% et un package utils à 100% ne donnent pas confiance — les packages critiques doivent être couverts en priorité.

| # | Critère | Version cible | Vérification |
|---|---------|--------------|-------------|
| 8 | Load test : 1000 WebSocket simultanées | v0.951 | Script de test + rapport |
| 9 | Load test : 500 req/s API | v0.951 | k6 ou Go benchmark + rapport |
| 10 | P99 < 500ms endpoints critiques | v0.951 | Prometheus metrics ou rapport load test |
| 11 | Zéro TODO/FIXME dans le code | v0.903 | `grep` automatisé |
| 12 | Documentation API complète (OpenAPI validée) | v0.962 | `swagger-cli validate` |
| 13 | Runbook opérationnel (déploiement, rollback, incident) | v0.961 | Fichiers dans `docs/runbooks/` |
| 14 | Dashboard Grafana fonctionnel avec alertes | v0.952 | Screenshot + test d'alerte |
| 15 | Migrations consolidées | v0.942 | `000_full_schema.sql` + test migration |
| 16 | VERSION file synchronisé | v0.903 | `cat VERSION` == `git describe --tags` |
| 17 | Docker images sans vulnérabilité CRITICAL | v0.991 | Trivy scan |
| 18 | Secrets : rotation documentée, aucun en dur | v0.961 | Runbook + `grep` |
| 19 | RGPD/CCPA : export, suppression, opt-out | v0.982 | Test manuel sur staging |
| 20 | Accessibilité : Lighthouse > 90 | v0.982 | Lighthouse audit |
| 21 | PWA : mode dégradé offline | v0.982 | Test manuel |

---

## 16. Annexe A — Mapping audit → versions

| Audit Finding | ID Audit | Sévérité | Version cible |
|--------------|----------|---------|--------------|
| OAuth `generateJWT` invalide | VEZA-SEC-001 | CRITIQUE | **v0.901** |
| `PasswordService.GenerateJWT` sans contrôles | VEZA-SEC-002 | ÉLEVÉ | **v0.901** |
| Pas de PKCE OAuth | VEZA-SEC-003 | ÉLEVÉ | **v0.902** |
| Tokens OAuth providers en clair en DB | VEZA-SEC-004 | ÉLEVÉ | **v0.902** |
| Webhook Hyperswitch vérification optionnelle | VEZA-SEC-005 | ÉLEVÉ | **v0.901** |
| TokenBlacklist déconnecté du middleware | VEZA-SEC-006 | MOYEN | **v0.901** |
| `waveform_service.go` sans ValidateExecPath | VEZA-SEC-007 | MOYEN | **v0.901** |
| Dynamic ORDER BY avec fmt.Sprintf | VEZA-SEC-008 | MOYEN | **v0.903** |
| Login/register exclus du rate limiter global | VEZA-SEC-009 | MOYEN | **v0.903** |
| CHAT_JWT_SECRET fallback JWT_SECRET | VEZA-SEC-010 | FAIBLE | **v0.902** |
| Rust stream server sous-testé (6/109 fichiers) | Audit-DEBT-01 | STRUCTURANT | **v0.921** |
| OFFSET pagination | Audit-DEBT-02 | OPÉRATIONNEL | **v0.931** |
| Redis SPOF | Audit-DEBT-03 | STRUCTURANT | **v1.1** (reporté — documenté dans V1_LIMITATIONS.md) |
| PostgreSQL SPOF | Audit-DEBT-04 | STRUCTURANT | **v1.1** (reporté — documenté dans V1_LIMITATIONS.md) |
| 122 migrations non consolidées | Audit-DEBT-05 | OPÉRATIONNEL | **v0.942** |
| Migrations dupliquées racine/backend | Audit-DEBT-06 | COSMÉTIQUE | **v0.941** |
| Chat-server Rust fantôme dans docs | Audit-DEBT-07 | COSMÉTIQUE | **v0.903** |
| Go version inconsistante | Audit-DEBT-08 | COSMÉTIQUE | **v0.903** |
| 10 fichiers Go > 1000 lignes | Audit-DEBT-09 | OPÉRATIONNEL | **v0.943** |
| VERSION file désynchronisé | Audit-DEBT-10 | COSMÉTIQUE | **v0.903** |
| OAuth redirect URL non validée | Audit-SEC-011 | FAIBLE | **v0.902** |
| WebRTC sans TURN/STUN | Audit-FEAT-01 | FONCTIONNEL | **v1.1** (reporté — feature-flagged "Beta" en v1.0) |
| Gamification MSW-only (fantôme) | Audit-FEAT-02 | COSMÉTIQUE | **v0.971** |
| Tokens OAuth existants en clair (migration data) | Audit-DATA-01 | ÉLEVÉ | **v0.902** (script one-shot) |
| Bases existantes après squash migrations | Audit-DATA-02 | MOYEN | **v0.942** (chemin marqueur) |
| Politique versioning API non documentée | Audit-DOC-01 | OPÉRATIONNEL | **v0.971** |

---

## 17. Annexe B — Fichiers impactés par version

| Version | Fichiers principaux |
|---------|-------------------|
| **v0.901** | `oauth_service.go`, `password_service.go`, `routes_webhooks.go`, `auth.go`, `token_blacklist.go`, `waveform_service.go` |
| **v0.902** | `oauth_service.go`, `crypto_service.go` (nouveau), `config.go`, migration OAuth |
| **v0.903** | `core/track/service.go`, `ratelimit.go`, `VERSION`, `.cursorrules`, Dockerfiles, `*.go` (TODOs) |
| **v0.911** | `tests/integration/oauth_*_test.go` (nouveaux), `tests/integration/token_*_test.go` (nouveaux) |
| **v0.912** | `tests/integration/payment_*_test.go` (nouveaux), `tests/integration/webhook_*_test.go` (nouveaux) |
| **v0.921** | `veza-stream-server/src/auth/`, `src/streaming/`, `src/error.rs`, `src/middleware/`, `src/config/` |
| **v0.922** | Tous les `*_test.go` avec `t.Skip`, `apps/web/e2e/*.spec.ts` |
| **v0.923** | `openapi.yaml` (nouveau), `apps/web/src/types/generated/api.ts`, `tests/contract/` (nouveau) |
| **v0.931** | `core/track/service.go`, `chat_service.go`, `social_service.go` |
| **v0.941** | `migrations/` (racine), `internal/api/archive/`, `internal/api/routes_core.go` |
| **v0.942** | `veza-backend-api/migrations/`, `cmd/migrate_tool/` |
| **v0.943** | `core/track/service.go`, `core/marketplace/service.go`, `handlers/playlist_handler.go`, `core/auth/service.go`, Rust `sync.rs`, `websocket.rs` |
| **v0.951** | `loadtests/` |
| **v0.952** | `config/grafana/`, `config/prometheus/`, `internal/middleware/request_id.go` |
| **v0.961** | `docs/runbooks/` (nouveaux) |
| **v0.962** | `docs/API_REFERENCE.md`, `docs/ONBOARDING.md`, `docs/adr/` |
| **v0.971** | `apps/web/src/mocks/handlers-*.ts`, `docs/FEATURE_STATUS.md`, `docs/PROJECT_STATE.md`, `docs/V1_LIMITATIONS.md` (nouveau), `docs/API_VERSIONING_POLICY.md` (nouveau) |
| **v0.981** | Infrastructure staging |
| **v0.982** | Variable (bugs), frontend pages (Lighthouse) |
| **v0.991** | `docs/V1_SIGNOFF.md`, `VERSION`, release branch |
| **v0.992** | Variable (fixes RC1), `RELEASE_NOTES_V1.md` |
| **v1.0.0** | `VERSION`, `CHANGELOG.md`, Docker images |

---

## 18. Annexe C — Métriques de suivi

Mesurer à chaque release :

| KPI | Cible v1.0 | Comment mesurer |
|-----|-----------|----------------|
| Vulnérabilités CRITIQUE/ÉLEVÉ ouvertes | 0 | `govulncheck` + `cargo audit` + `npm audit` + audit manuel |
| Couverture tests Go (global) | > 55% | `go test -cover ./...` |
| Couverture tests Go (auth/middleware) | > 80% | `go test -cover ./internal/middleware/...` |
| Couverture tests Go (core/auth, core/marketplace) | > 70% | `go test -cover ./internal/core/...` |
| Couverture tests Frontend | > 50% | `vitest --coverage` |
| Couverture tests Rust | > 30% | `cargo tarpaulin` |
| Tests skippés Go | < 50 | `grep -r "t.Skip" --include="*_test.go" \| wc -l` |
| Tests skippés Frontend | < 5 | `grep -r "test.skip" --include="*.spec.ts" \| wc -l` |
| TODO/FIXME/HACK | 0 | `grep -rn` automatisé |
| Fichiers > 800 LOC (hors générés) | < 10 | `wc -l` sur les fichiers source |
| P99 latence API (endpoints critiques) | < 500ms | Prometheus / load test |
| WebSocket connexions simultanées max | > 1000 | Load test |
| Score Lighthouse Performance | > 90 | Lighthouse CI |
| Score Lighthouse Accessibility | > 90 | Lighthouse CI |
| Temps onboarding nouveau dev | < 30 min | Test manuel |
| Temps de déploiement | < 15 min | Chrono |
| Temps de rollback | < 5 min | Chrono |
| Docker image size (backend) | < 100MB | `docker images` |
| Docker image size (frontend) | < 50MB | `docker images` |
| Docker vulnerabilities CRITICAL | 0 | Trivy |

---

---

### Éléments reportés à v1.1 (hors scope v1.0)

| Élément | Raison du report | Effort estimé v1.1 |
|---------|-----------------|---------------------|
| Redis Sentinel / HA | Pas nécessaire pour quelques centaines d'utilisateurs. Single instance + backup suffit. | L (5j) |
| PostgreSQL streaming replication | Idem. WAL archiving suffit pour v1.0. | L (5j) |
| WebRTC TURN/STUN production | Les appels fonctionnent en LAN. TURN/STUN nécessite 5-8j réalistes. | XL (8j) |
| 2FA SMS (Twilio) | Requiert un provider SMS payant. TOTP couvre le besoin v1.0. | M (3j) |
| Passkeys / WebAuthn | Complexité d'implémentation. Login classique + OAuth couvrent le besoin. | L (5j) |
| Live streaming RTMP réel | Requiert un serveur RTMP (Nginx-RTMP ou similar). Go Live est documenté mais pas de vrai streaming. | XL (10j) |

---

*Fin du document. Ce roadmap a été conçu pour être la référence unique du chemin vers v1.0.0. Chaque version est autonome, testable, et incrémentale.*

*Effort total : **71 jours ouvrés** (séquentiel) / **54 jours chemin critique** (avec parallélisation tracks A/B/C). Avec buffer 20% : **65 jours ≈ 13 semaines** sur le chemin critique. 20 sous-versions + v1.0.0.*

*Les estimations sont conservatrices : v0.942 (migrations squash) est budgété à 6 jours, v0.943 (refactoring) à 5 jours, v0.922 (Go test coverage) à 5 jours. Redis HA, PostgreSQL replication, et WebRTC TURN/STUN sont explicitement reportés à v1.1 pour ne pas alourdir le chemin critique sans bénéfice immédiat pour le lancement commercial.*