veza/docs/archive/root-md/999_FULL_AUDIT_VEZA.md

AUDIT TECHNIQUE INTÉGRAL — MONOREPO VEZA

Date : 11 février 2026 Branche auditée : fix/audit-remediation (post-remédiation, 14 commits au-dessus de main) Auditeur : Audit indépendant — mandat comité d'investissement

---

EXECUTIVE SUMMARY

Veza est une plateforme audio collaborative (streaming, chat temps réel, marketplace) construite en monorepo avec un backend Go (Gin/GORM), deux services Rust (Axum pour chat WebSocket et streaming audio), et un frontend React (Vite/TypeScript/Tailwind).

Verdict global : Le produit est techniquement ambitieux et partiellement fonctionnel. Le backend Go est le composant le plus mature (sécurité solide, 80+ endpoints, JWT/CSRF/rate limiting). Les services Rust sont fonctionnels mais avec des dépendances retardataires. Le frontend est massif (971 composants, 791 fichiers features) mais contient 700+ erreurs TypeScript non résolues et 5 routes « fantômes » sans backend.

Une campagne de remédiation récente (14 commits) a significativement amélioré la posture de sécurité : authentification WebSocket du stream-server, rate limiting Redis du chat-server, durcissement des docker-compose de production, et nettoyage CI. Des vulnérabilités résiduelles subsistent dans les workflows secondaires et les dépendances Rust du stream-server.

Peut-on lancer en production ? Non sans réserve. Les 700+ erreurs TypeScript, les dépendances Rust retardataires, et les 3 || true résiduels dans la CI doivent être traités.

Peut-on maintenir ? Oui, avec un effort structuré. L'architecture est cohérente et le code est bien organisé.

Faut-il réécrire ? Non. Le code est refactorable sans réécriture.

---

1. CARTOGRAPHIE GLOBALE

1.1 Stack complète

Couche	Technologie	Version	Statut
Frontend	React + TypeScript	18.2 / 5.3	⚠️ 700+ erreurs TS
Build	Vite	7.1.5	✅ Actuel
Styles	Tailwind CSS	4.0.0	✅ Actuel
State	Zustand + TanStack Query	4.5 / 5.17	✅ Bon pattern
Backend API	Go + Gin + GORM	1.23.8 / 1.11 / 1.30	✅ Actuel
Chat	Rust + Axum + SQLx	0.8 / 0.7	⚠️ SQLx retardataire
Streaming	Rust + Axum + SQLx	0.8 / 0.7	⚠️ Plusieurs deps retardataires
Base de données	PostgreSQL	16	✅ Actuel
Cache	Redis	7	✅ Actuel
Queue	RabbitMQ	3	✅ Actuel
Proxy	HAProxy	2.8	✅ Actuel
CI/CD	GitHub Actions	v4/v5	⚠️ 3 || true résiduels
Conteneurs	Docker + Docker Compose	Multi-stage	✅ Propre
Orchestration	Kubernetes	Manifests présents	✅ External Secrets
Monitoring	Prometheus + Grafana + Sentry	Intégrés	✅ Fonctionnel

1.2 Organisation du monorepo

veza/
├── apps/web/               # Frontend React (971 composants, 791 fichiers features)
├── veza-backend-api/        # Backend Go (80+ endpoints, 31 migrations)
├── veza-chat-server/        # Service chat Rust (WebSocket, JWT, rate limiting)
├── veza-stream-server/      # Service streaming Rust (audio, HLS, WebRTC)
├── veza-common/             # Code partagé (non audité - scope limité)
├── veza-desktop/            # Application desktop (coquille vide)
├── veza-mobile/             # Application mobile (abandonné)
├── veza-docs/               # Documentation
├── .github/workflows/       # CI/CD (11 workflows)
├── docker-compose.*.yml     # 4 compose root + 2 par service + 3 infra
├── k8s/                     # Manifests Kubernetes (67 fichiers)
├── config/                  # Config infrastructure (43 fichiers)
├── migrations/              # Migrations SQL backend
└── scripts/                 # Scripts utilitaires

