L'effacement impossible

Éditorial

Supprimer une donnée ne la fait pas disparaître : elle survit dans les sauvegardes, les journaux, les index, les caches, les réplicas et parfois dans des modèles entraînés. Le seul effacement qui passe à l'échelle consiste à détruire une clé, à condition d'avoir chiffré au bon grain avant d'en avoir besoin.

Mis à jour le 25 septembre 2026~27 min de lecture14 sections

papy cyber

→ Lire l’explication complète de la marmotte

Un bouton qui ment poliment

Toutes les interfaces ont un bouton « Supprimer ». C’est le plus honnête des mensonges de l’informatique, et peut-être le seul qui soit universellement apprécié. L’objet disparaît de l’écran, n’apparaît plus dans les listes, ne remonte plus dans les recherches. La personne qui a cliqué éprouve le petit soulagement de qui vient de jeter une lettre au feu. Elle a tort, mais elle l’ignore, et nous nous gardons bien de la détromper.

Du point de vue du système, presque rien ne s’est passé. Une ligne a été marquée comme morte dans une table, à la manière dont on raye un nom sur un registre paroissial sans arracher la page. Un drapeau a changé de valeur. Les octets, eux, n’ont pas bougé : dans le fichier de données tant que personne ne l’a compacté, dans le journal de transactions, dans les réplicas, dans la sauvegarde de cette nuit et dans celles des semaines précédentes, dans les journaux applicatifs, dans l’index de recherche, dans le cache du proxy, dans l’export mensuel qu’un analyste a déposé sur un partage en l’appelant final_v3_ok.xlsx.

Ce n’est pas un défaut d’implémentation. C’est l’aboutissement de trente ans de bonnes pratiques. Un système d’information bien conçu est un système qui refuse de perdre des données. Redondance, réplication, journalisation, sauvegarde, versionnement, cache : nous avons consacré des carrières entières à rendre l’écriture immortelle. Puis un jour quelqu’un nous demande d’oublier, et nous découvrons avec une certaine gêne que nous avons construit une cathédrale de la mémoire sans prévoir de porte de sortie.

L’éditorial Ce qu’on garde posait une question de tri : que mérite-t-on de conserver, et sous quelle forme ? Celui-ci part de l’autre bout. Supposons la décision prise : cette donnée doit disparaître, parce qu’une personne l’a demandé, parce qu’une durée de conservation est échue, parce qu’un secret s’est égaré là où il n’avait rien à faire. Que faut-il faire, techniquement, pour que ce soit vrai ? Et que peut-on honnêtement promettre quand on ne sait pas le faire ?

Ma thèse tient en deux phrases, ce qui à mon âge relève de l’exploit. L’effacement physique d’une donnée dans un système réel est, dans le cas général, impossible à garantir : on ne sait ni énumérer toutes les copies, ni les atteindre toutes. Le seul effacement qui passe à l’échelle est cryptographique : rendre toutes les copies illisibles d’un coup en détruisant la clé qui les protège, ce qui suppose d’avoir chiffré au bon grain au moment de l’écriture, c’est-à-dire bien avant que quiconque ne demande quoi que ce soit.

Anatomie d’une donnée qui ne veut pas mourir

Il faut prendre le temps d’énumérer, parce que l’illusion de l’effacement vient précisément de ce qu’on ne regarde qu’une copie : celle que l’application affiche. Prenons une donnée d’une parfaite banalité, l’adresse électronique d’un client, et suivons-la comme on suit un parent éloigné dans un arbre généalogique, avec la consternation croissante de qui découvre l’étendue de la famille.

Dans la base elle-même

La plupart des moteurs relationnels ne réécrivent pas les données en place lors d’une suppression. PostgreSQL, par exemple, marque la version de ligne comme morte ; l’espace n’est récupéré qu’au passage du nettoyage (VACUUM), et même alors il est rendu disponible pour de futures écritures plutôt que remis à zéro. La ligne n’est pas morte : elle est en sursis, et son exécution dépend du hasard des insertions à venir.

