Durée de conservation des données personnelles : méthode RGPD

La durée de conservation des données personnelles ne se choisit pas en copiant le plus grand nombre trouvé dans une politique. Le RGPD impose de relier chaque donnée à une finalité encore active, aux textes applicables, à un déclencheur calculable et à une action de fin vérifiable ¹.

Réponse rapide — La durée de conservation des données personnelles correspond au temps nécessaire pour accomplir une finalité déterminée, augmenté seulement des périodes imposées ou justifiées par le droit applicable. Le RGPD ne fixe aucun délai universel. Chaque règle doit comporter un déclencheur calculable, une action finale, des exceptions contrôlées et une preuve de suppression réelle.

Le calendrier doit décrire ce que les systèmes exécutent aujourd'hui, pas seulement l'intention de la politique. Un propriétaire vérifie chaque source, date la décision et traite les écarts jusqu'à une preuve de fin.

Dernière mise à jour : 26 août 2026.

Partir du dossier, pas d'un nombre favori

Commencez par un ensemble concret, tel que le dossier d'un client ayant résilié son abonnement. Il peut contenir des coordonnées, un contrat, des factures, des tickets d'assistance, des préférences de communication et des journaux de sécurité. Ces éléments ne poursuivent pas la même finalité et n'obéissent donc pas à une date unique.

Le principe de limitation de la conservation exige que les données identifiantes ne restent pas plus longtemps que nécessaire aux finalités ^1,2. Il ne prescrit pas « sept ans pour tout ». Une règle générale peut servir de point de départ à une catégorie homogène, mais chaque prolongation doit correspondre à un besoin démontré.

Séparez la période opérationnelle de la période résiduelle. Le compte actif peut nécessiter un accès quotidien ; après clôture, une petite partie du dossier peut être conservée pour une obligation ou une réclamation, avec accès limité. Cette réduction vaut mieux qu'un statut « archivé » qui laisse l'intégralité du profil recherchable par toutes les équipes.

La première version n'a pas besoin de couvrir tous les systèmes. Choisissez les ensembles à risque ou volume élevé, établissez des règles exécutables, puis étendez. Une politique exhaustive sans propriétaire ni mécanisme de suppression protège moins qu'un calendrier limité dont les premières règles sont réellement testées.

Le droit national fournit certaines périodes réelles

Le RGPD fournit le principe, tandis que le droit de l'Union, le droit de l'État membre et les règles sectorielles peuvent imposer la conservation de documents déterminés. La page européenne commune ne peut pas importer un nombre britannique ni inventer une période française : le responsable identifie le texte qui s'applique à son activité, son établissement et la catégorie exacte de document.

Enregistrez pour chaque période le texte, l'article, sa version, l'entité visée, la catégorie de document et la date de dernière vérification. Le simple lien vers une page générale ne permet pas au collègue suivant de confirmer que la durée s'applique. Une modification du texte doit déclencher une revue des règles et des systèmes affectés.

Lorsqu'aucune règle chiffrée n'impose la période, revenez à la finalité, aux risques et aux attentes. La Commission européenne résume la conservation comme limitée au temps nécessaire à la finalité ². Comparez la valeur opérationnelle réelle avec l'effet sur la personne, puis retenez une période que l'organisation peut expliquer et exécuter.

Le propriétaire juridique ne se contente pas de rechercher un nombre. Il établit une fiche indiquant l'entité visée, le territoire, l'activité, la catégorie exacte de document, le point de départ, les suspensions, la période et la version du texte ; le métier confirme que le document détenu correspond réellement à cette catégorie. Une durée comptable applicable à une facture ne couvre pas automatiquement les courriels, journaux de navigation et préférences associés au client.

Lorsque plusieurs textes paraissent s'appliquer, séparez leurs périmètres avant de retenir le délai le plus long. Une obligation peut exiger une pièce probante tout en interdisant l'usage opérationnel de certaines données qu'elle contient ; la solution consiste souvent à extraire ou restreindre le sous-ensemble nécessaire, non à garder le profil complet accessible. Le dossier nomme les conflits, l'interprétation approuvée et la prochaine date de vérification.

