GDPR et Event Sourcing : effacer sans supprimer l'histoire

Cet article est de nature architecturale et ne constitue pas un avis juridique. Les contraintes GDPR/RGPD varient selon les contextes ; pour les décisions de conformité, consultez un DPO ou un juriste spécialisé.

Une demande d'effacement arrive, au titre de l'article 17 du RGPD (droit à l'effacement). L'utilisateur veut que ses données disparaissent.

Votre EventStore est append-only, et un événement ne s'y supprime pas. AccountOpened { userId: "alice", email: "alice@example.com", ... } est là depuis trois ans. Il est dans le stream, dans les snapshots, dans les projections matérialisées, et peut-être dans les logs applicatifs.

L'erreur n'est pas de stocker un log immuable. L'erreur est d'y avoir mis des PII sans stratégie d'effacement.

Classifier avant de persister

La première décision se prend avant d'écrire le premier événement, et non le jour où la demande d'effacement arrive.

Pour chaque attribut, on se pose les questions suivantes.

1. Est-ce une PII (donnée à caractère personnel) ? Email, nom, numéro de téléphone, adresse IP, identifiant indirect.
2. A-t-on vraiment besoin de la persister dans l'EventStore ? Le userId est nécessaire, mais le nom complet de l'utilisateur est-il utile dans MoneyWithdrawn ?
3. Quelle est la durée de rétention légitime ? Le RGPD impose la minimisation, c'est-à-dire de ne conserver que ce qui est nécessaire pour la finalité déclarée.

Appliquée à l'Event Sourcing, la minimisation consiste à ne mettre dans l'EventStore que les identifiants nécessaires aux invariants métier. Les données personnelles détaillées vivent ailleurs.

Personal Data Store (PDS) et tokens de référence

La stratégie la plus propre consiste à ne jamais écrire de PII dans l'EventStore. On y stocke à la place un token de référence opaque (pdRef: "pds-ref-a7b2c9d4") qui pointe vers les données dans un store séparé.

// [NON] — PII dans le payload de l'événement
class AccountOpened implements DomainEvent {
  constructor(
    public readonly accountId: string,
    public readonly email: string,      // ← PII dans le stream immuable
    public readonly fullName: string,   // ← PII dans le stream immuable
  ) {}
}

// [OUI] — référence opaque, PII dans un store séparé
class AccountOpened implements DomainEvent {
  constructor(
    public readonly accountId: string,
    public readonly pdRef: string,      // ← token vers le Personal Data Store
  ) {}
}