# Plan d'action post-audit — Veza Monorepo

**Date** : 2026-02-22
**Base** : AUDIT_TECHNIQUE_2026-02-22.md (Cursor/Claude 4.6 Opus)
**Périmètre** : v0.404 (stabilisation) + préparation v0.501

---

## Légende

| Symbole | Signification |
|---------|---------------|
| 🔴 | Bloquant production — doit être corrigé avant tout déploiement |
| 🟠 | Élevé — doit être corrigé avant la fin de v0.404 |
| 🟡 | Moyen — planifiable en v0.404 ou début v0.501 |
| S | < 1 jour |
| M | 1–3 jours |
| L | 3–5 jours |
| XL | > 5 jours |

---

## Sprint 1 — Sécurité critique (jours 1–5)

> **Objectif** : Éliminer les vulnérabilités exploitables. Aucune feature, aucun refactoring.

| # | Ticket | Gravité | Effort | Fichiers impactés | Critère de complétion |
|---|--------|---------|--------|--------------------|-----------------------|
| 001 | **Fixer pipeline CD** — remplacer `if: secrets.*` par `if: vars.*` dans les conditions GitHub Actions. Ajouter `needs: ci` sur le job deploy. Pointer sur `Dockerfile.production`. | 🔴 | S | `.github/workflows/cd.yml` | Pipeline CD exécute push+deploy sur merge main |
| 002 | **Auth Redis production** — ajouter `--requirepass $REDIS_PASSWORD` au service Redis dans le compose prod. Propager `REDIS_PASSWORD` dans les env du backend et des services Rust. | 🔴 | S | `docker-compose.prod.yml`, `config.go` (Redis init), `chat-server/config.rs`, `stream-server/config.rs` | Redis refuse les connexions sans mot de passe |
| 003 | **Fixer auth HLS/WebSocket** — implémenter un endpoint `POST /auth/stream-token` qui génère un token éphémère (5 min, usage unique, scope streaming). Le frontend l'utilise en query param pour WS et HLS au lieu de `TokenStorage.getAccessToken()`. | 🔴 | M | Backend : nouveau handler `auth/stream_token.go`, middleware stream auth. Frontend : `hlsService.ts`, `websocket.ts`, `tokenStorage.ts` | HLS playback et WebSocket chat fonctionnent avec auth valide |
| 004 | **Supprimer `docker-compose.hybrid.yml`** ou retirer `network_mode: host` + changer le mot de passe Grafana par défaut | 🔴 | S | `docker-compose.hybrid.yml` | Fichier supprimé ou sécurisé |
| 005 | **JWT_SECRET pour stream-server** — ajouter la variable dans le compose prod, vérifier que le stream-server valide les tokens avec le même secret que le backend | 🔴 | S | `docker-compose.prod.yml:217`, `stream-server/config.rs` | Stream-server rejette les requêtes sans JWT valide |
| 006 | **Fixer IDOR GetUploadStatus** — ajouter vérification `upload.user_id == authenticated_user.id` | 🟠 | S | `internal/handlers/upload.go:308` | Un user ne peut voir que ses propres uploads |
| 007 | **Validation SSRF webhooks** — whitelist schémas (https uniquement), bloquer IPs privées (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16) dans le webhook delivery service | 🟠 | S | `webhook_handlers.go`, webhook delivery service | Les webhooks ne peuvent cibler que des URLs publiques HTTPS |
| 008 | **Vérifier signature webhook Hyperswitch** — implémenter validation HMAC-SHA256 sur le handler de callback paiement. Rejeter tout webhook sans signature valide. | 🟠 | M | Handler webhook paiement (localiser dans `internal/handlers/`) | Webhooks sans signature valide retournent 401 |
| 009 | **Unifier version Go** — 1.24 dans go.mod, go.work, CI workflows (`ci.yml`, `backend-ci.yml`), et `Dockerfile.production` | 🟠 | S | `go.mod`, `go.work`, `.github/workflows/ci.yml`, `.github/workflows/backend-ci.yml`, `Dockerfile.production` | `go version` identique partout |
| 010 | **Migrer secrets CI** — déplacer toute credential en clair dans les workflows vers GitHub Secrets. Vérifier qu'aucun secret ne reste dans les fichiers YAML. | 🟠 | S | `.github/workflows/*.yml` | `grep -r "password\|secret\|token" .github/` ne retourne rien de sensible |

