Dégradation de la mémoire des agents IA : pourquoi les LLMs s'effondrent en conversation multi-tours

Au bout de quatre-vingt-dix minutes de travail sur mon système de délibération⁹, l’agent ne faisait plus référence à l’architecture qu’il avait lui-même décrite trente minutes plus tôt. Les journaux de session montraient que Claude avait éliminé par compression le graphe de dépendances entre modules pour laisser place aux nouvelles sorties d’outils. L’agent continuait d’écrire du code, mais ce code ne respectait plus les contrats inter-modules établis pendant la première heure. Les tests passaient. L’intégration échouait. L’agent avait oublié sa propre conception.

Cette défaillance m’a coûté une journée entière de débogage. La recherche explique aujourd’hui pourquoi elle s’est produite.

TL;DR

Microsoft Research et Salesforce ont testé 15 LLMs sur plus de 200 000 conversations simulées et mesuré une chute de performance moyenne de 39 % entre l’interaction en un seul tour et l’interaction multi-tours.¹ La dégradation s’amorce dès le deuxième tour. Trois mécanismes indépendants provoquent cet effondrement : la compression du contexte élimine un état critique, la cohérence du raisonnement se fragmente à mesure que le budget de tokens se réduit, et la coordination entre agents se rompt en l’absence de référence partagée. Élargir la fenêtre de contexte n’en corrige aucun. L’approche de la boucle Ralph (contexte neuf à chaque itération, état stocké sur le système de fichiers) contourne la perte par compression, mais introduit ses propres coûts. Ci-dessous : la recherche, les trois mécanismes, des méthodes de détection applicables dès aujourd’hui et un protocole de résilience multi-tours.

Le décrochage des 90 minutes

Mon billet sur le contexte comme architecture⁸ décrivait un système de contexte à sept couches réparti sur 650 fichiers. Le construire a demandé de longues sessions de code pendant lesquelles l’agent devait retenir un état architectural complexe : frontières de modules, chaînes de dépendances, ordre d’exécution des hooks et contrats entre fichiers.

J’ai mesuré la qualité des sessions sur 30 itérations de la boucle Ralph, en janvier et février 2026.⁷ Les données révèlent un schéma constant :

Minutes 0-30:   Precise multi-file edits, correct cross-references
Minutes 30-60:  Occasional missed imports, still recoverable
Minutes 60-90:  Single-file tunnel vision, loses architectural context
Minutes 90+:    Repetitive attempts, contradicts earlier decisions

Le décrochage survenait quel que soit le type de tâche. Longues sessions de refactorisation, construction de suites de tests, passes de documentation : toutes se dégradaient selon la même courbe. Seule la sévérité variait : plus une tâche exigeait d’état réparti entre fichiers, plus la chute était brutale par rapport à un travail isolé sur un seul fichier.

J’ai attribué ce phénomène à la pression sur la fenêtre de contexte et j’ai construit la boucle Ralph pour le contourner : lancer une instance neuve de Claude à chaque itération, injecter l’état depuis le système de fichiers, ne jamais compter sur la mémoire conversationnelle au-delà d’une itération. L’approche fonctionne. Mais l’étude MSR/Salesforce publiée en mai 2025 a montré que le problème est plus structurel que la seule taille de la fenêtre de contexte.

Trois mécanismes de l’effondrement multi-tours

Laban et al. décomposent la dégradation multi-tours en mécanismes indépendants, et la distinction compte : chacun appelle une intervention de nature différente.¹

Mécanisme 1 : la compression du contexte

Toute conversation avec une IA se déroule dans un budget de tokens fini. À mesure qu’elle s’allonge, le système compresse les tours précédents pour faire place au nouveau contenu. Cette compression est destructrice. Les décisions d’architecture consignées au tour 3 peuvent très bien ne pas survivre jusqu’au tour 15.

