veza/AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md

AUDIT TECHNIQUE INTÉGRAL — MONOREPO VEZA

Date : 15 février 2026 Auditeur : Architecte logiciel senior / Expert sécurité Mandataire : Comité d'investissement Périmètre : Monorepo complet — talas/veza Méthode : Analyse statique exhaustive du code source, des configurations et de l'infrastructure

---

EXECUTIVE SUMMARY

Veza est une plateforme audio collaborative (type Bandcamp/SoundCloud) avec marketplace, fonctionnalités sociales, chat temps réel et streaming audio. Le projet est techniquement ambitieux avec une stack polyglotte (Go, Rust, TypeScript/React).

Verdict

Critère	Score	Commentaire
Architecture	6/10	Bonne séparation des services, mais dual-patterns et pollution du repo
Maintenabilité	5/10	470K LOC, 137 fichiers .md à la racine, dette structurelle
Sécurité	6.5/10	Fondations solides, 3 vulnérabilités critiques à corriger
Scalabilité	7/10	Architecture microservices correcte, K8s prêt

Peut-on lancer en production ? Non, pas en l'état. 3 correctifs critiques requis (estimé 1-2 semaines). Peut-on vendre le produit ? Le produit a de la valeur fonctionnelle. Le code nécessite une stabilisation avant due diligence. Faut-il réécrire ? Non. Refactoring ciblé suffisant.

---

TABLE DES MATIÈRES

1. Cartographie globale
2. Ce que le produit permet réellement
3. Validation fonctionnelle
4. Audit de sécurité — OWASP TOP 10
5. Dette technique
6. Qualité architecturale
7. Infra & DevOps
8. Risques business
9. Plan d'action priorisé

---

1. CARTOGRAPHIE GLOBALE

1.1 Stack complète

Couche	Technologie	Version	Rôle
Frontend	React + TypeScript	18.2 / TS 5.3	SPA
Build	Vite	7.1.5	Bundler
State	Zustand + TanStack Query	4.5 / 5.17	UI state + server state
Forms	react-hook-form + Zod	7.49 / 3.25	Validation
Styling	Tailwind CSS	4.0	Styles
UI	Radix UI + Lucide	-	Composants
i18n	i18next	25.5	Internationalisation
Backend API	Go + Gin	Go 1.23.8 / Gin 1.11	REST API
ORM	GORM	1.30	Accès DB
Chat	Rust + Axum	Axum 0.8	WebSocket temps réel
Streaming	Rust + Axum	Axum 0.8	Audio HLS/WebRTC
Database	PostgreSQL	16	Persistance
Cache	Redis	7	Sessions, rate limiting, CSRF
Queue	RabbitMQ	3	Events async
Paiement	Hyperswitch	-	Checkout
Monitoring	Prometheus + Sentry	-	Métriques + erreurs
CI/CD	GitHub Actions	-	12 workflows
Orchestration	Kubernetes + Turborepo	-	Déploiement + monorepo
Error tracking	Sentry	10.32	Frontend + backend

1.2 Organisation du repo

veza/
├── apps/web/                    # Frontend React (≈200K LOC)
│   ├── src/
│   │   ├── features/            # 25 modules fonctionnels
│   │   ├── components/          # Composants partagés + views
│   │   ├── services/api/        # Couche HTTP (Axios)
│   │   ├── stores/              # Zustand stores
│   │   ├── hooks/               # 41 hooks custom
│   │   ├── mocks/               # MSW handlers (8 fichiers)
│   │   ├── locales/             # en.json, fr.json
│   │   └── router/              # React Router v6
│   └── e2e/                     # Playwright tests
├── veza-backend-api/            # Backend Go (≈150K LOC)
│   ├── cmd/api/                 # Entry point
│   ├── internal/
│   │   ├── handlers/            # 88 fichiers handlers
│   │   ├── middleware/          # 49 middlewares
│   │   ├── models/              # 52 modèles
│   │   ├── services/            # Services métier
│   │   └── config/              # Configuration (1461 LOC)
│   ├── migrations/              # 42 fichiers SQL
│   └── tests/                   # Tests spécialisés
├── veza-chat-server/            # Chat Rust (≈30K LOC)
│   └── src/                     # WebSocket + message store
├── veza-stream-server/          # Streaming Rust (≈50K LOC)
│   └── src/                     # HLS + WebRTC + audio processing
├── veza-common/                 # Bibliothèque Rust partagée
├── k8s/                         # Manifestes Kubernetes
├── .github/workflows/           # 12 pipelines CI/CD
├── config/                      # Prometheus, metrics
├── 137 fichiers .md à la racine # ⚠️ Pollution documentaire
└── 25 fichiers .json à la racine # ⚠️ TODOs, rapports, états

