La vie privée, c'est ce qui reste une fois que le système a appris à oublier.

Le droit à l'effacement n'est pas un bouton « supprimer ». Dans les systèmes modernes, c'est une question rigoureuse portant sur les copies, les données...

La vie privée, c'est ce qui reste une fois que le système a appris à oublier.

Oublier n’est pas le contraire de se souvenir

Un dossier papier a une vie visible, rassurante. Il arrive, on le range quelque part, on le copie si l’on dispose d’un photocopieur, et il finit par passer au broyeur ou aux archives. La difficulté peut résider dans la décision de le détruire ou non, mais l’objet lui-même est obligeamment fini. Un enregistrement numérique est moins poli. Il peut être stocké sous forme de ligne, de pièce jointe, d’index de recherche, d’aperçu de message, de bloc de sauvegarde, d’entrée d’audit, de caractéristique dans une entrée de modèle, de vecteur dans un magasin d’intégrations, de réponse en cache ou de valeur ayant voyagé dans le système d’une autre organisation. Il ne suffit pas de demander où vit l’original. La question la plus utile est de savoir ce qui en a été tiré, ce qui permet encore d’identifier une personne et à quoi sert chaque trace restante.

C’est là la dignité pratique du droit à l’effacement. On l’appelle souvent le droit à l’oubli, une formule frappante mais imparfaite. L’oubli humain est accidentel, partiel et plein de retours embarrassants. Un processus d’effacement légal doit être délibéré. Il doit pouvoir distinguer un enregistrement qui doit être supprimé d’un enregistrement qui doit être conservé parce que la loi l’exige, d’une réclamation contestée qui doit rester disponible pour une défense juridique, et d’un résidu technique qui peut être isolé jusqu’à son expiration prévue. Il doit aussi résister à un instinct d’entreprise utile : traiter la suppression comme un état d’écran plutôt que comme une propriété des systèmes.

Le Règlement général sur la protection des données ne promet pas que chaque élément lié à une personne disparaîtra sur demande. L’article 17 énonce les motifs pour lesquels un responsable du traitement doit effacer des données à caractère personnel sans retard injustifié, notamment lorsque les données ne sont plus nécessaires au regard des finalités pour lesquelles elles ont été collectées ou traitées, lorsque le consentement est retiré et qu’il n’existe pas d’autre fondement juridique, et lorsque le traitement est illicite. Le même article fixe des limites. L’effacement ne s’applique pas lorsque le traitement est nécessaire, par exemple, à l’exercice du droit à la liberté d’expression et d’information, au respect d’une obligation légale, à l’exécution d’une mission d’intérêt public dans certaines circonstances, à des fins de santé publique, à des fins d’archivage, de recherche ou de statistiques sous réserve de garanties, ou à la constatation, à l’exercice ou à la défense de droits en justice. Ce n’est pas une faille dans une promesse. C’est la forme réelle du droit.

La question pour un responsable de système n’est donc pas : « Pouvons-nous supprimer des données ? » Presque tout système peut supprimer quelque chose. La question est de savoir si l’organisation peut expliquer, pour une demande particulière et une finalité de traitement particulière, quelles données elle détient, ce qui est advenu de ces données, ce qu’elle est obligée ou en droit de conserver, quels destinataires en aval doivent être informés et comment l’action accomplie peut être vérifiée. La différence semble procédurale. En pratique, elle est architecturale. Un produit qui ne sait qu’ajouter de l’information découvrira que la suppression est une fonctionnalité bien plus coûteuse.

Cela est particulièrement vrai pour les systèmes d’IA, mais cela ne se limite pas à l’IA. La recherche, l’analyse, le support client, l’identité, la surveillance de la sécurité et la gestion documentaire produisent tous des dérivés. Un modèle ne fait que donner de nouveaux noms au problème : jetons, gradients, intégrations, index de récupération, invites et sorties. Aucune de ces étiquettes ne dissout la question sous-jacente de savoir si une personne physique reste identifiable. Un terme technique ne répond pas non plus silencieusement à la question juridique. Une intégration n’est pas automatiquement anonyme parce qu’elle est difficile à lire. Un journal n’est pas automatiquement nécessaire parce qu’il est utile. Une sauvegarde n’est pas automatiquement exemptée parce qu’elle est gênante.

La vie privée après l’oubli n’est donc pas une page blanche. C’est l’état résiduel qui demeure après qu’une organisation a pris une décision légale, proportionnée et vérifiable sur ce qui ne devrait plus être traité. La qualité de cet état résiduel en dit bien plus long aux gens sur un système que la présence d’un bouton de suppression ne le fera jamais.

Le droit a des conditions, et c’est ce qui le renforce

Le droit européen de la protection des données est parfois présenté comme s’il offrait à chaque individu un bouton rouge universel. Cette image est assez nette pour un diaporama et assez fausse pour causer des problèmes. L’article 17 est lié à la finalité, à la base juridique et aux circonstances du traitement. Il contient un droit, des obligations pour les responsables du traitement et des exceptions qui protègent d’autres droits et l’intérêt public. Une réponse responsable commence par déterminer l’identité du demandeur lorsque cela est nécessaire, comprendre les données et la finalité du traitement concernées, et décider si un motif de l’article 17 et une exception s’appliquent. La réponse peut être l’effacement. Elle peut être un refus motivé, en tout ou en partie. Elle peut être la limitation du traitement pendant qu’un litige est résolu. Elle peut aussi être une demande qui renvoie à un système que l’organisation ne contrôle pas.

