Anthropic Memory tool 2026 : agents Claude à mémoire persistante pour PME

Vos agents Claude oublient tout entre deux conversations. C’est la limitation structurelle d’un LLM stateless : chaque appel API repart de zéro, le contexte ne survit pas. Le Memory tool d’Anthropic, disponible en 2026 avec le tag memory_20250818, change cette équation — sans déléguer le stockage à un fournisseur tiers. Voici comment il fonctionne, ce qu’il permet à une PME de construire concrètement, et les 3 pièges sécurité à anticiper avant la mise en production.

Ce que le Memory tool fait — et ce qu’il ne fait pas

Le Memory tool est un outil natif Anthropic que vous exposez à Claude via le champ tools de l’API Messages. Quand il est actif, Claude peut décider d’appeler 6 commandes pour gérer un répertoire /memories :

Commande	Effet	Cas d’usage typique
view	Lire un fichier ou lister un répertoire (jusqu’à 2 niveaux de profondeur)	Récupérer le contexte d’une session précédente
create	Créer un nouveau fichier	Sauver un brief client, un état projet
str_replace	Remplacer un texte précis dans un fichier	Mettre à jour un statut, corriger une décision
insert	Insérer du texte à une ligne donnée	Ajouter une étape dans un journal de progression
delete	Supprimer un fichier ou un répertoire	Nettoyer une mémoire obsolète
rename	Renommer ou déplacer	Promouvoir un brouillon en version finale

Point critique : le Memory tool est client-side. Claude n’écrit rien, lui-même : il émet des appels d’outil, et c’est votre code (votre serveur, votre filesystem, votre base de données) qui les exécute. Anthropic ne stocke aucune donnée mémoire — vous gardez 100 % de la main sur le où, le comment et le combien de temps.

C’est une différence importante avec deux autres briques Anthropic récentes :

• Claude Managed Agents (public beta, 2026) : Anthropic héberge l’état côté serveur, facturation à 0,08 $/heure de session active. Plus simple à démarrer, moins flexible.
• Anthropic Files API : stockage de documents pour usage en référence dans les conversations, sans état persistant inter-conversations.

Pour bien situer le Memory tool dans l’écosystème, voir notre analyse MCP Model Context Protocol (le standard de connexion outils) et Computer use et Agent SDK pour PME (l’orchestration agentique).

Architecture client-side : qui fait quoi

flowchart LR
  accTitle: Architecture Memory tool — flux client-side
  accDescr: Claude émet les appels d'outil mémoire ; l'application cliente exécute les opérations sur son propre filesystem ou base de données
  A([Utilisateur PME]) --> B[Application cliente\nNode.js / Python / Java]
  B -->|API Messages\n+ tools: memory_20250818| C[Anthropic API]
  C -->|tool_use: view /memories| B
  B -->|tool_result: contenu /memories| C
  C -->|réponse texte| B
  B --> D[(Filesystem local\nou S3 / DB chiffrée)]
  B --> A
  
  style C fill:#fef3c7,stroke:#f59e0b,color:#000
  style D fill:#dbeafe,stroke:#2563eb,color:#000

Le flux concret sur une session typique :

1. Utilisateur envoie une requête à votre application.
2. Votre application appelle messages.create avec tools: [{type: "memory_20250818", name: "memory"}].
3. Claude décide d’inspecter sa mémoire : il émet un tool_use avec command: "view", path: "/memories".
4. Votre application reçoit ce tool_use, exécute la lecture sur votre filesystem, et renvoie le contenu dans un tool_result.
5. Claude lit le résultat et continue son raisonnement, éventuellement en appelant d’autres commandes (view sur un fichier précis, puis str_replace pour mettre à jour un statut).

Anthropic fournit en avril 2026 des helpers SDK officiels pour Python (BetaAbstractMemoryTool à subclasser) et TypeScript (betaMemoryTool). Ces helpers gèrent la sérialisation et le format de retour standardisé attendu par Claude. Vous gardez le contrôle de l’implémentation du backend (filesystem, S3, base chiffrée).

3 cas d’usage PME concrets en 2026

Cas 1 — Agent SAV avec mémoire client persistante

Contexte : éditeur SaaS B2B, 200 tickets/jour, équipe support de 4 personnes.

Sans Memory tool : à chaque nouveau ticket, l’agent IA repart de zéro. Il doit relire l’historique du compte, les tickets précédents, les préférences client — soit autant de tokens à charger en contexte initial.

