docs(audit): add progress tracking section, mark 1.1 and 1.2 as done

AUDIT_2.md

@@ -0,0 +1,599 @@
+Now I have a comprehensive picture. Let me compile the full audit report.
+
+---
+
+# RAPPORT D'AUDIT TECHNIQUE INTÉGRAL — MONOREPO VEZA
+
+**Date** : 14 Février 2026
+**Auditeur** : Analyse technique indépendante
+**Objet** : Évaluation complète du monorepo Veza pour viabilité technique et investissement
+**Classification** : Confidentiel
+
+---
+
+## EXECUTIVE SUMMARY
+
+Veza est une **plateforme audio collaborative** de type SaaS (streaming, marketplace, social, chat temps réel) construite sur un monorepo polyglotte : **React/TypeScript** (frontend), **Go/Gin** (API backend), **Rust/Axum** (chat WebSocket + stream audio).
+
+**Taille du codebase** : ~442 000 lignes de code
+- Frontend : ~206 000 LoC (TypeScript/React)
+- Backend Go : ~169 000 LoC
+- Chat Server Rust : ~28 000 LoC
+- Stream Server Rust : ~39 000 LoC
+
+**Verdict global** : Le projet démontre une **ambition architecturale significative** et des **pratiques de sécurité au-dessus de la moyenne**. Cependant, il souffre de **scope creep sévère**, de **features fantômes**, d'une **duplication architecturale** sur le frontend, et d'un **stream server qui ne compile pas**. En l'état, il n'est **pas prêt pour la production** sans un travail de stabilisation de 6-8 semaines.
+
+---
+
+## ÉTAT D'AVANCEMENT (mis à jour le 14/02/2026)
+
+| # | Action | Statut | Commit |
+|---|--------|--------|--------|
+| 1.1 | SQL message_store.rs | Fait | - |
+| 1.2 | Compilation stream server | Fait | - |
+| 1.3 | Features fantômes | À faire | - |
+| 1.4 | Rate limit logs/frontend | À faire | - |
+| 1.5 | Tests Go sans -short | À faire | - |
+| 1.6 | Gitleaks CI | À faire | - |
+| 1.7 | Rapports couverture | À faire | - |
+
+---
+
+## 1. CARTOGRAPHIE GLOBALE
+
+### Stack technique
+
+| Couche | Technologie | Version | Statut |
+|--------|-------------|---------|--------|
+| Frontend | React + Vite + TypeScript | 18.2 / 7.1 / 5.3 | Opérationnel |
+| CSS | Tailwind v4 | 4.0 | Opérationnel |
+| State | Zustand + TanStack Query | 4.5 / 5.17 | Opérationnel |
+| Backend API | Go + Gin + GORM | 1.23 / 1.11 / 1.30 | Opérationnel |
+| Chat Server | Rust + Axum + SQLx | 2021 ed. / 0.8 | Compile |
+| Stream Server | Rust + Axum + Symphonia | 2021 ed. / 0.8 | **Ne compile pas** |
+| Base de données | PostgreSQL 16 | 16-alpine | Opérationnel |
+| Cache/Queues | Redis 7 + RabbitMQ 3 | 7-alpine / 3 | Opérationnel |
+| Reverse Proxy | HAProxy 2.8 | 2.8-alpine | Configuré |
+| CI/CD | GitHub Actions | N/A | Partiel |
+| Container | Docker multi-stage | N/A | Configuré |
+| K8s | Kubernetes + External Secrets | N/A | Scaffoldé |
+| Docs | Docusaurus 3.8 | 3.8.1 | Scaffoldé |
+| Tests | Vitest + Playwright + Storybook | 3.2 / 1.58 / 8.6 | Partiel |
+
+### Organisation du repo
+
+```
+veza/
+├── apps/web/                  # Frontend React (206K LoC)
+├── veza-backend-api/          # Backend Go (169K LoC)
+├── veza-chat-server/          # Chat WebSocket Rust (28K LoC)
+├── veza-stream-server/        # Audio Streaming Rust (39K LoC)
+├── veza-common/               # Shared Rust library
+├── veza-docs/                 # Docusaurus (scaffoldé)
+├── fixtures/                  # Test fixtures
+├── config/                    # HAProxy, etc.
+├── infra/                     # IaC configs
+├── k8s/                       # Kubernetes manifests
+├── scripts/                   # Build/deploy scripts
+├── .github/workflows/         # 8 CI/CD workflows
+└── make/                      # Modular Makefile system
+```
+
+**Orchestration monorepo** : npm workspaces uniquement. Pas de Turborepo, Nx, ou Lerna. C'est **insuffisant** pour un monorepo de cette taille avec 3 langages. Il n'y a aucune gestion de graphe de dépendances, aucun cache de build inter-services, aucune détection de changements ciblée.
+
+### Dépendances critiques
+
+- **Aucune dépendance obsolète majeure** identifiée (React 18.2 est mineur, TypeScript 5.3 acceptable)
+- **Tokio version mismatch** dans les crates Rust : `veza-common` utilise `tokio = "1.0"` tandis que les serveurs utilisent `1.35`
+- **Aucune dépendance abandonnée** détectée
+
+### Flux de données
+
+```
+Browser → HAProxy → Backend Go API → PostgreSQL
+                  → Chat Server Rust (WebSocket) → PostgreSQL / Redis
+                  → Stream Server Rust (Audio) → PostgreSQL / Redis
+                  
+Backend Go → Redis (sessions, cache, rate limiting, CSRF)
+           → RabbitMQ (événements async)
+           → ClamAV (antivirus upload, optionnel)
+```
+
+---
+
+## 2. CE QUE LE PRODUIT PERMET RÉELLEMENT
+
+### Features VALIDÉES (backend + frontend connectés)
+
+| Feature | Backend | Frontend | Tests | Verdict |
+|---------|---------|----------|-------|---------|
+| Auth (register, login, logout) | Go | React | Oui | **Fonctionnel** |
+| JWT + httpOnly cookies | Go | React | Oui | **Fonctionnel** |
+| 2FA (TOTP) | Go | React | Oui | **Fonctionnel** |
+| Password reset | Go | React | Oui | **Fonctionnel** |
+| Email verification | Go | React | Oui | **Fonctionnel** |
+| OAuth (Google, GitHub, Discord) | Go | React | Partiel | **Fonctionnel** |
+| Session management | Go | React | Oui | **Fonctionnel** |
+| RBAC (roles & permissions) | Go | React | Oui | **Fonctionnel** |
+| User profiles | Go | React | Oui | **Fonctionnel** |
+| Track CRUD | Go | React | Oui | **Fonctionnel** |
+| Track upload (chunked) | Go | React | Oui | **Fonctionnel** |
+| Playlist CRUD | Go | React | Oui | **Fonctionnel** |
+| Search (tracks, playlists, users) | Go | React | Oui | **Fonctionnel** |
+| Chat WebSocket temps réel | Rust | React | Partiel | **Fonctionnel** |
+| Marketplace products | Go | React | Partiel | **Fonctionnel** |
+| Cart & Checkout | Go | React | Partiel | **Fonctionnel** |
+| Notifications | Go | React | Partiel | **Fonctionnel** |
+| Admin dashboard | Go | React | Non | **Partiel** |
+| Analytics | Go | React | Non | **Partiel** |
+| Social feed/posts | Go | React | Non | **Partiel** |
+
+### Features PARTIELLEMENT implémentées
+
+| Feature | Ce qui manque |
+|---------|---------------|
+| HLS Audio Streaming | Stream server ne compile pas. Frontend prêt, backend Rust non validé |
+| Webhooks | API CRUD existe, delivery system incomplet |
+| Dashboard | Frontend avec données mockées uniquement (MSW) |
+| Library | Frontend scaffoldé, logique métier partielle |
+| File Manager | UI existe, pas de backend dédié |
+| Discover | Données mockées, pas d'algorithme de recommandation |
+
+### Features FANTÔMES (UI existe, aucun backend)
+
+| Feature | Fichiers | Verdict |
+|---------|----------|---------|
+| **Education** | `components/views/education-view/`, MSW handlers lignes 600-630 | **Ghost feature** — Cours, tutoriels, rien côté backend |
+| **Gamification** | `handlers-ghost.ts` importé dans MSW | **Ghost feature** — Badges, achievements, 100% mock |
+| **Studio** | `components/views/studio-view/` | **Ghost feature** — DAW-like, aucun backend |
+| **Live Streaming** | `components/views/live-view/` | **Partiellement ghost** — UI complète, backend minimal |
+
+### Features MORTES / Code non utilisé
+
+- `pages/auth/Login.tsx` duplique `features/auth/pages/LoginPage.tsx`
+- `context/AuthContext.tsx` coexiste avec `features/auth/store/authStore.ts` (deux sources de vérité)
+- `components/views/settings-view/` duplique `features/settings/pages/`
+- `components/views/upload-view/` duplique `features/upload/`
+- `dist_verification/` supprimé (git status montre 80+ fichiers deleted)
+
+### Incohérences produit/code
+
+1. **Deux patterns architecturaux coexistent** : `components/views/` (legacy) vs `features/*/pages/` (nouveau) sans plan de migration clair
+2. **Education, Gamification, Studio** sont routés et accessibles comme si fonctionnels, mais retournent des données fictives
+3. **Le stream server Rust ne build pas** mais le frontend intègre un player HLS complet avec dashboard de monitoring
+4. **303 stories Storybook** pour la validation visuelle, mais le git status montre des modifications non commitées dans de nombreux fichiers critiques
+
+---
+
+## 3. VALIDATION FONCTIONNELLE
+
+### Flows critiques analysés
+
+**Auth flow** : Validé
+- Registration avec validation email, password strength check, username uniqueness
+- Login avec rate limiting (5 tentatives / 15 min), account lockout (30 min)
+- JWT access token (5 min TTL) + refresh token (30 jours) en httpOnly cookies
+- CSRF protection avec timing-safe comparison
+- Token versioning pour invalidation immédiate
+- Tests : Oui (unitaires + intégration)
+
+**Upload flow** : Validé
+- Upload chunked avec validation multi-couche (magic bytes, MIME, extension, taille)
+- Scan antivirus ClamAV (optionnel mais intégré)
+- Rate limiting : 10 uploads/heure par utilisateur
+- Tests : Oui
+
+**Chat flow** : Partiellement validé
+- WebSocket avec auth JWT avant upgrade
+- Rate limiting par action (message, réaction, etc.)
+- Permission checks (membership, read/write)
+- **Risque** : SQL injection dans `message_store.rs:179` (voir section sécurité)
+
+**Payment/Checkout** : Non validé
+- Cart + checkout UI existent
+- **Aucune intégration Stripe/payment provider** trouvée dans le backend
+- Flow critique non fonctionnel en production
+
+### Points de rupture identifiés
+
+1. **Stream server inopérant** : `cargo check` en CI, pas de `cargo build`. Le TODO dans le CI confirme le problème : `TODO(C7): fix stream-server compilation if this fails`
+2. **Payments non intégrés** : Le checkout UI existe mais ne peut rien traiter
+3. **Rate limiting désactivé en dev/test** (lignes 99-109 de `rate_limiter.go`) — acceptable mais l'absence de tests de rate limiting en CI est un risque
+
+### Zones non testées
+
+- Dashboard (0 tests)
+- Library (0 tests)
+- Analytics views (0 tests)
+- Admin views (0 tests)
+- Social feed (0 tests)
+- Education (ghost feature, 0 tests)
+- Gamification (ghost feature, 0 tests)
+- Live view (0 tests)
+
+---
+
+## 4. AUDIT DE SÉCURITÉ — OWASP TOP 10
+
+### A01 — Broken Access Control | Gravité : FAIBLE
+
+**Constats** :
+- Middleware `RequireAuth()` appliqué systématiquement sur les routes protégées
+- `RequireOwnershipOrAdmin()` pour les opérations CRUD utilisateur
+- `RequireContentCreatorRole()` pour la création de contenu
+- CSRF sur toutes les opérations state-changing (POST, PUT, DELETE)
+- Routes admin protégées par `RequireAdmin()`
+
+**Risque résiduel** :
+- `POST /api/v1/logs/frontend` est public sans rate limiting dédié — un attaquant pourrait flood les logs
+
+**Correctif** : Ajouter un rate limiter sur l'endpoint de logging frontend.
+
+### A02 — Cryptographic Failures | Gravité : FAIBLE
+
+**Constats** :
+- Passwords : bcrypt avec `DefaultCost` (10 rounds)
+- JWT : HS256 avec secret en variable d'environnement, validation issuer/audience
+- Tokens httpOnly, Secure, SameSite=strict en production
+- CSRF : crypto/rand + timing-safe comparison
+- Aucun secret hardcodé trouvé dans le code
+
+**Risque résiduel** :
+- Refresh token TTL de 30 jours — long mais acceptable avec token versioning
+
+### A03 — Injection | Gravité : ÉLEVÉE
+
+**Vulnérabilité confirmée** dans `veza-chat-server/src/message_store.rs:179` :
+
+```177:184:veza-chat-server/src/message_store.rs
+    pub async fn cleanup_old_messages(&self, older_than_days: i32) -> Result<u64, sqlx::Error> {
+        let result = sqlx::query(
+            "DELETE FROM messages WHERE created_at < NOW() - INTERVAL '%s days'",
+        )
+        .bind(older_than_days)
+        .execute(&self.pool)
+        .await?;
+```
+
+Le placeholder `%s` n'est pas reconnu par PostgreSQL/SQLx. Le `.bind()` est ignoré. En l'état, la requête échoue systématiquement (erreur de syntaxe SQL), mais si le format était corrigé naïvement avec `format!()`, ce serait une injection SQL directe.
+
+**Risque supplémentaire** : Dynamic SQL dans `message_repository.rs` (lignes 387-515) utilise `format!()` avec des paramètres `.bind()`. Le pattern est sûr si les fragments dynamiques ne contiennent pas d'input utilisateur, mais c'est fragile.
+
+**Backend Go** : Toutes les requêtes utilisent GORM (paramétrisé) ou `$1/$2` placeholders. Aucune injection détectée.
+
+**Frontend** : `dangerouslySetInnerHTML` utilisé dans le chat, mais **toujours avec** `sanitizeChatMessage()` (DOMPurify). Correctement implémenté.
+
+**Correctif** :
+```rust
+"DELETE FROM messages WHERE created_at < NOW() - INTERVAL '1 day' * $1"
+```
+
+### A04 — Insecure Design | Gravité : MOYENNE
+
+**Constats** :
+- Rate limiting implémenté (Redis + in-memory fallback)
+- Account lockout implémenté (5 tentatives)
+- Input validation présente mais **inconsistante** — pas tous les DTOs utilisent des tags de validation
+- Pas de rate limiting sur le frontend logging endpoint
+
+**Risque** : Un attaquant peut envoyer des requêtes de logging en masse pour saturer le stockage de logs.
+
+### A05 — Security Misconfiguration | Gravité : MOYENNE
+
+**Constats** :
+- CORS validé en production (pas de wildcard)
+- Security headers complets (HSTS, X-Frame-Options, CSP, etc.)
+- Debug/stack traces désactivés en production
+- `CSRF_DISABLED` ne peut être activé qu'en dev/test
+- Rate limiting désactivé en dev/test via `NODE_ENV`/`APP_ENV`
+
+**Risque** :
+- Rate limiting bypass si `APP_ENV=development` est set en production par erreur — la validation de config devrait le prévenir mais ce n'est pas vérifié
+- Le web container utilise `VITE_API_URL=http://haproxy/api/v1` sans HTTPS dans docker-compose.prod.yml (les URLs internes sont HTTP, HTTPS est terminé au HAProxy)
+
+### A06 — Vulnerable & Outdated Components | Gravité : FAIBLE
+
+**Constats** :
+- CI exécute `govulncheck`, `cargo audit`, `npm audit`
+- Versions des dépendances à jour
+- Tokio mismatch dans `veza-common` (1.0 vs 1.35) — risque de compatibilité, pas de vulnérabilité
+
+### A07 — Identification & Authentication Failures | Gravité : FAIBLE
+
+**Constats** :
+- JWT validé avec algorithm check, issuer, audience, token version
+- Token refresh avec rotation (vérification à la ligne 684) — contrairement au rapport initial, la rotation EST implémentée via `s.refreshTokenService.Rotate()`
+- Sessions stockées en DB avec validation
+- Password reset avec tokens expirables
+- 2FA TOTP implémenté
+
+### A08 — Software & Data Integrity | Gravité : MOYENNE
+
+**Constats** :
+- CI/CD avec npm audit, govulncheck, cargo audit
+- Trivy scan sur images Docker (CRITICAL/HIGH)
+- SBOM generation (CycloneDX)
+- Image signing optionnel (cosign)
+
+**Risque** :
+- Pas de secret scanning (gitleaks/trufflehog) dans le CI
+- Go tests exécutés avec `-short` flag, excluant les tests nécessitant DB
+
+### A09 — Logging & Monitoring Failures | Gravité : FAIBLE
+
+**Constats** :
+- Structured logging (zap pour Go, tracing pour Rust)
+- Prometheus metrics
+- Sentry error tracking
+- Audit trail (`/api/v1/audit/logs`)
+- Secret filtering dans les logs (`secret_filter.go`)
+- Request ID tracking
+
+### A10 — SSRF | Gravité : FAIBLE
+
+**Constats** :
+- File upload paths validés (`ValidateExecPath`, `build_safe_path`)
+- Path traversal protection dans le stream server
+- URL scheme validation dans le frontend (`sanitizeURL`)
+- Pas d'appels HTTP sortants non filtrés identifiés
+
+### Tableau récapitulatif sécurité
+
+| OWASP | Gravité | Impact | Scénario |
+|-------|---------|--------|----------|
+| A01 | Faible | Logging flood | POST /api/v1/logs/frontend sans rate limit |
+| A02 | Faible | - | Pratiques crypto solides |
+| A03 | **Élevée** | Data loss | SQL buggé dans message_store.rs (échoue, pas exploitable en l'état) |
+| A04 | Moyenne | DoS | Logging endpoint non rate limited |
+| A05 | Moyenne | Bypass | Rate limiting conditionnel sur env vars |
+| A06 | Faible | - | Dépendances à jour |
+| A07 | Faible | - | Auth robuste |
+| A08 | Moyenne | Supply chain | Pas de secret scanning |
+| A09 | Faible | - | Logging/monitoring solides |
+| A10 | Faible | - | Protections en place |
+
+---
+
+## 5. DETTE TECHNIQUE
+
+### Dette CRITIQUE (bloquante)
+
+| # | Élément | Fichiers | Impact |
+|---|---------|----------|--------|
+| D1 | **Stream server ne compile pas** | `veza-stream-server/src/*` | 39K LoC inutilisables, feature streaming inopérante |
+| D2 | **Features fantômes accessibles en prod** | Education, Gamification, Studio | Expérience utilisateur cassée, données fictives |
+| D3 | **Pas de payment provider** | Checkout flow complet sans backend | Feature marketplace non fonctionnelle |
+| D4 | **SQL buggé dans chat** | `message_store.rs:179` | Cleanup job échoue silencieusement |
+
+### Dette STRUCTURANTE
+
+| # | Élément | Fichiers | Impact |
+|---|---------|----------|--------|
+| D5 | **Double architecture frontend** | `components/views/*` vs `features/*/pages/*` | Confusion, duplication, maintenance x2 |
+| D6 | **Pas d'orchestrateur monorepo** | Racine | CI lent, builds non optimisés, pas de cache |
+| D7 | **265 fichiers de test mais couverture inconnue** | Tests frontend | Impossible de mesurer la qualité réelle |
+| D8 | **261 fichiers test Go mais exécutés avec `-short`** | Tests backend | Tests d'intégration non exécutés en CI |
+| D9 | **i18n incomplet** | ~35+ fichiers avec strings hardcodées en anglais | Impossible de livrer une version FR complète |
+| D10 | **Duplication auth** | `AuthContext.tsx` + `authStore.ts` | Deux sources de vérité pour l'état auth |
+| D11 | **MSW handlers : 1737 lignes** | `handlers.ts` | Fichier monstre, difficile à maintenir |
+| D12 | **TODOs non résolus** | 40+ dans le backend Go, 15+ dans le frontend | Travail incomplet accumulé |
+
+### Dette COSMÉTIQUE
+
+| # | Élément | Impact |
+|---|---------|--------|
+| D13 | React 18.2 au lieu de 18.3 | Mineur |
+| D14 | TypeScript 5.3 au lieu de 5.7 | Mineur |
+| D15 | Scripts bash avec `eval` | Risque faible, dev only |
+| D16 | Commentaires en français/anglais mixtes | Incohérence |
+| D17 | Nombreux fichiers markdown d'audit/remediation dans le backend | Pollution du repo |
+
+---
+
+## 6. QUALITÉ ARCHITECTURALE
+
+### Score d'architecture : 6.5/10
+
+**Justification** :
+- (+) Séparation polyglotte intelligente (Go pour l'API, Rust pour le temps réel et le streaming)
+- (+) Feature-based structure sur le frontend
+- (+) Layered architecture sur le backend (handlers → services → repositories)
+- (-) Deux patterns frontend coexistent sans migration
+- (-) Pas d'orchestrateur monorepo (npm workspaces insuffisant)
+- (-) Stream server non fonctionnel = 1/4 de l'architecture cassée
+- (-) Features fantômes polluent le routing et l'UX
+
+### Score de maintenabilité : 5.5/10
+
+**Justification** :
+- (+) Code bien structuré dans chaque service individuellement
+- (+) 303 stories Storybook (excellent pour la documentation visuelle)
+- (+) 526 fichiers de test au total
+- (-) 442K LoC pour une équipe visiblement petite = surcharge
+- (-) Duplication architecturale frontend
+- (-) Tests backend en mode `-short` en CI
+- (-) Couverture de test inconnue (pas de rapport)
+- (-) 40+ TODOs non résolus
+
+### Score de sécurité : 7.5/10
+
+**Justification** :
+- (+) httpOnly cookies pour JWT
+- (+) CSRF avec timing-safe comparison
+- (+) CORS validé en production
+- (+) Rate limiting + account lockout
+- (+) Security headers complets
+- (+) Audit trail, secret filtering
+- (+) File upload multi-layer validation + ClamAV
+- (-) SQL bug dans le chat server
+- (-) Pas de secret scanning en CI
+- (-) Rate limiting bypassable via env var
+
+### Score de scalabilité : 6/10
+
+**Justification** :
+- (+) Architecture microservices avec message queue (RabbitMQ)
+- (+) Redis pour cache et sessions
+- (+) K8s manifests préparés
+- (+) HAProxy comme reverse proxy
+- (-) Stream server non fonctionnel
+- (-) Pas de CDN configuré pour les assets audio
+- (-) Pas de monitoring de performance applicative (APM) au-delà de Prometheus
+- (-) PostgreSQL comme seul datastore (pas de séparation read/write)
+
+---
+
+## 7. INFRA & DEVOPS
+
+### Docker : 7/10
+
+- Multi-stage builds pour tous les services
+- Dockerfiles production dédiés
+- Health checks sur tous les services
+- Resource limits définis (sauf HAProxy)
+- Network isolation
+
+**Problème** : Le HAProxy n'a pas de resource limits dans `docker-compose.prod.yml`.
+
+### Kubernetes : 6/10
+
+- Deployments avec `runAsNonRoot`, `runAsUser: 1001`
+- External Secrets Operator avec Vault
+- Health checks (readiness + liveness)
+- Graceful shutdown configuré
+
+**Problèmes** :
+- Pas de deployment K8s pour le stream server
+- Pas de Network Policies
+- Pas de Pod Security Standards
+
+### CI/CD : 5.5/10
+
+- 8 workflows GitHub Actions
+- Security audits intégrés (govulncheck, cargo audit, npm audit)
+- Trivy scanning sur les images Docker
+
+**Problèmes critiques** :
+- Stream server : `cargo check` seulement (pas de build)
+- Go tests : `-short` flag = tests d'intégration ignorés
+- Pas de secret scanning (gitleaks)
+- Pas de smoke tests post-deployment
+- Pas de coverage report
+- Pas de gestion de branches sophistiquée (pas de staging branch)
+
+### Secrets : 8/10
+
+- Variables d'environnement pour tout
+- `{VAR:?error message}` dans docker-compose.prod.yml (fail-fast)
+- External Secrets Operator pour K8s
+- Secret rotation policies configurées
+- Aucun secret hardcodé trouvé
+
+---
+
+## 8. RISQUES BUSINESS
+
+### Point de vue CTO
+
+**Peut-on lancer en production ?**
+
+**Non, pas en l'état.** Blockers :
+1. Le stream server ne compile pas — fonctionnalité core (streaming audio) non opérationnelle
+2. Le checkout n'a pas de payment provider — la marketplace ne peut pas générer de revenus
+3. Les features fantômes (Education, Gamification, Studio) vont confondre les utilisateurs
+4. Les tests d'intégration backend ne sont pas exécutés en CI
+
+**Estimation pour le go-live** : 6-8 semaines de stabilisation avec une équipe de 2-3 développeurs.
+
+### Point de vue investisseur
+
+**Peut-on investir ?**
+
+**Avec réserves.** Points positifs :
+- Architecture ambitieuse et cohérente dans sa vision
+- Pratiques de sécurité au-dessus de la moyenne du marché
+- Stack moderne et pertinente pour le domaine audio
+- 442K LoC = travail significatif
+
+**Red flags** :
+- Scope creep évident (25+ features dont 4 fantômes)
+- Un composant core (streaming) ne fonctionne pas
+- Ratio features implémentées / features annoncées faible (~60%)
+- Pas de métriques de couverture de test
+- Maintenu par une équipe visiblement petite pour la complexité
+
+**Valorisation technique** : Le code a de la valeur, mais l'écart entre ce qui est annoncé et ce qui fonctionne réellement est préoccupant. Un due diligence technique approfondi avec exécution des tests est recommandé.
+
+### Point de vue acquéreur
+
+**Peut-on acquérir et maintenir ?**
+
+**Faisable mais coûteux.** Le code est globalement bien écrit et bien structuré. La stack est moderne. Cependant :
+- L'onboarding nécessite de comprendre 3 langages (TypeScript, Go, Rust)
+- La dette architecturale frontend (double pattern) augmente le coût de maintenance
+- Le stream server Rust nécessite un développeur Rust expérimenté pour le débloquer
+- Les 17+ fichiers markdown de "remediation" et "audit" dans le backend suggèrent un historique de problèmes récurrents
+
+**Recommandation** : Acquérir uniquement si l'acquéreur dispose de compétences Go + Rust. Prévoir 3-6 mois de stabilisation avant de pouvoir itérer sur de nouvelles features.
+
+---
+
+## 9. PLAN D'ACTION PRIORISÉ
+
+### Phase 1 — URGENT (sécurité & stabilité) — Semaines 1-2
+
+| # | Action | Effort | Impact |
+|---|--------|--------|--------|
+| 1.1 | Fixer le SQL dans `message_store.rs:179` | **S** | Élimine bug critique |
+| 1.2 | Fixer la compilation du stream server | **L** | Débloquer le streaming audio |
+| 1.3 | Désactiver les routes des features fantômes en prod | **S** | UX cohérente |
+| 1.4 | Ajouter rate limiting sur `/api/v1/logs/frontend` | **S** | Prévenir DoS logs |
+| 1.5 | Exécuter les tests Go SANS `-short` en CI (ajouter DB test) | **M** | Couverture réelle |
+| 1.6 | Ajouter secret scanning (gitleaks) au CI | **S** | Prévenir les fuites |
+| 1.7 | Générer et publier les rapports de couverture de tests | **S** | Visibilité qualité |
+
+### Phase 2 — STABILISATION — Semaines 3-6
+
+| # | Action | Effort | Impact |
+|---|--------|--------|--------|
+| 2.1 | Migrer `components/views/` vers `features/` (éliminer la duplication) | **XL** | Maintenabilité +50% |
+| 2.2 | Supprimer `AuthContext.tsx`, consolider sur `authStore.ts` | **M** | Source de vérité unique |
+| 2.3 | Compléter l'i18n (migrer les 35+ fichiers avec strings hardcodées) | **L** | Prêt pour le marché FR |
+| 2.4 | Ajouter tests pour Dashboard, Library, Analytics, Admin | **L** | Couverture des zones aveugles |
+| 2.5 | Découper `handlers.ts` MSW (1737 lignes) en modules par feature | **M** | Maintenabilité |
+| 2.6 | Intégrer un payment provider (Stripe) pour le checkout | **XL** | Marketplace fonctionnelle |
+| 2.7 | Ajouter Network Policies K8s | **M** | Sécurité cluster |
+| 2.8 | Ajouter resource limits HAProxy | **S** | Stabilité infra |
+| 2.9 | Nettoyer les fichiers markdown d'audit/remediation du backend | **S** | Propreté repo |
+
+### Phase 3 — AMÉLIORATION & REFONTE — Semaines 7-12
+
+| # | Action | Effort | Impact |
+|---|--------|--------|--------|
+| 3.1 | Adopter Turborepo ou Nx pour l'orchestration monorepo | **L** | CI 3-5x plus rapide |
+| 3.2 | Implémenter ou supprimer définitivement les features fantômes | **XL** | Produit cohérent |
+| 3.3 | Configurer CDN pour assets audio | **M** | Performance streaming |
+| 3.4 | Ajouter smoke tests post-deployment | **M** | Fiabilité déploiements |
+| 3.5 | Implémenter request cancellation frontend (AbortController) | **M** | Prévenir memory leaks |
+| 3.6 | Ajouter store migration strategy (Zustand) | **M** | Résilience client |
+| 3.7 | Configurer read replicas PostgreSQL | **L** | Scalabilité |
+| 3.8 | Résoudre tous les TODOs restants (55+) | **L** | Dette technique zéro |
+
+---
+
+## CONCLUSION STRATÉGIQUE
+
+**Veza est un projet techniquement ambitieux, bien architecturé dans sa vision, mais en état de surextension.** Le ratio entre les fonctionnalités annoncées et celles réellement opérationnelles (~60%) révèle un scope creep classique. Le codebase est de qualité correcte à bonne, avec des pratiques de sécurité notablement supérieures à la moyenne (httpOnly cookies, CSRF timing-safe, ClamAV, secret filtering, RBAC multi-niveaux).
+
+**Les 3 risques majeurs** sont :
+1. Le stream server Rust (core feature) qui ne compile pas
+2. Les features fantômes qui donnent une fausse impression de complétude
+3. L'absence de payment provider pour une marketplace
+
+**La recommandation** est de concentrer les efforts sur la Phase 1 (2 semaines) pour sécuriser et stabiliser, puis Phase 2 (4 semaines) pour rendre le produit commercialisable. La Phase 3 est un luxe qui peut attendre la preuve de marché.
+
+**Score global de maturité technique : 6/10** — Suffisant pour un MVP, insuffisant pour une mise en production commerciale sans stabilisation.
+
+---
+
+*Fin du rapport d'audit technique — 14 Février 2026*