# Rapport d'audit technique intégral — Monorepo Veza

**Date** : 16 février 2026  
**Auditeur** : Architecte logiciel senior / Expert sécurité  
**Mandataire** : Comité d'investissement  
**Périmètre** : Monorepo complet — `talas/veza`  
**Méthode** : Analyse statique exhaustive du code source, des configurations et de l'infrastructure

---

## Executive summary

Veza est une **plateforme audio collaborative** (type Bandcamp/SoundCloud) avec marketplace, fonctionnalités sociales, chat temps réel et streaming audio. Le projet est techniquement ambitieux avec une stack polyglotte (Go, Rust, TypeScript/React).

### Verdict synthétique

| Critère | Score | Commentaire |
|---------|-------|-------------|
| **Architecture** | 6/10 | Bonne séparation des services, dual-patterns frontend, pollution documentaire |
| **Maintenabilité** | 5/10 | 470K+ LOC, ~137 fichiers .md à la racine, dette structurelle |
| **Sécurité** | 6/10 | Fondations solides, vulnérabilités npm, HLS public, bypass flags |
| **Scalabilité** | 7/10 | Architecture microservices, K8s ready, HAProxy |

**Peut-on lancer en production ?** Non, pas en l'état. Correctifs critiques requis (1–2 semaines estimées).  
**Peut-on vendre le produit ?** Le produit a de la valeur fonctionnelle. Stabilisation requise avant due diligence.  
**Faut-il réécrire ?** Non. Refactoring ciblé suffisant.

---

## 1. Cartographie globale

### 1.1 Stack complète

| Couche | Technologie | Version | Rôle |
|--------|-------------|---------|------|
| **Frontend** | React + TypeScript | 18.2 / TS 5.3 | SPA |
| **Build** | Vite | 7.1.5 | Bundler |
| **State** | Zustand + TanStack Query | 4.5 / 5.17 | UI state + server state |
| **Forms** | react-hook-form + Zod | 7.49 / 3.25 | Validation |
| **Styling** | Tailwind CSS | 4.0 | Styles |
| **UI** | Radix UI + Lucide | - | Composants |
| **i18n** | i18next | 25.5 | Internationalisation |
| **Backend API** | Go + Gin | Go 1.24 (go.mod) / 1.23 (CI) | REST API |
| **ORM** | GORM | 1.30 | Accès DB |
| **Chat** | Rust + Axum | Axum 0.8 | WebSocket temps réel |
| **Streaming** | Rust + Axum | Axum 0.8 | Audio HLS |
| **Database** | PostgreSQL | 16 | Persistance |
| **Cache** | Redis | 7 | Sessions, rate limiting, CSRF |
| **Queue** | RabbitMQ | 3 | Events async |
| **Paiement** | Hyperswitch | 2025.01.21 | Checkout |
| **Monitoring** | Prometheus + Sentry | - | Métriques + erreurs |
| **CI/CD** | GitHub Actions | - | ci.yml, cd.yml |
| **Orchestration** | Turborepo + Docker | - | Monorepo + déploiement |

### 1.2 Organisation du repo

```
veza/
├── apps/web/                    # Frontend React (~200K LOC)
│   ├── src/features/            # 25 modules fonctionnels
│   ├── src/components/          # Composants partagés + views
│   ├── src/services/            # API client, socialService, etc.
│   ├── src/stores/              # Zustand stores
│   ├── src/mocks/               # MSW handlers
│   └── e2e/                     # Playwright tests
├── veza-backend-api/            # Backend Go (~150K LOC)
│   ├── cmd/api/                 # Entry point
│   ├── internal/handlers/       # ~88 handlers
│   ├── internal/middleware/     # Auth, rate limit, CSRF, RBAC
│   ├── internal/services/       # JWT, session, upload, webhook
│   ├── migrations/              # 42+ fichiers SQL
│   └── tests/                   # Tests spécialisés
├── veza-chat-server/            # Chat Rust (Axum, WebSocket)
├── veza-stream-server/          # Streaming Rust (HLS, audio)
├── veza-common/                 # Bibliothèque Rust partagée
├── .github/workflows/           # ci.yml, cd.yml (playwright.yml supprimé)
├── config/                      # HAProxy, SSL
└── docker-compose*.yml          # prod, dev, test, staging
```

