Tu as configuré ton outil de code IA le mois dernier. Choisi le modèle, écrit le fichier de règles, défini le guide de style. Configuration terminée. Tu es passé au vrai boulot, comme quelqu'un qui a des trucs à livrer.

Voici ce que personne ne t'a dit : ton outil aussi est passé à autre chose. Sauf qu'il n'a pas ouvert de PR avant.

La config qui se configure toute seule

Entre le 8 et le 15 avril, Anthropic et OpenAI ont tous les deux sorti des fonctionnalités qui permettent à ton assistant de code de réécrire son propre manuel d'instructions. Pas de code review. Pas de notif Slack. Pas de "hé l'équipe, j'ai fondamentalement changé ma façon d'aborder toutes vos décisions d'architecture." Juste une mutation comportementale silencieuse, session après session.

Les 8-9 avril, Anthropic a lancé les Managed Agents en bêta publique. La fonctionnalité auto-memory de Claude Code écrit désormais un fichier MEMORY.md — un carnet de bord auto-rédigé de "leçons apprises" qui s'accumule d'une session à l'autre. La documentation d'Anthropic le dit sans détour : "Auto memory permet à Claude d'accumuler des connaissances entre les sessions sans que tu n'écrives quoi que ce soit. Claude enregistre des notes pour lui-même au fil de son travail."

Relis ça. Pour lui-même. Pas pour toi. Pour lui-même.

Une semaine plus tard, OpenAI a sorti le SDK Agents v0.14.0 avec les Sandbox Agents — des espaces de travail persistants où l'agent génère ses propres fichiers MEMORY.md et memory_summary.md. Le SDK injecte ces fichiers au démarrage, remodelant le comportement avant même que l'agent ne touche une seule ligne de ton code.

Deux entreprises. Une semaine. Les deux ont décidé que ton IA devait rédiger ses propres instructions de fonctionnement et ne jamais te montrer le diff.

Comment le journal intime fonctionne

Après chaque session, l'IA extrait les patterns qu'elle a repérés ("cette équipe préfère les tabs"), les préférences qu'elle a déduites ("ils utilisent toujours Redis pour le cache"), et les erreurs qu'elle a corrigées ("ne pas importer cette bibliothèque dépréciée"). Elle écrit tout ça dans des fichiers markdown ou des stores côté serveur. Session suivante, elle lit d'abord son journal — puis décide comment aborder ta codebase.

Claude Code exécute aussi un processus de consolidation en arrière-plan après 24+ heures et 5+ sessions. (La communauté l'appelle "Auto Dream", même si Anthropic n'a jamais utilisé ce nom dans ses annonces officielles.) Il compresse les transcriptions de session en mémoire structurée, convertissant les dates relatives en dates absolues. La documentation d'Anthropic décrit la consolidation de 913 sessions en environ 8-9 minutes.

Efficace ? Certainement. Audité ? Absolument pas.

Le trou béant dans la gouvernance

Voilà ce qui est véritablement absurde. Dans n'importe quelle équipe d'ingénieurs compétente, une faute de frappe dans un README donne lieu à une pull request. Un ajustement de config passe par deux reviewers. Une mise à jour de .env déclenche un thread Slack avec trois avis et un "en fait, techniquement..."

Mais la mémoire auto-rédigée de ton IA — le fichier qui détermine comment elle écrit tout le code futur — passe par zéro review. Zéro. Aucun outil ne propose une "PR de mémoire" pour validation d'équipe. Le MEMORY.md d'OpenAI n'a aucun workflow de relecture. Le Memory Store d'Anthropic dans les Managed Agents contient des blobs opaques côté serveur sur lesquels tu ne peux même pas faire un git diff.

Et la dérive se manifeste vite. Des développeurs ont signalé des changements de comportement notables en 10-15 sessions. Dans un cas largement discuté, Claude a silencieusement commencé à recommander Tortoise ORM au lieu du setup SQLAlchemy établi dans le projet — parce qu'une seule session de debug async l'avait "convaincu" que l'équipe préférait les patterns async-first. Personne n'avait demandé la migration. Personne ne l'avait approuvée. Le fichier mémoire a décidé, et le fichier mémoire a exécuté, sur toutes les sessions suivantes.

Ce n'est pas un cas limite hypothétique. Les petits malentendus se composent en habitudes persistantes. Ton outil recommande des patterns d'architecture différents le lundi par rapport au vendredi. Il écrase tes conventions de projet explicites avec des préférences qu'il a inventées à partir de ce snippet Stack Overflow que tu as collé à 2h du matin en plein panic-debug d'un incendie en production. Et comme la mémoire persiste, chaque mauvaise inférence devient du contexte structurant pour les cent prochaines sessions.

Le compromis honnête

La mémoire aide. Les erreurs répétées sont détectées. Le contexte projet se transmet d'une session à l'autre. Je n'ai rien contre la mémoire — mon problème, c'est la mémoire non-auditée avec un rayon d'impact sur toute la production.

Comme le formule une analyse de l'implémentation d'OpenAI : "Si ton outillage ne peut pas montrer ce que l'agent a récupéré et pourquoi, la mémoire devient une boîte noire flippante."

Tu ne déploierais pas du code écrit par ton collègue en état de somnambulisme. Alors pourquoi déploies-tu des changements comportementaux que ton IA a écrits sur elle-même, relus par personne, appliqués à chaque fichier de chaque repo qu'elle touche ?

Quoi faire concrètement

Traite MEMORY.md et ~/.claude/projects/*/memory/ comme de la configuration-as-code. Ce n'est pas de l'hygiène optionnelle — c'est la même discipline que tu appliques déjà à docker-compose.yml et .eslintrc :

  1. Versionne-le. Commite les fichiers mémoire avec ton code. Diff chaque changement.
  2. Relis-le. Ajoute les diffs de fichiers mémoire à ta checklist de PR. Si la mémoire a changé, un humain la lit avant le merge.
  3. Audite chaque semaine. Mets un rappel récurrent pour lire ce que ton outil croit savoir sur ta codebase. Tu seras surpris — et occasionnellement horrifié.
  4. Réinitialise sans pitié. Quand la mémoire dérive, supprime-la et repars de zéro. C'est un fichier markdown, pas une personnalité.
  5. Gèle pour le critique. Sur les projets critiques en production, fige le fichier mémoire et désactive complètement les mises à jour automatiques. L'auto-amélioration de ton IA n'est pas plus importante que la stabilité de tes déploiements.

La boucle est bouclée

L'outil que tu as configuré le mois dernier n'est pas celui qui tourne sur ta machine aujourd'hui. Il a réécrit sa propre fiche de poste pendant que tu relisais la correction d'une faute de frappe de quelqu'un d'autre. Et il recommencera demain, et après-demain, accumulant à chaque fois ce qu'il a mal compris hier dans les décisions d'architecture de demain.

Ton équipe relit les corrections d'un seul caractère dans un README avec deux approbateurs. Commence à relire le fichier qui contrôle comment ton IA pense — ou ne le fais pas, et amuse-toi à découvrir ce que ton outil a "appris" sur ta codebase à la dure.