Pourquoi les décisions prises dans un chat IA se perdent, et où les conserver

Les décisions prises dans une conversation ChatGPT ou Claude se perdent parce qu’une conversation n’a pas d’état. Rien n’y marque une ligne comme « voilà ce que nous avons décidé », rien ne relie cette ligne au travail qu’elle concerne, et une nouvelle conversation démarre vide. La solution : faire écrire la décision par l’IA là où vit le travail, sous forme d’un court enregistrement avec ses raisons, et faire lire ces enregistrements à la session suivante avant qu’elle agisse.

C’est nous qui faisons Weft. Les informations sur les autres produits viennent de leurs pages officielles, vérifiées le 27 octobre 2026. L’idée qu’un fil de discussion « n’a pas d’état » vient de l’article d’Hypertask sur les fils Slack. Ce guide l’applique aux conversations avec une IA.

Pourquoi les décisions prises avec ChatGPT ou Claude disparaissent-elles ?

Vous passez quarante minutes avec un assistant à peser deux fournisseurs de base de données, deux modèles de tarification ou deux façons de structurer une API. Vous en choisissez une. Le raisonnement est bon, l’assistant est d’accord, et vous passez à la suite.

Une semaine plus tard, la conclusion est toujours dans cette conversation, quelque part au-dessus de deux cents autres messages. Une nouvelle conversation n’en sait rien. Un coéquipier ne l’a jamais vue. Et si vous ouvrez un autre client IA le lendemain, par exemple un agent de code dans votre terminal, ce client part de zéro et peut vous proposer avec entrain l’option que vous avez écartée.

Ce n’est pas un problème de discipline. Une conversation est une suite de messages. Elle n’a pas de champ « décidé », pas de responsable, pas de lien vers une tâche, et aucun moyen de dire « ceci remplace ce que nous avons dit mardi ». Une question tranchée et une question abandonnée se ressemblent une fois sorties de l’écran.

La mémoire du chat ne règle-t-elle pas déjà ce problème ?

Pas pour cet usage. Beaucoup d’assistants peuvent désormais se souvenir de choses sur vous d’une conversation à l’autre, et c’est utile pour les préférences et le contexte. Mais cette mémoire appartient à un produit et à un compte. Elle est écrite pour que cet assistant s’en serve, pas comme un registre qu’une personne peut relire ligne à ligne, et un autre client IA ne peut pas la lire. Elle ne dit pas non plus à quelle tâche se rapportait un choix ni quel choix antérieur il remplaçait.

Un journal des décisions a d’autres exigences. Il doit être facile à retrouver pour les personnes et les agents qui travaillent sur le projet, lisible par n’importe quel client IA qui reprend le travail, rattaché à ce travail, et honnête sur l’historique : quand une décision change, l’ancienne doit rester visible avec la raison de son remplacement.

Qu’est-ce qui mérite d’être enregistré comme décision ?

Enregistrez un choix quand quelqu’un aurait raisonnablement pu choisir autrement et que ce choix va façonner le travail à venir. De bons exemples :

• Choisir un outil, un fournisseur ou une bibliothèque plutôt qu’un autre.
• Renoncer à quelque chose volontairement (« pas de programme de parrainage ce trimestre »).
• Fixer une règle que le travail doit suivre (« tous les prix affichés TVA comprise dans l’UE »).
• Changer un choix antérieur, avec la raison.
• Une leçon apprise à la dure (« ne pas lancer la migration pendant les heures ouvrées »).

N’enregistrez pas :

• Les idées lancées puis non retenues.
• Les étapes du travail lui-même (elles ont leur place dans la tâche et son résultat).
• Ce que la personne n’a pas encore validé, sauf si c’est clairement marqué comme proposé.
• Les faits que n’importe qui peut retrouver en une minute.

Un test utile : si une nouvelle session IA s’apprêtait à défaire ce choix, voudriez-vous qu’elle s’arrête pour lire pourquoi ? Si oui, enregistrez-le.

À quoi ressemble un bon enregistrement de décision ?

Faites court et gardez les raisons. Le format ci-dessous est une version allégée de MADR (Markdown Architectural Decision Records), celle qu’utilise l’outil record_decision de Weft :

Titre :          Fichiers envoyés : stockage objet, pas la base de données
Résultat :       Les fichiers envoyés vont dans le stockage objet ; la base ne garde
                 que la clé du fichier et ses métadonnées.
Statut :         accepted
Contexte :       Les utilisateurs joignent des fichiers jusqu’à 50 Mo. Les garder dans
                 la base rendrait les sauvegardes lentes et lourdes.
Options :        1. Stockage objet       + peu cher, sauvegardes légères
                                         - un service de plus à configurer
                 2. Colonne en base      + tout au même endroit
                                         - les sauvegardes grossissent à chaque envoi
