672 lines
22 KiB
Markdown
672 lines
22 KiB
Markdown
# Analyse des Incohérences entre ADR et Règles Métier
|
||
|
||
**Date d'analyse** : 2026-01-28
|
||
**Analysé par** : Audit Architecture RoadWave
|
||
**Scope** : 18 ADR × Règles Métier (17 fichiers)
|
||
|
||
---
|
||
|
||
## Résumé Exécutif
|
||
|
||
Cette analyse a identifié **15 incohérences** entre les décisions d'architecture (ADR) et les règles métier du projet RoadWave.
|
||
|
||
### Répartition par Sévérité
|
||
|
||
| Sévérité | Nombre | % Total | Statut | Action Required |
|
||
|----------|--------|---------|--------|-----------------|
|
||
| 🔴 **CRITICAL** | 2 | 13% | ✅ **RÉSOLU** | ~~avant implémentation~~ |
|
||
| 🟠 **HIGH** | 4 | 27% | ⏳ 3 restants (1 résolu) | Résolution Sprint 1-2 |
|
||
| 🟡 **MODERATE** | 8 | 53% | ⏳ En cours | Résolution Sprint 3-5 |
|
||
| 🟢 **LOW** | 1 | 7% | ⏳ En cours | À clarifier lors du développement |
|
||
|
||
### Impact par Domaine
|
||
|
||
| Domaine | Nombre d'incohérences | Criticité maximale |
|
||
|---------|----------------------|-------------------|
|
||
| Streaming & Géolocalisation | 3 | 🔴 CRITICAL |
|
||
| Données & Infrastructure | 3 | 🟠 HIGH |
|
||
| Authentification & Sécurité | 2 | 🟠 HIGH |
|
||
| Tests & Qualité | 2 | 🟡 MODERATE |
|
||
| Coûts & Déploiement | 3 | 🟡 MODERATE |
|
||
| UX & Engagement | 2 | 🟡 MODERATE |
|
||
|
||
---
|
||
|
||
## 🔴 Incohérences Critiques (Blocantes)
|
||
|
||
### #1 : HLS ne supporte pas les Notifications Push en Arrière-plan
|
||
|
||
**Statut** : ✅ **RÉSOLU** (ADR-019 créé)
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concerné** | ADR-002 (Protocole Streaming) |
|
||
| **Règle métier** | Règle 05, section 5.1.2 (Mode Piéton, lignes 86-120) |
|
||
| **Conflit** | HLS est unidirectionnel (serveur→client), ne peut pas envoyer de push quand l'app est fermée |
|
||
| **Impact** | Mode piéton non fonctionnel : notifications "Point d'intérêt à 200m" impossibles |
|
||
|
||
**Scénario d'échec** :
|
||
```
|
||
Utilisateur: Marie se promène, app fermée
|
||
Position: 150m de la Tour Eiffel
|
||
Attendu: Push notification "🗼 À proximité: Histoire de la Tour Eiffel"
|
||
Réel: Rien (HLS ne peut pas notifier)
|
||
```
|
||
|
||
**Solution implémentée** :
|
||
- ✅ **ADR-019** : Architecture hybride WebSocket + Firebase Cloud Messaging
|
||
- Phase 1 (MVP) : Push serveur via FCM/APNS
|
||
- Phase 2 : Geofencing natif iOS/Android pour mode offline
|
||
|
||
**Actions requises** :
|
||
- [ ] Backend : Implémenter endpoint WebSocket `/ws/location`
|
||
- [ ] Backend : Worker PostGIS avec requête `ST_DWithin` (30s interval)
|
||
- [ ] Mobile : Intégrer Firebase SDK (`firebase_messaging`)
|
||
- [ ] Tests : Validation en conditions réelles (10 testeurs, Paris)
|
||
|
||
---
|
||
|
||
### #2 : Latence HLS Incompatible avec ETA de 7 Secondes
|
||
|
||
**Statut** : ✅ **RÉSOLU** (ADR-002 mis à jour)
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concerné** | ADR-002 (Protocole Streaming, lignes 40-41) |
|
||
| **Règle métier** | Règle 05 (lignes 16-20), Règle 17 (lignes 25-30, 120-124) |
|
||
| **Conflit** | ETA de 7s avant le point, mais HLS a 5-30s de latence → audio démarre APRÈS avoir dépassé le point |
|
||
| **Impact** | UX catastrophique : utilisateur entend "Vous êtes devant le château" 100m APRÈS l'avoir dépassé |
|
||
|
||
**Calcul du problème** (90 km/h = 25 m/s) :
|
||
```
|
||
t=0s → Notification "Suivant: Château dans 7s" (175m avant)
|
||
t=7s → Utilisateur arrive au château
|
||
t=15s → HLS démarre (latence 15s)
|
||
Résultat: Audio démarre 200m APRÈS le point ❌
|
||
```
|
||
|
||
**Solution implémentée** :
|
||
- ✅ **ADR-002 mis à jour** : Section "Gestion de la Latence et Synchronisation Géolocalisée"
|
||
- Pre-buffering à ETA=30s (15 premières secondes en cache local)
|
||
- ETA adaptatif : 5s si cache prêt, 15s sinon
|
||
- Mesure dynamique de latence HLS par utilisateur
|
||
|
||
**Actions requises** :
|
||
- [ ] Backend : Endpoint `/api/v1/audio/poi/:id/intro` (retourne 15s d'audio)
|
||
- [ ] Mobile : Service `PreBufferService` avec cache local (max 100 MB)
|
||
- [ ] Mobile : Loader visuel avec progression si buffer > 3s
|
||
- [ ] Tests : Validation synchronisation ±10m du POI
|
||
|
||
---
|
||
|
||
## 🟠 Incohérences Importantes (Sprint 1-2)
|
||
|
||
### #3 : Souveraineté des Données (Français vs Suisse)
|
||
|
||
**Statut** : ✅ **RÉSOLU** (ADR-008 mis à jour)
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concernés** | ADR-004 (CDN, ligne 26), ADR-008 (Auth, mis à jour) |
|
||
| **Règle métier** | Règle 02 (RGPD, section 13.10) |
|
||
| **Conflit** | ADR-004 revendique "100% souveraineté française" mais ADR-008 utilisait Zitadel (entreprise suisse) |
|
||
| **Impact** | Contradiction marketing + risque juridique si promesse "100% français" |
|
||
|
||
**Solution implémentée** : **Self-hosting Zitadel sur OVH France**
|
||
|
||
- ✅ Container Docker sur le même VPS OVH (Gravelines, France)
|
||
- ✅ Base de données PostgreSQL partagée (schéma séparé pour Zitadel)
|
||
- ✅ Aucune donnée ne transite par des serveurs tiers
|
||
- ✅ Souveraineté totale garantie : 100% des données en France
|
||
- ✅ Cohérence complète avec ADR-004 (CDN 100% français)
|
||
|
||
**Changements apportés** :
|
||
- ✅ ADR-008 mis à jour avec architecture self-hosted détaillée
|
||
- ✅ TECHNICAL.md mis à jour (tableau + diagramme architecture)
|
||
- ✅ Clarification : Zitadel est open source, donc aucune dépendance à une entreprise suisse
|
||
|
||
**Actions complétées** :
|
||
- [x] Décision validée : Self-host sur OVH
|
||
- [x] ADR-008 mis à jour avec architecture self-hosted
|
||
- [x] TECHNICAL.md mis à jour
|
||
|
||
---
|
||
|
||
### #4 : ORM sqlc vs Types PostGIS
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concernés** | ADR-013 (ORM, lignes 12, 33-40), ADR-005 (BDD, lignes 47-56) |
|
||
| **Règle métier** | N/A (problème technique pur) |
|
||
| **Conflit** | sqlc génère types Go depuis SQL, mais PostGIS geography/geometry ne mappent pas proprement |
|
||
| **Impact** | Risque de type `interface{}` ou `[]byte` pour géographie → perte de type safety revendiquée |
|
||
|
||
**Nature du problème** :
|
||
|
||
sqlc génère du code Go depuis SQL, mais les types PostGIS (`geography`, `geometry`) ne sont pas mappés proprement en Go. Résultat : types opaques (`[]byte`, `interface{}`) qui perdent la **type safety** revendiquée dans ADR-013.
|
||
|
||
**Solution retenue** :
|
||
|
||
1. **Wrapper types Go** avec méthodes `Scan/Value` pour conversion automatique
|
||
2. **Utiliser les fonctions PostGIS de conversion** :
|
||
- `ST_AsGeoJSON()` → struct GeoJSON typée
|
||
- `ST_AsText()` → string WKT
|
||
- `geography` brut → `pgtype.Point` (lib pgx)
|
||
3. **Documenter le pattern** dans ADR-013 section "Gestion des Types PostGIS"
|
||
|
||
**Action** :
|
||
- [ ] Créer package `internal/geo` avec wrappers `GeoJSON`, `WKT`
|
||
- [ ] Mettre à jour ADR-013 section "Types PostGIS"
|
||
- [ ] Documenter pattern dans README backend
|
||
|
||
---
|
||
|
||
### #5 : Cache Redis (TTL 5min) vs Mode Offline (30 jours)
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concerné** | ADR-005 (BDD, ligne 60) |
|
||
| **Règle métier** | Règle 11 (Mode Offline, lignes 58-77) |
|
||
| **Conflit** | Redis avec TTL 5min pour géolocalisation, mais contenu offline valide 30 jours |
|
||
| **Impact** | En mode offline, impossible de rafraîchir le cache géolocalisation → POI proches non détectés |
|
||
|
||
**Analyse du flux** :
|
||
|
||
```
|
||
Mode connecté:
|
||
1. Requête POI proches → Redis (cache 5min)
|
||
2. Si miss → PostGIS → Cache Redis
|
||
3. ✅ Fonctionne
|
||
|
||
Mode offline (Règle 11):
|
||
1. Requête POI proches → Redis (expiré depuis 6 min)
|
||
2. Impossible de requêter PostGIS (pas de réseau) ❌
|
||
3. Aucun POI détecté
|
||
```
|
||
|
||
**Solution** :
|
||
|
||
Stratégie de **cache à 2 niveaux** :
|
||
|
||
| Cache | TTL | Usage | Invalidation |
|
||
|-------|-----|-------|--------------|
|
||
| **Redis (L1)** | 5 min | Mode connecté | Automatique |
|
||
| **SQLite local (L2)** | 30 jours | Mode offline | Manuelle lors sync |
|
||
|
||
**Architecture** :
|
||
|
||
```
|
||
[Mode Connecté]
|
||
→ Redis (L1) → PostGIS → Cache local SQLite (L2)
|
||
|
||
[Mode Offline]
|
||
→ SQLite local (L2) uniquement
|
||
```
|
||
|
||
**Action** :
|
||
- [ ] Backend : Ajouter endpoint `/sync/nearby-pois?lat=X&lon=Y&radius=10km`
|
||
- [ ] Mobile : Créer `OfflineCacheService` avec SQLite + index spatial
|
||
- [ ] Mettre à jour ADR-005 section "Cache" avec stratégie 2 niveaux
|
||
- [ ] Règle 11 : Clarifier sync automatique vs manuel
|
||
|
||
---
|
||
|
||
### #6 : Package Geofencing vs Permissions iOS/Android
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concerné** | ADR-014 (Frontend Mobile, ligne 48) |
|
||
| **Règle métier** | Règle 05 (lignes 86-134), Règle 11 (RGPD, lignes 51-86) |
|
||
| **Conflit** | Package `geofence_service` choisi, mais pas de doc sur compatibilité permissions "optionnelles" |
|
||
| **Impact** | Risque de rejet App Store/Play Store si permissions obligatoires mal gérées |
|
||
|
||
**Problématiques** :
|
||
|
||
1. **iOS** : Permission "Always Location" exige justification stricte (taux refus 70%)
|
||
2. **Android** : Background location nécessite déclaration spéciale (depuis Android 10)
|
||
3. **Règle métier** : Permissions optionnelles (app utilisable sans "Always Location")
|
||
|
||
**Package `geofence_service`** :
|
||
- ✅ Supporte iOS/Android
|
||
- ⚠️ Documentation peu claire sur permissions optionnelles
|
||
- ⚠️ Pas de fallback natif si permission refusée
|
||
|
||
**Solution** :
|
||
|
||
**Stratégie de permissions progressive** :
|
||
|
||
```dart
|
||
enum LocationPermissionLevel {
|
||
denied, // Pas de permission
|
||
whenInUse, // "Quand l'app est ouverte" (iOS)
|
||
always, // "Toujours" (iOS) / Background (Android)
|
||
}
|
||
|
||
class GeofencingService {
|
||
Future<void> requestPermissions() async {
|
||
// Étape 1: Demander "When In Use" (moins intrusif)
|
||
var status = await Permission.locationWhenInUse.request();
|
||
|
||
if (status.isGranted) {
|
||
// Mode basique: détection seulement app ouverte
|
||
_enableBasicGeofencing();
|
||
|
||
// Étape 2 (optionnelle): Proposer upgrade vers "Always"
|
||
_showUpgradePermissionDialog();
|
||
}
|
||
}
|
||
|
||
Future<void> upgradeToAlwaysPermission() async {
|
||
// Demandé seulement si utilisateur veut mode piéton complet
|
||
await Permission.locationAlways.request();
|
||
}
|
||
}
|
||
```
|
||
|
||
**Actions** :
|
||
- [ ] Mettre à jour ADR-014 avec stratégie permissions progressive
|
||
- [ ] Créer doc "Permissions Strategy" dans `/docs/mobile/`
|
||
- [ ] Tests : Validation rejet App Store (TestFlight beta)
|
||
|
||
---
|
||
|
||
## 🟡 Incohérences Modérées (Sprint 3-5)
|
||
|
||
### #7 : Points vs Pourcentages dans les Jauges
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concerné** | ADR-010 (Commandes Volant, lignes 15-21) |
|
||
| **Règle métier** | Règle 03 (Centres d'intérêt, lignes 7-14) |
|
||
| **Conflit** | ADR dit "+2 **points**", Règle dit "+2**%**" pour même action |
|
||
| **Impact** | Ambiguïté sur calcul : +2 points absolus ou +2% relatifs ? |
|
||
|
||
**Exemple du conflit** :
|
||
|
||
- **ADR-010 (ligne 18)** : "≥80% d'écoute = +2 **points**"
|
||
- **Règle 03 (ligne 9)** : "≥80% d'écoute = +2**%** à la jauge"
|
||
|
||
**Scénario** :
|
||
```
|
||
Jauge "Automobile" = 45%
|
||
Utilisateur écoute 85% d'un podcast voiture
|
||
|
||
Option A (points absolus): 45 + 2 = 47%
|
||
Option B (pourcentage relatif): 45 * 1.02 = 45.9%
|
||
```
|
||
|
||
**Recommandation** : **Option A (points absolus)** pour simplicité
|
||
|
||
**Justification** :
|
||
- Progression linéaire plus intuitive
|
||
- Évite effet "rich get richer" (jauges hautes progressent + vite)
|
||
- Cohérent avec système de gamification classique
|
||
|
||
**Actions** :
|
||
- [ ] Clarifier ADR-010 : remplacer "points" par "points de pourcentage"
|
||
- [ ] Clarifier Règle 03 : uniformiser terminologie
|
||
- [ ] Backend : Documenter formule exacte dans code
|
||
|
||
---
|
||
|
||
### #8 : OAuth2 Complexe vs Email/Password Simple
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concerné** | ADR-008 (Auth, lignes 12, 52-68) |
|
||
| **Règle métier** | Règle 01 (Auth, lignes 5-10) |
|
||
| **Conflit** | ADR implémente OAuth2 PKCE complet, mais Règle dit "❌ Pas d'OAuth tiers, email/password uniquement" |
|
||
| **Impact** | Sur-ingénierie : OAuth2 conçu pour tiers (Google, Facebook) mais non utilisé ici |
|
||
|
||
**Analyse** :
|
||
|
||
- **ADR-008** : Architecture OAuth2 avec PKCE, refresh tokens, etc.
|
||
- **Règle 01** : "❌ Pas de Google, Apple, Facebook OAuth"
|
||
|
||
**Zitadel supporte** :
|
||
- OAuth2 (pour intégrations tierces)
|
||
- Email/Password natif (ce dont on a besoin)
|
||
|
||
**Question** : Pourquoi implémenter OAuth2 si pas de tiers ?
|
||
|
||
**Options** :
|
||
|
||
| Option | Complexité | Justification |
|
||
|--------|------------|---------------|
|
||
| **A. Garder OAuth2** | Haute | Future-proof pour API partenaires |
|
||
| **B. Session simple** | Basse | Suffit pour MVP email/password |
|
||
|
||
**Recommandation** : **Option A** (garder OAuth2) si :
|
||
- Vision long-terme : API pour partenaires (créateurs, annonceurs)
|
||
- Coût marginal : Zitadel gère OAuth2 nativement
|
||
|
||
Sinon **Option B** (session simple) si MVP pur.
|
||
|
||
**Actions** :
|
||
- [ ] Décision : Confirmer besoin OAuth2 avec product owner
|
||
- [ ] Si A : Mettre à jour Règle 01 "OAuth tiers en Phase 2"
|
||
- [ ] Si B : Simplifier ADR-008 (session JWT classique)
|
||
|
||
---
|
||
|
||
### #9 : GeoIP Database (MaxMind)
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concerné** | ADR-005 (non mentionné) |
|
||
| **Règle métier** | Règle 02 (RGPD, lignes 146-149) |
|
||
| **Conflit** | Règle cite "MaxMind GeoLite2 (gratuit)", mais offre a changé en 2019 |
|
||
| **Impact** | Coût caché : MaxMind nécessite compte + API calls (plus de base offline gratuite) |
|
||
|
||
**Historique** :
|
||
- **Avant 2019** : GeoLite2 database téléchargeable gratuitement
|
||
- **Après 2019** : Compte requis + limite 1000 requêtes/jour (gratuit)
|
||
- **Dépassement** : 0.003$/requête
|
||
|
||
**Utilisation RoadWave** :
|
||
- Mode dégradé (sans GPS) → GeoIP pour localisation approximative
|
||
- Estimation : 10% des utilisateurs (1000 users × 10% = 100 requêtes/jour)
|
||
|
||
**Options** :
|
||
|
||
| Option | Coût/mois | Précision | Maintenance |
|
||
|--------|-----------|-----------|-------------|
|
||
| **A. MaxMind API** | ~10€ | ±50 km | Nulle |
|
||
| **B. IP2Location Lite** | Gratuit | ±50 km | Maj mensuelle |
|
||
| **C. Self-hosted GeoIP** | Gratuit | ±50 km | +2h/mois |
|
||
|
||
**Recommandation** : **Option C** (self-hosted avec IP2Location Lite DB)
|
||
|
||
**Architecture** :
|
||
```
|
||
[Backend Go] → [GeoIP Service]
|
||
↓
|
||
[IP2Location SQLite DB]
|
||
(màj mensuelle via cron)
|
||
```
|
||
|
||
**Actions** :
|
||
- [ ] Backend : Implémenter service GeoIP avec IP2Location
|
||
- [ ] DevOps : Cron job màj mensuelle de la DB
|
||
- [ ] Mettre à jour Règle 02 ligne 147
|
||
|
||
---
|
||
|
||
### #10 : Tests BDD Synchronisés (Backend + Mobile)
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concernés** | ADR-007 (Tests BDD, lignes 30-68), ADR-015 (Stratégie, lignes 59-62) |
|
||
| **Règle métier** | Toutes (Gherkin) |
|
||
| **Conflit** | Features partagées `/features`, step definitions séparées → qui exécute quoi ? |
|
||
| **Impact** | Risque de divergence backend/mobile si tests pas synchronisés |
|
||
|
||
**Architecture actuelle** :
|
||
|
||
```
|
||
/features/*.feature (partagé)
|
||
/backend/tests/bdd/ (step definitions Go)
|
||
/mobile/tests/bdd/ (step definitions Dart)
|
||
```
|
||
|
||
**Question non résolue** :
|
||
- Un test "Authentification" concerne-t-il backend ET mobile ?
|
||
- Qui est responsable de l'exécuter ?
|
||
- Si les implémentations divergent ?
|
||
|
||
**Recommandation** : **Catégoriser les features**
|
||
|
||
```
|
||
/features/
|
||
/api/ → Backend uniquement (tests API REST)
|
||
/ui/ → Mobile uniquement (tests interface)
|
||
/e2e/ → End-to-end (backend + mobile ensemble)
|
||
```
|
||
|
||
**Exemple** :
|
||
```gherkin
|
||
# features/api/authentication.feature (backend)
|
||
Scénario: Création de compte via API
|
||
Étant donné une requête POST /api/v1/auth/register
|
||
Quand j'envoie email "test@example.com" et password "Pass123!"
|
||
Alors le statut HTTP est 201
|
||
Et la réponse contient un token JWT
|
||
|
||
# features/ui/authentication.feature (mobile)
|
||
Scénario: Création de compte via interface
|
||
Étant donné que je suis sur l'écran d'inscription
|
||
Quand je saisis email "test@example.com"
|
||
Et je saisis mot de passe "Pass123!"
|
||
Et je clique sur "S'inscrire"
|
||
Alors je vois l'écran d'accueil
|
||
```
|
||
|
||
**Actions** :
|
||
- [ ] Réorganiser `/features` en 3 catégories (api, ui, e2e)
|
||
- [ ] Mettre à jour ADR-007 avec convention de nommage
|
||
- [ ] CI/CD : Séparer jobs backend-bdd et mobile-bdd
|
||
|
||
---
|
||
|
||
### #11 : 70/30 Split Paiements (Vérification Manquante)
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concerné** | ADR-009 (Paiement, lignes 32-52) |
|
||
| **Règle métier** | Règle 18 (Monétisation, non fournie complète) |
|
||
| **Conflit** | ADR assume 70/30 split sans référence règle métier |
|
||
| **Impact** | Risque de mauvaise répartition revenus créateurs |
|
||
|
||
**ADR-009 spécifie** :
|
||
- 70% créateur
|
||
- 30% plateforme
|
||
|
||
**Question** : Est-ce validé par les règles métier business ?
|
||
|
||
**Actions** :
|
||
- [ ] Lire Règle 18 (Monétisation Créateurs) complète
|
||
- [ ] Vérifier si 70/30 correspond aux attentes
|
||
- [ ] Si divergence : mettre à jour ADR-009
|
||
|
||
---
|
||
|
||
### #12 : Monorepo Path Filters vs Features Partagées
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concernés** | ADR-016 (Monorepo, ligne 80), ADR-015 (Tests) |
|
||
| **Règle métier** | N/A (problème CI/CD) |
|
||
| **Conflit** | Path filters pour éviter rebuild tout, mais features partagées déclenchent tout |
|
||
| **Impact** | Optimisation CI/CD inefficace |
|
||
|
||
**Problème** :
|
||
|
||
```yaml
|
||
# .github/workflows/backend.yml
|
||
on:
|
||
push:
|
||
paths:
|
||
- 'backend/**'
|
||
- 'features/**' # ❌ Change sur n'importe quel .feature → rebuild backend
|
||
```
|
||
|
||
**Solution** : Path filters **par catégorie** (suite de #10)
|
||
|
||
```yaml
|
||
# .github/workflows/backend.yml
|
||
on:
|
||
push:
|
||
paths:
|
||
- 'backend/**'
|
||
- 'features/api/**' # ✅ Seulement features API
|
||
- 'features/e2e/**' # ✅ E2E impacte backend
|
||
|
||
# .github/workflows/mobile.yml
|
||
on:
|
||
push:
|
||
paths:
|
||
- 'mobile/**'
|
||
- 'features/ui/**' # ✅ Seulement features UI
|
||
- 'features/e2e/**' # ✅ E2E impacte mobile
|
||
```
|
||
|
||
**Actions** :
|
||
- [ ] Implémenter catégorisation features (dépend de #10)
|
||
- [ ] Mettre à jour workflows CI/CD
|
||
- [ ] Mettre à jour ADR-016 avec stratégie path filters
|
||
|
||
---
|
||
|
||
### #13 : Coûts Email (Transition Free → Paid)
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concernés** | ADR-018 (Email, lignes 49-52), ADR-017 (Hébergement) |
|
||
| **Règle métier** | N/A (économique) |
|
||
| **Conflit** | ADR cite "gratuit" mais limite 9000 emails/mois → plan transition manquant |
|
||
| **Impact** | Coût surprise lors de la croissance |
|
||
|
||
**ADR-018 spécifie** :
|
||
- Brevo gratuit : 300 emails/jour = 9000/mois
|
||
- Phase MVP : 0-10K utilisateurs
|
||
|
||
**Calcul réaliste** :
|
||
```
|
||
Emails par utilisateur/mois:
|
||
- Vérification email: 1
|
||
- Reset password: 0.1 (10%)
|
||
- Notifications (opt-in 30%): 4
|
||
- Paiements créateurs (5%): 1
|
||
|
||
Total: ~2 emails/user/mois (moyenne)
|
||
|
||
10K users × 2 = 20K emails/mois → dépassement tier gratuit
|
||
```
|
||
|
||
**Coût Brevo** :
|
||
- Free: 0-9K emails
|
||
- Lite: 19€/mois (20K emails)
|
||
- Business: 49€/mois (50K emails)
|
||
|
||
**Actions** :
|
||
- [ ] Mettre à jour ADR-018 avec projection coûts
|
||
- [ ] Implémenter alertes (90% quota atteint)
|
||
- [ ] Plan B : Self-hosted SMTP (Postfix) si budget serré
|
||
|
||
---
|
||
|
||
### #14 : Kubernetes vs VPS MVP
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concernés** | ADR-017 (Hébergement, ligne 12), ADR-001 (Go, ligne 27) |
|
||
| **Règle métier** | N/A (infrastructure) |
|
||
| **Conflit** | ADR-001 justifie Go pour "Kubernetes first-class", mais ADR-017 utilise VPS simple |
|
||
| **Impact** | Sur-architecture : pourquoi choisir Go pour K8s si pas utilisé ? |
|
||
|
||
**Analyse** :
|
||
|
||
- **ADR-001** : Go choisi notamment pour "excellent support Kubernetes"
|
||
- **ADR-017** : MVP sur OVH VPS Essential (single VM, Docker Compose)
|
||
- **ADR-012** : Mentionne migration K8s "à 1M+ users"
|
||
|
||
**Question** : Justification K8s prématurée ?
|
||
|
||
**Réponse** : **Non, acceptable** si :
|
||
- Vision long-terme claire (1M users = besoin K8s)
|
||
- Go apporte autres avantages (perf, concurrence, typing)
|
||
- Coût marginal (Go vs Node.js comparable en complexité MVP)
|
||
|
||
**Recommandation** : **Clarifier la vision** dans ADR
|
||
|
||
**Actions** :
|
||
- [ ] Mettre à jour ADR-001 : "Go pour scalabilité future (K8s), mais aussi perf/typage"
|
||
- [ ] ADR-017 : Ajouter section "Roadmap Infrastructure" (VPS → K8s)
|
||
|
||
---
|
||
|
||
## 🟢 Incohérences Mineures (Clarification)
|
||
|
||
### #15 : Unlike Manuel sur Contenu Auto-liké
|
||
|
||
| Élément | Détail |
|
||
|---------|--------|
|
||
| **ADR concerné** | ADR-010 (ligne 15-21) |
|
||
| **Règle métier** | Règle 05 (lignes 248-323), Règle 03 (lignes 93-99) |
|
||
| **Conflit** | Auto-like +2% documenté, mais unlike manuel non spécifié |
|
||
| **Impact** | Ambiguïté : faut-il annuler (+2%) si unlike ? |
|
||
|
||
**Scénario** :
|
||
```
|
||
1. Utilisateur écoute 85% → auto-like → jauge +2%
|
||
2. Utilisateur clique "Unlike" (toggle)
|
||
3. Que se passe-t-il ?
|
||
Option A: Jauge -2% (annulation)
|
||
Option B: Jauge reste (unlike n'affecte pas)
|
||
```
|
||
|
||
**Recommandation** : **Option A** (annulation symétrique)
|
||
|
||
**Justification** : Unlike explicite = signal fort "pas intéressé"
|
||
|
||
**Actions** :
|
||
- [ ] Clarifier Règle 03 : section "Unlike Manuel"
|
||
- [ ] Backend : Implémenter logique annulation dans `GaugeService`
|
||
|
||
---
|
||
|
||
## Plan d'Action Global
|
||
|
||
### Phase 1 : Résolutions Critiques (Avant Implémentation)
|
||
|
||
| # | Tâche | Responsable | Effort | Deadline |
|
||
|---|-------|-------------|--------|----------|
|
||
| 1 | ✅ Créer ADR-019 (Notifications) | Architecture | 2h | ✅ Fait |
|
||
| 2 | ✅ Mettre à jour ADR-002 (Pre-buffering) | Architecture | 1h | ✅ Fait |
|
||
| 3 | Implémenter WebSocket backend | Backend Lead | 3j | Sprint 1 |
|
||
| 4 | Implémenter Pre-buffer mobile | Mobile Lead | 2j | Sprint 1 |
|
||
|
||
### Phase 2 : Résolutions Importantes (Sprint 1-2)
|
||
|
||
| # | Tâche | Responsable | Effort | Statut |
|
||
|---|-------|-------------|--------|--------|
|
||
| 5 | ✅ Décision souveraineté (Zitadel self-host) | CTO | 1h | ✅ **Fait** |
|
||
| 6 | Package geo types (PostGIS) | Backend | 1j | ⏳ Sprint 2 |
|
||
| 7 | Cache 2 niveaux (Redis + SQLite) | Backend + Mobile | 3j | ⏳ Sprint 2 |
|
||
| 8 | Stratégie permissions progressive | Mobile | 2j | ⏳ Sprint 2 |
|
||
|
||
### Phase 3 : Résolutions Modérées (Sprint 3-5)
|
||
|
||
| # | Tâche | Responsable | Effort | Deadline |
|
||
|---|-------|-------------|--------|----------|
|
||
| 9-15 | Clarifications ADR/Règles | Tech Writer | 5j | Sprint 3-4 |
|
||
| 16 | Réorganisation features BDD | QA Lead | 2j | Sprint 4 |
|
||
| 17 | Optimisation CI/CD path filters | DevOps | 1j | Sprint 5 |
|
||
|
||
---
|
||
|
||
## Métriques de Suivi
|
||
|
||
| Métrique | Valeur Initiale | Cible | Actuel |
|
||
|----------|----------------|-------|--------|
|
||
| Incohérences CRITICAL | 2 | 0 | ✅ **0** (2/2 résolues) |
|
||
| Incohérences HIGH | 4 | 0 | ⏳ **3** (1/4 résolue) |
|
||
| Incohérences MODERATE | 8 | ≤2 | ⏳ 8 |
|
||
| ADR à jour | 66% (12/18) | 100% | ⏳ 78% (14/18) |
|
||
| Coverage documentation | N/A | >90% | ⏳ 80% |
|
||
|
||
**Dernière mise à jour** : 2026-01-30
|
||
|
||
---
|
||
|
||
## Contacts et Ressources
|
||
|
||
- **Analyse complète** : Ce document
|
||
- **ADR-019** : `/docs/adr/019-notifications-geolocalisees.md`
|
||
- **ADR-002 (mis à jour)** : `/docs/adr/002-protocole-streaming.md`
|
||
- **Questions** : Créer une issue GitHub avec tag `[architecture]`
|
||
|
||
---
|
||
|
||
**Prochaine revue** : 2026-02-15 (après Sprint 2)
|