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

Now I have a comprehensive picture. Let me compile the full audit report.

---

RAPPORT D'AUDIT TECHNIQUE INTÉGRAL — MONOREPO VEZA

Date : 14 Février 2026 Auditeur : Analyse technique indépendante Objet : Évaluation complète du monorepo Veza pour viabilité technique et investissement Classification : Confidentiel

---

EXECUTIVE SUMMARY

Veza est une plateforme audio collaborative de type SaaS (streaming, marketplace, social, chat temps réel) construite sur un monorepo polyglotte : React/TypeScript (frontend), Go/Gin (API backend), Rust/Axum (chat WebSocket + stream audio).

Taille du codebase : ~442 000 lignes de code

• Frontend : ~206 000 LoC (TypeScript/React)
• Backend Go : ~169 000 LoC
• Chat Server Rust : ~28 000 LoC
• Stream Server Rust : ~39 000 LoC

Verdict global : Le projet démontre une ambition architecturale significative et des pratiques de sécurité au-dessus de la moyenne. Cependant, il souffre de scope creep sévère, de features fantômes, d'une duplication architecturale sur le frontend, et d'un stream server qui ne compile pas. En l'état, il n'est pas prêt pour la production sans un travail de stabilisation de 6-8 semaines.

---

ÉTAT D'AVANCEMENT (mis à jour le 14/02/2026)

#	Action	Statut	Commit
1.1	SQL message_store.rs	Fait	-
1.2	Compilation stream server	Fait	-
1.3	Features fantômes	Fait	fix(web): disable ghost...
1.4	Rate limit logs/frontend	Fait	fix(api): add rate limiting...
1.5	Tests Go sans -short	Fait	ci(backend): run Go tests...
1.6	Gitleaks CI	Fait	ci: add gitleaks secret scanning
1.7	Rapports couverture	Fait	ci(backend): add coverage...

Phase 2 — Stabilisation

#	Action	Statut	Commit
2.1	Migration views → features	Fait	refactor(web): migrate views...
2.2	Auth consolidation	Fait	refactor(auth): consolidate...
2.3	i18n	Fait	feat(i18n): migrate hardcoded...
2.4	Tests Dashboard, Library, Analytics, Admin	Fait	test(web): add tests for...
2.5	Découper handlers.ts MSW	Fait	refactor(msw): split handlers...
2.6	Payment provider	Fait	Hyperswitch
2.7	Network Policies K8s	Fait	ci(k8s): add Network Policies
2.8	Resource limits HAProxy	Fait	fix(infra): add resource limits...
2.9	Nettoyage audit/remediation	Fait	chore(backend): archive audit...

---

1. CARTOGRAPHIE GLOBALE

Stack technique

Couche	Technologie	Version	Statut
Frontend	React + Vite + TypeScript	18.2 / 7.1 / 5.3	Opérationnel
CSS	Tailwind v4	4.0	Opérationnel
State	Zustand + TanStack Query	4.5 / 5.17	Opérationnel
Backend API	Go + Gin + GORM	1.23 / 1.11 / 1.30	Opérationnel
Chat Server	Rust + Axum + SQLx	2021 ed. / 0.8	Compile
Stream Server	Rust + Axum + Symphonia	2021 ed. / 0.8	Compile
Base de données	PostgreSQL 16	16-alpine	Opérationnel
Cache/Queues	Redis 7 + RabbitMQ 3	7-alpine / 3	Opérationnel
Reverse Proxy	HAProxy 2.8	2.8-alpine	Configuré
CI/CD	GitHub Actions	N/A	Partiel
Container	Docker multi-stage	N/A	Configuré
K8s	Kubernetes + External Secrets	N/A	Scaffoldé
Docs	Docusaurus 3.8	3.8.1	Scaffoldé
Tests	Vitest + Playwright + Storybook	3.2 / 1.58 / 8.6	Partiel

Organisation du repo

