veza/docs/archive/root-md/AUDIT.md

I'll conduct this comprehensive technical audit by systematically exploring every layer of your monorepo. Let me start by gathering all the critical information in parallel.

[5 tools called]

Now let me dive deeper into specific security and infrastructure concerns.

[6 tools called]

Now let me write the complete audit report. Given the massive amount of data collected, I'll produce the full structured document.

[1 tool called]

---

AUDIT TECHNIQUE INTÉGRAL — MONOREPO VEZA

Date : 14 février 2026
Auditeur : Analyse automatisée exhaustive du code source
Périmètre : Monorepo complet (/home/senke/git/talas/veza)
Classification : Confidentiel — Comité d'investissement

---

EXECUTIVE SUMMARY

Veza est une plateforme audio collaborative (type SoundCloud/Bandcamp) avec marketplace, chat temps réel, streaming audio, social, et éducation. Le monorepo contient 4 services (Go API, 2 serveurs Rust, frontend React) et un site documentation.

Verdict global : Le produit est fonctionnel mais pas prêt pour la production.

Le backend Go est le composant le plus mature (150+ endpoints, tests solides, sécurité raisonnable). Le frontend est ambitieux mais contient ~150 fichiers de code mort. Les services Rust ont des TODOs critiques non résolus. Trois vulnérabilités de sécurité critiques ont été identifiées, toutes liées à des bypasses de développement laissés actifs.

Dimension	Score
Architecture	6/10
Maintenabilité	5/10
Sécurité	5/10
Scalabilité	7/10

---

1. CARTOGRAPHIE GLOBALE

Stack technique complète

Couche	Technologie	Version
Frontend	React + TypeScript	18.2.0 / 5.3.3
Build	Vite	7.1.5
CSS	Tailwind CSS	4.0.0
State	Zustand	4.5.0
Data	TanStack Query	5.17.0
Forms	React Hook Form + Zod	7.49.3 / 3.25.76
Tests frontend	Vitest + Playwright + Storybook	3.2.4 / 1.58.2 / 8.6.15
Backend API	Go + Gin	1.23.8 / 1.11.0
ORM	GORM	1.30.0
Chat Server	Rust + Axum	edition 2021 / 0.8
Stream Server	Rust + Axum + Symphonia	edition 2021 / 0.8 / 0.5
Base de données	PostgreSQL	16
Cache	Redis	7
Message broker	RabbitMQ	3
Storage	AWS S3	SDK v2
Monitoring	Prometheus + Sentry	-
CI/CD	GitHub Actions	11 workflows
Conteneurs	Docker + Kubernetes	Multi-stage builds
Documentation	Docusaurus + Storybook	3.8.1 / 8.6.15

Organisation du monorepo

veza/
├── apps/web/               # Frontend React (799 composants TSX)
├── veza-backend-api/        # API Go (88 handlers, 163 services, 49 middlewares)
├── veza-chat-server/        # Chat WebSocket Rust
├── veza-stream-server/      # Audio streaming Rust
├── veza-common/             # Bibliothèque Rust partagée
├── veza-docs/               # Documentation Docusaurus
├── fixtures/                # Seeding & fixtures
├── config/docker/           # Configs Docker
├── infra/                   # Configs infra lab
├── scripts/                 # Scripts utilitaires
├── make/                    # Modules Makefile
└── .github/workflows/       # 11 workflows CI/CD

Outil monorepo

npm workspaces uniquement pour le frontend. Go et Rust sont gérés indépendamment. Pas de Turborepo, Nx, ou Lerna. C'est essentiellement un poly-repo déguisé en monorepo — seul apps/web bénéficie réellement du workspace. Les services Go et Rust n'ont aucun lien de build partagé avec le frontend.

Dépendance potentiellement abandonnée

• github.com/Lyimmi/go-clamd v1.0.0 — dernière mise à jour 2017 (scan antivirus ClamAV). Risque : vulnérabilités non corrigées, pas de maintenance.

