veza/veza-backend-api/docs/archive/AUDIT_MODULE_VEZA_BACKEND_API.md

# AUDIT TECHNIQUE EXHAUSTIF - VEZA BACKEND API

**Date**: 2025-01-27  
**Auditeur**: AI Assistant (Auto)  
**Module**: veza-backend-api (Backend Go)  
**Version**: 1.2.0  
**Méthodologie**: Audit statique exhaustif + Analyse code + Tests + Configuration  
**Priorité**: Production-ready audit

---

## 📋 TABLE DES MATIÈRES

1. [PHASE A - Cartographie du Module](#phase-a---cartographie-du-module)
2. [PHASE B - Santé Technique](#phase-b---santé-technique)
3. [PHASE C - Sécurité](#phase-c---sécurité)
4. [PHASE D - Robustesse & Observabilité](#phase-d---robustesse--observabilité)
5. [PHASE E - Performance & Scalabilité](#phase-e---performance--scalabilité)
6. [PHASE F - Liste Exhaustive des Problèmes Priorisés](#phase-f---liste-exhaustive-des-problèmes-priorisés)
7. [PHASE G - Plan d'Exécution](#phase-g---plan-dexécution)

---

# PHASE A - CARTOGRAPHIE DU MODULE

## A.1 But du Module

**Veza Backend API** est le serveur API REST principal de la plateforme Veza, une plateforme audio collaborative. Il fournit :

- **Authentification & Autorisation** : JWT (HS256), sessions DB, RBAC, OAuth partiel, 2FA (TOTP)
- **Gestion Utilisateurs** : Profils, permissions, rôles, token versioning pour révocation
- **Gestion Contenu** : Tracks (audio), playlists, marketplace (products, orders)
- **Chat & Collaboration** : Rooms, messages, conversations (intégration Chat Server Rust)
- **Streaming** : Intégration avec Stream Server (WebRTC) pour streaming audio
- **Audit & Monitoring** : Logs structurés (zap), métriques Prometheus, Sentry error tracking
- **Jobs & Workers** : Job queue (RabbitMQ), workers (email, thumbnails, analytics, webhooks)

**Rôle dans l'écosystème Veza** :
- **Backend Go** : API REST principale (port 8080) - **MODULE COURANT**
- **Chat Server Rust** : WebSocket chat (port 8081) - consommateur de tokens JWT via `/api/v1/chat/token`
- **Stream Server Rust** : Streaming audio WebRTC (port 8082) - consommateur de tokens JWT
- **Frontend React** : Consommateur de l'API REST

## A.2 Entrées / Sorties

### APIs Exposées

**Base URL**: `http://localhost:8080` (configurable via `APP_PORT`, défaut: 8080)

**Routes Principales** (`/api/v1/`):

```
/api/v1/
├── /auth/*
│   ├── POST   /register              # Inscription
│   ├── POST   /login                  # Connexion (rate limited)
│   ├── POST   /refresh                # Renouvellement token
│   ├── POST   /verify-email           # Vérification email
│   ├── POST   /resend-verification   # Renvoyer vérification
│   ├── GET    /check-username         # Vérifier disponibilité username
│   ├── POST   /password/reset-request # Demande reset password
│   ├── POST   /password/reset         # Reset password
│   ├── POST   /logout                 # Déconnexion (protégé)
│   └── GET    /me                     # Profil utilisateur (protégé)
├── /users/*
│   ├── GET    /:id                    # Profil utilisateur
│   ├── GET    /by-username/:username # Profil par username
│   ├── PUT    /:id                    # Mise à jour profil (protégé)
│   └── GET    /:id/completion         # Complétion profil (protégé)
├── /tracks/*
│   ├── GET    /                       # Liste tracks
│   ├── GET    /:id                    # Détails track
│   ├── GET    /:id/stats              # Statistiques track
│   ├── GET    /:id/history            # Historique track
│   ├── GET    /:id/download           # Téléchargement track
│   ├── GET    /shared/:token          # Track partagé (public)
│   ├── POST   /                       # Upload track (protégé, creator role)
│   ├── PUT    /:id                    # Mise à jour track (protégé)
│   ├── DELETE /:id                    # Suppression track (protégé)
│   ├── POST   /:id/like               # Like track (protégé)
│   ├── DELETE /:id/like               # Unlike track (protégé)
│   ├── GET    /:id/likes              # Liste likes (protégé)
│   ├── POST   /:id/share              # Partager track (protégé)
│   └── DELETE /share/:id              # Révoquer partage (protégé)
├── /playlists/*                       # Gestion playlists (protégé)
├── /chat/*
│   └── POST   /token                  # Génération token WS (protégé)
├── /marketplace/*
│   ├── GET    /products               # Liste produits
│   ├── POST   /products               # Créer produit (protégé, creator role)
│   ├── POST   /orders                 # Créer commande (protégé)
│   └── GET    /download/:product_id   # URL téléchargement (protégé)
├── /sessions/*                        # Gestion sessions (protégé)
├── /uploads/*                         # Upload fichiers (protégé, rate limited)
├── /audit/*                           # Audit logs (protégé)
├── /conversations/*                   # Chat rooms (protégé)
├── /webhooks/*                        # Webhooks (protégé)
├── /admin/*                           # Routes admin (protégé, admin role)
├── /health                            # Health check simple
├── /healthz                           # Liveness probe
├── /readyz                            # Readiness probe
├── /status                            # Status complet (DB, Redis, Chat, Stream)
└── /metrics                           # Prometheus metrics
```

**Formats**:
- **Request/Response**: JSON (`application/json`)
- **Auth**: JWT Bearer tokens (`Authorization: Bearer <token>`)
- **Content-Type**: `application/json`
- **File Upload**: `multipart/form-data` (tracks, thumbnails)
- **WebSocket**: Chat Server (Rust) - tokens JWT fournis par `/api/v1/chat/token`

### Schémas JSON Principaux

**User**:
```json
{
  "id": "uuid",
  "username": "string",
  "email": "string",
  "role": "user|admin|creator|premium|artist|producer|label",
  "token_version": 1,
  "created_at": "2025-01-27T10:00:00Z",
  "updated_at": "2025-01-27T10:00:00Z"
}
```

**Track**:
```json
{
  "id": "uuid",
  "user_id": "uuid",
  "title": "string",
  "artist": "string",
  "duration": 180.5,
  "file_path": "string",
  "status": "processing|ready|error"
}
```

**Error Response** (standardisé):
```json
{
  "success": false,
  "data": null,
  "error": {
    "code": 2001,
    "message": "Validation failed",
    "details": [
      {"field": "email", "message": "Invalid email format"}
    ],
    "request_id": "uuid",
    "timestamp": "2025-01-27T10:00:00Z"
  }
}
```

## A.3 Dépendances Internes

**Structure du Module**:
```
veza-backend-api/
├── cmd/
│   ├── api/main.go                  # Point d'entrée principal (legacy?)
│   └── modern-server/main.go        # Point d'entrée moderne (ACTIF)
├── internal/
│   ├── api/                         # Routes et handlers HTTP
│   │   ├── router.go                # Configuration routes (APIRouter)
│   │   └── [user|track|chat|...]/  # Routes par domaine
│   ├── config/                      # Configuration centralisée
│   │   ├── config.go                # Config struct + NewConfig()
│   │   ├── env_loader.go            # Chargement .env
│   │   └── validator.go             # Validation config
│   ├── database/                    # Gestion DB
│   │   ├── database.go              # Connexion + migrations
│   │   └── migrations.go            # Migrations GORM (indexes)
│   ├── handlers/                    # Handlers HTTP (legacy + modern)
│   ├── middleware/                  # Middlewares Gin
│   │   ├── auth.go                  # AuthMiddleware (JWT + sessions)
│   │   ├── rbac_middleware.go       # RBAC permissions
│   │   ├── rate_limiter.go           # Rate limiting (Redis)
│   │   ├── error_handler.go         # Error handling standardisé
│   │   └── timeout.go               # Timeout middleware
│   ├── services/                    # Business logic
│   │   ├── jwt_service.go           # JWT generation/validation
│   │   ├── session_service.go       # Sessions DB
│   │   ├── user_service.go          # User management
│   │   └── [auth|track|playlist|...]/ # Services par domaine
│   ├── models/                      # Modèles GORM
│   ├── repositories/                # Data access layer
│   ├── workers/                     # Background workers
│   │   ├── job_worker.go            # Job queue worker
│   │   ├── email_job.go             # Email worker
│   │   └── [analytics|thumbnail|webhook]/ # Autres workers
│   ├── errors/                      # Error handling
│   ├── metrics/                     # Prometheus metrics
│   └── logging/                      # Logging (zap)
├── migrations/                      # Migrations SQL (100% SQL strategy)
│   ├── 001_extensions_and_types.sql
│   ├── 010_auth_and_users.sql
│   └── [020-900]_*.sql
└── tests/                           # Tests d'intégration
```

**Packages Partagés**:
- `internal/common/` : Types communs, validation
- `internal/types/` : Types métier (auth, user, stats)
- `internal/interfaces/` : Interfaces pour découplage

## A.4 Dépendances Externes

**Base de Données**:
- **PostgreSQL** (principal) : Via `github.com/lib/pq` + GORM (`gorm.io/driver/postgres`)
- **SQLite** (tests uniquement) : Via `gorm.io/driver/sqlite`
- **Stratégie Migrations** : 100% SQL (fichiers `.sql` dans `migrations/`), GORM uniquement pour indexes additionnels

**Cache & Sessions**:
- **Redis** (`github.com/redis/go-redis/v9`) : Cache, rate limiting, sessions (optionnel via `REDIS_ENABLE`)

**Message Queue**:
- **RabbitMQ** (`github.com/rabbitmq/amqp091-go`) : Job queue, event bus (optionnel via `RABBITMQ_ENABLE`)

**HTTP Framework**:
- **Gin** (`github.com/gin-gonic/gin`) : Router HTTP

**Auth & Security**:
- **JWT** (`github.com/golang-jwt/jwt/v5`) : Tokens JWT (HS256)
- **OTP** (`github.com/pquerna/otp`) : 2FA TOTP
- **Crypto** (`golang.org/x/crypto`) : Hashing passwords (bcrypt)

**Monitoring & Observability**:
- **Prometheus** (`github.com/prometheus/client_golang`) : Métriques
- **Sentry** (`github.com/getsentry/sentry-go`) : Error tracking
- **Zap** (`go.uber.org/zap`) : Logging structuré

**Validation**:
- **Validator** (`github.com/go-playground/validator/v10`) : Validation struct tags

**Autres**:
- **UUID** (`github.com/google/uuid`) : Génération UUID
- **OAuth2** (`golang.org/x/oauth2`) : OAuth (partiel)
- **Rate Limiting** (`golang.org/x/time`) : Rate limiting

## A.5 Exécution

### Commandes Build/Run/Dev

**Build**:
```bash
make build                    # Compile (bin/veza-backend-api)
make build-linux              # Compile pour Linux
```

**Run**:
```bash
make run                      # Build + run
make dev                      # Run en mode dev (go run)
make run-lab                  # Run en mode lab (dégradé sans Redis/RabbitMQ)
```

**Tests**:
```bash
make test                     # Tests unitaires
make test-coverage            # Tests avec couverture
make test-race                # Tests avec détection race conditions
make test-integration         # Tests d'intégration (nécessite Redis)
```

**Qualité**:
```bash
make lint                     # golangci-lint
make vet                      # go vet
make format                   # go fmt + goimports
make security                 # gosec + govulncheck
```

**Migrations**:
```bash
make migrate                  # Exécute migrations
make migrate-lab              # Migrations en environnement lab
```

### Configuration

**Variables d'Environnement Requises**:
```bash
# REQUIS
JWT_SECRET=<32+ chars>        # Secret JWT (minimum 32 caractères)
DATABASE_URL=postgres://...   # URL PostgreSQL

# OPTIONNEL (avec defaults)
APP_PORT=8080                 # Port serveur HTTP
APP_ENV=development|test|staging|production
REDIS_URL=redis://localhost:6379
REDIS_ENABLE=true
RABBITMQ_URL=amqp://guest:guest@localhost:5672/
RABBITMQ_ENABLE=true
CORS_ALLOWED_ORIGINS=http://localhost:3000,http://localhost:5173
LOG_LEVEL=INFO|DEBUG|WARN|ERROR
HANDLER_TIMEOUT=30s
RATE_LIMIT_LIMIT=100
RATE_LIMIT_WINDOW=60
AUTH_RATE_LIMIT_LOGIN_ATTEMPTS=5
AUTH_RATE_LIMIT_LOGIN_WINDOW=1
```

**Fichiers de Configuration**:
- `.env` : Variables d'environnement (chargé automatiquement)
- `.env.{env}` : Variables par environnement (ex: `.env.production`)
- Priorité : Variables système > `.env.{env}` > `.env`

**Secrets Management**:
- Secrets dans variables d'environnement (pas de fichiers secrets)
- Masquage dans logs via `SecretsProvider` (`internal/config/secrets.go`)

### Docker

**Build**:
```bash
make docker-build             # Construit image Docker
```

**Dockerfile**:
- Multi-stage build (Go 1.23-alpine → alpine:latest)
- Non-root user (`app:app`)
- Health check (`/health`)
- Expose port 8080

**Run**:
```bash
make docker-run               # Build + run container
```

## A.6 Points d'Intégration

### Contrats d'API avec Autres Services

**Chat Server (Rust)**:
- **Endpoint Backend → Chat** : `/api/v1/chat/token` génère JWT pour WebSocket
- **Format Token** : JWT avec `sub` (user_id UUID), `iss` (JWT_ISSUER), `aud` (JWT_AUDIENCE)
- **Secret Partagé** : `CHAT_JWT_SECRET` (fallback: `JWT_SECRET`)
- **URL Chat Server** : `CHAT_SERVER_URL` (défaut: `http://localhost:8081`)

**Stream Server (Rust)**:
- **Endpoint Backend → Stream** : Callback `/api/v1/internal/tracks/:id/stream-ready`
- **Format Token** : JWT (même format que Chat)
- **URL Stream Server** : `STREAM_SERVER_URL` (défaut: `http://localhost:8082`)

**Frontend React**:
- **Base URL** : `http://localhost:8080/api/v1`
- **Auth** : JWT Bearer tokens
- **CORS** : Configuré via `CORS_ALLOWED_ORIGINS` (wildcard `*` interdit en production)

### Auth (JWT/SSO)

**JWT**:
- **Algorithme** : HS256 (strictement vérifié, `none`/`RS256` rejetés)
- **Claims Requis** : `sub` (user_id UUID), `exp`, `iat`, `iss`, `aud`, `token_version`
- **TTL** : Access token 15min, Refresh token 30 jours
- **Révocation** : Token versioning (incrément `user.token_version` → tous tokens invalides)

**Sessions**:
- **Stockage** : DB (`user_sessions` table)
- **Validation** : Obligatoire dans `AuthMiddleware.authenticate()`
- **Expiration** : Configurable (défaut: 30 jours)

**RBAC**:
- **Rôles** : `user`, `admin`, `creator`, `premium`, `artist`, `producer`, `label`
- **Permissions** : Tables `permissions`, `role_permissions`, `user_roles`
- **Middleware** : `RequireAdmin()`, `RequirePermission()`, `RequireContentCreatorRole()`

**OAuth**:
- **Partiel** : Implémentation présente mais incomplète (TODO dans code)

### Schéma DB / UUID / Conventions

**IDs**:
- **Format** : UUID v4 (`github.com/google/uuid`)
- **Migration** : Migration complète de `int64` → `uuid.UUID` effectuée
- **Tables** : Toutes tables utilisent `id UUID PRIMARY KEY DEFAULT gen_random_uuid()`

**Soft Delete**:
- **Colonne** : `deleted_at TIMESTAMPTZ` (nullable)
- **GORM** : `gorm.DeletedAt` pour soft delete automatique
- **Tables** : `users`, `tracks`, `playlists`, `messages`, etc.

**Timestamps**:
- **Colonnes** : `created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()`, `updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()`
- **GORM** : `gorm.Model` (inclut `CreatedAt`, `UpdatedAt`, `DeletedAt`)

**Foreign Keys**:
- **Format** : `user_id UUID REFERENCES users(id) ON DELETE CASCADE`
- **Indexes** : Index automatiques sur foreign keys

---

# PHASE B - SANTÉ TECHNIQUE

## B.1 Build Status

**Compilation**:
- ✅ **Status** : Code compile sans erreurs (`go build ./...` réussit)
- ✅ **Go Version** : 1.23.8 (requis dans `go.mod`)
- ⚠️ **Warnings** : Quelques warnings de dépendances obsolètes

**Fichiers**:
- **Total Go Files** : 663 fichiers
- **Test Files** : 221 fichiers (`*_test.go`)
- **Ratio Tests** : ~33% (221/663)

## B.2 Tests

**Exécution**:
```bash
make test                     # Tests unitaires
```

**Résultats**:
- ⚠️ **3 Tests Échouent** :
  - `TestLoad_MissingRequiredVariable_DBPassword` : Devrait panic mais ne panic pas
  - `TestLoad_MissingRequiredVariable_JWTSecret` : Devrait panic mais ne panic pas
  - `TestNewConfig_RequiresJWTSecret` : Devrait panic mais ne panic pas
- ✅ **Autres Tests** : Passent (cached ou ok)

**Couverture**:
- ⚠️ **Non Mesurée Automatiquement** : Pas de CI/CD avec coverage report
- **Commande** : `make test-coverage` génère `coverage.html`

**Types de Tests**:
- ✅ **Unitaires** : Présents dans chaque package (`*_test.go`)
- ✅ **Intégration** : `tests/integration/` (nécessite Redis)
- ✅ **Transactions** : `tests/transactions/` (tests transactionnels)

**Fiabilité**:
- ⚠️ **Race Conditions** : Tests avec `-race` non exécutés automatiquement
- ⚠️ **Flaky Tests** : Non identifiés (nécessite plusieurs runs)

## B.3 Linting & Qualité Code

**Linters**:
- ✅ **golangci-lint** : Configuré dans Makefile
- ⚠️ **Non Exécuté Automatiquement** : Pas de CI/CD
- **Commande** : `make lint`

**Go Vet**:
- ✅ **Configuré** : `make vet`
- ⚠️ **Non Exécuté Automatiquement** : Pas de CI/CD

**Format**:
- ✅ **go fmt** : Configuré
- ✅ **goimports** : Configuré dans Makefile
- **Commande** : `make format`

**TODO/FIXME**:
- ⚠️ **90 TODOs/FIXMEs** trouvés dans le code
- **Fichiers Principaux** :
  - `internal/config/config.go` : 6 TODOs
  - `internal/services/job_service.go` : 3 TODOs
  - `internal/database/database.go` : 4 TODOs
  - `internal/api/api_manager.go` : 4 TODOs

## B.4 Gestion des Erreurs

**Patterns**:
- ✅ **AppError** : Erreurs standardisées (`internal/errors/errors.go`)
- ✅ **Error Codes** : Codes numériques (1000-9999) par catégorie
- ✅ **Error Wrapping** : `fmt.Errorf("...: %w", err)` pour chaînage
- ✅ **HTTP Status Mapping** : `mapErrorCodeToHTTPStatus()` dans `internal/handlers/error_response.go`

**Problèmes**:
- ⚠️ **P1-ERRORS** : Panics non capturés dans certains handlers (recovery middleware présent mais peut manquer)
- ⚠️ **P2-ERRORS** : Erreurs non loggées dans certains services (audit nécessaire)

**Recovery**:
- ✅ **Recovery Middleware** : `middleware.Recovery()` présent
- ✅ **Sentry Recovery** : `middleware.SentryRecover()` pour tracking erreurs

## B.5 Conventions & Structure

**Naming**:
- ✅ **Cohérent** : Go conventions respectées (PascalCase exports, camelCase privés)
- ✅ **Packages** : Packages par domaine (`auth`, `track`, `playlist`, etc.)

**Structure Dossiers**:
- ✅ **Organisée** : Séparation claire (`handlers/`, `services/`, `repositories/`, `models/`)
- ⚠️ **Duplication** : Certains handlers dans `internal/handlers/` ET `internal/api/handlers/` (legacy?)

**Séparation Couches**:
- ✅ **Respectée** : Handlers → Services → Repositories → DB
- ⚠️ **Couplage** : Certains services appellent directement GORM (bypass repositories)

---

# PHASE C - SÉCURITÉ

## C.1 Secrets & Configuration

**Secrets Hardcodés**:
- ✅ **Aucun Trouvé** : Grep `password|secret|key|token` ne révèle pas de secrets hardcodés
- ✅ **Variables d'Environnement** : Tous secrets via env vars

**Fichiers .env**:
- ⚠️ **P0-SECURITY** : `.env` peut être committé (vérifier `.gitignore`)
- ✅ **Masquage Logs** : `SecretsProvider` masque secrets dans logs (`internal/config/secrets.go`)

**Configuration**:
- ✅ **Validation** : `Config.Validate()` + `ValidateForEnvironment()` (stricte en production)
- ⚠️ **P0-SECURITY** : `getEnvRequired()` retourne erreur (pas panic) → tests échouent car attendent panic
  - **Fichier** : `internal/config/config.go:524-529`
  - **Impact** : Tests incorrects (devraient vérifier erreur, pas panic)

## C.2 Authentification & Autorisation

### JWT Validation

**Implémentation**:
- ✅ **Algorithme** : HS256 (HMAC) - sécurisé
- ✅ **Validation Signature** : `jwt.ParseWithClaims()` avec secret
- ✅ **Validation Expiration** : `exp` claim vérifié
- ✅ **Validation Session DB** : `SessionService.ValidateSession()` appelé
- ✅ **Validation Claims** : `sub` (user_id UUID), `exp`, `iat`, `iss`, `aud` vérifiés
- ✅ **Validation Algorithme** : `alg` header vérifié (HS256 uniquement) - **FIXÉ** (`internal/services/jwt_service.go:121-127`)
- ✅ **Token Version** : Vérifié dans `AuthMiddleware.authenticate()` (`internal/middleware/auth.go:119-129`)

**Problèmes**:
- ✅ **RÉSOLU** : Validation `aud`/`iss` JWT stricte (`jwt.WithIssuer()`, `jwt.WithAudience()`)
- ✅ **RÉSOLU** : Token version vérifiée dans `authenticate()`

### RBAC (Role-Based Access Control)

**Implémentation**:
- ✅ **FONCTIONNEL** : `RequireAdmin()` utilise `PermissionService.HasRole(..., "admin")`
- ✅ **FONCTIONNEL** : `RequirePermission()` utilise `PermissionService.HasPermission()`
- ✅ **FONCTIONNEL** : `RequireContentCreatorRole()` vérifie rôles creator/premium/admin/artist/producer/label
- ✅ **Tables DB** : `permissions`, `role_permissions`, `user_roles` existent

**Routes Protégées**:
- ✅ `/api/v1/admin/*` : Protégé par `RequireAdmin()`
- ✅ `/api/v1/tracks` (POST) : Protégé par `RequireContentCreatorRole()`
- ✅ `/api/v1/marketplace/products` (POST) : Protégé par `RequireContentCreatorRole()`

**Problèmes**:
- ⚠️ **P1-SECURITY** : Pas de vérification ownership sur certaines routes
  - Exemple: `/api/v1/users/:id` (PUT) - vérifier ownership ou admin
  - Exemple: `/api/v1/tracks/:id` (DELETE) - vérifier ownership ou admin
  - **Fichiers** : `internal/api/router.go:248`, `internal/api/router.go:299`

### Sessions

**Implémentation**:
- ✅ Sessions stockées en DB avec hash du token (pas token en clair)
- ✅ Validation session obligatoire dans `AuthMiddleware.authenticate()`
- ✅ Vérification `expires_at` et `revoked_at`
- ✅ Vérification user_id match entre token et session

**Problèmes**:
- ⚠️ **P2-SECURITY** : Pas de rotation automatique sessions (TTL fixe)
- ⚠️ **P2-SECURITY** : Pas de détection sessions suspectes (multiples IPs, etc.)

## C.3 Injection & Validation

### SQL Injection

**Protection**:
- ✅ **GORM** : Utilisé (parametrized queries par défaut)
- ✅ **Prepared Statements** : Présents (`internal/database/prepared_statements.go`)
- ✅ **Pas de Raw Queries** : Aucune raw query avec concaténation string identifiée
- ✅ **Pas de SELECT *** : Bonne pratique respectée

**Vérification**:
- ✅ 29+ fichiers avec requêtes SQL analysés
- ✅ Toutes utilisent paramètres (`$1`, `$2`, etc.) ou GORM

**Risque**: ✅ **FAIBLE** - Bien protégé

### Input Validation

**Implémentation**:
- ✅ `go-playground/validator/v10` présent
- ✅ Validateurs: `EmailValidator`, `PasswordValidator`
- ⚠️ **P1-SECURITY** : Validation pas utilisée partout
  - Exemples: Handlers peuvent accepter input non validé
  - Impact: Données invalides en DB, risque injection indirecte

**Sanitization XSS**:
- ⚠️ **P2-SECURITY** : Pas de sanitization XSS systématique
  - Impact: XSS possible si données affichées côté frontend sans échappement

**File Upload**:
- ✅ Validation type MIME (`UploadValidator`)
- ✅ Validation taille fichier
- ⚠️ **P1-SECURITY** : Scan antivirus ClamAV mentionné mais non vérifié
  - Fichier: `go.mod` contient `github.com/dutchcoders/go-clamd`
  - Impact: Fichiers malveillants peuvent être uploadés
  - **Fichier** : `internal/handlers/upload.go` - pas d'usage ClamAV trouvé

### CORS

**Implémentation**:
- ✅ CORS middleware présent (`internal/middleware/cors.go`)
- ✅ Whitelist configurable via `CORS_ALLOWED_ORIGINS`
- ✅ Wildcard `*` interdit en production (validation `ValidateForEnvironment()`)

**Problèmes**:
- ⚠️ **P0-SECURITY** : Si `CORS_ALLOWED_ORIGINS` vide, CORS middleware pas appliqué
  - Fichier: `internal/api/router.go:68-74`
  - Impact: CORS errors en browsers, mais pas de faille (pas de wildcard appliqué)
  - Fix: Logger warning (déjà fait) ou appliquer CORS restrictif par défaut

**Headers CORS**:
- ✅ `Access-Control-Allow-Origin`: Origin spécifique (pas wildcard en prod)
- ✅ `Access-Control-Allow-Credentials: true`
- ✅ `Access-Control-Allow-Methods`: GET, POST, PUT, DELETE, OPTIONS
- ✅ `Access-Control-Allow-Headers`: Authorization, Content-Type

### Rate Limiting

**Implémentation**:
- ✅ Rate limiter global (`middleware.RateLimiter` avec Redis)
- ✅ Rate limiter simple (`middleware.SimpleRateLimiter` sans Redis)
- ✅ Rate limiter par endpoint (`middleware.EndpointLimiter`)
- ✅ Rate limiting sur `/api/v1/auth/login` (via `EndpointLimiter.LoginRateLimit()`)

**Problèmes**:
- ✅ **RÉSOLU** : Rate limiting sur `/auth/login` présent (`internal/api/router.go:193-195`)
- ⚠️ **P2-SECURITY** : Rate limiting uploads présent mais peut être contourné (IP spoofing)

**Configuration**:
- ✅ Configurable via `RATE_LIMIT_LIMIT` et `RATE_LIMIT_WINDOW`
- ✅ Headers `X-RateLimit-*` présents

## C.4 Dépendances Vulnérables

**Scan Requis**:
- ⚠️ **P1-SECURITY** : Pas de scan automatique vulnérabilités (`govulncheck` non intégré en CI)
- ⚠️ **P1-SECURITY** : Pas de Dependabot/GitHub Security advisories configuré
- ⚠️ Nombreuses dépendances obsolètes (30+ packages avec updates disponibles)

**Commandes Recommandées**:
```bash
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...
```

**Versions Suspectes**:
- ⚠️ `golang.org/x/crypto v0.37.0` - Vérifier vulnérabilités récentes
- ⚠️ `golang.org/x/net v0.39.0` - Vérifier vulnérabilités récentes
- ⚠️ `github.com/gin-gonic/gin v1.9.1` - Vérifier updates disponibles

## C.5 Top 10 Risques Sécurité

1. **🔴 P0-SECURITY**: CORS pas appliqué si `CORS_ALLOWED_ORIGINS` vide (warning seulement)
2. **🔴 P0-SECURITY**: Tests config incorrects (attendent panic au lieu d'erreur)
3. **🟠 P1-SECURITY**: Scan antivirus ClamAV non vérifié (uploads)
4. **🟠 P1-SECURITY**: Validation input pas systématique (risque injection indirecte)
5. **🟠 P1-SECURITY**: Pas de vérification ownership sur routes PUT/DELETE
6. **🟠 P1-SECURITY**: Pas de scan automatique vulnérabilités (`govulncheck`)
7. **🟡 P2-SECURITY**: Pas de sanitization XSS systématique
8. **🟡 P2-SECURITY**: Pas de rotation automatique sessions
9. **🟡 P2-SECURITY**: Pas de détection sessions suspectes
10. **🟡 P2-SECURITY**: Rate limiting uploads peut être contourné (IP spoofing)

---

# PHASE D - ROBUSTESSE & OBSERVABILITÉ

## D.1 Logs Structurés

**Implémentation**:
- ✅ **Zap** utilisé (`go.uber.org/zap`)
- ✅ Logs structurés JSON en production
- ✅ Niveaux: DEBUG, INFO, WARN, ERROR
- ✅ Context: `request_id`, `user_id`, `trace_id`, `span_id`

**Problèmes**:
- ⚠️ **P1-OBSERVABILITY** : Stack traces dans logs (peut exposer info sensible)
  - Fichier: `internal/middleware/error_handler.go:145` (conditionnel via `includeStackTrace`)
  - Impact: Info sensible (chemins fichiers, code) dans logs prod
  - **FIX PARTIEL** : `includeStackTrace` désactivé en production (`internal/api/router.go:63`)
- ⚠️ **P2-OBSERVABILITY** : Pas de redaction automatique PII (emails, user_ids dans logs)
- ⚠️ **P2-OBSERVABILITY** : Logs peuvent être volumineux (stack traces en dev)

**Corrélation**:
- ✅ `request_id` présent (middleware `RequestID()`)
- ✅ `trace_id` et `span_id` supportés (OpenTelemetry ready)
- ⚠️ **P2-OBSERVABILITY** : OpenTelemetry pas complètement intégré (traces manquantes)

## D.2 Métriques

**Implémentation**:
- ✅ **Prometheus** intégré (`github.com/prometheus/client_golang`)
- ✅ Endpoint `/metrics` exposé
- ✅ Métriques erreurs (`ErrorMetrics`)
- ✅ Métriques health checks (`RecordHealthCheck`)

**Métriques Disponibles**:
- ✅ Erreurs par code (`veza_errors_total{code, status}`)
- ✅ Health checks latence (`veza_health_check_latency_ms{service}`)
- ✅ HTTP requests (via middleware `Metrics()`)

**Problèmes**:
- ⚠️ **P2-OBSERVABILITY** : Métriques business manquantes (tracks créés, users actifs, etc.)
- ⚠️ **P2-OBSERVABILITY** : Pas de métriques DB pool (connections, wait time)
- ⚠️ **P2-OBSERVABILITY** : Pas de métriques Redis (hit rate, latency)

## D.3 Health Checks

**Endpoints**:
- ✅ `/health` : Stateless, toujours `{status: "ok"}`
- ✅ `/healthz` : Liveness probe
- ✅ `/readyz` : Readiness probe (vérifie DB, Redis, RabbitMQ)
- ✅ `/status` : Status complet (DB, Redis, Chat Server, Stream Server)

**Implémentation**:
- ✅ Vérifications avec timeouts (5s DB, 5s Redis, 100ms Stream Server)
- ✅ Latence mesurée et retournée
- ✅ Status: `ok`, `slow`, `error`, `degraded`

**Problèmes**:
- ⚠️ **P1-ROBUSTNESS** : `/readyz` peut échouer si Redis/RabbitMQ down (même en dev)
  - Fichier: `internal/handlers/health.go:143-159`
  - Impact: Kubernetes peut tuer le pod si readiness échoue
  - Fix: Mode dégradé si services optionnels down

## D.4 Timeouts & Retries

**Timeouts**:
- ✅ **Global Handler Timeout** : `HANDLER_TIMEOUT` (défaut: 30s)
- ✅ **Timeout Middleware** : `middleware.Timeout()` appliqué globalement
- ⚠️ **P1-ROBUSTNESS** : Timeout middleware appliqué **2 fois** (duplication)
  - Fichier: `internal/api/router.go:77-79`
  - Impact: Redondant mais pas bloquant
- ⚠️ **P1-ROBUSTNESS** : Pas de timeout DB configuré explicitement (utilise contexte)

**Retries**:
- ✅ **DB Retries** : `DBMaxRetries` (défaut: 5) + `DBRetryInterval` (défaut: 5s)
- ✅ **RabbitMQ Retries** : `RabbitMQMaxRetries` (défaut: 3) + `RabbitMQRetryInterval` (défaut: 2s)

**Circuit Breakers**:
- ⚠️ **P2-ROBUSTNESS** : Pas de circuit breakers implémentés
  - Impact: Pas de protection contre cascading failures

## D.5 Gestion de Charge

**DB Pool**:
- ✅ Configuré: `MaxOpenConns: 25`, `MaxIdleConns: 10`, `MaxLifetime: 5min`, `MaxIdleTime: 1min`
- ⚠️ **P2-PERFORMANCE** : Pas de métriques pool (connections in use, wait time)

**Rate Limiting**:
- ✅ Global: 100 req/min par IP (configurable)
- ✅ Par endpoint: Login 5 attempts/min (configurable)
- ✅ Uploads: Rate limiting spécifique

**Backpressure**:
- ⚠️ **P2-ROBUSTNESS** : Pas de backpressure explicite (dépend de rate limiting)

## D.6 Migrations & Compatibilité

**Stratégie Migrations**:
- ✅ **100% SQL** : Migrations SQL dans `migrations/*.sql`
- ✅ **Transactions** : Chaque migration dans transaction (atomicité)
- ✅ **Versioning** : Table `schema_migrations` pour tracking
- ✅ **GORM Indexes** : Indexes additionnels via GORM après migrations SQL

**Compatibilité**:
- ✅ **UUID Migration** : Migration complète `int64` → `uuid.UUID` effectuée
- ✅ **Soft Delete** : Compatible avec GORM

**Problèmes**:
- ⚠️ **P2-ROBUSTNESS** : Pas de rollback automatique (migrations SQL seulement)
  - Impact: Rollback manuel nécessaire en cas d'échec

---

# PHASE E - PERFORMANCE & SCALABILITÉ

## E.1 Hotspots Évidents

**Allocations**:
- ⚠️ **P2-PERFORMANCE** : Copies de slices/strings dans certains handlers (audit nécessaire)
- ⚠️ **P2-PERFORMANCE** : JSON marshalling peut être optimisé (streaming pour grandes réponses)

**N+1 Queries**:
- ⚠️ **P2-PERFORMANCE** : Risque N+1 dans `ListTracks()` si relations chargées (audit nécessaire)
- ✅ **GORM Preload** : Utilisé dans certains services (`Preload("User")`)

**Locks**:
- ⚠️ **P2-PERFORMANCE** : Pas de locks identifiés (audit nécessaire pour concurrence)

## E.2 Streaming

**Buffering**:
- ✅ **Chunked Upload** : Implémenté (`TrackChunkService`)
- ✅ **Redis Cache** : Utilisé pour chunks (si Redis enabled)

**ffmpeg Pipeline**:
- ⚠️ **P2-PERFORMANCE** : Pas d'implémentation ffmpeg dans backend (délégué à Stream Server)

**IO**:
- ⚠️ **P2-PERFORMANCE** : File I/O synchrone (peut bloquer goroutines)

## E.3 Go-Specific Issues

**Goroutine Leaks**:
- ⚠️ **P1-ROBUSTNESS** : Goroutines dans timeout middleware peuvent leak si handler ne termine pas
  - Fichier: `internal/middleware/timeout.go:24-27`
  - Impact: Memory leak potentiel
  - Fix: Context cancellation + cleanup goroutine

**Context Propagation**:
- ✅ **Context** : Propagé dans handlers → services → repositories
- ⚠️ **P2-PERFORMANCE** : Pas toujours utilisé pour timeouts DB

**DB Pool Misuse**:
- ✅ **Pool Configuré** : MaxOpenConns, MaxIdleConns configurés
- ⚠️ **P2-PERFORMANCE** : Pas de métriques pool pour monitoring

## E.4 Optimisations Mesurables

1. **P2-PERFORMANCE** : Ajouter métriques DB pool (connections, wait time)
2. **P2-PERFORMANCE** : Optimiser JSON marshalling (streaming pour grandes réponses)
3. **P2-PERFORMANCE** : Précharger relations dans `ListTracks()` (éviter N+1)
4. **P2-PERFORMANCE** : File I/O asynchrone (goroutines pour uploads)
5. **P1-ROBUSTNESS** : Fix goroutine leak dans timeout middleware

---

# PHASE F - LISTE EXHAUSTIVE DES PROBLÈMES PRIORISÉS

## Définition des Priorités

- **P0** : Faille sécurité exploitable / perte de données / crash prod / corruption / auth bypass / build cassé
- **P1** : Bugs fréquents / dette bloquante / erreurs de contrat inter-modules / manque de tests critiques
- **P2** : Qualité, maintenabilité, perf non critique, DX
- **P3** : Cosmétique, refactors non urgents

---

## P0 - CRITIQUES (À CORRIGER IMMÉDIATEMENT)

### MOD-P0-001: CORS Middleware Non Appliqué si CORS_ALLOWED_ORIGINS Vide

- **ID** : `MOD-P0-001`
- **Titre** : CORS middleware pas appliqué si `CORS_ALLOWED_ORIGINS` vide
- **Impact** : CORS errors en browsers (requêtes bloquées). En production, si `CORS_ALLOWED_ORIGINS` vide (strict mode), CORS middleware n'est pas appliqué → requêtes cross-origin rejetées par navigateur (comportement attendu mais non documenté).
- **Preuve** : 
  - Fichier: `internal/api/router.go:68-74`
  - Code: `if r.config != nil && len(r.config.CORSOrigins) > 0 { router.Use(middleware.CORS(...)) } else { logger.Warn(...) }`
- **Cause Racine** : Condition `len(r.config.CORSOrigins) > 0` empêche application middleware si liste vide (strict mode).
- **Fix Minimal** : Appliquer CORS middleware même si liste vide (middleware doit rejeter toutes origines sauf celles explicitement autorisées). OU documenter que liste vide = strict mode (pas de CORS).
- **Plan Validation** :
  - Test: Requête cross-origin avec `CORS_ALLOWED_ORIGINS=""` → doit retourner erreur CORS
  - Commande: `curl -H "Origin: http://evil.com" http://localhost:8080/api/v1/health` → doit rejeter
- **Effet de Bord** : Aucun (comportement attendu en strict mode)
- **Effort** : S (1h)

### MOD-P0-002: Tests Config Incorrects (Attendent Panic au lieu d'Erreur)

- **ID** : `MOD-P0-002`
- **Titre** : Tests config attendent panic mais `getEnvRequired()` retourne erreur
- **Impact** : Tests échouent, confusion sur comportement attendu. Si config invalide, application doit crash au démarrage (acceptable) mais tests incorrects.
- **Preuve** :
  - Fichiers: `internal/config/config_test.go:137`, `166`, `315`
  - Tests: `TestLoad_MissingRequiredVariable_DBPassword`, `TestLoad_MissingRequiredVariable_JWTSecret`, `TestNewConfig_RequiresJWTSecret`
  - Code: `getEnvRequired()` retourne `error` (ligne 524-529), pas panic
- **Cause Racine** : Tests écrits avant implémentation ou changement de comportement.
- **Fix Minimal** : Corriger tests pour vérifier erreur retournée au lieu de panic. OU modifier `getEnvRequired()` pour panic (mais moins idiomatique en Go).
- **Plan Validation** :
  - Test: Exécuter `make test` → tests doivent passer
  - Commande: `go test ./internal/config/... -v`
- **Effet de Bord** : Aucun (correction tests seulement)
- **Effort** : S (30min)

### MOD-P0-003: Timeout Middleware Appliqué 2 Fois (Duplication)

- **ID** : `MOD-P0-003`
- **Titre** : Timeout middleware appliqué 2 fois (lignes 77 et 79)
- **Impact** : Redondant mais pas bloquant. Deux timeouts peuvent créer confusion (lequel s'applique?).
- **Preuve** :
  - Fichier: `internal/api/router.go:77-79`
  - Code: `router.Use(middleware.Timeout(r.config.HandlerTimeout))` (ligne 77) puis ligne 79 identique
- **Cause Racine** : Copier-coller ou merge conflict non résolu.
- **Fix Minimal** : Supprimer une des deux lignes (garder ligne 77).
- **Plan Validation** :
  - Test: Vérifier qu'un seul timeout s'applique
  - Commande: `grep -n "Timeout" internal/api/router.go` → doit trouver 1 occurrence
- **Effet de Bord** : Aucun (suppression duplication)
- **Effort** : S (5min)

---

## P1 - IMPORTANTS (À CORRIGER AVANT PROD)

### MOD-P1-001: Scan Antivirus ClamAV Non Vérifié (Uploads)

- **ID** : `MOD-P1-001`
- **Titre** : Scan antivirus ClamAV mentionné mais non vérifié dans code upload
- **Impact** : Fichiers malveillants peuvent être uploadés. Risque sécurité (malware, virus).
- **Preuve** :
  - Fichier: `go.mod` contient `github.com/dutchcoders/go-clamd`
  - Fichier: `internal/handlers/upload.go` - pas d'usage ClamAV trouvé
- **Cause Racine** : Dépendance présente mais intégration manquante.
- **Fix Minimal** : Ajouter scan ClamAV dans `UploadHandler.UploadFile()` avant sauvegarde. Si ClamAV unavailable, rejeter upload (fail-secure).
- **Plan Validation** :
  - Test: Uploader fichier EICAR (test virus) → doit être rejeté
  - Commande: `curl -X POST -F "file=@eicar.txt" http://localhost:8080/api/v1/uploads` → doit retourner 400
- **Effet de Bord** : Uploads plus lents (scan nécessaire). Nécessite ClamAV daemon running.
- **Effort** : M (4h)

### MOD-P1-002: Validation Input Pas Systématique

- **ID** : `MOD-P1-002`
- **Titre** : Validation input avec `go-validator` pas utilisée partout
- **Impact** : Données invalides en DB, risque injection indirecte, corruption données.
- **Preuve** : Handlers peuvent accepter input non validé (audit complet nécessaire). Exemples: `UpdateProfile`, `UpdateTrack`.
- **Cause Racine** : Validation manuelle au lieu de struct tags `validate:""`.
- **Fix Minimal** : Ajouter struct tags `validate:""` sur tous DTOs et middleware validation global. Exemple: `type UpdateProfileRequest struct { Email string `validate:"omitempty,email"` }`
- **Plan Validation** :
  - Test: Envoyer requête avec email invalide → doit retourner 400 avec détails
  - Commande: `curl -X PUT -d '{"email":"invalid"}' http://localhost:8080/api/v1/users/123` → doit valider
- **Effet de Bord** : Requêtes invalides seront rejetées (comportement attendu)
- **Effort** : M (8h)

### MOD-P1-003: Pas de Vérification Ownership sur Routes PUT/DELETE

- **ID** : `MOD-P1-003`
- **Titre** : Pas de vérification ownership sur routes PUT/DELETE (users, tracks)
- **Impact** : Utilisateurs peuvent modifier/supprimer ressources d'autres utilisateurs si ID connu. Risque sécurité (modification non autorisée).
- **Preuve** :
  - Fichier: `internal/api/router.go:248` - `PUT /users/:id` pas de vérification ownership
  - Fichier: `internal/api/router.go:299` - `PUT /tracks/:id` pas de vérification ownership
  - Fichier: `internal/api/router.go:300` - `DELETE /tracks/:id` pas de vérification ownership
- **Cause Racine** : Middleware auth vérifie seulement authentification, pas ownership.
- **Fix Minimal** : Ajouter vérification ownership dans handlers. Exemple: `if track.UserID != userID && !isAdmin { return 403 }`. OU middleware `RequireOwnership()`.
- **Plan Validation** :
  - Test: User A essaie modifier track de User B → doit retourner 403
  - Commande: `curl -X PUT -H "Authorization: Bearer <token_user_a>" http://localhost:8080/api/v1/tracks/<track_id_user_b>` → doit rejeter
- **Effet de Bord** : Utilisateurs ne peuvent plus modifier ressources d'autres (comportement attendu)
- **Effort** : M (6h)

### MOD-P1-004: Pas de Scan Automatique Vulnérabilités (govulncheck)

- **ID** : `MOD-P1-004`
- **Titre** : Pas de scan automatique vulnérabilités (`govulncheck`) en CI/CD
- **Impact** : Vulnérabilités non détectées automatiquement. Risque sécurité (exploitation vulnérabilités connues).
- **Preuve** : Pas de CI/CD configuré. `govulncheck` présent dans Makefile mais pas exécuté automatiquement.
- **Cause Racine** : Pas de CI/CD configuré (GitHub Actions, GitLab CI, etc.).
- **Fix Minimal** : Ajouter étape CI/CD: `govulncheck ./...`. OU intégrer Dependabot/GitHub Security advisories.
- **Plan Validation** :
  - Test: Exécuter `govulncheck ./...` → doit détecter vulnérabilités si présentes
  - Commande: `make security` → doit inclure govulncheck
- **Effet de Bord** : Aucun (détection seulement)
- **Effort** : S (2h pour CI/CD)

### MOD-P1-005: Stack Traces dans Logs Prod (Partiellement Fixé)

- **ID** : `MOD-P1-005`
- **Titre** : Stack traces dans logs peuvent exposer info sensible (chemins fichiers, code)
- **Impact** : Info sensible dans logs prod. Risque fuite données (chemins fichiers, structure code).
- **Preuve** :
  - Fichier: `internal/middleware/error_handler.go:145` - stack traces conditionnels
  - **FIX PARTIEL** : `includeStackTrace` désactivé en production (`internal/api/router.go:63`)
- **Cause Racine** : Stack traces utiles en dev mais dangereux en prod.
- **Fix Minimal** : Vérifier que `includeStackTrace` est bien `false` en production. Ajouter redaction automatique chemins fichiers si stack traces nécessaires.
- **Plan Validation** :
  - Test: Erreur en production → logs ne doivent pas contenir stack traces
  - Commande: `APP_ENV=production go run ...` → vérifier logs
- **Effet de Bord** : Aucun (déjà fixé partiellement)
- **Effort** : S (1h pour vérification)

### MOD-P1-006: /readyz Peut Échouer si Redis/RabbitMQ Down

- **ID** : `MOD-P1-006`
- **Titre** : `/readyz` peut échouer si Redis/RabbitMQ down (même en dev)
- **Impact** : Kubernetes peut tuer le pod si readiness échoue. Service peut être marqué "not ready" même si DB OK (services optionnels down).
- **Preuve** :
  - Fichier: `internal/handlers/health.go:143-159`
  - Code: Vérifie Redis et RabbitMQ même si `REDIS_ENABLE=false` ou `RABBITMQ_ENABLE=false` (à vérifier)
- **Cause Racine** : Readiness vérifie tous services sans distinction optionnels/requis.
- **Fix Minimal** : Mode dégradé si services optionnels down. `/readyz` doit retourner OK si DB OK et services optionnels down (mais status "degraded").
- **Plan Validation** :
  - Test: Redis down, DB OK → `/readyz` doit retourner 200 avec status "degraded"
  - Commande: `curl http://localhost:8080/api/v1/readyz` → doit retourner OK même si Redis down
- **Effet de Bord** : Service marqué "ready" même si services optionnels down (acceptable)
- **Effort** : M (4h)

### MOD-P1-007: Goroutine Leak Potentiel dans Timeout Middleware

- **ID** : `MOD-P1-007`
- **Titre** : Goroutines dans timeout middleware peuvent leak si handler ne termine pas
- **Impact** : Memory leak potentiel. Goroutines non nettoyées → consommation mémoire croissante.
- **Preuve** :
  - Fichier: `internal/middleware/timeout.go:24-27`
  - Code: `go func() { c.Next(); close(done) }()` - goroutine peut ne pas terminer si handler bloque
- **Cause Racine** : Goroutine lancée sans garantie de cleanup si timeout.
- **Fix Minimal** : Context cancellation + cleanup goroutine. Utiliser `context.WithCancel()` et annuler contexte si timeout.
- **Plan Validation** :
  - Test: Handler qui bloque indéfiniment → goroutine doit être nettoyée après timeout
  - Commande: Stress test avec handlers lents → vérifier nombre goroutines (stable)
- **Effet de Bord** : Aucun (fix memory leak)
- **Effort** : M (3h)

---

## P2 - QUALITÉ & MAINTENABILITÉ

### MOD-P2-001: Pas de Sanitization XSS Systématique

- **ID** : `MOD-P2-001`
- **Titre** : Pas de sanitization XSS systématique
- **Impact** : XSS possible si données affichées côté frontend sans échappement. Risque faible (backend ne génère pas HTML).
- **Preuve** : Pas de sanitization trouvée dans handlers.
- **Cause Racine** : Backend REST (JSON) ne génère pas HTML, sanitization côté frontend.
- **Fix Minimal** : Documenter que sanitization doit être côté frontend. OU ajouter sanitization si endpoints génèrent HTML (ex: emails).
- **Plan Validation** : N/A (backend REST)
- **Effet de Bord** : Aucun
- **Effort** : S (1h pour documentation)

### MOD-P2-002: Pas de Rotation Automatique Sessions

- **ID** : `MOD-P2-002`
- **Titre** : Pas de rotation automatique sessions (TTL fixe)
- **Impact** : Sessions longues (30 jours) sans rotation. Risque sécurité faible (tokens révoquables via token_version).
- **Preuve** : Sessions ont TTL fixe, pas de rotation automatique.
- **Cause Racine** : Design simple (TTL fixe).
- **Fix Minimal** : Ajouter rotation automatique (renouveler session après X jours d'inactivité). OU documenter que révocation via token_version est suffisante.
- **Plan Validation** : N/A (amélioration UX)
- **Effet de Bord** : Aucun
- **Effort** : M (4h)

### MOD-P2-003: Pas de Détection Sessions Suspectes

- **ID** : `MOD-P2-003`
- **Titre** : Pas de détection sessions suspectes (multiples IPs, etc.)
- **Impact** : Pas de détection compromission compte. Risque sécurité faible (détection proactive).
- **Preuve** : Pas de détection trouvée.
- **Cause Racine** : Feature non implémentée.
- **Fix Minimal** : Ajouter détection (multiples IPs, géolocalisation, etc.) et alerter utilisateur. OU documenter comme future amélioration.
- **Plan Validation** : N/A (feature additionnelle)
- **Effet de Bord** : Aucun
- **Effort** : L (8h)

### MOD-P2-004: Métriques Business Manquantes

- **ID** : `MOD-P2-004`
- **Titre** : Métriques business manquantes (tracks créés, users actifs, etc.)
- **Impact** : Monitoring business limité. Pas de visibilité sur métriques métier.
- **Preuve** : Métriques Prometheus présentes pour erreurs/health, pas pour business.
- **Cause Racine** : Focus sur métriques techniques.
- **Fix Minimal** : Ajouter métriques business: `veza_tracks_created_total`, `veza_users_active_total`, etc.
- **Plan Validation** :
  - Test: Créer track → métrique `veza_tracks_created_total` doit s'incrémenter
  - Commande: `curl http://localhost:8080/api/v1/metrics | grep tracks_created`
- **Effet de Bord** : Aucun
- **Effort** : M (6h)

### MOD-P2-005: Pas de Métriques DB Pool

- **ID** : `MOD-P2-005`
- **Titre** : Pas de métriques DB pool (connections, wait time)
- **Impact** : Monitoring DB limité. Pas de visibilité sur utilisation pool.
- **Preuve** : Pas de métriques pool trouvées.
- **Cause Racine** : Métriques pool non exposées.
- **Fix Minimal** : Exposer métriques `sql.DB.Stats()` via Prometheus: `veza_db_pool_open_connections`, `veza_db_pool_wait_count`, etc.
- **Plan Validation** :
  - Test: Stress test → métriques pool doivent refléter utilisation
  - Commande: `curl http://localhost:8080/api/v1/metrics | grep db_pool`
- **Effet de Bord** : Aucun
- **Effort** : M (4h)

### MOD-P2-006: Pas de Métriques Redis

- **ID** : `MOD-P2-006`
- **Titre** : Pas de métriques Redis (hit rate, latency)
- **Impact** : Monitoring Redis limité. Pas de visibilité sur performance cache.
- **Preuve** : Pas de métriques Redis trouvées.
- **Cause Racine** : Métriques Redis non exposées.
- **Fix Minimal** : Exposer métriques Redis via Prometheus: `veza_redis_hit_rate`, `veza_redis_latency_ms`, etc.
- **Plan Validation** :
  - Test: Requêtes avec cache → métriques Redis doivent refléter hits/misses
  - Commande: `curl http://localhost:8080/api/v1/metrics | grep redis`
- **Effet de Bord** : Aucun
- **Effort** : M (4h)

### MOD-P2-007: Pas de Redaction Automatique PII dans Logs

- **ID** : `MOD-P2-007`
- **Titre** : Pas de redaction automatique PII (emails, user_ids dans logs)
- **Impact** : PII dans logs (RGPD compliance). Risque faible si logs sécurisés.
- **Preuve** : Logs peuvent contenir emails, user_ids sans redaction.
- **Cause Racine** : Redaction PII non implémentée.
- **Fix Minimal** : Ajouter redaction automatique PII dans logs (emails → `***@***`, user_ids → hash). OU documenter que logs sont sécurisés.
- **Plan Validation** :
  - Test: Logger email → logs ne doivent pas contenir email en clair
  - Commande: `grep -r "email" logs/` → emails doivent être redactés
- **Effet de Bord** : Aucun
- **Effort** : M (6h)

### MOD-P2-008: OpenTelemetry Pas Complètement Intégré

- **ID** : `MOD-P2-008`
- **Titre** : OpenTelemetry pas complètement intégré (traces manquantes)
- **Impact** : Distributed tracing limité. Pas de visibilité sur traces complètes.
- **Preuve** : `trace_id` et `span_id` supportés mais traces non générées.
- **Cause Racine** : OpenTelemetry partiellement intégré.
- **Fix Minimal** : Intégrer OpenTelemetry complet (traces, spans). OU documenter comme future amélioration.
- **Plan Validation** : N/A (feature additionnelle)
- **Effet de Bord** : Aucun
- **Effort** : L (12h)

### MOD-P2-009: Pas de Circuit Breakers

- **ID** : `MOD-P2-009`
- **Titre** : Pas de circuit breakers implémentés
- **Impact** : Pas de protection contre cascading failures. Risque faible (retries présents).
- **Preuve** : Pas de circuit breakers trouvés.
- **Cause Racine** : Feature non implémentée.
- **Fix Minimal** : Ajouter circuit breakers pour services externes (Chat Server, Stream Server). OU documenter comme future amélioration.
- **Plan Validation** : N/A (feature additionnelle)
- **Effet de Bord** : Aucun
- **Effort** : M (8h)

### MOD-P2-010: Pas de Rollback Automatique Migrations

- **ID** : `MOD-P2-010`
- **Titre** : Pas de rollback automatique migrations (migrations SQL seulement)
- **Impact** : Rollback manuel nécessaire en cas d'échec. Risque faible (migrations transactionnelles).
- **Preuve** : Migrations SQL n'ont pas de `.down.sql` correspondants.
- **Cause Racine** : Stratégie 100% SQL sans down migrations.
- **Fix Minimal** : Ajouter down migrations (`.down.sql`) OU documenter procédure rollback manuelle.
- **Plan Validation** : N/A (amélioration DX)
- **Effet de Bord** : Aucun
- **Effort** : L (16h pour toutes migrations)

---

## P3 - COSMÉTIQUE & REFACTORS

### MOD-P3-001: 90 TODOs/FIXMEs dans Code

- **ID** : `MOD-P3-001`
- **Titre** : 90 TODOs/FIXMEs dans code
- **Impact** : Dette technique. Maintenance difficile.
- **Preuve** : Grep trouve 90 TODOs/FIXMEs.
- **Cause Racine** : Features incomplètes, refactors différés.
- **Fix Minimal** : Trier TODOs par priorité, créer issues GitHub, résoudre progressivement.
- **Plan Validation** : N/A
- **Effet de Bord** : Aucun
- **Effort** : L (variable)

### MOD-P3-002: Duplication Handlers (legacy + modern)

- **ID** : `MOD-P3-002`
- **Titre** : Duplication handlers (`internal/handlers/` ET `internal/api/handlers/`)
- **Impact** : Confusion, maintenance difficile.
- **Preuve** : Handlers dans deux emplacements.
- **Cause Racine** : Migration legacy → modern incomplète.
- **Fix Minimal** : Consolider handlers dans `internal/api/handlers/`, supprimer `internal/handlers/` (si possible).
- **Plan Validation** : N/A
- **Effet de Bord** : Aucun
- **Effort** : M (8h)

### MOD-P3-003: Couplage Services → GORM Direct

- **ID** : `MOD-P3-003`
- **Titre** : Certains services appellent directement GORM (bypass repositories)
- **Impact** : Violation séparation couches. Maintenance difficile.
- **Preuve** : Services utilisent `db.GormDB` directement.
- **Cause Racine** : Refactor incomplet vers repositories.
- **Fix Minimal** : Migrer services vers repositories. OU documenter exceptions.
- **Plan Validation** : N/A
- **Effet de Bord** : Aucun
- **Effort** : L (variable)

---

# PHASE G - PLAN D'EXÉCUTION

## G.1 Checklist P0 (Ordre Strict)

1. **MOD-P0-001** : Fix CORS middleware (appliquer même si liste vide) - **1h**
2. **MOD-P0-002** : Fix tests config (vérifier erreur au lieu de panic) - **30min**
3. **MOD-P0-003** : Supprimer duplication timeout middleware - **5min**

**Total P0** : ~2h

## G.2 Checklist P1 (Par Lots Cohérents)

### Lot 1: Sécurité Uploads & Validation (1 sprint)

1. **MOD-P1-001** : Intégrer scan ClamAV (uploads) - **4h**
2. **MOD-P1-002** : Validation input systématique - **8h**
3. **MOD-P1-003** : Vérification ownership routes PUT/DELETE - **6h**

**Total Lot 1** : ~18h (2-3 jours)

### Lot 2: Robustesse & Observabilité (1 sprint)

4. **MOD-P1-004** : Scan vulnérabilités CI/CD - **2h**
5. **MOD-P1-005** : Vérifier stack traces logs prod - **1h**
6. **MOD-P1-006** : Fix /readyz (mode dégradé) - **4h**
7. **MOD-P1-007** : Fix goroutine leak timeout - **3h**

**Total Lot 2** : ~10h (1-2 jours)

**Total P1** : ~28h (3-5 jours)

## G.3 Quick Wins (≤ 1h chacun)

1. **MOD-P0-003** : Supprimer duplication timeout - **5min**
2. **MOD-P1-004** : Ajouter govulncheck CI/CD - **2h** (si CI/CD configuré)
3. **MOD-P2-001** : Documenter sanitization XSS - **1h**

**Total Quick Wins** : ~3h

## G.4 Tests à Ajouter en Priorité

1. **Tests Ownership** : Vérifier que users ne peuvent pas modifier ressources d'autres
2. **Tests ClamAV** : Vérifier rejet fichiers malveillants
3. **Tests Validation** : Vérifier rejet input invalide
4. **Tests CORS** : Vérifier comportement avec `CORS_ALLOWED_ORIGINS` vide
5. **Tests Timeout** : Vérifier timeout middleware (pas de leak)

## G.5 PR Plan

### PR 1: Fix P0 Critiques
- **Titre** : `fix(security): Fix CORS middleware and config tests (P0)`
- **Fichiers** : `internal/api/router.go`, `internal/config/config_test.go`
- **Tests** : Tests CORS, tests config
- **Taille** : Petite (~200 lignes)

### PR 2: Sécurité Uploads
- **Titre** : `feat(security): Add ClamAV scan for file uploads (P1)`
- **Fichiers** : `internal/handlers/upload.go`, `internal/services/upload_validator.go`
- **Tests** : Tests ClamAV (EICAR)
- **Taille** : Moyenne (~500 lignes)

### PR 3: Validation Input
- **Titre** : `feat(validation): Add systematic input validation (P1)`
- **Fichiers** : DTOs, middleware validation
- **Tests** : Tests validation tous endpoints
- **Taille** : Grande (~1000 lignes)

### PR 4: Ownership Verification
- **Titre** : `feat(security): Add ownership verification for PUT/DELETE (P1)`
- **Fichiers** : `internal/api/router.go`, handlers users/tracks
- **Tests** : Tests ownership
- **Taille** : Moyenne (~600 lignes)

### PR 5: Robustesse
- **Titre** : `feat(robustness): Fix /readyz and goroutine leak (P1)`
- **Fichiers** : `internal/handlers/health.go`, `internal/middleware/timeout.go`
- **Tests** : Tests health checks, tests timeout
- **Taille** : Moyenne (~400 lignes)

### PR 6: Observabilité (P2)
- **Titre** : `feat(observability): Add business and DB pool metrics (P2)`
- **Fichiers** : `internal/metrics/`, handlers
- **Tests** : Tests métriques
- **Taille** : Moyenne (~500 lignes)

---

## G.6 Estimation Totale

- **P0** : 2h
- **P1** : 28h
- **P2** : ~60h (optionnel)
- **P3** : Variable (refactors)

**Total Critique (P0+P1)** : ~30h (1 semaine développeur)

---

# CONCLUSION

**Module** : veza-backend-api (Backend Go)  
**Status Global** : ✅ **Fonctionnel** avec **améliorations nécessaires**

**Points Forts** :
- ✅ Architecture solide (handlers → services → repositories)
- ✅ Sécurité JWT bien implémentée (HS256, token versioning, sessions DB)
- ✅ RBAC fonctionnel
- ✅ Observabilité de base (logs structurés, Prometheus, Sentry)
- ✅ Migrations SQL transactionnelles

**Points Faibles** :
- ⚠️ 3 problèmes P0 (CORS, tests, duplication)
- ⚠️ 7 problèmes P1 (sécurité uploads, validation, ownership, robustesse)
- ⚠️ 10+ problèmes P2 (observabilité, performance)

**Recommandation** : Corriger P0 immédiatement, puis P1 avant production, P2 progressivement.

---

**Fin du Rapport**