Outil monorepo : npm workspaces (pas Nx/Turborepo). Acceptable mais limité en fonctionnalités (pas de cache de build, pas de graph de dépendances).

1.3 Dépendances critiques

Dépendance	Service	Version actuelle	Dernière	Criticité
sqlx	chat + stream	0.7	0.8.x	⚠️ Élevée
redis	stream	0.25	0.32	⚠️ Élevée
bcrypt	stream	0.15	0.17	⚠️ Moyenne
thiserror	stream	1.0	2.0	⚠️ Moyenne
dashmap	stream	5.5	6.1	Faible

1.4 Schéma des flux

Browser → HAProxy (80/443)
  ├── /api/* → Backend Go (8080)
  │     ├── PostgreSQL (5432)
  │     ├── Redis (6379)
  │     └── RabbitMQ (5672)
  ├── /ws → Chat Server Rust (3000)
  │     ├── PostgreSQL
  │     ├── Redis
  │     └── RabbitMQ
  └── /stream → Stream Server Rust (3001/8082)
        ├── PostgreSQL
        ├── Redis
        └── Filesystem (audio)

---

2. CE QUE LE PRODUIT PERMET RÉELLEMENT

2.1 Features pleinement implémentées

Feature	Backend	Frontend	Tests	Production-ready
Authentification (email/pass)	✅	✅	✅	✅
OAuth (Google, GitHub)	✅	✅	Partiel	⚠️
2FA (TOTP)	✅	✅	✅	✅
Gestion utilisateurs (CRUD)	✅	✅	✅	✅
Upload/gestion tracks	✅	✅	✅	✅
Streaming audio (HLS)	✅	✅	Partiel	⚠️
Playlists (CRUD + collab)	✅	✅	✅	✅
Chat WebSocket temps réel	✅	✅	Partiel	⚠️
Social (follow, feed, posts)	✅	✅	Partiel	⚠️
Analytics	✅	✅	Faible	⚠️
Webhooks	✅	✅	Faible	⚠️
Admin dashboard	✅	✅	Partiel	⚠️

2.2 Features partiellement implémentées

Feature	Détail
Marketplace	Backend endpoints présents, frontend basique, flux paiement absent
Search	Backend search endpoint, frontend avec résultats partiels
Notifications	Backend + WebSocket, frontend affichage sans push natif
Role management (RBAC)	Backend complet, frontend admin basique

2.3 Features fantômes (frontend sans backend)

Route	Composant	Backend	Statut
/gear	LazyGear	❌ Aucun	Marqué PLANNED
/live	LazyLive	❌ Aucun	Marqué PLANNED
/education	LazyEducation	❌ MSW mock seulement	Marqué PLANNED
/queue	LazyQueue	❌ Aucun	Marqué PLANNED
/developer	LazyDeveloper	❌ Aucun	Marqué PLANNED

MSW handlers pour education et gamification sont annotés « GHOST FEATURE » dans apps/web/src/mocks/handlers.ts.

2.4 Features mortes / abandonnées

Élément	Localisation	Statut
veza-desktop/	Racine	Coquille vide, jamais développé
veza-mobile/	Racine	Abandonné
gamification	MSW handlers L.599	Mock uniquement, pas de backend
studio/	features/studio/	Cloud File Browser, UI seule
inventory/	features/inventory/	Gear/Inventory, UI + mocks

2.5 Incohérences produit/code

1. 5 routes protégées mènent à des features sans backend API
2. Gamification mockée complètement en MSW sans aucun endpoint backend
3. ContentFilter dans le chat-server (ligne 29, security/mod.rs) renvoie toujours true — filtre désactivé
4. 4 fichiers test legacy subsistent pour des services supprimés : src/services/__tests__/trackService.test.ts, src/services/__tests__/playlistService.test.ts, src/services/playlistService.test.ts, src/services/trackService.test.ts

---

3. VALIDATION FONCTIONNELLE

3.1 Flows critiques

Flow	Testabilité	Sécurité	Gestion erreurs	Verdict
Login / Register	✅ Tests présents	✅ Bcrypt + JWT + CSRF	✅ Structurée	Production-ready
Upload track	✅ Tests présents	✅ Auth + Rate limit	✅ Retry + progress	Production-ready
Streaming audio	Partiel	✅ JWT obligatoire (C2)	⚠️ Partielle	Nécessite tests E2E
Chat WebSocket	Partiel	✅ JWT + Rate limit (C5)	✅ Error messages	Nécessite tests charge
Payment/Marketplace	❌ Pas de tests	❌ Pas de flux paiement	❌ Non implémenté	Non production-ready

3.2 Couverture de tests

Service	Fichiers test	Couverture estimée	Qualité
Backend Go	~100+ _test.go	~70%	✅ Bonne (testcontainers)
Chat Rust	2 fichiers + modules	~30%	⚠️ Insuffisante
Stream Rust	Modules #[cfg(test)]	~20%	⚠️ Insuffisante
Frontend	~100 .test.ts(x)	~40%	⚠️ Tests fragiles

3.3 Points de rupture identifiés

1. 700+ erreurs TypeScript : le frontend ne passe pas tsc --noEmit (493 pré-existantes + 234 de noUncheckedIndexedAccess)
2. Stream-server SQLx runtime : les queries SQL ne sont plus validées au compile-time (migration C7 de query! vers query())
3. Chat-server ContentFilter : toujours true, aucun filtrage de contenu
4. Rate limiting désactivé en dev (Go backend + chat-server) — peut masquer des bugs
5. CSRF désactivé en dev (Go backend, csrf.go:44)

---

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

A01 — Broken Access Control

Élément	Gravité	Statut post-remédiation
Stream-server WebSocket sans auth	CRITIQUE	✅ CORRIGÉ (C2) — JWT obligatoire
user_id depuis query params	CRITIQUE	✅ CORRIGÉ (C2) — extrait des claims JWT
Routes admin protégées	N/A	✅ RequireAdmin() middleware
IDOR sur tracks/playlists	N/A	✅ RequireOwnershipOrAdmin() middleware
RBAC backend	N/A	✅ PermissionService implémenté

Gravité résiduelle : Faible. Les correctifs C2 ont éliminé la vulnérabilité critique.

A02 — Cryptographic Failures

Élément	Gravité	Détail
sslmode=disable en production	CRITIQUE	✅ CORRIGÉ (C4) — sslmode=require
JWT secret fallback faible	ÉLEVÉE	✅ CORRIGÉ (C4) — ${JWT_SECRET:?} obligatoire
DB password par défaut	ÉLEVÉE	✅ CORRIGÉ (C4) — ${DB_PASS:?} obligatoire
Hashing passwords	N/A	✅ Bcrypt (Go), Argon2 disponible (Rust)
JWT algorithm validation	N/A	✅ HS256 strict, rejette les autres
Token expiration	N/A	✅ Access 5min, Refresh 30j, versionné

Gravité résiduelle : Faible. Secrets dev dans .env (non tracké en git) — acceptable.

A03 — Injection

Élément	Gravité	Détail
SQL injection (Go)	N/A	✅ GORM paramétré, prepared statements
SQL injection (Rust)	N/A	✅ sqlx::query() avec .bind()
SQL injection testutils	FAIBLE	✅ CORRIGÉ (C14) — whitelist de tables
XSS frontend	N/A	✅ DOMPurify intégré (sanitize.ts)
Command injection	N/A	✅ Aucun exec() ou eval() trouvé

Gravité résiduelle : Négligeable.

A04 — Insecure Design

Élément	Gravité	Détail
Rate limiting chat absent	ÉLEVÉE	✅ CORRIGÉ (C5) — Redis + fallback mémoire
Rate limiting Go API	N/A	✅ Redis + Lua scripts, par IP et user
Rate limiting stream-server	MOYENNE	⚠️ NON CORRIGÉ — pas de rate limiting WebSocket
Validation serveur	N/A	✅ go-playground/validator, Zod côté client
ContentFilter stub	MOYENNE	⚠️ filter_content() retourne toujours true

Gravité résiduelle : Moyenne. Le stream-server manque de rate limiting WebSocket et le content filter est un stub.

A05 — Security Misconfiguration

Élément	Gravité	Détail
ALLOWED_ORIGINS=* stream	ÉLEVÉE	✅ CORRIGÉ (C3) — domaines explicites
CORS wildcard Go API	N/A	✅ Validation interdit * en production
HSTS	N/A	✅ Activé en production
CSP	N/A	✅ Strict pour API, relaxé pour Swagger
Debug en production	N/A	✅ Conditionné par APP_ENV
.env trackés	N/A	✅ Non trackés (vérifié via git ls-files)

Gravité résiduelle : Faible.

A06 — Vulnerable & Outdated Components

Composant	Version	Dernière	Gravité
sqlx (chat + stream)	0.7	0.8.x	ÉLEVÉE
redis (stream)	0.25	0.32	ÉLEVÉE
bcrypt (stream)	0.15	0.17	MOYENNE
thiserror (stream)	1.0	2.0	FAIBLE
dashmap (stream)	5.5	6.1	FAIBLE
jsonwebtoken (chat + stream)	10	10.3	✅ Actuel
Go deps	Actuelles	—	✅ Aucun retard
React/Vite/TS deps	Actuelles	—	✅ Aucun retard

Gravité résiduelle : Élevée pour les dépendances Rust du stream-server. Le chat-server est globalement à jour (jsonwebtoken 10 via C6).

A07 — Identification & Authentication Failures

Élément	Gravité	Détail
JWT validation	N/A	✅ Signature + expiration + issuer + audience
Token revocation	N/A	✅ Redis-backed, session revocation
Refresh token rotation	N/A	✅ Token families, anti-replay
Password reset	N/A	✅ Token unique, expiration courte
2FA (TOTP)	N/A	✅ Setup + verify + disable + status
Session management	N/A	✅ Cookie httpOnly + auto-refresh

Gravité résiduelle : Négligeable. L'authentification est la partie la plus solide du projet.

A08 — Software & Data Integrity Failures

Élément	Gravité	Détail
|| true dans CI	CRITIQUE	⚠️ PARTIELLEMENT CORRIGÉ — 3 instances résiduelles
continue-on-error	ÉLEVÉE	⚠️ 2 instances dans vulnerability-scan.yml
actions-rs/toolchain@v1	ÉLEVÉE	⚠️ 1 instance dans production-deploy.yml
Go version CI	ÉLEVÉE	⚠️ backend-ci.yml utilise encore Go 1.22
Input validation	N/A	✅ Zod (frontend) + validator (backend)
Build signatures	N/A	❌ Pas de signature de builds

Détail des || true résiduels :

• .github/workflows/cd.yml:47 — docker build ... || echo "..." (soft fail)
• .github/workflows/cd.yml:50 — idem pour stream-server
• veza-backend-api/.github/workflows/vulnerability-scan.yml:40 — govulncheck || true

Gravité résiduelle : Moyenne. Les workflows principaux (ci.yml) sont propres, mais 3 instances résiduelles dans les workflows secondaires.

A09 — Logging & Monitoring

Élément	Statut
Structured logging (Go)	✅ Logger configurable, niveaux
Structured logging (Rust)	✅ tracing crate avec spans
Audit trail	✅ audit_logs table, API access logging
Sentry error tracking	✅ Intégré (Go + frontend)
Prometheus metrics	✅ Intégré (Go + middleware)
Grafana dashboards	✅ Configurations présentes
Request correlation	✅ Request ID middleware (chat-server)

Gravité résiduelle : Négligeable. Le monitoring est bien implémenté.

A10 — SSRF

Élément	Gravité	Détail
Appels externes non filtrés	FAIBLE	Pas de fonctionnalité permettant à l'utilisateur de fournir des URLs pour des appels serveur. OAuth callbacks sont whitelistés.

Gravité résiduelle : Négligeable.

---

5. DETTE TECHNIQUE

5.1 Dette critique (bloquante)

ID	Description	Impact	Fichiers
D1	700+ erreurs TypeScript (493 pré-existantes + 234 noUncheckedIndexedAccess)	Impossible de valider les types en CI	apps/web/tsconfig.json, centaines de fichiers .tsx/.ts
D2	Dépendances Rust stream-server retardataires : sqlx 0.7, redis 0.25, bcrypt 0.15	Risque de vulnérabilités connues	veza-stream-server/Cargo.toml
D3	3 || true résiduels dans CI secondaire	Masque des échecs de build/audit	.github/workflows/cd.yml, vulnerability-scan.yml

5.2 Dette structurante

ID	Description	Impact
D4	ContentFilter stub dans chat-server — toujours true	Pas de modération de contenu
D5	5 routes fantômes sans backend	Confusion utilisateur, surface d'attaque inutile
D6	4 fichiers test legacy pour services supprimés	Tests échouent ou sont orphelins
D7	Pas de rate limiting sur stream-server WebSocket	Risque de DoS
D8	Couverture test insuffisante pour Rust services (~20-30%)	Régressions non détectées
D9	.unwrap() en production dans chat-server	Panics potentiels en production
D10	Code dupliqué dans JwtManager::new() et with_revocation_store_only()	Maintenance dupliquée
D11	veza-desktop/ et veza-mobile/ sont des coquilles vides polluant le monorepo	Confusion, surface de build inutile

5.3 Dette cosmétique

ID	Description
D12	npm workspaces sans Nx/Turborepo — pas de cache de build distribué
D13	Certains composants frontend > 300 lignes
D14	Services frontend src/services/ contient encore ~67 fichiers (certains ghost)
D15	Pas de lint Rust unifié (clippy pas dans tous les workflows)

---

6. QUALITÉ ARCHITECTURALE

6.1 Architecture

Go Backend : Clean architecture bien respectée. Séparation handlers → services → repositories → models. Middleware stack propre. Migrations SQL idempotentes.

Rust Services : Architecture Axum standard. AppState avec Arc pour shared ownership. WebSocket handlers bien structurés. Le chat-server a un pattern plus mature que le stream-server.

Frontend : Feature-based architecture avec features/, components/, stores/, services/. TanStack Query pour le data fetching, Zustand pour le state UI. MSW pour le mocking. Storybook pour les composants.

Monorepo : npm workspaces — fonctionnel mais basique. Pas de task orchestration (Nx, Turborepo), pas de cache distribué. Les services Rust et Go sont indépendants avec leurs propres build systems.

6.2 Scores

Critère	Score	Justification
Architecture	7/10	Clean architecture Go, feature-based frontend, services Rust cohérents. Pénalisé par le manque de tooling monorepo (Nx/Turborepo) et les coquilles vides (desktop/mobile).
Maintenabilité	5/10	700+ erreurs TS bloquent la validation de types. Tests insuffisants pour Rust. 67 services frontend dont certains ghost. Dépendances retardataires.
Sécurité	8/10	Post-remédiation significative : JWT auth sur WS, rate limiting, CORS fixé, docker-compose durci. Pénalisé par ContentFilter stub, 3 || true résiduels, pas de rate limit stream WS.
Scalabilité	7/10	Architecture microservices avec Redis/RabbitMQ pour la communication. HAProxy en proxy. K8s manifests avec autoscaling. Pénalisé par le manque de tests de charge et le rate limiting manquant sur stream-server.

---

7. INFRA & DEVOPS

7.1 Docker

Élément	Statut	Détail
Multi-stage builds	✅	Backend Go et Rust optimisés
Non-root user	✅	Stream-server utilise un user dédié
Health checks	✅	Configurés dans tous les compose
SQLX_OFFLINE	✅	Désactivé (C7 migration runtime)
Source maps prod	✅	sourcemap: 'hidden' (non exposées)

7.2 Docker Compose

Fichier	Statut	Remarques
docker-compose.prod.yml	✅	sslmode=require, secrets obligatoires
docker-compose.staging.yml	✅	sslmode=require, secrets obligatoires
docker-compose.yml (dev)	✅	Passwords dev acceptables
config/docker/README.md	✅	Documentation des fichiers compose
Fichiers production.yml	✅	Supprimés (C9)

7.3 Secrets & Environnement

Élément	Statut
.env trackés en git	✅ Non (vérifié)
.env.example présents	✅ Pour chaque service
.gitignore couvre .env	✅ Ligne 67
K8s External Secrets	✅ Vault/AWS/GCP stores configurés
Prod secrets hardcodés	✅ Aucun trouvé
Dev secrets hardcodés	⚠️ Présents dans docker-compose dev (acceptable)

7.4 CI/CD (11 workflows)

Workflow	|| true	Actions version	Statut
ci.yml	✅ 0	✅ v4/v5	✅ Propre
backend-ci.yml	✅ 0	⚠️ Go 1.22	⚠️ Go version
frontend-ci.yml	✅ 0	✅ v4	✅ Propre
chat-ci.yml	✅ 0	✅ dtolnay	✅ Propre
stream-ci.yml	✅ 0	✅ dtolnay	✅ Propre
cd.yml	⚠️ 2	✅ v4	⚠️ Soft fails
playwright.yml	✅ 0	✅ v4	✅ Propre
storybook-audit.yml	✅ 0	✅ v4	✅ Propre
test-coverage.yml	✅ 0	✅ v5	✅ Propre
vulnerability-scan.yml	⚠️ 1	⚠️ continue-on-error	⚠️ À revoir
production-deploy.yml	✅ 0	⚠️ actions-rs/toolchain@v1	⚠️ Déprécié

---

8. RISQUES BUSINESS

8.1 Perspective CTO

Forces :

• Architecture 3 services (Go + 2 Rust) est solide et scalable
• Sécurité post-remédiation est au-dessus de la moyenne
• Monitoring (Prometheus, Grafana, Sentry) est en place
• K8s manifests prêts avec External Secrets

Risques :

• 700+ erreurs TS = pas de confiance dans le typage frontend
• 5 routes fantômes = promesses non tenues dans l'UI
• Couverture test Rust ~25% = zone d'ombre significative
• Un développeur principal semble avoir construit tout → risque bus factor

Verdict : Lançable en beta fermée avec les routes fantômes désactivées et un focus sur les erreurs TS critiques. Pas prêt pour une GA ouverte.

8.2 Perspective Investisseur

Points positifs :

• Produit ambitieux et différencié (audio collab + social + marketplace)
• Backend Go mature et sécurisé
• Infrastructure K8s + monitoring prête
• 80+ endpoints = surface fonctionnelle réelle

Points négatifs :

• 5 features annoncées sans backend = dette produit
• veza-desktop et veza-mobile abandonnés = scope mal maîtrisé
• Gamification et éducation mockées = stratégie feature non exécutée
• Frontend fragile (700+ erreurs TS)

Verdict : Le produit démontre une compétence technique réelle mais un scope mal contrôlé. Investissable avec un plan de réduction scope strict et une roadmap réaliste.

8.3 Perspective Acquéreur

Valeur :

• Backend Go réutilisable tel quel
• Architecture sécurité (JWT, CSRF, rate limiting, RBAC) de qualité
• Infrastructure Docker/K8s prête
• 31 migrations SQL propres = schéma DB mature

Risques d'acquisition :

• Frontend nécessite 2-4 semaines de stabilisation TS
• Services Rust nécessitent mise à jour dépendances (1-2 semaines)
• Features fantômes à retirer ou implémenter
• Bus factor (un seul contributeur probable)

Verdict : Acquérable comme base technique. Valeur dans le backend et l'infra. Frontend et Rust à stabiliser post-acquisition. Ne pas valoriser les features fantômes.

---

9. PLAN D'ACTION PRIORISÉ

Phase 1 — Urgent : Sécurité & Stabilité (1-2 semaines)

Action	Effort	Fichiers	Criticité
Corriger les 3 || true résiduels dans CI	S	cd.yml, vulnerability-scan.yml	CRITIQUE
Remplacer actions-rs/toolchain@v1 dans production-deploy.yml	S	production-deploy.yml:25	ÉLEVÉE
Mettre Go 1.23 dans backend-ci.yml	S	backend-ci.yml:27	ÉLEVÉE
Mettre à jour sqlx, redis, bcrypt dans stream-server	M	veza-stream-server/Cargo.toml	ÉLEVÉE
Ajouter rate limiting WebSocket au stream-server	M	veza-stream-server/src/streaming/websocket.rs	ÉLEVÉE
Corriger .unwrap() en production dans chat-server	S	request_id.rs:36, prometheus_metrics.rs:357	MOYENNE

Phase 2 — Stabilisation (3-4 semaines)

Action	Effort	Détail
Résoudre les 493 erreurs TS pré-existantes	XL	Fichier par fichier, prioriser features/ et services/
Implémenter le ContentFilter dans chat-server	M	Remplacer le stub par un vrai filtre
Supprimer ou gate les 5 routes fantômes	S	routeConfig.tsx — feature flags ou suppression
Supprimer les 4 fichiers test legacy	S	services/__tests__/, services/*.test.ts
Augmenter couverture tests Rust à 50%+	L	Tests d'intégration pour WebSocket et streaming
Supprimer veza-desktop/ et veza-mobile/	S	Issues séparées, pas d'impact fonctionnel
Dédupliquer JwtManager::new() dans chat-server	S	Extraire setup commun

Phase 3 — Amélioration (6-8 semaines)

Action	Effort	Détail
Résoudre les 234 erreurs noUncheckedIndexedAccess	L	Progressive, optional chaining
Migrer npm workspaces vers Nx ou Turborepo	M	Cache de build, task graph
Ajouter signature de builds dans CI/CD	M	Cosign ou Sigstore
Implémenter les features fantômes ou les retirer	XL	Décision produit : gear, live, education, queue, developer
Tests de charge WebSocket (chat + stream)	L	k6 ou Artillery
Audit dépendances automatisé (Dependabot/Renovate)	S	Configuration repo
Migrer SQLx queries runtime vers offline mode	M	Générer .sqlx/ avec cargo sqlx prepare

---

CONCLUSION STRATÉGIQUE

Veza est un projet techniquement ambitieux avec une base solide mais un scope mal contrôlé. Le backend Go est de qualité production, les services Rust sont fonctionnels mais nécessitent une mise à jour, et le frontend est massif mais fragile.

La campagne de remédiation récente (14 commits) a éliminé les vulnérabilités critiques : authentification WebSocket, durcissement docker-compose, rate limiting, nettoyage CI. La posture de sécurité est passée d'un état préoccupant à un état acceptable.

Les risques principaux restants sont :

1. 700+ erreurs TypeScript — le frontend ne peut pas être validé statiquement
2. Dépendances Rust retardataires dans le stream-server
3. Features fantômes qui créent une dette produit
4. Bus factor probable (un seul contributeur)

Recommandation finale : Le projet mérite un investissement ciblé en stabilisation (Phase 1 + 2, ~5 semaines). Il ne nécessite pas de réécriture. Avec un scope produit réaliste et la résolution de la dette TypeScript, la plateforme peut atteindre un état de beta publique en 8-10 semaines.