Open Knowledge Format : la spec Markdown de Google

Le 12 juin 2026, Google Cloud a publié une spécification décrivant comment les agents IA doivent lire et échanger des connaissances organisées. On pourrait s’attendre à une base de données en graphe, un registre de schémas, un SDK, et un service pour le faire tourner.

Au lieu de ça, l’Open Knowledge Format se résume à ceci : un dossier de fichiers Markdown avec du frontmatter YAML.

C’est tout le format. Et cette sobriété est justement ce qu’il y a d’intéressant.

La spec est plus petite qu’on ne le croit

La plupart des articles sur OKF se contentent de résumer l’annonce. Ça vaut le coup de lire la spec elle-même, parce que sa surface est étonnamment réduite.

OKF v0.1 exige exactement un champ sur chaque document de concept :

---
type: BigQuery Table
---

C’est tout. type est une courte chaîne identifiant le genre de concept que décrit le document, utilisée pour le routage et le filtrage. Les valeurs ne sont pas enregistrées de façon centralisée — il n’y a pas de comité qui valide la liste des types possibles. Les producteurs choisissent des descripteurs explicites et passent à la suite.

Cinq autres champs sont recommandés, aucun n’est obligatoire :

Champ	Objectif
title	Nom affiché. Si absent, les consommateurs peuvent le déduire depuis le nom du fichier.
description	Résumé en une phrase.
resource	Une URI identifiant de façon unique la ressource sous-jacente.
tags	Une liste YAML, pour une catégorisation transversale.
timestamp	Date et heure ISO 8601 de la dernière modification.

Les producteurs peuvent ajouter les clés personnalisées de leur choix. Les consommateurs doivent préserver les champs inconnus plutôt que de rejeter le document.

Un document de concept complet et conforme ressemble à ça :

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders]
timestamp: 2026-05-28T00:00:00Z
---

# Schema

| Column | Type | Description |
|--------|------|-------------|
| order_id | STRING | Unique identifier |

Si vous avez déjà écrit une note Obsidian avec du frontmatter, vous avez déjà écrit quelque chose de très proche d’un concept OKF valide.

Le graphe de connaissances sans base de données en graphe

Voici la décision de design qui mérite d’être piquée, que vous adoptiez OKF ou non.

Les relations entre concepts sont exprimées via des liens Markdown standards. Pas des arêtes dans une base de données. Pas un bloc relationships: dans le frontmatter. Juste des liens :

Each order references a [customer](/tables/customers.md).

Les chemins absolus relatifs au bundle (commençant par /) sont recommandés pour la stabilité ; les chemins relatifs classiques comme ./other.md fonctionnent aussi.

Et voici la partie qui fait que ça marche : le type de relation est porté par la prose environnante, pas par le lien. “Chaque commande référence un client” est le label de l’arête. Il n’y a pas d’ontologie à maintenir, pas de vocabulaire de prédicats à négocier, parce que le langage naturel en a déjà un, et le consommateur est un modèle de langage.

Une décennie d’outillage autour des graphes de connaissances a été investie pour formaliser les types de relations afin que les machines puissent les interpréter. Le pari d’OKF, c’est que ce n’est plus nécessaire — la machine comprend le langage naturel, maintenant.

Deux noms de fichiers réservés

Seuls deux noms de fichiers ont une signification particulière dans un bundle :

• index.md — un sommaire du dossier qui permet une divulgation progressive. Il ne porte pas de frontmatter. Un agent lit d’abord l’index et ne suit que les liens dont il a besoin, plutôt que de charger tous les concepts dans son contexte.
• log.md — un historique chronologique des mises à jour, avec des titres de date ISO 8601, du plus récent au plus ancien.

Tous les autres fichiers .md sont des documents de concept. Un bundle finit par ressembler à un dossier ordinaire, navigable :

sales/
├── index.md
├── datasets/orders_db.md
├── tables/orders.md
└── metrics/weekly_active_users.md

index.md est celui qui compte discrètement le plus. C’est le même réflexe qui se cache derrière un bon CLAUDE.md : ne pas déverser toute la bibliothèque dans la fenêtre de contexte, mais donner à l’agent une table des matières et le laisser aller chercher.

Ce qu’OKF n’est pas

