1147 lines
43 KiB
Markdown
1147 lines
43 KiB
Markdown
# 🔍 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**
|