Je l’ai constaté directement pendant la construction du système de délibération. L’agent avait établi un graphe de dépendances entre modules dans les vingt premières minutes : deliberation_engine.py dépend de consensus_calculator.py, qui dépend de vote_aggregator.py. À la 75e minute, la chaîne de dépendances avait disparu de son contexte et il a écrit un cycle d’imports. Le code était syntaxiquement valide. L’import circulaire a provoqué un plantage à l’exécution.

Détection : suivez dans le temps la proportion de références inter-fichiers dans les sorties de l’agent. Quand il cesse de mentionner des fichiers évoqués plus tôt, la compression a probablement écarté le contexte correspondant.

# Count unique file references per 30-min window in a session log
# Declining count signals compression loss
git log --since="2 hours ago" --pretty=format:"%s" | \
  grep -oP '[a-z_]+\.(py|js|ts)' | sort -u | wc -l

Mécanisme 2 : la perte de cohérence du raisonnement

L’étude MSR/Salesforce montre que la dégradation multi-tours se décompose en deux effets : une légère perte d’aptitude et une forte dégradation de la fiabilité.¹ L’aptitude mesure la capacité du modèle à produire une réponse correcte ; la fiabilité mesure s’il y parvient de façon constante.

En mode mono-tour, les modèles atteignaient environ 90 % de performance moyenne sur six tâches de génération. En mode multi-tours, la performance tombait à 65 % environ, soit 25 points de moins en valeur absolue. Le constat décisif : « lorsque les LLMs prennent une mauvaise direction en conversation multi-tours, ils se perdent et ne s’en remettent pas ».¹

La perte de cohérence se manifeste quand l’agent contredit ses propres décisions antérieures. Non parce que le système a compressé le contexte (mécanisme 1), mais parce que sa chaîne de raisonnement s’est fragmentée d’un tour à l’autre. Le raisonnement de chaque tour est localement solide, mais globalement incohérent.

Les travaux de Du et al. sur le routage cognitif des décisions s’attaquent directement à ce mécanisme.² Inspiré de la théorie des deux systèmes de Kahneman (réponses intuitives rapides contre raisonnement délibéré lent), leur dispositif adapte la profondeur de raisonnement aux exigences de la tâche. L’idée : tous les tours d’un agent ne réclament pas la même profondeur, et en appliquer une uniforme gaspille du budget sur des étapes triviales tout en sous-investissant sur les décisions critiques.

Détection : cherchez les contradictions entre les sorties du début et de la fin de session. Si l’agent défend l’approche A à la 15e minute et l’approche B à la 60e sans jamais signaler le changement, la cohérence s’est dégradée.

Mécanisme 3 : la rupture de coordination

Les systèmes multi-agents ajoutent la rupture de coordination à la dégradation multi-tours. Dès que deux agents ou plus collaborent sur une tâche, le contexte de chacun se dégrade de son côté. Un agent qui a oublié une contrainte partagée ne peut plus l’intégrer à sa coordination avec les autres.

Les Agent Context Protocols de Bhardwaj et al. répondent à ce problème en instaurant des canaux de communication structurés entre agents.³ Leur cadre atteint 28,3 % de précision sur AssistantBench en définissant des protocoles explicites de partage de contexte, de propagation des erreurs et de synchronisation d’état. L’Unified Agent Communication Protocol de Krishnan prolonge l’approche avec des frontières de sécurité zero-trust entre agents.⁴

J’ai rencontré cette rupture lors d’une délibération à dix agents où trois relecteurs évaluaient la même modification de code. Au quatrième tour de relecture, les agents ne s’accordaient plus sur ce qu’était la « version actuelle » du code. Chaque contexte contenait un instantané différent. Leurs relectures se contredisaient non par désaccord, mais parce qu’ils ne relisaient pas le même code.

Détection : dans un flux de travail multi-agents, comparez les hypothèses d’état que chaque agent conserve. S’ils renvoient à des versions différentes du même artefact, la coordination a échoué.