veza/
├── apps/web/                  # Frontend React (206K LoC)
├── veza-backend-api/          # Backend Go (169K LoC)
├── veza-chat-server/          # Chat WebSocket Rust (28K LoC)
├── veza-stream-server/        # Audio Streaming Rust (39K LoC)
├── veza-common/               # Shared Rust library
├── veza-docs/                 # Docusaurus (scaffoldé)
├── fixtures/                  # Test fixtures
├── config/                    # HAProxy, etc.
├── infra/                     # IaC configs
├── k8s/                       # Kubernetes manifests
├── scripts/                   # Build/deploy scripts
├── .github/workflows/         # 8 CI/CD workflows
└── make/                      # Modular Makefile system

Orchestration monorepo : npm workspaces uniquement. Pas de Turborepo, Nx, ou Lerna. C'est insuffisant pour un monorepo de cette taille avec 3 langages. Il n'y a aucune gestion de graphe de dépendances, aucun cache de build inter-services, aucune détection de changements ciblée.

Dépendances critiques

• Aucune dépendance obsolète majeure identifiée (React 18.2 est mineur, TypeScript 5.3 acceptable)
• Tokio version mismatch dans les crates Rust : veza-common utilise tokio = "1.0" tandis que les serveurs utilisent 1.35
• Aucune dépendance abandonnée détectée

Flux de données

Browser → HAProxy → Backend Go API → PostgreSQL
                  → Chat Server Rust (WebSocket) → PostgreSQL / Redis
                  → Stream Server Rust (Audio) → PostgreSQL / Redis
                  
Backend Go → Redis (sessions, cache, rate limiting, CSRF)
           → RabbitMQ (événements async)
           → ClamAV (antivirus upload, optionnel)

---

2. CE QUE LE PRODUIT PERMET RÉELLEMENT

Features VALIDÉES (backend + frontend connectés)

Feature	Backend	Frontend	Tests	Verdict
Auth (register, login, logout)	Go	React	Oui	Fonctionnel
JWT + httpOnly cookies	Go	React	Oui	Fonctionnel
2FA (TOTP)	Go	React	Oui	Fonctionnel
Password reset	Go	React	Oui	Fonctionnel
Email verification	Go	React	Oui	Fonctionnel
OAuth (Google, GitHub, Discord)	Go	React	Partiel	Fonctionnel
Session management	Go	React	Oui	Fonctionnel
RBAC (roles & permissions)	Go	React	Oui	Fonctionnel
User profiles	Go	React	Oui	Fonctionnel
Track CRUD	Go	React	Oui	Fonctionnel
Track upload (chunked)	Go	React	Oui	Fonctionnel
Playlist CRUD	Go	React	Oui	Fonctionnel
Search (tracks, playlists, users)	Go	React	Oui	Fonctionnel
Chat WebSocket temps réel	Rust	React	Partiel	Fonctionnel
Marketplace products	Go	React	Partiel	Fonctionnel
Cart & Checkout	Go	React	Partiel	Fonctionnel
Notifications	Go	React	Partiel	Fonctionnel
Admin dashboard	Go	React	Non	Partiel
Analytics	Go	React	Non	Partiel
Social feed/posts	Go	React	Non	Partiel

Features PARTIELLEMENT implémentées

Feature	Ce qui manque
HLS Audio Streaming	Stream server ne compile pas. Frontend prêt, backend Rust non validé
Webhooks	API CRUD existe, delivery system incomplet
Dashboard	Frontend avec données mockées uniquement (MSW)
Library	Frontend scaffoldé, logique métier partielle
File Manager	UI existe, pas de backend dédié
Discover	Données mockées, pas d'algorithme de recommandation

Features FANTÔMES (UI existe, aucun backend)

Feature	Fichiers	Verdict
Education	components/views/education-view/, MSW handlers lignes 600-630	Ghost feature — Cours, tutoriels, rien côté backend
Gamification	handlers-ghost.ts importé dans MSW	Ghost feature — Badges, achievements, 100% mock
Studio	components/views/studio-view/	Ghost feature — DAW-like, aucun backend
Live Streaming	components/views/live-view/	Partiellement ghost — UI complète, backend minimal

