Chiffrer la mémoire de l'IA : pourquoi une clé par projet vaut mieux qu'une par base

Une mémoire qui mérite d'exister mérite d'être protégée. Si un système va conserver ce que vous lui avez confié sur le diagnostic de votre enfant, votre affaire judiciaire ou vos finances, alors la formule « chiffré au repos » — celle qu'emploie chaque fournisseur — mérite qu'on regarde de plus près ce qu'elle signifie vraiment.

TL;DR

Chaque fichier de mémoire et chaque message de chat est chiffré avec une clé qui appartient à un seul projet, non avec une clé unique pour toute la base.
Supprimer un projet détruit sa clé, si bien que les données deviennent illisibles y compris dans les sauvegardes, pas seulement dans le système en production.
Nous ne cherchons pas sur du texte chiffré et ne stockons pas votre texte dans l'index de recherche. Les deux choix découlent d'attaques publiées, non d'un goût.

Ce que « chiffré au repos » signifie le plus souvent

Le plus souvent, cela veut dire chiffrement du disque ou du volume entier. Le disque est chiffré ; le processus de base de données détient la clé et déchiffre tout ce qu'il lit. Cela protège d'une seule chose — que quelqu'un retire physiquement le disque — et de presque rien d'autre. Un attaquant qui atteint la base en cours d'exécution, une sauvegarde volée qui embarque sa clé, une requête interne trop large : dans tous ces cas les données sont lisibles sans plus, car du point de vue de la base elles l'ont toujours été.

Pour un produit bâti sur la mémoire, cela a en plus une propriété gênante : une clé ouvre tout le monde. Il n'y a aucune frontière technique entre votre matière et celle d'un autre client, seulement des requêtes correctement écrites.

Une clé par projet

FocusLM chiffre au niveau de la ligne, non du disque. Chaque projet reçoit sa propre clé de données. Chaque fichier de mémoire, chacune de ses révisions et chaque message du chat de ce projet est chiffré avec cette clé et aucune autre. Les fils de discussion qui n'appartiennent à aucun projet sont chiffrés avec une clé d'espace de travail, selon le même principe.

Ces clés par projet sont elles-mêmes chiffrées par une clé unique par environnement, jamais stockée à côté des données qu'elle protège. Cet agencement — une clé qui chiffre des clés, qui chiffrent des données — est le chiffrement en enveloppe, et c'est la recommandation standard pour les hiérarchies de clés dans les guides de gestion des clés du NIST. Il apporte deux choses pratiques : faire tourner la clé supérieure ne touche qu'une petite ligne par projet au lieu de rechiffrer les données de quiconque, et la clé d'un seul projet peut être détruite à part.

Une clé d'environnement enveloppe une clé de données distincte par projet. La matière du projet A n'est chiffrée qu'avec la clé de A : la base ne détient jamais de clé qui ouvre tout.

Le lien est plus étroit que « même clé, même projet ». Chaque valeur chiffrée est cryptographiquement liée à la ligne et au projet exacts auxquels elle appartient, de sorte qu'un texte chiffré copié dans un autre projet ne se déchiffre pas dans le mauvais contexte : il ne se déchiffre pas du tout. Déplacer des données entre locataires n'est pas un bug subtil qui apparaît plus tard ; c'est une erreur à l'instant même de la tentative.

Pourquoi nous ne cherchons pas sur du texte chiffré

Le souhait évident est de tout garder chiffré tout en exécutant une recherche textuelle ordinaire dessus. Des schémas existent — le chiffrement déterministe rend égales les valeurs égales, celui à préservation d'ordre garde les valeurs triables — et ils sont exactement aussi commodes qu'ils en ont l'air.

Ils fuient aussi. Une longue lignée de travaux sur les attaques par inférence contre les bases chiffrées à préservation de propriétés montre que, lorsque les textes chiffrés préservent l'égalité ou l'ordre, un attaquant qui ne dispose que de la colonne chiffrée et de statistiques publiques ordinaires peut récupérer une grande partie du texte clair. L'analyse de fréquence fait l'essentiel : dans des données réelles, la distribution des valeurs est rarement plate, et un chiffrement qui préserve la structure préserve la distribution avec elle.

C'est pourquoi FocusLM déchiffre au sein de l'application et filtre là, plutôt que de demander à la base de comparer sur du texte chiffré. Le coût est réel et mérite d'être nommé : une recherche littérale lit toutes les notes du projet au lieu de laisser un index les restreindre d'abord, si bien que le travail croît avec la taille de votre mémoire au lieu de rester constant. Nous l'avons préféré à acheter la recherche au prix d'une fuite permanente des fréquences de termes — qui, dans une mémoire personnelle, sont les mots qui comptent le plus.

L'index de recherche ne contient pas votre texte

La recherche sémantique a besoin de vecteurs, et les vecteurs ont leur propre histoire de confidentialité — facile à mal gérer, car un embedding ressemble à une liste inerte de nombres.

Il n'est pas inerte. Dans Text Embeddings Reveal (Almost) As Much As Text, Morris et ses collègues ont montré que les embeddings denses peuvent être inversés vers leur texte d'origine en traitant la reconstruction comme une génération contrôlée et en corrigeant itérativement une hypothèse jusqu'à ce qu'elle se ré-embarque au même point. Ils ont récupéré 92 % des entrées de 32 tokens de façon exacteet extrait des noms complets de patients d'un corpus de notes cliniques. Des travaux ultérieurs ont généralisé l'attaque : un modèle d'inversion génératif peut reconstruire des phrases entières cohérentes à partir d'un seul embedding de phrase, et des études de suivi ont reproduit et étendu le résultat.

