Pourquoi la recherche de code économe en jetons est importante pour les agents IA

Farah Rahman avait un problème familier à Doha : un rapport de bug client, un fil Slack à minuit et une base de code de 1,8 million de lignes réparties sur 43 dépôts. Elle a demandé à un agent de remonter l’origine d’un échec de paiement. Au premier passage, l’outil a avalé tellement de tokens que le modèle a perdu le fil. Puis il a renvoyé une réponse à moitié juste, présentée avec assurance.

C’est exactement le genre de désordre que Semble essaie de corriger. Son argument - une recherche de code pour agents qui utilise 98 % de tokens en moins que grep - semble presque insolent. Mais derrière le titre se cache un vrai changement : la recherche de code ne consiste plus seulement à trouver du texte rapidement. Il s’agit de fournir aux machines uniquement le mince fragment de source dont elles ont besoin. Dans une forme qu’elles peuvent raisonner sans exploser le budget ni le contexte.

Honnêtement, c’est important parce que l’ancien flux de travail était conçu pour des humains parcourant des terminaux. Les agents ne survolent pas. Ils ingèrent. Et lorsqu’ils ingèrent mal, chaque action en aval devient plus fragile : génération de patchs, analyse des causes racines, sélection de tests, corrections de documentation, voire revue de sécurité.

Pourquoi c’est important maintenant

Deux choses ont changé presque en même temps. D’abord, les équipes ont commencé à intégrer directement des LLMs dans les workflows d’ingénierie, des assistants dans l’IDE aux bots autonomes de triage. Ensuite, le coût du contexte est devenu douloureusement visible. Ça vous parle ? Les longs prompts ne sont pas seulement coûteux ; ils sont fragiles. Si un agent doit inspecter un monorepo, quelques mauvaises étapes de récupération peuvent gaspiller toute une exécution.

Parallèlement, les attentes en matière de recherche ont évolué. Les développeurs veulent toujours la précision de grep, mais les agents ont besoin de plus qu’une simple correspondance exacte de chaînes. Ils ont besoin d’un filtrage sémantique, d’un regroupement sensible aux symboles et d’assez de structure pour éviter de halluciner à partir d’extraits hors sujet. Semble se situe précisément dans cet espace intermédiaire.

L’idée centrale : chercher pour le modèle, pas seulement pour l’ingénieur

grep traditionnel est brillant dans une chose : faire correspondre du texte. Il est aussi d’une brutalité littérale. Si votre bug s’exprime par une fonction renommée, un fichier généré ou un symbole enveloppé dans cinq couches, grep peut être aveugle, à moins que l’humain sache exactement quelle aiguille viser.

La recherche de code pour agents devrait fonctionner différemment. Elle devrait réduire un vaste dépôt en preuves compactes et riches en signal. Cela signifie classer selon la pertinence probable. Retourner la structure environnante, et éliminer le boilerplate répété qu’un œil humain pourrait ignorer mais qu’un modèle va volontiers consommer en tokens.

Le point plus profond, c’est que les tokens sont désormais une ressource d’ingénierie rare. Pas au sens abstrait. Littéralement. Chaque bloc de fichier supplémentaire donné à un agent peut modifier la latence, le coût et la qualité de la réponse. C’est pourquoi un outil qui revendique 98 % de tokens en moins que grep est intéressant : non pas parce que grep est mauvais, mais parce que grep n’a jamais été conçu comme un plan de régime pour LLM.

En pratique, un meilleur système de recherche de code pour agents fait généralement bien quelques choses :

• Indexe les symboles, pas seulement les lignes. Les fonctions, classes, imports et références sont plus faciles à résumer pour les agents que de simples blocs de texte.
• Classe selon le contexte, pas seulement selon le nombre de correspondances. Une seule occurrence de grande valeur près d’un test en échec peut compter davantage que 27 occurrences dans de la documentation générée.
• Compresse agressivement. Les en-têtes de licence répétés, le code externalisé et les constantes dupliquées ne devraient pas dominer le prompt.
• Retourne des extraits structurés. Le chemin du fichier, le nom du symbole, l’intervalle et les indices de dépendance aident le modèle à raisonner sans relire tout l’arbre.
• Préserve la traçabilité. Une bonne recherche pour agents est vérifiable. Vous devriez pouvoir voir pourquoi un extrait a été choisi.
• S’intègre bien aux outils. La meilleure couche de recherche s’insère dans CI, les IDE et les workflows de terminal plutôt que d’imposer un rituel séparé.

