OKF peut-il remplacer le RAG pour vos agents IA ?

OKF ne remplace pas le RAG partout, il corrige surtout ses faiblesses quand la connaissance est structurée. Le vrai sujet, c’est de savoir quand utiliser une base vectorielle, quand utiliser des fichiers Markdown reliés, et comment combiner les deux sans compliquer votre stack IA.

Pourquoi le RAG atteint-il ses limites ?

Le RAG atteint ses limites quand il prend une connaissance structurée, avec des liens logiques importants, et qu’il la découpe en fragments qui ne portent plus toute la logique d’origine. C’est souvent là que les ennuis commencent.

Le fonctionnement classique du Retrieval-Augmented Generation, ou RAG, est assez simple. On prend des documents, on les découpe en petits blocs de texte, qu’on appelle des chunks. On transforme ces chunks en vecteurs, c’est-à-dire en représentations numériques du sens, puis on les stocke dans une base vectorielle. Quand l’utilisateur pose une question, le système cherche les chunks les plus proches de la requête, et les donne au modèle pour générer une réponse.

Ça marche très bien quand on a beaucoup de texte non structuré. Des PDF, des notes, des comptes rendus, des pages de documentation. Le RAG est bon pour retrouver “le bon passage” dans une masse de contenu. Mais il devient plus fragile quand la réponse dépend de relations précises entre plusieurs concepts.

Prenons une politique d’admission hospitalière. On peut avoir une logique du type : le patient passe par le triage, puis il est enregistré dans l’EHR, c’est-à-dire le dossier patient informatisé, puis un lit lui est attribué selon son état, sa priorité et les disponibilités. Si ces informations sont réparties dans trois ou quatre chunks différents, le modèle récupère parfois des morceaux pertinents, oui, mais incomplets. Il doit alors reconstruire lui-même la procédure.

Et c’est là que ça dérape. Le problème n’est pas juste technique. Ce n’est pas seulement une histoire de taille de chunk, de score de similarité ou de meilleure base vectorielle. C’est un problème de transmission du contexte. La logique métier vit dans les liens entre les éléments, pas seulement dans les phrases prises séparément.

J’ai souvent vu des projets RAG donner de très bons résultats en démo, puis devenir plus instables dès qu’on interroge des procédures métier un peu liées entre elles. Une question simple passe. Une question qui combine deux règles, une exception et une séquence opérationnelle devient beaucoup moins fiable.

Donc si la connaissance a déjà une structure, autant la conserver. Plutôt que de la casser en morceaux puis demander au modèle de deviner les liens, OKF part d’une idée plus saine : garder les relations explicites dès le départ.

Qu’est-ce que l’OKF change vraiment ?

OKF change l’approche en stockant la connaissance comme un réseau de concepts lisibles, versionnables et reliés, plutôt que comme une pile de fragments vectorisés. C’est ça le vrai sujet. Avec le RAG, on découpe souvent des documents en morceaux, on les transforme en vecteurs, puis on espère que la recherche retrouve le bon contexte au bon moment. Avec l’OKF, pour Open Knowledge Format, Google a introduit en juin 2026 une spécification ouverte pour organiser et échanger des connaissances destinées aux agents IA.

Ce n’est pas magique. Ce n’est pas non plus “le nouveau truc qui remplace tout”. C’est surtout une manière plus propre de représenter certaines connaissances, surtout quand elles ont une structure, une logique métier, des règles, des dépendances.

Les trois briques sont simples :

• Markdown sert à écrire le contenu dans un format lisible par un humain. Un concept, une procédure, une règle interne, une définition produit. Rien d’exotique.
• YAML sert à ajouter des métadonnées structurées. Par exemple le propriétaire du contenu, la version, le niveau de confiance, la date de mise à jour, les systèmes concernés. YAML, c’est juste une façon claire d’écrire des informations sous forme clé-valeur.
• Les liens servent à connecter les concepts entre eux. Une règle dépend d’une métrique. Une procédure applique une politique. Une définition produit renvoie à un modèle de données.

La nuance importante, c’est que l’OKF n’est pas un SDK complet. Un SDK, c’est un kit de développement avec du code, des fonctions, des outils prêts à intégrer. Ici, on parle plutôt d’une normalisation de format. Google cherche à formaliser une pratique, pas à imposer toute une plateforme.

Ça rejoint très bien l’idée de LLM Wiki popularisée par Andrej Karpathy. Un agent IA ne devrait pas toujours repartir de documents bruts, longs, ambigus, parfois contradictoires. Il peut lire, mettre à jour et relier des synthèses de concepts. Un peu comme une base de connaissances vivante, mais pensée pour être manipulée par des agents.

J’ai vu ce problème chez des clients : le RAG retrouve des passages, mais l’agent ne comprend pas toujours la logique globale. L’OKF aide justement quand il faut maintenir une mémoire organisationnelle, pas juste chercher une phrase dans un PDF.

L’intérêt d’OKF, ce n’est pas d’être plus moderne que RAG, c’est d’être plus fidèle à la structure réelle de certaines connaissances.

À quoi ressemble une base OKF ?

