Des sessions impossibles à emporter : la nouvelle dépendance créée par les API de raisonnement

• Les API de raisonnement cachent à l’intérieur du fournisseur les inférences chiffrées, résultats de recherche, états compactés et messages de sous-agents, si bien que l’historique de conversation détenu par l’utilisateur n’est plus une session complète, mais une copie partielle
• La portabilité d’une session ne consiste pas à reproduire la même sortie avec un autre modèle, mais à disposer d’un enregistrement sémantiquement complet que l’on peut inspecter, exporter, rejouer, auditer et supprimer sans consultation d’ID ni déchiffrement par le fournisseur d’origine
• Les réponses stockées et le raisonnement privé d’OpenAI, Anthropic et Google, ainsi que la recherche hébergée et les compactages opaques, renforcent la continuité au sein d’un même écosystème mais accumulent un état scellé par le fournisseur qu’un autre fournisseur ne peut pas reprendre
• Dans les systèmes multi-agents, même les délégations et les messages entre agents sont chiffrés, et la combinaison de compactages automatiques et d’instructions cachées fait qu’en cas de modification erronée de fichiers ou de fuite de secrets, il est difficile d’auditer quelles tâches ont été demandées
• Une API portable devrait prendre comme référence un journal local d’événements, rendre le stockage explicitement optionnel, fournir un historique complet et lisible de la recherche, du compactage, des communications entre agents et des artefacts, et permettre la distillation sous le contrôle de l’utilisateur

---

Comment les API de raisonnement transforment la propriété des sessions

• La promesse initiale des API de raisonnement était simple : envoyer une entrée, recevoir une sortie, conserver les deux, puis pouvoir inspecter, archiver, rejouer la conversation ou la transmettre à un autre modèle
• Cette abstraction n’a jamais été parfaite
  • Le cache de prompts existe sur les GPU du fournisseur
  • La tokenisation diffère d’un modèle à l’autre et l’échantillonnage n’est pas reproductible par conception
• Malgré cela, l’enregistrement sémantique contenant les instructions, messages, appels d’outils et résultats pouvait appartenir à l’utilisateur, et un autre modèle suffisamment capable pouvait comprendre le travail existant et le reprendre
• Les API récentes renvoient, en plus du texte, un état dépendant du fournisseur
  • Des jetons de raisonnement facturés, mais renvoyés uniquement sous forme de texte chiffré opaque ou de résumés limités
  • Une recherche web dont le client ne reçoit pas le texte original vu par le modèle
  • Un contexte compacté que seul le fournisseur d’origine peut déchiffrer
  • Des instructions et messages de sous-agents invisibles pour l’application
  • Des références à des fichiers, vector stores, conteneurs et caches impossibles à interpréter dans un autre environnement
  • Des réponses et états de conversation accessibles uniquement via des ID stockés sur les serveurs du fournisseur
• Chacun de ces choix a une justification en termes de confort ou de qualité, mais leur combinaison fait que l’historique local n’est plus la session entière : c’est une vue partielle d’une session dont le fournisseur possède l’état opérationnel

Cinq critères pour juger la portabilité d’une session

• Être portable ne signifie pas que le prochain token doit être identique après changement de modèle
  • Les modèles diffèrent par leurs capacités, leurs préférences apprises, leur fenêtre de contexte et leur manière d’utiliser les outils, et leurs sorties sont elles-mêmes non déterministes
• L’historique exporté doit contenir suffisamment d’informations compréhensibles pour qu’un nouveau modèle puisse poursuivre la tâche, sans devoir interroger les ID de l’ancien fournisseur, déchiffrer ses capsules, ni restaurer des résultats de recherche ou des résumés
• Inspection : l’utilisateur doit pouvoir voir ce que le modèle a vu, ce que les outils ont fait, et ce que les agents se sont échangé
• Export : sauf pour les artefacts ordinaires téléchargeables séparément, la session doit être autonome
• Replay : une autre implémentation doit pouvoir reconstruire un contexte sémantiquement équivalent
• Audit : un humain doit pouvoir expliquer a posteriori pourquoi le système a adopté un certain comportement
• Deletion : il doit être possible d’identifier et de supprimer toutes les copies côté serveur dont dépend la session
• Un ID de réponse servant de clé vers des données serveur n’est pas un historique de conversation, et un texte chiffré que l’utilisateur ne peut pas déverrouiller n’est pas sous contrôle de l’utilisateur
• Une simple liste d’URL citées ne remplace pas les éléments de preuve réellement injectés dans le contexte du modèle pendant la recherche

