La recherche sémantique au service des agents IA

Les agents IA comme Claude Code explorent le code avec les mêmes outils qu’un développeur : grep, ripgrep, find. Ces outils sont puissants, mais ils ont une limite fondamentale : ils cherchent du texte, pas du sens.

Quand un agent veut comprendre “où est gérée l’authentification”, il doit deviner les bons mots-clés. auth ? login ? session ? credentials ? Chaque tentative consomme des tokens et du temps.

La recherche sémantique change la donne : l’agent exprime son intention, et l’outil trouve le code correspondant. C’est le principe derrière grepai, un outil open source que j’ai développé pour répondre à ce besoin.

TL;DR

📌 En résumé :

grep cherche du texte, pas du sens : l’agent doit deviner les bons mots-clés

Résultat : recherches lentes, résultats bruités, tokens gaspillés

grepai utilise la recherche sémantique : résultats pertinents, exploration rapide, consommation réduite

Le problème : les limites de grep pour les agents IA

Les agents de code IA opèrent dans le terminal. C’est leur habitat naturel : ils ont accès aux mêmes outils qu’un développeur humain.

Face à une nouvelle codebase, l’agent fait ce que tout développeur ferait : il explore avec grep ou ripgrep. Ces outils sont rapides et puissants, mais ils ont une limite fondamentale pour un agent IA.

La “Taxe de Découverte” itérative

Contrairement à une recherche sémantique qui comprend l’intention, grep est un outil de correspondance littérale. Ça force l’agent dans une boucle de raisonnement surnommée le “jeu des vingt questions” (ce jeu où l’on doit deviner un mot en posant des questions fermées, par élimination) :

L’agent lance un grep pour un mot-clé
Il reçoit une liste de chemins de fichiers
Il doit lire ces fichiers pour comprendre le contexte
Il y trouve de nouveaux termes, et lance un nouveau grep
Et on recommence.

Cette boucle peut consommer des milliers de tokens par tour, parce que le modèle doit maintenir tout l’historique de ses recherches dans sa fenêtre de contexte.

Les benchmarks de Morph montrent qu’une approche grep classique nécessite en moyenne 35 tours de raisonnement pour accomplir une tâche, contre 26 avec une recherche sémantique. C’est 26% de tours en moins, et donc autant de tokens économisés.

Token Bloat : grep contourne les protections

Le plus gros gaspillage survient lors de recherches récursives mal ciblées. Les commandes comme grep -r peuvent contourner les règles de protection classiques de l’agent.

Un développeur sur Reddit a analysé les logs de son agent après avoir épuisé son quota. Sa découverte :

📊 85% de sa fenêtre de contexte (85 000 tokens sur 100 000) étaient consommés par du code provenant de node_modules, des artefacts de build et des fichiers internes de git.

Comme il l’a identifié lui-même : “Allowing Bash commands was the killer here”. Les systèmes de permission de l’agent ne s’appliquent pas à l’exécution de commandes Bash.

Les mêmes benchmarks Morph confirment : 39% de tokens d’entrée en moins (de 14 000 à 9 000) avec une recherche sémantique, et 10% de tâches résolues en plus (74,4% → 81,9%). Moins de tokens, meilleurs résultats.

Le manque de structure sémantique

grep ne comprend pas la structure du code. Il ne sait pas ce qu’est une fonction, une classe, un import. L’agent doit donc lire des fichiers entiers pour situer une ligne trouvée par grep.

Pire encore : grep ne comprend pas les synonymes. Si vous cherchez “authentification”, il ne trouvera pas le code qui parle de “vérification des credentials” ou de “validation du login”. L’agent doit donc multiplier les recherches avec des variantes de mots-clés.

C’est comme chercher une info dans une bibliothèque avec une lampe de poche qui ne montre qu’un mot à la fois. On finit par lire des milliers de pages inutiles juste pour vérifier si on est dans le bon rayon.

⚠️ Nuance importante : grep reste pertinent dans certains cas

Soyons honnêtes : grep (et surtout ripgrep) reste puissant quand on sait exactement ce qu’on cherche. Les regex sont imbattables pour tracer un symbole (rg "class UserRepository"), chercher un pattern précis (rg "TODO|FIXME|HACK"), ou trouver des appels de fonction (rg "myFunction\(").

ripgrep en particulier est 10x plus rapide que grep, respecte .gitignore par défaut, et parallélise les recherches.

