Mémoire d'un agent IA : que faut-il réellement conserver ?

Chaque dimanche, je reviens sur les captures accumulées pendant la semaine.

Certaines deviennent une note, une décision ou une prochaine action. D'autres restent des références. Une grande partie disparaît simplement : l'idée était moins utile que prévu, l'information a déjà perdu sa valeur ou je sais que je ne la chercherai jamais.

Mon agent pourrait techniquement tout conserver. Ce serait même plus simple à automatiser.

Je lui demande pourtant de ne pas décider seul de ce qui mérite d'entrer dans ma mémoire durable.

Une mémoire d'agent IA n'est pas un entrepôt dans lequel on verse chaque conversation, chaque document et chaque pensée. Plus elle accumule d'informations sans distinction, plus elle risque de mélanger une décision avec une hypothèse, une référence actuelle avec une ancienne version ou un élément utile avec une donnée sensible.

La bonne question n'est donc pas : « comment faire pour que mon agent se souvienne de tout ? »

Elle est plus sélective :

De quoi mon agent doit-il se souvenir pour accomplir un usage précis, et qu'est-ce qui doit rester temporaire, être vérifié à sa source ou ne jamais être conservé ?

Une mémoire n'est pas l'historique complet de l'agent

Le mot « mémoire » désigne souvent plusieurs mécanismes différents.

Un agent peut conserver l'historique d'une conversation afin de reprendre un échange. Il peut relire des fichiers. Il peut rechercher une information dans une base de connaissances. Il peut aussi recevoir quelques règles durables au début de chaque nouvelle session.

Ces mécanismes ne donnent pas le même statut aux informations.

La documentation de l'OpenAI Agents SDK décrit par exemple une mémoire de session qui récupère l'historique avant chaque exécution, puis stocke les nouveaux messages, réponses et appels d'outils après celle-ci. C'est utile pour assurer la continuité d'une conversation. Cela ne signifie pas que chaque élément de cet historique mérite de devenir une connaissance durable.

Une conversation contient aussi des essais, des erreurs, des formulations abandonnées et des réponses produites par le modèle. Si tout remonte indistinctement lors des prochaines demandes, l'agent reçoit davantage de texte, mais pas forcément un meilleur contexte.

Anthropic décrit ce problème comme la gestion d'une ressource limitée : à mesure que le contexte s'allonge, la capacité du modèle à retrouver précisément une information peut se dégrader. L'entreprise recommande donc de sélectionner le contexte utile plutôt que de remplir systématiquement la fenêtre disponible.

La mémoire d'un agent IA doit commencer par une séparation simple :

• l'historique aide à reconstruire ce qui s'est passé ;
• le contexte de travail aide à traiter la demande actuelle ;
• la mémoire durable conserve ce qui devra encore faire référence plus tard.

Confondre ces trois niveaux transforme facilement une trace utile en règle permanente.

Cinq catégories d'informations peuvent mériter de durer

Tout ne mérite pas d'être mémorisé, mais certaines informations évitent réellement de repartir de zéro.

Le cadre durable de votre activité

Un agent qui vous accompagne régulièrement doit connaître quelques éléments stables :

• votre activité et le public que vous servez ;
• votre vocabulaire de référence ;
• vos principes de travail ;
• vos contraintes de confidentialité ;
• vos préférences durables de forme ou de collaboration.

Dans mon cas, l'agent sait que je parle de « mise en place » d'un système IA personnel et non d'une simple installation technique. Il connaît aussi la frontière entre les apprentissages publiables et les informations liées à mon activité salariée, qui restent confidentielles.

Ces éléments changent peu. Ils peuvent donc être chargés régulièrement sans devoir relire des dizaines d'anciennes conversations.

Ils doivent toutefois rester modifiables. Une préférence n'est pas une loi éternelle, et un positionnement peut évoluer.

Les décisions et les règles actuellement valides

Une décision validée mérite souvent une place plus claire qu'un message perdu au milieu d'un fil.

Cela concerne par exemple :