Un chiffrement que l’utilisateur ne peut pas déverrouiller

• Le nom encrypted_content donne l’impression d’une fonction de confidentialité pilotée par l’utilisateur, mais en pratique il s’agit souvent d’une capsule illisible pour le client et déchiffrable uniquement par le fournisseur
• Comme le fournisseur choisit la clé, déchiffre pour ses propres modèles et décide des environnements de replay possibles, le terme plus juste est état scellé par le fournisseur (provider-sealed state)
• Ce scellement peut avoir un véritable intérêt en matière de confidentialité
  • Avec store: false, OpenAI renvoie au client un raisonnement chiffré et peut le déchiffrer en mémoire à la requête suivante, sans stocker l’état intermédiaire
  • C’est notamment préférable, pour les clients Zero Data Retention, à une approche qui imposerait un stockage serveur des conversations
• Mais ce chiffrement ne cache pas les données au fournisseur : il les cache seulement à l’utilisateur

Comment les conversations stockées transforment l’historique en pointeur

• L’API OpenAI Responses stocke les réponses par défaut et la documentation indique que les objets de réponse sont conservés au minimum 30 jours
• L’utilisation de store: false évite le stockage sur les serveurs d’OpenAI et rapproche le fonctionnement de l’ancien mode completions
• L’API Gemini Interactions utilise aussi store: true par défaut
  • Les offres payantes conservent les interactions pendant 55 jours
  • L’offre gratuite les conserve pendant 1 jour
• Le stockage serveur réduit la quantité de données envoyées par l’application, maintient le raisonnement caché et l’état des outils, et facilite le routage via cache
• Mais si l’application locale n’enregistre que les messages de l’utilisateur et le texte final, l’ID de réponse utilisé dans previousResponseId devient une clé étrangère vers une base de données externe hors de contrôle

Des traces de raisonnement qui ne sont pas publiées

• Les grands laboratoires d’IA estiment avoir des raisons de ne pas publier la chaîne de pensée brute (chain of thought) et n’exposent généralement pas via API les jetons de raisonnement de leurs modèles à poids fermés
• Chez OpenAI, le raisonnement antérieur des réponses stockées peut être récupéré via previous_response_id
  • Avec store: false, le client doit conserver encrypted_content et le renvoyer à la requête suivante
  • Même si reasoning.context: "all_turns" permet sa réutilisation pour les générations ultérieures, le raisonnement stocké reste opaque
• Anthropic renvoie un thinking complet chiffré dans le champ signature
  • Le texte de thinking lisible que l’on peut activer n’est pas la chaîne de pensée brute, mais un résumé généré par un autre modèle
  • Lors des tours avec usage d’outils, le bloc thinking doit être renvoyé sans modification
  • Ces blocs thinking sont liés au modèle qui les a produits et doivent être retirés lors d’un changement de modèle ; Anthropic ne vise donc pas la portabilité, y compris en interne
• Ces approches assurent une continuité à l’intérieur d’un même écosystème, mais ne produisent pas un historique de conversation portable qu’un modèle d’un autre fournisseur pourrait interpréter

Les trous laissés dans l’historique par la recherche hébergée

• Un outil de recherche côté client peut enregistrer la requête, l’heure de recherche, les URL et titres des résultats, ainsi que les extraits récupérés
  • L’utilisateur peut inspecter le classement et les extraits, recharger les pages ou en conserver des copies pour transmettre les mêmes preuves à un autre modèle
• Dans une recherche hébergée, le fournisseur exécute une boucle d’outils privée
  • OpenAI, Google et Anthropic fournissent le comportement de recherche, des citations et parfois des URL source, mais pas le contexte textuel complet utilisé pour générer la réponse
  • Le contenu des URL peut changer, et le modèle n’a peut-être reçu que des extraits plus courts ; ce n’est donc pas une trace stable pour le replay
