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

OKF ne remplace pas le RAG partout. Il répond surtout à un problème précis : donner aux agents IA une connaissance structurée, reliée et versionnable. Là où le RAG découpe, OKF garde les liens. Et pour certaines bases internes, ça change beaucoup de choses.

Pourquoi le RAG montre ses limites ?

Le RAG montre ses limites quand la connaissance a une structure logique forte et que le découpage en chunks casse les relations entre les idées. Le RAG, pour Retrieval Augmented Generation, reste excellent quand on veut interroger de gros volumes de contenu non structuré. Des PDF, des articles, des tickets support, des comptes rendus, des documents qui partent un peu dans tous les sens.

Son principe est simple. On découpe les documents en petits morceaux, on transforme ces morceaux en embeddings, c’est-à-dire en représentations numériques du sens, puis on cherche les passages les plus proches de la question. Ça marche très bien quand la réponse est dans un passage précis.

Le problème arrive avec les agents IA. Un agent ne cherche pas juste une phrase. Il doit souvent appliquer une logique métier, suivre une procédure, respecter une politique interne, comprendre une dépendance entre plusieurs étapes. Et là, si la connaissance est éclatée en fragments, le modèle doit reconstruire le contexte à chaque requête.

Prenez une politique d’admission hospitalière. Le triage initial, le dossier patient électronique et l’allocation des lits ne sont pas trois sujets isolés. Ils sont liés. Une décision au triage peut dépendre des informations déjà présentes dans le dossier patient, et cette décision peut ensuite influencer la priorité d’attribution d’un lit. Avec un RAG classique, ces éléments peuvent se retrouver dans trois chunks différents. L’agent récupère parfois deux morceaux sur trois, parfois le mauvais passage, parfois un extrait sans la règle qui donne vraiment le sens.

J’ai vu le même souci chez des clients. Le problème ne venait pas forcément du modèle. Il venait de la façon dont on lui servait la connaissance. On lui donnait des morceaux corrects, mais pas la structure qui expliquait comment ces morceaux s’articulaient.

Le coût pratique est assez clair : réponses moins fiables, relations implicites perdues, logique métier à reconstruire en permanence. Et plus l’agent prend des décisions sensibles, plus ce bricolage devient risqué.

Forces du RAG	Limites avec une connaissance organisée
Très utile pour chercher dans de gros volumes de documents non structurés.	Le découpage en chunks peut casser les liens entre procédures, règles et exceptions.
Rapide à mettre en place avec des PDF, tickets, articles ou bases documentaires.	Le modèle doit reconstruire le contexte à chaque demande.
Efficace quand la réponse se trouve dans un passage précis.	Moins fiable quand la réponse dépend d’une logique métier complète.

C’est quoi OKF exactement ?

On sort ici du réflexe classique du RAG. Le sujet n’est plus seulement de découper un document en morceaux plus propres, puis d’espérer que l’agent retrouve le bon passage. OKF part d’une autre idée : garder la structure de la connaissance au lieu de la perdre dès l’ingestion.

OKF, pour Open Knowledge Format, est une spécification ouverte pensée pour organiser et échanger des connaissances utilisables par des agents IA. Google a annoncé cette spécification en juin 2026, pas comme un SDK, pas comme un produit fermé, pas comme une nouvelle base vectorielle magique. Plutôt comme une manière de standardiser la forme des données que les agents doivent lire, comprendre, relier et réutiliser.

Le principe reste assez simple, et c’est justement ce qui le rend intéressant. On parle de fichiers Markdown lisibles par des humains, de métadonnées YAML légères, et de liens explicites entre concepts. YAML, c’est un petit format texte souvent utilisé pour décrire des métadonnées, par exemple un titre, une source, une relation. Rien de mystique. C’est fait pour être lu sans avoir besoin d’un parseur mental.

Voici un exemple illustratif minimal, pas une spécification complète OKF :

---
titre: Politique de remboursement
source: Centre d’aide
liens:
  - Conditions générales
  - Délais de traitement
---

La politique de remboursement décrit les cas où un client peut demander un remboursement.

Elle est liée aux conditions générales et aux délais de traitement.

