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
- Executive Summary
- Timeline Gantt
- Phase 0.90X — Corrections sécurité critiques
- Phase 0.91X — Stabilisation OAuth, auth, paiement
- Phase 0.92X — Tests et couverture
- Phase 0.93X — Performance et scalabilité
- Phase 0.94X — Consolidation technique
- Phase 0.95X — Hardening production
- Phase 0.96X — Documentation et onboarding
- Phase 0.97X — Features manquantes pour v1.0
- Phase 0.98X — Beta et QA
- Phase 0.99X — Release candidate
- v1.0.0 — Release commerciale
- Matrice de dépendances
- Checklist v1.0.0 finale
- Annexe A — Mapping audit → versions
- Annexe B — Fichiers impactés par version
- 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
- Rust stream server — 6 tests pour 109 fichiers. Le passage à > 30% de couverture est l'effort le plus volumineux (~10 jours).
- 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).
- Hyperswitch E2E — Le flux de paiement complet nécessite un environnement sandbox Hyperswitch fonctionnel.
- Load testing — L'objectif de 1000 connexions WebSocket simultanées nécessite une infrastructure de test dédiée.
- 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).
- 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
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
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
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
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
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
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
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
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
6. Phase 0.93X — Performance
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
