Survivre au pliage : une échelle pour les sessions d’agents à long terme et la compactation

Les alpinistes ne transportent pas tout l’équipement nécessaire pour l’ascension ; ils le cachent. Une longue montée est divisée en différents camps, chacun étant approvisionné en fonction des besoins de l’étape suivante. Tout ce qui n’est pas nécessaire reste en bas, disponible en cas de retour, mais ne sera jamais transporté plus haut. Ce qui parvient au sommet, c’est ce qui a survécu à la décision de chaque camp quant aux éléments à laisser derrière.

Une fenêtre de contexte fonctionne de la même manière. Sa capacité est fixe, mais le parcours ne l’est pas, et tôt ou tard, il faudra laisser quelque chose derrière.

Le stockage provisoire des prompts a déjà donné une règle pour les systèmes d’assistance aux agents : ne jamais invalider le cache. Conserver la partie stable au chaud et reporter les modifications à la fin. Cependant, cette règle traite une session comme une photographie statique, alors que les sessions possèdent une dimension temporelle. Chaque session vieillit. La conversation s’allonge jusqu’à ce que la fenêtre soit pleine et doive être pliée.

Un pli réduit la taille de la fenêtre ; c’est un aspect mécanique. Le coût est moins évident, car le pliage force l’invalidation du cache. Il est payé une seule fois, ce qui reste est réécrit, et la session se poursuit. Néanmoins, l’invalidation n’est qu’un problème secondaire. Ce qui compte vraiment, c’est le choix de ce qui sera conservé. Une bonne compression ne consiste pas seulement en suppression : elle condense une histoire sous une forme permettant à l’agent de continuer. De plus, une session longue ne se plie qu’une seule fois. Elle se plie, fonctionne, se plie à nouveau, et tôt ou tard se plie encore une fois.

Cela redéfinit la question de planification. Se demander quand effectuer la compression importe moins que de savoir ce qui reste après plusieurs tours de pliage, et ce qui a été perdu d’ici là. Le moment opportun relève d’une question de coût, car chaque invalidation est facturée. La qualité de compression relève d’une question d’identité, car elle détermine si la session qui suit est bien celle qui a commencé. Pour ces deux raisons, la compression doit figurer en haut de la hiérarchie, et non en bas.

Où s’accumulent les frais

Chaque requête se divise en deux zones de facturation. L’une est le préfixe, qui reste inchangé d’un tour à l’autre. L’autre est la partie finale, qui continue de croître.

Le préfixe contient l’invite système, les définitions des outils, le contexte du dépôt stable ainsi que les fichiers de règles. Il est écrit une seule fois, mémorisé en cache, puis lu ultérieurement pour un petit pourcentage du prix initial. Sa taille reste constante.

La partie suivante se compose uniquement de dialogues, d’appels d’outils, de leurs résultats, de blocs de réflexion et de différences. Elle ne cesse de s’agrandir.

Cependant, c’est l’agrandissement lui-même qui ne pose pas de problème. Ce qui est problématique, c’est la recharge répétée. Un nouveau message n’est pas envoyé seul : le système envoie à nouveau le préfixe correspondant, paie le tarif de lecture en mémoire pour celui-ci, ainsi que le supplément de écriture pour le nouveau contenu, et toute cette partie est transmise lors de chacune de ces lectures. Ainsi, 150 000 tokens de cette partie supplémentaire ne constituent pas un montant inactif restant dans la fenêtre de stockage ; il est facturé à nouveau à chaque étape, que le modèle en ait besoin ou non pour la question suivante. L’historique ancien est en fait loué pour toute la durée de la session.

Dans une fenêtre de 200 000 tokens, une grande partie de cet espace est déjà occupée. En fonction du système utilisé et de plusieurs autres facteurs, la quantité réellement disponible pour travailler peut diminuer pour se situer entre 7 500 et environ 15 000 tokens.

