Semantic code search vs grep sur le dépôt

La semantic code search est-elle meilleure que grep pour les agents de coding IA ?

Pour un agent de coding IA, la semantic code search est presque toujours moins chère et plus précise que de le laisser grep sur tout le dépôt, parce que grep renvoie chaque ligne qui correspond à une chaîne tandis que la semantic search renvoie les quelques fragments qui répondent à la question — et l'agent relit tout ce qu'il fait entrer dans la context window à chaque tour suivant. Je passe mes journées à construire de l'outillage token, et l'habitude la plus coûteuse que je vois dans les transcripts d'agents est toujours la même : poser une question vague, grep sur un mot-clé, déverser 40 fichiers correspondants dans la fenêtre, et facturer au modèle de relire tout ça pour le reste de la session. Soyons clairs d'emblée : grep est un outil brillant et je l'utilise constamment. Ce n'est pas « grep, c'est mal ». C'est « grep est un outil de chaîne, et votre agent pose une question de sens ». Quand les deux s'alignent — vous connaissez le nom exact du symbole et vous voulez tous les sites d'appel — grep gagne haut la main. Quand ils ne s'alignent pas, grep tend au modèle une botte de foin et lui facture d'y trouver l'aiguille. Cet article est une branche du playbook plus large dans Comment réduire l'usage de tokens d'un agent de coding IA. Ici je creuse un levier en profondeur : le retrieval.

Quelle est la différence entre grep et la semantic code search ?

Grep fait correspondre du texte ; la semantic code search fait correspondre du sens. Grep prend un motif — une chaîne littérale ou une expression régulière — et renvoie chaque ligne de chaque fichier qui le contient, classée par rien de particulier. La semantic search transforme votre requête et votre code en embeddings (des vecteurs numériques qui capturent le sens), puis renvoie les fragments dont les vecteurs sont les plus proches de celui de la requête, classés par pertinence. La conséquence pratique réside dans ce qui revient : Grep ne peut pas trouver une fonction appelée verifyCredentials quand vous avez cherché login, parce que les chaînes ne correspondent pas — même si le sens, lui, correspond. La semantic search le peut, parce que les vecteurs sont proches. Inversement, la semantic search est le mauvais outil quand vous avez réellement besoin de chaque occurrence littérale d'une API dépréciée avant un refactor. Des tâches différentes.

Pourquoi grep sur tout le dépôt coûte-t-il autant de tokens à un agent IA ?

Grep est peu coûteux à exécuter et coûteux à consommer, et c'est la consommation que l'agent paie. Le grep lui-même ne coûte rien — c'est une commande shell. Le coût arrive quand les correspondances entrent dans le contexte du modèle. Un mot-clé comme user dans un dépôt de taille moyenne peut correspondre à des centaines de lignes réparties sur des dizaines de fichiers, et un agent naïf ouvrira ces fichiers « par sécurité ». Chaque fichier ouvert représente des milliers de tokens, et voici la partie que les gens oublient : ces tokens ne sont pas facturés une seule fois. Dans une session agentique, l'historique de la conversation est renvoyé à chaque tour jusqu'à ce qu'il soit compacté. Un fichier de 9 000 tokens que l'agent a lu au tour 4 est payé à nouveau au tour 5, au tour 6, au tour 7 — jusqu'à ce que la session se termine ou se compacte. Donc un grep trop large en début de tâche taxe discrètement chaque tour qui suit. C'est le coût cumulé que je n'arrête pas de signaler dans le context engineering : l'erreur coûteuse n'est pas la lecture, c'est la relecture. Il y a aussi un coût de qualité, pas seulement un coût d'argent. Le « Lost in the Middle » de Liu et al. (arxiv.org/abs/2307.03172, 2023) a montré que les modèles prêtent le moins d'attention au contenu enfoui au milieu d'un long contexte. Donc quand grep bourre la fenêtre de 40 fichiers à peine pertinents, ça ne coûte pas seulement plus cher — ça peut masquer le seul fichier qui comptait. Vous payez un supplément pour rendre le modèle plus bête. C'est le pire marché du secteur.

Combien ça coûte vraiment, en dollars ?

