Rétention et suppression des données RGPD : guide pratique pour développeurs

L’essentiel du travail RGPD qui atterrit chez les développeurs ne concerne ni les bandeaux cookies ni les politiques de confidentialité. Ça se résume à deux obligations faciles à énoncer et difficiles à implémenter : ne pas garder les données personnelles plus longtemps que nécessaire, et les supprimer correctement quand on doit le faire.

Les deux sont des problèmes de rétention et de suppression, et les deux sont là où les vrais systèmes sortent discrètement de la conformité. Voici un guide pratique pour bien les traiter, y compris la partie que presque tous les plans oublient : vos backups.

Un avertissement d’abord. Je suis développeur, pas juriste, et ceci est un guide d’implémentation, pas un conseil juridique. Les durées de rétention exactes et les bases légales de votre produit sont une question pour votre DPO ou votre avocat. Ce qui suit, c’est comment construire la mécanique une fois ces décisions prises.

Obligation une : la limitation de conservation (arrêter de tout garder pour toujours)

Le principe de limitation de la conservation du RGPD dit que les données personnelles ne doivent être gardées que le temps où elles servent la finalité pour laquelle vous les avez collectées. En termes d’ingénierie : chaque catégorie de données personnelles a besoin d’une durée de vie définie et de quelque chose qui la fait respecter.

Le piège, c’est que les systèmes ont pour défaut de tout garder pour toujours. Le disque coûte peu, les suppressions font peur, et “on en aura peut-être besoin plus tard” gagne toutes les discussions. Donc la première étape, ingrate, c’est un calendrier de rétention : un tableau de quelles données personnelles vous détenez, pourquoi, et pour combien de temps.

Donnée	Finalité	Rétention
Profil de compte	Fournir le service	Vie du compte + 30 jours
Historique de commandes	Obligation légale et fiscale	6 à 10 ans (selon juridiction)
Messages de support	Service client	2 ans
Logs serveur et d’accès	Sécurité et débogage	30 à 90 jours
Événements analytics	Analyse produit	14 mois

La colonne rétention est une décision légale. Ce qui compte pour les développeurs, c’est qu’une fois qu’elle existe, elle devient une spec qu’on peut implémenter et tester.

La faire respecter : la purge automatique

Une politique de rétention qui dépend de quelqu’un qui pense à supprimer n’est pas une politique. Automatisez :

• Un job planifié (nocturne ou hebdomadaire) qui supprime en dur les enregistrements au-delà de leur fenêtre de rétention.
• Pour les données temporelles (logs, événements, analytics), utilisez le TTL ou le drop de partition du moteur de stockage plutôt que des suppressions ligne par ligne. Droppez l’ancienne partition, expirez l’index, posez la règle de cycle de vie du bucket. C’est plus rapide et ça ne peut pas rater des lignes en silence.

-- exemple : purger les messages de support de plus de 2 ans
DELETE FROM support_messages
WHERE created_at < now() - interval '2 years';

Le soft delete n’est pas une suppression

Une erreur courante : marquer une ligne deleted_at = now() et considérer que c’est fait. Un soft delete cache la donnée à l’application, mais la donnée personnelle est toujours là, parfaitement lisible dans la base. C’est acceptable comme état intermédiaire (une période de grâce, une fenêtre d’annulation), mais ça ne satisfait ni la rétention ni l’effacement à soi seul. Quelque chose doit finir par la supprimer en dur.

Obligation deux : le droit à l’effacement

Quand un utilisateur exerce son droit à l’effacement (le “droit à l’oubli”), vous avez en général 30 jours pour retirer réellement ses données personnelles. La difficulté n’est presque jamais la ligne users principale. C’est que les données personnelles se sont éparpillées.

Le temps qu’un produit devienne réel, les données d’un seul utilisateur vivent à plein d’endroits :

• la base principale (et ses réplicas de lecture)
• un index de recherche (Elasticsearch, Algolia, OpenSearch)
• des caches (Redis, un CDN)
• le stockage objet (avatars, uploads, exports)
• le pipeline analytics et l’entrepôt de données
• des sous-traitants tiers (email, paiements, support, suivi d’erreurs)
• le stockage des logs
• les backups

L’effacement veut dire cascader la suppression sur tout ça, pas seulement la ligne. Deux choses rendent ça survivable :

• Une cartographie des données. On ne peut pas supprimer ce qu’on n’a pas noté. Maintenez une liste de chaque système qui stocke des données personnelles et comment y supprimer. C’est la même carte dont votre calendrier de rétention a besoin.
• Déléguez à vos sous-traitants. Pour les tiers, en général vous ne supprimez pas leur copie vous-même, vous appelez leur API de suppression ou vous vous appuyez sur leur rétention contractuelle. Stripe, votre fournisseur d’email, votre suivi d’erreurs ont chacun un mécanisme de suppression. L’effacement inclut de déclencher le leur.