L’intérêt, c’est que l’agent ne voit pas juste un bloc de texte isolé. Il voit une connaissance située, reliée à d’autres connaissances. C’est très proche de l’intuition qu’on voyait déjà dans les communautés autour des LLM Wiki, ces wikis pensés pour être lus autant par des humains que par des modèles de langage. On retrouve aussi une logique à la Obsidian, ou même un IDE de connaissances. Un IDE, c’est l’environnement dans lequel un développeur navigue dans du code. Ici, on navigue dans des idées.

J’ai vu ce problème chez un client avec une documentation interne énorme. Le RAG retrouvait souvent le bon paragraphe, mais il ratait le contexte autour. OKF ne cherche pas à mieux chunker. Il cherche à éviter que la connaissance soit aplatie dès le départ.

Pourquoi OKF aide les agents IA ?

OKF aide les agents IA parce qu’il leur donne une carte de la connaissance, pas juste un tas de fragments à deviner. C’est une grosse différence. Avec un RAG classique, l’agent cherche des morceaux de texte qui “ressemblent” à la question. Avec OKF, il peut suivre des liens explicites entre des concepts, comme on suivrait un plan dans un système bien rangé.

Un agent peut partir d’une procédure, voir qu’elle dépend d’une politique interne, puis suivre un lien vers un runbook, c’est-à-dire une fiche opérationnelle qui explique quoi faire en cas de problème, puis remonter vers une définition métier. Ce n’est pas seulement de la proximité sémantique. C’est une relation posée à l’avance. Et ça change tout quand on veut des réponses fiables.

Je le vois souvent chez des clients avec des bases internes pleines de documents RH, sécurité, finance, support. Le RAG retrouve parfois le bon passage, parfois un passage “pas loin”. Le problème, c’est que “pas loin” peut coûter cher quand l’agent doit appliquer une règle, escalader un incident ou répondre à un client.

Recherche vectorielle classique	OKF
L’agent récupère des passages proches du sens de la question.	L’agent navigue dans des concepts reliés entre eux.
Les relations sont souvent reconstruites au moment de la réponse.	Les relations existent déjà dans les fichiers.
Le contrôle humain est possible, mais moins naturel.	La relecture, l’audit et l’historique sont intégrés au travail documentaire.

Le côté très intéressant d’OKF, c’est aussi le versioning. Comme le format repose sur des fichiers texte, souvent en Markdown pour le contenu et en YAML pour les métadonnées, on peut utiliser Git ou des outils proches. Git permet de suivre chaque changement dans le temps. Qui a modifié une règle. Quand. Pourquoi. Ce qui a été supprimé. Ce qui a été validé.

En entreprise, c’est précieux. On peut auditer, relire, corriger, améliorer progressivement. On n’est pas dans une boîte noire où tout dépend d’un index vectoriel généré à un instant donné.

Ce n’est pas magique non plus. Il faut structurer les connaissances, nommer les concepts proprement, maintenir les liens. C’est du travail. Mais pour des politiques internes, des procédures, des runbooks ou des connaissances business très connectées, cet effort est souvent plus rentable qu’un pipeline RAG qui essaie de reconstruire le contexte à chaque question.

Faut-il choisir entre OKF et RAG ?

Je ne choisirais pas entre OKF et RAG par principe. Dans la vraie vie, les deux peuvent très bien cohabiter. Le RAG, Retrieval Augmented Generation, sert à retrouver des documents ou des passages pertinents avant de faire répondre un modèle IA. C’est très fort quand la connaissance est énorme, désordonnée, mouvante, ou franchement impossible à modéliser proprement à la main.

Je pense aux archives documentaires, aux tickets support, aux articles internes, aux PDF fournisseurs, aux bases Notion ou SharePoint qui vivent leur vie depuis cinq ans. Dans ces cas-là, vouloir tout transformer en structure propre dès le départ, c’est souvent se raconter une histoire. J’ai vu des équipes passer des semaines à vouloir “nettoyer la connaissance” avant même d’avoir un premier agent utile. Mauvais réflexe.

