Le RAG ne suffit plus : pourquoi j’ai remplacé ChromaDB par GraphRAG chez 3 clients PME

Octobre 2025. Un mardi. Mon client – un fabricant français de pièces techniques, 180 personnes, deux usines – me regarde droit dans les yeux : « Alexandre, ton agent ne trouve plus rien. On l’a payé 28 000 euros et il me ressort de la bouillie. »

Le pire ? Il avait raison. Le RAG classique que j’avais déployé six mois plus tôt avec ChromaDB et OpenAI Embeddings tournait toujours techniquement. Mais sur les requêtes complexes, multi-documents, qui croisaient des références entre catalogues produits, normes ISO et historique support client, le système hallucinait. Sévèrement.

Trois semaines plus tard, j’ai migré son installation vers GraphRAG. Aujourd’hui, je l’ai déployé chez trois clients PME. Voici pourquoi, et surtout comment.

Le RAG vectoriel classique : ses limites cachées

Petit rappel pour ceux qui débarquent. Le RAG (Retrieval-Augmented Generation), c’est cette technique où on découpe tes documents en morceaux, on les transforme en vecteurs mathématiques, et on les stocke dans une base spécialisée (ChromaDB, Qdrant, Pinecone). Quand un utilisateur pose une question, on retrouve les morceaux « sémantiquement proches » et on les balance au LLM pour qu’il réponde.

Sur le papier : magique. En production : ça marche jusqu’à ce que ça ne marche plus.

Voici les 4 limites que j’ai rencontrées, classées par ordre de douleur croissante :

1. Les questions transversales tombent à l’eau. « Quelles sont les similitudes entre nos 3 incidents qualité de l’année dernière ? » → le RAG vectoriel récupère 1 incident, pas 3.
2. Les relations explicites se perdent. Si ton document dit « le produit X dépend du fournisseur Y », la base vectorielle « comprend » cette phrase mais ne sait pas que c’est une relation structurée.
3. Les chunks coupent les liens. Tu découpes en blocs de 800 tokens, et tu casses la mécanique du raisonnement.
4. L’absence de traçabilité hiérarchique. Impossible de répondre à « quels documents de la catégorie X sont concernés par le sujet Y ? ».

Chez mon client industriel, ces 4 limites se cumulaient. Le système était fonctionnel à 60%. Pas assez.

GraphRAG : la promesse, expliquée simplement

GraphRAG, introduit par Microsoft Research en 2024 puis adopté par la communauté open source, change l’approche fondamentale. Au lieu de stocker des morceaux flottants dans un espace mathématique, on construit un graphe de connaissances à partir de tes documents.

Concrètement, le pipeline ressemble à ça :

• On extrait les entités (personnes, produits, lieux, concepts).
• On extrait les relations entre ces entités (« X fournit Y », « Z appartient à W »).
• On regroupe ces entités en communautés thématiques.
• À la requête, on parcourt le graphe pour reconstruire un contexte structuré.

Résultat : les questions transversales redeviennent solvables. Et les hallucinations chutent dramatiquement parce que le LLM travaille sur du contexte structuré, pas sur du texte récupéré au petit bonheur.

Cas client 1 : l’industriel et ses 14 000 documents techniques

Reprenons mon ami fabricant. Sa base documentaire : 14 200 PDF, 6 catalogues produits, 8 ans d’archives support, des fiches normes ISO. Volume total : 2,1 Go de texte indexé.

Migration ChromaDB → GraphRAG (basé sur Neo4j) :

• Durée du projet : 19 jours-homme.
• Coût de la phase d’extraction d’entités : 412 € en API LLM (gpt-4o-mini en gros volume).
• Coût mensuel post-migration : 89 € (vs 156 € avec l’ancienne archi).

Sur 200 requêtes test représentatives, le taux de « réponse pertinente » mesuré par un panel de 3 utilisateurs métiers est passé de 64% à 91%. Le client a renouvelé sa mission.

Cas client 2 : le cabinet d’avocats et la jurisprudence