**Livrable Sprint 1** : Tag `v0.404-alpha1`. Les 5 blocages critiques de l'audit sont résolus.

---

## Sprint 2 — Infra & CI/CD (jours 6–12)

> **Objectif** : Rendre le pipeline de déploiement fiable et le monitoring opérationnel.

| # | Ticket | Gravité | Effort | Fichiers impactés | Critère de complétion |
|---|--------|---------|--------|--------------------|-----------------------|
| 011 | **Migrer rate limiter vers Redis** — remplacer le rate limiter in-memory par un rate limiter basé sur Redis (clé `ratelimit:{user_id}:{route}`, TTL sliding window). Conserver le fallback in-memory si Redis est down. | 🟠 | M | `internal/middleware/ratelimit.go`, `internal/config/config.go` | Rate limiting fonctionne en multi-instance. Test : 2 instances, la limite s'applique globalement. |
| 012 | **Aligner PostgreSQL 16 partout** — remplacer `postgres:15-alpine` par `postgres:16-alpine` dans test et hybrid composes | 🟠 | S | `docker-compose.test.yml`, `docker-compose.hybrid.yml` | Toutes les composes utilisent PG 16 |
| 013 | **Fixer `frontend-ci.yml`** — ajouter étapes lint (`eslint`), typecheck (`tsc --noEmit`), build (`vite build`) | 🟠 | S | `.github/workflows/frontend-ci.yml` | Les PRs frontend échouent si lint, typecheck ou build échouent |
| 014 | **Ajouter `go vet` et `gofmt` en CI** — étape dédiée dans le workflow backend | 🟡 | S | `.github/workflows/backend-ci.yml` | `go vet ./...` et `gofmt -l .` exécutés en CI |
| 015 | **Ajouter `clippy` en CI pour les services Rust** | 🟡 | S | `.github/workflows/ci.yml` (ou nouveau `rust-ci.yml`) | `cargo clippy -- -D warnings` exécuté en CI pour chat + stream |
| 016 | **Ajouter SAST** — configurer CodeQL ou Semgrep dans un workflow dédié, couvrant Go + TypeScript | 🟡 | M | Nouveau `.github/workflows/sast.yml` | SAST s'exécute sur chaque PR, résultats visibles dans les checks |
| 017 | **Compléter staging compose** — ajouter chat-server, stream-server, et reverse proxy (Caddy/Nginx) au compose staging | 🟡 | M | `docker-compose.staging.yml` (créer ou compléter) | `docker compose -f docker-compose.staging.yml up` démarre tous les services |
| 018 | **Ajouter alerting Prometheus** — configurer des alertes pour : service down > 30s, error rate > 5%, latence P99 > 2s, Redis unreachable | 🟡 | M | `config/prometheus/`, nouveau `config/alertmanager/` | Alertes se déclenchent quand les seuils sont dépassés |
| 019 | **Health checks Docker** — ajouter `healthcheck` pour chaque service dans les composes prod et staging | 🟡 | S | `docker-compose.prod.yml`, `docker-compose.staging.yml` | `docker compose ps` montre le statut santé de chaque service |
| 020 | **Implémenter hash des reset tokens** — hasher les password reset tokens en base (SHA-256), comparer le hash lors de la validation | 🟡 | S | Handler password reset, migration (ajouter colonne `token_hash` si nécessaire) | Un dump DB ne permet pas d'utiliser les reset tokens |

**Livrable Sprint 2** : Tag `v0.404-alpha2`. CI/CD fiable, monitoring avec alertes, infra sécurisée.

---

## Sprint 3 — Nettoyage & Qualité code (jours 13–20)

> **Objectif** : Réduire la dette technique critique, éliminer le code mort, aligner doc et réalité.

