Une mise à niveau qui échoue l'a presque toujours été avant la première commande
Beaucoup d'équipes repoussent la migration d'une application Laravel ancienne, par peur de casser quelque chose sans savoir quoi. Dans les faits, le framework lui-même est rarement le coupable. Les échecs viennent de ce qu'on n'a pas vérifié en amont : la version de PHP, les packages tiers, la couverture de tests et le plan de déploiement. Cet article reprend les grandes lignes d'une checklist publiée sur DEV Community et les organise en méthode de travail.
Pourquoi ne plus attendre
Chaque version majeure de Laravel suit un cycle de support : 18 mois de corrections de bugs, puis 2 ans de correctifs de sécurité au total. Passé ce délai, les vulnérabilités découvertes ne sont plus corrigées pour cette version.
Selon l'article source, en octobre 2026 :
- Laravel 13 est la version majeure actuelle, compatible avec PHP 8.3 à 8.5
- Laravel 12 reçoit encore des correctifs de sécurité jusqu'en février 2027
- Laravel 11 a perdu son support de sécurité en mars 2026
Une application sur Laravel 11 ou antérieur tourne donc déjà sans filet. Ces dates évoluent : vérifiez-les dans les notes de version officielles avant de planifier.
Avant de modifier une ligne de code
C'est la phase qui décide de tout le reste. Quatre contrôles à faire dans l'ordre.
1. L'environnement PHP
Chaque version de Laravel impose une plage de versions de PHP. Si votre serveur est en retard, la montée de PHP devient un chantier à part entière, à traiter avant le framework. Vérifiez aussi les extensions PHP utilisées en production, qui ne sont pas toujours identiques à celles de votre poste de développement.
2. Les dépendances
Listez les packages de votre composer.json et, pour chacun, regardez s'il est compatible avec la version cible. Trois cas se présentent :
- le package est maintenu et a une version compatible : on le met à jour
- le package est abandonné : il faut trouver un remplaçant ou internaliser le code
- le package est un fork maison : il faut estimer son coût de reprise
Les packages abandonnés sont le piège classique : ils bloquent la montée de version au pire moment.
3. Les tests
Sans tests, impossible de savoir si la migration a cassé quelque chose. Si la couverture est faible, écrivez d'abord des tests sur les parcours critiques (authentification, paiement, exports, tâches planifiées). Ils serviront de filet de sécurité pendant toute l'opération.
4. Le plan de déploiement
Prévoyez la sauvegarde de la base, la procédure de retour arrière et la fenêtre de mise en production. Une migration qu'on ne sait pas annuler est une migration risquée.
Monter de version étape par étape
Si l'application a plusieurs versions de retard, évitez le saut direct. Avancez version majeure par version majeure, en suivant le guide de mise à niveau officiel de chacune. À chaque palier :
- mettre à jour PHP si nécessaire, puis les dépendances, puis le framework
- corriger les changements incompatibles et les fonctions dépréciées
- lancer la suite de tests et corriger ce qui casse
- committer un état stable avant de passer au palier suivant
Cette progression par étapes isole les problèmes : quand un test échoue, on sait à quelle version il se rattache. Des outils d'automatisation de refactoring et d'analyse statique (comme PHPStan) aident à repérer les usages obsolètes avant même d'exécuter le code.
Tester et déployer sans prise de risque
Une fois le code migré, ne vous fiez pas uniquement aux tests automatisés. Déroulez les parcours métier à la main sur un environnement de préparation proche de la production : mêmes versions de PHP, même type de base de données, mêmes services externes. Surveillez ensuite les logs après la mise en production, et gardez la sauvegarde et la procédure de retour arrière à portée de main pendant les premiers jours.
Si l'équipe manque de temps, ou si la dette technique accumulée rend le chantier trop incertain, faire appel à un regard extérieur pour un audit préalable est souvent plus économique que de s'engager à l'aveugle.
Conclusion
Migrer une vieille application Laravel est un chantier prévisible quand on le prépare : vérification de PHP, inventaire des packages, filet de tests, plan de déploiement avec retour arrière. Le plus coûteux reste de ne rien faire, car une version sans support de sécurité accumule les risques à chaque mois qui passe. Commencez par un audit de l'existant, puis découpez le chantier en paliers maîtrisés.
Ce que ça change pour vous
Si votre logiciel métier repose sur une version ancienne de Laravel, il ne reçoit plus de correctifs de sécurité : une faille découverte demain ne sera pas réparée. Le risque est double : une intrusion possible, et des pannes lors des futures évolutions. La bonne démarche consiste à faire d'abord auditer l'application, afin de savoir ce qui bloque et combien de temps la remise à niveau demandera. Cette étape se fait sans arrêter votre activité, et elle transforme une inquiétude floue en plan chiffré.
