Open Knowledge Format de Google : un premier regard concret

Open Knowledge Format de Google : un premier regard concret sur l'OKF

J'ai failli l'ignorer. Encore une spécification, encore un acronyme, encore un communiqué de presse sur un « standard indépendant des fournisseurs » qui atterrissait dans mon flux un vendredi. Google Cloud a publié l'Open Knowledge Format — OKF v0.1 — le 12 juin 2026, et ma première réaction honnête a été un haussement d'épaules. On a vu une douzaine de formats qui « changent tout » arriver et mourir silencieusement.

Puis j'ai ouvert la spécification. Et j'ai réalisé que tout l'ensemble consiste simplement en des fichiers markdown avec quelques lignes de YAML en haut, regroupés dans un dossier. Pas de SDK. Pas de runtime. Pas de schéma de compression. Pas d'API à appeler. Un « bundle de connaissances » dans l'Open Knowledge Format est, de façon presque insultante, juste des fichiers que vous pourriez écrire dans un éditeur de texte.

C'est la partie qui m'a fait arrêter de défiler et créer un dossier de test. Parce que j'ai passé la dernière année à construire des workflows d'agents, et la seule chose contre laquelle je bute sans cesse est le même mur : mes agents sont brillants pour raisonner et nuls pour se souvenir. Ils re-scrapent, re-résument, re-dérivent le même contexte à chaque session. Si un format aussi bêtement simple pouvait donner à un agent un endroit propre et structuré pour lire des connaissances — au lieu de les re-dériver du HTML brut à chaque fois — ça vaut un après-midi.

J'ai donc consacré cet après-midi à ça. J'ai construit un petit bundle à la main à partir de la spécification publiée, j'ai fait passer mon propre site dans un générateur communautaire, et j'ai ouvert le résultat dans Obsidian pour voir si l'affirmation « convivial » survit au contact avec la réalité. Voici ce que j'ai trouvé — ce qu'est réellement l'OKF, les parties que les annonces ont raison de mentionner, et la pile bien plus grande de choses qui sont des promesses tournées vers l'avenir plutôt que de la réalité livrée. Je serai clair sur ce qui est quoi, parce que l'écart entre les deux est là où vit la plus grande partie du battage.

Qu'est-ce que l'Open Knowledge Format, concrètement ?

L'Open Knowledge Format est une spécification ouverte et indépendante des fournisseurs de Google Cloud pour stocker les connaissances sous forme d'un répertoire de fichiers markdown, chacun portant un front matter YAML, conçu pour être lu à la fois par les humains et les agents IA. C'est tout. Une phrase couvre l'ensemble.

En écartant le langage d'annonce, l'OKF prend exactement trois décisions structurelles :

• Les connaissances sont un dossier de fichiers markdown. Google appelle un dossier un bundle de connaissances. C'est un répertoire — possiblement avec des sous-répertoires — rempli de fichiers .md.
• Chaque fichier est un concept. Pas une page web. Pas un document entier. Une unité discrète de connaissance : un playbook, une définition de métrique, un runbook, une description d'API, une seule entité. L'intuition de Karpathy selon laquelle les connaissances devraient être atomisées en pages de concepts plutôt que déversées en longs documents est directement intégrée dans le format.
• Chaque concept déclare un type. La spécification exige exactement un champ de front matter dans chaque fichier : type. Tout le reste — title, description, resource, tags, timestamp — est recommandé mais optionnel.

Voici un fichier de concept que j'ai écrit à la main pour tester le format, modélisé d'après l'un de mes propres playbooks internes :

---
type: playbook
title: Client Onboarding Sequence
description: The exact steps I run when a new AI automation client signs.
tags: [onboarding, process, clients]
resource: https://mejba.me/onboarding
timestamp: 2026-06-18
---

# Client Onboarding Sequence

When a new client signs, I run these steps in order. Each one has a
trigger and a definition of done — agents reading this should treat the
"done" condition as the success check.