Features MORTES / Code non utilisé

• pages/auth/Login.tsx duplique features/auth/pages/LoginPage.tsx
• context/AuthContext.tsx coexiste avec features/auth/store/authStore.ts (deux sources de vérité)
• components/views/settings-view/ duplique features/settings/pages/
• components/views/upload-view/ duplique features/upload/
• dist_verification/ supprimé (git status montre 80+ fichiers deleted)

Incohérences produit/code

1. Deux patterns architecturaux coexistent : components/views/ (legacy) vs features/*/pages/ (nouveau) sans plan de migration clair
2. Education, Gamification, Studio sont routés et accessibles comme si fonctionnels, mais retournent des données fictives
3. Le stream server Rust ne build pas mais le frontend intègre un player HLS complet avec dashboard de monitoring
4. 303 stories Storybook pour la validation visuelle, mais le git status montre des modifications non commitées dans de nombreux fichiers critiques

---

3. VALIDATION FONCTIONNELLE

Flows critiques analysés

Auth flow : Validé

• Registration avec validation email, password strength check, username uniqueness
• Login avec rate limiting (5 tentatives / 15 min), account lockout (30 min)
• JWT access token (5 min TTL) + refresh token (30 jours) en httpOnly cookies
• CSRF protection avec timing-safe comparison
• Token versioning pour invalidation immédiate
• Tests : Oui (unitaires + intégration)

Upload flow : Validé

• Upload chunked avec validation multi-couche (magic bytes, MIME, extension, taille)
• Scan antivirus ClamAV (optionnel mais intégré)
• Rate limiting : 10 uploads/heure par utilisateur
• Tests : Oui

Chat flow : Partiellement validé

• WebSocket avec auth JWT avant upgrade
• Rate limiting par action (message, réaction, etc.)
• Permission checks (membership, read/write)
• Risque : SQL injection dans message_store.rs:179 (voir section sécurité)

Payment/Checkout : Non validé

• Cart + checkout UI existent
• Aucune intégration Stripe/payment provider trouvée dans le backend
• Flow critique non fonctionnel en production

Points de rupture identifiés

1. Stream server inopérant : cargo check en CI, pas de cargo build. Le TODO dans le CI confirme le problème : TODO(C7): fix stream-server compilation if this fails
2. Payments non intégrés : Le checkout UI existe mais ne peut rien traiter
3. Rate limiting désactivé en dev/test (lignes 99-109 de rate_limiter.go) — acceptable mais l'absence de tests de rate limiting en CI est un risque

Zones non testées

• Dashboard (0 tests)
• Library (0 tests)
• Analytics views (0 tests)
• Admin views (0 tests)
• Social feed (0 tests)
• Education (ghost feature, 0 tests)
• Gamification (ghost feature, 0 tests)
• Live view (0 tests)

---

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

A01 — Broken Access Control | Gravité : FAIBLE

Constats :

• Middleware RequireAuth() appliqué systématiquement sur les routes protégées
• RequireOwnershipOrAdmin() pour les opérations CRUD utilisateur
• RequireContentCreatorRole() pour la création de contenu
• CSRF sur toutes les opérations state-changing (POST, PUT, DELETE)
• Routes admin protégées par RequireAdmin()

Risque résiduel :

• POST /api/v1/logs/frontend est public sans rate limiting dédié — un attaquant pourrait flood les logs

Correctif : Ajouter un rate limiter sur l'endpoint de logging frontend.

A02 — Cryptographic Failures | Gravité : FAIBLE

Constats :

• Passwords : bcrypt avec DefaultCost (10 rounds)
• JWT : HS256 avec secret en variable d'environnement, validation issuer/audience
• Tokens httpOnly, Secure, SameSite=strict en production
• CSRF : crypto/rand + timing-safe comparison
• Aucun secret hardcodé trouvé dans le code

Risque résiduel :

• Refresh token TTL de 30 jours — long mais acceptable avec token versioning

A03 — Injection | Gravité : ÉLEVÉE → Corrigée

✅ Vulnérabilité corrigée dans veza-chat-server/src/message_store.rs (2026-02-15) :

• Requête paramétrée : make_interval(days => $1) avec .bind(older_than_days)
• Validation des entrées : older_than_days limité à 1-3650 jours
• Échappement COPY : backslash dans bulk_insert_messages pour content, message_type, metadata

Risque supplémentaire : Dynamic SQL dans message_repository.rs (lignes 387-515) utilise format!() avec des paramètres .bind(). Le pattern est sûr si les fragments dynamiques ne contiennent pas d'input utilisateur, mais c'est fragile.

Backend Go : Toutes les requêtes utilisent GORM (paramétrisé) ou $1/$2 placeholders. Aucune injection détectée.

Frontend : dangerouslySetInnerHTML utilisé dans le chat, mais toujours avec sanitizeChatMessage() (DOMPurify). Correctement implémenté.

A04 — Insecure Design | Gravité : MOYENNE

Constats :

• Rate limiting implémenté (Redis + in-memory fallback)
• Account lockout implémenté (5 tentatives)
• Input validation présente mais inconsistante — pas tous les DTOs utilisent des tags de validation
• Pas de rate limiting sur le frontend logging endpoint

Risque : Un attaquant peut envoyer des requêtes de logging en masse pour saturer le stockage de logs.

A05 — Security Misconfiguration | Gravité : MOYENNE

Constats :

• CORS validé en production (pas de wildcard)
• Security headers complets (HSTS, X-Frame-Options, CSP, etc.)
• Debug/stack traces désactivés en production
• CSRF_DISABLED ne peut être activé qu'en dev/test
• Rate limiting désactivé en dev/test via NODE_ENV/APP_ENV

Risque :

• Rate limiting bypass si APP_ENV=development est set en production par erreur — la validation de config devrait le prévenir mais ce n'est pas vérifié
• Le web container utilise VITE_API_URL=http://haproxy/api/v1 sans HTTPS dans docker-compose.prod.yml (les URLs internes sont HTTP, HTTPS est terminé au HAProxy)

A06 — Vulnerable & Outdated Components | Gravité : FAIBLE

Constats :

• CI exécute govulncheck, cargo audit, npm audit
• Versions des dépendances à jour
• Tokio mismatch dans veza-common (1.0 vs 1.35) — risque de compatibilité, pas de vulnérabilité

A07 — Identification & Authentication Failures | Gravité : FAIBLE

Constats :

• JWT validé avec algorithm check, issuer, audience, token version
• Token refresh avec rotation (vérification à la ligne 684) — contrairement au rapport initial, la rotation EST implémentée via s.refreshTokenService.Rotate()
• Sessions stockées en DB avec validation
• Password reset avec tokens expirables
• 2FA TOTP implémenté

A08 — Software & Data Integrity | Gravité : MOYENNE

Constats :

• CI/CD avec npm audit, govulncheck, cargo audit
• Trivy scan sur images Docker (CRITICAL/HIGH)
• SBOM generation (CycloneDX)
• Image signing optionnel (cosign)

Risque :

• Pas de secret scanning (gitleaks/trufflehog) dans le CI
• Go tests exécutés avec -short flag, excluant les tests nécessitant DB

A09 — Logging & Monitoring Failures | Gravité : FAIBLE

Constats :

• Structured logging (zap pour Go, tracing pour Rust)
• Prometheus metrics
• Sentry error tracking
• Audit trail (/api/v1/audit/logs)
• Secret filtering dans les logs (secret_filter.go)
• Request ID tracking

A10 — SSRF | Gravité : FAIBLE

Constats :

• File upload paths validés (ValidateExecPath, build_safe_path)
• Path traversal protection dans le stream server
• URL scheme validation dans le frontend (sanitizeURL)
• Pas d'appels HTTP sortants non filtrés identifiés

Tableau récapitulatif sécurité

OWASP	Gravité	Impact	Scénario
A01	Faible	Logging flood	POST /api/v1/logs/frontend sans rate limit
A02	Faible	-	Pratiques crypto solides
A03	Élevée	Data loss	SQL buggé dans message_store.rs (échoue, pas exploitable en l'état)
A04	Moyenne	DoS	Logging endpoint non rate limited
A05	Moyenne	Bypass	Rate limiting conditionnel sur env vars
A06	Faible	-	Dépendances à jour
A07	Faible	-	Auth robuste
A08	Moyenne	Supply chain	Pas de secret scanning
A09	Faible	-	Logging/monitoring solides
A10	Faible	-	Protections en place

---

5. DETTE TECHNIQUE

Dette CRITIQUE (bloquante)

#	Élément	Fichiers	Impact
D1	Stream server ne compile pas	veza-stream-server/src/*	39K LoC inutilisables, feature streaming inopérante
D2	Features fantômes accessibles en prod	Education, Gamification, Studio	Expérience utilisateur cassée, données fictives
D3	Pas de payment provider	Checkout flow complet sans backend	Feature marketplace non fonctionnelle
D4	SQL buggé dans chat	message_store.rs:179	Cleanup job échoue silencieusement

Dette STRUCTURANTE

#	Élément	Fichiers	Impact
D5	Double architecture frontend	components/views/* vs features/*/pages/*	Confusion, duplication, maintenance x2
D6	Pas d'orchestrateur monorepo	Racine	CI lent, builds non optimisés, pas de cache
D7	265 fichiers de test mais couverture inconnue	Tests frontend	Impossible de mesurer la qualité réelle
D8	261 fichiers test Go mais exécutés avec -short	Tests backend	Tests d'intégration non exécutés en CI
D9	i18n incomplet	~35+ fichiers avec strings hardcodées en anglais	Impossible de livrer une version FR complète
D10	Duplication auth	AuthContext.tsx + authStore.ts	Deux sources de vérité pour l'état auth
D11	MSW handlers : 1737 lignes	handlers.ts	Fichier monstre, difficile à maintenir
D12	TODOs non résolus	40+ dans le backend Go, 15+ dans le frontend	Travail incomplet accumulé

Dette COSMÉTIQUE

#	Élément	Impact
D13	React 18.2 au lieu de 18.3	Mineur
D14	TypeScript 5.3 au lieu de 5.7	Mineur
D15	Scripts bash avec eval	Risque faible, dev only
D16	Commentaires en français/anglais mixtes	Incohérence
D17	Nombreux fichiers markdown d'audit/remediation dans le backend	Pollution du repo

---

6. QUALITÉ ARCHITECTURALE

Score d'architecture : 6.5/10

Justification :

• (+) Séparation polyglotte intelligente (Go pour l'API, Rust pour le temps réel et le streaming)
• (+) Feature-based structure sur le frontend
• (+) Layered architecture sur le backend (handlers → services → repositories)
• (-) Deux patterns frontend coexistent sans migration
• (-) Pas d'orchestrateur monorepo (npm workspaces insuffisant)
• (-) Stream server non fonctionnel = 1/4 de l'architecture cassée
• (-) Features fantômes polluent le routing et l'UX

Score de maintenabilité : 5.5/10

Justification :

• (+) Code bien structuré dans chaque service individuellement
• (+) 303 stories Storybook (excellent pour la documentation visuelle)
• (+) 526 fichiers de test au total
• (-) 442K LoC pour une équipe visiblement petite = surcharge
• (-) Duplication architecturale frontend
• (-) Tests backend en mode -short en CI
• (-) Couverture de test inconnue (pas de rapport)
• (-) 40+ TODOs non résolus

Score de sécurité : 7.5/10

Justification :

• (+) httpOnly cookies pour JWT
• (+) CSRF avec timing-safe comparison
• (+) CORS validé en production
• (+) Rate limiting + account lockout
• (+) Security headers complets
• (+) Audit trail, secret filtering
• (+) File upload multi-layer validation + ClamAV
• (-) SQL bug dans le chat server
• (-) Pas de secret scanning en CI
• (-) Rate limiting bypassable via env var

Score de scalabilité : 6/10

Justification :

• (+) Architecture microservices avec message queue (RabbitMQ)
• (+) Redis pour cache et sessions
• (+) K8s manifests préparés
• (+) HAProxy comme reverse proxy
• (-) Stream server non fonctionnel
• (-) Pas de CDN configuré pour les assets audio
• (-) Pas de monitoring de performance applicative (APM) au-delà de Prometheus
• (-) PostgreSQL comme seul datastore (pas de séparation read/write)

---

7. INFRA & DEVOPS

Docker : 7/10

• Multi-stage builds pour tous les services
• Dockerfiles production dédiés
• Health checks sur tous les services
• Resource limits définis (sauf HAProxy)
• Network isolation

Problème : Le HAProxy n'a pas de resource limits dans docker-compose.prod.yml.

Kubernetes : 6/10

• Deployments avec runAsNonRoot, runAsUser: 1001
• External Secrets Operator avec Vault
• Health checks (readiness + liveness)
• Graceful shutdown configuré

Problèmes :

• Pas de deployment K8s pour le stream server
• Pas de Network Policies
• Pas de Pod Security Standards

CI/CD : 5.5/10

• 8 workflows GitHub Actions
• Security audits intégrés (govulncheck, cargo audit, npm audit)
• Trivy scanning sur les images Docker

Problèmes critiques :

• Stream server : cargo check seulement (pas de build)
• Go tests : -short flag = tests d'intégration ignorés
• Pas de secret scanning (gitleaks)
• Pas de smoke tests post-deployment
• Pas de coverage report
• Pas de gestion de branches sophistiquée (pas de staging branch)

Secrets : 8/10

• Variables d'environnement pour tout
• {VAR:?error message} dans docker-compose.prod.yml (fail-fast)
• External Secrets Operator pour K8s
• Secret rotation policies configurées
• Aucun secret hardcodé trouvé

---

8. RISQUES BUSINESS

Point de vue CTO

Peut-on lancer en production ?

Non, pas en l'état. Blockers :

1. Le stream server ne compile pas — fonctionnalité core (streaming audio) non opérationnelle
2. Le checkout n'a pas de payment provider — la marketplace ne peut pas générer de revenus
3. Les features fantômes (Education, Gamification, Studio) vont confondre les utilisateurs
4. Les tests d'intégration backend ne sont pas exécutés en CI

Estimation pour le go-live : 6-8 semaines de stabilisation avec une équipe de 2-3 développeurs.

Point de vue investisseur

Peut-on investir ?

Avec réserves. Points positifs :

• Architecture ambitieuse et cohérente dans sa vision
• Pratiques de sécurité au-dessus de la moyenne du marché
• Stack moderne et pertinente pour le domaine audio
• 442K LoC = travail significatif

Red flags :

• Scope creep évident (25+ features dont 4 fantômes)
• Un composant core (streaming) ne fonctionne pas
• Ratio features implémentées / features annoncées faible (~60%)
• Pas de métriques de couverture de test
• Maintenu par une équipe visiblement petite pour la complexité

Valorisation technique : Le code a de la valeur, mais l'écart entre ce qui est annoncé et ce qui fonctionne réellement est préoccupant. Un due diligence technique approfondi avec exécution des tests est recommandé.

Point de vue acquéreur

Peut-on acquérir et maintenir ?

Faisable mais coûteux. Le code est globalement bien écrit et bien structuré. La stack est moderne. Cependant :

• L'onboarding nécessite de comprendre 3 langages (TypeScript, Go, Rust)
• La dette architecturale frontend (double pattern) augmente le coût de maintenance
• Le stream server Rust nécessite un développeur Rust expérimenté pour le débloquer
• Les 17+ fichiers markdown de "remediation" et "audit" dans le backend suggèrent un historique de problèmes récurrents

Recommandation : Acquérir uniquement si l'acquéreur dispose de compétences Go + Rust. Prévoir 3-6 mois de stabilisation avant de pouvoir itérer sur de nouvelles features.

---

9. PLAN D'ACTION PRIORISÉ

Phase 1 — URGENT (sécurité & stabilité) — Semaines 1-2

#	Action	Effort	Impact
1.1	Fixer le SQL dans message_store.rs:179	S	Élimine bug critique
1.2	Fixer la compilation du stream server	L	Débloquer le streaming audio
1.3	Désactiver les routes des features fantômes en prod	S	UX cohérente
1.4	Ajouter rate limiting sur /api/v1/logs/frontend	S	Prévenir DoS logs
1.5	Exécuter les tests Go SANS -short en CI (ajouter DB test)	M	Couverture réelle
1.6	Ajouter secret scanning (gitleaks) au CI	S	Prévenir les fuites
1.7	Générer et publier les rapports de couverture de tests	S	Visibilité qualité

Phase 2 — STABILISATION — Semaines 3-6

#	Action	Effort	Impact
2.1	Migrer components/views/ vers features/ (éliminer la duplication)	XL	Maintenabilité +50%
2.2	Supprimer AuthContext.tsx, consolider sur authStore.ts	M	Source de vérité unique
2.3	Compléter l'i18n (migrer les 35+ fichiers avec strings hardcodées)	L	Prêt pour le marché FR
2.4	Ajouter tests pour Dashboard, Library, Analytics, Admin	L	Couverture des zones aveugles
2.5	Découper handlers.ts MSW (1737 lignes) en modules par feature	M	Maintenabilité
2.6	Intégrer un payment provider (Stripe) pour le checkout	XL	Marketplace fonctionnelle
2.7	Ajouter Network Policies K8s	M	Sécurité cluster
2.8	Ajouter resource limits HAProxy	S	Stabilité infra
2.9	Nettoyer les fichiers markdown d'audit/remediation du backend	S	Propreté repo

Phase 3 — AMÉLIORATION & REFONTE — Semaines 7-12

#	Action	Effort	Impact
3.1	Adopter Turborepo ou Nx pour l'orchestration monorepo	L	CI 3-5x plus rapide
3.2	Implémenter ou supprimer définitivement les features fantômes	XL	Produit cohérent
3.3	Configurer CDN pour assets audio	M	Performance streaming
3.4	Ajouter smoke tests post-deployment	M	Fiabilité déploiements
3.5	Implémenter request cancellation frontend (AbortController)	M	Prévenir memory leaks
3.6	Ajouter store migration strategy (Zustand)	M	Résilience client
3.7	Configurer read replicas PostgreSQL	L	Scalabilité
3.8	Résoudre tous les TODOs restants (55+)	L	Dette technique zéro

---

CONCLUSION STRATÉGIQUE

Veza est un projet techniquement ambitieux, bien architecturé dans sa vision, mais en état de surextension. Le ratio entre les fonctionnalités annoncées et celles réellement opérationnelles (~60%) révèle un scope creep classique. Le codebase est de qualité correcte à bonne, avec des pratiques de sécurité notablement supérieures à la moyenne (httpOnly cookies, CSRF timing-safe, ClamAV, secret filtering, RBAC multi-niveaux).

Les 3 risques majeurs sont :

1. Le stream server Rust (core feature) qui ne compile pas
2. Les features fantômes qui donnent une fausse impression de complétude
3. L'absence de payment provider pour une marketplace

La recommandation est de concentrer les efforts sur la Phase 1 (2 semaines) pour sécuriser et stabiliser, puis Phase 2 (4 semaines) pour rendre le produit commercialisable. La Phase 3 est un luxe qui peut attendre la preuve de marché.

Score global de maturité technique : 6/10 — Suffisant pour un MVP, insuffisant pour une mise en production commerciale sans stabilisation.

---

Fin du rapport d'audit technique — 14 Février 2026