veza/AUDIT_TECHNIQUE_2026-02-22.md

AUDIT TECHNIQUE — VEZA MONOREPO

Champ	Valeur
Date	2026-02-22
Auditeur	Claude 4.6 Opus (IA) — mandat due diligence
Version analysée	v0.402, main (HEAD+49 commits non poussés)
Périmètre	Backend Go, Chat Server Rust, Stream Server Rust, Frontend React, Infra Docker/CI
Méthodologie	Analyse statique du code source, 6 passes d'exploration
Classification	Confidentiel — Usage interne

---

EXECUTIVE SUMMARY

Verdict global

Veza est un projet ambitieux et structurellement bien pensé pour un effort solo/micro-équipe. L'architecture backend Go est la pièce la plus mature : séparation handler → service → repository, middleware stack complète, couverture de tests proche de 1:1. Le frontend React est extensif (~131K LOC source) avec un design system cohérent (SUMI), Storybook-driven development, et 288 stories.

Cependant, le projet n'est pas prêt pour la production. La vélocité affichée (345+ features, 12 releases en ~3 mois) masque une réalité : de nombreuses features sont partiellement implémentées (frontend mock, backend stub, ou flux E2E non connecté). Les services Rust compilent mais ne sont pas intégrés (gRPC = stub, boot mode = chat/stream OFF). L'infrastructure CI/CD contient des défauts critiques (pipeline CD non fonctionnel, secrets en clair, versions Go incohérentes).

Top 5 risques

#	Risque	Gravité
1	Pipeline CD non fonctionnel — Les conditions secrets.* dans les if GitHub Actions ne s'évaluent jamais. Les étapes push, sign, deploy ne s'exécutent pas.	CRITIQUE
2	Authentification HLS/WebSocket cassée — TokenStorage.getAccessToken() retourne toujours null (cookies httpOnly). Les clients HLS et WebSocket ne peuvent pas s'authentifier.	CRITIQUE
3	Redis sans mot de passe en production — docker-compose.prod.yml ne configure aucune authentification Redis.	ÉLEVÉ
4	Rate limiter en mémoire — Ne fonctionne pas en multi-instance. Brute force possible en prod scalée.	ÉLEVÉ
5	Services Rust non intégrés — Chat et Stream servers compilent mais tournent en "boot mode" (OFF). 21.5% des 600 features annoncées sont réellement fonctionnelles.	ÉLEVÉ

Top 5 forces

#	Force
1	Architecture backend Go exemplaire — Séparation claire des responsabilités, middleware stack complète (23 middlewares), ratio test/code 0.97:1
2	Sécurité auth solide — Tokens httpOnly, access token 5min, bcrypt cost 12, CSRF timing-safe, validation JWT stricte (iss/aud/exp/algo)
3	Design system cohérent — SUMI Design System v2.0, 882 lignes de tokens CSS, Storybook-first, 288 stories
4	Infrastructure de qualité — CI multi-pipeline, Dependabot, security scanning, Dockerfiles multi-stage, utilisateur non-root
5	Documentation extensive — 63 docs frontend, scope control par version, CHANGELOG structuré, FEATURE_STATUS tracé

Recommandation go/no-go

NO-GO pour production en l'état. Conditionnel à 4-6 semaines de stabilisation ciblée (voir Phase 1-2 du plan d'action). Le code est de qualité suffisante pour être corrigé, pas réécrit.

---

1️⃣ CARTOGRAPHIE GLOBALE

1.1 Stack réelle

Élément	Constaté dans le code
Go	1.24.0 (go.work), mais Dockerfile.production utilise 1.23-alpine — incohérence
Rust	Stable channel (rust-toolchain.toml), Edition 2021
Node.js	20 (CI workflows), npm 10.9.2 (packageManager)
React	18.2.0
Vite	7.1.5
TypeScript	5.3.3 (package.json) mais 5.9.3 (root devDependencies) — incohérence
Tailwind CSS	4.0.0 (CSS-first config)
Framework Go	Gin 1.11.0 (dernière stable, maintenu)
ORM Go	GORM 1.30.0 + lib/pq 1.10.9 (parameterized queries)
Framework Rust	Axum 0.8 (chat + stream), Tokio 1.35
SQLx	0.8 (Rust services)
PostgreSQL	16-alpine (dev/prod), 15-alpine (test/hybrid) — incohérence
Redis	7 (docker-compose), go-redis/v9 9.16.0
RabbitMQ	3-management-alpine
Auth	JWT HS256 via golang-jwt/jwt/v5, access 5min, refresh 14j, remember-me 30j
Paiement	Hyperswitch via @juspay-tech/hyper-js, SDK frontend uniquement, mode test
Streaming	HLS prévu mais désactivé (HLS_STREAMING=false), service stub
WebSocket	Gorilla (Go), Axum WS (Rust), native WebSocket API (frontend)
WebRTC	Code présent dans stream-server mais commenté/désactivé
CI/CD	GitHub Actions — 12 workflows
Containerisation	Docker multi-stage, images alpine, utilisateur non-root
Monitoring	Prometheus configuré, Grafana référencé, Sentry intégré, zap structured logging
Monorepo	Turborepo + npm workspaces + Go workspace

1.2 Organisation du monorepo

Répertoire	Rôle réel	Fichiers	LOC
veza-backend-api/	API REST Go — cœur fonctionnel du produit	671 .go	174,022
veza-chat-server/	Serveur chat Rust — compile, non intégré	78 .rs	~60,000*
veza-stream-server/	Serveur streaming Rust — compile, non intégré	113 .rs	~80,000*
apps/web/	Frontend React/Vite — interface utilisateur	1,837 .ts/.tsx	~206,000
veza-docs/	Site Docusaurus — squelette non alimenté	~20	~500
docs/	Documentation projet/versioning	332 .md	~15,000
scripts/	Scripts utilitaires (audit, migration, deploy)	85+	~5,000
.github/	CI/CD workflows + templates	12 workflows	~800
config/	Prometheus, métriques, SSL	5	~100
infra/	docker-compose lab	1	~50
make/	Makefile modulaire	11 .mk	~800
dev-environment/	Templates de services	~10	~400
fixtures/	Package npm vide	5	~50
packages/	Shared packages — vide	0	0