### 1.3 Dépendances critiques et obsolètes

| Dépendance | Service | Risque | Statut |
|-----------|---------|--------|--------|
| `gin-gonic/gin v1.11` | Backend | Faible | ✅ À jour |
| `gorm v1.30` | Backend | Faible | ✅ À jour |
| `golang-jwt/jwt v5.3` | Backend | Faible | ✅ À jour |
| `axum 0.8` | Chat/Stream | Faible | ✅ À jour |
| `sqlx 0.8` | Chat/Stream | Faible | ✅ À jour |
| `react 18.2` | Frontend | Faible | ✅ Stable |
| `axios 1.13.5` | Frontend | Moyen | ⚠️ Override >=1.13.5 (CVE) |
| **cookie** | @lhci/cli → @sentry/node | Moyen | ❌ <0.7.0 vulnérable |
| **jose** | newman | Modéré | ❌ 3.0–4.15.4 vulnérable |
| **node-forge** | newman | Élevé | ❌ <=1.3.1 vulnérable |
| **qs** | postman-request | Élevé | ❌ <6.14.1 DoS |
| **lodash** | postman-collection | Modéré | ❌ 4.0–4.17.21 prototype pollution |

**Note** : Les vulnérabilités npm concernent principalement des dépendances de dev (`@lhci/cli`, `newman`). Pas d’impact direct sur le runtime frontend si ces outils ne sont pas utilisés en production.

### 1.4 Schéma des flux

```
[Frontend] --HTTP/API--> [Backend Go] --GORM--> [PostgreSQL]
     |                         |                      |
     |--WebSocket--> [Chat Server Rust] --SQLx--> [PostgreSQL]
     |                         |
     |--WebSocket--> [Stream Server Rust] --SQLx--> [PostgreSQL]
     |                         |
     |--HLS--> [Stream Server] (segments audio)
     |
     +--[RabbitMQ]--> Workers (email, thumbnails, webhooks)
     +--[Redis]--> Cache, sessions, rate limit, CSRF
```

### 1.5 Incohérences techniques

| Élément | Constat | Impact |
|---------|---------|--------|
| **Go version** | go.mod: 1.24.0, CI: 1.23 | Risque de build différent selon l’environnement |
| **Playwright workflow** | `.github/workflows/playwright.yml` supprimé | E2E exécutés dans ci.yml uniquement |
| **veza-common** | Référence `../veza-common` (hors workspaces npm) | Build Rust OK, dépendance path |
| **RABBITMQ_URL vs AMQP_URL** | docker-compose.prod utilise `AMQP_URL` | Cohérence à vérifier |

---

## 2. Ce que le produit permet réellement

### 2.1 Features pleinement implémentées ✅

| Feature | Backend | Frontend | Tests | MSW |
|---------|---------|----------|-------|-----|
| Authentification (email/password) | ✅ | ✅ | ✅ | ✅ |
| 2FA TOTP | ✅ | ⚠️ Bug | ✅ | ✅ |
| OAuth | ✅ Partiel | ✅ | - | ✅ |
| Sessions management | ✅ | ✅ | ✅ | ✅ |
| Upload de tracks (chunked) | ✅ | ✅ | ✅ | ✅ |
| CRUD tracks | ✅ | ✅ | ✅ | ✅ |
| Streaming HLS | ✅ | ✅ | ✅ | ✅ |
| Player audio | - | ✅ | ✅ | ✅ |
| Playlists (CRUD + collaboration) | ✅ | ✅ | ✅ | ✅ |
| Recherche | ✅ | ✅ | ✅ | ✅ |
| Profil utilisateur | ✅ | ✅ | ✅ | ✅ |
| Notifications | ✅ | ✅ | ✅ | ✅ |
| Chat temps réel | ✅ | ✅ | ⚠️ | ✅ |
| Marketplace | ✅ | ✅ | ✅ | ✅ |
| Social (feed, posts, groupes) | ✅ | ✅ | ✅ | ✅ |
| Webhooks | ✅ | ✅ | ✅ | ✅ |
| Admin dashboard | ✅ | ✅ | ✅ | ✅ |
| Settings | ✅ | ✅ | ✅ | ✅ |
| Internationalisation (FR/EN) | - | ✅ | - | - |

