Open Knowledge Format va-t-il remplacer le RAG ?

L’Open Knowledge Format ne remplace pas le RAG partout, il corrige surtout son angle mort : la perte de contexte. Je vous explique où OKF change vraiment la donne pour les agents IA, comment il structure la connaissance, et quand le combo OKF + RAG reste le plus solide.

Pourquoi le RAG perd-il le contexte ?

Le RAG perd du contexte pour une raison assez simple : il découpe souvent les documents en fragments, puis il demande au modèle de reconstruire les liens logiques au moment de la requête. Ça marche très bien pour retrouver une information locale. Ça devient plus fragile quand la réponse dépend d’un enchaînement, d’une règle métier, ou d’une exception.

Le fonctionnement classique est connu. Je prends des documents, je les découpe en chunks, c’est-à-dire en petits blocs de texte. Je transforme chaque bloc en embedding, une représentation numérique du sens. Je stocke ça dans une base vectorielle, qui sert à retrouver vite les passages proches d’une question. Puis le modèle reçoit les morceaux jugés pertinents et génère une réponse.

Le vrai compromis est là. Le chunking aide à chercher vite dans de gros volumes, mais il casse parfois la structure interne du document. Les relations entre concepts, étapes, dépendances, exceptions et responsabilités ne sont plus forcément visibles. Le modèle voit des bouts. Pas toujours le plan complet.

Prenons un protocole d’admission hospitalière. Le document peut décrire le triage du patient, l’enregistrement dans l’EHR, c’est le dossier médical électronique, puis l’allocation des lits. Dans la vraie procédure, ces étapes ont un ordre. Le triage peut déclencher une priorité. L’enregistrement peut être obligatoire avant certaines décisions. L’allocation d’un lit peut dépendre du service, de l’état du patient, ou d’un cas particulier.

Si ces trois parties sont séparées en trois fragments, l’agent peut récupérer uniquement le passage sur les lits. Il peut alors répondre sans voir que le triage doit passer avant. Ou il peut récupérer le morceau sur l’EHR sans comprendre que certains patients urgents suivent un circuit différent. Ce n’est pas forcément une hallucination. C’est souvent une perte de structure.

Je le vois souvent dans les bases documentaires d’entreprise. Le sujet n’est pas seulement de trouver une phrase proche de la question. Le vrai sujet, c’est de comprendre comment une procédure s’enchaîne. Qui fait quoi. Dans quel ordre. Avec quelles exceptions. Le RAG aide beaucoup, mais il ne transporte pas toujours cette logique métier avec assez de fidélité.

Ce que RAG fait bien	Retrouver rapidement des passages pertinents dans de gros volumes documentaires.
Ce qu’il fragilise	Les liens entre étapes, dépendances, exceptions et responsabilités quand le document est découpé.
Ce que ça implique pour un agent IA	L’agent peut répondre avec un bon extrait, mais sans comprendre toute la procédure autour.

Qu’est-ce que l’Open Knowledge Format ?

L’Open Knowledge Format, ou OKF, c’est une spécification ouverte pensée pour organiser des connaissances destinées aux agents IA avec des fichiers Markdown, des métadonnées YAML et des liens explicites entre concepts.

Dit simplement, je le vois comme un wiki structuré pour agents IA. Les humains écrivent et valident la connaissance. Les agents peuvent ensuite la lire, la résumer, la relier, l’améliorer, la parcourir sans repartir de zéro à chaque fois.

L’idée rappelle le concept de LLM Wiki popularisé par Andrej Karpathy. Un espace de connaissance lisible par les modèles, pas juste par les humains. Google a ensuite annoncé en juin 2026 le passage à une spécification ouverte avec OKF, pour rendre cette approche plus standard, plus portable, et surtout moins dépendante d’un outil précis.

Le format repose sur trois briques simples.

