Dix minutes sur le papier, quelques pièges en pratique
Laravel 13 est sorti le 17 mars 2026 avec une promesse rassurante : la plupart des applications migrent sans toucher au code métier. La documentation officielle évoque une mise à jour en dix minutes. C'est globalement juste. Mais "peu de changements cassants" ne signifie pas "zéro changement cassant", et le guide officiel recense deux points à fort impact, deux points à impact moyen, et une quinzaine à faible impact. Si votre application cache des objets PHP sérialisés, effectue des upsert sur MySQL ou désactive le middleware CSRF dans vos tests, l'un de ces points vous concernera directement.
Cet article passe en revue les ruptures de compatibilité concrètes. Pour la procédure générale de migration (sauvegarde, branche Git, composer update, vérification), référez-vous au guide officiel de Laravel ou à l'article source de Marco Orta publié sur dev.to.
Pourquoi migrer maintenant
Laravel 12 a cessé de recevoir des correctifs de bugs le 13 août 2026. Seules les corrections de sécurité sont encore publiées, et elles s'arrêteront le 24 février 2027. Si votre application tourne sous Laravel 12 en production, vous êtes dans la dernière fenêtre de support.
Laravel 13 couvre PHP 8.3 à 8.5, avec des correctifs de bugs garantis jusqu'au troisième trimestre 2027 et des patches de sécurité jusqu'au 17 mars 2028. C'est un gain de plus d'un an de tranquillité opérationnelle, pour un effort de migration limité.
Les changements qui cassent vraiment
Cache d'objets PHP sérialisés
C'est le point à fort impact le plus insidieux. Si votre application stocke des objets PHP sérialisés en cache (via Cache::put() avec des instances de classes, des jobs sérialisés, ou des sessions contenant des objets), et que ces objets appartiennent à des classes dont la signature a changé entre Laravel 12 et 13, la désérialisation échouera silencieusement ou lèvera une exception à l'exécution.
La bonne pratique avant toute migration : videz le cache applicatif (php artisan cache:clear), les sessions (php artisan session:flush) et la file de jobs en attente. Ne migrez pas avec des données sérialisées issues de la version précédente.
Comportement des upsert sur MySQL
Laravel 13 modifie la génération SQL des opérations upsert pour MySQL. L'ancienne syntaxe utilisait ON DUPLICATE KEY UPDATE, la nouvelle s'appuie sur INSERT ... ON DUPLICATE KEY UPDATE avec une gestion différente des colonnes retournées. Si vos tests ou votre code s'appuient sur les valeurs de retour d'un upsert ou sur un comportement précis de la mise à jour en cas de doublon, vérifiez vos assertions.
// Vérifiez que vos upserts retournent ce que vous attendez
$result = Model::upsert(
[['email' => 'user@example.com', 'name' => 'Alice']],
['email'],
['name']
);
// Le type et la valeur de $result ont pu changer
Middleware CSRF dans les tests
Les tests qui utilisaient withoutMiddleware(VerifyCsrfToken::class) pour désactiver la vérification CSRF peuvent se comporter différemment. Laravel 13 réorganise la pile de middleware et l'exclusion ciblée du CSRF ne produit plus exactement le même effet dans certains scénarios de test impliquant des middlewares imbriqués.
Si votre suite de tests contient des appels à withoutMiddleware, auditez-les avant de lancer la migration. Préférez $this->withoutMiddleware() sans argument pour désactiver l'ensemble de la pile dans un test isolé, ou refactorisez les tests concernés pour ne pas dépendre de ce comportement.
// Avant (peut casser)
$this->withoutMiddleware(\App\Http\Middleware\VerifyCsrfToken::class)
->post('/api/action', $data);
// Alternative plus robuste
$this->withoutMiddleware()
->post('/api/action', $data);
Changements à impact moyen et faible
Le guide officiel liste en outre une quinzaine de points à faible impact. Parmi ceux à surveiller selon votre stack :
- La résolution des façades dans les closures de routes : certaines façades résolues à l'intérieur de closures de routes enregistrées sans binding explicite peuvent lever une exception si le conteneur n'est pas encore bootstrappé.
- Les contrats modifiés : plusieurs interfaces du framework ont reçu de nouvelles signatures de méthodes. Si vous implémentez directement un contrat Laravel dans votre code (plutôt que d'étendre une classe de base), vérifiez la compatibilité.
- Les règles de validation : quelques règles ont un comportement légèrement modifié sur les types scalaires. Auditez vos tests de validation si vous couvrez des cas limites.
La procédure de migration en pratique
Voici l'ordre d'opérations recommandé pour limiter les risques :
- Créez une branche dédiée et assurez-vous d'avoir une sauvegarde récente de la base de données.
- Videz le cache, les sessions et la file de jobs avant de lancer
composer update.
- Mettez à jour
composer.json : "laravel/framework": "^13.0".
- Lancez
composer update et corrigez les éventuelles incompatibilités de dépendances tierces.
- Auditez vos usages de
withoutMiddleware et vos appels upsert.
- Vérifiez vos implémentations directes de contrats Laravel.
- Lancez votre suite de tests complète et traitez chaque échec avant de fusionner.
La plupart des dépendances majeures de l'écosystème (Livewire, Filament, les packages Spatie courants) supportent déjà Laravel 13. Vérifiez néanmoins les contraintes de version de chaque package avant de mettre à jour.
Ce que ça change pour vous
Si vous gérez une application web ou un logiciel métier construit avec Laravel, voici ce que cette mise à jour signifie sans jargon : votre application continuera de fonctionner exactement comme avant, mais elle sera maintenue et protégée contre les failles de sécurité pour deux années supplémentaires. Ne pas effectuer cette mise à jour avant février 2027, c'est exposer votre outil à des vulnérabilités connues sans correctif disponible. L'opération est courte, le risque de ne pas la faire est bien plus élevé que celui de la faire. Si vous avez un prestataire technique, c'est le bon moment de lui demander où en est votre version de Laravel et de planifier la migration dans les prochaines semaines.
