Un agent IA n’a pas de mémoire. Chaque session Claude Code repart de zéro : ce qui n’est pas écrit quelque part sur le disque n’existe pas pour lui.

Sur Citios, j’ai réglé ça autrement qu’en cherchant un outil miracle. Deux décisions d’abord — tout ranger dans une arborescence de dossiers, n’écrire qu’en markdown — puis, seulement ensuite, adopter l’Open Knowledge Format pour rendre cette mémoire interrogeable. C’est ce que j’appelle mon company brain. Premier article d’une série sur la mémoire des agents.

Partie 1 — Le problème : mes agents ne se souviennent de rien

Sur mon projet Citios-agent — le dépôt qui centralise toute l’activité de mon CTO à la demande (clients, admin, marketing, veille) — j’ai vite pris l’habitude de tout consigner par écrit. Le problème n’était donc pas l’oubli, mais autre chose : comment organiser cette mémoire pour qu’un agent la retrouve vite, et juste ?

Le symptôme était visible dans mon propre fichier d’instructions : une liste à jour à la main de mes dossiers, avec leur description, à maintenir manuellement à chaque changement. Une mémoire non structurée, dupliquée entre plusieurs fichiers, et surtout pas interrogeable — impossible de demander « liste-moi tous mes clients » sans que l’agent rouvre chaque dossier un par un pour deviner ce qui est pertinent.

Partie 2 — La fondation : des dossiers, et rien que du markdown

Avant même de parler d’un format ou d’un standard, deux décisions plus simples ont posé les bases de ce company brain — le cerveau numérique de mon activité, la mémoire d’entreprise que mes agents consultent en permanence.

Décision 1 — Tout ranger dans une arborescence de dossiers qui reflète l’activité réelle. Un dossier par grand domaine (clients, administration, marketing, veille, historique des travaux), et à l’intérieur, un sous-dossier par sujet concret (un client, un mois de comptabilité, un article). C’est le même principe qu’un classement physique en classeurs : le nom du dossier répond directement à la question « où est-ce que je range ça ? », et surtout « où est-ce que je vais le retrouver ? ». Rien de technique là-dedans — c’est simplement de l’ordre, appliqué avec discipline.

