OKF va-t-il remplacer le RAG pour les agents IA ?

OKF ne remplace pas le RAG partout, il corrige surtout un vrai problème des bases vectorielles : la connaissance découpée en morceaux perd son contexte. Je vous montre où OKF apporte quelque chose aux agents IA, où le RAG reste utile, et pourquoi l’hybride sera souvent le meilleur choix.

Pourquoi le RAG bloque-t-il parfois ?

Le RAG bloque parfois parce qu’il découpe les documents en fragments qui perdent une partie de leur logique interne. Le RAG, pour Retrieval-Augmented Generation, c’est une méthode assez simple dans l’idée : on prend des documents, on les coupe en petits blocs qu’on appelle des chunks, on transforme ces blocs en vecteurs, puis on les stocke dans une base vectorielle. Quand vous posez une question, le système cherche les chunks les plus proches sémantiquement, puis les donne au modèle IA pour répondre.

C’est puissant. Vraiment. Ça permet de chercher vite dans des centaines de pages, parfois des milliers. Le souci, c’est que le système retrouve des morceaux proches d’une question, mais il ne comprend pas toujours comment ces morceaux s’articulent entre eux.

Prenons une politique d’admission hospitalière. Une règle peut dire : “Un patient peut être admis en service prioritaire si son état correspond aux critères d’urgence.” Très bien. Mais la définition de “critères d’urgence” est peut-être dix pages plus haut. Une exception est peut-être trois pages plus bas. La procédure à appliquer est peut-être dans une autre section liée au service concerné. Si tout ça est découpé séparément, l’agent IA peut récupérer le bon passage, mais rater la relation qui change l’interprétation.

J’ai vu exactement ce problème chez des clients. La base documentaire avait l’air propre. Les fichiers étaient bien nommés, les contenus à jour, les chunks plutôt bien faits. Mais les dépendances métier étaient implicites. Les experts humains savaient que telle règle dépendait de telle définition. L’agent, lui, voyait juste des morceaux de texte proches.

Le RAG reste très bon pour chercher vite dans de gros volumes. Son point faible apparaît surtout avec les procédures, les politiques internes, la documentation métier, les définitions liées, les règles conditionnelles et les connaissances qui évoluent. Là, on ne cherche plus seulement une phrase. On cherche une logique.

Critère	Document complet	Chunk RAG	Connaissance structurée
Contexte	Contexte présent mais lourd à lire.	Contexte souvent partiel.	Contexte explicite et ciblé.
Relations	Relations visibles si on lit tout.	Relations souvent perdues.	Relations décrites directement.
Mise à jour	Mise à jour parfois lente.	Mise à jour simple mais fragile.	Mise à jour plus contrôlée.
Lecture par agent IA	Lecture coûteuse et longue.	Lecture rapide mais incomplète.	Lecture plus fiable pour raisonner.

Qu’est-ce que le format OKF ?

OKF est une spécification ouverte qui organise la connaissance pour que les agents IA puissent la lire comme un wiki structuré, pas comme une pile de fragments isolés. Open Knowledge Format a été annoncé par Google en juin 2026 pour stocker et échanger des connaissances destinées aux agents IA. L’idée est simple : arrêter de donner aux modèles des bouts de texte sans contexte, et leur fournir une base de connaissance navigable.

Dans OKF, on retrouve trois briques assez classiques, mais bien assemblées.

• Des fichiers Markdown pour écrire le contenu. Markdown, c’est du texte simple avec un peu de structure : titres, listes, liens, blocs de code.
• Des métadonnées YAML pour décrire les concepts. YAML, c’est un format lisible par un humain, souvent utilisé pour déclarer des propriétés comme un nom, un type, un statut, une source.
• Des liens entre concepts pour garder les relations. Un agent peut voir qu’un sujet dépend d’un autre, qu’un document remplace une ancienne version, ou qu’une règle s’applique à un cas précis.