Les délais de prescription demandent la même précision. Identifiez la relation, les demandes plausibles, les pièces nécessaires, le point de départ et les événements d'interruption ou de suspension ; une possibilité abstraite de litige ne justifie pas toutes les données pendant chaque délai concevable. Après la période opérationnelle, placez les éléments nécessaires dans un périmètre restreint et empêchez leur réutilisation à d'autres fins.

La branche négative doit être explicite. Si aucune obligation ne vise la catégorie et que la finalité est terminée, le responsable ne prolonge pas la conservation parce qu'un texte voisin prévoit une période commode ; il supprime ou anonymise selon la règle approuvée. Toute exception reçoit un fondement, un propriétaire et une échéance de révision, faute de quoi elle expire.

Construire le calendrier comme un outil d'exploitation

Une ligne de calendrier doit permettre à une équipe technique de calculer une échéance et à une équipe juridique d'en comprendre le fondement. Évitez « conserver selon les besoins » ou « supprimer périodiquement », qui ne nomment ni événement ni responsable.

Pour chaque ensemble, définissez d’abord la catégorie et la finalité, puis vérifiez la source du besoin ². Fixez ensuite un déclencheur calculable, la période, les exceptions contrôlées et l’action finale. Appliquez cette action à toutes les copies réelles et vérifiez le résultat.

Ajoutez les dépendances. Un système maître peut lancer la suppression chez un fournisseur, retirer un fichier d'un espace partagé et inscrire une instruction pour les sauvegardes. Si chaque copie suit une règle indépendante, la date du calendrier ne garantit aucune fin réelle.

Versionnez les changements. Une règle raccourcie doit traiter le stock déjà arrivé à échéance ; une règle prolongée doit expliquer la nouvelle justification au lieu de repousser toutes les dates en silence. Conservez l'approbation, la date d'effet et le nombre d'enregistrements concernés.

L'information remise aux personnes doit rester cohérente. Elle peut indiquer la période ou les critères permettant de la déterminer ¹. Une formule publique vague alors que le système applique une durée précise empêche la personne de prévoir le traitement et fragilise la responsabilité démontrable.

Un dossier client produit plusieurs échéances

Imaginons un client qui résilie aujourd'hui. Les identifiants nécessaires au service actif perdent leur finalité opérationnelle ; les préférences de prospection suivent le statut et la règle du canal ; les factures peuvent relever d'une obligation nationale ; une réclamation ouverte conserve seulement les pièces nécessaires à sa résolution. Le calendrier calcule chaque branche séparément.

L'équipe réduit d'abord l'accès : le profil n'apparaît plus comme client actif et les données résiduelles sont limitées aux rôles qui traitent l'obligation ou la réclamation. Elle inscrit le déclencheur approprié, tel que le paiement final ou la clôture de la réclamation, plutôt que de faire repartir toutes les périodes à la dernière connexion d'un employé.

Lorsque la dernière finalité disparaît, le système supprime ou anonymise réellement. Une anonymisation ne consiste pas à retirer le nom tout en conservant un identifiant stable et des événements permettant de retrouver la personne. Documentez la méthode, le risque de réidentification et les données auxiliaires disponibles.

Ce cas montre pourquoi une « durée du client » unique échoue. Une personne est reliée à plusieurs finalités dont les commencements et fins diffèrent ; le modèle doit calculer la donnée par finalité, tout en évitant que des copies techniques prolongent l'ensemble par défaut.

Transformez l'exemple en lignes de calendrier avant de configurer le système. Le propriétaire client confirme la fin de prestation, la finance identifie les champs de la pièce soumise à une obligation, le service réclamations atteste les dossiers ouverts et le marketing vérifie la permission du canal ; chaque fonction fournit un événement daté et un jeu de données borné. Le DPO ou le rôle désigné challenge les chevauchements, puis un responsable approuve les règles.

Testez ensuite trois branches. Dans la branche ordinaire, aucune réclamation n'existe et les données opérationnelles disparaissent à l'échéance ; dans la branche d'obligation, seuls les documents et champs nécessaires restent en accès restreint ; dans la branche de réclamation, un gel conserve les pièces identifiées jusqu'à la clôture, puis rend la main au calendrier. Une copie ne peut pas rester active simplement parce qu'une autre branche justifie un sous-ensemble.

