PHP 8.6 sort le 19 novembre 2026, et je sais déjà par quelle fonctionnalité toutes les conférences vont ouvrir : l'application partielle de fonctions. Tu écris str_replace(' ', '-', ?) et tu obtiens un callable dont le dernier argument reste ouvert, prêt à glisser dans l'opérateur pipe. C'est franchement élégant, et après des années de closures fn($x) => qui encombraient nos pipelines de collections, je prends avec plaisir. Mais voici ma vraie thèse : la PFA, c'est le feu d'artifice, pas le chantier. Les parties de 8.6 qui compteront le plus dans trois ans sont celles qui semblent ennuyeuses aujourd'hui — les mots réservés, les dépréciations, et une API de polling qui débarque délibérément sans la chose que tout le monde réclame.

Commençons par les identifiants dont PHP te déconseille désormais l'usage : let, is, namespace pour certains noms, readonly comme nom de fonction, et le simple underscore _. Un langage ne clôture pas des mots comme let et is pour s'amuser. C'est la core team qui réserve des places de parking pour une syntaxe future — le pattern matching est le pari évident pour is — et qui le fait une version majeure entière en avance, pour que la RFC finale ne casse pas la moitié de Packagist. Si tu as déjà vu un langage tenter de greffer un mot-clé après coup, tu sais combien de douleur ce geste discret nous épargne.

La nouvelle API de polling raconte la même histoire. Elle donne aux entrailles de PHP — PHP-FPM, la gestion des signaux, ZTS — une vraie abstraction au-dessus d'epoll et de WSAPoll, et elle est exposée au userland pour que ReactPHP et Amp puissent remiser leurs acrobaties à base de stream_select(). Point crucial : elle ne livre ni async/await ni boucle d'événements. J'ai vu des gens y lire de la frilosité. J'y lis du séquencement : on ne coule pas le béton et on ne pose pas les cloisons le même après-midi. Si PHP obtient un jour un async de première classe, il reposera exactement sur ce genre de plomberie sans gloire, et les applis à forte concurrence gagnent en scalabilité en attendant.

La liste des dépréciations se lit de la même façon quand tu plisses les yeux. Le return depuis un finally — ce petit piège où un return [] dans le bloc finally avale silencieusement le return $value du try — est enfin sur la sellette. Les constructeurs et destructeurs qui retournent des valeurs, ce qui n'a jamais rien voulu dire, sont désormais officiellement dépréciés aussi. La Reflection se resserre : définir des propriétés sur des objets sans lien et appeler des méthodes statiques via des instances sont tous deux marqués pour suppression. Chacune de ces mesures ferme une porte autour de laquelle une fonctionnalité future aurait dû sinon avancer sur la pointe des pieds. Et oui, is_double(), is_integer(), is_long() et doubleval() prennent la sortie au profit de is_float(), is_int() et floatval() ; si ça casse ta base de code, elle avait de toute façon besoin d'un passage de rector depuis longtemps.

Laisse-moi concéder le contre-argument le plus solide, parce qu'il est bon : pour un dev en activité, c'est le truc immédiatement utile qui paie les factures, et 8.6 en a plein. clamp($value, 0, 100) remplace l'incantation max(0, min(100, $value)) qu'on a tous mal tapée un jour, et ça marche sur les strings, DateTime, tout ce qui est comparable. Les propriétés readonly peuvent maintenant porter des valeurs par défaut. La Reflection gagne isReadable() et isWriteable(), que les auteurs de frameworks aux prises avec les property hooks et les setters privés utiliseront dès le premier jour. ReflectionParameter::getDocComment() place les annotations juste à côté du paramètre qu'elles décrivent. Les enums reçoivent __debugInfo(), donc la sortie de var_dump() cesse d'être de l'archéologie. Si ta définition d'une bonne release, c'est « les trucs que j'utilise ce sprint », 8.6 passe la barre sans le moindre besoin de mon romantisme architectural.

Mais je reste sur ma position, et les valeurs par défaut de session en sont la raison. session.use_strict_mode = 1, session.cookie_httponly = 1, session.cookie_samesite = Lax — dès la sortie de la boîte. Personne n'écrira de billet enflammé sur des valeurs par défaut de ini, et pourtant ce seul changement va tuer en silence toute une classe de bugs de fixation de session et de vol de cookies dans des milliers d'applis dont les mainteneurs ne liront jamais le changelog. C'est le motif que je pointe du doigt : les décisions sans sex-appeal se composent dans le temps. L'enum SortDirection est un autre indice — livrée avant même que les fonctions de tri du cœur ne l'acceptent, purement pour que l'écosystème puisse se standardiser maintenant et que le langage rattrape plus tard. C'est un projet qui planifie en décennies, pas en cycles de release.

Conséquence pratique pour ta mise à niveau : ne traite pas 8.6 comme un buffet de fonctionnalités où grignoter quand bon te semble. Fais-la tourner en CI avec les dépréciations remontées comme des échecs dès la semaine de sa sortie. Les return dans les finally, les vieux helpers de type, les astuces de reflection dans cet antique sérialiseur que tu as vendored en 2019, les appels à spl_object_hash(), mysqli::stmt_init() — chaque correction faite maintenant est une migration que tu ne feras pas sous pression quand PHP 9 arrivera. Et vérifie si quelque chose dans ta stack dépend de POST cross-site qui touchent des sessions ou de JavaScript qui lit des IDs de session, parce que les nouvelles valeurs par défaut des cookies mordront exactement ces configurations en premier.

Alors voilà où j'attends la contradiction, parce que je sais que cette salle contient des gens qui ne sont pas d'accord. Une release se juge-t-elle mieux à ce qu'elle te laisse écrire aujourd'hui, ou à ce qu'elle rend possible dans trois ans ? Autrement dit : quel changement de 8.6 comptera encore en 2029 — la PFA et l'opérateur pipe, ou le jour où PHP a réservé le mot is ? Dis-moi que j'ai tort dans les commentaires ; apporte du code.