Le problème actuel des fils de discussions et de la mémoire des LLMs

Par Louis-Philippe Bellerose

Deux mois après le début d’un même fil de discussion avec un assistant IA, j’ai demandé une petite modification. Quelques mots. La demande a consommé le quart de mon allocation de session.

Rien n’était brisé. Je venais simplement de me heurter au fonctionnement de l’outil, et ce fonctionnement vaut la peine d’être compris avant de décider comment organiser sa pratique autour de ce dernier.

Pourquoi une petite demande peut coûter une fortune

Un fil de discussion n’a pas de mémoire au sens humain. À chaque tour, l’assistant relit toute la conversation depuis le début, puis répond. Le coût d’un message n’est donc pas la taille de la demande. C’est la taille de tout ce qui précède, plus la demande.

Mon fil avait grossi pendant deux mois. Chaque question (par exemple «corrige cette virgule») coûtait un paquet de jetons de relecture avant que l’assistant ne produise un mot. La demande était petite. Le contexte, lui, ne l’était pas, et la demande en a hérité.

J’avais entendu le folklore : commencer une nouvelle discussion de temps en temps, parce qu’une conversation se dégrade et coûte de plus en plus de jetons à mesure qu’elle grossit. Je le faisais chaque mois, en demandant à l’assistant un document de passation avant d’ouvrir une conversation neuve. J’ai voulu vérifier si c’était vraiment nécessaire en sautant un tour. Ça s’est avéré exact finalement.

Puis est arrivée la solution proposée automatiquement : passer au forfait supérieur ou acheter des jetons.

L’analyse de facteurs humains

Mettons la question du prix de côté un instant et regardons ça comme une interface.

On a une ressource qui s’épuise. Elle s’épuise de façon non linéaire, parce que le coût de chaque action grandit avec l’état accumulé. Et cet état est invisible. L’interface de clavardage n’affiche aucune mesure. La version en ligne de commande montre un compteur qui monte, sans plafond, alors on sait qu’on dépense, mais pas combien il reste. À un moment, ma demande consommait 160 000 jetons, et je n’avais aucune idée si c’était beaucoup ou non.

Dans la plupart des milieux où je travaille, cette combinaison échouerait la revue au premier passage. Aucune visibilité de l’état. Aucune rétroaction sur la consommation. Aucun moyen, pour l’opérateur, de se construire un modèle mental juste du système. Ça me rappelle l’époque où, au Canada, les forfaits Internet résidentiels avaient des plafonds de téléchargement (pas seulement les cellulaires). Je pense que presque tout le monde a reçu au moins une fois une facture absurde, parce qu’il n’y avait aucun moyen de savoir combien on avait consommé. Tout étant facturé à la fin du mois, la surprise était amère.

Le résultat prévisible, c’est que le folklore s’accumule. Demander une passation et ouvrir un nouveau fil chaque mois. Utiliser telle ou telle compétence. Formuler les requêtes de telle ou telle façon. En gros, on essaie d’apprendre ce qui consomme et ce qui ne consomme pas. On lit des forums pour savoir quelles fonctions coûtent cher. Chacun de ces conseils peut être réel et utile, et chacun est une tâche du produit refilée à la personne qui l’utilise.

Je ne dis pas que c’est un piège conçu pour coincer les gens. Le contexte est une contrainte d’ingénierie non résolue, et les gens qui bâtissent ces outils le savent mieux que moi. Mais il n’y a pas besoin d’intention pour qu’un incitatif soit mal aligné. Ici, l’opacité avantage le vendeur, et une solution automatique du type «passez au forfait supérieur» quand le vrai correctif est «ouvrez un nouveau fil» indique que le produit n’a pas encore pris le problème en charge.

Les contournements créent leurs propres problèmes

Le folklore a ensuite créé un deuxième problème. Quand on fait tourner les fils, chacun accumule des sujets. Mon fil marketing contenait le contenu entrant, la prospection sortante, une question d’autorisation d’un client et une discussion d’outillage, tout ça dans une seule conversation. J’ai essayé des fils plus larges pour réduire la rotation, et c’était pire : plus difficile à chercher, plus difficile à transmettre, et le document de passation a grossi jusqu’à souffrir du même problème que le fil.