*LOC Rust estimée (total 352K inclut le code généré gRPC/protobuf)

Packages orphelins :

• packages/ — déclaré dans npm workspaces mais vide
• fixtures/ — package npm avec vitest.config.ts mais aucun test
• veza-docs/ — Docusaurus configuré mais non alimenté

Packages fantômes :

• veza-backend-api/internal/api/archive/api_manager.go — 789 lignes de code commenté/TODO, jamais importé
• dev-environment/templates/ — templates de génération de code non utilisés par un outil

Duplications cross-packages :

• JWT validation implémentée 3 fois (Go jwt_service.go, Rust chat jwt_manager.rs, Rust stream token_validator.rs)
• Configuration loading implémentée 3 fois avec des patterns différents
• gRPC protobuf généré dupliqué entre chat et stream servers

1.3 Dépendances critiques

Backend Go (44 dépendances directes)

Dépendance	Version	Statut	Risque
gin-gonic/gin	1.11.0	Maintenu activement	Faible
gorm.io/gorm	1.30.0	Maintenu activement	Faible
golang-jwt/jwt/v5	5.3.0	Maintenu	Faible
redis/go-redis/v9	9.16.0	Maintenu	Faible
gorilla/websocket	1.5.3	Archivé (décembre 2024)	MOYEN — migrer vers nhooyr.io/websocket
lib/pq	1.10.9	En maintenance minimale	Faible (GORM l'utilise via driver)
swaggo/swag	1.16.6	Maintenu	Faible
sony/gobreaker	1.0.0	Maintenu	Faible
getsentry/sentry-go	0.40.0	Maintenu	Faible
testcontainers-go	0.33.0	Maintenu	Faible

Frontend React (dépendances majeures)

Dépendance	Version	Statut	Risque
react	18.2.0	React 19 disponible — 1 majeure de retard	MOYEN
@tanstack/react-query	5.17.0	Maintenu	Faible
zustand	4.5.0	Maintenu	Faible
msw	2.11.2	Maintenu	Faible
dompurify	Utilisé via sanitize.ts	Maintenu	Faible
@juspay-tech/hyper-js	Hyperswitch SDK	Niche — petit écosystème	MOYEN

Rust (dépendances clés)

Dépendance	Version	Risque
axum	0.8	Faible — maintenu par Tokio
sqlx	0.8	Faible — maintenu
jsonwebtoken	10	Faible
tonic	0.11	Faible — gRPC bien maintenu
lapin	2.3	MOYEN — RabbitMQ Rust, communauté petite
symphonia	0.5	MOYEN — audio processing, niche

1.4 Schéma des flux

Auth flow

Browser → POST /api/v1/auth/register → AuthHandler → AuthService → GORM → PostgreSQL
       → POST /api/v1/auth/login → AuthHandler → PasswordService.VerifyPassword → bcrypt
       → Set-Cookie: access_token (httpOnly, 5min)
       → Set-Cookie: refresh_token (httpOnly, 14j)
       → POST /api/v1/auth/refresh → Cookie → JWTService.ValidateToken → TokenVersion check → New tokens
       → POST /api/v1/auth/oauth/:provider → OAuthService → Google/GitHub → JWT

SPOF : PostgreSQL (session lookup per request), Redis (CSRF tokens) Timeout : 30s request timeout (middleware), context propagation Retry : Pas de retry sur DB failure Race condition : Token version increment non transactionnel — deux refresh simultanés pourraient invalider l'un l'autre

Payment flow

Frontend → POST /api/v1/marketplace/checkout → MarketplaceHandler → HyperswitchService
         → Hyperswitch API → Create PaymentIntent → client_secret
         → Frontend → Hyperswitch SDK → Card form → Confirm payment
         → Hyperswitch → Webhook → POST /api/v1/webhooks/hyperswitch (?)
         → MarketplaceService → Update order status

SPOF : Hyperswitch API (externe) Risque critique : Le handler de webhook entrant Hyperswitch n'a pas été trouvé dans webhook_handlers.go (ce fichier ne gère que les webhooks sortants). La vérification de signature webhook est potentiellement absente. Timeout : Non vérifié pour les appels Hyperswitch Idempotence : Non vérifiée pour les webhooks de paiement

Chat flow (théorique — non intégré)

Frontend → WebSocket /ws → Chat Server (Rust/Axum) → JWT validation → Hub
         → Message → SQLx → PostgreSQL (chat DB séparée)
         → Broadcast → Connected clients

État actuel : Boot mode — chat server OFF. Frontend utilise MSW mocks.

Stream flow (théorique — non intégré)

Frontend → GET /stream/hls/:track_id/playlist.m3u8 → Stream Server (Rust/Axum)
         → JWT validation (cassée — token null) → HLS segments → Player

État actuel : Stream server OFF. HLS désactivé. Frontend fallback sur des URLs directes.

---

2️⃣ CE QUE LE PRODUIT PERMET RÉELLEMENT

2.1 Classification des features

✅ Fonctionnelles (flux complet front + back + DB)

1. Authentication — Register/Login/Logout avec JWT httpOnly cookies
2. 2FA TOTP — Activation, vérification, codes de récupération
3. OAuth — Google, GitHub (Discord/Spotify : code présent mais non fonctionnel)
4. Profils utilisateur — CRUD, avatar, banner, liens sociaux, profil privé
5. Upload audio — Validation magic bytes, ClamAV, métadonnées
6. CRUD Tracks — Création, édition, suppression, métadonnées enrichies (BPM, key, lyrics, tags)
7. Playlists — CRUD, collaboration, partage, recommandations
8. Dashboard — Vue d'ensemble utilisateur
9. Sessions — Liste, révocation
10. Settings — Profil, sécurité, notifications, préférences
11. Marketplace — Catalogue produits, panier, wishlist
12. Search — Recherche full-text avec pg_trgm, filtres
13. Social posts — CRUD, likes, commentaires (feed basique)
14. RBAC — Rôles utilisateur, middleware d'autorisation

⚠️ Partiellement implémentées

Feature	Backend	Frontend	Écart
Checkout Hyperswitch	Handler + Hyperswitch SDK	Formulaire paiement	Webhook entrant non trouvé, mode test uniquement
Promo codes	Migration 099-100, handler	Modal + cart integration	En cours (fichiers modifiés dans git status)
Notifications	Service + push web	Composants UI	Backend OK, frontend MSW pour certaines routes
Analytics	Handler + service (7% complet selon audit interne)	Dashboard composants	Données réelles partielles
Admin panel	Routes protégées	Pages admin	Fonctionnalités limitées
Webhooks	CRUD outbound	Developer UI	Pas de delivery engine visible
Gear/Inventory	Handler	Composants	Backend minimal
Live streaming	Handler	Composants	Backend stub
Trending	TrendingService	Feed explore	Algorithme basique

👻 Fantômes (déclarées mais absentes ou stub)

Feature	Déclarée dans	Réalité
HLS Streaming	FEATURE_STATUS ("operational")	HLS_STREAMING=false, stream server OFF, getHLSXhrSetup() retourne token null
WebRTC Audio Calls	CHANGELOG v0.303	Code commenté/désactivé dans stream-server
OAuth Discord/Spotify	FEATURE_STATUS ("operational")	Audit interne confirme : non implémentés
Chat temps réel	FEATURE_STATUS ("operational")	Chat server en boot mode (OFF), frontend MSW
gRPC inter-services	Architecture déclarée	Stub — protobuf généré mais endpoints non connectés

💀 Mortes (code présent, jamais appelé)

Code mort	Fichier	LOC
api_manager.go	internal/api/archive/api_manager.go	789
docs.go (Swagger généré)	internal/handlers/docs/docs.go	5,482
GenerateJWT dans PasswordService	internal/services/password_service.go:249	~20 (méthode sans iss/aud, potentiellement dangereuse si appelée)
TokenStorage.getAccessToken()	apps/web/src/services/tokenStorage.ts	~107 (tout le fichier est un no-op)
isTokenExpiringSoon()	apps/web/src/services/tokenRefresh.ts	~30 (retourne toujours true)
MOCK_PURCHASES	apps/web/src/services/commerceService.ts	~50 (données mock retournées en production)
requestRefund()	apps/web/src/services/commerceService.ts	~10 (no-op, retourne toujours {success: true})

🧪 Expérimentales abandonnées

Feature	Traces
Éducation/Gamification	Supprimés du code, mentionnés dans FEATURE_STATUS comme "permanently deleted"
veza-mobile	Mentionné dans FEATURE_STATUS comme abandonné
packages/design-system	Répertoire packages/ vide, design system migré dans apps/web/src/index.css

2.2 Incohérences produit/code

Source	Affirme	Réalité code
docs/FEATURE_STATUS.md	"19 features operational"	~14 véritablement fonctionnelles E2E, 5 partielles ou fantômes
docs/FEATURE_STATUS.md	"HLS_STREAMING = true, operational"	HLS_STREAMING=false, service OFF, auth cassée
docs/FEATURE_STATUS.md	"OAuth Discord + Spotify operational"	Audit interne confirme non implémentés
CHANGELOG.md v0.303	"WebRTC audio calls 1-to-1"	Code commenté dans stream-server
CHANGELOG.md v0.402	"Checkout Hyperswitch production-ready"	Mode test, webhook entrant non trouvé
Audit interne (103)	Score 32/100, 21.5% features done	FEATURE_STATUS liste 19 features "operational"
V0_101_RELEASE_SCOPE.md	"All services must be running together"	Boot mode = chat/stream/RabbitMQ/ClamAV OFF

---

3️⃣ VALIDATION FONCTIONNELLE

3.1 Couverture de tests

Service	Fichiers test	LOC test	LOC source	Ratio	Commentaire
Go backend	264	85,455	87,930	0.97:1	Excellent. Tests unitaires + intégration + sécurité
Rust chat	~28 modules	~5,000*	~55,000*	~0.09:1	Faible. Principalement des tests unitaires inline
Rust stream	~30 modules	~8,000*	~72,000*	~0.11:1	Faible. Tests de charge présents mais basiques
Frontend	274	58,816	130,976	0.45:1	Correct. Tests composants Vitest + Storybook tests
Stories	288	15,987	—	—	Bonne couverture Storybook

*Estimé à partir des 352K LOC Rust totales incluant le code généré

Tests E2E : Playwright configuré (5 configs : smoke, storybook, visual, main, patch). Scénarios E2E dans ci.yml avec docker-compose full stack.

Tests de sécurité : Présents dans Go (tests/security/authorization_test.go, injection_attack_test.go).

Mocks vs API réelle : 100% du frontend teste contre MSW. Aucun test frontend contre l'API réelle (sauf E2E).

3.2 Points de rupture identifiés

Scénario	Impact	Mitigation existante
Redis tombe	CSRF cassé → toutes les mutations échouent (503)	Aucune — Redis est SPOF pour CSRF en prod
10K tracks par utilisateur	Pagination cursor OK, mais pas de limite max documentée	Pagination offset + limit avec max configurable
Fichier audio 10GB	MaxUploadSize configurable, validation taille	Oui — configurable dans env
1000 WebSocket simultanées	Chat server non testé sous charge en intégration	Load testing basique dans stream server
Webhook Hyperswitch replay	Handler webhook entrant non trouvé	RISQUE — pas d'idempotence vérifiable
Token expiré mid-session	Proactive refresh toutes les 4 min + retry 401 avec queue	Robuste — bien implémenté
Migration partielle	Pas de transaction wrapping dans les migrations SQL	RISQUE — état DB incohérent possible
2 refresh simultanés	Token version increment non-atomic	RISQUE — race condition possible

---

4️⃣ REGISTRE DES VULNÉRABILITÉS

ID	Catégorie	Gravité	Fichier(s)	Description	Impact	Correctif	Effort
VEZA-SEC-001	A05 Misconfig	CRITIQUE	.github/workflows/cd.yml	Conditions secrets.* dans if GHA ne s'évaluent jamais → pipeline CD non fonctionnel	Aucun déploiement automatisé ne fonctionne	Utiliser vars.* ou étape de vérification séparée	S
VEZA-SEC-002	A07 Auth	CRITIQUE	apps/web/src/services/tokenStorage.ts, hlsService.ts, websocket.ts	getAccessToken() retourne null → HLS et WebSocket ne peuvent pas s'authentifier	Streaming non protégé ou non fonctionnel	Implémenter auth par cookie pour WS/HLS ou endpoint de stream token	M
VEZA-SEC-003	A05 Misconfig	CRITIQUE	docker-compose.hybrid.yml	network_mode: host + Grafana password admin par défaut	Infrastructure accessible depuis le réseau sans auth	Supprimer network_mode host, forcer mot de passe	S
VEZA-SEC-004	A05 Misconfig	ÉLEVÉ	docker-compose.prod.yml	Redis sans authentification en production	Cache compromis → session hijacking, data poisoning	Ajouter --requirepass et REDIS_PASSWORD	S
VEZA-SEC-005	A01 Access	ÉLEVÉ	docker-compose.prod.yml:217-220	Stream server manque JWT_SECRET en prod compose	Service accepte potentiellement des requêtes non authentifiées	Ajouter JWT_SECRET dans la config stream-server	S
VEZA-SEC-006	A04 Design	ÉLEVÉ	internal/middleware/ratelimit.go	Rate limiter in-memory → ne fonctionne pas multi-instance	Brute force multiplié par nombre d'instances	Migrer vers rate limiting Redis	M
VEZA-SEC-007	A02 Crypto	ÉLEVÉ	.github/workflows/ci.yml:248,287	Mot de passe de test E2E en clair dans le workflow	Credential leakage si repo public	Migrer vers GitHub Secrets	S
VEZA-SEC-008	A01 Access	MOYEN	internal/handlers/upload.go:308-326	GetUploadStatus — IDOR, pas de vérification d'ownership	Un utilisateur authentifié peut voir le statut de n'importe quel upload	Ajouter check upload.UserID == currentUserID	S
VEZA-SEC-009	A10 SSRF	MOYEN	internal/handlers/webhook_handlers.go:69	URL de webhook accepte tout schéma (file://, http://169.254.x.x)	SSRF via webhook delivery	Valider schéma (https only), bloquer IPs privées	S
VEZA-SEC-010	A08 Integrity	MOYEN	Non trouvé	Webhook entrant Hyperswitch — handler non identifié, vérification de signature incertaine	Webhooks de paiement potentiellement non vérifiés	Vérifier/implémenter vérification HMAC-SHA256	M
VEZA-SEC-011	A05 Misconfig	MOYEN	cmd/api/main.go:8	import _ "net/http/pprof" en production	Profiling endpoints accessibles si DefaultServeMux exposé	Conditionner import au mode dev	S
VEZA-SEC-012	A02 Crypto	MOYEN	internal/services/password_service.go:92-95	Reset tokens stockés en clair dans PostgreSQL	Si DB compromise, tous les tokens de reset actifs sont exposés	Stocker le hash SHA-256 du token	S
VEZA-SEC-013	A07 Auth	MOYEN	internal/middleware/auth.go:312-406	OptionalAuth ne vérifie pas la correspondance session/user	Session hijacking silencieux sur les routes optionnelles	Ajouter vérification session.UserID == tokenUserID	S
VEZA-SEC-014	A04 Design	MOYEN	internal/middleware/csrf.go:153	Un seul token CSRF par utilisateur → multi-onglet cassé	UX dégradée, utilisateurs forcés de rafraîchir	Implémenter pool de tokens ou token par session	M
VEZA-SEC-015	A05 Misconfig	MOYEN	docker-compose.staging.yml:64	JWT_SECRET=${STAGING_JWT_SECRET} sans check ? → peut être vide	Staging potentiellement sans validation JWT	Ajouter :?error message	S
VEZA-SEC-016	A01 Access	MOYEN	docker-compose.staging.yml	Ports backend/frontend exposés directement sans reverse proxy	Pas de TLS termination, pas de WAF	Ajouter HAProxy comme en prod	M
VEZA-SEC-017	A09 Logging	MOYEN	Multiples fichiers	15+ fmt.Printf dans le code production (upload_validator.go, router.go)	Bypass du logging structuré, potentielle fuite d'info	Remplacer par logger.Debug()	S
VEZA-SEC-018	A07 Auth	FAIBLE	apps/web/src/features/auth/store/authStore.ts:352	isAuthenticated persisté dans localStorage	XSS → bypass des guards UI (backend protège toujours)	Utiliser sessionStorage ou mémoire uniquement	S
VEZA-SEC-019	A02 Crypto	FAIBLE	internal/services/password_service.go:150	Coût bcrypt hardcodé 12 au lieu de la constante bcryptCost	Risque d'incohérence lors de maintenance	Utiliser la constante	S

---

5️⃣ DETTE TECHNIQUE

5.1 Registre de la dette

Cat.	Description	Fichier(s)	Impact	Effort
🔴	Pipeline CD non fonctionnel — secrets dans if conditions	.github/workflows/cd.yml	Pas de déploiement auto	S
🔴	Services Rust non intégrés — gRPC stub, boot mode	Chat/Stream servers	60% des features annoncées non disponibles	XL
🔴	Auth HLS/WebSocket cassée — tokenStorage retourne null	Frontend services	Streaming/chat non fonctionnels	M
🔴	Versions Go incohérentes — 1.24 (CI) vs 1.23 (Dockerfile)	CI + Dockerfile	Build divergence possible	S
🟠	Rate limiter in-memory — ne scale pas	ratelimit.go	Sécurité dégradée en multi-instance	M
🟠	Postgres version incohérente — 15 (test/hybrid) vs 16 (dev/prod)	docker-compose files	Tests passent sur mauvaise version	S
🟠	Code mort ~6,500+ LOC — api_manager, docs.go, tokenStorage, commerceService mocks	Multiple	Confusion, maintenance inutile	M
🟠	22 fichiers Go >500 lignes — track/handler.go (2,262), config.go (955)	Backend handlers	Complexité élevée, refactoring nécessaire	L
🟠	11 fichiers TS/TSX >500 lignes — interceptors.ts (1,203), trackApi.ts (869)	Frontend services	Complexité élevée	L
🟠	commerceService.ts retourne des mocks en prod — MOCK_PURCHASES, fake refund	commerceService.ts	Utilisateurs voient des fausses données	S
🟠	Migrations non transactionnelles — SQL brut sans BEGIN/COMMIT	migrations/*.sql	État DB incohérent si migration échoue	M
🟡	90+ usages de any dans le frontend (hors tests/generated)	Multiple .ts/.tsx	Perte de type safety	M
🟡	18 fichiers avec console.log en production	Frontend src/	Pollution console, pas de contrôle log level	S
🟡	15+ fmt.Printf dans le backend	upload_validator, router	Bypass structured logging	S
🟡	gin.Logger() + gin.Recovery() en double avec custom middleware	main.go + router.go	Double logging, double recovery	S
🟡	gorilla/websocket archivé	go.mod	Plus de patches sécurité	M
🟡	chat-server sqlx-data.json vide {}	sqlx-data.json	Builds offline impossibles	S
🟡	stream-server sqlx-data.json absent	—	Builds offline impossibles	S
⚪	APP_ENV comparaison case-sensitive — "Production" bypass	Multiple middleware	Risque théorique	S
⚪	Packages npm vides — packages/, fixtures/	Monorepo config	Confusion	S

5.2 Quantification

Métrique	Go Backend	Rust Chat	Rust Stream	Frontend	Total
LOC source	87,930	~55,000	~72,000	130,976	~346,000
LOC test	85,455	~5,000	~8,000	58,816	~157,000
LOC stories	—	—	—	15,987	15,987
Ratio test/code	0.97:1	~0.09:1	~0.11:1	0.45:1	0.45:1
Fichiers source	402	~50	~80	1,275	~1,807
Fichiers test	264	~28	~30	274	~596
TODO/FIXME/HACK	20	5	5	8	38
Fichiers >500 LOC	22	~10	~8	11	~51
Code mort estimé	~6,500	~2,000	~1,000	~3,500	~13,000
Dépendances directes	44	~25	~30	~45	~144

---

6️⃣ QUALITÉ ARCHITECTURALE

6.1 Monorepo

Critère	Évaluation
Outil	Turborepo — adapté, bien configuré
Build orchestration	turbo run build — parallélisable, pas de cache custom
Versioning	Unifié par release scope (v0.101 → v0.402) — correct
Dépendances internes	Aucune shared package (packages/ vide) — chaque service est indépendant
Workspace	npm workspaces (root) + Go workspace (go.work) — cohérent
Problème	Rust non intégré dans Turborepo — builds Rust gérés séparément via Makefile

6.2 Frontend React

Critère	Score
Structure	Feature-based (excellent) — features/*/pages/, features/*/components/, features/*/hooks/
State management	Zustand (client) + React Query (server) — pattern moderne et correct
Data fetching	React Query v5 avec invalidation, prefetching, optimistic updates
Routing	React Router 6 avec lazy loading, route guards, preloading
Design system	SUMI v2.0 — tokens CSS centralisés, composants shadcn/ui adaptés
TypeScript	Strict mode activé, noUncheckedIndexedAccess: true — rigoureux
Storybook	288 stories, decorators avec providers, MSW intégré — mature
Accessibilité	Audit A11Y documenté (A11Y_AUDIT.md), ARIA via shadcn/ui
MSW vs API	100% MSW pour composants/stories. API réelle uniquement en E2E
Problème	Interceptors.ts à 1,203 lignes — trop complexe, à découper

6.3 Backend Go

Critère	Score
Architecture	Clean architecture avec séparation claire : handler → service → repository
Error handling	Custom apperrors package, errors wrappées, codes d'erreur HTTP cohérents
Middleware stack	23 middlewares — complet et bien ordonné (CORS → Auth → CSRF → Handler)
Database	GORM + PostgreSQL, migrations numérotées, connection pooling via GORM
Concurrency	Graceful shutdown, context propagation, semaphore uploads
Configuration	Env vars validées au démarrage, production checks, secret masking
API versioning	/api/v1/ — consistant
OpenAPI	openapi.yaml (3,655 lignes) + Swagger UI (dev only)
Problème	track/handler.go à 2,262 lignes — urgent à découper

6.4 Services Rust

Critère	Évaluation
Chat server	Architecture hub-based, Tokio runtime, WebSocket handler complet
Stream server	Transcoding engine, HLS segmenter, sync audio
Compilation	Compilent sans erreur (selon audit interne)
Error handling	anyhow + thiserror, propagation via ?
Problème critique	Non intégrés au système — boot mode OFF, gRPC stub, pas de tests d'intégration cross-service
Problème	unwrap() en production : ~30 (chat), ~50 (stream) — certains dans des chemins critiques (rate_limiter, websocket handler)
Justification Go + Rust	Questionnable pour cette taille d'équipe. Le chat server pourrait être un service Go avec gorilla/websocket. Le stream server est le seul cas justifiable (transcoding audio, performance). Le coût de maintenance de 3 langages est disproportionné.

6.5 Base de données

Critère	Évaluation
Schéma	66 migrations backend, 10 chat, 2 stream — riche
Indexes	pg_trgm pour recherche fuzzy, composite indexes, performance indexes
Extensions	uuid-ossp, pg_trgm (migration 086)
FK constraints	Migration 930 ajoute les FK manquantes — correction tardive
Audit triggers	Migration 053, 910 — audit trail en DB
Problème	Numérotation gaps (001→010→020, 069→070, 087→088→089→...→099→100→101→102, 900→910→920→930→931) — difficile à suivre
Problème	Migration 100 fait 3 lignes (ALTER TABLE orders ADD COLUMN discount_amount...) — fragmentation excessive
Problème	Pas de consolidation des 66 migrations — temps de setup initial long
Redis	Cache, CSRF tokens, presence, trending, rate limiting (potentiel). Pas de TTL documenté systématiquement

6.6 Scorecard

Dimension	Score /10	Justification
Architecture	7/10	Séparation claire des responsabilités, patterns modernes (feature-based frontend, clean arch backend). Perd des points : services Rust non intégrés, interceptors.ts monolithique, 3 langages pour une petite équipe.
Maintenabilité	6/10	Code bien structuré mais 51 fichiers >500 LOC, 13K LOC de code mort, conventions parfois incohérentes (fmt.Printf vs logger). Documentation extensive mais parfois contradictoire.
Sécurité	5/10	Bonnes bases (httpOnly cookies, bcrypt 12, CSRF, CSP, HSTS, secret masking). Perd des points : IDOR upload, rate limiter mémoire, Redis sans auth prod, auth HLS/WS cassée, CD pipeline mort, pprof enabled.
Scalabilité	4/10	PostgreSQL single-instance, Redis SPOF, rate limiter mémoire, pas de load balancer config, WebSocket sticky sessions non gérées. Architecture permet le scaling théorique mais rien n'est configuré.
Testabilité	7/10	Ratio test/code Go excellent (0.97:1), frontend correct (0.45:1), Storybook mature (288 stories). Perd des points : Rust quasi non testé, 100% MSW (aucun test composant contre API réelle), tests E2E fragiles (docker-compose full stack).
Opérabilité	3/10	Pipeline CD non fonctionnel, staging incomplet (pas de chat/stream), Prometheus sans alerting, Grafana password admin, Redis sans auth. Perd beaucoup de points : impossible de déployer en production de manière fiable aujourd'hui.
Vélocité dev	6/10	Storybook-first, MSW handlers, bonne documentation. Un dev React serait productif en <1 semaine. Un dev Go en ~2 semaines. Un dev Rust en 3+ semaines (code complexe, non documenté inline).
Maturité produit	3/10	14 features véritablement fonctionnelles E2E sur 600 annoncées (2.3%). 83/190 Tier 0 selon audit interne (44%). Score interne 32/100. Écart significatif entre documentation et réalité.

---

7️⃣ INFRA & DEVOPS

7.1 Docker

Critère	Résultat
Dockerfiles	Multi-stage, alpine, non-root — bien fait
docker-compose	5 fichiers (dev, prod, staging, test, hybrid) — trop, créent de la confusion
Secrets	Env vars partout (pas de Docker secrets) — risque élevé en prod
Health checks	Backend et Redis — OK. Frontend, Prometheus, Grafana — absents
Volumes	Données persistées pour DB, Redis, RabbitMQ — OK
Réseau	Prod: subnet /16 (trop large). Hybrid: host mode (aucune isolation)
Images	ClamAV, Prometheus, Grafana en latest — non reproductible

7.2 CI/CD

Critère	Résultat
Pipeline CI	12 workflows — couverture large mais incohérent (Go 1.23 vs 1.24)
Tests en CI	Go tests + frontend tests + E2E — bonne couverture
Linting	ESLint frontend. Manque : go vet, gofmt, clippy en CI
Security scanning	Gitleaks uniquement. Manque : SAST (CodeQL), container scanning, DAST
Build	Docker build en CI — oui, mais utilise le mauvais Dockerfile (dev au lieu de prod)
Deployment	CD pipeline existe mais ne fonctionne pas (conditions secrets jamais vraies)
Environments	Dev/staging/prod séparés en théorie. Staging manque chat/stream servers
Secrets management	Hardcodés dans workflow files. Pas de vault.

7.3 Reproductibilité

Critère	Résultat
Build one-command	docker compose up pour dev — oui, fonctionnel
Onboarding	Pas de ONBOARDING.md dédié. .env.example existe. README basique
Versions lockées	rust-toolchain.toml (stable, pas de version), go.work (1.24), pas de .nvmrc
Lock files	go.sum ✅, Cargo.lock ✅, package-lock.json ✅

---

8️⃣ PERFORMANCE & SCALABILITÉ

Composant	Risque	Seuil estimé	Mitigation
PostgreSQL	N+1 queries (GORM), full table scans possibles	>10K req/min	Indexes pg_trgm, composite indexes présents
Redis	SPOF — CSRF, cache, presence, trending dépendent de Redis	Si Redis down : CSRF → 503, presence → stale, cache miss	Aucun fallback implémenté
Chat server	WebSocket concurrentes, broadcast fan-out	>1000 connexions	Hub-based architecture, mais non testé sous charge réelle
Stream server	Transcoding CPU-intensive, HLS segment serving	>100 streams simultanés	Semaphore pour limiter concurrence (bon)
File storage	Stockage local par défaut, S3 optionnel	>10TB	S3 service implémenté mais non configuré par défaut
API Gateway	Single instance, pas de load balancer configuré	>1000 req/s	HAProxy en prod compose mais config minimale

Scalabilité horizontale : Le backend Go est stateless (sessions en DB, CSRF en Redis) — scalable horizontalement SI rate limiter migré vers Redis. Les services Rust ont des connexions WebSocket qui nécessitent sticky sessions ou Redis pub/sub pour broadcasting multi-instance.

---

9️⃣ RISQUES BUSINESS

9.1 Point de vue CTO

Question	Réponse
Recrutement productif <2 semaines ?	Oui pour React (Storybook-first, bonne doc, patterns standards). Oui pour Go (clean architecture, tests abondants). Non pour Rust (code complexe, non documenté, non intégré).
Vélocité soutenable ?	Non. 12 releases en ~3 mois avec 345+ features déclarées = ~3 features/jour. L'audit interne confirme que seules 21.5% sont réellement fonctionnelles. La vélocité est une vélocité de code, pas de produit.
Dette technique explosive ?	Oui si le rythme continue. 13K LOC de code mort, 51 fichiers >500 lignes, features fantômes documentées comme "operational". La divergence doc/réalité va s'aggraver.
Refactorings inévitables ?	1) Intégrer ou abandonner les services Rust. 2) Migrer rate limiter vers Redis. 3) Fixer le pipeline CD. 4) Consolider les migrations.
Go + Rust + React justifié ?	Partiellement. Go + React = justifié et bien exécuté. Rust stream server = justifiable (audio transcoding). Rust chat server = injustifié — un service Go avec gorilla/websocket ferait le même travail avec une maintenance unifiée.