Ce n’est pas une raison pour transformer une demande de personne concernée en parcours d’obstacles. Le RGPD exige que les responsables du traitement facilitent l’exercice des droits. L’article 12 exige que les informations et communications relatives aux actions prises sur une demande soient concises, transparentes, intelligibles et facilement accessibles. Il exige généralement des informations sur les mesures prises sans retard excessif et, en tout état de cause, dans un délai d’un mois à compter de la réception. Ce délai peut être prolongé de deux mois supplémentaires lorsque cela est nécessaire, compte tenu de la complexité et du nombre de demandes, mais le responsable doit informer la personne de la prolongation et de ses motifs dans le premier mois. Un système qui ne peut pas identifier ses propres flux de données avant le troisième mois n’a pas trouvé de défense procédurale. Il a trouvé un problème de gouvernance.

Les orientations du Comité européen de la protection des données pour les petites et moyennes entreprises exposent clairement le point opérationnel : les personnes peuvent demander l’effacement dans des circonstances particulières, et les organisations devraient avoir des procédures pour répondre aux demandes de droits. Une procédure n’est pas un avis juridique stocké sur un lecteur partagé. C’est un parcours opérationnel de la demande à la décision puis à l’exécution. Elle comprend les rôles autorisés à prendre une décision, les cartographies des données qui leur permettent de voir les traitements concernés, les fournisseurs et destinataires qui peuvent avoir besoin d’une notification, les calendriers de conservation qui expliquent une exception, et les preuves qui permettent à un examinateur ultérieur de comprendre ce qui a été fait.

La Cour de justice a contribué à rendre visible une autre distinction. Ses arrêts concernant le déréférencement portent sur la présentation des liens par les moteurs de recherche, et non sur une instruction d’effacer la publication sous-jacente du site source. Dans l’affaire Google Spain, la Cour a jugé qu’un exploitant de moteur de recherche peut être responsable du traitement de données à caractère personnel apparaissant sur des pages web publiées par des tiers, et qu’une personne concernée peut, dans certaines circonstances, demander le retrait de liens d’une liste de résultats affichée à la suite d’une recherche effectuée sur son nom. Dans des affaires ultérieures, la Cour a traité des questions notamment liées aux données sensibles, à la portée territoriale du déréférencement et aux informations inexactes. Ces affaires ne transforment pas chaque fait indésirable en demande d’effacement. Elles montrent pourquoi un système doit nommer la couche en cause : publication source, index, liste de résultats, cache, extrait ou autre copie.

Cette discipline des couches compte aussi au sein des organisations. Un employé peut demander à un responsable du traitement d’effacer une fiche de contact qui n’est plus nécessaire à une finalité de recrutement. Le responsable peut devoir évaluer une obligation distincte de conservation pour la paie ou les preuves d’égalité de traitement. Un organisme public peut traiter une donnée dans le cadre d’une mission légale et doit évaluer le droit applicable plutôt que de répéter une réponse du secteur privé. Un éditeur peut devoir peser la liberté d’expression et d’information. Le résultat ne peut pas être décidé par le seul vocabulaire des bases de données.

Il est tentant de s’irriter contre ces conditions parce qu’elles empêchent une promesse simple. Mais c’est elles qui donnent son sens à la promesse. Un droit qui ignorerait les obligations légales, les autres droits fondamentaux et la distinction pratique entre les systèmes s’effondrerait en un rituel. L’approche européenne exige une décision responsable, non une décision théâtrale. Cela demande plus de travail. Cela rend aussi un refus contestable et un effacement crédible.

L’effacement commence par la localisation des surfaces de traitement. Le schéma est une cartographie des systèmes, pas une affirmation selon laquelle chaque surface reçoit le même traitement juridique.

Un enregistrement peut disparaître de l’écran et rester dans le système

L’échec de suppression le plus courant est familier à quiconque a construit une application : retirer un élément de l’interface du produit, laisser les données sous-jacentes dans un stockage et considérer le travail terminé parce que les utilisateurs ordinaires ne peuvent plus le voir. Parfois, une suppression logique est exactement la bonne conception opérationnelle. Elle peut préserver une courte période d’annulation, rendre la réplication sûre ou éviter de rompre une relation qui doit être résolue. Mais la suppression logique n’est pas un effacement simplement parce que l’interface est devenue plus silencieuse. Son usage doit être lié à un objectif défini, à une durée de conservation, à des contrôles d’accès et à une action ultérieure qui modifie réellement l’état des données.

La suppression physique a ses propres limites. Supprimer une ligne peut laisser un index de recherche jusqu’au cycle d’indexation suivant. Un stockage d’objets peut avoir un versionnage. Un cache de diffusion de contenu peut conserver une réponse jusqu’à son expiration ou son invalidation. Une file de messages peut contenir un événement pas encore traité. Un entrepôt de données peut avoir ingéré un instantané. Un service peut avoir transféré les données à un sous-traitant, un sous-traitant ultérieur ou un destinataire. La leçon pratique n’est pas que la suppression est impossible. C’est qu’une organisation a besoin d’un inventaire suffisamment fidèle pour distinguer ces surfaces et d’une politique qui précise ce qui se produit sur chacune d’elles.

