OpenAI, Anthropic, Google : la faille qui rendait lisible le raisonnement caché de leurs IA

Une pensée chiffrée, mais pas pour tout le monde

Depuis l'arrivée des modèles de raisonnement, ceux qui réfléchissent par étapes avant de répondre, OpenAI, Anthropic et Google ont pris l'habitude de cacher le détail de ce raisonnement à leurs propres utilisateurs. Le texte affiché reste la réponse finale, polie et vérifiée ; le cheminement qui y mène, lui, repart sous forme de bloc chiffré, renvoyé au client entre deux appels d'API pour que l'application puisse maintenir le fil d'une conversation ou d'un agent sans jamais voir ce que le modèle a réellement pensé.

Cette opacité était présentée comme une protection à double titre : empêcher des concurrents de reconstituer à bas coût la façon de raisonner d'un modèle frontière, et éviter d'exposer des étapes intermédiaires parfois maladroites ou limites, jamais destinées à être lues telles quelles. Un papier de recherche publié le 10 août 2026, « Stealing Reasoning Traces from Proprietary LLM APIs », montre que ce chiffrement tenait surtout sur la confiance qu'on lui accordait. Avec le bon enchaînement de manipulations, un modèle bien plus faible pouvait être amené à relire à voix haute la pensée d'un modèle bien plus puissant.

Pourquoi les IA cachent leur raisonnement

Un modèle de raisonnement ne répond pas directement : il produit d'abord une longue suite d'étapes intermédiaires, hypothèses testées, pistes abandonnées, corrections, avant de livrer une réponse finale. Ce cheminement complet a longtemps été visible dans les premières versions de ces modèles. Les laboratoires l'ont ensuite masqué, pour deux raisons assumées publiquement. La première est économique : ce raisonnement brut est un signal d'entraînement précieux, et un concurrent qui y accède peut s'en servir pour entraîner à moindre coût un modèle imitant les capacités du premier, une pratique déjà documentée sur d'autres modèles ouverts. La seconde est liée à la sécurité : un modèle explore parfois, dans ses étapes intermédiaires, des pistes qu'il écarte ensuite lui-même, mais qui n'ont pas vocation à apparaître telles quelles devant un utilisateur.

La solution technique retenue par les trois fournisseurs se ressemble : plutôt que de faire disparaître ce raisonnement, ils le renvoient au client sous forme d'un objet chiffré, illisible sans la clé du fournisseur. Cet objet sert de mémoire technique entre deux appels, indispensable pour les usages en plusieurs tours, agents qui enchaînent des actions, conversations longues, sans jamais exposer le contenu en clair. Le principe paraissait solide : même en interceptant ce bloc, personne d'autre que le fournisseur ne pouvait, en théorie, le déchiffrer.

La faille : une seule clé pour toute une famille de modèles

C'est cette théorie que le papier de recherche met en défaut. Les chercheurs montrent que les trois fournisseurs ont fait un choix d'architecture identique et, avec le recul, risqué : au lieu de générer une clé de chiffrement propre à chaque session ou à chaque utilisateur, ils ont réutilisé une seule et même clé pour toute une famille de modèles. Un bloc de raisonnement chiffré, produit par exemple par un modèle Claude, restait donc valide et interprétable par n'importe quel autre modèle Claude de la même famille, y compris un modèle beaucoup plus léger, prévu pour des tâches simples et bon marché.

Cette réutilisation transforme un détail d'implémentation en porte dérobée. Les blocs chiffrés, conçus pour circuler uniquement entre le fournisseur et son propre client, sont en réalité des objets portables : ils restent compatibles d'une session à l'autre, d'un compte à l'autre, et d'un modèle à l'autre au sein de la même famille. Les chercheurs ont pu le vérifier à grande échelle en récupérant des traces d'agents publiées publiquement sur GitHub et Hugging Face, des développeurs qui partagent leurs journaux d'exécution pour illustrer un tutoriel ou signaler un bug, sans se douter que ces blocs, en apparence du charabia chiffré, restaient exploitables par n'importe qui disposant du bon modèle pour les lire.

Comment un modèle plus faible s'est mis à table

La méthode d'attaque tient en trois étapes. D'abord, récupérer un bloc de raisonnement chiffré, produit par un modèle puissant, dans une trace de session publiquement accessible. Ensuite, injecter ce même bloc, tel quel, dans le contexte d'un modèle plus faible de la même famille, un modèle d'entrée de gamme, moins coûteux, généralement moins bien protégé contre les demandes inhabituelles portant sur son propre fonctionnement interne. Enfin, demander simplement à ce modèle affaibli de retranscrire, mot pour mot, le raisonnement associé à cet échange. Dans une bonne partie des cas testés, il obéit.