Le parallèle le plus simple, c’est un wiki ou un espace de notes comme Obsidian. Sauf qu’ici, ce n’est pas pensé uniquement pour des humains qui cliquent dans une interface. C’est pensé pour des agents IA qui doivent lire, comprendre, relier, et parfois proposer des changements.

Cette idée n’arrive pas de nulle part. Elle rejoint le mouvement des LLM Wikis, popularisé notamment par Andrej Karpathy. Un LLM Wiki, c’est une base de connaissance structurée pour les grands modèles de langage, pas juste une documentation classique. Google vient surtout mettre une couche de standardisation dessus, sans forcer tout le monde à utiliser un outil précis. Et ça, c’est important. OKF normalise la connaissance, pas l’interface.

Concrètement, ça change le comportement attendu d’un agent. Il ne récupère pas seulement un extrait “proche” d’une question. Il peut naviguer d’un concept vers un autre, suivre des liens, comprendre une hiérarchie, repérer une dépendance, puis proposer une mise à jour si une information semble obsolète.

J’aime bien ce point parce qu’il est très terre à terre. Markdown et YAML passent très bien dans Git. On peut versionner, relire, comparer deux changements, revenir en arrière. Dans beaucoup d’entreprises, c’est déjà comme ça qu’on gère du code. OKF applique cette logique à la connaissance.

Pour moi, la partie la plus sous-estimée est là : rendre la connaissance modifiable par des humains et exploitable par des agents. Pas juste la stocker. La faire vivre proprement.

À quoi ressemble un bundle OKF ?

Un bundle OKF ressemble à un dossier de connaissances versionnable, avec des fichiers Markdown, des métadonnées YAML et des liens explicites entre concepts. Je le vois comme un paquet cohérent sur un domaine précis. Une politique interne, une documentation produit, des règles métier, un référentiel de métriques, des procédures support. Pas juste des bouts de texte jetés dans un moteur de recherche.

Le bundle sert à dire à l’agent IA : Voilà le domaine, voilà les concepts importants, voilà comment ils sont reliés. YAML, c’est un petit format lisible par humain et machine, souvent placé en haut d’un fichier pour décrire ce qu’il contient. Markdown, c’est le texte structuré simple, avec titres, listes, paragraphes.

Élément	Exemple	Rôle
Dossier racine	support-client-okf/	Contient le bundle complet.
Page d’index	index.md	Présente le domaine et les points d’entrée.
Dossier concepts	concepts/	Regroupe les notions clés.
Fichiers Markdown	concepts/delai-remboursement.md	Décrit une notion précise.
Liens entre concepts	related: [procedure-litige, politique-remboursement]	Rend les relations explicites.

Un fichier concept peut ressembler à ça. Je prends une métrique hospitalière volontairement générique, sans inventer de règle médicale.

---
id: metric-delai-prise-en-charge
title: Délai moyen de prise en charge
type: metric
related:
  - concept-admission
  - procedure-triage
  - exception-donnees-manquantes
depends_on:
  - horodatage-arrivee
  - horodatage-premier-contact
---

Définition

Cette métrique mesure le temps moyen entre l’arrivée enregistrée d’un patient et le premier contact documenté avec une équipe de prise en charge.

Formule

Moyenne de : horodatage du premier contact moins horodatage d’arrivée.

Dépendances

La métrique dépend de la qualité des horodatages et du périmètre retenu.

Exceptions

Les dossiers avec horodatage manquant doivent être identifiés séparément, au lieu d’être mélangés dans le calcul.

L’intérêt pour un agent IA est assez concret. Il ne voit pas juste un paragraphe qui parle d’hôpital. Il comprend que ce fichier décrit une métrique, que cette métrique a une formule, des dépendances, des exceptions, et des concepts liés. Ça change tout quand l’agent doit répondre, vérifier une règle, générer une requête SQL ou expliquer une décision.