Il existe une autre distinction entre le contenu et la preuve. Un ticket de service client peut contenir le message d’une personne. Un système peut avoir besoin d’une trace attestant qu’un ticket a existé, a été résolu et a été supprimé selon une règle approuvée. Conserver le message entier pour toujours afin de prouver qu’il a été supprimé est un petit chef-d’œuvre bureaucratique, mais pas un contrôle de confidentialité. Une meilleure conception ne conserve que la preuve minimale nécessaire à la responsabilité, séparée du contenu qui n’a plus d’utilité. Cette preuve peut être un identifiant de demande, le type de décision, l’heure d’achèvement, la catégorie de conservation applicable et les systèmes atteints. La conception dépend de l’organisation. Le principe, lui, ne dépend de rien : la preuve ne doit pas recréer des données personnelles inutiles.

Les sauvegardes méritent le même langage simple. Une sauvegarde peut être nécessaire pour la disponibilité, la sécurité ou la reprise après sinistre. Elle reste un traitement. La question pratique est de savoir si la sauvegarde est accessible séparément, combien de temps elle reste récupérable, qui peut la restaurer, si elle est incluse dans le flux d’effacement normal et comment un environnement restauré est empêché de réintroduire silencieusement des données qui ont depuis été retirées du système en production. Une politique raisonnable peut s’appuyer sur la période de rotation définie de la sauvegarde plutôt que de modifier chaque bloc de sauvegarde historique individuellement. Mais une politique doit le dire, protéger l’accès entre-temps et garantir que la restauration suit l’état actuel des données lorsque c’est possible. « C’est dans la sauvegarde » décrit un problème. Ce n’est pas une réponse à ce problème.

Les journaux sont similaires. Les journaux de sécurité et d’exploitation peuvent être essentiels. Ils peuvent constituer la seule trace d’un accès, d’une tentative d’authentification échouée ou d’une modification en production. Ils peuvent également conserver des identifiants, des adresses, des corps de requête ou des fragments de contenu qui n’ont jamais été nécessaires au diagnostic. Une bonne conception des journaux minimise dès la collecte, masque ou pseudonymise lorsque c’est approprié, sépare les charges utiles sensibles des métadonnées d’événement, limite les accès et applique des calendriers de conservation. Tenter de découvrir chaque champ sensible lors d’une demande d’effacement est possible, mais c’est un bien piètre substitut au fait de décider, au moment de la conception, ce que le journal n’aurait jamais dû contenir.

Un responsable technique n’a pas besoin de promettre un effacement immédiat et uniforme sur chaque appareil pour agir de manière responsable. Il doit en revanche être en mesure d’énoncer le cycle de vie : ce qui devient indisponible immédiatement, ce qui est supprimé lors du prochain traitement, ce qui persiste selon un calendrier de conservation documenté, ce qui reste protégé en attendant l’expiration, et ce qui se produira en cas d’opération de récupération. Ce compte rendu donne à une personne, à un régulateur et à un exploitant quelque chose de concret à examiner. Une notification verte de confirmation ne leur donne que très peu de choses.

Les données dérivées ne sont pas une porte de sortie

Les systèmes modernes transforment souvent les données personnelles avant de les utiliser. Ils extraient une date d’un document, classent un message, calculent un score, déduisent une langue, créent un index de recherche, produisent un résumé, relient deux comptes ou transforment du texte et des images en vecteurs utilisés pour la recherche de similarité. Ces transformations peuvent être utiles. Elles peuvent aussi donner à une organisation le sentiment d’avoir dépassé le cadre des données personnelles. Ce n’est pas nécessairement le cas.

Le RGPD est technologiquement neutre. Ses considérants expliquent que les données pseudonymisées qui pourraient être attribuées à une personne physique grâce à des informations supplémentaires devraient être considérées comme des informations concernant une personne physique identifiable. Ils expliquent également que l’identification doit tenir compte de tous les moyens raisonnablement susceptibles d’être utilisés, par le responsable du traitement ou par une autre personne, en considérant des facteurs tels que le coût, le temps, les technologies disponibles et les évolutions technologiques. La question n’est pas de savoir si une représentation ressemble à un nom dans un tableur. Elle est de savoir si elle se rapporte à une personne identifiée ou identifiable dans le contexte réel.

Une incorporation rend ce point utilement embarrassant. Dans un système de recherche, un document peut être divisé en segments et représenté sous forme de vecteurs numériques afin qu’une requête puisse trouver du contenu sémantiquement similaire. Le vecteur n’est pas un paragraphe lisible. Il peut néanmoins être lié à un document source, à un locataire, à un utilisateur, à un contrôle d’accès, à un champ de métadonnées ou à une clé de recherche. Il peut permettre au système de sélectionner du contenu personnel en réponse à une requête. L’organisation ne peut pas le qualifier d’anonyme simplement parce qu’un être humain ne peut pas reconstituer une phrase en regardant une liste de coordonnées. Elle doit évaluer la représentation, les données associées, les moyens de liaison et la finalité du traitement.

