Au-delà d’une seule voie de récupération : connaissances canoniques, RAG et requêtes en temps réel pour les agents d’entreprise

Un titre affirmant qu’un nouveau format ouvert remplace la base de données vectorielle suscite le scepticisme. Ce qui mérite d’être retenu dans cette affirmation n’est pas l’idée du remplacement, mais plutôt une question architecturale plus pertinente : est-il judicieux d’imposer un même mécanisme de recherche à un trop grand nombre de types différents de connaissances d’entreprise ?

Dans une entreprise, le terme « connaissance » englobe des choses très variées. Un ticket de support compte, tout comme un document de conception de 60 pages, un schéma de base de données, une définition de métrique ou un manuel de gestion d’incidents. Le nombre actuel de livraisons retardées compte également. Ces éléments se comportent différemment, il est donc étrange qu’un agent d’IA puisse s’y référer de la même manière.

Le cadre pertinent n’est pas celui qui oppose OKF à RAG, et ce n’est pas non plus que les bases de données vectorielles soient mortes. Il s’agit plutôt d’une triage pratique en trois catégories : les connaissances à récupérer, celles à conserver en version canonique, et celles à interroger en temps réel.

Un problème d’entreprise ordinaire

Imaginons une entreprise fictive de logistique SaaS comptant une centaine vingt ingénieurs. Comme de nombreuses entreprises expérimentant avec des agents, elle a relié ses documents internes, ses workflows de support, ses systèmes opérationnels, ses indicateurs et ses guides opérationnels à une plateforme d’agents. Pour la plupart des questions, cela fonctionne très bien.

Puis quelqu’un demande le taux de livraison à temps, et le système affiche trois définitions différentes :

• L’équipe des données compte les livraisons qui arrivent à la date promise.
• Le tableau de bord produit utilise un calcul légèrement différent.
• La documentation destinée aux clients omet les commandes annulées et les retours.

Aucun de ces éléments n’est absurde. D’équipes différentes les ont rédigés pour des raisons variées. Les problèmes commencent lorsque l’agent doit déterminer lequel d’entre eux est officiel. Une base de données vectorielle peut indiquer ce qui est sémantiquement proche, mais elle ne sait pas quelle version l’entreprise a déclarée comme définition officielle. C’est un problème distinct.

La pertinence n’est pas l’autorité

Un flux RAG standard renvoie tous les documents qui correspondent. Si trois documents décrivent une même métrique de trois manières différentes, tous trois sont affichés. Une meilleure classification, des métadonnées supplémentaires, un réclassement, un plus grand top_k ou une fenêtre de contexte plus large peuvent tous être utiles. Aucun de ces éléments ne répond à la question organisationnelle concernant la définition officielle.

Ainsi, la véritable faiblesse n’est pas simplement le fait que RAG génère des hallucinations. La pertinence et l’autorité sont des propriétés différentes, et les agents d’entreprise ont de plus en plus besoin des deux.

Lorsque la structure est le sens

Une autre raison pour laquelle toutes les connaissances ne conviennent pas à un seul mécanisme de récupération concerne leur forme. Prenons un tableau à dix lignes et sept colonnes : son sens ne réside pas uniquement dans les mots, mais dans la manière dont les en-têtes, les étiquettes des lignes, les valeurs, les unités et le contexte environnant sont liés les uns aux autres.

Si l’on divise ce tableau en blocs de 256 tokens, un fragment pourrait ne contenir qu’un couple d’en-têtes, par exemple « région » et « revenus », tandis qu’un autre contiendrait « Est : 2,1 M » et « Ouest : 1,8 M ». Le modèle peut reconstruire correctement ces relations, ou il peut ne pas y parvenir.

Pour le texte en prose, le découpage en blocs est généralement souhaité. Pour les connaissances structurées, cela devient un détour étrange :

1. commencer par la structure
2. la transformer en texte
3. diviser le texte en fragments
4. incorporer ces fragments
5. récupérer un petit nombre d’entre eux
6. demander au modèle de reconstruire la structure originale

À un certain moment, la question se pose de savoir si cet élément aurait dû être fragmenté dès le départ. Il en va de même pour les schémas de base de données, les chemins de jointure, les règles de configuration, les formules de métriques, les SLA et les procédures opérationnelles. Le contenu structuré n’est pas interdit dans RAG. L’important est que la structure mérite un traitement particulier lorsque sa perte modifie le sens.