Retirer le texte ne clôt pourtant pas cet argument, et le présenter comme tel serait malhonnête. Le vecteur lui-même est toujours là — il le doit, car la géométrie entre vecteurs est précisément ce qui rend la recherche sémantique possible. Le chiffrer comme on chiffre une note ne laisserait rien à chercher.

L'étape suivante est donc de lier l'espace des vecteurs à la même clé par projet qui protège déjà le contenu : les vecteurs de chaque projet résident dans un espace que seule la clé de ce projet décrit. Cela maintient la recherche inchangée tout en rendant les vecteurs inutilisables dans les coordonnées propres du modèle d'embeddings — là où opèrent les attaques d'inversion publiées. Cela relève le coût d'une attaque au lieu de l'éliminer, et nous préférons le dire plutôt que d'appeler cela du chiffrement. C'est en cours, non livré.

92 %des textes courts reconstruits de façon exacte à partir de leurs seuls embeddings

La conséquence pour un produit de mémoire est directe : un index de vecteurs volé doit être traité comme du texte clair volé. C'est pourquoi l'index de FocusLM stocke le vecteur, le chemin du fichier et une empreinte à clé — et pas le texte de vos notes. Quand une recherche correspond, l'extrait que vous lisez est récupéré et déchiffré depuis le stockage chiffré à cet instant. L'index sait où se trouve quelque chose de pertinent ; il ne sait pas ce que cela dit.

Un embedding n'est pas une version anonymisée de votre texte. C'en est une réversible.

Une suppression qui survit à la sauvegarde

« Supprimer », dans la plupart des systèmes, signifie marquer une ligne comme supprimée. Les données restent — dans la table, dans le dump d'hier soir, dans la réplique, dans la rétention qu'ont les sauvegardes. Pour une note sur la maladie d'un enfant, ce n'est pas une suppression dans un sens que la personne qui la demande reconnaîtrait.

Parce que chaque projet a sa propre clé, nous pouvons faire plus fort : supprimer un projet détruit cette clé. Le texte chiffré reste où il est déjà, et rien ne peut plus jamais en être lu — ni dans la base en production, ni dans un instantané pris avant la suppression. C'est le crypto-shredding, et c'est la réponse standard à l'effacement dans les systèmes où réécrire physiquement chaque copie est impraticable ou invérifiable, c'est-à-dire tout système distribué avec des sauvegardes.

Des travaux récents affinent le cas pour les systèmes d'IA en particulier. Une étude de 2026 sur les bases de vecteurs a trouvé que les embeddings simplement supprimés en douceurrestent reconstructibles à partir de la structure de l'index : la suppression est un drapeau, et les données sont encore là pour qui lit le fichier au lieu d'interroger le moteur de requêtes. Combiné à l'inversion d'embeddings, un soft-delete dans un magasin de vecteurs n'est pas une suppression du tout.

Le crypto-shredding est réellement irréversible, ce qui est le but et aussi le risque. Restaurer un projet supprimé depuis une sauvegarde ramène des lignes que personne ne peut lire. FocusLM vous demande donc de taper le nom du projet avant qu'il ne parte — la même friction qui protège une action destructrice partout ailleurs.

Ce qui reste honnêtement visible

Les promesses de chiffrement valent exactement ce qu'admettent leurs exceptions. Les nôtres :

La structure n'est pas le contenu. Les noms de dossiers et de fichiers de votre mémoire sont stockés en clair, car le système les parcourt et les globbe. Un chemin comme santé/oncologie/… révèle un sujet même si la note elle-même est illisible.
Titres de chat.Le titre d'un fil est stocké en clair pour que la barre latérale puisse le chercher, et il est généré à partir de votre premier message. La conversation est chiffrée ; la phrase qui l'a ouverte ne l'est pas.
Noms de fichiers. Le nom que vous avez téléversé voyage dans la clé de stockage et dans le journal opérationnel, même si le contenu du fichier est scellé.
Les vecteurs de recherche, pour l'instant.Aujourd'hui ils sont dans l'index dans l'espace propre du modèle d'embeddings, l'espace auquel s'applique la recherche sur l'inversion. Les lier à la clé du projet est le travail décrit ci-dessus.
Métadonnées opérationnelles. Quel modèle a tourné, combien de temps, ce que cela a coûté. Pas ce qui a été dit.

Un motif les traverse : le contenu est protégé, les noms ne le sont pas. Les chemins, les titres et les noms de fichiers sont ce que le système doit lire pour organiser et retrouver, donc ils restent lisibles. C'est une limite réelle, c'est celle qu'on voudrait qu'on nous signale en tant qu'utilisateur, et c'est le prochain chantier, non une note de bas de page qu'on balaie.

Pourquoi cela compte pour un produit de mémoire en particulier

Un assistant de chat qui vous oublie entre les sessions détient peu de choses à voler. Un système bâti pour accumuler ce vers quoi vous revenez sans cesse — la mémoire structuréequi rend possibles des réponses ancrées — accumule précisément la matière qui ne devrait jamais fuir. La valeur de la mémoire et sa sensibilité croissent ensemble ; c'est la même propriété vue de deux côtés.

C'est la raison de mettre l'ingénierie dans une clé par projet plutôt que dans une case qui dit chiffré. Plus la mémoire est forte, moins la réponse ordinaire est acceptable.

Sources