• Markdown sert à écrire le contenu principal. C’est lisible par un humain, facile à versionner, et assez propre pour être consommé par une IA.
• YAML sert à décrire les métadonnées. Par exemple le propriétaire du document, sa version, son statut, son périmètre, sa date de mise à jour. YAML, c’est juste un format texte très utilisé pour écrire des données de configuration de manière lisible.
• Les liens entre concepts servent à garder les relations importantes. Une règle peut dépendre d’une procédure, une procédure peut appeler une API, une API peut avoir un runbook associé.

Ce point est important. Dans beaucoup de systèmes RAG, on demande au modèle de reconstruire les relations à partir de morceaux de texte retrouvés dans une base vectorielle. Une base vectorielle, c’est une base qui cherche des contenus proches en sens grâce à des embeddings, donc des représentations numériques du texte. Ça marche bien, mais les relations restent souvent implicites.

Avec OKF, une partie de ces relations devient persistante dans le référentiel. Par exemple, une politique interne peut être liée explicitement à une procédure RH, à une API de validation, à un runbook d’incident et à une exception métier. L’agent n’a pas besoin de deviner que tout ça est connecté. C’est écrit.

Ça ne veut pas dire qu’on abandonne les embeddings ou les bases vectorielles. Pas du tout. OKF apporte surtout une autre manière de représenter la connaissance quand la structure compte autant que le texte.

La vraie question devient alors très concrète : à quoi ressemble un bundle OKF quand on l’ouvre dans un dossier ?

Comment structurer un bundle OKF ?

Je structure un bundle OKF comme un dépôt de connaissances lisible par un humain, versionnable avec Git, et exploitable par un agent IA. Je ne cherche pas à faire compliqué. Le bon bundle, c’est celui qu’une équipe peut ouvrir, comprendre, modifier et relire sans avoir besoin d’un outil magique.

Dans la pratique, je pars sur une structure simple : des dossiers par domaine, des fichiers Markdown légers, un bloc YAML en haut pour les métadonnées, et des liens entre concepts quand une règle dépend d’une autre. OKF, pour Open Knowledge Format, pousse surtout cette idée de connaissance portable et structurée. Je reste prudent : je ne parle pas ici d’une norme officielle gravée dans le marbre, plutôt d’une façon saine d’organiser la connaissance.

Un fichier conceptuel peut ressembler à ça, en version lisible :

— / id: admission_hospitaliere / title: Protocole d’admission hospitalière / type: procedure / related: identite_patient, couverture_assurance, triage_urgence / updated: 2026-01-18 / — / Résumé : Ce document décrit les règles d’admission d’un patient à son arrivée. / Étapes : Vérifier l’identité. Collecter les documents administratifs. Évaluer le niveau d’urgence. Créer ou retrouver le dossier patient. Orienter vers le bon service. / Dépendances : Identité patient validée. Couverture assurance connue. Disponibilité du service cible. / Exceptions : Patient inconscient. Mineur non accompagné. Urgence vitale prioritaire sur l’administratif.

Le bloc YAML sert à donner des repères stables à la machine. L’id permet de référencer le concept sans ambiguïté. Le title aide les humains. Le type indique si on parle d’une procédure, d’une règle, d’une définition ou d’une FAQ. Related crée des connexions entre connaissances. Updated donne un signal de fraîcheur, très utile quand un agent doit éviter de s’appuyer sur une règle périmée.

Le contenu Markdown, lui, reste fait pour être lu. Résumé, étapes, dépendances, exceptions. C’est bête, mais ça évite beaucoup de flou. J’ai déjà vu des équipes support perdre des heures parce que la bonne règle existait, mais cachée dans un PDF de 40 pages nommé “process_final_v7”. Là, on veut l’inverse.

Git ajoute la couche qui manque souvent aux bases de connaissance : historique, revue, branches, retour arrière, validation avant mise en production. Une équipe data peut proposer une modification, le produit peut relire, les opérations peuvent valider, le support peut signaler une incohérence. La connaissance devient vivante, mais contrôlée.

