Le 12 juin 2026, Google Cloud a présenté l’Open Knowledge Format (OKF), un standard ouvert destiné à uniformiser la manière dont les entreprises structurent leurs connaissances internes pour les agents d’intelligence artificielle. Pensé comme un langage commun lisible par les humains et exploitable par les modèles de langage, ce format repose sur des fichiers Markdown enrichis de métadonnées YAML. Publié sous licence Apache 2.0, il se veut neutre et part d’un constat simple : la fragmentation des données freine encore l’essor de l’IA agentique.
Pourquoi les agents IA peinent à exploiter le savoir des entreprises
Un agent IA ne peut agir de façon pertinente que s’il dispose d’un contexte fiable et structuré. Dans la pratique, les informations nécessaires à son bon fonctionnement restent trop souvent prisonnières de silos technologiques et organisationnels.
Des informations critiques dispersées dans des systèmes cloisonnés
Dans une entreprise type, la connaissance qui alimente un agent se trouve éparpillée entre une multitude de sources : schémas de bases de données, métriques opérationnelles, procédures de dépannage, définitions de règles métier. Ces données résident dans des wikis internes, des conversations Slack, des catalogues de métadonnées, voire dans la mémoire des ingénieurs les plus expérimentés. Chaque nouvel agent doit alors reconstituer ce puzzle informationnel depuis zéro.
Ce phénomène, que les équipes de Google qualifient de « problème d’assemblage du contexte », transforme l’intégration d’un agent en un exercice coûteux de collecte et de reformatage. Sans source de référence commune, l’IA navigue à l’aveugle ou s’appuie sur des informations partielles.
La connaissance critique est souvent dispersée dans les catalogues de métadonnées, les wikis et la tête des ingénieurs seniors.
MarkTechPost, analyse du lancement OKF
Des formats propriétaires qui enferment l’information
Les outils d’IA actuels utilisent chacun leurs propres conventions pour stocker et indexer les données. Les formats propriétaires empêchent toute portabilité : un agent conçu pour une plateforme A ne peut pas directement exploiter les connaissances préparées pour une plateforme B. Cette incompatibilité technique enferme l’organisation dans un écosystème unique et complique la collaboration entre équipes utilisant des fournisseurs différents.
En l’absence de standard, les développeurs passent un temps disproportionné à configurer des pipelines d’ingestion (RAG) sur mesure. Cette redondance ralentit les déploiements et alourdit la maintenance, sans améliorer la qualité des réponses fournies par l’agent.
Un risque accru d’hallucinations et d’erreurs
Quand un agent reçoit un contexte mal structuré ou incomplet, la probabilité d’hallucinations augmente. Le modèle peut alors inventer des liens inexistants ou produire des réponses incohérentes. À l’inverse, une source unique de vérité bien organisée réduit ces dérives en offrant un socle factuel solide pour le raisonnement. La fragmentation actuelle freine donc la fiabilité et l’adoption en production des agents IA.
L’Open Knowledge Format : un standard ouvert pour structurer le savoir d’entreprise
Face à ces défis, Google Cloud a mis au point une spécification qui repense la gestion des connaissances de manière simple et interopérable. L’OKF reprend l’idée du « LLM Wiki », un concept théorisé par Andrej Karpathy, qui consiste à traiter les informations d’entreprise comme des pages de wiki directement compréhensibles par les grands modèles de langage.
Un format volontairement low-tech
L’OKF ne repose ni sur un SDK propriétaire, ni sur une base de données spécialisée. Il utilise des fichiers Markdown classiques, complétés par un bloc de métadonnées YAML en en-tête. Cette approche permet à n’importe quel éditeur de texte de créer ou de modifier un bundle de connaissances, sans outillage complexe. La lisibilité humaine est préservée, ce qui facilite la collaboration entre ceux qui documentent les processus métier et les ingénieurs IA.
La spécification actuelle, en version v0.1, définit des conventions de nommage, une arborescence de répertoires et des champs de frontmatter obligatoires ou recommandés. Elle est publiée sur GitHub sous licence Apache 2.0, une licence open source permissive qui facilite l’adoption par l’industrie sans imposer de contraintes juridiques lourdes.
La philosophie du « Bundle » : un répertoire de concepts
Le cœur de l’OKF est le « Bundle », un répertoire racine qui contient un ensemble de fichiers Markdown. Chaque fichier correspond à un concept unique : une table de base de données, une définition de métrique, un guide de résolution d’incident, une règle métier. L’idée est simple : transformer la connaissance implicite de l’organisation en une collection explicite, navigable et versionnable.
En structurant le savoir sous forme de dossiers et de liens entre fichiers, l’OKF crée un graphe sémantique léger. Un simple lien Markdown d’un fichier à un autre suffit à indiquer une relation de dépendance, d’héritage ou d’association. Cette simplicité permet aux agents IA de parcourir le savoir comme un wiki, tout en gardant une logique de parcours orientée.
Anatomie technique d’un bundle OKF : le markdown comme langage commun
Pour comprendre comment l’OKF structure concrètement l’information, il faut entrer dans le détail des fichiers et de leurs conventions. La force du format tient à l’équilibre entre souplesse éditoriale et rigueur des métadonnées.
Un répertoire de fichiers Markdown sans base de données
Un bundle OKF est simplement un dossier contenant des fichiers .md et, éventuellement, des sous-dossiers thématiques. Il ne nécessite ni moteur d’exécution, ni runtime, ni base de données. Cette légèreté facilite le partage, la sauvegarde et le versionnage avec des outils classiques comme Git. Un développeur peut cloner un bundle, le modifier localement dans son éditeur préféré, puis proposer ses changements.
Le frontmatter YAML obligatoire et ses champs recommandés
Chaque fichier Markdown commence par un bloc YAML délimité par trois tirets. La spécification exige au moins la présence d’un champ « type », qui décrit la nature du concept (par exemple table, metric, process). D’autres champs sont recommandés pour enrichir l’indexation : title pour un libellé humain, description pour une synthèse en langage naturel, resource pour pointer vers une source technique associée, tags pour faciliter le filtrage, et timestamp pour la traçabilité temporelle.
Ces métadonnées permettent aux agents de comprendre rapidement le contenu de chaque fichier sans avoir à l’analyser en entier. Elles servent de points d’accroche pour les moteurs de recherche internes et les systèmes de grounding (ancrage) qui relient les réponses de l’IA à des faits vérifiés.
Des liens Markdown pour créer un graphe sémantique
Les relations entre concepts ne sont pas stockées dans un fichier de configuration centralisé. L’OKF mise sur les liens hypertextes standard du Markdown. Lorsqu’un fichier A décrit une table de faits, il peut inclure un lien vers un fichier B qui définit la dimension associée. Ces connexions, purement textuelles, forment un graphe que l’agent peut parcourir de manière déterministe. Cela évite la complexité des bases de données orientées graphes tout en conservant une navigation sémantique fluide.
Cette approche permet aussi de visualiser le bundle avec un simple outil HTML statique, ce que Google propose déjà via un visualiseur de graphes. La lisibilité humaine reste intacte, et le réseau de connaissances peut s’enrichir progressivement au fil des mises à jour.
Le rôle du fichier d’index comme point d’entrée
À la racine du bundle, un fichier index.md sert de guide pour l’agent IA. Il peut contenir une vue d’ensemble du domaine, la liste des concepts principaux et des liens vers les sections clés. Cette convention permet à l’agent de commencer par une lecture structurée, plutôt que de deviner l’organisation des dossiers. L’index agit comme une « table des matières vivante » que les rédacteurs peuvent adapter selon les besoins métier.
L’intégration avec l’écosystème Google Cloud et au-delà
Si l’OKF se veut un standard neutre et ouvert, Google Cloud l’a immédiatement intégré à ses propres services pour offrir une expérience clé en main aux entreprises qui utilisent ses agents Gemini.
Knowledge Catalog : un moteur de contexte natif pour les agents Gemini
Le service Dataplex a été repositionné sous le nom de Knowledge Catalog. Il joue désormais le rôle de « moteur de contexte » permanent pour les agents Google. Concrètement, une organisation peut déposer ses bundles OKF dans ce catalogue, et les agents Gemini y puiseront automatiquement les informations nécessaires pour ancrer leurs réponses. Ce mécanisme de grounding réduit le risque d’hallucinations en rattachant chaque énoncé à une source documentaire explicite.
Knowledge Catalog assure aussi des fonctions de gouvernance, de contrôle d’accès et de traçabilité, tout en restant compatible avec les flux Git pour le versionnage. L’entreprise garde la maîtrise de ses données : elle peut les stocker sur ses propres infrastructures ou dans le cloud de son choix, l’OKF n’imposant aucune dépendance propriétaire.
L’Agentic Resource Discovery (ARD) : un protocole compagnon
Parallèlement à l’OKF, Google a introduit l’Agentic Resource Discovery (ARD), une spécification destinée à publier et à découvrir des capacités IA de manière sécurisée. L’ARD permet à un agent d’annoncer les ressources qu’il sait exploiter (par exemple « je sais interpréter les bundles OKF de type metric »). Cette couche de découverte facilite l’interopérabilité entre agents de fournisseurs différents, en évitant les intégrations manuelles point à point.
L’ARD et l’OKF forment un duo complémentaire : le premier définit le vocabulaire des connaissances, le second la manière de les signaler et de les trouver. Ensemble, ils visent surtout à éviter de renégocier les formats à chaque nouveau projet.
Des outils d’accompagnement pour générer, visualiser et versionner
Pour faciliter l’adoption, Google fournit un visualiseur HTML statique qui transforme un bundle en un site consultable par des humains, ainsi qu’un agent d’enrichissement capable de suggérer des améliorations dans les bundles existants. Ces outils sont eux aussi diffusés en open source, pour éviter de recréer un verrouillage autour de l’outillage.
L’intégration native avec les dépôts Git permet aux équipes de traiter les bundles comme du code : revue par les pairs, branches de modification, fusion après validation. Cette approche « docs as code » s’aligne sur les pratiques des équipes DevOps et renforce la confiance dans la qualité des données fournies aux agents.
L’OKF n’est pas conçu pour le seul usage des agents Google. Grâce à sa nature neutre et à l’absence de SDK dédié, des agents issus d’autres fournisseurs, comme ceux d’Anthropic ou d’OpenAI, peuvent consommer les mêmes bundles. Une même base de connaissances peut ainsi alimenter plusieurs types d’agents à la fois, chacun puisant les informations pertinentes selon son domaine d’expertise.
Cette ouverture distingue l’OKF d’autres propositions comme le format llms.txt, davantage tourné vers l’exposition de contenus web publics. Là où llms.txt décrit des pages à destination des crawlers, l’OKF modélise des graphes de connaissances internes, structurés et privés. Il répond à un besoin de base pour l’IA agentique en entreprise, là où llms.txt reste un outil de référencement pour le web.
Ce que l’OKF change concrètement pour les développeurs et les organisations
Au-delà de la spécification technique, l’Open Knowledge Format change la manière dont les entreprises gèrent leurs connaissances. Son adoption progressive modifie les pratiques de documentation et de déploiement des agents.
Une réduction mesurable du temps d’assemblage du contexte
En fournissant un format commun, l’OKF supprime la nécessité de reconstruire des pipelines de RAG spécifiques à chaque projet. Les développeurs peuvent concentrer leurs efforts sur l’amélioration des capacités de raisonnement de l’agent, plutôt que sur l’intégration de sources disparates. Les premiers retours d’équipes qui expérimentent le format indiquent une diminution notable des phases d’ingestion préparatoire, ce qui accélère le passage en production.
Cette simplification profite aussi à la maintenance : lorsqu’une règle métier évolue, il suffit de modifier le fichier Markdown correspondant et de pousser la mise à jour via Git. Tous les agents connectés au bundle reçoivent alors la nouvelle version, sans intervention manuelle sur chaque pipeline.
Une meilleure gouvernance et une fiabilité accrue
L’OKF encourage la source unique de vérité pour chaque domaine de connaissance. La documentation s’écrit dans des fichiers versionnés, relus et approuvés, ce qui limite les incohérences et les informations obsolètes. Les agents disposent ainsi d’un ancrage solide, réduisant le risque d’hallucinations et renforçant la confiance des utilisateurs métier dans les résultats produits.
Les métadonnées (timestamp, tags) facilitent aussi la traçabilité de l’origine d’une réponse. En cas d’erreur, l’équipe peut remonter au fichier source et corriger le tir de manière centralisée. Cette boucle de rétroaction rapide reste un atout pour les environnements réglementés comme la finance ou la santé.
Un socle pour la collaboration et la portabilité des agents
Parce que l’OKF est neutre vis-à-vis des fournisseurs, il facilite la migration et la coexistence d’agents hétérogènes. Une organisation peut commencer avec un agent Google pour un cas d’usage, puis adopter un agent d’un autre éditeur pour un autre besoin, tout en réutilisant le même socle de connaissances. Cela réduit le risque de dépendance technologique et favorise une approche « best of breed » dans le choix des modèles.
La portabilité s’étend aussi aux équipes internes : la connaissance documentée dans un bundle peut être partagée entre la data engineering, le support opérationnel et les équipes métier, sans traduction supplémentaire. Chacune peut contribuer à enrichir le bundle dans un langage commun, ce qui casse les silos organisationnels historiques.
Une utilisation sobre des ressources informatiques
La légèreté du format Markdown, combinée à l’absence de base de données dédiée, réduit la charge de calcul nécessaire à l’indexation et au maintien des connaissances. Contrairement aux moteurs de recherche vectorielle qui nécessitent des embeddings coûteux et des infrastructures de stockage spécialisées, un bundle OKF peut être exploré directement par un agent via une simple lecture de fichiers. Cette sobriété s’inscrit dans une logique d’efficacité opérationnelle, où chaque ressource informatique consommée sert directement à la prise de décision plutôt qu’à l’entretien d’une usine à gaz de pré-traitement.
En limitant les étapes intermédiaires et en standardisant le format d’entrée, l’OKF contribue à un usage plus économe de l’énergie et des ressources cloud, un aspect qui compte désormais dans les stratégies d’adoption de l’IA à grande échelle.
Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.