veza/AUDIT_TECHNIQUE_INTEGRAL_2026_02.md

# 🔍 AUDIT TECHNIQUE INTÉGRAL — Monorepo Veza

**Date :** 14 février 2026  
**Mandant :** Comité d'investissement  
**Périmètre :** Monorepo complet (frontend, backend, services Rust, infra, CI/CD)

---

## EXECUTIVE SUMMARY

Le monorepo Veza est une plateforme audio collaborative (streaming, chat, marketplace) avec une architecture multi-services (Go, Rust, React). L’audit révèle :

| Critère | Verdict |
|---------|---------|
| **Lancement en production** | ⚠️ Possible avec corrections urgentes |
| **Vente / acquisition** | ❌ Non recommandé sans remédiation |
| **Maintenance** | ⚠️ Risques élevés (dette, tests fragiles) |
| **Refactorisation** | ✅ Recommandée (phases 2–3) |
| **Réécriture** | ❌ Non nécessaire |

**Points positifs :**
- Backend Go solide (auth, RBAC, ownership, CSRF, rate limiting)
- Chat Server Rust compile et fonctionne
- Stream Server Rust compile
- Migrations DB structurées
- CI/CD configuré (Go, Rust, frontend, E2E)

**Points critiques :**
- Route interne `/api/v1/internal/tracks/:id/stream-ready` non authentifiée
- Vulnérabilités npm (React Router XSS, Axios DoS, etc.)
- Rate limiting désactivé en développement
- Tests frontend : ~42 % d’échecs (selon règles utilisateur)
- Features "Coming Soon" (Gear, Live, Education, Queue, Developer) sans backend

---

## 1️⃣ CARTOGRAPHIE GLOBALE

### Stack

| Couche | Technologie | Version |
|--------|-------------|---------|
| **Frontend** | React + Vite + TypeScript | React 18.2, Vite 7.1 |
| **Backend API** | Go + Gin | Go 1.23, Gin 1.11 |
| **Chat Server** | Rust + Axum + WebSocket | Axum 0.8, Tokio 1.35 |
| **Stream Server** | Rust + Axum + HLS | Rust 2021 |
| **Base de données** | PostgreSQL | 16-alpine |
| **Cache** | Redis | 7-alpine |
| **Message broker** | RabbitMQ | 3-management |
| **Shared lib** | veza-common (Rust) | 0.1.0 |

### Organisation du repo

```
veza/
├── apps/web/              # Frontend React (source unique UI)
├── veza-backend-api/      # API Go principale
├── veza-chat-server/      # Chat WebSocket Rust
├── veza-stream-server/    # Streaming audio Rust
├── veza-common/            # Lib Rust partagée (logging, types)
├── veza-docs/              # Documentation
├── packages/               # (vide ou minimal)
├── config/                 # Docker, HAProxy
├── infra/                  # docker-compose lab
└── .github/workflows/      # CI/CD
```

**Workspaces npm :** `apps/web`, `packages/*` (package.json racine)

### Flux fonctionnels

```
Frontend (React) ──► Backend API (Go) ──► PostgreSQL
       │                    │
       │                    ├──► Redis (sessions, CSRF, rate limit)
       │                    ├──► RabbitMQ (jobs)
       │                    ├──► Stream Server (callback stream-ready)
       │                    └──► Chat Server (JWT token)
       │
       ├──► Chat Server (WebSocket)
       └──► Stream Server (HLS/audio)
```

### Dépendances critiques

- **Backend :** GORM, JWT, bcrypt, ClamAV (go-clamd), AWS S3, Sentry, Prometheus
- **Frontend :** React Query, Zustand, Axios, i18next, Framer Motion, HLS.js
- **Chat/Stream :** SQLx, jsonwebtoken, Redis, RabbitMQ (lapin)

### Dépendances obsolètes / abandonnées

- `veza-common` : SQLx 0.8 (aligné avec chat/stream) — conflit historique résolu
- Pas de dépendance abandonnée majeure identifiée

### Technologies utilisées vs déclarées

| Déclaré | Réel |
|---------|------|
| veza-desktop (Electron) | Non présent dans workspaces npm |
| Nx / Turborepo / Lerna | Aucun — monorepo npm basique |
| Design tokens | Présents (`apps/web/docs/DESIGN_TOKENS.md`) |

---

