Vous avez engagé un prestataire pour développer votre application Laravel. La démo fonctionne, les écrans se chargent et la facture est en route. Mais ce qui se trouve sous le capot est une autre question, que la plupart des équipes ne se posent qu’une fois que quelque chose a cessé de fonctionner.
Ce manque de confiance est la raison pour laquelle nous avons élaboré ce guide. La liste ci-dessous est la même que celle que nos auditeurs utilisent lors de l’examen des bases de code Laravel, et elle reflète le cadre de chaque revue de code Laravel que nous effectuons pour nos clients. De nombreuses équipes héritent d’une base de code Laravel plutôt que de la remettre en question. Exécutez donc les étapes ci-dessous avant votre prochaine remise ou publication, et vous identifierez ce qui coûte le plus cher à corriger plus tard.
Normes de codage Laravel (PSR-12)
Un code qui ignore les conventions est difficile à lire, difficile à intégrer pour les nouveaux développeurs, et un aimant à bugs. PSR-12 est la norme PHP-FIG que l’écosystème Laravel suit par défaut, et une revue commence ici car toutes les vérifications ultérieures s’appuient sur une base de code que vous pouvez lire. Nous considérons cette couche comme un prérequis, pas un avantage.
Ce que nous vérifions dans le formatage et la dénomination
Trois modèles que nous signalons en premier lors de l’ouverture d’une nouvelle base de code :
- Indentation mixte, lignes de plus de 120 caractères, aucun type hint nulle part.
- Modèles nommés au pluriel (Users au lieu de User), contrôleurs sans le suffixe Controller.
- Colonnes en snake_case à côté de colonnes en camelCase dans la même migration.
Une passe d’audit propre s’attend à une indentation de 4 espaces, des modèles en PascalCase, des méthodes en camelCase, des colonnes en snake_case, des noms de table au pluriel, et des type hints sur chaque paramètre et valeur de retour. Les blocs PHPDoc devraient expliquer le pourquoi sur les méthodes publiques.
Pint et Larastan dans CI
Les outils appliquent les normes de codage Laravel afin que les auditeurs puissent se concentrer sur la logique. Pint est le formateur officiel de Laravel, et Larastan ajoute une analyse statique sensible à Laravel par-dessus PHPStan. Les deux devraient s’exécuter dans l’intégration continue, car les conventions ne tiennent que lorsque le pipeline bloque les fusions qui les enfreignent.
Une étape CI minimale ressemble à ceci :
vendor/bin/pint --test
vendor/bin/phpstan analyse --memory-limit=2GLorsque l’une ou l’autre commande échoue, la pull request est bloquée. Cette seule règle empêche la plupart des dérives de style dans les équipes de toute taille.
Code propre et architecture
Laravel permet d’expédier rapidement, ce qui est à la fois sa force et son piège. De nombreuses bases de code que nous auditons ont livré un MVP fonctionnel avec une logique répartie sur les contrôleurs, les modèles et les vues Blade, et le nettoyage ultérieur coûte plus cher que la construction d’origine. Un code Laravel propre fait la différence entre une base de code que vous pouvez étendre la deuxième année et une que vous devez réécrire.
Contrôleurs légers, classes de service et classes d'action
Le rôle d’un contrôleur est HTTP, rien de plus. Lorsque nous voyons des méthodes de plus de 30 lignes, nous savons que la logique métier a fui et que la solution est une classe de service ou une classe d’action à usage unique.
Mauvais :
public function store(Request $request)
{
$data = $request->validate([
'email' => 'required|email',
'plan' => 'required|in:basic,pro',
]);
$user = User::create($data);
Mail::to($user->email)->send(new WelcomeMail($user));
Subscription::create([
'user_id' => $user->id,
'plan' => $data['plan'],
]);
return redirect()->route('dashboard');
}Mieux :
public function store(RegisterRequest $request, RegisterUser $action)
{
$action->execute($request->validated());
return redirect()->route('dashboard');
}Le contrôleur se lit maintenant en une seule fois. La classe d’action est testable seule et réutilisable à partir d’une commande console ou d’une tâche mise en file d’attente, ce qui rend les refactorisations sûres.
Form Requests et Policies
La validation et l’autorisation intégrées sont deux des raccourcis les plus courants que nous débrouillons. Les règles de validation appartiennent aux classes Form Request, et l’autorisation appartient aux Policies enregistrées auprès du modèle. Ces deux évolutions réduisent la taille des contrôleurs et placent les règles là où les développeurs s’attendent à les trouver, ce qui accélère l’intégration et réduit les bugs introduits par la personne suivante qui touche le fichier.
Si vous continuez à repérer des contrôleurs de 200 lignes aux responsabilités mixtes, le problème est plus profond qu’une simple refactorisation, et il pourrait être temps de faire appel à un consultant en architecture logicielle avant que le nettoyage ne se transforme en réécriture.
Requêtes Eloquent et de base de données
Eloquent est élégant et dangereux à parts égales. L’ORM masque le coût d’une requête, et un foreach négligent déclenche des centaines d’appels à la base de données sous le capot. Les audits de performance commencent souvent dans cette couche.
Requêtes N+1 et chargement anticipé (Eager Loading)
La requête N+1 est le bug de performance Laravel le plus courant que nous trouvons. Le schéma semble innocent à l’écran :
$posts = Post::all();
foreach ($posts as $post) {
echo $post->author->name; // one extra query per post
}La correction se fait avec :
$posts = Post::with('author')->get();
foreach ($posts as $post) {
echo $post->author->name; // no extra queries
}Ajoutez Model::preventLazyLoading() dans votre AppServiceProvider pour les environnements non-production et Laravel lèvera une exception dès que le chargement paresseux se produira. Le bug apparaîtra dans votre suite de tests plutôt que sous charge de production.
Index, affectation de masse et migrations
Trois vérifications au niveau de la base de données que nous effectuons lors de chaque audit :
- Les clés étrangères et les colonnes fréquemment filtrées ont des index.
- Les modèles déclarent $fillable ou $guarded délibérément, de sorte qu’une entrée malveillante ne puisse pas écraser des champs réservés aux administrateurs.
- Les migrations ont des méthodes down() fonctionnelles, de sorte que les annulations ne corrompent pas les données de production.
Le troisième point est plus important que la plupart des équipes ne le réalisent. Une migration sans annulation est une porte à sens unique, et cette porte s’ouvre toujours au pire moment.
Bonnes pratiques de sécurité Laravel
La sécurité est le domaine où les transferts de fournisseurs échouent le plus douloureusement. Selon le IBM Cost of a Data Breach Report 2025, le coût moyen mondial d’une violation de données s’élève désormais à 4,44 millions USD, et à 10,22 millions USD aux États-Unis. Une revue de code est le moment le moins cher pour trouver les failles qui conduisent à ces chiffres.
Environnement, CSRF, XSS et téléversements de fichiers
Ce sont les bonnes pratiques de sécurité Laravel les plus souvent négligées dans nos audits. Une liste de vérification rapide :
- APP_DEBUG=false et APP_ENV=production dans les environnements de production.
- .env exclu du contrôle de version et renvoyant 403 via HTTP.
- Moyenne CSRF activée sur chaque route modifiant l’état.
- Utilisation de Blade {{ }} pour la sortie, avec {!! !!} uniquement après une désinfection explicite.
- Les téléversements de fichiers sont validés pour le type MIME, la taille et l’extension, puis stockés en dehors du répertoire public.
Le OWASP Top 10 couvre les catégories plus larges contre lesquelles ces vérifications défendent. Mapper vos découvertes d’audit aux catégories OWASP donne au rapport une structure que votre équipe de sécurité reconnaîtra.
Authentification, limitation de débit et audits de dépendances
Les mots de passe doivent être hachés avec bcrypt ou Argon2, jamais MD5 ou SHA1. Les API doivent utiliser Laravel Sanctum ou Passport, avec le middleware throttle appliqué aux points d’accès de connexion et de réinitialisation de mot de passe pour arrêter les attaques par force brute. La commande composer audit doit s’exécuter dans l’environnement CI à chaque compilation, afin qu’une vulnérabilité fraîchement publiée dans une dépendance ne reste pas inaperçue pendant des semaines.
Un seul package obsolète peut annuler toutes les autres vérifications de cette liste. C’est pourquoi une revue sans audit de dépendances est incomplète.
Optimisation des performances de Laravel
Les problèmes de performance arrivent rarement sous la forme d’un seul bug. Ils s’accumulent sur plusieurs couches, et une revue met en évidence les couches qui sont silencieusement coûteuses. L’optimisation des performances de Laravel lors d’un audit est un diagnostic, pas une implémentation, de sorte que le rapport vous indique où se situe le coût et pourquoi.
Quelques points que nous vérifions sur chaque projet :
- Les caches de route, de configuration, de vue et d’événement sont chauds en production (php artisan route:cache, config:cache, view:cache, event:cache).
- Les tâches lourdes (envoi d’e-mails, exports, appels API tiers, traitement d’images) sont envoyées aux files d’attente avec un vrai driver comme Redis, pas de manière synchrone.
- Chaque point d’accès de liste est paginé, sans Model::all() sur une table qui grandit.
- Une couche de cache se situe devant les lectures coûteuses, avec des valeurs de durée de vie raisonnables.
- OPcache est activé au niveau PHP.
- Les résultats de Telescope ou Laravel Debugbar depuis staging ont été examinés.
Un schéma courant dans les MVP est de déployer sans aucune des mesures ci-dessus et de découvrir le coût lorsque le trafic double après un lancement. Le compromis est documenté dans notre analyse des coûts cachés qui apparaissent plus tard.
Tests et fiabilité
Une application Laravel sans tests est une application Laravel à une refactorisation de l’indisponibilité de production. Le code source n’a pas besoin de 100% de couverture pour être sûr, mais les chemins critiques en ont absolument besoin. Ce que nous recherchons, c’est une suite Pest ou PHPUnit qui tourne au vert dans l’intégration continue, des tests de fonctionnalités sur chaque flux touchant aux revenus (authentification, paiement, CRUD principal), des factories définies pour les modèles principaux afin que les données de test soient une ligne de code, le trait RefreshDatabase sur chaque test qui touche la base de données, et des API externes mockées plutôt que sollicitées pendant la suite.
Lorsque la suite est manquante ou tourne au rouge, la première bonne étape est de créer des tests de caractérisation autour du comportement actuel, suivis d’une refactorisation. La couverture construite autour d’un contrat figé est la seule que vous pouvez faire confiance plus tard, et les équipes qui sautent cette étape en paient généralement le double, d’abord en confiance, puis en rapports d’incidents.
Dépendances et outillage
Le graphe des dépendances est souvent la partie la plus négligée d’une application Laravel. Les frameworks obsolètes et les packages abandonnés représentent une grande part des vulnérabilités et incompatibilités que nous constatons, et l’utilisation de versions supportées est fortement corrélée à la vélocité de l’équipe dans toutes les enquêtes de développeurs des dernières années.
La liste de contrôle ici est courte mais elle fait mal si vous la sautez. Laravel devrait être sur une version supportée (Laravel 12 a un support de sécurité jusqu’en février 2027). PHP devrait être en 8.3 ou 8.4, pas avant. Le fichier composer.lock devrait être commité et identique sur toutes les machines de développement, l’environnement CI et la production. Il ne devrait y avoir aucun package signalé comme abandonné par composer audit. Pint, Larastan et Pest devraient s’exécuter dans l’environnement CI à chaque push, avec Rector ajouté si vous souhaitez des refactorisations automatiques de mise à niveau entre les versions PHP et Laravel.
Ce que notre liste de vérification de revue de code Laravel révèle lors d'audits réels
Les chiffres racontent mieux l’histoire que les promesses. Au cours du dernier cycle d’audits de notre équipe, nos réviseurs ont enregistré 82 vulnérabilités de sécurité sur 15 projets Laravel et PHP, 27 cas de programmation par copier-coller, et 23 cas de conflits de dépendances suffisamment graves pour bloquer les déploiements. La plupart de ces problèmes se trouvaient dans du code que l’équipe d’origine pensait prêt pour la production.
Top 5 des signaux d'alarme Laravel
Les schémas se répètent lors des audits, et ces cinq problèmes reviennent le plus souvent :
- Contrôleurs « gros » avec validation, logique métier et effets secondaires dans une seule méthode.
- Requêtes N+1 sur les points d’accès du tableau de bord qui n’apparaissent que sous une charge réelle.
- Fuite de .env via APP_DEBUG=true sur une URL de staging exposée à Internet.
- Absence de limitation de débit sur la connexion ou la réinitialisation du mot de passe, laissant la porte ouverte aux attaques par force brute.
- Code généré par IA qui s’exécute dans le scénario idéal et ignore silencieusement les Form Requests, les Policies et les tests.
Lorsqu’un MVP est livré avec plusieurs de ces problèmes, le chemin le plus propre consiste en une revue structurée suivie d’une maintenance Laravel continue plutôt qu’une réécriture complète. Pour les équipes prêtes à faire évoluer la même pile technologique vers un produit payant, nos services de développement Laravel reprennent là où le rapport d’audit s’arrête.
Conclusion
Une checklist d’audit de code Laravel ne remplace pas le jugement d’un ingénieur expérimenté, mais c’est le moyen le moins cher de rendre ce jugement reproductible. Le respect des meilleures pratiques Laravel établies lors de chaque audit, chaque publication et chaque transfert de fournisseur est ce qui distingue une application que vous pouvez faire évoluer d’une application que vous devrez reconstruire. Le travail est rentable dès la première fois où vous évitez un rollback du vendredi soir ou une divulgation de sécurité du lundi matin.
Si vous préférez qu’un second regard examine votre base de code, ou si vous n’avez tout simplement pas la bande passante nécessaire pour effectuer l’audit en interne, contactez-nous et nous évaluerons une revue adaptée à votre pile technologique.
Découvrez comment Redwerk a audité une API backend et a augmenté sa maintenabilité de 80 % grâce à une revue de code structurée.