Conséquences :   Il faut des URL signées pour les téléchargements.
                 Supprimer une tâche doit aussi supprimer ses fichiers.
Revoir quand :   Nous aurons besoin de chercher dans le contenu des fichiers.
Tâche :          Envoi de fichiers

• Titre nomme la décision pour qu’on la retrouve d’un coup d’œil.
• Résultat est une phrase sur laquelle un nouveau venu peut agir.
• Contexte, c’est ce qui était vrai à ce moment-là. C’est la partie qui s’efface la première de la mémoire.
• Options ne liste que ce qui a réellement été pesé, pas des alternatives inventées après coup.
• Conséquences inclut les inconvénients acceptés, pour que personne ne les « découvre » plus tard sous forme de bugs.
• Revoir quand dit ce qui rendrait ce choix mauvais.

Comment Weft conserve-t-il un enregistrement de décision ?

Weft est un tableau de tâches que vos clients IA atteignent via MCP sur https://letsweft.com/api/mcp. Trois de ses 32 outils gèrent les décisions :

• record_decision prend un titre et un résultat, plus le contexte, jusqu’à cinq options avec leurs pour et contre, les conséquences et la condition pour y revenir. Il peut être rattaché à une tâche (taskId) ou à un projet. Les enregistrements sont immuables : pour en changer un, l’IA enregistre une nouvelle décision avec supersedesId pointant vers l’ancienne, et l’ancien enregistrement reste, marqué comme remplacé.
• get_context renvoie les décisions et leçons en vigueur dans l’espace de travail, les plus récentes d’abord, dans un budget de jetons (800 par défaut). On peut le restreindre à un projet ou à une tâche. Chaque ligne porte sa date, une décision remplacée n’apparaît jamais, et les lignes qui n’ont pas tenu dans le budget sont comptées plutôt que cachées.
• get_task_history en mode decisions liste toutes les décisions enregistrées sur une tâche, y compris les verdicts de relecture et leurs raisons.

record_decision a un second usage : relayer un verdict que la personne a donné en conversation sur un travail qui attend sa relecture (accepté, à revoir, abandonné ou reporté). La description de l’outil précise à l’IA qu’elle n’est ici que la messagère, pas celle qui décide : elle ne doit jamais s’en servir pour accepter son propre travail.

Comme les enregistrements ne sont jamais modifiés sur place, l’historique reste honnête. Si vous changez de fournisseur en mars, la décision de janvier est toujours là, marquée comme remplacée, et l’enregistrement de mars dit pourquoi.

Comment demander à mon IA d’enregistrer les décisions ?

Connectez Weft à votre client IA, puis collez une consigne comme celle-ci au début d’une conversation, ou dans les instructions personnalisées ou le fichier de projet du client s’il en a :

Quand nous faisons un vrai choix dans cette conversation (nous préférons une option à une autre,
nous renonçons à quelque chose, ou nous changeons un choix antérieur), enregistre-le dans Weft avec
record_decision avant de passer à la suite :
- title : la décision, nommée en quelques mots
- outcome : le choix en une phrase
- context : ce qui était vrai et a imposé ce choix
- options : uniquement les options réellement pesées, avec leurs pour et contre
- consequences : ce qui en découle, en bien et en mal
- confirmation : quand nous devrions y revenir
- taskId ou project : la tâche ou le projet concerné
Si cela change une décision antérieure, passe supersedesId au lieu de modifier.
N’enregistre pas les bavardages, les suppositions, ni ce que je n’ai pas validé.
Si je ne me suis pas encore engagé, utilise le statut "proposed".
Au début de tout travail non trivial, appelle d’abord get_context et dis-moi
quelles décisions passées s’appliquent.

La connexion prend une minute. Dans ChatGPT, Weft est une appli publiée dans l’annuaire des plugins, disponible sur tous les forfaits, y compris le gratuit (configuration). Dans Claude Code, c’est une seule commande (configuration). Claude.ai et Claude Desktop l’ajoutent comme connecteur personnalisé. La connexion se fait par OAuth dans le navigateur : aucune clé à copier, et comme Weft émet des jetons de rafraîchissement, le client renouvelle la connexion tout seul. Les pages de configuration des autres clients, dont Cursor et Codex, sont dans la documentation.

Que se passe-t-il si je passe de ChatGPT à Claude Code le lendemain ?

Voici le cas pour lequel la consigne est faite.

