Comment éviter la mémorisation dans un LLM interne

Un modèle de langage interne réduit l’exposition à un fournisseur externe, mais ne transforme pas les données saisies en matière inoffensive. Les prompts, les réponses, les journaux, les sauvegardes et les jeux d’entraînement forment autant de copies potentielles d’un secret, avec des durées de vie rarement maîtrisées.

→ Lire l’explication complète de la marmotte

Mémorisation : le modèle n’est pas un coffre-fort

Un LLM (Large Language Model) prédit la suite la plus probable d’un texte. Lorsqu’il est entraîné ou affiné sur un corpus interne, ses paramètres statistiques peuvent retenir des séquences rares, répétées ou fortement distinctives. Une clé d’accès, une clause contractuelle nominative, un extrait de code propriétaire ou une fiche de paie n’ont pas besoin d’être présents dans le contexte actif pour réapparaître : une requête suffisamment proche peut provoquer leur restitution partielle, parfois verbatim.

Le risque de mémorisation ne se limite pas au fine-tuning. Un mécanisme de contexte conversationnel persistant peut injecter dans une réponse les messages d’un autre utilisateur si l’identité de session, le tenant ou l’espace de travail ne participe pas à la clé de recherche. Un cache de réponses mal indexé produit le même effet avec moins de poésie et davantage de preuves exploitables.

La position à tenir est nette : ne pas fine-tuner un modèle mutualisé avec des données propres à une équipe, un client ou une entité juridique. Le gain est une réponse plus spécialisée et parfois moins coûteuse en contexte. Le prix est une donnée qui devient difficile à retirer, difficile à auditer et impossible à isoler parfaitement après apprentissage. Pour des données sensibles, préférer la recherche documentaire augmentée, décrite dans les embeddings et le RAG, avec une base séparée par périmètre d’autorisation.

Supprimer un document de la base documentaire retire son accès futur si les index et caches sont purgés. Supprimer ce même document d’un jeu de fine-tuning ne garantit pas son effacement des poids du modèle. Il faut alors réentraîner depuis un point de départ vérifié, sans le document concerné. Le bouton « delete » des slides commerciales a donc une portée métaphysique assez limitée.

Les attaques connues incluent l’extraction par requêtes répétées, les amorces de complétion d’un texte connu, l’inversion de membre, qui cherche à déterminer si une donnée a participé à l’entraînement, et les jailbreaks visant à contourner les règles de réponse. Un filtre de sortie réduit l’exfiltration accidentelle, mais ne retire rien du modèle. Une politique de données réduit la probabilité d’introduction du secret, mais ne prouve pas son absence. Ces contrôles se complètent, aucun ne mérite le costume de solution miracle.

Prompts, journaux et rétention des échanges

Un LLM local ne garantit pas la confidentialité par sa seule localisation. Les prompts peuvent être écrits dans les journaux applicatifs, les traces de proxy, les métriques, les outils de débogage, les files de messages, les sauvegardes et les exports de support. Une donnée qui ne sort pas du réseau mais reste lisible par un administrateur non habilité reste une fuite. Le datacenter n’est pas une gomme.

La journalisation doit séparer trois finalités : sécurité, exploitation et amélioration du modèle. Elles n’ont ni la même durée ni les mêmes lecteurs.

Les journaux de sécurité conservent l’identité pseudonymisée, l’horodatage, le modèle appelé, le code de réponse, la décision d’autorisation et un identifiant de corrélation. Ils ne doivent pas contenir le prompt complet par défaut.
Les journaux d’exploitation conservent latence, consommation de ressources, taille des requêtes et erreurs techniques. Hasher un prompt avec une fonction de hachage ne le rend pas anonyme si son espace de recherche est faible ou connu.
Les corpus d’amélioration ne reçoivent que des échanges explicitement sélectionnés, minimisés, nettoyés et validés. Ils ne doivent jamais être alimentés automatiquement par les journaux de production.