Flux de données

Browser → React (Vite) → Axios + httpOnly cookies
  ↓
Go API (Gin) ← JWT ← PostgreSQL ← GORM
  ↓
Redis (cache, rate limit, sessions)
RabbitMQ (event bus)
AWS S3 (fichiers audio)
ClamAV (scan antivirus)
  ↓
Chat Server (Rust/Axum) ← WebSocket ← JWT
Stream Server (Rust/Axum) ← WebSocket/HLS ← JWT
  ↓
PostgreSQL (messages, streams)
Redis (présence, sync)

---

2. CE QUE LE PRODUIT PERMET RÉELLEMENT

Features validées (fonctionnelles, routes + backend + frontend)

Feature	Backend	Frontend	Tests
Authentification (login, register, 2FA, OAuth)	✅ Complet	✅ Complet	✅
Gestion de profil	✅ Complet	✅ Complet	✅
Upload et gestion de tracks	✅ Complet (chunked)	✅ Complet	✅
Playlists (CRUD, collaboratifs, export)	✅ Complet	✅ Complet	⚠️ 3 tests skip
Marketplace (produits, commandes, panier)	✅ Complet	✅ Complet	✅
Chat temps réel (WebSocket)	✅ Complet	✅ Complet	✅
Recherche (tracks, users, playlists)	✅ Complet	✅ Complet	✅
Notifications	✅ Complet	✅ Complet	✅
Social (feed, posts, likes, groupes)	✅ Complet	✅ Complet	✅
Webhooks (CRUD, test, stats)	✅ Complet	✅ Complet	✅
Analytics et dashboard	✅ Complet	✅ Complet	✅
Sessions (gestion, révocation)	✅ Complet	✅ Complet	✅
Settings utilisateur	✅ Complet	✅ Complet	✅
Admin dashboard	✅ Complet	✅ Complet	✅
Rôles et permissions (RBAC)	✅ Complet	✅ Complet	✅
Audit trail	✅ Complet	✅ Complet	✅

Features partiellement implémentées

Feature	État	Détail
Streaming HLS	⚠️ Backend complet, feature flag OFF	HLS_STREAMING: false dans config/features.ts
Playlist Search	⚠️ Backend complet, feature flag OFF	PLAYLIST_SEARCH: false (activé seulement en Storybook)
Playlist Recommendations	⚠️ Backend complet, feature flag OFF	PLAYLIST_RECOMMENDATIONS: false
Role Management UI	⚠️ Backend complet, feature flag OFF	ROLE_MANAGEMENT: false
Audio transcoding	⚠️ Pipeline stub	core/encoding_pool.rs:141 — TODO: implémenter la création réelle du pipeline
Developer API Keys	⚠️ Frontend localStorage	Pas de persistance backend pour les clés API

Features fantômes (code présent, inaccessible)

Feature	Fichiers	Problème
Studio	93+ fichiers dans src/components/studio/	Aucune route dans routeConfig.tsx. Feature entièrement implémentée côté UI mais inaccessible
Gamification	gamificationService.ts, LeaderboardView, AchievementsView	Service mock, TODO: "Implement with real API endpoints when backend is ready"
Cloud Storage	storageService.ts, CloudFileBrowser	Service mock avec données hardcodées
Projects Manager	projectService.ts, ProjectsManager	Service mock, lié au Studio fantôme

Features mortes / deprecated

Feature	Fichier	État
Modal composant	src/components/ui/modal.tsx	@deprecated S1.4: Prefer using Dialog — encore utilisé
ToastProvider	src/components/feedback/ToastProvider.tsx	@deprecated S1.2: Use useToast — encore importé
aggressiveVisualFix	src/utils/aggressiveVisualFix.ts	Deprecated, fix visuel agressif
Legacy chat tables	migrations/050_legacy_chat.sql	Tables legacy coexistant avec le chat Rust

Incohérences produit/code

