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

OKF remplace surtout le RAG quand vos agents IA doivent comprendre une connaissance structurée, liée, vivante. Le RAG reste fort sur les gros corpus bruts. La vraie question, c’est moins remplacement que choix d’architecture. Et souvent, le meilleur setup combine les deux.

Pourquoi le RAG bloque parfois ?

Le RAG bloque surtout quand la connaissance dépend fortement de relations internes, de contexte métier et d’une structure documentaire précise.

Sur le papier, le RAG est simple. On prend des documents, on les découpe en morceaux, qu’on appelle des chunks, puis on transforme ces morceaux en embeddings. Un embedding, c’est une représentation numérique du sens d’un texte. Ensuite, on stocke ça dans une base vectorielle, une base faite pour retrouver les morceaux les plus proches d’une question. Le modèle récupère ces morceaux, puis génère une réponse.

C’est très efficace quand vous avez de gros volumes de documents non structurés. Des PDF, des comptes rendus, des pages wiki, des notes internes. Pour chercher une information générale, ça marche souvent très bien. Le souci arrive au moment du découpage.

Un document métier, ce n’est pas juste une suite de paragraphes. Il y a une logique. Des dépendances. Des exceptions. Des définitions qui ne valent que dans un contexte précis. Des procédures qui se répondent. Des règles qui changent selon un statut, une date, un service, un niveau de risque.

Prenez un protocole hospitalier. Vous avez une partie sur l’admission patient, une autre sur les règles de tri, une autre sur les indicateurs à surveiller, puis les responsabilités par rôle, puis les exceptions. Si on découpe tout ça en morceaux trop indépendants, le modèle peut récupérer le chunk sur l’admission, mais louper celui sur l’exception critique. Ou récupérer la règle de tri, sans voir que cette règle ne s’applique pas aux patients déjà suivis en oncologie.

Et là, la réponse a l’air crédible. Elle est même souvent bien formulée. Mais elle est incomplète. C’est le pire cas, parce qu’on ne voit pas tout de suite l’erreur.

Quand je vois un projet RAG qui répond à peu près bien mais rate les cas précis, le problème vient souvent moins du modèle que de la façon dont on a cassé la connaissance au départ. On a transformé une logique métier en petits bouts de texte. Et après, on demande au modèle de recoller les morceaux.

Ce que le RAG fait bien	Ce qu’il gère moins bien
Retrouver une information dans un gros volume de documents.	Comprendre des dépendances fortes entre plusieurs parties d’un document.
Répondre à des questions générales sur une base documentaire.	Traiter correctement les exceptions métier et les cas limites.
Exploiter des contenus peu structurés comme des PDF ou des pages wiki.	Préserver la logique complète d’une procédure découpée en chunks.
Donner rapidement une synthèse avec des sources proches.	Savoir qu’un fragment pertinent ne suffit pas toujours à répondre juste.

Qu’est-ce que l’OKF change ?

L’OKF change l’approche parce qu’il organise la connaissance pour qu’un agent IA puisse la parcourir, pas seulement retrouver des fragments isolés. C’est une nuance importante. Avec un RAG classique, on cherche souvent le bon morceau de texte au bon moment. Avec OKF, on prépare plutôt un terrain navigable, avec des concepts, des liens, du contexte et des relations déjà explicites.

L’Open Knowledge Format, annoncé par Google en juin 2026, est une spécification ouverte pour structurer et échanger des connaissances destinées aux agents IA. Ce n’est pas un SDK, ni un outil propriétaire à installer dans un coin. C’est plutôt une manière standardisée de représenter ce qu’une organisation sait, pour que plusieurs agents, outils ou systèmes puissent lire la même base sans repartir de zéro.

Le principe reste assez simple. Le contenu vit dans des fichiers Markdown, donc du texte lisible par un humain. Les métadonnées sont en YAML, un petit format de description très léger, souvent utilisé pour dire “ce document parle de quoi, dépend de quoi, appartient à quel domaine”. Les liens entre concepts gardent les relations. On se rapproche d’un wiki, mais d’un wiki pensé dès le départ pour des agents IA.

• Markdown garde le contenu métier lisible et modifiable.
• YAML décrit le concept, son statut, ses dépendances ou ses attributs.
• Les liens indiquent comment une règle, une métrique ou un process dépend d’un autre élément.

Il y a aussi cette idée communautaire autour du LLM Wiki. Un LLM, c’est un Large Language Model, le modèle qui comprend et génère du texte. L’analogie est assez parlante : Obsidian peut jouer le rôle d’IDE, donc l’environnement où on travaille, le LLM devient le programmeur, et le wiki devient le code. Je ne pousserais pas l’image trop loin, mais elle aide à comprendre le basculement.

Le vrai changement est là. Au lieu de reconstruire les relations à chaque requête, l’agent navigue dans une base déjà reliée. Pour des connaissances d’entreprise, c’est beaucoup plus naturel. Les process, les définitions métier, les politiques internes, les métriques, les systèmes, tout dépend de tout. J’ai vu ce problème chez des clients : le contenu existe, mais les liens implicites sont dans la tête des équipes. OKF cherche justement à rendre ces liens exploitables.

