Rétention des données RGPD : quoi garder, quand supprimer, et pourquoi la plupart des équipes se trompent

Le problème de rétention que personne n'anticipe

Le RGPD ne vous fournit pas un tableur avec des durées de conservation. Il impose quelque chose de bien plus difficile à implémenter : ne conservez les données que tant que vous avez une raison valable, et supprimez-les quand cette raison disparaît.

La plupart des équipes n'y pensent pas avant qu'un utilisateur soumette une demande de suppression — et là, elles découvrent que l'e-mail de l'utilisateur se trouve dans 10 tables différentes, trois outils tiers et la sauvegarde d'hier. Personne ne détient la décision « combien de temps garde-t-on ça ? » parce que personne ne l'a jamais prise explicitement.

En 2023, Meta a reçu une amende de 1,2 milliard d'euros pour avoir transféré des données européennes aux États-Unis sans base juridique suffisante. Mais ce ne sont pas que les géants de la tech. Des petites entreprises en Europe reçoivent régulièrement des amendes de 5 000 à 50 000 € pour absence de politique de rétention ou refus de traiter des demandes de suppression. L'autorité estonienne de protection des données (Andmekaitse Inspektsioon) est également active — l'application de la loi est réelle, même pour des entreprises de quelques employés.

Base juridique : le fondement de toute décision de rétention

Vous ne pouvez pas définir combien de temps conserver des données sans savoir pourquoi vous les avez collectées. Le RGPD définit six bases juridiques pour le traitement des données personnelles. En pratique, trois reviennent dans presque chaque projet :

• Consentement — l'utilisateur a dit oui. Les données restent jusqu'à ce qu'il dise non.
• Contrat — vous avez besoin des données pour fournir un service. Les données restent tant que le contrat est actif.
• Intérêt légitime — vous justifiez vous-même le besoin métier et définissez la portée et la durée.

C'est là que ça se complique : la même adresse e-mail peut être traitée sous différentes bases juridiques selon le contexte. Votre système de facturation la conserve au titre du « contrat ». Votre outil de newsletter au titre du « consentement ». Vos analytics y font référence au titre de l'« intérêt légitime ». Chaque contexte a sa propre durée de conservation — pour le même champ, dans la même base de données, appartenant à la même personne.

C'est pourquoi la rétention ne peut pas être une règle unique appliquée globalement. C'est un arbre de décision enraciné dans le pourquoi de chaque donnée.

Cartographie des données : avant d'écrire la moindre politique

Vous ne pouvez pas construire une politique de rétention sans savoir ce que vous stockez et où. Une cartographie des données n'a pas besoin de faire 40 pages — mais elle doit répondre à quatre questions pour chaque type de données personnelles que vous détenez :

• De quelles données personnelles s'agit-il ? (nom, e-mail, adresse IP, historique d'achats…)
• Où sont-elles stockées ? (quelle table de base de données, quel service tiers, quelle sauvegarde)
• Sur quelle base juridique les traitez-vous ?
• Qui est responsable de la décision sur leur cycle de vie ?

Cette dernière question compte plus qu'on ne le pense. Si personne ne détient la décision de rétention, personne ne la prend — et les données s'accumulent indéfiniment par défaut. Ce n'est pas un exercice technique. C'est une conversation entre développeurs, responsables produit et la personne en charge de la conformité. Le résultat est une compréhension partagée, pas un fichier de configuration.

Comment définir une durée de conservation pour chaque type de données

La logique est toujours la même : pourquoi l'avez-vous collecté → quand cet objectif est-il atteint → existe-t-il une obligation externe de le conserver plus longtemps ?

Quelques exemples concrets :

• Formulaire de contact — l'objectif est atteint quand vous avez répondu (ou décidé de ne pas le faire). Une durée raisonnable : 6 mois, puis suppression.
• Enregistrement de transaction — le droit fiscal exige la conservation des documents financiers. En Estonie, c'est 7 ans en vertu de la loi comptable. Mais « document financier » signifie la date de transaction, le montant et la catégorie fiscale — pas nécessairement le profil complet de l'acheteur, son adresse de livraison ou son numéro de téléphone.
• Préférences marketing — conservées jusqu'au retrait du consentement. Pas de consentement = pas de données.
• Journaux d'accès serveur — intérêt légitime pour la surveillance de sécurité. 90 jours est courant ; 12 mois est la limite haute que la plupart des autorités considèrent raisonnable sans justification spécifique.

Un détail important : différents champs au sein du même enregistrement peuvent avoir des durées de conservation différentes. Un enregistrement de commande peut conserver le montant et la date pendant 7 ans (obligation fiscale) tandis que le nom du client et l'adresse sont anonymisés après 2 ans (plus nécessaires pour l'objectif initial). Traiter une table entière comme une seule unité de rétention est le raccourci le plus courant — et l'erreur la plus courante.

Trois types de « suppression » — et pourquoi le soft delete n'en fait pas partie

Quand quelqu'un dit « nous avons supprimé l'utilisateur », il veut généralement dire l'une de trois choses. Seules deux comptent au regard du RGPD :

