🔍 AUDIT TECHNIQUE INTÉGRAL — Monorepo Veza
Date : 14 février 2026
Mandant : Comité d'investissement
Périmètre : Monorepo complet (frontend, backend, services Rust, infra, CI/CD)
EXECUTIVE SUMMARY
Le monorepo Veza est une plateforme audio collaborative (streaming, chat, marketplace) avec une architecture multi-services (Go, Rust, React). L’audit révèle :
| Critère |
Verdict |
| Lancement en production |
⚠️ Possible avec corrections urgentes |
| Vente / acquisition |
❌ Non recommandé sans remédiation |
| Maintenance |
⚠️ Risques élevés (dette, tests fragiles) |
| Refactorisation |
✅ Recommandée (phases 2–3) |
| Réécriture |
❌ Non nécessaire |
Points positifs :
- Backend Go solide (auth, RBAC, ownership, CSRF, rate limiting)
- Chat Server Rust compile et fonctionne
- Stream Server Rust compile
- Migrations DB structurées
- CI/CD configuré (Go, Rust, frontend, E2E)
Points critiques :
- Route interne
/api/v1/internal/tracks/:id/stream-ready non authentifiée
- Vulnérabilités npm (React Router XSS, Axios DoS, etc.)
- Rate limiting désactivé en développement
- Tests frontend : ~42 % d’échecs (selon règles utilisateur)
- Features "Coming Soon" (Gear, Live, Education, Queue, Developer) sans backend
1️⃣ CARTOGRAPHIE GLOBALE
Stack
| Couche |
Technologie |
Version |
| Frontend |
React + Vite + TypeScript |
React 18.2, Vite 7.1 |
| Backend API |
Go + Gin |
Go 1.23, Gin 1.11 |
| Chat Server |
Rust + Axum + WebSocket |
Axum 0.8, Tokio 1.35 |
| Stream Server |
Rust + Axum + HLS |
Rust 2021 |
| Base de données |
PostgreSQL |
16-alpine |
| Cache |
Redis |
7-alpine |
| Message broker |
RabbitMQ |
3-management |
| Shared lib |
veza-common (Rust) |
0.1.0 |
Organisation du repo
veza/
├── apps/web/ # Frontend React (source unique UI)
├── veza-backend-api/ # API Go principale
├── veza-chat-server/ # Chat WebSocket Rust
├── veza-stream-server/ # Streaming audio Rust
├── veza-common/ # Lib Rust partagée (logging, types)
├── veza-docs/ # Documentation
├── packages/ # (vide ou minimal)
├── config/ # Docker, HAProxy
├── infra/ # docker-compose lab
└── .github/workflows/ # CI/CD
Workspaces npm : apps/web, packages/* (package.json racine)
Flux fonctionnels
Frontend (React) ──► Backend API (Go) ──► PostgreSQL
│ │
│ ├──► Redis (sessions, CSRF, rate limit)
│ ├──► RabbitMQ (jobs)
│ ├──► Stream Server (callback stream-ready)
│ └──► Chat Server (JWT token)
│
├──► Chat Server (WebSocket)
└──► Stream Server (HLS/audio)
Dépendances critiques
- Backend : GORM, JWT, bcrypt, ClamAV (go-clamd), AWS S3, Sentry, Prometheus
- Frontend : React Query, Zustand, Axios, i18next, Framer Motion, HLS.js
- Chat/Stream : SQLx, jsonwebtoken, Redis, RabbitMQ (lapin)
Dépendances obsolètes / abandonnées
veza-common : SQLx 0.8 (aligné avec chat/stream) — conflit historique résolu- Pas de dépendance abandonnée majeure identifiée
Technologies utilisées vs déclarées
| Déclaré |
Réel |
| veza-desktop (Electron) |
Non présent dans workspaces npm |
| Nx / Turborepo / Lerna |
Aucun — monorepo npm basique |
| Design tokens |
Présents (apps/web/docs/DESIGN_TOKENS.md) |
2️⃣ CE QUE LE PRODUIT PERMET RÉELLEMENT
Features validées (implémentées et utilisables)
| Feature |
Backend |
Frontend |
Tests |
| Auth (login, register, 2FA) |
✅ |
✅ |
✅ |
| Sessions, logout, refresh |
✅ |
✅ |
✅ |
| Password reset |
✅ |
✅ |
✅ |
| Email verification |
✅ |
✅ |
✅ |
| OAuth (Google, GitHub, Discord) |
✅ |
✅ |
Partiel |
| Tracks (CRUD, upload, HLS) |
✅ |
✅ |
✅ |
| Playlists (CRUD, collaborateurs) |
✅ |
✅ |
✅ |
| Marketplace (products, cart, checkout) |
✅ |
✅ |
✅ |
| Wishlist, Purchases |
✅ |
✅ |
✅ |
| Chat (token, stats) |
✅ |
✅ |
✅ |
| Social (feed, posts, groups, follow) |
✅ |
✅ |
✅ |
| Webhooks |
✅ |
✅ |
✅ |
| Analytics |
✅ |
✅ |
✅ |
| Admin (audit, unlock, pprof) |
✅ |
✅ |
✅ |
| Roles, RBAC |
✅ |
✅ |
✅ |
| Notifications |
✅ |
✅ |
✅ |
| Data export (GDPR) |
✅ |
✅ |
- |
Features incomplètes
| Feature |
État |
| OAuth |
Config via env, baseURL hardcodé veza.fr si non défini |
| Stream Server callback |
Route interne non authentifiée |
| E2E |
Présents mais résultats instables (e2e-results.json) |
Features fantômes / mortes
| Feature |
Route |
État |
| Gear |
/gear |
ComingSoon placeholder |
| Live |
/live |
ComingSoon placeholder |
| Education |
/education |
ComingSoon placeholder |
| Queue |
/queue |
ComingSoon placeholder |
| Developer |
/developer |
ComingSoon placeholder |
Incohérences produit / code
- README mentionne
veza-desktop (Electron) mais pas dans workspaces
docker-compose.prod.yml utilise HAProxy ; docker-compose.yml (dev) nondist_verification committé (artefacts de build) — mauvaise pratique
3️⃣ VALIDATION FONCTIONNELLE
Tests
| Composant |
Commande |
Résultat |
| Backend Go |
go test ./... -short |
Exécution longue (timeout 60s) |
| Chat Server |
cargo test |
✅ |
| Stream Server |
cargo check |
✅ (warnings) |
| Frontend |
npm run test -- --run |
~42 % échecs (règles utilisateur) |
| E2E |
npx playwright test |
Instable |
Points de rupture
- Route interne stream-ready : Appelée par Stream Server sans auth — n’importe qui peut forger un callback.
- Rate limiting : Désactivé en dev (
config.Env == config.EnvDevelopment) — risque en staging si APP_ENV mal configuré.
- CSRF : Désactivé si Redis indisponible (sauf prod où démarrage échoue).
Scénarios de crash évidents
- Redis down en prod → crash (CSRF requis)
- ClamAV down avec
CLAMAV_REQUIRED=true → uploads rejetés
JWT_SECRET vide → crash au démarrage (correct)
Zones non testées
- Handlers OAuth (flows complets)
- Intégration Stream Server ↔ Backend
- Webhooks sortants (workers)
4️⃣ AUDIT DE SÉCURITÉ — OWASP TOP 10
A01 – Broken Access Control
| Point |
Gravité |
Détail |
| Route interne stream-ready |
Critique |
POST /api/v1/internal/tracks/:id/stream-ready sans auth. Exploitation : forger des callbacks pour modifier le statut de tracks. |
| Ownership |
✅ |
RequireOwnershipOrAdmin sur users, tracks, playlists, products |
| Admin |
✅ |
RequireAdmin sur /admin/* |
| Sessions |
✅ |
Vérification ownership sur DELETE /sessions/:id (à confirmer dans handler) |
Correctif A01 : Protéger la route interne par API key ou IP whitelist (réseau interne).
A02 – Cryptographic Failures
| Point |
Gravité |
Détail |
| Mots de passe |
✅ |
bcrypt (golang.org/x/crypto/bcrypt) |
| JWT |
✅ |
HS256, validation stricte (alg, exp, iss, aud) |
| Secrets |
⚠️ Moyenne |
JWT_SECRET requis en prod (:? dans docker-compose.prod.yml) |
| HTTPS |
⚠️ |
COOKIE_SECURE=true en prod ; dépend du reverse proxy |
Correctif A02 : S’assurer que TLS est forcé au niveau HAProxy/load balancer.
A03 – Injection
| Point |
Gravité |
Détail |
| SQL |
✅ |
GORM + prepared statements ; pas de concaténation |
| Full-text search |
✅ |
plainto_tsquery avec paramètres |
| XSS |
⚠️ Moyenne |
DOMPurify présent côté frontend ; pas de sanitization systématique côté backend pour tous les champs texte |
Correctif A03 : Sanitiser les champs affichés (comments, posts, etc.) côté backend ou documenter la responsabilité frontend.
A04 – Insecure Design
| Point |
Gravité |
Détail |
| Callback stream-ready |
Critique |
Pas d’authentification du callback Stream Server → Backend |
| Rate limiting dev |
⚠️ Faible |
Désactivé en dev — acceptable si staging/prod corrects |
| Validation |
✅ |
go-playground/validator, EmailValidator, PasswordValidator |
Correctif A04 : Authentifier le callback (header X-Stream-Server-API-Key ou mTLS).
A05 – Security Misconfiguration
| Point |
Gravité |
Détail |
| CORS |
✅ |
Validation stricte en prod, pas de wildcard |
| Debug |
✅ |
Stack traces uniquement en dev/DEBUG |
| Swagger |
⚠️ Faible |
Exposé en prod — à restreindre ou désactiver |
| Secrets |
✅ |
.env dans .gitignore ; SECRETS_VERIFICATION.md |
Correctif A05 : Désactiver Swagger en prod ou le protéger par auth.
A06 – Vulnerable & Outdated Components
| Point |
Gravité |
Détail |
| npm |
Élevée |
React Router XSS (GHSA-2w69-qvjg-hvjx), Axios DoS (GHSA-43fc-jf86-j433), cookie, diff, jose, lodash, node-forge |
| Go |
✅ |
govulncheck dans CI |
| Rust |
✅ |
cargo audit dans CI |
Correctif A06 : npm audit fix ; mise à jour manuelle si breaking.
A07 – Identification & Authentication Failures
| Point |
Gravité |
Détail |
| JWT |
✅ |
Validation complète, token versioning |
| Sessions |
✅ |
DB, expiration, révocation |
| Account lockout |
✅ |
5 tentatives, 30 min |
| Password reset |
✅ |
Tokens avec expiration, audit |
A08 – Software & Data Integrity Failures
| Point |
Gravité |
Détail |
| CI/CD |
⚠️ Moyenne |
Pas de signature des images Docker |
| Build |
✅ |
Types générés depuis OpenAPI |
A09 – Logging & Monitoring Failures
| Point |
Gravité |
Détail |
| Logs |
✅ |
Zap structuré, pas de secrets en clair |
| Métriques |
✅ |
Prometheus |
| Audit |
✅ |
AuditService, audit_logs |
A10 – SSRF
| Point |
Gravité |
Détail |
| Webhooks |
⚠️ Faible |
Appels sortants vers URLs utilisateur — risque SSRF si URL non validée |
| OAuth |
✅ |
URLs fixes (Google, GitHub, Discord) |
5️⃣ DETTE TECHNIQUE
Dette critique (bloquante)
| Élément |
Fichier / Zone |
| Route stream-ready non protégée |
router.go:622-625 |
| Vulnérabilités npm high |
apps/web/package.json |
Dette structurante
| Élément |
Détail |
fmt.Printf debug dans router |
router.go:110-121 (logs ClamAV) |
| Duplication setup routes |
Nombreux trackService, chunkService recréés |
| Conventions |
Pas de tooling monorepo (Nx/Turborepo) |
| Tests fragiles |
Frontend 42 % échecs |
Dette cosmétique
| Élément |
Détail |
| Warnings Stream Server |
dead_code, unused_comparisons |
Fichiers dist_verification committés |
.gitignore à étendre |
| Commentaires FR/EN mélangés |
Cohérence |
6️⃣ QUALITÉ ARCHITECTURALE
Scores (sur 10)
| Critère |
Score |
Justification |
| Architecture |
7/10 |
Séparation claire (handlers, services, core) ; duplication de setup dans router |
| Maintenabilité |
6/10 |
Code structuré ; dette, tests fragiles, pas de tooling monorepo |
| Sécurité |
6/10 |
Bonnes bases (auth, RBAC, CSRF) ; faille callback, vulnérabilités npm |
| Scalabilité |
7/10 |
Stateless API, Redis, RabbitMQ ; pas de stratégie cache avancée documentée |
7️⃣ INFRA & DEVOPS
Docker
docker-compose.yml : dev (postgres, redis, rabbitmq, backend-api)docker-compose.prod.yml : prod (postgres, redis, rabbitmq, backend, chat, stream, web, HAProxy)- Secrets :
DB_PASS, RABBITMQ_PASS, JWT_SECRET requis en prod (:?)
Config
- Variables d’environnement documentées (règles utilisateur)
- Pas de secrets en clair dans les fichiers versionnés (vérification SECRETS_VERIFICATION.md)
Scripts
make utilisé (smoke, e2e, postman, etc.)- Pas de script dangereux identifié
8️⃣ RISQUES BUSINESS
CTO
- Lancement prod : Possible après correction de la route stream-ready et des vulnérabilités npm.
- Maintenance : Risque moyen : dette, tests instables, dépendances à mettre à jour.
Investisseur
- Vente : Non recommandée sans remédiation des vulnérabilités et de la dette critique.
- Valeur : Architecture solide, fonctionnalités riches ; qualité à renforcer.
Acquéreur
- Refactorisation : Oui, phases 2–3 du plan d’action.
- Réécriture : Non nécessaire.
9️⃣ PLAN D’ACTION PRIORISÉ
Phase 1 — Urgent (sécurité & stabilité)
| Action |
Effort |
Fichiers |
Protéger route /api/v1/internal/tracks/:id/stream-ready (API key ou IP) |
S |
router.go, middleware/ |
| Corriger vulnérabilités npm (audit fix, mise à jour manuelle) |
S |
apps/web/package.json |
Supprimer fmt.Printf debug du router |
S |
router.go |
Étendre .gitignore pour dist_verification |
S |
.gitignore |
Phase 2 — Stabilisation
| Action |
Effort |
Détail |
| Stabiliser tests frontend |
M |
Analyser échecs, mocks, dépendances |
| Stabiliser E2E Playwright |
M |
Fiabiliser setup, timeouts |
| Documenter/sécuriser callback Stream Server |
S |
Spec API key, implémentation |
| Désactiver ou protéger Swagger en prod |
S |
Config conditionnelle |
Phase 3 — Amélioration & refonte
| Action |
Effort |
Détail |
| Introduire tooling monorepo (Turborepo/Nx) |
L |
Cache builds, orchestration |
| Réduire duplication dans router |
M |
Factoring des services |
| Corriger warnings Stream Server |
S |
dead_code, unused |
| Implémenter ou retirer features Coming Soon |
M |
Gear, Live, Education, Queue, Developer |
CONCLUSION STRATÉGIQUE
Le monorepo Veza est techniquement viable avec une base solide (auth, RBAC, marketplace, chat, streaming). Les correctifs de la Phase 1 sont indispensables avant toute mise en production. La Phase 2 renforce la confiance (tests, documentation). La Phase 3 améliore la maintenabilité et la scalabilité.
Recommandation : Exécuter la Phase 1 sous 1–2 semaines, puis planifier la Phase 2 en parallèle du déploiement.
Rapport généré par audit technique automatisé — 14 février 2026
43af35fd93