Élément du bundle	Rôle	Bénéfice pour l’agent IA
Dossiers	Organisent les domaines métier	Réduit le bruit et cible mieux le contexte
Fichiers Markdown	Décrivent les concepts simplement	Facilite la lecture et l’extraction
Métadonnées YAML	Donnent une identité et un statut	Améliore le filtrage et la fiabilité
Liens related	Connectent les notions entre elles	Aide l’agent à raisonner par dépendances
Git	Trace et valide les changements	Limite les réponses basées sur du contenu non validé

Comment un agent IA utilise OKF ?

Un agent IA utilise OKF un peu comme un humain qui suit un dossier bien rangé. Il ne se contente pas de chercher “ce qui ressemble” à la question. Il parcourt les fichiers, lit les métadonnées, suit les liens déclarés entre les concepts, puis reconstruit la logique du sujet.

Concrètement, l’agent commence par identifier un concept. Par exemple “triage patient”. Il lit le contenu associé, puis regarde les métadonnées : service concerné, niveau de priorité, date de mise à jour, propriétaire métier, contexte d’usage. Ensuite, il suit les liens vers les concepts liés. C’est là que OKF devient intéressant.

Dans l’exemple hospitalier, l’agent peut partir du triage, comprendre que le patient doit ensuite être enregistré dans l’EHR, c’est-à-dire le dossier médical électronique, puis suivre le lien vers l’allocation des lits. Il garde l’ordre logique : évaluer le patient, créer ou mettre à jour son dossier, vérifier la disponibilité, orienter vers le bon service. Il ne mélange pas tout juste parce que deux paragraphes ont des mots proches.

RAG classique	L’agent récupère des fragments proches de la question avec une similarité vectorielle.
OKF	L’agent peut aussi parcourir les relations déclarées entre les concepts, les procédures et les règles.

Ça ne rend pas OKF magique. Si les fichiers sont mal écrits, si les liens sont faux, si les métadonnées sont pauvres, l’agent restera limité. Il aura juste une mauvaise carte au lieu d’avoir aucun plan. Et une mauvaise carte, ça peut aussi envoyer dans le décor.

Chez les clients, je vois souvent le même truc. Le vrai gain ne vient pas seulement du modèle IA. Il vient du travail de structuration en amont. Quand les liens métier sont écrits noir sur blanc, l’IA fait moins de contorsions. Elle n’a pas besoin de deviner qu’une politique interne dépend d’une procédure, qu’un runbook renvoie vers une API, ou qu’une étape doit forcément arriver avant une autre.

OKF est particulièrement adapté quand la connaissance est interconnectée et sensible à l’ordre logique :

• Procédures internes avec dépendances entre étapes.
• Politiques d’entreprise et règles de conformité.
• Runbooks d’exploitation et gestion d’incidents.
• Documentations API avec objets, endpoints et contraintes liés.
• Connaissances organisationnelles où le contexte compte autant que le contenu.

À mon avis, OKF ne remplace pas forcément le RAG. Il lui donne surtout une colonne vertébrale quand le sujet demande plus qu’une recherche de passages similaires.

Quand combiner OKF et RAG ?

Je combine OKF et RAG quand j’ai besoin à la fois d’une connaissance structurée et d’une recherche sémantique large. C’est souvent le cas dans les vrais systèmes d’entreprise. Vous avez des règles propres, validées, parfois sensibles. Et à côté, vous avez des tonnes de contenus moins propres, mais très utiles.

Le RAG reste excellent pour fouiller dans de gros volumes de contenus non structurés. RAG veut dire Retrieval Augmented Generation, en gros l’IA va chercher des passages pertinents avant de répondre. C’est pratique pour interroger des archives, des tickets support, des comptes rendus, des documents longs, ou des contenus qui changent vite. Quand la question ressemble à “Est-ce qu’on a déjà vu ce problème quelque part ?”, le RAG fait très bien le job.

OKF devient plus intéressant quand les relations comptent. OKF, Open Knowledge Format, sert à organiser la connaissance de façon plus explicite, avec des blocs, des liens, des versions, des dépendances. C’est adapté aux procédures, politiques internes, runbooks, documentations API, règles métiers, processus internes, connaissances validées. Là, je ne veux pas seulement retrouver un paragraphe proche. Je veux savoir quelle règle s’applique, dans quel contexte, avec quelle exception.