| # | Ticket | Gravité | Effort | Fichiers impactés | Critère de complétion |
|---|--------|---------|--------|--------------------|-----------------------|
| 021 | **Supprimer code mort** (~13K LOC) — `internal/api/archive/api_manager.go` (789 LOC), `dev-environment/templates/` non utilisés, `fixtures/` vide, `packages/` vide, `veza-docs/` non alimenté | 🟡 | M | Voir liste. Vérifier avec `grep -r` qu'aucun import ne référence ces fichiers. | LOC total réduit de ~13K. Aucune régression. |
| 022 | **Supprimer/corriger mocks commerceService** — les données factices (`getSellerStats`, etc.) doivent soit pointer vers les API réelles (v0.401+ les a créées), soit être clairement marquées comme non-prod | 🟡 | S | `apps/web/src/services/commerceService.ts` (localiser les mocks) | Aucun mock ne retourne de données factices en mode production |
| 023 | **Remplacer `fmt.Printf` par logger structuré** — 15+ occurrences identifiées dans le backend. Utiliser `zap` déjà configuré. | 🟡 | S | `grep -rn "fmt.Print" veza-backend-api/internal/` pour la liste exacte | Aucun `fmt.Printf` dans `internal/` (hors tests) |
| 024 | **Éliminer les `any` TypeScript** — 90+ occurrences. Remplacer par des types concrets ou `unknown` avec type guards. Prioriser les fichiers services/ et stores/. | 🟡 | L | `apps/web/src/services/`, `apps/web/src/stores/` | `grep -rn ": any" apps/web/src/ | wc -l` < 10 |
| 025 | **Aligner FEATURE_STATUS.md avec la réalité** — pour chaque feature "opérationnelle", vérifier le flux E2E. Dégrader en "partielle" les features qui dépendent de MSW ou de services Rust OFF. | 🟡 | M | `docs/FEATURE_STATUS.md` | Le document reflète fidèlement l'état du code |
| 026 | **Aligner TypeScript versions** — 5.3.3 dans `apps/web/package.json` vs 5.9.3 dans root. Unifier sur la dernière stable. | 🟡 | S | `package.json` (root + apps/web) | `grep -r "typescript" */package.json` retourne la même version |
| 027 | **Nettoyer gRPC protobuf dupliqué** — les fichiers proto générés sont dupliqués entre chat et stream. Centraliser dans un dossier `proto/` partagé ou un build step commun. | 🟡 | M | `veza-chat-server/proto/`, `veza-stream-server/proto/` | Un seul jeu de fichiers proto, importé par les deux services |
| 028 | **Documenter la décision Rust** — écrire un ADR (Architecture Decision Record) expliquant pourquoi Go + Rust, quand utiliser quoi, et le plan pour le chat server (garder Rust ou migrer Go) | 🟡 | S | Nouveau `docs/adr/ADR-001-rust-services.md` | ADR rédigé et référencé dans docs/README.md |

**Livrable Sprint 3** : Tag `v0.404-beta`. Codebase nettoyé, documentation alignée.

---

## Sprint 4 — Intégration services & Tests (jours 21–30)

> **Objectif** : Décider du sort des services Rust. Ajouter les tests d'intégration manquants.

| # | Ticket | Gravité | Effort | Fichiers impactés | Critère de complétion |
|---|--------|---------|--------|--------------------|-----------------------|
| 029 | **Décision : chat server Rust — intégrer ou remplacer** — Évaluer le coût d'intégration (gRPC fonctionnel, auth, persistence) vs le coût de réécriture en Go. Produire un document de décision. Si intégration : continuer ticket 030. Si remplacement : planifier en v0.501. | 🟠 | S (décision) | — | ADR-002 rédigé avec décision argumentée |
| 030 | **Intégrer le stream server Rust** — connecter gRPC entre backend Go et stream server, activer HLS (`HLS_STREAMING=true`), vérifier le flux upload → transcode → HLS serve → player | 🟠 | XL | `veza-stream-server/`, `veza-backend-api/internal/services/stream/`, `docker-compose.prod.yml`, `apps/web/src/services/hlsService.ts` | Un track uploadé est jouable en HLS via le stream server |
| 031 | **Tests d'intégration cross-service** — écrire des tests qui vérifient les flux critiques avec tous les services démarrés (Docker Compose test). Minimum : auth → upload → playback, register → login → chat. | 🟡 | L | Nouveau dossier `tests/integration/` ou dans `scripts/` | 5+ scénarios E2E qui passent en CI |
| 032 | **Fixer tests désactivés backend** — `metrics_test.go`, `profile_handler_test.go`, `system_metrics_test.go` désactivés pour bitrot. Les corriger ou les supprimer. | 🟡 | M | Fichiers de test identifiés dans le CHANGELOG (section Known Issues) | Aucun test `skip` ou `disabled` restant |
| 033 | **Ajouter tests Rust** — les services Rust ont peu/pas de tests. Ajouter au minimum : tests unitaires JWT validation, tests WebSocket message routing, tests de non-régression. | 🟡 | L | `veza-chat-server/tests/`, `veza-stream-server/tests/` | `cargo test` passe avec > 20 tests par service |
| 034 | **Remplacer `gorilla/websocket`** — librairie archivée (déc. 2024), plus de patches sécurité. Migrer vers `nhooyr.io/websocket` ou `coder/websocket`. | 🟡 | M | `veza-backend-api/` — tous les fichiers importants `gorilla/websocket` | Aucune dépendance à `gorilla/websocket` |