Là où OKF prend le relais, c’est quand l’erreur coûte cher. Par OKF, je parle d’un cadre de connaissance structuré, avec des concepts validés, des règles, des relations claires entre les objets métier. C’est utile pour les procédures critiques, les règles internes, les runbooks, la documentation métier très reliée, les validations de conformité, ou les chemins de décision qu’un agent ne doit pas improviser.

Une architecture hybride me paraît souvent plus saine :

• Le RAG retrouve les documents bruts, même s’ils sont longs, nombreux, imparfaits ou récents.
• L’OKF représente les concepts validés, les liens importants, les règles métier et les décisions qui ne doivent pas bouger tous les matins.
• L’agent utilise les deux, avec le RAG pour explorer et l’OKF pour raisonner sur une base plus fiable.

Je commencerais simple. J’identifierais d’abord les connaissances où une mauvaise réponse crée un vrai problème : perte financière, erreur client, incident technique, non-conformité. Puis je les structurerais en OKF. Sans jeter le RAG existant. Il reste précieux pour couvrir tout ce qui est trop large, trop vivant, ou pas encore stabilisé.

Type de connaissance	Meilleur choix	Raison
Archives, PDF, articles, tickets support	RAG	Le volume est élevé et la structure change souvent.
Procédures critiques et règles internes	OKF	La précision compte plus que la couverture large.
Documentation métier reliée	OKF	Les liens entre concepts doivent être explicites.
Base de contenu diverse et mouvante	RAG	Il faut retrouver vite sans tout modéliser.
Système agentique sérieux	RAG + OKF	Le RAG apporte la matière, l’OKF apporte le cadre fiable.

Alors, OKF vaut-il vraiment le coup pour vos agents IA ?

OKF vaut le coup si votre problème n’est pas seulement de retrouver du texte, mais de préserver la logique entre vos connaissances. Le RAG reste très solide pour explorer de gros corpus non structurés. Mais quand on parle de procédures, politiques internes, runbooks ou règles business reliées entre elles, OKF apporte quelque chose de plus propre : des fichiers lisibles, des métadonnées légères, des liens explicites et du versioning. Je ne le vois pas comme un remplaçant universel du RAG. Je le vois comme une couche de connaissance structurée, plus fiable pour les agents IA. Le bénéfice pour vous : moins de contexte reconstruit à l’aveugle, plus de réponses pilotables.

FAQ

• OKF veut dire quoi ?
  OKF veut dire Open Knowledge Format. C’est une spécification ouverte annoncée par Google en juin 2026 pour organiser des connaissances destinées aux agents IA, avec des fichiers Markdown, des métadonnées YAML légères et des liens explicites entre concepts.
• Quelle est la différence entre OKF et RAG ?
  Le RAG retrouve des fragments pertinents dans de grands corpus grâce aux embeddings. OKF structure la connaissance dès le départ, avec des relations explicites entre les concepts. En clair, le RAG cherche dans des morceaux, OKF aide l’agent à naviguer dans une connaissance organisée.
• OKF remplace-t-il le RAG ?
  Pas vraiment. OKF est plus adapté aux connaissances internes structurées et interconnectées, comme les politiques, procédures ou runbooks. Le RAG reste très utile pour exploiter des masses de documents non structurés, comme des PDF, tickets, articles ou archives.
• Pourquoi le chunking pose problème aux agents IA ?
  Le chunking découpe les documents en fragments pour les indexer. C’est pratique pour la recherche, mais ça peut casser la logique interne d’un document. Un agent IA doit alors reconstruire les liens entre les morceaux, ce qui peut créer des pertes de contexte ou des réponses moins fiables.
• Dans quels cas OKF est-il le plus utile ?
  OKF est surtout utile quand votre connaissance est stable, critique et très reliée : procédures internes, règles métier, politiques d’entreprise, runbooks, documentation organisationnelle. C’est là que les liens explicites et le versioning deviennent vraiment intéressants.

 

 

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 connaissances et leurs workflows vraiment exploitables par des humains et par des agents IA. Avec webAnalyste et Formations Analytics, j’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos données, vos bases de connaissance ou vos automatisations IA, contactez-moi.