## 1. Access provisioning
Grant repo + cloud read access within 24h of signature...

## 2. Context capture call
A 45-minute recorded call. The recording becomes its own concept file...

C'est un concept OKF complet et conforme à la spécification. Aucun outil ne l'a produit. Je l'ai tapé. Et voici la partie discrètement importante : il s'affiche proprement dans chaque application markdown où je l'ai jeté — GitHub en a montré un aperçu, Obsidian a indexé le front matter comme propriétés, et il rentrerait dans Notion sans problème. Le format ne vous demande pas d'adopter quoi que ce soit. Il décrit ce que vous faites probablement déjà, juste avec une forme convenue.

Mais un fichier seul n'est pas l'unité intéressante. Le bundle l'est. Laissez-moi donc vous montrer comment un bundle est réellement assemblé — parce que c'est ici que l'OKF cesse d'être « un fichier markdown » et commence à être un système.

Comment un bundle de connaissances est structuré

Un bundle de connaissances est un répertoire de concepts, et la spécification lui donne deux fichiers d'organisation optionnels mais puissants qui transforment un dossier plat en quelque chose dans lequel un agent peut naviguer intelligemment.

La structure ressemble à ceci :

my-knowledge-bundle/
├── index.md          # aperçu + liste du répertoire (optionnel)
├── log.md            # historique chronologique des changements (optionnel)
├── onboarding.md     # un concept à la racine du bundle
├── pricing.md        # un autre concept
└── playbooks/        # un sous-répertoire regroupe les concepts liés
    ├── index.md      # les sous-répertoires peuvent avoir leur propre index
    ├── refunds.md
    └── escalation.md

Les deux fichiers spéciaux sont là où le design devient astucieux.

index.md est la carte du bundle. Il énumère ce qui se trouve dans le répertoire pour qu'un agent puisse inspecter le bundle avant de lire quoi que ce soit. C'est de la révélation progressive — exactement le même pattern qui rend les skills d'agents bien conçus efficaces. Un agent lit l'index, décide lesquels des quarante fichiers de concept il a réellement besoin, et ne charge que ceux-là. Il ne déverse pas tout le dossier dans le contexte. Si vous avez lutté contre l'inflation de tokens qui vient du fait de tout mettre dans la fenêtre de contexte, vous reconnaîtrez pourquoi c'est important — c'est le même principe sur lequel j'ai écrit dans mon analyse de pourquoi la gestion du contexte bat la configuration pour les agents IA. L'index est le projecteur ; les concepts sont ce qu'il éclaire.

log.md est la mémoire du bundle de ses propres changements. Un historique chronologique des mises à jour. Pourquoi un format de connaissances a-t-il besoin d'un journal des modifications ? Parce que l'OKF suppose que les connaissances vivent — qu'elles sont révisées, contredites et corrigées au fil du temps. Le log est la façon dont un agent (ou un humain) comprend non seulement ce que disent les connaissances aujourd'hui, mais comment elles en sont arrivées là.

Quand j'ai construit mon bundle de test, le fichier index est ce qui m'a convaincu. J'ai écrit cinq fichiers de concept, puis j'ai écrit un index.md qui listait chacun avec une description d'une ligne. Puis j'ai pointé Claude vers le dossier et posé une question à laquelle un seul concept pouvait répondre. Il a lu l'index en premier, ouvert exactement un fichier, et répondu. Il n'a jamais touché aux quatre autres. C'est la différence entre donner à un agent un catalogue de fiches de bibliothèque et déverser chaque livre sur son bureau.

Maintenant — avant que cela ne semble trop poli — laissez-moi être honnête sur l'endroit où la simplicité devient une limitation. Il n'y a pas d'application forcée. Rien ne vous empêche d'écrire quarante fichiers de concept sans index, avec des valeurs de type incohérentes, et un log.md qui est un mensonge. Le format est une convention, pas une garantie. Ce qui m'amène à la comparaison que tout le monde continue de faire, et de légèrement mal comprendre.