### 2.2 Features partiellement implémentées ⚠️

| Feature | État | Détail |
|---------|------|--------|
| **2FA Login** | ⚠️ Bug | `TwoFactorVerify.tsx` — possible mauvais endpoint/service |
| **OAuth user lookup** | ⚠️ Non implémenté | `database.go:559` — TODO non résolu |
| **Live streaming** | ⚠️ Mocked | Routes backend existent, frontend mocké via MSW |
| **Gear / Inventory** | ⚠️ Mocked | MSW handlers présents, backend partiel |

### 2.3 Features fantômes (déclarées mais retirées)

| Feature | Preuve | Statut |
|---------|--------|--------|
| Education/Tutorials | Routes backend existent | Supprimée du frontend |
| Gamification | MSW handlers existaient | Supprimée du frontend |
| Studio | Composants dans `components/studio/` | Supprimée des routes |

### 2.4 Features mortes / Code mort

| Élément | Localisation | État |
|---------|-------------|------|
| `webhookApi.ts` | Frontend | **Supprimé** — `socialService.ts` utilise `apiClient` directement |
| `cmd/modern-server/main.go` | Backend | Serveur alternatif, code commenté |
| `cmd/backup/main.go` | Backend | Outil de backup, usage incertain |
| `pages/` directory | Frontend | Legacy, doublon de `features/*/pages/` |
| `components/education/`, `components/studio/` | Frontend | Composants pour features retirées |

### 2.5 Incohérences produit/code

1. **Dual-pattern views** : `components/views/` ET `features/*/pages/` — architecture incohérente
2. **Routes Education** : Backend expose des routes publiques, feature retirée du frontend
3. **webhookApi.ts supprimé** : Les webhooks restent fonctionnels via `socialService` + `apiClient`

---

## 3. Validation fonctionnelle

### 3.1 Couverture de tests

| Composant | Fichiers test | Type | Fiabilité |
|-----------|--------------|------|-----------|
| Frontend | 269+ fichiers | Unit + Component | Seuil 80% configuré |
| Backend Go | 264+ fichiers | Unit + Integration + Security | Bonne |
| Chat Rust | 18+ `#[test]` | Unit | Basique |
| Stream Rust | 50+ `#[test]` | Unit | Correcte |
| E2E | 30 specs | Playwright (4 browsers) | Correcte |
| Storybook | 296 stories | Visual + Audit | Complète |

### 3.2 Points de rupture identifiés

| Scénario | Gravité | Détail |
|----------|---------|--------|
| 2FA login flow | **Élevée** | `TwoFactorVerify.tsx` — possible mauvais service |
| Redis indisponible | **Moyenne** | CSRF panic en prod si Redis down (`routes_core.go`) |
| OAuth callback | **Moyenne** | User lookup non implémenté (`database.go:559`) |
| **~80+ `.unwrap()` / `.expect()`** | **Élevée** | Stream server + Chat server — crash en prod |
| E2E auth tests | **Moyenne** | Git status : tests auth échoués (retry1, retry2) |

### 3.3 Zones non testées

- OAuth flow complet
- Payment webhook Hyperswitch
- WebRTC streaming
- Multi-tenant isolation / IDOR
- Migration rollback SQL

### 3.4 Risques de production

1. **Crash des services Rust** : ~80+ `.unwrap()` / `.expect()` en production
2. **CSRF inutilisable** : Si Redis tombe, le backend peut panic
3. **2FA cassé** : Flow de login 2FA possiblement incorrect
4. **HLS sans auth** : Segments audio publiquement accessibles

---

## 4. Audit de sécurité — OWASP Top 10

### A01 — Broken Access Control

