Mémoire et état : contexte court terme et rappel long terme

Vous dites à un agent de support « Je m'appelle Priya et mamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → commande est la #4471. » Trois messages plus tard, il demande : « Puis-je avoir votre nom ? » C'est un agent sans mémoire, et l'impressionimpressionLe nombre total de fois qu'une publicité ou un contenu est affiché, indépendamment des clics. Chaque affichage compte pour une impression, même auprès de la même personne.Voir la définition complète → est celle d'un produit cassé. Mais l'échec inverse est tout aussi mauvais : un agent qui entasse chaque conversation passée dans chaque réponse s'embrouille, ralentit et coûte une fortune. Les bons agents retiennent les *bonnes* choses au *bon* moment. C'est le sujet de cette leçon.

Deux types de mémoire

Le cerveau humain a une mémoire de travail (ce à quoi vous pensez à l'instant) et une mémoire à long terme (ce que vous pouvez rappeler au besoin). Les agents IA fonctionnent de la même manière, et la distinction a des conséquences sur la façon de les construire.

Mémoire court terme : la fenêtre de contexte

La fenêtre de contexte est le bloc de texte que le modèle peut « voir » dans une seule requête. Elle comprend les instructions système, la conversation jusqu'ici et toutes les données que vous y collez. Voyez-la comme le bureau de l'agent : tout ce qui est posé dessus est visible d'un coup, mais le bureau a une taille fixe.

Cette taille se mesure en tokenstokensUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → (environ ¾ de mot chacun). Les modèles récents de 2026 ont de grandes fenêtres, souvent 200 000 tokens ou plus, mais « grande » n'est pas « infinie », et une fenêtre pleine est lente et coûteuse.

Voici le fait clé qui surprend : le modèle n'a aucune mémoire entre deux appels. Chaque fois que vous envoyez un message, toute la conversation est renvoyée. L'agent ne « se souvient » de votre nom que parce que votre application conserve le transcript et le recolle à chaque tour.

# Short-term memory is just a list you resend every turn.
messages = [
    {"role": "system", "content": "You are a support agent."},
]

def chat(user_text):
    messages.append({"role": "user", "content": user_text})
    reply = model.generate(messages)          # toute la liste est envoyée à chaque fois
    messages.append({"role": "assistant", "content": reply})
    return reply

chat("My name is Priya, order #4471.")
chat("When does it ship?")   # 'Priya' et '#4471' sont toujours dans la liste

C'est toute l'astuce derrière la mémoire conversationnelle. Aucune magie, juste une liste qui grossit.

Mémoire long terme : un stockage interrogeable

Le bureau se remplit. Anciens tickets, échanges passés et historique de compte ne peuvent pas tous rester indéfiniment dans la fenêtre de contexte. On les déplace donc vers la mémoire long terme : un stockage externe que l'agent peut interroger quand un sujet revient.

L'outil courant pour cela est un vector storevector storeUne vector database stocke les données sous forme de vecteurs numériques à haute dimension (embeddings) et retrouve les éléments par similarité plutôt que par correspondance exacte, ce qui rend possible la recherche sémantique et les applications d'IA.Voir la définition complète → (aussi appelé base de données vectorielle). Il stocke le texte sous forme d'embeddings : des empreintes numériques qui capturent le sens. Quand Priya réécrit, l'agent transforme son nouveau message en embeddingembeddingUn embedding est un vecteur numérique qui représente des données (texte, images ou items) en capturant leur sens, de sorte que les éléments similaires se retrouvent proches dans l'espace.Voir la définition complète → et demande au store : « Quels tickets passés ressemblent le plus à celui-ci ? » Il ne récupère que les quelques éléments pertinents et les pose sur le bureau.

C'est ce qu'on appelle le retrieval : aller chercher la poignée de souvenirs qui compte, ignorer les milliers qui ne comptent pas. Si vous voulez la mécanique en détail, cette introduction gratuite aux embeddings et à la recherche vectorielle l'explique clairement sans supposer que vous codez.

Un agent de support concret

Rendons cela réel. Priya a contacté le support quatre fois en deux ans. Elle écrit aujourd'hui : « Mon blender fume à nouveau. »

Voici ce que fait un agent bien conçu :

1. Court terme : il garde la conversation du jour dans la fenêtre de contexte pour ne pas redemander son nom en cours d'échange.
2. Retrieval long terme : il interroge le vector store pour les tickets passés de Priya. Il trouve le ticket #4471 de l'année dernière : « blender en surchauffe, remplacé sous garantie ». C'est très pertinent, donc il le charge.
3. Il ignore son ticket sans rapport sur une facture en retard. Pas similaire, pas chargé.
4. Il répond avec le contexte : « Je vois que nous avons remplacé ce blender pour surchauffe en mars dernier. Vérifions s'il est encore sous garantie. »

On a l'impression d'un humain qui se souvient vraiment de vous. Notez que l'agent n'a pas déversé les quatre tickets dans la fenêtre. Il en a récupéré un.

# Long-term recall: search, then inject only what's relevant.
def build_context(user_text, user_id):
    past = vector_store.search(
        query=user_text,
        filter={"user_id": user_id},
        top_k=3            # seulement les 3 souvenirs les plus pertinents
    )
    memory_block = "\n".join(m.text for m in past)
    return [
        {"role": "system",
         "content": f"You are a support agent.\nRelevant history:\n{memory_block}"},
        {"role": "user", "content": user_text},
    ]

Le top_k=3 fait beaucoup de travail. Il dit « donne-moi les trois meilleures correspondances, pas tout ». Ce simple nombre fait souvent la différence entre un agent précis et un agent qui se noie dans l'historique.

Ce qu'il faut garder, résumer ou oublier

La mémoire, ce n'est pas « tout sauvegarder ». C'est une série de décisions. Voici des règles pratiques.

Garder (mot pour mot, dans la fenêtre)

• La tâche en cours et les derniers tours de conversation.
• Les faits que l'agent ne doit pas se tromper : numéros de commande, objectif déclaré de l'utilisateur, adresse de livraison confirmée.
• Tout ce dont l'utilisateur vient de dire « retiens ça ».

Résumer (compresser, puis garder le résumé)

Quand une conversation s'allonge, ne transportez pas les cinquante messages. Résumez les plus anciens en une note courte et ne gardez que celle-ci. On parle souvent de « rolling summary ».

Exemple : quarante messages d'aller-retour de diagnostic deviennent une ligne : *« Utilisateur en dépannage d'un blender qui fume ; modèle X200 confirmé ; statut de garantie inconnu. »* Vous venez de libérer l'essentiel du bureau tout en gardant ce qui compte.

# When the transcript gets long, compress the old part.
if token_count(messages) > 6000:
    old = messages[1:-6]                      # garder le système + les 6 derniers tours
    summary = model.generate([
        {"role": "user",
         "content": f"Summarize these support messages in 3 sentences:\n{old}"}
    ])
    messages[1:-6] = [{"role": "system", "content": f"Summary so far: {summary}"}]

Oublier (supprimer entièrement)

• Les bavardages et politesses. « Merci beaucoup ! » n'a pas besoin d'être mémorisé.
• Les données sensibles que vous ne devez pas conserver (voir plus bas).
• Les tentatives échouées une fois la tâche réussie. L'agent n'a pas besoin de trois mauvaises réponses encombrant sa mémoire d'un ticket résolu.

Un modèle mental utile : garder les faits, résumer les parcours, oublier le bruit.

Trouver le bon équilibre

Deux modes de défaillance encadrent une bonne mémoire.

Trop peu de mémoire : l'agent repose des questions, perd le fil et paraît robotique. Généralement causé par un transcript non persisté, ou un top_k réglé trop bas.

Trop de mémoire : l'agent est perturbé par un historique périmé ou hors sujet, se contredit, tourne lentement et coûte plus cher par message. Généralement causé par le déversement de l'historique complet au lieu d'un retrieval, ou par l'absence de synthèse.

La correction est la même discipline dans les deux cas : soyez délibéré sur ce qui entre dans la fenêtre. Récupérez les souvenirs long terme pertinents, résumez les longues conversations, oubliez le bruit. La fenêtre de contexte est un emplacement de premier choix. Traitez chaque token comme s'il vous coûtait quelque chose, parce que c'est le cas.

Un dernier point pratique : réécrivez la mémoire. Après la clôture d'un ticket, enregistrez une courte note structurée dans le vector store : *« 2026-03-11 : Priya, blender X200, surchauffe, remplacé sous garantie. »* C'est ce que l'agent de demain récupérera. Un agent qui n'écrit jamais de nouveaux souvenirs ne pourra rappeler que ce avec quoi il a démarré.

Une note sur la confidentialité et les frameworks

La mémoire long terme signifie que vous stockez des données utilisateur, parfois sensibles. Deux règles vous évitent les ennuis :

• Ne stockez pas ce dont vous n'avez pas besoin. Masquez les numéros de carte, les mots de passe et les données de santé avant qu'ils n'atteignent le vector store.
• Laissez les utilisateurs voir et supprimer leurs souvenirs. « Oublie tout ce qui me concerne » doit réellement fonctionner. Concevez-le dès le premier jour.

Vous n'avez pas à construire toute cette plomberie vous-même. Chaque grand fournisseur livre désormais un framework d'agents qui gère les transcripts, le retrieval et la synthèse pour vous : l'OpenAI Agents SDK, le Claude Agent SDK et l'Agent Development Kit (ADK) de Google. Ils diffèrent dans les détails mais partagent la structure que vous venez d'apprendre : contexte court terme plus retrieval long terme. Les blocs d'approfondissement par fournisseur de ce cours couvrent les spécificités de chacun. Les concepts se transfèrent directement, donc choisissez le fournisseur que vous utilisez déjà.

Points clés

• La mémoire court terme n'est que le transcript que vous renvoyez à chaque tour. Le modèle n'a aucune mémoire entre les appels ; votre application la fournit en recollant la conversation.
• La mémoire long terme est un vector store interrogeable. Récupérez les quelques éléments passés pertinents (un top_k bas), pas tout l'historique.
• Gardez les faits, résumez les parcours, oubliez le bruit. Transportez les numéros de commande mot pour mot, compressez les longues conversations en un rolling summary, et laissez tomber les politesses.
• Réécrivez la mémoire après chaque tâche pour que les sessions futures puissent la rappeler, et intégrez la suppression dès le départ pour la confidentialité.
• La fenêtre de contexte est un emplacement de premier choix. Trop peu comme trop de mémoire cassent les agents ; le remède est d'être délibéré sur chaque token qui entre dans la fenêtre.