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

docs/adr/019-notifications-geolocalisees.md

@@ -65,6 +65,8 @@ Architecture hybride en **2 phases** :
 
 ## Alternatives considérées
 
+### Architecture de délivrance (serveur vs local)
+
 | Option | Fonctionne offline | Batterie | Complexité | Limite POI | Précision |
 |--------|-------------------|----------|------------|------------|-----------|
 | **WebSocket + FCM (Phase 1)** | ❌ Non | ⭐ Optimale | ⭐ Faible | ∞ | ⭐⭐ Bonne |
@@ -72,6 +74,17 @@ Architecture hybride en **2 phases** :
 | Polling GPS continu | ⭐ Oui | ❌ Critique | ⭐ Faible | ∞ | ⭐⭐⭐ Excellente |
 | **Hybride (Phase 1+2)** | ⭐ Oui | ⭐ Adaptative | ⚠️ Moyenne | ∞/20 | ⭐⭐⭐ Excellente |
 
+### Fournisseurs de push notifications
+
+| Provider | Fiabilité | Coût MVP | Coût 100K users | Self-hosted | Vendor lock-in | Verdict |
+|----------|-----------|----------|-----------------|-------------|----------------|---------|
+| **Firebase (choix)** | 99.95% | **0€** | **0€** | ❌ Non | 🔴 Fort (Google) | ✅ Optimal MVP |
+| OneSignal | 99.95% | 0€ | 500€/mois | ❌ Non | 🔴 Fort | ❌ Plus cher |
+| Pusher Beams | 99.9% | 0€ | 300€/mois | ❌ Non | 🔴 Fort | ❌ Niche |
+| Custom WS + APNS/FCM | Votre charge | 5€ | 100€+ | ✅ Oui | 🟢 Aucun | ⚠️ Complexe |
+| Novu (open source) | 99.9% | 15€ | 50€ | ✅ Oui | 🟢 Aucun | 🟡 Phase 2 |
+| Brevo API | 99.9% | 0€ | 49€ | ✅ Oui | 🟢 Aucun | ❌ Email seulement |
+
 ## Justification
 
 ### Pourquoi WebSocket et pas HTTP long-polling ?
@@ -87,6 +100,37 @@ Architecture hybride en **2 phases** :
 - **Batterie** : Utilise les mécanismes système (Google Play Services)
 - **Cross-platform** : API unifiée iOS/Android
 
+### Incohérence acceptée : Firebase vs self-hosted (ADR-008, ADR-017)
+
+**Problème** : RoadWave promeut 100% self-hosted + souveraineté française, mais Firebase = dépendance Google Cloud.
+
+**Réalité technique** : Notifications natives requièrent obligatoirement Google/Apple
+- **APNS (Apple)** : Seul protocole pour notifications iOS → dépendance Apple inévitable
+- **FCM (Google)** : Meilleur protocole Android (vs Huawei HMS, Samsung)
+
+**Alternatives analysées** :
+1. **Custom WebSocket** (self-hosted) :
+   - ✅ Zéro dépendance externe
+   - ❌ 150+ heures dev (2-3 sprints)
+   - ❌ Maintien de la reliability en-house
+   - ❌ Toujours besoin d'appeler APNS/FCM de toute façon
+
+2. **Novu (open source self-hosted)** :
+   - ✅ Self-hostable
+   - ❌ Jeune (moins mature)
+   - ❌ Toujours wrapper autour APNS/FCM
+   - ❌ Overhead sans gain réel
+
+3. **OneSignal / Pusher** :
+   - ❌ Même vendor lock-in que Firebase
+   - ❌ Plus cher (500€+/mois @ 100K users)
+
+**Décision pragmatique** :
+- Firebase pour MVP : gratuit + fiabilité + time-to-market
+- **Mitigation vendor lock-in** : Utiliser abstraction layer (`NotificationProvider` interface)
+- **Exit path documenté** : Migration vers custom solution < 1 sprint si besoin futur
+- **Probabilité de changement** : Très basse (MVP gratuit, pas d'incitation financière)
+
 ### Pourquoi limiter le geofencing local à Phase 2 ?
 
 - **Complexité** : Permissions "Always Location" difficiles à obtenir (taux d'acceptation ~30%)
@@ -101,10 +145,17 @@ Architecture hybride en **2 phases** :
 - ✅ Fonctionne avec HLS pour l'audio (pas de conflit avec ADR-002)
 - ✅ Scalable : Worker backend peut gérer 10K utilisateurs/seconde avec PostGIS indexé
 - ✅ Mode offline disponible en Phase 2 sans refonte
+- ✅ Coût zéro jusqu'à millions de notifications (gratuit MVP + croissance)
+- ✅ Géolocalisation natif iOS/Android optimisé (moins de batterie)
 
 ### Négatives
 
-- ❌ Dépendance à Firebase (vendor lock-in) - mitigée par l'utilisation de l'interface FCM standard
+- ⚠️ **Dépendance Google (Firebase)** : Contradictoire avec ADR-008 (self-hosted) + ADR-017 (souveraineté FR)
+  - Mitigé par abstraction layer (`NotificationProvider` interface) → swap facile si besoin
+  - Exit path documenté pour migration custom (< 1 sprint)
+- ⚠️ **Données utilisateur chez Google** : Tokens FCM, timestamps notifications
+  - Risque RGPD : Nécessite DPA Google valide
+  - À consulter avec DPO avant déploiement production
 - ❌ WebSocket nécessite maintien de connexion (charge serveur +10-20%)
 - ❌ Mode offline non disponible au MVP (déception possible des early adopters)
 
@@ -115,6 +166,57 @@ Architecture hybride en **2 phases** :
 - **ADR-012 (Architecture Backend)** : Ajouter un module `geofencing` avec worker dédié
 - **ADR-014 (Frontend Mobile)** : Intégrer `firebase_messaging` (Flutter) et gérer permissions
 
+## Abstraction Layer (Mitigation Vendor Lock-in)
+
+Pour minimiser le coût de changement future, implémenter une interface abstraite :
+
+```go
+// backend/internal/notification/provider.go
+type NotificationProvider interface {
+    SendNotification(ctx context.Context, token, title, body, deepLink string) error
+    UpdateToken(ctx context.Context, userID, newToken string) error
+}
+
+// backend/internal/notification/firebase_provider.go
+type FirebaseProvider struct {
+    client *messaging.Client
+}
+
+func (p *FirebaseProvider) SendNotification(ctx context.Context, token, title, body, deepLink string) error {
+    message := &messaging.Message{
+        Notification: &messaging.Notification{
+            Title: title,
+            Body:  body,
+        },
+        Data: map[string]string{
+            "deepLink": deepLink,
+        },
+        Token: token,
+    }
+    _, err := p.client.Send(ctx, message)
+    return err
+}
+
+// backend/internal/notification/service.go
+type NotificationService struct {
+    provider NotificationProvider  // ← Interface, pas concrète
+    repo     NotificationRepository
+}
+```
+
+**Bénéfice** : Swap Firebase → Custom/Novu sans changer business logic.
+
+```go
+// Futur : switch facilement
+var provider NotificationProvider
+
+if config.Provider == "firebase" {
+    provider = &FirebaseProvider{...}
+} else if config.Provider == "custom" {
+    provider = &CustomProvider{...}
+}
+```
+
 ## Métriques de Succès
 
 - Latence notification < 60s après entrée dans rayon 200m