Les données dérivées suivent également leur finalité. Un score, un segment ou une prédiction reste une donnée personnelle lorsqu'il se rapporte au client et ne reçoit pas un nouveau départ du seul fait de son calcul ; le calendrier le relie aux sources, à la rectification et à la suppression. Une agrégation ne sort du régime que si la réidentification n'est plus raisonnablement possible et si aucune clé parallèle n'est conservée.

Avant la clôture, comparez le résultat attendu aux systèmes : statut du compte, droits d'accès, listes de campagne, entrepôt, fournisseur et exports. Un échantillon d'identifiants démontre que chaque branche produit l'état prévu, tandis que les anomalies obtiennent une cause, un propriétaire et une date. Le cas travaillé devient ainsi une preuve d'exécution, pas seulement une illustration de politique.

La suppression doit atteindre les copies réelles

Une action dans l'application principale ne suffit pas si les données restent dans l'entrepôt analytique, le service d'assistance, les exports, les espaces partagés ou chez un sous-traitant. Cartographiez les destinations au moment de définir la règle, puis assignez un mécanisme de fin à chacune.

Les sauvegardes demandent une conception explicite. Il peut être impossible de retirer immédiatement un enregistrement d'une sauvegarde immuable sans compromettre l'intégrité de celle-ci ; limitez alors l'accès, fixez un cycle d'écrasement et empêchez qu'une restauration réintroduise durablement des données arrivées à échéance. Le registre explique cette gestion au lieu de présenter la sauvegarde comme une exemption permanente.

Un rapport de suppression utile indique la règle, la date, les systèmes ciblés, les volumes, les échecs et la résolution. Échantillonnez ensuite des identifiants supprimés dans les systèmes en aval. Une tâche planifiée marquée « succès » prouve seulement que le programme a terminé, pas que chaque destinataire a exécuté l'action.

Les exports et messageries exigent un contrôle particulier parce qu'ils échappent souvent à l'application principale. Limitez leur création, attribuez une date d'expiration, utilisez des espaces contrôlés plutôt que des pièces jointes lorsque cela réduit les copies et recherchez les fichiers anciens sans exposer leur contenu à une équipe trop large. Une règle de boîte aux lettres conserve le contexte légitime tout en supprimant les pièces devenues inutiles.

Chez un sous-traitant, la clause de suppression ne constitue pas une preuve. Le propriétaire demande le mécanisme, le délai, le traitement des sauvegardes et l'accusé de fin, puis teste un compte échantillon ; lors d'une migration, il inclut l'ancienne plateforme et les copies de transfert dans le plan de clôture. Un échec reste ouvert jusqu'à une confirmation vérifiable.

La branche négative empêche aussi une restauration durable. Si une sauvegarde réintroduit des données arrivées à échéance, une liste de suppressions ou un recalcul du calendrier les retire avant le retour en service normal ; les utilisateurs ne doivent pas retrouver le profil pendant cette étape. L'exercice de restauration mesure ce comportement et conserve son résultat.

Les gels restent des exceptions assorties d'une échéance

Un gel juridique ou d'enquête peut suspendre la suppression pour des données nécessaires à une procédure identifiée. Il doit nommer son fondement, son périmètre, son responsable, sa date de révision et l'événement qui le lève. « Litige possible » sans autre précision transforme une exception en conservation indéfinie.

Isolez les données gelées et restreignez leur usage. Elles ne redeviennent pas disponibles pour le marketing, l'analyse générale ou la formation d'un modèle simplement parce qu'elles sont conservées. Toute extension de périmètre reçoit une justification et une nouvelle approbation.

À la levée, recalculez l'action depuis la règle correcte. Si la durée normale a déjà expiré, supprimez sans créer une nouvelle période complète à compter de la fin du gel, sauf fondement distinct. Conservez la preuve de levée et d'exécution.

Rendre le déclencheur calculable

Les expressions « dernier contact », « fin de relation » ou « compte inactif » cachent souvent plusieurs événements. Définissez lequel compte : dernière commande livrée, solde payé, contrat résilié, ticket fermé ou dernière connexion authentifiée. Précisez aussi les événements qui ne redémarrent pas la durée, comme l'ouverture d'un courriel automatique.