1. 19 fichiers de tests exclus dans vitest.config.ts pour des composants non implémentés (CommentForm, PlaysChart, TrackEdit, TrackUpload, HLSPlayer, ProfileEditForm, etc.)
2. 3 services mock-only (gamificationService, projectService, storageService) référencés par des composants actifs
3. 100+ commentaires TODO/FIXME non résolus dans le frontend
4. 7 tests skippés dans les suites Vitest actives

---

3. VALIDATION FONCTIONNELLE

Couverture des tests

Couche	Tests unitaires	Tests intégration	Tests E2E	Seuil couverture
Backend Go	88 fichiers handler + 163 fichiers service	✅ tests/api_routes_integration_test.go	-	Non configuré
Frontend	286 fichiers .test.ts/.tsx	-	✅ Playwright (4 navigateurs)	80% (branches, functions, lines)
Chat Rust	Tests unitaires présents	-	-	Non configuré
Stream Rust	Tests unitaires présents	-	-	Non configuré
Stories	323 fichiers .stories.tsx	-	-	-

Points de rupture identifiés

1. Rate limiting fail-open — Si Redis est indisponible, le rate limiting du chat server est désactivé silencieusement (handler.rs:299). Un attaquant peut flood le service pendant un incident Redis.

2. Account lockout fail-open — Si Redis est indisponible, le lockout de comptes est désactivé (account_lockout_service.go:89-94). Brute force possible pendant un incident Redis.

3. INTERNAL_API_KEY optionnel — Le stream server n'exige pas cette clé pour les callbacks vers le backend (compression.rs:536). Les notifications de transcoding peuvent échouer silencieusement.

4. Migration relative path — database.go:239 utilise filepath.Glob("migrations/*.sql") avec un chemin relatif. Si le binaire est lancé depuis un répertoire différent, les migrations échouent.

Scénarios de crash évidents

1. Dual migration numbers — Les migrations 020_create_sessions.sql et 020_rbac_and_profiles.sql ont le même préfixe. L'ordre alphabétique peut créer des incohérences de schéma.
2. Idem pour 050_data_validation_constraints.sql et 050_legacy_chat.sql.
3. Pas de migrations down — Aucun rollback possible en cas de migration défaillante.

Zones non testées

• 19 composants frontend référencés dans vitest.config.ts comme exclus
• Studio feature (93+ fichiers, 0 test)
• Pipeline d'encodage audio (stub)
• Gamification service (mock)
• Intégration ClamAV end-to-end
• WebSocket stream server rate limiting
• Rollback de migration

---

4. AUDIT DE SÉCURITÉ — OWASP TOP 10

A01 — Broken Access Control

Vulnérabilité	Gravité	Fichier	Détail
Dev bypass role check	CRITIQUE	middleware/auth.go:440-451	En mode development, TOUS les checks de rôle sont bypassed. Si APP_ENV=development en production → accès total.
Dev bypass CSRF	CRITIQUE	middleware/csrf.go:44-47	CSRF désactivé si env == "development". Misconfiguration = CSRF exploitable.
Ownership checks	OK	Handlers	Les routes de modification vérifient la propriété (ownership middleware).
Admin routes	OK	router.go	Routes admin protégées par middleware admin.
IDOR potentiel	Faible	Handlers profil	PUT /api/v1/users/:id vérifie ownership. Pas de IDOR évident.

Scénario d'exploitation A01 : Un attaquant découvre que l'environnement de staging/preprod est configuré avec APP_ENV=development. Il peut alors bypasser toutes les vérifications de rôle et créer du contenu, accéder aux routes admin, et contourner la protection CSRF.

A02 — Cryptographic Failures