Si un modèle ne peut pas expliquer pourquoi il a choisi un fichier, vous ne lui faites probablement pas assez confiance pour modifier ce fichier.

Il y a aussi un gain subtil en ergonomie. Les humains utilisent la recherche pour s’orienter. Les agents utilisent la recherche pour générer des actions. Ce n’est pas la même tâche. Un développeur peut jeter un œil à 12 résultats bruyants et savoir quand même où aller. Un agent, en revanche, peut propager avec assurance une mauvaise hypothèse dans tout un patch si la couche de récupération est bancale.

L’affirmation de Semble sur la réduction des tokens doit donc être lue comme un indicateur de quelque chose de plus large : une meilleure hygiène de récupération. Moins de bruit signifie moins de surface d’hallucination. Moins de bruit signifie aussi plus d’espace pour que le modèle voie les véritables invariants du code. Et c’est de là que viennent les changements utiles.

À quoi cela ressemble en pratique

Kenji Silva, analyste de données à Cracovie, en Pologne, aidait son équipe à déboguer un pipeline de tarification qui touchait 14 services et 9 modèles SQL. Une recherche classique a renvoyé 311 correspondances pour une seule chaîne d’erreur. Un workflow de recherche conscient des tokens a réduit l’ensemble de travail à 18 extraits et diminué la taille du prompt de l’agent de 91 %. Il a dit que le premier diagnostic utile est arrivé en 4 minutes au lieu de 29.

Rina Popescu, responsable des opérations à Tallinn, en Estonie, a utilisé un agent pour inspecter des playbooks d’incident dans 6 dépôts internes. L’agent était sans cesse perturbé par du markdown à modèle fixe et des runbooks dupliqués. Une fois son équipe passée à une couche de recherche de code qui dédupliquait le boilerplate, les fausses escalades du bot sont passées de 17 en une semaine à 3, et l’équipe d’astreinte a cessé d’ignorer la moitié de ses alertes.

Farah Rahman, de retour à Doha, a mené un pilote sur un service de paiement avec 248 échecs de test en un mois. Son équipe a demandé à un agent de regrouper les échecs par cause racine. Avec une meilleure couche de recherche, l’agent en a regroupé 193 en 5 schémas et a mis en évidence les chemins de fichiers exacts qui avaient changé. Cela n’a pas supprimé le jugement humain. Cela a supprimé beaucoup de fouilles à l’aveugle.

Erreurs courantes à éviter

• Considérer les économies de tokens comme l’objectif principal. Réduire l’usage des tokens est formidable, mais ce n’est pas le produit. Si la recherche renvoie moins de contexte et de moins bonnes preuves, vous avez seulement compressé l’erreur. Le but n’est pas des prompts plus petits ; c’est des décisions plus fiables.

• Employer une logique de correspondance exacte pour des tâches sémantiques. grep est excellent quand vous connaissez la chaîne, le symbole ou le chemin d’import. Les agents, eux, ne le savent souvent pas. Si votre stratégie de récupération ne fait que copier grep avec une interface plus fine, vous manquerez du code renommé, des dépendances implicites et des artefacts générés.

• Ignorer la structure du dépôt. Une définition de fonction dans un helper de test et le même nom dans le code de production ne sont pas équivalents. Les agents ont besoin d’indices sur la responsabilité, les frontières de module et le sens des appels. Sans cela, ils peuvent corriger la mauvaise couche avec aplomb.

• Fournir trop de boilerplate. Les blocs de licence, les bundles vendor, le JS minifié et les fragments de configuration répétés peuvent consommer le contexte très vite. Les équipes les négligent souvent parce que les humains sautent mentalement ce bruit. Les modèles, eux, ne sautent pas ; ils absorbent.