Il y a ensuite le journal de transactions. Toute écriture passe d’abord par un journal d’écriture anticipée, souvent archivé pour permettre la restauration à un instant donné. La création de la ligne y figure, avec son contenu. La suppression y figure aussi, comme un événement postérieur. Rejouer le journal jusqu’à la veille reconstitue la donnée : c’est exactement ce pour quoi on l’a archivé.

Enfin, les réplicas. Chaque nœud a reçu l’écriture, chaque nœud reçoit la suppression, avec les mêmes limites. Le réplica retardé, configuré pour avoir quelques heures de retard afin de rattraper une erreur humaine, contient la donnée pendant tout ce délai. C’est son rôle. On l’a précisément payé pour ne pas croire ce qu’on lui dit tout de suite.

Autour de la base

La donnée n’est pas restée sagement dans la base. Elle a été indexée par le moteur de recherche interne, qui en a fait des jetons répartis dans des segments. Dans les moteurs dérivés de Lucene, un document supprimé est marqué comme tel et ne disparaît physiquement qu’à la fusion de son segment, ce qui peut prendre longtemps sur un index paisible.

Elle a été mise en cache, à trois ou quatre étages. Elle a été journalisée. Le journal d’accès a noté l’URL qui la portait en paramètre. Le journal applicatif a tracé l’erreur de validation qui l’affichait en clair. L’outil de suivi des exceptions a capturé la requête complète, corps compris, avec le zèle d’un greffier qui recopierait aussi les ratures. Le tout est parti vers un agrégateur centralisé, dont la durée de conservation a été fixée par une autre équipe, pour d’autres raisons, lors d’une réunion dont il ne reste aucun compte rendu.

Elle a été copiée : dans l’entrepôt de données alimenté chaque nuit, dans l’environnement de recette rafraîchi depuis la production « pour avoir des données réalistes » (formule qui a fait plus pour la dissémination des données personnelles que toutes les fuites réunies), dans un tableur exporté pour une campagne, dans un ticket de support, dans une messagerie où elle a voyagé en pièce jointe.

Sous tout cela

Et sous chacune de ces couches, il y a le support physique. Sur un disque magnétique, écraser un bloc écrase ce bloc. Sur un SSD, ce n’est plus vrai : le contrôleur répartit les écritures pour égaliser l’usure des cellules, écrit les nouvelles données ailleurs, et garde en réserve des cellules invisibles au système d’exploitation. Écraser un fichier ne garantit pas que les anciennes cellules aient été effacées ; le disque a sa vie intérieure, et il ne nous la raconte pas. Les recommandations publiques sur l’assainissement des supports, comme la publication SP 800-88 du NIST, tiennent compte de cette différence et rangent l’effacement cryptographique parmi les méthodes admises pour les supports qui le prennent en charge.

Au bout de l’énumération, un constat s’impose : la donnée a été écrite une fois et existe en un nombre de copies que personne, dans l’organisation, n’est capable de donner. Pas par négligence : chaque copie a été créée par un mécanisme légitime, conçu par une équipe différente, avec son propre cycle de vie. L’ensemble a la cohérence d’une succession où chaque héritier aurait emporté un meuble.

Trois verbes que l’on confond

Le mot « supprimer » recouvre au moins trois opérations qui n’ont ni le même coût, ni la même portée. La langue française, qui dispose de onze manières de dire « pleuvoir », n’en a prévu qu’une pour celle-ci, et c’est dommage.

Masquer. L’objet n’est plus présenté. C’est la suppression logique : un drapeau, une date de suppression, un statut. Elle est instantanée, réversible, et ne réduit en rien l’exposition. Pour un attaquant qui obtient une copie de la base, une donnée masquée est une donnée présente, avec en prime une étiquette qui signale qu’on aurait préféré qu’il ne la voie pas.

