Laravel 14 devrait sortir au premier trimestre 2027. La version minimale requise sera PHP 8.4. Les corrections de bugs sont prévues jusqu’au troisième trimestre 2028, puis les correctifs de sécurité jusqu’au premier trimestre 2029. Au 21 septembre 2026, l’équipe Laravel n’avait annoncé ni date de sortie ni liste officielle de fonctionnalités. Ces informations proviennent de la branche master de laravel/framework et peuvent encore évoluer.

<?php

Route::query('/search', function () {
    return request()->input('filter');
});

Le routage ajoutera Route::query() pour la méthode HTTP QUERY. Cette méthode sûre accepte un corps de requête. Route::any() inclura QUERY, tandis que le middleware CSRF la traitera comme une requête de lecture, au même titre que GET, HEAD et OPTIONS. Vazha Aptsiauri a proposé cette évolution dans la PR #60655. Laravel 13.19 avait déjà ajouté Http::query() ainsi que les helpers de test query() et queryJson().

La PR #59708 de Will Rowe ajoute authorize() au contrat et au trait Authorizable. Un utilisateur pourra appeler $user->authorize('viewAny', Post::class). Le comportement correspond à celui de $user->can(), avec une AuthorizationException lorsque l’autorisation échoue.

La PR #60767, signée par Caleb White, ajoute un tableau de contexte facultatif au helper report() et à la méthode report() du gestionnaire d’exceptions. Une application pourra joindre des données comme order_id au signalement d’une erreur. Le contrat ExceptionHandler utilise désormais report(Throwable $e, array $context = []). Les gestionnaires personnalisés qui redéfinissent cette méthode devront accepter ce paramètre.

La PR #61378 ajoute Storage::fake('ondemand') pour les disques créés à la demande. Le fake intercepte Storage::build() et permet d’utiliser les mêmes assertions qu’avec les disques nommés. Cette modification a été placée dans la branche Laravel 14, car une application peut déjà posséder un disque nommé ondemand.

La PR #61395 regroupe whereKey() et whereKeyNot() et ajoute orWhereKey() ainsi que orWhereKeyNot(). La PR #61496 permet aux quatre méthodes d’accepter une sous-requête.

Plusieurs changements de comportement méritent un test lors de la migration. Queue::pause(), Queue::pauseFor(), resume() et isPaused() recevront d’abord le nom de la file. La connexion deviendra le deuxième argument facultatif, avec la connexion par défaut comme valeur implicite. Laravel 13.25 avait ajouté la mise en pause de toutes les files. La PR #61076 modifie les signatures par file, qui passent de formes comme Queue::pause('redis', 'emails') à Queue::pause('emails') ou Queue::pause('emails', 'redis').

Les méthodes lazy() et chunk() ne modifieront plus le Query Builder pendant la pagination. Les PR #61411 et #61428 corrigent un comportement de Laravel 13 où la réutilisation du builder après lazy() pouvait faire retourner 0 à count(). Laravel 14 conservera le nombre complet de lignes.

La PR #61577 modifie Builder::findOr() lorsqu’un tableau d’identifiants est fourni. Avec User::findOr([1, 99], fn () => 'fallback'), Laravel 13 renvoyait une collection contenant l’utilisateur 1 et ignorait le callback. Laravel 14 exécutera le callback dès qu’un identifiant manque, comme findOrFail() et les variantes liées aux relations.

La PR #61466 corrige la gestion des tableaux dans Cache::has() et Cache::forget(). Leurs docblocks acceptaient les tableaux depuis quatre ans, mais has(['a', 'b']) renvoyait toujours true sans vérifier chaque clé, et forget() ne supprimait pas les clés. Laravel 14 fera retourner true à has() uniquement lorsque toutes les clés existent. forget() supprimera toutes les clés transmises et ne renverra true que si chaque suppression réussit. L’ancien chemin Redis pouvait produire l’avertissement Array to string conversion.

La PR #61425 aligne MassPrunable sur Prunable pour les modèles utilisant les suppressions logiques. Avec MassPrunable et SoftDeletes, model:prune sélectionnera aussi les lignes déjà supprimées logiquement et les supprimera définitivement si elles correspondent à la requête. Pour conserver le comportement de Laravel 13, il faudra ajouter withoutTrashed() à prunable().

La PR #59104 fait passer le minimum de PHP de 8.3 dans Laravel 13 à 8.4 dans Laravel 14. Symfony 8 exige PHP 8.4. D’autres évolutions prévues concernent une version de ably/ably-php utilisant Ably protocol 2.0 dans la PR #60860, orchestra/testbench-core en ^12.0 et la prise en charge de PHPUnit 11.5, 12.5 et 13.

Laravel suit un cycle annuel de versions majeures autour du premier trimestre. Laravel 11 prend en charge PHP 8.2 à 8.4, est sorti le 12 mars 2024, a reçu des corrections de bugs jusqu’au 3 septembre 2025 et reçoit des correctifs de sécurité jusqu’au 12 mars 2026. Laravel 12 prend en charge PHP 8.2 à 8.5, est sorti le 24 février 2025, a cessé de recevoir des corrections de bugs le 13 août 2026 et recevra des correctifs de sécurité jusqu’au 24 février 2027.

Laravel 13 prend en charge PHP 8.3 à 8.5 et est sorti le 17 mars 2026. Les corrections de bugs sont prévues jusqu’au troisième trimestre 2027, avec des correctifs de sécurité jusqu’au 17 mars 2028. Laravel 14 est annoncé avec PHP 8.4+, une sortie visée au premier trimestre 2027, des corrections de bugs jusqu’au troisième trimestre 2028 et des correctifs de sécurité jusqu’au premier trimestre 2029. La documentation officielle ne référence pas encore Laravel 14.

Laravel Shift pourra automatiser la migration lors de la sortie. Le service ouvre une pull request composée de commits atomiques à examiner.