Il en va de même pour un score dérivé. Un score de risque, une catégorie de préférence ou un indicateur d’éligibilité peut contenir moins de détails bruts que les données sources et avoir néanmoins des effets importants pour la personne. Il peut s’agir de données personnelles s’il se rapporte à une personne identifiée ou identifiable. Supprimer la source tout en conservant un score qui continue d’influencer une décision n’est pas une réponse propre. Cela peut simplement faire passer la personne sous une forme plus opaque. Le système a besoin d’une règle pour les dérivés : lesquels sont supprimés avec la source, lesquels sont recalculés, lesquels ne peuvent plus être utilisés, lesquels doivent être conservés en vertu d’une obligation distincte, et qui décide.

Il n’existe aucun test technique universel qui tranche le sort de chaque dérivé. Certaines statistiques agrégées peuvent être anonymes. D’autres peuvent rester vulnérables à la réidentification ou au recoupement. Certains paramètres de modèle peuvent ne pas être raisonnablement attribuables à un individu dans un contexte donné. D’autres encore peuvent être associés à des données d’entraînement, à un modèle au périmètre étroit ou à une surface d’attaque qui modifie l’évaluation. La notion d’information anonyme du RGPD n’est pas une étiquette décorative pour des données devenues simplement difficiles à interpréter. Le responsable du traitement doit procéder à une évaluation fondée sur les moyens et le contexte de l’identification.

Cette incertitude ne justifie pas de qualifier chaque dérivé de définitivement toxique. Elle justifie de maintenir une traçabilité. Une équipe doit savoir quels ensembles de données d’entrée ont été utilisés pour un feature store, un index, une exécution d’entraînement ou une table de reporting ; quelles versions d’un dérivé ont été produites ; quels systèmes les consomment ; et quelle réponse un changement dans la source doit déclencher. La traçabilité transforme une question inconfortable en une tâche d’ingénierie délimitée. Sans elle, chaque demande relative aux droits devient une expédition archéologique à travers des noms de tâches, des buckets de stockage et la mémoire de quelqu’un concernant une migration vieille de deux hivers.

L’apprentissage automatique soulève une question difficile, pas une exemption magique

L’apprentissage automatique rend l’effacement difficile parce que l’entraînement n’est pas une opération de classement. Un exemple d’entraînement peut affecter les paramètres à travers une longue séquence de mises à jour, en compagnie de nombreux autres exemples. Un modèle déployé peut avoir été copié dans plusieurs environnements. Un modèle ultérieur peut avoir été affiné à partir d’un modèle antérieur. Une équipe peut utiliser des données d’évaluation, des invites, des corpus de récupération et des journaux de retour qui suivent chacun des cycles de vie différents. Si les données d’une personne sont entrées dans un tel système, une organisation ne peut pas répondre de manière responsable par un haussement d’épaules évoquant les mathématiques. Elle ne peut pas non plus promettre honnêtement qu’une suppression dans une base de données élimine toute influence possible sur chaque paramètre.

La première étape consiste à séparer les systèmes. Un corpus de récupération n’est pas un modèle entraîné. Si un document est utilisé comme source pour la récupération, l’effacement peut impliquer la suppression ou la désactivation du document, de ses fragments, de ses métadonnées et de ses entrées d’index, puis la vérification que la récupération ne l’atteint plus. Un journal d’invites n’est pas un magasin d’embeddings. Un ensemble de données d’affinage n’est pas une piste d’audit de sécurité. Un point de contrôle de modèle n’est pas un enregistrement source actuel. La réponse appropriée peut différer pour chaque surface, mais une réponse ne peut être conçue tant que les surfaces ne sont pas nommées.

Pour les données d’entraînement, l’analyse juridique et technique peut nécessiter une décision quant à savoir si le réentraînement, le remplacement, la restriction, la conservation ou une autre mesure est approprié. La recherche sur le désapprentissage automatique est pertinente car elle explore des méthodes pour réduire l’influence de données particulières sans réentraîner un modèle à partir de zéro. Elle ne constitue pas un certificat général attestant qu’un système a oublié. Les méthodes comportent des hypothèses, des classes de modèles, des conditions de données et des limites de vérification. Une organisation ne devrait pas commercialiser une technique expérimentale comme une mise en œuvre universelle de l’article 17. Elle ne devrait pas non plus attendre une technique parfaite avant de concevoir de meilleurs contrôles des données.

De meilleurs contrôles commencent en amont. Minimisez les données collectées. Séparez les données personnelles du matériel d’entraînement lorsque la finalité prévue le permet. Fixez une durée de conservation avant que l’accumulation ne rende la question émotionnellement coûteuse. Conservez des enregistrements versionnés des ensembles de données et des exécutions d’entraînement. Rendez explicites les conditions d’adhésion ou autres conditions licites lorsqu’elles constituent la base pertinente. Évitez qu’une archive de production d’invites ne devienne silencieusement un corpus de développement de modèles. Maintenez la distinction entre les données d’évaluation et d’assistance et les données d’entraînement. Moins un système repose sur une provenance inconnue, plus il peut répondre avec précision à une question de suppression.

