veza/AUDIT_2.md

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 | Fait | fix(web): disable ghost... |
| 1.4 | Rate limit logs/frontend | Fait | fix(api): add rate limiting... |
| 1.5 | Tests Go sans -short | Fait | ci(backend): run Go tests... |
| 1.6 | Gitleaks CI | Fait | ci: add gitleaks secret scanning |
| 1.7 | Rapports couverture | Fait | ci(backend): add coverage... |

### Phase 2 — Stabilisation

| # | Action | Statut | Commit |
|---|--------|--------|--------|
| 2.1 | Migration views → features | À faire | - |
| 2.2 | Auth consolidation | Fait | refactor(auth): consolidate... |
| 2.3 | i18n | À faire | - |
| 2.4 | Tests Dashboard, Library, Analytics, Admin | À faire | - |
| 2.5 | Découper handlers.ts MSW | À faire | - |
| 2.6 | Payment provider | Fait | Hyperswitch |
| 2.7 | Network Policies K8s | À faire | - |
| 2.8 | Resource limits HAProxy | À faire | - |
| 2.9 | Nettoyage audit/remediation | À 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 | Compile |
| 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*