Deuxième cas, complètement différent. Un cabinet d’avocats parisien spécialisé en droit social, 22 collaborateurs. Le besoin : un assistant capable de retrouver des arguments juridiques sur la base de leur historique de dossiers anonymisés (4 800 cas) plus la jurisprudence Légifrance.

RAG classique testé sur 4 semaines, abandonné. Pourquoi ? Les avocats ont besoin de tracer des chaînes de raisonnement entre arrêts. Le RAG vectoriel leur ramenait des arrêts isolés. Inutilisable juridiquement.

Avec GraphRAG, j’ai modélisé un graphe où les entités sont : « arrêt », « article de code », « principe juridique », « décision », « magistrat », « cabinet ». Les relations capturent les citations, les renvois, les antagonismes.

Le résultat le plus convaincant : sur une recherche d’arguments contradictoires (l’avocat veut savoir « quels arrêts sont allés dans le sens opposé sur le sujet X »), le système retrouve désormais 7 fois plus d’arrêts pertinents qu’avant.

Cas client 3 : la scale-up SaaS et sa base support

Plus prosaïque mais tout aussi parlant. Un SaaS B2B (gestion de chantiers BTP), 11 personnes au support, environ 800 tickets par mois. Leur base de connaissances : 1 200 articles techniques + 18 000 conversations support archivées.

Le problème classique : le support nouvellement embauché met 4 semaines à devenir autonome parce qu’il ne sait pas où chercher. GraphRAG permet de « remonter » depuis un symptôme client jusqu’aux solutions documentées en passant par les concepts métier liés.

Mesure : temps moyen de résolution de ticket en première intention passé de 14 minutes à 8 minutes. Sur 800 tickets/mois et un coût horaire chargé de 35 €, l’économie annuelle dépasse 33 000 €. ROI inférieur à 3 mois.

Quand le RAG classique reste la bonne réponse

Je vais éviter le piège du consultant fanatique. GraphRAG n’est pas une solution universelle. Pour 4 cas sur 10 que je vois passer, le RAG vectoriel classique fait largement le job.

Quand garder un RAG simple :

• Base documentaire homogène (FAQ, glossaire, articles courts).
• Pas ou peu de références croisées dans les documents.
• Volume inférieur à 500 documents.
• Pas de besoin de raisonnement multi-saut (« trouve A en passant par B en lien avec C »).

Sur un projet récent – une mutuelle, 2 800 articles support très autonomes – j’ai gardé Qdrant. Aucun intérêt à la complexité du graphe.

Le coût caché que personne n’aborde

Soyons honnête. GraphRAG coûte plus cher à mettre en place. La phase d’extraction d’entités via LLM peut grimper à plusieurs centaines d’euros sur de gros volumes initiaux. Sur mon premier client industriel, c’était 412 €. Sur un autre projet (cabinet conseil, 28 000 documents), c’est monté à 1 740 €.

Et la maintenance demande une expertise rare : connaître les graphes de connaissances, Neo4j ou équivalent, comprendre Cypher. Très peu de freelances français maîtrisent ça aujourd’hui.

Mon conseil : ne lancez GraphRAG que si vos enjeux justifient cet investissement supplémentaire. Sinon vous payez Ferrari pour aller chercher du pain.

FAQ rapide

Qu’est-ce que GraphRAG concrètement ?

GraphRAG est une approche d’augmentation des LLM qui combine recherche dans un graphe de connaissances et génération de réponse. Au lieu de chercher du texte similaire, on parcourt des relations explicites entre entités extraites des documents source.

GraphRAG est-il adapté à une PME ?

Oui dès lors que la base documentaire dépasse 1 000 documents avec des références croisées (catalogues, normes, historique support, fiches produits). En dessous, un RAG vectoriel classique reste plus pertinent économiquement.

Combien coûte un projet GraphRAG ?

Pour une PME française, compter entre 18 000 € et 45 000 € pour la mise en place initiale selon le volume documentaire et la complexité d’extraction d’entités. Coût d’exploitation mensuel généralement compris entre 80 € et 350 €.

Votre base documentaire dépasse 1 000 documents et vos équipes peinent à exploiter cette mine d’or ? Discutons de votre cas d’usage.