Les caches expirent également. La mise à jour des activités réinitialise la durée de vie du cache, ce qui signifie qu’une pause peut transformer l’opération suivante en écriture « froide ». Le temps passé par une personne à réfléchir représente une dépense cachée liée au cache que personne ne mentionne.

Vu sous cet angle, la compression de la partie finale du cache constitue aussi une opération sur ce dernier. Un coût unique d’invalidation est échangé contre la fin du paiement continu lié à l’utilisation du cache. Telle est l’ensemble de l’accord, et il existe des moyens moins coûteux d’agir avant de recourir à cette solution.

Une échelle de cinq étapes

Il existe cinq moyens pour lutter contre la croissance de cette partie finale du cache. Ce ne sont pas autant d’alternatives que de barreaux d’échelle : plus on monte haut, plus l’historique existant est perturbé.

Étape un : ne le générer jamais. Limitez la sortie au niveau de l’outil. L’éditeur de texte d’Anthropic prend en charge max_characters et sa recherche en ligne prend en charge max_uses. Codex limite par défaut les sorties des différents outils à environ 10 000 à 16 000 tokens avant qu’elles ne soient prises en compte dans le calcul de compression. Une approche plus rigoureuse consiste à couper le texte : conserver le début et la fin, supprimer le milieu, en partant du principe que la manière dont une commande commence et où elle se termine est plus importante que le contenu intermédiaire. Le défaut de cette méthode est de tronquer le texte avant même de savoir ce qui est important, et un historique d’erreurs manquant des frames pertinents est pire que rien du tout.

Deuxième étape : conserver l’artefact. Si l’ensemble de l’observation n’est pas nécessaire, ne la conservez pas. Lorsqu’un résultat obtenu à l’aide d’un outil dépasse un seuil de taille, le système l’enregistre sur disque et y laisse une référence. L’artefact complet reste intact, tandis que le contexte en temps réel disparaît. Cela diffère de la troncature, car rien n’est éliminé. Un journal de compilation de 500 000 lignes peut rester sur disque, tandis que le contexte ne contient que son chemin, des métadonnées ou un index recherchable ; un outil de recherche ou de lecture natif récupère ensuite uniquement la partie pertinente. Conservez l’artefact, supprimez l’observation. Cela sépare clairement le stockage du contexte, permettant ainsi aux informations de rester durables sans engendrer de surcoûts ultérieurement.

Le problème, c’est que le système de gestion doit permettre de le retrouver. Le stockage temporaire ne sert à rien si l’agent ne peut pas rechercher ce qui a été enregistré, le lire et en comprendre le sens ; sans cela, l’excès de contexte se transforme en un système de fichiers rempli d’éléments irrécupérables.

On note une convergence notable entre ces systèmes de gestion. Claude Code enregistre sur disque tout résultat de outil dépassant environ 100 k et fournit une vue préliminaire ainsi qu’un chemin d’accès, tandis qu’Hermes applique également une limite de 100 k par résultat. Les deux prévoient la même exception pour l’outil de lecture, car une lecture temporaire génère un chemin que l’agent ne lira que rarement, tandis qu’une lecture temporaire menant à un chemin déjà lu entraîne une nouvelle écriture temporaire, indéfiniment. Il est facile de tomber dans de tels cercles vicieux. L’unique outil dont la fonction est de récupérer du contenu est celui qui ne doit absolument pas effectuer de stockage temporaire.

Étape trois : empêcher l’accès. Confiez la tâche à un sous-agent. Équipé des outils intégrés au harnais, il peut lire des fichiers, examiner les journaux et analyser le répertoire, accumulant ainsi un vaste contexte privé, sans que rien de tout cela ne parvienne au processus principal. Une fois la tâche terminée, sa fenêtre est supprimée et seul la valeur de retour est transmise. Les fournisseurs de harnais ont fait de cette fonctionnalité l’une des plus largement déployées cette année.