Une base OKF ressemble à un dossier de fichiers Markdown enrichis par des métadonnées YAML et reliés entre eux par des liens explicites. C’est assez simple, et c’est justement l’intérêt. Un bundle OKF, je le vois comme un ensemble de fichiers lisibles, éditables, versionnables, qu’on peut mettre dans un dépôt Git ou garder dans un environnement documentaire plus classique.

OKF, dans cette logique, ne cherche pas à cacher la connaissance dans une boîte noire. On garde des fichiers Markdown simplifiés pour écrire les concepts, les règles, les définitions. On ajoute du YAML, c’est un petit format de métadonnées lisible par un humain comme par une machine. Puis on relie les concepts entre eux avec des liens explicites.

Un fichier conceptuel pourrait ressembler à ça :

---
type: concept
domaine: hopital
proprietaire: equipe_operations
derniere_mise_a_jour: 2026-01-12
---

# admission_hospitaliere

Résumé:
Processus par lequel un patient est officiellement pris en charge par l’hôpital,
depuis son arrivée jusqu’à son orientation vers un service ou un lit disponible.

Liens:
- triage
- dossier_patient_ehr
- attribution_lit

Ce n’est pas magique. Et c’est une bonne nouvelle. Une organisation peut relire cette connaissance, la corriger, la valider avec les métiers, la versionner dans Git, voir qui a modifié quoi, et relier proprement les concepts entre eux. J’ai vu des clients perdre un temps fou avec des bases documentaires où personne ne savait si une définition était encore vraie. Là, au moins, on peut auditer.

La différence avec une base vectorielle est importante. Dans une base vectorielle, les documents sont transformés en embeddings, c’est-à-dire en représentations numériques qui capturent une proximité de sens. Les liens existent souvent implicitement dans ces vecteurs. C’est puissant pour retrouver un passage proche d’une question, mais c’est moins confortable quand on veut contrôler précisément pourquoi un agent IA associe deux notions. Dans OKF, les liens sont écrits. Donc ils sont visibles, discutables, modifiables.

Élément	Rôle	Valeur pour un agent IA
Markdown	Décrire les concepts dans un format simple et lisible	Donne une connaissance claire, relisible par les équipes
YAML	Ajouter des métadonnées légères comme le type, le domaine ou le propriétaire	Aide l’agent à filtrer, classer et contextualiser l’information
Liens entre concepts	Relier explicitement les notions importantes	Permet un raisonnement plus contrôlable et plus traçable

Comment un agent IA exploite-t-il OKF ?

Un agent IA exploite OKF en parcourant des concepts et leurs liens, au lieu de dépendre uniquement d’une recherche de fragments similaires. OKF, pour Open Knowledge Fabric, c’est une façon d’organiser la connaissance en fichiers simples, reliés entre eux, avec du contenu, des métadonnées et des relations explicites.

Le parcours est assez logique. L’agent part d’un concept de départ, par exemple “Admission patient”. Il lit le contenu du fichier, regarde les métadonnées, comme le service concerné, la version, la date de mise à jour ou le propriétaire métier. Puis il suit les liens vers les concepts reliés. C’est là que ça change beaucoup de choses.

Dans un hôpital, une question sur l’admission d’un patient ne doit pas seulement retrouver un paragraphe qui parle du triage. Elle doit aussi comprendre que le triage est lié à l’enregistrement dans l’EHR, c’est-à-dire le dossier patient informatisé, puis à l’attribution des lits, aux règles de priorité, aux contraintes de capacité et parfois aux politiques internes du service.

Avec un RAG classique, l’agent peut tomber sur le bon bout de texte, mais perdre une partie du chemin métier. Avec OKF, il navigue dans une carte de connaissances. Il voit que “Admission patient” dépend de “Triage”, que “Triage” alimente “Enregistrement EHR”, et que cet enregistrement déclenche ou conditionne “Attribution des lits”. La réponse devient plus stable, parce qu’elle suit la logique de l’organisation, pas juste la proximité statistique entre une question et un morceau de document.

C’est particulièrement utile pour certains types de connaissances :

• Les procédures, où l’ordre des étapes compte vraiment.
• Les politiques internes, où une règle dépend souvent d’un contexte précis.
• Les métriques, parce qu’un indicateur sans définition claire devient vite dangereux.
• Les règles métiers, qui ont presque toujours des exceptions.
• La connaissance organisationnelle, celle qui est souvent dans la tête des équipes.

Ce modèle aide aussi la maintenance. Si un concept change, on met à jour le fichier concerné et ses liens. L’agent travaille sur une base plus lisible pour les humains, pas sur une soupe de PDF découpés en morceaux. Mais ce n’est pas magique. Il faut structurer la connaissance. J’ai rarement vu une base de connaissance devenir fiable sans un minimum de gouvernance. La force d’OKF, c’est de rendre cette gouvernance praticable, parce que les fichiers restent simples.

Faut-il choisir entre OKF et RAG ?

Il ne faut pas choisir systématiquement entre OKF et RAG. Le meilleur montage est souvent hybride, surtout dès qu’on veut des agents IA fiables dans un vrai contexte métier.