Il existe aussi une limite au mot « influence ». Une personne peut s’inquiéter qu’un texte ait un jour fait partie d’un ensemble d’apprentissage. Une équipe technique peut être en mesure de déterminer que l’enregistrement source a été retiré d’un corpus actuel, mais sans pouvoir prouver, au sens philosophique large, qu’aucune parcelle d’influence ne subsiste dans un quelconque paramètre d’un modèle historique. Le droit de la protection des données ne devient pas plus simple lorsqu’une organisation remplace une description concrète par de la métaphysique. L’obligation est d’évaluer le traitement, les fondements et les mesures au regard de la loi. L’organisation doit expliquer la portée de sa conclusion, les systèmes qu’elle couvre et la limitation qui demeure. La précision est plus bienveillante qu’une promesse exagérée.

Pour les déployeurs d’IA, la charge pratique relève souvent autant des achats que de l’ingénierie. Un fournisseur doit être en mesure d’expliquer ce qu’il fait des requêtes, des fichiers téléversés, de la télémétrie et des retours facultatifs ; lesquels de ces éléments servent à l’apprentissage ou à l’amélioration du service ; quels contrôles de conservation existent ; comment un client peut obtenir les informations nécessaires pour répondre aux demandes d’exercice des droits ; et ce qui se passe dans un environnement partagé par rapport à un environnement dédié. Un contrat qui se contente de mentionner « conforme au RGPD » n’a pas fourni les informations nécessaires pour mener à bien une procédure d’effacement. Il a fourni un adjectif.

Les moteurs de recherche enseignent une leçon utile sur les couches

La jurisprudence de la Cour de justice sur le déréférencement est utile ici précisément parce qu’elle est plus étroite que l’expression populaire « droit à l’oubli ». Les affaires portent sur la question de savoir si, et à quelles conditions, un moteur de recherche doit retirer des liens des résultats affichés à partir d’une recherche sur un nom. Elles ne créent pas un simple pouvoir de modifier l’histoire à sa source. Cette distinction montre que les questions de protection des données portent souvent sur la manière dont l’information est rendue disponible, connectée et amplifiée, et pas seulement sur le fait qu’un enregistrement ait un jour existé.

Dans l’affaire Google Spain, la Cour a examiné des liens figurant dans la liste de résultats d’un moteur de recherche vers des pages publiées par un tiers. La décision a précisé que l’activité d’un moteur de recherche peut constituer un traitement de données à caractère personnel et que, à certaines conditions, l’exploitant peut être tenu de retirer des liens des résultats affichés à la suite d’une recherche portant sur le nom d’une personne. La décision ne constituait pas un ordre adressé au journal qui avait publié les avis initiaux. Le propriétaire d’un système qui examine une base de connaissances interne peut en tirer un enseignement : les index de recherche, les aperçus et le classement des résultats sont des couches de traitement ayant leurs propres conséquences.

L’affaire GC et autres a examiné des demandes de retrait de liens vers des pages web contenant des données à caractère personnel sensibles. La Cour a abordé la mise en balance requise et les obligations qui peuvent incomber à un exploitant de moteur de recherche. L’affaire Google c. CNIL a porté sur la portée territoriale et a jugé, dans les circonstances de l’espèce, que le droit de l’Union n’exigeait pas un déréférencement sur toutes les versions d’un moteur de recherche dans le monde, tout en exigeant des mesures effectives pour empêcher ou décourager sérieusement l’accès depuis les États membres aux liens retirés des versions européennes. Les affaires TU et RE concernaient une demande relative à des informations prétendument inexactes et ont clarifié des éléments de la charge de la preuve et du traitement des images d’aperçu. Ces arrêts sont des décisions juridiques propres à leurs faits, et non une liste de contrôle pour le déploiement. Ensemble, ils font valoir un point systémique : le lien, la liste de résultats, l’aperçu d’image et la page d’origine ne relèvent pas automatiquement du même remède.

Ce point se transpose bien. Un portail d’entreprise peut conserver légalement un enregistrement source à des fins limitées, tandis qu’un accès via une large surface de recherche serait excessif. Un système d’assistance technique peut avoir besoin d’une entrée d’audit protégée, tandis que son aperçu de saisie semi-automatique ne devrait pas exposer les coordonnées d’un ancien client à un grand nombre de personnes. Un document peut être retiré d’un corpus de recherche tandis qu’un résumé généré par un modèle demeure dans un autre espace de stockage. La bonne réponse n’est pas de déclarer toutes les couches identiques. Elle consiste à comprendre comment la couche modifie l’exposition, la finalité et le risque.

Il met aussi en garde contre un raccourci courant : supposer que la visibilité est le seul problème de confidentialité. Un enregistrement peut être techniquement masqué et pourtant être traité, interrogé, profilé, transféré ou restauré. À l’inverse, une organisation peut avoir besoin d’un enregistrement soigneusement limité pour prouver qu’elle a répondu correctement, protéger une action en justice ou satisfaire à une obligation légale. La confidentialité n’est pas un concours visant à produire le moins de données possible dans toutes les circonstances imaginables. C’est une discipline de finalité, de nécessité, de proportionnalité et de contrôle.

