Passer au contenu principal
Octobre 2026 a apporté des fonctionnalités pour contrôler la forme des requêtes, la destination des lectures en base de données et l’exécution des tâches planifiées sur plusieurs serveurs. Laravel Cloud a simplifié l’envoi d’e-mails et la configuration des commandes planifiées, et Forge permet de suivre plus facilement les mises à jour de sécurité de PHP et les échecs de provisionnement. Cette page est un compte rendu mensuel fondé sur l’article officiel « Laravel October Product Updates » publié le 4 novembre et sur les entrées d’octobre du changelog officiel du Framework. Les sources primaires ont été vérifiées le 7 novembre 2026, et la partie Framework ne couvre que Laravel 13. Les versions de novembre ne sont pas incluses. Sources :

Laravel Framework

Versions publiées en octobre

En plus des principales nouveautés du changelog officiel, les dates et les versions ont été vérifiées dans les notes de version. Les sections suivantes détaillent les neuf éléments du changelog officiel. Pour les corrections mineures et les changements de dépendances, consultez chaque note de version.

Définir des recherches avec un corps de requête grâce aux routes QUERY

La v13.35.0 a ajouté Route::query(), qui prend en charge la méthode HTTP QUERY. Vous pouvez définir des routes qui reçoivent les critères de recherche dans le corps de la requête plutôt que dans la query string de GET.
Route::any() correspond aussi aux requêtes QUERY, et la liste des routes reconnaît cette méthode. Le SearchProductsController ci-dessus représente un contrôleur invocable de votre application qui implémente la recherche.
Les routes QUERY du groupe de middlewares web sont soumises à la vérification CSRF. Ne considérez pas que vous pouvez sauter la vérification comme pour GET parce qu’il s’agit d’une recherche. Envoyez le jeton CSRF.
Sources principales : Register QUERY Routes, routing.md officiel de Laravel 13. Pages associées : Routage, Protection CSRF

Éviter les lectures obsolètes dans les requêtes suivant une écriture

Avec une base de données à lecture et écriture séparées, une lecture juste après une mise à jour peut partir vers un réplica de lecture pas encore synchronisé. L’option existante sticky ne couvre que la même requête. Le middleware PreventStaleDatabaseReads de la v13.38.0 protège aussi, pendant une certaine durée, les requêtes suivantes de la même session. Dans bootstrap/app.php, importez Illuminate\Foundation\Http\Middleware\PreventStaleDatabaseReads et ajoutez-le dans le callback de withMiddleware() avec $middleware->web(append: [PreventStaleDatabaseReads::class]);. Il n’est pas activé automatiquement. Le middleware enregistre dans la session l’heure des écritures sur la connexion de base de données par défaut. Par défaut, il dirige les lectures de cette connexion vers la base d’écriture pendant 2 secondes après une écriture. Vous pouvez changer la durée en enregistrant par exemple PreventStaleDatabaseReads::for(5) à la place de la classe. Comme il utilise la session, il doit s’exécuter après StartSession. Il ne bascule pas les lectures des autres sessions ni des autres connexions, et ne détecte pas la fin de la synchronisation du réplica. Sources principales : Avoid Stale Reads After Database Writes, database.md officiel de Laravel 13. Pages associées : Base de données, Session

Lire depuis la base d’écriture pour certains traitements seulement

Connection::usingWritePdo(), ajouté également dans la v13.38.0, bascule la destination de lecture de la connexion vers la base d’écriture uniquement pendant l’exécution du callback. Il est utile lorsque vous voulez que l’application indique explicitement quelles lectures sont critiques, plutôt que de protéger toute une session.
Il s’applique aussi aux requêtes Eloquent et aux requêtes de relations qui utilisent la même connexion. Il renvoie le résultat du callback et restaure le réglage de lecture précédent même en cas d’exception, si bien que la bascule ne persiste pas dans le code suivant. Sources principales : Temporarily Read from the Write Database Connection, database.md officiel de Laravel 13

Configurer globalement l’exécution des tâches sur un seul serveur

Pour réduire les oublis de onOneServer() lorsque le planificateur tourne sur plusieurs serveurs, la v13.35.0 a ajouté Schedule::alwaysOnOneServer(). Appelez-le dans boot() de AppServiceProvider pour l’appliquer d’un coup à toutes les tâches planifiées concernées.
Cette valeur par défaut ne prend effet qu’une fois appelée. Les closures planifiées sans nom sont exclues et continuent de s’exécuter sur chaque serveur.
onOneServer() nécessite un cache central partagé par tous les serveurs. Les drivers indiqués par la documentation officielle sont database, memcached, dynamodb et redis. Ajouter le réglage ne fournit pas à lui seul une infrastructure de verrouillage entre serveurs.
Sources principales : Run Scheduled Tasks on One Server by Default, scheduling.md officiel de Laravel 13. Page associée : Planification des tâches

Vérifier les dispatchs des fakes en indiquant des propriétés

