Qu'est-ce que l'Open Knowledge Format (OKF) ? Le standard Markdown de Google pour les agents IA

Le 12 juin 2026, l’équipe data de Google Cloud a publié l’Open Knowledge Format (OKF), une spécification ouverte pour représenter un corps de connaissance comme un répertoire de fichiers Markdown. Pas de nouveau produit, pas de SaaS, pas de SDK : et c’est exactement ce qui le rend intéressant. À l’heure où chaque éditeur essaie de vous enfermer dans sa plateforme, Google publie un format que personne ne possède : du Markdown, des fichiers, point.

Cet article explique ce qu’est l’OKF, comment il est structuré, pourquoi il tombe pile au bon moment pour les agents IA, et ce qui le distingue d’un knowledge graph ou d’un outil comme NotebookLM.

Le problème que l’OKF cherche à résoudre

Quand un agent IA doit répondre à une question métier (« calcule les utilisateurs actifs hebdomadaires »), il assemble sa réponse à partir de sources fragmentées : un catalogue de métadonnées ici, un wiki là, des commentaires dans le code, une définition de métrique dans une feuille de calcul. Chaque agent réinvente ce travail de glanage, et chaque organisation le structure différemment.

L’OKF formalise un schéma déjà émergent que Google appelle le pattern « LLM-wiki » : une bibliothèque de connaissances curée, écrite une fois, que n’importe quel agent peut consulter. L’idée centrale est de séparer proprement le producteur du consommateur : qui écrit le savoir n’a pas à savoir qui le lira, et inversement (Google Cloud Blog, How the Open Knowledge Format can improve data sharing).

La structure : juste des fichiers, juste du Markdown

Un bundle OKF est un répertoire de fichiers Markdown, organisés par concept. Un concept, c’est tout ce que vous voulez capturer : une table, un jeu de données, une métrique, un runbook, une API, un personnage de roman. La règle fondatrice : le chemin du fichier est l’identité du concept.

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

Trois propriétés en découlent, et c’est tout ce qui fait l’OKF :

Juste du Markdown : lisible dans n’importe quel éditeur, rendu sur GitHub, indexable par n’importe quel outil de recherche.
Juste des fichiers : livrable en tarball, hébergeable dans un dépôt git, montable sur un système de fichiers.
Juste du frontmatter YAML : pour les quelques champs structurés que l’on veut pouvoir requêter.

Pas de compression exotique, pas de runtime, pas de base de données. Si vous savez écrire un fichier .md, vous savez produire de l’OKF.

Le frontmatter : un seul champ obligatoire

Chaque document de concept porte un frontmatter YAML en tête. Et là, l’OKF fait un choix radical de simplicité : un seul champ est requis :

---
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, revenue]
timestamp: 2026-05-28T14:30:00Z
---

type : le seul champ obligatoire. Il décrit la nature du concept (table, métrique, personnage, endpoint…). C’est ce qui permet à un agent de savoir ce qu’il lit sans deviner.
title, description, resource, tags, timestamp : champs standard optionnels. resource pointe vers la ressource réelle (URL), timestamp date la dernière mise à jour en ISO 8601.

Au-delà de ces champs, les producteurs définissent les leurs. La spécification ne dicte ni les types disponibles, ni le modèle de contenu, ni les sections du corps. Elle est, selon les mots de Google, « minimalement opinionnée ».

Les liens croisés : un graphe avec des liens Markdown ordinaires

C’est l’élément qui transforme un dossier de fichiers en base de connaissance. Les concepts se relient entre eux avec de simples liens Markdown :

| `customer_id` | STRING | Clé étrangère vers [customers](/tables/customers.md). |

Jointe avec [customers](/tables/customers.md) sur `customer_id`.

Le résultat est un graphe de relations plus riche que la simple hiérarchie parent/enfant du système de fichiers. Un agent qui lit orders.md découvre, en suivant le lien, qu’il existe une table customers et comment elles se joignent, sans qu’on ait eu à le lui expliquer dans le prompt.

Les fichiers réservés : `index.md` et `log.md`

La spécification réserve deux noms de fichiers, tous deux optionnels :

index.md : permet une divulgation progressive. À mesure qu’un agent descend dans la hiérarchie, le index.md de chaque dossier lui donne une vue d’ensemble avant de plonger dans les concepts individuels.
log.md : un historique chronologique des changements apportés aux concepts.

