Migrer Laravel 11 vers 12 n'est ni la formalité de cinq minutes que la documentation laisse entendre, ni le chantier qui justifierait de repousser l'échéance. Il faut le faire avec méthode, et sans attendre : selon le calendrier officiel de Laravel, la version 11 ne reçoit plus de correctifs de sécurité depuis le 12 mars 2026.
Un retour d'expérience publié sur r/laravel donne le ton. Son auteur a fait passer son application Event Schedule de la 11 à la 12, d'abord pour cette raison. Résultat : composer audit, l'outil qui recense les failles connues dans les composants utilisés, est passé de 13 avis à aucun. Et quelques détails ont cassé en route.
"Laravel 11 tourne encore, la migration peut attendre"
L'argument est honnête. Une application qui fonctionne ne prévient pas quand elle devient fragile, personne ne reçoit d'alerte le jour de la fin du support, et le sujet glisse au trimestre suivant. Le site répond, les commandes passent.
Sauf que la règle est connue d'avance : 18 mois de correctifs de bugs et deux ans de correctifs de sécurité par version majeure. Passé ce délai, une faille trouvée dans le framework n'est plus corrigée pour la 11. Et ceux qui cherchent ces failles, eux, lisent le même calendrier que nous.
Les 13 avis de l'auteur sont son chiffre, pas une mesure indépendante, et le vôtre sera différent. Le test, lui, se refait en une minute : lancez composer audit sur votre application et regardez ce qu'il répond.
"C'est une mise à jour de cinq minutes"
Le guide officiel l'estime en effet à cinq minutes, et l'équipe Laravel présente la 12 comme une version de maintenance : la plupart des applications passent sans changer une ligne. Pour beaucoup, c'est vrai. Pour d'autres, ce sont les détails qui mordent.
Le point le mieux établi concerne Blade, le moteur qui fabrique les pages. Laravel y a ajouté une directive @context. Or le JSON-LD, ces données invisibles qui expliquent à Google ce qu'est une page, contient justement un champ nommé "@context". Blade le prend désormais pour une instruction, et environ 60 vues d'Event Schedule ne se compilaient plus. Le contournement tient en un caractère (@@context). Un site soigneusement référencé a donc de bonnes chances d'être concerné.
Les deux autres ruptures viennent du seul récit de l'auteur, et le guide officiel ne les mentionne pas. Selon lui, se connecter renouvelle désormais le jeton CSRF, le code secret qui protège les formulaires. Une page restée ouverte pendant la connexion renvoie alors une erreur 419 à l'envoi suivant ; nous avons détaillé ce symptôme dans notre article sur Laravel 419 Page Expired. Enfin, les comptes créés via Google ou Facebook, donc sans mot de passe, provoquaient des erreurs 500 une fois la session expirée avec un cookie "se souvenir de moi".
Rien ne dit si cela vient de la 12.0 ou d'une version mineure. À vérifier chez vous plutôt qu'à croire sur parole.
"Autant sauter la 12 et viser directement la 13"
Le raisonnement se défend. La 12 n'a plus de correctifs de bugs depuis le 13 août 2026, seulement des correctifs de sécurité, jusqu'au 24 février 2027. Le tableau officiel donne à la 13 une sécurité garantie jusqu'au premier trimestre 2028, et la documentation la présente comme la version courante. Nous n'avons toutefois pas pu confirmer sa date de sortie exacte sur une page officielle.
Notre avis reste pourtant de passer par la 12. Elle referme la brèche tout de suite, et la 13, qui exige PHP 8.3 au lieu de 8.2, se prépare ensuite sans urgence. Sauter l'étape additionne les changements, et l'on ne sait plus lequel a cassé quoi. Deux autres voies existent : Laravel Shift, un service de mise à niveau automatisée cité par le guide, ou la reconstruction sur la 13 en portant le code, option évoquée par un prestataire de migration qui a évidemment intérêt à la vendre.
"Une montée de version, c'est l'affaire des développeurs"
Le geste, oui. La décision et la préparation, non. Une démarche saine commence par un audit de sécurité, puis une copie de l'application avec les données de production, des tests sur cette copie, et un plan de retour arrière avant toute bascule. On regarde d'abord les écrans qui affichent des données structurées pour Google, et ceux où l'on se connecte avec un compte Google ou Facebook.
Côté budget, l'outil est gratuit, mais le temps de travail dépend du volume de code et des tests existants. Nous n'avons trouvé aucun chiffre neutre pour le chiffrer, et nous préférons ne pas en inventer. Une application jamais maintenue demandera plus de travail qu'une application suivie : c'est l'objet d'une reprise d'application existante, et d'un contrat de maintenance qui évite d'en arriver là.
Nous accompagnons des entreprises de Provence, du côté de Pélissanne notamment, sur ce type de montée de version. Si votre application tourne encore en 11, parlons-en avant que le calendrier ne vous rattrape.
Questions fréquentes
Peut-on rester en Laravel 11 si l'application fonctionne bien ?
Elle fonctionnera, mais sans correctifs de sécurité du framework depuis le 12 mars 2026 d'après le calendrier officiel. Une faille découverte ensuite ne sera plus corrigée pour cette version.
Faut-il changer la version de PHP pour passer à Laravel 12 ?
Laravel 12 demande PHP 8.2 au minimum, et Laravel 13 PHP 8.3. Si votre serveur est plus ancien, la mise à jour de PHP fait partie du chantier.
Comment savoir si mon application a des failles connues ?
La commande composer audit liste les avis de sécurité qui touchent les composants installés. Elle se lance en une minute et donne une première mesure objective.
Existe-t-il un outil pour automatiser la mise à niveau ?
Le guide officiel mentionne Laravel Shift, un service de mise à niveau automatisée. Il ne dispense pas de tester l'application ensuite, surtout sur les écrans de connexion et les pages générées.