• Si le modèle suivant veut comparer une source précise ou revérifier un chiffre contestable, il n’obtient ni le classement des résultats, ni les extraits extraits, ni les documents filtrés, ni la preuve exacte vue par le modèle précédent
• Même en rechargeant les pages citées, il est impossible de reproduire exactement les données utilisées à ce moment-là ; l’ancien fournisseur reste donc présent dans la session, même après son transfert ailleurs
• La recherche hébergée a besoin d’un export à fidélité complète contenant la requête, les métadonnées des résultats, les extraits de recherche, les horodatages et le contenu conservé ; des citations brèves ne doivent pas devenir l’unique trace

Un compactage de contexte opaque

• Les longues sessions d’agents ont besoin de compactage, et un résumé lisible contrôlé par le client peut, même avec perte, être inspecté, édité et transféré
• Le compactage côté serveur d’OpenAI renvoie des éléments compaction chiffrés qui ne sont pas conçus pour être interprétés par un humain
  • /responses/compact renvoie la canonical next context window que le client doit simplement retransmettre telle quelle
  • OpenAI peut ainsi poursuivre le sens compacté, mais un autre fournisseur ne recevra qu’un texte chiffré et une partie du contexte récent
• Ce type de compactage opaque n’est pas techniquement inévitable
  • Le compactage côté serveur d’Anthropic renvoie des blocs compaction avec un champ content lisible
  • Le client peut fournir des instructions de résumé personnalisées, puis inspecter le résultat ou le transmettre à un autre modèle
  • Le compactage côté client est également possible chez tous les fournisseurs
• L’artefact scellé d’OpenAI peut mieux préserver un état propre au modèle qu’un simple résumé et donc offrir de meilleures performances avec le modèle d’origine, mais il devrait être proposé comme optimisation optionnelle, accompagné d’un résumé de passation lisible

Délégations et communications cachées dans le multi-agent

• Dans un système multi-agent, le problème de portabilité est plus grave encore, car il n’y a pas un seul historique mais un arbre de session et des flux de messages entre agents
• La bêta OpenAI Responses Multi-agent ajoute des éléments multi_agent_call, multi_agent_call_output et agent_message
  • Dans l’exemple spawn_agent, l’argument message est chiffré
  • Les messages entre agents ne contiennent que encrypted_content
  • Quand le mode multi-agent est activé, un compactage automatique côté serveur est appliqué à tous les agents, même si le client ne l’a pas demandé
  • Les résumés de raisonnement ne sont pas pris en charge, et des instructions racine et sous-agent que le développeur ne peut ni éditer ni supprimer sont aussi injectées
• Au final, délégations scellées, messages scellés, contextes compactés individuellement, raisonnement caché et orchestration hébergée par le fournisseur forment un paquet d’état impossible à transférer
• En juin 2026, le client open source Codex a intégré la modification Encrypt multi-agent v2 message payloads
  • L’API Responses chiffre les arguments d’outils du modèle parent
  • Quand Codex transmet le texte chiffré, l’API le déchiffre en interne pour le modèle enfant
  • InterAgentCommunication.content de Codex est vide, si bien que les instructions de tâche exactes n’apparaissent ni dans la trace d’exécution lisible ni dans l’historique
• Même si un agent enfant modifie le mauvais fichier, divulgue un secret, duplique une autre tâche ou suit une hypothèse erronée, l’utilisateur ne peut pas vérifier ce qui lui a été demandé
• L’issue publique de Codex demande de conserver, en plus du transfert chiffré, une copie d’audit lisible
  • C’est le minimum ; des messages inter-agents en clair devraient être le comportement par défaut

Pourquoi il faut la liberté de déplacer une session

• Même si la plupart des utilisateurs ne changent pas de modèle au milieu d’une session, la possibilité de le faire change la relation entre l’utilisateur et le fournisseur
• Les situations qui exigent un transfert incluent la suppression d’un modèle, une panne de service, un changement de prix, une politique bloquant la requête suivante, une exécution locale pour une étape confidentielle, ou encore une reconstruction a posteriori par un auditeur
• À mesure que les agents allongent les sessions, les sessions de code et de recherche accumulent sur plusieurs jours des décisions et des preuves, tandis qu’un assistant personnel peut accumuler un historique sur plusieurs années
• Si l’utilisateur peut continuer ailleurs, les fournisseurs doivent se battre sur la qualité du modèle, le prix, la fiabilité et la confiance
• Si un seul fournisseur peut interpréter le contexte accumulé, cela crée une structure d’incitations défavorable qui rend le départ de l’utilisateur plus difficile