Assez pour le remarquer, une fois l'arithmétique faite. Prenez une tâche de navigation où un grep trop large fait entrer environ 25 000 tokens de fichiers, contre une semantic search qui renvoie les 2 000 tokens qui répondent à la question. Ça fait un écart de 23 000 tokens rien que sur le premier tour. Maintenant multipliez par l'effet de relecture sur, disons, huit tours de plus avant compaction, et vous re-payez une bonne partie de ces 23 000 à chaque fois. Au tarif d'entrée actuel — Claude Sonnet 4.6 à 3 $ par million de tokens d'entrée, Claude Opus 4.8 à 5 $, GPT-5.5 à 5 $ (tarifs Anthropic, tarifs OpenAI, 2026) — le delta d'entrée d'une seule requête ressemble à de la menue monnaie. Si ça s'additionne, c'est à cause du volume et de la répétition : des centaines de tours agentiques par jour, la même sur-lecture refacturée à chacun. Le prompt caching adoucit le coup pour le contenu stable (un token d'entrée mis en cache vaut environ 10 % d'un token frais sur Claude — doc prompt caching, 2026), mais un dump de grep est assemblé à neuf à chaque tâche, donc la majeure partie n'obtient jamais la remise du cache. Le correctif n'est pas une lecture moins chère ; c'en est une plus petite. Faites le calcul sur votre propre usage avec le calculateur de coût de tokens LLM.

Quand grep reste-t-il le bon outil ?

Grep est le bon outil dès que vous avez besoin de correspondances de chaînes exactes et que vous connaissez déjà la chaîne. Cas concrets où je tends la main vers ripgrep, pas vers la semantic search :

• Renommage ou refactor exhaustif. Vous supprimez legacyParse et vous avez besoin de tous les sites d'appel, sans exception. Le classement sémantique est le mauvais réflexe ici — vous voulez l'exhaustivité, pas la pertinence.
• Vous connaissez déjà l'identifiant exact. Si le nom du symbole est dans votre tête, grep vous y emmène directement sans aucune surcharge d'embedding.
• Motifs non sémantiques. Trouver tous les TODO(, chaque console.log, tous les littéraux de couleur hexadécimaux, un code d'erreur précis. Il n'y a pas de « sens » à faire correspondre — c'est du texte pur.
• Petits dépôts. Si tout le projet tient confortablement dans le contexte, la précision du retrieval compte moins ; lisez-le, c'est tout.

Le mode d'échec, ce n'est pas d'utiliser grep. C'est d'utiliser grep pour une question de sens — « où l'auth se passe-t-elle ? », « comment le total du panier est-il calculé ? », « qu'est-ce qui gère le retry du webhook ? » — où la formulation de la réponse correspond rarement à celle de votre requête.

Comment la semantic search garde-t-elle la réponse exacte, et pas seulement courte ?

Une bonne semantic code search est consciente du code (code-aware), et c'est ce qui empêche « moins de tokens » de devenir discrètement « mauvaise réponse ». Une recherche vectorielle naïve sur des fragments de texte arbitraires peut renvoyer un commentaire, une fixture de test ou un site d'utilisation alors que ce dont vous aviez besoin était la définition. Le retrieval code-aware classe différemment :

• Il place la définition d'un symbole au-dessus de ses utilisations, pour que le modèle voie la vérité de base en premier.
• Il classe le code source au-dessus des fixtures de test, pour qu'une requête sur un comportement ne renvoie pas des mocks.
• Il découpe sur des frontières structurelles (fonctions, classes, exports) plutôt qu'en tranchant au milieu d'une instruction, pour que chaque fragment renvoyé ait un sens de façon autonome.

Ceci est étroitement lié à la retrieval-augmented generation : l'étape de retrieval décide des preuves sur lesquelles le modèle raisonne. Ratez le retrieval et aucune astuce de prompt ne sauvera la réponse. La condition de victoire pour un agent IA, c'est un retrieval précis — lui tendre les trois fonctions qui comptent, pas les trois cents lignes qui mentionnent le mot.

Puis-je obtenir le meilleur des deux — le sens et l'exhaustivité ?

Oui, et en pratique vous voulez une approche en couches plutôt que de désigner un gagnant. Le schéma que je recommande :

1. Commencez par la semantic search pour vous orienter — « où X est-il géré ? » — et amener l'agent vers la bonne région du codebase en quelques milliers de tokens au lieu de vingt mille.
2. Puis grep de façon étroite à l'intérieur de cette région quand vous avez besoin de correspondances exactes — chaque site d'appel de la fonction précise que vous venez de localiser.
3. Lisez la structure avant les corps. Une fois que l'agent sait où regarder, sortez le skeleton du fichier (signatures et exports) avant tout corps de fonction complet. C'est l'autre moitié de la context compression.

La semantic search rétrécit l'espace de recherche ; grep fait le balayage exhaustif à l'intérieur ; les skeletons gardent la lecture légère. Chaque étape réduit ce qui entre dans la fenêtre sans perdre de signal. Pour l'ensemble plus large de mouvements dans lequel ceci s'insère, l'article sur le context engineering déroule les six leviers.

Comment Tokenade fait-il ça automatiquement ?

Tokenade se place entre votre agent de coding IA et les outils qu'il appelle, et remplace le déversement de fichiers brutal par un retrieval code-aware sans aucune configuration par prompt. Quand l'agent part chercher du code, Tokenade sert une semantic search qui renvoie les fragments classés qui répondent à la requête — les définitions plutôt que les utilisations, le source plutôt que les fixtures — au lieu de le laisser grep large et ouvrir tout ce qui a correspondu. Il empile ça avec l'output filtering pour les logs de commandes bruyants, des lectures skeleton-first, et le chargement paresseux des outils MCP, puis vous montre l'économie en cours sur un dashboard pour que le chiffre ne soit pas une devinette. Ça marche avec Claude Code, Cursor, Codex, GitHub Copilot, Windsurf, Cline, Roo Code, Aider et plus encore — un seul binaire, une seule commande d'installation, zéro config — et c'est source-available sous licence MIT, donc vous pouvez lire exactement ce qu'il fait à votre trafic. Le plan Free couvre jusqu'à ≈10M de tokens/mois sans carte ; le Pro est à 19,90 $/mois (hors taxes, US) ou 19,90 €/mois (TTC, FR) avec postes illimités. Si vous voulez d'abord une vue éditorialisée des optimiseurs de cet espace, voyez Meilleurs optimiseurs de tokens pour Claude Code.

Foire aux questions

La semantic search remplace-t-elle entièrement grep ?

Non, et elle ne le devrait pas. Ils répondent à des questions différentes. La semantic search est pour « où vit le sens ? » et grep est pour « où apparaît cette chaîne exacte ? ». Le workflow solide utilise la semantic search pour trouver la bonne région, puis grep pour les correspondances de chaînes exhaustives à l'intérieur. Remplacer grep par la semantic search pour un balayage de dépréciation serait une erreur — vous manqueriez les occurrences dont le code environnant n'a pas été classé comme « pertinent ».

Construire des embeddings pour mon dépôt fait-il fuiter mon code quelque part ?

Ça dépend entièrement de l'outil, ce qui est exactement pourquoi l'angle de la confiance m'importe. Les embeddings peuvent être calculés localement ou envoyés à un modèle hébergé — lisez la doc et le source. Tokenade est source-available sous licence MIT précisément pour que vous n'ayez pas à croire un fournisseur sur parole quant à ce qui arrive à votre code ; vous pouvez inspecter vous-même le chemin de retrieval.

La semantic search manquera-t-elle quelque chose que grep aurait attrapé ?

Pour une requête de sens, rarement — et quand ça arrive, le workflow en couches le rattrape : vous grep de façon étroite à l'intérieur de la région que la semantic search a localisée. Pour une requête exhaustive (chaque site d'appel, chaque littéral), ne comptez pas du tout sur le classement sémantique ; c'est le travail de grep par conception. Le savoir-faire, c'est de faire correspondre l'outil à la question.