Élément	Intérêt pour l’agent IA
Fichier Markdown	Donne un contenu lisible, structuré, facile à citer.
Métadonnées YAML	Indiquent le type de connaissance, l’identifiant, les dépendances.
Liens explicites	Aident l’agent à naviguer entre définition, procédure, politique et exception.
Git	Permet de versionner, relire, valider et tracer les changements.

Comment un agent IA utilise-t-il OKF ?

Un agent IA utilise OKF en parcourant les liens et les métadonnées pour reconstruire le contexte avant de répondre ou d’agir. Il ne se contente pas de chercher le passage le plus proche d’une question, comme dans un RAG classique. Il peut partir d’un concept, lire sa définition, suivre ses relations, consulter les exceptions, puis remonter vers une règle parent ou une procédure associée.

C’est là que ça devient intéressant. OKF fonctionne comme un wiki structuré. Pas juste des pages posées les unes à côté des autres, mais des connaissances reliées entre elles avec des concepts, des règles, des dépendances, des dates, des propriétaires, des statuts de validation. Pour un agent IA, c’est beaucoup plus exploitable qu’un gros tas de documents découpés en morceaux.

Prenons une politique d’admission hospitalière. Un utilisateur demande : “Est-ce qu’un patient mineur peut être admis sans représentant légal ?”. L’agent identifie le concept principal, ici l’admission d’un mineur. Il lit le fichier concerné, puis suit les liens vers les conditions d’admission, les exceptions d’urgence, les documents de consentement, les règles liées au service pédiatrique et peut-être la procédure d’escalade vers l’administrateur de garde. Sa réponse sera plus contextualisée, parce qu’il ne répond pas seulement avec un extrait trouvé au hasard. Il reconstruit le raisonnement métier autour de la question.

Je reste prudent quand même. OKF ne garantit pas la vérité. Il donne une structure plus saine pour exploiter la connaissance. Si le contenu est mauvais, obsolète ou non validé, l’agent peut produire une réponse propre en apparence mais fausse sur le fond. La qualité dépend toujours des experts métier, des validations humaines et de la gouvernance. Qui valide ? Qui met à jour ? Qui tranche quand deux règles se contredisent ? C’est souvent là que le vrai travail commence.

Pour les agents, ça marche bien parce qu’ils ont besoin de naviguer, raisonner, citer des concepts, proposer des corrections et mettre à jour la base. Avec Git, on peut contrôler les changements, relire les modifications, revenir en arrière et garder un historique clair. Dans les projets IA en entreprise, je le vois souvent : le vrai sujet n’est pas seulement le modèle. C’est l’état réel de la connaissance métier.

Les cas d’usage naturels sont assez évidents :

• Support interne.
• Procédures opérationnelles.
• Knowledge management.
• Documentation produit.
• Référentiels de métriques.

Faut-il choisir OKF ou RAG ?

Il ne faut pas forcément choisir entre OKF et RAG. Je vois plutôt ça comme deux outils qui ne répondent pas au même problème. Le RAG, Retrieval-Augmented Generation, sert à retrouver des passages pertinents dans un gros volume de documents avant de les donner au modèle IA. OKF, lui, sert à organiser une connaissance métier propre, structurée, maintenable, avec des règles, des liens et des versions.

Le RAG reste excellent quand on doit fouiller vite dans beaucoup de contenu. Des PDF, des comptes rendus, des archives, des pages wiki un peu vieillissantes, des contrats, des tickets support. C’est très fort pour trouver “le bon passage” dans un corpus large, même si tout n’est pas parfaitement rangé. Je ne le vois pas comme une technologie dépassée. Franchement, pour de la recherche exploratoire, c’est souvent le meilleur point de départ.

OKF prend l’avantage dès que la connaissance devient stratégique. Quand une règle dépend d’une autre règle. Quand une procédure change tous les mois. Quand la documentation doit être relue, validée, versionnée et améliorée. Là, découper des PDF au hasard et espérer que l’agent comprenne tout correctement, c’est fragile. J’ai vu ça chez un client sur des règles métier internes, le RAG retrouvait bien des bouts de texte, mais l’agent mélangeait parfois l’ancien process et le nouveau. Le problème n’était pas le modèle. Le problème, c’était la connaissance.