La question suivante devient donc très concrète : À quoi ressemble réellement un bundle OKF quand on ouvre le capot ?

À quoi ressemble un bundle OKF ?

Un bundle OKF ressemble à une base de connaissance lisible par un humain et exploitable par un agent IA, composée de Markdown, de YAML et de liens.

Je le vois comme un dossier bien rangé, pas comme une usine à gaz. OKF, ici, c’est surtout une manière ouverte d’organiser la connaissance pour qu’elle soit claire, versionnable et utile à un agent. On peut imaginer une organisation par concepts, procédures, métriques ou domaines métier. L’important, c’est que les fichiers restent lisibles, reliés entre eux, et simples à relire dans Git.

Le Markdown porte le contenu principal. C’est le texte lisible, avec des titres, des listes, des explications. Le YAML ajoute des métadonnées légères, comme un identifiant, un type de document, un responsable, ou des fichiers liés. Les liens relient les concepts entre eux. Git permet de suivre les changements, de revoir l’historique, et de travailler à plusieurs sans perdre qui a modifié quoi. C’est bête, mais chez un client dans la santé, c’est souvent ce point-là qui manque le plus. La connaissance existe, mais elle est éparpillée.

Voici un exemple volontairement simple autour d’un indicateur hospitalier :

---
id: indicateur-delai-admission
type: metric
owner: equipe-qualite
related:
  - procedure-admission-patient
  - definition-admission-complete
  - exception-urgence-vitale
---

# Délai moyen d'admission

Description:
Temps moyen entre l'arrivée administrative du patient et la validation complète de son admission.

Méthode de calcul:
Voir [[definition-admission-complete]] pour savoir quand une admission est considérée comme complète.

Procédure liée:
La collecte dépend de [[procedure-admission-patient]].

Exception:
Les cas d'urgence vitale suivent [[exception-urgence-vitale]] et ne doivent pas être comparés aux admissions standards.

Ce qui m’intéresse ici, ce n’est pas le format parfait. C’est le fait que l’agent ne lit pas juste un bloc de texte isolé. Il voit que l’indicateur dépend d’une définition, d’une procédure, et d’une exception. Les liens évitent de perdre ces dépendances. Et ça change beaucoup de choses quand l’agent doit répondre proprement, auditer une règle, ou signaler une incohérence.

Composant	Rôle	Bénéfice pour l’agent IA
Markdown	Contenu lisible et structuré	Comprend les règles, définitions et procédures sans parsing compliqué
YAML	Métadonnées légères	Filtre, classe et priorise les fichiers plus facilement
Liens internes	Relations entre concepts	Suit les dépendances au lieu de répondre sur un extrait isolé
Git	Historique et collaboration	Identifie les changements, les auteurs et les versions fiables

Comment un agent IA utilise OKF ?

Un agent IA utilise OKF en suivant les liens entre concepts, au lieu de dépendre uniquement d’une recherche vectorielle sur des morceaux de texte. Le RAG, pour Retrieval Augmented Generation, va souvent chercher les passages les plus proches d’une question dans une base vectorielle. OKF prend un autre chemin : il donne à l’agent une carte lisible de la connaissance.

Concrètement, l’agent part d’un concept. Par exemple “remboursement client”. Il lit ses métadonnées, comme son propriétaire, son statut, sa définition, ses règles métier. Puis il suit les liens vers les concepts liés : “avoir”, “facture”, “SAV”, “validation manager”, “délai légal”. Il compare les définitions, retrouve les procédures associées, puis construit une réponse avec plus de contexte.

Ce parcours ressemble plus à une enquête qu’à une simple recherche. L’agent ne se contente pas de dire “ce paragraphe ressemble à la question”. Il peut comprendre que tel concept dépend d’un autre, que telle procédure est obsolète, ou que telle règle appartient à une équipe précise.

Ce qui marche bien avec OKF, c’est surtout ça :

• Les relations sont explicites. L’agent voit les liens entre les notions au lieu de les deviner.
• La connaissance est maintenable. Les fichiers peuvent être corrigés, relus, renommés, versionnés.
• Les humains gardent la main. Un fichier OKF reste lisible par une personne métier, pas seulement par une machine.
• Git garde l’historique. On sait qui a changé quoi, quand, et pourquoi si les commits sont propres.
• Les changements sont traçables. C’est précieux quand un agent commence à répondre à des clients, des équipes support ou des commerciaux.

Je préfère être clair : OKF ne rend pas le raisonnement magique. Il ne remplace pas une vraie gouvernance documentaire. Si les fichiers sont mal écrits, si les concepts sont flous, si les liens sont absents ou faux, l’agent fera aussi de mauvais raisonnements. La structure aide, elle ne fait pas tout.

