Files

jpgiannetti 852f6d5e16 refactor(docs): réorganiser ADR et règles métier pour clarté

**Changements majeurs** :

1. **Suppression ADR-010 (Commandes volant et likes)** :
   - Contenu consolidé dans Règle 05 (section 5.3)
   - Raison : ADR-010 était du métier déguisé en architecture
   - Section "Implémentation Technique" ajoutée à Règle 05
   - Pattern correct (addition) vs incorrect (multiplication)

2. **Déplacement ADR-011 → Compliance** :
   - `docs/adr/011-conformite-stores.md` → `docs/compliance/stores-submission.md`
   - Raison : Nature opérationnelle/légale, pas architecture technique
   - Nouveau dossier `/docs/compliance/` créé

3. **Renumérotation ADR (010-022)** :
   - Combler les trous de numérotation (010 et 011)
   - ADR-012→010, ADR-013→011, ..., ADR-024→022
   - 22 ADR numérotés en continu (001-022)
   - Historique Git préservé (git mv)

4. **Mise à jour références** :
   - Règle 03 : ADR-010 → Règle 05 (section 5.3)
   - Règle 09 : ADR-010 → Règle 05 (section 5.3)
   - INCONSISTENCIES-ANALYSIS.md : toutes références mises à jour
   - Incohérence #15 annulée (faux problème : modes séparés)

**Résultat** :
- ✅ Séparation claire ADR (technique) vs Règles métier (fonctionnel)
- ✅ Documentation compliance séparée
- ✅ Numérotation ADR continue sans trous
- ✅ Single Source of Truth (pas de redondance)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

2026-02-01 14:34:12 +01:00

3.0 KiB

Raw Blame History

ADR-001 : Langage Backend

Statut : Accepté Date : 2025-01-17

Contexte

RoadWave doit gérer 10M d'utilisateurs avec des connexions concurrentes massives pour le streaming audio géolocalisé.

Décision

Go avec le framework Fiber.

Alternatives considérées

Comparatif synthétique

Option	Conn/serveur	P99 latency	Simplicité	Écosystème RoadWave
Go + Fiber	1M+	5-50ms	⭐⭐⭐⭐	⭐⭐⭐⭐
Rust + Tokio	2M+	2-20ms	⭐⭐	⭐⭐⭐
Node.js	100-500K	10-100ms	⭐⭐⭐⭐	⭐⭐⭐
Elixir/Phoenix	2M+	5-50ms	⭐⭐⭐	⭐⭐

Justification

Pourquoi Go plutôt que Rust ?

Rust offre meilleures performances absolues (2M conn/serveur vs 1M, 0 GC pauses) mais Go gagne sur le plan startup :

Time-to-market critique : MVP en 8 semaines vs 12+ pour Rust
- Courbe d'apprentissage borrow checker = grosse friction pour juniors
- Temps compilation + refactoring : 30-60s vs 1-2s Go
- Recrutement moins onéreux (€35-50K junior Go vs €50-70K Rust)
Écosystème production-ready pour RoadWave :
- WebRTC : pion/webrtc (mature) vs webrtc.rs (naissant)
- Tests BDD : Godog/Gherkin natif en Go, pas d'équivalent Rust
- PostgreSQL + PostGIS : pgx (excellent) vs sqlx (bon mais moins mature)
- Zitadel/OAuth2 : clients Go stables vs Rust émergents
Performance suffisante pour 10M users distribués :
- 1M conn/serveur = 10 serveurs max pour pics
- GC pauses (10-100ms) acceptable avec stratégie multi-région
- Scaling horizontal plus simple que vertical
Tooling natif :
- pprof intégré (CPU, mémoire)
- race detector systématique
- Cold start ~10ms (vs ~50ms Rust)
- Scalabilité future : Excellent support Kubernetes (migration prévue à 100K+ users, voir ADR-015)

Note importante : Kubernetes n'est pas utilisé en MVP (Docker Compose sur VPS suffit pour 0-20K users). Go est choisi principalement pour sa simplicité, son écosystème mature et ses performances concurrentielles. Le support K8s est un bonus pour la scalabilité future, pas la raison principale du choix.

Quand Rust aurait du sens

Si concentrations d'1M+ connexions sur serveur unique (cas rare RoadWave)
Si p99 latencies en prod > 100ms deviennent bottleneck (après Growth phase)
Si refonte majeure planifiée anyway
Stratégie possible : réécrire services hot (WebRTC, HLS streaming) en Rust à phase Scale

Conséquences

Formation équipe sur Go si nécessaire
Utilisation des bibliothèques : Fiber (HTTP), pgx (PostgreSQL), rueidis (Redis)
Monitoring GC pauses en production (cibler < 20ms p95)
Potential migration partielle à Rust pour services critiques post-Series A

Librairies : Voir ADR-018 pour stack complet (16 librairies validées)

3.0 KiB Raw Blame History