La base de données vectorielle n’a jamais été la source de vérité

La société fictive rencontrait un autre problème familier : les connaissances étaient dispersées. Les schémas étaient décrits dans des commentaires de base de données, des wikis GitHub, Confluence et des fichiers de migration. Les définitions de métriques se trouvaient dans des tableaux de bord analytiques, des spécifications de produits, des documents de l’équipe de données et d’anciens diapositives. Les guides opérationnels étaient répartis sur Notion, des tickets d’incidents, Slack et GitHub. Une partie de la logique de jointure résidait principalement dans la tête de celui qui avait travaillé le plus longtemps sur le projet.

La création d’une base de données vectorielle à partir de cela n’a pas produit une source de vérité. Elle a plutôt généré un index permettant de rechercher les incohérences existantes. Cela a de la valeur, mais ce n’est pas une gouvernance.

Ce que l’OKF apporte

Ce qui distingue le format Open Knowledge, ce n’est pas Markdown, qui existe déjà. C’est l’idée de rendre les connaissances d’entreprise explicitement lisible par des machines tout en les rendant agréables à utiliser pour les humains. En théorie, un fichier de concept commence par des métadonnées structurées :

type: metric
name: on_time_delivery_rate
owner: data-platform
reviewer: product
trust_tier: verified
stale_after: 1 day
related:
- shipments
- sla_definition

et se poursuit par une explication écrite pour le grand public :

# On-Time Delivery Rate
Percentage of shipments delivered on or before the current
promised delivery date.
## Excludes
- cancelled shipments
- test orders
- returns

L’agent ne reçoit plus simplement un texte concernant la livraison à temps. Il peut également apprendre à qui appartient la définition, si elle est à jour, si elle a été vérifiée, de quoi elle dépend et quels autres concepts y sont liés. La question passe de savoir quel fragment ressemble le plus à quel concept canonique et s’il est sûr de l’utiliser.

OKF ne remplace pas RAG

Ici, la conclusion diffère du titre. Une image plus précise est celle d’une progression : les connaissances canoniques se trouvent dans OKF, les connaissances exploratoires dans RAG, et l’état actuel dans les systèmes en temps réel.

Les connaissances canoniques englobent les schémas de base de données, les définitions de métriques, les SLA, les règles métier, les guides opérationnels et les informations relatives aux responsabilités. La question qui se pose à leur sujet concerne généralement quelle est la définition officielle et à jour.

Connaissances exploratoires : il s’agit de rapports historiques, d’un historique des incidents, de conversations de support, de documents de conception, d’études de cas et de retours clients. La question qui se pose est de savoir quelles informations sont pertinentes pour ce qui est recherché. C’est précisément là que RAG excelle.

État en temps réel : il comprend le taux de ponctualité actuel, le solde actuel du client, les incidents en cours, les commandes ouvertes et les niveaux d’inventaire. La question est de savoir quelle est la situation en ce moment même, et un index vectoriel n’est probablement pas le bon outil pour y répondre. Le système opérationnel qui détient ces chiffres doit les fournir.

Certains données ne doivent pas être récupérées

C’est ici que l’architecture devient plus intéressante. Supposons qu’un utilisateur demande les cinq meilleurs clients en termes de chiffre d’affaires ce trimestre. Une approche consiste à récupérer des documents et des données dans l’index pour permettre au modèle de les trier. Cela est possible, mais il existe un flux plus efficace : l’agent cherche la définition canonique de « chiffre d’affaires », construit une requête et la lance sur le système de base de données. Par exemple :

SELECT
customer_name,
SUM(revenue) AS total_revenue
FROM sales_data
WHERE quarter = 'Q3_2026'
GROUP BY customer_name
ORDER BY total_revenue DESC
LIMIT 5;

L’agent reçoit désormais deux éléments provenant de deux sources. La signification provient de la couche de connaissances canonique, tandis que les valeurs actuelles proviennent du système qui détient réellement les données. L’agent ne récupère plus de données brutes ; il obtient d’abord la structure, puis interroge le système en temps réel.

