Claude Code, Cursor, Sourcegraph : les trois ont abandonné les embeddings de code en 2026. J'ai refait le test moi-même sur 5655 fichiers de prod, en double session. Le verdict n'est pas un vainqueur, c'est un ordre.
Trois enterrements en un an
Claude Code a testé le RAG avec un vector store local. Boris Cherny, son créateur, en a fait l'autopsie sur Hacker News : "we found pretty quickly that agentic search generally works better". Cursor a supprimé la page d'indexation de sa codebase en juillet dernier : plus d'embeddings calculés, plus de statut d'index. Sourcegraph a officiellement remplacé les embeddings de Cody par sa propre recherche.
Trois éditeurs qui vendaient de l'index sémantique l'ont enterré la même année. Le message du marché : ton agent avec grep et read s'en sort mieux, sans l'infra, sans la staleness de l'index, sans les questions de sécurité.
Est-ce que c'est vrai partout ? J'ai voulu le vérifier sur du réel, pas sur des slides.
Le protocole
Une codebase frontend de prod : 5655 fichiers (Next.js, monorepo, services, composants). Sept questions que je pose vraiment quand j'arrive sur un repo inconnu : où est la config d'env, comment on gère les erreurs API, où est l'auth, comment c'est routé, où est le state management, comment fonctionne le cache.
Deux méthodes, mêmes questions :
Natif : grep, find, glob, read. Ce que ton agent fait déjà.
Sémantique : recherche sur un index d'embeddings de la codebase (j'utilise QMD, un index local).
Je compte trois choses : ce qui est trouvé (recall), la qualité des résultats (précision), et combien d'appels outils il faut.
Les chiffres
Indicateur | Natif (grep/find) | Sémantique (index) |
|---|---|---|
Recall | 7/7 | 4/7 |
Précision | 83% | 100% |
Appels outils | ~18 | 9 |
Le sémantique perd 3 questions sur 7. Mais quand il trouve, il trouve juste : zéro faux positif, et deux fois moins d'appels outils.
Le plus intéressant, c'est ce qui distingue les victoires des échecs.
Pourquoi le sémantique gagne et perd en même temps
Sur mes notes de projet en markdown, le même test donne l'inverse : recall 100%, 40% de tokens en moins, 4x moins d'appels. Pourquoi une telle différence ?
La densité sémantique.
Sur du markdown dense, chaque note dit quelque chose. Un embedding la capture bien. Sur du code, trois obstacles :
Les fichiers structurels sont "pauvres" en sens. Un
page.tsxde l'App Router, c'est des imports et du JSX minimal. L'embedding ne contient presque rien. Résultat : "comment c'est routé" ne trouve rien, alors que le fichier existe sous mes yeux.Les patterns implicites ne portent pas leur nom. Le state management de cette codebase, c'est React Context. Mais dans le code, personne n'écrit "state management" : les fichiers s'appellent
modals.tsx,locales.tsx,menu.tsx. Ils sont nommés par leur fonction. Le sémantique ne fait pas le lien, le grep sur le patterncreateContextle fait en un appel.Les patterns ubiquitaires n'ont pas de fichier. Le cache Next.js, c'est des options de
fetch()éparpillées partout. Chercher un index de "cache" sur un truc qui n'existe pas en tant que fichier : aucune des deux méthodes ne le trouve bien, et le grep se noie dans les occurrences.
En face, quand le fichier est dense (auth.server.ts, http.ts, catch.ts), le sémantique est imbattable : "comment gère-t-on les erreurs" remonte catch.ts sans que j'aie tapé le mot "catch". Le grep exige de connaître le vocabulaire exact du repo. Le sémantique cherche par le sens.
L'ordre qui marche
Le débat "embeddings vs grep" est mal posé. La vraie question : dans quel ordre ton agent les enchaîne. Ma règle d'usage, validée sur les deux benchmarks :
# Recherche codebase (instructions agent)
- Question conceptuelle ("comment on gère X") : recherche sémantique d'abord
- Pattern structurel (fichiers, extensions, chemins) : glob/grep direct
- Grep qui renvoie trop de bruit : sémantique en raffinementC'est presque exactement la hiérarchie qui émerge côté éditeurs : ripgrep par défaut, index structurel (repo map, arbre de symboles) comme amplificateur, sémantique pour les questions conceptuelles sur du code sans mots-clés partagés. Un benchmark public va plus loin : grep seul atteint 65 à 80% de précision fichier, grep + sémantique monte à 87%. Chacun gagne sur son type de requête.
Ce que ça change pour ton équipe
L'endroit où le sémantique rapporte le plus, c'est l'onboarding. Les questions d'un dev qui arrive sur le repo sont précisément des questions conceptuelles : "comment on gère les erreurs", "où on validate les inputs". Ce sont les questions où le grep tourne en rond et brûle des appels. Si tu branches un index sémantique sur ta codebase, c'est pour ça.
Et si tu n'en branches pas, ton agent grep par défaut : ça marche, ça coûte juste plus d'appels et plus de tokens. Tu perds de l'efficacité, pas de la capacité. C'est une décision économique, pas une décision binaire.
Les limites, honnêtement
Une codebase. Sept questions. Pas de réplication. Le fait que trois éditeurs aient abandonné les embeddings me conforte, mais le débat public est loin d'être tranché : certains benchmarks montrent le vector 4x plus cher, d'autres montrent le combo grep + sémantique qui gagne. La seule chose solide, c'est ce que j'ai mesuré : le sémantique seul rate 3 questions sur 7 sur du code, et le grep seul brûle deux fois plus d'appels sur les questions conceptuelles.
Fais ton propre test. 7 questions, deux sessions, un tableau. Deux heures.
Liens sélectionnés
Claude Code Doesn't Index Your Codebase (vadim.blog, mars 2026) : la citation complète de Cherny + le tableau des stratégies de recherche des 5 éditeurs principaux. La meilleure synthèse du basculement.
Benchmarking semantic code retrieval on Claude Code (Turbopuffer, juin 2026) : 65% de précision fichier pour Claude Code nu, 87% avec grep + sémantique. Prendre avec le biais éditeur (ils vendent un vector DB), mais la méthodologie est publique.
Agentic Search vs Vector Search for Coding Agents (Braintrust, octobre 2026) : accuracy égale, vector 4x plus cher. L'auteure liste elle-même les limites du test, c'est rare et appréciable.
CoRE: A Multitask Benchmark and Model for Code Search (Alipay, mai 2026) : le finding qui pique : les requêtes courtes à mots-clés, le format dominant des agents, effondrent tous les modèles d'embeddings à un score quasi nul.
Code Isn't Memory: A Structural Codebase Index Inside a Coding Agent (arXiv, juin 2026) : l'index de symboles (pas d'embeddings) bat le grep pur en coût par problème résolu. Reformule tout le débat : le concurrent du grep, c'est l'index structurel, pas le vector.
Outil de la semaine
QMD (30k stars, MIT), par Tobias Lütke. Un moteur de recherche local : BM25 + embeddings + reranking, tout sur ta machine, zéro cloud. Install : npm install -g @tobilu/qmd. Tes fichiers restent chez toi, l'index se recalcule à la demande. J'ai les chiffres du test ci-dessus et sur 7000+ notes : 40% de tokens en moins, 4x moins d'appels. Là où il brille : markdown dense et questions conceptuelles. Là où il déçoit : le code structurel, comme vu dans le test.
Et toi, ton agent il cherche comment ? Grep brut, ou vous avez déjà branché quelque chose sur la codebase ? Dis-moi la question où il tourne en rond, je suis curieux de voir si ça matche mes 3 échecs.