Retirer. L’objet est supprimé de son stockage primaire : le moteur ne le retournera plus et libérera l’espace un jour. C’est ce que fait un DELETE suivi d’un nettoyage. Il reste toutes les copies secondaires, et les octets résiduels jusqu’à réécriture.

Détruire. Il n’existe plus aucun moyen, pour personne, de reconstituer l’information à partir de ce que le système détient. C’est la seule opération qui corresponde à ce que la personne a en tête quand elle demande l’effacement, et c’est la seule qu’on ne sait presque jamais faire.

La confusion n’est pas innocente. Nous vendons de la destruction et nous livrons du masquage, avec la meilleure foi du monde, parce que l’interface ne fait aucune différence et que la personne qui a rédigé le message de confirmation (« Vos données ont été supprimées ») n’a jamais été présentée à celle qui administre les sauvegardes. Elles travaillent dans le même bâtiment. Elles se croisent parfois à la machine à café. Elles ne parlent pas de ça.

Ce que demande le droit, et ce qu’il ne dit pas

Le droit à l’effacement du RGPD, prévu à son article 17, donne à la personne concernée le droit d’obtenir l’effacement de ses données dans un certain nombre de cas : quand elles ne sont plus nécessaires, quand le consentement est retiré, quand le traitement est illicite, entre autres. Il connaît aussi des exceptions, notamment lorsque la conservation est imposée par une obligation légale ou nécessaire à la défense de droits en justice.

Ce que le texte ne dit pas, c’est comment. Il ne distingue pas le masquage de la destruction ; il ignore superbement les sauvegardes, les journaux de transactions et les segments d’index. C’est cohérent avec sa logique (un texte technologiquement neutre fixe un résultat, pas un procédé), et c’est exactement ce qui laisse l’ingénieur seul face à la question, dans la posture du traducteur à qui l’on a confié un poème sans lui préciser la langue d’arrivée.

Sur les sauvegardes, une position pragmatique est couramment admise dans la pratique : on ne restaure pas une sauvegarde entière pour en retirer une personne, mais on s’assure que la donnée ne sera pas réutilisée si la sauvegarde est restaurée, et qu’elle disparaîtra au rythme normal de la rotation. Je la trouve raisonnable. Je note qu’elle repose sur deux conditions rarement vérifiées : que la procédure de restauration réapplique effectivement les effacements intervenus depuis, et que la rotation existe vraiment. Une sauvegarde conservée « indéfiniment, au cas où » ne disparaît au rythme de rien. Elle attend, comme ces cousins de province qui ne meurent jamais et héritent de tout le monde.

Pourquoi la chasse aux copies échoue

On pourrait penser que le problème est affaire de rigueur : dresser l’inventaire de toutes les copies, puis écrire une procédure qui les parcourt une à une. C’est ce que tentent les organisations sérieuses, et c’est une bonne pratique. Il faut seulement être lucide sur ses limites, qui ne tiennent pas à la paresse des équipes mais à la nature des choses.

L’inventaire est toujours en retard. Chaque nouvel outil, chaque nouveau flux, chaque export ponctuel crée une copie qui n’était pas dans la liste. L’inventaire décrit l’architecture telle qu’elle était le jour où on l’a fait, à la façon de ces cartes anciennes où les continents inconnus s’ornaient de dragons. Le tableur d’un analyste pour une réunion de mardi n’apparaîtra dans aucun registre ; c’est notre dragon.

Certaines copies sont inaccessibles par conception. Une sauvegarde immuable, conçue pour qu’aucun identifiant ne puisse la modifier avant l’échéance (c’est le sujet de l’éditorial sur la règle 3-2-1 face au rançongiciel), ne peut pas être purgée d’une personne. Si on le pouvait, un attaquant le pourrait aussi. Les propriétés qui rendent une sauvegarde fiable sont exactement celles qui la rendent impossible à expurger. Ce n’est pas un compromis à trouver, c’est une contradiction à accepter, ce qui est plus rare et nettement moins confortable.