C’est là que c’est devenu clair : le problème n’était pas la longueur du fil. C’est que j’utilisais un fil de discussion comme mémoire, et qu’un fil de discussion est une très mauvaise mémoire. Elle est linéaire, elle coûte cher à relire, elle mélange les sujets, et elle appartient au fournisseur.

Ce que j’ai bâti à la place

J’ai cessé de traiter les fils comme une mémoire. L’état vit maintenant hors du clavardage.

Concrètement : un coffre de notes en texte brut (markdown), un sujet par note, hébergé dans Obsidian sur un serveur maison que j’exploite déjà. Un petit serveur MCP expose le coffre à l’assistant par un tunnel, de sorte que n’importe quelle surface d’IA peut le lire et y écrire. Un court fichier de règles dans le coffre dit à l’assistant comment se comporter : lire l’index maître et la note d’état pertinente au début d’une session, réécrire les faits et les décisions à la fin, consigner chaque modification dans un journal des changements, ne jamais écrire du contenu de clavardage, un sujet par note, et déposer tout ce qui est incertain dans un dossier d’entrée avec un emplacement proposé.

Les fils sont devenus des sessions. J’en ouvre un pour un morceau de travail, l’assistant lit quelques milliers de jetons de coffre plutôt que cent soixante mille jetons d’historique, on fait le travail, il réécrit ce qui a changé, et le fil peut mourir. La session suivante part du coffre, pas d’une passation.

Les bénéfices secondaires se sont révélés aussi importants que l’économie de jetons. Le coffre est versionné, alors je vois ce qui a changé et quand. Il est sauvegardé. Il est portable, alors je peux changer d’outil ou pointer deux outils sur le même travail. Et il est à moi, dans un format qui s’ouvrira encore dans vingt ans.

Ce que ça coûte

Ce n’est vraiment pas une solution parfaite, surtout vue la façon dont les outils sont conçus en ce moment.

Ce n’est pas une solution grand public. Il a fallu un serveur maison, un tunnel Cloudflare, un après-midi avec un agent de codage pour brancher le serveur, et la volonté d’entretenir une infrastructure. La plupart des gens ne devraient pas faire ça, et le fait qu’ils devraient le faire est tout le propos de la première moitié de cet article.

Ça repose sur la discipline. Un coffre dans lequel on ne réécrit pas se dégrade en miroir périmé du monde, ce qui est pire qu’aucun coffre, parce qu’on lui fait confiance. Le fichier de règles aide. L’assistant le suit bien. Mais l’étape de réécriture est une habitude, et les habitudes flanchent.

Les fils se sont mis à se multiplier beaucoup plus vite, et je n’utilise plus l’outil de clavardage comme il a été conçu. Le contexte que chaque fil accumule fait double emploi avec le coffre, et les nombreux fils courts créés pour contourner le problème laissent derrière eux une pléthore de conversations inutilisables. L’historique des conversations devient un outil inutilisé, qui n’est plus qu’une distraction.

Ce que j’attendrais du produit

D’abord, de la prévisibilité. Pas besoin que ce soit parfait, mais il nous faut une idée de ce qui va être consommé. Ça ne devrait pas être difficile à bâtir, puisque les outils d’IA savent déjà quand compacter, et savent comment ça affecte la consommation de jetons. Il ne nous faut pas un tableau de bord d’utilisation enfoui dans les réglages. Il nous faut un indicateur visible de ce que ce fil coûte à poursuivre, là où on tape le message. Ce seul élément aurait remplacé le folklore pour moi.

Ensuite, une séparation native entre la session et l’état. Les morceaux existent, projets, fonctions de mémoire et ainsi de suite, mais ils appartiennent encore au fournisseur et restent opaques. Le modèle que j’ai bâti est celui vers lequel ces outils se dirigent. J’aimerais simplement qu’il arrive sous une forme qui n’exige pas un serveur dans mon sous-sol.

D’ici là, le coffre tient. Il a remis le compteur là où je peux le voir, et il a empêché mes outils d’oublier l’essentiel.

À propos de l'auteur

Louis-Philippe Bellerose

Fondateur et Consultant Principal

Louis-Philippe Bellerose est le fondateur et consultant principal de Bellerose XD, une firme de conseil en UX stratégique qui allie les objectifs d’affaires à la réalité des utilisateurs. Il travaille en français, en anglais et en portugais brésilien.
Voir sur LinkedIn →