1. Lundi, vous planifiez une fonctionnalité dans ChatGPT. Vous décidez de stocker les fichiers envoyés dans le stockage objet plutôt que dans la base, et ChatGPT appelle record_decision avec le contexte, les deux options et les conséquences, rattaché à la tâche « Envoi de fichiers ».
2. Mardi, vous ouvrez Claude Code dans le dépôt. Si vous ne l’avez pas encore connecté : claude mcp add --transport http weft https://letsweft.com/api/mcp.
3. Vous lui demandez de prendre la tâche des fichiers envoyés. Avant d’écrire du code, il appelle get_context pour cette tâche, ou get_task_history en mode decisions, et récupère l’enregistrement de lundi.
4. Il construit sur le stockage objet au lieu de rouvrir la question. S’il trouve une vraie raison pour laquelle le choix est mauvais, il peut proposer une nouvelle décision qui remplace celle de lundi, et c’est vous qui tranchez.

Les deux clients lisent le même tableau et les mêmes décisions, parce que l’enregistrement vit dans Weft, pas dans l’une ou l’autre conversation. Chaque connexion OAuth est un acteur distinct, et le tableau affiche le nom sous lequel chaque client s’est enregistré : vous voyez donc quelle connexion a créé quelle tâche. Pour faire tourner plusieurs agents sur un même tableau sans collisions, voir plusieurs agents IA, un seul tableau.

Où les décisions prises dans ChatGPT doivent-elles finir ?

Quatre endroits courants, comparés selon les besoins d’un journal des décisions :

Il ne s’agit pas de dire que le chat ou les documents sont mauvais. Le chat, c’est là que vous réfléchissez. La décision doit être sortie du chat vers quelque chose qui a un état, au moment où elle est prise, par la partie déjà présente dans la conversation : l’IA.

Cela remplace-t-il notre documentation ou notre wiki ?

Non. Weft n’a ni documentation ni wiki, et ne cherche pas à en être un. Les longues explications, les guides d’accueil et les notes de conception ont leur place dans votre outil de documentation. Un enregistrement de décision est volontairement petit : un choix, ses raisons, et ce qui l’a remplacé. Si votre équipe tient déjà ses décisions dans un wiki et que chaque client IA que vous utilisez peut le lire, cela peut suffire. Weft est utile quand les décisions sont prises dans des conversations avec une IA et que le lecteur suivant est souvent une autre IA. Si vous envisagez Notion pour cela, voir les alternatives à Notion pour les tâches IA.

Deux autres limites, honnêtement. Weft ne lit pas vos conversations : une décision n’est enregistrée que si l’IA appelle record_decision, d’où l’importance de la consigne ci-dessus. Et l’IA peut mal juger ce qui constitue une décision : lisez get_context de temps en temps et remplacez ce qu’elle a mal compris.

Combien cela coûte-t-il ?

Enregistrer et lire des décisions fonctionne sur le forfait gratuit, qui comprend 50 tâches actives et 200 appels d’outils IA par mois. Chaque appel record_decision ou get_context compte pour un appel. Pro coûte 7,80 € par place et par mois ou 66 € par place et par an, avec tâches et appels illimités (tarifs). Weft n’a pas de crédits d’IA : la réflexion se fait dans votre propre client IA, et Weft ne stocke que le tableau et ses enregistrements.

Ne puis-je pas simplement demander à ChatGPT de résumer les décisions en fin de conversation ?

Si, et ça aide. Mais le résumé vit toujours dans cette conversation ou là où vous le collez. Il n’est pas rattaché à la tâche, un autre client IA ne peut pas le lire, et quand la décision change, rien n’indique ce qu’elle a remplacé. Enregistrer chaque décision au moment où elle est prise évite ces trois écueils.

L’IA enregistrera-t-elle les décisions sans qu’on le lui demande ?

La description de l’outil record_decision demande à l’IA de s’en servir chaque fois que l’utilisateur fait un vrai choix en conversation : certains clients le feront donc. Ne comptez pas dessus. La consigne collée le rend explicite, et vous pouvez toujours dire « enregistre cette décision ».

Peut-on modifier une décision mal enregistrée ?

Pas sur place. Les enregistrements sont immuables. Enregistrez une décision corrigée avec supersedesId pointant vers la mauvaise. L’ancien enregistrement reste, marqué comme remplacé, et get_context cesse de l’afficher.

Une décision a-t-elle besoin d’une tâche ?

Non. Une décision peut être rattachée à une tâche, à un projet, ou à rien. La rattacher à une tâche permet à get_task_history de l’afficher à côté de ce travail, et à get_context d’être restreint à elle.

Est-ce la même chose que la mémoire de travail de Weft ?

Non. La mémoire de travail (de courtes notes apprises) est une fonction Pro distincte. Les enregistrements de décision viennent de record_decision, et le code ne les réserve pas à Pro.

Et si j’utilise plusieurs clients IA ?

C’est la principale raison de le faire. ChatGPT, Claude Code, Cursor ou Codex connectés au même espace Weft lisent tous les mêmes décisions via get_context : le second client ne rouvre pas les questions que le premier a tranchées.