- ▸ Avril 2026 : un Show HN qui déplace le débat
- ▸ Thèse de l'article
- ▸ Contexte historique : de grep aux embeddings, trente ans de compromis
- ▸ Analyse technique : trois briques, un ratio
Un index de dépôt complet en 250 millisecondes, des requêtes répondues en 1,5 milliseconde, 98 % de jetons en moins que la combinaison grep+read. Semble, projet open source du laboratoire MinishLab publié sur GitHub, ne propose pas un nouveau modèle de langage : il propose un nouvel intermédiaire entre l’agent et le code. Trois axes techniques, trois conséquences économiques, un déplacement du goulot d’étranglement.
Points clés 1. Semble atteint 99 % du rendement du modèle CodeRankEmbed Hybrid (137 M de paramètres) en indexant 218 fois plus vite et en répondant aux requêtes 11 fois plus vite, selon le dépôt GitHub MinishLab. 2. L’indexation et la recherche bout-en-bout d’un dépôt entier prennent moins d’une seconde, avec 250 ms d’indexation moyenne et 1,5 ms par requête, le tout sur CPU. 3. Semble utilise environ 98 % de jetons en moins que
grep+readet atteint 94 % de rappel avec un budget de seulement 2 000 jetons, là oùgrep+readexige une fenêtre de 100 000 jetons pour atteindre 85 %. 4. L’outil cible explicitement les agents : Claude Code, Codex, OpenCode, Cursor. Il s’installe comme serveur MCP ou s’invoque depuis l’invite de commande viaAGENTS.md. 5. Le snippet de recherche doit être ajouté àAGENTS.mdouCLAUDE.mdpour que l’agent l’utilise — une intégration qui se mesure en lignes, pas en jours.
Avril 2026 : un Show HN qui déplace le débat
Le 6 avril 2026, un dépôt baptisé Semble apparaît sur le compte GitHub de MinishLab. Le pitch, posé en première ligne du README, tient en une phrase brutale : « Code search for agents that uses ~98% fewer tokens than grep+read ». L’argument n’est pas nouveau dans l’air du temps — chaque équipe travaillant sur des agents de programmation a buté sur la même paroi : la lecture brute des fichiers via les outils Unix engorge la fenêtre de contexte des modèles. Ce qui change, ici, c’est la mise en chiffres.
Sur la même page, MinishLab publie un comparatif face à CodeRankEmbed Hybrid, un transformeur spécialisé de 137 millions de paramètres. Semble revendique 99 % de la qualité de recherche, 218 fois la vitesse d’indexation, 11 fois la vitesse de requête. Le projet totalise 1 400 étoiles GitHub depuis sa publication. Un volume modeste à l’échelle des grands frameworks d’IA, mais significatif pour un outil d’infrastructure publié il y a quelques semaines.
Thèse de l’article
La promesse de Semble n’est pas technique au sens strict : elle est économique. En ramenant la consommation de jetons d’une étape de recherche à quelques milliers contre quelques centaines de milliers, l’outil déplace le centre de gravité du coût d’un agent de codage. Le bénéfice ne se mesure pas en qualité de réponse — il se mesure en facture d’inférence et en latence cumulée par tour. Ce dossier décompose les trois mécanismes qui produisent ce ratio, les conditions concrètes de déploiement, et les angles morts que le projet n’adresse pas encore.
Contexte historique : de grep aux embeddings, trente ans de compromis
Pour comprendre la rupture que représente Semble, il faut revenir à la couche basse de l’outillage : la recherche textuelle dans un dépôt. Depuis les années 1970, la famille grep, egrep, ripgrep règne sans partage sur la recherche de motifs dans le code source. Sa logique est lexicale : on cherche une chaîne, on retourne les lignes qui la contiennent. C’est rapide, prévisible, exhaustif. C’est aussi aveugle à la sémantique. Une fonction nommée validate_user ne sera pas retrouvée si la requête porte sur check authentication.
La recherche sémantique sur le code émerge dans les années 2010 avec l’arrivée des embeddings de tokens, puis avec les modèles spécialisés comme CodeBERT, GraphCodeBERT, et plus récemment des familles dédiées au retrieval comme CodeRankEmbed. Le principe est inverse : on projette chaque fragment de code dans un espace vectoriel et l’on cherche les fragments dont le vecteur est proche de celui de la requête. Le bénéfice : un appariement sémantique. Le coût : une infrastructure de calcul, des modèles à charger en mémoire, une latence non triviale, et — surtout — une indexation préalable qui se compte parfois en minutes ou en heures pour les gros dépôts.
L’irruption des agents de programmation à partir de 2024 — Claude Code, OpenAI Codex CLI, Cursor, OpenCode — a redistribué les contraintes. Ces agents n’ont pas la latence d’un humain qui réfléchit : à chaque tour, ils émettent des appels d’outils, attendent les réponses, raisonnent, recommencent. Chaque jeton coûte deux fois : une fois en entrée du modèle, une fois en surcharge de la fenêtre de contexte qui réduit l’espace disponible pour le raisonnement. Une session de codage qui charge 100 000 jetons de contexte de recherche puis demande au modèle de raisonner dessus paie l’addition à chaque tour suivant, tant que ces jetons restent dans le buffer.
Dans cette logique, grep+read est devenu l’épine dorsale informelle des agents : grep pour localiser, read pour ramener le contenu, le modèle pour trier. C’est efficace en première intention, c’est désastreux en consommation de jetons. C’est ce déséquilibre que Semble vient frapper de plein fouet.
Analyse technique : trois briques, un ratio
L’architecture de Semble, telle que la documente le dépôt MinishLab, repose sur trois composants assemblés sans détour. Le premier est Chonkie, un découpeur de code « code-aware ». Concrètement, Chonkie ne segmente pas un fichier par tranches arbitraires de N lignes : il s’appuie sur la structure syntaxique du langage pour produire des fragments cohérents — une fonction, une classe, un bloc. Ce détail change l’équation en aval : un fragment qui correspond à une unité sémantique se laisse encoder, indexer et restituer sans bavure.
Le deuxième composant est un encodeur statique : Model2Vec dans sa déclinaison potion-code-16M. Ici, le choix est radical. Les encodeurs neuronaux classiques pour le code dépassent souvent les 100 M de paramètres et exigent un GPU pour rester confortables. Model2Vec inverse la logique : il distille un modèle d’embedding en une matrice statique de plongements, ramenant l’inférence à un produit scalaire. La conséquence pratique tient en un mot : CPU. Pas de GPU à provisionner, pas de runtime CUDA à maintenir, pas de file d’attente sur une carte partagée.
Le troisième composant est BM25, l’algorithme de scoring lexical issu de la tradition de la recherche d’information depuis les années 1990. BM25 ne capture pas la sémantique ; il capture l’identifiant exact, le nom d’API, le mot rare. Pour du code source, où les identifiants sont stables et discriminants, BM25 est un excellent rappel. La combinaison des deux retrievers — un sémantique, un lexical — corrige les angles morts de chacun. La sémantique trouve validate_user quand on cherche « authentication ». La lexicale trouve JwtBearerAuthHandler quand on tape exactement ce nom.
Le tableau qui résume tout
| Indicateur | Semble | CodeRankEmbed Hybrid | grep+read |
|---|---|---|---|
| Qualité de retrieval (référence) | 99 % | 100 % | — |
| Vitesse d’indexation | × 218 | × 1 | n/a (pas d’index) |
| Vitesse de requête | × 11 | × 1 | rapide mais aveugle sémantiquement |
Jetons consommés (vs grep+read) | – 98 % en moyenne | non communiqué | référence |
| Rappel à 2 000 jetons | 94 % | non communiqué | < 85 % |
| Rappel à 100 000 jetons | non communiqué | non communiqué | 85 % |
| Paramètres du modèle | 16 M (potion-code) | 137 M | aucun |
| Cible matérielle | CPU | GPU recommandé | CPU |
| Indexation moyenne d’un dépôt | ~ 250 ms | non communiqué | n/a |
| Latence par requête | ~ 1,5 ms | ~ 16,5 ms (ratio × 11) | quelques ms |
Sources : dépôt MinishLab/semble, GitHub, données publiées au 6 avril 2026.
Le chiffre-phare : 94 % de rappel à 2 000 jetons
C’est probablement la donnée la plus parlante du dossier. La métrique de rappel mesure la proportion de fragments pertinents effectivement retrouvés par le système. Semble atteint 94 % avec un budget de seulement 2 000 jetons restitués à l’agent. Pour comparaison, grep+read plafonne à 85 % lorsqu’on lui octroie une fenêtre de 100 000 jetons. Ramené à l’unité, Semble fait mieux en restituant 50 fois moins de matière à digérer.
Cette donnée éclaire l’écart de coût et de latence d’une session agentique. Si chaque tour d’un agent appelle la recherche de code une à plusieurs fois, et que chaque appel passe de 100 000 à 2 000 jetons, la facture d’inférence et la latence de traitement chutent dans des proportions équivalentes. Sur une session de 50 tours — un ordre de grandeur courant pour une tâche de refactoring sérieuse — l’économie cumulée se chiffre en millions de jetons.
Ce que l’outil ne fait pas
Semble ne génère pas de code, ne corrige pas de bug, ne résume pas un dépôt. Il restitue des snippets. C’est un retriever pur, qui se glisse entre l’agent et le système de fichiers, et dont la valeur ajoutée tient à la qualité du tri opéré avant que l’agent n’ait à lire. Cette modestie de périmètre est en soi un parti pris : MinishLab ne propose pas un nouveau cerveau, il propose un meilleur tamis.
L’analyse technique conduit naturellement à la question suivante : qu’est-ce que cela change, concrètement, pour les équipes qui déploient des agents de codage ?
Impact terrain : de la facture d’API à la productivité d’équipe
Le premier impact tangible se loge dans la ligne « tokens » des factures d’API. Les fournisseurs de modèles facturent à l’entrée et à la sortie ; les tarifs d’entrée varient typiquement entre quelques dollars et quelques dizaines de dollars par million de jetons selon les modèles haut de gamme. Une équipe qui exécute des agents en continu pour de la maintenance de code consomme régulièrement plusieurs centaines de millions de jetons par mois. Réduire la part « recherche » de 98 % ne réduit pas la facture totale de 98 % — d’autres étapes (raisonnement, écriture, tests) continuent de peser. Mais sur des charges où la recherche domine le contexte, l’économie est de premier ordre.
Le second impact est la latence perçue. Un agent qui attend la lecture de 100 000 jetons avant de répondre est un agent qui frustre. Semble revendique des indexations à 250 ms et des requêtes à 1,5 ms. À cette échelle, la recherche disparaît de l’expérience : l’agent réfléchit déjà au tour suivant pendant que la réponse arrive. Cette inversion change la conception même des agents — on peut imaginer des stratégies multi-passes où l’agent enchaîne dix recherches affinées plutôt qu’une recherche large.
Le troisième impact est la portabilité. Semble s’expose comme serveur MCP (Model Context Protocol), le standard désormais adopté par Claude Code, Codex CLI, Cursor et OpenCode. Concrètement, l’installation se résume à éditer un fichier de configuration JSON ou TOML. Pour Codex, on ajoute un bloc dans ~/.codex/config.toml. Pour Cursor, on édite ~/.cursor/mcp.json ou le fichier équivalent au niveau du projet. Pour OpenCode, on édite ~/.opencode/config.json. Une fois le serveur déclaré, l’agent dispose d’un outil supplémentaire — Semble — exactement comme il dispose nativement de read_file ou de run_command.
Pour Claude Code spécifiquement, la commande semble init génère un fichier .claude/agents/semble-search.md qui décrit l’outil au modèle. Le projet recommande également d’ajouter un snippet de description dans le AGENTS.md ou le CLAUDE.md du dépôt, fichiers que les agents lisent en début de session pour comprendre l’environnement.
Hors MCP : un CLI autonome
Semble n’est pas captif du protocole MCP. Le projet expose également une CLI utilisable depuis n’importe quel script. Les commandes documentées sont directes :
semble search ./my-projectpour interroger un dépôt local.semble search ./my-projectavec une chaîne de requête pour chercher un symbole ou un identifiant.semble searchavec une URL git pour interroger un dépôt distant, cloné à la demande.
Côté Python, l’API n’est pas plus longue : SembleIndex.from_git(...) indexe un dépôt distant, index.search(...) lance une requête en langage naturel ou en pseudo-code. Cette double exposition — protocole d’agent et bibliothèque standard — élargit le périmètre d’usage au-delà des agents : pipelines CI, outils de revue de code, scripts d’audit.
Le détail qui fait la différence : le AGENTS.md
Un point souvent négligé dans la littérature des agents tient au mécanisme par lequel l’agent « apprend » à utiliser un nouvel outil. Dans la culture émergente, deux fichiers servent de couche d’amorçage : AGENTS.md et CLAUDE.md. Ce sont des notices que l’agent ingère au démarrage, dans lesquelles l’équipe décrit l’environnement, les commandes utiles, les conventions du dépôt. Semble fournit un extrait à coller dans ces fichiers, qui explique à l’agent quand et comment invoquer la recherche.
Cette approche est révélatrice d’un déplacement plus large : la documentation d’un dépôt n’est plus seulement humaine, elle devient également destinée à la machine. Un dépôt sans AGENTS.md à jour est, pour un agent, un dépôt mal documenté — au même titre qu’un dépôt sans README l’est pour un humain.
L’efficacité de Semble en environnement réel est donc fonction de deux variables : la qualité de son retrieval, et la qualité de la documentation d’agent du dépôt qui l’utilise. Cette dépendance soulève des questions, que la suite de l’analyse aborde.
Perspectives contradictoires : ce que le ratio ne dit pas
Les chiffres publiés par MinishLab sont impressionnants, mais ils méritent d’être lus avec la prudence due à toute publication issue d’un projet open source. Plusieurs angles de critique sont à instruire.
Premier angle : la nature des benchmarks. Le dépôt mentionne des « benchmarks » sans détailler, dans l’extrait disponible, la composition exacte du jeu de test. La métrique de rappel à 94 % à 2 000 jetons est puissante, mais elle dépend du protocole d’évaluation : sur quels dépôts ? avec quelles requêtes ? sur quels langages ? Un retriever peut exceller sur du Python idiomatique et chuter sur du C++ template-lourd. Les utilisateurs avisés réserveront leur jugement définitif aux mesures faites sur leurs propres dépôts.
Deuxième angle : la dépendance à la qualité du chunking. Chonkie segmente le code en fragments syntaxiques. Si le langage cible est mal supporté, ou si les fichiers contiennent des constructions inhabituelles (macros, génération de code, DSL embarqués), les chunks peuvent perdre en cohérence. Or, la qualité du retriever final dépend directement de la qualité des chunks indexés. Cette limite n’est pas propre à Semble — elle frappe toutes les approches code-aware — mais elle relativise le ratio de performance affiché.
Troisième angle : la concurrence d’approches alternatives. D’autres équipes explorent des voies différentes pour réduire la consommation de jetons des agents. Les fenêtres de contexte de plusieurs millions de jetons, désormais disponibles chez plusieurs fournisseurs, repoussent mécaniquement le problème. Les techniques de prompt caching réduisent le coût marginal d’un contexte stable. Les systèmes de mémoire structurée externalisent une partie de l’état hors du contexte. Semble ne rend pas ces approches obsolètes ; il s’inscrit dans une boîte à outils plus large.
Quatrième angle : la maintenance d’un index. Un index, contrairement à grep, doit être tenu à jour. Pour un dépôt actif, cela implique soit une réindexation périodique, soit une indexation incrémentale, soit une indexation à la volée à chaque session. Le coût de 250 ms pour un dépôt moyen rend la dernière option viable, mais cette mécanique reste un poste de complexité supplémentaire dans une chaîne d’agent. À l’inverse, grep est sans état — sa robustesse opérationnelle est une qualité que la recherche sémantique paie en complexité.
Cinquième angle : l’effet de capture. Une fois qu’une équipe a configuré son outillage d’agents autour d’un protocole MCP donné et d’un retriever donné, le coût de bascule augmente. Semble est open source, ce qui limite ce risque. Mais l’écosystème MCP, encore jeune, n’a pas encore connu de fragmentation ou de bascules majeures. Le pari implicite des adopteurs précoces est que la couche restera stable.
Ces réserves n’invalident pas le projet : elles dessinent le périmètre dans lequel le ratio annoncé fait sens. Elles préparent aussi la question prospective : que se passe-t-il si l’approche de Semble s’impose comme standard ?
Prospective : un déplacement durable du goulot ?
L’hypothèse la plus solide à formuler aujourd’hui est que Semble, ou un outil de la même famille, devient un composant standard de l’outillage agentique en 2026-2027. Trois forces poussent dans ce sens. La pression économique sur les coûts d’inférence reste forte : tant que chaque jeton se facture, toute économie d’un facteur 50 sur une étape récurrente trouve preneur. La pression sur la latence est tout aussi forte : les agents qui répondent en quelques secondes gagnent face à ceux qui attendent dix. Enfin, la convergence des éditeurs autour du protocole MCP réduit le coût d’adoption d’outils tiers à quasi-zéro.
Si cette hypothèse se vérifie, le goulot d’étranglement de la productivité agentique se déplace une fois de plus. Hier, c’était la qualité du modèle. Aujourd’hui, c’est la qualité de la recherche de contexte. Demain, ce sera probablement la qualité de la mémoire entre sessions et de la planification multi-étape. Chaque déplacement libère un cran de productivité ; chaque déplacement crée une niche pour un outil spécialisé. Reste à observer si MinishLab consolide sa position de premier entrant, ou si l’équation petit modèle statique + BM25 + chunking code-aware se reproduit chez plusieurs acteurs simultanément, au point de devenir une commodité.
FAQ
Quelle est la principale amélioration apportée par Semble par rapport à grep+read ?
Semble restitue à l’agent uniquement les fragments de code pertinents, là où grep+read ramène l’intégralité des fichiers correspondants. Sur le dépôt MinishLab, l’écart annoncé est d’environ 98 % de jetons en moins en moyenne, avec un rappel de 94 % à 2 000 jetons contre 85 % à 100 000 jetons pour grep+read. L’agent réfléchit donc sur un contexte 50 fois plus dense en information utile.
Comment Semble s’intègre-t-il à un agent existant ?
Deux voies sont documentées. Première voie : déclarer Semble comme serveur MCP dans le fichier de configuration de l’agent (~/.codex/config.toml, ~/.cursor/mcp.json, ~/.opencode/config.json ou équivalent Claude Code). Seconde voie : utiliser la CLI semble search ou la bibliothèque Python SembleIndex depuis un script. Pour Claude Code, la commande semble init génère le fichier de description d’agent attendu.
Faut-il un GPU pour faire tourner Semble ?
Non. Le projet revendique explicitement un fonctionnement sur CPU, rendu possible par l’usage de Model2Vec et du modèle statique potion-code-16M, ainsi que de BM25. Cette contrainte matérielle minimale fait partie du positionnement : indexation à 250 ms et requêtes à 1,5 ms sont obtenues sur CPU, sans dépendance à un accélérateur dédié.
Semble remplace-t-il un modèle d’embeddings comme CodeRankEmbed ?
Pour la majorité des cas d’usage liés aux agents, le compromis penche vers Semble : 99 % de la qualité affichée par CodeRankEmbed Hybrid, mais 218 fois plus vite à l’indexation et 11 fois plus vite en requête. Pour des contextes exigeant une qualité de retrieval maximale et tolérant la latence ainsi que le coût matériel, un transformeur spécialisé reste pertinent. La décision se prend dépôt par dépôt, après benchmark interne.
Sources
- GitHub – MinishLab/semble, Fast and Accurate Code Search for Agents. Uses ~98% fewer tokens than grep+read, dépôt public, version consultée au 6 avril 2026. URL : github.com/MinishLab/semble.
- Documentation Semble — README, section Benchmarks, MinishLab, 2026.
- Documentation Semble — README, section Installation MCP (Codex, Cursor, OpenCode, Claude Code), MinishLab, 2026.
- Documentation Semble — README, section CLI usage et Python API, MinishLab, 2026.
- Spécifications Model Context Protocol (MCP), ressources publiques référencées par le projet Semble.
- Spécifications Model2Vec et modèle potion-code-16M, ressources référencées par le projet Semble.
- Algorithme BM25 (Robertson, Sparck Jones), littérature classique de la recherche d’information.
- Documentation Chonkie, segmenteur code-aware référencé par Semble.
À lire également sur LagazetteIA : Anthropic et la course aux 1M de tokens, MCP : le protocole qui standardise les outils d’agents, Cursor, Codex, Claude Code : la nouvelle pile du développeur assisté, Embeddings statiques : pourquoi Model2Vec change l’économie du retrieval.