C’est pourquoi un inventaire des suppressions devrait inclure les chemins de récupération et de présentation. Demandez-vous quels index contiennent l’enregistrement, quels caches le servent, quelles exportations l’incluent, quelles API le renvoient, quels champs dérivés servent à classer ou à recommander, et quels chemins de restauration de sauvegarde pourraient le rendre de nouveau actif. La liste ne sera pas élégante. Elle sera plus utile que l’élégance.

La démonstration diffère de l’affirmation

Lorsqu’un système prétend pouvoir effacer des données, deux questions distinctes se posent. La première est de savoir si la conception dispose d’un chemin légitime et documenté pour le faire. La seconde est de savoir si une organisation peut démontrer que ce chemin a été suivi pour une demande particulière sans conserver plus de données personnelles que la démonstration ne l’exige. La première est une capacité produit. La seconde est une question de responsabilité.

Un enregistrement d’effacement utile est volontairement modeste. Il n’a pas besoin de reproduire l’intégralité de la demande, des documents ou de l’historique du compte d’une personne dans une nouvelle base de données de conformité. Il peut consigner une référence de demande, le résultat de la vérification d’identité le cas échéant, la catégorie de la demande, les systèmes concernés, la décision et la justification juridique à un niveau approprié, les dates d’action, les exceptions ou motifs de conservation, les notifications aux destinataires lorsque requis, et le statut de la suppression asynchrone ou de l’expiration des sauvegardes. Les champs exacts dépendent du responsable du traitement et du contexte. Ce qui importe, c’est qu’un examinateur ultérieur puisse voir le chemin sans reconstituer le contenu sensible à partir de fragments.

La vérification doit correspondre à la surface des données. Un enregistrement d’application en production peut être vérifié en confirmant qu’une recherche autorisée ne le renvoie plus. Un système de récupération peut être testé avec l’identifiant d’origine et les modèles de requête pertinents, tout en évitant de larges tentatives de recréation du contenu personnel. Un index peut indiquer son état de suppression. Une file d’attente peut montrer son achèvement. Un processus de sauvegarde peut montrer qu’une image de récupération est protégée par sa règle de conservation et que la restauration applique un registre de suppressions à jour ou un contrôle équivalent. La vérification n’a pas besoin de prouver une négation métaphysique. Elle doit fournir des preuves proportionnées à l’affirmation faite.

Il y a ici un piège modeste. Une équipe peut construire un tableau de bord impressionnant avec tous les voyants au vert et sans aucun lien stable avec le travail réel. Un tableau de bord utile nomme la surface de données, l’action, l’état, le responsable, la preuve et la prochaine revue. Il permet de distinguer « demande acceptée », « enregistrement en production supprimé », « notification au destinataire en attente », « sauvegarde en attente d’expiration » et « conservé en vertu d’une obligation légale ». Ces états ont des significations différentes. Les réduire tous à « supprimé » transforme l’incertitude en choix de conception d’interface utilisateur.

L’effacement démontrable dépend aussi de la gestion des changements. Un système source peut être remplacé, un sous-traitant ajouté, un format d’index modifié, une nouvelle destination d’analyse introduite, ou la politique de conservation d’un fournisseur d’IA révisée. Si la procédure d’effacement n’est pas mise à jour avec ces changements, elle décrit progressivement un système qui n’existe plus. Le résultat est familier à toute discipline opérationnelle : un beau manuel d’exploitation et un service réel qui vont dans des directions opposées. Tester régulièrement un petit échantillon du chemin, y compris le système difficile, est généralement plus révélateur que de commander un grand document d’assurance que personne ne peut exécuter.

Pour une autorité publique ou une entreprise réglementée, il ne s'agit pas d'une préoccupation étroite du bureau de la protection des données. Le délégué à la protection des données peut guider l'interprétation, mais l'ingénierie est responsable des interfaces et des mécanismes de suppression, le produit est responsable de la finalité et du parcours utilisateur, les achats sont responsables des obligations d'information imposées aux fournisseurs, la sécurité est responsable des contrôles d'accès et de restauration, et les opérations sont responsables de l'exécution sous pression. Un propriétaire unique ne peut pas inspecter chaque couche seul. Une couche sans propriétaire n'est pas rendue sûre par le fait qu'elle soit difficile à aborder.

Un processus défendable consigne sa décision et son exécution sans créer une seconde biographie inutile de la personne.

La conservation est l'autre moitié de la suppression

De nombreux problèmes de suppression commencent bien avant une demande. Ils commencent lorsqu'un système n'a aucune décision de conservation. Les données arrivent parce qu'elles pourraient devenir utiles. Les journaux deviennent permanents parce que le stockage est bon marché. Les exports sont conservés parce qu'un futur audit pourrait les demander. Les données d'entraînement sont accumulées parce qu'un futur modèle pourrait en bénéficier. Chaque décision semble inoffensive isolément. Ensemble, elles transforment une organisation en propriétaire d'une vaste archive mal comprise et rendent chaque demande d'effacement plus coûteuse, plus incertaine et plus contentieuse.