Il existe une limite, car explorer est plus sûr que de modifier des choses. Un agent qui lit les fichiers incorrects se contente de provoquer une nouvelle exécution. Un agent qui modifie les fichiers erronés laisse des dommages une fois son contexte terminé, il est donc essentiel de savoir quel modèle doit être chargé des modifications. Les anciennes armées l’illustrent bien : les éclaireurs étaient des personnes rapides et remplaçables envoyées en avant, car observer coûte peu et le rapport peut être vérifié, tandis que les actions vraiment décisives étaient confiées aux meilleurs commandants, car elles ne peuvent être annulées. La même distinction s’applique ici. Confiez la reconnaissance à un contexte peu coûteux et éphémère, réservez le modèle le plus puissant pour l’étape qui modifie le monde, et faites en sorte que le parent participe à la vérification. Le parent paie pour la réponse et non pour l’enquête.

Étape quatre : remplacez-le par un pointeur. Si le contenu est déjà stocké de manière durable, que ce soit sous forme de fichier, d’artefact, de rapport généré ou de résultat obtenu, la conversation n’a besoin que d’une référence à celui-ci. Relire signifie se rendre là où se trouve le matériel, plutôt que de le transporter avec soi. L’outil de mémoire d’Anthropic fait précisément cela, et OpenAI permet un comportement similaire grâce à l’appel de fonctions. Un état de conversation coûteux devient ainsi une référence peu coûteuse vers un état durable. Une précaution s’impose : les économies ne durent que tant que le contenu de base reste en dehors de la fenêtre de visionnage. Une fois relu, il redevient du contenu temporaire et commence immédiatement à générer des coûts.

Étape cinq : la supprimer par la suite. Nettoyer, compresser ou plier. Seule cette étape annule ce qui est déjà en mémoire tampon. Une manche est consacrée à échanger l’historique accumulé contre quelque chose de plus petit, dans l’espoir que la manche suivante puisse partir de là. Le texte complet peut rester sur le disque, mais le contexte en temps réel est différent.

À partir de là, l’aspect économique devient une mise. Le loyer évité pour le reste de la session dépasse-t-il le coût actuel de réécriture de l’historique ? Compresser tôt signifie jeter une mémoire tampon utile qui aurait pu servir des centaines de manches peu coûteuses. Compresser tard signifie que le loyer a déjà été payé pour une montagne d’historique, au cours de laquelle le modèle a peut-être déjà perdu en efficacité pour l’utiliser. La plupart des discussions sur les sessions longues commencent par cette question, ce qui n’est pas approprié. Les cinq étapes dans l’ordre :

1. Ne jamais le générer : arrêter la croissance de la queue à la source.
2. Le révéler : retirer l’observation volumineuse et conserver l’artefact.
3. Le garder caché : envoyer l’enquête dans un contexte différent.
4. Y faire allusion : laisser une référence peu coûteuse dans la conversation.
5. Le supprimer plus tard : le compresser ou le plier, et vivre avec cette perte.

Le contexte le moins cher n’est pas un contexte compressé. C’est un contexte qui n’a jamais eu besoin d’exister.

Les ensembles d’outils comme pari sur l’endroit où payer

Le lieu où se trouve la définition d’un outil est important. Les définitions occupent le préfixe, un coût fixe qui est écrit une fois et mémorisé. Les résultats occupent la partie finale, un coût variable qui doit être payé continuellement. Choisir un ensemble d’outils revient donc à parier sur quelle zone devrait absorber le coût de l’information. Peu d’outils signifient un préfixe réduit mais plus d’observations brutes à la fin ; de nombreux outils signifient des tokens de préfixe supplémentaires dépensés pour obtenir des observations plus petites et mieux structurées.

