diff --git a/AUDIT_2.md b/AUDIT_2.md new file mode 100644 index 000000000..332e5721b --- /dev/null +++ b/AUDIT_2.md @@ -0,0 +1,599 @@ +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. + +--- + +## ÉTAT D'AVANCEMENT (mis à jour le 14/02/2026) + +| # | Action | Statut | Commit | +|---|--------|--------|--------| +| 1.1 | SQL message_store.rs | Fait | - | +| 1.2 | Compilation stream server | Fait | - | +| 1.3 | Features fantômes | À faire | - | +| 1.4 | Rate limit logs/frontend | À faire | - | +| 1.5 | Tests Go sans -short | À faire | - | +| 1.6 | Gitleaks CI | À faire | - | +| 1.7 | Rapports couverture | À faire | - | + +--- + +## 1. CARTOGRAPHIE GLOBALE + +### Stack technique + +| Couche | Technologie | Version | Statut | +|--------|-------------|---------|--------| +| Frontend | React + Vite + TypeScript | 18.2 / 7.1 / 5.3 | Opérationnel | +| CSS | Tailwind v4 | 4.0 | Opérationnel | +| State | Zustand + TanStack Query | 4.5 / 5.17 | Opérationnel | +| Backend API | Go + Gin + GORM | 1.23 / 1.11 / 1.30 | Opérationnel | +| Chat Server | Rust + Axum + SQLx | 2021 ed. / 0.8 | Compile | +| Stream Server | Rust + Axum + Symphonia | 2021 ed. / 0.8 | **Ne compile pas** | +| Base de données | PostgreSQL 16 | 16-alpine | Opérationnel | +| Cache/Queues | Redis 7 + RabbitMQ 3 | 7-alpine / 3 | Opérationnel | +| Reverse Proxy | HAProxy 2.8 | 2.8-alpine | Configuré | +| CI/CD | GitHub Actions | N/A | Partiel | +| Container | Docker multi-stage | N/A | Configuré | +| K8s | Kubernetes + External Secrets | N/A | Scaffoldé | +| Docs | Docusaurus 3.8 | 3.8.1 | Scaffoldé | +| Tests | Vitest + Playwright + Storybook | 3.2 / 1.58 / 8.6 | Partiel | + +### Organisation du repo + +``` +veza/ +├── apps/web/ # Frontend React (206K LoC) +├── veza-backend-api/ # Backend Go (169K LoC) +├── veza-chat-server/ # Chat WebSocket Rust (28K LoC) +├── veza-stream-server/ # Audio Streaming Rust (39K LoC) +├── veza-common/ # Shared Rust library +├── veza-docs/ # Docusaurus (scaffoldé) +├── fixtures/ # Test fixtures +├── config/ # HAProxy, etc. +├── infra/ # IaC configs +├── k8s/ # Kubernetes manifests +├── scripts/ # Build/deploy scripts +├── .github/workflows/ # 8 CI/CD workflows +└── make/ # Modular Makefile system +``` + +**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. + +### Dépendances critiques + +- **Aucune dépendance obsolète majeure** identifiée (React 18.2 est mineur, TypeScript 5.3 acceptable) +- **Tokio version mismatch** dans les crates Rust : `veza-common` utilise `tokio = "1.0"` tandis que les serveurs utilisent `1.35` +- **Aucune dépendance abandonnée** détectée + +### Flux de données + +``` +Browser → HAProxy → Backend Go API → PostgreSQL + → Chat Server Rust (WebSocket) → PostgreSQL / Redis + → Stream Server Rust (Audio) → PostgreSQL / Redis + +Backend Go → Redis (sessions, cache, rate limiting, CSRF) + → RabbitMQ (événements async) + → ClamAV (antivirus upload, optionnel) +``` + +--- + +## 2. CE QUE LE PRODUIT PERMET RÉELLEMENT + +### Features VALIDÉES (backend + frontend connectés) + +| Feature | Backend | Frontend | Tests | Verdict | +|---------|---------|----------|-------|---------| +| Auth (register, login, logout) | Go | React | Oui | **Fonctionnel** | +| JWT + httpOnly cookies | Go | React | Oui | **Fonctionnel** | +| 2FA (TOTP) | Go | React | Oui | **Fonctionnel** | +| Password reset | Go | React | Oui | **Fonctionnel** | +| Email verification | Go | React | Oui | **Fonctionnel** | +| OAuth (Google, GitHub, Discord) | Go | React | Partiel | **Fonctionnel** | +| Session management | Go | React | Oui | **Fonctionnel** | +| RBAC (roles & permissions) | Go | React | Oui | **Fonctionnel** | +| User profiles | Go | React | Oui | **Fonctionnel** | +| Track CRUD | Go | React | Oui | **Fonctionnel** | +| Track upload (chunked) | Go | React | Oui | **Fonctionnel** | +| Playlist CRUD | Go | React | Oui | **Fonctionnel** | +| Search (tracks, playlists, users) | Go | React | Oui | **Fonctionnel** | +| Chat WebSocket temps réel | Rust | React | Partiel | **Fonctionnel** | +| Marketplace products | Go | React | Partiel | **Fonctionnel** | +| Cart & Checkout | Go | React | Partiel | **Fonctionnel** | +| Notifications | Go | React | Partiel | **Fonctionnel** | +| Admin dashboard | Go | React | Non | **Partiel** | +| Analytics | Go | React | Non | **Partiel** | +| Social feed/posts | Go | React | Non | **Partiel** | + +### Features PARTIELLEMENT implémentées + +| Feature | Ce qui manque | +|---------|---------------| +| HLS Audio Streaming | Stream server ne compile pas. Frontend prêt, backend Rust non validé | +| Webhooks | API CRUD existe, delivery system incomplet | +| Dashboard | Frontend avec données mockées uniquement (MSW) | +| Library | Frontend scaffoldé, logique métier partielle | +| File Manager | UI existe, pas de backend dédié | +| Discover | Données mockées, pas d'algorithme de recommandation | + +### Features FANTÔMES (UI existe, aucun backend) + +| Feature | Fichiers | Verdict | +|---------|----------|---------| +| **Education** | `components/views/education-view/`, MSW handlers lignes 600-630 | **Ghost feature** — Cours, tutoriels, rien côté backend | +| **Gamification** | `handlers-ghost.ts` importé dans MSW | **Ghost feature** — Badges, achievements, 100% mock | +| **Studio** | `components/views/studio-view/` | **Ghost feature** — DAW-like, aucun backend | +| **Live Streaming** | `components/views/live-view/` | **Partiellement ghost** — UI complète, backend minimal | + +### Features MORTES / Code non utilisé + +- `pages/auth/Login.tsx` duplique `features/auth/pages/LoginPage.tsx` +- `context/AuthContext.tsx` coexiste avec `features/auth/store/authStore.ts` (deux sources de vérité) +- `components/views/settings-view/` duplique `features/settings/pages/` +- `components/views/upload-view/` duplique `features/upload/` +- `dist_verification/` supprimé (git status montre 80+ fichiers deleted) + +### Incohérences produit/code + +1. **Deux patterns architecturaux coexistent** : `components/views/` (legacy) vs `features/*/pages/` (nouveau) sans plan de migration clair +2. **Education, Gamification, Studio** sont routés et accessibles comme si fonctionnels, mais retournent des données fictives +3. **Le stream server Rust ne build pas** mais le frontend intègre un player HLS complet avec dashboard de monitoring +4. **303 stories Storybook** pour la validation visuelle, mais le git status montre des modifications non commitées dans de nombreux fichiers critiques + +--- + +## 3. VALIDATION FONCTIONNELLE + +### Flows critiques analysés + +**Auth flow** : Validé +- Registration avec validation email, password strength check, username uniqueness +- Login avec rate limiting (5 tentatives / 15 min), account lockout (30 min) +- JWT access token (5 min TTL) + refresh token (30 jours) en httpOnly cookies +- CSRF protection avec timing-safe comparison +- Token versioning pour invalidation immédiate +- Tests : Oui (unitaires + intégration) + +**Upload flow** : Validé +- Upload chunked avec validation multi-couche (magic bytes, MIME, extension, taille) +- Scan antivirus ClamAV (optionnel mais intégré) +- 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. + +### A02 — Cryptographic Failures | Gravité : FAIBLE + +**Constats** : +- Passwords : bcrypt avec `DefaultCost` (10 rounds) +- JWT : HS256 avec secret en variable d'environnement, validation issuer/audience +- Tokens httpOnly, Secure, SameSite=strict en production +- CSRF : crypto/rand + timing-safe comparison +- Aucun secret hardcodé trouvé dans le code + +**Risque résiduel** : +- Refresh token TTL de 30 jours — long mais acceptable avec token versioning + +### A03 — Injection | Gravité : ÉLEVÉE + +**Vulnérabilité confirmée** dans `veza-chat-server/src/message_store.rs:179` : + +```177:184:veza-chat-server/src/message_store.rs + pub async fn cleanup_old_messages(&self, older_than_days: i32) -> Result { + let result = sqlx::query( + "DELETE FROM messages WHERE created_at < NOW() - INTERVAL '%s days'", + ) + .bind(older_than_days) + .execute(&self.pool) + .await?; +``` + +Le placeholder `%s` n'est pas reconnu par PostgreSQL/SQLx. Le `.bind()` est ignoré. En l'état, la requête échoue systématiquement (erreur de syntaxe SQL), mais si le format était corrigé naïvement avec `format!()`, ce serait une injection SQL directe. + +**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é. + +**Correctif** : +```rust +"DELETE FROM messages WHERE created_at < NOW() - INTERVAL '1 day' * $1" +``` + +### A04 — Insecure Design | Gravité : MOYENNE + +**Constats** : +- Rate limiting implémenté (Redis + in-memory fallback) +- Account lockout implémenté (5 tentatives) +- Input validation présente mais **inconsistante** — pas tous les DTOs utilisent des tags de validation +- Pas de rate limiting sur le frontend logging endpoint + +**Risque** : Un attaquant peut envoyer des requêtes de logging en masse pour saturer le stockage de logs. + +### A05 — Security Misconfiguration | Gravité : MOYENNE + +**Constats** : +- CORS validé en production (pas de wildcard) +- Security headers complets (HSTS, X-Frame-Options, CSP, etc.) +- Debug/stack traces désactivés en production +- `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) + +### A06 — Vulnerable & Outdated Components | Gravité : FAIBLE + +**Constats** : +- CI exécute `govulncheck`, `cargo audit`, `npm audit` +- Versions des dépendances à jour +- Tokio mismatch dans `veza-common` (1.0 vs 1.35) — risque de compatibilité, pas de vulnérabilité + +### A07 — Identification & Authentication Failures | Gravité : FAIBLE + +**Constats** : +- 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()` +- Sessions stockées en DB avec validation +- Password reset avec tokens expirables +- 2FA TOTP implémenté + +### A08 — Software & Data Integrity | Gravité : MOYENNE + +**Constats** : +- CI/CD avec npm audit, govulncheck, cargo audit +- Trivy scan sur images Docker (CRITICAL/HIGH) +- SBOM generation (CycloneDX) +- Image signing optionnel (cosign) + +**Risque** : +- Pas de secret scanning (gitleaks/trufflehog) dans le CI +- Go tests exécutés avec `-short` flag, excluant les tests nécessitant DB + +### A09 — Logging & Monitoring Failures | Gravité : FAIBLE + +**Constats** : +- Structured logging (zap pour Go, tracing pour Rust) +- Prometheus metrics +- Sentry error tracking +- Audit trail (`/api/v1/audit/logs`) +- Secret filtering dans les logs (`secret_filter.go`) +- Request ID tracking + +### A10 — SSRF | Gravité : FAIBLE + +**Constats** : +- File upload paths validés (`ValidateExecPath`, `build_safe_path`) +- Path traversal protection dans le stream server +- URL scheme validation dans le frontend (`sanitizeURL`) +- Pas d'appels HTTP sortants non filtrés identifiés + +### Tableau récapitulatif sécurité + +| OWASP | Gravité | Impact | Scénario | +|-------|---------|--------|----------| +| A01 | Faible | Logging flood | POST /api/v1/logs/frontend sans rate limit | +| A02 | Faible | - | Pratiques crypto solides | +| A03 | **Élevée** | Data loss | SQL buggé dans message_store.rs (échoue, pas exploitable en l'état) | +| A04 | Moyenne | DoS | Logging endpoint non rate limited | +| A05 | Moyenne | Bypass | Rate limiting conditionnel sur env vars | +| A06 | Faible | - | Dépendances à jour | +| A07 | Faible | - | Auth robuste | +| A08 | Moyenne | Supply chain | Pas de secret scanning | +| A09 | Faible | - | Logging/monitoring solides | +| A10 | Faible | - | Protections en place | + +--- + +## 5. DETTE TECHNIQUE + +### Dette CRITIQUE (bloquante) + +| # | Élément | Fichiers | Impact | +|---|---------|----------|--------| +| D1 | **Stream server ne compile pas** | `veza-stream-server/src/*` | 39K LoC inutilisables, feature streaming inopérante | +| D2 | **Features fantômes accessibles en prod** | Education, Gamification, Studio | Expérience utilisateur cassée, données fictives | +| D3 | **Pas de payment provider** | Checkout flow complet sans backend | Feature marketplace non fonctionnelle | +| D4 | **SQL buggé dans chat** | `message_store.rs:179` | Cleanup job échoue silencieusement | + +### Dette STRUCTURANTE + +| # | Élément | Fichiers | Impact | +|---|---------|----------|--------| +| D5 | **Double architecture frontend** | `components/views/*` vs `features/*/pages/*` | Confusion, duplication, maintenance x2 | +| D6 | **Pas d'orchestrateur monorepo** | Racine | CI lent, builds non optimisés, pas de cache | +| D7 | **265 fichiers de test mais couverture inconnue** | Tests frontend | Impossible de mesurer la qualité réelle | +| D8 | **261 fichiers test Go mais exécutés avec `-short`** | Tests backend | Tests d'intégration non exécutés en CI | +| D9 | **i18n incomplet** | ~35+ fichiers avec strings hardcodées en anglais | Impossible de livrer une version FR complète | +| D10 | **Duplication auth** | `AuthContext.tsx` + `authStore.ts` | Deux sources de vérité pour l'état auth | +| D11 | **MSW handlers : 1737 lignes** | `handlers.ts` | Fichier monstre, difficile à maintenir | +| D12 | **TODOs non résolus** | 40+ dans le backend Go, 15+ dans le frontend | Travail incomplet accumulé | + +### Dette COSMÉTIQUE + +| # | Élément | Impact | +|---|---------|--------| +| D13 | React 18.2 au lieu de 18.3 | Mineur | +| D14 | TypeScript 5.3 au lieu de 5.7 | Mineur | +| D15 | Scripts bash avec `eval` | Risque faible, dev only | +| D16 | Commentaires en français/anglais mixtes | Incohérence | +| D17 | Nombreux fichiers markdown d'audit/remediation dans le backend | Pollution du repo | + +--- + +## 6. QUALITÉ ARCHITECTURALE + +### Score d'architecture : 6.5/10 + +**Justification** : +- (+) Séparation polyglotte intelligente (Go pour l'API, Rust pour le temps réel et le streaming) +- (+) Feature-based structure sur le frontend +- (+) Layered architecture sur le backend (handlers → services → repositories) +- (-) Deux patterns frontend coexistent sans migration +- (-) Pas d'orchestrateur monorepo (npm workspaces insuffisant) +- (-) Stream server non fonctionnel = 1/4 de l'architecture cassée +- (-) Features fantômes polluent le routing et l'UX + +### Score de maintenabilité : 5.5/10 + +**Justification** : +- (+) Code bien structuré dans chaque service individuellement +- (+) 303 stories Storybook (excellent pour la documentation visuelle) +- (+) 526 fichiers de test au total +- (-) 442K LoC pour une équipe visiblement petite = surcharge +- (-) Duplication architecturale frontend +- (-) Tests backend en mode `-short` en CI +- (-) Couverture de test inconnue (pas de rapport) +- (-) 40+ TODOs non résolus + +### Score de sécurité : 7.5/10 + +**Justification** : +- (+) httpOnly cookies pour JWT +- (+) CSRF avec timing-safe comparison +- (+) CORS validé en production +- (+) Rate limiting + account lockout +- (+) Security headers complets +- (+) Audit trail, secret filtering +- (+) File upload multi-layer validation + ClamAV +- (-) SQL bug dans le chat server +- (-) Pas de secret scanning en CI +- (-) Rate limiting bypassable via env var + +### Score de scalabilité : 6/10 + +**Justification** : +- (+) Architecture microservices avec message queue (RabbitMQ) +- (+) Redis pour cache et sessions +- (+) K8s manifests préparés +- (+) HAProxy comme reverse proxy +- (-) Stream server non fonctionnel +- (-) Pas de CDN configuré pour les assets audio +- (-) Pas de monitoring de performance applicative (APM) au-delà de Prometheus +- (-) PostgreSQL comme seul datastore (pas de séparation read/write) + +--- + +## 7. INFRA & DEVOPS + +### Docker : 7/10 + +- Multi-stage builds pour tous les services +- Dockerfiles production dédiés +- Health checks sur tous les services +- Resource limits définis (sauf HAProxy) +- Network isolation + +**Problème** : Le HAProxy n'a pas de resource limits dans `docker-compose.prod.yml`. + +### Kubernetes : 6/10 + +- Deployments avec `runAsNonRoot`, `runAsUser: 1001` +- External Secrets Operator avec Vault +- Health checks (readiness + liveness) +- Graceful shutdown configuré + +**Problèmes** : +- Pas de deployment K8s pour le stream server +- Pas de Network Policies +- Pas de Pod Security Standards + +### CI/CD : 5.5/10 + +- 8 workflows GitHub Actions +- Security audits intégrés (govulncheck, cargo audit, npm audit) +- Trivy scanning sur les images Docker + +**Problèmes critiques** : +- 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. + +--- + +## 9. PLAN D'ACTION PRIORISÉ + +### Phase 1 — URGENT (sécurité & stabilité) — Semaines 1-2 + +| # | Action | Effort | Impact | +|---|--------|--------|--------| +| 1.1 | Fixer le SQL dans `message_store.rs:179` | **S** | Élimine bug critique | +| 1.2 | Fixer la compilation du stream server | **L** | Débloquer le streaming audio | +| 1.3 | Désactiver les routes des features fantômes en prod | **S** | UX cohérente | +| 1.4 | Ajouter rate limiting sur `/api/v1/logs/frontend` | **S** | Prévenir DoS logs | +| 1.5 | Exécuter les tests Go SANS `-short` en CI (ajouter DB test) | **M** | Couverture réelle | +| 1.6 | Ajouter secret scanning (gitleaks) au CI | **S** | Prévenir les fuites | +| 1.7 | Générer et publier les rapports de couverture de tests | **S** | Visibilité qualité | + +### Phase 2 — STABILISATION — Semaines 3-6 + +| # | Action | Effort | Impact | +|---|--------|--------|--------| +| 2.1 | Migrer `components/views/` vers `features/` (éliminer la duplication) | **XL** | Maintenabilité +50% | +| 2.2 | Supprimer `AuthContext.tsx`, consolider sur `authStore.ts` | **M** | Source de vérité unique | +| 2.3 | Compléter l'i18n (migrer les 35+ fichiers avec strings hardcodées) | **L** | Prêt pour le marché FR | +| 2.4 | Ajouter tests pour Dashboard, Library, Analytics, Admin | **L** | Couverture des zones aveugles | +| 2.5 | Découper `handlers.ts` MSW (1737 lignes) en modules par feature | **M** | Maintenabilité | +| 2.6 | Intégrer un payment provider (Stripe) pour le checkout | **XL** | Marketplace fonctionnelle | +| 2.7 | Ajouter Network Policies K8s | **M** | Sécurité cluster | +| 2.8 | Ajouter resource limits HAProxy | **S** | Stabilité infra | +| 2.9 | Nettoyer les fichiers markdown d'audit/remediation du backend | **S** | Propreté repo | + +### Phase 3 — AMÉLIORATION & REFONTE — Semaines 7-12 + +| # | Action | Effort | Impact | +|---|--------|--------|--------| +| 3.1 | Adopter Turborepo ou Nx pour l'orchestration monorepo | **L** | CI 3-5x plus rapide | +| 3.2 | Implémenter ou supprimer définitivement les features fantômes | **XL** | Produit cohérent | +| 3.3 | Configurer CDN pour assets audio | **M** | Performance streaming | +| 3.4 | Ajouter smoke tests post-deployment | **M** | Fiabilité déploiements | +| 3.5 | Implémenter request cancellation frontend (AbortController) | **M** | Prévenir memory leaks | +| 3.6 | Ajouter store migration strategy (Zustand) | **M** | Résilience client | +| 3.7 | Configurer read replicas PostgreSQL | **L** | Scalabilité | +| 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* \ No newline at end of file