**Livrable Sprint 4** : Tag `v0.404-rc1`. Services intégrés ou décision documentée. Tests d'intégration en place.

---

## Sprint 5 — Finalisation v0.404 (jours 31–35)

> **Objectif** : Valider la stabilisation, tagger, préparer v0.501.

| # | Ticket | Gravité | Effort | Fichiers impactés | Critère de complétion |
|---|--------|---------|--------|--------------------|-----------------------|
| 035 | **Smoke test prod** — déployer sur l'environnement staging la config prod complète. Vérifier les 14 features E2E identifiées dans l'audit. Documenter les résultats. | 🟠 | M | Staging environment | 14/14 features E2E fonctionnent en staging |
| 036 | **Mettre à jour PROJECT_STATE.md** pour v0.404 | 🟡 | S | `docs/PROJECT_STATE.md` | Reflète l'état post-stabilisation |
| 037 | **Mettre à jour SCOPE_CONTROL.md** — référence active → v0.501 | 🟡 | S | `docs/SCOPE_CONTROL.md` | Référence pointe vers `V0_501_RELEASE_SCOPE.md` |
| 038 | **Archiver V0_404_RELEASE_SCOPE.md** dans `docs/archive/` | 🟡 | S | `docs/archive/` | Document archivé |
| 039 | **Tag v0.404** | — | S | Git | Tag créé, CHANGELOG mis à jour |
| 040 | **Rétrospective audit** — comparer les scores pré/post stabilisation. Documenter ce qui reste à traiter en v0.501+. | 🟡 | S | Nouveau `docs/RETRO_V0_404.md` | Document rédigé |

**Livrable Sprint 5** : **Tag `v0.404`**. Stabilisation terminée. Prêt pour Phase 5.

---

## Résumé

| Sprint | Jours | Tickets | Focus |
|--------|-------|---------|-------|
| 1 | 1–5 | 001–010 | Sécurité critique |
| 2 | 6–12 | 011–020 | Infra & CI/CD |
| 3 | 13–20 | 021–028 | Nettoyage & Qualité |
| 4 | 21–30 | 029–034 | Intégration & Tests |
| 5 | 31–35 | 035–040 | Finalisation & Tag |

**Durée totale** : ~7 semaines (35 jours ouvrés)
**Tickets** : 40
**Répartition effort** : 14 S, 14 M, 5 L, 2 XL, 5 tâches administratives

---

## Tickets reportés à v0.501+

Ces éléments de l'audit ne sont pas bloquants pour la stabilisation mais doivent être traités :

| Ticket | Description | Version cible |
|--------|-------------|---------------|
| Découper fichiers > 1000 LOC | `track/handler.go`, `interceptors.ts`, `config.go` | v0.501 |
| Consolider migrations | Squash 78 migrations en baseline | v0.501 |
| Migration React 19 | React 18.2.0 → 19. Évaluer impact hooks. | v0.602 |
| Réécriture chat server Go | Si décision ADR-002 = remplacement | v0.501–v0.502 |
| Blue-green deployment | Nécessite reverse proxy + health checks | v0.601 |
| Container image scanning | Trivy ou Grype en CI | v0.501 |
| IaC (Terraform/Pulumi) | Infrastructure as Code | v0.801 |
| Hyperswitch mode production | Passer de test à live | v0.501 (si payout ready) |