Mai 2026 · 11 min de lecture · Fran Olivares, fondateur d’OlivaresAI
La gestion de projet est essentiellement un travail de mémoire. Qui est en charge de ce flux ? Qu’avons-nous convenu sur la fenêtre de migration ? Pourquoi avons-nous descopé le rate limiter ? Quand la revue juridique bloque-t-elle la release ? Un agent qui doit reposer ces questions chaque matin n’est pas un agent — c’est un stagiaire légèrement plus rapide. La manière de changer cela est de donner au modèle une couche de mémoire persistante qu’il peut lire et écrire entre les tours, peuplée automatiquement depuis la conversation. Ce guide parcourt l’architecture de référence et le code d’intégration, en utilisant l’API Anthropic Claude comme LLM et la REST API d’Alma comme couche de mémoire.
Trois raisons structurelles. Premièrement, les entités qu’un PM suit (personnes, décisions, livrables, SLA, risques) sont elles-mêmes de longue durée — elles survivent par définition à toute conversation isolée. Deuxièmement, le style conversationnel est à haute fréquence et faible effort : courts messages de stand-up, clarifications rapides, questions « qu’avons-nous dit sur X ? ». Charger la bonne tranche de contexte à bas coût compte. Troisièmement, le coût d’oublier est élevé : une décision manquée devient une release manquée, une dépendance oubliée devient un blocage.
Une conversation Claude sans état gère bien une seule session de planification. Dès que l’utilisateur veut de la continuité (« hier nous avons convenu… », « qu’est-ce qui bloque l’équipe auth cette semaine ? »), la conversation doit soit rejouer l’historique complet dans la fenêtre de contexte (coûteux, à terme impossible), soit s’appuyer sur une couche mémoire à l’extérieur du modèle.
Quatre pièces mobiles :
messages.create du SDK Anthropic avec un prompt système conscient du projet. L’usage d’outils est activé pour que le modèle puisse demander à la couche mémoire des entités par nom au besoin.stakeholder, decision, sla, risk) et un score d’importance. Les épisodes capturent les stand-ups quotidiens compressés ; les procédures capturent les workflows récurrents (« la manière dont nous gérons les hotfixes »).Cinq catégories couvrent la plupart des équipes : stakeholder (personnes avec rôle + responsabilités), decision (ce qui a été convenu, quand, par qui, avec le raisonnement), sla (engagements envers d’autres équipes ou clients), risk (problèmes ouverts avec propriétaire + atténuation), milestone (date cible + scope + statut). Chaque mémoire porte un score d’importance pour que l’assembleur puisse prioriser les éléments à forts enjeux dans la récupération.
La catégorie n’est pas que pour l’organisation — elle fait partie du signal de récupération. Quand l’utilisateur demande « qu’avons-nous décidé ? », l’assembleur pondère plus haut les mémoires de catégorie decision. Quand il demande « qui est bloqué ? », les mémoires de catégorie risk remontent. L’ assemblage de contexte d’Alma expose des poids de boost par catégorie pour exactement ce cas d’usage.
Trois phases par message utilisateur. Le pseudo-code ci-dessous utilise Node.js avec le SDK Alma et le SDK Anthropic, mais la même forme fonctionne en Python ou dans n’importe quelle autre stack :
const { systemPrompt } = await alma.context.assemble({ query: userMessage, environmentId: projectId });const stream = anthropic.messages.stream({ model: 'claude-opus-4-7', system: systemPrompt, messages: [{ role: 'user', content: userMessage }] });await alma.memories.extract({ text: lastTurn, environmentId: projectId });La phase 3 tourne en arrière-plan — l’utilisateur voit la réponse streamée immédiatement, et l’extraction se fait dans la ~1 s suivante sans bloquer. Les nouvelles mémoires sont dédupliquées, les contradictions sont détectées contre les entrées existantes et le stockage reste propre automatiquement. Référence complète du SDK : @olivaresai/alma-sdk; équivalents HTTP dans la documentation de la REST API.
Utilisez les environnementsAlma : un environnement par projet. Chaque environnement a ses propres mémoires, épisodes, procédures et blocs Soul, complètement isolés des autres. L’agent passe environmentId à chaque appel mémoire ; l’API applique la frontière. Les requêtes inter-projets ne sont simplement pas possibles sans un changement explicite d’environnement — ce qui est le bon défaut pour un outil PM où faire fuiter des décisions du projet A vers le projet B est un vrai problème.
Pour les agents PM à l’échelle de l’équipe (plusieurs humains interagissant avec le même agent), utilisez la ressource teams d’Alma : chaque équipe a des mémoires partagées visibles par tous les membres, plus des mémoires par utilisateur pour les préférences personnelles. Les contrôles d’accès basés sur les rôles déterminent qui peut écrire quoi.
Message utilisateur : « stand-up : équipe backend, Maria débloque la migration aujourd’hui, José est sur le rate limiter ; nous avons décidé de pousser la release GA à vendredi parce que le juridique relit encore le DPA ». Le flux de l’agent :
Archéologie de décisions. « Pourquoi avons-nous descopé le rate limiter ? » — l’agent récupère la mémoire de décision plus l’épisode environnant et la mémoire de risque qu’elle référençait. Renvoie la réponse avec des citations des enregistrements, pour que l’utilisateur puisse plonger dans la conversation au besoin.
Recherche de partie prenante. « Qui est en charge de la migration ? » — requête mémoire directe contre la catégorie stakeholder , renvoie l’enregistrement. Si la réponse est obsolète (le rôle a changé la semaine dernière), la détection de contradictions la rattrape à la prochaine conversation qui mentionne le nouveau propriétaire.
Génération de rapports récurrents. « Génère un rapport de statut pour le flux auth cette semaine » — l’agent assemble une fenêtre de contexte d’épisodes, de décisions et de risques étiquetés pour ce flux, puis rédige le rapport à partir de cette tranche soignée. C’est nettement moins cher et plus précis que de demander à Claude de résumer l’historique de chat brut.
Budgets de tokens par défaut dans l’assembleur : ~2 K tokens pour les mémoires, ~1 K pour les épisodes, ~500 pour les procédures, ~500 pour les blocs Soul. Total ~4 K — bien en dessous du budget de contexte de tout modèle, et les hits de cache s’amortissent à travers la conversation. Si votre projet est petit (<100 active memories), you can lower the budget further. If it's large (10 K+ memories), the assembler stays at ~4 K because retrieval limits the number of records included even when the store is big.
Deux choses comptent opérationnellement : les blocs Soul (l’identité de l’agent) doivent être mis en cache comme préfixe de prompt système stable pour que les appels répétés ne re-paient pas les tokens d’entrée ; et le contexte dynamique (mémoires + épisodes) doit se trouver après le breakpoint du cache pour que chaque appel ne réuploade que la partie modifiée. La documentation de prompt-caching d’Anthropic couvre le placement du breakpoint.
Sur un flux d’équipe PM typique (~20 messages/jour par utilisateur, principalement stand-ups + clarifications), le coût marginal est dominé par les appels LLM eux-mêmes. La couche mémoire ajoute : un appel assemble (quelques Ko en lecture + récupération, ~30 ms), un appel extract (Haiku, ~$0,001 par tour). Surcoût mémoire total par jour par utilisateur actif : bien en dessous d’un centime. Comparez à la valeur d’une équipe PM qui ne perd pas de décisions — et le calcul est évident.
Le plan Starter d’Alma ($14/mois) est l’offre d’entrée et inclut la couche de mémoire persistante. Inscrivez-vous sur alma.olivares.ai, générez une clé API dans Settings et clonez le starter SDK depuis la page développeurs. Câblez la boucle en trois phases dans le code de votre agent, pointez-la sur un seul projet de test et faites-la tourner une semaine. Le stockage se peuplera naturellement à partir des conversations ; vous verrez décisions, parties prenantes et risques s’accumuler sans saisie manuelle. De là, il suffit d’étoffer les catégories et d’ajuster l’assembleur.
Lecture associée : Persistent Memory for AI: Complete 2026 Guide · Comment donner à l’IA une mémoire persistante · Architecture de mémoire à trois couches · Documentation Context Assembly · Environnements.