Donner une mémoire et du contexte à l’agent

Un modèle démarre chaque session sans rien savoir de votre entreprise. Tout ce qu’il doit savoir vient de trois endroits : ce qu’il lit à chaque démarrage, ce qu’il peut aller chercher quand la tâche l’exige, et ce qu’il a appris la dernière fois et que quelqu’un a écrit. Quand un agent dérive, la cause est le plus souvent sa mémoire : le même fait existe dans quatre fichiers avec trois valeurs différentes, ou une leçon a été notée là où personne ne la lit. Le remède est une règle d’organisation : chaque fait vit à un seul endroit, au niveau le plus bas partagé par tout ce qui s’en sert, et tout le reste pointe vers lui.

Triez ce que l’agent doit savoir

Prenez l’agent que vous construisez et listez ce dont il a besoin. Rangez ensuite chaque élément dans l’une de ces trois colonnes.

Toujours chargé	Consulté à la demande	Jamais dans le contexte
Le rôle, le périmètre, les règles à ne jamais enfreindre	Les faits produit et les prix	Clés API et mots de passe
Où vit chaque type de fait	La liste clients, le CRM	Des données personnelles brutes dont il n’a pas besoin
Le format de sa sortie	Les résultats passés, le registre des leçons	Des exports complets quand un condensé suffit
Les contrôles avant toute sortie	Des exemples de style pour la tâche en cours	Tout ce qu’on ajoute « au cas où »

La première colonne doit rester courte : elle se paie à chaque session et dispute l’attention du modèle à la tâche elle-même. Un bon test : si une ligne ne sert qu’à une tâche sur dix, elle va dans la deuxième colonne, derrière un renvoi du type « avant de citer un prix, lis facts/pricing.md ». La façon d’écrire cette première colonne fait l’objet du chapitre sur le rôle, les règles et les exemples.

Dans Claude Code, la couche toujours chargée, ce sont les fichiers CLAUDE.md : un dans votre dossier personnel pour tout, un par projet, un par sous-dossier si besoin, lus dans cet ordre à l’ouverture d’une session. La documentation sur la mémoire (en anglais) explique comment ils se combinent. Les autres outils ont un équivalent ; le principe reste le même.

Une seule source de vérité par domaine

Voici la règle que j’applique dans toute mon organisation d’agents : un fait vit au niveau le plus bas partagé par tous les agents qui s’en servent, les niveaux au-dessus pointent vers lui, et rien n’est copié. Les faits produit utilisés par les agents SEO, LinkedIn et outbound vivent dans un seul fichier à la racine, parce que les trois s’en servent. Les règles de publication SEO vivent dans le dossier SEO, parce que seul le SEO les utilise.

company/
  CLAUDE.md               # qui nous sommes, où vit chaque domaine (renvois seulement)
  facts/
    product.md            # features, prix, formulations interdites : un responsable, daté
    customers-public.md   # ce qu'on peut dire des clients
  seo/
    CLAUDE.md             # règles SEO, renvoie à facts/product.md
    agents/
      head-of-seo.md      # rôle, règles, leçons devenues règles
    ledger.md             # expériences et verdicts, datés
  linkedin/
    CLAUDE.md
    voice.md              # calibrage de la voix, formulations interdites

Ce sont les copies qui tuent. Quand un prix change et qu’il était écrit à cinq endroits, quatre agents continuent de citer l’ancien, et ils le font avec un aplomb total. Avec un fichier et des renvois, vous changez une ligne et chaque agent lit la nouvelle valeur au prochain démarrage.

Chaque fichier de faits porte une date de dernière vérification et un responsable. Un fait sans date est un fait dont vous ne pouvez pas savoir s’il est périmé.

Calculez ce qui peut se calculer

Certains faits ne devraient pas être écrits du tout. Un nombre de features, de pages, de clients bouge, et un nombre tapé dans un fichier est faux le lendemain du changement. Chez moi, les totaux ne sont jamais écrits en dur : un script les calcule depuis la source, et un contrôle vérifie qu’une feature existe avant qu’un contenu la cite. Votre version peut être minuscule :

# Échoue si l'article cite une feature absente du catalogue
for slug in $(grep -o '/features/[a-z0-9-]*' draft.md | cut -d/ -f3 | sort -u); do
  grep -q "\"$slug\"" data/features.json || echo "Unknown feature: $slug"
done

Les instructions disent alors « pour donner le nombre de features, lance le script de comptage » au lieu de donner un nombre. L’agent fait un appel d’outil de plus et ne cite jamais un chiffre périmé.

Donnez des condensés, pas des fichiers bruts

Un CSV de 40 Mo, un mois de logs ou un dump complet de base n’ont rien à faire dans le contexte. Le modèle en lit une partie, se noie dans le reste et répond avec assurance sur des lignes qu’il n’a jamais vues. Mes agents lisent un condensé : un résumé court produit par un script, avec la structure, les totaux et les lignes qui comptent, une fois les secrets et les données personnelles retirés, avant que le modèle ne voie quoi que ce soit.

Voici la forme d’un condensé, avec des chiffres inventés :

digest: search_console_export
rows: 18,240 (pages x queries)
total_clicks: 12,906   # à comparer au total de l'interface avant usage
columns: page, query, clicks, impressions, position
top_pages_by_clicks: [10 rows]
pages_with_zero_clicks: 312
redacted: none needed (no personal data in this export)

Le commentaire de la troisième ligne n’est pas là par hasard : le 5 novembre 2026, l’agent Head of SEO de cette organisation a découvert qu’un de ses propres exports ne comptait qu’environ un tiers des clics réels (l’histoire complète). Un condensé qui affiche son total à côté d’un total de référence rend ce genre d’écart visible dès la première lecture.

Faites en sorte que les leçons restent

Un agent qui refait deux fois la même erreur en a été informé au mauvais endroit. J’utilise deux niveaux. Un registre consigne chaque leçon avec sa date et son contexte : ce qui s’est passé, comment on l’a vu, ce qui a changé. Quand une leçon est durable, elle est écrite directement dans les instructions de l’expert concerné, sous forme de règle. Un rappel n’est pas une action : une note qui dit « attention aux exports » ne change rien, une règle dans les instructions change la prochaine exécution.

Entrée du registre	Règle qu’elle devient dans les instructions
2026-11-05 : l’export ne comptait que les clics à requête nommée, environ un tiers du total	Avant de combiner deux exports, vérifier que leurs totaux concordent. S’ils diffèrent, s’arrêter et le signaler.
2026-11-05 : une routine a modifié des pages en cours de test	Avant de modifier une page, lire la liste des pages en test et les ignorer.

La deuxième ligne est réelle elle aussi : déclarer les pages en test ne servait à rien tant que la routine qui modifiait les pages ne lisait pas la déclaration. Une règle que rien ne lit équivaut à pas de règle.

Protégez la mémoire elle-même

La mémoire est devenue un actif : traitez-la comme tel. Jusqu’au 9 novembre 2026, toute mon organisation d’agents existait en un seul exemplaire, sur un seul ordinateur portable (le chapitre sécurité montre comment elle est protégée aujourd’hui). Faites-le avant d’en avoir besoin : versionnez les fichiers d’instructions et de faits, gardez-en les données personnelles à l’écart, et relisez les modifications quand un agent édite ses propres instructions.

Votre prochaine étape : listez chaque fait sur lequel s’appuie votre agent, notez où chacun est écrit aujourd’hui, et pour chaque fait présent à plus d’un endroit, gardez une seule copie, datez-la, et remplacez les autres par un renvoi.