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

OKF complète plutôt le RAG qu’il ne le remplace. Là où le RAG retrouve des morceaux d’information, OKF aide un agent IA à naviguer dans une connaissance structurée, liée, versionnable. La vraie question, c’est où mettre chaque approche sans créer une usine à gaz.

Pourquoi le RAG bloque parfois ?

Le RAG, pour Retrieval Augmented Generation, marche très bien quand votre agent IA doit retrouver une information dans une grosse masse de documents. C’est même souvent le meilleur réflexe au départ. J’ai vu des bases documentaires énormes devenir enfin exploitables avec ça. Des PDF, des comptes rendus, des pages Notion, des mails, des procédures dispersées un peu partout.

Le pipeline classique est assez simple. On découpe les documents en morceaux, souvent appelés chunks. On transforme chaque morceau en embedding, c’est-à-dire une représentation numérique du sens du texte. On stocke ces embeddings dans une base vectorielle. Quand l’utilisateur pose une question, on transforme aussi sa question en embedding, puis on cherche les passages les plus proches. Le modèle IA récupère ces passages et génère une réponse.

Sur du contenu non structuré, ça fait très bien le job. Si vous demandez “Qu’est-ce que notre politique de télétravail dit sur les jours autorisés ?”, le RAG retrouve les bons paragraphes et le modèle reformule proprement. Le problème commence quand la connaissance n’est pas juste du texte à retrouver, mais une logique à respecter.

Je le vois souvent chez les clients sur des procédures, des politiques internes, des règles métier ou des protocoles. Le souci n’est pas le RAG en lui-même. Le vrai problème, c’est le découpage qui casse le raisonnement.

• Une condition peut être dans un chunk.
• Une exception peut être dans un autre chunk.
• Une métrique ou un seuil peut se retrouver encore ailleurs.
• Et l’agent IA doit reconstruire la logique avec seulement quelques morceaux récupérés.

Prenons un protocole d’admission hospitalier. Un passage dit qu’un patient doit être admis si sa saturation en oxygène passe sous un certain seuil. Un autre passage précise que ce seuil change pour les patients atteints d’une pathologie respiratoire chronique. Un troisième passage ajoute une exception si le patient est déjà sous oxygène à domicile. Si ces trois éléments sont séparés, le RAG peut récupérer deux morceaux sur trois. Et là, la réponse peut être plausible, mais incomplète. C’est le pire cas en business comme en santé.

C’est là que l’OKF devient intéressant. J’entends par OKF une façon d’organiser la connaissance avant de la donner à l’agent IA, avec des objets, des règles, des relations et du contexte explicite. Pas juste des passages similaires. Une connaissance préparée pour raisonner, pas seulement pour retrouver du texte.

Qu’est-ce que OKF change ?

OKF change surtout le point de départ. Au lieu de traiter la connaissance comme une grosse pile de morceaux de texte à retrouver au bon moment, on la traite comme un réseau de concepts reliés entre eux. C’est une différence simple, mais elle change beaucoup de choses pour un agent IA en business.

Open Knowledge Format, ou OKF, est une spécification ouverte proposée pour organiser et échanger des connaissances destinées aux agents IA. L’idée n’est pas de créer une nouvelle base de données compliquée. L’idée, c’est plutôt d’utiliser des fichiers simples, souvent en Markdown, avec quelques métadonnées YAML au début du fichier, puis des liens entre concepts.

Concrètement, ça peut ressembler à ça :

---
type: concept
owner: sales
updated: 2026-01-12
tags: [pricing, enterprise, negotiation]
---

# Remise entreprise

Une remise entreprise peut être proposée si le client signe un engagement annuel.

Voir aussi : [[Politique de pricing]] [[Process de validation commerciale]]

Si vous utilisez Obsidian, vous voyez vite l’idée. Chaque note contient un concept, et les liens créent une carte de connaissance. Pour un développeur, on pourrait aussi comparer ça à un IDE, un environnement de développement, mais appliqué à la connaissance d’un agent IA. L’agent ne pioche plus juste dans des bouts de documents. Il navigue dans un espace structuré, avec des relations explicites.

C’est assez proche de l’idée de LLM Wiki popularisée par Andrej Karpathy. Sans en faire une religion, l’intuition est bonne : Un agent IA a besoin d’une connaissance lisible, reliée, modifiable, pas seulement d’un moteur de recherche collé à un modèle.