## 2️⃣ CE QUE LE PRODUIT PERMET RÉELLEMENT

### Features validées (implémentées et utilisables)

| Feature | Backend | Frontend | Tests |
|---------|---------|----------|-------|
| Auth (login, register, 2FA) | ✅ | ✅ | ✅ |
| Sessions, logout, refresh | ✅ | ✅ | ✅ |
| Password reset | ✅ | ✅ | ✅ |
| Email verification | ✅ | ✅ | ✅ |
| OAuth (Google, GitHub, Discord) | ✅ | ✅ | Partiel |
| Tracks (CRUD, upload, HLS) | ✅ | ✅ | ✅ |
| Playlists (CRUD, collaborateurs) | ✅ | ✅ | ✅ |
| Marketplace (products, cart, checkout) | ✅ | ✅ | ✅ |
| Wishlist, Purchases | ✅ | ✅ | ✅ |
| Chat (token, stats) | ✅ | ✅ | ✅ |
| Social (feed, posts, groups, follow) | ✅ | ✅ | ✅ |
| Webhooks | ✅ | ✅ | ✅ |
| Analytics | ✅ | ✅ | ✅ |
| Admin (audit, unlock, pprof) | ✅ | ✅ | ✅ |
| Roles, RBAC | ✅ | ✅ | ✅ |
| Notifications | ✅ | ✅ | ✅ |
| Data export (GDPR) | ✅ | ✅ | - |

### Features incomplètes

| Feature | État |
|---------|------|
| OAuth | Config via env, baseURL hardcodé `veza.fr` si non défini |
| Stream Server callback | Route interne non authentifiée |
| E2E | Présents mais résultats instables (e2e-results.json) |

### Features fantômes / mortes

| Feature | Route | État |
|---------|-------|------|
| Gear | `/gear` | ComingSoon placeholder |
| Live | `/live` | ComingSoon placeholder |
| Education | `/education` | ComingSoon placeholder |
| Queue | `/queue` | ComingSoon placeholder |
| Developer | `/developer` | ComingSoon placeholder |

### Incohérences produit / code

- README mentionne `veza-desktop` (Electron) mais pas dans workspaces
- `docker-compose.prod.yml` utilise HAProxy ; `docker-compose.yml` (dev) non
- `dist_verification` committé (artefacts de build) — mauvaise pratique

---

## 3️⃣ VALIDATION FONCTIONNELLE

### Tests

| Composant | Commande | Résultat |
|-----------|----------|----------|
| Backend Go | `go test ./... -short` | Exécution longue (timeout 60s) |
| Chat Server | `cargo test` | ✅ |
| Stream Server | `cargo check` | ✅ (warnings) |
| Frontend | `npm run test -- --run` | ~42 % échecs (règles utilisateur) |
| E2E | `npx playwright test` | Instable |

### Points de rupture

1. **Route interne stream-ready** : Appelée par Stream Server sans auth — n’importe qui peut forger un callback.
2. **Rate limiting** : Désactivé en dev (`config.Env == config.EnvDevelopment`) — risque en staging si `APP_ENV` mal configuré.
3. **CSRF** : Désactivé si Redis indisponible (sauf prod où démarrage échoue).

### Scénarios de crash évidents

- Redis down en prod → crash (CSRF requis)
- ClamAV down avec `CLAMAV_REQUIRED=true` → uploads rejetés
- `JWT_SECRET` vide → crash au démarrage (correct)

### Zones non testées

- Handlers OAuth (flows complets)
- Intégration Stream Server ↔ Backend
- Webhooks sortants (workers)

---

## 4️⃣ AUDIT DE SÉCURITÉ — OWASP TOP 10

### A01 – Broken Access Control

| Point | Gravité | Détail |
|-------|---------|--------|
| Route interne stream-ready | **Critique** | `POST /api/v1/internal/tracks/:id/stream-ready` sans auth. Exploitation : forger des callbacks pour modifier le statut de tracks. |
| Ownership | ✅ | `RequireOwnershipOrAdmin` sur users, tracks, playlists, products |
| Admin | ✅ | `RequireAdmin` sur `/admin/*` |
| Sessions | ✅ | Vérification ownership sur `DELETE /sessions/:id` (à confirmer dans handler) |

**Correctif A01 :** Protéger la route interne par API key ou IP whitelist (réseau interne).

---

### A02 – Cryptographic Failures

