Cache applicatif : propager les suppressions RGPD

Supprimer une donnée dans la base ne suffit pas si une carte client, un aperçu ou une réponse stockée continue de la restituer. Pour propager un effacement, identifiez les copies, empêchez leur réutilisation devenue injustifiée et traitez les mécanismes susceptibles de les recréer. Une expiration automatique contribue à cette organisation ; elle ne prouve pas, à elle seule, que la décision a été exécutée.

Le sujet concerne les caches applicatifs, les réponses HTTP intermédiaires et les copies locales maîtrisées par le service. Il faut distinguer leurs mécanismes : vider l’un ne commande pas nécessairement les autres.

Définir la décision avant la purge

Commencez par écrire ce qui doit changer. Une demande d’effacement acceptée ne se traite pas comme une correction d’adresse ou un retrait d’habilitation. La première vise les données entrant dans son périmètre ; la deuxième exige une information exacte ; le troisième empêche un utilisateur d’accéder à un dossier qui peut rester légitimement conservé.

L’Art. 17(1) impose l’effacement dans les meilleurs délais lorsque ses conditions sont réunies, sous les exceptions de l’Art. 17(3). L’Art. 16 traite la rectification ; l’Art. 18 prévoit une limitation qui peut autoriser la conservation tout en restreignant les autres usages. Aucune de ces règles ne définit un délai universel de quelques secondes pour tous les caches. Une durée technique par défaut ne constitue pas non plus une exception juridique. Source : RGPD, Art. 16 à 18.

La fiche de décision précise les données, les finalités et les systèmes concernés, les éléments éventuellement conservés et le résultat attendu. Si une pièce comptable doit rester dans une archive justifiée, cette conservation n’autorise pas à continuer d’afficher un profil supprimé dans le portail commercial. Le composant de performance doit suivre la décision, sans décider lui-même de son étendue.

Dessiner le trajet de la donnée

Un cache est une copie préparée pour éviter un nouveau calcul ou une nouvelle lecture. Son nom importe moins que son contenu et son usage. Une synthèse de dossier, une vignette avec un nom ou une réponse contenant des coordonnées peuvent toujours constituer des données personnelles.

La conservation et la communication sont des traitements selon l’Art. 4(2). Les exigences de conservation limitée, de protection dès la conception et de sécurité s’appliquent aussi à ces copies. Sources : RGPD, Art. 4(2), Art. 5(1)(e) et Art. 25(1), 32(1).

Prenez une vue réellement utilisée et remontez son parcours : source de référence, calcul, stockage, diffusion, écran. Demandez ensuite comment la copie disparaît et ce qui peut la fabriquer à nouveau. Les copies du moteur de recherche interne peuvent suivre un autre circuit, avec leurs propres extraits et règles d’accès.

Exemple d’inventaire renseigné, entièrement fictif. Le portail Orme affiche une carte de profil C-42 et une liste de profils autorisés. Le dossier de conception retient les composants suivants :

Ce tableau décrit une architecture illustrative, pas le comportement vérifié d’un produit. L’équipe doit identifier les composants réellement présents dans son service, avec leur propriétaire et leur mécanisme de suppression.

Expiration, invalidation et effacement ne sont pas synonymes

L’expiration détermine à quel moment une copie arrive à l’échéance prévue par sa règle technique ; son devenir dépend du mécanisme appliqué. L’invalidation la retire du circuit de lecture ou impose son renouvellement. L’effacement porte sur les données qui doivent disparaître. Une entrée marquée invalide peut rester physiquement stockée : il faut donc vérifier son devenir si l’obligation concerne sa conservation elle-même.

Pour les réponses HTTP, la RFC 9111 distingue notamment no-cache, qui impose une validation avant réutilisation dans sa forme sans argument, et no-store, qui encadre le stockage. private concerne les caches partagés ; ce mot ne garantit pas la confidentialité du contenu. La RFC précise aussi qu’une invalidation ne touche pas automatiquement tous les caches du système. Source : RFC 9111, sections 4.4, 5.2.2.4, 5.2.2.5 et 5.2.2.7.

Ces paramètres ne remplacent pas la procédure applicative. Un calcul stocké dans une base de cache, un fichier exporté ou une tâche en attente ne disparaissent pas simplement parce qu’une nouvelle réponse HTTP porte un en-tête différent. Pour chaque couche, obtenez un résultat observé et une description des limites ; évitez la consigne imprécise « activer no-cache partout ».

Le piège du résultat recréé après la suppression

Dans l’exemple Orme, l’effacement du profil C-42 est accepté : les données du profil ne sont plus nécessaires et aucune exception n’est retenue pour ce périmètre. La suppression des pièces conservées pour d’autres finalités est examinée séparément. Les horaires suivants illustrent une concurrence d’opérations, sans constituer un essai réellement exécuté.

À 10 h, une tâche lit la version 7 du profil pour préparer une carte. À 10 h 01, le profil est retiré de la source et sa carte disparaît du cache. À 10 h 02, la tâche termine son calcul et remet la carte de version 7 dans le cache. Le contrôle effectué juste après 10 h 01 aurait pu paraître satisfaisant ; il n’aurait pas détecté cette réintroduction.

