Agents de code : déléguer la recherche à un modèle local

Les agents de code passent une bonne partie de leur budget à chercher avant d'écrire la moindre ligne. Le 12 octobre, l'équipe française de LightOn a publié ColGrep-Agent, un modèle de 2 milliards de paramètres qui tourne sur le poste du développeur et prend en charge l'exploration du dépôt à la place du modèle frontière. Résultat mesuré sur 624 sessions : 34 % de tokens d'API en moins par rapport à une recherche au grep, pour une précision statistiquement inchangée, mais une latence plus élevée.

Le sujet dépasse l'outil lui-même. Il pose une question que toutes les équipes qui industrialisent des agents finissent par rencontrer : quelles tâches méritent vraiment le modèle le plus cher, et lesquelles peuvent être confiées à un petit modèle spécialisé, en local ?

Le contexte

Un agent de code comme Claude Code, Codex ou OpenCode fonctionne en boucle : il lit la demande, explore le dépôt, ouvre des fichiers, propose une modification, vérifie. La phase d'exploration est la plus coûteuse en contexte. Chaque grep renvoie des dizaines de lignes, chaque fichier ouvert remplit la fenêtre, et tout ce texte est facturé en tokens d'entrée au tarif du modèle principal.

Deux familles d'outils s'affrontent pour cette exploration. La recherche lexicale, grep ou ripgrep, est rapide et exacte, mais elle ne trouve que les mots que l'on tape. La recherche sémantique compare le sens de la question à celui du code : une requête sur des « attributs personnalisés » peut faire remonter une fonction nommée fieldDefinition. ColGrep appartient à la seconde famille, avec une particularité : il s'appuie sur une approche multi-vecteurs, dite à interaction tardive, qui encode chaque token plutôt qu'une fonction entière.

Comment ColGrep-Agent découpe le travail

Un moteur de recherche et un petit agent. L'ensemble repose sur deux briques publiées dans le dépôt next-plaid, sous licence Apache 2.0. D'abord ColGrep, un moteur de recherche de code qui combine filtrage par expressions régulières et classement sémantique. Il utilise LateOn-Code-edge, un modèle de recherche multi-vecteurs de 17 millions de paramètres. L'index est construit en local (colgrep init) et se met à jour tout seul quand les fichiers changent. Le code ne quitte pas la machine.

Ensuite ColGrep-Agent, un modèle de 2 milliards de paramètres basé sur MiniCPM5-2B. Il dispose de trois outils : la recherche ColGrep, un terminal en lecture seule et un outil de réponse finale. Il a droit à dix tours au maximum par question, et il renvoie à l'agent principal les lignes exactes qui répondent à la question, au lieu de la liste brute de fichiers candidats.

Un entraînement par distillation puis renforcement. LightOn décrit un entraînement en deux temps. D'abord un ajustement supervisé avec Qwen3.5-27B comme modèle enseignant, puis un apprentissage par renforcement avec GRPO (Group Relative Policy Optimization), sur 500 étapes avec 16 trajectoires par tâche. C'est un schéma devenu classique pour les petits modèles agentiques : on apprend d'abord à imiter un grand modèle, puis on optimise directement le résultat de la tâche.

Une intégration par hooks. Côté installation, le binaire s'installe via Homebrew ou un script shell, et colgrep --install-agent télécharge le modèle local, environ 2,5 Go au format GGUF. L'intégration la plus complète vise Claude Code, via ses hooks (colgrep --install-claude-code). Des intégrations plus basiques existent pour OpenCode, Codex et Hermes. Point notable : l'intégration ne force pas l'agent principal à déléguer, elle lui suggère l'outil de recherche dans son contexte.

Ce que disent les chiffres sur les agents de code

Le gain : un tiers de tokens en moins. Le banc de test principal porte sur 52 questions réparties sur 13 dépôts, soit 624 sessions. En déléguant la recherche à l'agent local, les tokens d'API baissent de 34 % par rapport au grep, avec un intervalle de confiance de 28 à 40 %. En tenant compte du cache de prompt, le coût d'API baisse de 40 %. Et 88 % des questions consomment moins de tokens. Le nombre moyen de tours de l'agent principal passe de 5,5 à 3,9.

Sur le benchmark public Semble (1 251 questions), l'agent renvoie en moyenne 1,7 fichier contre 9,8 pour ColGrep seul, avec une précision@10 de 0,744. C'est là que se joue l'économie : moins de fichiers renvoyés, c'est moins de texte injecté dans la fenêtre du modèle cher.

Les limites : précision et latence. LightOn ne cache pas les contreparties. La précision passe de 83,3 % avec grep à 80,8 % avec l'agent, soit 2,6 points de moins. L'écart n'est pas statistiquement significatif, mais l'intervalle de confiance va de -10,9 à +5,1 points, ce qui ne permet pas d'exclure une vraie baisse. Un juge automatique a toutefois préféré les traces de l'agent dans 75 % des cas.

