Définition : OKF est un format ouvert pour rendre le contexte portable

Définir OKF simplement

Open Knowledge Format est une spécification ouverte publiée par Google Cloud pour représenter de la connaissance organisée dans un dossier. Dans sa version v0.1, un bundle OKF est composé de fichiers Markdown UTF-8, d'un frontmatter YAML en haut de chaque fichier, de liens Markdown entre concepts et de quelques conventions de bundle.

La définition la plus simple est donc celle-ci: OKF transforme un dossier de connaissances en contexte portable. Chaque fichier décrit un concept identifiable, par exemple une table, une métrique, une API, un playbook, une règle métier, une décision ou une source. Les liens entre fichiers donnent progressivement une structure de graphe.

Cette simplicité est volontaire. OKF ne demande pas de runtime, pas de SDK obligatoire, pas de base de données spécifique et pas de compte propriétaire pour lire un bundle. Un humain peut ouvrir les fichiers dans un éditeur. Un agent peut parser le frontmatter, parcourir les liens et utiliser le Markdown comme matière de raisonnement.

Ce qu'OKF standardise vraiment

OKF standardise surtout une surface minimale d'interopérabilité. Il définit une manière de reconnaître un bundle, de représenter un concept dans un fichier Markdown, d'ajouter des métadonnées structurées en YAML et d'utiliser les liens Markdown pour relier les concepts entre eux.

Le point important est que la spécification est peu prescriptive. Le champ `type` est le seul champ requis pour un concept. Des champs comme `title`, `description`, `resource`, `tags` ou `timestamp` sont utiles et recommandés selon les cas, mais OKF laisse les producteurs ajouter leurs propres champs métier.

Cette approche évite de figer trop tôt une taxonomie universelle. Une équipe data, une équipe support et une équipe produit n'ont pas les mêmes objets métier. OKF cherche donc à standardiser le contenant et quelques conventions de lecture, pas à imposer un modèle unique de connaissance.

Ce qu'OKF ne cherche pas à remplacer

OKF n'est pas une base de données. Il ne remplace pas BigQuery, Postgres, un CRM ou un data warehouse. Un fichier OKF peut pointer vers une table, décrire son schéma, expliquer ses usages et citer une source, mais il ne devient pas la donnée transactionnelle elle-même.

OKF n'est pas non plus un data catalog complet. Il peut représenter des métadonnées et des concepts de catalogue, mais il ne fournit pas à lui seul la gouvernance, les permissions, l'observabilité, la qualité de données ou les workflows de certification qu'un outil de catalogage mature peut offrir.

Enfin, OKF n'est pas un framework agent. Il ne décide pas comment l'agent planifie, appelle des outils, arbitre ses actions ou gère sa mémoire. Il fournit plutôt une matière première propre: un contexte mieux structuré, plus explicite et plus facile à transporter entre agents, moteurs de recherche, visualizers et humains.

Pourquoi parler de format plutôt que de plateforme

Le choix du mot format est central. Une plateforme concentre la valeur dans un produit. Un format permet à plusieurs producteurs et consommateurs de parler une langue commune. Google Cloud insiste sur cette distinction: OKF doit pouvoir être produit sans SDK obligatoire et consommé sans intégration propriétaire.

Cela change la logique d'adoption. Une équipe peut créer un bundle à la main, l'enrichir avec un script, le versionner dans Git, le visualiser dans un outil, puis le faire consommer par un agent. Les outils peuvent changer, mais le dossier reste lisible et transportable.

C'est aussi ce qui rend OKF intéressant pour les entreprises prudentes. Le contexte ne doit pas rester enfermé dans l'outil qui l'a généré. S'il devient un actif stratégique, il doit survivre aux changements de fournisseurs, de modèles, de clouds, de frameworks et d'organisations.

La définition opérationnelle pour une entreprise

Pour une entreprise, OKF peut être compris comme une couche de traduction entre la connaissance existante et les agents qui doivent l'utiliser. Il ne demande pas de réécrire toute l'organisation. Il demande de choisir un périmètre utile, puis de décrire les concepts critiques dans un format propre.

Un premier bundle peut par exemple contenir les métriques commerciales, les tables data, les règles de calcul, les playbooks support, les pages d'offre et les sources qui font foi. Le but n'est pas de tout documenter. Le but est de rendre explicite ce qui bloque les agents lorsqu'ils doivent produire une réponse fiable.

La valeur immédiate vient souvent de la clarification humaine: quelles définitions sont valides, quelles sources sont obsolètes, quelles décisions doivent être reliées, quelles procédures méritent d'être transformées en playbooks. L'agent bénéficie ensuite de ce travail, mais l'entreprise aussi.

Lire ensuite

Une fois la définition posée, les pages suivantes détaillent les briques concrètes du format: la structure d'un bundle, l'anatomie d'un concept, les liens qui forment le graphe et les règles minimales de conformité.

Sources officielles et lectures utiles