Certaines copies sont hors de votre périmètre. Le prestataire de messagerie, le support externalisé, l’outil d’analyse d’audience, le sous-traitant de paie : chacun a ses sauvegardes, ses journaux, ses réplicas. Vous pouvez leur transmettre la demande, et vous le devez. Vous ne pouvez pas vérifier ce qu’ils en font.

D’où la conclusion inconfortable : on ne peut pas garantir la destruction d’une donnée en chassant ses copies. On peut en réduire le nombre, raccourcir leur durée de vie, documenter celles qu’on connaît. On ne peut pas atteindre la dernière, parce qu’on ne sait pas laquelle c’est. C’est toujours celle à laquelle on n’a pas pensé, par définition.

Détruire la clé plutôt que la donnée

Si l’on ne peut pas atteindre toutes les copies, il faut s’arranger pour qu’elles deviennent toutes inutiles en même temps. C’est le principe de l’effacement cryptographique, que les anglophones appellent crypto-shredding avec ce goût du broyeur qui les caractérise.

L’idée est d’une simplicité presque vexante. Chaque donnée est chiffrée, au moment de l’écriture, avec une clé qui ne sert qu’à un périmètre déterminé : une personne, un client, un dossier, un locataire. Toutes les copies en aval (réplicas, sauvegardes, exports, journaux de transactions) contiennent le chiffré, jamais le clair. La clé est conservée à un seul endroit, dans un service dont c’est le métier. Le jour où il faut effacer, on ne cherche pas les copies : on détruit la clé, et toutes les copies deviennent simultanément un bruit indéchiffrable, y compris celles qu’on ne connaissait pas, y compris celles qui sont immuables, y compris celles qui dorment chez un prestataire. On ne brûle pas les lettres une à une : on oublie la langue dans laquelle elles étaient écrites.

Le mécanisme n’a rien d’exotique. C’est le chiffrement par enveloppe que pratiquent déjà la plupart des services de stockage : une clé de données chiffre le contenu, une clé de chiffrement de clés protège la clé de données. La distinction entre clé de données et clé de chiffrement de clés est le levier : détruire une clé de données rend illisible ce qu’elle protégeait ; détruire une clé de chiffrement de clés rend illisibles toutes les clés qu’elle enveloppait, donc tout ce qu’elles protégeaient.

Ce qui distingue l’effacement cryptographique du chiffrement au repos ordinaire, c’est le grain. Le chiffrement de disque protège contre le vol du disque, avec une clé pour tout le volume. Le chiffrement transparent d’une base protège contre la lecture des fichiers, avec une clé pour toute la base. Ni l’un ni l’autre ne permet d’effacer une personne : détruire la clé effacerait tout le monde, ce qui est une manière radicale de satisfaire une demande individuelle. Pour que la destruction d’une clé corresponde à l’effacement d’un sujet, il faut une clé par sujet, donc un chiffrement applicatif, champ par champ ou enregistrement par enregistrement. La page sur la protection des données au repos détaille ces niveaux ; seul le plus fin sert l’effacement.

Ce que cela change dans l’architecture

Un système conçu pour l’effacement cryptographique a quelques traits reconnaissables :

une table de correspondance entre sujets et identifiants de clés, qui est la seule chose à mettre à jour lors d’un effacement ;
des données personnelles qui ne quittent jamais le service applicatif en clair : les exports, les journaux et l’entrepôt reçoivent le chiffré, ou une donnée pseudonymisée par une clé elle aussi destructible ;
un service de gestion de clés qui sait réellement détruire une clé, et qui journalise cette destruction ;
des sauvegardes de ce service pensées à part, parce que c’est le seul endroit où la question de l’effacement physique se pose encore.

La différence est que ce problème-là est soluble. Un coffre de clés contient des objets de taille fixe, dans un système unique, avec des sauvegardes qu’on peut concevoir pour avoir une rotation courte et vérifiable. C’est de l’ingénierie ordinaire. Chasser une adresse électronique dans quarante systèmes relève de la spéléologie.

