Laravel en production : 8 erreurs que je corrige en maintenance

Je passe une bonne partie de mes semaines en interventions de maintenance sur des applications Laravel qui tournent en production. Beaucoup de ces projets ont été développés avec soin : la logique métier est propre, le code est lisible. Et pourtant, dès que l’on passe en production, les mêmes incidents reviennent — comme une mauvaise habitude partagée. Cache oublié, migration modifiée, débogage laissé ouvert... Dans cet article, je partage les 8 erreurs que je corrige le plus souvent lors de la reprise d’un projet Laravel, et les bonnes pratiques qui permettent de les éviter.

Déploiement et cache : les premières causes d’incident

Erreur n°1 — Déployer sans purger le cache. C’est la toute première cause de bugs après une mise en production. Une variable ajoutée dans .env ne prend tout simplement pas effet. Laravel utilise des fichiers de cache pour la configuration, les routes et les vues. Si le projet est déployé sans exécuter php artisan config:cache, ou sans purger les caches existants après une modification, le résultat est incompréhensible pour le client : nouveau domaine, nouvelles clés API, mais l’application répond toujours avec les anciennes valeurs. Le réflexe : tout automatiser dans un script de déploiement unique, qui exécute migrations, caches et optimisation à chaque release.

Erreur n°2 — Faire un git pull en production. Certaines équipes mettent en ligne en se connectant au serveur, en tirant la branche principale puis en lançant manuellement composer install --no-dev. Ça fonctionne... jusqu’au jour où une étape est oubliée. L’usage d’un pipeline de déploiement continu réduit considérablement le risque : tests automatisés, build, migrations et caches y sont exécutés de manière reproductible. En maintenance, c’est souvent la première brique que j’installe pour fiabiliser un projet. Le bénéfice est immédiat : vous retrouvez la capacité de déployer sereinement, même en fin de journée.

Erreur n°3 — Sauter plusieurs versions majeures en une seule fois. Une application restée sur Laravel 8 qui passe directement en Laravel 12 : l’évolution de la structure de fichiers, des dépendances ou du comportement des middlewares peut casser silencieusement des fonctionnalités. La règle que j’applique : monter les versions une par une, avec une batterie de tests minimale à chaque étape. Même si cela prend du temps, c’est toujours plus rapide qu’un débogage à l’aveugle en production.

Migrations et base de données : préserver l’intégrité

Erreur n°4 — Éditer une migration déjà exécutée. Je retrouve cette erreur dans presque toutes les reprises : un développeur ajoute une colonne en modifiant la migration d’origine au lieu d’en créer une nouvelle. En local, tout semble correct. En production, cette migration a déjà été jouée : la modification est ignorée, et l’équipe perd des heures à chercher pourquoi le champ n’existe pas. Une migration est un enregistrement historique. Elle ne se réécrit jamais. On ajoute une nouvelle migration pour chaque évolution de schéma, on rédige une autre migration pour corriger une erreur, mais on ne modifie pas celles qui sont déjà passées.

Erreur n°5 — Migrer sans connaître la volumétrie. Une migration qui s’exécute en quelques secondes sur une base de développement peut bloquer une table de production pendant plusieurs minutes. Ajouter un index, modifier une colonne sur une grosse table, changer le collationnement... Ces opérations méritent d’être testées sur une copie réaliste de la base, ou planifiées pendant une fenêtre de maintenance. C’est un point trop souvent négligé, et pourtant il conditionne la disponibilité de votre application le jour J.

Sécurité en production : trois réflexes essentiels

Erreur n°6 — Laisser le mode débogage activé. APP_DEBUG=true est une invitation au vol de données. Chaque erreur 500 devient une page contenant la stack trace, les variables d’environnement, les identifiants de connexion. Pire : certaines applications laissent aussi des routes de test ou une documentation API accessibles publiquement. Je commence toujours par fermer ces accès, puis je vérifie la configuration du serveur. Un simple fichier .env accessible par erreur peut exposer l’intégralité des secrets du projet.

Erreur n°7 — Stocker les secrets dans le code. Il arrive encore de trouver des clés API ou des identifiants de base de données directement dans les fichiers de configuration versionnés dans Git. C’est un problème de sécurité immédiat, mais aussi un risque collaboratif : trop de personnes peuvent avoir accès au dépôt, surtout quand l’historique Git n’est pas nettoyé. En reprise, je passe systématiquement par les variables d’environnement, je fais tourner les clés exposées et j’interdis — au moins par convention — de committer des valeurs sensibles.

Supervision et maintenance continue : la clé de la sérénité

Erreur n°8 — Ne regarder les logs qu’après l’incident. C’est le point commun de toutes les applications que je reprends en maintenance. Personne ne consulte les logs, excepté quand un bug est signalé. Résultat : une erreur silencieuse s’accumule pendant des semaines avant d’être détectée. Un minimum de supervision change tout :

Cela permet d’intervenir avant que l’utilisateur final ne soit impacté, et de capitaliser sur l’historique des incidents pour améliorer la qualité du code au fil du temps.

Si vous vous reconnaissez dans l’une de ces situations, sachez que ce n’est jamais une fatalité. Une application Laravel peut être fiabilisée avec des méthodes simples : automatiser le déploiement, surveiller les logs, traiter la base de données comme un patrimoine sensible, et maintenir les versions à jour. C’est exactement le type de travail que je réalise au quotidien en maintenance applicative : reprendre un projet existant, corriger les angles morts, et stabiliser l’ensemble pour durer. Vous avez un projet Laravel à sécuriser, optimiser ou faire évoluer ? Le développement Laravel sur mesure est mon cœur de métier — parlons de votre besoin.