La spécification complète, critères de conformité, règles de liens croisés et noms réservés compris, tient sur une seule page (spécification officielle, GoogleCloudPlatform/knowledge-catalog).

« Format, not platform »

C’est le principe directeur, et il mérite qu’on s’y arrête. Google insiste : l’OKF est vendor-neutral. Pas de compte propriétaire, pas de cloud imposé, pas de SDK requis. Un bundle OKF :

survit au déplacement entre systèmes, organisations et outils ;
se versionne avec git, à côté du code qu’il décrit ;
est lisible par les humains et les machines dans le même fichier, sans couche de traduction.

Google fournit d’ailleurs des implémentations de référence pour amorcer l’écosystème : un enrichment agent qui parcourt des bases de données BigQuery pour générer de l’OKF enrichi par un LLM, un visualiseur HTML statique (un seul fichier autonome, sans backend) qui rend un bundle comme un site navigable, et des bundles d’exemple (GA4 e-commerce, Stack Overflow, Bitcoin).

OKF, knowledge graph, NotebookLM : trois choses différentes

La confusion est fréquente. Démêlons.

OKF vs knowledge graph

Un knowledge graph est un modèle de données abstrait : des entités et des relations, souvent stockées dans une base de données à graphe (triplets RDF, propriétés, etc.). L’OKF est un format de fichiers concret qui peut exprimer des relations via des liens Markdown. L’un est une théorie de la donnée, l’autre est une manière de l’écrire sur disque. On peut sérialiser une partie d’un knowledge graph en OKF, mais ce ne sont pas les mêmes objets.

OKF vs NotebookLM (ou tout autre application)

NotebookLM est une application : vous y téléversez des documents, vous posez des questions dans son interface, et tout reste chez Google. L’OKF est un format : il définit comment structurer des fichiers pour qu’ils soient lisibles par n’importe quel outil.

Ces deux choses sont orthogonales. Vous pouvez parfaitement déposer un bundle OKF dans NotebookLM. Mais vous pouvez aussi le donner à Claude, à GPT, à un agent maison, à un script Python, sans être enfermé dans une plateforme. La vraie question est : voulez-vous une session de questions-réponses interactive (une application le fait bien), ou une base de connaissance portable et programmatique que des agents peuvent traverser, que vous versionnez avec git, et qui vit à côté de votre code ou de vos textes ? L’OKF répond à la seconde.

Le bon moment, le bon niveau d’ambition

L’OKF arrive précisément là où le besoin se fait sentir : des agents IA partout, et nulle part une façon simple de leur donner du contexte curé. Google a choisi de publier tôt et léger, une spec d’une page plutôt qu’un comité de standardisation de trois ans, et c’est une bonne nouvelle. Le format est déjà utilisable aujourd’hui, et conçu pour grandir proprement :

Le catalogue des type, libre par défaut, laisse chaque domaine inventer son vocabulaire avant que les conventions les plus utiles ne s’imposent d’elles-mêmes.
L’interopérabilité est la promesse centrale : un wiki écrit par l’un, consommé par l’autre sans traducteur. C’est exactement ce que rend possible un format de fichiers nu.
Le versionnement de la spécification est pensé dès le départ pour rester rétrocompatible.

En bref

OKF = un répertoire de fichiers Markdown + frontmatter YAML, publié par Google Cloud le 12 juin 2026 pour donner du contexte curé aux agents IA.
Un seul champ obligatoire : type. Le reste (title, description, resource, tags, timestamp) est optionnel ; les producteurs ajoutent leurs propres champs.
Les concepts se relient par de simples liens Markdown, formant un graphe. Fichiers réservés optionnels : index.md, log.md.
Format, pas plateforme : pas de SDK, versionnable dans git, lisible par humains et machines.
Différent d’un knowledge graph (modèle abstrait) et d’une application comme NotebookLM (plateforme) : c’est un format portable d’un outil à l’autre.

L’OKF déplace la question du « quel outil consomme mon savoir ? » vers « mon savoir est-il écrit dans un format que n’importe quel outil peut lire ? ». Et puisque ce format n’est rien d’autre que du Markdown bien rangé, n’importe quel éditeur Markdown, comme Draft_, peut déjà servir à en produire.