Principes d’une API de raisonnement portable

• Le journal local d’événements doit être l’enregistrement de référence
  • Le stockage serveur peut le répliquer ou l’accélérer, mais le client doit pouvoir reconstruire la session sans consulter d’ID serveur
• Le stockage doit être un choix explicite
  • store: false doit être simple à utiliser, bien documenté et idéalement être le comportement par défaut
  • Les fonctionnalités qui nécessitent de la rétention doivent le signaler au moment où elles sont utilisées

• Les éléments opaques ne doivent pas monopoliser le sens

  • Le raisonnement chiffré, les compactages et les signatures d’outils peuvent être inclus pour améliorer la qualité chez un même fournisseur, mais ils doivent être accompagnés d’une représentation de passation lisible et neutre vis-à-vis du fournisseur
  • Les outils hébergés doivent produire des journaux à fidélité complète
    • Ils doivent enregistrer les entrées et sorties exactes, les preuves, le filtrage, les sources, les horodatages et les hachages de contenu
  • Les communications de sous-agents doivent être auditables
    • Il faut conserver sous forme lisible les tâches exactes de chaque agent, ses messages, résultats, lignage, modèle et autorisations d’outils
  • Le compactage doit être inspectable
    • Il doit renvoyer un résumé lisible, les instructions ayant servi à le produire, et un lignage permettant de comprendre ce qui a été écarté

• Les artefacts doivent pouvoir être exportés

  • Les fichiers, sorties de conteneurs, instantanés de recherche et médias générés doivent pouvoir être téléchargés dans une archive locale adressée par contenu

Distillation et dépendance à la hiérarchie des modèles

• Certains grands laboratoires américains à poids fermés durcissent leur hostilité envers la distillation externe
• Anthropic, dans un billet de février 2026, qualifie les activités de DeepSeek, Moonshot et MiniMax de distillation attacks
  • Ses conditions commerciales précisent que les clients possèdent les sorties, tout en interdisant l’usage des sorties du service pour entraîner des modèles d’IA concurrents
  • Dans le même temps, Anthropic reconnaît dans ses propres publications que la distillation est une méthode d’entraînement courante et légitime lorsqu’elle est utilisée par les laboratoires de pointe sur leurs propres modèles
• Anthropic a collecté des données du web public avec des robots et découpé des livres pour les scanner afin de développer ses modèles ; OpenAI a lui aussi déclaré s’entraîner sur des contenus publics librement accessibles sur Internet en invoquant le fair use
• Les deux entreprises considèrent la distillation comme une méthode normale quand elles créent en interne des modèles plus petits
  • OpenAI a même proposé un workflow de distillation via sa propre API pour affiner de petits modèles OpenAI à partir des sorties de modèles OpenAI plus puissants
• Il existe une asymétrie morale : on exige que les machines puissent apprendre à partir de l’immense masse de travaux publiés par des humains sur Internet, tout en refusant que d’autres machines apprennent à partir des sorties produites par les laboratoires
• La distillation peut transférer les capacités de modèles frontier coûteux vers des modèles plus petits, moins chers et plus rapides
  • Ils peuvent fonctionner en local, hors ligne, sur du matériel contraint ou dans des environnements sous contrôle utilisateur
  • Cela accroît la concurrence, préserve les capacités même si une API disparaît, et réduit le calcul et l’énergie nécessaires aux tâches courantes

Les libertés minimales que l’utilisateur devrait avoir

• L’utilisateur devrait pouvoir conserver ses sessions après la fermeture de son compte et les transmettre à un autre modèle
• Le nouveau modèle peut porter un jugement différent, poser des questions, ou être moins performant, mais il ne devrait pas recevoir uniquement du texte chiffré à la place de l’historique utilisateur, des preuves, des plans et des tâches déléguées vus par le modèle précédent
• Les API à état persistant ne sont pas le problème en soi ; le problème est que de meilleures performances soient couplées à une réduction du contrôle utilisateur
• Le stockage serveur doit être optionnel, les outils hébergés observables, le compactage lisible et les communications entre agents auditables
• Même pour le raisonnement privé, il faut au minimum une trace de passation portable, et la distillation ne devrait pas être un tabou servant à justifier des barrières plus élevées, mais un moyen de rendre les capacités plus largement accessibles

