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

Dans la plupart des organisations, la connaissance dont ont besoin les modèles est fragmentée entre des dizaines de systèmes incompatibles : catalogues de métadonnées avec leurs propres API, wikis internes, commentaires dans le code, documentation dans des drives partagés, et savoirs tacites dans la tête de quelques experts seniors.

Quand un agent doit répondre à une question comme "comment calculer nos utilisateurs actifs hebdomadaires depuis notre flux d'événements ?", il doit assembler la réponse depuis des plateformes mutuellement incompatibles. Chaque éditeur de catalogue réinvente les mêmes modèles de données, et la connaissance reste prisonnière de la surface qui l'a créée.

Le résultat : chaque équipe qui construit un agent résout le même problème d'assemblage de contexte depuis zéro, de manière bespoke, sans interopérabilité possible.

Ce qu'est concrètement l'OKF

L'Open Knowledge Format entend répondre à ce problème avec une approche délibérément minimaliste. Un bundle OKF est un répertoire de fichiers Markdown. Chaque fichier représente un concept : une table de base de données, une métrique métier, un runbook, une procédure, une API dépréciée. Le chemin du fichier correspond à l'identité du concept.

Chaque fichier commence par un bloc YAML avec un petit ensemble de champs structurés : type, title, description, resource, tags, timestamp. Seul le champ type est obligatoire. Tout le reste, y compris la structure du corps en Markdown, est laissé à la discrétion du producteur.

Voici à quoi ressemble un document OKF minimal, tel que fourni dans la spécification officielle de Google :

---

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

---

# Schema

| Column     | Type   | Description                         |

|------------|--------|-------------------------------------|

| order_id   | STRING | Globally unique order identifier.   |

| customer_id| STRING | FK to [customers](/tables/customers.md). |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

Les concepts se lient entre eux via des liens Markdown standard, transformant le répertoire en un graphe de relations. Les bundles peuvent aussi inclure des fichiers index.md pour la navigation hiérarchique, et des fichiers log.md pour l'historique chronologique des modifications.

Ce que Google insiste à souligner : pas de schéma de compression complexe, pas de nouveau runtime, pas de SDK obligatoire. Le bundle OKF est simple "du Markdown, des fichiers et du YAML frontmatter". Il peut être versionné dans Git, hébergé sur n'importe quel dépôt, rendu lisible sur GitHub, indexé par n'importe quel outil de recherche.

Les trois principes de conception

Google articule le design autour de trois axes.

1. Minimalisme : l'OKF n'impose qu'une seule chose à chaque document ; un champ type. Ce que sont les types, quels autres champs inclure, quelle structure adopter dans le corps : tout cela reste à la discrétion du producteur. La spécification définit la surface d'interopérabilité, pas le modèle de contenu.
2. Indépendance producteur/consommateur : un bundle rédigé à la main par un humain peut être utilisé par un agent IA. Un bundle généré par un pipeline d'export de métadonnées...