Une conception possible consiste à vérifier l’état actuel et la version autorisée avant de publier le résultat calculé. Dans cette organisation, la tâche de 10 h 02 constate que sa version n’est plus admissible, abandonne la publication et libère sa copie de travail selon la procédure prévue. Ce contrôle doit être organisé avec les écritures concurrentes : une vérification suivie d’une publication tardive ne suffit pas si une suppression peut encore intervenir entre les deux.

L’équipe technique choisit le mécanisme approprié à son architecture : coordination des opérations, contrôle atomique, versions ou autre dispositif démontré. Le DPO a besoin de comprendre le résultat et ses limites, pas de prescrire un produit particulier. Si le service conserve un identifiant minimal pour empêcher une réintroduction, il doit aussi justifier son usage, sa durée et ses accès : ce marqueur n’est pas automatiquement anonyme.

Une spécification de réception utilisable

La recette du cache doit vérifier les chemins de lecture et de renouvellement. Le tableau suivant fournit les résultats attendus dans le dossier fictif C-42. Ce sont des critères proposés, et non des preuves déjà obtenues.

Ajoutez les chemins propres au produit : ancienne session, nouvelle session, recherche, aperçu, interface mobile ou synchronisation locale. Si la même information existe dans plusieurs clés de cache, le contrôle doit couvrir leur relation avec C-42. Une purge limitée à une clé connue ne démontre pas que toutes les listes dérivées ont été traitées.

La CNIL recommande d’intégrer ces exigences au développement et de vérifier les évolutions dans des environnements adaptés, avec des données fictives lorsque possible. Le scénario doit reproduire l’ordre d’opérations qui présente un risque, pas seulement l’affichage final attendu. Source : CNIL, encadrer les développements.

Organiser la reprise lorsqu’une couche ne répond pas

Une opération asynchrone peut échouer, être retardée ou ne jamais parvenir à un composant. Conservez un suivi permettant de distinguer demande émise, réception et exécution confirmée. Un nouvel essai doit rester rattaché à la même décision, sans réintroduire les données qu’il cherche à retirer.

Pendant l’anomalie, examinez comment empêcher la diffusion devenue injustifiée : désactivation du chemin concerné, consultation directe d’une source fiable ou autre mesure appropriée. Ne servez pas silencieusement l’ancienne copie au seul motif que le composant récent ne répond pas. Analysez aussi les conséquences d’une indisponibilité pour les personnes : le traitement d’un cache de rendez-vous n’a pas le même contexte qu’une simple préférence d’affichage.

La rectification des bases dérivées suit une logique proche, mais son résultat est différent : la bonne valeur doit être propagée. Une limitation peut imposer de conserver la donnée tout en empêchant certains usages. Le suivi doit porter le type de décision pour éviter qu’une procédure générique efface une information qui devait seulement être restreinte.

Présenter une preuve qui correspond au périmètre maîtrisé

Le compte rendu comporte la référence de la décision, les composants, les actions, les résultats des contrôles, les inconnues et leur responsable. Conservez des références utiles sans recopier inutilement les données supprimées dans le journal de preuve. La preuve d’exécution d’un effacement doit refléter les opérations réalisées, pas seulement le statut affiché par l’interface.

Pour les sous-traitants, obtenez l’assistance nécessaire selon l’Art. 28(3)(e). Les copies déjà communiquées à d’autres destinataires demandent un traitement distinct, notamment la notification prévue par l’Art. 19 dans ses conditions. Une copie téléchargée sur un terminal tiers ne peut pas être déclarée effacée par la seule purge du serveur. Sources : Art. 28(3)(e) et Art. 19.

Si une donnée reste accessible à une personne non autorisée, examinez aussi l’existence d’une violation de sécurité, puis les risques et obligations des Art. 33 et 34. Corriger le cache n’efface pas l’exposition passée. Enfin, réexaminez la carte lors de tout ajout de composant : une nouvelle couche de performance doit entrer dans les mêmes procédures de droits et de sécurité.

Ce qu’il faut retenir

• Associez chaque copie à sa source, ses lecteurs et son mécanisme de renouvellement.
• Un résultat invalide peut rester stocké ; distinguez arrêt de lecture et effacement.
• Vérifiez les tâches commencées avant la décision et les listes dérivées.
• Gardez les opérations non confirmées ouvertes, sans promettre une disparition totale.

FAQ

Un cache de quelques minutes échappe-t-il au RGPD ?

Non. Sa brièveté peut réduire une exposition, mais les données personnelles restent traitées pendant ce temps. Il faut justifier les usages, maîtriser les accès et exécuter les décisions applicables.

Faut-il vider tous les caches pour une seule demande ?

Une action ciblée peut convenir si elle couvre les copies et chemins concernés. Une purge générale peut perturber le service sans corriger une tâche qui recrée ensuite la donnée. Le choix doit être démontré sur l’architecture réelle.

Peut-on clôturer dès que le prestataire indique « purge demandée » ?

Cette mention prouve une demande, pas son exécution. Identifiez ce qui reste à confirmer et les mesures prises dans l’intervalle. La réponse à la personne doit refléter cet état réel, dans les délais applicables à sa demande.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.