Une durée de conservation doit être définie par classe de données. Pour l’exploitation courante, conserver les métadonnées pendant une période courte, par exemple 30 jours, suffit généralement à traiter les incidents récurrents. Pour les prompts complets, la politique défendable par défaut est zéro conservation. Lorsqu’une conservation est nécessaire pour un service identifié, limiter la durée, chiffrer les enregistrements, journaliser chaque lecture et isoler le stockage du plan de service.

L’accès doit relever d’un contrôle d’accès fondé sur les rôles, ou RBAC (Role-Based Access Control), complété par une approbation ponctuelle pour les contenus bruts. L’équipe qui administre l’infrastructure n’a pas automatiquement besoin de lire les conversations. L’équipe qui traite un incident n’a pas automatiquement besoin de parcourir toutes les conversations. La séparation des rôles évite que l’observabilité devienne une bibliothèque de secrets financée par le budget supervision.

Le chiffrement au repos protège les supports volés ou les sauvegardes sorties de leur périmètre. Il ne protège pas contre un compte applicatif autorisé à déchiffrer l’ensemble des historiques. Les clés de chiffrement doivent être séparées de la base de prompts, stockées dans un HSM (Hardware Security Module) ou un service de gestion de clés équivalent, et faire l’objet d’une rotation documentée. La rotation d’une clé ne purge pas les copies déjà exportées ni les textes présents dans les sauvegardes historiques.

Cloisonnement des contextes et des corpus

Chaque requête doit porter un contexte d’autorisation calculé côté serveur : identité, organisation, projet, classification et droits documentaires. Le client ne doit jamais fournir seul ce périmètre. Accepter un champ tenant_id non recoupé avec le jeton d’identité revient à demander poliment à l’utilisateur quel classeur il souhaite consulter. Le secteur a déjà assez de portes blindées avec une étiquette « accès réservé » collée dessus.

Le contexte de conversation doit être indexé au minimum par identifiant d’utilisateur, espace de travail et conversation. Une conversation partagée exige un objet d’autorisation explicite, pas une URL devinable. Les mémoires longues durées doivent être désactivées par défaut, soumises à une expiration, visibles par leur propriétaire et effaçables de manière vérifiable.

Le cloisonnement doit aussi couvrir les composants annexes :

isoler les index documentaires par domaine d’autorisation ou appliquer un filtre obligatoire avant toute recherche ;
interdire le partage de cache entre tenants si la clé n’intègre pas identité, modèle, paramètres et corpus ;
séparer les comptes de service de l’inférence, de l’indexation et de l’administration ;
chiffrer les sauvegardes, tester leur restauration et documenter la purge des données expirées dans les copies restaurées ;
contrôler les connecteurs documentaires, car un connecteur trop large transforme le modèle en lecteur universel avec une interface souriante.

Cette architecture rejoint les principes exposés dans l’architecture cybersécurité : l’identité doit être vérifiée avant l’accès à la donnée, pas après la génération d’une réponse. Une règle ajoutée au prompt système ne remplace pas une autorisation appliquée par le moteur de recherche ou la passerelle d’accès.

Exemple de politique de rétention et de filtrage

L’exemple suivant illustre une configuration de passerelle. Il ne remplace pas le contrôle d’accès du stockage documentaire : il empêche surtout la collecte réflexe de contenus bruts dans les journaux.

# Politique de la passerelle LLM interne.
logging:
  prompt_body: false              # Ne jamais journaliser le contenu par défaut.
  response_body: false            # Même règle pour la réponse générée.
  metadata_retention_days: 30     # Latence, statut, modèle et identifiant corrélé.
  security_events_retention_days: 180
  raw_capture:
    enabled: true                 # Exception réservée au diagnostic approuvé.
    max_retention_hours: 24       # Purge automatique, y compris des index.
    require_incident_ticket: true # Référence obligatoire avant capture.
    encrypt_with: hsm-key-llm-log # Clé séparée du stockage applicatif.

conversation_memory:
  scope: user_workspace           # Jamais globale au modèle ou au tenant.
  ttl_hours: 8                    # Expiration après la fenêtre de travail.
  cross_user_reuse: false         # Interdit toute réutilisation entre utilisateurs.

training:
  ingest_production_logs: false   # Les journaux ne nourrissent jamais l'entraînement.
  require_curated_dataset: true   # Corpus revu, minimisé et versionné.

