Comparaisons : où placer OKF face à Notion, Obsidian, Git, RAG et data catalogs ?

La bonne comparaison : OKF n'est pas un outil de plus

La confusion la plus fréquente consiste à comparer OKF à Notion, Obsidian, Git ou un data catalog comme si tous jouaient exactement le même rôle. Ce n'est pas le bon angle. Ces outils sont des lieux de travail, de gouvernance, de stockage, de versioning ou de recherche. OKF est un format qui permet de représenter une partie de leur connaissance sous une forme portable.

Autrement dit, OKF n'a pas vocation à devenir l'endroit où toute l'entreprise écrit au quotidien. Une équipe peut continuer à travailler dans Notion, documenter ses décisions dans Google Docs, gérer son code dans GitHub, maintenir son glossaire dans un data catalog et utiliser AGENTS.md pour guider ses agents de code. OKF intervient quand il faut extraire, clarifier, relier et publier le contexte utile dans une forme stable.

La bonne question n'est donc pas: faut-il remplacer nos outils par OKF ? La bonne question est: quelles connaissances doivent sortir de nos outils pour devenir lisibles, versionnables, vérifiables et réutilisables par plusieurs agents ?

OKF vs Notion : interface collaborative ou format portable ?

Notion est excellent pour écrire, organiser des pages, commenter, collaborer et faire vivre une documentation au quotidien. C'est une interface de travail. Une équipe marketing peut y garder ses briefs, une équipe produit ses specs, une équipe sales ses scripts de découverte et une équipe support ses procédures internes.

La limite apparaît quand un agent doit consommer ce contenu de façon fiable. Une page Notion peut être riche, mais elle mélange souvent du texte, des bases de données, des commentaires, des embeds, des permissions, des versions implicites et des conventions locales. L'export Markdown existe, mais il ne transforme pas automatiquement le contenu en concepts OKF bien typés, reliés et cités.

OKF peut donc devenir une couche de publication. Notion reste l'espace de collaboration; OKF devient l'export curaté agent-ready: un dossier avec des concepts, des liens, des citations, des types et un historique. Exemple: un wiki Notion sur les offres commerciales peut produire un bundle OKF avec des fichiers `offers/enterprise.md`, `personas/cfo.md`, `playbooks/demo-discovery.md` et `objections/security.md`.

OKF vs Obsidian : graphe personnel ou convention interopérable ?

Obsidian est très proche de l'esprit OKF sur un point important: il repose sur des fichiers Markdown locaux, stockés dans un vault, avec des liens qui créent un graphe de connaissances. Pour une personne ou une équipe qui pense déjà en Markdown, c'est souvent un excellent outil de capture et de réflexion.

La différence est que Obsidian est d'abord une application et un environnement de notes. OKF ajoute une convention destinée à l'interopérabilité: un bundle, des concept files, un frontmatter YAML, un champ `type`, des citations et des règles de tolérance côté consommateur. L'objectif n'est pas seulement de naviguer dans ses notes; c'est de rendre une partie de la connaissance exploitable par d'autres outils.

En pratique, un vault Obsidian peut être une très bonne source pour produire un bundle OKF. Mais toutes les notes d'un vault ne méritent pas de devenir des concepts. Il faut sélectionner ce qui est stable, utile, relié à des décisions ou à des workflows, puis ajouter assez de structure pour qu'un agent sache quoi en faire.

OKF vs Git : versionner les fichiers ou structurer leur sens ?

Git permet de suivre l'historique d'un ensemble de fichiers, de relire les changements, de faire des reviews, de gérer des branches et de distribuer un projet. C'est précieux pour du contexte parce qu'une connaissance d'entreprise change: une métrique évolue, une règle métier est corrigée, une source devient obsolète, un playbook est amélioré.

Mais Git ne donne pas de signification métier aux fichiers. Pour Git, un fichier Markdown reste un fichier texte. Il ne sait pas si ce fichier décrit une table BigQuery, une métrique, une décision, une procédure support ou un persona. OKF ajoute cette couche de sens minimale avec `type`, les métadonnées recommandées, les liens et les citations.

Le bon duo est souvent Git + OKF. Git apporte le diff, la revue et l'historique. OKF apporte la convention de représentation. Une entreprise peut ainsi traiter son contexte critique comme du code: versionné, relu, attribué, mais encore lisible par des personnes non techniques.

OKF vs data catalog : gouvernance data ou contexte transverse ?

Un data catalog sert à inventorier, documenter et gouverner des assets data: tables, colonnes, glossaires, propriétaires, politiques d'accès, classification, lineage ou qualité. C'est un outil central pour les équipes data et gouvernance.

OKF ne remplace pas ce rôle. Il peut référencer un data catalog, reprendre certaines définitions, documenter une métrique ou expliquer comment une table est utilisée dans un playbook métier. Mais OKF est plus transverse: il peut aussi décrire une décision pricing, une FAQ support, une API, un persona, un modèle de relance commerciale ou une source documentaire.