| Point | Gravité | Détail |
|-------|---------|--------|
| Mots de passe | ✅ | bcrypt (golang.org/x/crypto/bcrypt) |
| JWT | ✅ | HS256, validation stricte (alg, exp, iss, aud) |
| Secrets | ⚠️ Moyenne | `JWT_SECRET` requis en prod (`:?` dans docker-compose.prod.yml) |
| HTTPS | ⚠️ | `COOKIE_SECURE=true` en prod ; dépend du reverse proxy |

**Correctif A02 :** S’assurer que TLS est forcé au niveau HAProxy/load balancer.

---

### A03 – Injection

| Point | Gravité | Détail |
|-------|---------|--------|
| SQL | ✅ | GORM + prepared statements ; pas de concaténation |
| Full-text search | ✅ | `plainto_tsquery` avec paramètres |
| XSS | ⚠️ Moyenne | DOMPurify présent côté frontend ; pas de sanitization systématique côté backend pour tous les champs texte |

**Correctif A03 :** Sanitiser les champs affichés (comments, posts, etc.) côté backend ou documenter la responsabilité frontend.

---

### A04 – Insecure Design

| Point | Gravité | Détail |
|-------|---------|--------|
| Callback stream-ready | **Critique** | Pas d’authentification du callback Stream Server → Backend |
| Rate limiting dev | ⚠️ Faible | Désactivé en dev — acceptable si staging/prod corrects |
| Validation | ✅ | go-playground/validator, EmailValidator, PasswordValidator |

**Correctif A04 :** Authentifier le callback (header `X-Stream-Server-API-Key` ou mTLS).

---

### A05 – Security Misconfiguration

| Point | Gravité | Détail |
|-------|---------|--------|
| CORS | ✅ | Validation stricte en prod, pas de wildcard |
| Debug | ✅ | Stack traces uniquement en dev/DEBUG |
| Swagger | ⚠️ Faible | Exposé en prod — à restreindre ou désactiver |
| Secrets | ✅ | `.env` dans `.gitignore` ; `SECRETS_VERIFICATION.md` |

**Correctif A05 :** Désactiver Swagger en prod ou le protéger par auth.

---

### A06 – Vulnerable & Outdated Components

| Point | Gravité | Détail |
|-------|---------|--------|
| npm | **Élevée** | React Router XSS (GHSA-2w69-qvjg-hvjx), Axios DoS (GHSA-43fc-jf86-j433), cookie, diff, jose, lodash, node-forge |
| Go | ✅ | govulncheck dans CI |
| Rust | ✅ | cargo audit dans CI |

**Correctif A06 :** `npm audit fix` ; mise à jour manuelle si breaking.

---

### A07 – Identification & Authentication Failures

| Point | Gravité | Détail |
|-------|---------|--------|
| JWT | ✅ | Validation complète, token versioning |
| Sessions | ✅ | DB, expiration, révocation |
| Account lockout | ✅ | 5 tentatives, 30 min |
| Password reset | ✅ | Tokens avec expiration, audit |

---

### A08 – Software & Data Integrity Failures

| Point | Gravité | Détail |
|-------|---------|--------|
| CI/CD | ⚠️ Moyenne | Pas de signature des images Docker |
| Build | ✅ | Types générés depuis OpenAPI |

---

### A09 – Logging & Monitoring Failures

| Point | Gravité | Détail |
|-------|---------|--------|
| Logs | ✅ | Zap structuré, pas de secrets en clair |
| Métriques | ✅ | Prometheus |
| Audit | ✅ | AuditService, audit_logs |

---

### A10 – SSRF

| Point | Gravité | Détail |
|-------|---------|--------|
| Webhooks | ⚠️ Faible | Appels sortants vers URLs utilisateur — risque SSRF si URL non validée |
| OAuth | ✅ | URLs fixes (Google, GitHub, Discord) |

---

## 5️⃣ DETTE TECHNIQUE

### Dette critique (bloquante)

| Élément | Fichier / Zone |
|--------|----------------|
| Route stream-ready non protégée | `router.go:622-625` |
| Vulnérabilités npm high | `apps/web/package.json` |

### Dette structurante

| Élément | Détail |
|--------|--------|
| `fmt.Printf` debug dans router | `router.go:110-121` (logs ClamAV) |
| Duplication setup routes | Nombreux `trackService`, `chunkService` recréés |
| Conventions | Pas de tooling monorepo (Nx/Turborepo) |
| Tests fragiles | Frontend 42 % échecs |