Décision 2 — Écrire exclusivement en markdown, plutôt qu’en Word, Google Docs ou Notion. Le markdown, c’est du texte brut avec une mise en forme minimale (des titres avec #, des listes avec -, du gras avec **). Rien d’autre. Trois raisons à ce choix :

  • Lisible par tout le monde et tout outil, sans logiciel propriétaire ni conversion — un humain, un moteur de recherche ou un agent IA l’ouvrent de la même façon.
  • Versionnable comme du code : chaque modification est tracée dans Git, avec un historique complet de qui a changé quoi et quand — impossible avec un fichier Word ou une page Notion.
  • Zéro friction pour un agent : Claude Code lit un fichier .md nativement, sans plugin, sans export, sans API tierce à interroger.

Ces deux décisions — arborescence + markdown exclusif — sont le socle. Elles suffisent déjà, à elles seules, à donner une vraie mémoire à un agent : il sait où chercher (la structure de dossiers) et il sait lire ce qu’il trouve (du texte simple). C’est sur ce socle que vient ensuite se greffer un format plus structurant : l’Open Knowledge Format.

Partie 3 — Open Knowledge Format, en une page

En cherchant comment aller plus loin que « des dossiers et des fichiers texte », je suis tombé sur l’Open Knowledge Format (OKF) : une spécification ouverte publiée par Google Cloud en juin 2026, qui formalise ce que beaucoup appellent le pattern « LLM-wiki ». Ce n’est pas un produit, pas un SDK, pas une base de données — juste une convention qui vient en complément de la structuration en dossiers et de l’usage du markdown, pas en remplacement.

Le principe tient en trois règles :

  • Un fichier = un concept. Le chemin du fichier est son identité.
  • Un bloc d’information en tête de chaque fichier (le « frontmatter »), avec un seul champ obligatoire : type. Tout le reste (catégories, champs additionnels) est laissé libre.
  • Un dossier = un bundle, distribuable en dépôt git, avec un index.md optionnel qui énumère son contenu pour qu’on puisse le découvrir avant d’ouvrir chaque fichier.

Ce qui m’a convaincu : ça ne demande aucun outillage supplémentaire. Si Claude Code sait déjà lire des fichiers markdown rangés en dossiers, il sait déjà lire de l’OKF. Point de vigilance honnête : c’est une spec v0.2, très jeune, portée par Google seul pour l’instant — pas encore d’adoption large ni d’outillage tiers mûr. Mais la simplicité du format fait qu’il n’y a presque rien à perdre à l’adopter.

Partie 4 — Comment j’ai structuré citios-agent

Avant, mon projet ressemblait à ça : des dossiers bien rangés en markdown (la fondation de la partie 2), chacun avec un fichier _nom-du-dossier.md expliquant en prose ce qu’on y trouvait, mais sans information structurée, et sans hiérarchie de navigation exploitable par un agent.

La cible OKF, c’est :

  • Un index.md à la racine du projet qui cartographie l’ensemble :
## Business

* [Clients](/clients/index.md) - Portefeuille clients, un sous-dossier par client et par mission.
* [Contacts](/contacts/index.md) - Contacts et prospects en cours.
* [Marketing](/marketing/index.md) - Assets, concurrents, LinkedIn, articles du site.
  • Un frontmatter systématique sur chaque fichier concept, par exemple une fiche client :
---
type: Client
title: Client Clovis
description: Fiche client Clovis (SaaS de gestion documentaire et de chantier pour le BTP) — mission CTO à temps partagé, stack technique, équipe et points de vigilance.
tags: [clovis, cto, btp, saas]
status: stable
---
  • Un index.md par dossier qui remplace les anciens _nom.md, avec la même information mais sous forme de sommaire navigable et lié.

Partie 5 — Les opérations de mise en conformité

Concrètement, la bascule a porté sur une centaine de fichiers markdown répartis dans tout le projet. Pour aller vite sans perdre en qualité, j’ai fait traiter les gros dossiers (admin, clients, knowledges, marketing, works) en parallèle, chacun avec la même consigne : lire le fichier en entier, choisir un type pertinent (Client, Bilan, Article LinkedIn, Article Web, Project Note, Prompt, Report…), écrire une description fidèle au contenu réel — jamais devinée depuis le nom du fichier — et ne jamais toucher au corps du document.

Deuxième chantier : remplacer les anciens fichiers _admin.md, _clients.md, _contacts.md, _marketing.md, _works.md par de vrais index.md, en réinjectant tout leur contenu explicatif (conventions de nommage, liens externes) plutôt que de le perdre dans un simple listing.

Le point de vigilance rencontré en cours de route : tous les fichiers préfixés _ ne sont pas des sommaires. knowledges/linkedin/_linkedin.md, par exemple, est en réalité une synthèse de plus de cent lignes — un concept à part entière, pas un index. L’avoir converti en liste de liens aurait fait perdre du contenu. La bonne réaction a été de le laisser tel quel et de lui ajouter un index.md voisin pour la navigation, sans y toucher.

Résultat mesurable : je peux désormais faire une recherche sur type: Client ou status: draft dans tout le dépôt et obtenir une réponse exacte en une commande, là où il fallait auparavant ouvrir les dossiers un par un.

Partie 6 — Les skills pour exploiter cette mémoire

Structurer la mémoire ne suffit pas : encore faut-il documenter comment l’interroger, pas seulement où elle se trouve. C’est le rôle des skills Claude Code — le même principe que celui que j’applique déjà autour de BB-DEV et BB-LOG : borner l’agent, lui dire où chercher, lui interdire de réinventer la méthode.

J’ai créé une première skill, citios-client, dont le seul rôle est d’expliquer à l’agent la méthode pour lister les clients du projet : d’abord lire clients/index.md pour une réponse rapide, sinon requêter directement le frontmatter, en excluant explicitement les modèles et les fiches archivées.

Le pattern est généralisable : une skill par type de requête récurrente sur la mémoire (clients, contacts, chantiers en cours, veille à jour…), chacune codifiant la bonne source à consulter et les pièges à éviter — plutôt que de laisser l’agent réinventer sa méthode de recherche à chaque session.

Partie 7 — Ce que ça change concrètement

Le point d’arrivée, c’est que je peux maintenant interroger mon propre agent en langage naturel plutôt que d’aller rouvrir des fichiers moi-même :

  • « Quel est le chiffre d’affaires de Citios ? » — l’agent repère les huit bilans mensuels via type: Bilan, puis lit chaque fichier pour en extraire les montants facturés.
  • « Combien de clients en 2026 ? » — l’agent liste les fiches type: Client référencées dans clients/index.md.
  • « Quels sont les contacts à relancer ? » — la question type que je veux pouvoir poser une fois que contacts/ sera aussi peuplé et structuré que clients/ : aujourd’hui ce dossier n’est encore qu’un squelette, c’est la prochaine case à cocher.

La bascule tient en une phrase : avant cette mise en ordre, ces réponses demandaient de rouvrir des fichiers dispersés sans convention commune ; maintenant l’agent sait où chercher et quoi lire, et moi je n’ai plus qu’à poser la question.

Suite de la série

Cet article est le premier d’une mini-série sur la mémoire des agents. La prochaine étape : construire un vrai wiki (LLM-Wiki) à partir de ce company brain, pour le rendre consultable au-delà de Claude Code lui-même.

Si vous voulez poser le même type de mémoire sur votre activité — ou simplement en discuter — contactez-moi.