Les angles morts de la destruction de clé

L’effacement cryptographique est la seule réponse qui passe à l’échelle. Ce n’est pas une réponse complète, et je m’en voudrais de remplacer un mensonge poli par un autre, plus savant.

Tout ce qui a été déchiffré a pu être copié en clair. La clé ne protège que les copies restées chiffrées. Le tableur exporté, le ticket de support, la capture d’écran, la réponse d’API mise en cache, le texte transmis à un service d’analyse : tout ce qui est sorti en clair échappe à la destruction. L’effacement cryptographique vaut exactement ce que vaut la discipline qui empêche le clair de fuir. Il se conçoit donc avec les flux de sortie, pas seulement avec le stockage.

Les données dérivées ne sont pas protégées par la clé de la source. Un index construit sur le clair, un agrégat statistique, un score, un vecteur de plongement sémantique calculé à partir d’un texte : ces objets sont produits depuis la donnée et stockés ailleurs. Un vecteur de plongement n’est pas le texte, mais il n’en est pas non plus orphelin ; des travaux de recherche ont montré que, dans certaines conditions, on peut en retrouver une part significative du contenu. Il faut donc dériver ces objets sous la même clé, les reconstruire après chaque effacement, ou accepter qu’ils survivent.

Le chiffré reste, et la cryptographie vieillit. Détruire la clé rend le chiffré illisible en l’état des connaissances. Pour un chiffrement symétrique moderne correctement employé, la réserve est théorique. Elle l’est moins si l’enveloppe repose sur une cryptographie asymétrique que des ordinateurs quantiques pourraient un jour affaiblir, ou si l’implémentation a une faiblesse. Le chiffré conservé des années dans une sauvegarde immuable attend, patient comme un testament, toute la cryptanalyse future.

La granularité a un coût. Une clé par personne, ce sont potentiellement des millions de clés, des appels au service à chaque lecture, une mise en cache des clés déchiffrées (qui recrée une copie à gérer), et des requêtes qui ne peuvent plus filtrer ni trier sur les champs chiffrés sans mécanismes supplémentaires.

Les identifiants eux-mêmes posent problème. Pour savoir quelle clé détruire, il faut savoir à qui appartient chaque enregistrement. La table sujet-clé contient donc un identifiant du sujet. Elle doit être elle-même effaçable, ou l’identifiant doit être un pseudonyme sans signification hors du système. Faute de quoi on aura soigneusement tout effacé, sauf la liste des gens qu’on a effacés.

Le cas des modèles entraînés

Il reste un lieu où aucune des techniques précédentes ne s’applique, et il prend chaque année plus de place : les modèles statistiques entraînés sur des données qui contenaient celle qu’il faudrait effacer.

Un modèle n’est pas une base de données. Il ne contient pas les exemples sous forme d’enregistrements qu’on pourrait retirer ; il contient des paramètres, ajustés par l’ensemble du corpus, où l’influence de chaque exemple est diffuse. Pour certains (rares, répétés, très caractéristiques), les modèles de langage peuvent mémoriser et restituer le contenu mot pour mot, ce que des travaux de recherche sur l’extraction de données d’entraînement ont démontré publiquement. La donnée n’est plus dans un tiroir ; elle est dans le caractère du modèle, et l’on sait ce qu’il en coûte de corriger un caractère.

Que signifie alors effacer ? Trois options, aucune satisfaisante.

Réentraîner sans la donnée. C’est la seule méthode qui donne une garantie propre : le nouveau modèle n’a jamais vu l’exemple. C’est aussi, pour un grand modèle, une opération dont le coût rend absurde de la déclencher à chaque demande.

Désapprendre. La recherche sur le machine unlearning cherche à modifier un modèle existant pour qu’il se comporte comme s’il n’avait pas vu certains exemples. En l’état de ce que je sais, elle ne fournit pas de garantie vérifiable comparable à un réentraînement : on sait mesurer que le modèle ne restitue plus une donnée à une certaine requête, on sait beaucoup moins bien prouver qu’aucune requête ne la fera ressortir. C’est l’amnésie sur parole.