Terminus 2 représente l’extrême de la simplicité : un terminal sans tête, fondé sur la conviction Unix selon laquelle un outil général peut être composé sans limite. Codex est souvent regroupé avec lui, ce qui n’est que partiellement justifié. Son préfixe natif n’est pas du tout minuscule, comprenant une vingtaine d’outils présents en permanence, une suite multi-agents ainsi qu’une paire v1/v2. Il évite l’encombrement grâce au report, en indexant les outils MCP et de connexion dans un moteur de recherche et en les chargeant uniquement lorsque c’est nécessaire. Codex mise véritablement sur la partie minimale du système. apply_patch illustre bien cela, puisqu’un bref diff remplace des milliers de tokens de fichiers réécrits, et des limites imposées à la sortie de chaque outil empêchent l’accumulation d’observations brutes. Les deux approches aboutissent à des résultats similaires par des voies différentes : Terminus 2 maintient le préfixe petit, tandis que Codex maintient la partie finale petite.

Claude Code et Hermes consacrent davantage de préfixes à des outils spécialisés qui renvoient des observations structurées plutôt que des données brutes. Le catalogue de Claude Code dépasse 40 lorsque l’on prend en compte LSP, le mode plan, les worktrees et cron, tandis que Hermes atteint environ 55, regroupés en ensembles d’outils pour le terminal, les fichiers, la mémoire, les compétences, la délégation et bien d’autres domaines. Le schéma récurrent est celui de Grep, qui renvoie les résultats correspondants plutôt que tout le fichier : un préfixe légèrement plus important afin d’éviter des milliers de tokens de contenu non pertinent à la fin.

La comparaison à effectuer ne concerne donc pas le nombre d’outils. Il s’agit de savoir si les dépenses supplémentaires en préfixes suffisent à réduire suffisamment la croissance des données en fin de traitement pour retarder le pliement. Il s’agit du même compromis entre anticipation et approche juste-à-temps, appliqué à un niveau supérieur. Anthropic l’exprime clairement dans son chargement différé : les définitions d’outils peuvent être découvertes lorsque c’est nécessaire plutôt que d’être incluses à chaque demande. Claude Code utilise un mécanisme ToolSearch qui laisse visibles les noms des outils différés et retient les schémas complets jusqu’à ce que le modèle le demande, s’activant automatiquement lorsque les définitions d’outils MCP représentent environ 10 % de la fenêtre de contexte. Même l’ordre est choisi pour protéger le préfixe, car le tri alphabétique maintient le bloc de définition identique en termes de taille en bytes entre les différentes interactions, ce qui le rend cacheable. Le préfixe est conçu pour rester actif, quel que soit son taille.

L’axe conserve son utilité, mais son rôle change. Il ne décide pas s’il faut compresser les données. Il détermine plutôt dans quelle mesure l’historique s’accumule en premier. Or cet historique n’est pas homogène. Les résultats de recherche peuvent souvent être dérivés à nouveau, mais les décisions, non. Un chemin de fichier peut être reconstitué, tandis que la raison pour laquelle une approche a été rejetée ne l’est pas nécessairement. Plus une session dure, plus il devient coûteux de confondre ces deux types de mémoire.

La délégation en tant que limite de mémoire

La délégation se distingue par le fait qu’elle permet d’éliminer l’historique tout en laissant le cache du parent intact, ce qui vaut plus qu’une simple réduction des coûts de traitement. Un sous-agent dispose de sa propre fenêtre de contexte. Il peut développer une longue série d’opérations, remplir cette fenêtre, se compresser internement puis disparaître, sans avoir à réécrire un seul mot de l’historique du parent.

