Protection des données et conformité
Ce que magot garantit aujourd'hui sur les données des familles, et ce qui reste à faire. Cadre : nLPD (Suisse), données de mineurs, exigences d'audit bancaire.
Cloisonnement
| Niveau | Mécanisme |
|---|---|
| Entre établissements | Row Level Security Postgres sur toutes les tables métier ; le rôle applicatif ne voit aucune ligne hors de l'établissement de la requête |
| Entre foyers d'un établissement | contrôlé par l'API : un parent n'agit que sur les enfants de son foyer et ne reçoit que ses événements ; un appareil enfant que sur son enfant. Toute ressource d'un autre foyer répond 404 (son existence n'est pas confirmée) |
Consentements parentaux
Le traitement des données d'un enfant repose sur le consentement de son parent, daté, versionné et retirable :
POST /v1/children/:id/consents { kind, version }— donné par un parent identifié (jamais par une clé technique) ;- une nouvelle version des conditions clôt l'ancien consentement et en ouvre un nouveau : l'historique complet reste consultable ;
POST /v1/consents/:id/withdraw— le retrait se date, rien n'est effacé ;GET /v1/consents— l'état et l'historique du foyer.
Les types de consentement (child_data_processing, card_issuance, …) et
ceux qui conditionnent une fonctionnalité seront fixés par établissement
(configuration, à venir) : aujourd'hui ils sont enregistrés, pas encore
exigés.
Appareils et sessions
GET /v1/devices: les appareils du foyer (parents, iPhone et montre des enfants), leurs sessions actives, dernière activité ;POST /v1/devices/:id/revoke: téléphone perdu, montre revendue — toutes les sessions de l'appareil tombent immédiatement, il ne reçoit plus de notifications ;- les sessions issues de l'identité bancaire expirent avec le jeton de la
banque ;
POST /v1/identity/logoutrévoque la session courante.
Journal d'audit
Inscrit dans la même transaction que l'action (pas d'action sans trace), non modifiable ni effaçable par le rôle applicatif. Chaque entrée : auteur (appareil, clé technique ou fournisseur d'identité), action, sujet, valeurs.
| Actions tracées |
|---|
| argent : recharges, demandes acceptées ou refusées, missions validées |
| sécurité : gel et dégel de carte, révocation d'appareil |
| règles : plafonds, catégories, arrondi |
| consentements : don, nouvelle version, retrait |
| identité : enrôlement et connexion passkey, échange de jeton bancaire, liaison d'identité, déconnexion, jeton d'appairage émis, appareil enfant appairé, montre approuvée |
Durées de conservation
| Donnée | Conservation |
|---|---|
| Journal d'événements, décisions d'autorisation, virements, audit | permanente (traces financières et de conformité) — voir « Effacement » |
| Clés d'idempotence | 30 jours |
| Jetons d'appareil révoqués ou expirés (empreintes seules) | 90 jours |
| Jetons d'appairage, codes montre, défis WebAuthn expirés | 1 jour |
La purge tourne chaque jour (PURGE_INTERVAL_HOURS). Le rôle applicatif ne
peut supprimer que ces données techniques.
Idempotence stricte
Toute écriture porte une Idempotency-Key. Rejouer la même requête rend la
réponse d'origine sans réexécuter ; réutiliser la clé pour une autre
requête (autre route, autre montant) est refusé (422) au lieu d'être rejoué
en silence.
Reste à faire
- Effacement (droit à l'oubli) : le journal d'événements est immuable par conception, et contient des libellés saisis par la famille. Approche prévue : chiffrer les données personnelles des événements avec une clé par foyer ; la fermeture d'un foyer détruit la clé (crypto-shredding), les montants et la chronologie restant exploitables pour les obligations comptables.
- Consentements exigés par fonctionnalité, selon la configuration de l'établissement.
- Accès du support de la banque : nominatif, justifié et tracé (avec l'API back-office).
- Export d'audit pour le délégué à la protection des données.
- Limitation de débit des points publics.