L’idée n’est pas de choisir un camp. Je place chaque approche au bon endroit. Une architecture hybride simple ressemble à ça : OKF sert de couche de connaissance organisée et versionnée. RAG sert de couche de recherche sémantique sur les contenus volumineux ou moins structurés. L’agent interroge l’un ou l’autre selon la question, parfois les deux.

Un exemple concret : un agent support interne peut consulter OKF pour récupérer la procédure validée, puis utiliser RAG pour retrouver des cas similaires dans d’anciens tickets. Il répond mieux parce qu’il a la règle et le terrain. J’ai vu ce cas chez un client, les réponses devenaient tout de suite moins théoriques, parce que l’agent ne récitait pas seulement la documentation officielle, il voyait aussi comment les problèmes avaient été résolus en vrai.

Besoin	Meilleure approche	Raison
Retrouver des cas similaires dans beaucoup de documents	RAG	Il explore vite des contenus longs, variés et peu structurés.
Appliquer une règle métier ou une procédure validée	OKF	Il garde les relations, les versions et le contexte explicite.
Répondre avec une règle fiable et des exemples terrain	OKF + RAG	L’agent combine la connaissance officielle avec les cas réels.

Et si le vrai sujet, c’était la connaissance elle-même ?

L’Open Knowledge Format remet un truc simple au centre : une IA ne devient pas fiable juste parce qu’elle retrouve des morceaux de texte. Elle a besoin de comprendre les liens entre les idées, les procédures, les règles et les exceptions. Le RAG reste très utile, surtout sur de gros volumes de contenus. OKF apporte autre chose : une connaissance lisible, structurée, versionnable et parcourable par des agents IA. Pour moi, la bonne approche sera souvent hybride. Vous gardez la puissance de la recherche sémantique, tout en donnant à vos agents une base de connaissances plus claire. Le bénéfice pour vous : moins de réponses fragiles, plus de contexte, et une IA vraiment exploitable dans votre business.

FAQ

• Qu’est-ce que l’Open Knowledge Format ?
  L’Open Knowledge Format, ou OKF, est une spécification ouverte pour organiser des connaissances utilisées par des agents IA. Il s’appuie sur des fichiers Markdown, des métadonnées YAML et des liens explicites entre concepts. L’objectif est de rendre la connaissance lisible, versionnable et plus facile à parcourir par une IA.
• OKF remplace-t-il le RAG ?
  Pas totalement. OKF répond surtout à une limite du RAG : la perte de contexte causée par le découpage des documents en fragments. Le RAG reste très utile pour chercher dans de gros volumes de texte. OKF est plus adapté quand les relations entre concepts, procédures ou règles métiers doivent rester explicites.
• Pourquoi le chunking pose problème dans un système RAG ?
  Le chunking découpe les documents en morceaux pour faciliter la recherche sémantique. C’est pratique, mais ça peut casser la logique d’un document. Dans une procédure, une étape peut dépendre d’une autre. Si ces éléments sont séparés, l’agent doit reconstruire le contexte à chaque requête, avec un risque d’erreur.
• Quels contenus sont adaptés à OKF ?
  OKF est particulièrement adapté aux connaissances structurées et interconnectées : politiques internes, procédures, runbooks, documentations API, règles métiers, protocoles opérationnels. Dès que les liens entre concepts sont importants, OKF devient intéressant.
• Quelle est la meilleure approche pour une entreprise ?
  Dans beaucoup de cas, la meilleure approche est hybride. OKF sert de base structurée, claire et versionnée. Le RAG complète avec une recherche sémantique sur des contenus plus volumineux ou moins organisés. L’agent IA peut alors s’appuyer à la fois sur une connaissance validée et sur des documents plus larges.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent rendre leurs données, leurs outils et leurs agents IA vraiment opérationnels, pas juste impressionnants en démo. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos données, vos automatisations ou vos bases de connaissance IA, contactez-moi, je peux vous aider.