La latence, elle, augmente nettement : 21,6 secondes par question contre 13,0 avec grep, soit 8,6 secondes de plus. L'appel médian à l'agent local prend 7 secondes. Pour un développeur qui attend devant son terminal, c'est perceptible. Pour une chaîne d'agents qui tourne en tâche de fond, c'est probablement acceptable.

Grep, sémantique ou agent : choisir l'outil de recherche des agents de code

Les trois approches ne s'excluent pas, et le bon choix dépend de la question posée.

Quand grep reste imbattable

Quand on connaît le nom exact d'une fonction, d'une variable ou d'un message d'erreur, la recherche lexicale reste la plus rapide et la plus fiable. Elle ne demande ni index, ni modèle, ni mémoire supplémentaire. Les chiffres de LightOn le confirment en creux : sur leur banc de test, grep garde un léger avantage de précision et répond plus vite. Pour une base de code bien nommée et une question précise, ajouter une couche sémantique n'apporte pas grand-chose.

Quand la recherche sémantique prend le relais

Elle devient utile dès que la question est formulée en langage naturel, ou que le vocabulaire du code diffère de celui du métier. C'est le cas typique des grands dépôts hérités, où la même notion porte trois noms différents selon l'époque d'écriture. Une recherche sémantique seule renvoie cependant beaucoup de candidats : près de dix fichiers en moyenne sur le benchmark Semble. C'est utile pour un humain qui parcourt la liste, beaucoup moins pour un agent qui paie chaque fichier lu.

Quand un agent de recherche se justifie

L'agent ajoute une étape de tri : il lit les candidats et ne remonte que les lignes pertinentes. C'est ce filtrage qui fait baisser la facture du modèle principal. Le coût se paie en latence et en complexité d'exploitation. Il se justifie surtout sur les grands dépôts, pour les questions exploratoires, et dans les usages où l'agent principal tourne longtemps sans intervention humaine.

Ce que ça change pour les équipes IA

Le premier enseignement est économique. Sur un agent de code utilisé toute la journée par une équipe, la recherche dans le dépôt représente un poste de dépense réel. Un tiers de tokens en moins sur ces sessions, c'est une économie qui se mesure sur la facture mensuelle. Avant d'adopter l'outil, il faut pourtant mesurer sur vos propres dépôts : 52 questions sur 13 dépôts, c'est un échantillon honnête mais modeste, et vos bases de code ne ressemblent pas forcément à celles du test.

Le deuxième enseignement est architectural. ColGrep-Agent illustre un patron qui va se généraliser : le routage des sous-tâches vers des modèles spécialisés. Le modèle frontière garde le raisonnement et l'écriture, un petit modèle local gère l'exploration. On retrouve la même logique dans les passerelles qui orientent les requêtes simples vers des modèles moins chers. Pour une équipe MLOps, cela veut dire de nouveaux composants à exploiter : un modèle de 2,5 Go à distribuer sur les postes, un index à maintenir, une version à suivre.

Le troisième enseignement concerne la confidentialité. L'index et l'agent tournent en local, le code ne sort pas de la machine pour la phase de recherche. Pour des clients soumis à des contraintes de souveraineté, c'est un argument. Il faut toutefois rester lucide : les extraits renvoyés à l'agent principal partent, eux, vers l'API du fournisseur. Le gain porte sur le volume envoyé, pas sur le principe.

Enfin, il faut instrumenter. Si vous testez ce type d'outil, mesurez trois choses avant et après : les tokens d'entrée par session, le taux de tâches réussies et le temps de réponse perçu. Sans ces mesures, impossible de savoir si les 8 secondes de latence en plus valent les tokens économisés dans votre contexte. C'est exactement le genre d'arbitrage que les équipes qui industrialisent des agents de code doivent rendre visible dans leurs tableaux de bord.

En bref

• ColGrep-Agent, publié par LightOn le 12 octobre 2026, délègue la recherche de code à un modèle local de 2 milliards de paramètres, sous licence Apache 2.0.
• Sur 624 sessions, il réduit les tokens d'API de 34 % (40 % en coût avec cache) par rapport au grep.
• La précision baisse de 2,6 points sans écart significatif, mais la latence augmente de 8,6 secondes par question.
• L'intégration la plus aboutie vise Claude Code via les hooks ; OpenCode, Codex et Hermes ont un support basique.
• Pour les agents de code en production, le patron à retenir est le routage des sous-tâches vers de petits modèles spécialisés, à mesurer sur vos propres dépôts.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by Mohammad Rahmani on Unsplash.