Pourquoi élargir la fenêtre de contexte ne règle rien

La réponse intuitive à la dégradation multi-tours tient en une phrase : « donnez plus de tokens au modèle ». L’étude MSR/Salesforce réfute cette intuition par un dispositif expérimental astucieux.

Les auteurs ont testé une condition « Concat » : présenter l’intégralité de la conversation multi-tours sous la forme d’un seul prompt concaténé. Cette condition atteint 95,1 % de la performance obtenue en un seul tour.¹ Longueur de contexte identique à la condition multi-tours. Contenu informationnel identique. Seule différence : la structure de l’interaction, un tour contre plusieurs.

Les 39 % de dégradation ne sont donc pas un problème de longueur de contexte. Doubler la fenêtre de 200 000 à 400 000 tokens n’y changerait rien, car la dégradation naît des frontières entre les tours, pas d’un manque de place.

Ce résultat rejoint mes données de production. Claude travaille avec environ 200 000 tokens de contexte. Mes mesures de gestion de la fenêtre de contexte montrent que les sessions les plus longues (plus de trois heures, usage intensif des outils) consomment près de 180 000 tokens avant le déclenchement du compactage. Or la qualité chute bien avant que la fenêtre ne soit pleine : le décrochage des 90 minutes survient autour de 60 à 70 % d’utilisation, pas à la limite. La dette cognitive qui en résulte s’accumule dès lors que l’agent produit du code plus vite qu’un développeur ne peut le vérifier. C’est le même problème de contexte composé à une autre échelle : chaque tour ajoute de l’information qui interagit de façon non linéaire avec tout ce qui précède.

Le routage cognitif de Du et al. reformule la question : l’enjeu n’est pas le nombre de tokens que le modèle peut retenir, mais l’efficacité avec laquelle il répartit ses ressources de raisonnement sur ces tokens.² Leur dispositif obtient 34 % de coûts de calcul en moins et 23 % de cohérence en plus en aiguillant les décisions simples vers le raisonnement rapide et les décisions complexes vers le raisonnement délibéré.

La solution du contexte neuf (et ce qu’elle coûte)

La boucle Ralph résout le mécanisme 1 (la compression) et partiellement le mécanisme 2 (la cohérence) en ne laissant jamais une conversation durer assez longtemps pour que l’un ou l’autre se manifeste. Chaque itération lance une instance neuve de Claude avec un contexte complet de 200 000 tokens. L’état persiste sur le système de fichiers, pas dans la mémoire conversationnelle.

# Simplified Ralph loop iteration (from jiro-artisan.sh)
while [ "$stories_remaining" -gt 0 ]; do
  # Orient: inject current state from filesystem
  state=$(cat jiro.state.json)
  progress=$(cat jiro.progress.json)
  git_state=$(git diff --stat HEAD)

  # Spawn fresh context with injected state
  claude --print \
    "State: $state" \
    "Progress: $progress" \
    "Git: $git_state" \
    "Task: implement next story from prd.json"

  # Update filesystem state from agent output
  update_state_from_output
done

Chaque itération dispose du budget de contexte complet. Aucun artefact de compression hérité des tours précédents. Aucun fragment de raisonnement issu des chaînes antérieures. Le système de fichiers tient lieu de mémoire externe : jiro.state.json suit la story en cours, jiro.progress.json consigne le travail achevé d’une itération à l’autre et git diff fournit la vérité de terrain sur ce qui a réellement changé.

Les Recursive Language Models de Zhang, Kraska et Khattab adoptent une approche complémentaire : au lieu de lancer des instances neuves, le modèle décharge le contexte dans un environnement REPL Python et raisonne dessus sous forme de code plutôt que dans l’espace des tokens.⁵ RLM-Qwen3-8B dépasse sa référence de 28,3 % sur les tâches à long contexte en traitant les prompts longs comme des structures de données externes et non comme une mémoire interne. Là où la boucle Ralph externalise l’état vers des fichiers, les RLM l’externalisent vers du code. Les deux approches règlent le même problème de compression par des voies différentes.

