RGPD

Couverture RGPD en V1

Droit	Article RGPD	Implémentation
Droit à l’effacement	Art. 17	`anonymize()` sur `GuestProfile` + purge `TravelerRegistry`
Droit à la portabilité	Art. 20	Export JSON/CSV via `GET /v1/guests/:id/export`
Consentements	Art. 7	Append-only sur `guest_consents` (immuables, horodatés)
Rétention limitée	Art. 5(1)(e)	Fichier voyageurs : 6 mois après départ, purge automatique

Anonymisation des profils invités

L’opération anonymize() sur GuestProfile est irréversible :

Nom, prénom, email, téléphone → valeurs pseudonymisées (hash one-way)
Adresse, date de naissance → effacées
Consentements → conservés (base légale de traçabilité)
Historique de séjours → conservé (nécessaire pour la comptabilité NF203)
Statut anonymized: true posé sur le profil

L’anonymisation ne supprime pas les lignes de folio — la comptabilité NF203 doit rester intacte. Les références au guestProfileId dans les réservations sont conservées (ID opaque).

Export de données (art. 20)

GET /v1/guests/:guestProfileId/export
Authorization: Bearer <token>

Retourne un JSON incluant :

Données d’identité
Historique des séjours
Consentements
Documents chiffrés disponibles (liste des IDs — pas le contenu)

Fichier voyageurs R611-42

Le fichier voyageurs est une obligation légale française (art. R611-42 CESEDA) pour les hébergements touristiques.

Saisie

La fiche voyageur est saisie au check-in via la réception (apps/reception → drawer fiche voyageur). Les champs obligatoires varient selon la nationalité :

Résidents UE/EEE/CH : allégement (exemption partielle)
Autres nationalités : identité complète, document d’identité, date d’arrivée/départ prévue

PII chiffrée

Les données PII du fichier voyageur sont chiffrées en base via FieldCipher (AES-256-GCM, clé dérivée DEK par tenant) :

Prénom, nom, date de naissance, nationalité, numéro de document
La clé DEK est elle-même chiffrée par la KEK (Key Encryption Key) via SecretStorePort (KMS-agnostique)
En production, la KEK doit venir d’un KMS cloud réel (résiduel A)

Rétention et purge automatique

La rétention légale est de 6 mois après la date de départ réelle :

Au check-out, le consumer traveler reçoit stay.checked_out et recale la date de fin de rétention au départ réel (pas à la date prévue de check-out)
Le workflow Temporal purge-traveler (lancé mensuellement) purge les fiches dont la rétention est expirée

stay.checked_out → consumer traveler → MAJ retention_until
             → après 6 mois → Temporal purge-traveler → DELETE PII

Idempotency-Key

La saisie de la fiche voyageur utilise Idempotency-Key pour éviter les doublons en cas de rejeu (réseau instable au check-in).

Documents chiffrés (MinIO)

Les documents scannés (pièces d’identité, EDL signés) sont chiffrés côté client avec une DEK par document avant upload vers MinIO. La DEK est chiffrée par la KEK tenant et stockée en DB.

L’accès se fait via des URLs presigned MinIO (GET /v1/storage/presigned) avec durée de validité courte (15 min).

Consentements

Les consentements sont append-only sur pms.guest_consents :

Chaque consentement est horodaté avec occurred_at serveur
Retrait de consentement = nouvelle entrée status: 'revoked', pas de DELETE/UPDATE
La vue courante = dernière entrée par type de consentement

Logs et monitoring

Les logs (Pino/pino-http) ne contiennent pas de PII — les identifiants sont opaques (UUID). Les traces OpenTelemetry ne transportent pas de données personnelles.

Les handlers NATS ne logguent jamais le payload complet des events — le pattern event_id + type uniquement.