Rapport d'audit technique intégral — Monorepo Veza
Date : 16 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 synthétique
| Critère |
Score |
Commentaire |
| Architecture |
6/10 |
Bonne séparation des services, dual-patterns frontend, pollution documentaire |
| Maintenabilité |
5/10 |
470K+ LOC, ~137 fichiers .md à la racine, dette structurelle |
| Sécurité |
6/10 |
Fondations solides, vulnérabilités npm, HLS public, bypass flags |
| Scalabilité |
7/10 |
Architecture microservices, K8s ready, HAProxy |
Peut-on lancer en production ? Non, pas en l'état. Correctifs critiques requis (1–2 semaines estimées).
Peut-on vendre le produit ? Le produit a de la valeur fonctionnelle. Stabilisation requise avant due diligence.
Faut-il réécrire ? Non. Refactoring ciblé suffisant.
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.24 (go.mod) / 1.23 (CI) |
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 |
| Database |
PostgreSQL |
16 |
Persistance |
| Cache |
Redis |
7 |
Sessions, rate limiting, CSRF |
| Queue |
RabbitMQ |
3 |
Events async |
| Paiement |
Hyperswitch |
2025.01.21 |
Checkout |
| Monitoring |
Prometheus + Sentry |
- |
Métriques + erreurs |
| CI/CD |
GitHub Actions |
- |
ci.yml, cd.yml |
| Orchestration |
Turborepo + Docker |
- |
Monorepo + déploiement |
1.2 Organisation du repo
veza/
├── apps/web/ # Frontend React (~200K LOC)
│ ├── src/features/ # 25 modules fonctionnels
│ ├── src/components/ # Composants partagés + views
│ ├── src/services/ # API client, socialService, etc.
│ ├── src/stores/ # Zustand stores
│ ├── src/mocks/ # MSW handlers
│ └── e2e/ # Playwright tests
├── veza-backend-api/ # Backend Go (~150K LOC)
│ ├── cmd/api/ # Entry point
│ ├── internal/handlers/ # ~88 handlers
│ ├── internal/middleware/ # Auth, rate limit, CSRF, RBAC
│ ├── internal/services/ # JWT, session, upload, webhook
│ ├── migrations/ # 42+ fichiers SQL
│ └── tests/ # Tests spécialisés
├── veza-chat-server/ # Chat Rust (Axum, WebSocket)
├── veza-stream-server/ # Streaming Rust (HLS, audio)
├── veza-common/ # Bibliothèque Rust partagée
├── .github/workflows/ # ci.yml, cd.yml (playwright.yml supprimé)
├── config/ # HAProxy, SSL
└── docker-compose*.yml # prod, dev, test, staging
1.3 Dépendances critiques et obsolètes
| 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 |
react 18.2 |
Frontend |
Faible |
✅ Stable |
axios 1.13.5 |
Frontend |
Moyen |
⚠️ Override >=1.13.5 (CVE) |
| cookie |
@lhci/cli → @sentry/node |
Moyen |
❌ <0.7.0 vulnérable |
| jose |
newman |
Modéré |
❌ 3.0–4.15.4 vulnérable |
| node-forge |
newman |
Élevé |
❌ <=1.3.1 vulnérable |
| qs |
postman-request |
Élevé |
❌ <6.14.1 DoS |
| lodash |
postman-collection |
Modéré |
❌ 4.0–4.17.21 prototype pollution |
Note : Les vulnérabilités npm concernent principalement des dépendances de dev (@lhci/cli, newman). Pas d’impact direct sur le runtime frontend si ces outils ne sont pas utilisés en production.
1.4 Schéma des flux
[Frontend] --HTTP/API--> [Backend Go] --GORM--> [PostgreSQL]
| | |
|--WebSocket--> [Chat Server Rust] --SQLx--> [PostgreSQL]
| |
|--WebSocket--> [Stream Server Rust] --SQLx--> [PostgreSQL]
| |
|--HLS--> [Stream Server] (segments audio)
|
+--[RabbitMQ]--> Workers (email, thumbnails, webhooks)
+--[Redis]--> Cache, sessions, rate limit, CSRF
1.5 Incohérences techniques
| Élément |
Constat |
Impact |
| Go version |
go.mod: 1.24.0, CI: 1.23 |
Risque de build différent selon l’environnement |
| Playwright workflow |
.github/workflows/playwright.yml supprimé |
E2E exécutés dans ci.yml uniquement |
| veza-common |
Référence ../veza-common (hors workspaces npm) |
Build Rust OK, dépendance path |
| RABBITMQ_URL vs AMQP_URL |
docker-compose.prod utilise AMQP_URL |
Cohérence à vérifier |
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 |
✅ |
✅ |
✅ |
✅ |
| Social (feed, posts, groupes) |
✅ |
✅ |
✅ |
✅ |
| Webhooks |
✅ |
✅ |
✅ |
✅ |
| Admin dashboard |
✅ |
✅ |
✅ |
✅ |
| Settings |
✅ |
✅ |
✅ |
✅ |
| Internationalisation (FR/EN) |
- |
✅ |
- |
- |
2.2 Features partiellement implémentées ⚠️
| Feature |
État |
Détail |
| 2FA Login |
⚠️ Bug |
TwoFactorVerify.tsx — possible mauvais endpoint/service |
| OAuth user lookup |
⚠️ Non implémenté |
database.go:559 — TODO non résolu |
| Live streaming |
⚠️ Mocked |
Routes backend existent, frontend mocké via MSW |
| Gear / Inventory |
⚠️ 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 |
Supprimée du frontend |
| Gamification |
MSW handlers existaient |
Supprimée du frontend |
| Studio |
Composants dans components/studio/ |
Supprimée des routes |
2.4 Features mortes / Code mort
| Élément |
Localisation |
État |
webhookApi.ts |
Frontend |
Supprimé — socialService.ts utilise apiClient directement |
cmd/modern-server/main.go |
Backend |
Serveur alternatif, code commenté |
cmd/backup/main.go |
Backend |
Outil de backup, usage incertain |
pages/ directory |
Frontend |
Legacy, doublon de features/*/pages/ |
components/education/, components/studio/ |
Frontend |
Composants pour features retirées |
2.5 Incohérences produit/code
- Dual-pattern views :
components/views/ ET features/*/pages/ — architecture incohérente
- Routes Education : Backend expose des routes publiques, feature retirée du frontend
- webhookApi.ts supprimé : Les webhooks restent fonctionnels via
socialService + apiClient
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 |
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 — possible mauvais service |
| Redis indisponible |
Moyenne |
CSRF panic en prod si Redis down (routes_core.go) |
| OAuth callback |
Moyenne |
User lookup non implémenté (database.go:559) |
~80+ .unwrap() / .expect() |
Élevée |
Stream server + Chat server — crash en prod |
| E2E auth tests |
Moyenne |
Git status : tests auth échoués (retry1, retry2) |
3.3 Zones non testées
- OAuth flow complet
- Payment webhook Hyperswitch
- WebRTC streaming
- Multi-tenant isolation / IDOR
- Migration rollback SQL
3.4 Risques de production
- Crash des services Rust : ~80+
.unwrap() / .expect() en production
- CSRF inutilisable : Si Redis tombe, le backend peut panic
- 2FA cassé : Flow de login 2FA possiblement incorrect
- HLS sans auth : Segments audio publiquement accessibles
4. Audit de sécurité — OWASP Top 10
A01 — Broken Access Control
| Constat |
Gravité |
Impact |
Scénario d'exploitation |
Correctif |
| HLS endpoints publics |
Élevée |
Accès non autorisé aux flux audio |
Connaissance d’un track_id → téléchargement HLS sans auth |
JWT ou validation par signature |
| Routes Education actives |
Moyenne |
Exposition de données fantômes |
GET /api/v1/education/* publics |
Supprimer ou ajouter auth |
POST /api/v1/validate sans auth |
Faible |
Abus de validation |
Endpoint accessible sans limite stricte |
Rate limiting strict |
Positif : RBAC (RequireAdmin(), RequirePermission()), routes admin protégées, WebSocket avec JWT.
A02 — Cryptographic Failures
| Constat |
Gravité |
Impact |
Correctif |
JWT secret dev dans .env |
Moyenne |
Si .env fuite en prod |
.env gitignoré, validation longueur min 32 chars en prod |
| Secrets test hardcodés (chat) |
Moyenne |
Bypass auth si config test en prod |
Isoler dans config de test |
Positif : Bcrypt cost 12, SHA-256 pour sessions, token versioning, cookies httpOnly, CSRF.
A03 — Injection
| Constat |
Gravité |
Correctif |
| GORM / sqlx paramétrés |
✅ |
Requêtes paramétrées |
fmt.Sprintf avec noms de tables (test utils) |
Faible |
Whitelist validateTableName() appliquée |
Positif : GORM, sqlx paramétrés, validation go-playground/validator, Zod frontend.
A04 — Insecure Design
| Constat |
Gravité |
Correctif |
| Download de tracks public |
Moyenne |
Vérifier droits avant download |
DISABLE_RATE_LIMIT_FOR_TESTS |
Moyenne |
CI E2E : DISABLE_RATE_LIMIT_FOR_TESTS=true — risque si activé en prod |
Positif : Rate limiting multi-couche, account lockout, validation centralisée, upload multi-couche.
A05 — Security Misconfiguration
| Constat |
Gravité |
Correctif |
| Bypass flags en dev |
Moyenne |
BYPASS_CONTENT_CREATOR_ROLE, CSRF_DISABLED — vérifier APP_ENV=production |
| Swagger |
Faible |
Désactivé en prod ✅ |
Positif : Security headers, config validation, CORS strict, .env gitignoré.
A06 — Vulnerable & Outdated Components
| Constat |
Gravité |
Correctif |
| npm audit |
Modéré |
cookie, jose, node-forge, qs, lodash (principalement dev deps) |
@lhci/cli, newman |
Dev |
Mettre à jour ou retirer si non utilisés |
| CI : govulncheck, npm audit, cargo audit |
✅ |
Présents |
A07 — Identification & Authentication Failures
| Constat |
Gravité |
Correctif |
| OAuth user lookup non implémenté |
Moyenne |
Implémenter le lookup |
| 2FA login flow |
Élevée |
Vérifier et corriger le flow |
Positif : Password policy, bcrypt cost 12, account lockout, token version, refresh rotation.
A08 — Software & Data Integrity Failures
| Constat |
Gravité |
Correctif |
| CI/CD |
✅ |
Trivy, SBOM, cosign signing |
| Input validation |
✅ |
Zod + validator |
| Webhook signature |
✅ |
Hyperswitch webhooks vérifiés |
A09 — Logging & Monitoring Failures
| Constat |
Gravité |
Correctif |
| Logging structuré |
✅ |
Zap (Go), tracing (Rust), Sentry |
| Audit trail |
✅ |
audit_logs table |
| Secret filtering |
✅ |
WrapLoggerWithSecretFilter() |
A10 — SSRF
| Constat |
Gravité |
Correctif |
| OAuth callbacks |
Faible |
Providers connus uniquement |
| Stream server → fichiers |
Faible |
Accès fichiers locaux seulement |
| Pas de fetch user-controlled URL |
✅ |
Aucun pattern dangereux |
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 |
✅ Protégé |
| A04 — Insecure Design |
Moyenne |
⚠️ Download public, rate limit bypass |
| A05 — Misconfiguration |
Moyenne |
⚠️ Bypass flags |
| A06 — Outdated Components |
Modéré |
⚠️ npm vulns (dev deps) |
| A07 — Auth Failures |
Élevée |
⚠️ 2FA, OAuth |
| 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 |
~80+ .unwrap() / .expect() |
veza-stream-server/, veza-chat-server/ |
Crash des services en production |
L |
panic() si Redis down |
routes_core.go |
Backend crash si Redis indisponible |
S |
| OAuth user lookup manquant |
database.go:559 |
OAuth non fonctionnel |
M |
| 2FA login flow |
TwoFactorVerify.tsx |
Feature inutilisable |
M |
5.2 Dette structurante
| Problème |
Localisation |
Impact |
Effort |
| Dual-pattern views/pages |
components/views/ vs features/*/pages/ |
Confusion architecturale |
L |
| ~137 fichiers .md à la racine |
Racine |
Pollution, navigabilité |
M |
| 25+ fichiers .json à la racine |
Racine |
TODOs, rapports accumulés |
S |
| Code mort : Education, Studio, Gamification |
Backend + Frontend |
Code fantôme |
M |
pages/ directory legacy |
apps/web/src/pages/ |
Doublon |
M |
| Go version mismatch |
go.mod vs CI |
Build incohérent |
S |
5.3 Dette cosmétique
| Problème |
Localisation |
Impact |
Effort |
| 72+ TODOs/FIXMEs |
Tous les services |
Code inachevé documenté |
Variable |
| Coverage reports |
*.out |
Non gitignorés |
S |
| Test results committés |
e2e-results.json, test-results/ |
Artefacts de build |
S |
6. Qualité architecturale
6.1 Score d'architecture : 6/10
Positif : Séparation des services, communication HTTP/WebSocket/RabbitMQ, veza-common, feature-based frontend.
Négatif : Dual-pattern views/pages, config Go monolithique, features fantômes, 3 points d’entrée serveur.
6.2 Score de maintenabilité : 5/10
Positif : Tests unitaires, Storybook, TypeScript strict, Zod, OpenAPI, i18n.
Négatif : 470K+ LOC, ~137 fichiers .md, documentation dispersée, onboarding difficile.
6.3 Score de sécurité : 6/10
Positif : Bcrypt cost 12, JWT rotation, CSRF, rate limiting, security headers, audit trail.
Négatif : Vulnérabilités npm, HLS public, .unwrap() en Rust, 2FA cassé, bypass flags.
6.4 Score de scalabilité : 7/10
Positif : Microservices, K8s ready, PostgreSQL read replicas, Redis, RabbitMQ.
Négatif : Pas de sharding, pas de circuit breaker, pas de service mesh.
7. Infra & DevOps
7.1 Docker
| Aspect |
État |
Détail |
| Multi-stage builds |
✅ |
Tous les Dockerfiles |
| Non-root user |
✅ |
UID 1001 |
| Health checks |
✅ |
Configurés |
| Image minimale |
✅ |
Alpine Linux |
| Secrets dans le build |
✅ |
Pas de secrets dans les images |
7.2 CI/CD
| Aspect |
État |
Détail |
| Backend Go |
✅ |
Vet, lint, test, build, govulncheck |
| Rust services |
✅ |
cargo audit, lint, build, test |
| Frontend |
✅ |
Lint, typecheck, test, build |
| E2E |
✅ |
Postgres, Redis, RabbitMQ, migrations, Playwright |
| CD |
✅ |
Trivy, SBOM, cosign, push registry |
| Playwright workflow |
❌ Supprimé |
E2E intégrés dans ci.yml |
7.3 Production
- docker-compose.prod.yml : Canonique
- HAProxy : HTTP→HTTPS, routing vers backend, chat, stream, web
- Secrets :
DB_PASS, RABBITMQ_PASS, JWT_SECRET requis
8. Risques business
8.1 CTO
- Peut-on lancer en prod ? Non. Corriger
.unwrap() Rust, 2FA, HLS auth, Redis panic.
- Peut-on maintenir ? Oui, avec effort. Dette structurelle et documentation à nettoyer.
- Faut-il refactorer ? Oui, ciblé. Dual-pattern views, config Go, code mort.
8.2 Investisseur
- Peut-on vendre le produit ? Le produit a de la valeur fonctionnelle. Stabilisation requise avant due diligence.
- Risques de réputation ? Vulnérabilités npm (dev deps), HLS public — à corriger avant communication publique.
8.3 Acquéreur
- Faut-il réécrire ? Non. Refactoring ciblé suffisant.
- Dette technique ? Élevée mais gérable. Plan de remédiation clair.
9. Plan d'action priorisé
Phase 1 — Urgent (sécurité & stabilité)
| Action |
Effort |
Priorité |
| Protéger les endpoints HLS (JWT ou signature) |
M |
P0 |
| Corriger le flow 2FA login |
S |
P0 |
| Fallback gracieux si Redis down (CSRF) |
S |
P0 |
Remplacer .unwrap() / .expect() critiques en Rust |
L |
P0 |
| Aligner Go version (go.mod / CI) |
S |
P1 |
Phase 2 — Stabilisation
| Action |
Effort |
Priorité |
| Implémenter OAuth user lookup |
M |
P1 |
| Supprimer les routes Education fantômes |
S |
P1 |
| Mettre à jour npm dev deps vulnérables |
S |
P1 |
| Protéger les bypass flags en prod |
S |
P1 |
| Corriger les tests E2E auth |
M |
P1 |
Phase 3 — Amélioration & refonte
| Action |
Effort |
Priorité |
| Unifier dual-pattern views/pages |
L |
P2 |
| Nettoyer code mort (Education, Studio, Gamification) |
M |
P2 |
| Réorganiser documentation (~137 .md) |
M |
P2 |
| Réduire .unwrap() restants en Rust |
L |
P2 |
| Découper config Go |
M |
P2 |
Conclusion stratégique
Le monorepo Veza est techniquement viable avec une architecture microservices cohérente et des bases de sécurité solides. Les principaux blocages sont :
- Sécurité : HLS public, 2FA cassé, bypass flags, vulnérabilités npm (dev deps),
.unwrap() en Rust.
- Stabilité : Panic Redis, crash des services Rust.
- Dette : Dual-pattern views, code mort, pollution documentaire.
Recommandation : Exécuter la Phase 1 (1–2 semaines) avant toute mise en production. Les Phases 2 et 3 peuvent être planifiées sur 2–4 semaines supplémentaires selon les priorités produit.
Rapport généré le 16 février 2026. Fichiers critiques cités : veza-backend-api/internal/middleware/auth.go, veza-backend-api/internal/api/routes_core.go, apps/web/src/config/env.ts, config/haproxy/haproxy.cfg, docker-compose.prod.yml, veza-chat-server/Cargo.toml, veza-stream-server/Cargo.toml.