| Constat | Gravité | Impact | Scénario d'exploitation | Correctif |
|---------|---------|--------|------------------------|-----------|
| HLS endpoints publics | **Élevée** | Accès non autorisé aux flux audio | Connaissance d’un `track_id` → téléchargement HLS sans auth | JWT ou validation par signature |
| Routes Education actives | **Moyenne** | Exposition de données fantômes | `GET /api/v1/education/*` publics | Supprimer ou ajouter auth |
| `POST /api/v1/validate` sans auth | **Faible** | Abus de validation | Endpoint accessible sans limite stricte | Rate limiting strict |

**Positif** : RBAC (`RequireAdmin()`, `RequirePermission()`), routes admin protégées, WebSocket avec JWT.

### A02 — Cryptographic Failures

| Constat | Gravité | Impact | Correctif |
|---------|---------|--------|-----------|
| JWT secret dev dans `.env` | **Moyenne** | Si `.env` fuite en prod | `.env` gitignoré, validation longueur min 32 chars en prod |
| Secrets test hardcodés (chat) | **Moyenne** | Bypass auth si config test en prod | Isoler dans config de test |

**Positif** : Bcrypt cost 12, SHA-256 pour sessions, token versioning, cookies httpOnly, CSRF.

### A03 — Injection

| Constat | Gravité | Correctif |
|---------|---------|-----------|
| GORM / sqlx paramétrés | ✅ | Requêtes paramétrées |
| `fmt.Sprintf` avec noms de tables (test utils) | **Faible** | Whitelist `validateTableName()` appliquée |

**Positif** : GORM, sqlx paramétrés, validation `go-playground/validator`, Zod frontend.

### A04 — Insecure Design

| Constat | Gravité | Correctif |
|---------|---------|-----------|
| Download de tracks public | **Moyenne** | Vérifier droits avant download |
| `DISABLE_RATE_LIMIT_FOR_TESTS` | **Moyenne** | CI E2E : `DISABLE_RATE_LIMIT_FOR_TESTS=true` — risque si activé en prod |

**Positif** : Rate limiting multi-couche, account lockout, validation centralisée, upload multi-couche.

### A05 — Security Misconfiguration

| Constat | Gravité | Correctif |
|---------|---------|-----------|
| Bypass flags en dev | **Moyenne** | `BYPASS_CONTENT_CREATOR_ROLE`, `CSRF_DISABLED` — vérifier `APP_ENV=production` |
| Swagger | **Faible** | Désactivé en prod ✅ |

**Positif** : Security headers, config validation, CORS strict, `.env` gitignoré.

### A06 — Vulnerable & Outdated Components

| Constat | Gravité | Correctif |
|---------|---------|-----------|
| npm audit | **Modéré** | cookie, jose, node-forge, qs, lodash (principalement dev deps) |
| `@lhci/cli`, `newman` | **Dev** | Mettre à jour ou retirer si non utilisés |
| CI : govulncheck, npm audit, cargo audit | ✅ | Présents |

### A07 — Identification & Authentication Failures

| Constat | Gravité | Correctif |
|---------|---------|-----------|
| OAuth user lookup non implémenté | **Moyenne** | Implémenter le lookup |
| 2FA login flow | **Élevée** | Vérifier et corriger le flow |

**Positif** : Password policy, bcrypt cost 12, account lockout, token version, refresh rotation.

### A08 — Software & Data Integrity Failures

| Constat | Gravité | Correctif |
|---------|---------|-----------|
| CI/CD | ✅ | Trivy, SBOM, cosign signing |
| Input validation | ✅ | Zod + validator |
| Webhook signature | ✅ | Hyperswitch webhooks vérifiés |

### A09 — Logging & Monitoring Failures

| Constat | Gravité | Correctif |
|---------|---------|-----------|
| Logging structuré | ✅ | Zap (Go), tracing (Rust), Sentry |
| Audit trail | ✅ | `audit_logs` table |
| Secret filtering | ✅ | `WrapLoggerWithSecretFilter()` |

### A10 — SSRF

| Constat | Gravité | Correctif |
|---------|---------|-----------|
| OAuth callbacks | **Faible** | Providers connus uniquement |
| Stream server → fichiers | **Faible** | Accès fichiers locaux seulement |
| Pas de fetch user-controlled URL | ✅ | Aucun pattern dangereux |

