Un agent de programmation peut reproduire une erreur que l’équipe a déjà corrigée : oublier le périmètre d’un tenant, stocker un prix en nombre décimal alors que l’application utilise des centimes entiers, ou réintroduire une couche d’accès aux données abandonnée depuis longtemps. Ces écarts viennent souvent de conventions présentes dans l’histoire du code, mais absentes du contexte immédiat de l’agent. La question est alors moins de lui donner davantage d’instructions que de lui permettre de retrouver les bonnes au bon moment.

Un fichier Markdown est un format de texte lisible, pratique pour consigner ces règles et les versionner avec le projet. Une mémoire sémantique, dans le contexte des agents, désigne plutôt une méthode de recherche qui tente de retrouver des informations selon leur sens. Les deux approches peuvent contribuer à une base de connaissances, mais elles ne répondent pas au même besoin : l’une organise le contenu, l’autre cherche à le retrouver. Dans Laravel Boost, une solution fondée sur des règles Markdown et un index généré illustre une voie plus simple qu’un moteur vectoriel pour les projets qui n’ont que quelques dizaines de conventions.

En bref

• Markdown est un format de stockage et de structuration des règles, pas un système de recherche à lui seul.

• La recherche sémantique peut aider à retrouver des notions formulées différemment, mais elle ajoute index, maintenance et risques de décalage.

• Un index de chemins, complété par une recherche textuelle, suffit souvent pour une collection modeste de conventions de projet.

• La relecture humaine reste essentielle : une règle mémorisée peut devenir obsolète après une évolution du code.

Mémoire sémantique et fichier Markdown : deux fonctions différentes

Le Markdown structure un document avec des éléments simples — titres, listes, liens et emphase — sans imposer une mise en page complexe. Sa lisibilité facilite la revue dans une pull request et sa simplicité favorise le stockage des connaissances dans le dépôt du projet. Un guide sur le langage Markdown rappelle qu’il s’agit d’un balisage léger, conçu pour rester compréhensible même sans rendu graphique.

La mémoire sémantique, au sens cognitif, renvoie aux connaissances générales stockées et mobilisées par une personne ; en intelligence artificielle, l’expression désigne souvent des méthodes qui rapprochent une question de contenus similaires par leur signification. Ces deux sens ne doivent pas être confondus avec le simple fait d’enregistrer des règles dans un fichier. Pour situer le terme, on peut consulter cette présentation de la mémoire sémantique.

Dans une application Laravel fictive, l’équipe de « Maison Claire » a fixé une règle : les montants sont conservés en centimes entiers. Le fichier la rend durable et révisable ; un système de récupération, lui, doit permettre à l’agent de la retrouver lorsqu’il modifie une commande, un modèle ou un test.

Pourquoi une base de connaissances ne doit pas tout charger à chaque tâche

Placer toutes les consignes dans un unique fichier de démarrage paraît pratique. Mais si l’agent reçoit systématiquement les règles de migration pendant une modification Livewire, ou les consignes de tests backend pour un composant d’interface, le contexte s’alourdit sans aider la tâche. Cette surcharge, parfois appelée coût de contexte, peut diluer les instructions réellement utiles.

Laravel Boost fournit déjà des recommandations liées au framework dans les fichiers d’instructions utilisés par les agents. Les conventions propres à un projet — contrôleur de base, organisation des domaines, stratégie de tests ou représentation des prix — gagnent à rester disponibles sans être toutes injectées en permanence. Une organisation de l’information par fichiers permet de conserver ces règles sans transformer chaque requête en inventaire complet.

Par exemple, l’équipe de Maison Claire peut réserver un fichier aux règles de facturation et un autre aux tests de fonctionnalités. L’agent n’a pas besoin de relire toute la base de connaissances avant chaque modification : il lui faut un chemin fiable vers la consigne pertinente.

Index Markdown et recherche contextuelle : une solution légère pour Laravel Boost

Une première piste consiste à créer une couche de « mémoire sémantique » avec des outils de recherche, des embeddings et un index vectoriel. Pour quelques dizaines de notes courtes, cette architecture peut toutefois coûter plus cher à maintenir qu’à utiliser : l’index doit rester synchronisé avec les fichiers, et son contenu peut diverger si une règle est modifiée sans régénération.

Dans l’approche présentée pour Boost, les règles restent dans des fichiers Markdown sous un dossier dédié, tandis qu’un index concis indique quels fichiers concernent quels chemins. À chaque mise à jour d’une règle, l’index est régénéré. L’agent peut alors comparer le fichier qu’il s’apprête à modifier avec les motifs de chemins et ouvrir uniquement la consigne correspondante.

Cette recherche contextuelle s’appuie aussi sur une recherche textuelle, par exemple avec grep, pour les concepts transversaux. La règle sur les montants en centimes peut concerner à la fois un modèle, une action, une requête et un test : une recherche du terme « montant » complète alors le repérage par chemin. La récupération d’informations combine ainsi deux gestes simples, adaptés à un corpus réduit.

Comment une règle de projet est enregistrée et retrouvée

Lorsqu’un développeur demande à l’agent de mémoriser une convention, Boost peut enregistrer un motif de fichiers, un titre et une note. Le système déduit une catégorie à partir du chemin, crée ou complète le fichier approprié, puis met à jour l’index. La règle et son pointeur évoluent ensemble, ce qui rend le changement lisible et vérifiable lors de la revue de code.

Le parcours est direct : l’agent identifie le fichier concerné, repère le motif correspondant dans l’index, lit la règle associée et l’applique pendant la planification et la modification. Les liens entre les concepts se construisent par les chemins, les termes recherchés et les documents reliés, sans exiger un système vectoriel pour chaque petit dépôt.

• Une règle de facturation peut viser les modèles, actions et tests qui manipulent les montants.

• Une consigne de contrôleur peut s’appliquer à une zone précise de l’application grâce à un motif de chemin.

• Une recherche textuelle permet de retrouver une règle dont le sujet traverse plusieurs répertoires.

Cette méthode ne prétend pas remplacer la recherche sémantique dans tous les cas. Quand une collection devient vaste, que le vocabulaire varie fortement ou que les notions sont difficiles à repérer par mots et chemins, un mécanisme spécialisé peut apporter un réel bénéfice. Pour approfondir la syntaxe et l’usage du format, le vademecum Markdown présente des repères pratiques de structuration.

Gestion de la mémoire : maintenir des règles fiables dans le temps

Une règle enregistrée n’est pas nécessairement vraie pour toujours. L’application peut évoluer, adopter une nouvelle architecture ou modifier sa politique de stockage ; une ancienne consigne risque alors d’orienter l’agent vers une solution dépassée. La gestion de la mémoire comprend donc aussi la vérification et la suppression des règles obsolètes.

Le format texte facilite cette discipline : une convention se lit, se discute et se corrige dans le même dépôt que le code. Une équipe peut demander que chaque ajout précise son périmètre, son motif et, si nécessaire, un exemple. Les ressources consacrées à la mémoire organisée en fichiers soulignent également l’intérêt de notes courtes, bien classées et reliées à un usage identifiable.

Pour une équipe Laravel, le choix dépend donc surtout du volume et de la nature des conventions. Quelques dizaines de règles stables se prêtent bien aux fichiers Markdown, à un index généré et à grep ; une mémoire sémantique devient plus pertinente lorsque la recherche par chemins et mots-clés ne suffit plus. Dans les deux cas, la valeur vient d’abord de règles précises, partagées et régulièrement relues.