Ce format rend aussi Git très naturel. Git, c’est un système de versionnage qui garde l’historique des modifications. Comme les connaissances sont dans des fichiers texte simples, on peut suivre qui a changé quoi, revenir en arrière, relire une modification, faire une revue avant publication.

• Les fichiers Markdown restent lisibles par un humain.
• Les métadonnées YAML donnent du contexte sans alourdir le contenu.
• Les liens entre concepts aident l’agent à comprendre les dépendances.
• Le versionnage rend la connaissance auditable et maintenable.

Sur le terrain, c’est souvent là que ça se joue. Une connaissance IA utile n’est pas seulement une connaissance que le modèle peut lire. C’est une connaissance que les équipes peuvent maintenir sans appeler un data engineer à chaque virgule. Sinon, le système marche trois semaines, puis il devient faux, personne n’ose le toucher, et l’agent commence à raconter n’importe quoi avec beaucoup d’assurance.

Comment structurer une base OKF ?

Dans une base OKF, je cherche surtout une chose : que l’agent IA comprenne vite de quoi on parle, avec quoi c’est lié, et dans quel contexte il peut s’en servir. L’OKF, pour Object Knowledge Format, peut être vu comme un petit graphe de connaissances lisible par des humains, souvent stocké dans des fichiers Markdown simples.

Une structure de dossier typique ressemble à ça. Rien de sacré, juste une façon propre de ranger les concepts.

/okf-bundle/
  /concepts/
    procedure-admission-urgence.md
    metric-delai-prise-en-charge.md
  /policies/
    confidentialite-donnees-patient.md
  manifest.yaml
  version.txt

Chaque fichier Markdown décrit un concept. En haut, je mets un bloc YAML, ce qu’on appelle le front matter. YAML, c’est un format très lisible pour décrire des métadonnées sous forme clé-valeur. Puis sous ce bloc, je mets une explication courte, utile, pas un roman.

---
id: PROC-HOSP-001
title: Procédure d’admission aux urgences
type: procedure
tags:
  - hopital
  - urgences
  - admission
relations:
  depends_on:
    - POLICY-DATA-001
  measured_by:
    - METRIC-HOSP-001
---

Cette procédure décrit les étapes minimales pour accueillir un patient aux urgences, vérifier son identité, créer son dossier administratif et déclencher le tri médical.

Concepts liés : [[confidentialite-donnees-patient]], [[metric-delai-prise-en-charge]]

Le point important, c’est que l’agent IA n’a pas seulement un texte à lire. Il a un identifiant stable, un type, des tags, et des relations. Dans un projet client, c’est souvent ce qui manque dans les bases documentaires classiques. Les documents existent, mais l’IA ne sait pas ce qui est central, ce qui dépend de quoi, ni quelle métrique surveiller.

Voici un concept de métrique lié à la procédure précédente.

---
id: METRIC-HOSP-001
title: Délai moyen de prise en charge aux urgences
type: metric
tags:
  - hopital
  - performance
  - urgences
relations:
  measures:
    - PROC-HOSP-001
---

Cette métrique mesure le temps moyen entre l’arrivée administrative du patient et le premier contact avec un professionnel de santé.

Avec ce format, l’agent peut répondre à une question métier, mais aussi naviguer dans le contexte. Il peut voir qu’une procédure est mesurée par une métrique, qu’elle dépend d’une politique de confidentialité, et qu’elle appartient au domaine urgences.

Élément	Rôle pour un agent IA
Fichier Markdown	Contient le contenu lisible du concept, avec une description claire et exploitable.
Métadonnées YAML	Donnent à l’agent des repères stables comme l’identifiant, le type, les tags et les relations.
Liens entre concepts	Permettent de naviguer entre procédures, règles, métriques et dépendances métier.
Versionnage	Aide à savoir quelle version de la connaissance est utilisée, surtout en contexte réglementé.

Comment les agents utilisent OKF et RAG ?

Un agent IA n’a pas besoin de chercher partout de la même manière. Quand la connaissance est critique, stable, validée, j’aime bien la mettre dans un OKF, c’est-à-dire un cadre de connaissance organisé avec des concepts, des règles, des liens et des métadonnées. Quand la connaissance est massive, floue, historique ou mal rangée, le RAG reste très utile. Le RAG, pour Retrieval Augmented Generation, consiste à chercher des passages dans des documents puis à les donner au modèle pour qu’il réponde.

Avec OKF, l’agent part souvent d’un concept. Par exemple “remboursement client”. Il lit ses métadonnées : définition officielle, propriétaire métier, version, niveau de confiance, date de mise à jour, règles applicables. Puis il suit les liens vers des concepts liés comme “avoir”, “délai légal”, “client premium”, “exception commerciale”. Là, il ne récupère pas juste des bouts de texte. Il récupère le contexte logique.

