Se souvenir de chaque conversation est‑ce vraiment une bonne conception ?

Il y a une question sur laquelle j'ai passé bien plus de temps que prévu en construisant DoDone : comment faire remonter le contexte d'une conversation dans la fenêtre de chat. Quand on crée un produit d'agents IA, il est facile d'y penser de façon simpliste au départ. Ne pourrait‑on pas simplement mettre chaque message précédent dans le contexte ?

Les fenêtres de contexte des modèles n'arrêtent pas de croître. Des centaines de milliers de jetons, et maintenant des modèles qui supportent un million. On en déduit donc qu'il vaut mieux fournir au modèle autant de la conversation de l'utilisateur que possible. Mais la conclusion à laquelle je suis arrivé en construisant DoDone était un peu différente.

La mémoire d'une IA n'est pas tant une question de quantité que de décider ce qu'elle doit retenir maintenant.

La façon la plus intuitive de gérer les longues conversations

Des agents comme Claude Code et Hermes utilisent une technique appelée compactage pour maintenir des tâches longues. Anthropic décrit aussi le compactage comme une méthode centrale pour gérer le contexte dans des agents de longue durée. Quand une conversation s'allonge, au lieu de garder chaque ancien message, on résume ce qui compte et on construit un contexte frais à côté des échanges récents. Claude Code compresse de la même façon les anciens messages et travaux tout en préservant les décisions de conception clés, les problèmes ouverts et les détails d'implémentation.

L'implémentation d'Hermes est plus concrète. Elle ne compacte pas en fonction du nombre de messages mais d'un budget de jetons. Quand les jetons réellement utilisés dans l'appel API courant atteignent une fraction définie de la fenêtre de contexte, le compactage se déclenche automatiquement. Le seuil par défaut est de 50 %, et pour les modèles avec des fenêtres inférieures à 512K il est relevé à au moins 75 % pour éviter de compacter trop tôt. Certains messages récents sont conservés tels quels tandis que la partie médiane est résumée.

C'est une structure très raisonnable. Elle convient particulièrement bien quand un seul objectif dure longtemps — une tâche de code, un fil de recherche. Mais DoDone avait un problème légèrement différent.

Pourquoi DoDone ne se contente pas de transmettre l'intégralité de la conversation.

DoDone est un bureau virtuel où des collègues IA travaillent. Il ne s'agit pas seulement d'une IA et d'un sujet approfondi pendant des heures. Un utilisateur peut parler au collègue marketing, puis confier du travail au développeur, tenir une réunion dans un canal de projet, puis transmettre un suivi à un collègue précis — et revenir chercher ce collègue un jour plus tard.

Autrement dit, le chat dans DoDone n'est pas juste une fenêtre de conversation. C'est l'interface où le travail se fait. Cette différence a changé la conception du contexte. Si vous continuez à renvoyer chaque message passé au modèle au fur et à mesure que la conversation grandit, vous pouvez vous souvenir de beaucoup de choses — mais trois problèmes apparaissent en même temps.

La première, c'est le coût. Un LLM relit le contexte à chaque requête. Plus la conversation est longue, plus vous renvoyez les mêmes messages encore et encore. Surtout avec des modèles à très grandes fenêtres : si la compaction intervient tard, le coût d'une session entière peut augmenter fortement. Même chez Hermes, on discute du fait qu'avec un modèle 1M et le seuil par défaut de 50 %, la première compaction pourrait ne pas se déclencher avant 500K tokens.

La deuxième, c'est la vitesse. Plus de tokens d'entrée signifient plus d'informations à traiter pour le modèle. Inutile de lui faire relire des conversations d'il y a des semaines qui n'ont rien à voir avec la question actuelle.

Mais celui que j'ai le plus retenu était le troisième : la pollution du contexte.

Plus de contexte n'est pas toujours mieux