Le système doit conserver la date source et la raison du déclencheur. Lorsqu'une action humaine ferme un dossier, le formulaire exige l'événement et contrôle les pièces ouvertes. Lorsqu'un calcul automatisé s'applique, testez les fuseaux horaires, les dates manquantes, les migrations et les comptes fusionnés.

Prévoyez une file d'exceptions limitée. Un propriétaire peut corriger une date erronée ou suspendre une action pour un gel valide, mais il doit fournir un motif, une échéance et une approbation. Les exceptions sans fin deviennent rapidement le principal calendrier de l'organisation.

Mesurez le stock en retard. Le nombre d'enregistrements au-delà de l'échéance, leur âge, les systèmes responsables et le délai moyen de résolution révèlent si la politique fonctionne. Les orientations du Comité européen destinées aux petites organisations insistent sur la conservation limitée et la mise en pratique des obligations, pas seulement leur documentation ^3,4.

Définissez précisément les événements qui ne redémarrent pas la période. L'ouverture automatique d'un courriel, une synchronisation technique, une consultation interne ou une sauvegarde ne constituent pas une nouvelle interaction du client ; les laisser déplacer l'échéance rendrait la conservation indéfinie. Le registre des événements porte un code stable et le calcul ignore ceux qui n'ont aucun lien avec la finalité.

Les dates manquantes suivent une voie contrôlée. Elles entrent dans une file de correction avec un propriétaire et une échéance ; si la source ne peut être reconstruite, l'organisation applique une hypothèse prudente documentée ou une revue manuelle bornée, au lieu de classer l'enregistrement comme permanent. Le volume et l'âge de cette file font partie des indicateurs de conformité.

Avant une suppression à grande échelle, exécutez le calcul sur un échantillon et comparez les relations entre tables, les exceptions et le nombre attendu. Une seconde personne valide la règle et la population ; le test ne copie pas pour autant toute la production dans un environnement moins protégé. Après lancement, la tâche publie volumes réussis, échecs et systèmes injoignables, puis attribue chaque anomalie.

Le déclencheur doit aussi survivre aux migrations. Transférez la date source et la raison, non uniquement l'échéance calculée, afin qu'une règle modifiée puisse être recalculée et auditée ; une date d'import ne devient jamais le nouveau départ. Un contrôle de rapprochement compare un échantillon avant et après migration et bloque la mise en service si les échéances se sont déplacées sans justification.

La branche positive se termine par une action observable, tandis que la branche d'exception se termine par une nouvelle date. Si aucune action n'est possible dans un système, le propriétaire choisit une correction de conception et limite entre-temps l'accès ; « non pris en charge » ne peut pas servir d'état final. Le rapport montre le stock résiduel jusqu'à sa résolution.

Les demandes de droits ne suppriment pas le calendrier

Une demande d'effacement déclenche une analyse, non une suppression aveugle de tout ce qui porte un nom. Le responsable identifie les données, les finalités encore actives, les obligations et exceptions, puis supprime ce qui n'a plus de fondement. La réponse explique clairement les catégories conservées et la raison.

Une demande d'accès ne doit pas prolonger arbitrairement chaque donnée. Préservez le dossier nécessaire pour répondre et éviter une suppression opportuniste, mais continuez d'appliquer les règles aux éléments sans rapport. Documentez toute suspension courte liée à la demande et sa date de sortie.

La rectification doit se propager aux copies actives sans rétablir des données déjà supprimées. L'opposition à la prospection entraîne l'arrêt du traitement concerné ; un identifiant limité peut rester dans une liste d'exclusion afin d'éviter une réimportation, avec accès et finalité strictement bornés.

Ces interactions appartiennent au calendrier. Ajoutez les signaux qui suspendent, raccourcissent ou transforment l'action, le rôle qui décide et la preuve attendue. Une équipe chargée des droits doit voir l'échéance de conservation, et l'équipe chargée de la conservation doit voir la demande ouverte.

