Format Open Knowledge : Mémoire portable pour les agents de codage IA
Le format Open Knowledge stocke ce que les agents de codage apprennent sous forme de fichiers Markdown liés. En quoi il diffère de CLAUDE.md et MCP, et comment commencer à l’utiliser dès aujourd’hui.
Sources: Google Just Quietly Released the Missing Piece for AI Agents. It’s Called OKF.
Le format Open Knowledge est une norme conçue pour rendre la mémoire des agents portable, versionnée et lisible par tous les outils d’un écosystème de développement.
Le problème de devoir tout recommencer chaque matin
Tout ceux qui utilisent un agent de codage basé sur l’IA ont rencontré ce même obstacle. La session se termine, et le lendemain, l’agent ne sait rien. Il doit redécouvrir le processus d’authentification, deviner à nouveau les raisons derrière une décision architecturale vieille de trois ans et relire les mêmes cinq fichiers pour reconstituer un contexte qui avait pris une heure à expliquer la veille.
La solution de contournement courante consiste à utiliser un fichier CLAUDE.md ou AGENTS.md, un document de contexte lu au début de chaque session. Ce sont des outils rudimentaires : ils chargent tout à chaque exécution, que cela soit pertinent ou non, ils sont conçus pour un seul agent sur une seule plateforme et ne s’adaptent pas facilement. De plus, ils mélangent des instructions comportementales comme « écrire toujours des tests » avec des faits tels que « le tableau des commandes est joint au tableau des clients via customer_id », ce qui entraîne rapidement un désordre.
Le 12 juin 2026, Google Cloud a publié une spécification visant à combler cette lacune, appelée Open Knowledge Format, ou OKF. C’est pour l’instant la réponse la plus organisée au problème de la mémoire des agents.
Où réside aujourd’hui le savoir
Supposons qu’un agent doive déterminer comment calculer le nombre d’utilisateurs actifs par semaine à partir d’un flux d’événements. La réponse se trouve répartie sur au moins quatre endroits :
+-----------------------+--------------------------------------------+
| WHERE IT LIVES | WHAT'S THERE |
+-----------------------+--------------------------------------------+
| Metadata catalogs | Table schemas (but vendor-locked APIs) |
| Wiki / Notion | Runbooks, metric definitions |
| Code comments | Docstrings, inline notes |
| People's heads | Join paths, deprecation warnings |
+-----------------------+--------------------------------------------+
Rien ici ne s’adapte automatiquement au code, et rien ne survit à la fermeture d’une nouvelle fenêtre de contexte. Chaque outil de création d’agents doit résoudre à nouveau le même problème d’assemblage du contexte, et chaque fournisseur de catalogues élabore ses propres schémas.
OKF estime que ce qui manque, c’est un format, et non une nouvelle plateforme.
Quel est ce format
La version 0.1 du Open Knowledge Format est une spécification ouverte et neutre par rapport aux fournisseurs, licenciée sous Apache 2.0. Les connaissances y sont stockées sous forme de répertoires de fichiers Markdown, chacun contenant du frontmatter en YAML. Cela semble simple parce que c’est effectivement simple, et c’est intentionnel.
Il n’y a ni registre de schémas, ni moteur de temps de exécution, ni SDK obligatoire. Tout ce qui peut utiliser cat sur un fichier peut le lire, et tout ce qui peut effectuer git clone sur un répertoire peut le distribuer. L’ensemble des spécifications tient sur une seule page et ne comporte qu’un champ obligatoire, le reste étant optionnel ou laissé à la discrétion du producteur.
Anatomie d’un bundle
Un bundle n’est rien d’autre qu’un dossier, et le chemin d’un fichier sert à identifier son concept.
.okf/
+-- index.md <- progressive entry point
+-- log.md <- dated change history, newest first
+-- services/
| +-- index.md
| +-- auth-api.md <- one concept = one file
| +-- payments-service.md
+-- datasets/
| +-- index.md
| +-- orders-db.md
+-- metrics/
| +-- index.md
| +-- weekly-active-users.md
+-- decisions/
+-- index.md
+-- why-we-use-postgres.md
Deux noms de fichiers sont réservés dans chaque bundle :
index.mdgère la divulgation progressive. Les agents parcourent un bundle en lisant l’index à chaque niveau et ne descendent qu’en cas de nécessité. Il s’agit du même chargement par étapes qui permet à Claude Skills d’utiliser des tokens de manière économique.log.mdcontient un historique des modifications avec des dates ISO, la dernière entrée en premier. Les humains et les agents qui maintiennent le bundle y ajoutent des informations chaque fois que des concepts changent.
Tous les autres fichiers sont des documents de concepts, identifiés par leur chemin. Le seul champ obligatoire dans un document de concept est un champ type non vide.
---
type: Service
title: "Auth API"
description: "Issues and verifies short-lived access tokens."
resource: https://github.com/acme/auth
tags: [auth, platform]
timestamp: 2026-06-14T10:00:00Z
---
Le corps contient ensuite du markdown ordinaire, y compris des tableaux.
## Endpoints| Method | Path | Description |
|--------|----------|---------------------------|
| POST | /token | Exchange creds for a JWT. |
| GET | /verify | Validate a token. |## Why This ExistsSee the decision at [decisions/why-we-separated-auth.md](../decisions/why-we-separated-auth.md).
Joins with [datasets/orders-db.md](../datasets/orders-db.md) for user scoping.
La prochaine étape importante de la conception arrive. Les concepts sont reliés les uns aux autres grâce à des liens Markdown standard. Cela transforme le répertoire en un graphe, un ensemble de connaissances structurées et croisément référencées présentant des relations explicites que l’on peut parcourir, plutôt qu’en un simple amas de documents.
[auth-api.md]
/ \
links links
/ \
[decisions/why-separated-auth.md] [datasets/orders-db.md]
|
links
|
[datasets/customers-db.md]
Un outil capable de suivre un lien Markdown peut parcourir le graphe, et un agent ayant accès aux fichiers peut à la fois les lire et les écrire.
Puisque seul le type est requis, le producteur choisit quels types existent (Service, Dataset, Metric, Decision, Runbook, etc.), quels champs optionnels utiliser et quelles sections du corps inclure. OKF définit l’interopérabilité et non les modèles de contenu.
Producteurs et consommateurs
Le format fonctionne de la même manière des deux côtés, donc le remplacement d’un producteur ou d’un consommateur ne perturbe pas les connaissances stockées.
PRODUCERS CONSUMERS
--------- ---------
Human authors ----> AI agents
BigQuery pipelines ----> HTML visualizers
LLM-generated ----> Search indexes
Wiki exports ----> Other agents / tools
Il n’y a pas de compte propriétaire, pas de SDK et pas de registre central. La valeur augmente avec l’ampleur de l’adoption et non grâce à un verrouillage par le fournisseur. Cela suit la philosophie à l’origine de git, markdown et JSON, des formats qui ont perduré parce qu’ils ne nécessitaient rien pour être utilisés.
Comment cela se rapporte à CLAUDE.md et MCP
La plupart des confusions commencent ici. OKF ne remplace pas les outils déjà en usage. Il comble un manque spécifique.
+---------------------+---------------------------+---------------------------+
| TOOL | PURPOSE | SCOPE |
+---------------------+---------------------------+---------------------------+
| CLAUDE.md | How the agent behaves | Per-project, one agent |
| AGENTS.md | Repo instructions | Per-repo, tool-specific |
| Karpathy LLM wiki | Agent-maintained notes | Pattern, not a spec |
| MCP | Live tool access | Runtime connections |
| OKF | What the team knows | Cross-project, any agent |
+---------------------+---------------------------+---------------------------+
Un modèle mental clair sépare trois types de questions :
- CLAUDE.md indique comment l’agent doit se comporter.
- OKF précise ce que l’équipe sait sur ce système.
- MCP indique quels outils en temps réel l’agent peut utiliser à ce moment-là.
Ils sont imbriqués les uns dans les autres. Une ligne de CLAUDE.md peut indiquer de lire .okf/metrics/ avant toute tâche d’analyse. Le paquet OKF fournit alors les connaissances structurées auxquelles fait référence CLAUDE.md, tandis que les connexions MCP fournissent les sources de données en temps réel décrites dans les documents OKF.
L’idée de wiki qu’il reprend
Andrej Karpathy, qui a inventé le terme « vibe coding » et préfère désormais l’expression « agentic engineering », a publié un résumé sur un wiki consacré aux LLM qui a recueilli plus de 5 000 étoiles. Son argument est simple : les gens abandonnent les wikis lorsque leur entretien devient une corvée, mais les agents ne se fatiguent pas, n’oublient pas les références croisées et n’ont pas de mal à modifier 15 fichiers d’un seul coup.
Ce même schéma réapparaissait indépendamment, dans Obsidian associé à des agents de codage, dans des dépôts remplis de fichiers AGENTS.md, ainsi que dans des fichiers index.md et log.md au sein de dizaines de projets. Les gens réinventaient constamment la même chose. Ce que propose OKF, c’est un accord sur les champs que chaque document contient et la signification des noms de fichiers, afin que des wikis distincts, voire une exportation depuis BigQuery, puissent collaborer sans nécessiter de traduction.
La correspondance entre les deux niveaux comporte trois couches :
KARPATHY LAYER OKF EQUIVALENT
-------------- --------------
Raw sources (immutable) --> External datasets, docs, APIs
(OKF bundles are the compiled layer)
Wiki (LLM-maintained) --> OKF bundle (*.md + frontmatter)
(OKF adds type, resource, tags, timestamp)Schema (CLAUDE.md) --> Producer/consumer conventions + okf/SPEC.md
(org-wide spec replaces per-vault bespoke rules)
Tant l’approche de Karpathy que celle d’OKF réservent index.md et log.md à des tâches identiques, et cette convergence n’était pas le fruit du hasard.
Ce que Google a fourni avec OKF
OKF est une spécification, mais Google a également publié trois outils pratiques associés :
- Un agent d’enrichissement pour BigQuery. Dirigé vers un ensemble de données, il rédige un document de concept OKF pour chaque table et vue, puis effectue une seconde passe avec un LLM afin d’ajouter des citations, des schémas et des chemins de jointure tirés de la documentation. Le résultat pour un entrepôt de données est un répertoire
.okf/complété. - Un visualiseur HTML statique. Il convertit n’importe quel paquet OKF en un graphique interactif au sein d’un seul fichier HTML autonome, sans besoin de serveur backend et sans que rien ne quitte la page. Les concepts apparaissent sous forme de nœuds et les liens Markdown sous forme d’arêtes ; en cliquant sur un nœud, un panneau de style wiki s’ouvre affichant le Markdown rendu ainsi que des liens inversés étiquetés « Liens vers / Cité par ».
- Paquets d’exemple. Trois paquets réels sur GitHub utilisent des ensembles de données publics de BigQuery :
+--------------------+----------------------------------+
| BUNDLE | WHAT IT DOCUMENTS |
+--------------------+----------------------------------+
| GA4 e-commerce | Analytics tables and metrics |
| Stack Overflow | Public dataset concepts |
| Bitcoin | Blockchain dataset structure |
+--------------------+----------------------------------+
Ils servent à la fois de modèles de départ à copier et de preuve que le format fonctionne correctement sur différents domaines.
Quand OKF est le choix idéal
C’est le bon outil lorsque le problème de connaissance correspond à l’un de ces cas :
- Les mêmes explications se répètent à chaque nouvelle session de l’agent. Si un bloc de contexte est constamment collé dans CLAUDE.md, il doit être placé dans OKF.
- Les connaissances concernent plusieurs projets ou équipes. CLAUDE.md est lié à un seul projet et à un seul agent, tandis qu’OKF permet de regrouper des éléments qui se déplacent entre des dépôts, des agents et des outils.
- Les documents de projet doivent être versionnables. OKF est stocké dans git à côté du code qu’il décrit ; chaque modification apparaît dans un diff, et une demande de fusion peut intégrer des mises à jour de connaissances avec les modifications de code.
- Le stack est Google Cloud et BigQuery. Il existe une intégration directe avec le Knowledge Catalog de Google, qui reçoit les bundles et les transmet aux agents GCP.
- Un graphe de connaissances est souhaité, et non une wiki plate. Le graphe de liens Markdown permet d’établir des relations structurées entre les concepts sans recourir à une base de données graphique.
C’est le mauvais choix dans certains cas :
- Des données en temps réel sont nécessaires, ce qui exige MCP.
- Des règles comportementales doivent être codées, tâche pour laquelle CLAUDE.md est conçu.
- Le projet est de petite taille et peut être traité en une seule session, où CLAUDE.md seul suffit.
Démarrer
La configuration est minimale par conception.
Avec Claude Code
Le plugin okf-skills regroupe trois compétences. /okf:okf crée et gère les bundles, /okf:validate vérifie que un bundle est conforme et /okf:visualize génère le graphique interactif. Installez-le avec :
/plugin marketplace add scaccogatto/okf-skills
/plugin install okf@scaccogatto
Tout outil, y compris Claude Code, Cursor, Codex et plus de vingt autres, peut au lieu de cela utiliser npm :
npx skills add scaccogatto/okf-skills
Ensuite, exécutez les compétences :
/okf:okf produce .okf # create your first bundle
/okf:validate .okf --strict # check conformance
/okf:visualize .okf # generate viz.html
Pour mettre automatiquement les choses à jour, afin que Claude lise .okf/ avant d’exécuter les tâches et enregistre ce qu’il a appris par la suite, copiez le modèle templates/CLAUDE-okf.md dans le fichier CLAUDE.md du projet. Aucun élément ne force cette étape.
Rédiger manuellement
Créez un répertoire .okf/ et ajoutez un fichier index.md. Ensuite, ajoutez un fichier de concept pour chaque fonctionnalité importante du système. Un enregistrement de décision a cet aspect :
---
type: Decision
title: "Why we use Postgres over MySQL"
description: "JSONB support and row-level security were decisive."
timestamp: 2026-03-01T00:00:00Z
tags: [infrastructure, database]
---
Le corps suit :
## ContextIn early 2026 we evaluated both options. MySQL's JSON support was insufficient for our metadata schema...## DecisionPostgres 16. See [datasets/primary-db.md](../datasets/primary-db.md) for schema docs.
C’est tout ce qui est nécessaire. Tout agent ayant accès au fichier peut le lire immédiatement, et il peut être examiné dans une PR ainsi que comparé via git.
Toute la stack
Voici comment OKF s’intègre aux autres éléments au sein d’une session :
+--------------------------------------------------+
| AGENT SESSION |
+--------------------------------------------------+
| CLAUDE.md / AGENTS.md |
| (behavioral rules - how agent acts) |
+--------------------------------------------------+
| OKF BUNDLE (.okf/) |
| (curated team knowledge - what we know) |
| - index.md: entry points per domain |
| - concepts/*.md: services, datasets, decisions |
| - log.md: change history |
+--------------------------------------------------+
| AUTO-MEMORY (memory.md) |
| (what the agent picked up implicitly) |
+--------------------------------------------------+
| MCP CONNECTIONS |
| (live tool access - what the agent can do) |
+--------------------------------------------------+
| SKILLS (.claude/skills/) |
| (reusable SOPs - how to do specific tasks) |
+--------------------------------------------------+
Chaque couche répond à sa propre question. Elles ne se chevauchent pas, elles se composent.
Ce que v0.1 laisse en suspens
Google qualifie ouvertement v0.1 de point de départ, l’interopérabilité étant résolue en premier. Plusieurs questions de conception restent en suspens :
- Contradictions. Lorsque deux documents OKF diffèrent sur un même fait, aucune sémantique de fusion n’existe encore.
- Connaissances obsolètes. Comme OKF est basé sur des fichiers, un document laissé inchangé lorsque le système évolue constitue une défaillance de processus et non de format.
- Relations typées. La spécification actuelle utilise des liens Markdown simples, tandis que des types de relations plus riches tels que « contredit », « étend » ou « remplace » sont encore en cours d’élaboration par la communauté.
- Recherche facettée. Certains professionnels souhaitent davantage de balises que ne le prévoit la spécification minimale.
La version v0.2 traitera probablement de plusieurs de ces problèmes en fonction des retours, et le dépôt des spécifications est public et accepte des problèmes ainsi que des propositions de modification.
Pourquoi les formats ennuyeux l’emportent
Les formats qui deviennent une infrastructure ont tendance à être monotones. JSON a gagné parce que c’était la solution la plus simple qui fonctionnait et qui ne coûtait rien à adopter, et non parce qu’elle était ingénieuse. Markdown a gagné de la même manière.
OKF correspond à cette description. Il ne faut rien pour le lire, rien pour l’écrire, et il fonctionne avec n’importe quel outil capable de gérer des fichiers. Sa valeur augmente avec le nombre de producteurs et de consommateurs, et les décisions d’un seul fournisseur n’influencent pas son évolution. Il consigne également un schéma que les gens avaient déjà développé par eux-mêmes, grâce à Karpathy’s gist, aux habitudes AGENTS.md et aux hiérarchies index.md construites manuellement, ce qui constitue la meilleure preuve qu’un véritable problème est résolu.
Karpathy a souligné que les agents gèrent mieux les wikis que les humains car ils ne se sentent pas ennuyés. Selon OKF, la valeur d’un wiki ne s’accroît que s’il peut être partagé. Ensemble, ces deux idées pourraient constituer dans quelques années une base fondamentale pour le développement assisté par des agents. Le construire maintenant, tant qu’il est encore nouveau, sera bénéfique pour vous à l’avenir ainsi que pour tous les agents auxquels vous donnerez des instructions.