• le périmètre actuel d'une offre ;
• une règle de qualification ;
• un choix de structure ;
• une permission accordée ou refusée ;
• une procédure approuvée ;
• une formulation abandonnée qu'il ne faut plus réintroduire.

Le mot important est « actuellement ».

Une ancienne décision peut rester utile pour comprendre l'historique. Elle ne doit plus être présentée comme la règle en vigueur. Je préfère donc conserver l'ancienne version dans l'historique tout en désignant explicitement la note ou le document qui fait référence aujourd'hui.

L'état des projets actifs

Un projet ne se résume pas à sa description initiale. L'agent a surtout besoin de savoir où le travail s'est arrêté.

Une mémoire de projet utile peut contenir :

• l'objectif actuel ;
• les décisions déjà prises ;
• les points encore ouverts ;
• les blocages ;
• la dernière sortie produite ;
• la prochaine action.

Cette couche change plus vite que le cadre durable. Elle doit donc être courte, datée et facile à remplacer.

L'agent n'a pas besoin de relire tout le projet pour répondre à « où en étions-nous ? ». Il lui faut une représentation fiable de l'état présent, puis l'accès à l'historique si un détail doit être retrouvé.

Les connaissances de référence

Certains documents doivent pouvoir être consultés pendant plusieurs usages : documentation, méthode interne, note conceptuelle, transcription validée, grille de décision ou fiche client autorisée.

Les conserver ne suffit pas. L'agent doit savoir :

• d'où vient l'information ;
• à quel sujet elle s'applique ;
• si elle constitue une référence ou un simple matériau ;
• quand elle a été créée ou vérifiée ;
• si une version plus récente existe.

Une base de connaissances sans provenance place sur le même plan une source primaire, une synthèse personnelle et un texte généré par l'IA. Le problème apparaîtra plus tard, lorsque l'agent devra arbitrer entre deux versions contradictoires.

Les enseignements réellement réutilisables

Un agent peut aussi conserver ce qui améliore les prochaines exécutions : une correction récurrente, une convention de projet, une erreur à éviter ou une préférence confirmée plusieurs fois.

Je distingue ici l'apprentissage durable du compte rendu d'une tâche terminée.

« Quentin préfère des réponses directes et courtes » peut rester utile dans plusieurs mois. « L'article de mardi a été publié » est un état temporaire que l'on retrouvera dans l'historique ou le système de suivi. Le premier évite une correction répétée. Le second vieillira rapidement.

Cette distinction empêche la mémoire de devenir un journal d'activité que l'agent doit parcourir avant chaque réponse.

Ce qui doit rester temporaire

Une partie du contexte est utile pendant quelques minutes, quelques heures ou la durée d'un projet, puis perd sa valeur.

C'est le cas :

• d'une capture qui n'a pas encore été triée ;
• d'une hypothèse en cours d'exploration ;
• d'un brouillon intermédiaire ;
• du résultat brut d'un outil ;
• d'un plan abandonné ;
• d'une préférence exprimée pour une seule tâche ;
• d'une donnée extérieure susceptible de changer.

Ces éléments peuvent rester dans la conversation, dans une boîte de réception ou dans un espace de travail temporaire. Ils ne doivent pas être promus automatiquement dans la mémoire durable.

Anthropic cite la compaction et la prise de notes structurée parmi les moyens permettant à un agent de poursuivre un travail long sans conserver chaque détail dans son contexte immédiat. Le principe est utile au-delà de la technique : résumer ce qui compte et laisser disparaître le bruit.

Dans mon propre système, l'Inbox remplit précisément ce rôle. Une capture y entre sans recevoir immédiatement le statut de connaissance. Je peux la relire avec du recul, décider de la développer, la déplacer vers une ressource ou la supprimer.

L'agent peut préparer ce tri. La décision de conserver durablement reste humaine lorsque le contenu touche à mes priorités, à mon identité ou à une information sensible.

Certaines informations doivent être consultées, pas mémorisées

Un tarif, une documentation logicielle, une échéance administrative, le contenu d'une page web ou l'état d'un dépôt peuvent devenir faux sans que la mémoire de l'agent soit prévenue.

