Zéro rétention de prompts : notre test, sa contre-épreuve, ses limites

== 4. Recherche du marqueur sur les deux machines
  absent ia-poc-veilleur : journald, tous services (190 entrées écrites pendant le test)
  absent ia-poc-gpu : journald, tous services (2585 entrées écrites pendant le test)
  absent ia-poc-gpu : /run (513 fichier(s) modifié(s) pendant le test, tous lus)
  absent ia-poc-gpu : /data (0 fichier(s) modifié(s) pendant le test, tous lus)
  …

RÉSULTAT : CONFORME — marqueur ZDR-20261109-0c608fa886ee2d8c introuvable…

== 4. Recherche du marqueur sur les deux machines
  absent ia-poc-veilleur : journald, tous services (127 entrées écrites pendant le test)
  TROUVÉ ia-poc-gpu : journald, 4 ligne(s) :
           … [request_logger.py:119] Generated response chatcmpl-ace6…: output: 'ZDR-20261107-0764b9712833da79', finish_reason: stop
  TROUVÉ ia-poc-gpu : / : /var/log/journal/…/system.journal /var/log/syslog
  …

RÉSULTAT : NON CONFORME — 2 point(s) en échec (voir ci-dessus).

Un samedi de novembre, notre script de vérification a retrouvé un prompt écrit en clair dans le journal d’un serveur. Nous l’avions provoqué exprès : c’était la contre-épreuve. Deux minutes et demie plus tard, configuration rétablie, le même script, avec un nouveau marqueur, ne trouvait plus rien.

Un test qui ne trouve rien ne vaut que s’il sait trouver quelque chose. Ces deux résultats, ensemble, apportent une vérification technique concrète, en complément des engagements contractuels. Cet article décrit comment nous testons la promesse « zéro rétention » (Zero Data Retention, ZDR) de notre LLM hébergé à Paris : ce que nous visons, ce que le test vérifie, ce que nous avons découvert en chemin, et ce qu’il ne peut pas établir.

Une promesse floue ne se vérifie pas. La nôtre a été écrite avant la première ligne de code :

Aucun prompt ni aucune réponse n’est écrit sur disque ni journalisé, à aucun maillon de la chaîne serveur : moteur d’inférence, passerelle, proxy, système. Seules des métadonnées sont conservées.

« Seules des métadonnées » n’est pas une échappatoire : sans elles, ni facturation ni sécurité. Mais elles doivent être listées, avec leur règle de conservation.

Deux précisions. Le journal identifie une clé, pas nécessairement la personne derrière la requête. Et une métadonnée qui désigne un utilisateur reste une donnée personnelle : le journal système ne la garde donc que 14 jours au plus, sur chaque machine, et le test contrôle cette durée.

Un prompt traverse plus de maillons qu’on ne le croit : le poste, la connexion chiffrée jusqu’au veilleur, le veilleur lui-même, le réseau privé, le serveur GPU. Voici dix endroits où il peut finir écrit, et ce que nous y avons fait.

1. Le proxy ou CDN devant le service. Un proxy qui termine le TLS voit tout en clair. Notre domaine est déclaré chez Cloudflare en « DNS seul », sans proxy[3] : le chiffrement s’arrête sur une machine que nous administrons.
2. Le journal d’accès du reverse proxy. Caddy n’a aucune directive log : pas de journal d’accès[4].
3. La passerelle. Le veilleur n’écrit qu’une ligne de métadonnées par requête, jamais un corps. Même le journal par défaut de son serveur HTTP, qui noterait chemins et adresses, est neutralisé.
4. Le moteur d’inférence. vLLM sait journaliser requêtes et réponses[5]. Nous forçons --disable-log-requests --disable-log-outputs, ajoutés en dernier à la ligne de commande : quand une option apparaît deux fois, la dernière l’emporte[6], et un réglage glissé plus haut ne peut pas réactiver les journaux.
5. Les outils tiers. Suivi d’erreurs (type Sentry[7]), traces (OpenTelemetry[8]), collecte de journaux : chacun peut capturer un corps de requête « pour aider au débogage ». Nous les avons exclus de cette architecture, et le test cherche les agents connus.
6. L’observabilité de l’hébergeur. Aucun journal applicatif n’est envoyé à Cockpit, la supervision de Scaleway[1] ; seules ses métriques automatiques existent.
7. Le swap. De la mémoire écrite sur disque, donc potentiellement des prompts. Aucune des deux machines n’en a.
8. Les core dumps. Quand un processus plante, Linux peut écrire sa mémoire sur disque[9], prompts en cours compris. C’est là que nous avons eu la surprise du projet.
9. Les sauvegardes et instantanés. Un snapshot fige tout ce que contient un disque. Les API de Scaleway n’en listent aucun dans notre projet, en fr-par-2.
10. Votre poste. L’agent de code garde l’historique des conversations en local. C’est hors de notre chaîne, mais pas hors de votre périmètre.