Vulnérabilité	Gravité	Fichier	Détail
Bcrypt cost 12	OK	password_service.go:21	Acceptable
JWT HS256	OK	jwt_service.go:127	Validation stricte de l'algorithme
JWT secret min 32 chars	OK	config.go	Validé au démarrage
Password truncation silencieuse	Élevée	password_service.go:299-303	Mots de passe > 72 bytes tronqués sans erreur. L'utilisateur croit être protégé par un mot de passe long.
Chat JWT secret fallback	Moyenne	config.go:262	Si CHAT_JWT_SECRET non défini, utilise le secret principal. Blast radius augmenté.
Tokens httpOnly cookies	OK	Frontend	Tokens non accessibles en JS
HTTPS (HSTS)	OK	security_headers.go	En production uniquement

A03 — Injection

Vulnérabilité	Gravité	Fichier	Détail
SQL injection	Faible	Backend Go	GORM paramétrise les requêtes. Raw SQL utilise $1, $2 placeholders.
SQL injection (Rust)	Faible	Chat/Stream	SQLx avec requêtes paramétrées.
XSS	Faible	Frontend	DOMPurify sur dangerouslySetInnerHTML. Config stricte.
NoSQL injection	N/A	-	Pas de NoSQL
Command injection	Faible	compression.rs	FFmpeg exécuté via commande système mais avec paramètres contrôlés

A04 — Insecure Design

Vulnérabilité	Gravité	Fichier	Détail
Rate limit bypass via headers	CRITIQUE	rate_limiter.go:94-104	Headers X-Test-Mode: true ou X-E2E-Test: true désactivent le rate limiting. Un attaquant peut envoyer ces headers.
Rate limiting present	OK	Auth endpoints	EndpointLimiter avec limites configurées
Input validation	OK	Validators, Zod	Validation côté serveur et client
Account lockout	OK	account_lockout_service.go	5 tentatives / 30 min lockout

Scénario d'exploitation A04 : Un attaquant envoie X-Test-Mode: true dans ses requêtes HTTP. Le rate limiter du backend Go est immédiatement désactivé. L'attaquant peut alors brute-forcer les identifiants sans restriction.

A05 — Security Misconfiguration

Vulnérabilité	Gravité	Fichier	Détail
Debug print en production	Faible	auth.go:88	fmt.Println("DEBUG: Using c.JSON(401)") laissé dans le code
JWT secrets hardcodés (dev)	Faible	docker-compose.yml:98	dev-secret-key-minimum-32-characters-long — acceptable en dev
Grafana default password	Faible	Docker compose locaux	admin/admin — dev uniquement
Elasticsearch security off	Faible	docker-compose.local.yml:72	Dev uniquement
CORS validé en production	OK	cors.go, config.go	Pas de wildcard en production
Security headers	OK	security_headers.go	CSP, HSTS, X-Frame-Options, etc.

A06 — Vulnerable & Outdated Components

Vulnérabilité	Gravité	Fichier	Détail
go-clamd v1.0.0	Moyenne	go.mod	Abandonné depuis 2017, risque de vulnérabilités
CI scanning	OK	CI workflows	govulncheck, cargo audit, npm audit exécutés
Trivy scanning	Partiel	Stream server seulement	Main CD pipeline n'a pas de scan Trivy

A07 — Identification & Authentication Failures

Vulnérabilité	Gravité	Fichier	Détail
JWT token versioning	OK	jwt_service.go, auth.go:136	Révocation via version
Session management	OK	session_service.go	Auto-refresh, révocation
Password reset anti-enum	OK	auth/service.go:806-814	Retourne nil si user non trouvé
Timing attack CSRF	Élevée	csrf.go:122	Comparaison string non constant-time. if storedToken != token
Session refresh race	Moyenne	auth.go:199-216	Goroutine sans mutex. Refreshs concurrents possibles.
2FA implémenté	OK	twoFactorHandler	TOTP complet

A08 — Software & Data Integrity Failures

Vulnérabilité	Gravité	Fichier	Détail
Pas de signature d'images Docker	Moyenne	.github/workflows/cd.yml	Images poussées sans cosign
CI/CD avec secrets GitHub	OK	Workflows	Secrets gérés via GitHub
Input validation backend	OK	Validators, binding tags	Validation serveur systématique

A09 — Logging & Monitoring Failures