Le problème n’est pas grep en soi, c’est son utilisation par les agents IA pour explorer une codebase inconnue. Quand l’agent ne sait pas encore ce qu’il cherche, grep devient un outil de devinette coûteux.

Règle simple : Recherche exacte → grep/ripgrep | Exploration par intention → recherche sémantique

La solution : grepai

En explorant les alternatives à grep, je suis tombé sur mgrep de Mixedbread AI. L’outil est impressionnant : recherche sémantique, embeddings vectoriels, intégration avec les agents IA. Exactement ce qu’il fallait.

Dans un benchmark de 50 tâches comparant mgrep avec des workflows basés sur grep dans Claude Code, les résultats sont sans appel : mgrep utilise environ 2x moins de tokens à qualité égale ou supérieure. grepai implémente la même approche de recherche sémantique, avec des gains similaires attendus (enfin, j’espère !).

Sauf que mgrep est un service cloud. Payant. Avec tout ce que ça implique :

Le code transite par leurs serveurs
Dépendance à un service externe
Coûts récurrents
Latence réseau

Pour un outil qui est censé m’aider à économiser des tokens, envoyer mon code dans le cloud me semblait… ironique.

Alors j’ai développé grepai, un outil open source, 100% local, avec la même philosophie que mgrep mais sans aucune dépendance cloud.

Au lieu de chercher des correspondances de texte, grepai permet à l’agent de chercher par intention. On pose une question en langage naturel, et l’outil trouve les extraits de code qui y répondent.

Les bénéfices sont multiples :

Plus rapide : moins de tours de raisonnement = réponse plus directe
Plus précis : fini les faux positifs, l’agent trouve le bon code du premier coup
Plus complet : la recherche sémantique capture les concepts liés, pas juste les mots exacts
Moins cher : moins de tokens consommés = facture divisée

Ce que grepai fait différemment de grep

Recherche sémantique : Comprend le sens, pas juste le texte. “Where do we set up auth?” trouve le code d’authentification même s’il ne contient pas le mot “auth”.
100% local : Tourne entièrement sur la machine avec Ollama. Le code ne quitte jamais le laptop. Zero cloud.
Traçage du graphe d’appels : Qui appelle cette fonction ? Qu’est-ce qu’elle appelle ? Le contexte complet en une commande.
Intégration native Claude Code : Un sous-agent deep-explore prêt à l’emploi.
Index en temps réel : Un observateur de fichiers maintient l’index à jour pendant le développement.

Exemple concret : avant/après

Imaginons une tâche simple : “Trouve où on gère l’authentification utilisateur”.

	Avec grep	Avec grepai
Approche	`grep -r "auth"` → 47 fichiers. L’agent lit chaque fichier, filtre les faux positifs, relance avec “login”, “session”, etc.	`grepai search "where is user authentication handled"` → 3 fichiers pertinents, classés par score
Tours de raisonnement	~12 tours	~3 tours
Temps perçu	L’agent “cherche partout”	L’agent “sait où regarder”

Ce n’est qu’un exemple, mais il illustre le changement de paradigme : au lieu de deviner des mots-clés, l’agent exprime son intention.

Installation en 30 secondes

# Installer grepai
curl -sSL https://raw.githubusercontent.com/yoanbernabeu/grepai/main/install.sh | sh

# Dans votre projet
cd votre-projet
grepai init
grepai watch  # Lance l'indexation

💡 Le temps d’indexation varie selon la taille de votre codebase et votre machine. Les puces Apple Silicon (M1/M2/M3/M4) et les GPU accélèrent significativement le processus. Sans GPU ni puce M, ça fonctionne… mais vous aurez le temps de vous faire un café, étendre une machine et préparer à manger. Alternative : vous pouvez utiliser l’API OpenAI pour l’embedding si vous préférez déléguer le calcul.

Pour l’intégration Claude Code :

grepai agent-setup --with-subagent

Ça crée automatiquement un sous-agent .claude/agents/deep-explore.md que Claude Code utilisera pour ses recherches.

Pourquoi ça marche : la recherche sémantique expliquée

La différence fondamentale est cognitive.

Avec grep : L’agent traduit sa compréhension de haut niveau (“logique d’authentification”) en jeu de devinettes. Il essaie des dizaines de motifs textuels, espérant tomber sur le bon fichier.

Avec grepai : L’agent exprime son intention (“où gère-t-on l’auth ?”), et grepai retourne les fragments de code sémantiquement liés au concept d’authentification.

Comment ça fonctionne sous le capot