OKF vs llms.txt vs schema.org : où se situe-t-il ?

C'est la question que j'avais dans les dix minutes suivant la lecture de la spécification, et c'est celle à laquelle les annonces répondent le moins clairement. On a déjà llms.txt. On a déjà schema.org. A-t-on besoin d'une troisième chose ? La réponse courte : ils se situent à des couches différentes, et l'OKF est la plus profonde.

Voici comment je cartographierais la stack pour la visibilité IA en 2026 :

Pensez-y comme un restaurant. llms.txt est le menu qui dit à l'agent ce qui est disponible. Schema.org est l'étiquetage des allergènes et des ingrédients qui élimine l'ambiguïté sur chaque plat. L'OKF est la nourriture elle-même, dressée et prête à manger — les connaissances elles-mêmes, transmises sous forme de concept markdown propre au lieu de forcer l'agent à faire de la rétro-ingénierie à partir de HTML scrapé.

Ce cadrage est important à cause d'une comparaison que la spécification fait implicitement et que je ferai explicitement : l'OKF est ce vers quoi on se tourne quand schema.org manque de place. Schema.org est brillant pour les choses pour lesquelles il a des types — produits, recettes, événements, organisations. Mais dès que vos connaissances sont un playbook nuancé, un processus propriétaire, une définition de métrique durement gagnée, ou une stratégie qui ne correspond à aucun @type dans le vocabulaire, schema.org n'a rien pour vous. L'OKF ne vous restreint pas à un vocabulaire prédéfini. Votre type peut être playbook, runbook, case-study, pricing-logic — tout ce dont votre domaine a besoin. C'est le compromis : schema.org vous donne une rigueur validée par machine dans un vocabulaire fixe ; l'OKF vous donne une flexibilité ouverte avec presque aucune validation.

Et le tissu conjonctif probable entre ces couches est encore llms.txt. L'attente tournée vers l'avenir — et je veux le signaler clairement comme attendu, pas livré — est que les sites signaleront l'existence d'un bundle OKF via un pointeur de style llms.txt, de la même façon que les sitemaps XML et les données structurées sont arrivés après robots.txt. À partir de la v0.1, il n'y a pas de protocole de découverte formalisé intégré dans l'OKF lui-même. C'est un manque, et c'est le genre de manque qu'une v0.1 est censée avoir.

Si vous construisez des systèmes de contenu et préférez avoir cette couche automatisée plutôt que maintenue manuellement, c'est exactement le type de pipeline que je construis — transformer les connaissances d'un site en structure lisible par des agents devient une discipline à part entière, et vous pouvez voir comment j'aborde cela dans mon travail sur l'automatisation des workflows de contenu SEO avec Claude Code. Mais vous n'avez pas besoin de moi pour commencer. Vous pouvez construire votre premier bundle aujourd'hui, et vous devriez le faire, parce que lire une spécification ne vous apprend presque rien comparé à écrire un mauvais bundle.

Comment j'ai construit mon premier bundle OKF (et ce qui a cassé)

J'ai pris deux chemins exprès : construire un bundle à la main pour comprendre le format, et faire passer un site existant dans un générateur pour voir ce que l'automatisation produit. Le contraste m'a appris plus que chacun séparément.

Chemin un : à la main. J'ai créé un dossier, écrit cinq fichiers de concept à partir de vrais documents internes — ma séquence d'onboarding, ma logique de tarification, deux playbooks, et un glossaire de termes que j'utilise avec les clients. Le front matter a été la seule friction. Décider du type pour chaque concept a pris plus de temps qu'écrire le contenu, parce que la spécification ne vous dit délibérément pas quels types utiliser. Mon document de tarification est-il un pricing ? Une policy ? Une reference ? La liberté est réelle, et la fatigue décisionnelle aussi. Ma conclusion : choisissez votre vocabulaire de types d'abord, écrivez-le comme son propre concept, et tenez-vous-y. Des types incohérents sont le moyen le plus rapide de créer un bundle dans lequel un agent navigue mal.

