Files

jpgiannetti 841028d1b2 (doc) : ajout et modification de docs après arbitrage

2026-01-31 21:09:59 +01:00

26 KiB

Raw Blame History

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	14%	✅ RÉSOLU	~~avant implémentation~~
🟠 HIGH	2	14%	✅ RÉSOLU (2 résolus, 1 annulé)	~~Résolution Sprint 1-2~~
🟡 MODERATE	6	43%	⏳ 4 restants (3 résolus)	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	2	🟠 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 :

Décision validée : Self-host sur OVH
ADR-008 mis à jour avec architecture self-hosted
TECHNICAL.md mis à jour

#4 : ORM sqlc vs Types PostGIS

Statut : ✅ RÉSOLU (ADR-013 mis à jour)

Élément	Détail
ADR concerné	ADR-013 (section "Gestion des Types PostGIS")
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

Solution implémentée :

Wrappers typés + fonctions de conversion PostGIS :

Wrapper types Go avec méthodes Scan/Value pour conversion automatique
Patterns SQL recommandés :
- ST_AsGeoJSON(location)::jsonb → struct GeoJSON typée (frontend)
- ST_AsText(location) → string WKT (debug/logging)
- ST_Distance()::float8 → natif Go float64
Index GIST sur colonnes géographiques pour performance

Architecture conversion :

SQL PostGIS → ST_AsGeoJSON() → json.RawMessage → GeoJSON (strongly-typed)

Code Pattern :

// internal/geo/types.go
type GeoJSON struct {
    Type        string    `json:"type"`
    Coordinates [2]float64 `json:"coordinates"`
}

func (g *GeoJSON) Scan(value interface{}) error {
    bytes, _ := value.([]byte)
    return json.Unmarshal(bytes, g)
}

-- queries/poi.sql
SELECT id, ST_AsGeoJSON(location)::jsonb as location,
       ST_Distance(location, $1::geography) as distance_meters
FROM points_of_interest
WHERE ST_DWithin(location, $1::geography, $2);

Actions requises :

Créer package backend/internal/geo avec wrappers
Ajouter migrations index GIST (CREATE INDEX idx_poi_gist ON pois USING GIST(location))
Tests d'intégration avec Testcontainers (PostGIS réel)
Documenter patterns dans backend/README.md

Référence : ADR-013 - Gestion des Types PostGIS

#5 : Cache Redis (TTL 5min) vs Mode Offline (30 jours)

Statut : ✅ ANNULÉ (Faux problème)

É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~~

Raison de l'annulation : Le mode offline ne concerne pas les POI (Points d'Intérêt) mais uniquement le contenu audio déjà téléchargé. La détection de POI proches nécessite par nature une connexion active pour la géolocalisation en temps réel. Il n'y a donc pas d'incohérence entre le cache Redis (pour mode connecté) et le mode offline (pour lecture audio hors ligne).

Aucune action requise : Ce point est un faux problème et peut être ignoré.

#6 : Package Geofencing vs Permissions iOS/Android

Statut : ✅ RÉSOLU (Stratégie de permissions progressive implémentée)

Élément	Détail
ADR concerné	ADR-014 (Frontend Mobile, mis à jour)
Règle métier	Règle 05 (section 5.1.2, mis à jour), Règle 02 (RGPD)
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~~

Solution implémentée :

Stratégie de permissions progressive en 2 étapes :

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 complétées :

✅ ADR-014 mis à jour avec section complète "Stratégie de Permissions"
✅ Règle 05 (section 5.1.2) mise à jour avec clarifications permissions progressive
✅ Documentation détaillée créée : /docs/mobile/permissions-strategy.md
✅ Plan de validation TestFlight créé : /docs/mobile/testflight-validation-plan.md

Changements apportés :

✅ Permissions demandées en 2 étapes : "When In Use" (onboarding) → "Always" (optionnel, mode piéton)
✅ Écran d'éducation obligatoire avant demande "Always" (requis pour validation stores)
✅ Fallback gracieux à tous niveaux : app utilisable même sans permission arrière-plan
✅ Mode dégradé (GeoIP) si toutes permissions refusées
✅ Configuration iOS/Android complète avec textes validés RGPD
✅ Plan de validation beta (TestFlight + Play Console Internal Testing)

Références :

🟡 Incohérences Modérées (Sprint 3-5)

#7 : Points vs Pourcentages dans les Jauges