Vulnérabilité	Gravité	Fichier	Détail
Structured logging	OK	Zap (Go), tracing (Rust)	Logs structurés partout
Audit trail	OK	audit_handler.go, audit_service.go	Logs d'audit avec détection activités suspectes
Sentry integration	OK	Frontend + Backend	Error tracking
Prometheus metrics	OK	Tous les services	Métriques exposées
Info disclosure lockout	Faible	auth/service.go:438	Message d'erreur révèle la durée du lockout

A10 — SSRF

Vulnérabilité	Gravité	Fichier	Détail
Webhook URLs	Moyenne	webhook.go	URLs de webhook fournies par l'utilisateur. Vérifier si les URLs internes sont filtrées.
OAuth callbacks	OK	oauthHandler	Providers configurés côté serveur
Stream callbacks	OK	Internal routes	Authentifié par API key interne

Résumé sécurité

Catégorie	Critique	Élevée	Moyenne	Faible
A01 - Access Control	2	0	0	0
A02 - Crypto	0	1	1	0
A03 - Injection	0	0	0	1
A04 - Insecure Design	1	0	0	0
A05 - Misconfig	0	0	0	3
A06 - Outdated	0	0	1	0
A07 - Auth Failures	0	1	1	0
A08 - Integrity	0	0	1	0
A09 - Logging	0	0	0	1
A10 - SSRF	0	0	1	0
TOTAL	3	2	5	5

---

5. DETTE TECHNIQUE

Dette critique (bloquante)

Problème	Fichier(s)	Impact
3 bypasses sécurité pilotés par env	rate_limiter.go, csrf.go, auth.go	Exploitation possible si env mal configuré
Duplicate migration numbers	020_*.sql, 050_*.sql	Schéma DB potentiellement incohérent
Pas de migrations down	migrations/	Impossible de rollback une migration en erreur
Pipeline encoding stub	encoding_pool.rs:141	Transcoding audio non fonctionnel
93+ fichiers Studio fantômes	components/studio/	~150 fichiers de code mort inaccessible

Dette structurante

Problème	Fichier(s)	Impact
19 tests exclus pour composants non implémentés	vitest.config.ts	Tests écrits pour du code qui n'existe pas
7 tests skippés	Suites Vitest	Régressions non détectées
Services mock-only (gamification, projects, storage)	src/services/	Features fantômes visibles dans l'UI
Composants deprecated encore utilisés (Modal, ToastProvider)	modal.tsx, ToastProvider.tsx	Double implémentation, confusion
100+ TODO/FIXME non résolus	Frontend entier	Travail inachevé accumulé
Repository pattern incomplet	internal/repositories/	Track, Notification, Webhook, Role n'ont pas de repository dédié
Monorepo sans orchestration	Racine	Go et Rust indépendants, pas de build unifié
Feature flags pour features backend-ready	config/features.ts	4 features désactivées côté frontend alors que le backend est prêt
router.go : 1576 lignes	internal/api/router.go	Fichier massif, difficile à maintenir
Chat server legacy modules	security_legacy.rs, auth.rs	Code mort dans le serveur Rust

Dette cosmétique

Problème	Fichier(s)	Impact
Debug print laissé	auth.go:88	Pollution des logs
Info disclosure lockout duration	auth/service.go:438	Fuite d'information mineure
Composants > 300 lignes	Plusieurs fichiers	Non-conformité aux règles projet
Duplicate skeleton patterns	Composants studio/views	Patterns répétitifs non factorisés
Convention mixte (anglais/français)	Commentaires, docs	Incohérence linguistique

---

6. QUALITÉ ARCHITECTURALE

Frontend — Structure

Le frontend suit une organisation features-first avec séparation claire entre composants UI, features métier, services, hooks, et stores. React Router avec lazy loading systématique. Zustand pour le state, TanStack Query pour le data fetching. MSW pour les mocks (1737 lignes de handlers). Storybook obligatoire pour les composants.

