969 lines
37 KiB
Markdown
969 lines
37 KiB
Markdown
|
# AUDIT_05_ROADMAP_v1.0.md -- Roadmap Exhaustive vers la v1.0
|
|||
|
|
|
|||
|
|
**Date** : 2026-03-11
|
|||
|
|
**Auditeur** : Claude Opus 4.6
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 0. PRINCIPES DE CETTE ROADMAP
|
|||
|
|
|
|||
|
|
Cette roadmap remplace la section TODO du `VEZA_VERSIONS_ROADMAP.md` existant. Elle est construite a partir du diagnostic Phase 4 et couvre **tous les ecarts identifies** entre le code actuel et les specifications ORIGIN, organises par priorite.
|
|||
|
|
|
|||
|
|
**Regle cardinale** : Rien ne passe en v1.0 tant que tous les criteres GO/NO-GO ne sont pas satisfaits.
|
|||
|
|
|
|||
|
|
**Ordre de priorite** :
|
|||
|
|
- **P0** : Bloquants securite — sans resolution, aucun deploiement possible
|
|||
|
|
- **P1** : Features manquantes bloquant v1.0 — versions TODO du roadmap + tests ethiques
|
|||
|
|
- **P2** : Conformite — ecarts spec/code qui n'empechent pas le fonctionnement mais violent les ORIGIN
|
|||
|
|
- **P3** : Polish — features partielles et ameliorations d'experience
|
|||
|
|
- **P4** : Nice-to-have — optionnel pour v1.0, peut etre reporte en v1.1+
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. TABLEAU DE BORD — ETAT AVANT ROADMAP
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
VERSIONS EXISTANTES
|
|||
|
|
DONE : 27 versions (v0.9.1 → v0.12.6.1)
|
|||
|
|
TODO : 3 versions (v0.12.7, v0.12.8, v1.0.0)
|
|||
|
|
|
|||
|
|
ECARTS DIAGNOSTIQUES
|
|||
|
|
P0 Bloquants securite : 3 ecarts (~5j)
|
|||
|
|
P1 Features bloquantes : 7 ecarts (~15j)
|
|||
|
|
P2 Conformite : 8 ecarts (~14j)
|
|||
|
|
P3 Polish : 10 ecarts (~20j)
|
|||
|
|
P4 Nice-to-have : 5 ecarts (~10j)
|
|||
|
|
|
|||
|
|
TOTAL ECARTS : 33
|
|||
|
|
EFFORT TOTAL ESTIME : 50-65 jours-dev
|
|||
|
|
|
|||
|
|
CRITERES NON COCHES DANS VERSIONS DONE
|
|||
|
|
v0.9.1 : 1 (staging deploy)
|
|||
|
|
v0.9.2 : 1 (pentest partiel)
|
|||
|
|
v0.9.5 : 1 (tests pass)
|
|||
|
|
v0.9.8 : 1 (coverage 70%)
|
|||
|
|
v0.10.0 : 2 (perf, staging)
|
|||
|
|
v0.10.1 : 1 (test biais)
|
|||
|
|
v0.10.2 : 1 (test 0-plays)
|
|||
|
|
v0.11.0 : 1 (Lighthouse)
|
|||
|
|
v0.12.6 : 1 (3 HIGH findings)
|
|||
|
|
TOTAL : 10 criteres non coches
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. NOUVELLES VERSIONS — VUE D'ENSEMBLE
|
|||
|
|
|
|||
|
|
| # | Version | Nom | Priorite | Effort | Prerequisite | GO/NO-GO |
|
|||
|
|
|---|---------|-----|----------|--------|--------------|----------|
|
|||
|
|
| 1 | v0.12.6.1 | Correctifs Pentest (30/30 findings) | P0 | 5-8j | v0.12.6 | ✅ DONE 2026-03-12 |
|
|||
|
|
| 2 | v0.12.6.2 | Correctifs Securite Spec | P0 | 1.5j | v0.12.6 | Securite |
|
|||
|
|
| 3 | v0.12.6.3 | Nettoyage Code Fantome | P1 | 1-2j | v0.12.6 | Ethique |
|
|||
|
|
| 4 | v0.12.7 | Internationalisation (i18n) | P1 | 3-4j | v0.12.5 | Qualite |
|
|||
|
|
| 5 | v0.12.8 | Documentation & API Publique | P1 | 3-4j | v0.12.6 | Qualite |
|
|||
|
|
| 6 | v0.12.9 | Tests Ethiques & Coverage CI | P1 | 2-3j | v0.12.6.3 | Ethique+Qualite |
|
|||
|
|
| 7 | v0.13.0 | Conformite Features Partielles | P2 | 5-7j | v0.12.9 | Qualite |
|
|||
|
|
| 8 | v0.13.1 | Conformite Audio & Player | P2 | 4-5j | v0.13.0 | Qualite |
|
|||
|
|
| 9 | v0.13.2 | Consolidation Design System | P2 | 2-3j | v0.13.0 | Qualite |
|
|||
|
|
| 10 | v0.13.3 | Polish Securite Avancee | P3 | 3-4j | v0.13.0 | Securite |
|
|||
|
|
| 11 | v0.13.4 | Polish Audio & Player | P3 | 3-4j | v0.13.1 | — |
|
|||
|
|
| 12 | v0.13.5 | Polish Marketplace & Compliance | P3 | 3-4j | v0.13.0 | Business |
|
|||
|
|
| 13 | v0.14.0 | Validation Runtime & Staging | P0-P1 | 3-5j | v0.13.2 | Stabilite+Perf |
|
|||
|
|
| 14 | v1.0.0-rc1 | Release Candidate 1 | — | 2-3j | Tout | Tout |
|
|||
|
|
| 15 | v1.0.0 | Release Stable | — | 1-2j | v1.0.0-rc1 | Tout |
|
|||
|
|
|
|||
|
|
**Effort total estime : 40-55 jours-dev**
|
|||
|
|
**Duree calendaire estimee (1 dev) : 10-14 semaines**
|
|||
|
|
**Duree calendaire estimee (2 devs) : 6-8 semaines**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. DETAIL DES VERSIONS
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.12.6.1 — Correctifs Pentest (30/30 findings)
|
|||
|
|
|
|||
|
|
**Priorite** : P0 — BLOQUANT SECURITE
|
|||
|
|
**Statut** : ✅ DONE
|
|||
|
|
**Complete le** : 2026-03-12
|
|||
|
|
**Effort** : 3-5 jours
|
|||
|
|
**Prerequisite** : v0.12.6
|
|||
|
|
**GO/NO-GO** : `Securite → Pentest externe valide (0 finding critique/haut ouvert)` ✅
|
|||
|
|
|
|||
|
|
**Contexte** : Le pentest v0.12.6 a identifie 30 findings (2 CRIT, 10 HIGH, 12 MEDIUM, 6 LOW). Tous les 30 ont ete corriges dans 4 commits. La matrice de remediation (REMEDIATION_MATRIX_v0.12.6.md) montre 30/30 corriges.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [x] **TASK-PFIX-001** : Corriger CRIT-001 — IDOR conversations privees (CVSS 9.1)
|
|||
|
|
- [x] **TASK-PFIX-002** : Corriger CRIT-002 — Metriques de popularite publiques (CVSS 5.3)
|
|||
|
|
- [x] **TASK-PFIX-003** : Corriger les 10 findings HIGH
|
|||
|
|
- [x] **TASK-PFIX-005** : Corriger les 12 findings MEDIUM
|
|||
|
|
- [x] **TASK-PFIX-006** : Corriger les 6 findings LOW
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [x] Les 2 findings CRITIQUES corriges (IDOR + metriques publiques)
|
|||
|
|
- [x] Les 10 findings HIGH corriges (race conditions, TrustedProxies, RGPD, RTMP, etc.)
|
|||
|
|
- [x] Les 12 findings MEDIUM corriges (CSP, pagination, WebSocket, k-anonymity, etc.)
|
|||
|
|
- [x] Les 6 findings LOW corriges (password policy, Docker pins, dotenv, Elasticsearch, context)
|
|||
|
|
- [x] 0 finding critique ou haut ouvert
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.12.6.2 — Correctifs Securite Spec
|
|||
|
|
|
|||
|
|
**Priorite** : P0 — BLOQUANT SECURITE
|
|||
|
|
**Effort** : 1.5 jours
|
|||
|
|
**Prerequisite** : v0.12.6
|
|||
|
|
**GO/NO-GO** : `Securite → JWT RS256 en production` + regles ORIGIN
|
|||
|
|
|
|||
|
|
**Contexte** : Deux ecarts de conformite securite identifies entre le code et ORIGIN_SECURITY_FRAMEWORK.md.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-SFIX-001** : Forcer MFA pour roles admin et moderator
|
|||
|
|
- Modifier le middleware auth pour exiger MFA sur les roles `admin` et `moderator`
|
|||
|
|
- Ajouter un ecran de setup MFA obligatoire au premier login admin/moderator
|
|||
|
|
- Ref: ORIGIN_SECURITY_FRAMEWORK.md Regle 5
|
|||
|
|
- Fichiers: `backend/internal/middleware/auth_middleware.go`, `backend/internal/auth/mfa_enforcement.go`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-SFIX-002** : Aligner refresh token TTL sur la spec (30j → 7j)
|
|||
|
|
- Modifier la configuration JWT pour fixer le refresh token TTL a 7 jours
|
|||
|
|
- Invalider les refresh tokens existants avec TTL > 7j (migration)
|
|||
|
|
- Ref: ORIGIN_SECURITY_FRAMEWORK.md Regle 4
|
|||
|
|
- Fichiers: `backend/internal/auth/jwt_service.go`, `backend/configs/`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-SFIX-003** : Tests de validation securite spec
|
|||
|
|
- Test: MFA est requis pour tout endpoint admin/moderator
|
|||
|
|
- Test: refresh token expire apres 7 jours exactement
|
|||
|
|
- Test: access token expire apres 15 minutes
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] Connexion admin sans MFA → redirige vers setup MFA obligatoire
|
|||
|
|
- [ ] Connexion moderator sans MFA → redirige vers setup MFA obligatoire
|
|||
|
|
- [ ] `jwt_service.go` : refresh token TTL = 7 jours (604800 secondes)
|
|||
|
|
- [ ] Tests unitaires passent pour les 2 correctifs
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Impact sur les admins existants qui n'ont pas encore configure MFA
|
|||
|
|
- Migration des tokens existants a gerer proprement
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.12.6.3 — Nettoyage Code Fantome
|
|||
|
|
|
|||
|
|
**Priorite** : P1
|
|||
|
|
**Effort** : 1-2 jours
|
|||
|
|
**Prerequisite** : v0.12.6
|
|||
|
|
**GO/NO-GO** : `Ethique → Aucune donnee comportementale`, `Ethique → Audit UX anti-dark-patterns`
|
|||
|
|
|
|||
|
|
**Contexte** : Le diagnostic a identifie 9 modules "fantomes" — du code present dans le repo mais non specifie dans les ORIGIN. Certains (`contest`, `voting_system`, `production_challenge`) pourraient constituer de la gamification interdite. `playback_abtest_service.go` pose un probleme ethique potentiel.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-GHOST-001** : Auditer les modules fantomes
|
|||
|
|
- Verifier si `contest/`, `sound_design_contest/`, `production_challenge/`, `voting_system/` sont actifs (routes enregistrees? appeles quelque part?)
|
|||
|
|
- Si actifs et gamification → desactiver/supprimer
|
|||
|
|
- Si inactifs → supprimer le code mort
|
|||
|
|
- Fichiers: `backend/internal/api/contest/`, `backend/internal/api/sound_design_contest/`, `backend/internal/api/production_challenge/`, `backend/internal/api/voting_system/`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-GHOST-002** : Evaluer et traiter `playback_abtest_service.go`
|
|||
|
|
- Verifier si le A/B testing audio est actif
|
|||
|
|
- S'il manipule l'experience utilisateur sans consentement → supprimer
|
|||
|
|
- S'il est desactive → supprimer le code mort
|
|||
|
|
- Ref: ORIGIN_UI_UX_SYSTEM.md §13 anti-dark-patterns
|
|||
|
|
|
|||
|
|
- [ ] **TASK-GHOST-003** : Traiter les modules non-spec utiles
|
|||
|
|
- `listing/handler.go` et `offer/handler.go` : determiner si lies au marketplace (F226-F275)
|
|||
|
|
- `graphql/handler.go` : ORIGIN ne specifie que REST → documenter ou supprimer
|
|||
|
|
- `grpc/handler.go` : spec dans ORIGIN section 9 → conserver, documenter
|
|||
|
|
|
|||
|
|
- [ ] **TASK-GHOST-004** : Verifier absence de code mort residuel
|
|||
|
|
- Confirmer 0 traces AI/ML, blockchain, gamification apres nettoyage
|
|||
|
|
- grep final sur les termes interdits
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] Aucun module de gamification actif dans le code
|
|||
|
|
- [ ] `playback_abtest_service.go` traite (supprime ou desactive avec documentation)
|
|||
|
|
- [ ] Code mort fantome supprime ou documente
|
|||
|
|
- [ ] grep confirme 0 traces des categories ethiquement exclues
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Certains modules fantomes pourraient etre utilises par des routes actives → regression possible
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.12.7 — Internationalisation (i18n)
|
|||
|
|
|
|||
|
|
**Priorite** : P1 — BLOQUE v1.0
|
|||
|
|
**Effort** : 3-4 jours
|
|||
|
|
**Prerequisite** : v0.12.5
|
|||
|
|
**GO/NO-GO** : `Qualite → CI/CD verte`
|
|||
|
|
|
|||
|
|
**Contexte** : Version TODO existante dans le roadmap. L'internationalisation n'est pas implementee. Le spec exige FR/EN/ES minimum.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-I18N-001** : Infrastructure i18n frontend
|
|||
|
|
- Installer et configurer `react-i18next` ou `next-intl`
|
|||
|
|
- Creer la structure de fichiers de traduction `locales/{fr,en,es}/`
|
|||
|
|
- Configurer le detection de langue (navigator, cookie, URL param)
|
|||
|
|
- Fichiers: `apps/web/src/i18n/`, `apps/web/src/locales/`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-I18N-002** : Extraction des chaines
|
|||
|
|
- Parcourir tous les composants React et extraire les chaines hardcodees
|
|||
|
|
- Remplacer par des appels `t('key')` ou equivalent
|
|||
|
|
- Generer les fichiers de traduction FR (source), EN, ES
|
|||
|
|
|
|||
|
|
- [ ] **TASK-I18N-003** : Commutateur de langue
|
|||
|
|
- Composant UI de selection de langue (dropdown header)
|
|||
|
|
- Persistence du choix (localStorage / cookie)
|
|||
|
|
- Commutation sans rechargement de page (reactif)
|
|||
|
|
|
|||
|
|
- [ ] **TASK-I18N-004** : i18n backend (messages d'erreur)
|
|||
|
|
- Internationaliser les messages d'erreur API (`Accept-Language` header)
|
|||
|
|
- Messages de validation, emails transactionnels
|
|||
|
|
- Fichiers: `backend/internal/i18n/`, `backend/pkg/apierror/`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-I18N-005** : Tests i18n
|
|||
|
|
- Test: toutes les cles de traduction existent dans les 3 langues
|
|||
|
|
- Test: commutation de langue fonctionne sans rechargement
|
|||
|
|
- Test: fallback vers EN si cle manquante
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] Interface 100% traduite en FR/EN/ES
|
|||
|
|
- [ ] Commutation de langue sans rechargement
|
|||
|
|
- [ ] Messages d'erreur API internationalises
|
|||
|
|
- [ ] 0 chaine hardcodee dans les composants React
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Volume de chaines a extraire potentiellement important (~1900 fichiers TSX)
|
|||
|
|
- Traductions ES a faire (ou placeholders acceptables pour v1.0)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.12.8 — Documentation & API Publique
|
|||
|
|
|
|||
|
|
**Priorite** : P1 — BLOQUE v1.0
|
|||
|
|
**Effort** : 3-4 jours
|
|||
|
|
**Prerequisite** : v0.12.6
|
|||
|
|
**GO/NO-GO** : `Qualite → CI/CD verte`
|
|||
|
|
|
|||
|
|
**Contexte** : Version TODO existante. Module 24 Developpeurs & API (F586-F600) est tres partiel. ORIGIN exige une documentation API publique navigable.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-APIDOC-001** : Generation OpenAPI / Swagger
|
|||
|
|
- Annoter les handlers Go existants avec des commentaires Swagger (swag/swaggo)
|
|||
|
|
- Generer `swagger.json` / `openapi.yaml`
|
|||
|
|
- Servir Swagger UI sur `/api/docs`
|
|||
|
|
- Fichiers: `backend/cmd/`, `backend/internal/handlers/`, routes
|
|||
|
|
|
|||
|
|
- [ ] **TASK-APIDOC-002** : Gestion des cles API developpeurs
|
|||
|
|
- CRUD de cles API pour developpeurs tiers
|
|||
|
|
- Modele: `api_keys` (id, user_id, key_hash, name, scopes, rate_limit, created_at, expires_at)
|
|||
|
|
- Middleware de validation de cle API
|
|||
|
|
- Fichiers: `backend/internal/models/api_key.go`, `backend/internal/handlers/api_key_handler.go`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-APIDOC-003** : Rate limiting API publique
|
|||
|
|
- Rate limits specifiques par cle API (configurable)
|
|||
|
|
- Headers `X-RateLimit-*` sur les reponses
|
|||
|
|
- Ref: ORIGIN_API_SPECIFICATION.md §rate limits
|
|||
|
|
|
|||
|
|
- [ ] **TASK-APIDOC-004** : Page portail developpeurs frontend
|
|||
|
|
- Page de gestion des cles API
|
|||
|
|
- Documentation interactive embeddee (Swagger UI)
|
|||
|
|
- Fichiers: `apps/web/src/pages/developers/`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-APIDOC-005** : Tests API publique
|
|||
|
|
- Test: Swagger UI accessible et a jour
|
|||
|
|
- Test: cle API valide → acces OK, cle invalide → 401
|
|||
|
|
- Test: rate limiting par cle API fonctionne
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] Documentation API navigable en ligne (`/api/docs`)
|
|||
|
|
- [ ] Un developpeur externe peut creer une cle et consommer l'API
|
|||
|
|
- [ ] Rate limiting par cle API fonctionnel
|
|||
|
|
- [ ] OpenAPI spec generee automatiquement a jour
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Annotation Swagger de ~70+ route files = effort significatif
|
|||
|
|
- Scope de "API publique" a definir (quels endpoints exposer?)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.12.9 — Tests Ethiques & Coverage CI
|
|||
|
|
|
|||
|
|
**Priorite** : P1
|
|||
|
|
**Effort** : 2-3 jours
|
|||
|
|
**Prerequisite** : v0.12.6.3
|
|||
|
|
**GO/NO-GO** : `Ethique → Algorithme de decouverte auditable`, `Qualite → Coverage tests >= 70%`
|
|||
|
|
|
|||
|
|
**Contexte** : Les tests de biais ethiques exiges par les specs sont absents. La coverage n'est ni mesuree ni enforcee en CI.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-ETH-001** : Test de biais artistes emergents (v0.10.1 non coche)
|
|||
|
|
- Ecrire un test qui verifie que la decouverte ne defavorise pas les artistes avec 0 ou peu de contenus
|
|||
|
|
- Le feed/decouverte doit inclure des artistes emergents proportionnellement
|
|||
|
|
- Ref: ORIGIN_FEATURES_REGISTRY.md, criteres ethiques
|
|||
|
|
- Fichiers: `backend/internal/service/discovery_service_test.go`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-ETH-002** : Test recherche artiste 0 plays (v0.10.2 non coche)
|
|||
|
|
- Ecrire un test qui verifie qu'un artiste avec 0 plays apparait dans les resultats de recherche par nom
|
|||
|
|
- La recherche ne doit pas filtrer/penaliser par popularite
|
|||
|
|
- Fichiers: `backend/internal/service/search_service_test.go`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-ETH-003** : Documenter l'algorithme de decouverte
|
|||
|
|
- Ecrire un document expliquant le fonctionnement de la decouverte
|
|||
|
|
- Confirmer: chronologique + tags/genres declaratifs, JAMAIS de classement par popularite
|
|||
|
|
- Fichier: `veza-docs/DISCOVERY_ALGORITHM.md`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-COV-001** : Configurer coverage CI
|
|||
|
|
- Ajouter `go test -coverprofile` dans le workflow CI
|
|||
|
|
- Ajouter quality gate: coverage >= 70% sur nouveau code
|
|||
|
|
- Publier le rapport coverage (badge, artefact)
|
|||
|
|
- Fichiers: `.github/workflows/ci.yml`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-COV-002** : Augmenter coverage Rust
|
|||
|
|
- Ajouter des tests unitaires au stream server Rust (actuellement 25 fichiers)
|
|||
|
|
- Cible: au moins 50% de coverage Rust
|
|||
|
|
- Configurer `cargo tarpaulin` en CI
|
|||
|
|
|
|||
|
|
- [ ] **TASK-COV-003** : Rapport coverage global
|
|||
|
|
- Agreger Go + Rust + Frontend dans un rapport unique
|
|||
|
|
- Quality gate globale >= 70%
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] Test de biais artistes emergents PASSE
|
|||
|
|
- [ ] Test recherche artiste 0 plays PASSE
|
|||
|
|
- [ ] Algorithme de decouverte documente
|
|||
|
|
- [ ] Coverage mesuree et enforcee en CI (>= 70% Go, >= 50% Rust)
|
|||
|
|
- [ ] Badge coverage visible dans le repo
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- La coverage Rust peut etre difficile a monter rapidement (de ~40% a 50%)
|
|||
|
|
- Les tests de biais peuvent reveler des problemes dans la logique de decouverte
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.13.0 — Conformite Features Partielles
|
|||
|
|
|
|||
|
|
**Priorite** : P2
|
|||
|
|
**Effort** : 5-7 jours
|
|||
|
|
**Prerequisite** : v0.12.9
|
|||
|
|
**GO/NO-GO** : `Qualite → 0 linting error`
|
|||
|
|
|
|||
|
|
**Contexte** : ~83 features sont marquees PARTIEL dans le diagnostic. Cette version cible les features partielles les plus impactantes pour la conformite.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-CONF-001** : Completer 2FA SMS (F020)
|
|||
|
|
- Implementer l'envoi de codes SMS via un provider (Twilio ou equivalent)
|
|||
|
|
- Frontend: ecran de saisie du code SMS
|
|||
|
|
- Ref: ORIGIN_FEATURES_REGISTRY.md F020
|
|||
|
|
- Fichiers: `backend/internal/auth/sms_service.go`, `apps/web/src/pages/auth/`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-CONF-002** : Implementer CAPTCHA anti-bot (F029)
|
|||
|
|
- Integrer hCaptcha ou Turnstile (pas Google reCAPTCHA pour la vie privee)
|
|||
|
|
- Proteger: registration, login, password reset, contact forms
|
|||
|
|
- Ref: ORIGIN_FEATURES_REGISTRY.md F029
|
|||
|
|
- Fichiers: `apps/web/src/components/captcha/`, `backend/internal/middleware/captcha_middleware.go`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-CONF-003** : Completer les features auth partielles
|
|||
|
|
- F010: tester logout all devices completement
|
|||
|
|
- F013: verifier password history (empecher reutilisation)
|
|||
|
|
- F014: ajouter validation force password cote backend
|
|||
|
|
- F018: completer notification changement password
|
|||
|
|
- F021: tester 2FA backup codes completement
|
|||
|
|
- F024: implementer notification connexion inhabituelle
|
|||
|
|
- F026: completer historique connexions avec details
|
|||
|
|
|
|||
|
|
- [ ] **TASK-CONF-004** : Completer les features fichiers partielles
|
|||
|
|
- F075: verifier integration ClamAV complete
|
|||
|
|
- F080: evaluer watermarking (si requis pour v1.0)
|
|||
|
|
|
|||
|
|
- [ ] **TASK-CONF-005** : Resoudre la double structure handlers
|
|||
|
|
- Migrer les handlers restants de `internal/handlers/` vers `internal/core/*/handler.go`
|
|||
|
|
- Ou documenter la coexistence et nettoyer les doublons
|
|||
|
|
- Ref: diagnostic §5.1
|
|||
|
|
|
|||
|
|
- [ ] **TASK-CONF-006** : Nettoyer TODO/FIXME frontend
|
|||
|
|
- Traiter les 43 TODO/FIXME identifies dans le frontend
|
|||
|
|
- Resoudre ou convertir en issues trackees
|
|||
|
|
- Cible: < 10 TODO/FIXME restants
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] F020 2FA SMS fonctionnel de bout en bout
|
|||
|
|
- [ ] F029 CAPTCHA actif sur registration et login
|
|||
|
|
- [ ] Features auth partielles completees (F010, F013, F014, F018, F021, F024, F026)
|
|||
|
|
- [ ] Structure handlers unifiee ou nettoyee
|
|||
|
|
- [ ] TODO/FIXME < 10
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Integration SMS provider necessite un compte et des couts
|
|||
|
|
- Migration handlers peut causer des regressions si routes mal recablees
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.13.1 — Conformite Audio & Player
|
|||
|
|
|
|||
|
|
**Priorite** : P2
|
|||
|
|
**Effort** : 4-5 jours
|
|||
|
|
**Prerequisite** : v0.13.0
|
|||
|
|
**GO/NO-GO** : `Qualite`
|
|||
|
|
|
|||
|
|
**Contexte** : Plusieurs features du module 4 (Streaming Audio, F106-F150) sont partielles ou absentes.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-AUDIO-001** : Gapless playback (F116)
|
|||
|
|
- Implementer la lecture sans interruption entre deux tracks
|
|||
|
|
- Utiliser Web Audio API pour le pre-buffering du track suivant
|
|||
|
|
- Fichiers: `apps/web/src/components/player/`, stream server
|
|||
|
|
|
|||
|
|
- [ ] **TASK-AUDIO-002** : Crossfade (F117) — si absent
|
|||
|
|
- Verifier l'etat actuel du crossfade
|
|||
|
|
- Implementer le fondu enchaine configurable (1-12s)
|
|||
|
|
|
|||
|
|
- [ ] **TASK-AUDIO-003** : Normalisation audio (F118) — si absent
|
|||
|
|
- Normalisation du volume entre tracks (ReplayGain ou equivalent)
|
|||
|
|
- Cote serveur (Rust) ou cote client (Web Audio API)
|
|||
|
|
|
|||
|
|
- [ ] **TASK-AUDIO-004** : Completer les features player partielles
|
|||
|
|
- Verifier F106-F115 (play, pause, seek, volume, queue, shuffle, repeat, progress, waveform)
|
|||
|
|
- Completer les tests pour chaque feature player
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] Gapless playback fonctionne entre deux tracks consecutifs
|
|||
|
|
- [ ] Crossfade configurable
|
|||
|
|
- [ ] Pas de saut de volume entre tracks
|
|||
|
|
- [ ] Toutes les features player core testees
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Gapless playback complexe sur mobile/PWA (limitations navigateur)
|
|||
|
|
- Performance Web Audio API a valider
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.13.2 — Consolidation Design System
|
|||
|
|
|
|||
|
|
**Priorite** : P2
|
|||
|
|
**Effort** : 2-3 jours
|
|||
|
|
**Prerequisite** : v0.13.0
|
|||
|
|
**GO/NO-GO** : `Qualite → 0 linting error`
|
|||
|
|
|
|||
|
|
**Contexte** : Le package `packages/design-system/` est quasi vide (1 fichier). Les composants SUMI sont dans `apps/web/src/components/ui/`. Cela cree de la duplication et empeche la reutilisation entre apps.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-DS-001** : Migrer les composants SUMI vers le design system
|
|||
|
|
- Deplacer les composants UI de base de `apps/web/src/components/ui/` vers `packages/design-system/src/`
|
|||
|
|
- Exporter proprement depuis `packages/design-system/`
|
|||
|
|
- Mettre a jour les imports dans `apps/web/`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-DS-002** : Design tokens
|
|||
|
|
- Extraire les tokens (couleurs, typo, spacing, shadows, radius) dans le package
|
|||
|
|
- S'assurer que dark mode et light mode utilisent les memes tokens
|
|||
|
|
- Ref: ORIGIN_UI_UX_SYSTEM.md §design tokens
|
|||
|
|
|
|||
|
|
- [ ] **TASK-DS-003** : Documentation Storybook
|
|||
|
|
- Verifier que les stories existantes couvrent les composants principaux
|
|||
|
|
- Ajouter les stories manquantes pour les composants migres
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] `packages/design-system/` contient les composants UI de base
|
|||
|
|
- [ ] Design tokens centralises et utilises par toutes les apps
|
|||
|
|
- [ ] Stories a jour pour les composants principaux
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Nombre de composants a migrer potentiellement important
|
|||
|
|
- Risque de casser les imports dans l'app web
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.13.3 — Polish Securite Avancee
|
|||
|
|
|
|||
|
|
**Priorite** : P3
|
|||
|
|
**Effort** : 3-4 jours
|
|||
|
|
**Prerequisite** : v0.13.0
|
|||
|
|
**GO/NO-GO** : Partiel (`Securite`)
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-SECADV-001** : Passkeys/WebAuthn (F022)
|
|||
|
|
- Implementer l'enregistrement et l'authentification par passkeys
|
|||
|
|
- Utiliser la Web Authentication API
|
|||
|
|
- Backend: `backend/internal/auth/webauthn_service.go`
|
|||
|
|
- Frontend: `apps/web/src/pages/auth/passkeys/`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-SECADV-002** : Password configurable policy (F015)
|
|||
|
|
- Politique de mot de passe configurable par l'admin
|
|||
|
|
- Longueur min, complexite, expiration
|
|||
|
|
|
|||
|
|
- [ ] **TASK-SECADV-003** : Geolocalisation connexions (F025)
|
|||
|
|
- Detection IP → pays via MaxMind GeoIP ou equivalent
|
|||
|
|
- Notification si connexion depuis un nouveau pays
|
|||
|
|
- Affichage dans l'historique des sessions
|
|||
|
|
|
|||
|
|
- [ ] **TASK-SECADV-004** : Password expiration (F016) — optionnel
|
|||
|
|
- Politique d'expiration configurable
|
|||
|
|
- Notification avant expiration
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] WebAuthn fonctionnel (enregistrement + login)
|
|||
|
|
- [ ] Geolocalisation des connexions affichee
|
|||
|
|
- [ ] Politique de mot de passe configurable
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- WebAuthn complexe a implementer correctement
|
|||
|
|
- GeoIP necessite une base de donnees (licence MaxMind)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.13.4 — Polish Audio & Player
|
|||
|
|
|
|||
|
|
**Priorite** : P3
|
|||
|
|
**Effort** : 3-4 jours
|
|||
|
|
**Prerequisite** : v0.13.1
|
|||
|
|
**GO/NO-GO** : —
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-APLSH-001** : Picture-in-picture (F121)
|
|||
|
|
- Implementer le mode picture-in-picture pour le player
|
|||
|
|
- Utiliser l'API Picture-in-Picture du navigateur
|
|||
|
|
|
|||
|
|
- [ ] **TASK-APLSH-002** : Chromecast support (F124) — optionnel v1.0
|
|||
|
|
- Integrer le SDK Cast
|
|||
|
|
- Streaming vers Chromecast
|
|||
|
|
|
|||
|
|
- [ ] **TASK-APLSH-003** : AirPlay support (F125) — optionnel v1.0
|
|||
|
|
- Streaming vers appareils AirPlay
|
|||
|
|
|
|||
|
|
- [ ] **TASK-APLSH-004** : Spectrogram/Equalizer visualiseurs
|
|||
|
|
- Visualisation audio temps reel (Web Audio API AnalyserNode)
|
|||
|
|
- Equalizer graphique basique
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] Picture-in-picture fonctionne sur les navigateurs supportes
|
|||
|
|
- [ ] Au moins un visualiseur audio basique
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Chromecast/AirPlay dependent des SDKs proprietaires
|
|||
|
|
- Peut etre reporte en v1.1 sans bloquer le GO/NO-GO
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.13.5 — Polish Marketplace & Compliance
|
|||
|
|
|
|||
|
|
**Priorite** : P3
|
|||
|
|
**Effort** : 3-4 jours
|
|||
|
|
**Prerequisite** : v0.13.0
|
|||
|
|
**GO/NO-GO** : `Business → Flux de paiement teste E2E`
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-MKT-001** : KYC vendeurs (F055)
|
|||
|
|
- Verification d'identite pour les vendeurs marketplace
|
|||
|
|
- Integration avec un service KYC (Stripe Identity ou equivalent)
|
|||
|
|
- Fichiers: `backend/internal/service/kyc_service.go`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-MKT-002** : Validation E2E flux de paiement
|
|||
|
|
- Test complet: creation produit → achat → paiement → download
|
|||
|
|
- Test avec Hyperswitch en mode test
|
|||
|
|
- Documenter le flux
|
|||
|
|
|
|||
|
|
- [ ] **TASK-MKT-003** : Validation E2E flux de payout createur
|
|||
|
|
- Test complet: ventes accumulees → seuil $50 → payout automatique
|
|||
|
|
- Documenter le flux
|
|||
|
|
|
|||
|
|
- [ ] **TASK-MKT-004** : Page support accessible
|
|||
|
|
- Page de contact / helpdesk
|
|||
|
|
- Au minimum: formulaire de contact email
|
|||
|
|
- Ref: GO/NO-GO `Business → Support accessible`
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] KYC vendeurs fonctionnel
|
|||
|
|
- [ ] Flux paiement teste E2E
|
|||
|
|
- [ ] Flux payout teste E2E
|
|||
|
|
- [ ] Page support accessible
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- KYC necessite un provider externe avec des couts
|
|||
|
|
- Tests E2E paiement necessitent un environnement Hyperswitch fonctionnel
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v0.14.0 — Validation Runtime & Staging
|
|||
|
|
|
|||
|
|
**Priorite** : P0-P1
|
|||
|
|
**Effort** : 3-5 jours
|
|||
|
|
**Prerequisite** : v0.13.2
|
|||
|
|
**GO/NO-GO** : `Stabilite`, `Performance`
|
|||
|
|
|
|||
|
|
**Contexte** : De nombreux criteres GO/NO-GO ne peuvent etre valides que sur un environnement live (staging). Cette version est dediee aux validations runtime.
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-STAG-001** : Deploiement staging
|
|||
|
|
- Deployer l'ensemble de la stack sur un environnement staging
|
|||
|
|
- Verifier que tous les services demarrent correctement
|
|||
|
|
- Ref: critere non coche v0.9.1
|
|||
|
|
|
|||
|
|
- [ ] **TASK-STAG-002** : Validation performances
|
|||
|
|
- Executer les tests k6 existants
|
|||
|
|
- Mesurer: p95 API < 100ms, p99 < 200ms
|
|||
|
|
- Mesurer: audio stream start < 500ms
|
|||
|
|
- Mesurer: search results < 500ms
|
|||
|
|
|
|||
|
|
- [ ] **TASK-STAG-003** : Validation Lighthouse
|
|||
|
|
- Executer Lighthouse sur les pages principales
|
|||
|
|
- Cibles: Performance >= 85, Accessibility >= 90, PWA >= 90
|
|||
|
|
- Ref: critere non coche v0.11.0
|
|||
|
|
|
|||
|
|
- [ ] **TASK-STAG-004** : Validation stabilite
|
|||
|
|
- Monitorer pendant 48h minimum
|
|||
|
|
- Verifier: taux erreur 5xx < 0.1%
|
|||
|
|
- Verifier: aucun crash/restart non planifie
|
|||
|
|
|
|||
|
|
- [ ] **TASK-STAG-005** : Validation RGPD
|
|||
|
|
- Tester export de donnees utilisateur de bout en bout
|
|||
|
|
- Tester suppression de compte de bout en bout
|
|||
|
|
- Verifier anonymisation effective
|
|||
|
|
|
|||
|
|
- [ ] **TASK-STAG-006** : Validation bundle size
|
|||
|
|
- Verifier: bundle JS initial < 200KB gzip
|
|||
|
|
- Documenter le resultat
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] Staging deploye et fonctionnel
|
|||
|
|
- [ ] p95 API < 100ms
|
|||
|
|
- [ ] Lighthouse Performance >= 85, Accessibility >= 90
|
|||
|
|
- [ ] Taux erreur 5xx < 0.1% sur 48h
|
|||
|
|
- [ ] RGPD export + suppression fonctionnels
|
|||
|
|
- [ ] Bundle < 200KB gzip
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Infrastructure staging peut ne pas etre disponible
|
|||
|
|
- Les metriques runtime peuvent reveler des problemes non detectes en dev
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v1.0.0-rc1 — Release Candidate 1
|
|||
|
|
|
|||
|
|
**Priorite** : —
|
|||
|
|
**Effort** : 2-3 jours
|
|||
|
|
**Prerequisite** : Toutes les versions precedentes
|
|||
|
|
**GO/NO-GO** : Validation finale de tous les criteres
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-RC-001** : Checklist GO/NO-GO complete
|
|||
|
|
- Parcourir chaque critere GO/NO-GO et cocher
|
|||
|
|
- Documenter les preuves pour chaque critere
|
|||
|
|
- Fichier: `veza-docs/GO_NO_GO_CHECKLIST.md`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-RC-002** : Audit final anti-dark-patterns
|
|||
|
|
- Parcours complet de l'UI
|
|||
|
|
- Verifier: 0 FOMO, 0 gamification, 0 metriques publiques, 0 friction desinscription
|
|||
|
|
- Documenter le resultat
|
|||
|
|
|
|||
|
|
- [ ] **TASK-RC-003** : Politique de confidentialite
|
|||
|
|
- Verifier que la politique de confidentialite est a jour
|
|||
|
|
- Conforme RGPD
|
|||
|
|
- Ref: GO/NO-GO Ethique
|
|||
|
|
|
|||
|
|
- [ ] **TASK-RC-004** : Documentation decouverte
|
|||
|
|
- Verifier que le document `DISCOVERY_ALGORITHM.md` est complet et auditable
|
|||
|
|
- Ref: GO/NO-GO Ethique → Algorithme de decouverte documente
|
|||
|
|
|
|||
|
|
- [ ] **TASK-RC-005** : Freeze du code
|
|||
|
|
- Branche `release/v1.0.0` creee
|
|||
|
|
- Seuls les bugfixes critiques acceptes
|
|||
|
|
- CI/CD verte depuis 2 semaines minimum
|
|||
|
|
|
|||
|
|
- [ ] **TASK-RC-006** : Re-pentest final (optionnel)
|
|||
|
|
- Si les correctifs pentest sont significatifs, un re-scan peut etre necessaire
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] 100% des criteres GO/NO-GO coches
|
|||
|
|
- [ ] Branche release creee
|
|||
|
|
- [ ] CI/CD verte
|
|||
|
|
|
|||
|
|
**Risques**
|
|||
|
|
- Des criteres GO/NO-GO peuvent echouer → retour a la version correspondante
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### v1.0.0 — Release Stable
|
|||
|
|
|
|||
|
|
**Priorite** : —
|
|||
|
|
**Effort** : 1-2 jours
|
|||
|
|
**Prerequisite** : v1.0.0-rc1 validee
|
|||
|
|
|
|||
|
|
**Taches**
|
|||
|
|
|
|||
|
|
- [ ] **TASK-REL-001** : Tag v1.0.0
|
|||
|
|
- `git tag -a v1.0.0 -m "Version 1.0.0 : Release Stable"`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-REL-002** : Release notes
|
|||
|
|
- Changelog complet depuis v0.9.1
|
|||
|
|
- Features highlights
|
|||
|
|
- Fichier: `CHANGELOG.md`
|
|||
|
|
|
|||
|
|
- [ ] **TASK-REL-003** : Deploiement production
|
|||
|
|
- Pipeline CI/CD production
|
|||
|
|
- Validation post-deploiement
|
|||
|
|
|
|||
|
|
**Criteres d'acceptation**
|
|||
|
|
- [ ] Tag v1.0.0 cree
|
|||
|
|
- [ ] Release notes publiees
|
|||
|
|
- [ ] Deploiement production reussi
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. MAPPING GO/NO-GO ↔ VERSIONS
|
|||
|
|
|
|||
|
|
Chaque critere GO/NO-GO est couvert par au moins une version de cette roadmap.
|
|||
|
|
|
|||
|
|
### Securite
|
|||
|
|
|
|||
|
|
| Critere | Version(s) | Statut actuel |
|
|||
|
|
|---------|-----------|---------------|
|
|||
|
|
| JWT RS256 en production | v0.9.1 (DONE) | ✅ Implemente |
|
|||
|
|
| Aucun secret dans le repo git | v0.9.1 (DONE) | ✅ Implemente |
|
|||
|
|
| Pentest valide (0 CRIT/HIGH ouvert) | v0.12.6.1 (DONE) | ✅ 30/30 findings corriges (0 ouvert) |
|
|||
|
|
| RGPD export + suppression | v0.10.8 (DONE) + **v0.14.0** | ⚠️ Code OK, validation runtime requise |
|
|||
|
|
|
|||
|
|
### Stabilite
|
|||
|
|
|
|||
|
|
| Critere | Version(s) | Statut actuel |
|
|||
|
|
|---------|-----------|---------------|
|
|||
|
|
| Uptime >= 99.9% (30j) | **v0.14.0** | ❌ Non mesure |
|
|||
|
|
| Taux erreur 5xx < 0.1% | **v0.14.0** | ❌ Non mesure |
|
|||
|
|
| Aucun incident P0 non resolu | **v0.14.0** | ⚠️ A verifier |
|
|||
|
|
|
|||
|
|
### Performance
|
|||
|
|
|
|||
|
|
| Critere | Version(s) | Statut actuel |
|
|||
|
|
|---------|-----------|---------------|
|
|||
|
|
| p95 API < 100ms | v0.12.4 (DONE) + **v0.14.0** | ⚠️ Optimise, non mesure runtime |
|
|||
|
|
| Lighthouse Performance >= 85 | v0.12.5 (DONE) + **v0.14.0** | ⚠️ PWA OK, non mesure |
|
|||
|
|
| Lighthouse Accessibility >= 90 | v0.12.5 (DONE) + **v0.14.0** | ⚠️ WCAG AA OK, non mesure |
|
|||
|
|
| Lighthouse PWA >= 90 | v0.12.5 (DONE) + **v0.14.0** | ⚠️ PWA OK, non mesure |
|
|||
|
|
|
|||
|
|
### Qualite
|
|||
|
|
|
|||
|
|
| Critere | Version(s) | Statut actuel |
|
|||
|
|
|---------|-----------|---------------|
|
|||
|
|
| Coverage >= 70% (Go + Rust) | **v0.12.9** | ❌ Non mesuree |
|
|||
|
|
| 0 linting error | v0.9.4 (DONE) + **v0.13.0** | ⚠️ CI lint OK, 43 TODO frontend |
|
|||
|
|
| CI/CD verte 2 semaines | **v1.0.0-rc1** | ❌ A valider |
|
|||
|
|
|
|||
|
|
### Ethique
|
|||
|
|
|
|||
|
|
| Critere | Version(s) | Statut actuel |
|
|||
|
|
|---------|-----------|---------------|
|
|||
|
|
| Audit UX anti-dark-patterns | **v0.12.6.3** + **v1.0.0-rc1** | ⚠️ Code clean, audit formel non fait |
|
|||
|
|
| Aucune donnee comportementale revendue | **v0.12.6.3** | ✅ Pas de code de revente |
|
|||
|
|
| Algorithme decouverte documente | **v0.12.9** | ❌ Non documente |
|
|||
|
|
| Politique confidentialite RGPD | **v1.0.0-rc1** | ❌ A verifier/creer |
|
|||
|
|
|
|||
|
|
### Business
|
|||
|
|
|
|||
|
|
| Critere | Version(s) | Statut actuel |
|
|||
|
|
|---------|-----------|---------------|
|
|||
|
|
| Flux paiement teste E2E | v0.12.0 (DONE) + **v0.13.5** | ⚠️ Code OK, test E2E formel requis |
|
|||
|
|
| Flux payout createur teste | v0.12.0 (DONE) + **v0.13.5** | ⚠️ Code OK, test E2E formel requis |
|
|||
|
|
| Support accessible | **v0.13.5** | ❌ Non implemente |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. CRITERES NON COCHES DES VERSIONS DONE — RESOLUTION
|
|||
|
|
|
|||
|
|
Les 10 criteres non coches dans les versions DONE sont resolus par cette roadmap :
|
|||
|
|
|
|||
|
|
| Version DONE | Critere non coche | Resolution |
|
|||
|
|
|--------------|-------------------|------------|
|
|||
|
|
| v0.9.1 | Deploiement staging | **v0.14.0** TASK-STAG-001 |
|
|||
|
|
| v0.9.2 | Pentest partiel | v0.12.6.1 (DONE) — pentest revalide |
|
|||
|
|
| v0.9.5 | Tests pass | Verifier en CI, **v0.12.9** coverage |
|
|||
|
|
| v0.9.8 | Coverage 70% | **v0.12.9** TASK-COV-001 |
|
|||
|
|
| v0.10.0 | Perf metrics staging | **v0.14.0** TASK-STAG-002 |
|
|||
|
|
| v0.10.1 | Test biais emergents | **v0.12.9** TASK-ETH-001 |
|
|||
|
|
| v0.10.2 | Test 0-plays search | **v0.12.9** TASK-ETH-002 |
|
|||
|
|
| v0.11.0 | Lighthouse scores | **v0.14.0** TASK-STAG-003 |
|
|||
|
|
| v0.12.6 | 2 CRIT + 10 HIGH findings | v0.12.6.1 (DONE) — 30/30 corriges |
|
|||
|
|
|
|||
|
|
Tous les 10 criteres sont couverts.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 6. DIAGRAMME GANTT SIMPLIFIE
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Semaine S1 S2 S3 S4 S5 S6 S7 S8 S9 S10
|
|||
|
|
-------- -------- -------- -------- -------- -------- -------- -------- -------- --------
|
|||
|
|
|
|||
|
|
P0 SECURITE
|
|||
|
|
v0.12.6.1 [=====]
|
|||
|
|
v0.12.6.2 [===]
|
|||
|
|
|
|||
|
|
P1 BLOQUANTS
|
|||
|
|
v0.12.6.3 [====]
|
|||
|
|
v0.12.7 [========]
|
|||
|
|
v0.12.8 [========]
|
|||
|
|
v0.12.9 [======]
|
|||
|
|
|
|||
|
|
P2 CONFORMITE
|
|||
|
|
v0.13.0 [============]
|
|||
|
|
v0.13.1 [==========]
|
|||
|
|
v0.13.2 [======]
|
|||
|
|
|
|||
|
|
P3 POLISH
|
|||
|
|
v0.13.3 [========]
|
|||
|
|
v0.13.4 [========]
|
|||
|
|
v0.13.5 [========]
|
|||
|
|
|
|||
|
|
P0-P1 VALIDATION
|
|||
|
|
v0.14.0 [==========]
|
|||
|
|
|
|||
|
|
RELEASE
|
|||
|
|
v1.0.0-rc1 [======]
|
|||
|
|
v1.0.0 [====]
|
|||
|
|
|
|||
|
|
JALONS ^M1 ^M2 ^M3 ^M4 ^M5 ^v1.0
|
|||
|
|
Secu OK i18n+API done Features done Polish done RC RELEASE
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Jalons cles** :
|
|||
|
|
- **M1 (fin S2)** : Securite P0 resolue — 0 finding critique/haut, MFA admin, token TTL 7j
|
|||
|
|
- **M2 (fin S4)** : Versions TODO existantes completees (i18n + API docs) + tests ethiques + coverage CI
|
|||
|
|
- **M3 (fin S6)** : Conformite features completee — ecarts spec/code P2 resolus
|
|||
|
|
- **M4 (fin S8)** : Polish termine — securite avancee, audio, marketplace
|
|||
|
|
- **M5 (fin S9)** : Staging valide, metriques runtime OK, RC1 prete
|
|||
|
|
- **v1.0 (fin S10)** : Release stable
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 7. CHEMINS CRITIQUES
|
|||
|
|
|
|||
|
|
### Chemin critique principal (bloque v1.0)
|
|||
|
|
```
|
|||
|
|
v0.12.6.1 (pentest) → v0.12.6.2 (MFA/TTL) → v0.12.6.3 (fantomes)
|
|||
|
|
↓
|
|||
|
|
v0.12.7 (i18n) ──────────────────────────────→ v0.12.9 (ethique/coverage)
|
|||
|
|
v0.12.8 (API docs) ─────────────────────────→ ↓
|
|||
|
|
v0.13.0 (conformite)
|
|||
|
|
↓
|
|||
|
|
v0.13.2 (design system)
|
|||
|
|
↓
|
|||
|
|
v0.14.0 (staging/runtime)
|
|||
|
|
↓
|
|||
|
|
v1.0.0-rc1 → v1.0.0
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Parallelisation possible
|
|||
|
|
```
|
|||
|
|
PARALLELE A (securite) PARALLELE B (features)
|
|||
|
|
v0.12.6.1 v0.12.7 (i18n)
|
|||
|
|
v0.12.6.2 v0.12.8 (API docs)
|
|||
|
|
v0.12.6.3
|
|||
|
|
|
|||
|
|
\ /
|
|||
|
|
→ v0.12.9 (ethique) ←
|
|||
|
|
↓
|
|||
|
|
v0.13.0 (conformite)
|
|||
|
|
/ \
|
|||
|
|
v0.13.1 (audio) v0.13.2 (design)
|
|||
|
|
v0.13.4 (polish) v0.13.3 (sec adv)
|
|||
|
|
v0.13.5 (marketplace)
|
|||
|
|
\ /
|
|||
|
|
→ v0.14.0 (staging) ←
|
|||
|
|
↓
|
|||
|
|
v1.0.0-rc1
|
|||
|
|
↓
|
|||
|
|
v1.0.0
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Avec 2 developpeurs, le chemin critique passe de ~10 semaines a ~6-7 semaines grace a la parallelisation des branches securite et features.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 8. FEATURES REPORTEES POST-v1.0
|
|||
|
|
|
|||
|
|
Les features suivantes sont classees P4 et ne bloquent pas la v1.0. Elles seront implementees en v1.1+ :
|
|||
|
|
|
|||
|
|
| Feature | Ref | Effort | Justification report |
|
|||
|
|
|---------|-----|--------|---------------------|
|
|||
|
|
| Chromecast (F124) | Module 4 | 2-3j | SDK proprietaire, complexe |
|
|||
|
|
| AirPlay (F125) | Module 4 | 2-3j | SDK proprietaire, complexe |
|
|||
|
|
| IP whitelisting (F027) | Module 1 | 1j | Feature entreprise, pas consumer |
|
|||
|
|
| Watermarking (F080) | Module 3 | 2j | Nice-to-have, pas bloquant |
|
|||
|
|
| Spectrogram visualiseur | Module 4 | 3j | Cosmetique |
|
|||
|
|
| Equalizer graphique | Module 4 | 2j | Cosmetique |
|
|||
|
|
| Password expiration (F016) | Module 1 | 1j | Optionnel securite |
|
|||
|
|
| Module 9 Gestion Materiel complet | F306-F330 | 5-10j | Scope P3, partiellement implemente |
|
|||
|
|
| Module 17 Collaboration complete | F481-F490 | 5j | Partiellement implemente, avance |
|
|||
|
|
|
|||
|
|
**Total reporte** : ~25-35 jours-dev en v1.1+
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 9. ESTIMATION GLOBALE
|
|||
|
|
|
|||
|
|
### Effort par priorite
|
|||
|
|
|
|||
|
|
| Priorite | Versions | Effort total |
|
|||
|
|
|----------|----------|-------------|
|
|||
|
|
| P0 | ~~v0.12.6.1~~ (DONE), v0.12.6.2 | 1.5j restant |
|
|||
|
|
| P1 | v0.12.6.3, v0.12.7, v0.12.8, v0.12.9 | 9.5-13j |
|
|||
|
|
| P2 | v0.13.0, v0.13.1, v0.13.2 | 11-15j |
|
|||
|
|
| P3 | v0.13.3, v0.13.4, v0.13.5 | 9-12j |
|
|||
|
|
| Validation | v0.14.0 | 3-5j |
|
|||
|
|
| Release | v1.0.0-rc1, v1.0.0 | 3-5j |
|
|||
|
|
| **TOTAL** | **15 versions** | **42-59.5j** |
|
|||
|
|
|
|||
|
|
### Scenarios
|
|||
|
|
|
|||
|
|
| Scenario | Equipe | Duree | Date estimee v1.0 |
|
|||
|
|
|----------|--------|-------|--------------------|
|
|||
|
|
| Optimiste | 2 devs | 6 semaines | 2026-04-22 |
|
|||
|
|
| Realiste | 1 dev | 10 semaines | 2026-05-20 |
|
|||
|
|
| Pessimiste | 1 dev + imprevu | 14 semaines | 2026-06-17 |
|
|||
|
|
|
|||
|
|
### Facteurs de risque
|
|||
|
|
|
|||
|
|
| Risque | Impact | Probabilite | Mitigation |
|
|||
|
|
|--------|--------|-------------|------------|
|
|||
|
|
| Findings pentest necessitent refactoring majeur | +2-5j | Moyenne | Identifier tot, isoler les changements |
|
|||
|
|
| Coverage Rust difficile a monter | +2-3j | Haute | Prioriser les tests critiques |
|
|||
|
|
| Infrastructure staging non disponible | +1-2 semaines | Moyenne | Utiliser docker-compose comme staging minimal |
|
|||
|
|
| Traductions ES incompletes | +1-2j | Basse | Accepter placeholders EN pour v1.0 |
|
|||
|
|
| Tests E2E paiement echouent | +2-3j | Moyenne | Tester en mode sandbox Hyperswitch |
|
|||
|
|
| WebAuthn trop complexe pour le calendrier | 0 (report v1.1) | Haute | Declasser en P4 si necessaire |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 10. RECOMMANDATIONS
|
|||
|
|
|
|||
|
|
### Recommandation 1 : Commencer par P0 immediatement
|
|||
|
|
Les 3 findings HIGH du pentest bloquent tout. Il faut les corriger avant toute autre chose. En parallele, un second developpeur peut attaquer v0.12.7 (i18n).
|
|||
|
|
|
|||
|
|
### Recommandation 2 : Ne pas sous-estimer v0.14.0
|
|||
|
|
La validation runtime (staging) est le goulot d'etranglement. Beaucoup de criteres GO/NO-GO ne seront verifiables qu'a ce stade. Preparer l'infrastructure staging le plus tot possible.
|
|||
|
|
|
|||
|
|
### Recommandation 3 : Etre pret a reporter des features P3
|
|||
|
|
Si le calendrier se tend, les features P3 (WebAuthn, Chromecast/AirPlay, spectrogram, KYC) peuvent etre reportees en v1.1 sans affecter la validite du GO/NO-GO.
|
|||
|
|
|
|||
|
|
### Recommandation 4 : Automatiser les validations
|
|||
|
|
Integrer les checks Lighthouse, coverage, et anti-dark-patterns dans la CI pour detecter les regressions automatiquement plutot qu'en validation finale.
|
|||
|
|
|
|||
|
|
### Recommandation 5 : Clarifier le statut des features fantomes
|
|||
|
|
Les modules `contest`, `voting_system`, `production_challenge` doivent etre evalues immediatement. S'ils constituent de la gamification, leur presence est un risque ethique meme s'ils sont desactives.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
*Fin de la roadmap Phase 5*
|