Filtrer en sortie. On laisse le modèle tel quel et on bloque les réponses qui contiennent la donnée. C’est du masquage, avec une interface plus coûteuse. La donnée est toujours là ; on a tiré un rideau.

La conclusion pratique pour une petite structure est plus simple que le débat : ne mettez pas dans un entraînement ce que vous pourriez avoir à effacer. Pour un modèle affiné localement sur des documents internes, cela veut dire trier le corpus avant, pas après. Pour un système de recherche augmentée, qui interroge des documents au lieu de les apprendre, la situation est nettement meilleure : la donnée vit dans un index séparé qu’on sait reconstruire, et c’est un argument architectural réel quand l’effacement compte.

Quant à savoir si un modèle entraîné « contient » des données personnelles au sens du droit, la question est discutée par les autorités de protection des données et je ne prétends pas la trancher. Je me borne à observer qu’elle n’est pas close, ce qui est une excellente raison de ne pas s’y exposer quand on peut l’éviter.

Le meilleur argument contre

Il faut maintenant donner à l’objection sa meilleure forme, parce qu’elle est sérieuse, et que j’ai passé l’âge de gagner les débats contre des adversaires imaginaires mal armés.

L’effacement cryptographique est une réponse d’ingénieur à un problème qui n’en demande pas tant. La plupart des petites structures reçoivent peu de demandes d’effacement, détiennent des données d’une sensibilité ordinaire, et font tourner leurs sauvegardes sur quelques semaines. Pour elles, la réponse honnête consiste à supprimer dans le système principal, à documenter que les sauvegardes expireront au rythme de leur rotation, à s’assurer que la restauration réapplique les suppressions, et à le dire à la personne concernée. C’est une suppression imparfaite, mais bornée dans le temps et expliquée, et elle ne coûte presque rien. Introduire un chiffrement par sujet avec un service de gestion de clés, c’est ajouter une dépendance critique pour résoudre un problème qui se résout tout seul en quelques semaines.

L’argument va plus loin. L’effacement cryptographique crée un risque de disponibilité qui n’existait pas. Une erreur dans la gestion des clés, un script qui détruit la mauvaise clé, une sauvegarde du coffre défaillante : et c’est de la donnée légitime qui devient irrécupérable, définitivement, avec toute l’efficacité qu’on avait réclamée.

Je trouve cet argument juste pour ce qu’il décrit. J’y fais deux réserves.

La première : il suppose que la rotation des sauvegardes est courte et réelle. C’est exactement ce qui dérive : une archive annuelle ajoutée « pour la conformité », une copie hors ligne sans date de fin, un export de migration jamais supprimé. La promesse « tout aura disparu d’ici un mois » est vraie le jour où on la formule et fausse dix-huit mois plus tard, sans que personne ait rien décidé. Les politiques de rétention ont ceci de commun avec les régimes alimentaires qu’elles sont toujours respectées la première semaine.

La seconde : il ne traite que la demande individuelle. L’effacement cryptographique change réellement la donne pour la fin de relation avec un client entier, le départ d’un locataire dans un service mutualisé, la fin de conservation légale d’un lot de dossiers, la destruction d’un jeu de données compromis. Là, chasser les copies devient un chantier ; détruire une clé reste une opération.

Ma position est donc graduée. Pour une petite structure, la suppression bornée et documentée est acceptable, à condition d’en vérifier les hypothèses. L’effacement cryptographique devient la bonne réponse dès qu’on stocke des données pour le compte de plusieurs clients distincts, dès que les sauvegardes sont immuables ou longues, ou dès que la sensibilité des données survit de loin à leur utilité. Dans tous les cas, la décision se prend à la conception, parce qu’elle ne se prend pas après.