Le principe de limitation de la conservation du RGPD stipule que les données personnelles doivent être conservées sous une forme permettant l'identification des personnes concernées pendant une durée n'excédant pas celle nécessaire au regard des finalités pour lesquelles elles sont traitées, sous réserve d'une conservation plus longue à des fins d'archivage dans l'intérêt public, de recherche scientifique ou historique, ou à des fins statistiques, lorsque des garanties appropriées sont prévues. Le principe ne prescrit pas un calendrier unique pour chaque organisation. Il exige un jugement lié à la finalité. Un calendrier de conservation doit donc nommer les catégories de données, la finalité, la base juridique, la durée normale, l'événement déclencheur, l'exception, l'action de destruction, le responsable et le point de révision. « Aussi longtemps que nécessaire » est un principe. Il devient une règle opérationnelle uniquement lorsque quelqu'un peut dire nécessaire pour quoi, jusqu'à quand, et décidé par qui.

Cette structure est utile pour l'IA car elle empêche qu'une étiquette large, telle que données d'entraînement, ne masque plusieurs choses différentes. Une contribution brute, un ensemble de données nettoyé, un ensemble de caractéristiques, une version de modèle, un historique de requêtes, un ensemble d'évaluation et un journal de surveillance peuvent chacun avoir des finalités et des considérations de conservation différentes. Les combiner dans un seul compartiment indéfini aggrave à la fois l'innovation et la responsabilité. Les séparer ne garantit pas une réponse juridique, mais cela la rend possible.

Les décisions de conservation bénéficient également d'une condition de refus. Qu'est-ce qui nous ferait cesser de conserver ceci ? Un contrat terminé, un litige résolu, la fin d'une période légale, une enquête de sécurité achevée, une version de modèle remplacée, l'expiration d'une fenêtre de restauration, ou une décision de ne pas poursuivre une finalité de recherche peuvent tous être de véritables déclencheurs. Le but n'est pas d'automatiser une horloge de suppression pour tout. Il s'agit d'éviter un système dans lequel la seule condition pour conserver des données est que personne n'a encore été tenu de les expliquer.

Il y a un petit instinct néerlandais qui vaut la peine d'être conservé ici : une armoire n'est pas organisée parce qu'elle a une porte. Elle est organisée parce que vous pouvez trouver la chose pertinente, savoir pourquoi elle est là et la retirer sans déménager. Un patrimoine de données mérite au moins cette norme. Un calendrier de conservation qui ne survit pas à une conversation avec les personnes qui exploitent le système n'est pas un calendrier. C'est une prévision météorologique rédigée en prose juridique.

Ceci ne signifie pas que chaque organisation doit centraliser toutes les décisions de suppression. Les équipes locales comprennent souvent mieux leurs processus. Cela signifie que les règles locales ont besoin de concepts communs, d'une propriété visible et d'une voie d'escalade. Sinon, l'archive d'une équipe est la violation d'une autre, et la demande d'une personne est acheminée à travers un labyrinthe de services aux noms polis.

Ce qu'un fournisseur d'IA honnête peut dire

Un fournisseur d'IA honnête ne prétend pas que toutes les données clients s'évaporent lorsqu'une demande arrive. Il ne se cache pas non plus derrière la difficulté des modèles. Il décrit la limite du service. Ce qui est traité pour l'inférence. Ce qui est conservé pour l'administration du compte, la sécurité, le support, la facturation ou la prévention des abus. Si les invites et les sorties sont stockées. Si elles sont utilisées pour l'entraînement, l'évaluation ou l'amélioration du service. Quels sous-traitants et quelles régions sont impliqués. Comment les clients peuvent configurer la conservation. Quelle documentation existe pour les demandes des personnes concernées. Quelles actions sont immédiates, lesquelles sont asynchrones, et lesquelles dépendent d'une évaluation juridique distincte.

Pour les acheteurs, les questions d'approvisionnement sont pratiques. Pouvons-nous obtenir une carte claire du flux de données ? Pouvons-nous identifier les rôles de responsable du traitement et de sous-traitant pour le traitement concerné ? Pouvons-nous exporter ou supprimer des éléments de manière utilisable ? Les index de recherche et les magasins dérivés sont-ils inclus dans le cycle de vie documenté ? Qu'advient-il des sauvegardes ? Comment les changements de sous-traitants sont-ils communiqués ? Le fournisseur peut-il nous aider à répondre à une demande dans les délais applicables ? Les utilisations pour l'entraînement et l'amélioration du service sont-elles opt-in, opt-out, contractées, ou décrites uniquement sur une page qui peut changer après l'achat ? Quels enregistrements techniques sont disponibles pour prouver l'action ?

Les réponses varieront. Un grand service partagé ne peut pas toujours offrir le même contrôle qu'un environnement dédié. Un journal de sécurité ne peut pas toujours être supprimé au même moment qu'un profil de compte. Une archive légale ne peut pas être traitée comme une préférence de consommateur. Ces différences ne sont pas nécessairement des échecs. Le silence à leur sujet l'est. La bonne réponse de l'acheteur est de faire correspondre le comportement documenté du service à l'objectif, aux obligations et au risque de l'organisation. Un produit peut être inadapté à une tâche très sensible même s'il est tout à fait adapté à un outil de rédaction à faible risque.

Chez Dweve, notre Trust Centre adopte la même vision étroite des preuves. Une page publique peut décrire les contrôles et les limites documentaires, mais elle ne peut pas certifier chaque déploiement client ni décider de la base légale du traitement d'un client. Cette limite est importante. Une plateforme peut prendre en charge les contrôles de conservation, les enregistrements et les flux de travail vérifiables. L'organisation qui l'utilise conserve toujours son objectif, ses choix en matière de données et la décision de répondre à une personne particulière. Un bon texte produit devrait rendre cette responsabilité plus claire, pas l'hériter silencieusement.

