Dans une application Laravel ancienne, les choix importants ne sont pas toujours consignés dans un guide. Ils se nichent dans les contrôleurs, les modèles, les tests et parfois dans une abstraction que l’équipe a décidé de ne pas créer. Quand un assistant de programmation intervient sans connaître cet historique, il peut proposer du code correct en apparence, mais incompatible avec les habitudes et les contraintes du projet. Laravel Boost répond à ce problème avec une compétence d’audit qui examine le dépôt et suggère des règles propres à l’application.

La démarche ne consiste pas à demander à l’intelligence artificielle de réécrire le logiciel ni de deviner une architecture idéale. Elle vise à repérer, preuves à l’appui, les conventions qui pourraient échapper à un agent lors d’une prochaine modification. Le développeur garde la main : il vérifie les exemples, ajuste la formulation et choisit ce qui sera enregistré. Pour une équipe qui reprend un code peu documenté, cette analyse de code transforme une part de la rétro-ingénierie en instructions partageables, sans confondre les règles métier avec les préférences générales du framework.

En bref

• La compétence infer-conventions de Laravel Boost explore plusieurs dimensions du projet et propose des règles adaptées à son code.
• Une règle utile décrit une décision locale que l’agent pourrait raisonnablement manquer, pas un comportement déjà imposé par Laravel ou un outil de formatage.
• Les propositions s’accompagnent d’exemples à examiner et ne sont enregistrées qu’après validation humaine.
• Les règles approuvées sont conservées dans .ai/rules, en fichiers lisibles et suivis dans le dépôt.
• Les règles peuvent vieillir : leur entretien doit accompagner les changements du logiciel et les revues de code.

Laravel Boost : retrouver les règles cachées dans un code existant

Dans une nouvelle application, une équipe peut consigner ses décisions au fil de leur adoption. Un projet ancien raconte plutôt son histoire à travers des choix répétés : une manière de valider les données, un emplacement réservé à la logique métier ou une représentation particulière des montants. Pour un nouvel arrivant comme pour un assistant de code, ces indices sont précieux, mais ils ne sont pas toujours évidents à distinguer des automatismes du framework.

Boost propose une compétence d’inférence des conventions qui parcourt différentes surfaces du projet : architecture, modèles, contrôleurs, validation, représentation des données et tests. Elle couvre environ 49 dimensions réparties en 10 groupes. Cette exploration sert à formuler des hypothèses vérifiables, pas à certifier que chaque habitude est une bonne pratique.

Pourquoi des détecteurs automatiques ne suffisent pas

Une première approche reposait sur une commande Artisan, boost:infer-conventions, et des détecteurs déterministes. Ils repéraient notamment la casse des clés d’énumération, l’usage de guarded ou fillable, le style des scopes de requête et la syntaxe des règles de validation. Cette méthode était rapide et n’utilisait aucun jeton de modèle, mais chaque nouvelle convention exigeait un détecteur spécifique, avec ses exemples et son estimation de confiance.

La fréquence d’un motif ne dit pas, à elle seule, s’il mérite d’être documenté. Les migrations anonymes, par exemple, sont courantes dans Laravel parce qu’elles correspondent au comportement généré par défaut. À l’inverse, une règle comme « stocker les montants en centimes entiers » peut influer sur les calculs, la validation, la sérialisation et les tests : un agent pourrait facilement choisir une autre représentation.

Le critère décisif est donc la valeur d’une décision pour les tâches futures, et non le nombre d’occurrences. Pour comprendre les enjeux d’une intégration sans refonte générale, des ressources consacrées à la migration et à la documentation du code legacy offrent un éclairage complémentaire.

Cette évolution déplace le travail des règles codées une par une vers une exploration guidée, où les éléments observés restent visibles et discutables.

Audit logiciel : distinguer les décisions du projet des automatismes

La compétence d’audit cherche surtout ce qu’il est pertinent de laisser de côté. Laravel fournit déjà des conventions générales, tandis que Pint, Rector, les linters et les analyseurs statiques prennent en charge de nombreuses règles mécaniques. Répéter ces consignes dans un fichier destiné à l’agent consomme du contexte sans lui apporter d’information supplémentaire.

Une règle de projet doit plutôt préserver une décision particulière. « Les contrôleurs délèguent aux Actions dans app/Actions » indique une destination à suivre. « Les contrôleurs et les Actions interrogent directement Eloquent ; l’application n’a pas de couche Repository » précise une limite tout aussi utile : l’absence d’une abstraction peut faire partie de l’architecture choisie.

Une règle utile est appuyée par des exemples

