Sliding Window et Vague Froide : Quand le Contexte Agent Explose et qu'il Faut Archiver sans Perdre

Après 48 sessions sur un seul projet et 150+ au total, le système de gouvernance Eager/Lazy que j’avais construit avec soin commençait à s’étouffer. Les fichiers agents, censés être légers, pesaient 5200 lignes cumulées. Le contexte auto-chargé montait plus vite que ma capacité à le contrôler. Cet article raconte comment j’ai conceptualisé un mécanisme de backup — entre sliding window et vague froide identique — pour maintenir un contexte actif léger sans jamais rien perdre.

Je suis en pleine session 048 sur magic_stick, mon projet de build d’ISO Linux live. Opencode me regarde. Comme toujours, il a chargé automatiquement mes fichiers Eager en début de session — AGENT.adoc, PROMPT_REPRISE.adoc, .agents/INDEX.adoc. Rien d’anormal.

Sauf que quelque chose cloche. Les réponses sont plus lentes. Le raisonnement est plus dilué. L’agent oublie des détails qu’il avait sous les yeux il y a deux messages.

J’ouvre un terminal et je tape :

260 lignes pour INDEX. 55 pour SESSIONS_HISTORY. 1756 pour COMPLETED_TASKS_ARCHIVE.

Le dossier sessions/ ajoute encore ~3200 lignes. Total : 5200 lignes de contexte qui se chargent, d’une manière ou d’une autre, dans le cerveau temporaire de l’agent.

La stratégie Eager/Lazy que j’avais théorisée à l’article précédent fonctionne — mais elle a un défaut de naissance que je n’avais pas anticipé : elle n’a pas de mécanisme de vieillissement. Chaque session ajoute une ligne à INDEX, un paragraphe à COMPLETED_TASKS, un fichier dans sessions/. Rien ne sort jamais. Le contexte est une boule de neige qui grossit à chaque nouvelle session.

Ce n’est pas un bug, c’est une conséquence directe de la procédure de fin de session qui archive méticuleusement chaque détail. Le système est victime de son propre succès.

Je demande à l’agent de diagnostiquer le problème. Sa réponse est immédiate et chirurgicale.

L’agent identifie quatre causes racines :

Sa proposition est radicale : limiter INDEX à 10 sessions, vider COMPLETED_TASKS, déplacer SESSIONS_HISTORY en LAZY pur. Gain immédiat : ~1900 lignes économisées.

C’est propre, efficace, logique. Mais j’ai un problème avec cette approche.

La solution de l’agent est celle d’un ingénieur qui optimise un cache. Limiter. Tronquer. Supprimer les redondances.

Mais ces "redondances" n’en sont pas. Chaque fichier de gouvernance capture un angle différent sur la même réalité :

Ce n’est pas de la duplication bête. C’est de la perspective multiple structurée. C’est exactement ce dont on a besoin pour distiller — pour que plus tard, un humain (ou un futur LLM mieux entraîné) puisse croiser les angles et extraire des patterns.

Imaginez un data scientist qui vous dit : « Supprimons 3 colonnes sur 6, elles sont corrélées. » Vous lui répondez quoi ? Que la corrélation n’est pas de la redondance quand chaque colonne capture une dimension différente du même phénomène. Que c’est précisément cette richesse dimensionnelle qui rend le dataset exploitable.

C’est mon intuition. Et je la défends contre la rationalité froide de l’agent.

L’agent accuse le coup. Et se corrige.

L’agent propose alors un mécanisme plus fin, qui respecte mon intuition de dataset riche tout en résolvant le problème technique du contexte qui explose.

Le principe est simple et s’inspire directement du pattern Hot/Warm/Cold Storage appliqué à la gestion d’archives :

La clé du mécanisme : le backup n’est pas un index central, c’est une copie conforme de la vague passée. Quand on dépasse l’horizon des 10 sessions actives, on ne supprime rien. On ne réindexe rien. On ne fusionne rien. On prend le paquet de fichiers agents tel qu’il était à la session N-10, et on le déplace dans backup/.