La déclaration la plus précieuse d'un fournisseur est souvent une limitation. « Cet enregistrement restera dans les sauvegardes protégées jusqu'à la fin de la période de rotation indiquée. » « Ce service n'utilise pas le contenu client spécifié pour l'entraînement selon ces conditions. » « Cet index est supprimé de manière asynchrone et son statut peut être vérifié ici. » « Nous ne pouvons pas faire cette déclaration pour une intégration tierce. » Ces phrases peuvent sembler moins magiques qu'une promesse universelle de confidentialité. Elles permettent à un acheteur de concevoir un processus réel.

Des questions à se poser avant que la demande n'arrive

Une organisation n’a pas besoin d’inventer une violation, une personne en détresse ou un incident héroïque au milieu de la nuit pour tester sa conception de l’effacement. Elle peut utiliser une demande hypothétique clairement identifiée comme telle pendant les heures de travail ordinaires. Supposons qu’une personne demande la suppression de données détenues dans un système destiné aux clients. Quelle équipe reçoit la demande ? Comment l’identité est-elle vérifiée sans collecter de nouvelles informations excessives ? Quelles finalités sont pertinentes ? Quels systèmes contiennent les données sources, les dérivés, les index, les journaux, les caches, les exports et les copies de récupération ? Quels sous-traitants ont besoin d’une instruction ou d’une notification ? Quelle exception ou obligation de conservation, le cas échéant, s’applique ? Qui peut décider ? Qui peut exécuter ? Comment l’organisation expliquera-t-elle le résultat ?

Posez ensuite les questions techniques délicates. Un opérateur peut-il trouver l’inventaire actuel des données sans l’aide d’un ancien ingénieur ? Un index de recherche peut-il être vérifié indépendamment de sa table source ? Un identifiant supprimé réapparaît-il après une restauration ? Les traitements par lots utilisent-ils d’anciens instantanés ? Un stockage d’embeddings peut-il être relié à ses documents et à son locataire ? Un pipeline de surveillance capture-t-il le contenu des invites par défaut ? Les fichiers d’export sont-ils soumis aux mêmes règles de conservation que leur source ? L’enregistrement des preuves crée-t-il un nouveau tas de contenus sensibles ? Ce ne sont pas des cas limites ajoutés pour donner l’air sérieux à une politique. Ce sont des conséquences ordinaires de systèmes qui font des copies pour fonctionner.

Enfin, posez la question de gouvernance : qu’est-ce qui ferait changer l’organisation d’avis ? Une nouvelle obligation légale, une identité contestée, une action en justice en cours, un changement de fournisseur, un échec de vérification de la suppression, une restauration de sauvegarde, un nouveau pipeline de modèles ou une décision d’un régulateur peuvent chacun avoir leur importance. Un processus sans déclencheur de réexamen n’est qu’une hypothèse initiale promue au rang de politique.

Aucun de ces éléments ne remplace un avis juridique dans un cas particulier. Les exigences du RGPD, le droit national, les obligations sectorielles, les contrats et les faits du traitement comptent tous. Mais les organisations n’ont pas besoin d’un litige pour commencer à concevoir les conditions d’une réponse intelligible. Elles doivent connaître suffisamment leurs systèmes pour cesser d’offrir une simple promesse face à une réalité compliquée.

La vie privée est la qualité du résidu

L’ambition derrière l’effacement n’est pas de rendre le passé irréel. Elle est de donner aux personnes un contrôle réel lorsque les données n’ont plus besoin d’être traitées, lorsque le consentement a été retiré, lorsque le traitement est illicite, ou lorsqu’un autre motif de l’article 17 s’applique. Elle demande aux responsables de traitement de considérer les données personnelles comme quelque chose de détenu pour une finalité, et non comme une matière première bénéficiant d’un bail indéfini. Elle leur demande d’expliquer les exceptions plutôt que de les utiliser comme une machine à brouillard. Elle demande aux systèmes de porter suffisamment de lignage pour que l’oubli puisse être délibéré.

Pour les services numériques, le test discret est ce qui reste. Après le retrait d’un enregistrement d’un écran produit, qu’est-ce qui est encore actif ? Après le départ d’un document d’un corpus de recherche, quelle représentation dérivée le sélectionne encore ? Après la suppression d’un compte, quel journal est conservé, à quelle fin et pour combien de temps ? Après la restauration d’une sauvegarde, qu’est-ce qui empêche un enregistrement retiré de revenir ? Après un changement de modèle, quel historique de données peut être inspecté ? Après la clôture d’une demande, l’organisation peut-elle montrer son travail sans constituer un autre profil caché ?

Un système répondra rarement à toutes ces questions par une seule action et un seul horodatage. C’est normal. Ce qui n’est pas normal, c’est de prétendre que les questions disparaissent parce que les données sont difficiles, distribuées ou rentables. La vie privée n’est pas le moment où un service apprend une commande de suppression. C’est ce qui reste après que le système a appris à oublier avec une finalité, une limite et une trace de sa propre retenue.

Sources