La purge doit être testée sur les données primaires, les répliques, les caches, les index de recherche et les sauvegardes. Un test utile consiste à injecter une chaîne sentinelle non sensible, déclencher l’expiration, puis vérifier son absence dans chaque emplacement autorisé. Si la chaîne ressort d’un export ou d’une restauration, la rétention réelle est celle de cette copie, pas celle de la configuration YAML. Le fichier est innocent, l’architecture beaucoup moins.

Exploitation, détection et réponse à une fuite

La supervision doit mesurer les refus d’accès documentaire, les requêtes anormalement longues, les taux de répétition, les tentatives de contournement et les volumes exportés par identité. Un pic de demandes proches d’un même secret peut signaler une tentative d’extraction, mais ne permet pas d’établir seul l’intention. Conserver des métadonnées de sécurité rend l’investigation possible sans collectionner tous les textes.

Un plan de réponse doit distinguer quatre cas : fuite par journal, fuite par contexte inter-utilisateur, fuite par corpus documentaire et fuite par mémorisation du modèle. Les trois premiers se corrigent par purge, révocation d’accès, correction de l’isolation et rotation des secrets exposés. Le dernier impose une décision plus coûteuse : arrêter le modèle concerné pour les périmètres sensibles, reconstruire le corpus, réentraîner ou remplacer le modèle, puis tester la non-restitution avec un protocole de requêtes contrôlées.

Aucun test ne prouve l’absence absolue de mémorisation. Il réduit une incertitude sur un ensemble de sondes. La garantie opérationnelle vient donc d’abord de l’absence de données sensibles dans le fine-tuning mutualisé, puis de l’isolation des sources consultées à l’inférence. Pour les secrets techniques, appliquer aussi les règles de gestion des données : révocation, rotation et inventaire restent nécessaires après une exposition potentielle.

🐝 Ce qui arrive si on s’en passe

Sans cloisonnement ni politique de rétention, la porte de la ruche reste ouverte : chaque réponse devient une source d’information exploitable par sondages répétés, exactement le mécanisme décrit dans la question qui rend le module bavard, où l’interrogation patiente d’un composant finit par livrer ce qu’il ne devait pas dire. Au-delà des fuites, c’est la capacité de rendre des comptes qui disparaît : sans corrélation ni classe de conservation, une demande d’effacement ne peut être honorée sur les répliques, index et sauvegardes, et rien ne permet d’établir quelles conversations ont réellement été exposées ni depuis quand. La reprise coûte alors un réentraînement complet, faute de pouvoir démontrer qu’une donnée n’a jamais été absorbée. La preuve manquante se paie en périmètre suspendu, pas en incident circonscrit.

🦫 Explication de la marmotte 🍫

Un modèle de langage produit du texte en calculant quelles suites de mots semblent les plus probables. Pendant son entraînement, il reçoit beaucoup de textes et modifie ses réglages internes. Si un texte rare ou sensible est présent dans ces données, une question proche peut parfois faire ressortir une partie de ce texte plus tard. Retirer le fichier d’origine ne retire pas forcément ce qui a été appris : il faut alors reconstruire l’entraînement sans ce fichier.

Le risque existe aussi sans nouvel entraînement. Quand une personne écrit une question, le système peut conserver cette question dans l’historique de discussion, dans un journal technique, dans une copie de sauvegarde ou dans une mémoire prévue pour les prochaines réponses. Si ces emplacements sont mal séparés, une autre personne peut recevoir une information qui ne lui était pas destinée.

La protection commence avant la réponse : le système vérifie l’identité de la personne et les documents auxquels elle a droit. Il recherche ensuite seulement dans ce périmètre. Les discussions sont séparées entre utilisateurs et expirent après une durée définie. Les journaux gardent surtout des informations techniques, pas le texte complet des échanges.

Si une fuite est détectée, supprimer un journal ou un document ne suffit pas toujours. Il faut aussi chercher les copies, vider les mémoires, retirer les accès concernés et changer les secrets exposés. Si le modèle a appris la donnée, il peut devoir être réentraîné.