• Soft delete — un indicateur passe de 0 à 1. Les données sont masquées dans l'interface mais restent en base, apparaissent dans les sauvegardes et sont visibles via des requêtes directes. Juridiquement, ce n'est pas une suppression. C'est une dissimulation. Le RGPD ne regarde pas votre interface — il regarde si les données existent.
• Anonymisation — les identifiants personnels sont supprimés de manière irréversible. L'enregistrement existe encore, mais ne peut plus être relié à une personne. Juridiquement, les données anonymisées ne sont plus des données personnelles. Le RGPD ne s'y applique plus.
• Suppression définitive — les données sont physiquement supprimées. Disparues de la base de données, des index, et finalement des sauvegardes lors de leur rotation.

L'illusion la plus répandue : « on fait du soft-delete pour les utilisateurs, donc on est conforme. » Non. Si les données sont récupérables, elles ne sont pas supprimées. Si votre panneau d'administration a un bouton « Restaurer » pour les utilisateurs supprimés, vous n'avez rien supprimé.

La pseudonymisation n'est pas l'anonymisation

Remplacer un e-mail par un hash ressemble à de l'anonymisation. Ce n'en est pas. Le RGPD trace une ligne nette entre les deux :

• Pseudonymisation — les données personnelles sont transformées pour ne plus pouvoir être attribuées à une personne sans informations complémentaires (comme une clé ou une table de correspondance). Les données restent des données personnelles au sens du RGPD car la ré-identification est possible.
• Anonymisation — la ré-identification est impossible, même combinée avec d'autres données disponibles. Ce n'est qu'à ce moment que le RGPD cesse de s'appliquer.

Le test n'est pas de savoir si vous pouvez ré-identifier quelqu'un — mais si quiconque le pourrait raisonnablement. Effacer un e-mail mais laisser un prénom rare + une ville + une date de naissance dans le même enregistrement ? Cette combinaison peut identifier une personne. Le RGPD voit au-delà.

Une véritable anonymisation exige de vérifier la combinaison complète des champs restants, pas seulement d'effacer un par un les identifiants évidents.

Anonymiser ou supprimer : quand utiliser quoi

La décision est simple une fois la bonne question posée : avez-vous besoin de l'enregistrement après le départ de la personne ?

• Anonymiser quand les données servent à l'analytique, au reporting ou à l'audit. Un enregistrement de commande (date, montant, catégorie de produit) sans identifiants personnels reste précieux pour l'intelligence économique.
• Supprimer quand les données n'existent que pour identifier ou contacter une personne. Noms, e-mails, numéros de téléphone, adresses physiques — s'il n'y a pas d'utilité métier sans l'identité, supprimez tout.

Un piège à éviter : l'anonymisation partielle sans vérifier la combinaison restante. Vous retirez le nom et l'e-mail d'une commande, mais laissez l'adresse de livraison, la date et un produit de niche. Dans une petite ville, cette combinaison peut pointer vers exactement une personne. L'anonymisation n'est réelle que quand l'ensemble des données restantes passe le test de ré-identification.

Retrait du consentement vs. droit à l'effacement : droits différents, réponses différentes

Ces deux demandes arrivent dans la même boîte de réception mais déclenchent des processus différents :

Retrait du consentement (« je ne veux plus de mails marketing ») arrête le traitement basé sur le consentement — mais les données collectées sur une autre base juridique restent. Si vous conservez aussi cet e-mail au titre d'un contrat (parce que l'utilisateur est un client actif), vous ne le supprimez pas. Vous arrêtez les newsletters, mais l'e-mail reste dans votre système de facturation.

Droit à l'effacement (« supprimez tout ce que vous avez sur moi ») est plus large — mais pas absolu. Vous pouvez refuser si vous avez une obligation légale de conservation (les données fiscales, par exemple) ou si un intérêt légitime prévaut. Cependant, vous devez répondre dans les 30 jours, expliquer ce que vous avez fait ou pourquoi vous avez refusé, et documenter la décision.

Traiter ces demandes de la même manière est une erreur courante. Un retrait de consentement ne nécessite pas une purge complète des données. Une demande d'effacement ne prime pas automatiquement sur les obligations légales de conservation. Chacune nécessite son propre workflow et son propre modèle de réponse.

La conclusion pratique

La rétention n'est pas un document de politique unique que l'on rédige et que l'on oublie. C'est un ensemble de décisions — une par type de données, une par base juridique, une par lieu de stockage — qui doivent être prises explicitement, documentées clairement et appliquées automatiquement.

Commencez par la cartographie des données. Définissez les durées de conservation selon la base juridique et l'objectif. Choisissez l'anonymisation ou la suppression pour chaque type de données. Construisez le workflow pour le retrait de consentement et les demandes d'effacement séparément. Et assurez-vous que quelqu'un est propriétaire de chaque décision — pas « l'équipe », pas « le juridique », mais une personne précise qui peut expliquer pourquoi ces données sont conservées aussi longtemps.

Dans le prochain article, nous traduirons ces principes en code : comment implémenter des politiques de rétention dans Laravel avec un nettoyage planifié, des règles de cascade pour les enregistrements liés et un workflow de droit à l'effacement qui fonctionne réellement en production.