Pourquoi je suis contre la récupération uniquement par grep de Claude Code ? Elle consomme tout simplement trop de tokens
Les assistants de codage IA explosent. Au cours des deux dernières années seulement, des outils comme Cursor, Claude Code, Gemini CLI et Qwen Code sont passés du statut de curiosités à celui de compagnons quotidiens pour des millions de développeurs. Mais derrière cette ascension rapide se profile un combat autour de quelque chose de faussement simple : comment un assistant de codage IA devrait-il réellement rechercher du contexte dans votre codebase ?
À l’heure actuelle, il existe deux approches :
RAG alimenté par la recherche vectorielle (récupération sémantique).
Recherche par mots-clés avec grep (correspondance littérale de chaînes).
Claude Code et Gemini ont choisi la seconde. En fait, un ingénieur de Claude a ouvertement admis sur Hacker News que Claude Code n’utilise pas du tout RAG. À la place, il se contente de parcourir votre repo avec grep ligne par ligne (ce qu’ils appellent « recherche agentique ») — pas de sémantique, pas de structure, juste une correspondance brute de chaînes.
Cette révélation a divisé la communauté :
Les partisans défendent la simplicité de grep. C’est rapide, exact et — surtout — prévisible. En programmation, affirment-ils, la précision est essentielle, et les embeddings actuels restent trop flous pour qu’on puisse leur faire confiance.
Les critiques voient grep comme une impasse. Il vous noie dans des correspondances non pertinentes, consomme des tokens et bloque votre flux de travail. Sans compréhension sémantique, c’est comme demander à votre IA de déboguer les yeux bandés.
Les deux camps ont raison. Et après avoir construit et testé ma propre solution, je peux dire ceci : l’approche RAG basée sur la recherche vectorielle change la donne. Non seulement elle rend la recherche considérablement plus rapide et plus précise, mais elle réduit aussi l’utilisation des tokens de 40 % ou plus. (Passez directement à la partie Claude Context pour mon approche)
Alors pourquoi grep est-il si limitant ? Et comment la recherche vectorielle peut-elle réellement offrir de meilleurs résultats en pratique ? Décomposons tout cela.
Qu’est-ce qui ne va pas avec la recherche de code uniquement basée sur grep de Claude Code ?
Je me suis heurté à ce problème en déboguant un souci épineux. Claude Code a lancé des requêtes grep dans tout mon repo, me renvoyant d’énormes blocs de texte non pertinent. Au bout d’une minute, je n’avais toujours pas trouvé le fichier pertinent. Cinq minutes plus tard, j’avais enfin les 10 bonnes lignes — mais elles avaient été enfouies dans 500 lignes de bruit.
Ce n’est pas un cas isolé. En parcourant les issues GitHub de Claude Code, on voit de nombreux développeurs frustrés se heurter au même mur :
issue1: https://github.com/anthropics/claude-code/issues/1315
issue2: https://github.com/anthropics/claude-code/issues/4556
La frustration de la communauté se résume à trois points douloureux :
Gonflement des tokens. Chaque sortie grep injecte d’énormes quantités de code non pertinent dans le LLM, faisant grimper des coûts qui augmentent terriblement avec la taille du repo.
Taxe temporelle. Vous êtes coincé à attendre pendant que l’IA joue aux devinettes avec votre codebase, ce qui tue la concentration et le flow.
Zéro contexte. Grep fait correspondre des chaînes littérales. Il n’a aucune notion de signification ou de relations, donc vous cherchez effectivement à l’aveugle.
C’est pourquoi le débat compte : grep n’est pas simplement « old school », il freine activement la programmation assistée par IA.
Claude Code vs Cursor : pourquoi ce dernier dispose d’un meilleur contexte de code
En matière de contexte de code, Cursor a fait un meilleur travail. Dès le premier jour, Cursor s’est appuyé sur l’indexation de codebase : découper votre repo en fragments significatifs, intégrer ces fragments sous forme de vecteurs et les récupérer sémantiquement chaque fois que l’IA a besoin de contexte. C’est le Retrieval-Augmented Generation (RAG) appliqué au code dans les règles de l’art, et les résultats parlent d’eux-mêmes : un contexte plus précis, moins de tokens gaspillés et une récupération plus rapide.
Claude Code, à l’inverse, a misé encore davantage sur la simplicité. Pas d’index, pas d’embeddings — seulement grep. Cela signifie que chaque recherche est une correspondance littérale de chaînes, sans compréhension de la structure ni de la sémantique. C’est rapide en théorie, mais en pratique, les développeurs finissent souvent par passer au crible des bottes de foin de résultats non pertinents avant de trouver l’aiguille dont ils ont réellement besoin.
| Claude Code | Cursor | |
|---|---|---|
| Précision de recherche | Ne fait remonter que les correspondances exactes — manque tout ce qui porte un nom différent. | Trouve du code sémantiquement pertinent même lorsque les mots-clés ne correspondent pas exactement. |
| Efficacité | Grep déverse d’énormes blocs de code dans le modèle, faisant grimper les coûts en tokens. | Des fragments plus petits et plus pertinents réduisent la charge en tokens de 30 à 40 %. |
| Évolutivité | Relance grep sur le dépôt à chaque fois, ce qui ralentit à mesure que les projets grandissent. | Indexe une fois, puis récupère à grande échelle avec un délai minimal. |
| Philosophie | Rester minimaliste — aucune infrastructure supplémentaire. | Tout indexer, récupérer intelligemment. |
Alors pourquoi Claude (ou Gemini, ou Cline) n’a-t-il pas suivi l’exemple de Cursor ? Les raisons sont en partie techniques et en partie culturelles. La récupération vectorielle n’est pas triviale — il faut résoudre le découpage en fragments, les mises à jour incrémentales et l’indexation à grande échelle. Mais plus important encore, Claude Code est construit autour du minimalisme : pas de serveurs, pas d’index, seulement une CLI épurée. Les embeddings et les bases de données vectorielles ne correspondent pas à cette philosophie de conception.
Cette simplicité est séduisante — mais elle plafonne aussi ce que Claude Code peut offrir. La volonté de Cursor d’investir dans une véritable infrastructure d’indexation est la raison pour laquelle il paraît plus puissant aujourd’hui.
Claude Context : un projet open-source pour ajouter la recherche sémantique de code à Claude Code
Claude Code est un outil solide — mais il dispose d’un contexte de code médiocre. Cursor a résolu ce problème grâce à l’indexation de la base de code, mais Cursor est closed-source, verrouillé derrière des abonnements, et coûteux pour les individus ou les petites équipes.
C’est cet écart qui nous a poussés à commencer à construire notre propre solution open-source : Claude Context.
Claude Context est un plugin MCP open-source qui apporte la recherche sémantique de code à Claude Code (et à tout autre agent de codage IA qui parle MCP). Au lieu de forcer brutalement votre dépôt avec grep, il intègre des bases de données vectorielles avec des modèles d’embeddings afin de fournir aux LLMs un contexte profond et ciblé à partir de l’ensemble de votre base de code. Résultat : une récupération plus précise, moins de gaspillage de tokens et une bien meilleure expérience développeur.
Voici comment nous l’avons construit :
Technologies que nous utilisons
🔌 Couche d’interface : MCP comme connecteur universel
Nous voulions que cela fonctionne partout — pas seulement avec Claude. MCP (Model Context Protocol) agit comme le standard USB pour les LLMs, permettant à des outils externes de se connecter de façon fluide. En empaquetant Claude Context comme serveur MCP, il fonctionne non seulement avec Claude Code, mais aussi avec Gemini CLI, Qwen Code, Cline, et même Cursor.
🗄️ Base de données vectorielle : Zilliz Cloud
Pour l’épine dorsale, nous avons choisi Zilliz Cloud (un service entièrement géré construit sur Milvus). Il est hautement performant, cloud-native, élastique, et conçu pour les charges de travail IA comme l’indexation de bases de code. Cela signifie une récupération à faible latence, une évolutivité quasi infinie et une fiabilité à toute épreuve.
🧩 Modèles d’embeddings : flexibles par conceptionLes différentes équipes ont des besoins différents, donc Claude Context prend en charge plusieurs fournisseurs d’embeddings prêts à l’emploi :
OpenAI embeddings pour la stabilité et une large adoption.
Voyage embeddings pour des performances spécialisées dans le code.
Ollama pour des déploiements locaux axés sur la confidentialité.
Des modèles supplémentaires peuvent être intégrés à mesure que les exigences évoluent.
💻 Choix du langage : TypeScript
Nous avons débattu entre Python et TypeScript. TypeScript l’a emporté — pas seulement pour la compatibilité au niveau applicatif (plugins VSCode, outillage web), mais aussi parce que Claude Code et Gemini CLI eux-mêmes sont basés sur TypeScript. Cela rend l’intégration fluide et maintient la cohérence de l’écosystème.
Architecture du système
Claude Context suit une conception propre et en couches :
Les modules cœur gèrent le travail lourd : analyse du code, découpage, indexation, recherche et synchronisation.
L’interface utilisateur gère les intégrations — serveurs MCP, plugins VSCode ou autres adaptateurs.
Cette séparation garde le moteur cœur réutilisable dans différents environnements tout en permettant aux intégrations d’évoluer rapidement à mesure que de nouveaux assistants de codage IA émergent.
Implémentation du module cœur
Les modules cœur constituent la fondation de tout le système. Ils abstraient les bases de données vectorielles, les modèles d’embedding et d’autres composants en modules composables qui créent un objet Context, permettant d’utiliser différentes bases de données vectorielles et différents modèles d’embedding selon les scénarios.
import { Context, MilvusVectorDatabase, OpenAIEmbedding } from '@zilliz/claude-context-core';
// Initialize embedding provider
const embedding = new OpenAIEmbedding(...);
// Initialize vector database
const vectorDatabase = new MilvusVectorDatabase(...);
// Create context instance
const context = new Context({embedding, vectorDatabase});
// Index your codebase with progress tracking
const stats = await context.indexCodebase('./your-project');
// Perform semantic search
const results = await context.semanticSearch('./your-project', 'vector database operations');
Résoudre les principaux défis techniques
Construire Claude Context ne consistait pas seulement à connecter des embeddings et une base de données vectorielle. Le véritable travail a été de résoudre les problèmes difficiles qui font réussir ou échouer l’indexation du code à grande échelle. Voici comment nous avons abordé les trois plus grands défis :
Défi 1 : Découpage intelligent du code
Le code ne peut pas simplement être découpé par lignes ou par caractères. Cela crée des fragments désordonnés et incomplets, et supprime la logique qui rend le code compréhensible.
Nous avons résolu cela avec deux stratégies complémentaires :
Découpage basé sur l’AST (stratégie principale)
C’est l’approche par défaut, qui utilise les analyseurs tree-sitter pour comprendre la structure syntaxique du code et découper selon des frontières sémantiques : fonctions, classes, méthodes. Cela offre :
Complétude syntaxique – pas de fonctions tronquées ni de déclarations cassées.
Cohérence logique – la logique associée reste groupée pour une meilleure recherche sémantique.
Prise en charge multilingue – fonctionne avec JS, Python, Java, Go et bien plus via les grammaires tree-sitter.
Découpage de texte LangChain (stratégie de repli)
Pour les langages que l’AST ne peut pas analyser ou lorsque l’analyse échoue, le RecursiveCharacterTextSplitter de LangChain fournit une solution de secours fiable.
// Use recursive character splitting to maintain code structure
const splitter = RecursiveCharacterTextSplitter.fromLanguage(language, {
chunkSize: 1000,
chunkOverlap: 200,
});
C’est moins « intelligent » que l’AST, mais très fiable — garantissant que les développeurs ne restent jamais bloqués. Ensemble, ces deux stratégies équilibrent richesse sémantique et applicabilité universelle.
Défi 2 : Gérer efficacement les changements de code
La gestion des changements de code représente l’un des plus grands défis des systèmes d’indexation de code. Réindexer des projets entiers pour de petites modifications de fichiers serait totalement impraticable.
Pour résoudre ce problème, nous avons construit le mécanisme de synchronisation basé sur les arbres de Merkle.
Arbres de Merkle : la fondation de la détection des changements
Les arbres de Merkle créent un système hiérarchique d’« empreintes » dans lequel chaque fichier possède sa propre empreinte de hachage, les dossiers ont des empreintes basées sur leur contenu, et le tout aboutit à une empreinte de nœud racine unique pour l’ensemble de la base de code.
Lorsque le contenu d’un fichier change, les empreintes de hachage se propagent vers le haut à travers chaque couche jusqu’au nœud racine. Cela permet une détection rapide des changements en comparant les empreintes de hachage couche par couche depuis la racine vers le bas, en identifiant et en localisant rapidement les modifications de fichiers sans réindexation complète du projet.
Le système effectue des vérifications de synchronisation par handshake toutes les 5 minutes à l’aide d’un processus simplifié en trois phases :
Phase 1 : Détection ultra-rapide calcule le hachage racine Merkle de toute la base de code et le compare à l’instantané précédent. Des hachages racine identiques signifient qu’aucun changement n’a eu lieu — le système ignore tout traitement en quelques millisecondes.
Phase 2 : Comparaison précise se déclenche lorsque les hachages racine diffèrent, en effectuant une analyse détaillée au niveau des fichiers afin d’identifier exactement quels fichiers ont été ajoutés, supprimés ou modifiés.
Phase 3 : Mises à jour incrémentielles recalcule les vecteurs uniquement pour les fichiers modifiés et met à jour la base de données vectorielle en conséquence, maximisant ainsi l’efficacité.
Gestion des instantanés locaux
Tout l’état de synchronisation persiste localement dans le répertoire ~/.context/merkle/ de l’utilisateur. Chaque base de code conserve son propre fichier d’instantané indépendant contenant les tables de hachage des fichiers et les données sérialisées de l’arbre de Merkle, garantissant une récupération précise de l’état même après des redémarrages du programme.
Cette conception offre des avantages évidents : la plupart des vérifications se terminent en quelques millisecondes lorsqu’aucun changement n’existe, seuls les fichiers réellement modifiés déclenchent un retraitement (évitant un gaspillage massif de calcul), et la récupération de l’état fonctionne parfaitement d’une session de programme à l’autre.
Du point de vue de l’expérience utilisateur, la modification d’une seule fonction déclenche une réindexation uniquement pour ce fichier, et non pour l’ensemble du projet, améliorant considérablement l’efficacité du développement.
Défi 3 : Concevoir l’interface MCP
Même le moteur d’indexation le plus intelligent est inutile sans une interface propre destinée aux développeurs. MCP était le choix évident, mais il a introduit des défis uniques :
🔹 Conception des outils : rester simple
Le module MCP sert d’interface côté utilisateur, faisant de l’expérience utilisateur la priorité absolue.
La conception des outils commence par l’abstraction des opérations standard d’indexation et de recherche de bases de code en deux outils principaux : index_codebase pour indexer les bases de code et search_code pour rechercher du code.
Cela soulève une question importante : quels outils supplémentaires sont nécessaires ?
Le nombre d’outils exige un équilibre soigneux : trop d’outils créent une charge cognitive et perturbent la sélection d’outils par les LLM, tandis qu’un nombre insuffisant pourrait faire manquer des fonctionnalités essentielles.
Remonter à partir de cas d’utilisation réels aide à répondre à cette question.
Relever les défis du traitement en arrière-plan
Les grandes bases de code peuvent prendre un temps considérable à indexer. L’approche naïve consistant à attendre synchroniquement la fin du traitement force les utilisateurs à patienter plusieurs minutes, ce qui est tout simplement inacceptable. Le traitement asynchrone en arrière-plan devient essentiel, mais MCP ne prend pas en charge nativement ce modèle.
8.png
Notre serveur MCP exécute un processus en arrière-plan au sein du serveur MCP pour gérer l’indexation tout en renvoyant immédiatement des messages de démarrage aux utilisateurs, leur permettant de continuer à travailler.
9.png
Cela crée un nouveau défi : comment les utilisateurs suivent-ils la progression de l’indexation ?
Un outil dédié à l’interrogation de la progression ou de l’état de l’indexation résout ce problème élégamment. Le processus d’indexation en arrière-plan met en cache de manière asynchrone les informations de progression, permettant aux utilisateurs de vérifier à tout moment les pourcentages d’achèvement, l’état de réussite ou les conditions d’échec. De plus, un outil manuel de suppression d’index gère les situations où les utilisateurs doivent réinitialiser des index inexacts ou redémarrer le processus d’indexation.
Conception finale des outils :
index_codebase - Indexer la base de code
search_code - Rechercher du code
get_indexing_status - Interroger l’état de l’indexation
clear_index - Supprimer l’index
Quatre outils qui trouvent l’équilibre parfait entre simplicité et fonctionnalité.
🔹 Gestion des variables d’environnement
La gestion des variables d’environnement est souvent négligée, alors qu’elle a un impact significatif sur l’expérience utilisateur. Exiger une configuration séparée des clés API pour chaque client MCP obligerait les utilisateurs à configurer leurs identifiants plusieurs fois lorsqu’ils passent de Claude Code à Gemini CLI.
Une approche de configuration globale élimine cette friction en créant un fichier ~/.context/.env dans le répertoire personnel de l’utilisateur :
# ~/.context/.env
OPENAI_API_KEY=your-api-key-here
MILVUS_TOKEN=your-milvus-token
Cette approche offre des avantages clairs : les utilisateurs configurent une seule fois et utilisent partout sur tous les clients MCP, toutes les configurations sont centralisées en un seul emplacement pour une maintenance facile, et les clés API sensibles ne sont pas dispersées dans plusieurs fichiers de configuration.
Nous mettons également en œuvre une hiérarchie de priorité à trois niveaux : les variables d’environnement du processus ont la priorité la plus élevée, les fichiers de configuration globale ont une priorité moyenne, et les valeurs par défaut servent de solutions de repli.
Cette conception offre une flexibilité considérable : les développeurs peuvent utiliser des variables d’environnement pour des remplacements temporaires lors des tests, les environnements de production peuvent injecter des configurations sensibles via les variables d’environnement système pour une sécurité renforcée, et les utilisateurs configurent une seule fois pour travailler de manière fluide avec Claude Code, Gemini CLI et d’autres outils.
À ce stade, l’architecture centrale du serveur MCP est complète, couvrant l’analyse du code et le stockage vectoriel jusqu’à la récupération intelligente et la gestion de la configuration. Chaque composant a été soigneusement conçu et optimisé pour créer un système à la fois puissant et convivial.
Tests pratiques
Alors, comment Claude Context fonctionne-t-il réellement en pratique ? Je l’ai testé sur exactement le même scénario de chasse aux bugs qui m’avait initialement laissé frustré.
L’installation n’a nécessité qu’une seule commande avant de lancer Claude Code :
claude mcp add claude-context -e OPENAI_API_KEY=your-openai-api-key -e MILVUS_TOKEN=your-zilliz-cloud-api-key -- npx @zilliz/claude-context-mcp@latest
Une fois mon codebase indexé, j’ai donné à Claude Code la même description de bug qui l’avait auparavant lancé dans une chasse au dahu de cinq minutes propulsée par grep. Cette fois, grâce aux appels MCP de claude-context, il a immédiatement identifié le fichier exact et le numéro de ligne, avec une explication du problème.
La différence n’était pas subtile : c’était le jour et la nuit.
Et il ne s’agissait pas seulement de chasse aux bugs. Avec Claude Context intégré, Claude Code a systématiquement produit des résultats de meilleure qualité dans les domaines suivants :
Résolution de problèmes
Refactorisation de code
Détection de code dupliqué
Tests complets
Le gain de performance apparaît aussi dans les chiffres. Lors de tests comparatifs côte à côte :
L’utilisation de tokens a chuté de plus de 40 %, sans aucune perte de rappel.
Cela se traduit directement par des coûts d’API plus faibles et des réponses plus rapides.
Sinon, avec le même budget, Claude Context a fourni des récupérations bien plus précises.
Nous avons publié Claude Context en open source sur GitHub, et il a déjà obtenu plus de 2,6K étoiles. Merci à tous pour votre soutien et vos likes.
Vous pouvez l’essayer vous-même :
GitHub : github.com/zilliztech/claude-context
Des benchmarks détaillés et la méthodologie de test sont disponibles dans le repo — nous serions ravis de recevoir vos retours.
Perspectives
Ce qui a commencé comme une frustration avec grep dans Claude Code est devenu une solution solide : Claude Context — un plugin MCP open source qui apporte la recherche sémantique alimentée par des vecteurs à Claude Code et à d’autres assistants de codage. Le message est simple : les développeurs n’ont pas à se contenter d’outils d’IA inefficaces. Avec RAG et la récupération vectorielle, vous pouvez déboguer plus vite, réduire les coûts de tokens de 40 % et enfin bénéficier d’une assistance IA qui comprend réellement votre codebase.
Et cela ne se limite pas à Claude Code. Comme Claude Context repose sur des standards ouverts, la même approche fonctionne parfaitement avec Gemini CLI, Qwen Code, Cursor, Cline, et au-delà. Fini l’enfermement dans des compromis imposés par les fournisseurs qui privilégient la simplicité au détriment de la performance.
Nous serions ravis que vous fassiez partie de cet avenir :
Essayez Claude Context** :** il est open-source et totalement gratuit
Contribuez à son développement
Ou créez votre propre solution en utilisant Claude Context
👉 Partagez vos retours, posez vos questions ou obtenez de l’aide en rejoignant notre communauté Discord.
Continuer à lire
Introducing Business Critical Plan: Enterprise-Grade Security and Compliance for Mission-Critical AI Applications
Discover Zilliz Cloud’s Business Critical Plan—offering advanced security, compliance, and uptime for mission-critical AI and vector database workloads.
Announcing the General Availability of Single Sign-On (SSO) on Zilliz Cloud
SSO is GA on Zilliz Cloud, delivering the enterprise-grade identity management capabilities your teams need to deploy vectorDB with confidence.
Bringing AI to Legal Tech: The Role of Vector Databases in Enhancing LLM Guardrails
Discover how vector databases enhance AI reliability in legal tech, ensuring accurate, compliant, and trustworthy AI-powered legal solutions.