Le système Wink de Nanda et al. s’intéresse à ce qui se passe quand la dégradation est déjà installée.⁶ En analysant plus de 10 000 trajectoires d’agents réelles, les auteurs constatent que des comportements déviants (dérive par rapport à la spécification, boucles répétitives, échecs d’appels d’outils) surviennent dans environ 30 % des sessions. Wink observe la trajectoire de l’agent et applique une correction de cap ciblée, résolvant 90 % des cas traitables en une seule intervention. La détection se fait en temps réel : Wink repère les schémas de dégradation dès qu’ils apparaissent, au lieu d’attendre qu’une défaillance se propage dans le code.

Ce que cela coûte

L’itération à contexte neuf n’est pas gratuite. Trois coûts :

1. Le surcoût d’orientation. Chaque itération dépense des tokens à relire un état que la précédente avait déjà assimilé. Mes mesures situent entre 15 et 20 % du budget de tokens la part consacrée à cette étape d’orientation : lecture des fichiers d’état, survol de l’historique git récent, reconstitution d’un contexte suffisant pour reprendre le travail. Une itération de 200 000 tokens démarre donc avec 160 000 à 170 000 tokens réellement exploitables.

2. La perte du savoir implicite. Le contexte conversationnel porte un savoir implicite que l’état sur disque ne capture pas : le raisonnement derrière un choix de conception, les options envisagées puis écartées, la nuance qui a fait préférer l’approche A à l’approche B. L’étape d’orientation injecte des faits (ce qui a changé, ce qui vient ensuite). Le pourquoi, lui, s’évapore entre deux itérations.

3. Le coût de coordination. Si plusieurs boucles Ralph tournent en parallèle (implémentation simultanée de plusieurs stories), chacune maintient son propre état. Les coordonner impose une logique de fusion et une résolution de conflits explicites, là où une longue session unique s’en chargeait implicitement.

Le calcul coût-bénéfice est net : en dessous de 60 minutes, une conversation unique reste plus efficace. Au-delà de 90 minutes, le contexte neuf produit un meilleur résultat malgré le surcoût d’orientation. Le point de bascule dépend de la complexité de la tâche : un état fortement réparti entre fichiers l’avance, un travail isolé sur un seul fichier le recule.

Mesurer la dégradation avant qu’elle ne frappe

Nul besoin d’attendre une panne en production pour détecter la dégradation multi-tours. Trois méthodes, de la plus simple à la plus poussée :

Méthode 1 : surveiller la pression sur le contexte

Suivez l’utilisation du contexte en temps réel. Mon hook context-pressure.sh s’exécute après chaque appel d’outil et alerte dès que l’utilisation dépasse 60 % :

# Simplified context pressure check
context_used=$(wc -c < "$CONVERSATION_LOG" | awk '{print int($1/4)}')
context_max=200000
utilization=$(( context_used * 100 / context_max ))

if [ "$utilization" -gt 60 ]; then
  echo "[WARN] Context at ${utilization}% — quality degradation likely"
fi

if [ "$utilization" -gt 80 ]; then
  echo "[CRITICAL] Context at ${utilization}% — start new session"
fi

Méthode 2 : suivre les références croisées

Comptez le nombre de fichiers distincts que l’agent mentionne dans chaque sortie. Une tendance à la baisse signale une perte par compression :

# Track file reference diversity in recent commits
for commit in $(git log --oneline -5 --format="%H"); do
  files=$(git diff-tree --no-commit-id --name-only -r "$commit" | wc -l)
  echo "$commit: $files files touched"
done

Méthode 3 : détecter les contradictions

Comparez dans le temps les affirmations d’architecture de l’agent. S’il annonce « le module A dépend du module B » à la 20e minute puis « le module A n’a aucune dépendance externe » à la 70e, la cohérence s’est dégradée. Version automatisée : comparez ses instructions EXPLAIN (ou ses commentaires de conception) entre les sorties du début et celles de la fin de session.