La valeur d'OKF est donc de faire le pont entre les assets data et le reste du contexte opérationnel. Un agent n'a pas seulement besoin de savoir qu'une table existe; il doit comprendre quelle métrique elle alimente, quelle règle métier s'applique, quelle décision l'a modifiée et quel playbook doit l'utiliser.

OKF vs AGENTS.md et CLAUDE.md : instructions locales ou connaissance métier ?

`AGENTS.md` et `CLAUDE.md` sont utiles pour donner des consignes persistantes à un agent dans un projet: comment installer, tester, coder, respecter le style, éviter certaines erreurs ou comprendre les règles locales d'un repository.

Ces fichiers répondent surtout à la question: comment l'agent doit se comporter ici ? OKF répond à une autre question: que doit-il savoir sur le métier, les systèmes, les sources, les métriques, les décisions et les procédures ? Les deux sont complémentaires, mais ils ne portent pas le même type de contexte.

Un exemple simple: `AGENTS.md` peut dire à Codex de lancer `npm run check` avant une PR. OKF peut expliquer ce qu'est le MRR, quelles tables l'alimentent, quelles exclusions appliquer, quelle décision pricing a changé la formule et quelle source officielle citer dans une réponse.

OKF vs RAG : préparer le corpus ou retrouver les passages ?

Le RAG est une méthode de retrieval: il cherche dans un corpus les passages susceptibles d'aider un modèle à répondre à une question. C'est une couche d'accès au contexte au moment de la requête.

OKF intervient plus en amont. Il aide à préparer le corpus: découper les connaissances en concepts, ajouter des métadonnées, relier les fichiers, citer les sources et rendre le contexte plus propre avant son indexation. Un moteur RAG peut ensuite indexer un bundle OKF comme il indexerait d'autres documents, mais avec une matière première plus claire.

La combinaison la plus intéressante n'est donc pas OKF ou RAG. C'est OKF + RAG: OKF structure et gouverne; le RAG retrouve les bons passages au bon moment.

Matrice de décision : quand utiliser quoi ?

Le choix ne doit pas être idéologique. Il dépend du geste que vous voulez permettre. Si l'équipe doit écrire et commenter vite, gardez son outil de collaboration. Si vous voulez historiser un contexte critique, utilisez Git. Si vous voulez rendre ce contexte portable et exploitable par des agents, produisez un bundle OKF.

Cette matrice aide à éviter deux erreurs: vouloir tout convertir en OKF trop tôt, ou attendre que la documentation soit parfaite avant de créer un premier bundle. La bonne V1 consiste souvent à sélectionner un périmètre où le contexte est assez stable et assez utile pour être publié.

Exemple concret : transformer un wiki Notion en bundle OKF

Imaginez une équipe sales qui possède dans Notion un wiki avec les offres, les personas, les scripts de découverte, les objections, les preuves clients et les règles de pricing. Ce wiki est utile pour les humains, mais difficile à donner tel quel à un agent commercial: certaines pages sont longues, certains blocs sont obsolètes, les sources sont implicites et les liens ne disent pas toujours pourquoi deux informations sont reliées.

Une V1 OKF ne consiste pas à exporter tout Notion d'un coup. Elle consiste à choisir un périmètre, par exemple le traitement des objections enterprise, puis à créer quelques concepts: `personas/cfo.md`, `offers/enterprise.md`, `objections/security.md`, `playbooks/discovery-call.md`, `sources/security-whitepaper.md` et `decisions/pricing-2026.md`.

Le résultat ne remplace pas Notion. L'équipe continue de travailler dans Notion. Mais le contexte critique utilisé par les agents devient plus stable: chaque concept a un type, une définition, des liens, des citations et un emplacement connu dans un bundle. L'agent peut alors répondre plus proprement, citer ses sources et éviter de mélanger une objection ancienne avec une règle commerciale récente.

Erreurs fréquentes à éviter

La première erreur consiste à présenter OKF comme un remplaçant de Notion, Obsidian, Git ou d'un data catalog. Cette promesse est trop forte et crée de la résistance inutile. OKF est plus crédible comme couche d'échange et de publication.

La deuxième erreur consiste à convertir trop de contenu. Un export massif produit souvent un bundle volumineux mais peu fiable. Il vaut mieux créer quelques concepts de haute qualité, reliés à un cas d'usage agent clair.

La troisième erreur consiste à oublier les sources. Un bundle OKF sans citations peut être lisible, mais il reste fragile. Les agents ont besoin de savoir d'où vient une affirmation importante, surtout quand elle concerne une métrique, une règle métier ou une décision.

La quatrième erreur consiste à confondre instructions et connaissance. Un fichier d'instructions dit à l'agent comment agir; un bundle OKF lui donne la matière métier à comprendre.

Lire ensuite

Cette page situe OKF par rapport aux outils existants. Les chapitres suivants expliquent comment passer d'un diagnostic à une première production concrète de contexte.

Sources officielles et lectures utiles