Ce qu’on peut faire lundi

Entre le masquage généralisé et la refonte cryptographique, il existe des gestes modestes qui améliorent réellement la situation, et dont aucun ne nécessite de comité de pilotage, ce qui explique sans doute qu’on les fasse si rarement.

Écrire la liste des copies connues. Pour une catégorie de données (les coordonnées des clients, par exemple), lister les endroits où elle se trouve : base, réplicas, sauvegardes, journaux, index, entrepôt, recette, prestataires. La liste sera incomplète. Elle sera infiniment plus utile que l’absence de liste, et elle fera apparaître les copies qui n’ont aucune raison d’exister.

Supprimer les copies gratuites et aligner les durées. Une donnée supprimée de la base mais conservée trois ans dans les journaux n’a pas été supprimée ; elle a déménagé. La recette alimentée par des données réelles, les journaux qui écrivent des corps de requêtes, les exports oubliés sur des partages : ce sont des copies qui n’apportent rien et qu’on peut tarir à la source. C’est là que la minimisation rapporte le plus pour le moins d’effort.

Tester la restauration contre les effacements. Restaurer une sauvegarde dans un environnement isolé et vérifier qu’une donnée effacée depuis ne réapparaît pas dans l’application. Si elle réapparaît, la restauration doit rejouer un registre des effacements, et ce registre doit exister.

Vérifier ce que « supprimer » veut dire chez le fournisseur de stockage. Sur un stockage objet versionné, une suppression crée un marqueur et conserve les versions précédentes. La commande suivante, en lecture seule, montre ce qui subsiste sous un préfixe :

# Lecture seule : versions et marqueurs de suppression qui subsistent
# sous un préfixe d'un compartiment S3 versionné.
aws s3api list-object-versions \
  --bucket mon-compartiment \
  --prefix clients/ \
  --query '{Versions: Versions[].{Cle: Key, Version: VersionId, Actuelle: IsLatest},
            Suppressions: DeleteMarkers[].{Cle: Key, Version: VersionId}}'

Si des versions anciennes apparaissent pour des objets que vous pensiez effacés, ce n’est pas une anomalie : c’est le versionnement qui fait son travail, avec une conscience professionnelle qu’on aimerait voir plus souvent ailleurs. À vous de savoir s’il est compatible avec ce que vous avez promis.

Réécrire les promesses avec le bon verbe. Remplacer « vos données sont supprimées » par ce qui est vrai : « vos données sont supprimées de nos systèmes actifs ; elles subsistent dans nos sauvegardes chiffrées jusqu’à leur expiration, au plus tard dans tel délai, et ne seront pas réutilisées d’ici là ». C’est moins confortable à lire. C’est exact, et l’exactitude est la seule forme de confiance qui résiste à une question précise.

Ce que je ne sais pas

Je ne sais pas quelle part des copies d’une donnée est typiquement inconnue de l’organisation qui la détient. Je la crois substantielle, parce que le mécanisme qui les produit est structurel, mais je n’ai aucune mesure à proposer, et je me méfie de celles qu’on trouve sans méthode publiée.

Je ne sais pas où en sera le désapprentissage dans quelques années. Il est possible que la recherche produise des méthodes aux garanties vérifiables et que la section sur les modèles vieillisse mal. Je l’espère. Je ne construirais pas une promesse d’effacement sur cet espoir aujourd’hui.

Je ne sais pas précisément comment les autorités apprécient l’effacement cryptographique. L’argument technique est solide : un chiffré dont la clé a été détruite est, en pratique, inexploitable. Mais « en pratique » n’est pas « par définition », et je n’ai pas sous les yeux de doctrine publiée qui dise, pour une autorité donnée, qu’un chiffré sans clé équivaut à une donnée détruite. C’est à vérifier auprès de la source.

Ce qui reste

