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.
**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.
- 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.
**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é.
-`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)
- 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()`
- 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.
| 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*