Avec Memory tool : pour chaque client, vous maintenez un fichier /memories/clients/{client_id}.md qui contient : préférences contact, niveau d’expertise technique, historique des frustrations, mots à éviter, mots-clés du domaine. Quand un nouveau ticket arrive, votre application charge ce fichier en view, et Claude entre directement dans la résolution avec le bon ton et le bon contexte.

Économie typique :

• Sans mémoire : 8 000 tokens/ticket × 200 tickets/jour × 30 j = 48 M tokens/mois
• Avec mémoire : 2 000 tokens/ticket (mémoire + ticket courant) = 12 M tokens/mois
• Soit −75 % d’input tokens, donc une économie pas négligeable au tarif Sonnet 4.6.

Combiné au prompt caching, l’économie peut atteindre −85 % du coût input sur ce profil.

Cas 2 — Agent dev qui apprend des PRs validées

Contexte : équipe dev de 6 personnes, agent Claude Code utilisé comme assistant de revue de PR et générateur d’issues.

Sans Memory tool : l’agent ne sait pas quelles conventions ont été validées dans les PRs précédentes. Il propose à chaque fois ses propres patterns, parfois en contradiction avec les choix internes.

Avec Memory tool : un fichier /memories/conventions/code-style.md mis à jour automatiquement après chaque PR mergée. Un fichier /memories/conventions/architecture-decisions.md qui sert d’ADR vivant. Un fichier /memories/sessions/progress.md qui survit aux compactions de contexte.

Le pattern multi-session documenté par Anthropic dans Effective harnesses for long-running agents consiste à :

1. Session 0 (initializer) : créer un progress.md (état du projet) et un features.md (scope).
2. Sessions suivantes : view /memories/progress.md en premier appel pour reprendre exactement où la session précédente s’est arrêtée.
3. Fin de session : update du progress.md avec ce qui a été fait + ce qui reste.

C’est le pattern le plus puissant pour les workflows agentiques de plus de 4 heures cumulées.

Cas 3 — Agent commercial qui maintient un CRM allégé

Contexte : SaaS B2B en early stage, pas encore de CRM Salesforce ou HubSpot, 80 prospects actifs.

Sans Memory tool : chaque appel utilise un context dump Notion, lent et imprécis.

Avec Memory tool : un fichier /memories/prospects/{prospect_id}.md par prospect, structuré ainsi :

# {Prospect Name}
- Statut : qualifié / en négociation / signé / perdu
- Stack actuelle : ...
- Pain points : ...
- Décideur : ...
- Dernière interaction : 2026-04-22 — call de qualification
- Actions ouvertes : envoyer benchmark Sonnet 4.6 vs Mistral
- Notes décisives : refuse les fournisseurs hors EU

L’agent peut être invoqué avant chaque call avec un simple “Prépare-moi le call avec Acme Corp” et ressortira un résumé structuré + les questions à poser.

Pour les PME qui ont des contraintes RGPD strictes, stockez la mémoire dans une base chiffrée (Postgres avec pgcrypto, S3 + KMS, ou filesystem chiffré LUKS). Le primitif client-side donne cette flexibilité — c’est l’un de ses arguments fondamentaux face aux Managed Agents.

Comparaison Memory tool vs alternatives 2026

Les quatre approches ne sont pas exclusives. Beaucoup de stacks PME 2026 combinent :

• Memory tool pour l’état d’agent (préférences, statut, conventions) — ~1-50 KB par entité
• RAG pour la recherche dans la documentation produit — millions de tokens
• Contexte 1M pour les requêtes ad hoc qui ont besoin du dossier complet en input — voir notre analyse contexte 1M tokens vs RAG 2026

Sécurité : les 3 risques à blinder dès le jour 1

Risque 1 — Path traversal

C’est le risque numéro un identifié par la documentation Anthropic. Si votre implémentation accepte naïvement le path envoyé par Claude, un agent compromis ou victime de prompt injection peut lire ou écrire n’importe où sur votre serveur.

Mesures obligatoires :

from pathlib import Path

MEMORY_ROOT = Path("/var/app/memories").resolve()

def safe_resolve(user_path: str) -> Path:
    candidate = (MEMORY_ROOT / user_path.lstrip("/memories").lstrip("/")).resolve()
    if not candidate.is_relative_to(MEMORY_ROOT):
        raise ValueError(f"Path traversal attempt: {user_path}")
    return candidate

