veilletech.fr
4 sept. Feed du jour
#04 LARAVEL Article

Boost supprime sa recherche sémantique

Quarante fichiers Markdown. grep suffisait depuis le début.

L'auteur de Laravel Boost raconte pourquoi il a supprimé, cinq jours après l'avoir écrite, la recherche sémantique qui devait donner une mémoire aux agents. À la place : des fichiers Markdown dans .ai/rules et un index à deux colonnes régénéré à chaque écriture, que l'agent recoupe avec le chemin du fichier qu'il modifie. Le tout est activé par défaut dans Boost.

3 min de lectureavancévidéo 1:11
Partager
Sommaire5 sections
  1. Le problème posé
  2. La solution savante, supprimée en cinq jours
  3. Ce qui a réellement fonctionné
  4. Les limites, dites par l'auteur
  5. À retenir

Le problème posé

Un agent de code répète l'erreur que l'équipe a corrigée il y a deux ans : il étend le contrôleur du framework et rate le scope de tenant, choisit un flottant alors que les montants sont stockés en centimes, réintroduit une couche repository supprimée depuis longtemps. Ces conventions existent, mais nulle part sous une forme durable.

La réponse habituelle — tout écrire dans CLAUDE.md ou AGENTS.md — se paie à chaque prompt : les règles de migration sont chargées pendant un travail Livewire, les règles de test back pendant l'édition d'un composant front. C'est l'objet de l'issue #606 de Boost.

Deux repères sont cités à l'appui : la documentation de Claude Code vise ~200 lignes pour CLAUDE.md, et le banc IFScale (arXiv 2507.11538) mesure que, à 500 instructions, les meilleurs modèles n'en suivent plus que 68 %.

La solution savante, supprimée en cinq jours

La première version était une couche de « mémoire sémantique » : deux outils MCP (memory-search, memory-write) adossés à un MemoryRepository de 359 lignes. Elle a été retirée cinq jours après avoir été écrite.

L'argument est dimensionnel, pas idéologique. Une application Laravel mature accumule quelques dizaines de fichiers de convention courts. Quelques dizaines de fichiers ne justifient ni embeddings, ni index vectoriel, ni stratégie d'invalidation — surtout quand l'index peut diverger du Markdown qu'il décrit, ce qui ajoute un mode de panne à un problème que ls et grep traitent déjà. La recommandation du SDK d'Anthropic va dans le même sens : commencer par la recherche agentique, ajouter le sémantique quand l'échelle l'impose.

Ce qui a réellement fonctionné

Deuxième tentative : un dossier .ai/rules, chaque fichier déclarant les chemins qu'il couvre. Les agents l'ignoraient, surtout les petits modèles — on leur demandait de juger la pertinence d'un dossier avant de l'avoir lu.

D'où la version retenue : un index à deux colonnes, .ai/rules/index.md, régénéré à chaque écriture. Glob à gauche, fichier de règles à droite. Il est assez court pour tenir dans les instructions de départ, et la recherche devient mécanique :

  1. identifier le fichier en cours d'édition ;
  2. faire correspondre son chemin à la première colonne ;
  3. lire le fichier nommé en deuxième colonne ;
  4. appliquer ces règles pendant la planification et l'édition.

L'écriture passe par un outil MCP record-rule (glob, title, note), et RuleRepository::write() dérive l'aire depuis la partie stable du glob, fusionne le glob dans le frontmatter, ajoute la règle puis reconstruit l'index. Pour les conventions transverses — le stockage des montants touche modèle, action, requête et test — Boost demande en plus un grep -rin sur .ai/rules.

Les limites, dites par l'auteur

À retenir

  1. Avant d'installer un RAG, compter les documents. À quelques dizaines de fichiers, grep gagne — sans index à invalider.
  2. Ne demandez pas à un agent de juger la pertinence d'un dossier qu'il n'a pas lu : donnez-lui une table courte, il fera la correspondance.
  3. Les project rules sont activées par défaut dans Laravel Boost ; les fichiers générés restent lisibles et relisibles en revue de code.

Source : Laravel