Un agent, trois chemins de connaissance

Avec cette distinction en tête, certaines questions d’exemple sont traitées différemment :

• Que signifie une livraison à temps ? Consultez la définition canonique de la métrique.
• Quel est le taux de livraison à temps aujourd’hui ? Utilisez la logique de calcul de la définition canonique, puis interrogez l’entrepôt en temps réel.
• Pourquoi le taux a-t-il baissé au dernier trimestre ? Associez la définition canonique aux données historiques de l’entrepôt, ainsi qu’éventuellement à des informations provenant de rapports d’incidents et de notes des transporteurs.

Que s’est-il passé avec le client X au premier trimestre ? Faites une recherche parmi les tickets, notes et rapports antérieurs.

Il y a une panne de la base de données, que faire maintenant ? Utilisez le manuel de procédures officiel.

L’agent reste le même, mais les chemins diffèrent. C’est un sujet plus productif à aborder que la question de savoir si les bases de données vectorielles vont être remplacées.

Le routeur passe au centre

Avec plusieurs chemins de connaissance, il faut bien que quelque chose choisisse parmi eux. Un premier routeur peut être délibérément simple.

class HybridKnowledgeRouter:
    def __init__(self, okf, rag):
        self.okf = okf
        self.rag = rag

    def classify(self, query: str) -> str:
        q = query.lower()

        if any(word in q for word in [
            "schema", "column", "definition",
            "metric", "sla", "runbook"
        ]):
            return "canonical"

        if any(word in q for word in [
            "history", "report", "example",
            "case study", "what happened"
        ]):
            return "exploratory"

        if any(word in q for word in [
            "today", "current", "now",
            "latest value", "how many"
        ]):
            return "live"

        return "hybrid"

Sa méthode contexte suit :

def get_context(self, query: str):
    query_type = self.classify(query)

    if query_type == "canonical":
        return self.okf.lookup(query)

    if query_type == "exploratory":
        return self.rag.search(query)

    if query_type == "live":
        concept = self.okf.lookup_relevant_schema(query)
        return {
            "concept": concept,
            "requires_live_query": True
        }

    return {
        "okf": self.okf.search(query),
        "rag": self.rag.search(query)
    }

Il ne s’agit pas d’une classification de niveau production, ce qui est acceptable. Le premier objectif est simplement de déterminer si cette séparation est utile.

Pourquoi pas simplement BM25 ou des métadonnées encore meilleures ?

Avant d’ajouter un autre mécanisme, cette idée mérite d’être sérieusement mise à l’épreuve.

BM25. Pour le texte structuré, il peut être excellent. Les noms de champs exacts sont importants, les mots-clés le sont également, et un classement déterministe est utile. Pour les requêtes de type schéma, il peut surpasser les embeddings. Cependant, il ne modifie pas l’architecture de base. Une table placée dans un index de recherche doit toujours être représentée et récupérée d’une manière ou d’une autre, et le résultat sont de meilleurs fragments, qui restent des fragments. BM25 améliore la récupération des informations. Il ne crée ni autorité, ni propriété, ni fraîcheur, ni sémantique canonique.

Plus de métadonnées RAG. Cela est également raisonnable. Des champs tels que ceux ci-dessous peuvent être associés, avec un filtrage strict en plus :

document_type
owner
version
effective_date
trust_tier
source

Cela peut suffire pour de nombreux systèmes. Mais dès que les métadonnées deviennent le mécanisme qui indique à l’agent ce qui est fiable, à jour, pertinent et sûr, une couche de connaissances structurée est déjà en cours de création. À ce stade, formuler le concept directement est plus clair que de le conserver sous forme de document atypique enfoui dans un index polyvalent.

Les requêtes en temps réel posent un problème de sécurité

Dès qu’un LLM est autorisé à formuler des requêtes auprès de systèmes opérationnels, les enjeux augmentent considérablement. Personne ne souhaite cela :

DROP TABLE shipments;

Même pas ça :

SELECT * FROM shipments;

Exécuter une requête sur un tableau de 50 millions de lignes simplement parce que le modèle est devenu curieux. La meilleure approche consiste à ne pas donner à l’agent d’accès à la base de données, mais plutôt à lui fournir une capacité de requête restreinte. Un concept de schéma peut décrire la forme autorisée d’une requête :

