# STRATÉGIE COMMERCIALE — EasyPhone & objets connectés (SAS NewAppAI)

> Version 1.0 — 01/10/2026 — Document de travail (analyse + propositions)
> Sources : études marché 2026 (autonomag, toute-une-generation, Xerfi), CNIL, décret n°2026-209, e-santé.gouv.fr
> Convention : ✅ = fait/vérifié · 🎯 = proposition · ⚠️ = risque/à vérifier

---

## 1. OÙ ON EN EST (état réel, vérifié le 01/10)

| Actif | État | Détail |
|---|---|---|
| APK **Senior** (kiosk) | ✅ | polices 6 tailles, contact unique rond + défilement, verrouillage géométrique, décrocher par glissement, faille BACK corrigée, boutons VIDEO/PHOTO/LOISIR masquables (admin) |
| APK **Famille** (dashboard) | ✅ | check-in, alertes, journal des demandes, appels visio/audio LiveKit, contacts à distance par consentement TTS, rôles (responsable/member/senior) |
| **PWA Famille** | ✅ | build web (build/web) servi, raccourci posé sur le Honor — ⚠️ encore **HTTP** → pas installable en vraie PWA (Chrome exige HTTPS) |
| **Pont objets connectés** | ✅ | Gadgetbridge opérationnel : 19 030 mesures réelles importées, bande testée, specs wearables + algo chute prêts |
| **Confiance/RGPD** | ✅ | Consentement 4 temps (TTS → OUI/NON géants → révocable, silence = refus), données senior en local SQLite, GB sans permission réseau |
| Distribution | ❌ | pas encore de vitrine, pas de paiement, pas d'hébergement public |

---

## 2. LE MARCHÉ (chiffres sourcés 2026)

| Indicateur | Chiffre | Source |
|---|---|---|
| Silver economy France | **130 Md€** (2023), +4 à 6 %/an | Ministère Éco. via Autonomag |
| Abonnés téléassistance France | **900 000** | Autonomag 2026 |
| Prix téléassistance classique | 20-35 €/mois | marché |
| Prix mobile GPS / détection chute | 35-60 € / 30-50 €/mois | marché |
| Prix « connectée » (capteurs passifs) | 40-80 €/mois | marché |
| Chutes >65 ans | **1 toutes les 3 s**, 1re cause d'hospitalisation traumatique, **12 000 décès/an** | toute-une-génération |
| Effet téléassistance | **÷3 le risque de décès** après chute non détectée | idem |
| Aides cumulables | APA, CARSAT, AGIRC-ARRCO, Département, CCAS, associations + **crédit d'impôt 50 %** | idem |

**Lecture stratégique :** le marché paie déjà 20-80 €/mois pour un *médaillon avec bouton*. On vend un *système familial complet* (app kiosk senior + dashboard famille + visio + objets connectés + consentement) dans la même fourchette → **on n'a pas à se battre sur le prix, on gagne sur l'inclus**.

---

## 3. PROPOSITIONS STRATÉGIQUES & INNOVANTES (le cœur)

### 🎯 P1 — « Le bracelet offert, l'abonnement paie » (couteau-suicide, standard du secteur mais mal fait chez les concurrents)
- **Principe :** bracelet/objet connecté **fourni gratuitement** avec engagement 24 mois (comme les box mobiles).
- **Innovation réelle :** chez les concurrents, le bracelet est acheté 100-200 € = le premier « non » du senior. Chez toi, **coût d'entrée = 0**.
- **Chiffres :** coût bracelet ~25-40 € (JCVital/Colmi en direct usine) amorti en **2 mois** d'abonnement 19,90 €.
- **ROI :** LTV 24 mois ≈ **480 €** pour un CAC matériel de ~35 € → ratio ~14:1.
- **Faisable avec l'existant :** pont Gadgetbridge = déjà fait, l'objet se branche sans dev.