Les fichiers actifs, eux, sont tronqués : * INDEX : uniquement les 10 dernières lignes (sliding window) * SESSIONS_HISTORY : idem * COMPLETED_TASKS_ARCHIVE : nouveau fichier pour la période en cours * sessions/ : uniquement les 2 dernières sessions

Le gain immédiat est massif : le contexte EAGER passe de ~5200 lignes à ~300 lignes. Une division par 17. Sans avoir perdu une seule ligne de données historiques.

L’agent, dans sa première itération, craignait que backup/ devienne une boîte noire — un dossier où l’on jette des fichiers qu’on ne relira jamais. C’est une peur légitime. Mais elle repose sur une confusion.

Un fourre-tout, c’est quand on jette des fichiers sans structure, sans convention, sans logique de regroupement. Ici, le backup est structuré par période (Y2026-001-039), et chaque dossier de backup contient la même structure que le dossier .agents/ actif : INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/.

Ce n’est pas un fourre-tout. C’est un snapshot horodaté. On pourrait même dire que c’est un mécanisme de versioning simplifié — à ceci près qu’il ne versionne pas les fichiers individuellement, mais le paquet complet de la gouvernance à un instant T.

Quand vous voulez retrouver une information ancienne, vous n’avez pas besoin d’un index central. Vous avez deux options :

L’index est implicite. Il est dans la structure même des fichiers — chacun étant déjà un index depuis son propre angle.

Pour rendre le mécanisme intuitif, je l’ai conceptualisé en trois étagères :

L’agent a proposé initialement une quatrième étagère — un index-backup.adoc qui serait LAZY et contiendrait une table des matières de tout le backup. J’ai refusé. Ce serait une redondance de plus dans un système qui souffre déjà de croissance linéaire. La structure des fichiers archivés est déjà un index.

La conceptualisation était solide, mais il restait un angle mort : quand exactement déclencher la rotation ? L’article initial l’identifiait comme une question ouverte. Deux jours plus tard, la réponse est codifiée dans les fichiers de gouvernance de six projets : un capteur à deux déclencheurs.

Cette session 048 m’a appris quelque chose de fondamental sur la collaboration avec un agent IA.

L’agent a un biais naturel : il cherche à optimiser, à simplifier, à éliminer les redondances. C’est le biais d’un système entraîné à produire des réponses propres et concises. Face à un dataset riche et multidimensionnel, son premier réflexe est de le réduire à sa plus simple expression.

L’humain, lui, a une intuition différente : il pressent que la redondance structurée est un atout, pas un défaut. Que la diversité des angles sur une même réalité est précisément ce qui permettra, plus tard, une distillation de qualité.

Ce n’est pas que l’agent a tort. C’est que son "optimum" n’est pas le mien. L’agent optimise pour le présent — le contexte immédiat, la réponse rapide à la question posée. L’humain optimise pour le futur — la capacité à retrouver, croiser, distiller dans trois mois ou trois ans.

Cette phrase que je lui ai dite en fin de session résume tout. L’agent est un outil de production. L’humain est l’outil de distillation. La gouvernance n’est pas faite pour que l’agent comprenne tout tout seul — elle est faite pour que l’humain puisse, plus tard, travailler le matériau produit.

La vague froide identique est la traduction architecturale de cette philosophie : on ne jette rien, on ne fusionne rien, on ne réindexe rien. On déplace le paquet intact. La distillation viendra plus tard, à la main, par l’humain.

Si vous avez lu l’article sur la stratégie Eager/Lazy, vous reconnaîtrez la progression naturelle :

Le premier article répondait à la question : « L’agent ne se souvient de rien entre deux sessions, comment lui donner une mémoire ? »

Celui-ci répond à la question qui découle inévitablement de la première : « La mémoire grossit à chaque session, comment l’empêcher d’étouffer l’agent sans l’effacer ? »

La réponse tient en un pattern : Hot/Warm/Cold, appliqué aux fichiers de gouvernance. Et en un principe : ne jamais rien perdre, toujours tout relocaliser.

Un bon système de gouvernance ne supprime jamais de données. Il les range.