data_source: analytics.shipments
allowed_columns:
  - shipment_id
  - customer_id
  - carrier_id
  - status
  - promised_delivery_date
  - actual_delivery_date

required_filters:
  - tenant_id

max_result_rows: 1000
access_mode: read_only

La requête générée est ensuite validée par rapport à cette politique :

def validate_query(query, policy):
    checks = [
        uses_allowed_table(query, policy),
        selects_allowed_columns(query, policy),
        contains_required_filters(query, policy),
        respects_row_limit(query, policy),
        is_read_only(query),
    ]

    if not all(checks):
        raise UnsafeQueryError()

    return True

Dans un environnement de production, d’autres mesures s’imposent : des identifiants d’exécution séparés, une isolation des utilisateurs assurée en dehors du modèle, des permissions au niveau de la base de données, des limites par ligne et par coût, ainsi que l’enregistrement de chaque requête exécutée. Le principe directeur est que le modèle propose des actions et que l’infrastructure décide si cette proposition peut être mise en œuvre.

Le savoir canonique a besoin d’un responsable

Une source unique de vérité semble idéale tant que personne ne la met à jour. La responsabilité et la fraîcheur des informations sont plus importantes que le format du fichier. Un concept peut contenir des champs tels que ceux-ci :

owner: data-platform@company.io
reviewer: product-analytics@company.io
stale_after: 7 days

Lorsque la définition d’une métrique est modifiée, la mise à jour des connaissances correspondante doit faire partie du même document. Lorsqu’un schéma change, sa forme canonique doit être régénérée ou révisée. Les utilisateurs ne doivent pas réécrire ce que la base de données connaît déjà, c’est pourquoi des faits connus par la machine sont générés :

for table in database.tables():
  generated = generate_okf_schema(table)
  save(generated)

Les humains examinent ensuite ce qui nécessite un jugement : la signification commerciale, la propriété, les colonnes sensibles, les utilisations autorisées, les relations et les réserves. En omettant cela, la source unique de vérité se transforme en un autre répertoire devenu obsolète.

La versionning est plus importante qu’il n’y paraît

Le caractère canonique ne signifie pas être intemporel. Imaginez que l’entreprise change la définition de la livraison à temps de « livraisons à temps divisées par le total des commandes » en « livraisons à temps divisées par le total des livraisons effectuées ». Si l’ancienne définition est simplement écrasée, un agent répondant à une question historique pourrait appliquer la logique d’aujourd’hui au rapport de l’année dernière. Les concepts nécessitent donc des versions ou des dates d’effet :

versions:
  - version: "2.0"
    active: true
    effective_from: 2026-06-10
    change: "Denominator changed to delivered shipments"

  - version: "1.0"
    active: false
    effective_from: 2025-01-01
    effective_to: 2026-06-09

Deux questions reçoivent désormais des réponses différentes. Une question concernant la définition de OTD utilise la version actuelle, tandis qu’une question sur le fait pour lequel le rapport du premier trimestre 2026 l’a calculé différemment fait appel à la version en vigueur à ce moment-là. « Canonique » ne signifie pas immuable ; cela signifie contrôlé.

Lorsque RAG et les connaissances canoniques sont en désaccord

Tôt ou tard, l’agent récupérera un document ancien indiquant que OTD correspond au nombre total de livraisons à temps par rapport au nombre total de commandes passées, tandis que le concept canonique prévoit le nombre de livraisons à temps par rapport au nombre total de livraisons. Le système a besoin d’une règle de priorité explicite, et en cas de contradiction, d’une réponse telle que :

if contradiction(okf_context, rag_context):
  log_conflict(…)
  prefer(okf_context)

Il peut même indiquer à l’utilisateur qu’un document plus ancien entre en conflit avec la définition métrique actuelle, et que c’est la définition actuellement vérifiée qui a été utilisée. L’agent fait donc plus que simplement répondre : il met en évidence des dettes de connaissance, ce qui peut constituer l’un des effets secondaires les plus précieux de cette conception.

Mesurer plus que la réponse finale

Dans cette architecture, il ne suffit pas de se contenter de suivre le taux d’hallucinations. Il convient également d’évaluer la manière dont le système est parvenu à une réponse, par exemple :

