Module 7 — Mémoire commune et passage de contexte

Le module 3 a montré ce qui traverse d'une tâche à l'autre : la sortie finale, rien de plus. C'est vrai par défaut, mais CrewAI expose un mécanisme de mémoire qui, activé, permet de garder trace de plus que ces sorties. Comprendre ce que ce mécanisme retient — et surtout ce qu'il ne retient pas — est indispensable pour éviter de payer des jetons pour rien ou, pire, de laisser fuir une information qu'on croyait effacée.

Trois mémoires, trois usages

CrewAI expose trois types de mémoire, activables ensemble via Crew(memory=True).

La mémoire courte (short_term_memory) est un cache des échanges récents à l'intérieur d'une exécution. Elle sert l'agent à qui l'on repose une question proche de la précédente et évite qu'il réinvente la même réflexion trois fois. Sa durée de vie est celle du kickoff() en cours.

La mémoire longue (long_term_memory) persiste entre exécutions dans un magasin local (par défaut un fichier SQLite). C'est elle qui permet à l'équipe, relancée le lendemain sur des spécifications proches, de retrouver le glossaire, les conventions et les décisions passées.

La mémoire d'entités (entity_memory) suit les objets nommés — un produit, une personne, un identifiant technique — mentionnés au fil des tâches. Quand un agent relit la sortie d'un autre et voit apparaître FactureExpress, la mémoire d'entités lui fournit le résumé de ce qui a déjà été dit à propos de ce nom.

equipe = Crew(
    agents=[analyste, redacteur, relecteur, responsable],
    tasks=[t1, t2, t3, t4],
    process=Process.sequential,
    memory=True,          # active les trois
    embedder={"provider": "openai", "config": {"model": "text-embedding-3-small"}},
)

Le paramètre embedder désigne le modèle qui vectorise les fragments stockés ; les mémoires longue et d'entités s'en servent pour retrouver des fragments similaires à la nouvelle question.

Ce qui traverse et ce qui ne traverse pas

La confusion la plus coûteuse consiste à croire que la mémoire remplace le context=[…] des tâches. Non. Le mécanisme est le suivant, et il faut le retenir précisément :

• Le contexte d'une tâche (paramètre context) est injecté dans la consigne de la tâche. Il est toujours vu.
• La mémoire est retrouvée par recherche au moment où un agent formule sa demande. Elle est vue si — et seulement si — la recherche trouve un fragment pertinent.

Autrement dit, ce qui doit impérativement être vu par la tâche suivante doit passer par le context. La mémoire est un accélérateur ; ce n'est pas un fil de continuité garanti.

Cette distinction se voit à la trace : le contexte apparaît en clair dans la consigne, la mémoire apparaît sous forme d'extraits injectés « au cas où ». En cas de bogue « il ne retrouve pas l'information », neuf fois sur dix la cause est de compter sur la mémoire là où le context était obligatoire.

La taille du contexte cumulé

Une exécution CrewAI de dix tâches où chaque tâche prend en entrée la sortie de la précédente et un fragment de mémoire longue et un résumé d'entités peut voir la consigne effective enfler à des dizaines de milliers de jetons. Trois conséquences :

1. La facture grimpe : les jetons d'entrée coûtent — souvent moins que les jetons de sortie, mais leur volume est bien plus grand.
2. La latence s'allonge : un modèle traite d'autant plus lentement qu'il reçoit un contexte plus long.
3. La qualité peut baisser : au-delà d'une certaine longueur, les modèles perdent des informations en début et en milieu de contexte — le fameux « lost in the middle ».

Ces trois raisons justifient à elles seules de désactiver la mémoire au démarrage d'un projet. Vous l'activerez plus tard, quand vous aurez identifié un cas précis où elle apporte.

Ce que la mémoire retient — et ce qu'elle expose

La mémoire longue et la mémoire d'entités persistent dans un fichier local. Cela a deux implications pratiques que beaucoup ignorent.

D'abord, si vous exécutez l'équipe sur des données confidentielles, ces données peuvent se retrouver sur le disque, disponibles à toute exécution suivante. Un agent qui pose une question proche récupérera l'extrait, qu'il soit autorisé à le lire ou non — la mémoire ne gère pas d'ACL. Pour un projet où les spécifications relèvent d'un client précis, il faut soit désactiver la mémoire longue, soit isoler le magasin par projet (crew_id distinct, ou dossier de stockage distinct).

Ensuite, la mémoire longue est un cache. Elle ne s'invalide pas toute seule quand les faits sous-jacents changent. Si vous corrigez une spécification, l'ancienne réponse peut ressortir de la mémoire au tour suivant. La solution est de purger régulièrement le magasin en développement, et de ne l'activer en production que quand la stabilité des données le justifie.

Notre fil rouge : quelle mémoire activer ?

Pour la rédaction d'une documentation en une seule exécution, la mémoire courte suffit largement. Elle stabilise la qualité quand plusieurs sections partagent des tournures. La mémoire longue et la mémoire d'entités n'apportent rien pour une exécution unique et coûtent des jetons pour rien.

Pour un projet où la même équipe documente plusieurs produits successifs en réutilisant un glossaire et des conventions, la mémoire longue devient pertinente : elle rappelle les décisions éditoriales prises sur les produits précédents.

Le geste qui économise en développement

Désactivez memory tant que vous n'avez pas mesuré son utilité. Activez-la une fois que vous avez une exécution de référence stable. Vous verrez très vite, en comparant les traces, ce que la mémoire apporte réellement — et ce qu'elle coûte.

En résumé

• CrewAI expose trois mémoires : courte (une exécution), longue (persistante) et d'entités (objets nommés) ; toutes s'activent via memory=True.
• La mémoire n'est pas un substitut au paramètre context=[…] : le contexte est toujours vu, la mémoire est retrouvée par recherche.
• Une exécution avec mémoire cumule coût, latence et risque de qualité liés à un contexte qui enfle ; désactivez-la par défaut, activez-la sur cas précis.
• La mémoire longue persiste sur disque sans gestion de permissions ni invalidation automatique : à isoler par projet et à purger pendant le développement.

Module suivant : le coût, la latence et les limites structurelles de l'approche multi-agents.