senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore(docs): reorganize markdown files, add docs/README (P2)

Browse source
This commit is contained in:
senke 2026-02-16 11:04:24 +01:00
parent 9c0c065383
commit fd51839d34
10 changed files with 545 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
README.md
View file

@ -42,4 +42,5 @@ See `make/config.mk` for COMPOSE_PROD and deployment docs.
## Documentation ## Documentation
- **[Developer Onboarding](docs/ONBOARDING.md)** — Setup, architecture, conventions, troubleshooting - **[Developer Onboarding](docs/ONBOARDING.md)** — Setup, architecture, conventions, troubleshooting
- **[Documentation index](docs/README.md)** — Index complet de la documentation
- See `docs/` for detailed architecture and development guides. Older audits and reports are archived in `docs/archive/`. - See `docs/` for detailed architecture and development guides. Older audits and reports are archived in `docs/archive/`.

2
apps/web/PROCHAINES_ETAPES.md
View file

@ -262,7 +262,7 @@ services:
- [ ] `apps/web/.env.example` - Documenter variables frontend - [ ] `apps/web/.env.example` - Documenter variables frontend
- [ ] `docker-compose.yml` - Ajouter variables dev - [ ] `docker-compose.yml` - Ajouter variables dev
- [ ] `docker-compose.prod.yml` - Ajouter variables production - [ ] `docker-compose.prod.yml` - Ajouter variables production
- [ ] `ENV_CONFIG.md` - Mettre à jour documentation - [ ] `docs/ENV_CONFIG.md` - Mettre à jour documentation
### 2.4 Critères de Validation ### 2.4 Critères de Validation

0
ENV_CONFIG.md → docs/ENV_CONFIG.md
View file

2
docs/ONBOARDING.md
View file

@ -244,4 +244,4 @@ cd veza-common && cargo build
- [README](../README.md) — Quick start - [README](../README.md) — Quick start
- [veza-backend-api/README.md](../veza-backend-api/README.md) — API structure - [veza-backend-api/README.md](../veza-backend-api/README.md) — API structure
- [loadtests/README.md](../loadtests/README.md) — Load testing - [loadtests/README.md](../loadtests/README.md) — Load testing
- [AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md](../AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md) — Technical audit - [archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md](archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md) — Technical audit

47
docs/README.md Normal file
View file

@ -0,0 +1,47 @@
# Documentation Veza
Index de la documentation principale du monorepo.
## Démarrage
- **[Onboarding](ONBOARDING.md)** — Setup, architecture, conventions, troubleshooting
- **[Frontend Setup](FRONTEND_SETUP.md)** — Configuration du frontend React
- **[Environment Config](ENV_CONFIG.md)** — Variables d'environnement et connexion Docker
## Architecture & Déploiement
- **[Production Deployment](PRODUCTION_DEPLOYMENT.md)** — Déploiement en production
- **[Monorepo Orchestration](MONOREPO_ORCHESTRATION.md)** — Organisation du monorepo
- **[Monitoring Setup](MONITORING_SETUP.md)** — Configuration du monitoring
## Développement
- **[Feature Status](FEATURE_STATUS.md)** — Statut des fonctionnalités
- **[Storybook Contract](STORYBOOK_CONTRACT.md)** — Conventions Storybook
- **[Visual Testing Strategy](VISUAL_TESTING_STRATEGY.md)** — Stratégie des tests visuels
- **[PR Ready Checklist](PR_READY_CHECKLIST.md)** — Checklist avant merge
## Base de données & Migrations
- **[DB Migrations Strategy](DB_MIGRATIONS_STRATEGY_FINAL.md)** — Stratégie des migrations
- **[UUID Migration Plan](UUID_DB_MIGRATION_PLAN.md)** — Plan de migration UUID
## Sécurité & Opérations
- **[Secrets Verification](SECRETS_VERIFICATION.md)** — Vérification des secrets
- **[Secret Rotation](SECRET_ROTATION.md)** — Rotation des secrets
- **[Payments Setup](PAYMENTS_SETUP.md)** — Configuration des paiements
## Remédiation & Progression
- **[Remediation Progress](REMEDIATION_PROGRESS.md)** — Suivi de la remédiation
- **[Global Project State](GLOBAL_PROJECT_STATE_2026.md)** — État global du projet
## Archives
Les audits et rapports historiques sont dans **[docs/archive/](archive/)**.
## Documentation par composant
- **Frontend** : `apps/web/docs/` (FULL_LAYOUT_PAGE, DESIGN_TOKENS, etc.)
- **Backend** : `veza-backend-api/docs/`

