Mémoire des agents IA : Build vs Buy

Développez votre propre système de mémoire lorsque votre schéma de récupération est simple et stable : une table Postgres avec quelques colonnes typées et un filtre de fraîcheur surpassera une intégration de plateforme, aussi bien en coût qu'en débogage. N'achetez une couche de mémoire managée que lorsque vous avez de nombreux utilisateurs, chacun accumulant son propre graphe de mémoire à long terme, et que vous n'avez plus de temps d'ingénierie disponible pour gérer vous-même la décroissance, la résumé et la logique de classement.

La « mémoire des agents » est devenue une catégorie très encombrée en un temps record : chaque fournisseur d'agents IA propose désormais un produit de « mémoire », et chaque fondateur développant un agent se demande s'il en a besoin. La réponse honnête est que la plupart des équipes confondent trois problèmes très différents et finissent par acheter une plateforme pour un problème qu'une seule table SQL aurait résolu.

Ce que « mémoire » signifie réellement pour un agent

Au-delà du marketing, la mémoire d'un agent se réduit à l'un de ces trois éléments :

• État de session : ce qui s'est passé dans cette conversation. C'est simplement de la gestion de fenêtre de contexte, pas de la mémoire. N'achetez rien pour ça.
• Faits structurés : le niveau d'abonnement d'un utilisateur, ses cinq dernières commandes, une préférence exprimée une fois. C'est un problème de base de données avec une clé de recherche.
• Rappel émergent : l'agent remonte quelque chose de pertinent que personne n'a indexé explicitement, des semaines après qu'il ait été mentionné, classé par pertinence et fraîcheur. C'est la seule partie qui soit véritablement difficile.

La plupart des produits qui se demandent « avons-nous besoin de mémoire pour notre agent » parlent en réalité du deuxième cas — et ce deuxième cas, c'est une table facts avec les colonnes user_id, type, value et updated_at. Aucune plateforme n'est nécessaire.

Les arguments en faveur du développement en interne

Si vos appels à la mémoire sont prévisibles, développez votre propre solution. Un schéma typique comprend une table Postgres indexée par utilisateur ou locataire, un enum type pour la catégorie de fait, une colonne JSON value, et pgvector sur un champ résumé pour les cas où vous avez réellement besoin d'une recherche sémantique plutôt que d'une correspondance exacte. Consultez la documentation PostgreSQL sur JSONB et pgvector pour les primitives.

L'avantage n'est pas seulement financier — c'est aussi la maîtrise. Lorsque la mémoire dysfonctionne (un agent remonte un fait obsolète, ou oublie quelque chose qu'il aurait dû retenir), vous devez pouvoir exécuter un SELECT * FROM facts WHERE user_id = ... et voir exactement ce qui est stocké et pourquoi cela a été récupéré ou non. Avec une plateforme managée, cela devient un ticket de support. Nous avons constaté le même principe dans nos propres travaux sur les appels uniques vs les chaînes d'agents : moins il y a de couches d'indirection entre votre code et le store sous-jacent, plus vous diagnostiquez rapidement pourquoi un agent a eu un comportement inattendu.

Le développement en interne s'impose également lorsque :

• Vous avez un schéma de récupération principal (par utilisateur, par conversation, par entité) plutôt qu'une recherche ouverte de type « trouvez tout ce qui est pertinent ».
• Le volume de données par utilisateur est faible (quelques dizaines à quelques centaines de faits), de sorte qu'un filtrage brute-force surpasse un moteur de classement spécialisé.
• Vous utilisez déjà Postgres et ne souhaitez pas ajouter un autre fournisseur à votre liste d'évaluation de fournisseurs d'agents IA.

Les arguments en faveur de l'achat

Les plateformes de mémoire managée se justifient lorsque le problème de récupération devient véritablement ouvert : de nombreux utilisateurs, chacun avec un graphe de mémoire large et croissant, où l'agent doit déterminer quels souvenirs sont pertinents pour le tour en cours sans que vous ayez à écrire cette logique de classement vous-même. C'est un vrai problème d'ingénierie impliquant des fonctions de décroissance, la résolution de contradictions (la préférence de l'utilisateur a changé — quel fait l'emporte ?), et la résumé des anciens souvenirs en souvenirs compressés pour que le graphe ne croisse pas indéfiniment.

Optez pour l'achat lorsque :

• Vous opérez des agents multi-locataires à l'échelle grand public, où le volume de mémoire par utilisateur continuera de croître indéfiniment.
• Vous avez besoin d'une résumé ou d'un oubli automatique, et le développer correctement représente plusieurs semaines de travail que vous n'avez pas.
• La différenciation de votre équipe réside dans l'expérience produit, et non dans l'infrastructure de mémoire, et la tarification de la plateforme est réellement moins coûteuse que le temps d'ingénierie nécessaire pour la reproduire.

Le risque côté achat rejoint ce que nous avons écrit sur l'auto-hébergement des LLM vs le coût API et la conformité : vous échangez un coût de développement ponctuel contre des frais récurrents à l'appel ou à l'utilisateur, plus une dépendance dont vous ne contrôlez pas la feuille de route. Lisez le comportement réel de récupération et de classement du fournisseur avant de vous engager — de la même façon que vous liriez les évaluations dans un contrat fournisseur IA avant de signer.

Un schéma qui se généralise : adaptez l'outil à la forme de la récupération

Nous avons rencontré cette même question build-vs-buy sur notre propre agent de prospection, qui analyse le site de chaque prospect et rédige un e-mail personnalisé. Au départ, nous avons envisagé un pipeline en plusieurs étapes avec une étape de mémoire distincte pour suivre ce qu'il avait déjà appris sur une entreprise d'une exécution à l'autre. Il s'est avéré qu'un schéma à appel unique, avec les faits extraits passés directement dans le contexte, surpassait la version multi-étapes en coût comme en qualité — parce que la « mémoire » dont nous avions besoin n'était en réalité que « le dernier résultat d'extraction », et non un graphe évolutif. La leçon s'applique directement : n'utilisez pas une infrastructure conçue pour le rappel ouvert lorsque votre schéma de récupération réel est une simple recherche par clé.

Un test de décision simple

Posez-vous trois questions avant de choisir votre camp :

1. Pouvez-vous nommer la requête à l'avance ? Si vous pouvez écrire la clause WHERE aujourd'hui, développez en interne.
2. La mémoire par utilisateur va-t-elle croître sans limite ? Si oui et que vous n'avez aucun plan pour l'élaguer, acheter une logique de décroissance et de résumé vous fera gagner un temps réel.
3. Avez-vous quelqu'un pour en être responsable l'année prochaine ? Les systèmes développés en interne ont besoin d'un propriétaire. Si personne n'a la bande passante, acheter transfère cette responsabilité au fournisseur — à un coût.

La plupart des produits agents — notamment les outils B2B avec quelques centaines de faits structurés par compte — pencheront pour le développement en interne. Les produits de personnalisation à l'échelle grand public pencheront pour l'achat. Sachez lequel vous construisez avant de chercher une plateforme.

Si vous êtes en train de cadrer un agent et souhaitez un second avis pour savoir si la mémoire est même la bonne couche dans laquelle investir, parlons-en.