Les copier dans une note peut fournir un historique. Cette copie ne remplace pas la source actuelle.

Pour ces informations, la mémoire doit surtout conserver une règle de consultation :

• quelle source fait référence ;
• quand la vérifier ;
• quelle date associer au résultat ;
• que faire si la source n'est pas disponible ;
• quelle ancienne donnée peut être utilisée comme simple contexte.

C'est la différence entre mémoriser « le tarif est de 100 € » et mémoriser « vérifier le tarif sur la page officielle avant de le citer ».

La seconde règle vieillit beaucoup mieux.

Dans l'article précédent, j'expliquais déjà pourquoi la mémoire de ChatGPT ne suffit pas à connaître votre contexte de travail. Cette distinction entre mémoire et source actuelle en est la conséquence pratique : certaines vérités doivent être récupérées au moment de la demande.

Ce qui ne doit pas entrer dans la mémoire

La possibilité technique de stocker une information ne justifie pas sa conservation.

Je commence par exclure tout ce dont l'agent n'a pas besoin pour l'usage choisi :

• mots de passe, clés API et secrets ;
• données personnelles sans nécessité claire ;
• documents confidentiels sans permission explicite ;
• informations appartenant à un autre contexte ;
• contenus privés d'un tiers sans son accord ;
• données dont la durée de conservation n'est pas définie.

La fiche Sensitive Information Disclosure de l'OWASP classe notamment les informations personnelles, les données financières, les dossiers de santé, les secrets professionnels, les identifiants de sécurité et les documents juridiques parmi les informations sensibles susceptibles d'être exposées par une application reposant sur un grand modèle de langage. Sa recommandation suit le principe du moindre privilège : limiter l'accès aux données nécessaires pour l'utilisateur ou le processus concerné.

Cette règle vaut aussi dans un système personnel.

Un agent chargé de préparer un article n'a pas besoin d'accéder à des informations administratives privées. Un agent professionnel n'a pas à consulter un journal personnel sous prétexte que tout se trouve dans le même espace de notes. Une mémoire commune paraît pratique jusqu'au jour où un fragment traverse la mauvaise frontière.

La séparation personnel-professionnel, les permissions de lecture et les validations ne sont donc pas des raffinements ajoutés après coup. Elles déterminent ce que la mémoire a le droit de contenir et de restituer.

Une information durable a besoin d'un statut

Même une information pertinente devient fragile si l'agent ignore comment l'interpréter.

Avant de faire entrer un élément dans une mémoire durable, je veux pouvoir répondre à quelques questions :

1. Quelle est sa source ? Une décision personnelle, un document officiel, une conversation, une synthèse ou une sortie générée ne portent pas la même autorité.
2. À quel périmètre s'applique-t-elle ? Toute l'activité, un client, un projet, un canal ou une seule tâche ?
3. Quel est son statut ? Hypothèse, décision validée, préférence, référence, archive ?
4. Quand doit-elle être revue ? À une date précise, à la fin du projet ou lors du prochain usage ?
5. Qu'est-ce qui la remplace ? Une nouvelle version doit pouvoir devenir la référence sans effacer l'historique.

Ces informations peuvent être portées par une structure de dossiers, des métadonnées, une note de décision ou une convention de nommage. L'outil importe moins que la capacité de l'agent à interpréter correctement ce qu'il lit.

Une note intitulée « offre finale » ne restera pas finale très longtemps. Une note intitulée, datée et reliée à une décision actuelle fournit déjà un signal plus solide.

La mémoire doit accepter la correction et l'oubli

Une mémoire figée finit par mentir.

Vos priorités changent. Une règle devient inutile. Un client retire son consentement. Une source est corrigée. Une préférence cesse d'être vraie. Si l'agent ne peut qu'ajouter, chaque nouvelle information s'empile sur les précédentes.

Une mémoire exploitable doit permettre de :

• corriger une information ;
• remplacer la référence actuelle ;
• conserver un historique lorsqu'il est utile ;
• archiver ce qui ne guide plus l'action ;
• supprimer ce qui n'a plus de raison d'être conservé ;
• restaurer une version saine après une mauvaise modification.