9.2 Point de vue investisseur

Question	Réponse
Produit fonctionnel ou démo ?	Entre les deux. 14 features fonctionnelles E2E constituent un MVP viable (auth, upload, tracks, playlists, marketplace). Mais les features différenciantes (streaming HLS, chat temps réel, WebRTC) sont non fonctionnelles. C'est un CMS audio avec marketplace, pas une plateforme de streaming.
Risques sécurité publics ?	Oui. Redis sans auth en prod, IDOR sur uploads, pipeline CD mort, auth streaming cassée. Un audit de sécurité professionnel est nécessaire avant tout lancement.
Code repris par une autre équipe ?	Oui. Le code Go et React est propre, bien structuré, avec de bons tests. Le Rust est plus risqué (non intégré, peu documenté). Un onboarding de 3-4 semaines est réaliste pour une équipe de 3 devs (1 Go, 1 React, 1 Rust/infra).
Coût v1.0 production-ready ?	3-4 mois, 2-3 développeurs (estimation basée sur : fixer sécurité 2 semaines, stabiliser services Rust 4 semaines, fixer CD/infra 2 semaines, tests E2E complets 2 semaines, polish UX 2 semaines).
IP technique défendable ?	Limitée. Architecture standard (Go API + React SPA), pas d'algorithme propriétaire, pas de technologie unique. La valeur est dans l'exécution (qualité du code, design system SUMI, couverture tests) plutôt que dans l'innovation technique.
Ratio features/qualité ?	Red flag modéré. La quantité (345 features déclarées) masque la qualité (21.5% fonctionnelles). Mais les features qui fonctionnent sont bien implémentées avec des tests. C'est un problème de scope control, pas de compétence.