La surprise : apport

Pour interdire les core dumps, la méthode classique tient en une ligne de sysctl : kernel.core_pattern=|/bin/false. Nous l’avions écrite. Elle ne tenait pas.

Sur notre image Ubuntu, le service apport, qui collecte les rapports de plantage, reprenait la main sur kernel.core_pattern au démarrage[10][11]. Or, quand ce réglage confie les dumps à un programme (le | en tête), la limite ulimit -c 0 du processus ne suffit plus à empêcher le noyau de transmettre le dump[9] : c’est le collecteur qui applique ensuite ses propres règles[10]. Nous avons masqué et arrêté apport, puis réappliqué notre configuration sysctl, sur les deux machines.

Et le test contrôle désormais la valeur effective du noyau, pas celle du fichier de configuration. C’est la leçon la plus utile du projet : vérifier la configuration écrite ne suffit pas, il faut vérifier l’état réel.

Le principe : faire traverser toute la chaîne à une chaîne de caractères unique, puis la chercher là où elle aurait pu être écrite.

1. Un marqueur unique, du type ZDR-20261109-0c608fa886ee2d8c : la date et huit octets aléatoires, pour rendre une collision accidentelle extrêmement improbable.
2. De vraies requêtes, par l’API publique : une requête classique, une requête en flux (SSE), et une requête avec une clé invalide dont le corps contient aussi le marqueur. On demande au modèle de recopier le marqueur, et on vérifie qu’il l’a fait : la chaîne est dans le prompt et dans la réponse.
3. Une recherche sur les deux machines. Le journal système écrit depuis le début du test, tous services confondus, interrogé sous forme exportée. Puis les fichiers ordinaires modifiés depuis le début du test, sur les systèmes de fichiers ext4, xfs, btrfs, vfat et tmpfs, y compris /run, /dev/shm et le disque qui porte les poids du modèle. Les noms de fichiers aussi, et le swap s’il en existait.
4. Résultat attendu : introuvable.

Deux détails, parce qu’un test de fuite peut lui-même fuir ou se tromper :

• Le marqueur ne figure pas dans la commande SSH : il arrive par l’entrée standard de la session. Les outils de recherche le lisent ensuite par un tube, jamais en argument : il n’apparaît dans la ligne de commande d’aucun processus des serveurs.
• On laisse aux journaux le temps d’arriver : quelques secondes d’attente, puis journalctl --sync, avant de chercher. Un test trop pressé ne trouve rien, et conclut à tort que tout va bien.

Le 9 novembre, la recherche a porté sur 2 585 entrées de journal écrites pendant le test sur le serveur GPU et 190 sur le veilleur, et sur 513 fichiers modifiés dans /run côté GPU. Marqueur introuvable.

Un point a été corrigé depuis : « tous lus » est ce qu’affiche le script, mais une erreur de lecture pendant la recherche ne le faisait pas échouer. Pour qu’un « conforme » vaille quelque chose, toute erreur d’inventaire, de lecture, de recherche ou de réponse d’API rend désormais le test non concluant ; seul un fichier effacé entre l’inventaire et la lecture est compté à part.

Un marqueur introuvable peut vouloir dire deux choses : rien n’a fuité, ou le test cherche mal. Pour trancher, on active volontairement la journalisation des requêtes de vLLM le temps du test, et on le rejoue. Le contrôle de configuration doit échouer, bien sûr ; surtout, la recherche doit retrouver le marqueur.

Elle l’a retrouvé : quatre lignes dans le journal du serveur GPU, et deux fichiers sur disque (le journal système et syslog). On rétablit la configuration et on rejoue avec un nouveau marqueur : introuvable dans le périmètre examiné. Ce rejeu ne démontre pas l’effacement des traces de la contre-épreuve : elles restent dans les journaux du serveur GPU jusqu’à leur purge. La surcharge de configuration vit dans /run, qu’un redémarrage efface, et le script prévoit de la retirer en sortant, même en cas d’erreur ; une interruption brutale demanderait une intervention.

Notre relecteur a alors soulevé le vrai problème : la contre-épreuve est elle-même une fuite. Pendant sa fenêtre de 5 à 10 minutes, le moteur journalise tout ce qu’il reçoit, y compris les requêtes des autres utilisateurs, et ces journaux restent, en mémoire, jusqu’à l’extinction du serveur GPU. Le script refuse donc de démarrer si une autre clé que la sienne a appelé le service pendant le délai d’inactivité, et signale après coup toute requête étrangère arrivée pendant la fenêtre.