Grep n'est-il pas gratuit ? Pourquoi l'optimiser du tout ?

Exécuter grep est gratuit ; consommer sa sortie ne l'est pas. La commande shell ne coûte rien, mais les correspondances qu'elle déverse dans le contexte du modèle sont facturées comme des tokens d'entrée — et refacturées à chaque tour jusqu'à ce que la session se compacte. L'optimisation ne porte pas sur le grep, mais sur ce que l'agent fait des résultats : ouvrir 40 fichiers contre lire 3 fragments classés. Voyez Coûts en tokens des agents de coding IA pour ce que vaut cette différence.

Comment savoir que ça économise vraiment des tokens ?

Mesurez-le. Lancez la même tâche deux fois — une fois en laissant l'agent grep-and-dump, une fois avec du retrieval sémantique — et comparez les totaux de tokens d'entrée que rapporte votre fournisseur. L'écart est généralement plus grand que les gens ne s'y attendent. Un outil avec un dashboard d'économies fait cette comptabilité pour vous en continu, plutôt qu'une tâche à la fois.

---

Voir aussi :

• Comment réduire l'usage de tokens d'un agent de coding IA — le playbook complet à six leviers dont ceci est une branche.
• Context engineering pour les agents de coding IA — où le retrieval s'insère parmi les autres leviers.
• Réduire l'usage de tokens de Claude Code — les mêmes techniques appliquées spécifiquement à Claude Code.
• Meilleurs optimiseurs de tokens pour Claude Code — les outils de cet espace, comparés.
• Coûts en tokens des agents de coding IA — les prix qui rendent un retrieval précis utile à faire.