9.3 Point de vue acquéreur

Question	Réponse
Code réutilisable ?	Oui à 70%. Backend Go et frontend React sont réutilisables. Services Rust = à réévaluer (garder stream, réécrire chat en Go). Infra = à refaire proprement.
Données migrables ?	Oui. PostgreSQL standard, schéma normalisé, migrations numérotées. Export/import straightforward.
Vendor-lock ?	Faible. Hyperswitch (paiement) est un choix moins mainstream que Stripe mais l'interface est abstraite. Pas de lock cloud (S3 compatible).
Onboarding 5 devs ?	4-6 semaines. 2 semaines pour Go/React (bien documenté), 4 semaines pour Rust + infra (complexe, non documenté).
Score rachetabilité ?	6/10. Code propre et testable, architecture saine, stack mainstream. Perd des points : 3 langages, services non intégrés, écart doc/réalité, dette infra.

9.4 Verdict

Question	Réponse	Justification
Lancer en production tel quel ?	Non	CD pipeline mort, Redis sans auth, auth streaming cassée, features fantômes
Vendre / monétiser tel quel ?	Non	Checkout en mode test, webhook paiement non vérifié, features commerciales (streaming, chat) non fonctionnelles
Maintenir avec 2 devs ?	Conditionnel	Oui si on abandonne les services Rust et se concentre sur Go + React. Non si on veut tout maintenir.
Refactorer avant prod ?	Oui	Sécurité (2 semaines) + infra (2 semaines) + intégration services (4 semaines) minimum
Réécrire certains services ?	Oui	Chat server Rust → service Go. Le stream server Rust peut être conservé mais doit être intégré.
Vélocité = red flag ?	Oui, modéré	345 features déclarées en ~3 mois avec un écart de 78% entre déclaré et fonctionnel suggère une optimisation pour les métriques plutôt que pour la valeur produit. Mais le code qui existe est de qualité correcte — ce n'est pas du "feature stuffing" de basse qualité.

