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

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

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

---

0. PRINCIPES DE CETTE ROADMAP

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

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

Ordre de priorite :

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

---

1. TABLEAU DE BORD — ETAT AVANT ROADMAP

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

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

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

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

---

2. NOUVELLES VERSIONS — VUE D'ENSEMBLE

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

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

---

3. DETAIL DES VERSIONS

---

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

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

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

Taches

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

Criteres d'acceptation

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

---

v0.12.6.2 — Correctifs Securite Spec

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

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

Taches

• TASK-SFIX-001 : Forcer MFA pour roles admin et moderator

  • Modifier le middleware auth pour exiger MFA sur les roles admin et moderator
  • Ajouter un ecran de setup MFA obligatoire au premier login admin/moderator
  • Ref: ORIGIN_SECURITY_FRAMEWORK.md Regle 5
  • Fichiers: backend/internal/middleware/auth_middleware.go, backend/internal/auth/mfa_enforcement.go

• TASK-SFIX-002 : Aligner refresh token TTL sur la spec (30j → 7j)

  • Modifier la configuration JWT pour fixer le refresh token TTL a 7 jours
  • Invalider les refresh tokens existants avec TTL > 7j (migration)
  • Ref: ORIGIN_SECURITY_FRAMEWORK.md Regle 4
  • Fichiers: backend/internal/auth/jwt_service.go, backend/configs/

• TASK-SFIX-003 : Tests de validation securite spec

  • Test: MFA est requis pour tout endpoint admin/moderator
  • Test: refresh token expire apres 7 jours exactement
  • Test: access token expire apres 15 minutes

Criteres d'acceptation

• Connexion admin sans MFA → redirige vers setup MFA obligatoire
• Connexion moderator sans MFA → redirige vers setup MFA obligatoire
• jwt_service.go : refresh token TTL = 7 jours (604800 secondes)
• Tests unitaires passent pour les 2 correctifs

Risques

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

---

v0.12.6.3 — Nettoyage Code Fantome

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

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

Taches

• TASK-GHOST-001 : Auditer les modules fantomes

  • Verifier si contest/, sound_design_contest/, production_challenge/, voting_system/ sont actifs (routes enregistrees? appeles quelque part?)
  • Si actifs et gamification → desactiver/supprimer
  • Si inactifs → supprimer le code mort
  • Fichiers: backend/internal/api/contest/, backend/internal/api/sound_design_contest/, backend/internal/api/production_challenge/, backend/internal/api/voting_system/

• TASK-GHOST-002 : Evaluer et traiter playback_abtest_service.go

  • Verifier si le A/B testing audio est actif
  • S'il manipule l'experience utilisateur sans consentement → supprimer
  • S'il est desactive → supprimer le code mort
  • Ref: ORIGIN_UI_UX_SYSTEM.md §13 anti-dark-patterns

• TASK-GHOST-003 : Traiter les modules non-spec utiles

  • listing/handler.go et offer/handler.go : determiner si lies au marketplace (F226-F275)
  • graphql/handler.go : ORIGIN ne specifie que REST → documenter ou supprimer
  • grpc/handler.go : spec dans ORIGIN section 9 → conserver, documenter

• TASK-GHOST-004 : Verifier absence de code mort residuel

  • Confirmer 0 traces AI/ML, blockchain, gamification apres nettoyage
  • grep final sur les termes interdits

Criteres d'acceptation

• Aucun module de gamification actif dans le code
• playback_abtest_service.go traite (supprime ou desactive avec documentation)
• Code mort fantome supprime ou documente
• grep confirme 0 traces des categories ethiquement exclues

Risques

• Certains modules fantomes pourraient etre utilises par des routes actives → regression possible

---

v0.12.7 — Internationalisation (i18n)

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

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

Taches

• TASK-I18N-001 : Infrastructure i18n frontend

  • Installer et configurer react-i18next ou next-intl
  • Creer la structure de fichiers de traduction locales/{fr,en,es}/
  • Configurer le detection de langue (navigator, cookie, URL param)
  • Fichiers: apps/web/src/i18n/, apps/web/src/locales/

• TASK-I18N-002 : Extraction des chaines

  • Parcourir tous les composants React et extraire les chaines hardcodees
  • Remplacer par des appels t('key') ou equivalent
  • Generer les fichiers de traduction FR (source), EN, ES