Depuis la v13.35.0, les fakes Queue, Bus, Event et Notification acceptent un tableau de propriétés attendues. Vous n’avez plus besoin d’écrire un callback à chaque fois pour une simple comparaison d’attributs. Par exemple, avec un job ShipOrder doté d’une propriété publique order et un $order préparé dans le test, vous pouvez vérifier ainsi :
Toutes les propriétés indiquées doivent correspondre. Les valeurs sont comparées strictement, mais les modèles Eloquent sont comparés avec is(), si bien qu’une autre instance représentant le même modèle correspond aussi. Les fakes vérifient le dispatch, pas le résultat de l’exécution du job lui-même. Sources principales : Assert Fake Dispatches by Their Properties, queues.md officiel de Laravel 13. Pages associées : Files d’attente, Mocking

Indiquer la limite mémoire du worker en pourcentage

Depuis la v13.35.0, l’option --memory de queue:work accepte un pourcentage du memory_limit de PHP. Vous pouvez ajuster le seuil d’arrêt du worker au réglage PHP sans recalculer une valeur fixe en Mo pour chaque environnement.
Ce n’est pas un pourcentage de la mémoire totale de l’hôte ou du conteneur. Si le memory_limit de PHP est illimité (-1), utilisez une valeur en Mo plutôt qu’un pourcentage. Le redémarrage d’un worker arrêté au seuil est confié à un superviseur de processus comme Supervisor. Sources principales : Set Queue Worker Memory Limits as Percentages, queues.md officiel de Laravel 13

Renvoyer du Markdown avec un Content-Type dédié

La v13.35.0 a ajouté markdown() à la factory de réponses. Elle renvoie un contenu Markdown en text/markdown, et vous pouvez aussi indiquer un code de statut et des en-têtes supplémentaires.
Vous pouvez la combiner avec une logique qui choisit le format de réponse, comme wantsMarkdown(). Elle ne convertit pas le Markdown en HTML. C’est une API pour servir le Markdown lui-même comme réponse. Sources principales : Return Markdown Responses, responses.md officiel de Laravel 13. Page associée : Réponses

Exécuter des requêtes analytiques en mode OLAP avec Vitess

La v13.36.0 a ajouté isVitess() et olap() aux connexions MySQL. Vous pouvez détecter l’utilisation de Vitess ou de PlanetScale et exécuter des requêtes analytiques avec la charge de travail OLAP.
La charge de travail est définie sur les connexions de lecture et d’écriture, puis remise en OLTP à la fin du callback. Elle est aussi restaurée en cas d’exception, et sur une connexion MySQL ordinaire sans Vitess, le callback s’exécute sans changer la charge de travail. Sources principales : Use OLAP Workloads with Vitess Connections, database.md officiel de Laravel 13

Trouver les règles de validation existantes grâce aux builders

La v13.36.0 a ajouté des méthodes builder de Rule pour de nombreuses règles qui s’écrivaient jusque-là sous forme de chaîne. Des méthodes comme requiredWith(), acceptedIf(), regex() et timezone() se trouvent plus facilement grâce à l’autocomplétion de l’IDE, et vous pouvez choisir le style d’écriture sans changer le comportement de validation existant.
Les noms de méthodes sont en camel case. Vous pouvez les mélanger avec des règles en chaîne, il n’est donc pas nécessaire de réécrire toutes les règles existantes d’un coup. Sources principales : Discover More Validation Rules Through Builders, validation.md officiel de Laravel 13. Page associée : Validation

Laravel Cloud

Le blog mensuel officiel présente les trois éléments suivants. Sources principales : Laravel October Product Updates — Laravel Cloud, Laravel Cloud changelog. Page associée : Présentation de Laravel Cloud

Laravel Forge

  • Alertes de mises à jour de sécurité PHP : Forge affiche, pour chaque serveur, les versions touchées par les versions de sécurité PHP d’octobre et la disponibilité des versions corrigées. Recheck versions revérifie la version réellement installée. Revérifier l’affichage et mettre à jour PHP sont deux opérations distinctes.
  • Gestion des échecs de provisionnement : les serveurs qui ne peuvent pas être finalisés s’affichent en état d’échec, avec une notification, des indications sur l’étape suivante et une action de suppression. L’installation de PHP et de Nginx est aussi relancée avant de confirmer l’échec.
Le blog mensuel mentionne aussi la publication d’un post-mortem sur la réponse de sécurité PHP et Node.js d’octobre. Pour les mesures prises et les décisions de mise à jour, consultez les annonces officielles. Sources principales : Laravel October Product Updates — Laravel Forge, Laravel Forge changelog

Articles associés

Mises à jour de septembre 2026

Retour sur la construction de fournisseurs d’IA à l’exécution, les extensions de recherche, Mercure et les environnements de prévisualisation isolés dans Cloud.

Guide de la base de données

Revoyez la séparation lecture/écriture et les bases des connexions de base de données.
Dernière modification le 7 novembre 2026