Une hypothèse courante doit être ajustée. Il est tentant d’imaginer une bifurcation du même modèle, où un enfant hérite de la queue accumulée par son parent ainsi que de son préfixe correspondant. Les implementations que l’on peut tester ne font généralement pas cela. Claude Code, OpenCode, Codex et Hermes lancent chacun un contexte de travail distinct, et non une copie de toute la queue du parent. Certains permettent de faire fonctionner le travailleur sur un modèle différent : Codex applique une modification de modèle au moment du démarrage, tandis que Claude Code laisse à chaque sous-agent le choix entre sonnet, opus ou haiku. Cela n’est pas universel, et le délégué d’Hermes ne dispose d’aucun moyen direct pour changer de modèle. Ce qui est transmis entre les différents systèmes, c’est le contexte séparé, et non le choix du modèle.

Cela indique quelque chose de plus important que la simple création de branches. La « queue » de l’agent enfant peut être éliminée : il peut lire quarante fichiers, analyser les journaux et définir une convention de nommage, et tout le contexte disparaît tandis qu’un paragraphe réapparaît. La délégation agit comme une frontière mémoire. Le parent assigne une tâche et précise ce dont elle a besoin, ce qui revient à effectuer une compression à l’avance, car l’agent exécutant sait qui lira son résultat et quelle décision ce résultat doit soutenir. Lorsque l’agent secondaire revient, le parent vérifie généralement le résultat. Le faire nécessite quelques étapes supplémentaires, mais c’est une pratique judicieuse.

La compactation s’effectue à l’inverse, a posteriori. Elle doit résumer pour un lecteur qui n’existe pas encore, en se prémunissant contre toute question éventuelle. La compression préalable présente l’avantage d’avoir un lecteur connu. Cela donne naissance à un principe de budgétisation : budgétiser pour ce qui sera restitué, et non pour le processus lui-même. Un agent peut dépenser des centaines de milliers de tokens sans que aucun d’eux ne devienne de la mémoire parente. Le texte restitué, en revanche, devient bien de la mémoire. Quatre cents tokens de réponse se retrouvent dans la partie finale de la mémoire parente et sont facturés à chaque tour suivant ; ainsi, au cours d’une session longue, une différence brute peut coûter plus cher qu’un agent coûteux qui ne restitue qu’une seule phrase utile. L’enquête est temporaire et la réponse fait partie de l’histoire, et cette réponse devra à son tour survivre à une opération de pliage.

Ce que proposent les plateformes

La plateforme du modèle détermine quelle partie de ce mécanisme le système doit construire lui-même.

Anthropic propose deux types d’aide destinés à des problèmes différents. Le premier, clear_tool_uses_20250919, est précis. Lorsque la requête dépasse un seuil (100 000 tokens d’entrée par défaut, avec les trois dernières utilisations d’outil conservées), il supprime les anciens résultats des outils sur le serveur et remplace chaque résultat par un marqueur temporaire. Son option clear_at_least répartit le coût de suppression en exigeant que soit effacé un montant minimum. Le second, compact_20260112, est une solution plus lourde : il s’agit d’une synthèse complète du côté serveur qui génère une nouvelle version de la conversation, plutôt que de simplement modifier celle existante.

Claude Code constitue un bon exemple d’étude, car même le harnais développé par l’entreprise qui fournit ces primitives semble coordonner son /compact plus lourd de son côté. Ce fonctionnement provient du reverse engineering mené par la communauté, qui remonte à une seule source GitHub publique, et non de la documentation publique d’Anthropic. Le nettoyage léger a lieu sur le serveur, tandis que la décision quant à l’état de conversation à conserver est gérée par le client.

OpenAI se concentre sur la compression. Son point de terminaison /v1/responses/compact renvoie un bloc opaque chiffré que le client renvoie tel quel sans l’analyser, en partie pour bloquer une méthode d’injection de commandes par le biais d’un résumé altéré pouvant influencer les étapes suivantes. Rien dans ce système ne correspond à un nettoyage précis, ce qui oblige Codex à gérer lui-même la taille du résultat généré par l’outil ; de plus, il existe une solution de secours rudimentaire : si la mémoire reste insuffisante, Codex élimine l’élément historique le plus ancien et tente à nouveau.