### 🎯 P2 — « Vendre le dossier d'aides, pas l'abonnement » (le vrai différenciateur FR)
- **Principe :** la majorité des seniors **ne connaît pas** les aides (APA, CARSAT, crédit d'impôt 50 %, CCAS). On ne vend pas « 19,90 €/mois », on vend **« votre dossier d'aides est rempli pour vous »**.
- **Innovation :** aucun concurrent n'industrialise le montage de dossier. Tu livres un **kit tout prêt** : formulaire APA pré-rempli, attestation crédit d'impôt, lettre CCAS.
- **Effet :** prix perçu divisé par 2 → conversion ×2 à ×3, et tu deviens **le prestataire de référence des caisses de retraite** (canal B2B gratuit).
- **Action :** 1 page « Aides disponibles » + 1 personne (ou outil) pour monter les dossiers. ⚠️ À vérifier : conditions exactes d'éligibilité du dispositif (alerteur + boîtier) au crédit d'impôt.

### 🎯 P3 — PWA famille = moteur d'acquisition viral à coût zéro
- **Principe :** la PWA se partage en 1 lien (Telegram/famille). Chaque famille = en moyenne **3-5 aidants** (fratrie, conjoint, aidant).
- **Mécanique :** le « responsable » invite les autres → 1 acquisition = 4 comptes potentiels. La **gratuité de base** (PWA) et la **payance de la sécurité** (alertes, visio, journal) est le point de bascule.
- **Action :** bouton « Inviter un proche » + code famille (déjà le principe d'appairage 6 caractères).
- ⚠️ Condition : **HTTPS obligatoire** → déploiement DEV en HTTPS avant toute diffusion externe.

### 🎯 P4 — Le différenciateur que personne n'a : le **moteur CNV** (clé de voûte produit)
- **Principe :** tu possèdes déjà un moteur de Communication Non Violente (projet Sérénité). Dans EasyPhone : le message d'alerte/relance est **reformulé par l'IA en langage bienveillant** avant d'être envoyé au senior ou à la famille.
- **Pourquoi c'est innovant :** les téléassistances envoient des SMS bruts (« ALERTE : chute détectée »). Toi : « Maman a besoin d'un petit coup de main, tout va bien, elle attend un appel. » → **moins d'anxiété, plus d'ouverture, rétention ×2**.
- **C'est le seul actif que tes concurrents ne peuvent pas copier vite** (un copieur recopie une app en 3 mois, pas un moteur IA + son corpus).

### 🎯 P5 — Modèle « service » facturé APRÈS aides : prix affiché net
- **Principe :** affichage **« 19,90 €/mois → 9,95 € après crédit d'impôt »** partout (site, offres, emails).
- **Innovation :** personne n'affiche le prix net en grand. C'est un choc psychologique positif + 100 % honnête.
- **ROI :** même marge, conversion doublée.

### 🎯 P6 — B2B white-label : revendre la plateforme aux pros (EHPAD, AD, assistantes familiales, mutuelles)
- **Principe :** même app, **leur marque**, facturation à l'établissement, senior = utilisateur final.
- **Innovation :** les petites AD (aide à domicile) n'ont aucun outil digital — tu leur donnes un dashboard « mes 30 clients » avec alertes en temps réel.
- **ROI :** 1 contrat B2B = 30-100 seniors → revenu récurrent prévisible, CAC partagé. Ex. 8 €/mois × 50 clients × 12 = **4 800 €/an par contrat**.
- **Prérequis :** RGPD complet (phase 3) + sous-traitance formalisée (tu es sous-traitant du professionnel de santé).

### 🎯 P7 — « Marketplace d'objets certifiés EasyPhone » (zéro stock)
- **Principe :** tu **ne fabriques pas**. Tu **certifies et déployes** : bracelets, bagues, brassards tension, capteurs — testés par toi, garantis compatibles avec l'app.
- **Innovation :** tu transformes ta faiblesse (pas d'usine, pas de stock) en force (le client choisit, tu gardes 15-25 % de marge de courtage, **aucun immobilisation**).
- **Preuve :** les specs wearables + pont Gadgetbridge = la compatibilité est déjà réelle et démontrée (19 030 mesures).

### 🎯 P8 — Bundle « Famille répartie » : 1 abonnement, N proches
- **Principe :** prix identique que la famille soit 2 ou 8 aidants → incite au partage → chaque aidant devient un **prescripteur** de son propre foyer (« ça, je l'installe chez ma belle-mère »).
- **Coût marginal :** ~0 (le serveur supporte déjà les rôles).

### 🎯 P9 — Preuve sociale industrielle : « Le chantier grand public »
- **Principe :** ta propre famille = **cas d'étude publié** (avec accord) : « Maman, 78 ans, utilise EasyPhone depuis le 01/10/2026 — voici son journal de check-ins anonymisé ».
- **Innovation :** aucune boîte n'ose montrer l'usage réel. Une démo **live et datée** (dashboards réels, jamais simulés — ta règle) vaut 10 pages de marketing.
- **Action :** page de démo publique avec **données factices étiquetées clairement** (règle : toujours distinguer live vs démo).

### 🎯 P10 — Positionnement « anti-gadget » (l'angle d'auteur)
- **Principe :** les concurrents vendent de la **technologie**. Toi vends **« être présent à distance sans être intrusif »** — le consentement 4 temps, la local-first, le zéro réseau du mode senior = **arguments de guerre** dans un marché où le peur-vend.
- **Discours type :** « Vos données de santé ne quittent pas la maison. Vous, vous choisissez. »
- **C'est l'inverse exact des pratiques de masse (objets connectés chinois qui remontent tout au fabricant)** → et c'est vrai (vérifié : GB sans permission réseau, SQLite locale).

---

## 4. SÉCURITÉ / ANTI-COPIE — point par point

⚠️ **Vérité d'abord :** une APK se reverse-engineere. **Aucune technique ne protège définitivement.** Ce qui suit est une stratégie de **dissuasion + déplacement de la valeur**.

| # | Levier | Principe concret | Coût | Faire quand |
|---|---|---|---|---|
| 1 | **Valeur côté serveur** | facturation, règles métier, seuils d'alerte, contenus Loisir, IA = **jamais dans l'APK** | 0 | 🎯 dès maintenant (c'est déjà partiellement le cas) |
| 2 | **Appairage matériel ↔ compte** | l'objet connecté porte un secret ; APK copiée sans compte+objet = écran vide | faible | 🎯 au lancement (appairage 6 car. existant à renforcer côté serveur) |
| 3 | **Obfuscation build** | `flutter build --obfuscate --split-debug-info` + signature unique + updates uniquement via ta source | 0 | 🎯 build de prod |
| 4 | **Dissuasion légale** | CGU (interdiction reverse engineering) + **marque déposée INPI** (~190 €/classe) | ~200 € | 🎯 avant communication publique |
| 5 | **Course à l'itération** | vitesse de feature + support + confiance = le copieur te suit à 6-12 mois de retard | 0 | en continu |

**Ce que je ne te promets pas :** un logiciel in-copiable. Quiconque te le vend ment. Le vrai bouclier = **le serveur, la marque, et la vitesse**.

---

## 5. RGPD — point par point, 3 phases

**Règle juridique clé (source CNIL) :** données **exclusivement locales, sans connexion extérieure = hors RGPD**. Dès qu'une donnée de santé sort de l'appareil → RGPD + **hébergement certifié HDS obligatoire** (surcoût 8-15 k€/an + 3-8 k€ de dev).

### Phase 1 — Lancement (quasi gratuit) ✅ déjà aligné
- [x] Mode senior local-first (SQLite local) — **déjà fait**
- [x] GB sans permission réseau — **déjà fait**
- [x] Consentement TTS OUI/NON, silence = refus — **déjà fait** (au-dessus du marché)
- [ ] Notice d'information 1 page (qui, quoi, durée, droits)
- [ ] Minimisation : auditer chaque champ collecté (la CNIL sanctionne le « au cas où »)

### Phase 2 — Dès la 1re sync famille (RGPD plein)
- [ ] Responsable de traitement = SAS NewAppAI (statut, siège, contact DPO)
- [ ] Consentement **granulaire et SÉPARÉ des CGU** — ⚠️ **interdiction formelle** : une seule case = CGU + données santé (faute sanctionnée par la CNIL)
- [ ] Base légale : consentement explicite art. 9.2.a (données santé)
- [ ] Durées de conservation limitées + effacement physique ≤ 30 jours (backups inclus)
- [ ] **Bouton « Exporter mes données »** (JSON/CSV) — obligation de portabilité
- [ ] Registre des traitements
- [ ] **Hébergement en UE** ✅ (DEV/PJP = Europe) — le décret 2026-209 impose la territorialisation des données de santé en UE/EEE

### Phase 3 — Objets connectés + données de santé réelles (vitals, chute, médicaments)
- [ ] **Hébergement HDS certifié** ← **le gros poste budgétaire : 8-15 k€/an. À budgétiser MAINTENANT, pas en cours de route**
- [ ] **AIPD** (analyse d'impact) avant mise en prod
- [ ] Notification des violations sous **72 h**
- [ ] Chiffrement : TLS 1.3 / AES-256 au repos / Keystore mobile
- [ ] Mode **enfant** = mineurs → consentement responsable légal, données strictement nécessaires
- [ ] Interdiction absolue (L.1111-8) : **aucune cession ni monétisation des données de santé** → le business case DOIT être l'abonnement, jamais la data

⚠️ **Frontière « bien-être » vs « santé »** : ton app parle chute, médicaments, ECG → **considère-toi en santé**. Ne construis pas le ROI sur l'hypothèse inverse.
🎯 **Argument de vente :** la conformité EST un avantage concurrentiel — en B2B (EHPAD, mutuelles), on te demandera ces preuves avant de signer.

---

## 6. PLAN D'ACTION 30 / 60 / 90 jours

**J+0 → J+30 (tests avant déplacement — décision Antoine)**
1. ✅ Terminer les tests sur les 2 téléphones (radio, dashboard famille, police « Moyenne »)
2. 🎯 HTTPS sur DEV (Traefik + Let's Encrypt) → PWA installable + URL publique conforme à ta règle « déploiement externe »
3. 🎯 Sondage d'éligibilité crédit d'impôt / APA (le levier P2 repose dessus)
4. 🎯 10 familles pilotes (connaissances) = preuve sociale + bug bounty naturel

**J+30 → J+60**
5. 🎯 Vitrine simple + paiement Stripe (offre : bracelet offert + 19,90 €/mois → 9,95 € après aides)
6. 🎯 Kit dossier d'aides (P2) : formulaire APA pré-rempli + attestation crédit d'impôt
7. 🎯 Marque déposée + CGU + notice RGPD phase 2
8. 🎯 Build de prod obfusqué + appairage matériel serveur

**J+60 → J+90**
9. 🎯 1er contrat B2B pilote (AD/EHPAD local) en white-label
10. 🎯 Moteur CNV dans les alertes EasyPhone (P4)
11. 🎯 Passage HDS si les données de santé sortent réellement (décision budgétaire)

---

## 7. RISQUES HONNÊTES (ce que je ne garantis pas)

| Risque | Sévérité | Parade |
|---|---|---|
| APK copiée | moyenne | serveur + marque + vitesse (§4) — **pas d'obstacle technique durable** |
| Coût HDS (8-15 k€/an) | forte | phase 1 local-first → reporter au moment où c'est nécessaire, **mais le budgéter maintenant** |
| Éligibilité aides NON confirmée | forte | ⚠️ **à vérifier AVANT** d'afficher « 9,95 € après aides » (P2/P5 s'effondrent sans ça) |
| Adoption senior (peur du smartphone) | forte | kiosk = déjà le bon angle ; la vraie barrière = l'installation → service « on installe pour vous » |
| Concurrence 900 000 abonnés / 15+ acteurs | moyenne | on ne les attaque pas sur leur terrain (médaillon) — on élargit le marché (famille) |
| PWA HTTP non installable | faible | HTTPS DEV (J+30) |

---

## 8. SYNTHÈSE EN 5 LIGNES

1. **On ne vend pas une app, on vend une tranquillité familiale récurrente** : 19,90 €/mois dans une fourchette marché 20-80 € déjà acceptée.
2. **Le bracelet offert + le dossier d'aides monté pour le client** = les 2 leviers de conversion les plus puissants du marché français (P1 + P2).
3. **Le moteur CNV + le consentement 4 temps** = les seuls actifs non copiables rapidement (P4 + P10).
4. **Anti-copie : la valeur vit sur le serveur**, l'APK est un simple terminal (§4).
5. **RGPD par phases : local-first pour lancer gratuitement, HDS budgété avant que ça devienne obligatoire** (§5).

---

## 9. FEUILLE DE ROUTE RGPD (section vivante — mise à jour à chaque tour de discussion)

### 9.1 DÉCISIONS ACTUELLES (validées par Antoine)

| # | Décision | Statut |
|---|---|---|
| D1 | **Architecture** : APK senior (données locales SQLite, objet connecté BLE) + base serveur SaaS (France/UE) + APK/PWA Famille en **lecture d'une vue minimisée** (événements, jamais de valeurs brutes, pas d'export) | ✅ acté |
| D2 | **Alertes reformulées** — interdiction d'afficher « chute » / « médicament » ; formulaires douces, **paramétrables par l'aidant ET par le senior** (choix A : les deux) | ✅ acté |
| D3 | **3 niveaux de ton** : Doux (défaut) / Standard / Explicite + choix de la relation (maman, papa, grand-mère…) | ✅ acté |
| D4 | **Séparation code événement ↔ libellé affiché** : la base garde le code (`fall_suspected`, `med_routine_missed`) pour l'audit et la fiabilité ; l'affichage passe par `alert_templates` (événement, langue, ton, relation, texte) — **le libellé doux ne retire pas la qualification « donnée de santé » de l'événement stocké** | ✅ acté |
| D5 | **Push muet** : payload type uniquement, libellé construit dans l'app authentifiée (jamais d'info santé sur écran verrouillé) | ✅ acté |
| D6 | **Abonnement** : droits côté serveur (Stripe → table entitlements → licence JWT 7-14 j, heartbeat quotidien), relances 14-30 j ; **JAMAIS de coupure des alertes de sécurité pour impayé** (confort verrouillé d'abord, résiliation avec préavis avant toute coupure sécurité, kiosque 112 jamais bloqué) | ✅ acté |
| D7 | **Table de reformulation par défaut** | ✅ acté |
| D8 | **Sauvegarde E2EE hébergée chez nous (EU)** : le tél du senior chiffre la base **AVANT envoi** (AES-256, passphrase = code famille), le serveur ne stocke qu'un **blob chiffré illisible, AUCUNE clé côté serveur** ; + export fichier vers l'aidant en redondance ; + option compte Google/Apple du senior pour qui veut. **Sous condition juridique** : le juriste doit valider « stockage E2EE sans clé = hors HDS ? » (position ANS : *chiffrer ne dispense pas toujours* → risque résiduel assumé, au pire 8-15 k€/an, au mieux 0) | 🎯 acté sous condition |
| D9 | **Code de secours imprimé** remis à la vente (2ᵉ code famille) — sans lui, une sauvegarde E2EE = **données définitivement irrécupérables** en cas de perte des deux codes | 🎯 acté |
| D10 | **Cloud du senior créé à la livraison + changement de mot de passe obligatoire devant lui** (procédure humaine tracée, case de confirmation dans l'app au 1er lancement) → le compte devient 100 % le sien : sauvegarde = **traitement personnel hors RGPD (art. 2)**. **La destination du cloud n'a plus d'importance juridique** puisque le fichier .epbak est chiffré AVANT l'envoi (même Google ne voit que du chiffré → Google Drive 15 Go gratuit = choix par défaut). **Limites assumées** : (i) aucun moyen technique de VÉRIFIER le changement de mdp → procédure + preuve par la case tracée, (ii) mdp oublié = compte gelé → **protocole de récupération obligatoire** (email/tél de secours = aidant, fiche papier), (iii) Android ne sauvegarde PAS les bases d'app seul → export maison EasyPhone toujours requis | 🎯 acté |
| D11 | **Architecture finale sauvegarde (double filet)** : (1) **PRINCIPAL = cloud du senior** (hors champ RGPD, gratuit), (2) **SECOURS = notre coffre E2EE** D8 automatique quand le cloud senior n'est pas configuré (senior sans compte, refus…) → jamais de donnée lisible hors du tél, jamais de dépendance à un seul plan | 🎯 acté |

| Événement interne (jamais affiché tel quel) | Libellé FAMILLE (défaut « Doux ») | Libellé SENIOR |
|---|---|---|
| `fall_suspected` | « Prenez de vos nouvelles de {prénom} » | « Quelque chose s'est passé, prévenez la famille » |
| `med_routine_missed` | « Vérifiez si {prénom} a bien suivi sa routine de ce matin » | « Routine du matin non confirmée » |
| `no_activity` | « {prénom} n'a pas donné signe de vie depuis {n} h » | « Pas d'activité détectée » |
| `low_battery` | « L'appareil de {prénom} a besoin de recharge » | « Batterie faible » |
| `checkin_no` | « {prénom} a répondu « non » à son check-in » | idem |

⚠️ **Limite juridique assumée** : ces libellés font de la **minimisation d'affichage** (art. 5.1.c + 25 RGPD : dignité/vie privée du senior, pas de fuite sur écran verrouillé) — **ce ne sont PAS un levier de conformité RGPD** : la CNIL juge la substance stockée, pas le vocabulaire. Ne jamais présenter cette reformulation comme « sortir du champ santé ».

### 9.2 VERDICT : L'ARCHITECTURE RESPECTE-T-ELLE LE RGPD ?

**Réponse courte : la FORME est la bonne (elle va au-delà du RGPD sur la minimisation), mais elle n'est PAS ENCORE CONFORME toute seule — la conformité se prouve par des documents et process qui n'existent pas encore.**

Le RGPD ne valide pas des « architectures » : il impose des **résultats** (minimiser, sécurir, donner des droits, être responsable et pouvoir le prouver). Le plan de la maison est bon, il manque le permis et l'assurance.

| Obligation | Base légale | Statut |
|---|---|---|
| Minimisation des données | art. 5.1.c | ✅ actée (vue minimisée, libellés doux) |
| Protection dès la conception | art. 25 | ✅ actée (local-first, cloisonnement, push muet) |
| Base légale données santé = consentement explicite | art. 9.2.a | ✅ ConsentGate 4 temps (TTS → OUI/NON, silence = refus) |
| Hébergement UE / territorialisation santé | décret 2026-209 | ✅ serveurs France |
| Traçabilité / responsabilité | art. 5.2 | ✅ audit d'accès prévu |
| **Hébergement HDS** si stockage santé côté serveur | L.1111-8 CSP | ❓ **DÉCISION À PRENDRE** (voir 9.3) |
| **AIPD (analyse d'impact)** — obligatoire : santé + personnes vulnérables + surveillance | art. 35 | ❌ **absente** — c'est LE document demandé en 1er par la CNIL |
| **Registre des traitements** | art. 30 | ❌ absent |
| **Notice d'information** (qui, quoi, durée, droits) | art. 13-14 | ❌ absente |
| **Droits des personnes** : accès, rectification, effacement ≤ 30 j, portabilité (export JSON/CSV), opposition | art. 15-20 | ❌ absent (aucun point d'entrée) |
| **Durées de conservation** définies + purge auto | art. 5.1.e | ❌ absentes |
| **DPO** — très probablement obligatoire (suivi systématique de personnes vulnérables) | art. 37 | ❓ DPO externe ~1-2 k€/an à prévoir |
| **Notification de violation 72 h** | art. 33 | ❌ plan absent |
| **Contrat sous-traitant** si hébergeur tiers | art. 28 | ❌ si hébergeur externe retenu |
| Consentement **granulaire séparé des CGU** (case unique = faute sanctionnée) | art. 7 | ⚠️ à structurer : chaque finalité = son consentement (alertes / visio / statistiques), preuve horodatée |

**Conclusion :** conformité actuelle **~50 %** — la partie technique/conception est excellente, la partie **preuves et droits** (le vrai cœur du RGPD) est à construire. Estimation : AIPD + registre + notice + droits + durées = **2 à 4 semaines** (juriste santé recommandé), DPO externe à budgétiser.

### 9.3 ✅ DÉCISION TRANCHÉE (01/10) : OPTION A — base de données UNIQUEMENT sur le tél du senior

**Décision Antoine :** les données vivent **uniquement sur le téléphone du senior**, avec **une sauvegarde vers un compte à lui** (sauvegarde de son téléphone) pour **restaurer en cas de casse/perte**.

**Conséquences :**
- **HDS : très probablement évitable** (plus de stockage de données de santé par le SAS) → 8-15 k€/an économisés.
- **Sauvegarde sur le compte du senior = traitement à des fins personnelles** (art. 2 RGPD : hors champ quand le traitement est personnel) → la boucle se referme proprement, aucune donnée de santé ne passe par nos serveurs.
- **Conformité : ~50 % → ~80 %.** Restent : AIPD, registre, notice, droits (portabilité simplifiée : rien à exporter côté serveur), durées, notification 72 h.

**3 exigences techniques incontournables (à coder) :**

| # | Point | Pourquoi |
|---|---|---|
| 1 | **Sauvegarde explicite dans EasyPhone** (bouton + auto hebdo + après ajout de contact) | Android **ne sauvegarde pas** les bases SQLite d'app par défaut → sans export maison, la « sauvegarde » promise n'existe pas |
| 2 | **Format .epbak chiffré AES-256, passphrase = code famille (6 car.)** | Ni le cloud du senior ni un fichier aidant ne contiennent que du chiffré non lisible ; restauration sur un NOUVEAU tél = saisie du code. **Cycle casse → restauration = test obligatoire** (c'est l'usage réel) |
| 3 | **Maillon restant : le relais d'alertes offline** (famille hors-ligne au moment de l'événement) | C'est le SEUL stock santé restant côté serveur. Solutions : (a) **tampon TTL 24-48 h** à faire valider par le juriste, ou (b) **relais pair-à-pair via la data channel LiveKit déjà en place** (serveur = simple annuaire de découverte, **zéro stockage santé** = le plus propre) |

**Vérifications avant commercialisation :** (i) test complet de restauration sur 2ᵉ appareil, (ii) si le senior n'a AUCUN compte Google/Apple → repli obligatoire « export fichier vers l'aidant ».

### 9.4 RISQUES SPÉCIFIQUES À DOCUMENTER DANS L'AIPD

1. **Qui consent quand le senior est vulnérable** (démence, tutelle, curatelle) : le titulaire des droits est le SENIOR ; sans représentant légal, la surveillance d'un adulte est interdite → cas d'usage à trancher produit (aide = consentement explicite, cas dur = représentant légal + information du senior).
2. **Statut MDR** : ne JAMAIS promettre « prévention/détection médicale des chutes » dans le marketing → risque de classement en dispositif médical. CGV : « alerte indicative, ni téléassistance certifiée, ni dispositif médical, aucune garantie de détection ».
3. **Fiabilité réelle** = risque n°1 (falses négatifs : Doze, BLE, batterie) : mesurer les faux négatifs AVANT de vendre.

---
*Journal des versions :*
- **v1.4 (01/10/2026)** — décisions D10/D11 : cloud du senior créé à la livraison (mdp changé devant lui → traitement personnel hors RGPD, destination du cloud indifférente car fichier chiffré avant envoi) + architecture double filet (cloud senior = principal, coffre E2EE maison = secours automatique).
- **v1.3 (01/10/2026)** — décisions D8/D9 : sauvegarde E2EE hébergée chez nous en EU (blob chiffré, aucune clé serveur, sous condition juriste HDS) + code de secours imprimé (sinon perte définitive en cas de double perte de code).
- **v1.2 (01/10/2026)** — §9.3 TRANCHÉ : Option A retenue (base UNIQUEMENT sur le tél du senior + sauvegarde sur le compte du senior) → HDS évitable, conformité ~80 % ; 3 exigences techniques à coder (sauvegarde explicite .epbak chiffrée AES-256/code famille, restauration testée, relais alertes offline TTL ou P2P LiveKit).
- **v1.1 (01/10/2026)** — ajout §9 Feuille de route RGPD vivante : décisions D1-D7 (alertes douces paramétrables aidant+senior, table de reformulation, push muet, abonnement sans coupure sécurité), verdict de conformité (checklist ~50 %), décision ouverte A/B/C sur la localisation des données de santé, risques AIPD.
- **v1.0 (01/10/2026)** — rédaction initiale (Hermes, analyse marché + 10 propositions + plan 30/60/90).