--- title: "L'Open Knowledge Format de Google Cloud est un standard, pas un produit : plongée dans OKF v0.1" description: "Le 12 juin 2026, Google Cloud a publié l'Open Knowledge Format (OKF), une spécification ouverte qui formalise le pattern LLM-wiki en format portable et interopérable : un répertoire de fichiers markdown avec frontmatter YAML, un seul champ obligatoire (type), cinq recommandés, et zéro outillage requis. Le tweet de Google Cloud Tech du 16 juin a généré 117 000 vues en 24 heures et a fait de la spec l'annonce de format de connaissance la plus discutée de l'année. Cette longue lecture parcourt la spec v0.1 section par section, les choix de design qui la rendent délibérément minimale, ce que Google livre avec (un agent d'enrichissement pour BigQuery, un visualiseur HTML statique, trois bundles d'exemple, et une intégration native au Knowledge Catalog BigQuery), et la question ouverte que tout constructeur d'agents IA et toute équipe plateforme de données devraient suivre sur les six prochains mois." date: 2026-06-17 image: "/images/heroes/2026-06-17--google-cloud-okf-open-knowledge-format-deep-dive.png" author: lschvn tags: ["ai", "tooling", "ecosystem"] tldr: - "OKF v0.1 a été publié le 12 juin 2026 dans le dépôt GoogleCloudPlatform/knowledge-catalog (Apache-2.0, actuellement 3,3k étoiles) et promu via un tweet de Google Cloud Tech le 16 juin. La spec est un répertoire de fichiers markdown avec frontmatter YAML, un seul champ obligatoire (type), cinq recommandés (title, description, resource, tags, timestamp), et deux noms de fichiers réservés (index.md, log.md). Il n'y a pas de registre de schéma, pas d'autorité centrale, et pas de SDK requis." - "Le 'pattern LLM-wiki' qu'OKF formalise est le même pattern qui est réapparu sous différents noms pendant un an : le gist LLM Wiki de Karpathy, les vaults Obsidian branchés à des agents de codage, la famille de fichiers de convention AGENTS.md / CLAUDE.md, les dépôts remplis d'artefacts index.md et log.md que les agents consultent, et les dépôts 'metadata as code' dans les équipes data. OKF fixe le petit ensemble de conventions nécessaires pour rendre ces instances interopérables sans dicter l'outillage." - "Google a livré quatre artefacts de référence dans la même release : un agent d'enrichissement construit sur le Google Agent Development Kit avec Gemini comme backend, un visualiseur HTML statique qui rend n'importe quel bundle OKF comme un graphe interactif auto-contenu, trois bundles d'exemple (GA4 e-commerce, Stack Overflow, jeux de données publics Bitcoin), et une intégration au Knowledge Catalog BigQuery qui ingère OKF nativement. Le format est la contribution ; les outils sont des preuves de concept." - "Ce qui change pour les builders : le Knowledge Catalog BigQuery peut maintenant servir un corpus de markdown OKF aux agents, ce qui signifie que la spec n'est pas seulement un format pour wikis, c'est aussi un format d'export de catalogue de données, et la cible d'export est l'endroit où vit la connaissance enterprise la plus importante sur les tables SQL, les métriques et les runbooks. La question stratégique intéressante est de savoir si OKF devient la lingua franca, ou si une spec concurrente émerge dans les six prochains mois." faq: - question: "Qu'est-ce que l'Open Knowledge Format (OKF) ?" answer: "OKF v0.1 est une spécification ouverte publiée par Google Cloud le 12 juin 2026 sous Apache-2.0. Elle définit un répertoire de fichiers markdown avec frontmatter YAML comme format portable et interopérable pour représenter les métadonnées, le contexte et la connaissance curatée dont les agents IA ont besoin. Le format est intentionnellement minimal : un seul champ frontmatter obligatoire (type), cinq recommandés (title, description, resource, tags, timestamp), deux noms de fichiers réservés (index.md, log.md), des liens croisés en markdown standard, et un modèle de consommation permissif où les champs inconnus et les liens cassés sont tolérés par design. L'implémentation de référence vit à github.com/GoogleCloudPlatform/knowledge-catalog sous le répertoire okf/." - question: "OKF est-il un produit Google, et l'adopter nous enferme-t-il dans BigQuery ?" answer: "Non sur les deux points. OKF est publié comme une spécification ouverte avec le texte de la spec sous Apache-2.0, et Google l'a explicitement positionné comme 'vendor-neutral, agent- and human-friendly'. Le texte de la spec ne mentionne jamais BigQuery, Gemini, ou aucun produit Google. L'agent d'enrichissement BigQuery et l'intégration au Knowledge Catalog BigQuery sont des implémentations de référence à une extrémité de l'axe producteur/consommateur, pas une partie du format. Vous pouvez produire OKF dans Notion, l'éditer dans Obsidian, le rendre avec Hugo ou MkDocs, le livrer en tarball, le monter sur un système de fichiers, ou écrire un producteur dans n'importe quel langage. La question du lock-in est celle que la spec est conçue pour dissoudre." - question: "Qu'est-ce que le pattern LLM-wiki qu'OKF formalise ?" answer: "Le pattern LLM-wiki est la pratique de stocker de la connaissance curatée sous forme de fichiers markdown avec frontmatter YAML, organisés en arborescence de répertoires, et de laisser les agents (plutôt que les moteurs de recherche) traverser la structure. Le pattern est réapparu sous différents noms pendant au moins un an : le gist LLM Wiki d'Andrej Karpathy (qui argue que les LLMs sont meilleurs que les humains pour la comptabilité qui fait abandonner les wikis personnels), les vaults Obsidian branchés à Claude Code ou Cursor, la famille de fichiers de convention AGENTS.md et CLAUDE.md, les dépôts remplis d'artefacts index.md et log.md, et les dépôts 'metadata as code' dans les équipes data. Chaque instance est bespoke ; OKF fixe le petit ensemble de conventions qui permet à ces instances de coopérer." - question: "En quoi OKF est différent d'un pipeline RAG, d'une base de données vectorielle, ou d'un catalogue de métadonnées ?" answer: "OKF est un format de fichiers, pas un système de retrieval. Il n'y a pas de modèle d'embedding, pas de stratégie de chunking, pas d'interface de requête, et pas de couche de stockage spécifiée. Un bundle de fichiers markdown OKF peut être ingéré par un pipeline RAG (chaque fichier est un chunk naturel), indexé dans une base vectorielle (le frontmatter et le body sont tous deux du texte embeddable), exporté depuis un catalogue de métadonnées (l'agent d'enrichissement BigQuery en est l'exemple), ou lu directement par un agent dans sa fenêtre de contexte. Le format est le contrat ; l'outillage à chaque extrémité est interchangeable indépendamment. C'est la partie que la spec appelle 'producer/consumer independence' et c'est le choix de design qui distingue OKF d'un framework RAG." - question: "Que dois-je concrètement faire pour démarrer avec OKF ?" answer: "Trois choses. Premièrement, lire la spec, qui fait environ 1 000 lignes et tient sur une seule page. Deuxièmement, créer un répertoire avec quelques fichiers markdown, donner à chacun un bloc frontmatter YAML avec au moins un champ type, et commencer à écrire les concepts que vous voulez qu'un agent puisse trouver. Troisièmement, lancer le visualiseur de référence (bunx ou python -m enrichment_agent visualize --bundle ./my_bundle) pour voir votre bundle rendu comme un graphe interactif. L'agent d'enrichissement de référence fonctionne contre BigQuery ; pour d'autres sources, l'interface Source est le point d'extension documenté et un producteur non-BigQuery peut être écrit dans n'importe quel langage en quelques centaines de lignes." - question: "Comment OKF se rapporte-t-il au LLM Wiki de Karpathy, à Obsidian, AGENTS.md, CLAUDE.md, et Hugo ?" answer: "OKF est en aval des cinq et est intentionnellement compatible avec la forme des artefacts qu'ils produisent. Le LLM Wiki de Karpathy est la source conceptuelle : 'les LLMs ne s'ennuient pas, n'oublient pas de mettre à jour une référence croisée, et peuvent toucher 15 fichiers en une passe.' Les vaults Obsidian utilisent déjà markdown + frontmatter + liens croisés, donc un vault Obsidian peut être transformé en bundle OKF avec une petite couche de mapping. AGENTS.md et CLAUDE.md sont le pattern de fichier de convention que les agents consultent avant de travailler ; OKF généralise cela d'un fichier à un répertoire. Hugo, MkDocs, et Jekyll rendent déjà du markdown + frontmatter, donc un bundle OKF est browsable comme un site statique out of the box. La section 'Relationship to other formats' de la spec (SPEC.md §10) est explicite sur cette filiation." - question: "Qu'est-ce que Google gagne à publier OKF comme spec ouverte ?" answer: "Trois choses, par ordre d'importance stratégique. Premièrement, la distribution. Si OKF devient la lingua franca pour représenter la connaissance enterprise, le Knowledge Catalog BigQuery devient la cible d'ingestion naturelle pour toute équipe qui utilise déjà BigQuery, qui est la partie du marché de la data cloud sur laquelle Google a été le plus focalisé. Deuxièmement, l'agent d'enrichissement BigQuery devient un producteur par défaut que tout client BigQuery peut lancer en une commande CLI, ce qui fait de BigQuery l'endroit le plus facile pour authorer un bundle OKF. Troisièmement, une spec ouverte est un hedge contre le fait qu'une des dizaines de propositions de format de connaissance concurrentes devienne le standard de facto ; en publiant la spec sous Apache-2.0 et en accueillant les implémentations alternatives, Google baisse la température d'une guerre de format qu'il préférerait ne pas mener." - question: "Quelle est la licence d'OKF et qu'est-ce qu'elle autorise ?" answer: "OKF est publié sous Apache License 2.0, la même licence utilisée par le dépôt knowledge-catalog dans son ensemble. La licence est permissive : n'importe qui peut utiliser, modifier et distribuer la spec et toute implémentation dérivée, y compris à des fins commerciales, avec attribution et notice de modifications. Il n'y a pas de grants de brevets au-delà du grant implicite de la licence Apache-2.0, pas de copyleft, et pas de restrictions de domaine d'utilisation. Le choix d'Apache-2.0 sur MIT est en soi un signal : Apache-2.0 inclut le grant de brevet explicite que MIT n'a pas, ce qui est la raison pour laquelle la plupart des standards ouverts enterprise-friendly (Kubernetes, TensorFlow, Swift) utilisent Apache-2.0 plutôt que MIT." --- Dans la soirée du 16 juin 2026, le compte Google Cloud Tech a posté un seul tweet qui a généré 117 000 vues, 1 800 likes, et 1 800 bookmarks en 24 heures, l'annonce de format de connaissance la plus engagée de l'année par ordre de grandeur. Le tweet introduisait l'[Open Knowledge Format (OKF)](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf), une spécification ouverte qui 'formalise le pattern LLM-wiki en format portable et interopérable'. Le post pointait vers la [spec sur GitHub](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf) et vers un [blog post sur cloud.google.com](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing) signé par Sam McVeety (Tech Lead, Data Analytics) et Amir Hormati (Tech Lead, BigQuery). Le blog post avait été publié quatre jours avant le tweet, le 12 juin, le même jour où l'implémentation de référence avait été poussée pour la première fois sur le dépôt GoogleCloudPlatform/knowledge-catalog. > [@GoogleCloudTech](https://x.com/GoogleCloudTech/status/2067012903337664886) - 22:34 · 16 juin 2026 > > Introducing the Open Knowledge Format (OKF), an open specification that formalizes the LLM-wiki pattern into a portable, interoperable format. AI is only as smart as the context we give it. As we build more advanced, agentic AI systems, they need accurate metadata and context to organizations, that context is locked inside fragmented data catalogs, isolated wikis, scattered code comments, or the minds of senior engineers. Every time a new AI agent is built, teams are forced to solve the exact same context-assembly problem from scratch. > > To solve this, we've announced OKF, a vendor-neutral, open specification that formalizes the "LLM-wiki pattern" into a portable, interoperable format. It provides a standardized way to represent the enterprise knowledge that modern AI systems rely on. > > — Just markdown: readable in any editor, renderable on GitHub, indexable by any search tool > — Just files: shippable as a tarball, hostable in any git repo, mountable on any filesystem > — Just YAML frontmatter: for the small set of structured fields that need to be queryable: type, title, description, resource, tags, and timestamp > > We've also shipped reference implementations to help you hit the ground running, including an enrichment agent for BigQuery, a static HTML visualizer, and live sample bundles on GitHub. La substance de l'annonce se comprend mieux comme quatre mouvements distincts : la spec elle-même, les implémentations de référence, l'intégration BigQuery, et le mouvement de positionnement. Chacun fait un travail différent. La spec est un document de 1 000 lignes qui définit un répertoire de fichiers markdown avec frontmatter YAML, un seul champ obligatoire, et deux noms de fichiers réservés. Les implémentations de référence sont trois artefacts : un agent d'enrichissement BigQuery, un visualiseur HTML statique, et trois bundles d'exemple. L'intégration BigQuery est un chemin d'ingestion natif dans le [Knowledge Catalog](https://cloud.google.com/bigquery) qui transforme un bundle OKF en surface requêtable et servable aux agents. Le mouvement de positionnement est l'affirmation que le pattern LLM-wiki est une catégorie, pas un one-off, et que le format est la contribution, pas l'outillage. ## La correction de cadrage, en un paragraphe Le cadrage qui mérite d'être fait d'entrée est qu'OKF est un format, pas un produit, et que la lecture la plus commune de l'annonce est de la traiter comme un lancement de produit Google Cloud. Le texte de la spec ne mentionne jamais BigQuery, Gemini, ou aucun produit Google. Les implémentations de référence sont délibérément appelées 'proofs of concept' dans le README, et la section 'Relationship to other formats' de la spec (SPEC.md §10) est explicite : OKF est en aval des patterns que la communauté construit depuis au moins un an : le [gist LLM Wiki de Karpathy](https://gist.github.com/karpathy), les vaults Obsidian branchés à des agents de codage, la famille de fichiers de convention [AGENTS.md et CLAUDE.md](/articles/2026-03-23-claude-code-rise-ai-coding-tool-2026), et les dépôts 'metadata as code' dans les équipes data. Ce que Google a fait, dans la lecture la plus propre, c'est fixer le petit ensemble de conventions qui permet à ces instances de coopérer, publier le fixage sous Apache-2.0, et livrer une implémentation de référence par extrémité de l'axe producteur/consommateur. La question du lock-in est celle que la spec est conçue pour dissoudre. Le corollaire est la partie qui compte pour les builders. Si OKF devient la lingua franca, le [Knowledge Catalog BigQuery](https://cloud.google.com/bigquery/docs/knowledge-catalog) devient la cible d'ingestion naturelle pour toute équipe qui utilise déjà BigQuery, qui est la plus grande partie du marché de la data cloud. C'est le mouvement stratégique, et le cadrage en spec ouverte est la manière dont le mouvement est fait sans déclencher le type de scrutiny réglementaire et concurrentiel qu'un lancement de produit fermé inviterait. Le format est la contribution, et le format est aussi le coin. ## La spec, en un écran La spec v0.1, [SPEC.md](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) dans le dépôt, fait environ 1 000 lignes de markdown avec 11 sections, un appendice de conformance, et un unique exemple de bundle minimal. La structure d'un bundle est la partie qui ancre tout le reste, et elle est assez petite pour être reproduite intégralement : ``` sales/ ├── index.md # Optionnel. Listing de répertoire pour la disclosure progressive. ├── log.md # Optionnel. Historique chronologique des updates. ├── .md # Un concept à la racine du bundle. └── / # Les sous-répertoires organisent les concepts en groupes. ├── index.md ├── .md └── / └── … ``` Un bundle est une arborescence de répertoires. La structure du répertoire est indépendante du domaine, et les producteurs organisent les concepts comme cela fait sens pour la connaissance capturée. Un bundle PEUT être distribué comme un dépôt git (la forme recommandée, parce que git fournit historique, attribution et diffs), comme une archive tarball ou zip, ou comme un sous-répertoire dans un dépôt plus large. Les noms de fichiers réservés, `index.md` et `log.md`, ont une signification définie à tout niveau de la hiérarchie et NE DOIVENT PAS être utilisés pour des documents de concept. Tous les autres fichiers `.md` dans l'arborescence sont des documents de concept. Un concept est un unique fichier markdown UTF-8 avec deux parties : un bloc frontmatter YAML délimité par des lignes `---` en haut du fichier, et un body markdown contenant du contenu libre. Le frontmatter est où le travail structurel se fait, et la spec est opinionated sur exactement une chose dans le frontmatter : le champ `type` est obligatoire, doit être non-vide, et est le seul champ que les consommateurs ont le droit de requérir. Tout le reste est défini par le producteur. ```yaml --- type: # REQUIRED title: description: resource: tags: [, , …] # Optional timestamp: # Optional last-modified time # … other producer-defined key/value pairs --- ``` Les champs recommandés, par ordre de priorité, sont `title` (nom d'affichage lisible par un humain, dérivé du nom de fichier si absent), `description` (résumé en une phrase utilisé par les générateurs d'index, les snippets de recherche, et les previews), `resource` (URI canonique pour l'asset sous-jacent que le concept décrit, omis pour les concepts qui décrivent des idées abstraites plutôt que des ressources physiques), `tags` (liste YAML de chaînes courtes pour la catégorisation cross-cutting), et `timestamp` (datetime ISO 8601 du dernier changement significatif). Les producteurs PEUVENT inclure n'importe quelles clés additionnelles, et les consommateurs DEVRAIENT préserver les clés inconnues lors du round-trip et NE DEVRAIENT PAS rejeter les documents avec des champs non reconnus. La tolérance est intentionnelle : OKF est censé rester utile à mesure que les bundles grandissent, sont refactorés, et sont partiellement générés par des agents. Le body est du markdown standard. Il n'y a pas de sections de body obligatoires, mais la spec nomme trois titres de section conventionnels que les producteurs DEVRAIENT utiliser quand applicables : `# Schema` (description structurée des colonnes ou champs d'un asset, typiquement en table markdown), `# Examples` (exemples d'usage concrets, souvent en blocs de code fence), et `# Citations` (sources externes qui soutiennent les claims du body, avec des références numérotées). Le body est où vit la majeure partie de la valeur pour un consommateur agent, et la guidance structurelle est la partie qui distingue un document OKF d'un fichier de notes personnelles dans le même répertoire. Le champ type est la partie qui fait le plus de travail. Les valeurs de type ne sont pas enregistrées centralement, et la spec donne une liste d'exemples : `BigQuery Table`, `BigQuery Dataset`, `API Endpoint`, `Metric`, `Playbook`, `Reference`. Les producteurs DEVRAIENT choisir des valeurs descriptives et self-explanatory ; les consommateurs DOIVENT tolérer les types inconnus avec grâce, typiquement en les traitant comme des concepts génériques. La tolérance est la même que la tolérance pour les extensions de frontmatter : un agent qui rencontre un concept de type `Sev1 Incident Runbook` d'un vendor qu'il n'a jamais vu ne devrait pas refuser le bundle, il devrait rendre le concept comme un document générique et laisser la prose du producteur décrire la sémantique. Le modèle de consommation permissif est le choix de design qui rend OKF viable comme format maintenu par la communauté plutôt que comme schéma contrôlé par Google. ## La spec, en détail : linking, indexing, logging, conformance Les parties intéressantes de la spec sont les quatre mécanismes qui transforment un répertoire de fichiers en corpus de connaissance navigable et version-contrôlable. Ils sont petits, ils composent, et chacun est la réponse à une question que toute équipe qui a essayé de maintenir un wiki de plus de quelques centaines de pages reconnaîtra. Le cross-linking est la partie qui transforme le répertoire en graphe. Les concepts PEUVENT pointer vers d'autres concepts avec des liens markdown standard, sous deux formes. La première est bundle-relative (absolue dans le bundle) : un lien comme `[customers table](/tables/customers.md)` est résolu relativement à la racine du bundle, ce qui le rend stable quand les documents sont déplacés dans leur sous-répertoire. La seconde est relative, la forme markdown standard `./other.md`. La spec recommande la forme absolue parce qu'elle survit à la réorganisation. La sémantique des liens est délibérément untyped : un lien du concept A vers le concept B assert une relation, et le type spécifique de relation (parent/enfant, references, joins-with, depends-on) est véhiculé par la prose environnante, pas par le lien lui-même. Les consommateurs qui construisent une vue en graphe traitent typiquement tous les liens comme des arêtes dirigées d'une relation untyped, et le modèle untyped est ce qui empêche la spec de glisser vers un schéma. Les consommateurs DOIVENT tolérer les liens cassés, un lien dont la cible n'existe pas n'est pas malformé, il peut simplement représenter de la connaissance pas-encore-écrite, et la tolérance est la partie qui rend le format utilisable pendant qu'un bundle est en cours de construction. L'indexing est la partie qui supporte la disclosure progressive. Un fichier `index.md` PEUT apparaître dans n'importe quel répertoire, y compris à la racine du bundle, et il énumère le contenu du répertoire pour permettre à un humain ou un agent de voir ce qui est disponible avant d'ouvrir les documents individuels. Les fichiers d'index ne contiennent pas de frontmatter. Le body utilise une ou plusieurs sections, chacune groupant les concepts sous un titre, avec des entrées en bullet-list qui pointent vers l'URL relative du concept et reprennent la description du concept depuis son frontmatter. Les producteurs PEUVENT générer `index.md` automatiquement ; les consommateurs PEUVENT en synthétiser un à la volée quand aucun n'est présent. Le pattern de disclosure progressive est la partie qui rend OKF utilisable pour les grands corpus : un agent peut lire l'`index.md` racine, décider quel sous-répertoire est pertinent, lire cet `index.md`-là, décider quel concept ouvrir, et lire le concept, sans jamais charger le bundle entier en contexte. Pour un bundle de 10 000 concepts, le pattern est la différence entre un corpus utilisable et un corpus inutilisable. Le logging est la partie qui supporte les workflows de contrôle de version. Un fichier `log.md` PEUT apparaître à tout niveau de la hiérarchie pour enregistrer l'historique des changements de ce scope. Le format est une liste plate d'entrées groupées par date, les plus récentes d'abord, avec des titres de date en format ISO 8601 `YYYY-MM-DD`. Les entrées de log sont en prose, avec un mot en gras en tête (`**Update**`, `**Creation**`, `**Deprecation**`) comme convention plutôt que comme requirement. Le pattern est emprunté directement aux conventions de changelog que la communauté open-source utilise depuis une décennie, et le choix de garder le format en prose plutôt qu'en structuré est la partie qui rend le log lisible par des humains, parsable par des agents, et écrivable dans un message de commit git. Le log n'est pas autoritaire (git est la source de vérité), c'est une vue dénormalisée read-optimized de l'historique qu'un curateur de bundle peut produire à chaque release. La conformance est la partie qui fixe ce que signifie être OKF-compatible. Un bundle est conforme à v0.1 si trois conditions tiennent : tout fichier `.md` non-réservé dans l'arborescence contient un bloc frontmatter YAML parsable, tout bloc frontmatter contient un champ `type` non-vide, et tout nom de fichier réservé suit la structure décrite en §6 et §7 quand présent. Les consommateurs DEVRAIENT traiter toutes les autres contraintes comme de la guidance molle, et les consommateurs NE DOIVENT PAS rejeter un bundle à cause de champs frontmatter optionnels manquants, de valeurs de `type` inconnues, de clés frontmatter additionnelles inconnues, de liens croisés cassés, ou de fichiers `index.md` manquants. Le modèle de consommation permissif est le choix de design qui distingue OKF d'un format piloté par schéma plus strict (Protocol Buffers, Avro, OpenAPI), et le choix est délibéré : la valeur d'un format de connaissance est dans combien de parties le parlent, et un format qui rejette des bundles pour des champs optionnels manquants est un format qui se fait forker. L'histoire de versioning est la partie qui détermine si OKF v0.1 est un point de départ ou un standard fini. La spec est versionnée sous la forme `.`, avec un bump de version mineure qui introduit des additions backward-compatible (nouveaux champs optionnels, nouveaux titres de section conventionnels) et un bump de version majeure réservé aux changements breaking (renommer des champs obligatoires, changer les noms de fichiers réservés). Les bundles PEUVENT déclarer la version OKF qu'ils ciblent en incluant `okf_version: "0.1"` dans le bloc frontmatter de l'`index.md` à la racine du bundle, qui est le seul endroit où le frontmatter est permis dans un `index.md`. Les consommateurs qui ne comprennent pas la version déclarée DEVRAIENT tenter une consommation best-effort plutôt que de refuser le bundle. Le pattern est le même que celui que l'IETF, le W3C, et le WHATWG utilisent depuis deux décennies, et le choix d'être explicite sur la sémantique de version est la partie qui fait d'OKF un candidat à une standardisation réelle plutôt qu'un format one-off. ## Le pattern LLM-wiki, nommé La chose la plus utile que fait l'annonce est de donner un nom à un pattern qui a émergé silencieusement à travers l'écosystème IA pendant au moins un an. Le pattern est la pratique de stocker de la connaissance curatée sous forme de fichiers markdown avec frontmatter YAML, organisés en arborescence de répertoires, et de laisser les agents (plutôt que les moteurs de recherche) traverser la structure. Le pattern est réapparu sous différents noms, dans différentes communautés, pour différentes raisons, et OKF est la première spec à revendiquer la catégorie plutôt qu'une seule des instances. Le [gist LLM Wiki d'Andrej Karpathy](https://gist.github.com/karpathy) est la source conceptuelle, et le blog post le cite directement : 'les LLMs ne s'ennuient pas, n'oublient pas de mettre à jour une référence croisée, et peuvent toucher 15 fichiers en une passe'. L'argument est que la comptabilité qui fait abandonner les wikis personnels aux humains (mettre à jour les références croisées, fixer les liens morts, restructurer les hiérarchies) est exactement ce que les LLMs font bien. Le même insight apparaît sous différentes formes à travers l'écosystème d'outillage IA. Les vaults Obsidian branchés à des agents de codage sont l'instance la plus visible : un développeur maintient un vault de notes sur son codebase, un agent lit le vault avant de travailler, l'agent met à jour le vault au fur et à mesure qu'il apprend, et le vault devient une mémoire vivante du projet qui devient de plus en plus utile avec le temps. La famille de fichiers de convention [AGENTS.md et CLAUDE.md](/articles/2026-03-23-claude-code-rise-ai-coding-tool-2026) est le même pattern sous forme d'un seul fichier : un unique fichier markdown à la racine du dépôt qu'un agent consulte avant de travailler, et que l'agent met à jour au fur et à mesure qu'il apprend les conventions du projet. Le pattern apparaît aussi dans les équipes data comme dépôts 'metadata as code', où la documentation des tables SQL, les définitions de métriques, et les runbooks vivent dans des fichiers markdown version-contrôlés plutôt que dans un registre de métadonnées séparé. La raison pour laquelle le pattern est réapparu est qu'il résout un problème devenu aigu à mesure que les agents sont devenus les consommateurs primaires de la connaissance enterprise. Le retrieval basé sur la recherche (trouve-moi un document qui contient la chaîne `weekly_active_users`) s'effondre quand l'agent a besoin d'assembler un contexte à partir de dix documents différents, avec des références croisées entre eux, dans un ordre spécifique, avec un niveau spécifique de confiance dans chaque pièce. Un répertoire de fichiers markdown structurés permet à l'agent de naviguer dans la structure : lire l'index racine, décider quel sous-répertoire est pertinent, lire l'index du sous-répertoire, décider quel concept ouvrir, lire le concept, suivre les liens croisés. La navigation est explicite dans le système de fichiers et explicite dans le frontmatter, ce qui est la partie qui la rend à la fois lisible par un humain et navigable par un agent. La raison pour laquelle le pattern a été en désordre jusqu'ici est que chaque instance est bespoke. Le wiki de Karpathy et le wiki de votre équipe et l'export de catalogue d'un vendor peuvent tous se ressembler (markdown, frontmatter, liens croisés), mais aucun d'eux n'est intentionnellement conçu pour coopérer. Il n'y a pas de réponse convenue à quels champs chaque document devrait porter, ou à ce que les noms de fichiers veulent dire. En conséquence, la connaissance encodée dans les wikis reste siloed au sein des équipes d'origine, menant à un effort redondant à chaque fois qu'un nouvel agent est construit. OKF est la réponse à la question 'quel est le plus petit ensemble de conventions qui permet à toutes ces instances de coopérer', et la réponse est assez petite pour tenir dans une spec de 1 000 lignes. La chose à remarquer sur le pattern est qu'il est en aval de trois idées plus anciennes, et la filiation est une partie de la raison pour laquelle la spec est si minimale. La première est le pattern de static-site-generator (Hugo, Jekyll, MkDocs, Docusaurus), qui rend du markdown + frontmatter depuis plus d'une décennie. La seconde est le pattern de personal-knowledge-management (Obsidian, Notion, Roam, Logseq), qui maintient du markdown + frontmatter + liens croisés pour usage personnel depuis presque aussi longtemps. La troisième est le pattern de documentation-as-code (docs en markdown dans le même dépôt que le code, déployé à chaque release), qui est maintenant le défaut pour presque tout produit developer-facing. OKF est la combinaison des trois, avec l'agent comme nouveau consommateur, et la spec est minimale parce que les patterns sous-jacents sont déjà minimaux. Le travail était déjà là ; OKF est la partie qui le nomme. ## Ce que Google livre : quatre artefacts de référence, une intégration stratégique Les implémentations de référence sont délibérément appelées 'proofs of concept' dans le README, et le cadrage est important : le format est la contribution, et les outils existent pour rendre le format tangible aux deux extrémités de l'axe producteur/consommateur. Google a livré quatre artefacts distincts dans la même release, et chacun est la réponse à une question spécifique sur la manière dont le format fonctionne en pratique. L'agent d'enrichissement est l'extrémité producteur. C'est un package Python (`enrichment_agent`, installé via `python3.13 -m venv .venv && .venv/bin/pip install -e .[dev]`) construit sur le [Google Agent Development Kit](https://adk.dev/) avec Gemini comme backend de modèle. L'agent tourne en deux passes. La première passe parcourt un dataset BigQuery, lit le schéma et les métadonnées pour chaque table et vue, et écrit un document de concept OKF par concept que la source annonce. La seconde passe fait tourner le LLM comme son propre crawler : il reçoit une liste d'URLs de seed, fetch les seeds, et décide quels liens sortants valent la peine d'être suivis selon qu'ils ressemblent à de la documentation autoritaire pour les concepts existants. Pour chaque page qu'il fetch, l'agent choisit d'enrichir un ou plusieurs docs de concept existants, de minter un doc `references/` autonome, ou de skip. Un cap dur `--web-max-pages` et un filtre allowed-hosts same-domain sont enforced à l'intérieur de l'outil, donc l'agent ne peut pas dériver. La CLI est une commande : ``` .venv/bin/python -m enrichment_agent enrich \ --source bq \ --dataset . \ --web-seed-file \ --out ./bundles/ ``` L'interface Source est conçue pour grandir. BigQuery est la première implémentation source ; Dataplex, Unity Catalog, Collibra, et un walker de base de données sont tous nommés dans le README comme cibles, et l'interface est le point d'extension documenté pour toute nouvelle source. Le visualiseur HTML statique est l'extrémité consommateur. C'est une sous-commande `visualize` sur le même package Python, et elle rend n'importe quel bundle OKF comme un fichier HTML interactif auto-contenu : un seul fichier, pas de backend, pas d'install côté visualisation. Le viewer montre un graphe force-directed de chaque concept dans le bundle, avec des nœuds colorés par type (datasets, tables, references) et des arêtes dirigées tracées depuis chaque cross-link dans les bodies markdown. Un panneau de détail pour le concept sélectionné montre son frontmatter (description, lien resource, tags) et son body markdown rendu, avec les liens internes recâblés pour naviguer à l'intérieur du viewer au lieu de suivre le chemin. Une liste de backlinks 'Cited by' est calculée à partir de l'inverse du graphe de liens. Une boîte de recherche matche titre, concept id, et tags, un filtre de type restreint les nœuds visibles, et des layouts de graphe commutables (cose, concentric, breadth-first, circle, grid) permettent à un curateur d'explorer le corpus de différentes manières. La visualisation est générée par cytoscape.js, embarquée dans un seul fichier HTML auto-contenu, et le fichier peut être ouvert localement, partagé comme artefact, ou hébergé sur un serveur de fichiers statique. Les trois bundles d'exemple sont les exemples vivants. Le premier est le [bundle GA4 e-commerce](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf/bundles/ga4), généré depuis le dataset public GA4 BigQuery Export et seedé avec les URLs de documentation GA4 canoniques. Le second est le [bundle Stack Overflow](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf/bundles/stackoverflow), généré depuis le dataset public Stack Exchange Data Dump et seedé avec les références de schéma canoniques de la communauté ; il exerce l'enrichissement multi-concept depuis des pages de docs cross-cutting. Le troisième est le [bundle Bitcoin](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf/bundles/crypto_bitcoin), généré depuis le pipeline `bitcoin-etl` et seedé avec la documentation du protocole Bitcoin ; il exerce les relations de foreign key cross-table en prose, le type de connaissance qui est difficile à représenter dans un schéma relationnel et facile à représenter en quelques phrases de markdown. Chaque sample apparie une recette (les URLs de seed et la commande `enrich` exacte, dans `samples//`) avec le bundle produit (dans `bundles//`), donc un développeur peut reproduire le bundle sur sa propre machine avec une commande. Les bundles d'exemple sont aussi la preuve la plus solide que le format fonctionne à une échelle non-triviale : le bundle GA4 a des centaines de documents de concept et un graphe de liens richement connecté, et le visualiseur le rend sans problèmes de performance. L'intégration au Knowledge Catalog BigQuery est le mouvement stratégique. Le [Knowledge Catalog](https://cloud.google.com/bigquery/docs/knowledge-catalog) est le service de métadonnées intégré de BigQuery, la surface qui alimente l'autocomplete SQL, la découverte de schéma, et l'intégration avec les agents Vertex AI. Au lancement d'OKF, le Knowledge Catalog peut ingérer des bundles OKF nativement : une équipe peut faire tourner l'agent d'enrichissement contre son dataset BigQuery, produire un bundle OKF, et le pousser au catalogue sans écrire d'intégration custom. Le catalogue sert alors le contenu OKF aux agents qui requêtent BigQuery, avec le frontmatter devenant les métadonnées indexables et le body devenant le contexte lisible par l'agent. L'intégration est documentée séparément, dans la documentation BigQuery, plutôt que dans la spec OKF, et la séparation est délibérée : la spec est platform-neutral, et l'intégration est une commodité spécifique à la plateforme Google par-dessus. Les quatre artefacts ensemble font un travail différent de celui qu'ils ont l'air de faire. L'agent d'enrichissement n'est pas un produit, c'est une implémentation de référence. Le visualiseur n'est pas un produit, c'est une implémentation de référence. Les bundles d'exemple ne sont pas des produits, ce sont des exemples de référence. L'intégration BigQuery est le seul des quatre qui est un produit, et c'est la partie qui est positionnée comme un value-add pour les clients BigQuery plutôt qu'un lancement de produit séparé. L'architecture est la même que celle que Google a utilisée pour Kubernetes, TensorFlow, et gRPC : publier la spec ouverte, livrer une implémentation de référence de haute qualité, et laisser les intégrations produit suivre l'adoption de la spec. La stratégie est bien testée, et la spec est bien positionnée pour être le type de chose qui devient le défaut sans jamais être la seule option. ## Le précédent : qui fait déjà ça, et ce qui change La question intéressante pour les six prochains mois n'est pas de savoir si OKF est un bon format, la spec est bonne, le format est minimal, et les implémentations de référence fonctionnent. La question intéressante est de savoir si le pattern qu'OKF nomme, le pattern LLM-wiki, était déjà en train de converger vers une convention communautaire avant que Google publie la spec, et si la spec accélère la convergence ou la fragmente. Le pattern était déjà en train de converger, et la preuve est la liste des communautés qui sont arrivées indépendamment à la même forme. La communauté [Hugo](https://gohugo.io/) fait du markdown + frontmatter + liens croisés pour des sites statiques depuis 2013. La communauté [Obsidian](https://obsidian.md/) fait la même chose pour le personal knowledge management depuis 2020, avec un écosystème de plugins qui inclut déjà des exports en forme OKF. Les communautés [Docusaurus](https://docusaurus.io/) et [Astro](https://astro.build/) font du markdown + frontmatter pour des sites de documentation depuis 2017 et 2021 respectivement. La communauté data-engineering fait du 'metadata as code' sous diverses formes (dbt docs, LookML views avec descriptions, BigQuery INFORMATION_SCHEMA + markdown écrit à la main) depuis au moins cinq ans. La communauté d'outillage IA fait de l'AGENTS.md / CLAUDE.md / context.md depuis les dix-huit derniers mois. Le [gist LLM Wiki de Karpathy](https://gist.github.com/karpathy) a cristallisé le pattern comme recommandation, et le [blog post context engineering d'Anthropic](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) a formalisé les principes à la mi-2025. Le pattern est le point de convergence, et OKF est la première spec à le revendiquer. Ce qui change avec la spec est la réponse à la question 'quel est le plus petit ensemble de conventions qui permet à toutes ces instances de coopérer'. Avant OKF, la réponse était 'rien, elles se ressemblent juste un peu'. Après OKF, la réponse est 'la spec v0.1, qui fait 1 000 lignes et tient sur une seule page'. Le changement n'est pas dans le format lui-même, le format était déjà là, le changement est dans le fait social qu'il y a maintenant une spec publiée que n'importe qui peut pointer, que n'importe qui peut implémenter contre, et que n'importe qui peut forker s'il n'est pas d'accord avec les choix de design. La spec est un point de coordination, et les points de coordination sont l'artefact le plus précieux dans tout écosystème qui a plus de trois participants. La question compétitive, celle qui va se jouer sur les six prochains mois, est de savoir si OKF devient la lingua franca, ou si une spec concurrente émerge d'un coin différent de l'écosystème IA. Les candidats specs concurrentes les plus crédibles sont le travail context.md d'Anthropic (s'il se formalise au-delà du blog post d'ingénierie), le format de resource de la communauté [MCP (Model Context Protocol)](https://modelcontextprotocol.io/) (qui est basé sur JSON-RPC et pas en markdown), et les formats de graph-store de [Cognee](https://www.cognee.ai/) / [LlamaIndex](https://www.llamaindex.ai/) (qui sont basés sur JSON et en forme de base de données plutôt que de fichiers). Chacune a une constituency, et chacune résout un problème légèrement différent : MCP est pour le tool-calling runtime, les formats de graph-store sont pour le retrieval vectoriel, et OKF est pour les corpus human-readable, version-contrôlés, agent-navigables. Les problèmes se chevauchent mais ne sont pas identiques, et le résultat le plus probable est la coexistence plutôt que la consolidation. La raison est que les trois formats résolvent trois problèmes différents, et la même équipe qui utilise MCP pour le tool-calling et LlamaIndex pour le retrieval utilisera OKF pour la documentation que l'agent lit pour comprendre le contexte. La question stratégique pour Google est de savoir si l'intégration au Knowledge Catalog BigQuery suffit à faire d'OKF le défaut, ou si l'écosystème a besoin de moats additionnels. L'intégration est un moat solide pour les clients BigQuery, mais elle n'aide pas les équipes qui tournent sur Snowflake, Databricks, ou Redshift. Les implémentations de référence sont délibérément platform-neutral, mais le producteur de haute qualité dans le set de référence (l'agent d'enrichissement) est BigQuery-only en v0.1. Le pari est que l'adoption de la spec viendra des équipes qui utilisent déjà BigQuery, que les clients BigQuery produiront les bundles OKF les plus utiles, et que les bundles pulleront les consommateurs non-BigQuery parce que les bundles sont bons. Le pari est plausible, et la timeline est la partie à surveiller : si Snowflake ou Databricks publie une spec concurrente dans les six mois, la guerre de format a commencé ; si aucune spec concurrente n'émerge dans l'année, OKF a gagné par défaut. La chose qui rend le pari plausible est l'ouverture de la licence et du design. OKF est publié sous Apache-2.0, la même licence qui a été le fondement de l'écosystème open-source moderne (Kubernetes, TensorFlow, Swift, projets Apache Foundation). La licence permissive est la partie qui rend la spec forkable, la partie qui rend les implémentations alternatives bienvenues, et la partie qui fait de la spec une candidate à l'adoption par des équipes philosophiquement allergiques à tout ce qui ressemble à un standard contrôlé par Google. La licence permissive est aussi la partie qui rend la spec mal adaptée à un fork hostile : une spec concurrente devrait être significativement différente, pas juste différemment brandée, et le seuil de différence significative est élevé quand la spec sous-jacente est déjà aussi minimale. ## Ce qu'il faut surveiller Les 24 prochaines heures et les 24 prochaines semaines ont chacune des signaux spécifiques qui valent la peine d'être suivis. OKF v0.1 est un point de départ, et les signaux qui décideront s'il devient une spec category-defining ou un format one-off sont tous observables. Pour la semaine prochaine : - **Les premières PRs communautaires du dépôt.** Le dépôt est à 3 300 étoiles, 213 forks, et 22 issues ouvertes à la date de l'article, et les premières PRs communautaires donneront le ton de l'évolution de la spec. Une PR qui ajoute un nouveau champ frontmatter optionnel est un signal sain (la spec est étendue de la manière dont elle a été conçue pour l'être). Une PR qui ajoute un champ obligatoire concurrent est un warning sign (la communauté est déjà en train de forker le design). Une PR qui ajoute une nouvelle implémentation de référence sur une source non-BigQuery (Snowflake, Databricks, Postgres) est le signal le plus fort de traction écosystème. - **Le premier bundle OKF non-Google.** Les trois bundles d'exemple sont tous produits par Google. Le premier bundle OKF non-Google, posté sur GitHub ou Hacker News dans les sept prochains jours, est le test le plus direct de l'adoption de la spec au-delà de l'écosystème BigQuery. La source la plus probable est un développeur qui maintenait un wiki LLM à la Karpathy et cherchait un moyen de partager le format ; la source la plus valuable est une équipe data dans un shop non-BigQuery qui a décidé de standardiser sur OKF. - **Le premier visualiseur tiers.** Le visualiseur de référence est un seul fichier HTML auto-contenu généré par le package Python Google. Un visualiseur tiers, écrit dans un langage différent (TypeScript, Go, Rust) ou utilisant une bibliothèque de visualisation différente (d3, vis.js, sigma.js), est le signal le plus fort d'adoption côté consommateur. Le premier à apparaître est probablement un port TypeScript qui utilise vis-network ou react-flow, parce que l'audience de développeurs pour les bibliothèques de visualisation est fortement TypeScript. - **La première mention OKF dans un blog post d'outillage IA non-Google.** Le blog post et le tweet sont tous les deux Google. La première mention non-Google, dans un blog post Cursor, une release note Claude Code, un changelog LangChain, une annonce LlamaIndex, ou un cookbook OpenAI, est le premier signal que la spec a franchi le pas de 'projet Google' à 'standard communautaire'. Le venue le plus probable est un post Cursor ou Claude Code sur la manière dont l'équipe utilise OKF comme format pour la base de connaissance interne de l'outil. Pour les 24 prochaines semaines : - **Une release OKF v0.2.** v0.1 est un draft, et la première release v0.2 est le premier signal de la manière dont la spec est façonnée par le feedback communautaire. Le changelog v0.2 est la lecture la plus importante : quels champs optionnels ont été ajoutés, quels titres de section conventionnels ont été promus, quels critères de conformance ont été resserrés. Une v0.2 qui ajoute trop de champs est un signe que la spec perd sa minimalité ; une v0.2 qui en ajoute trop peu est un signe que la spec est sous-curated. - **Une implémentation source non-Google équivalente à BigQuery.** L'agent d'enrichissement est BigQuery-only en v0.1. La première implémentation source non-BigQuery (Snowflake, Databricks, Postgres, MySQL, un walker SQL générique) est le premier signal que le format est adopté comme standard multi-vendor. La source la plus probable est une PR communautaire au dépôt existant, pas un nouveau dépôt, parce que le nom du format est plus découvrable quand il vit à un seul endroit. - **Un produit OKF-compatible d'un concurrent de BigQuery.** Snowflake Cortex, Databricks Unity Catalog, Redshift Spectrum, ou tout autre produit data-warehouse-adjacent livrant un chemin d'ingestion OKF-compatible est le premier signal que la spec est devenue un champ de bataille concurrentiel. La timeline la plus probable est Q4 2026 ou Q1 2027, parce que les vendors de data-warehouse ont historiquement été lents à adopter des standards ouverts initiés par des concurrents. - **La réponse d'Anthropic.** Anthropic a son propre travail de context engineering, le protocole MCP, et un intérêt fort pour le pattern LLM-wiki. Le premier post Anthropic qui mentionne OKF, soit positivement (comme un complément utile à MCP) soit négativement (comme un format qui ne répond pas aux besoins d'Anthropic), est le premier signal de la manière dont le deuxième plus grand lab IA se positionne relativement à la spec. Une mention positive serait un endorsement majeur ; une mention négative serait le premier tir d'une guerre de format. - **Le premier bundle OKF avec plus de 10 000 concepts.** Les bundles de référence ont des centaines de concepts. Le premier bundle OKF avec plus de 10 000 concepts est le premier signal que le format fonctionne à l'échelle d'une vraie entreprise. La source la plus probable est une équipe data qui a décidé d'exporter un corpus INFORMATION_SCHEMA BigQuery entier vers OKF, qui est le cas d'usage naturel de l'agent d'enrichissement BigQuery. La performance du visualiseur sur un bundle de 10 000 concepts est le premier signal de la viabilité du format pour des corpus véritablement grands. - **Une release OKF v1.0 avec breaking changes.** v0.1 est explicitement un draft. La première release v1.0, avec quels que soient les breaking changes que le processus de curation a accumulés, est le premier signal de la question de savoir si OKF va suivre le pattern IETF/W3C d'évolution lente, soignée, backward-incompatible, ou le pattern Kubernetes d'évolution fréquente, soignée, backward-incompatible. Les breaking changes que v1.0 introduit sont le premier signal de quels choix de design la communauté est prête à défendre et lesquels elle est prête à réviser.