RAG production : pourquoi Obsidian + Claude Code est un piège

1. Ce que fait vraiment Claude Code avec Obsidian

Depuis quelques semaines, des dizaines de vidéos circulent sur le thème “Claude Code + Obsidian remplace le RAG”. Le pitch est séduisant : vous donnez vos documents à Claude Code, il génère un knowledge graph dans Obsidian, et vous interrogez votre base de connaissance en langage naturel. En 10 minutes chrono.

J’ai testé cette approche sur mes propres documents de référence RAG — une douzaine de fichiers techniques sur le diagnostic de panne moteur — pour comparer objectivement avec un RAG classique. Le résultat est sans appel : ce n’est pas du RAG. C’est une confusion entre deux mécanismes fondamentalement différents.

Dans un RAG classique, le fonctionnement est précis : la question utilisateur passe par un modèle d’embedding pour obtenir un vecteur en 372 dimensions (ou davantage selon le modèle). Ce vecteur est comparé aux vecteurs de la base de connaissance. Les chunks les plus proches sémantiquement remontent, et seulement eux. Le contexte envoyé au LLM est chirurgical — quelques centaines de tokens ciblés.

Dans l’approche Obsidian + Claude Code, aucun embedding n’est impliqué. Claude Code lit les fichiers Markdown, navigue dans la structure des notes liées, et fait passer l’ensemble en contexte. C’est de la lecture de fichiers avec traversée de graphe — pas de la recherche sémantique vectorielle.

Résultats de mon test

Sur le symptôme “mon moteur change de régime tout seul”, l’approche Obsidian + Claude Code a retourné des causes comme “prise d’air dans le circuit (70 % des cas)” ou “filtre à carburant encrassé” — des causes certes possibles mais parmi les moins probables pour ce symptôme précis. La vraie cause documentée (course du câble push-pull trop courte, signal de tête de commande variable) n’est pas remontée, bien que présente dans les documents. Le système n’a simplement pas su naviguer vers les bonnes relations.

Un RAG vectoriel correctement configuré avec un chunking et des métadonnées intentionnels aurait ciblé directement ce passage. La différence n’est pas marginale.

2. Les 3 limites structurelles qui cassent en production

Limite 1 : le contexte rot

On sait aujourd’hui, grâce aux recherches sur le mécanisme d’attention des LLM, qu’au-delà de 30 % de remplissage de la fenêtre de contexte, les performances commencent à décliner. Les éléments au milieu du contexte sont progressivement oubliés. Plus vous remplissez, plus le LLM se perd dans ses propres inputs.

Avec une base Obsidian alimentée quotidiennement (via Web Clipper par exemple), la taille du contexte ne fait que grossir. Chaque requête demande à Claude Code de traverser de plus en plus de notes liées. À 200 000 tokens par requête, vous êtes entre 2 € et 3 € la requête côté API. 50 requêtes par jour : 3 000 € par mois. Pour une précision inférieure à ce que donnerait un RAG vectoriel optimisé à 300 € par mois.

Limite 2 : l’impossibilité du multi-utilisateur

Obsidian a été conçu pour un usage personnel, local. Partager une base Obsidian entre plusieurs utilisateurs, synchroniser les modifications en temps réel, gérer les conflits d’écriture — tout cela est intrinsèquement difficile. Le déploiement dans une équipe ou en mode SaaS est pratiquement impossible sans renoncer à l’architecture Obsidian elle-même.

Un RAG production s’appuie sur une base de données vectorielle (Pinecone, Qdrant, pgvector) qui est nativement multi-utilisateurs, queryable via API, et scalable indépendamment du LLM. C’est une différence architecturale, pas un détail de configuration.

Limite 3 : le stockage local uniquement

Les fichiers Markdown d’Obsidian vivent sur le disque de votre machine (ou dans un vault Obsidian Sync). En production, cela signifie absence de haute disponibilité, pas de backup automatisé, pas d’audit trail des modifications. Pour un usage métier sérieux, ce n’est pas une fondation acceptable.

3. Knowledge Graph vs Graph RAG : ne pas confondre

C’est la confusion centrale que j’observe dans ces vidéos virales. Un knowledge graph (ce qu’Obsidian construit) permet de naviguer manuellement dans la connaissance : je pars d’une entité, je suis les relations, j’arrive aux concepts liés. C’est une navigation descendante depuis un nœud source.

Le Graph RAG fonctionne à l’inverse : on part des chunks (fragments de documents) les plus pertinents pour une requête donnée, on remonte leurs relations dans le graphe pour enrichir le contexte, et on fournit au LLM à la fois les chunks directs et leurs voisins relationnels. C’est une augmentation de la récupération vectorielle classique, pas un remplacement.

Pour des questions factuelles simples (“quelle est la procédure de diagnostic pour ce symptôme ?”), le RAG vectoriel classique sera toujours meilleur et moins cher qu’Obsidian. Le Graph RAG n’est pertinent que lorsqu’on a besoin de raisonnement sur des relations entre plusieurs documents distants — des concepts liés sémantiquement éloignés mais logiquement connectés.

