Pourquoi la rétention RGPD n'est pas qu'une question juridique
Un compte que personne n'a rouvert depuis des années, un formulaire de contact jamais nettoyé : sur un site Drupal, la question de la rétention des données est facile à ne jamais poser. Elle est alors tranchée par défaut, par l'absence de décision plutôt que par un choix documenté.
Le RGPD pose deux obligations précises sur ce terrain. La première limite la durée pendant laquelle une donnée identifiante peut être conservée. La seconde donne à une personne le droit de demander l'effacement de ses données. Les deux se traduisent en choix concrets dans Drupal, de la méthode d'annulation de compte retenue à la durée de conservation des logs.
Le principe de limitation de conservation appliqué à un site
Le cycle de vie de la donnée selon la CNIL
L'article 5(1)(e) du RGPD pose le principe : les données permettant d'identifier une personne ne sont conservées que le temps nécessaire aux finalités du traitement, sauf archivage encadré pour un motif précis comme l'intérêt public ou la recherche (texte officiel du RGPD, chapitre 2).
La CNIL traduit ce principe en un cycle de vie à trois phases. Chaque phase a sa propre durée et ses propres règles d'accès (CNIL, les durées de conservation des données) :
- La base active : la donnée sert le traitement courant.
- L'archivage intermédiaire : la donnée ne sert plus l'objectif initial mais garde un intérêt administratif, par exemple une obligation légale de conservation comme la facturation, conservée dix ans au titre du Code de commerce ; l'accès y est ponctuel et contrôlé.
- L'archivage définitif : la donnée est conservée dans un intérêt public, historique ou statistique.
Qui fixe la durée : le responsable de traitement, pas Drupal
Il n'existe aucune durée de rétention universelle, ni pour Drupal, ni pour le RGPD en général. La durée dépend de la finalité du traitement : un compte client actif, une candidature non retenue, un log de connexion n'ont pas la même durée de vie légitime. C'est au responsable de traitement de la fixer et de la documenter, pas au CMS.
Drupal ne prend aucune décision à votre place sur ce point. Il exécute ce que vous configurez : une méthode d'annulation de compte choisie dans les paramètres utilisateurs, un cron planifié, un module qui applique une règle. La durée elle-même reste une décision de gouvernance, écrite dans votre registre de traitements.
Le droit à l'effacement (article 17) et ses limites légales
L'article 17 du RGPD oblige à effacer les données sans délai dans des cas précis : la donnée n'est plus nécessaire, la personne retire son consentement, le traitement était illicite, une obligation légale l'impose. Mais ce droit n'est pas absolu : l'article prévoit aussi des exceptions, parmi lesquelles une obligation légale de conservation, un motif d'intérêt public, la liberté d'expression ou la défense en justice (texte officiel du RGPD, chapitre 3).
Concrètement, un site Drupal n'efface pas tout sur simple demande. Une facture liée à une obligation comptable, par exemple, peut devoir être conservée malgré la demande d'effacement. La bonne pratique commence donc en amont : savoir, pour chaque type de donnée, si une exception s'applique avant même de recevoir une demande.
Purger un compte dans Drupal : les 4 méthodes natives
Bloquer, dépublier, réassigner ou supprimer : effet sur le contenu
La purge d'un compte utilisateur Drupal passe par quatre méthodes natives, configurables dans les paramètres utilisateurs (documentation Drupal, AccountCancellation, branche 11.x) :
- Bloquer le compte en conservant tout son contenu.
- Bloquer le compte et dépublier son contenu.
- Supprimer le compte en réassignant son contenu à l'utilisateur Anonyme.
- Supprimer le compte et effacer tout son contenu (réservé à l'administrateur).
Seule la quatrième méthode efface réellement le compte et son contenu. Avec les méthodes 1 et 2, le compte subsiste sous une forme bloquée ; avec la méthode 3, le contenu reste publié sous l'utilisateur Anonyme. Choisir la bonne méthode pour répondre à une demande d'effacement détermine si la demande est honorée ou contournée.
Les hooks qui anonymisent ou dépublient à l'annulation
Drupal core expose un point d'extension, hook_user_cancel(), que des modules utilisent pour réagir à l'annulation d'un compte, par exemple pour anonymiser un commentaire ou dépublier un contenu. Ce hook s'applique aux trois premières méthodes, mais pas à la suppression complète du compte : dans ce cas, les modules doivent s'appuyer sur d'autres points d'extension, hook_ENTITY_TYPE_predelete() ou hook_ENTITY_TYPE_delete() (documentation Drupal, hook_user_cancel, branche 11.x).
Cette nuance a une conséquence pratique directe : l'anonymisation n'est jamais automatique sur l'ensemble d'un site. Elle dépend des modules effectivement activés et de ce qu'ils implémentent. Un module de commentaires qui gère ce hook anonymisera les commentaires ; un module métier qui ne le gère pas laissera les données identifiantes en place, même après annulation du compte.
Les preuves d'effacement : ce que les logs prouvent, et ce qu'ils ne prouvent pas
Le log de suppression (notice) comme trace technique
À l'annulation d'un compte, Drupal core écrit une entrée dans le journal du site, une notice du type Deleted user: %name %email., visible dans les logs (dblog ou syslog selon la configuration) (code source Drupal, user.module, 11.4.11). C'est la trace la plus proche d'une preuve technique d'effacement que Drupal produit nativement.
Mais l'article 5(2) du RGPD exige davantage qu'une trace technique isolée : le responsable de traitement doit pouvoir démontrer sa conformité, ce que le texte appelle le principe de responsabilité ou « accountability » (texte officiel du RGPD, chapitre 2). Une ligne de log qui dit qu'un compte a été supprimé ne documente ni la date de la demande initiale, ni le périmètre exact des données effacées, ni la vérification que les exceptions légales ne s'appliquaient pas. Ce log reste un indice technique : il ne vaut pas preuve d'effacement au sens de la loi.
Pourquoi cette trace est éphémère (purge cron dblog)
Cette trace a en plus une durée de vie limitée. Le cron du module dblog purge automatiquement le journal au-delà d'un nombre de lignes configuré : passé ce seuil, les entrées les plus anciennes sont supprimées à chaque exécution (documentation Drupal, DblogHooks::cron, branche 11.x). La valeur par défaut livrée par Drupal core pour ce seuil est de 1000 lignes (configuration d'installation de dblog, Drupal 11.4.11).
Selon le volume d'événements qu'un site génère, ce seuil peut être franchi avant que vous ayez besoin de la trace. Si vous comptez sur ce log comme preuve d'effacement, vous comptez sur une trace que le cron peut avoir déjà supprimée, sauf à relever ce seuil, exporter le journal vers un système externe ou documenter la suppression ailleurs, de façon durable.
Le mythe du module qui rend « conforme »
Il existe des modules contrib dédiés au RGPD, comme GDPR Compliance, qui proposent une fonctionnalité d'oubli, une checklist de conformité et une anonymisation des exports SQL. Le mainteneur du module le dit lui-même dans sa documentation : installer et utiliser ce module ne rend pas le site conforme au RGPD (README du module GDPR, version 3.1.4).
Nous le disons aussi directement : aucun module Drupal, à lui seul, ne produit la conformité. Un module peut outiller une politique de rétention déjà écrite ; il ne peut pas la remplacer. La conformité commence par une décision humaine documentée (quelles données, combien de temps, pour quelle finalité), que l'outil applique ensuite.
Checklist pratique pour une agence ou un DPO
Avant de considérer qu'un site Drupal gère correctement la rétention et l'effacement, nous vérifions systématiquement les points suivants :
- Une durée de conservation est documentée pour chaque type de données (comptes, commandes, candidatures, logs), avec sa justification.
- La méthode d'annulation de compte sélectionnée dans les paramètres utilisateurs correspond réellement à l'objectif : conserver, dépublier ou effacer.
- Les modules métier actifs implémentent les hooks nécessaires pour anonymiser ou dépublier le contenu à l'annulation, quand c'est pertinent.
- Le seuil de purge du journal (
row_limit) est connu et ajusté si le log doit servir de point de départ à une investigation. - Une preuve d'effacement documentée (date de la demande, périmètre, vérification des exceptions légales) existe indépendamment du journal technique du site.
- Aucune exception légale (facturation, obligation comptable, procédure en cours) n'a été oubliée avant de traiter une demande d'effacement.
Cette checklist ne couvre pas tout ce qu'impose le RGPD : elle couvre ce que Drupal peut concrètement faire, et montre où s'arrête sa responsabilité et où commence la vôtre.
Si votre site accumule des comptes et des formulaires sans politique de rétention écrite, le risque dépasse le terrain juridique : c'est aussi ne pas savoir répondre le jour où une personne exerce son droit.
Demander un diagnostic est le premier pas pour clarifier ce que votre site conserve réellement, et ce qu'il devrait effacer.