Les captures d'écran qui circulent cette semaine montrent toutes la même chose : php artisan dev avec de jolis onglets. D'accord, c'est très réussi visuellement. Mais mon vote pour le changement qui mérite vraiment qu'on en parle dans Laravel 13.25 va à une commande dont tout le but est de faire en sorte que des processus ne fassent rien pendant un moment. queue:pause --all s'attaque à un danger de déploiement que la plupart d'entre nous ont appris à ignorer d'un haussement d'épaules il y a des années, et il le fait avec plus de soin que n'importe quel script bash que j'ai pu écrire pour le même problème.

Le danger, au cas où tu aurais eu la chance de ne jamais le rencontrer : ton pipeline remplace le code sur le disque, mais un worker de longue durée garde encore les anciennes classes chargées en mémoire, et les jobs qui attendent dans Redis ont été sérialisés selon la forme d'hier de ton code. Renomme un paramètre de constructeur sur le job qui génère les factures mensuelles, pousse à 14:03, et un payload mis en file à 14:02 atterrit sur une classe qui ne lui correspond plus. Tu le découvres via une table failed_jobs qui grossit pendant que le pipeline reste joyeusement au vert. Jusqu'ici tu avais deux instruments grossiers. Le mode maintenance renvoie aussi les visiteurs payants, ce qui fait beaucoup de dégâts collatéraux pour un problème de jobs en arrière-plan. Et queue:restart n'interrompt jamais rien, parce qu'un worker ne vérifie ce signal qu'une fois son job en cours terminé, donc le timing t'échappe complètement.

Laravel 13.25 te donne le scalpel : lance queue:pause --all avant que la release ne parte, laisse les workers redémarrer sur le nouveau code, puis queue:resume --all. Un job déjà en pleine exécution a le droit de finir, et le dispatch continue de fonctionner tout du long, donc le backlog se vide simplement une fois la reprise faite. Le détail qui m'a convaincu que quelqu'un a vraiment réfléchi : resumeAll() ne touchera pas une file mise en pause individuellement. Imagine le collègue d'astreinte qui a mis en pause la file des imports à 3 h du matin parce qu'un job empoisonné la faisait planter en boucle. Quand ton script de déploiement de 9 h appelle Queue::resumeAll(), cette file reste à l'arrêt, exactement comme prévu. Il y a aussi un événement QueuesPaused, donc câbler une alerte Slack pour « quelqu'un a gelé les files de production » prend environ quatre lignes.

Passons maintenant à la partie clinquante, et je veux être honnête avec elle. Depuis la 13.16, php artisan dev démarre toute la stack locale depuis un seul terminal : le serveur HTTP, queue:listen --tries=1 --timeout=0, Pail là où pcntl_fork existe, et ton build frontend, qu'il tourne sur npm, pnpm, Yarn ou Bun. Ce que la 13.25 ajoute, c'est @laravel/multiplex en dessous. Chaque processus vit dans son propre onglet, tu peux relancer Vite sans emporter le listener de queue avec lui, le mode stream est enfin scrollable et cherchable, et quand il n'y a pas de TTY, disons dans un conteneur, il retombe tout seul sur une sortie inline classique. Un processus qui plante redémarre automatiquement sauf si tu passes --no-restart. Le hic : macOS et Linux seulement pour l'instant, Windows garde l'ancien comportement basé sur concurrently.

Voici l'objection que je prends au sérieux : un framework web qui embarque son propre multiplexeur de terminal, ça sent la dérive de périmètre. tmux existe. Un fichier compose existe. Chaque pièce mobile supplémentaire dans le framework est quelque chose que la core team doit maintenant faire fonctionner sur tous les systèmes d'exploitation et émulateurs de terminal pour toujours. J'ai moi-même fait cet argument à propos d'autres fonctionnalités. Ce qui m'a fait changer d'avis ici, c'est l'onboarding. « Copie juste ma config tmux » a un taux de réussite proche de zéro, et au bout de six mois chaque laptop de l'équipe fait tourner une stack locale légèrement différente. Un appel DevCommands::artisan('horizon', 'queue') dans AppServiceProvider, commité dans le repo et remplaçant carrément le worker par défaut, ça veut dire que ton setup local passe par la revue de code comme tout le reste, et dev:list montre à une nouvelle recrue exactement ce qui va tourner avant que quoi que ce soit ne démarre. Ça vaut bien un peu de poids dans le framework.

Pour compléter la fournée, l'Installer v5.31.0 a appris laravel package. Il récupère le laravel/package-skeleton officiel, supprime l'historique git du squelette, installe les dépendances puis t'interroge sur ce dont le package a besoin, ou saute complètement l'interrogatoire si tu passes des flags comme --config, --facade et --vendor-namespace. Il détecte même quand c'est un agent IA qui le pilote et reste non interactif au lieu de rester bloqué sur un prompt. Mon avis tient en peu de mots : la première heure fastidieuse d'extraction de code partagé vers un vrai package vient de devenir assez bon marché pour que « on devrait vraiment en faire un package » cesse d'être une phrase qu'on ne prononce qu'en rétro.

Prends du recul et remarque ce qu'aucune de ces releases ne touche : le routing, Eloquent, la validation, le vrai cœur du framework. Laravel dépense son énergie sur les minutes autour de ton code, sur le démarrage de la stack, son déploiement en sécurité, son découpage. Je pense que c'est le bon pari en 2026, et queue:pause --all en est la preuve, parce qu'il comble un trou qu'on connaissait tous et que personne n'avait priorisé. Alors dis-moi : est-ce que tu vas mettre pause et resume dans ton pipeline de déploiement, ou est-ce que la fenêtre où un vieux payload rencontre du nouveau code est un risque que tes classes de jobs sont assez stables pour tolérer ?