---

🔟 PLAN D'ACTION PRIORISÉ

Phase 1 — Critique (semaines 1-2) — Sécurité & CI/CD

#	Quoi	Pourquoi	Fichiers	Effort
1	Fixer pipeline CD — remplacer secrets.* par vars.* dans les if, utiliser Dockerfile.production, ajouter needs: ci	Aucun déploiement ne fonctionne	.github/workflows/cd.yml	S
2	Redis auth en production — ajouter --requirepass, configurer REDIS_PASSWORD	Cache/CSRF compromettable	docker-compose.prod.yml	S
3	Ajouter JWT_SECRET au stream-server prod compose	Service potentiellement sans auth	docker-compose.prod.yml:217	S
4	Supprimer docker-compose.hybrid.yml ou fixer network_mode	Infrastructure ouverte au réseau	docker-compose.hybrid.yml	S
5	Fixer auth HLS/WebSocket — implémenter cookie-based auth ou stream token endpoint	Streaming non protégé	hlsService.ts, websocket.ts, backend /auth/stream-token	M
6	Unifier version Go — 1.24 partout (go.mod, CI, Dockerfile)	Builds divergents	go.mod, ci.yml, backend-ci.yml, Dockerfile.production	S
7	Migrer secrets CI vers GitHub Secrets	Credentials en clair dans le repo	.github/workflows/ci.yml	S
8	Fixer IDOR GetUploadStatus — ajouter ownership check	Fuite d'information	internal/handlers/upload.go:308	S
9	Ajouter validation SSRF webhooks — whitelist schéma, bloquer IPs privées	SSRF via webhook delivery	webhook_handlers.go, webhook delivery service	S
10	Vérifier webhook Hyperswitch — signature HMAC-SHA256	Paiements potentiellement non vérifiés	Handler webhook paiement (à localiser/créer)	M

