veza/docs/archive/backend-sessions-2026/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
2. PHASE B - Santé Technique
3. PHASE C - Sécurité
4. PHASE D - Robustesse & Observabilité
5. PHASE E - Performance & Scalabilité
6. PHASE F - Liste Exhaustive des Problèmes Priorisés
7. PHASE G - Plan d'Exé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:

{
  "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:

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

Error Response (standardisé):

{
  "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:

make build                    # Compile (bin/veza-backend-api)
make build-linux              # Compile pour Linux

Run:

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:

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

make lint                     # golangci-lint
make vet                      # go vet
make format                   # go fmt + goimports
make security                 # gosec + govulncheck

Migrations:

make migrate                  # Exécute migrations
make migrate-lab              # Migrations en environnement lab

Configuration

Variables d'Environnement Requises:

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

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:

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:

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:

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