En expliquant l'ingénierie du contexte, Anthropic souligne que la pertinence et la pollution du contexte restent des problèmes même avec des contextes longs. C'est un point important. Une fenêtre d'un million de jetons ne signifie pas que la remplir à ras bord est l'état optimal.

Supposons qu'un utilisateur ait eu cette série d'échanges avec le collègue marketing. La semaine dernière, le branding d'un nouveau service. Il y a quelques jours, des textes pour Instagram. Hier, la politique tarifaire du produit. Et aujourd'hui, il demande un communiqué de presse. Techniquement, vous pouvez tout transmettre au modèle. Mais si le travail d'aujourd'hui est un communiqué, est‑ce que ramener mot à mot les allers‑retours d'édition d'un texte Instagram d'il y a des semaines aide vraiment ? Ça crée juste de la place pour des informations sans rapport avec la tâche courante qui influencent le jugement du modèle.

Dès le départ, DoDone s'est moins soucié de « combien de conversation inclure » que de « à quel point une conversation récente doit‑elle être conservée intégralement ».

L'approche de DoDone — le récent en nette clarté, l'ancien compressé

Aujourd'hui, DoDone conserve les 8 tâches les plus récentes comme contexte détaillé. Une conversation entre collègues utilise un budget de contexte détaillé d'environ 20K caractères, et le canal principal environ 16K. Jusqu'aux 8 dernières tâches, les détails sont conservés aussi intacts que possible ; tout ce qui est plus ancien est compressé dans un résumé déroulant qui porte le contexte antérieur.

Simplifié, la structure est la suivante : les tâches passées 1–12 deviennent un résumé roulant, les tâches récentes 13–20 restent en contexte détaillé, et ce que vous faites maintenant est la mission en cours.

L'essentiel, c'est que les anciennes conversations ne sont pas supprimées : leur résolution est diminuée. Les tours récents sont mémorisés en haute résolution, les plus anciens en basse résolution. Je pense que c'est assez proche du fonctionnement de la mémoire humaine. Nous ne nous rappelons pas mot à mot d'une conversation d'il y a une semaine. Mais le contexte important reste : « nous avons fixé le prix à $29 sur ce projet », « nous avons choisi les solopreneurs comme clientèle cible », « la tâche suivante était de construire la landing page ». J'estime que les longues conversations avec l'IA paraissent plus naturelles en gardant cette structure.

Mais les résumés ont aussi leurs limites

Bien sûr, un résumé roulant n'est pas une panacée. Un résumé, c'est une compression, et plus vous compressez, plus vous perdez inévitablement de détails. Et une fois que 20, 30 ou 50 tâches s'entassent dans une seule conversation, un autre problème apparaît : il devient flou de savoir si l'utilisateur est même toujours en train de faire la même chose.

Vous pouvez commencer en discutant de stratégie marketing, construire une page d'accueil entre‑temps, parler recrutement après, puis revenir à la création de contenu. Techniquement, tout peut rester connecté dans une seule session. Mais « techniquement possible » et « bonne expérience utilisateur » sont deux choses différentes. C'est pourquoi DoDone a récemment ajouté un petit mécanisme amusant.

L'IA est la première à dire : « Essayez de démarrer une nouvelle conversation »

Quand les missions de la session en cours atteignent 20, DoDone avertit l'utilisateur en premier. C'est le moment où les 8 récentes détaillées plus environ 12 intégrées dans le résumé déroulant se sont accumulées. À cet instant, ce message apparaît :

“💡 Cette conversation est devenue assez longue. Si le sujet a changé, je vous suggère de démarrer une nouvelle session : les réponses seront plus précises et les coûts liés à l'IA diminueront. Si vous continuez, le fil antérieur est quand même conservé sous forme de résumé.”

L'important, c'est que cela ne force jamais la fin de la session. Si vous continuez sur le même projet, poursuivez simplement. Mais si le sujet a déjà changé, commencer une nouvelle session est largement préférable — et même dans ce cas, le flux antérieur dont vous avez besoin est transmis via le contexte résumé. Au final, le choix appartient à l'utilisateur.