Ce garde-fou a ses limites, et nous les écrivons : il observe les requêtes terminées et il ne bloque pas les requêtes concurrentes. Il utilisait aussi la clé d’un associé : le test a désormais sa propre clé, distincte de celles des utilisateurs. Depuis que nos associés ont leur clé, nous n’avons pas rejoué la contre-épreuve.

Le marqueur couvre ce qui est écrit sur nos machines. Le même script vérifie des indices cohérents avec notre architecture :

• le nom de domaine résout (en IPv4) vers l’adresse du veilleur, pas vers un CDN ;
• le certificat servi au public a la même empreinte que celui stocké sur le veilleur ;
• l’API de Scaleway compte zéro snapshot et zéro image de disque dans la zone utilisée ;
• Cockpit n’a ni source de données ni jeton d’envoi créés par nous ;
• aucun agent connu d’erreurs, de traces ou de journaux ne tourne (Sentry, OpenTelemetry, Promtail, Alloy…) ;
• pas de swap, core dumps désactivés (valeur effective), Caddy sans journal d’accès, vLLM avec ses deux options en dernier.

Ces contrôles ne valent pas une attestation exhaustive d’absence d’intermédiaire, de collecte ou de sauvegarde. Ils ont pourtant déjà servi. La vérification du 9 novembre a signalé que vLLM envoyait par défaut des statistiques d’usage anonymes à ses développeurs : type de GPU, modèle, réglages, jamais de contenu[12]. Elles sont désormais coupées et contrôlées : le test en fait un échec bloquant, et la vérification rejouée le même jour a constaté la coupure.

Une preuve honnête dit où elle s’arrête.

• Ce qui n’est pas lisible tel quel. La recherche porte sur la chaîne exacte. Elle ne reconstitue pas un contenu effacé, écrasé, compressé dans une archive, encodé ou fragmenté, ni l’espace libre des disques.
• Tous les chemins d’erreur. Trois scénarios sont testés, pas toutes les exceptions, déconnexions ou écritures différées possibles.
• La mémoire vive. Pendant le calcul, prompt et réponse sont en clair dans la mémoire des deux machines, et vLLM garde un cache des échanges récents sur le GPU, jusqu’à éviction ou extinction[13][14].
• L’hébergeur. Scaleway peut techniquement accéder à la mémoire de ses machines, et le trafic entre le veilleur et le GPU circule en clair sur son réseau privé.
• Demain. Un administrateur peut réactiver les journaux : la contre-épreuve le démontre. La garantie repose aussi sur un engagement, et sur des vérifications répétées.
• Les tiers sans contenu, comme Cloudflare pour le DNS ou Let’s Encrypt, qui publie le nom de domaine dans les registres de certificats[15]. Et le poste client.

Pour vérifier par vous-même, il faut des accès d’administration. Un client peut assister à l’exécution ; une vérification indépendante suppose aussi l’accès au script, à la révision testée et aux sorties expurgées.

Notre test porte sur la configuration. Il ne remplace pas les trois autres garanties, qui répondent à d’autres questions :

1. La configuration : ce que décrit cet article, vérifiable par un test rejouable.
2. L’engagement contractuel : lorsqu’un prestataire traite des données personnelles pour un client, l’accord prévu par l’article 28 du RGPD s’applique[16]. Ce n’est pas une option.
3. L’audit et la qualification : audit indépendant, ISO 27001, ou qualification SecNumCloud de l’ANSSI. Cette dernière se vérifie sur le périmètre exact du service retenu[17], et ne démontre pas à elle seule l’absence de journalisation applicative.
4. La protection matérielle : l’informatique confidentielle peut réduire l’accès de l’opérateur aux données en cours de traitement[18], avec une architecture compatible et une attestation vérifiée, sur tout le chemin (terminaison TLS, mémoire, transferts, GPU). Elle n’empêche pas une application autorisée de journaliser.

Ce que la relecture nous a fait ouvrir, et qui conditionne la valeur du prochain « conforme » :

• La contre-épreuve : avant d’activer les journaux, fermer l’admission des requêtes ordinaires et attendre la fin de celles déjà admises ; n’autoriser qu’une identité de test dédiée ; maintenir la fermeture jusqu’au rétablissement vérifié du moteur. Puis rejouer un cycle complet (normal, contre-épreuve, rétabli) sur une révision identifiée, sorties expurgées à l’appui.

Notre objectif est de traiter prompts et réponses sans les écrire sur disque ni dans les journaux de nos serveurs. Lors du test du 9 novembre 2026, aucun des marqueurs envoyés par l’API n’a été retrouvé dans les journaux et fichiers examinés sur nos deux machines Scaleway, à Paris. Ce résultat vaut pour les scénarios et le périmètre décrits ici ; il ne constitue pas une preuve générale d’absence de conservation.

Si un fournisseur vous promet davantage, demandez-lui comment il le prouve.