Puis j'ai écrit l'index.md à la main et j'ai immédiatement compris pourquoi il est optionnel dans la spécification mais obligatoire en pratique. Sans lui, un bundle est un tas. Avec lui, c'est un graphe.

Chemin deux : un générateur. La communauté a bougé vite ici. Suganthan Mohanadasan — un SEO qui, fait notable, avait déjà son propre site parlant un format de concept markdown avant que Google ne lance l'OKF — a construit un OKF Bundle Generator gratuit qui prend une URL ou un sitemap et produit un bundle téléchargeable plus une carte de votre contenu. J'ai fait passer une section de mon propre site dedans.

Le résultat était sincèrement utile et sincèrement limité en même temps, et la limitation est toute la leçon. Le générateur a bien fait l'évident : chaque page est devenue un fichier markdown propre avec un front matter sensé, avec des liens croisés, sans résidus HTML. Mais il a produit un concept par page — et ce n'est pas vraiment ce pour quoi l'OKF est fait. L'unité de l'OKF est le concept, pas la page. Un seul long article de blog de ma part pourrait contenir quatre concepts distincts qui, dans un bundle approprié, devraient être quatre fichiers séparés auxquels un agent peut se référer indépendamment. Le générateur a fidèlement traduit ma structure de pages ; il ne pouvait pas effectuer l'acte plus difficile d'extraction de concepts — lire une page et décider qu'elle contient en fait trois idées qui méritent leurs propres fichiers.

Ce manque est la vraie opportunité, et je le dis franchement : l'outillage OKF de valeur n'a pas encore été construit. Les convertisseurs page-vers-markdown sont un problème résolu et banalisé. Les outils qui compteront sont ceux qui liront votre contenu désordonné et qui se chevauche et le décomposeront en concepts propres et dédupliqués qui reflètent votre véritable structure d'entreprise. Le terme de Suganthan pour ce que l'OKF permet — le « désenfournement sémantique », briser les connaissances cuites ensemble pour retrouver des éléments structurés et interopérables — est exactement la partie que l'automatisation n'a pas encore résolue. Un modèle de langage est bien adapté à cette extraction, mais en pointer un naïvement vers « transforme ce site en concepts » produit encore des fichiers de concept qui se chevauchent et se contredisent. Le faire bien reste non résolu.

Si vous préférez que quelqu'un construise cette pipeline d'extraction de concepts pour votre entreprise plutôt que de vous y frotter vous-même, c'est un projet que j'accepte — vous pouvez voir le type de systèmes que je construis sur fiverr.com/s/EgxYmWD. Mais sincèrement, construisez d'abord un bundle de cinq fichiers à la main. Ça prendra vingt minutes et ça vous apprendra ce qu'aucun outil ne peut.

La connexion Karpathy : des connaissances qui se maintiennent elles-mêmes

L'OKF ne sort pas de nulle part. C'est la formalisation d'une idée qu'Andrej Karpathy a proposée — ce qu'il a appelé le pattern LLM Wiki — et comprendre cette origine vous dit où tout cela se dirige vraiment.

L'argument de Karpathy allait à contre-courant de la façon dont nous faisons le retrieval aujourd'hui. Le pattern dominant, le RAG, fonctionne en découpant des documents non structurés en chunks, en les embeddant, et en récupérant les chunks les plus proches au moment de la requête. C'est puissant, mais c'est fondamentalement une recherche sur un tas statique. Le tas n'apprend pas. Il ne réconcilie pas. Si deux documents se contredisent, le RAG récupère joyeusement les deux et laisse le modèle s'en sortir.