Phase 2 — Stabilisation (semaines 3-6)

#	Quoi	Pourquoi	Effort
11	Migrer rate limiter vers Redis	Sécurité multi-instance	M
12	Aligner Postgres 16 partout (test, hybrid)	Tests sur mauvaise version	S
13	Compléter staging compose (chat, stream, reverse proxy)	Staging ne reflète pas la prod	M
14	Ajouter alerting Prometheus (service down, error rate, latence)	Monitoring sans alerting = inutile	M
15	Supprimer code mort (~13K LOC)	Confusion, maintenance inutile	M
16	Supprimer/corriger commerceService mocks	Données factices en production	S
17	Ajouter go vet, clippy, gofmt en CI	Qualité code non vérifiée en CI	S
18	Remplacer fmt.Printf par logger structuré (15+ occurrences)	Fuite d'info, bypass logging	S
19	Ajouter SAST en CI (CodeQL ou Semgrep)	Vulnérabilités non détectées automatiquement	M
20	Fixer frontend-ci.yml — ajouter lint, typecheck, build	PRs frontend sans vérification	S

Phase 3 — Consolidation (semaines 7-12)

#	Quoi	Pourquoi	Effort
21	Intégrer ou abandonner le chat server Rust	Service non connecté, coût de maintenance	XL
22	Intégrer le stream server — connecter gRPC, activer HLS	Feature différenciante non fonctionnelle	XL
23	Découper fichiers >1000 LOC (track/handler.go, interceptors.ts, config.go)	Complexité maintenance	L
24	Consolider migrations — squash 66 migrations en baseline	Setup initial long	L
25	Éliminer 90+ any dans le frontend	Type safety dégradée	M
26	Remplacer gorilla/websocket (archivé)	Plus de patches sécurité	M
27	Ajouter tests d'intégration cross-service	Services jamais testés ensemble	L
28	Mettre en place Docker secrets pour la prod	Secrets dans env vars	M
29	Aligner FEATURE_STATUS avec la réalité	Écart doc/code = perte de confiance	S
30	Implémenter hash des reset tokens	Sécurité en cas de compromission DB	S