En entreprise, j’ai souvent vu le vrai problème ailleurs que dans la techno. Le plus dur, c’est de nommer proprement les concepts, clarifier qui est responsable de quoi, et accepter que la connaissance doit être entretenue. OKF est très fort quand la connaissance est organisée. Mais le RAG reste utile dans certains cas, surtout quand il faut chercher vite dans beaucoup de documents peu structurés.

Faut-il choisir entre OKF et RAG ?

Il ne faut pas forcément choisir entre OKF et RAG, parce qu’ils ne répondent pas au même besoin et, dans beaucoup de cas, ils se complètent très bien.

Le RAG, pour Retrieval Augmented Generation, reste excellent quand on doit chercher dans de gros volumes de documents. Des PDF, des archives, des comptes rendus, des contrats, des tickets support, des pages Notion, des fichiers un peu partout. Il récupère des passages pertinents, puis les donne au modèle IA pour répondre. C’est très pratique quand la connaissance est large, hétérogène, pas toujours bien rangée.

L’OKF, que je vois comme un cadre de connaissance organisationnelle structuré, prend l’avantage quand on parle de procédures, de règles métier, de concepts liés entre eux, de responsabilités, de définitions internes. Là, on ne veut pas juste retrouver un paragraphe. On veut que l’agent comprenne que tel produit dépend de telle règle, que telle exception bloque tel process, que telle équipe est propriétaire de telle donnée. Chez un client, c’est souvent là que le RAG seul commence à patiner. Il retrouve les bons bouts de texte, mais il ne sait pas toujours les relier proprement.

Une architecture hybride simple marche souvent mieux. L’OKF sert de noyau fiable, propre, maintenu dans le temps. Le RAG sert à explorer les documents bruts autour. L’agent peut partir d’un concept OKF, par exemple “résiliation client entreprise”, comprendre les règles principales, puis utiliser le RAG pour retrouver les clauses, les emails ou les procédures détaillées qui complètent la réponse.

Situation	Approche recommandée	Raison
Beaucoup de documents non structurés	RAG	Il cherche efficacement dans un gros corpus documentaire.
Règles métier complexes et liées entre elles	OKF	Il garde les relations, les concepts et les dépendances explicites.
Base de connaissance qui évolue souvent	OKF avec gouvernance	Il devient plus simple de maintenir une version fiable de la connaissance.
Besoin de retrouver les sources exactes	RAG	Il permet de pointer vers les documents et passages utilisés.
Agent IA critique pour des décisions métier	OKF + RAG	L’OKF sécurise le raisonnement, le RAG apporte le contexte documentaire.

Le bon sujet n’est pas de remplacer une techno par une autre, mais de donner à l’agent la bonne forme de connaissance pour la bonne tâche.

Et si le vrai sujet c’était la forme de votre connaissance ?

OKF met le doigt sur un problème que je vois souvent dans les projets IA : on veut des agents fiables, mais on leur donne une connaissance éclatée. Le RAG reste très utile pour fouiller de gros corpus bruts. OKF devient intéressant quand votre business repose sur des concepts, des procédures, des règles et des liens qu’il ne faut pas casser. Pour moi, l’approche la plus solide sera souvent hybride : un socle OKF structuré, complété par du RAG quand il faut explorer large. Le bénéfice pour vous est simple : des agents IA plus cohérents, plus traçables, et plus faciles à maintenir.

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 utilisables par des agents IA. L’idée est de stocker la connaissance dans des fichiers Markdown, avec des métadonnées YAML légères et des liens entre concepts. On garde une base lisible, versionnable et navigable.
• Pourquoi le RAG peut-il perdre le contexte ?
  Le RAG découpe souvent les documents en chunks avant de les indexer dans une base vectorielle. C’est efficace pour chercher dans de gros volumes, mais ce découpage peut casser les relations internes d’un document. Le modèle récupère alors un bon fragment, sans forcément récupérer tout ce qui lui donne son sens.
• OKF remplace-t-il complètement le RAG ?
  Pas forcément. OKF est plus adapté aux connaissances structurées, reliées et maintenues dans le temps. Le RAG reste très bon pour interroger de grands corpus non structurés. Dans beaucoup de cas, le bon choix sera une architecture hybride qui combine les deux.
• Quels types de connaissances conviennent bien à OKF ?
  OKF convient bien aux procédures, définitions métier, politiques internes, métriques, règles organisationnelles et bases de connaissances où les liens entre concepts sont importants. Dès que la relation entre les informations compte autant que le texte lui-même, OKF devient intéressant.
• Quel est l’intérêt de Git dans une base OKF ?
  Git permet de suivre les changements, revenir en arrière, relire l’historique et collaborer proprement. Pour une base de connaissance utilisée par des agents IA, c’est important. On ne veut pas seulement produire des réponses, on veut aussi comprendre quelle connaissance a été utilisée et comment elle évolue.

 

 

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 passer de la démo IA sympa à des systèmes utiles, maintenables et branchés sur leurs vraies données. 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 connaissances ou vos automatisations IA, contactez-moi.