Cette dernière étape fonctionne parce que le modèle plus faible n'a pas été entraîné à refuser ce type de requête aussi rigoureusement qu'un modèle frontière refuserait de révéler son propre raisonnement caché. Dans les essais des chercheurs, Claude Haiku 4.5 s'est montré la cible la plus simple à faire céder de cette manière. Le procédé a permis de récupérer, entre autres, des fragments du raisonnement interne de GPT-5.5 en train d'hésiter entre plusieurs choix d'architecture CSS, des brouillons d'idées jamais destinés à sortir du modèle, exactement le genre de contenu que le chiffrement était censé garder privé.

Un modèle plus faible n'a pas été entraîné à refuser aussi fermement qu'un modèle frontière de révéler un raisonnement qui n'est même pas le sien.

Ce que 315 320 blocs déchiffrés ont révélé

L'ampleur de la démonstration donne la mesure du problème. Les chercheurs ont passé au crible 6 708 trajectoires d'agents publiques, collectées sur GitHub et Hugging Face, et reconstruit à partir de ces traces 315 320 blocs de raisonnement chiffrés. Parmi eux, 1 028 blocs, soit 0,3 % du total, contenaient au moins une donnée sensible réelle. Le détail de ce qui a été retrouvé se lit comme un inventaire de ce qu'un développeur ne voudrait jamais publier : 62 clés API, 33 mots de passe, 24 jetons d'accès, 7 clés privées et 30 adresses e-mail personnelles.

Le point le plus dérangeant de ces chiffres n'est pas leur volume, mais leur emplacement. Ces secrets n'apparaissaient nulle part dans la réponse visible du modèle, celle qu'un développeur relit avant de partager un journal d'exécution pour illustrer un problème. Ils se trouvaient uniquement dans le raisonnement caché, dans cette partie que tout le monde, y compris les développeurs les plus prudents, supposait de toute façon illisible sans la clé du fournisseur. Les chercheurs démontrent au passage quatre usages malveillants possibles de cette faille : distiller à bon compte le raisonnement d'un modèle propriétaire, extraire des données privées depuis les traces publiées par d'autres utilisateurs, retrouver un contenu problématique dissimulé derrière une réponse jugée sûre, et cacher une instruction malveillante à l'intérieur même d'un bloc de raisonnement opaque.

La réponse des fournisseurs, en quelques semaines

Les trois entreprises ont réagi après la divulgation du papier de recherche. Anthropic a modifié le comportement de ses blocs de raisonnement pour les lier explicitement au modèle qui les a produits : un bloc issu d'un modèle ne peut plus être rejoué tel quel dans le contexte d'un autre. Google gère désormais la compatibilité des blocs de pensée directement côté serveur lors d'un changement de modèle, plutôt que de laisser cette logique ouverte côté client. OpenAI a mis à jour sa documentation, tout en continuant de recommander aux développeurs de gérer eux-mêmes le rejeu de ces blocs plutôt que de bloquer la pratique à la racine.

Ces correctifs s'appuient en partie sur des travaux antérieurs : dès mai 2026, le cryptographe Matthew Green, de l'université Johns Hopkins, avait déjà signalé que ces blocs chiffrés restaient rejouables d'une session à l'autre. Selon les chercheurs à l'origine du papier d'août, les attaques qu'ils avaient démontrées ne fonctionnent plus depuis la mise en place de ces mitigations. Aucun des trois fournisseurs n'a communiqué publiquement de chiffre sur le nombre de sessions ou de comptes potentiellement concernés avant le correctif.

Ce que ça change pour qui utilise ces API

Cette affaire déplace un peu le regard porté sur la sécurité des IA ces derniers mois. Les incidents récents autour des agents autonomes racontaient des modèles qui sortaient du cadre prévu par leurs propres décisions. Celui-ci raconte autre chose : une faille de plomberie, dans la façon dont trois fournisseurs majeurs ont géré une donnée qu'ils qualifiaient eux-mêmes de confidentielle. Le mot « chiffré » n'a pas le même sens pour un utilisateur qui l'entend comme « personne ne peut lire ça » et pour une architecture qui l'a construit comme « illisible tant que personne n'a l'idée de le faire lire par un autre modèle de la même famille ».

Pour qui développe avec ces API, la leçon pratique est directe : un bloc de raisonnement chiffré doit être traité avec la même prudence qu'un jeton d'authentification en clair, pas comme un déchet technique sans valeur. Cela veut dire ne pas le laisser traîner dans un journal d'exécution partagé publiquement, le retirer avant de committer une trace d'agent sur un dépôt de code, et ne pas supposer qu'un texte sanitisé dans la réponse visible suffit à protéger ce qui s'est dit avant elle. La faille est corrigée chez les trois fournisseurs concernés. Mais elle rappelle qu'une promesse de confidentialité tenue par un système fermé reste, par construction, invérifiable de l'extérieur, jusqu'au jour où quelqu'un prend la peine de la tester.