Indexation : grepai découpe le code en “chunks” (par défaut ~500 tokens, configurable) et génère des embeddings vectoriels via Ollama. Le modèle par défaut est nomic-embed-text (768 dimensions), choisi pour son bon rapport qualité/performance sur du code.
Recherche vectorielle : La question est convertie en vecteur avec le même modèle. Une recherche de similarité cosinus trouve les chunks les plus proches dans l’espace vectoriel. Les concepts sémantiquement liés (“auth”, “login”, “session”, “credentials”) se retrouvent naturellement proches.
Hybrid Search : grepai combine recherche vectorielle ET recherche textuelle. Pourquoi ? Parce que chercher “handleUserLogin” doit trouver la fonction exacte, pas juste des concepts liés à l’authentification. Les deux classements sont fusionnés via l’algorithme RRF (Reciprocal Rank Fusion) pour obtenir le meilleur des deux mondes.
Search Boost : Les résultats sont ajustés automatiquement selon le chemin des fichiers. Un fichier dans src/ reçoit un bonus, un fichier dans tests/ ou mocks/ reçoit une pénalité. Exemple : tests/auth_test.py subit deux pénalités (répertoire tests/ + suffixe _test), son score est divisé par 4. Le code métier remonte naturellement en tête.
Retour ciblé : L’agent reçoit uniquement les fragments pertinents (avec contexte), pas des fichiers entiers. Chaque résultat inclut le chemin, les lignes exactes et un score de confiance.

L’analogie : grep c’est une lampe de poche étroite. grepai c’est un aimant qui attire directement le métal.

Aller plus loin

Mode MCP Server

grepai peut fonctionner comme serveur MCP pour d’autres agents :

grepai mcp-serve

Outils exposés :

grepai_search : Recherche sémantique
grepai_trace_callers : Qui appelle cette fonction ?
grepai_trace_callees : Qu’est-ce que cette fonction appelle ?
grepai_trace_graph : Graphe d’appels complet
grepai_index_status : État de l’index

Traçage du graphe d’appels

Une fonctionnalité killer pour comprendre une codebase :

# Qui appelle la fonction handleLogin ?
grepai trace callers "handleLogin"

# Qu'est-ce que handleLogin appelle ?
grepai trace callees "handleLogin"

Support multilingue : Go, JavaScript/TypeScript, Python, PHP, C/C++, Rust, Zig.

Configuration avancée

Le fichier .grepai/config.yaml permet de personnaliser :

Le backend d’embedding (Ollama, LM Studio, OpenAI)
Le modèle utilisé
La taille des chunks
Le backend de stockage (fichier local ou PostgreSQL)

Conclusion

grep est un outil de 1973. Brillant pour son époque, mais pas conçu pour des agents IA qui raisonnent par intention.

grepai change le paradigme : au lieu de deviner des motifs textuels, l’agent exprime ce qu’il cherche. La recherche sémantique fait le reste.

Le résultat :

Plus pertinent : l’agent trouve le bon code du premier coup
Plus rapide : moins de tours de raisonnement, réponses plus directes
Plus économique : moins de tokens consommés
100% local : le code ne quitte jamais la machine

L’outil est open source et en développement actif. Testez-le sur vos projets !

Le projet vous plaît ? Une petite étoile sur GitHub fait toujours plaisir. Vous avez trouvé un bug ou une idée d’amélioration ? Les issues et PRs sont les bienvenues. C’est aussi ça, l’open source.

Sources :

Warp Grep Benchmarks - Morph - Statistiques sur la réduction de tokens (39% moins de tokens, 26% moins de tours)
Claude Code usage limit hack - Reddit - Discussion sur le token bloat (85% de contexte gaspillé)
mgrep - Mixedbread AI - Benchmark montrant 2x moins de tokens
Claude Context - Zilliz - Plugin MCP avec 40% de réduction de tokens
Why I’m Against Claude Code’s Grep-Only Retrieval - Article critique sur grep
CodeGrok MCP - HackerNoon - 10x de réduction de contexte
Why Coding Agents Should Use ripgrep - Comparatif grep vs ripgrep
ast-grep with AI Tools - Recherche par AST pour agents IA
Mantic.sh - Réduit les tokens de 63%
Stop Wasting Tokens: Optimize Claude Code - Guide d’optimisation
grepai - Documentation officielle
grepai - GitHub

Cet article a été écrit avec l’assistance de Claude Code. Ironiquement, il a consommé beaucoup moins de tokens que d’habitude grâce à grepai.