Un protocole de résilience multi-tours

Trois niveaux, chacun visant un mécanisme distinct. Commencez par le niveau 1 et ajoutez des couches au besoin.

Niveau 1 : les points de contrôle d’état

Toutes les 30 minutes, sérialisez dans un fichier la compréhension architecturale de l’agent. Pas la conversation entière, mais l’état structurel : quels modules existent, comment ils s’articulent, quelles contraintes s’appliquent.

# Pre-compaction checkpoint (runs before Claude compresses context)
mkdir -p .claude/checkpoints
cat > ".claude/checkpoints/$(date +%s).md" << 'CHECKPOINT'
## Architectural State
- Module graph: [current understanding]
- Active constraints: [list]
- Design decisions made this session: [list with reasoning]
CHECKPOINT

Si le comportement de l’agent se dégrade, repartez du point de contrôle plutôt que de poursuivre avec un contexte abîmé.

Niveau 2 : les itérations à contexte neuf

Au-delà de 60 minutes, basculez sur le principe de la boucle Ralph. Tout se joue à l’étape d’orientation : injecter assez d’état pour que le nouveau contexte reprenne le travail sans relire tout l’historique de la conversation.

État requis pour l’étape d’orientation : 1. La tâche en cours et ses critères d’acceptation 2. Les fichiers modifiés lors de l’itération précédente (via git diff) 3. Les décisions d’architecture et leur justification 4. Les contraintes connues et les modes de défaillance

Niveau 3 : les protocoles de coordination entre agents

Pour les flux de travail multi-agents, instaurez un document d’état partagé que tous les agents lisent et écrivent. Ce document fait office de vérité de terrain et prévient la divergence observée pendant les relectures de délibération.

{
  "version": 7,
  "last_updated": "2026-02-22T14:30:00Z",
  "active_files": ["engine.py", "calculator.py", "aggregator.py"],
  "constraints": [
    "No circular imports between modules",
    "All public functions require type annotations"
  ],
  "decisions": [
    {"decision": "Use RRF for vote aggregation", "reasoning": "Handles rank-only data", "turn": 3}
  ]
}

Chaque agent lit ce document au début de son tour et le met à jour à la fin. Un conflit déclenche une pause de coordination au lieu d’une divergence silencieuse. Les meilleurs agents fonctionnent ainsi, sans se faire remarquer : comme je l’explore dans L’agent invisible, l’objectif est une infrastructure qui travaille sans que le développeur la remarque.

À retenir

• La dégradation multi-tours est structurelle, ce n’est pas un problème de longueur de contexte. L’étude MSR/Salesforce mesure 39 % de dégradation à longueur de contexte constante. Ce sont les frontières entre les tours, pas les limites de tokens, qui provoquent l’effondrement.¹
• Trois mécanismes indépendants appellent trois interventions différentes. La perte par compression demande des points de contrôle d’état. La perte de cohérence demande des itérations à contexte neuf. La rupture de coordination demande des protocoles d’état partagé.
• Le décrochage des 90 minutes est réel et mesurable. Surveillez l’utilisation du contexte, la diversité des références croisées et les contradictions d’architecture pour repérer la dégradation avant qu’elle ne se traduise par des pannes en production.
• L’itération à contexte neuf fonctionne, au prix de 15 à 20 % de surcoût. La boucle Ralph échange ce coût d’orientation contre un budget de contexte entier à chaque itération. L’arbitrage penche en faveur du contexte neuf au-delà de 60 à 90 minutes.
• L’allocation adaptative du raisonnement bat la profondeur uniforme. Le routage cognitif de Du et al. obtient 34 % de coûts en moins et 23 % de cohérence en plus en ajustant la profondeur de raisonnement aux exigences de la tâche.²

FAQ

Références