veza/AUDIT_EXHAUSTIF_2025_01_27.md

🔍 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
2. Cartographie détaillée du code
3. État fonctionnel : ce qui marche / est partiel / est cassé
4. Sécurité : failles et surfaces d'attaque
5. Performance & architecture technique
6. Guide d'utilisation du projet (mode actuel réel)
7. Axes d'amélioration (sécurité, qualité, features)
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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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/) :

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/) :

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/) :

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/) :

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 :

cd veza-backend-api
go mod download

Chat Server (Rust) :

cd veza-chat-server
cargo build --release

Stream Server (Rust) :

cd veza-stream-server
cargo build --release

Frontend :

cd apps/web
npm install

6.2 Lancement des composants

Option 1 : Docker Compose (recommandé)

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 :

# Via Makefile
make infra-up

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

2. Appliquer migrations :

# 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 :

# 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

cd veza-backend-api
go test ./... -v

Résultat attendu : ✅ Tests passent (92% coverage)

Chat Server

cd veza-chat-server
cargo test

Résultat attendu : ⚠️ Certains tests #[ignore] (nécessitent DB)

Stream Server

cd veza-stream-server
cargo test

Résultat attendu : ⚠️ Peu de tests présents

Frontend

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