Phase 4 — Évolution (mois 4+)

• Activer Hyperswitch en mode production
• Implémenter payout (Stripe Connect — v0.403)
• Compléter analytics (7% → 50%+)
• Implémenter social (13% → 50%+)
• Évaluer migration React 19
• Considérer réécriture chat server en Go
• Mettre en place blue-green deployment
• Ajouter container image scanning en CI
• Implémenter IaC (Terraform/Pulumi)

---

ANNEXES

A. Arbre des dépendances inter-services

                    ┌──────────────┐
                    │   Frontend   │
                    │  React/Vite  │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
     ┌────────────┐  ┌──────────┐  ┌──────────┐
     │ Backend Go │  │Chat Rust │  │Stream    │
     │ (API REST) │  │(WebSocket│  │Rust (HLS)│
     └─────┬──────┘  └────┬─────┘  └────┬─────┘
           │              │              │
     ┌─────┼─────┐   ┌────┘         ┌───┘
     │     │     │   │              │
     ▼     ▼     ▼   ▼              ▼
  ┌────┐ ┌────┐ ┌─────┐    ┌───────────┐
  │ PG │ │Redis│ │Rabbit│   │ PG (chat) │
  └────┘ └────┘ └─────┘    └───────────┘

  Légende:
  ──── = Connexion fonctionnelle
  - - - = Connexion prévue mais non connectée (gRPC stub)

B. Métriques brutes

Total LOC (source + test + stories) : ~519,000
Total fichiers source : ~2,400
Total fichiers test : ~596
Total stories : 288
Total migrations SQL : 78
Total workflows CI : 12
Total scripts : 85+
Total docs markdown : 332
Total dépendances directes : ~144

C. Fichiers critiques à auditer en priorité

1. veza-backend-api/internal/middleware/auth.go (704 LOC)
2. veza-backend-api/internal/middleware/ratelimit.go (189 LOC)
3. veza-backend-api/internal/config/config.go (955 LOC)
4. apps/web/src/services/api/interceptors.ts (1,203 LOC)
5. apps/web/src/services/tokenStorage.ts (107 LOC)
6. .github/workflows/cd.yml (170 LOC)
7. docker-compose.prod.yml (301 LOC)
8. veza-backend-api/internal/handlers/upload.go (627 LOC)

---

CONCLUSION STRATÉGIQUE

Veza est un projet techniquement compétent dans son exécution Go/React, mais souffrant d'un excès d'ambition architecturale par rapport à ses ressources. Le choix de trois langages (Go, Rust, TypeScript) pour un MVP crée une charge de maintenance disproportionnée. Les services Rust, bien que compilables, ne sont pas intégrés au système et représentent ~132K LOC de code non productif.

La recommandation stratégique est : investir, mais avec recadrage.

Le code Go et React constitue une base solide et testée. La sécurité auth (httpOnly cookies, JWT 5min, bcrypt 12) est supérieure à la moyenne des startups early-stage. Le design system SUMI et l'approche Storybook-first démontrent une maturité UX réelle.

Cependant, l'écart entre le narratif (345+ features, 12 releases) et la réalité (14 features E2E, score interne 32/100) est un signal d'alarme pour un investisseur. Ce n'est pas un signe de mauvaise foi technique — le code qui existe est de qualité — mais d'un scope management déficient et d'une communication produit trop optimiste.

Avec 4-6 semaines de stabilisation ciblée et un recadrage stratégique (abandonner le chat Rust, intégrer le stream server, fixer l'infra), Veza peut devenir un MVP commercialisable. Sans ce recadrage, la dette technique et l'écart doc/réalité continueront de croître, rendant le produit de plus en plus difficile à maintenir et à vendre.

Verdict final : Investir sous condition de recadrage technique et produit dans les 60 jours.