Le LLM Wiki de Karpathy inverse le modèle : au lieu d'un tas statique que l'on cherche, on maintient un wiki vivant que le modèle lui-même construit et révise. Les nouvelles informations ne sont pas simplement ajoutées — elles sont intégrées. Le modèle met à jour la page d'entité pertinente, révise un résumé, et quand de nouvelles données contredisent une ancienne affirmation, il réconcilie la contradiction plutôt que de stocker les deux. La base de connaissances est quelque chose de dynamique et en évolution, et le modèle fait l'essentiel de la maintenance. Cette dernière partie est le déclic : la raison pour laquelle les wikis ne passent généralement pas à l'échelle est que les humains doivent les maintenir. Un agent qui maintient son propre wiki supprime le goulot d'étranglement.

On peut voir le log.md de l'OKF et le design concept-par-fichier comme le format sur disque pour exactement cette vision. Un fichier de concept est une page d'entité. Le log est l'historique de révision. La structure est délibérément assez simple pour qu'un agent puisse non seulement la lire mais aussi l'écrire — ouvrir un concept, réviser une affirmation, ajouter au log, sauvegarder. C'est un graphe de connaissances vivant qu'une machine peut réellement maintenir à jour.

Je poursuis une version artisanale de cela depuis un moment en utilisant Obsidian comme stockage et Claude comme mainteneur — j'ai écrit tout cet expériment dans mon setup de mémoire persistante Obsidian + Claude Code et un deep-dive lié sur la construction d'une base de connaissances RAG à la Karpathy dans Obsidian. La contribution de l'OKF n'est pas une nouvelle idée par-dessus. C'est une forme partagée. La raison pour laquelle un standard compte ici est l'interopérabilité : si mon agent et votre agent parlent tous deux OKF, mon bundle d'onboarding pourrait être lu par votre agent sans aucune traduction. Ce qui mène à la partie qui est soit la plus excitante, soit la plus sur-promise, selon votre scepticisme.

Optimisation de la recherche agentique et connaissances vendables

C'est ici que les annonces deviennent bruyantes, donc c'est ici que je vais être prudent. Deux grandes affirmations accompagnent l'OKF, et ce sont toutes les deux des directions plausibles plutôt que des réalités actuelles. Je séparerai le mécanisme du marketing.

Affirmation un : l'OKF reformule le SEO en « optimisation de la recherche agentique ». La logique : à mesure que les agents IA médiatisent de plus en plus entre les personnes et l'information, l'objectif passe d'être trouvable par un crawler de recherche à être utilisable par un agent. Au lieu d'optimiser une page pour qu'un humain clique dessus, vous publiez des connaissances pour qu'un agent puisse les lire, les citer et agir dessus directement. Quand Google lui-même commence à décrire votre contenu comme du « contexte à servir aux agents », le servir dans la forme que Google décrit est une couverture rationnelle.

Je pense que la direction est réelle. L'exécution n'est pas prouvée. Il n'y a, mi-2026, aucun mécanisme confirmé par lequel la publication d'un bundle OKF améliore votre visibilité dans les surfaces médiées par les agents de Google. Google a sorti un format ; il n'a pas livré — ni promis — un avantage de classement pour son utilisation. Traitez quiconque vendant « l'OKF pour les rankings » avec la même suspicion que vous auriez envers quelqu'un qui vous a vendu une balise meta keyword. Le coup honnête est : l'OKF rend vos connaissances plus propres et plus utilisables pour tout agent qui les lit, et c'est un pari défendable par ses propres mérites, que Google le récompense un jour ou non.

Affirmation deux : les gens vont empaqueter et vendre des bundles de connaissances OKF. Un avocat vend un bundle de playbooks juridiques curés. Un comptable vend des concepts de stratégie fiscale. Un SEO vend un bundle d'heuristiques de classement. Une entreprise les achète et les monte dans le contexte de ses propres agents. Parce qu'un bundle est juste un tarball de markdown, il est trivialement livrable, hébergeable sur n'importe quel dépôt git, et licenciable comme n'importe quel produit numérique.