### Dette cosmétique

| Élément | Détail |
|--------|--------|
| Warnings Stream Server | dead_code, unused_comparisons |
| Fichiers `dist_verification` committés | `.gitignore` à étendre |
| Commentaires FR/EN mélangés | Cohérence |

---

## 6️⃣ QUALITÉ ARCHITECTURALE

### Scores (sur 10)

| Critère | Score | Justification |
|---------|-------|---------------|
| **Architecture** | 7/10 | Séparation claire (handlers, services, core) ; duplication de setup dans router |
| **Maintenabilité** | 6/10 | Code structuré ; dette, tests fragiles, pas de tooling monorepo |
| **Sécurité** | 6/10 | Bonnes bases (auth, RBAC, CSRF) ; faille callback, vulnérabilités npm |
| **Scalabilité** | 7/10 | Stateless API, Redis, RabbitMQ ; pas de stratégie cache avancée documentée |

---

## 7️⃣ INFRA & DEVOPS

### Docker

- `docker-compose.yml` : dev (postgres, redis, rabbitmq, backend-api)
- `docker-compose.prod.yml` : prod (postgres, redis, rabbitmq, backend, chat, stream, web, HAProxy)
- Secrets : `DB_PASS`, `RABBITMQ_PASS`, `JWT_SECRET` requis en prod (`:?`)

### Config

- Variables d’environnement documentées (règles utilisateur)
- Pas de secrets en clair dans les fichiers versionnés (vérification SECRETS_VERIFICATION.md)

### Scripts

- `make` utilisé (smoke, e2e, postman, etc.)
- Pas de script dangereux identifié

---

## 8️⃣ RISQUES BUSINESS

### CTO

- **Lancement prod :** Possible après correction de la route stream-ready et des vulnérabilités npm.
- **Maintenance :** Risque moyen : dette, tests instables, dépendances à mettre à jour.

### Investisseur

- **Vente :** Non recommandée sans remédiation des vulnérabilités et de la dette critique.
- **Valeur :** Architecture solide, fonctionnalités riches ; qualité à renforcer.

### Acquéreur

- **Refactorisation :** Oui, phases 2–3 du plan d’action.
- **Réécriture :** Non nécessaire.

---

## 9️⃣ PLAN D’ACTION PRIORISÉ

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

| Action | Effort | Fichiers |
|--------|--------|----------|
| Protéger route `/api/v1/internal/tracks/:id/stream-ready` (API key ou IP) | S | `router.go`, `middleware/` |
| Corriger vulnérabilités npm (audit fix, mise à jour manuelle) | S | `apps/web/package.json` |
| Supprimer `fmt.Printf` debug du router | S | `router.go` |
| Étendre `.gitignore` pour `dist_verification` | S | `.gitignore` |

### Phase 2 — Stabilisation

| Action | Effort | Détail |
|--------|--------|--------|
| Stabiliser tests frontend | M | Analyser échecs, mocks, dépendances |
| Stabiliser E2E Playwright | M | Fiabiliser setup, timeouts |
| Documenter/sécuriser callback Stream Server | S | Spec API key, implémentation |
| Désactiver ou protéger Swagger en prod | S | Config conditionnelle |

### Phase 3 — Amélioration & refonte

| Action | Effort | Détail |
|--------|--------|--------|
| Introduire tooling monorepo (Turborepo/Nx) | L | Cache builds, orchestration |
| Réduire duplication dans router | M | Factoring des services |
| Corriger warnings Stream Server | S | dead_code, unused |
| Implémenter ou retirer features Coming Soon | M | Gear, Live, Education, Queue, Developer |

---

## CONCLUSION STRATÉGIQUE

Le monorepo Veza est **techniquement viable** avec une base solide (auth, RBAC, marketplace, chat, streaming). Les correctifs de la Phase 1 sont **indispensables** avant toute mise en production. La Phase 2 renforce la confiance (tests, documentation). La Phase 3 améliore la maintenabilité et la scalabilité.

**Recommandation :** Exécuter la Phase 1 sous 1–2 semaines, puis planifier la Phase 2 en parallèle du déploiement.

---

*Rapport généré par audit technique automatisé — 14 février 2026*