Historique : comment le contexte agent est devenu un format ouvert

Avant OKF : la documentation humaine ne suffisait plus

Pendant longtemps, la connaissance d'une entreprise a été pensée pour des humains : pages Notion, dossiers Drive, wikis internes, commentaires de code, tickets support, dashboards BI, exports CSV et présentations. Cette documentation reste indispensable, mais elle n'est pas toujours structurée pour un agent.

Un humain sait souvent lire entre les lignes. Il comprend que telle page est plus récente, que tel dashboard remplace l'ancien, ou que telle règle métier n'est appliquée que dans un cas particulier. Un agent, lui, a besoin de repères explicites : sources, dates, liens, définitions, ownership, contraintes et relations entre concepts.

C'est le point de départ historique d'OKF : le problème n'est pas seulement d'avoir plus de documents, mais de transformer ces documents en contexte interprétable par des systèmes IA.

Les premiers fichiers de contexte pour agents

Avant de parler d'OKF, les équipes ont commencé à écrire des fichiers d'instructions pour guider leurs agents. Dans l'écosystème Codex, le fichier AGENTS.md donne un endroit prévisible pour décrire les commandes, conventions, tests et règles projet qu'un coding agent doit connaître.

Dans Claude Code, les fichiers CLAUDE.md et les mémoires projet jouent un rôle proche : ils chargent au début d'une session des instructions, préférences, décisions d'architecture ou workflows que l'utilisateur ne veut pas répéter à chaque fois.

Ces fichiers ont révélé une chose importante : les agents deviennent meilleurs quand le contexte est explicite, stable et proche du travail réel. Mais ils restent souvent centrés sur les instructions de travail, pas sur la représentation complète de la connaissance métier.

Le pattern LLM-wiki : faire écrire une base de connaissance par l'agent

Le gist LLM Wiki d'Andrej Karpathy a popularisé une idée simple et puissante : au lieu de garder les connaissances dans une conversation éphémère, on peut demander à un agent de construire et maintenir un wiki en Markdown.

Dans ce pattern, l'agent lit des sources brutes, crée des pages de synthèse, maintient des entités, ajoute des comparaisons, met à jour les liens et fait évoluer la base de connaissance au fil des nouvelles informations. Le wiki devient un artefact durable, relisible, amendable et réutilisable.

OKF reprend cette intuition, mais cherche à la rendre plus interopérable. Le passage du LLM-wiki à OKF, c'est le passage d'une méthode émergente vers un format que plusieurs producteurs, consommateurs et outils peuvent comprendre.

Metadata-as-code : traiter la connaissance comme un actif versionné

En parallèle, les équipes data et platform ont déjà appris à gérer une partie de leur connaissance comme du code : schémas, définitions de métriques, catalogues, modèles dbt, fichiers de configuration, runbooks et contrats de données.

Cette logique metadata-as-code apporte des pratiques précieuses : revue, historique, diff, ownership, validation, rollback et collaboration dans Git. Elle rend visible l'évolution de la connaissance au lieu de la laisser se perdre dans des outils fermés.

OKF s'inscrit dans cette continuité. Il ne demande pas de jeter les outils existants. Il propose un format léger pour que la connaissance utile aux agents puisse circuler comme un dossier versionnable, plutôt que rester enfermée dans un silo.

12 juin 2026 : Google Cloud formalise le pattern avec OKF

Le 12 juin 2026, Google Cloud publie Open Knowledge Format v0.1 et le présente comme une spécification ouverte qui formalise le pattern LLM-wiki dans un format portable et interopérable.

La proposition est volontairement minimale : des fichiers Markdown, un frontmatter YAML, des liens Markdown, quelques conventions de bundle et un champ requis important, type, pour aider les agents à comprendre la nature d'un concept.

Google publie aussi la spec, le repo knowledge-catalog, des exemples de bundles et un README OKF qui rappelle que le format lui-même est la contribution principale. Les outils, agents de référence et visualizers servent surtout à rendre le format tangible et testable.

Ce que cette histoire change pour les entreprises

Pour les entreprises, cette chronologie est importante parce qu'elle montre une direction de fond : les agents ne consommeront pas seulement des prompts. Ils auront besoin d'un contexte maintenu, sourcé, relié et transportable.

Un fichier AGENTS.md peut dire comment travailler dans un projet. Un CLAUDE.md peut conserver des instructions. Un wiki Markdown peut capitaliser la connaissance. OKF essaie de donner à cette matière un format commun pour qu'elle puisse être produite, lue et échangée entre outils.

La bonne lecture n'est donc pas : OKF remplace Notion, Obsidian, Git ou un data catalog. La bonne lecture est : OKF peut devenir une couche d'échange pour rendre une partie de cette connaissance utilisable par des agents.

Lire ensuite : relier l'histoire à la pratique

Pour passer de l'historique à l'action, lisez ensuite la définition d'OKF, puis l'anatomie d'un bundle. Ces deux pages expliquent ce que le format impose vraiment et comment un premier dossier de concepts peut être structuré.

Si vous venez du RAG ou du search, la page OKF vs RAG aide à comprendre pourquoi OKF ne remplace pas la recherche, mais prépare un corpus plus propre pour les agents. La page outils officiels rassemble ensuite les sources primaires, la spec, le repo et les exemples publiés.

Sources officielles et références utiles

Cette page privilégie les sources primaires ou proches de l'origine du format : annonce Google Cloud, spec GitHub, README OKF, gist LLM-wiki, documentation AGENTS.md et documentation Claude Code.