6
docs/REMEDIATION_PROGRESS.md
View file

@ -14,6 +14,8 @@
## Audit sécurité (AUDIT_TECHNIQUE_INTEGRAL_2026_02_16) ## Audit sécurité (AUDIT_TECHNIQUE_INTEGRAL_2026_02_16)
Référence : [archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_16.md](archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_16.md).
**Référence** : [Plan de remédiation sécurité](.cursor/plans/remédiation_sécurité_audit_veza_0de3fd35.plan.md) **Référence** : [Plan de remédiation sécurité](.cursor/plans/remédiation_sécurité_audit_veza_0de3fd35.plan.md)
### Lot 2 — Routes Education fantômes (A01) ✅ ### Lot 2 — Routes Education fantômes (A01) ✅
@ -49,7 +51,7 @@
## Vulnérabilités npm (A06 — Phase 1) ✅ ## Vulnérabilités npm (A06 — Phase 1) ✅
Référence : [AUDIT_TECHNIQUE_INTEGRAL_2026_02.md](../AUDIT_TECHNIQUE_INTEGRAL_2026_02.md) section A06. Référence : [archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_16.md](archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_16.md) section A06.
### Correctifs appliqués ### Correctifs appliqués
- **npm audit fix** : brace-expansion, diff, undici corrigés automatiquement. - **npm audit fix** : brace-expansion, diff, undici corrigés automatiquement.
@ -65,7 +67,7 @@ Référence : [AUDIT_TECHNIQUE_INTEGRAL_2026_02.md](../AUDIT_TECHNIQUE_INTEGRAL_
## Rate limiting (A04) ✅ ## Rate limiting (A04) ✅
Référence : [AUDIT_TECHNIQUE_INTEGRAL_2026_02.md](../AUDIT_TECHNIQUE_INTEGRAL_2026_02.md) — Points de rupture (ligne 170), A04 (ligne 232). Référence : [archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_16.md](archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_16.md) — Points de rupture (ligne 170), A04 (ligne 232).
### Correctifs appliqués ### Correctifs appliqués
- **Rate limiting toujours actif** : suppression de la condition `Env != EnvDevelopment` pour le rate limit global et register. - **Rate limiting toujours actif** : suppression de la condition `Env != EnvDevelopment` pour le rate limit global et register.

0
AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md → docs/archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md
View file

490
docs/archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_16.md Normal file
View file

@ -0,0 +1,490 @@
# 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
1. **Dual-pattern views** : `components/views/` ET `features/*/pages/` — architecture incohérente
2. **Routes Education** : Backend expose des routes publiques, feature retirée du frontend
3. **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
1. **Crash des services Rust** : ~80+ `.unwrap()` / `.expect()` en production
2. **CSRF inutilisable** : Si Redis tombe, le backend peut panic
3. **2FA cassé** : Flow de login 2FA possiblement incorrect
4. **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 :
1. **Sécurité** : HLS public, 2FA cassé, bypass flags, vulnérabilités npm (dev deps), `.unwrap()` en Rust.
2. **Stabilité** : Panic Redis, crash des services Rust.
3. **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`.*

0
blueprint.md → docs/archive/blueprint.md
View file

2
veza-backend-api/docs/architecture/ADR-001-backend-architecture.md
View file

@ -41,4 +41,4 @@ We choose Option A for long-term consistency with the existing core domains (tra
## References ## References
- [veza-backend-api/README.md](../../README.md) — Patterns section - [veza-backend-api/README.md](../../README.md) — Patterns section
- [AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md](../../../AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md) — Phase 3 plan - [docs/archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md](../../../docs/archive/AUDIT_TECHNIQUE_INTEGRAL_2026_02_15.md) — Phase 3 plan