### Résumé sécurité

| Catégorie OWASP | Gravité max | État |
|-----------------|-------------|------|
| A01 — Access Control | Élevée | ⚠️ HLS public, routes fantômes |
| A02 — Crypto | Moyenne | ⚠️ Secrets test hardcodés |
| A03 — Injection | Faible | ✅ Protégé |
| A04 — Insecure Design | Moyenne | ⚠️ Download public, rate limit bypass |
| A05 — Misconfiguration | Moyenne | ⚠️ Bypass flags |
| A06 — Outdated Components | Modéré | ⚠️ npm vulns (dev deps) |
| A07 — Auth Failures | Élevée | ⚠️ 2FA, OAuth |
| A08 — Integrity | N/A | ✅ CI/CD sécurisé |
| A09 — Logging | N/A | ✅ Complet |
| A10 — SSRF | N/A | ✅ RAS |

---

## 5. Dette technique

### 5.1 Dette critique (bloquante)

| Problème | Localisation | Impact | Effort |
|----------|-------------|--------|--------|
| **~80+ `.unwrap()` / `.expect()`** | `veza-stream-server/`, `veza-chat-server/` | Crash des services en production | L |
| **`panic()` si Redis down** | `routes_core.go` | Backend crash si Redis indisponible | S |
| **OAuth user lookup manquant** | `database.go:559` | OAuth non fonctionnel | M |
| **2FA login flow** | `TwoFactorVerify.tsx` | Feature inutilisable | M |

### 5.2 Dette structurante

| Problème | Localisation | Impact | Effort |
|----------|-------------|--------|--------|
| Dual-pattern views/pages | `components/views/` vs `features/*/pages/` | Confusion architecturale | L |
| ~137 fichiers .md à la racine | Racine | Pollution, navigabilité | M |
| 25+ fichiers .json à la racine | Racine | TODOs, rapports accumulés | S |
| Code mort : Education, Studio, Gamification | Backend + Frontend | Code fantôme | M |
| `pages/` directory legacy | `apps/web/src/pages/` | Doublon | M |
| Go version mismatch | go.mod vs CI | Build incohérent | S |

### 5.3 Dette cosmétique

| Problème | Localisation | Impact | Effort |
|----------|-------------|--------|--------|
| 72+ TODOs/FIXMEs | Tous les services | Code inachevé documenté | Variable |
| Coverage reports | `*.out` | Non gitignorés | S |
| Test results committés | `e2e-results.json`, `test-results/` | Artefacts de build | S |

---

## 6. Qualité architecturale

### 6.1 Score d'architecture : 6/10

**Positif** : Séparation des services, communication HTTP/WebSocket/RabbitMQ, `veza-common`, feature-based frontend.

**Négatif** : Dual-pattern views/pages, config Go monolithique, features fantômes, 3 points d’entrée serveur.

### 6.2 Score de maintenabilité : 5/10

**Positif** : Tests unitaires, Storybook, TypeScript strict, Zod, OpenAPI, i18n.

**Négatif** : 470K+ LOC, ~137 fichiers .md, documentation dispersée, onboarding difficile.

### 6.3 Score de sécurité : 6/10

**Positif** : Bcrypt cost 12, JWT rotation, CSRF, rate limiting, security headers, audit trail.

**Négatif** : Vulnérabilités npm, HLS public, `.unwrap()` en Rust, 2FA cassé, bypass flags.

### 6.4 Score de scalabilité : 7/10

**Positif** : Microservices, K8s ready, PostgreSQL read replicas, Redis, RabbitMQ.

**Négatif** : Pas de sharding, pas de circuit breaker, pas de service mesh.

---

## 7. Infra & DevOps

### 7.1 Docker

| Aspect | État | Détail |
|--------|------|--------|
| Multi-stage builds | ✅ | Tous les Dockerfiles |
| Non-root user | ✅ | UID 1001 |
| Health checks | ✅ | Configurés |
| Image minimale | ✅ | Alpine Linux |
| Secrets dans le build | ✅ | Pas de secrets dans les images |