Points forts : Séparation des responsabilités claire. Lazy loading systématique. DOMPurify pour la sanitization. CSRF géré côté client. httpOnly cookies.

Points faibles : 799 composants TSX — volume massif. 93+ fichiers Studio fantômes. 3 services mock-only. Composants deprecated non nettoyés.

Backend — Structure

Architecture handlers → services → repositories → database classique et propre. 150+ endpoints bien organisés. Middleware stack complète (CORS, CSRF, rate limiting, auth, security headers, metrics, logging). Migrations SQL manuelles (pas d'outil type golang-migrate). GORM pour l'ORM avec raw SQL quand nécessaire.

Points forts : Sécurité mature (JWT versioning, account lockout, audit trail). 88 handlers testés. Séparation propre des couches.

Points faibles : router.go à 1576 lignes. Repository pattern incomplet. Migrations avec numéros dupliqués. Pas de down migrations.

Services Rust — Structure

Architecture Axum/Tokio correcte. Gestion d'erreurs avec types dédiés. Logging structuré via tracing. Event bus RabbitMQ avec dégradation gracieuse.

Points forts : Requêtes SQL paramétrées. Signatures timing-safe (stream server). Rate limiting granulaire (chat server).

Points faibles : Timeouts hardcodés. Rate limiting fail-open. Pipeline d'encodage stub. Modules legacy.

CI/CD

11 workflows GitHub Actions. Scanning de sécurité (govulncheck, cargo audit, npm audit, Trivy partiel). Pipeline complète : lint → test → build → deploy.

Points faibles : Pas de Trivy dans le CD principal. Pas de signature d'images. Pas de SBOM.

Scores

Dimension	Score	Justification
Architecture	6/10	Bonne séparation des couches, mais monorepo sans orchestration réelle. Go et Rust isolés. Studio fantôme pollue la base de code. Router.go monolithique.
Maintenabilité	5/10	100+ TODOs, 150+ fichiers morts, composants deprecated, tests exclus/skippés, conventions mixtes français/anglais, pas de down migrations.
Sécurité	5/10	Fondations solides (JWT versioning, bcrypt, security headers, audit trail) MAIS 3 vulnérabilités critiques (bypasses dev), timing attack CSRF, fail-open patterns.
Scalabilité	7/10	Architecture microservices appropriée. PostgreSQL + Redis + RabbitMQ. Code splitting frontend. HLS streaming prévu. Prometheus metrics. Kubernetes-ready. Manque le pipeline d'encodage réel.

---

7. INFRA & DEVOPS

Docker

Positif :

• Multi-stage builds sur tous les services (images optimisées)
• Utilisateurs non-root dans tous les Dockerfiles
• Health checks configurés partout
• Isolation réseau via veza-net
• Resource limits configurés
• Fichiers de production séparés des fichiers de dev

Négatif :

• Secrets hardcodés dans les docker-compose dev (acceptable mais risque de copier en prod)
• Grafana avec password admin dans les configs monitoring locales
• Elasticsearch security désactivé en local

Gestion des environnements

• dev : docker-compose.yml — secrets hardcodés, acceptable
• test : docker-compose.test.yml — tmpfs, credentials test
• staging : docker-compose.staging.yml — variables d'environnement requises
• production : docker-compose.prod.yml — validation des variables (${DB_PASS:?DB_PASS must be set}), SSL obligatoire

La chaîne dev → staging → prod est cohérente. Le code valide bien les variables critiques en production (config.go:141-198).

Secrets

• .gitignore exclut correctement tous les .env* et le répertoire secrets/
• Pas de secrets trouvés dans le code source versionné
• CI/CD utilise GitHub Secrets
• Backend masque les secrets dans les logs (config.go:1369-1384)

Reproductibilité

Le setup est reproductible via Docker Compose. fixtures/ package permet le seeding. Pas de docker-compose up one-liner documenté qui lance tout le stack — chaque service a son propre compose.

---

8. RISQUES BUSINESS

Point de vue CTO

Peut-on lancer ce produit en prod ?

Non, pas en l'état. Les 3 vulnérabilités critiques (bypass rate limiting via headers, bypass CSRF en dev, bypass rôles en dev) doivent être corrigées avant tout déploiement. Le pipeline d'encodage audio est un stub. 4 features sont désactivées par feature flag côté frontend alors que le backend est prêt. Le code mort (Studio, 93+ fichiers) alourdit inutilement la base de code.

Temps estimé pour atteindre le production-ready : 3-4 semaines avec 2 développeurs seniors.

Point de vue investisseur

Peut-on investir dans ce produit ?

Oui, avec réserves. Le socle technique est solide : stack moderne, architecture microservices, 150+ endpoints fonctionnels, auth mature, monitoring intégré. Le produit couvre un large périmètre fonctionnel (audio, marketplace, social, chat, analytics). La dette technique est significative mais traitable. Les vulnérabilités sont corrigeables rapidement.

Risques principaux :

1. Un seul développeur apparent (volume de code vs qualité homogène)
2. Feature scope très ambitieux pour une phase pré-production
3. Services Rust avec des TODOs critiques non résolus

Point de vue acquéreur

Peut-on acheter ce produit ?

Avec décote. La valeur réside dans :

• L'architecture globale (Go + Rust + React, scalable)
• Le backend API mature (150+ endpoints, 92% coverage revendiqué)
• Le frontend riche (799 composants, i18n, a11y)

Facteurs de décote :

• ~150 fichiers de code mort à nettoyer
• Services Rust pas production-ready
• 3 vulnérabilités critiques
• Pas de revenus ni d'utilisateurs documentés
• Monorepo sans orchestration

Faut-il refactorer ou réécrire ?

Refactorer. La base est saine. Les problèmes sont des problèmes de nettoyage, pas de conception fondamentale. Le coût de réécriture serait prohibitif par rapport au coût de remédiation (~3-4 semaines vs ~6-12 mois).

---

9. PLAN D'ACTION PRIORISÉ

Phase 1 — Urgent (sécurité & stabilité) — 1-2 semaines

Action	Effort	Fichier(s)	Détail
Supprimer le bypass rate limiting via headers	S	rate_limiter.go:94-104	Retirer la vérification X-Test-Mode et X-E2E-Test. Utiliser uniquement les variables d'environnement.
Supprimer le bypass CSRF en dev	S	csrf.go:44-47	Retirer le bypass ou le gater derrière un flag explicite CSRF_DISABLED=true (jamais activé en prod).
Supprimer le bypass rôle en dev	S	auth.go:440-451	Idem, flag explicite ou suppression.
Corriger la comparaison CSRF timing-safe	S	csrf.go:122	Remplacer != par crypto/subtle.ConstantTimeCompare().
Supprimer le debug print	S	auth.go:88	Retirer fmt.Println("DEBUG: ...").
Corriger les numéros de migration dupliqués	S	020_*.sql, 050_*.sql	Renommer 020_rbac_and_profiles.sql → 021_rbac_and_profiles.sql, 050_legacy_chat.sql → 051_legacy_chat.sql.
Rendre INTERNAL_API_KEY obligatoire	S	compression.rs:536	Fail si non défini au lieu de warning.
Implémenter fail-secure pour account lockout	M	account_lockout_service.go:89-94	Fallback in-memory au lieu de fail-open quand Redis est down.
Implémenter fail-secure pour rate limiting chat	M	handler.rs:299	Idem, fallback in-memory.
Rejeter les mots de passe > 72 bytes	S	password_service.go:299-303	Retourner une erreur au lieu de tronquer silencieusement.
Ajouter Trivy au CD principal	M	.github/workflows/cd.yml	Scan avant push d'images.

Phase 2 — Stabilisation — 2-4 semaines

Action	Effort	Fichier(s)	Détail
Supprimer le code Studio mort	L	components/studio/ (93+ fichiers)	Supprimer ou déplacer dans une branche feature.
Supprimer les services mock-only	M	gamificationService.ts, projectService.ts, storageService.ts	Supprimer ou déplacer.
Migrer Modal → Dialog	M	Tous les imports de modal.tsx	Remplacer par Dialog partout.
Activer les feature flags prêts	M	config/features.ts	Activer HLS_STREAMING, PLAYLIST_SEARCH, ROLE_MANAGEMENT, PLAYLIST_RECOMMENDATIONS.
Implémenter les composants manquants ou supprimer les tests	L	19 fichiers exclus de vitest	Soit implémenter, soit nettoyer les tests orphelins.
Fixer les 7 tests skippés	M	Suites Vitest	Corriger les tests ou les supprimer si obsolètes.
Ajouter les migrations down	L	migrations/	Écrire les scripts de rollback pour chaque migration.
Découper router.go	M	router.go (1576 lignes)	Séparer en sous-fichiers par domaine (auth, tracks, playlists, etc.).
Compléter le repository pattern	M	internal/repositories/	Créer les repositories manquants (Track, Notification, Webhook, Role).
Nettoyer les modules Rust legacy	S	security_legacy.rs, auth.rs	Supprimer si inutilisés.
Résoudre les 100+ TODOs frontend	L	Frontend entier	Prioriser et traiter ou supprimer.

Phase 3 — Amélioration & refonte — 4-8 semaines

Action	Effort	Fichier(s)	Détail
Implémenter le pipeline d'encodage réel	XL	encoding_pool.rs	Remplacer le stub par un vrai pipeline FFmpeg/GStreamer.
Ajouter go.work ou un orchestrateur monorepo	L	Racine	Turborepo ou Nx pour orchestrer Go + Rust + React.
Remplacer go-clamd	M	go.mod	Fork ou alternative maintenue pour ClamAV.
Ajouter la signature d'images Docker	M	CD pipeline	Intégrer cosign dans le workflow de déploiement.
Générer des SBOM	M	CD pipeline	Supply chain security.
Filtrage SSRF sur les webhooks	M	webhook.go	Bloquer les URLs internes/privées dans les webhooks utilisateur.
Configurer les timeouts Rust	S	Chat/Stream servers	Rendre configurables via env les timeouts hardcodés.
Ajouter un distributed lock pour session refresh	M	auth.go:199-216	Redis lock pour éviter les race conditions.
Optimiser GetTrackStats()	S	Track service	4 requêtes → 1 requête avec jointures.
Audit de composants > 300 lignes	M	Frontend	Découper selon les règles projet.
Ajouter des indexes manquants	S	Migrations	tracks.file_id, tracks.cover_art_file_id, messages.attachment_file_id.

---

CONCLUSION STRATÉGIQUE

Le monorepo Veza représente un effort de développement considérable et architecturalement cohérent. Le choix de Go pour l'API, Rust pour les services temps réel, et React pour le frontend est pertinent pour une plateforme audio collaborative.

Le produit n'est pas un prototype — c'est une application fonctionnelle avec 150+ endpoints, 20+ features, une sécurité raisonnablement mature, et une infrastructure Docker/Kubernetes prête.

Cependant, le produit n'est pas production-ready. Trois vulnérabilités critiques exploitables par un attaquant non sophistiqué (simples headers HTTP ou misconfiguration d'environnement) doivent être corrigées en priorité absolue. Le pipeline d'encodage audio — qui est au coeur du produit — est un stub.

La dette technique est significative mais pas structurelle. Elle relève principalement de code mort (Studio fantôme), de features inachevées (gamification, encoding), et de bypasses de développement laissés actifs. Le coût de remédiation est estimé à 3-4 semaines pour la phase 1, 2-4 semaines pour la phase 2.

Recommandation finale : Investissement viable sous condition de remédiation des vulnérabilités critiques (Phase 1) avant tout déploiement utilisateur. Le socle technique justifie un refactoring plutôt qu'une réécriture.