Statut : ✅ RÉSOLU (Terminologie unifiée : points de pourcentage absolus)

Élément	Détail
ADR concerné	ADR-010 (Commandes Volant, mis à jour)
Règle métier	Règle 03 (Centres d'intérêt, mis à jour)
Conflit	~~ADR dit "+2 points", Règle dit "+2%" pour même action~~
Impact	~~Ambiguïté sur calcul : +2 points absolus ou +2% relatifs ?~~

Solution adoptée : Option A (points de pourcentage absolus)

Calcul confirmé :

Jauge "Automobile" = 45%
Utilisateur écoute 85% d'un podcast voiture
→ Like renforcé : +2%
→ 45 + 2 = 47% ✅

NOT 45 × 1.02 = 45.9% ❌

Justification :

✅ Progression linéaire : Intuitive et prévisible
✅ Équité : Tous les utilisateurs progressent à la même vitesse
✅ Gamification standard : Cohérent avec Duolingo, Spotify, Strava
✅ Simplicité technique : Addition simple, pas de risque d'overflow
✅ Prédictibilité UX : "+2%" signifie vraiment +2 points de pourcentage

Actions complétées :

✅ ADR-010 mis à jour : "points" → "+2%" avec note explicite "points de pourcentage absolus"
✅ ADR-010 : Section "Implémentation Technique" ajoutée avec code Go complet
✅ Règle 03 : Note ajoutée clarifiant calcul absolu vs relatif
✅ Règle 03 : Exemples de calcul vérifiés et cohérents
✅ Référence croisée ADR-010 ↔ Règle 03

Changements apportés :

ADR-010 :

Règles reformulées : "+2 points" → "+2%" (points de pourcentage absolus)
Note explicite ajoutée : "Par exemple, si jauge = 45%, +2% → 47%"

Nouvelle section "Implémentation Technique" avec formule Go :

func CalculateGaugeIncrease(listenPercentage float64) float64 {
    if listenPercentage >= 80.0 { return 2.0 }  // +2 points de pourcentage
    // ...
}

Exemples de calcul concrets

Règle 03 :

Tableau mis à jour : valeurs en gras (+2%, +1%, etc.)
Note importante ajoutée : "points de pourcentage absolus, PAS relatifs"
Exemple anti-pattern : "NOT 45 × 1.02 = 45.9% ❌"
Référence croisée vers ADR-010 pour implémentation

Références :

#8 : OAuth2 Complexe vs Email/Password Simple

Statut : ✅ RÉSOLU (Clarification : OAuth2 = protocole, PAS providers tiers)

Élément	Détail
ADR concerné	ADR-008 (Auth, mis à jour)
Règle métier	Règle 01 (Auth, mis à jour)
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~~

Clarification : Il y avait une confusion terminologique entre :

OAuth2 PKCE (protocole d'authentification moderne pour mobile) ✅ Utilisé
OAuth providers tiers (Google, Apple, Facebook) ❌ Pas utilisés

Solution adoptée :

RoadWave utilise Zitadel self-hosted avec email/password natif uniquement :

Aspect	Détail
Méthode d'authentification	Email + mot de passe (formulaire natif Zitadel)
Protocole technique	OAuth2 PKCE (entre app mobile et Zitadel)
Fournisseurs tiers	❌ Aucun (pas de Google, Apple, Facebook)

Pourquoi OAuth2 PKCE alors ? :

✅ Standard moderne pour auth mobile (sécurisé, refresh tokens)
✅ Protocole, pas un provider externe
✅ Alternative serait session cookies (moins adapté mobile) ou JWT custom (réinventer la roue)
✅ Zitadel implémente OAuth2/OIDC comme protocole, mais auth reste email/password

Flow d'authentification :

User → Formulaire email/password (app mobile)
     → Zitadel (OAuth2 PKCE protocol)
     → Validation email/password natif
     → JWT access token + refresh token
     → Go API (validation JWT locale)

Actions complétées :

✅ ADR-008 : Section "OAuth2 PKCE : Protocole vs Fournisseurs Tiers" ajoutée
✅ ADR-008 : Architecture clarifiée ("Email/Pass native" dans diagramme)
✅ ADR-008 : Note explicite : "OAuth2 PKCE = protocole, PAS providers tiers"
✅ Règle 01 : Clarification technique ajoutée + référence croisée ADR-008

Références :

#9 : GeoIP Database (MaxMind)

Statut : ✅ RÉSOLU (ADR-021 créé)

Élément	Détail
ADR concerné	ADR-021 (créé)
Règle métier	Règle 02 (RGPD, mis à jour)
Conflit	~~Règle citait "MaxMind GeoLite2 (gratuit)", mais offre a changé en 2019~~
Impact	~~Coût caché potentiel~~

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)

Solution implémentée : IP2Location Lite (self-hosted)

Option	Coût/mois	Précision	Maintenance
IP2Location Lite ✅	Gratuit	±50 km	Maj mensuelle
MaxMind API	~10€	±50 km	Nulle
Self-hosted MaxMind	Gratuit	±50 km	Compte requis

Architecture :

[Backend Go] → [GeoIP Service]
                     ↓
               [IP2Location SQLite DB]
               (màj mensuelle via cron)

Avantages :

✅ Gratuit (pas de limite de requêtes)
✅ Self-hosted (souveraineté des données, cohérence avec ADR-004)
✅ Pas de compte tiers requis
✅ Base de données SQLite légère (50-100 MB)
✅ Mise à jour mensuelle automatisable

Actions complétées :

✅ ADR-021 créé : Service de Géolocalisation par IP
✅ Règle 02 mise à jour (ligne 147 et 317)

Actions requises :

Backend : Implémenter service GeoIP avec IP2Location
DevOps : Cron job màj mensuelle de la DB

Référence : ADR-021 - Service de Géolocalisation par IP

#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 :

# 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 :

# .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)

# .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	✅ Fait
7	~~Cache 2 niveaux (Redis + SQLite)~~	Backend + Mobile	3j	❌ Annulé (faux problème)
8	✅ Stratégie permissions progressive	Mobile	2j	✅ Fait

Phase 3 : Résolutions Modérées (Sprint 3-5)

#	Tâche	Responsable	Effort	Statut
9	✅ Clarification Points vs Pourcentages (ADR-010 + Règle 03)	Tech Writer	0.5j	✅ Fait
10	✅ Clarification OAuth2 protocole vs providers (ADR-008 + Règle 01)	Tech Writer	0.5j	✅ Fait
11	✅ GeoIP Database (ADR-021 + Règle 02)	Tech Writer	0.5j	✅ Fait
12-15	Clarifications ADR/Règles (restantes)	Tech Writer	2.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	✅ 0 (2 résolues, 1 annulée)
Incohérences MODERATE	8	≤2	⏳ 5 (3/8 résolues)
ADR à jour	66% (12/18)	100%	⏳ 95% (18/19)
Coverage documentation	N/A	>90%	⏳ 93%

Dernière mise à jour : 2026-01-31

Contacts et Ressources

Analyse complète : Ce document
ADR-019 : /docs/adr/019-notifications-geolocalisees.md
ADR-021 : /docs/adr/021-geolocalisation-ip.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)