Une implémentation propre, c’est un workflow d’effacement : un job qui diffuse la suppression vers chaque système de la carte, enregistre ce qu’il a fait, et est idempotent pour pouvoir être relancé si un appel en aval échoue.

Ce que tout le monde oublie : les backups

Voici la question qui bloque net la plupart des plans d’effacement. Vous avez supprimé l’utilisateur de la production, de l’index de recherche, du stockage objet, de chaque sous-traitant. Mais le backup de la base de la nuit dernière le contient encore. Celui d’avant-hier aussi, et tous ceux qui remontent des semaines en arrière. Avez-vous réellement respecté l’obligation ?

Vous ne pouvez pas réalistement ouvrir chaque backup, en retirer chirurgicalement un utilisateur, et le réempaqueter. Ça irait à l’encontre du but des backups et risquerait de les corrompre. Les régulateurs le savent, et les réponses d’ingénierie acceptées sont celles-ci :

1. Une rétention de backups bornée. Si vos backups tournent sur un calendrier défini (disons 30 jours) puis sont détruits, les données de l’utilisateur supprimé disparaissent du jeu de backups dans cette fenêtre. Documentez-le. “Les backups sont conservés 30 jours, après quoi les données effacées sont définitivement perdues” est une position défendable et courante. L’essentiel, c’est que la fenêtre soit finie et appliquée, pas “on garde les backups pour toujours”.

2. Le crypto-shredding. Chiffrez les données personnelles de chaque utilisateur avec une clé par utilisateur. Pour effacer l’utilisateur, vous supprimez sa clé. Le chiffré peut encore se trouver dans de vieux backups, mais sans la clé il est irrécupérable, ce qui, en pratique et pour le régulateur, vaut suppression. C’est l’approche la plus solide, et celle à privilégier quand votre rétention de backups est longue ou légalement obligatoire.

3. Une procédure de restauration-puis-réeffacement. Acceptez que les backups contiennent encore la donnée, et engagez-vous par écrit à ce que, si vous restaurez un jour un backup, vous relancez immédiatement le job d’effacement pour toute personne ayant demandé la suppression entre-temps. Gardez la liste des demandes d’effacement pour que ce soit possible. Plus faible que les deux premières, mais honnête et applicable.

La mauvaise réponse, c’est de n’avoir aucune réponse. “On supprime de la base” pendant que des backups non bornés conservent discrètement tout le monde pour toujours, c’est le trou que les auditeurs et les enquêtes de violation trouvent en premier.

N’oubliez pas vos logs

Les logs sont le stock de données personnelles le plus négligé. Une adresse email dans un message d’erreur, une IP dans un log d’accès, un corps de requête complet capturé en débogage : tout ça est de la donnée personnelle, soumise aux mêmes obligations de rétention et d’effacement, et éparpillée dans un système de logs conçu pour être append-only.

Vous ne ferez pas de suppressions par utilisateur sur un firehose de logs, donc traitez les logs à la source :

• Ne loggez pas de PII au départ. Redactez les emails, les tokens et les corps de requête avant qu’ils soient écrits. C’est de loin le contrôle le moins cher.
• Mettez une rétention courte. 30 à 90 jours couvrent presque tous les besoins de sécurité et de débogage. Configurez-la et laissez les vieux logs expirer automatiquement.
• Traitez “on peut chercher dans deux ans de logs” comme une responsabilité, pas une fonctionnalité.

Une courte checklist

• Un calendrier de rétention écrit : chaque catégorie de données personnelles, sa finalité, sa durée de vie.
• Une purge automatique qui applique le calendrier (TTL, drops de partition, jobs planifiés).
• Une cartographie des données : chaque système qui stocke des données personnelles et comment y supprimer.
• Un workflow d’effacement idempotent qui cascade sur tous, sous-traitants inclus.
• Une réponse documentée et défendable pour les backups : rétention bornée, crypto-shredding, ou restauration-puis-réeffacement.
• Aucune PII dans les logs, et une rétention de logs courte.

Rien de tout ça n’est de l’ingénierie exotique. C’est surtout de la tenue de registres (savoir où est la donnée) plus quelques jobs planifiés. La raison pour laquelle ça échoue si souvent n’est pas la difficulté technique, c’est que personne ne possède la carte. Écrivez la carte, automatisez les suppressions, et décidez votre stratégie de backups exprès plutôt que par accident. C’est la différence entre un système conforme et un système qui a seulement l’air conforme jusqu’à ce que quelqu’un pose la question.