Le raisonnement caché des IA contenait des identifiants bien réels

Décryptage

Vos conversations avec une IA ont un brouillon. Les modèles dits « de raisonnement » écrivent d’abord pour eux-mêmes une suite d’étapes intermédiaires, puis rédigent la réponse que vous lisez. Les grands fournisseurs ne montrent plus ce brouillon : ils le renvoient à votre logiciel sous forme de bloc chiffré, que celui-ci retourne au serveur au tour suivant. Une équipe de huit chercheurs affirme avoir rouvert ces blocs. Dans le papier déposé sur arXiv le 10 août 2026, elle annonce en avoir décodé 315 320 et y avoir trouvé 367 artefacts de données personnelles ainsi que 182 identifiants.

Une chaîne de raisonnement, c’est une feuille de brouillon

Le terme fait savant. La chose est banale. Une chaîne de raisonnement, c’est la feuille de brouillon d’un élève : le modèle y pose ses étapes, essaie une piste, se corrige, recopie un bout de fichier pour vérifier un détail. Puis il rédige au propre. Vous ne recevez que la copie au propre.

Concrètement, cela veut dire que le brouillon peut contenir ce que la réponse finale ne contient pas. Un modèle à qui l’on soumet un fichier de configuration va le relire dans son raisonnement, ligne par ligne, avant de conclure « votre paramétrage est correct ». La conclusion est propre. Le brouillon, lui, a manipulé le contenu du fichier.

Pourquoi les fournisseurs cachent-ils cette feuille ? Pour deux raisons énoncées dans le papier : protéger leur propriété intellectuelle et limiter les fuites d’information. Un brouillon lisible permet en effet d’entraîner un modèle plus petit à imiter un modèle plus gros. Plutôt que de garder ces traces sur leurs serveurs, les fournisseurs les confient au client sous scellé, à charge pour lui de les rendre au tour suivant.

Pourquoi les blocs chiffrés se sont rouverts

Le constat central du papier tient en une phrase : ces blocs chiffrés sont « pleinement compatibles et interchangeables entre différentes sessions, différents utilisateurs et différents modèles » à l’intérieur de l’écosystème d’un même fournisseur. Autrement dit, un scellé produit dans une conversation est accepté dans une autre. Il n’a pas de nom sur l’enveloppe.

Dans son analyse du 11 août, le développeur Simon Willison résume la mécanique : les modèles d’une même famille partagent la même clé, et les chercheurs ont poussé des traces produites par un modèle fort vers un modèle plus faible de la même lignée, qui les a restituées en clair. Nous ne détaillons pas la manipulation, et le papier vise le principe, pas le mode d’emploi.

La fiche publiée sur Hugging Face recense quatre voies d’attaque distinctes : contourner les protections anti-distillation, extraire des données privées, exposer des contenus dangereux tenus cachés, et glisser des instructions invisibles dans un raisonnement que le modèle traite comme sacré. Les trois fournisseurs concernés ont accusé réception ; les tentatives menées après correction ont échoué.

Notre calcul : une trace sensible tous les 574 blocs

Le papier livre trois nombres bruts et s’arrête là. Nous en dérivons une proportion qu’aucune source ne publie, et la méthode tient en trois lignes. Les 367 artefacts de données personnelles et les 182 identifiants forment 549 éléments sensibles. Rapportés au corpus décodé : 549 / 315 320 = 0,00174, soit 0,17 % des blocs. Pris dans l’autre sens, 315 320 / 549 = 574. Un bloc de raisonnement sur 574 portait une trace exploitable.

Le détail sépare les deux familles. Une donnée personnelle apparaît tous les 859 blocs (315 320 / 367), un identifiant tous les 1 733 (315 320 / 182). Voici ce que donne cette distance moyenne, famille par famille.

La lecture est contre-intuitive : le taux paraît minuscule à l’échelle d’un bloc, et devient banal à l’échelle d’un usage professionnel. Une équipe qui passe 5 000 appels de raisonnement par jour franchit le seuil de neuf blocs sensibles quotidiens (5 000 / 574 = 8,7). La limite de méthode est nette : ce taux est mesuré sur un corpus ramassé dans des dépôts publics, pas sur le trafic réel d’une entreprise, et rien ne dit que les deux populations se ressemblent.

Deux précisions comptables. Les 549 éléments ne sont pas 549 personnes : un même incident peut produire plusieurs artefacts. Et les pourcentages sont arrondis au centième, ce qui explique que la somme des deux premières lignes tombe sur 0,17 % et non sur 0,18 %.

Ce que ça change pour vous, concrètement

Si vous utilisez un assistant grand public, votre exposition passe par ce que vous lui donnez à lire. Un contrat, une fiche de paie, un export de messagerie collés dans une conversation transitent par le brouillon avant de ressortir en résumé propre. La question n’est plus seulement « où sont stockées mes conversations », mais « qui détient les brouillons, et sous quelle forme ».

Le point le plus inconfortable n’est pas l’attaque : c’est l’origine du matériau. Les 315 320 blocs ne viennent pas d’un serveur forcé. Ils viennent de dépôts de code publics, c’est-à-dire de développeurs qui avaient publié ces blocs eux-mêmes, dans des fichiers de trace, des journaux de débogage ou des jeux de test, sans savoir que ces chaînes chiffrées contenaient encore quelque chose de lisible.

Pour un développeur, la conséquence est immédiate : un bloc de raisonnement n’est pas un identifiant technique opaque. Il se traite comme une donnée, il n’a rien à faire dans un dépôt public, et un dépôt déjà publié se relit avec cette grille.

Ce que le droit français en fait

Une entreprise française qui appelle ces API est responsable de traitement au sens du RGPD. Si des données personnelles se retrouvent exposées dans un fichier publié, la qualification ne dépend pas de l’intention. La CNIL rappelle la définition de l’article 4.12 du règlement : une violation de la sécurité entraînant, de manière accidentelle ou illicite, la divulgation non autorisée de données.

Les obligations qui suivent sont datées. Notification à la CNIL dans un délai maximal de 72 heures après la prise de connaissance, inscription au registre interne des violations dans tous les cas, y compris ceux jugés sans risque, et information des personnes concernées lorsque le risque est élevé. L’autorité prévoit des exceptions à cette dernière obligation, notamment quand les données étaient réellement chiffrées. C’est précisément le point que le papier fragilise : un chiffrement dont la clé voyage avec le message ne protège pas comme on le croyait. Nous avions déjà vu ce raisonnement à l’œuvre dans un vol de données de santé hébergées chez un tiers.

Montrer le raisonnement, le cacher, ou le signer

Le secteur avait tranché pour « cacher ». Ce papier rouvre le dossier avec un argument inattendu : cacher un brouillon en le confiant à l’utilisateur sous scellé, c’est en faire un objet qui circule, se stocke, se versionne et finit par se publier. Un brouillon gardé côté serveur ne se serait jamais retrouvé dans un dépôt de code.

Une troisième voie existe, et elle est technique : signer le bloc plutôt que se contenter de le chiffrer, pour qu’il ne soit valable que dans la session et pour l’utilisateur qui l’a produit. C’est la lecture directe du constat des auteurs, qui pointent l’interchangeabilité des blocs comme la faiblesse d’architecture, avant même la question de la clé. Ce que les correctifs déployés depuis semblent avoir suivi.

Article créé en collaboration avec l’IA.