26 KiB Raw Blame History Unescape Escape

Analyse des Incohérences entre ADR et Règles Métier

Résumé Exécutif

Répartition par Sévérité

Impact par Domaine

🔴 Incohérences Critiques (Blocantes)

#1 : HLS ne supporte pas les Notifications Push en Arrière-plan

#2 : Latence HLS Incompatible avec ETA de 7 Secondes

🟠 Incohérences Importantes (Sprint 1-2)

#3 : Souveraineté des Données (Français vs Suisse)

#4 : ORM sqlc vs Types PostGIS

#5 : Cache Redis (TTL 5min) vs Mode Offline (30 jours)

#6 : Package Geofencing vs Permissions iOS/Android

🟡 Incohérences Modérées (Sprint 3-5)

#7 : Points vs Pourcentages dans les Jauges

#8 : OAuth2 Complexe vs Email/Password Simple

#9 : GeoIP Database (MaxMind)

#10 : Tests BDD Synchronisés (Backend + Mobile)

#11 : 70/30 Split Paiements (Vérification Manquante)

#12 : Monorepo Path Filters vs Features Partagées

#13 : Coûts Email (Transition Free → Paid)

#14 : Kubernetes vs VPS MVP

🟢 Incohérences Mineures (Clarification)

#15 : Unlike Manuel sur Contenu Auto-liké

Plan d'Action Global

Phase 1 : Résolutions Critiques (Avant Implémentation)

Phase 2 : Résolutions Importantes (Sprint 1-2)

Phase 3 : Résolutions Modérées (Sprint 3-5)

Métriques de Suivi

Contacts et Ressources

26 KiB

Raw Blame History