C’est ce qui change beaucoup de choses. L’agent comprend mieux pourquoi une réponse est valide. Il peut dire “dans ce cas, la règle A s’applique, sauf si la condition B est vraie”. Pour les procédures, les définitions, les politiques internes, les offres, les règles métier, c’est souvent plus propre qu’un RAG brut. J’ai vu ça chez un client où le chatbot répondait correctement au hasard sur les règles RH. Le problème n’était pas le modèle. Le problème, c’était que les règles étaient perdues dans 80 PDF contradictoires.

Le RAG garde sa place dès qu’on parle de volumes nombreux, hétérogènes et pas vraiment curatés. Archives, comptes rendus, contrats anciens, tickets support, documentation technique longue, emails exportés. Là, structurer tout ça en OKF coûterait trop cher ou prendrait trop de temps.

Une architecture simple marche souvent mieux qu’un débat théorique :

• OKF pour les connaissances critiques : Procédures, définitions, règles métier, référentiels, décisions validées.
• RAG pour les grands fonds documentaires : Archives, contenus historiques, documents longs, bases non structurées.
• Agent IA au milieu : Il vérifie d’abord l’OKF, puis interroge le RAG si le contexte manque ou si la question demande une preuve documentaire.

Dans une vraie entreprise, le bon choix est rarement tout OKF ou tout RAG. On mélange les deux, parce que tout n’a pas la même valeur, la même fraîcheur, ni le même niveau de risque.

Approche	Usage idéal	Forces	Limites
OKF	Connaissances critiques, règles métier, procédures, définitions validées.	Réponses plus cohérentes, contexte logique, meilleure traçabilité.	Demande un travail de structuration et de gouvernance.
RAG	Documents nombreux, archives, contenus longs, bases peu organisées.	Rapide à déployer sur de gros volumes, flexible, bon pour explorer.	Moins fiable si les sources sont contradictoires ou mal qualifiées.

Alors on choisit OKF ou RAG ?

Je ne choisirais pas OKF contre RAG. Je choisirais OKF quand la connaissance doit rester lisible, reliée, versionnée et exploitable proprement par un agent IA. Je garderais le RAG quand il faut chercher vite dans un gros stock de documents non structurés. Le vrai sujet, c’est l’architecture de connaissance. Si vos procédures, règles et définitions sont découpées en morceaux sans logique, l’agent va bricoler. Avec OKF, vous lui donnez une carte. Avec RAG, vous lui donnez un moteur de recherche. Bien combinés, vous gagnez en fiabilité, en maintenance et en qualité de réponse.

FAQ

• Qu’est-ce que OKF pour les agents IA ?
  OKF, pour Open Knowledge Format, est une manière ouverte d’organiser la connaissance pour les 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 lisible, structurée et navigable.
• OKF remplace-t-il vraiment le RAG ?
  OKF ne remplace pas totalement le RAG. Il répond à un autre problème. Le RAG est très utile pour retrouver des informations dans de grands ensembles de documents non structurés. OKF est plus adapté quand la connaissance a des relations fortes, comme des procédures, politiques, règles métier ou définitions liées.
• Pourquoi le découpage en chunks peut poser problème ?
  Le chunking peut séparer des informations qui devraient rester ensemble. Une règle, son exception et sa condition peuvent finir dans trois morceaux différents. Pour une recherche simple, ça passe souvent. Pour un agent IA qui doit raisonner sur une procédure complète, ça peut créer des réponses incomplètes ou fragiles.
• Quels contenus mettre dans OKF ?
  Je mettrais dans OKF les connaissances critiques et structurées : procédures internes, règles métier, définitions, politiques, métriques, concepts produits, processus opérationnels. Tout ce qui doit être maintenu, relié et compris dans son contexte mérite mieux qu’un simple découpage en fragments.
• Quelle est la meilleure architecture entre OKF et RAG ?
  La meilleure architecture est souvent hybride. OKF sert de colonne vertébrale pour la connaissance fiable et structurée. RAG sert de couche de recherche sur les gros volumes de documents moins organisés. C’est cette combinaison qui donne aux agents IA à la fois du contexte, de la profondeur et de la souplesse.

 

 

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 contenus et leurs automatisations vraiment exploitables, pas juste plus complexes. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos connaissances, vos données ou vos agents IA proprement, contactez-moi.