DeepSeek offre une gestion du contexte bien moins efficace. Son mécanisme de mise en cache des préfixes du côté serveur réduit les coûts, mais ne résout pas le problème de la fenêtre de traitement fixe ; par conséquent, tout outil utilisé doit gérer l’intégralité du processus de compression. L’outil officiel DeepSeek en crée un sans endommager quoi que ce soit : les événements enregistrés restent dans le journal et peuvent être consultés. Une interface de terminal de tiers testée évite ce travail et ne procède jamais à une compression proactive.

Ce qui importe, ce n’est pas la qualité de l’endpoint de compression d’une API en particulier, mais plutôt qui est responsable de décider ce qui doit être conservé. Hermes constitue un cas limite révélateur, car il fait appel à plusieurs fournisseurs et ne peut pas supposer que l’un d’eux propose les primitives adéquates. Il met donc en œuvre son propre compresseur côté client en tant que référence, en utilisant deux seuils : 50 % selon son propre système de comptage des tokens, et 85 % selon une vérification plus grossière au niveau du gateway, qui permet de détecter les sessions qui s’allongent entre les interactions sans que personne ne les surveille. Chaque fois que le fournisseur actif dispose d’une méthode meilleure, il reporte l’opération.

Telle est la bonne approche générale. Le système de gestion doit gérer la compression par défaut, car il dispose d’informations que le serveur ne pourra jamais voir, et il doit la transmettre à la plateforme lorsque celle-ci le mérite. Peu importe qui effectue la compression, la question reste la même : qu’est-ce qui peut être accepté comme oublié ?

Retour au camp

Tout ce qui a été mentionné ci-dessus part du principe que la session ne s’arrête jamais. Or, les sessions s’arrêtent bel et bien : les ordinateurs portables se ferment, les processus s’arrêtent, les tâches CI se terminent, et quelqu’un tape /resume dans l’espoir de reprendre là où tout s’était arrêté.

C’est la commande la plus simple à utiliser, mais elle entraîne le coût le plus élevé pour reprendre une session. Elle compte sept caractères, y compris le slash, ressemble à /help ou /clear, ne nécessite aucun argument, aucune confirmation et ne présente aucune difficulté. Rien dans sa structure ne trahit son coût, et l’interface est conçue de telle manière que reprendre la session semble gratuit.

La conversation peut être restaurée, mais pas le cache. Une session reprise n’est pas un processus simplement mis en pause. Le système réexécute le texte enregistré sur le disque et reconstruit l’historique des messages, de sorte que le dialogue est récupéré depuis le stockage, tandis que le préfixe temporaire ne l’est pas. Deux coûts de récupération différents en résultent.

Le premier facteur est l’argent. Le cache de préfixes d’Anthropic dure par défaut cinq minutes, ou une heure si l’option de sauvegarde plus importante a été achetée, et seuls les activités le mettent à jour. Une pause correspond à un temps d’inactivité poussé à son extrême, une période durant laquelle aucun processus n’existe du tout. Le préfixe qui était auparavant peu coûteux redevient instantanément cher, et le tour suivant oblige à payer le prix plein pour le reconstruire. Le cas le plus coûteux concerne la reprise d’une session qui a duré des jours, ce qui constitue une bonne raison de gérer les sessions avec prudence.

Le deuxième élément est l’information. Lorsque la transcription est plus longue que la fenêtre disponible, le système peut devoir la compresser avant que toute nouvelle action ne soit effectuée. Il s’agit d’une compression particulièrement risquée, car elle a lieu avant que quiconque ait pu déterminer ce qui est important. Une contrainte qui expliquait un choix effectué auparavant peut être présente dans la transcription mais absente de la version compressée. L’agent reprend son travail avec une fenêtre plus petite et un historique crédible, qui n’est pas nécessairement celui qui rendait les décisions précédentes sensées.