• TASK-I18N-003 : Commutateur de langue

  • Composant UI de selection de langue (dropdown header)
  • Persistence du choix (localStorage / cookie)
  • Commutation sans rechargement de page (reactif)

• TASK-I18N-004 : i18n backend (messages d'erreur)

  • Internationaliser les messages d'erreur API (Accept-Language header)
  • Messages de validation, emails transactionnels
  • Fichiers: backend/internal/i18n/, backend/pkg/apierror/

• TASK-I18N-005 : Tests i18n

  • Test: toutes les cles de traduction existent dans les 3 langues
  • Test: commutation de langue fonctionne sans rechargement
  • Test: fallback vers EN si cle manquante

Criteres d'acceptation

• Interface 100% traduite en FR/EN/ES
• Commutation de langue sans rechargement
• Messages d'erreur API internationalises
• 0 chaine hardcodee dans les composants React

Risques

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

---

v0.12.8 — Documentation & API Publique

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

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

Taches

• TASK-APIDOC-001 : Generation OpenAPI / Swagger

  • Annoter les handlers Go existants avec des commentaires Swagger (swag/swaggo)
  • Generer swagger.json / openapi.yaml
  • Servir Swagger UI sur /api/docs
  • Fichiers: backend/cmd/, backend/internal/handlers/, routes

• TASK-APIDOC-002 : Gestion des cles API developpeurs

  • CRUD de cles API pour developpeurs tiers
  • Modele: api_keys (id, user_id, key_hash, name, scopes, rate_limit, created_at, expires_at)
  • Middleware de validation de cle API
  • Fichiers: backend/internal/models/api_key.go, backend/internal/handlers/api_key_handler.go

• TASK-APIDOC-003 : Rate limiting API publique

  • Rate limits specifiques par cle API (configurable)
  • Headers X-RateLimit-* sur les reponses
  • Ref: ORIGIN_API_SPECIFICATION.md §rate limits

• TASK-APIDOC-004 : Page portail developpeurs frontend

  • Page de gestion des cles API
  • Documentation interactive embeddee (Swagger UI)
  • Fichiers: apps/web/src/pages/developers/

• TASK-APIDOC-005 : Tests API publique

  • Test: Swagger UI accessible et a jour
  • Test: cle API valide → acces OK, cle invalide → 401
  • Test: rate limiting par cle API fonctionne

Criteres d'acceptation

• Documentation API navigable en ligne (/api/docs)
• Un developpeur externe peut creer une cle et consommer l'API
• Rate limiting par cle API fonctionnel
• OpenAPI spec generee automatiquement a jour

Risques

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

---

v0.12.9 — Tests Ethiques & Coverage CI

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

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

Taches

• TASK-ETH-001 : Test de biais artistes emergents (v0.10.1 non coche)

  • Ecrire un test qui verifie que la decouverte ne defavorise pas les artistes avec 0 ou peu de contenus
  • Le feed/decouverte doit inclure des artistes emergents proportionnellement
  • Ref: ORIGIN_FEATURES_REGISTRY.md, criteres ethiques
  • Fichiers: backend/internal/service/discovery_service_test.go

• TASK-ETH-002 : Test recherche artiste 0 plays (v0.10.2 non coche)

  • Ecrire un test qui verifie qu'un artiste avec 0 plays apparait dans les resultats de recherche par nom
  • La recherche ne doit pas filtrer/penaliser par popularite
  • Fichiers: backend/internal/service/search_service_test.go

• TASK-ETH-003 : Documenter l'algorithme de decouverte

  • Ecrire un document expliquant le fonctionnement de la decouverte
  • Confirmer: chronologique + tags/genres declaratifs, JAMAIS de classement par popularite
  • Fichier: veza-docs/DISCOVERY_ALGORITHM.md

• TASK-COV-001 : Configurer coverage CI

  • Ajouter go test -coverprofile dans le workflow CI
  • Ajouter quality gate: coverage >= 70% sur nouveau code
  • Publier le rapport coverage (badge, artefact)
  • Fichiers: .github/workflows/ci.yml

• TASK-COV-002 : Augmenter coverage Rust

  • Ajouter des tests unitaires au stream server Rust (actuellement 25 fichiers)
  • Cible: au moins 50% de coverage Rust
  • Configurer cargo tarpaulin en CI

• TASK-COV-003 : Rapport coverage global

  • Agreger Go + Rust + Frontend dans un rapport unique
  • Quality gate globale >= 70%

Criteres d'acceptation

• Test de biais artistes emergents PASSE
• Test recherche artiste 0 plays PASSE
• Algorithme de decouverte documente
• Coverage mesuree et enforcee en CI (>= 70% Go, >= 50% Rust)
• Badge coverage visible dans le repo

Risques

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

---

v0.13.0 — Conformite Features Partielles

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

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

Taches

• TASK-CONF-001 : Completer 2FA SMS (F020)

  • Implementer l'envoi de codes SMS via un provider (Twilio ou equivalent)
  • Frontend: ecran de saisie du code SMS
  • Ref: ORIGIN_FEATURES_REGISTRY.md F020
  • Fichiers: backend/internal/auth/sms_service.go, apps/web/src/pages/auth/

• TASK-CONF-002 : Implementer CAPTCHA anti-bot (F029)

  • Integrer hCaptcha ou Turnstile (pas Google reCAPTCHA pour la vie privee)
  • Proteger: registration, login, password reset, contact forms
  • Ref: ORIGIN_FEATURES_REGISTRY.md F029
  • Fichiers: apps/web/src/components/captcha/, backend/internal/middleware/captcha_middleware.go

• TASK-CONF-003 : Completer les features auth partielles

  • F010: tester logout all devices completement
  • F013: verifier password history (empecher reutilisation)
  • F014: ajouter validation force password cote backend
  • F018: completer notification changement password
  • F021: tester 2FA backup codes completement
  • F024: implementer notification connexion inhabituelle
  • F026: completer historique connexions avec details

• TASK-CONF-004 : Completer les features fichiers partielles

  • F075: verifier integration ClamAV complete
  • F080: evaluer watermarking (si requis pour v1.0)

• TASK-CONF-005 : Resoudre la double structure handlers

  • Migrer les handlers restants de internal/handlers/ vers internal/core/*/handler.go
  • Ou documenter la coexistence et nettoyer les doublons
  • Ref: diagnostic §5.1

• TASK-CONF-006 : Nettoyer TODO/FIXME frontend

  • Traiter les 43 TODO/FIXME identifies dans le frontend
  • Resoudre ou convertir en issues trackees
  • Cible: < 10 TODO/FIXME restants

Criteres d'acceptation

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

Risques

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

---

v0.13.1 — Conformite Audio & Player

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

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

Taches

• TASK-AUDIO-001 : Gapless playback (F116)

  • Implementer la lecture sans interruption entre deux tracks
  • Utiliser Web Audio API pour le pre-buffering du track suivant
  • Fichiers: apps/web/src/components/player/, stream server

• TASK-AUDIO-002 : Crossfade (F117) — si absent

  • Verifier l'etat actuel du crossfade
  • Implementer le fondu enchaine configurable (1-12s)

• TASK-AUDIO-003 : Normalisation audio (F118) — si absent

  • Normalisation du volume entre tracks (ReplayGain ou equivalent)
  • Cote serveur (Rust) ou cote client (Web Audio API)

• TASK-AUDIO-004 : Completer les features player partielles

  • Verifier F106-F115 (play, pause, seek, volume, queue, shuffle, repeat, progress, waveform)
  • Completer les tests pour chaque feature player

Criteres d'acceptation

• Gapless playback fonctionne entre deux tracks consecutifs
• Crossfade configurable
• Pas de saut de volume entre tracks
• Toutes les features player core testees

Risques

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

---

v0.13.2 — Consolidation Design System

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

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

Taches

• TASK-DS-001 : Migrer les composants SUMI vers le design system

  • Deplacer les composants UI de base de apps/web/src/components/ui/ vers packages/design-system/src/
  • Exporter proprement depuis packages/design-system/
  • Mettre a jour les imports dans apps/web/

• TASK-DS-002 : Design tokens

  • Extraire les tokens (couleurs, typo, spacing, shadows, radius) dans le package
  • S'assurer que dark mode et light mode utilisent les memes tokens
  • Ref: ORIGIN_UI_UX_SYSTEM.md §design tokens

• TASK-DS-003 : Documentation Storybook

  • Verifier que les stories existantes couvrent les composants principaux
  • Ajouter les stories manquantes pour les composants migres

Criteres d'acceptation

• packages/design-system/ contient les composants UI de base
• Design tokens centralises et utilises par toutes les apps
• Stories a jour pour les composants principaux

Risques

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

---

v0.13.3 — Polish Securite Avancee

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

Taches

• TASK-SECADV-001 : Passkeys/WebAuthn (F022)

  • Implementer l'enregistrement et l'authentification par passkeys
  • Utiliser la Web Authentication API
  • Backend: backend/internal/auth/webauthn_service.go
  • Frontend: apps/web/src/pages/auth/passkeys/

• TASK-SECADV-002 : Password configurable policy (F015)

  • Politique de mot de passe configurable par l'admin
  • Longueur min, complexite, expiration

• TASK-SECADV-003 : Geolocalisation connexions (F025)

  • Detection IP → pays via MaxMind GeoIP ou equivalent
  • Notification si connexion depuis un nouveau pays
  • Affichage dans l'historique des sessions

• TASK-SECADV-004 : Password expiration (F016) — optionnel

  • Politique d'expiration configurable
  • Notification avant expiration

Criteres d'acceptation

• WebAuthn fonctionnel (enregistrement + login)
• Geolocalisation des connexions affichee
• Politique de mot de passe configurable

Risques

• WebAuthn complexe a implementer correctement
• GeoIP necessite une base de donnees (licence MaxMind)

---

v0.13.4 — Polish Audio & Player

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

Taches

• TASK-APLSH-001 : Picture-in-picture (F121)

  • Implementer le mode picture-in-picture pour le player
  • Utiliser l'API Picture-in-Picture du navigateur

• TASK-APLSH-002 : Chromecast support (F124) — optionnel v1.0

  • Integrer le SDK Cast
  • Streaming vers Chromecast

• TASK-APLSH-003 : AirPlay support (F125) — optionnel v1.0

  • Streaming vers appareils AirPlay

• TASK-APLSH-004 : Spectrogram/Equalizer visualiseurs

  • Visualisation audio temps reel (Web Audio API AnalyserNode)
  • Equalizer graphique basique

Criteres d'acceptation

• Picture-in-picture fonctionne sur les navigateurs supportes
• Au moins un visualiseur audio basique

Risques

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

---

v0.13.5 — Polish Marketplace & Compliance

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

Taches

• TASK-MKT-001 : KYC vendeurs (F055)

  • Verification d'identite pour les vendeurs marketplace
  • Integration avec un service KYC (Stripe Identity ou equivalent)
  • Fichiers: backend/internal/service/kyc_service.go

• TASK-MKT-002 : Validation E2E flux de paiement

  • Test complet: creation produit → achat → paiement → download
  • Test avec Hyperswitch en mode test
  • Documenter le flux

• TASK-MKT-003 : Validation E2E flux de payout createur

  • Test complet: ventes accumulees → seuil $50 → payout automatique
  • Documenter le flux

• TASK-MKT-004 : Page support accessible

  • Page de contact / helpdesk
  • Au minimum: formulaire de contact email
  • Ref: GO/NO-GO Business → Support accessible

Criteres d'acceptation

• KYC vendeurs fonctionnel
• Flux paiement teste E2E
• Flux payout teste E2E
• Page support accessible

Risques

• KYC necessite un provider externe avec des couts
• Tests E2E paiement necessitent un environnement Hyperswitch fonctionnel

---

v0.14.0 — Validation Runtime & Staging

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

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

Taches

• TASK-STAG-001 : Deploiement staging

  • Deployer l'ensemble de la stack sur un environnement staging
  • Verifier que tous les services demarrent correctement
  • Ref: critere non coche v0.9.1

• TASK-STAG-002 : Validation performances

  • Executer les tests k6 existants
  • Mesurer: p95 API < 100ms, p99 < 200ms
  • Mesurer: audio stream start < 500ms
  • Mesurer: search results < 500ms

• TASK-STAG-003 : Validation Lighthouse

  • Executer Lighthouse sur les pages principales
  • Cibles: Performance >= 85, Accessibility >= 90, PWA >= 90
  • Ref: critere non coche v0.11.0

• TASK-STAG-004 : Validation stabilite

  • Monitorer pendant 48h minimum
  • Verifier: taux erreur 5xx < 0.1%
  • Verifier: aucun crash/restart non planifie

• TASK-STAG-005 : Validation RGPD

  • Tester export de donnees utilisateur de bout en bout
  • Tester suppression de compte de bout en bout
  • Verifier anonymisation effective

• TASK-STAG-006 : Validation bundle size

  • Verifier: bundle JS initial < 200KB gzip
  • Documenter le resultat

Criteres d'acceptation

• Staging deploye et fonctionnel
• p95 API < 100ms
• Lighthouse Performance >= 85, Accessibility >= 90
• Taux erreur 5xx < 0.1% sur 48h
• RGPD export + suppression fonctionnels
• Bundle < 200KB gzip

Risques

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

---

v1.0.0-rc1 — Release Candidate 1

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

Taches

• TASK-RC-001 : Checklist GO/NO-GO complete

  • Parcourir chaque critere GO/NO-GO et cocher
  • Documenter les preuves pour chaque critere
  • Fichier: veza-docs/GO_NO_GO_CHECKLIST.md

• TASK-RC-002 : Audit final anti-dark-patterns

  • Parcours complet de l'UI
  • Verifier: 0 FOMO, 0 gamification, 0 metriques publiques, 0 friction desinscription
  • Documenter le resultat

• TASK-RC-003 : Politique de confidentialite

  • Verifier que la politique de confidentialite est a jour
  • Conforme RGPD
  • Ref: GO/NO-GO Ethique

• TASK-RC-004 : Documentation decouverte

  • Verifier que le document DISCOVERY_ALGORITHM.md est complet et auditable
  • Ref: GO/NO-GO Ethique → Algorithme de decouverte documente

• TASK-RC-005 : Freeze du code

  • Branche release/v1.0.0 creee
  • Seuls les bugfixes critiques acceptes
  • CI/CD verte depuis 2 semaines minimum

• TASK-RC-006 : Re-pentest final (optionnel)

  • Si les correctifs pentest sont significatifs, un re-scan peut etre necessaire

Criteres d'acceptation

• 100% des criteres GO/NO-GO coches
• Branche release creee
• CI/CD verte

Risques

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

---

v1.0.0 — Release Stable

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

Taches

• TASK-REL-001 : Tag v1.0.0

  • git tag -a v1.0.0 -m "Version 1.0.0 : Release Stable"

• TASK-REL-002 : Release notes

  • Changelog complet depuis v0.9.1
  • Features highlights
  • Fichier: CHANGELOG.md

• TASK-REL-003 : Deploiement production

  • Pipeline CI/CD production
  • Validation post-deploiement

Criteres d'acceptation

• Tag v1.0.0 cree
• Release notes publiees
• Deploiement production reussi

---

4. MAPPING GO/NO-GO ↔ VERSIONS

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

Securite

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

Stabilite

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

Performance

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

Qualite

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

Ethique

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

Business

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

---

5. CRITERES NON COCHES DES VERSIONS DONE — RESOLUTION

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

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

Tous les 10 criteres sont couverts.

---

6. DIAGRAMME GANTT SIMPLIFIE

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

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

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

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

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

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

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

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

Jalons cles :

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

---

7. CHEMINS CRITIQUES

Chemin critique principal (bloque v1.0)

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

Parallelisation possible

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

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

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

---

8. FEATURES REPORTEES POST-v1.0

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

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

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

---

9. ESTIMATION GLOBALE

Effort par priorite

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

Scenarios

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

Facteurs de risque

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

---

10. RECOMMANDATIONS

Recommandation 1 : Commencer par P0 immediatement

Les 3 findings HIGH du pentest bloquent tout. Il faut les corriger avant toute autre chose. En parallele, un second developpeur peut attaquer v0.12.7 (i18n).

Recommandation 2 : Ne pas sous-estimer v0.14.0

La validation runtime (staging) est le goulot d'etranglement. Beaucoup de criteres GO/NO-GO ne seront verifiables qu'a ce stade. Preparer l'infrastructure staging le plus tot possible.

Recommandation 3 : Etre pret a reporter des features P3

Si le calendrier se tend, les features P3 (WebAuthn, Chromecast/AirPlay, spectrogram, KYC) peuvent etre reportees en v1.1 sans affecter la validite du GO/NO-GO.

Recommandation 4 : Automatiser les validations

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

Recommandation 5 : Clarifier le statut des features fantomes

Les modules contest, voting_system, production_challenge doivent etre evalues immediatement. S'ils constituent de la gamification, leur presence est un risque ethique meme s'ils sont desactives.

---

Fin de la roadmap Phase 5