[GN⁺]

Commentaires sur Hacker News

• Cet article montre que la situation est déjà plus grave qu’on ne le pense. Il est important de ne pas dépendre d’un écosystème donné, car c’est en exerçant réellement sa liberté que la relation avec le fournisseur peut changer
  J’ai accepté à contrecœur Codex, qui masque le processus de raisonnement, parce que ses performances sont bonnes, mais l’impossibilité d’audit est déjà un problème majeur, au point de me faire reconsidérer mon abonnement personnel. C’est aussi pour cela que je développe une application mobile pour OpenCode

  • En gardant à l’esprit le problème de la disparition de conversations de session d’agent pourtant précieuses, j’ai créé https://www.agentkanban.io. On peut y stocker le contexte dans les tâches du tableau et le recharger plus tard dans une nouvelle session d’agent, avec prise en charge actuelle de Claude et GitHub Copilot dans VS Code
    L’historique d’utilisation d’outils propriétaires est volontairement exclu, car il casse la portabilité des sessions
  • Je reste optimiste : les dark patterns ne sont qu’une stratégie gagnante à court terme, qui finira par être dépassée à long terme par des approches respectueuses des utilisateurs et orientées vers l’intérêt général. Vu la rapidité possible du basculement, c’est peut-être le moment de se concentrer sur des modèles à poids ouverts et économiquement viables
  • En attendant que les prix baissent, j’essaie de collecter autant que possible les données de session de Claude et Codex pour les exploiter plus tard dans le fine-tuning de modèles ouverts. J’ai aussi créé mes propres outils d’analyse et d’archivage de sessions
  • J’ai même réuni jusqu’à 96 Go de VRAM pour faire tourner des modèles en local, mais il n’existe toujours rien qui approche Codex basé sur GPT. Laguna S2.1 NVFP4 s’en rapproche pas mal pour le code, mais les modèles locaux semblent encore loin de constituer une alternative généraliste sérieuse
  • https://indieweb.org/POSSE est la solution

• C’est un bon article sur un problème que la plupart des utilisateurs d’IA évaluent à peine. Les fournisseurs de pointe en raisonnement présentent des fonctions non-LLM comme la recherche web ou l’exécution de code comme de simples outils, alors qu’en réalité elles créent de fortes barrières à l’entrée et du couplage
  En théorie, on pourrait les externaliser via des serveurs MCP séparés de l’API de raisonnement, mais les fournisseurs le proposent rarement et les alternatives concurrentes sont généralement faibles. En développant https://github.com/EratoLab/erato, une plateforme de chat on-premise et indépendante des fournisseurs, j’ai constaté que même une fonction apparemment simple comme la génération d’images dans le chat était difficile à implémenter, notamment parce que le MCP n’a toujours pas de spécification de base pour le transfert de fichiers : https://github.com/modelcontextprotocol/modelcontextprotocol...
  Avec l’intérêt croissant pour les modèles à poids ouverts, j’espère voir davantage d’implémentations alternatives plus faciles à remplacer

  • Faire exécuter en local des agents dont on ne peut absolument pas inspecter les prompts, comme avec des messages de sous-agents chiffrés, est fondamentalement irresponsable. En revanche, je ne considère pas comme problématique le fait qu’un fournisseur propose des outils hébergés, un peu comme des achats d’impulsion à la caisse
    Pour la génération d’images, il suffit d’écrire son propre outil plutôt que de passer par MCP. Il existe déjà suffisamment de fournisseurs d’inférence image/média comme Fal, ainsi que de recherche web et de recherche approfondie

• Il nous faudrait peut-être des standards ouverts ou des formats de fichier pour le contexte. Je me demande si les modèles ouverts pourraient s’aligner sur un même format pour la portabilité, et si cela pourrait être basé sur SQLite afin que d’autres programmes puissent aussi l’interroger