Ce n’est pas du RAG. Le RAG redérive la connaissance au moment de la requête, en récupérant des morceaux de texte bruts et en espérant que les bons remontent. Un bundle OKF stocke des concepts organisés et reliés entre eux, qu’un agent lit et met à jour directement. La curation se fait une fois, délibérément, plutôt que d’être approximée à chaque requête.

Ce n’est pas AGENTS.md ou CLAUDE.md. Ce sont des fichiers d’instructions — ils indiquent à un agent comment se comporter dans un repo. OKF décrit de la connaissance métier : ce que signifie cette table, comment cette métrique est définie, pourquoi ce dataset a un trou en mars. Un rôle différent, complémentaire.

Ce n’est pas MCP. MCP est un protocole d’exécution pour connecter un agent à des systèmes vivants. OKF est un format de fichier qui repose sur disque. Les deux se combinent naturellement : MCP pour atteindre l’entrepôt de données, OKF pour expliquer ce qu’il contient.

Les règles de conformité sont volontairement indulgentes

Un bundle est conforme à OKF v0.1 si chaque fichier .md non réservé a un frontmatter YAML analysable, si chaque bloc de frontmatter a un type non vide, et si les fichiers réservés respectent leur structure quand ils sont présents.

Ce qui en dit plus long, c’est ce que la spec interdit aux consommateurs de faire. Un consommateur ne doit pas rejeter un bundle à cause de champs optionnels manquants, de valeurs de type inconnues, de clés inconnues, de liens croisés cassés, ou d’un index.md absent.

C’est un format conçu par des gens qui s’attendent à ce que les bundles soient à moitié terminés, en partie générés par des machines, et constamment en mouvement — ce à quoi ressemblent réellement les vraies bases de connaissances. Les formats stricts meurent de leur propre rigidité. Celui-ci est construit pour survivre au contact d’un dossier en bordel.

Google a livré de l’outillage de référence avec la spec : un agent d’enrichissement BigQuery, un visualiseur HTML statique, et trois bundles d’exemple.

Une réserve qui mérite d’être dite clairement : OKF est en v0.1, et explicitement un brouillon. La spec est versionnée et conçue pour évoluer de façon rétrocompatible, mais les noms de champs et les conventions peuvent encore bouger. Ne reconstruisez pas votre base de connaissances autour de ça aujourd’hui. Mais notez bien dans quelle direction pointe le standard.

Pourquoi ça compte au-delà de Google Cloud

Enlevez les exemples BigQuery, et OKF devient un pari avec un rayon d’action bien plus large : que le format durable pour la connaissance lisible par une machine, ce sont des fichiers Markdown bruts dans un dossier qui vous appartient.

Pas un catalogue propriétaire avec une API. Pas des embeddings dans une base vectorielle illisible pour vous. Pas un wiki avec un bouton d’export qui bousille vos tableaux. Des fichiers. Sur disque. Diffables, greppables, portables d’un fournisseur à l’autre, lisibles par un humain et par tous les modèles du marché.

C’est la même conclusion à laquelle Claude Code, Cursor, Copilot et Windsurf sont arrivés indépendamment en choisissant Markdown comme format d’instructions. Que Google Cloud le couche noir sur blanc dans une spec, c’est une confirmation, pas une invention.

La place de Minibase

Si vous tenez un Minibase Vault, vous entretenez déjà quelque chose de structurellement proche d’un bundle OKF : un dossier de fichiers Markdown avec frontmatter, sur votre propre disque, lu par Claude et ChatGPT.

Le rendre formellement conforme tient en une petite modif — ajoutez un type à votre frontmatter, et laissez vos liens faire le reste :

---
type: Article
title: How the Open Knowledge Format can improve data sharing
resource: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
tags: [okf, agents, markdown]
timestamp: 2026-07-19T00:00:00Z
---

C’est la forme concrète de cette annonce. La partie difficile d’une base de connaissances pour agents n’a jamais été le format de fichier — c’était d’y faire entrer de la bonne matière première. Une spécification vous dit comment façonner le dossier. Elle ne le remplit pas.

Minibase, c’est la partie qui le remplit : un clic transforme n’importe quelle page web — documentation, README GitHub, spec, thread, papier de recherche — en Markdown propre, posé dans votre dossier, prêt pour le prochain agent que vous lancez.

Le format est désormais standard. Ce que vous y mettez reste votre avantage.

---

Minibase transforme n’importe quelle page web en Markdown propre que vos agents peuvent lire — installez l’extension et commencez à construire le bundle qui rend vos agents plus intelligents.