Pour aller plus loin sur la maîtrise des concepts fondamentaux des LLM et embeddings, j’ai documenté les 30 notions clés à maîtriser en 2026.

4. Le vrai problème : l’autogénération d’entités

Que ce soit dans Obsidian ou dans les implémentations naïves de Graph RAG, le problème central est l’autogénération d’entités par le LLM. Laissé à lui-même, le LLM va créer des entités basées sur la proximité textuelle — et non sur la logique métier.

Trois pathologies récurrentes

Fragmentation des synonymes. Sur un corpus financier, le LLM peut créer trois entités distinctes pour le même concept : “ROI”, “retour sur investissement” et “rentabilité”. Au lieu d’un seul nœud qui agrège toutes les occurrences pertinentes, on obtient trois nœuds partiels. Une requête sur “rentabilité” manquera tous les documents liés à “ROI”.

Pollution contextuelle. Dans un rapport marketing mentionnant “budget” et “podcast café” dans le même paragraphe, le LLM va créer une relation entre ces deux entités. Toute requête autour du café ou des boissons remonte potentiellement des données budgétaires — du bruit pur qui sature le contexte et dégrade la précision.

Explosion combinatoire. Sur 12 documents seulement, j’ai observé un knowledge graph Obsidian générer des centaines de nœuds avec des clusters redondants (“moteur”, “moteur diesel”, “commande moteur”) sans liens entre eux alors qu’ils devraient être proches. À l’échelle de milliers de documents, cette explosion combinatoire rend le graphe ingérable et les recherches polluées par des faux positifs.

Le principe à retenir : la génération automatique d’entités vous enlève le contrôle sur la granularité de votre knowledge graph. Sans ontologie définie intentionnellement, vous n’avez pas un RAG — vous avez un générateur de bruit.

C’est exactement pour cette raison que j’utilise Claude Code différemment dans mes automatisations : pour de la génération et de l’extraction structurée, pas comme moteur de recherche sur un corpus non structuré.

5. Quelle architecture choisir selon votre cas d’usage ?

Il n’y a pas une architecture RAG universelle. Voici la grille de décision que j’applique avec mes clients en Pays de la Loire :

L’hybride SQL + Vector search couvre environ 80 % des besoins RAG en entreprise. Il combine la précision du filtrage structuré (date, auteur, catégorie, numéro de document) avec la puissance de la recherche sémantique. C’est la configuration la plus efficace et la moins chère pour un RAG production multi-utilisateurs.

Le Graph RAG n’est pertinent qu’en dernier recours — quand les relations inter-documents sont complexes et que la précision supplémentaire de +15 à +25 % justifie le coût de setup et de maintenance d’une ontologie intentionnelle. Sans cette ontologie, Graph RAG est pire que le RAG classique.

Pour comprendre comment choisir entre ces approches dans le contexte de la transformation IA de votre entreprise, un audit de vos données et de vos cas d’usage est la première étape incontournable.

6. Data model intentionnel : la seule voie vers la précision

Quelle que soit l’architecture choisie — RAG vectoriel, SQL hybride ou Graph RAG — la règle fondamentale reste la même : être intentionnel dans la définition du data model avant toute ingestion.

Qu’est-ce qu’un data model pour un RAG ?

Un data model RAG définit explicitement les entités métier, leurs attributs et leurs relations. Dans mon exemple de diagnostic de panne, le data model minimal ressemble à ceci :

• Entité Symptôme — description, fréquence d’occurrence, contexte (2 moteurs / 1 moteur)
• Entité Cause — libellé normalisé, probabilité, pièce concernée
• Entité Diagnostic — étapes ordonnées, outils nécessaires
• Entité Remède — action corrective, durée estimée, pièces de rechange
• Métadonnées non-sémantiques — numéro de page, nom du document, version

Avec ce data model posé avant l’ingestion, le RAG sait exactement quelles entités extraire de chaque chunk et comment les normaliser. “ROI”, “retour sur investissement” et “rentabilité” deviennent une seule entité “rentabilité” avec ses alias. Les chunks sont annotés avec les bonnes métadonnées métier, pas seulement avec du texte brut.

Les deux phases critiques

Depuis 2 ans que je mets des RAG en production pour des PME, j’ai identifié que les deux phases les plus importantes sont l’ingestion et la récupération — pas l’interface utilisateur ni le choix du LLM. Un mauvais chunking ou une mauvaise extraction d’entités en ingestion ne sera jamais rattrapé en récupération, quelle que soit la sophistication du prompt.

La phase d’ingestion comprend : audit de data pour cartographier la logique métier, définition du data model, pipeline de chunking avec extraction d’entités intentionnelles, enrichissement des métadonnées, normalisation et déduplication.

La phase de récupération comprend : stratégie de requête (query expansion, reranking), filtrage par métadonnées avant recherche vectorielle, gestion du contexte (taille des chunks, fenêtre de récupération), et évaluation continue de la précision.

L’IA peut aujourd’hui vous aider à extraire ces entités intentionnelles lors de l’ingestion — c’est d’ailleurs un des chantiers les plus intéressants de l’IA agentique en entreprise. Mais le data model reste une décision humaine, métier, que vous ne pouvez pas déléguer à l’auto-génération.