• En pratique, il y a souvent beaucoup de bruit dans une conversation, au point qu’il vaut mieux l’exclure du contexte. Je fais écrire à l’IA, dans le répertoire de notes du dépôt, des fichiers Markdown contenant ce qu’elle a appris, ce qu’elle a terminé et ce qu’il reste à faire, pour qu’un autre modèle puisse reprendre dans la conversation suivante
  Et si besoin, je peux d’abord modifier moi-même les notes

  • C’est pour cela que j’utilise davantage le codage par agent. J’assigne une tâche, j’exige des tests et un lint strictement validés, puis j’ignore les longues explications du modèle
    Il n’a qu’à revenir quand tous les contrôles sont passés, ce qui évite une bonne partie des échanges inutiles de l’interface de chat
  • Si on jette la session, on perd les fonctions d’inspection, d’export, de réexécution et d’audit. Les principaux fournisseurs de modèles n’ont pas de véritable barrière à l’entrée, et OpenAI comme Anthropic affichent de fortes marges opérationnelles négatives sans disposer non plus des moyens financiers des géants de la tech
    Ils cherchent donc à créer artificiellement de la dépendance, ce qui relève fondamentalement du droit antitrust. Mais aux États-Unis, l’affaiblissement actuel de la FTC laisse faire
  • Pouvoir changer facilement de modèle sans perte améliorerait la concurrence du marché et produirait une IA meilleure et moins chère. Si la perte d’une partie du contexte rend la transition pénible, les fournisseurs peuvent créer du vendor lock-in, dégrader l’expérience utilisateur et augmenter les prix
    Même s’il existe aujourd’hui des contournements, l’incitation à rendre la mobilité plus difficile reste forte, et il est inquiétant de voir les entreprises de l’IA commencer à poser les bases de cette dégradation des services
  • Les sessions longues perdent souvent le fil de l’avancement, et plus un modèle est verbeux, plus le rapport signal/bruit devient mauvais. Ce qui a de la valeur, ce n’est pas la session brute, mais les résultats comme les modifications de code ou les plans et résumés

• Il faut distinguer deux phénomènes. Le premier est l’augmentation de l’état caché que l’utilisateur ne peut ni inspecter ni déplacer, ce qui est clairement mauvais. Le second est la divergence des implémentations de fonctions et des API selon les fournisseurs : le problème n’est pas que la portabilité devienne impossible, mais qu’elle devienne plus difficile
  L’époque où l’API OpenAI Completions servait de standard universel touche à sa fin, et hors des parties fermées, la nouvelle API Responses est peut-être meilleure. Il n’est pas nécessaire que produits, bibliothèques et SDK continuent à viser une abstraction unifiée couvrant tous les fournisseurs
  Comme pour les bases de données, où les abstractions unifiées ont fini par fuir et laisser place à des implémentations spécifiques, la même chose arrivera sans doute avec les fournisseurs de modèles ; il suffit qu’une partie de la session reste portable

  • Cet article ne traite que du premier phénomène, celui de l’état caché

• Je développe https://github.com/pantoniou/fyai, encore assez brut, qui préserve directement les données de session et les gère selon un modèle proche de git

  • Cet outil ne peut pas résoudre le problème traité dans l’article, et ne peut pas le résoudre par conception

• Il serait raisonnable d’avoir un contrat garantissant qu’on puisse conserver ses sessions et les transmettre à un autre modèle même après la fermeture du compte. Idéalement, il devrait aussi être facile de trouver des modèles aux caractéristiques d’embedding similaires
  Quand GPT-4o a été interrompu la première fois, certaines personnes ont essayé de retrouver leur ancien compagnon en injectant leurs conversations exportées dans des modèles au ton et à la personnalité proches, mais les autres modèles d’OpenAI ne procuraient pas la même impression. Les modèles à poids ouverts ont l’avantage de pouvoir être conservés à jamais : un grand groupe ne peut pas vous retirer un guide, un ami ou un conseiller d’un simple geste unilatéral

• Je me demande ce qu’il faudrait pour faire avancer cette discussion au-delà d’un simple sujet de blog HN

• Les modèles actuels ont une fenêtre de contexte limitée, donc ils finissent de toute façon par oublier ; la valeur d’une session n’est donc pas si grande. Si, à l’avenir, les interactions faisaient réellement apprendre et évoluer le modèle lui-même, ce changement ne pourrait de toute façon pas être porté vers un autre modèle, donc je ne pense pas que ce problème ait beaucoup d’importance

• Lire aussi https://gwern.net/complement avec cet article en fait un excellent complément

  • Pourquoi est-ce un complément ? Il faudrait l’expliquer