C'est l'une des raisons pour lesquelles je conserve ma mémoire de travail dans des fichiers que je possède et dont GitHub garde l'historique. Je peux lire ce que l'agent lit, revoir une modification et reprendre à partir d'une version antérieure.

Cette capacité ne dispense pas du tri. Versionner dix copies contradictoires protège contre la perte, pas contre la confusion. Il faut encore désigner la version actuelle.

Mon article sur la manière dont mon agent travaille avec Obsidian sans décider à ma place montre cette répartition : l'agent peut retrouver, préparer et proposer, tandis que certaines décisions de conservation ou de modification restent sous validation humaine.

L'agent peut entretenir sa mémoire sans en devenir le propriétaire

Une validation humaine sur chaque détail rendrait le système pénible. Une autonomie totale rendrait la mémoire difficile à maîtriser.

Je préfère répartir les tâches.

L'agent peut :

• détecter deux informations contradictoires ;
• signaler une note ancienne ;
• proposer une synthèse ;
• suggérer qu'une capture rejoigne un projet existant ;
• identifier une donnée potentiellement sensible ;
• préparer une modification avec son motif.

Je garde la validation pour les décisions qui changent la référence, suppriment une information importante, déplacent une frontière de confidentialité ou engagent une action externe.

Cette répartition peut évoluer. Une règle déterministe et bien testée pourra automatiser certaines opérations simples. Archiver une sortie temporaire après une durée définie ne demande pas toujours une interprétation par l'IA.

Le système doit alors prévoir le comportement d'échec : si le statut est incertain, si deux sources se contredisent ou si la modification paraît sensible, l'agent n'improvise pas. Il demande une validation ou laisse l'information en attente.

Commencez par la mémoire nécessaire à un seul usage

Construire la mémoire complète de votre activité avant le premier usage crée beaucoup de travail et peu de retours.

Partez d'une demande qui revient réellement.

Si vous voulez que l'agent prépare vos contenus, il aura peut-être besoin de votre positionnement actuel, de votre voix, de vos preuves autorisées, de vos sujets déjà traités et de vos règles de confidentialité. Il n'a pas besoin de connaître toute votre vie ni chaque note accumulée depuis dix ans.

Si vous voulez reprendre plus facilement un projet après plusieurs jours, commencez par l'objectif, les décisions, l'état actuel et la prochaine action. L'historique détaillé restera disponible à la demande.

Pour définir cette première mémoire, répondez à six questions :

1. Quel résultat l'agent doit-il préparer ?
2. Quelles informations vous oblige-t-il aujourd'hui à répéter ?
3. Quelles décisions doivent faire référence ?
4. Quelles données risquent de devenir obsolètes ?
5. Quelles informations doivent rester hors de portée ?
6. Qui valide une modification durable ?

Ces réponses dessinent un périmètre beaucoup plus utile qu'une consigne générale comme « souviens-toi de tout ».

Elles permettent aussi de vérifier si vous avez réellement besoin d'un système IA personnel. Pour une demande ponctuelle avec toutes les informations fournies dans le prompt, une conversation classique peut suffire. Le système devient pertinent lorsque le contexte doit durer, rester possédé, évoluer sans perdre son historique et respecter des permissions.

Une bonne mémoire choisit ce qu'elle accepte de perdre

Une mémoire d'agent IA ne devient pas fiable parce qu'elle contient davantage d'informations.

Elle devient fiable lorsque chaque couche joue son rôle : l'historique permet de revenir en arrière, le contexte temporaire aide à terminer la tâche, les sources actuelles sont vérifiées et la mémoire durable conserve les décisions qui devront encore guider l'agent.

Le tri n'est donc pas une opération de rangement après la mise en place. Il fait partie du fonctionnement du système.

Ce que vous refusez de mémoriser compte autant que ce que vous conservez. C'est ce choix qui protège la pertinence, la confidentialité et votre capacité à corriger le système plus tard.