### 7.2 CI/CD

| Aspect | État | Détail |
|--------|------|--------|
| Backend Go | ✅ | Vet, lint, test, build, govulncheck |
| Rust services | ✅ | cargo audit, lint, build, test |
| Frontend | ✅ | Lint, typecheck, test, build |
| E2E | ✅ | Postgres, Redis, RabbitMQ, migrations, Playwright |
| CD | ✅ | Trivy, SBOM, cosign, push registry |
| Playwright workflow | ❌ Supprimé | E2E intégrés dans ci.yml |

### 7.3 Production

- **docker-compose.prod.yml** : Canonique
- **HAProxy** : HTTP→HTTPS, routing vers backend, chat, stream, web
- **Secrets** : `DB_PASS`, `RABBITMQ_PASS`, `JWT_SECRET` requis

---

## 8. Risques business

### 8.1 CTO

- **Peut-on lancer en prod ?** Non. Corriger `.unwrap()` Rust, 2FA, HLS auth, Redis panic.
- **Peut-on maintenir ?** Oui, avec effort. Dette structurelle et documentation à nettoyer.
- **Faut-il refactorer ?** Oui, ciblé. Dual-pattern views, config Go, code mort.

### 8.2 Investisseur

- **Peut-on vendre le produit ?** Le produit a de la valeur fonctionnelle. Stabilisation requise avant due diligence.
- **Risques de réputation ?** Vulnérabilités npm (dev deps), HLS public — à corriger avant communication publique.

### 8.3 Acquéreur

- **Faut-il réécrire ?** Non. Refactoring ciblé suffisant.
- **Dette technique ?** Élevée mais gérable. Plan de remédiation clair.

---

## 9. Plan d'action priorisé

### Phase 1 — Urgent (sécurité & stabilité)

| Action | Effort | Priorité |
|--------|--------|----------|
| Protéger les endpoints HLS (JWT ou signature) | M | P0 |
| Corriger le flow 2FA login | S | P0 |
| Fallback gracieux si Redis down (CSRF) | S | P0 |
| Remplacer `.unwrap()` / `.expect()` critiques en Rust | L | P0 |
| Aligner Go version (go.mod / CI) | S | P1 |

### Phase 2 — Stabilisation

| Action | Effort | Priorité |
|--------|--------|----------|
| Implémenter OAuth user lookup | M | P1 |
| Supprimer les routes Education fantômes | S | P1 |
| Mettre à jour npm dev deps vulnérables | S | P1 |
| Protéger les bypass flags en prod | S | P1 |
| Corriger les tests E2E auth | M | P1 |

### Phase 3 — Amélioration & refonte

| Action | Effort | Priorité |
|--------|--------|----------|
| Unifier dual-pattern views/pages | L | P2 |
| Nettoyer code mort (Education, Studio, Gamification) | M | P2 |
| Réorganiser documentation (~137 .md) | M | P2 |
| Réduire .unwrap() restants en Rust | L | P2 |
| Découper config Go | M | P2 |

---

## Conclusion stratégique

Le monorepo Veza est **techniquement viable** avec une architecture microservices cohérente et des bases de sécurité solides. Les principaux blocages sont :

1. **Sécurité** : HLS public, 2FA cassé, bypass flags, vulnérabilités npm (dev deps), `.unwrap()` en Rust.
2. **Stabilité** : Panic Redis, crash des services Rust.
3. **Dette** : Dual-pattern views, code mort, pollution documentaire.

**Recommandation** : Exécuter la Phase 1 (1–2 semaines) avant toute mise en production. Les Phases 2 et 3 peuvent être planifiées sur 2–4 semaines supplémentaires selon les priorités produit.

---

*Rapport généré le 16 février 2026. Fichiers critiques cités : `veza-backend-api/internal/middleware/auth.go`, `veza-backend-api/internal/api/routes_core.go`, `apps/web/src/config/env.ts`, `config/haproxy/haproxy.cfg`, `docker-compose.prod.yml`, `veza-chat-server/Cargo.toml`, `veza-stream-server/Cargo.toml`.*