1.3 Dépendances critiques

Dépendance	Service	Risque	Statut
gin-gonic/gin v1.11	Backend	Faible	✅ À jour
gorm v1.30	Backend	Faible	✅ À jour
golang-jwt/jwt v5.3	Backend	Faible	✅ À jour
axum 0.8	Chat/Stream	Faible	✅ À jour
sqlx 0.8	Chat/Stream	Faible	✅ À jour
jsonwebtoken 10	Chat/Stream	Faible	✅ À jour
react 18.2	Frontend	Faible	✅ Stable
axios 1.13.5	Frontend	Moyen	⚠️ Vérifier CVE
vite 7.1.5	Frontend	Faible	✅ Dernier

1.4 Complexité globale

• 470 079 lignes de code source (Go + Rust + TypeScript)
• 4 langages de programmation en production
• 4 services distribués
• 42 migrations SQL
• 1 679 commits sur l'historique
• Couplage : Modéré — les services communiquent via HTTP/WebSocket/RabbitMQ
• Cohérence : Moyenne — dual-patterns dans le frontend (views vs features/pages)

---

2. CE QUE LE PRODUIT PERMET RÉELLEMENT

2.1 Features pleinement implémentées ✅

Feature	Backend	Frontend	Tests	MSW
Authentification (email/password)	✅	✅	✅	✅
2FA TOTP	✅	⚠️ Bug	✅	✅
OAuth	✅ Partiel	✅	-	✅
Sessions management	✅	✅	✅	✅
Upload de tracks (chunked)	✅	✅	✅	✅
CRUD tracks	✅	✅	✅	✅
Streaming HLS	✅	✅	✅	✅
Player audio	-	✅	✅	✅
Playlists (CRUD + collaboration)	✅	✅	✅	✅
Recherche	✅	✅	✅	✅
Profil utilisateur	✅	✅	✅	✅
Notifications	✅	✅	✅	✅
Chat temps réel	✅	✅	⚠️	✅
Marketplace (produits, panier, checkout)	✅	✅	✅	✅
Social (feed, posts, groupes)	✅	✅	✅	✅
Analytics	✅	✅	⚠️	✅
Admin dashboard (RBAC, audit)	✅	✅	✅	✅
Webhooks	✅	✅	✅	✅
Settings	✅	✅	✅	✅
Internationalisation (FR/EN)	-	✅	-	-
Library management	✅	✅	✅	✅

2.2 Features partiellement implémentées ⚠️

Feature	État	Détail
2FA Login	⚠️ Bug confirmé	TwoFactorVerify.tsx:47 — TODO: Fix this - twoFactorService.verify is for setup, not login verification
OAuth user lookup	⚠️ Non implémenté	database.go:559 — TODO: Implémenter OAuth user lookup
Live streaming	⚠️ Mocked	Routes backend existent, frontend mocké via MSW, intégration réelle non confirmée
Inventory/Gear	⚠️ Mocked	MSW handlers présents, backend partiel

2.3 Features fantômes (déclarées mais retirées) 👻

Feature	Preuve	Statut
Education/Tutorials	Routes backend existent (routes_education.go), handlers sans backend complet	Supprimée du frontend (commit 1cab7d5e)
Gamification (achievements, leaderboard)	MSW handlers existaient	Supprimée du frontend (commit 1cab7d5e)
Studio	Composants dans components/studio/	Supprimée des routes (commit 44829ea3)

2.4 Features mortes / Code mort