La limitation du traitement exige un état technique distinct. Les données nécessaires restent conservées, mais les usages, exports et décisions automatisées ordinaires sont bloqués ; seuls les rôles et opérations compatibles avec la limitation restent autorisés. Un test depuis un compte métier démontre l'interdiction, car une étiquette visible dans le registre sans contrôle d'accès ne protège pas la personne.

Lorsqu'une rectification, un effacement ou une limitation doit être communiqué aux destinataires, le responsable conserve leur liste, l'instruction, l'accusé et les échecs, sauf impossibilité ou effort disproportionné dûment établi ¹. La correction du système maître ne suffit pas si une copie active persiste chez un partenaire. La réponse à la personne décrit les catégories conservées, leur motif et la durée résiduelle sans révéler d'informations sur autrui.

Après la clôture d'une demande, retirez les suspensions temporaires et recalculez chaque règle depuis son déclencheur d'origine. Le traitement d'un droit ne crée pas automatiquement une nouvelle période complète ; les données déjà arrivées à échéance sont supprimées dès que la nécessité procédurale disparaît. Un propriétaire vérifie ce retour au calendrier et joint le rapport au dossier de la demande.

En France, la Commission nationale de l'informatique et des libertés (CNIL) est l'autorité à contacter pour les traitements relevant de sa compétence. Le lien constitue une orientation nationale ; les durées chiffrées doivent toujours être établies à partir du texte propre à l'activité et ne sont pas généralisées dans cette page européenne.

Réviser le calendrier en testant les systèmes

Une revue documentaire compare les finalités, les textes, les fournisseurs et les produits actuels avec le calendrier. Une revue technique vérifie que les déclencheurs et actions existent dans les systèmes. Les deux sont nécessaires : une règle juridiquement exacte mais jamais exécutée laisse les données en place.

Attribuez chaque écart avec une date de correction et vérifiez de nouveau après intervention. Une série d'échecs dans le même système appelle une modification de conception, pas une nouvelle exception manuelle. Suivez également les nouvelles catégories sans règle ; elles montrent où le produit a avancé plus vite que la gouvernance.

La revue commence par rapprocher l'inventaire du calendrier : nouvelles tables, champs dérivés, fournisseurs, exports et environnements doivent tous posséder une règle ou une décision documentée de non-applicabilité. Le métier confirme la finalité, le juridique la source, la technique le déclencheur et l'action, puis un réviseur examine les exceptions les plus anciennes. Les éléments orphelins reçoivent un propriétaire et une échéance avant la clôture.

Exécutez des tests dans les deux directions. Un enregistrement arrivé à échéance doit disparaître de toutes les copies prévues, tandis qu'un dossier sous obligation ou gel valide ne doit pas être effacé ; cette seconde branche révèle les règles trop larges ou les jointures incorrectes. Les résultats indiquent identifiants d'échantillon, systèmes, heures, volumes et anomalies, sans reproduire inutilement les données dans le rapport.

Comparez les indicateurs d'une revue à l'autre : stock en retard, données sans déclencheur, exceptions expirées, taux d'échec chez les fournisseurs et temps de résolution. Une amélioration déclarée doit apparaître dans ces mesures et dans un nouvel échantillon ; déplacer les enregistrements vers une table d'archive sans changer leur accessibilité ne réduit pas la dette.

Enfin, testez une restauration et une migration, car ces opérations contournent souvent la suppression ordinaire. Le système doit réappliquer les suppressions, conserver les dates sources et maintenir les restrictions avant de rouvrir l'accès ; le propriétaire signe le résultat et inscrit toute lacune dans le plan de correction. La prochaine revue vérifie que la correction a réellement supprimé le risque.

Le RGPD de l'Union et le régime britannique suivent une logique de conservation matériellement équivalente : aucun ne donne une durée universelle, et chacun relie la période à la nécessité et aux textes d'appui. La différence pratique réside dans les obligations domestiques. L'article européen reste donc sans suffixe, tandis qu'une analyse britannique doit utiliser ses propres périodes nationales.

Terminez la revue par un état vérifiable : règles confirmées, règles modifiées, stock en retard, exceptions, propriétaire et prochain contrôle. La durée de conservation devient alors une fonction du système, non une promesse enfermée dans une politique que personne ne peut exécuter.