Rejeter aussi les séquences URL-encodées (%2e%2e%2f = ../).

Risque 2 — Données sensibles écrites en mémoire

Claude refuse généralement d’écrire des données sensibles (mots de passe, numéros CB, données médicales). Mais cette protection n’est pas absolue. Pour les PME en environnement RGPD ou santé, ajoutez une couche de filtrage dans votre implémentation :

• Liste de regex bloquantes (numéros de carte bancaire, IBAN, NIR, etc.)
• Audit log de toutes les opérations mémoire (création, modification, suppression)
• Chiffrement at-rest obligatoire si la mémoire contient des données nominatives

Risque 3 — Croissance non bornée

Sans limites, la mémoire d’un agent peut grossir sans fin et finir par dépasser le contexte quand Claude lit /memories en début de session. Mesures de cadrage recommandées par Anthropic :

• Plafond par fichier : 100 KB par défaut
• Pagination obligatoire sur view au-delà de 1 000 lignes
• Expiration : nettoyer les fichiers non accédés depuis 90 jours

Implémentation minimale en 30 lignes (TypeScript)

import Anthropic from "@anthropic-ai/sdk";
import { promises as fs } from "fs";
import path from "path";

const MEMORY_ROOT = path.resolve("/var/app/memories");

async function executeMemoryTool(input: any): Promise<string> {
  const targetPath = path.resolve(MEMORY_ROOT, (input.path ?? "/memories").replace(/^\/memories\/?/, ""));
  if (!targetPath.startsWith(MEMORY_ROOT)) {
    throw new Error("Path traversal blocked");
  }
  switch (input.command) {
    case "view": {
      const stat = await fs.stat(targetPath);
      if (stat.isDirectory()) {
        const items = await fs.readdir(targetPath);
        return items.join("\n");
      }
      return await fs.readFile(targetPath, "utf-8");
    }
    case "create": {
      await fs.writeFile(targetPath, input.file_text, { flag: "wx" });
      return `File created successfully at: ${input.path}`;
    }
    // ... str_replace, insert, delete, rename
    default:
      return `Unknown command: ${input.command}`;
  }
}

const client = new Anthropic();
const message = await client.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 2048,
  tools: [{ type: "memory_20250818", name: "memory" }],
  messages: [{ role: "user", content: "Reprends le contexte projet et propose la prochaine étape." }],
});

L’extrait ci-dessus est volontairement minimal. Une implémentation production doit ajouter le streaming, la gestion d’erreurs typées, le logging structuré, et la couche de chiffrement au repos.

Memory tool + Compaction + Context editing : le triangle long-running

Pour les agents qui doivent tenir des conversations de plus de 8 heures cumulées (recherche, audit, dev itératif), Anthropic recommande de combiner trois primitives :

• Memory tool : ce qui doit survivre inter-sessions
• Compaction : résumé serveur du conversation log quand il approche de la fenêtre context
• Context editing : suppression côté client de tool_results qui ne servent plus

Le triangle permet de tenir des sessions agentiques sans jamais perdre l’état métier critique, tout en gardant le contexte actif fluide.

Verdict pratique 2026

Le Memory tool n’est pas une révolution : c’est une primitive bien designée qui rend praticable un pattern (état agent persistant) que beaucoup d’équipes essayaient d’émuler à la main avec des hacks RAG ou des vector DBs surdimensionnées.

À adopter si :

• Vous avez un cas d’usage clair qui demande un état entre sessions (SAV, dev, sales).
• Vous voulez la maîtrise du stockage (souveraineté EU, RGPD, audit).
• Vous êtes à l’aise avec un peu de plomberie back-end.

À éviter si :

• Vous cherchez un service totalement managé clé en main → préférez Managed Agents.
• Votre besoin est en réalité de la recherche documentaire massive → préférez RAG + framework d’évaluation, voir notre framework d’évaluation LLM 6 critères.

---

À lire aussi côté écosystème agent Anthropic : MCP Model Context Protocol pour la connexion outils, Computer use et Agent SDK pour l’orchestration UI, Prompt injection : protéger vos agents pour la sécurité MCP + Memory.

Note : le Memory tool évolue rapidement. Vérifiez la documentation officielle Memory tool avant tout commit production, et testez sur Sonnet 4.6 + Opus 4.7 avant Haiku 4.5 pour évaluer la qualité d’usage de la mémoire.