Claude Code pour un développeur Laravel : workflow, CLAUDE.md et garde-fous

Un assistant de code comme Claude Code peut lire un projet, proposer un plan, modifier plusieurs fichiers et lancer les tests. C'est puissant, et c'est précisément pourquoi il faut l'encadrer : sans règles, il produit du code plausible mais qui ne respecte ni vos conventions, ni votre architecture. Voici un workflow pratique pour l'utiliser sur un projet Laravel en gardant la main.

1. Donner du contexte avec un fichier CLAUDE.md

Placez à la racine du projet un fichier CLAUDE.md : il est lu au début de chaque session et sert de mémoire du projet. Mieux vaut qu'il soit court et précis. Un contenu utile pour Laravel :

• les commandes à connaître (lancer les tests, le formateur, l'analyse statique, le serveur de développement) ;
• l'architecture : où va la logique métier (actions, services), comment sont nommés les modèles et les ressources ;
• les conventions : style de code, versions de PHP et de Laravel, packages standards du projet ;
• les interdits : ne jamais modifier une migration déjà déployée, ne jamais toucher au fichier .env, ne jamais lancer de commande destructrice sur la base.

Si vous ajoutez un contexte propre à Laravel (documentation de la version installée, structure de la base, état de l'application), l'outil Laravel Boost le fournit à l'assistant de façon structurée, et le panorama Laravel et MCP en explique le principe.

2. Demander un plan avant d'écrire du code

Pour toute tâche qui dépasse une correction triviale, commencez par un mode plan : l'assistant explore le code, puis propose les fichiers concernés et les étapes. Relisez ce plan, corrigez-le, puis seulement validez l'exécution. Cette étape coûte deux minutes et évite l'essentiel des mauvaises directions. Formulez des demandes précises : « ajouter une pagination à la liste des commandes de l'API, avec test de fonctionnalité » vaut mieux que « améliore la liste ».

3. Faire des tests votre garde-fou principal

Un assistant qui peut lancer vos tests corrige ses propres erreurs ; sans tests, il avance à l'aveugle. Écrivez (ou faites écrire) d'abord un test qui échoue, demandez ensuite l'implémentation, et exigez que la suite passe avant de considérer la tâche terminée. Si votre suite est ancienne ou lente, la migration progressive vers Pest peut l'améliorer. Ajoutez l'analyse statique (PHPStan ou Larastan) et un formateur (Pint) : ils attrapent des erreurs que les tests ne voient pas.

4. Régler les permissions

Ne donnez pas les pleins pouvoirs par défaut. Autorisez explicitement les commandes sûres (lecture de fichiers, lancement des tests, formateur) et exigez une validation pour tout le reste : installation de dépendances, migrations, suppression de fichiers, accès réseau. Des hooks peuvent aussi lancer automatiquement le formateur après chaque modification. Travaillez toujours sur une branche dédiée, avec un dépôt propre au départ, pour que tout retour arrière soit simple.

5. Protéger les secrets et les données

• Ne donnez jamais à l'assistant d'identifiants de production ni de clés d'API réelles.
• Travaillez avec une base de développement contenant des données fictives, pas des données clients.
• Vérifiez que les fichiers sensibles (.env, clés privées) sont exclus du contexte et du dépôt.
• Appliquez à l'assistant le même principe de moindre privilège qu'à un nouveau collaborateur — c'est aussi l'esprit de nos recommandations pour un serveur MCP.

6. Relire le diff comme celui d'un collègue

Le code produit par une IA doit être relu avec le même sérieux que celui d'un développeur junior. Dans le diff, cherchez en priorité :

• les requêtes N+1 et les index manquants ;
• la validation et l'autorisation (une route sans policy) ;
• les dépendances ajoutées sans raison, les API inventées qui n'existent pas dans votre version ;
• les modifications hors périmètre : fichiers touchés sans rapport avec la demande.

Faites aussi relire les parties sensibles (authentification, paiements) par un humain, même si les tests passent.

7. Bien choisir ce que l'on délègue

Bien adapté : génération de tests, refactorisations mécaniques, migrations de syntaxe, documentation, exploration d'une base de code inconnue, tâches répétitives. À encadrer fortement : sécurité, logique financière, changements d'architecture, migrations de données en production. Gardez la décision d'architecture ; déléguez l'exécution.

8. Capitaliser

Chaque fois que l'assistant répète une erreur (mauvaise convention, mauvaise commande), ajoutez la règle correspondante au CLAUDE.md. Avec le temps, le fichier devient une version vivante de vos standards, utile aussi pour l'intégration d'un nouveau développeur. Combinée à une chaîne de déploiement solide — voir notre guide sur le déploiement avec GitHub Actions —, cette discipline permet de gagner du temps sans prendre de risques inconsidérés.

Conclusion

Un assistant de code n'est ni un stagiaire magique ni un danger : c'est un outil dont la valeur dépend du cadre que vous lui donnez. Contexte clair, plan validé, tests comme filet, permissions limitées, relecture systématique : avec ces cinq habitudes, vous gagnez en vitesse tout en conservant la qualité et la maîtrise de votre code.