Élément	Localisation	État
cmd/modern-server/main.go	Backend	Serveur alternatif, code commenté
cmd/backup/main.go	Backend	Outil de backup, usage incertain
pages/ directory	Frontend	Répertoire legacy, doublon de features/*/pages/
components/education/	Frontend	Composants pour feature retirée
components/studio/	Frontend	Composants pour feature retirée
137 fichiers .md à la racine	Racine	53 833 lignes de documentation accumulée
25 fichiers .json à la racine	Racine	TODOs, rapports, états intermédiaires

2.5 Incohérences produit/code

1. Dual-pattern views : components/views/ ET features/*/pages/ servent le même objectif — architecture incohérente
2. Routes Education : Le backend expose des routes publiques pour les tutoriels, mais la feature est retirée du frontend
3. cmd/modern-server : Doublon du point d'entrée serveur avec du code commenté
4. Coverage reports : 72 fichiers .out dans le backend, non gitignorés

---

3. VALIDATION FONCTIONNELLE

3.1 Couverture de tests

Composant	Fichiers test	Type	Fiabilité
Frontend	269 fichiers	Unit + Component	Seuil 80% configuré
Backend Go	264 fichiers	Unit + Integration + Security + Performance	Bonne
Chat Rust	18 #[test]	Unit	Basique
Stream Rust	50+ #[test]	Unit	Correcte
E2E	30 specs	Playwright (4 browsers)	Correcte
Storybook	296 stories	Visual + Audit	Complète

3.2 Points de rupture identifiés

Scénario	Gravité	Détail
2FA login flow	Élevée	TwoFactorVerify.tsx appelle twoFactorService.verify (setup) au lieu de la vérification login
Redis indisponible	Moyenne	CSRF panic en prod si Redis down (routes_core.go:242)
OAuth callback	Moyenne	User lookup non implémenté (database.go:559)
.unwrap() en Rust	Élevée	100+ appels sans gestion d'erreur → crash service
Chat server sans DB	Faible	Dégradation gracieuse, mais logs avertissement

3.3 Zones non testées

• OAuth flow complet : Pas de tests d'intégration OAuth
• Payment webhook : Tests limités pour Hyperswitch callbacks
• WebRTC streaming : Logique complexe, tests unitaires seulement
• Audio processing pipeline : Tests basiques, pas de tests de performance audio
• Multi-tenant isolation : Pas de tests IDOR systématiques
• Migration rollback : Pas de tests de rollback SQL

3.4 Risques de production

1. Crash du stream server : 100+ .unwrap() dans du code Rust de production
2. CSRF inutilisable : Si Redis tombe, le backend Go panic au lieu de fallback gracieux
3. 2FA cassé : Le flow de login 2FA appelle le mauvais endpoint
4. HLS sans auth : Les segments audio HLS sont accessibles publiquement sans authentification

---

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

A01 — Broken Access Control