Le RAG, pour Retrieval-Augmented Generation, reste très utile quand on doit chercher dans de gros volumes de contenus non structurés. Des documents longs, des archives, des PDF, des tickets support, des pages Notion, des contrats, des contenus qui changent souvent. Si le corpus est trop large ou trop bordélique pour être organisé à la main, le RAG fait très bien le job : il retrouve les passages utiles et les donne au modèle comme contexte.

OKF joue un autre rôle. OKF, ici, c’est la couche de connaissance organisée : concepts métiers, relations entre objets, procédures internes, politiques, métriques, règles opérationnelles. C’est ce que l’agent doit comprendre, maintenir et réutiliser proprement. Pas juste “retrouver un bout de texte qui ressemble à la question”.

Dans les meilleurs systèmes que j’ai vus, l’architecture ressemble plutôt à ça :

• Le RAG retrouve les documents bruts, les sources, les preuves, les passages d’origine.
• OKF maintient une connaissance propre, reliée, stable, exploitable par les agents IA.
• L’agent utilise les deux : il raisonne avec OKF, puis il vérifie ou cite avec le RAG.

Sur un projet client, on avait un assistant support interne. Le RAG seul répondait parfois juste, parfois à côté, parce qu’il piochait dans des procédures anciennes. En ajoutant une couche OKF avec les politiques à jour, les produits, les exceptions et les règles de priorité, l’agent a commencé à raisonner beaucoup plus proprement. Le RAG servait encore, mais plutôt comme source de preuve.

Le critère est simple. Si vous cherchez dans un vrac documentaire, RAG est adapté. Si vous voulez faire raisonner un agent sur des concepts reliés, des règles et des décisions métier, OKF devient intéressant.

Usage	RAG seul	OKF seul	Hybride	Recommandation pratique
Support interne	Bon pour retrouver des tickets et procédures.	Bon pour structurer les règles de réponse.	Très solide.	Utiliser OKF pour les règles, RAG pour les sources.
Assistant métier	Limité si les concepts sont complexes.	Très utile pour les objets métier.	Recommandé.	Modéliser les concepts clés dans OKF.
Agent d’onboarding	Utile pour explorer la documentation RH.	Utile pour les parcours et politiques internes.	Très adapté.	Combiner parcours structuré et recherche documentaire.
Agent qualité	Faible si les critères doivent être stables.	Très bon pour les grilles et règles.	Idéal.	Mettre les critères dans OKF, garder les preuves via RAG.
Documentation analytique	Bon pour retrouver des rapports.	Bon pour définir métriques et dimensions.	Recommandé.	Structurer les métriques dans OKF.

Et si le bon sujet était la structure de votre connaissance ?

OKF apporte une réponse simple à un problème que je vois souvent : on demande aux agents IA de raisonner sur une connaissance qu’on a d’abord cassée en chunks. Le RAG reste très utile, surtout sur de gros corpus non structurés. Mais quand vos procédures, vos métriques ou vos règles métiers dépendent de liens précis, OKF devient plus naturel. Markdown garde le contenu lisible, YAML ajoute le contexte, les liens préservent la logique. Le bon choix n’est pas dogmatique. Une architecture hybride peut donner le meilleur des deux. Le bénéfice pour vous : des agents IA plus stables, plus maintenables, et une connaissance enfin exploitable.

FAQ

• Qu’est-ce que l’OKF pour les agents IA ?
  L’OKF, ou Open Knowledge Format, est une spécification ouverte pensée pour organiser des connaissances destinées aux agents IA. L’idée est simple : utiliser des fichiers Markdown, des métadonnées YAML et des liens entre concepts pour créer une base de connaissance lisible, navigable et maintenable.
• Pourquoi le RAG peut-il perdre du contexte ?
  Le RAG découpe souvent les documents en chunks pour les indexer dans une base vectorielle. Ça marche bien pour rechercher dans beaucoup de texte, mais ça peut séparer des idées qui étaient liées dans le document d’origine. Le modèle doit alors reconstruire la logique à partir de fragments.
• OKF remplace-t-il une base vectorielle ?
  Pas forcément. OKF est plus adapté aux connaissances structurées, reliées et maintenues dans le temps. Une base vectorielle reste pertinente pour explorer de grands volumes de contenus non structurés. Dans beaucoup de cas, l’approche la plus solide consiste à combiner OKF et RAG.
• Quel est l’intérêt du Markdown et du YAML dans OKF ?
  Markdown rend le contenu facile à lire et à éditer. YAML ajoute des métadonnées simples comme le type de concept, le domaine, le propriétaire ou la date de mise à jour. Ensemble, ils permettent de créer une connaissance utilisable par les humains et par les agents IA.
• Dans quels cas OKF est-il le plus utile ?
  OKF est surtout utile pour les procédures internes, les politiques métier, les métriques, les règles opérationnelles et les bases de connaissance où les relations entre concepts comptent beaucoup. Dès que le raisonnement dépend de liens explicites, OKF devient intéressant.

 

 

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 utilisables, 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 connaissances, automatiser vos process ou intégrer l’IA proprement dans votre business, contactez-moi.