Tout ce qui survit à un pliage survit également à une reprise, et c’est là l’argument le plus solide en faveur d’un état durable. Les règles situées à la racine du projet peuvent être réinjectées depuis le disque, les fichiers peuvent être relus, une liste de tâches peut être reconstruite, et un journal de compilation généré peut être stocké et consulté. Une décision qui n’existe que dans la conversation n’a aucune source extérieure. Si elle a seulement persisté parce que la transcription la contenait, elle doit être réintroduite à chaque retour, et si le pliage l’a supprimée, elle peut disparaître définitivement.

Ainsi, le classement tient compte à la fois de la durabilité et du coût. De la plus solide à la plus fragile : l’état qui peut être reconstruit, l’état externe durable, l’état de conversation en temps réel, puis les observations transitoires. Plus un élément se trouve bas dans le classement, plus il est exposé à un pliage.

Deux manières dont le pliage échoue

La pliure échoue de deux manières. Le cas critique est facile à repérer : la compression fonctionne, puis une grande quantité de données remplit immédiatement la fenêtre, la sangle se compresse à nouveau, les mêmes données réapparaissent, et le cycle se répète, comme si l’on vidait un bateau tout en y creusant un trou. Claude Code cesse de tenter des réessais au lieu de consommer inutilement des appels en boucle, grâce à une logique intégrée capable de détecter qu’il est bloqué et ne progresse pas. C’est le comportement correct, mais la boucle elle-même est un signe que l’étape appropriée n’est pas utilisée. Idéalement, l’agent revient en arrière et essaie une autre approche plutôt que de réessayer la même fonction native. Si un seul fichier de grande taille force constamment la compression, une limite plus basse ne constitue pas la solution ; il faudrait plutôt lire uniquement une petite partie des lignes, effectuer des recherches dans une portée limitée, cibler des données stables, ou confier le fichier à un sous-agent dont la fenêtre peut être remplacée. Chaque fois que la mise au point de la compression commence, demandez-vous si la solution se trouve un niveau plus élevé ou dans une approche complètement différente.

L’échec progressif est plus subtil. La compression perd des informations, et les sessions longues ne se compressent jamais qu’une seule fois. Elles se compressent, fonctionnent, se compressent à nouveau, fonctionnent encore, se compressent encore : des résumés empilés sur d’autres résumés.

Plis sur plis

Un premier niveau de synthèse peut être excellent et conduire néanmoins à un troisième niveau médiocre. Le deuxième résuméur ne voit jamais l’historique original, seulement la représentation choisie par le premier résuméur. Le troisième ne voit ni l’un ni l’autre, seulement le jugement du deuxième concernant le jugement du premier. Observez ce que cela fait aux faits par rapport aux raisons. Le premier niveau de synthèse pourrait conserver « L’approche B a été choisie ». Le deuxième pourrait conserver « B est l’implémentation actuelle ». Le troisième pourrait conserver « L’implémentation utilise B ». Chacun de ces éléments est vrai, mais la raison pour laquelle l’approche A a été rejetée a disparu. Le système n’a pas perdu la décision ; il a perdu ce qui rendait cette décision compréhensible, et c’est là le dommage particulier causé par les niveaux successifs de synthèse.

Qu’est-ce qui doit être conservé

Dans différents systèmes, les résumés structurés convergent vers à peu près les mêmes catégories :

• Intention : qu’est-ce qui est accompli ?
• État : qu’a été appris ou modifié ?
• Travail et tâches en cours : quoi a été fait et quoi reste-t-il à faire ?
• Points en suspens : quelles questions restent sans réponse, non résolues ou en cours d’évaluation ?

Les étiquettes varient d’un outil à l’autre, mais la structure est similaire, ce qui suggère qu’elle correspond à l’état pratique minimal que une session doit conserver. Plusieurs outils ajoutent également des étapes de restauration de fichiers afin que l’ensemble des données en cours de travail puisse être rechargé après un pliement.