Tu utilises ton outil de code IA depuis des mois. Il autocomplète tes noms de variables comme tu les aimes. Il se souvient des patterns de test de ton équipe. Il sait que tu as renommé ce service mardi dernier et ne te le redemande pas. Tu n'as rien configuré — il a juste appris.

Agréable, non ? Comme avoir un dev junior qui prend vraiment des notes. Sauf qu'il y a un petit hic : des preuves de plus en plus solides suggèrent que toute cette mémoire accumulée rend peut-être ton agent pire en écriture de code. Et tu ne peux toujours pas l'emporter avec toi quand tu pars.

Entre le 8 et le 16 avril, Anthropic et OpenAI ont livré de tout nouveaux systèmes de mémoire pour leurs agents de code. Le Memory Bank de Google tourne depuis décembre 2025. Les trois architectures sont totalement incompatibles — et au moins une étude montre que l'approche se retourne contre toi plus souvent qu'elle ne t'aide.

Trois architectures de mémoire, trois paris différents

Anthropic a ouvert le bal. Le 8 avril, ils ont lancé les Managed Agents avec Memory Stores — des collections de texte rattachées à un workspace que l'agent lit avant chaque tâche et met à jour à la fin. Chaque mémoire est plafonnée à 100 Ko, tu peux en attacher jusqu'à 8 par session, et chaque modification crée une version immuable. Tarif : les prix API standard plus 0,08 $ par session-heure.

Et ce n'est qu'une couche. Claude Code fait tourner trois mécanismes de mémoire : les fichiers CLAUDE.md écrits par l'utilisateur (tes instructions), les fichiers MEMORY.md auto-générés (les notes de l'agent pour lui-même), et ces Memory Stores côté serveur. Trois couches de contexte. Trois formats. Zéro portabilité.

OpenAI a suivi une semaine après. Les 15-16 avril, Codex a livré les fichiers AGENTS.md pour les instructions projet, plus une fonctionnalité "Memories" transportant des "préférences stables, conventions de projet et patterns de travail récurrents" d'une session à l'autre. Leur approche parcourt l'arborescence de la racine du projet jusqu'au répertoire courant, en fusionnant les fichiers de façon hiérarchique — jusqu'à 32 Ko chargés à chaque exécution.

Google a pris un chemin radicalement différent. Memory Bank dans Vertex AI Agent Engine, en disponibilité générale depuis décembre 2025 et facturé depuis février 2026, fait l'impasse sur les fichiers markdown. Les modèles Gemini analysent ton historique de conversation en arrière-plan et en extraient des mémoires structurées — faits clés, préférences, relations — avec expiration automatique et recherche par similarité.

Couches markdown vs. chaînes d'instructions hiérarchiques vs. données structurées extraites par IA. Trois éditeurs, chacun convaincu que son architecture est la bonne. L'industrie a atteint l'incompatibilité parfaite en un temps record.

La taxe mémoire

C'est ici que le discours commercial percute la réalité. Dans un preprint de mars 2026, des chercheurs de l'ETH Zurich ont testé l'impact des fichiers de contexte sur les performances des agents de code. Dans 5 configurations sur 8, les agents ont performé moins bien avec le contexte accumulé qu'à vide — pendant que les coûts d'inférence grimpaient d'au moins 20 %.

Laisse ça infuser derrière le sourire satisfait de ton "assistant IA personnalisé". La fonctionnalité de mémoire que les éditeurs présentent comme leur avantage décisif a activement dégradé la qualité du code dans la majorité des scénarios de test. L'agent lit ses propres notes, s'emmêle dans du contexte périmé ou contradictoire, et produit du code pire tout en te facturant plus de tokens pour le privilège.

Ça ne devrait surprendre aucun ingénieur senior qui a vu un system prompt gonfler jusqu'à 50 Ko. Plus de contexte signifie plus de choses à jongler. Certains éléments sont obsolètes. D'autres se contredisent. D'autres étaient pertinents il y a trois refactos. Ton agent lit consciencieusement ses notes vieilles de deux mois sur un monolithe que tu as depuis découpé en trois microservices, puis génère avec aplomb du code pour une architecture qui n'existe plus. Pratique.

Et pourtant — chaque session en rajoute. Chaque bug que tu expliques, chaque décision d'architecture que tu débats, chaque raccourci que tu décris est absorbé. L'analyse de MindStudio du 9 avril a forgé le terme "behavioral lock-in" : "Quand tu exportes ton historique de conversation, tu obtiens du texte. Ce que tu n'obtiens pas, ce sont les représentations internes du modèle, les embeddings et les poids qui encodent ce que l'agent a réellement appris."

Tu paies pour accumuler une archive de mémoire qui plombe probablement les résultats de ton agent — mais tu ne peux pas partir parce que repartir de zéro signifie perdre ce qui fonctionne effectivement. Magnifique.

La cage confortable

Comme Kai Waehner l'a noté le 6 avril, "si tes workflows agentiques reposent sur la couche d'orchestration propriétaire d'un éditeur, les coûts de migration s'accumulent très vite." Quand les modèles deviennent des commodités — quand GPT-5, Claude 4 et Gemini 2.5 sont à 5 % l'un de l'autre sur les benchmarks — l'agent qui te connaît le mieux est celui que tu continues à payer. Pas parce qu'il est meilleur. Parce que partir fait trop mal.

Et voici le vide réglementaire que MindStudio pointe : le RGPD et le CCPA couvrent les données personnelles structurées — ton nom, ton email, ton historique d'achats. Personne ne régule les patterns implicites que ton agent IA construit sur ton style de code, tes préférences d'architecture ou tes particularités de déploiement. Tu peux demander tes données. Tu ne peux pas demander la compréhension que ton agent a de toi. Ce comportement appris — précisément ce qui crée les coûts de migration — existe dans un no man's land juridique où aucun bouton d'export n'existe et aucune loi n'en exige un.

Aucun éditeur n'a intérêt à construire un format d'échange de mémoire portable. Ton contexte accumulé — même le contexte qui dégrade tes résultats — est leur fossé concurrentiel.

Ce que tu devrais faire maintenant

Fais l'audit de ce que ton agent a réellement appris. Si tu utilises Claude Code, ouvre tes fichiers CLAUDE.md et MEMORY.md — ce sont de simples fichiers markdown dans ton répertoire projet. Lis-les avec un œil critique. Combien reflètent encore ton vrai codebase ? Combien décrivent un service que tu as décomposé il y a deux sprints ? Si tu utilises Codex, parcours ta chaîne AGENTS.md de la racine aux feuilles. Si tu utilises Vertex, vérifie tes entrées Memory Bank dans la console.

Puis fais quelque chose de contre-intuitif : désactive la mémoire pour une session et compare les résultats. Si ton agent performe aussi bien ou mieux sans ses notes accumulées, tu as payé une taxe mémoire pour le privilège d'être enfermé.

Les guerres de modèles étaient l'entrée. La couche mémoire est le plat principal — et la vérité qui dérange, c'est que tu paies pour accumuler du contexte qui dégrade le travail de ton agent, stocké dans un format que seul ton éditeur actuel peut lire, protégé par aucune réglementation, et portable nulle part. L'agent qui se souvient de toi n'est pas celui qui te sert le mieux. C'est juste celui que tu ne peux plus quitter.