Le choix de l'endroit où afficher cette notification avait aussi son importance.

Je n'ai pas jugé suffisant de déclencher l'alerte de longue conversation uniquement par le nombre de messages. DoDone le vérifie à deux endroits.

Le premier instant, c'est l'arrivée d'une instruction de tâche. Qu'elle provienne d'une conversation 1:1 avec un collègue, du canal principal, du canal all-hands, d'un compte‑rendu de réunion ou d'un projet, la longueur de la session est vérifiée de manière asynchrone juste après la réception de l'instruction. Si la condition est remplie, l'avertissement apparaît naturellement sous l'instruction que vous venez d'envoyer.

Le second instant, c'est quand l'utilisateur entre dans un canal. Quand vous cliquez sur un collègue dans l'office pour ouvrir un chat, ou que vous accédez à un canal de projet, l'état de la session en cours est vérifié. S'il est déjà assez long, vous pouvez voir l'avertissement avant même d'envoyer un nouveau message. Et au sein d'une même session, on ne vous le signale qu'une seule fois ; démarrer une nouvelle session remet l'éligibilité. C'est un petit détail UX, mais dans un produit d'agents, ce genre de chose compte beaucoup.

Dans un agent IA, mémoire et contexte ne sont pas la même chose

Une chose devient de plus en plus claire au fur et à mesure que je construis DoDone : mémoire et contexte ne doivent pas être traités comme la même chose.

La mémoire, c'est ce qu'un collègue doit savoir sur le long terme : préférences utilisateur, informations sur l'entreprise, façons de travailler, règles récurrentes, faits importants décidés sur des projets passés. Ces informations peuvent être nécessaires des jours ou des mois plus tard. Le contexte est différent — c'est plutôt la mémoire de travail nécessaire pour bien faire la tâche maintenant : la demande précédente immédiate, le fichier en cours, ce qui vient d'être décidé, le problème à résoudre maintenant. Tenter de résoudre les deux en les entassant dans l'historique du chat et le système devient lourd très vite.

Je pense donc qu'un bon système d'agents finit par avoir plusieurs couches de mémoire : la mission en cours (ce qui est fait maintenant), le contexte récent (les dernières interactions détaillées), un résumé roulant (le flux compressé des travaux passés), et la mémoire à long terme (faits et règles qui doivent persister quelle que soit la session). La fenêtre de contexte du modèle n'est que l'espace où s'assemblent, au moment voulu, ceux dont vous avez besoin.

Plus la fenêtre de contexte est grande, plus l'ingénierie du contexte importe.

Il y a une ironie ici. À l'époque où les fenêtres de contexte étaient petites, les développeurs n'avaient d'autre choix que de réduire l'information. Puis, à mesure que les fenêtres sont passées à 128K, 200K, 1M, on a pu en mettre beaucoup. Et cela a créé un nouveau problème : il faut décider ce qu'il ne faut pas inclure.

Un bon agent IA n'est peut‑être pas celui qui se souvient de tout. Ce qu'il faut maintenant, c'est une IA qui mémorise le présent avec précision, compresse le passé de manière appropriée, transfère l'important en mémoire à long terme, et crée un nouvel espace de travail quand le sujet change. En fin de compte, le travail que vous faites de plus en plus en construisant un agent n'est pas de l'ingénierie des prompts — c'est de l'ingénierie du contexte.

La question centrale évolue aussi. Avant, on demandait « que devons‑nous dire au modèle ? » Aujourd'hui, c'est plutôt « en ce moment, combien le modèle devrait‑il réellement savoir ? »

C'est exactement là-dessus que j'ai passé le plus de temps en construisant DoDone. Pas pour que l'IA se souvienne de plus, mais pour qu'elle retienne les bonnes choses au bon moment. Je suis convaincu que la différence qui déterminera la qualité des agents IA dorénavant se joue à cet endroit.