Le seuil actuel demande au moins trois exemples cohérents, sans contre-exemple significatif. La proposition indique les fichiers qui la justifient. Si les indices sont mélangés, le rapport doit montrer cette diversité plutôt que la masquer derrière une consigne présentée comme certaine.

Cette précaution est essentielle pour la logique décisionnelle enfouie dans l’application. Une équipe peut, par exemple, conserver volontairement une structure que Rector modifierait, pour des raisons de compatibilité. L’outil peut faire ressortir cette exception ; c’est ensuite au développeur de déterminer si elle exprime une contrainte réelle ou une habitude à revoir.

L’analyse ne doit pas devenir une refonte déguisée. Décrire le code tel qu’il fonctionne aujourd’hui permet de séparer la documentation technique des propositions de changement, lesquelles méritent leur propre discussion et leur propre revue.

Les indices observables donnent de l’explicabilité à la proposition : l’équipe peut comprendre pourquoi une règle apparaît et décider si elle représente bien son projet.

Enregistrer les règles de code Laravel après validation humaine

Après examen, le développeur peut rejeter une proposition, en réduire la portée ou en modifier les termes. Une règle approuvée est ensuite transmise à l’outil d’enregistrement de Boost avec trois éléments : un glob qui désigne les fichiers concernés, un titre qui résume la décision et une note qui apporte le contexte nécessaire à l’agent.

Boost écrit les règles sous .ai/rules, dans des fichiers Markdown lisibles, modifiables et versionnés avec l’application. Son dépôt de règles organise les chemins, ajoute la convention puis met à jour l’index au cours d’une même opération testée. Les règles sont ainsi visibles en revue de code, plutôt que conservées dans la mémoire personnelle d’un membre de l’équipe.

Guidelines, compétences et règles : trois rôles distincts

Boost distingue les consignes générales de Laravel, les compétences qui décrivent des procédures spécialisées et les règles propres à une application. Une recommandation valable dans de nombreux projets a sa place dans les guidelines ; un processus approfondi relève d’une compétence ; une décision locale appartient aux règles du dépôt.

Cette séparation évite de charger chaque tâche avec des informations qui ne la concernent pas. Des instructions sur les modèles peuvent, par exemple, viser les fichiers de app/Models/, tandis que celles dédiées aux tests s’appliquent à tests/. Un mécanisme expérimental permet aussi de limiter certaines consignes internes de Boost, mais il reste désactivé par défaut et hors de la documentation publique.

Ces règles partagées diffèrent de la mémoire d’un agent conservée pour une seule personne : elles voyagent avec le dépôt et peuvent servir aux outils utilisés par toute l’équipe. Pour approfondir les méthodes d’audit de code assisté par l’IA, il est également utile de garder en tête que les modèles prédictifs proposent des pistes à partir d’indices, mais ne remplacent pas la validation de leur contexte.

Le bon emplacement d’une consigne réduit le bruit et aide l’agent à appliquer la bonne information au bon moment.

Règles métier et code legacy : maintenir les conventions dans le temps

Une règle peut devenir obsolète lorsque le code évolue. Si une équipe remplace une couche d’accès aux données ou modifie la représentation d’un montant, une ancienne instruction peut pousser l’agent à reproduire l’architecture précédente. Boost ne dispose pas encore d’un audit automatique de péremption : la revue de code reste donc le principal moment pour actualiser les règles associées aux changements.

Un futur contrôle pourrait vérifier que les fichiers cités existent toujours, signaler un glob qui ne correspond plus à aucun fichier ou relancer l’inférence en mode rapport. Même dans ce cas, toute modification devrait être revue par un développeur. Les algorithmes peuvent accélérer le repérage, mais l’intention derrière une règle métier doit rester comprise par l’équipe qui la porte.

Un exemple concret : éviter une mauvaise représentation des données

Dans une application de réservation, les prix peuvent être enregistrés en centimes pour éviter les imprécisions des nombres décimaux. Si cette décision apparaît dans plusieurs modèles et tests, une règle bien formulée peut rappeler à un agent de conserver cette représentation dans la validation et les réponses de l’API, au lieu d’introduire des montants flottants.

La règle ne remplace ni les tests ni les contrôles automatiques ; elle transmet un choix transversal qu’un outil de formatage ne peut pas déduire. Pour approfondir la façon dont l’IA peut aider à comprendre une base existante sans prendre son interprétation pour une certitude, la ressource sur la compréhension du code existant avec l’IA complète bien cette approche.

En pratique, Boost rend les décisions visibles, mais leur pertinence dépend toujours d’une vérification régulière par les personnes qui connaissent le logiciel.