Celle-ci, je la trouve plus convaincante, parce que le mécanisme est solide — un bundle est sincèrement une unité portable et autonome d'expertise, et il y a une vraie demande pour du contexte curé que les agents peuvent consommer. Mais c'est un marché qui n'existe pas encore, pas quelque chose qui se passe à grande échelle aujourd'hui. La même friction qui rend les bons bundles difficiles à générer (extraction de concepts, cohérence, garder le log honnête) rend les bons bundles vendables encore plus difficiles, parce que maintenant la qualité est une fonctionnalité du produit. Je parierais que ce marché émerge. Je ne parierais pas sur le calendrier, et je serais sceptique envers la première vague de « bundles d'expertise » de la même façon que je suis sceptique envers toute première vague.

Alors, où cela laisse-t-il un développeur maintenant ? Avec un mouvement clair et à faible risque et beaucoup de patience pour le reste.

Ce que je ferais réellement avec l'OKF aujourd'hui

Laissez-moi rendre cela concret, parce que « expérimentez avec » est le genre de conseil qui sonne bien et ne change rien. Voici la séquence précise que je suivrais, et ce qu'il faut attendre de chaque étape.

1. Lisez la spécification réelle, pas les résumés. La OKF SPEC.md sur GitHub est courte et lisible en quinze minutes. Chaque résumé de seconde main (y compris celui-ci) perd en fidélité. La source est la source.

2. Construisez un bundle de cinq fichiers à la main. Choisissez un vrai morceau de vos propres connaissances — vos processus, votre documentation produit, vos heuristiques durement gagnées. Écrivez cinq fichiers de concept, un index.md, et un log.md. N'utilisez pas d'outil. La friction est l'éducation. Vous en apprendrez plus sur votre propre structure de connaissances en vingt minutes qu'un générateur ne vous en dira jamais.

3. Ouvrez-le dans les outils que vous utilisez déjà. Déposez le dossier dans Obsidian, poussez-le vers un dépôt GitHub, collez un fichier dans Notion. Confirmez par vous-même que « convivial » tient bon. C'est la propriété qui rend l'OKF sûr à adopter : dans le pire des cas, vous avez écrit du markdown bien organisé, qui a de la valeur avec ou sans aucun agent.

4. Pointez un agent vers le bundle et posez une question. Donnez à Claude ou Gemini le dossier et demandez quelque chose qu'un seul concept peut répondre. Observez s'il utilise l'index pour naviguer. C'est le moment où l'OKF cesse d'être abstrait — quand vous voyez un agent inspecter la carte et ouvrir exactement le bon fichier, le design fait clic.

5. Écrivez votre vocabulaire de type comme son propre concept. C'est l'habitude unique avec le plus grand effet de levier. La liberté de la spécification sur les types est une arme à double tranchant ; les bundles qui vieillissent bien sont ceux avec un système de types délibéré et documenté. Prenez cette décision une fois, intentionnellement, et référencez-la.

Ce que je ne ferais pas aujourd'hui : restructurer toute mon opération de contenu autour de l'OKF, payer pour des services « OKF SEO », ou traiter la v0.1 comme un standard fini. Google lui-même a appelé la v0.1 un point de départ, pas une spécification finie. Construire dessus est intelligent ; parier son entreprise sur sa forme actuelle ne l'est pas.

Questions fréquemment posées

Qu'est-ce que l'Open Knowledge Format (OKF) ?

L'Open Knowledge Format est une spécification ouverte et indépendante des fournisseurs de Google Cloud, publiée en tant que v0.1 le 12 juin 2026, pour stocker les connaissances sous forme d'un répertoire de fichiers markdown avec du YAML front matter — lisible à la fois par les humains et les agents IA. Chaque fichier représente un concept et doit déclarer un champ type. Pour la décomposition complète de la structure, voir la section bundle ci-dessus.

