Constituer un Open Knowledge Format avec Draft_ : le guide pratique
Un bundle OKF, c'est un répertoire de Markdown bien rangés : exactement ce que Draft_ produit, sans rien configurer. Pourquoi écrire sa base de connaissance dans un traitement de texte Markdown, puis la donner telle quelle à un agent IA. Trois cas où ça change tout.
L’Open Knowledge Format de Google (OKF) ne demande aucun outil propriétaire. Un bundle, c’est un répertoire de fichiers Markdown, un peu de frontmatter YAML, des liens entre les concepts, et c’est tout. Autrement dit, le format est déjà votre éditeur de texte.
Reste que « possible » et « agréable » ne sont pas synonymes. Écrire une base de connaissance, c’est un travail d’écriture : on veut un endroit calme pour le faire, pas un terminal. C’est là que Draft_ tombe juste : non pas grâce à une fonctionnalité « OKF » dédiée, mais parce que son format natif est déjà celui de l’OKF. Voyons pourquoi, puis trois cas concrets où ça compte.
Pourquoi un traitement de texte Markdown pour l’OKF ?
L’OKF sépare deux rôles : celui qui produit la connaissance et celui qui la consomme. Le consommateur, c’est un agent IA. Le producteur, c’est un humain qui écrit, et qui mérite mieux qu’un champ de saisie pour le faire.
Ce renversement est la ligne de Draft_ : c’est vous qui nourrissez l’IA, ce n’est pas l’IA qui crée à votre place. L’OKF a beau s’adresser à des machines, tout ce qu’il contient naît d’une pensée humaine, écrite, structurée, assumée. Et le choix de qui tient le clavier n’est pas neutre : déléguer l’écriture à un assistant a un coût cognitif désormais mesuré, de la surcharge mentale à la dépendance à l’IA, tandis que la hiérarchie neuroscientifique main > clavier > IA montre que c’est l’engagement de celui qui écrit qui fait la valeur de ce qui est produit. Une base de connaissance ne vaut que par ce qu’on y met. Autant l’écrire soi-même, dans un outil construit pour ça.
Or les briques de l’OKF sont, une à une, celles de Draft_ :
| Convention OKF | Draft_, en l’état |
|---|---|
| Répertoire de fichiers Markdown | Format de stockage natif |
| Frontmatter YAML | Zone metadata en tête de document |
| Liens croisés entre concepts | Liens internes relatifs ([texte](../dossier/doc.md)) |
| Arborescence de concepts | Espaces et dossiers |
| Bundle versionné | Synchronisation GitHub intégrée |
| Lisible par un humain | Éditeur Markdown sans distraction |
Rien à installer, rien à brancher. La correspondance n’est pas un hasard : l’OKF a simplement formalisé ce que les bons éditeurs Markdown font depuis longtemps.
Le workflow concret
Vous créez un espace : c’est la racine de votre bundle. Vous y rangez des dossiers (personnages/, tables/, lieux/…) qui deviennent les familles de concepts. Chaque document s’ouvre sur une zone metadata où vous tapez le frontmatter en clair (type: Personnage, title, tags), sans même les délimiteurs ---, que Draft_ ajoute à l’export. Le nom du document devient le nom du fichier (orders → orders.md), donc vous maîtrisez le chemin de chaque concept ; vos liens internes deviennent les arêtes du graphe que l’agent suivra ; et la synchronisation GitHub transforme l’ensemble en dépôt versionné. Un bundle OKF valide, sorti d’un éditeur où l’on a surtout écrit.
Trois cas concrets
Cas 1 : la bible d’un univers de fiction
Vous écrivez un roman, une série, un jeu. Vous tenez un espace bible/ :
personnages/
└── elena.md (type: Personnage)
lieux/
└── valdris.md (type: Lieu)
factions/
└── pacte-de-fer.md (type: Faction)La fiche d’Elena cite Valdris et le Pacte de Fer par de simples liens. Plus tard, vous donnez le dépôt à un LLM : « Voici ma bible. Écris une scène où Elena revient à Valdris, fidèle à son histoire et à l’atmosphère du lieu. » L’agent remonte les fiches pertinentes en suivant les liens et écrit dans votre univers, sans que vous ayez à le réexpliquer à chaque session. Votre cohérence devient un actif, pas une charge mentale.
Cas 2 : une documentation technique vivante
Vous documentez une API ou un produit, par type : endpoints/, concepts/, runbooks/, chacun avec son type. Le dépôt vit à côté du code, dans le même GitHub, versionné par les mêmes commits. La doc cesse d’être un wiki parallèle qui rassit : elle est lisible par un agent de CI, par l’assistant qui répond aux questions de l’équipe, ou par la développeuse qui arrive lundi. Une seule source, et tout le monde, humains comme machines, y boit.
Cas 3 : des notes de recherche interrogeables
Vous accumulez des notes sur un sujet : concurrents, lectures, idées. Chaque note est un concept, relié aux autres. Le bundle synchronisé devient une mémoire externe que vous interrogez : « Quelles tensions traversent ces deux approches dans mes notes ? » Le LLM parcourt le graphe de votre pensée pour répondre : pas Wikipédia, votre raisonnement à vous, structuré et cité.
Le périmètre, en une ligne
Draft_ couvre le maillon humain de la chaîne OKF : écrire, nommer, relier, versionner. La consommation se fait ensuite avec n’importe quel LLM, et c’est tout l’intérêt d’un format portable. Vous tapez le frontmatter et vous gardez la main sur la cohérence, exactement le niveau de contrôle qu’on attend d’un travail d’écriture soigné.
En bref
- Un bundle OKF, c’est un répertoire de Markdown + frontmatter YAML ; Draft_ le produit nativement.
- Espace = racine, dossiers = concepts, zone metadata = frontmatter, nom du document = nom du fichier, liens internes = graphe, sync GitHub = bundle versionné.
- Vous écrivez dans un vrai traitement de texte, puis vous donnez la connaissance telle quelle à un agent.
- Trois terrains de jeu : bible de fiction, doc technique vivante, notes de recherche interrogeables.
Pour constituer votre base de connaissance OKF, vous avez déjà tout ce qu’il faut dans Draft_ : vous écrivez, vous nommez, vous synchronisez. Le reste, c’est du Markdown, et c’est déjà entre vos mains.