Ce qu'il faut retenir :
- L'OKF est un répertoire de fichiers Markdown avec un en-tête YAML, sans SDK requis, sans runtime propriétaire : n'importe quel agent peut le lire, n'importe qui peut en produire.
- Le format formalise le "LLM-Wiki pattern" décrit par Andrej Karpathy : une base de connaissances vivante, maintenue par les agents eux-mêmes, organisée en concepts liés entre eux.
- Pour le SEO et le GEO, ce standard représente un glissement majeur : il ne s'agit plus seulement d'être trouvé par les moteurs de recherche, mais de rendre sa connaissance exploitable par les agents.
- Google a déjà mis à jour son Knowledge Catalog pour ingérer l'OKF et le servir à ses propres agents, ce qui donne au format une crédibilité immédiate.
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.
- 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.
- 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 peut être parcouru dans un visualiseur. Un bundle synthétisé par un LLM peut être interrogé par un autre. Le format est le contrat ; les outils aux deux extrémités sont indépendamment interchangeables.
- Un format, pas une plateforme : l'OKF n'est lié à aucun cloud, aucune base de données, aucun fournisseur de modèles, aucun framework d'agents. Il ne requerra jamais de compte propriétaire ni de SDK pour lire, écrire ou servir des bundles. Google publie la spécification en open source explicitement parce que la valeur d'un format de connaissance vient du nombre de parties qui l'adoptent, non de qui en est propriétaire.
La filiation avec le "LLM-Wiki pattern"
L'OKF formalise explicitement un pattern qui avait émergé dans la communauté des développeurs d'agents, théorisé notamment par Andrej Karpathy dans un gist publié sur GitHub. L'idée fondamentale est la suivante : plutôt que d'envoyer des agents chercher les mêmes documents pour les mêmes faits en boucle, on leur donne une bibliothèque Markdown partagée qui grandit en utilité au fil du temps.
Karpathy le formule ainsi : les LLM ne s'ennuient pas, n'oublient pas de mettre à jour une référence croisée, et peuvent modifier quinze fichiers en un seul passage. La bureaucratie de maintenance qui pousse les humains à abandonner leurs wikis personnels est précisément ce pour quoi les LLM sont bons.
Ce pattern apparaît sous des formes variées : des vaults Obsidian connectés à des agents de code, les conventions de fichiers AGENTS.md ou CLAUDE.md, des dépôts de index.md et log.md que les agents consultent avant tout travail réel. Chaque instance est faite sur mesure. L'OKF apporte la couche de standardisation qui permet à ces wikis de coopérer entre eux.
Ce que Google livre avec la spécification
Au-delà de la spec elle-même, Google publie plusieurs éléments concrets pour amorcer l'écosystème :
- Un agent d'enrichissement qui parcourt un dataset BigQuery, génère un document OKF pour chaque table et vue, puis effectue un second passage LLM qui enrichit chaque concept avec des citations, des schémas et des chemins de jointure.
- Un visualisateur HTML statique qui transforme n'importe quel bundle OKF en une vue graphique interactive dans un fichier HTML auto-contenu, sans backend, sans installation, sans que les données quittent la page.
- Trois bundles d'exemples prêts à parcourir, basés sur des datasets publics BigQuery (GA4 e-commerce, Stack Overflow, Bitcoin), produits par l'agent de référence et engagés dans le dépôt comme exemples vivants d'OKF conforme.
Google a également mis à jour son Knowledge Catalog pour ingérer l'OKF et le servir à ses agents, ce qui ancre le format dans un usage production réel dès son lancement.
Les implications pour le SEO et la visibilité des agents
Marie Haynes, consultante SEO reconnue, formule une observation centrale sur ce que représente ce changement de paradigme : nous passons d'un travail consistant à être trouvé par les moteurs de recherche à un travail consistant à rendre la connaissance d'une entreprise exploitable par les agents pour accomplir des tâches.
Cette évolution est profonde. Jusqu'ici, le GEO (Generative Engine Optimization) consistait à optimiser du contenu pour qu'il soit cité par les modèles génératifs dans leurs réponses. Avec l'OKF, la question est différente : comment structurer la connaissance d'une organisation pour qu'un agent puisse s'en emparer, naviguer dedans, et agir avec elle ?
Marie Haynes souligne que construire un bundle OKF de qualité pour une entreprise demandera un travail de fond : comprendre en profondeur les concepts sur lesquels une organisation a de la connaissance, documenter ses processus, cartographier les relations entre ses données. Ce n'est pas simplement convertir des pages web en Markdown. C'est construire le cerveau structuré d'une organisation.
Elle note également une opportunité commerciale émergente : la possibilité de vendre des bundles OKF de connaissance experte. Un avocat, un comptable, un consultant SEO pourrait vendre un bundle de ses processus propriétaires, que d'autres organisations pourraient intégrer directement dans leur propre système de connaissance pour le rendre accessible à leurs agents.
Premiers retours pratiques
Haynes documente ses premiers essais de création d'un bundle OKF à partir de ses propres évaluations de chutes de trafic. Elle a utilisé un outil pour extraire les concepts clés de plusieurs documents et les stocker en fichiers Markdown distincts, puis les a visualisés sous forme de graphe, où chaque noeud représente un concept et les arêtes expriment les relations entre eux. Elle a ensuite interrogé ce bundle via Gemini 2.0 Flash.
Elle précise que son test portait seulement sur trois documents d'entraînement, et que le système sera largement amélioré. Mais le principe est validé : on peut construire dès aujourd'hui une base de connaissance OKF fonctionnelle avec des outils accessibles.
Des outils de conversion de pages web en bundles OKF existent déjà, comme celui développé par Suganthan Mohanadasan. Mais Haynes insiste sur le fait que la vraie valeur réside dans la création d'un OKF sur mesure, pas dans la simple transposition mécanique de contenu existant.
Un standard ouvert pensé pour évoluer
Google présente explicitement l'OKF v0.1 comme un point de départ, non comme un standard achevé. La spécification tient en une seule page. Le format évoluera à mesure que producteurs et consommateurs émergeront, et que la communauté apprendra collectivement quelles représentations de la connaissance les agents ont réellement besoin en pratique.
La publication en open source dès le premier jour est un choix délibéré : la valeur d'un format de connaissance vient du nombre de parties qui l'adoptent. Les prochaines étapes que Google encourage : lire la spécification, écrire des producteurs pour différentes sources de données, écrire des consommateurs (visualisateurs, index de recherche, agents), tester l'implémentation de référence sur ses propres données, et contribuer au dépôt GitHub.