Constat	Gravité	Impact	Scénario d'exploitation	Correctif
HLS endpoints publics (/hls/:track_id/*) sur le stream server	Élevée	Accès non autorisé aux flux audio	Un attaquant qui connaît un track_id peut télécharger le contenu HLS sans authentification	Ajouter JWT ou validation par signature
Routes Education encore actives côté backend	Moyenne	Exposition de données fantômes	Les endpoints GET /api/v1/education/* sont publics et retournent des données	Supprimer les routes ou ajouter auth
POST /api/v1/validate sans auth	Faible	Abus de validation	Endpoint accessible sans limite significative	Ajouter rate limiting strict
GET /api/v1/status potentiellement informatif	Faible	Information disclosure	Exposition de métadonnées système	Restreindre ou filtrer les données exposées

Positif :

• RBAC correctement implémenté (RequireAdmin(), RequirePermission(), RequireOwnershipOrAdmin())
• Toutes les routes admin protégées
• WebSocket (Chat + Stream) requièrent JWT
• Frontend : ProtectedRoute appliqué systématiquement

A02 — Cryptographic Failures

Constat	Gravité	Impact	Scénario d'exploitation	Correctif
JWT secret faible dans .env dev	Moyenne	Si .env fuite en prod, tokens forgés	.env contient JWT_SECRET=dev-secret-key-minimum-32-characters-long-for-testing-only	✅ .env gitignoré. Validation de longueur min 32 chars en prod
Hardcoded test JWT secrets dans le chat server	Moyenne	Bypass auth si config test utilisée en prod	config.rs:216 contient des secrets de test hardcodés	Supprimer ou isoler dans des builds de test

Positif :

• Bcrypt cost 12 pour les mots de passe
• SHA-256 pour le hashing des tokens de session
• Access tokens : TTL 5 min (backend), 15 min (chat)
• Refresh tokens : TTL 30 jours avec rotation
• Token versioning pour révocation immédiate
• Cookies httpOnly pour les tokens
• CSRF protection avec tokens aléatoires de 32 bytes

A03 — Injection

Constat	Gravité	Impact	Scénario d'exploitation	Correctif
SQL injection dans message_store.rs	Élevée	Injection SQL via l'intervalle de cleanup	Utilisation de %s au lieu de $1	✅ Corrigé : make_interval(days => $1) + .bind() + validation 1-3650 jours
fmt.Sprintf avec noms de tables (test utils)	Faible	Test-only, whitelist appliquée	testutils/db.go:158 utilise fmt.Sprintf("DELETE FROM %s", table) mais validateTableName() est appelé	Conserver la whitelist, considérer les requêtes paramétrées

Positif :

• GORM utilisé systématiquement côté Go (requêtes paramétrées)
• sqlx avec $1/$2 côté Rust (requêtes paramétrées)
• Validation des inputs avec go-playground/validator
• Content filtering dans le chat (patterns XSS/SQL)
• Zod validation côté frontend

A04 — Insecure Design

Constat	Gravité	Impact	Correctif
Pas de validation serveur sur les données education	Faible	Handlers fantômes	Supprimer les routes
Download de tracks public sans auth	Moyenne	Contenu payant potentiellement accessible	Vérifier les droits avant download

Positif :

• Rate limiting multi-couche (IP, user, endpoint)
• Account lockout après tentatives échouées
• Input validation centralisée (BindAndValidateJSON() avec limite 10MB)
• File upload validation multi-couche (magic bytes, MIME, extension, taille, ClamAV optionnel)

A05 — Security Misconfiguration

Constat	Gravité	Impact	Scénario d'exploitation	Correctif
Bypass flags en développement	Moyenne	Si activés en prod, bypass de sécurité	BYPASS_CONTENT_CREATOR_ROLE=true et CSRF_DISABLED=true fonctionnent en dev/test	Ajouter une vérification explicite APP_ENV=production qui refuse ces flags
Swagger activé sauf en production	Faible	Exposition de la doc API	Swagger désactivé en prod (correct)	✅ Correct
CORS_ALLOWED_ORIGINS wildcards refusés en prod	N/A	N/A	✅ Validation en place	✅ Correct

Positif :

• Security headers implémentés (HSTS, CSP, X-Frame-Options)
• Config validation au démarrage (fail-fast)
• CORS strict en production
• .env fichiers dans .gitignore
• .env non trackés par Git (vérifié : git ls-files --cached)

A06 — Vulnerable & Outdated Components

Constat	Gravité	Correctif
Toutes les dépendances majeures sont à jour	N/A	✅
axios 1.13.5 — à vérifier pour CVE récentes	Faible	Lancer npm audit
cargo audit non exécuté régulièrement	Faible	Ajouter au CI

Positif :

• Dependabot configuré (.github/dependabot.yml)
• CI exécute govulncheck (Go), npm audit (frontend)
• Gitleaks pour la détection de secrets

A07 — Identification & Authentication Failures

Constat	Gravité	Impact	Scénario d'exploitation	Correctif
2FA login flow cassé	Élevée	Utilisateurs 2FA ne peuvent pas se connecter	Mauvais service	✅ Corrigé : commentaire trompeur fixé, MSW handler ajouté, erreur AuthViewContent affichée
OAuth user lookup non implémenté	Moyenne	OAuth probablement non fonctionnel	database.go:559 — TODO non résolu	Implémenter le lookup

Positif :

• Password policy : minimum 12 caractères, complexité requise
• Bcrypt cost 12
• Account lockout
• Token version checking (révocation immédiate)
• Refresh token rotation avec token family
• Session management avec détection de device

A08 — Software & Data Integrity Failures

Constat	Gravité	Correctif
CI/CD sécurisé	✅	Trivy scans, SBOM, cosign signing
Input validation	✅	Zod (frontend) + validator (backend)
Webhook signature verification	✅	Hyperswitch webhooks vérifiés

Positif :

• CD pipeline avec Trivy vulnerability scans
• SBOM generation
• Image signing avec cosign
• Post-deploy smoke tests

A09 — Logging & Monitoring Failures

Constat	Gravité	Correctif
Logging structuré	✅	Zap (Go), tracing (Rust), Sentry (Frontend)
Audit trail	✅	audit_logs table avec triggers
Secret filtering dans les logs	✅	WrapLoggerWithSecretFilter()
Prometheus metrics	✅	Collecte de métriques API

Positif :

• Logging structuré en JSON en production
• Rotation de logs configurée
• Filtrage de secrets dans les logs
• Audit trail complet en base de données
• Prometheus + Grafana pour le monitoring
• Loki + Promtail pour l'agrégation de logs

A10 — SSRF

Constat	Gravité	Correctif
OAuth callbacks	Faible	Callbacks vers des providers connus uniquement
Stream server → fichiers	Faible	Accès fichiers locaux seulement
Pas de fetch user-controlled URL	✅	Aucun pattern dangereux détecté

Positif : Pas de vecteur SSRF significatif identifié.

Résumé sécurité

Catégorie OWASP	Gravité max	État
A01 — Access Control	Élevée	⚠️ HLS public, routes fantômes
A02 — Crypto	Moyenne	⚠️ Secrets test hardcodés
A03 — Injection	Faible	✅ SQL injection chat server corrigée
A04 — Insecure Design	Moyenne	⚠️ Download public
A05 — Misconfiguration	Moyenne	⚠️ Bypass flags
A06 — Outdated Components	Faible	✅ Globalement à jour
A07 — Auth Failures	Moyenne	✅ 2FA login flow corrigé
A08 — Integrity	N/A	✅ CI/CD sécurisé
A09 — Logging	N/A	✅ Complet
A10 — SSRF	N/A	✅ RAS

---

5. DETTE TECHNIQUE

5.1 Dette critique (bloquante)

Problème	Localisation	Impact	Effort
100+ .unwrap() en prod Rust	veza-stream-server/, veza-chat-server/	Crash des services en production	L
panic() si Redis down	veza-backend-api/internal/api/routes_core.go:242	Backend crash si Redis indisponible	S
SQL injection potentielle	veza-chat-server/src/message_store.rs	Vulnérabilité de sécurité	✅ Corrigé
2FA login flow cassé	TwoFactorVerify.tsx	Feature inutilisable	✅ Corrigé
OAuth user lookup manquant	veza-backend-api/internal/database/database.go:559	OAuth non fonctionnel	M

5.2 Dette structurante

Problème	Localisation	Impact	Effort
Dual-pattern views/pages	components/views/ vs features/*/pages/	Confusion architecturale, duplication	L
Config Go monolithique	internal/config/config.go (1 461 LOC)	Maintenance difficile	M
137 fichiers .md à la racine	Racine du repo	Pollution, navigabilité nulle	M
25 fichiers .json à la racine	Racine du repo	TODOs/rapports accumulés	S
72 fichiers .out coverage	veza-backend-api/	Non gitignorés, pollution	S
Code mort : Education, Studio, Gamification	Backend routes + Frontend components	Code fantôme non nettoyé	M
Serveur alternatif	cmd/modern-server/main.go	Code commenté, doublon	S
pages/ directory legacy	apps/web/src/pages/	Doublon de features/*/pages/	M
Versions Tokio non alignées	veza-common (1.0) vs chat-server (1.35)	Conflits potentiels	S

5.3 Dette cosmétique

Problème	Localisation	Impact	Effort
72 TODOs/FIXMEs	Tous les services	Code inachevé documenté	Variable
Fichiers HTML à la racine	veza_design_system_v4.html, etc.	Pollution du repo	S
Fichiers de log committés	frontend.log, typecheck_output_*.txt	Bruit dans le repo	S
Répertoire chat_exports/	Racine	Données non pertinentes	S
Fichier gen_hash.py	Racine	Script utilitaire orphelin	S
Tests result files committés	apps/web/e2e-results.json, etc.	Artefacts de build	S

5.4 Métriques de dette

Indicateur	Valeur	Seuil acceptable	Verdict
Fichiers à la racine	162+	< 20	❌ Critique
LOC config Go	1 461	< 500	❌
.unwrap() en prod Rust	100+	0	❌
TODOs dans le code	72+	< 20	⚠️
Dual-patterns architecturaux	2	0	⚠️
Features fantômes	3	0	⚠️

---

6. QUALITÉ ARCHITECTURALE

6.1 Score d'architecture : 6/10

Positif :

• Séparation claire des services (API, Chat, Stream, Frontend)
• Communication inter-services via HTTP/WebSocket/RabbitMQ
• Shared library veza-common pour les types communs
• Feature-based architecture côté frontend
• Couche API clean avec interceptors (retry, CSRF, refresh)

Négatif :

• Dual-pattern components/views/ vs features/*/pages/ — incohérence architecturale
• pages/ directory legacy encore présent
• Config monolithique Go (1 461 lignes dans un seul fichier)
• 3 points d'entrée serveur (cmd/api/, cmd/modern-server/, cmd/backup/)
• Features fantômes (Education, Gamification, Studio) non nettoyées

6.2 Score de maintenabilité : 5/10

Positif :

• Tests unitaires conséquents (269 frontend, 264 backend)
• Storybook complet (296 stories)
• TypeScript strict
• Zod validation schemas
• OpenAPI spec (3 654 lignes)
• Internationalisation complète

Négatif :

• 470K LOC pour un MVP — surengineering probable
• 137 fichiers markdown accumulés à la racine
• Complexité cyclomatique élevée dans certains handlers
• Documentation technique dispersée et redondante
• Pas de documentation d'architecture (ADR, C4 model)
• Onboarding difficile pour un nouveau développeur

6.3 Score de sécurité : 6.5/10

Positif :

• Bcrypt cost 12, JWT avec rotation, CSRF, rate limiting multi-couche
• Security headers, CORS strict en prod
• Audit trail, secret filtering dans les logs
• CI avec govulncheck, npm audit, gitleaks, Trivy
• Session management avec hashing SHA-256

Négatif :

• 3 vulnérabilités de gravité élevée non corrigées
• .unwrap() → crashes en prod
• HLS endpoints publics
• 2FA login cassé
• Bypass flags non protégés contre activation en prod

6.4 Score de scalabilité : 7/10

Positif :

• Architecture microservices avec services dédiés
• Kubernetes ready avec HPA, VPA, cluster autoscaler
• PostgreSQL avec support read replicas
• Redis caching, connection pooling
• RabbitMQ pour l'event bus
• CDN support ajouté récemment
• Prometheus metrics pour l'auto-scaling

Négatif :

• Pas de sharding database
• Chat server : max 20 connexions DB (potentiellement limitant)
• Pas de circuit breaker entre services
• Pas de service mesh (Istio/Linkerd)

---

7. INFRA & DEVOPS

7.1 Docker

Aspect	État	Détail
Multi-stage builds	✅	Tous les Dockerfiles
Non-root user	✅	UID 1001 partout
Health checks	✅	Configurés dans tous les services
Image minimale	✅	Alpine Linux
Build optimisé	✅	-ldflags="-w -s", LTO en Rust
Secrets dans le build	✅	Pas de secrets dans les images

7.2 Kubernetes

Aspect	État	Détail
Deployments	✅	3 replicas par service
Network Policies	✅	Default deny
Secrets management	✅	External Secrets Operator
TLS	✅	cert-manager
HPA	✅	Auto-scaling configuré
Monitoring	✅	Prometheus + Grafana + Loki
Ingress	✅	Configuré

7.3 CI/CD

Aspect	État	Détail
Tests automatisés	✅	12 workflows
Security scanning	✅	Gitleaks, govulncheck, Trivy
Vulnerability scanning	✅	npm audit, cargo audit
Image signing	✅	cosign
SBOM	✅	Génération automatique
Deploy automation	✅	CD workflow avec smoke tests

7.4 Points d'attention

Problème	Gravité	Détail
.env fichiers locaux non committés	✅	Correctement gitignorés
Pas de cargo audit dans le CI chat/stream	Moyenne	Ajouter au workflow
docker-compose.yml expose des ports larges	Faible	Acceptable en dev
Pas de backup automatisé DB	Moyenne	cmd/backup/ existe mais usage incertain

7.5 Reproductibilité du setup

• docker-compose.yml : Setup local complet (PostgreSQL, Redis, RabbitMQ)
• .env.example : Template de configuration
• Makefile : Commandes de commodité
• go.work : Workspace Go
• rust-toolchain.toml : Version Rust fixée
• turbo.json : Orchestration monorepo

Verdict : Le setup est reproductible mais nécessite de la documentation (pas de GETTING_STARTED.md clair parmi les 137 fichiers markdown).

---

8. RISQUES BUSINESS

8.1 Point de vue CTO

Forces :

• Stack moderne et cohérente
• Tests conséquents
• CI/CD mature
• Sécurité globalement solide
• Architecture scalable

Faiblesses :

• 470K LOC pour un MVP — vélocité de développement compromise
• Onboarding estimé à 2-3 semaines pour un senior
• 4 langages = besoin de profils polyglots rares
• 137 fichiers de documentation non structurés
• Risque de regression élevé sans tests d'intégration E2E robustes

Recommandation CTO : Stabiliser avant de recruter. Nettoyer la dette cosmétique pour faciliter l'onboarding.

8.2 Point de vue Investisseur

Forces :

• Produit fonctionnellement riche (15+ features)
• Architecture technique sérieuse
• Sécurité au-dessus de la moyenne des startups
• Kubernetes-ready = scaling possible

Faiblesses :

• 3 vulnérabilités critiques non corrigées
• Complexité disproportionnée vs stade du produit
• Dépendance à des profils Go + Rust + React (recrutement coûteux)
• Pas de métriques produit (DAU, retention, conversion)
• Pas de tests de charge en conditions réelles

Recommandation Investisseur : Corriger les vulnérabilités critiques avant. Le risque technique est maîtrisable. Le risque est davantage dans la complexité opérationnelle.

8.3 Point de vue Acquéreur

Forces :

• Base de code structurée
• Pas de dette de sécurité majeure (après correctifs P0)
• Stack standard sans vendor lock-in
• OpenAPI spec existante

Faiblesses :

• Coût de maintenance élevé (4 langages, 4 services)
• Documentation technique inexploitable (137 fichiers non structurés)
• Pas de ADR (Architecture Decision Records)
• Difficile à intégrer dans un écosystème existant

Recommandation Acquéreur : Valoriser comme acquisition technologique. Prévoir 3-6 mois de stabilisation post-acquisition.

8.4 Réponses directes

Question	Réponse
Peut-on lancer en prod ?	Non, pas en l'état. 3 correctifs P0 requis (1-2 semaines). Après correctifs : oui, avec monitoring renforcé.
Peut-on le vendre ?	Oui, mais nécessite stabilisation et nettoyage documentaire pour due diligence.
Peut-on le maintenir ?	Oui, mais coût élevé. Nécessite 2-3 développeurs seniors polyglots.
Faut-il refactorer ?	Oui, refactoring ciblé sur : dual-patterns frontend, config monolithique, nettoyage code mort. Estimé 4-6 semaines.
Faut-il réécrire ?	Non. La base est solide. Refactoring suffisant.

---

9. PLAN D'ACTION PRIORISÉ

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

#	Action	Effort	Fichier(s)	Criticité
1.1	Corriger SQL injection dans le chat server	S	veza-chat-server/src/message_store.rs	✅ Fait
1.2	Corriger le flow 2FA login	S	TwoFactorVerify.tsx, AuthViewContent.tsx, handlers-auth.ts	✅ Fait
1.3	Ajouter auth sur les endpoints HLS	M	veza-stream-server/src/routes/api.rs	✅ Fait
1.4	Remplacer panic() par erreur gracieuse si Redis down	S	veza-backend-api/internal/api/routes_core.go:242	✅ Fait
1.5	Corriger les .unwrap() critiques en Rust (paths de production)	M	veza-stream-server/src/, veza-chat-server/src/	✅ Fait
1.6	Supprimer les secrets test hardcodés	S	veza-chat-server/src/config.rs:216, jwt_manager.rs:575	✅ Fait
1.7	Ajouter protection contre bypass flags en production	S	veza-backend-api/internal/middleware/auth.go, csrf.go	✅ Fait
1.8	Implémenter OAuth user lookup	M	veza-backend-api/internal/database/database.go:559	✅ Fait
1.9	Ajouter cargo audit au CI	S	.github/workflows/chat-ci.yml, stream-ci.yml	✅ Fait

Phase 2 — STABILISATION (4-6 semaines)

#	Action	Effort	Détail
2.1	Unifier components/views/ et features/*/pages/	L	✅ Fait — pattern unique features/*/pages/
2.2	Nettoyer les 137 fichiers .md à la racine	M	✅ Fait — archivés dans docs/archive/root-md/
2.3	Nettoyer les 25 fichiers .json à la racine	S	✅ Fait — archivés dans docs/archive/root-json/
2.4	Supprimer le code mort (Education, Studio, Gamification)	M	Backend routes + Frontend components
2.5	Supprimer cmd/modern-server/	S	Serveur alternatif inutile
2.6	Supprimer pages/ directory legacy	M	✅ Fait — migré vers features/*/pages/
2.7	Découper config.go (1 461 LOC)	M	Séparer par domaine (DB, JWT, CORS, etc.)
2.8	Gitignorer les fichiers .out, test results, .turbo/	S	Mettre à jour .gitignore
2.9	Aligner versions Tokio dans veza-common	S	1.0 → 1.35
2.10	Ajouter des tests d'intégration E2E pour les flows critiques	L	Auth, Upload, Purchase, Chat

Phase 3 — AMÉLIORATION & PRÉPARATION SCALE (6-12 semaines)

#	Action	Effort	Détail
3.1	Implémenter circuit breaker entre services	L	Résilience inter-services
3.2	Ajouter tests de charge	L	k6 ou Locust
3.3	Créer une documentation d'architecture (C4, ADR)	M	Pour onboarding et due diligence
3.4	Ajouter un GETTING_STARTED.md clair	S	Guide d'onboarding développeur
3.5	Mettre en place database sharding strategy	XL	Si > 100K utilisateurs
3.6	Considérer service mesh (Istio)	XL	Observabilité + sécurité réseau
3.7	Migrer React 18 → React 19	L	Quand stable
3.8	Ajouter WebAuthn comme alternative 2FA	M	Sécurité renforcée
3.9	Implémenter IDOR testing systématique	M	Tests de sécurité automatisés
3.10	Ajouter métriques produit (DAU, retention)	M	Pour les investisseurs

---

CONCLUSION STRATÉGIQUE

Ce qui est bien fait

1. Fondations sécurité solides : Bcrypt, JWT avec rotation, CSRF, rate limiting multi-couche, audit trail
2. Architecture microservices cohérente : Séparation claire des responsabilités
3. CI/CD mature : 12 workflows, vulnerability scanning, image signing
4. Testing conséquent : 569 fichiers de test, Storybook, E2E
5. Infrastructure production-ready : Kubernetes, monitoring, auto-scaling
6. Stack moderne : Pas de dette technologique sur les frameworks

Ce qui pose problème

1. 3 vulnérabilités critiques non corrigées avant mise en production
2. Complexité disproportionnée pour un MVP (470K LOC, 4 langages)
3. Pollution documentaire massive (137 .md, 25 .json à la racine)
4. Code mort non nettoyé (3 features fantômes, serveur alternatif)
5. Stabilité Rust fragile (100+ .unwrap() en production)
6. 2FA login cassé — feature critique non fonctionnelle

Verdict final

Le projet Veza possède une base technique de qualité supérieure à la moyenne des startups à ce stade. L'architecture est saine, la sécurité est prise au sérieux, et l'infrastructure est prête pour la production.

Cependant, le projet souffre d'une dette d'accumulation (documentation, code mort, artefacts) et de 3 vulnérabilités critiques qui doivent être corrigées avant tout déploiement en production.

Le plan de remédiation est estimé à 2-3 semaines pour les correctifs P0, 4-6 semaines pour la stabilisation, et 6-12 semaines pour l'amélioration. Ces délais sont raisonnables et ne nécessitent pas de réécriture.

Recommandation : Investissement viable sous condition de remédiation Phase 1 avant mise en production.

---

Rapport généré le 15 février 2026 Méthode : Analyse statique exhaustive du code source Périmètre : 470 079 lignes de code, 4 services, 1 679 commits