En quoi l'OKF diffère-t-il de llms.txt ?

L'OKF et llms.txt opèrent à des couches différentes : llms.txt est un fichier de découverte qui pointe les agents vers vos ressources importantes, tandis que l'OKF transmet les connaissances curées elles-mêmes sous forme de documents markdown au niveau du concept. llms.txt est le menu ; l'OKF est la nourriture. Ils sont complémentaires, et les bundles OKF seront probablement signalés via un pointeur de style llms.txt à l'avenir.

L'OKF est-il un facteur de classement SEO ?

Non — mi-2026, Google n'a annoncé aucun avantage de classement pour la publication de bundles OKF. L'OKF rend vos connaissances plus propres et plus utilisables pour les agents IA qui les lisent, ce qui est une raison défendable de l'adopter, mais traitez toute affirmation selon laquelle l'OKF améliore directement les classements avec scepticisme. Voir la section sur la recherche agentique ci-dessus pour la mise en garde complète.

Quels outils puis-je utiliser pour créer des bundles OKF ?

Vous pouvez écrire des bundles OKF à la main dans n'importe quel éditeur de texte, puisqu'il s'agit simplement de markdown plus YAML. Les générateurs communautaires comme l'OKF Bundle Generator de Suganthan peuvent convertir un site en un bundle basique, mais ils produisent actuellement un concept par page plutôt qu'une véritable extraction de concepts — l'outillage plus précieux pour décomposer le contenu en concepts propres n'a pas encore été construit.

Qu'est-ce que le LLM Wiki de Karpathy et quel est son rapport avec l'OKF ?

Le LLM Wiki est le concept d'Andrej Karpathy d'une base de connaissances vivante qu'un modèle IA construit et maintient lui-même — intégrant de nouvelles informations, révisant des affirmations et réconciliant des contradictions, plutôt que de chercher dans un tas statique comme le RAG traditionnel. L'OKF est essentiellement le format de fichier sur disque pour cette vision, avec des fichiers de concept comme pages d'entité et un fichier log comme historique de révision.

La vraie raison pour laquelle je suis content de ne pas l'avoir ignoré

J'y suis entré en m'attendant à une autre spécification à classer sous « intéressant, jamais utilisé ». J'en suis sorti ayant changé la façon dont je stocke mes propres connaissances — non pas parce que l'OKF est fini, mais parce qu'il pointait vers quelque chose de vrai.

Ce qu'il fait bien est modeste : les connaissances pour les agents devraient être curées, atomisées et transmises, pas scrapées, découpées en chunks et rétro-ingénieriées. C'est correct que le format spécifique de Google gagne ou non. Le bundle que j'ai construit à la main survivra à toute prédiction sur l'adoption de l'OKF, parce que c'est simplement du markdown bien structuré que je comprends maintenant mieux que ce matin.

Alors voici la seule chose que je vous demanderais vraiment de faire avant la fin de cette semaine : ouvrez un dossier, écrivez cinq fichiers de concept sur quelque chose que vous connaissez à fond, ajoutez un index, et pointez un agent dessus. Vingt minutes. Puis formez votre propre jugement sur le fait que l'avenir soit un dossier. Le mien est que le format va presque certainement évoluer au-delà de la v0.1 — mais la forme qu'il décrit, les connaissances comme des concepts qu'un agent peut lire et maintenir, est la direction dans laquelle tout se dirige déjà. Mieux vaut apprendre la forme maintenant que de se scraper un chemin jusque-là plus tard.

Travaillons ensemble

Vous cherchez à construire des systèmes IA, automatiser des workflows, ou mettre à l'échelle votre infrastructure tech ? Je serais ravi de vous aider.

• Fiverr (constructions sur mesure & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io