• Sauter l’évaluation. Une couche de recherche qui semble brillante en démonstration peut échouer sur des charges réelles avec des noms rares, des dépôts polyglottes ou des tests désordonnés. Mesurez la qualité de récupération avec des tâches concrètes : localisation de bug, classement des fichiers et exactitude des réponses, pas seulement la latence des requêtes.

• Supposer que l’agent se corrigera de lui-même. Il ne le fera souvent pas. Si l’étape de récupération pointe vers le mauvais cluster de fichiers, le modèle peut bâtir une histoire nette mais fausse à partir de cela. Une bonne recherche est la première ligne de défense, pas une amélioration facultative.

Une liste de contrôle pratique

1. Commencez par un seul workflow douloureux. Choisissez une tâche comme le triage de bugs, l’analyse d’échecs de tests ou le suivi des dépendances. Ne cherchez pas à tout faire avant de savoir quelle douleur de recherche compte le plus.

2. Mesurez la taille du prompt avant et après. Suivez les tokens d’entrée, la qualité de sortie et le temps jusqu’à la première réponse exploitable. Si vous ne pouvez pas nommer la base de départ, vous ne pouvez pas prouver l’amélioration.

3. Journalisez la raison de chaque extrait renvoyé. Conservez le chemin du fichier, le symbole et le signal de pertinence. La débogabilité compte quand un modèle fait un saut étrange.

4. Éliminez tôt le poids mort. Excluez les répertoires vendor, les artefacts de build et les fichiers générés dupliqués. C’est peu coûteux et souvent immédiatement rentable.

5. Préférez une récupération structurée à des dumps de texte brut. Donnez à l’agent un paquet compact : nom du symbole, lignes environnantes et indices de dépendance. Cela vaut généralement mieux que de coller des fichiers entiers.

6. Testez avec des requêtes laides. Essayez des fonctions renommées, des messages d’erreur partiels et des descriptions vagues comme « le truc du checkout casse après retry ». Les agents réels voient du désordre, pas des mots-clés parfaits.

7. Comparez honnêtement avec grep. grep reste gagnant pour de nombreuses tâches humaines. Voyez où la nouvelle recherche aide un agent et où l’ancien outil reste plus rapide et plus simple.

8. Surveillez la fausse confiance. Si l’agent devient plus fluide mais moins précis, resserrez la récupération et exigez des citations renvoyant aux segments source.

Quand ne pas faire cela

Toutes les équipes n’ont pas besoin d’une couche de recherche pensée d’abord pour les agents. Si votre dépôt est petit, votre stack est propre et vos tâches sont surtout pilotées par des humains, grep plus une recherche IDE correcte peut suffire. Une récupération sophistiquée peut devenir du théâtre quand le vrai goulot d’étranglement est la compréhension du produit, pas la localisation du fichier.

C’est aussi le mauvais choix si vous n’avez pas assez de rigueur opérationnelle pour évaluer les résultats. Un moteur de recherche économe en tokens peut rendre les expériences moins coûteuses, ce qui est appréciable, mais il peut aussi rendre les mauvais comportements des agents moins coûteux. Si personne n’examine la qualité de la récupération, vous risquez seulement d’automatiser la confusion à moindre coût.

Pour aller plus loin

• https://owasp.org/www-project-top-ten/ - pour les bases de sécurité qui restent importantes lorsque les agents touchent au code
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions - un bon rappel de ce que fait réellement la recherche de type grep en coulisses
• https://en.wikipedia.org/wiki/Information_retrieval - le champ plus large derrière le classement, la pertinence et l’évaluation de la recherche

Fwiw, la partie intéressante de Semble n’est pas le chiffre marketing, même si 98 % de tokens en moins fait un bon titre. C’est l’indice que la recherche de code est reconstruite d’abord pour les lecteurs machines, ensuite pour les lecteurs humains, et que ce changement va remodeler la manière dont les équipes déboguent, corrigent et automatisent leurs logiciels. La question n’est plus de savoir si les agents peuvent chercher du code - c’est de savoir si votre couche de recherche les aide à penser clairement ou se contente de leur donner encore plus de bruit.