# 🔍 AUDIT EXHAUSTIF — PROJET VEZA

**Date** : 2025-01-27  
**Auditeur** : Audit technique senior (sécurité + architecture + performance)  
**Repository** : `/home/senke/Documents/veza`  
**Objectif** : Cartographier l'état actuel du projet et proposer un plan de remédiation réaliste

---

## 📋 TABLE DES MATIÈRES

1. [Vue d'ensemble du projet](#1-vue-densemble-du-projet)
2. [Cartographie détaillée du code](#2-cartographie-détaillée-du-code)
3. [État fonctionnel : ce qui marche / est partiel / est cassé](#3-état-fonctionnel)
4. [Sécurité : failles et surfaces d'attaque](#4-sécurité)
5. [Performance & architecture technique](#5-performance--architecture-technique)
6. [Guide d'utilisation du projet (mode actuel réel)](#6-guide-dutilisation)
7. [Axes d'amélioration (sécurité, qualité, features)](#7-axes-damélioration)
8. [Synthèse finale](#8-synthèse-finale)

---

## 1. VUE D'ENSEMBLE DU PROJET

### 1.1 Résumé exécutif

**Veza** est une plateforme audio collaborative en développement, organisée en monorepo avec une architecture micro-services. Le projet vise à fournir un service de streaming audio avec fonctionnalités collaboratives (chat, playlists partagées, transcodage).

**État global** : **"PoC prometteur mais fragile"**

Le projet présente :
- ✅ **Backend Go** : Fonctionnel et relativement stable (92% coverage selon l'audit de stabilité)
- ⚠️ **Chat Server (Rust)** : Compile avec warnings, mais présente des problèmes de race conditions et de gestion d'erreurs
- ⚠️ **Stream Server (Rust)** : Compile avec de nombreux warnings, code partiellement implémenté
- ❌ **Frontend React** : Erreurs TypeScript bloquantes (42% échec de tests selon les règles)

**Points positifs** :
- Architecture claire (monorepo bien structuré)
- Documentation présente (docs/, veza-docs/)
- Système de migrations DB cohérent
- Authentification JWT implémentée
- Tests présents (même si partiellement fonctionnels)

**Points fragiles** :
- Incohérences entre services (pas de transaction distribuée)
- Code mort / partiellement implémenté (notamment dans stream-server)
- Erreurs TypeScript non résolues dans le frontend
- Gestion d'erreurs incomplète dans plusieurs composants
- Race conditions identifiées dans le chat server

**Utilisabilité actuelle** :
- **Backend Go** : Utilisable avec précautions (nécessite PostgreSQL, Redis, variables d'env)
- **Chat Server** : Utilisable en dev, mais nécessite attention aux race conditions
- **Stream Server** : Partiellement fonctionnel, code expérimental présent
- **Frontend** : Non utilisable sans corrections TypeScript

### 1.2 Stack technique identifiée

#### Langages principaux
- **Backend** : Go 1.23.8
- **Chat Server** : Rust (édition 2021)
- **Stream Server** : Rust (édition 2021)
- **Frontend** : TypeScript/React (Vite)
- **Scripts** : Bash, Python (outils)

#### Frameworks et bibliothèques clés

**Backend Go** :
- `gin-gonic/gin` : Framework HTTP
- `gorm.io/gorm` : ORM
- `golang-jwt/jwt/v5` : JWT
- `go.uber.org/zap` : Logging
- `github.com/redis/go-redis/v9` : Client Redis
- `github.com/rabbitmq/amqp091-go` : RabbitMQ

**Chat Server (Rust)** :
- `axum` : Framework web async
- `tokio` : Runtime async
- `sqlx` : SQL async
- `jsonwebtoken` : JWT
- `lapin` : RabbitMQ client
- `tracing` : Logging structuré

**Stream Server (Rust)** :
- `axum` : Framework web
- `tokio` : Runtime async
- `sqlx` : SQL async
- `symphonia`, `hound`, `minimp3` : Traitement audio
- `m3u8-rs` : HLS streaming
- `tracing` : Logging

**Frontend** :
- `react` 18.2.0
- `vite` 7.1.5
- `typescript` 5.3.3
- `tailwindcss` 4.0.0
- `zustand` : State management
- `@tanstack/react-query` : Data fetching
- `playwright` : E2E tests

#### Bases de données et systèmes de stockage
- **PostgreSQL 15** : Base principale (backend, chat, stream)
- **Redis 7** : Cache et sessions
- **RabbitMQ 3.12** : Event bus inter-services

#### Services externes / API
- **Sentry** : Monitoring d'erreurs (configuré mais optionnel)
- **Prometheus** : Métriques (exposées via `/metrics`)

#### Organisation du repo
**Monorepo** avec structure claire :
```
veza/
├── apps/web/              # Frontend React
├── veza-backend-api/      # Backend Go
├── veza-chat-server/      # Chat Server Rust
├── veza-stream-server/    # Stream Server Rust
├── veza-desktop/          # Wrapper Electron
├── veza-common/           # Code partagé Rust
├── veza-rust-common/      # Utilitaires Rust
├── docs/                  # Documentation
├── scripts/               # Scripts de déploiement/test
├── docker/                # Config Docker
└── migrations/            # Migrations globales
```

---

## 2. CARTOGRAPHIE DÉTAILLÉE DU CODE

### 2.1 Structure du repository

#### `veza-backend-api/` (Go)
- **Rôle** : API REST principale, gestion utilisateurs, playlists, tracks, analytics
- **Langage** : Go 1.23.8
- **Niveau de maturité** : ✅ **Stable** (92% coverage, migrations structurées)
- **Structure** :
  - `cmd/api/main.go` : Point d'entrée principal
  - `internal/handlers/` : Handlers HTTP
  - `internal/services/` : Logique métier
  - `internal/models/` : Modèles GORM
  - `internal/middleware/` : Middleware (auth, RBAC, metrics)
  - `internal/database/` : Gestion DB et migrations
  - `migrations/` : Migrations SQL (12 fichiers)

#### `veza-chat-server/` (Rust)
- **Rôle** : Serveur WebSocket pour chat en temps réel
- **Langage** : Rust (édition 2021)
- **Niveau de maturité** : ⚠️ **Partiel** (compile mais warnings, race conditions)
- **Structure** :
  - `src/main.rs` : Point d'entrée
  - `src/websocket/` : Gestion WebSocket
  - `src/repository/` : Accès DB
  - `src/security/` : Permissions, CSRF
  - `src/typing_indicator.rs` : Indicateurs de frappe
  - `migrations/` : Migrations SQL (11 fichiers)

#### `veza-stream-server/` (Rust)
- **Rôle** : Streaming audio (HLS, WebSocket), transcodage
- **Langage** : Rust (édition 2021)
- **Niveau de maturité** : ⚠️ **Partiel / Expérimental** (compile avec warnings, code mort)
- **Structure** :
  - `src/main.rs` : Point d'entrée
  - `src/core/` : Traitement audio, encoding, sync
  - `src/codecs/` : Codecs audio (MP3, AAC, FLAC, Opus)
  - `src/streaming/` : HLS, WebSocket transport
  - `src/routes/` : Routes HTTP
  - `migrations/` : Migrations SQL (2 fichiers)

#### `apps/web/` (React/TypeScript)
- **Rôle** : Interface utilisateur web
- **Langage** : TypeScript/React
- **Niveau de maturité** : ❌ **Cassé** (erreurs TypeScript bloquantes)
- **Structure** :
  - `src/app/` : Point d'entrée React
  - `src/features/` : Features par domaine (auth, player, chat, etc.)
  - `src/components/` : Composants réutilisables
  - `src/services/` : Clients API
  - `e2e/` : Tests Playwright

#### `scripts/` (Bash)
- **Rôle** : Automatisation (déploiement, tests, migrations)
- **Fichiers clés** :
  - `start-veza.sh` : Démarrage complet
  - `migrate-db.sh` : Migrations DB
  - `run-tests.sh` : Tests
  - `lab/` : Scripts pour environnement lab

#### `docs/` (Markdown)
- **Rôle** : Documentation technique
- **Fichiers clés** :
  - `AUDIT_STABILITY.md` : Audit de stabilité existant
  - `DB_MIGRATIONS_STRATEGY_FINAL.md` : Stratégie migrations
  - `TODO_TRIAGE_VEZA.md` : Tâches en cours

### 2.2 Points d'entrée

#### Backend Go
**Fichier principal** : `veza-backend-api/cmd/api/main.go`

**Commande de lancement** :
```bash
cd veza-backend-api
go run ./cmd/api
```

**Dépendances** :
- PostgreSQL (via `DATABASE_URL`)
- Redis (via `REDIS_URL`)
- Variables d'environnement :
  - `JWT_SECRET` (requis)
  - `DB_PASSWORD` (requis)
  - `APP_PORT` (défaut: 8080)
  - `APP_ENV` (défaut: development)

**Port** : 8080 (configurable)

#### Chat Server (Rust)
**Fichier principal** : `veza-chat-server/src/main.rs`

**Commande de lancement** :
```bash
cd veza-chat-server
cargo run --release
```

**Dépendances** :
- PostgreSQL (via `DATABASE_URL`)
- Redis (optionnel, via `REDIS_URL`)
- RabbitMQ (optionnel, via `RABBITMQ_URL`)
- Variables d'environnement :
  - `JWT_SECRET` (requis, min 32 caractères)
  - `CHAT_SERVER_PORT` (défaut: 8081)

**Port** : 8081 (configurable)

#### Stream Server (Rust)
**Fichier principal** : `veza-stream-server/src/main.rs`

**Commande de lancement** :
```bash
cd veza-stream-server
cargo run --release
```

**Dépendances** :
- PostgreSQL (via `DATABASE_URL`)
- Redis (via `REDIS_URL`)
- Variables d'environnement :
  - `JWT_SECRET` (requis)
  - `STREAM_PORT` (défaut: 8082)
  - `SECRET_KEY` (requis, 32 bytes)

**Port** : 8082 (configurable)

#### Frontend React
**Fichier principal** : `apps/web/src/main.tsx`

**Commande de lancement** :
```bash
cd apps/web
npm install
npm run dev
```

**Dépendances** :
- Node.js 18+
- Variables d'environnement :
  - `VITE_API_URL` (défaut: http://localhost:8080/api)
  - `VITE_WS_URL` (défaut: ws://localhost:8081/ws)
  - `VITE_STREAM_URL` (défaut: ws://localhost:8082/stream)

**Port** : 5173 (Vite dev server)

#### Docker Compose (tous services)
**Fichier** : `docker-compose.yml`

**Commande de lancement** :
```bash
docker-compose up -d
```

**Services** :
- `postgres` : PostgreSQL 15
- `redis` : Redis 7
- `rabbitmq` : RabbitMQ 3.12
- `backend-api` : Backend Go
- `chat-server` : Chat Server Rust
- `stream-server` : Stream Server Rust
- `frontend` : Frontend React (Nginx)
- `haproxy` : Reverse proxy

### 2.3 Tests & qualité

#### Backend Go
**Types de tests** : Unitaires, intégration, transactions

**Commande** :
```bash
cd veza-backend-api
go test ./... -v
```

**Résultat** : ✅ **Fonctionnel** (92% coverage selon AUDIT_STABILITY.md)

**Linters** : Pas de linter configuré explicitement (gofmt standard)

#### Chat Server (Rust)
**Types de tests** : Unitaires (certains marqués `#[ignore]` car nécessitent DB)

**Commande** :
```bash
cd veza-chat-server
cargo test
```

**Résultat** : ⚠️ **Partiel** (tests nécessitant DB ignorés)

**Linters** : `cargo clippy` (non exécuté dans l'audit)

#### Stream Server (Rust)
**Types de tests** : Unitaires (peu présents)

**Commande** :
```bash
cd veza-stream-server
cargo test
```

**Résultat** : ⚠️ **Partiel** (peu de tests)

**Linters** : `cargo clippy` (non exécuté dans l'audit)

#### Frontend React
**Types de tests** : Unitaires (Vitest), E2E (Playwright)

**Commande** :
```bash
cd apps/web
npm test              # Unitaires
npm run test:e2e      # E2E
```

**Résultat** : ❌ **Cassé** (42% échec selon règles, erreurs TypeScript)

**Linters** : ESLint configuré (`npm run lint`)

#### CI/CD
**Fichiers** : `.github/workflows/`
- `backend-ci.yml` : Tests Go
- `chat-ci.yml` : Tests Rust (chat)
- `stream-ci.yml` : Tests Rust (stream)
- `frontend-ci.yml` : Tests React
- `ci.yml` : Pipeline global

**Status** : Configuré mais non validé dans cet audit

---

## 3. ÉTAT FONCTIONNEL

### 3.1 Tableau de synthèse

| Composant / Module | Rôle | Langage / Tech | État | Commentaire technique | Commande(s) |
|-------------------|------|---------------|------|---------------------|-------------|
| **Backend API** | API REST principale | Go 1.23 / Gin | ✅ | Fonctionnel, 92% coverage. Gestion JSON robuste. | `go run ./cmd/api` |
| **Chat Server** | WebSocket chat | Rust / Axum | ⚠️ | Compile mais race conditions (TypingIndicatorManager). Warnings. | `cargo run --release` |
| **Stream Server** | Streaming audio | Rust / Axum | ⚠️ | Compile avec warnings. Code mort présent. FFmpeg monitoring fragile. | `cargo run --release` |
| **Frontend Web** | Interface utilisateur | React / Vite | ❌ | Erreurs TypeScript bloquantes. Imports manquants. | `npm run dev` (ne démarre pas proprement) |
| **Database Migrations** | Schéma DB | SQL | ✅ | Migrations structurées (12 backend, 11 chat, 2 stream). UUID-first. | `scripts/migrate-db.sh` |
| **Docker Compose** | Orchestration | Docker | ✅ | Configuration complète. Health checks présents. | `docker-compose up` |
| **Authentication** | JWT + Sessions | Go/Rust | ✅ | JWT HS256, refresh tokens, sessions validées. | Intégré |
| **RBAC** | Permissions | Go | ✅ | Service PermissionService, middleware RequirePermission. | Intégré |
| **Event Bus** | Communication inter-services | RabbitMQ | ⚠️ | Implémenté mais optionnel (mode dégradé si absent). | Via RabbitMQ |
| **Health Checks** | Monitoring | HTTP | ✅ | `/health` (stateless), `/status` (avec DB check). | Intégré |

### 3.2 Détail par composant

#### 3.2.1 Backend Go (`veza-backend-api`)

**Description** : API REST pour gestion utilisateurs, playlists, tracks, analytics, chat (legacy).

**Implémentation actuelle** :
- **Fichiers clés** :
  - `cmd/api/main.go` : Point d'entrée avec graceful shutdown
  - `internal/api/router.go` : Configuration routes
  - `internal/handlers/` : Handlers HTTP (auth, social, playlists, etc.)
  - `internal/services/` : Services métier (auth, playlist, RBAC, etc.)
  - `internal/middleware/auth.go` : Middleware JWT + sessions
  - `internal/middleware/rbac_auth_middleware.go` : RBAC
  - `internal/database/database.go` : Gestion DB + migrations

- **Endpoints importants** :
  - `POST /api/v1/auth/login` : Authentification
  - `POST /api/v1/auth/register` : Inscription
  - `GET /api/v1/playlists` : Liste playlists
  - `GET /api/v1/tracks` : Liste tracks
  - `GET /health` : Health check
  - `GET /status` : Status avec DB check

- **Couverture de tests** : 92% (selon AUDIT_STABILITY.md)

**État réel** :
- ✅ **Marche bien** : Compilation OK, démarrage OK, endpoints principaux fonctionnels
- ⚠️ **Points de fragilité** :
  - Erreurs silencieuses dans certains handlers (résolu partiellement avec `BindAndValidateJSON`)
  - Absence de transactions dans certaines opérations multi-étapes
  - Race condition dans workers retries
  - Timing attack potentiel sur password reset

**Points de fragilité** :
- **Hypothèses implicites** : DB toujours disponible (pas de circuit breaker)
- **Gestion d'erreur** : Certaines erreurs DB non wrappées avec contexte
- **Couplage** : Dépendance forte à PostgreSQL (pas de fallback)
- **Legacy** : Code chat legacy présent (`internal/api/` vs `internal/handlers/`)

#### 3.2.2 Chat Server (`veza-chat-server`)

**Description** : Serveur WebSocket pour chat en temps réel avec gestion des conversations, typing indicators, read receipts.

**Implémentation actuelle** :
- **Fichiers clés** :
  - `src/main.rs` : Point d'entrée avec Axum
  - `src/websocket/handler.rs` : Handler WebSocket
  - `src/repository/message_store.rs` : Repository messages
  - `src/typing_indicator.rs` : Gestion typing indicators
  - `src/read_receipts.rs` : Read receipts
  - `src/security/permission.rs` : Vérifications permissions

- **Endpoints** :
  - `GET /ws` : WebSocket upgrade
  - `GET /api/messages/:conversation_id` : Récupération messages
  - `POST /api/messages` : Envoi message
  - `GET /health` : Health check

**État réel** :
- ⚠️ **Marche mais avec limitations** :
  - Compile avec warnings (unused imports, variables)
  - Race condition dans `TypingIndicatorManager` (RwLock vs Mutex)
  - Race conditions dans `DeliveredStatusManager` et `ReadReceiptManager`
  - Pas de panic boundary dans `handle_socket`
  - Tasks orphelins possibles (monitoring typing indicators)
  - Pas de heartbeat timeout pour détecter connexions zombies

**Points de fragilité** :
- **Race conditions** : TypingIndicatorManager, DeliveredStatusManager, ReadReceiptManager
- **Gestion d'erreur** : 31 fichiers avec `unwrap()` ou `expect()` (panics possibles)
- **Tasks** : Pas de mécanisme de shutdown propre pour certaines tasks
- **Permissions** : Risque de bypass si PermissionService échoue (fail-secure non garanti)

#### 3.2.3 Stream Server (`veza-stream-server`)

**Description** : Serveur de streaming audio avec transcodage (HLS, WebSocket), gestion des segments, synchronisation multi-clients.

**Implémentation actuelle** :
- **Fichiers clés** :
  - `src/main.rs` : Point d'entrée
  - `src/core/processing/processor.rs` : Traitement audio
  - `src/core/processing/segment_tracker.rs` : Suivi segments
  - `src/core/processing/ffmpeg_monitor.rs` : Monitoring FFmpeg
  - `src/streaming/hls.rs` : HLS streaming
  - `src/streaming/websocket.rs` : WebSocket transport
  - `src/routes/encoding.rs` : Routes transcodage

**État réel** :
- ⚠️ **Partiellement fonctionnel** :
  - Compile avec de nombreux warnings (unused imports, variables, champs)
  - Code mort présent (champs non lus, méthodes non utilisées)
  - Tasks non cancellées proprement en cas d'erreur (`abort()` brutal)
  - Erreurs FFmpeg non propagées correctement (loggées mais job continue)
  - DB pas toujours sync en cas de crash (segments non persistés)
  - Corruption d'état concurrent possible dans SegmentTracker
  - Regex non robustes dans FFmpegMonitor (pas de fallback)

**Points de fragilité** :
- **Code mort** : Nombreux champs/méthodes non utilisés (refactoring nécessaire)
- **Gestion d'erreur** : Erreurs FFmpeg loggées mais non fatales
- **Concurrence** : SegmentTracker peut avoir des problèmes d'ordre
- **Monitoring** : FFmpegMonitor fragile (regex, IO errors incomplètes)

#### 3.2.4 Frontend React (`apps/web`)

**Description** : Interface utilisateur web pour la plateforme Veza (player audio, chat, playlists, recherche).

**Implémentation actuelle** :
- **Fichiers clés** :
  - `src/app/App.tsx` : Point d'entrée React
  - `src/features/player/` : Player audio
  - `src/features/chat/` : Chat
  - `src/features/auth/` : Authentification
  - `src/services/api.ts` : Client API

**État réel** :
- ❌ **Cassé** :
  - Erreurs TypeScript bloquantes (50+ erreurs)
  - Imports manquants (`@/hooks/use-toast`, `@/components/ui/scroll-area`, etc.)
  - Propriétés manquantes sur types (`Track.url`, `Track.cover_url`)
  - Tests échouent (42% selon règles)

**Points de fragilité** :
- **TypeScript** : Types incomplets, imports manquants
- **Paths aliases** : Configuration `@/` peut être incorrecte
- **Tests** : Échecs nombreux

---

## 4. SÉCURITÉ

### 4.1 Vue d'ensemble sécurité

#### Authentification
- ✅ **JWT** : Implémenté (HS256) dans backend Go et services Rust
- ✅ **Sessions** : Validation côté serveur (backend Go)
- ✅ **Refresh tokens** : Implémentés avec version checking
- ✅ **Token revocation** : Blacklist Redis partielle

#### Autorisation / Rôles
- ✅ **RBAC** : Implémenté (`PermissionService`, middleware `RequirePermission`)
- ✅ **Rôles** : Admin, Moderator, User, Premium, Artist, Guest
- ✅ **Permissions** : Granulaires (StreamAudio, UploadAudio, ManageUsers, etc.)

#### Gestion des mots de passe
- ✅ **Hashing** : bcrypt (cost 12) dans backend Go
- ✅ **Validation** : Force minimale (8 caractères)
- ✅ **Password reset** : Protégé contre énumération (toujours retourne succès)

#### Utilisation de secrets
- ✅ **Stockage** : Variables d'environnement (`.env` non commité)
- ⚠️ **Gestion** : Pas de gestionnaire de secrets centralisé (Vault, etc.)
- ✅ **Masquage** : Secrets masqués dans les logs (`MaskSecret`)

**Niveau général** : **"Minimalement acceptable pour un labo / dev"**

### 4.2 Failles et mauvaises pratiques

#### P0 – Critique (doit être corrigé avant déploiement)

1. **Backend Go : Erreurs JSON non traitées silencieusement**
   - **Localisation** : Résolu partiellement (`BindAndValidateJSON` créé)
   - **Description** : Certains handlers dans `internal/api/` n'utilisent pas encore `BindAndValidateJSON`
   - **Impact** : Erreurs JSON peuvent passer silencieusement
   - **Piste de correction** : Refactoriser tous les handlers pour utiliser `BindAndValidateJSON`

2. **Backend Go : Absence de transactions dans opérations critiques**
   - **Localisation** : `internal/core/marketplace/service.go:134-136` et autres services
   - **Description** : Opérations multi-étapes non transactionnelles
   - **Impact** : Incohérence DB en cas d'erreur partielle
   - **Piste de correction** : Wrapper opérations multi-étapes dans transactions

3. **Chat Server : Race condition dans TypingIndicatorManager**
   - **Localisation** : `src/typing_indicator.rs:34-48`
   - **Description** : RwLock peut causer des inversions de timestamps
   - **Impact** : Broadcasts dans le mauvais ordre
   - **Piste de correction** : Utiliser Mutex ou canal sérialisé

4. **Chat Server : Panics possibles (31 fichiers avec `unwrap()`)**
   - **Localisation** : 31 fichiers identifiés
   - **Description** : `unwrap()` et `expect()` peuvent causer des panics
   - **Impact** : Crash du serveur
   - **Piste de correction** : Remplacer par `?` ou gestion d'erreur explicite

5. **Stream Server : Tasks non cancellées proprement**
   - **Localisation** : `src/core/processing/processor.rs:168-169`
   - **Description** : `abort()` tue brutalement les tasks
   - **Impact** : Transactions DB non commitées, handles orphelins
   - **Piste de correction** : Utiliser `CancellationToken`, attendre fin des tasks

6. **Global : Pas de transaction distribuée**
   - **Localisation** : Tous les services
   - **Description** : Pas de garantie de cohérence inter-services
   - **Impact** : Données incohérentes entre services
   - **Piste de correction** : Pattern Saga ou Event Sourcing

7. **Global : Manque de tests unitaires critiques**
   - **Localisation** : Tous les services
   - **Description** : Beaucoup de tests `#[ignore]` ou absents
   - **Impact** : Pas de validation automatique
   - **Piste de correction** : Utiliser mocks ou containers Docker pour tests

8. **Global : Jobs/messages/segments peuvent être incohérents**
   - **Localisation** : Tous les services
   - **Description** : Pas de cleanup des données orphelines
   - **Impact** : DB contient des données incohérentes
   - **Piste de correction** : Jobs de cleanup périodiques

#### P1 – Important

1. **Backend Go : Erreurs silencieuses, validation input incomplète**
   - **Localisation** : `internal/handlers/`
   - **Description** : Certains handlers retournent erreurs génériques
   - **Impact** : Debugging difficile
   - **Piste de correction** : Utiliser systématiquement `RespondWithAppError`

2. **Backend Go : Race condition dans workers retries**
   - **Localisation** : `internal/workers/job_worker.go:127-135`
   - **Description** : `Retries` peut être incrémenté plusieurs fois
   - **Impact** : Jobs retry plus que `maxRetries`
   - **Piste de correction** : Mutex ou atomic operations

3. **Backend Go : Timing attack password reset**
   - **Localisation** : `internal/services/password_reset_service.go:70-125`
   - **Description** : Temps de traitement diffère selon existence email
   - **Impact** : Détection d'emails existants via timing
   - **Piste de correction** : Délai artificiel pour égaliser temps

4. **Chat Server : Race conditions dans DeliveredStatusManager/ReadReceiptManager**
   - **Localisation** : `src/delivered_status.rs`, `src/read_receipts.rs`
   - **Description** : Updates DB peuvent se chevaucher
   - **Impact** : Statuts incohérents
   - **Piste de correction** : Queue sérialisée ou transaction DB

5. **Chat Server : Pas de panic boundary dans WebSocket handler**
   - **Localisation** : `src/websocket/handler.rs:77-163`
   - **Description** : Panic peut faire crasher la task Tokio
   - **Impact** : Client malveillant peut faire crasher le serveur
   - **Piste de correction** : Wrapper dans `std::panic::catch_unwind`

6. **Chat Server : Tasks orphelins, pas de heartbeat timeout**
   - **Localisation** : `src/typing_indicator.rs`, `src/websocket/handler.rs`
   - **Description** : Tasks continuent après arrêt, pas de détection connexions zombies
   - **Impact** : Fuites ressources
   - **Piste de correction** : `CancellationToken`, heartbeat ping/pong

7. **Stream Server : Erreurs FFmpeg non propagées, DB pas toujours sync**
   - **Localisation** : `src/core/processing/processor.rs:154-156`, `src/core/processing/processor.rs:238-243`
   - **Description** : Erreurs loggées mais non fatales, segments non persistés en cas de crash
   - **Impact** : Jobs se terminent en "succès" alors que FFmpeg a échoué, incohérence DB
   - **Piste de correction** : Détecter erreurs fatales, persister immédiatement chaque segment

8. **Stream Server : Corruption d'état concurrent dans SegmentTracker**
   - **Localisation** : `src/core/processing/segment_tracker.rs:59-78`
   - **Description** : Ordre d'insertion peut varier
   - **Impact** : Segments persistés dans le mauvais ordre
   - **Piste de correction** : Canal sérialisé ou mutex global

9. **Stream Server : Regex non robustes, IO errors incomplètes**
   - **Localisation** : `src/core/processing/ffmpeg_monitor.rs:22-24`, `src/core/processing/ffmpeg_monitor.rs:90-94`
   - **Description** : Regex peut ne plus matcher, IO errors non propagées
   - **Impact** : Segments non détectés, monitoring s'arrête silencieusement
   - **Piste de correction** : Fallback détection segments, logger et propager erreurs

10. **Global : Pas de validation croisée IDs, pas de tests de charge**
    - **Localisation** : Communication inter-services
    - **Description** : Chat server accepte `conversation_id` sans vérification, pas de tests charge
    - **Impact** : Messages pour conversations inexistantes, problèmes performance non détectés
    - **Piste de correction** : Validation croisée via API, tests k6/locust

11. **Global : Fuites goroutine/task, pas de correlation-id**
    - **Localisation** : `internal/jobs/cleanup_sessions.go:33-45`, `veza-chat-server/src/optimized_persistence.rs:264-285`
    - **Description** : Goroutines/tasks sans mécanisme shutdown, pas de tracing distribué
    - **Impact** : Fuites ressources, debugging difficile
    - **Piste de correction** : `context.Context` avec cancellation, OpenTelemetry

#### P2 – Amélioration

1. **Backend Go : Pas de circuit breaker health check**
   - **Localisation** : Health checks
   - **Description** : Pas de circuit breaker pour éviter surcharger DB
   - **Impact** : Health checks continuent à tenter connexions si DB down
   - **Piste de correction** : Implémenter circuit breaker

2. **Backend Go : Queue in-memory sans persistance**
   - **Localisation** : `internal/workers/job_worker.go`
   - **Description** : Queue en mémoire, jobs perdus en cas de crash
   - **Impact** : Perte de jobs non traités
   - **Piste de correction** : Queue persistante (Redis, RabbitMQ)

3. **Global : Logs non structurés, pas de vérification d'intégrité**
   - **Localisation** : Quelques handlers
   - **Description** : Certains logs utilisent `fmt.Printf`, pas de job vérification intégrité
   - **Impact** : Logs non queryables, incohérences non détectées
   - **Piste de correction** : Standardiser sur `tracing`/`zap`, job vérification quotidien

### 4.3 Gestion des données & vie privée

#### Type de données manipulées
- Emails, identifiants utilisateurs
- Messages de chat
- Métadonnées audio (tracks, playlists)
- Logs d'accès

#### Points sensibles
- ⚠️ **Données personnelles dans logs** : Emails, user IDs peuvent apparaître dans logs (vérifier masquage)
- ✅ **Masquage secrets** : `MaskSecret` implémenté pour secrets
- ⚠️ **Export / stockage** : Pas de contrôle d'accès explicite sur exports de données

---

## 5. PERFORMANCE & ARCHITECTURE TECHNIQUE

### 5.1 Architecture globale

**Style général** : **Micro-services avec monorepo**

- **Backend Go** : Monolithe modulaire (handlers, services, models)
- **Chat Server** : Service indépendant (WebSocket)
- **Stream Server** : Service indépendant (streaming audio)
- **Frontend** : Application React monolithique

**Couplage entre modules** :
- **Fort** : Backend ↔ Chat (validation conversation_id), Backend ↔ Stream (jobs transcodage)
- **Faible** : Services Rust indépendants (communication via RabbitMQ optionnel)

**Zones problématiques** :
- Pas de transaction distribuée (incohérence possible)
- Validation croisée IDs manquante (chat accepte conversation_id sans vérification backend)

**Patterns utilisés** :
- **Backend Go** : MVC-ish (handlers → services → models)
- **Chat/Stream Rust** : Hexagonal-ish (repository pattern, services)

### 5.2 Points de performance

#### Requêtes DB non indexées / répétitives
- **Localisation** : À vérifier dans les migrations
- **Description** : Indexes présents dans migrations SQL, mais certains peuvent manquer
- **Impact** : Requêtes lentes sur grandes tables
- **Piste d'amélioration** : Audit indexes, ajouter indexes manquants

#### Boucles ou traitements synchrones
- **Localisation** : `veza-chat-server/src/typing_indicator.rs` (monitoring task)
- **Description** : Task de monitoring avec interval 500ms
- **Impact** : CPU usage si nombreuses conversations
- **Piste d'amélioration** : Optimiser algorithme, réduire fréquence si possible

#### I/O bloquantes
- **Localisation** : `veza-stream-server/src/core/processing/ffmpeg_monitor.rs`
- **Description** : Lecture stderr FFmpeg peut bloquer
- **Impact** : Latence traitement audio
- **Piste d'amélioration** : Async I/O, buffering

#### Absence de pagination / limitation
- **Localisation** : `veza-chat-server/src/main.rs:389` (get_messages avec limit 50 max)
- **Description** : Pagination présente mais limitée à 100
- **Impact** : OK pour chat, mais vérifier autres endpoints
- **Piste d'amélioration** : Vérifier pagination sur tous endpoints listes

#### Cache
- **Localisation** : Redis utilisé pour sessions, mais cache métier limité
- **Description** : Pas de cache systématique pour données fréquemment accédées
- **Impact** : Requêtes DB répétitives
- **Piste d'amélioration** : Cache Redis pour playlists, tracks populaires

---

## 6. GUIDE D'UTILISATION

### 6.1 Prérequis

#### Services nécessaires
- **PostgreSQL 15** : Base de données principale
- **Redis 7** : Cache et sessions
- **RabbitMQ 3.12** : Event bus (optionnel, mode dégradé si absent)

#### Variables d'environnement

**Backend Go** (`.env` dans `veza-backend-api/`) :
```bash
DATABASE_URL=postgresql://veza:password@localhost:5432/veza_db?sslmode=disable
REDIS_URL=redis://localhost:6379
JWT_SECRET=your-super-secret-jwt-key-min-32-chars
APP_PORT=8080
APP_ENV=development
```

**Chat Server** (`.env` dans `veza-chat-server/`) :
```bash
DATABASE_URL=postgresql://veza:password@localhost:5432/veza_db?sslmode=disable
REDIS_URL=redis://localhost:6379
JWT_SECRET=your-super-secret-jwt-key-min-32-chars
CHAT_SERVER_PORT=8081
```

**Stream Server** (`.env` dans `veza-stream-server/`) :
```bash
DATABASE_URL=postgresql://veza:password@localhost:5432/veza_db?sslmode=disable
REDIS_URL=redis://localhost:6379
JWT_SECRET=your-super-secret-jwt-key
SECRET_KEY=your-32-byte-secret-key
STREAM_PORT=8082
```

**Frontend** (`.env` dans `apps/web/`) :
```bash
VITE_API_URL=http://localhost:8080/api
VITE_WS_URL=ws://localhost:8081/ws
VITE_STREAM_URL=ws://localhost:8082/stream
```

#### Commandes d'installation

**Backend Go** :
```bash
cd veza-backend-api
go mod download
```

**Chat Server (Rust)** :
```bash
cd veza-chat-server
cargo build --release
```

**Stream Server (Rust)** :
```bash
cd veza-stream-server
cargo build --release
```

**Frontend** :
```bash
cd apps/web
npm install
```

### 6.2 Lancement des composants

#### Option 1 : Docker Compose (recommandé)
```bash
docker-compose up -d
```
- Démarre tous les services (PostgreSQL, Redis, RabbitMQ, Backend, Chat, Stream, Frontend, HAProxy)
- Health checks automatiques
- Ports : 80 (HAProxy), 8080 (Backend), 8081 (Chat), 8082 (Stream), 8085 (Frontend)

#### Option 2 : Manuel (développement)

**1. Démarrer infrastructure** :
```bash
# Via Makefile
make infra-up

# Ou manuellement
docker-compose up -d postgres redis rabbitmq
```

**2. Appliquer migrations** :
```bash
# Via Makefile
make migrate-all

# Ou manuellement
cd veza-backend-api
go run ./cmd/migrate_tool
cd ../veza-chat-server
sqlx migrate run
cd ../veza-stream-server
sqlx migrate run
```

**3. Démarrer services** :
```bash
# Backend
cd veza-backend-api
go run ./cmd/api

# Chat Server (terminal 2)
cd veza-chat-server
cargo run --release

# Stream Server (terminal 3)
cd veza-stream-server
cargo run --release

# Frontend (terminal 4)
cd apps/web
npm run dev
```

#### Problèmes potentiels et workarounds

1. **PostgreSQL non accessible** :
   - Vérifier `DATABASE_URL`
   - Vérifier que PostgreSQL est démarré : `pg_isready -U veza -d veza_db`

2. **Redis non accessible** :
   - Vérifier `REDIS_URL`
   - Tester : `redis-cli ping`

3. **Frontend erreurs TypeScript** :
   - ⚠️ **Problème connu** : Erreurs TypeScript bloquantes
   - Workaround : `npm run dev` peut fonctionner malgré erreurs (Vite ignore certaines erreurs)

4. **Stream Server compilation** :
   - ⚠️ Nécessite PostgreSQL accessible pour `sqlx::query!` macros
   - Solution : Générer `sqlx-data.json` avec `cargo sqlx prepare`

### 6.3 Tests

#### Backend Go
```bash
cd veza-backend-api
go test ./... -v
```
**Résultat attendu** : ✅ Tests passent (92% coverage)

#### Chat Server
```bash
cd veza-chat-server
cargo test
```
**Résultat attendu** : ⚠️ Certains tests `#[ignore]` (nécessitent DB)

#### Stream Server
```bash
cd veza-stream-server
cargo test
```
**Résultat attendu** : ⚠️ Peu de tests présents

#### Frontend
```bash
cd apps/web
npm test              # Unitaires
npm run test:e2e      # E2E
```
**Résultat attendu** : ❌ Erreurs TypeScript, tests échouent

#### Recommandation minimale
Avant un commit / release :
1. ✅ Backend Go : `go test ./...`
2. ⚠️ Chat Server : `cargo test` (vérifier tests non ignorés)
3. ⚠️ Stream Server : `cargo test` (vérifier tests présents)
4. ❌ Frontend : Corriger erreurs TypeScript avant commit

---

## 7. AXES D'AMÉLIORATION

### 7.1 Plan de remédiation priorisé

#### P0 – Urgent / bloquant

1. **Corriger erreurs TypeScript frontend**
   - **Résumé** : Résoudre 50+ erreurs TypeScript bloquantes
   - **Pourquoi** : Frontend non utilisable
   - **Où** : `apps/web/src/`
   - **Complexité** : Moyenne (corrections types, imports, paths aliases)
   - **Estimation** : 4-6h

2. **Implémenter transactions dans opérations critiques backend**
   - **Résumé** : Wrapper opérations multi-étapes dans transactions
   - **Pourquoi** : Éviter incohérences DB
   - **Où** : `veza-backend-api/internal/services/`, `internal/core/`
   - **Complexité** : Moyenne (identifier opérations, wrapper)
   - **Estimation** : 6-8h

3. **Corriger race conditions chat server**
   - **Résumé** : Remplacer RwLock par Mutex dans TypingIndicatorManager, sérialiser updates dans DeliveredStatusManager/ReadReceiptManager
   - **Pourquoi** : Éviter incohérences données
   - **Où** : `veza-chat-server/src/typing_indicator.rs`, `src/delivered_status.rs`, `src/read_receipts.rs`
   - **Complexité** : Faible-Moyenne (changements ciblés)
   - **Estimation** : 4-6h

4. **Remplacer unwrap() par gestion d'erreur explicite**
   - **Résumé** : Remplacer tous les `unwrap()`/`expect()` par `?` ou gestion explicite
   - **Pourquoi** : Éviter panics
   - **Où** : 31 fichiers identifiés dans chat server
   - **Complexité** : Faible (mécanique)
   - **Estimation** : 4-6h

5. **Corriger gestion tasks stream server**
   - **Résumé** : Utiliser CancellationToken au lieu de `abort()`, attendre fin tasks
   - **Pourquoi** : Éviter transactions DB non commitées
   - **Où** : `veza-stream-server/src/core/processing/processor.rs`
   - **Complexité** : Moyenne (refactoring shutdown)
   - **Estimation** : 4-6h

6. **Implémenter cleanup jobs données orphelines**
   - **Résumé** : Jobs périodiques pour supprimer données incohérentes
   - **Pourquoi** : Maintenir cohérence DB
   - **Où** : Nouveaux workers dans chaque service
   - **Complexité** : Moyenne (identifier données orphelines, implémenter cleanup)
   - **Estimation** : 6-8h

#### P1 – Important / à planifier à court terme

1. **Refactoriser handlers backend pour utiliser BindAndValidateJSON**
   - **Résumé** : Migrer handlers dans `internal/api/` vers `BindAndValidateJSON`
   - **Pourquoi** : Uniformiser gestion erreurs JSON
   - **Où** : `veza-backend-api/internal/api/`
   - **Complexité** : Faible (mécanique)
   - **Estimation** : 2-4h

2. **Ajouter panic boundary WebSocket handler**
   - **Résumé** : Wrapper `handle_incoming_message` dans `catch_unwind`
   - **Pourquoi** : Éviter crash serveur si panic
   - **Où** : `veza-chat-server/src/websocket/handler.rs`
   - **Complexité** : Faible
   - **Estimation** : 1-2h

3. **Implémenter heartbeat timeout WebSocket**
   - **Résumé** : Ping/pong avec timeout pour détecter connexions zombies
   - **Pourquoi** : Libérer ressources
   - **Où** : `veza-chat-server/src/websocket/handler.rs`
   - **Complexité** : Moyenne
   - **Estimation** : 3-4h

4. **Corriger gestion erreurs FFmpeg stream server**
   - **Résumé** : Détecter erreurs fatales, arrêter traitement immédiatement
   - **Pourquoi** : Éviter jobs "succès" alors que FFmpeg a échoué
   - **Où** : `veza-stream-server/src/core/processing/processor.rs`, `src/core/processing/ffmpeg_monitor.rs`
   - **Complexité** : Moyenne
   - **Estimation** : 4-6h

5. **Implémenter validation croisée IDs inter-services**
   - **Résumé** : Chat server vérifie conversation_id via API backend
   - **Pourquoi** : Éviter messages pour conversations inexistantes
   - **Où** : `veza-chat-server/src/websocket/handler.rs`
   - **Complexité** : Moyenne (appel API, cache)
   - **Estimation** : 4-6h

6. **Ajouter correlation-id / tracing distribué**
   - **Résumé** : Implémenter OpenTelemetry ou système de tracing
   - **Pourquoi** : Faciliter debugging en production
   - **Où** : Tous les services
   - **Complexité** : Élevée (infrastructure)
   - **Estimation** : 8-12h

7. **Nettoyer code mort stream server**
   - **Résumé** : Supprimer champs/méthodes non utilisés
   - **Pourquoi** : Réduire complexité, améliorer maintenabilité
   - **Où** : `veza-stream-server/src/`
   - **Complexité** : Faible (mécanique)
   - **Estimation** : 2-4h

#### P2 – Amélioration continue

1. **Implémenter circuit breaker health checks**
   - **Résumé** : Circuit breaker pour éviter surcharger DB
   - **Pourquoi** : Améliorer résilience
   - **Où** : `veza-backend-api/internal/handlers/health.go`
   - **Complexité** : Moyenne
   - **Estimation** : 4-6h

2. **Migrer queue in-memory vers queue persistante**
   - **Résumé** : Utiliser Redis ou RabbitMQ pour jobs
   - **Pourquoi** : Éviter perte jobs en cas de crash
   - **Où** : `veza-backend-api/internal/workers/job_worker.go`
   - **Complexité** : Élevée (refactoring)
   - **Estimation** : 8-12h

3. **Standardiser logs (tracing/zap)**
   - **Résumé** : Remplacer `fmt.Printf` par `tracing`/`zap`
   - **Pourquoi** : Logs queryables
   - **Où** : Quelques handlers
   - **Complexité** : Faible
   - **Estimation** : 2-4h

4. **Implémenter job vérification intégrité DB**
   - **Résumé** : Job quotidien vérifiant cohérence fichiers/DB
   - **Pourquoi** : Détecter incohérences
   - **Où** : Nouveau worker
   - **Complexité** : Moyenne
   - **Estimation** : 4-6h

5. **Ajouter tests de charge**
   - **Résumé** : Tests k6 ou locust pour valider performance
   - **Pourquoi** : Détecter problèmes performance
   - **Où** : Nouveau dossier `tests/load/`
   - **Complexité** : Moyenne
   - **Estimation** : 6-8h

### 7.2 Nouveaux features (optionnels, mais intelligents)

1. **Health check dashboard**
   - **Problème actuel** : Health checks dispersés (`/health`, `/status`)
   - **Impact** : Centraliser monitoring santé services
   - **Implémentation** : Endpoint `/health/all` agrégeant health checks de tous services
   - **Complexité** : Faible-Moyenne

2. **Rate limiting global**
   - **Problème actuel** : Pas de rate limiting systématique
   - **Impact** : Protection contre abus, DDoS
   - **Implémentation** : Middleware rate limiting (Redis-based) dans backend, chat, stream
   - **Complexité** : Moyenne

3. **Metrics dashboard (Prometheus + Grafana)**
   - **Problème actuel** : Métriques exposées mais pas de dashboard
   - **Impact** : Visualisation métriques, alerting
   - **Implémentation** : Grafana avec datasource Prometheus
   - **Complexité** : Faible (infrastructure)

4. **API documentation interactive (Swagger/OpenAPI)**
   - **Problème actuel** : Documentation API limitée
   - **Impact** : Faciliter intégration, tests
   - **Implémentation** : Swagger déjà configuré dans backend Go, compléter annotations
   - **Complexité** : Faible

5. **Webhook notifications**
   - **Problème actuel** : Pas de notifications externes
   - **Impact** : Intégrations tierces
   - **Implémentation** : Système webhooks pour événements (nouveau track, nouveau message, etc.)
   - **Complexité** : Élevée

---

## 8. SYNTHÈSE FINALE

### Dans quel état réel est le projet aujourd'hui ?

**"PoC prometteur mais fragile"**

Le projet Veza présente une architecture solide avec des services bien séparés (Backend Go, Chat Rust, Stream Rust, Frontend React). Le backend Go est fonctionnel et relativement stable (92% coverage), mais les autres composants présentent des fragilités importantes :
- **Chat Server** : Compile mais race conditions et panics possibles
- **Stream Server** : Code partiellement implémenté, gestion d'erreurs incomplète
- **Frontend** : Erreurs TypeScript bloquantes, non utilisable sans corrections

Le projet est **utilisable en développement avec précautions**, mais nécessite des corrections critiques avant un déploiement en production.

### Qu'est-ce qui fonctionne le mieux ?

1. **Backend Go** : Architecture claire, tests présents, migrations structurées, authentification JWT robuste, RBAC implémenté
2. **Docker Compose** : Configuration complète avec health checks, facile à démarrer
3. **Migrations DB** : Système cohérent, UUID-first, bien documenté
4. **Documentation** : Présente et structurée (docs/, veza-docs/)

### Qu'est-ce qui est le plus dangereux / fragile ?

1. **Frontend TypeScript** : 50+ erreurs bloquantes, non utilisable
2. **Race conditions chat server** : TypingIndicatorManager, DeliveredStatusManager, ReadReceiptManager
3. **Panics Rust** : 31 fichiers avec `unwrap()`/`expect()` dans chat server
4. **Incohérences DB** : Pas de transactions distribuées, données orphelines possibles
5. **Gestion d'erreurs stream server** : Erreurs FFmpeg non propagées, tasks non cancellées proprement

### Quelles 3 actions prioritaires maximisent le rapport effort / bénéfice ?

1. **Corriger erreurs TypeScript frontend** (P0, 4-6h)
   - **Bénéfice** : Frontend utilisable
   - **Effort** : Moyen (corrections mécaniques)
   - **Impact** : Immédiat (frontend fonctionnel)

2. **Corriger race conditions chat server** (P0, 4-6h)
   - **Bénéfice** : Stabilité chat, cohérence données
   - **Effort** : Faible-Moyen (changements ciblés)
   - **Impact** : Critique (évite bugs production)

3. **Remplacer unwrap() par gestion d'erreur explicite** (P0, 4-6h)
   - **Bénéfice** : Évite panics, stabilité serveurs Rust
   - **Effort** : Faible (mécanique)
   - **Impact** : Critique (évite crashes)

**Total estimation P0 critiques** : 12-18h de travail ciblé pour rendre le projet significativement plus stable.

---

**Fin du rapport d'audit**