Situation	Meilleur choix	Raison
Politique interne complexe	OKF	Les règles doivent être structurées, reliées et maintenues proprement
Recherche dans archives	RAG	Le besoin principal est de retrouver rapidement des passages pertinents
Documentation produit maintenue	OKF + RAG	OKF porte la vérité structurée, RAG retrouve les détails dans les sources
Corpus massif non structuré	RAG	Le volume est trop large pour tout modéliser proprement au départ
Agent métier critique	OKF + RAG	L’agent a besoin d’un cadre fiable et de preuves dans les documents

Le modèle le plus réaliste, c’est l’hybride. OKF sert de socle fiable, structuré et maintenu. RAG reste autour comme moteur de recherche dans les documents sources et les contenus moins organisés. L’agent peut commencer par naviguer dans OKF pour comprendre le cadre, puis interroger un index vectoriel pour trouver des éléments complémentaires.

Ma recommandation est simple. Si votre connaissance est stratégique, il faut arrêter de la traiter comme un tas de PDF découpés au hasard. OKF peut devenir la couche propre sur laquelle les agents travaillent. Le RAG reste très utile, mais plutôt comme moteur de recherche autour de ce socle.

Et si le vrai sujet était la qualité de votre connaissance ?

OKF apporte une réponse intéressante à un problème très concret : les agents IA ont besoin de contexte, de liens et de connaissances maintenues, pas seulement de chunks récupérés par similarité. Le RAG reste utile, surtout pour chercher vite dans de grands volumes. Mais dès qu’on touche à des règles métier, des procédures, des métriques ou des politiques internes, structurer la connaissance change beaucoup de choses. Mon avis : le bon réflexe, c’est souvent OKF pour le socle fiable, RAG pour l’exploration large. Le bénéfice pour vous est simple : des agents IA plus cohérents, plus auditables et plus utiles au business.

FAQ

• Qu’est-ce que OKF pour les agents IA ?
  OKF, ou Open Knowledge Format, est une spécification ouverte pensée pour organiser des connaissances que les agents IA peuvent lire, parcourir et mettre à jour. L’idée est de stocker la connaissance dans des fichiers Markdown, avec des métadonnées YAML et des liens entre concepts, un peu comme un wiki structuré.
• Pourquoi OKF peut-il être meilleur que le RAG classique ?
  OKF peut être meilleur quand la connaissance dépend de relations entre concepts. Le RAG classique découpe souvent les documents en chunks, ce qui peut casser la logique d’un document. OKF garde les liens, les définitions, les dépendances et les exceptions visibles pour l’agent IA.
• Le RAG devient-il inutile avec OKF ?
  Non, le RAG reste très utile pour chercher dans de gros volumes de documents, surtout quand le contenu est peu structuré. OKF sert plutôt à construire une base de connaissance propre, versionnée et reliée. Les deux peuvent très bien fonctionner ensemble dans une architecture hybride.
• Pourquoi Markdown et YAML sont-ils importants dans OKF ?
  Markdown rend le contenu lisible par les humains et facile à éditer. YAML ajoute des métadonnées légères, comme le type de concept, l’identifiant ou les liens liés. Ensemble, ils permettent de créer une connaissance simple à maintenir, compatible avec Git et compréhensible par des agents IA.
• Dans quels cas utiliser OKF en entreprise ?
  OKF est pertinent pour les procédures internes, les politiques métier, la documentation produit, les référentiels de métriques, les bases de support et les connaissances qui évoluent régulièrement. Dès que le contexte et les relations comptent, OKF apporte une structure plus fiable qu’un simple découpage documentaire.

 

 

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 process et leurs connaissances vraiment exploitables par des systèmes IA. 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 et vos connaissances pour vos agents IA, contactez-moi.