% queries routed to correct source
% canonical lookups with stale concepts
% live queries rejected by policy
% RAG/OKF conflicts detected
% concepts past stale_after
% concepts with no active owne

Une réponse finale incorrecte peut résulter de défauts très différents. Le modèle a pu raisonner de manière erronée. Le routeur a pu choisir RAG alors qu’une connaissance canonique était nécessaire. Le concept canonique a pu être obsolète. La requête en temps réel a pu être correcte tandis que la définition de la métrique était fausse. Il s’agit de problèmes d’ingénierie distincts, et l’observabilité devrait permettre de les séparer.

Lorsque c’est de l’overengineering

Une équipe d’ingénieurs composée de cinq personnes disposant seulement de quelques documents internes n’a probablement pas besoin d’une plateforme de gouvernance des connaissances. Si l’usage principal consiste à trouver des informations pertinentes parmi des milliers de documents, RAG peut suffire. Si les connaissances changent rarement, des mécanismes de mise à jour en temps réel peuvent s’avérer inutiles. Si personne ne s’occupe actuellement de la documentation, l’ajout de métadonnées YAML ne créera pas automatiquement une culture de responsabilisation.

Cette approche devient intéressante lorsque plusieurs de ces conditions sont remplies :

• Plusieurs équipes définissent chacune les mêmes concepts
• Les agents exécutent des actions opérationnelles
• Les schémas et les métriques sont modifiés fréquemment
• Des connaissances incorrectes coûtent réellement de l’argent à l’entreprise
• Les définitions nécessitent des responsables et un historique d’audit
• Les données en temps réel doivent être associées à une sémantique canonique

Plus ces points s’appliquent, plus la séparation des responsabilités s’avère bénéfique.

Où MCP s’insère

Lorsque les agents s’appuient sur plusieurs sources de connaissances et de données, MCP devient un point d’intégration naturel. Un agent peut disposer de capacités telles que :

get_canonical_metric_definition
get_schema
search_historical_documents
query_warehouse
get_runbook

Le routeur choisit celui qui convient. OKF décrit les concepts et les contraintes, MCP met à disposition des outils et des ressources, les systèmes en temps réel restent les propriétaires des données actuelles, et RAG demeure la couche de découverte pour l’historique non structuré. Il est préférable de conserver ces responsabilités séparées, sauf s’il existe une raison forte de les fusionner.

Une première version judicieuse

Commencer avec 300 concepts serait une erreur. Dix est un meilleur chiffre, plus précisément dix concepts sur lesquels les gens débattent déjà. Par exemple :

3 metrics
2 schemas
2 SLAs
2 runbooks
1 business rule

Ensuite, mesurez plusieurs éléments. L’agent parvient-il à trouver le concept canonique ? Sait-il quand ce concept est obsolète ? Le routage choisit-il le bon chemin ? Les requêtes en temps réel peuvent-elles être exécutées en toute sécurité ? Les personnes maintiennent-elles réellement ces concepts ? De bons résultats justifient l’élargissement du champ d’application. De mauvais résultats justifient l’arrêt. Une expérience architecturale doit pouvoir échouer sans coûter trop cher.

La leçon principale

La conclusion la plus utile n’est pas un nouveau format de fichier. C’est que les connaissances d’entreprise possèdent différents modes de vérité. Certaines sont autoritaires, d’autres sont exploratoires, et d’autres encore représentent l’état actuel ; chaque mode mérite son propre schéma d’accès. Une correspondance pratique associe chaque question à un mode :

• Définition officielle : connaissance canonique.
• Informations pertinentes : récupération.
• Vérité actuelle : une requête en temps réel.
• Ce que l’agent doit faire : combiner tout ce qui précède selon des règles définies.

RAG reste précieux, les bases de données vectorielles restent précieuses, et OKF peut également l’être. L’erreur architecturale réside dans l’idée que l’un d’eux devrait répondre à toutes les questions. L’avenir ne consiste pas à remplacer RAG, mais à savoir quand RAG est l’outil adapté et quand il ne l’est pas. Une fois que les agents entreprennent des actions réelles au sein des entreprises, choisir la source de vérité cesse d’être une question de gestion des connaissances pour devenir une décision architecturale.