Le mot « supprimer » a été emprunté par l’informatique à un monde où les objets avaient un seul exemplaire. Une lettre brûlée n’existe plus. Une donnée supprimée existe en un nombre de copies que personne ne connaît, et ce nombre mesure assez fidèlement la qualité de l’architecture : plus elle est résiliente, moins elle sait oublier. Nous avons fabriqué des systèmes qui ont la mémoire des éléphants et la discrétion des concierges.

Trois choses me paraissent acquises. Que l’effacement par chasse aux copies ne passe pas à l’échelle, parce que l’inventaire est toujours en retard et que certaines copies sont inaccessibles par conception. Que la destruction de clé est la seule forme d’effacement qui atteint aussi les copies qu’on ne connaît pas, à condition d’avoir chiffré au bon grain, d’avoir empêché le clair de fuir, et d’avoir traité honnêtement les sauvegardes du coffre. Et que l’effacement se décide à l’écriture : un système qui n’a pas été conçu pour oublier ne peut, au mieux, que faire semblant.

Le reste est une affaire de loyauté envers la personne qui clique sur « Supprimer ». On ne lui doit pas l’impossible. On lui doit le verbe exact.

🐝 Ce qui arrive si on s’en passe

Une organisation qui confond masquer et détruire promet un oubli qu’elle ne livre pas : la donnée « supprimée » reste lisible par quiconque obtient une copie de la base, d’une sauvegarde ou d’un journal, et la fuite qui suit expose aussi les personnes qui avaient demandé leur effacement, ce qui est une manière particulièrement coûteuse de tenir un registre. Une restauration sans registre des effacements ressuscite en outre les enregistrements retirés, sans que quiconque le remarque. Et faute d’avoir chiffré au bon grain dès l’écriture, la fin de relation avec un client entier se transforme en chasse aux copies dont personne ne peut dire quand elle s’achève, ni si elle s’est achevée.

🦫 Explication de la marmotte 🍫

Quand une personne clique sur « Supprimer », le logiciel se contente souvent de cacher l’élément : une case indique qu’il est supprimé, mais les données restent enregistrées. Même quand la base de données retire vraiment la ligne, la place libérée n’est pas remise à zéro tout de suite, et d’autres copies existent : le journal qui enregistre chaque modification, les serveurs qui reçoivent une copie de la base, les sauvegardes, l’index du moteur de recherche interne, les journaux d’erreurs, les exports dans des tableurs, l’environnement de test, les prestataires. Sur les disques à mémoire électronique, le matériel choisit lui-même où il écrit, si bien qu’écraser un fichier ne garantit pas que l’ancienne version ait disparu. Personne ne peut donc dresser la liste complète des copies, et certaines, par exemple les sauvegardes impossibles à modifier, ne peuvent pas être corrigées. La solution qui fonctionne à grande échelle est l’effacement par la clé. Chaque donnée est chiffrée dès son écriture avec une clé propre à une personne ou à un client, et toutes les copies ne contiennent alors que du texte chiffré. Pour effacer, on détruit la clé, et toutes les copies deviennent illisibles d’un coup. Cette méthode a des limites : ce qui a déjà été copié en clair n’est pas concerné, les données calculées à partir de l’original survivent, la clé elle-même a des sauvegardes, et un modèle d’intelligence artificielle entraîné sur la donnée ne l’oublie pas sans être entraîné de nouveau.

Pages voisines

La citent

Frontières : cacher, coder, compresser et détruire

L'effacement impossible

Elle cite

: les deux pages se citent l’une l’autre.

L'effacement impossible

Un bouton qui ment poliment

Anatomie d’une donnée qui ne veut pas mourir

Dans la base elle-même

Autour de la base

Sous tout cela

Trois verbes que l’on confond

Ce que demande le droit, et ce qu’il ne dit pas

Pourquoi la chasse aux copies échoue

Détruire la clé plutôt que la donnée

Ce que cela change dans l’architecture

Les angles morts de la destruction de clé

Le cas des modèles entraînés

Le meilleur argument contre

Ce qu’on peut faire lundi

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines