Limites OKF : ce que le format ne résout pas encore

Pourquoi parler des limites maintenant ?

Un guide crédible sur OKF doit dire ce que le format permet, mais aussi ce qu'il ne permet pas. Sinon, OKF risque de devenir un mot-valise: un peu SEO, un peu RAG, un peu knowledge graph, un peu data catalog, sans frontière claire.

Les limites ne diminuent pas l'intérêt du format. Au contraire, elles aident à l'utiliser correctement: sur un périmètre réduit, avec des sources citées, un owner, une revue humaine et des tests agents concrets.

La bonne posture est donc pragmatique. OKF peut améliorer la qualité du contexte, mais il ne garantit pas seul la qualité des décisions prises par les agents.

OKF v0.1 reste un format jeune

La spec officielle indique clairement une version `0.1` en draft. Cela signifie que le format est utile à tester, mais qu'il ne faut pas le présenter comme un standard mature, universellement adopté et stabilisé pour dix ans.

Les conventions autour des types de concepts, des champs additionnels, des outils de validation, des exports et des intégrations vont probablement évoluer. C'est normal pour un format naissant.

Pour une entreprise, la conséquence est simple: commencer petit, éviter de coupler toute une architecture critique à une interprétation trop rigide de la V1, et garder les bundles faciles à migrer.

OKF ne remplace pas les schémas métier

La spec OKF le dit explicitement: OKF ne remplace pas les schémas domain-specific comme OpenAPI, Avro ou Protobuf. Il peut les référencer, les expliquer, les relier à des usages métier, mais il ne devient pas le contrat technique de l'API ou de la donnée.

Un concept `API Endpoint` peut pointer vers une spec OpenAPI et expliquer quand appeler l'endpoint, avec quelles limites et depuis quel playbook. Mais la vérité contractuelle de l'endpoint reste dans OpenAPI.

De la même manière, un concept `Metric` peut expliquer une métrique et ses exclusions, mais il ne remplace pas le semantic layer, le SQL validé ou la définition opérationnelle utilisée par les systèmes analytiques.

OKF n'est pas une base de données

Un bundle OKF est un dossier de fichiers Markdown. Ce n'est pas une base transactionnelle, un warehouse, un CRM, un helpdesk, un moteur de recherche ou un vector store.

Il peut décrire une table, citer une source, expliquer un grain, lier un dashboard, documenter un owner et pointer vers un système source. Mais il ne stocke pas les transactions, ne garantit pas la fraîcheur des données et ne gère pas les permissions opérationnelles.

Cette distinction est essentielle: OKF transporte le contexte autour des systèmes; il ne devient pas ces systèmes.

OKF ne garantit pas la vérité du contenu

Un fichier OKF peut être proprement structuré et quand même contenir une information fausse. Le format rend la connaissance lisible, versionnable et citables; il ne vérifie pas automatiquement que chaque affirmation est vraie.

Les citations aident beaucoup, parce qu'elles obligent à relier les affirmations importantes à des sources. Mais une citation peut être ancienne, mal interprétée ou insuffisante.

La qualité d'un bundle dépend donc encore de pratiques humaines: revue, ownership, sources de vérité, tests, règles de mise à jour et capacité à retirer les informations obsolètes.

Un bundle mal maintenu peut devenir dangereux

Un mauvais bundle OKF peut être plus dangereux qu'un dossier non structuré, parce qu'il donne une impression de fiabilité. Un agent peut le lire avec confiance alors que son contenu est périmé.

Exemple: une policy de remboursement change dans le help center, mais le concept `support/refund-policy.md` n'est pas mis à jour. L'agent répond alors avec une ancienne règle, cite le bundle et crée une erreur opérationnelle.

La solution n'est pas d'éviter OKF, mais de traiter la maintenance comme une partie du produit: `log.md`, owners, revues périodiques, tests agents et suppression des concepts obsolètes.

La portabilité ne règle pas la gouvernance

La portabilité est une force d'OKF: un bundle peut vivre dans Git, une archive, un sous-dossier ou un système de fichiers. Mais être portable ne signifie pas être gouverné.

Une entreprise doit encore décider qui peut modifier le bundle, qui valide une source, comment gérer les données sensibles, quelles informations ne doivent pas être exposées à un agent, et comment auditer les changements.

OKF rend ces questions plus visibles, mais ne les résout pas à la place de l'organisation.

Le SEO direct n'est pas confirmé

Il n'existe pas de preuve officielle qu'OKF soit un signal direct de ranking Google Search. Présenter OKF comme une astuce SEO garantie serait une erreur.

L'impact crédible est indirect: mieux structurer les entités, les preuves, les sources, les pages, les relations et les capacités peut aider les agents, workflows internes et systèmes de réponse à mieux comprendre votre contenu.

Le SEO classique reste nécessaire: contenu utile, pages indexables, architecture claire, maillage, performance, données structurées quand pertinentes et crédibilité des sources.

L'adoption par les outils reste à construire

OKF est lisible sans outil, ce qui est une force. Mais sa valeur pratique augmentera avec l'adoption par les IDE, agents, moteurs de recherche internes, visualizers, CMS, data catalogs, plateformes documentaires et workflows d'entreprise.

Aujourd'hui, une équipe peut déjà écrire, versionner et consommer un bundle. Mais il faudra du temps pour que des conventions partagées émergent autour des types, validations, intégrations, exports et UI.

C'est une raison de commencer maintenant sur des périmètres limités, pas une raison de tout migrer d'un coup.

Exemple concret : quand OKF aide, et quand il ne suffit pas

Prenons une métrique `monthly_recurring_revenue`. OKF aide à documenter la définition, la formule, les exclusions, la table source, le dashboard officiel, l'owner et les décisions liées.

Mais OKF ne calcule pas la métrique, ne remplace pas le modèle dbt, ne valide pas automatiquement les données, ne gère pas les permissions et ne décide pas quel chiffre est officiel en cas de conflit.

Le bon usage consiste à relier OKF aux systèmes sources. Le bundle devient la couche explicative que les humains et agents lisent avant d'interroger les données ou de produire une analyse.

Comment adopter OKF prudemment

La meilleure adoption commence par un petit périmètre: une boucle support, une métrique data, un cluster SEO, un playbook ops ou une offre commerciale. Le but est de tester la qualité du contexte, pas de cartographier toute l'entreprise.

Chaque bundle devrait avoir un owner, des sources citées, une revue humaine, un `log.md`, des liens internes, un test agent et des critères de succès observables.

Cette approche garde le meilleur d'OKF: portabilité, lisibilité, versioning et contexte agent-ready, sans lui demander de résoudre toute la gouvernance du savoir.

Adoption prudente

Cette checklist permet de garder OKF utile sans en faire une promesse excessive.

Lire ensuite

Après les limites, vous pouvez vérifier les règles de conformité, revenir au workflow de création, ou passer aux prochaines étapes pour transformer cette prudence en plan d'action.

Sources officielles et lectures utiles