Sommaire
PHP 8.6 vient de franchir une étape importante de son développement : la première Beta est disponible.
RSS
Le RSS envoie les nouveaux articles dans le lecteur de votre choix, sans algorithme ni newsletter.
Ça ne veut pas dire qu’il faut ouvrir son serveur de production et mettre à jour PHP cet après-midi. Une Beta reste une version de développement, avec des bugs potentiels, des régressions et un écosystème qui n’est pas encore totalement prêt.
En revanche, pour les développeurs, les mainteneurs de bibliothèques, les éditeurs de logiciels ou de modules, le signal est différent : PHP 8.6 commence à devenir suffisamment concret pour qu’on s’y intéresse sérieusement.
Après trois Alpha publiées pendant l’été, nous sortons progressivement de la période où la prochaine version de PHP ressemble surtout à une collection de RFC.
Le langage commence à prendre sa forme définitive.
Et ce que on trouve intéressant avec PHP 8.6, ce n’est justement pas une fonctionnalité spectaculaire censée tout révolutionner.
C’est plutôt l’accumulation de changements qui vont dans la même direction : rendre le code plus explicite, supprimer quelques vieux irritants et améliorer le runtime là où le développeur n’a normalement rien à faire.
PHP 8.6 entre réellement dans sa phase de test
Le cycle PHP 8.6 a commencé avec Alpha 1 le 2 juillet 2026, suivie d’Alpha 2 le 16 juillet et d’Alpha 3 le 30 juillet.
Beta 1 change un peu la nature du travail.
Pendant les Alpha, les fonctionnalités peuvent encore bouger fortement. À mesure que les Betas puis les Release Candidates arrivent, le périmètre se stabilise et l’objectif devient davantage de trouver ce qui casse.
C’est exactement à cela que sert cette période.
Si vous développez une application PHP classique, vous n’avez probablement aucune raison urgente de passer plusieurs heures sur PHP 8.6 aujourd’hui.
Si vous maintenez en revanche une bibliothèque, un framework, un CMS, une extension ou un module utilisé par des centaines de clients, attendre novembre pour découvrir un problème de compatibilité serait beaucoup moins raisonnable.
La sortie stable est actuellement prévue pour le 19 novembre 2026.
Cela laisse encore plusieurs mois pour tester sans précipitation.
clamp() : pas révolutionnaire, juste beaucoup plus clair
Parmi les nouveautés de PHP 8.6, clamp() illustre assez bien ce que j’attends aujourd’hui d’un langage mature.
Imaginons que on veuille garantir qu’un pourcentage reste compris entre 0 et 100.
Aujourd’hui, on peux écrire :
$percentage = max(0, min(100, $percentage));
Ça fonctionne.
Ce n’est même pas spécialement compliqué.
Mais il faut tout de même lire l’imbrication de min() et max() pour comprendre ce que le développeur cherche à faire.
Avec PHP 8.6 :
$percentage = clamp($percentage, 0, 100);
Le gain n’est pas algorithmique.
Le gain est dans l’intention.
Même quelqu’un qui arrive sur le projet plusieurs mois plus tard peut comprendre immédiatement : cette valeur doit rester entre 0 et 100.
On retrouve le même intérêt sur une pagination :
$page = clamp($page, 1, $maxPage);
Une opacité :
$opacity = clamp($opacity, 0.0, 1.0);
Ou n’importe quelle donnée métier soumise à une borne minimale et maximale.
Ce genre de fonction ne permet pas de faire quelque chose d’impossible auparavant.
Et c’est justement le point.
Toutes les évolutions utiles d’un langage ne doivent pas introduire une nouvelle manière de programmer. Certaines servent simplement à mieux exprimer ce que nous faisions déjà.
Sur une ligne, la différence paraît minuscule.
Multipliée par plusieurs centaines de milliers de lignes de code, cette recherche de clarté finit par compter.
#[Override] : laisser PHP vérifier ce que nous croyons faire
PHP continue également de faire évoluer l’attribut #[Override].
L’idée derrière cet attribut est assez simple : lorsqu’un développeur dit qu’un élément surcharge quelque chose provenant d’un parent ou d’un contrat, PHP peut vérifier que c’est réellement le cas.
PHP 8.6 étend cette logique aux constantes de classe.
On peut par exemple écrire :
interface PaymentProvider
{
public const NAME = 'default';
}
final class StripeProvider implements PaymentProvider
{
#[Override]
public const NAME = 'stripe';
}
À première vue, on pourrait considérer l’attribut comme une simple information destinée à la personne qui lit le code.
Mais son intérêt est justement qu’il ne s’agit pas uniquement de documentation.
On donne une information supplémentaire au langage.
Nous lui disons :
Cette constante est censée en surcharger une autre.
PHP peut alors vérifier cette hypothèse.
Si le contrat parent évolue plus tard et que cette surcharge n’a plus de sens, nous avons davantage de chances de détecter le problème immédiatement plutôt que plusieurs semaines plus tard au détour d'un comportement étrange.
C’est une évolution que on trouve saine dans PHP : faire exprimer davantage d’intentions au code afin de permettre au langage de mieux nous protéger.
Les analyseurs statiques font évidemment déjà énormément de travail dans ce domaine. Mais lorsqu’une information peut faire partie directement du langage, elle devient accessible à tout le monde, indépendamment de la configuration des outils du projet.
Certaines améliorations de PHP 8.6 ne changeront aucune ligne de votre code
Il y a également une partie moins visible du travail réalisé sur PHP 8.6.
Et c’est souvent cette partie que on trouve la plus intéressante.
Le moteur continue d’être optimisé autour des closures et des arrow functions.
PHP peut notamment mieux détecter certaines closures qui n’utilisent pas $this et les traiter comme statiques lorsque c’est possible.
D’autres optimisations concernent les closures sans état.
Prenons volontairement un exemple très simple :
function callback()
{
return static function () {
return 'hello';
};
}
Si cette fonction est appelée énormément de fois, PHP pourrait théoriquement créer énormément d’objets représentant une closure dont le comportement ne varie jamais.
Ce n’est pas très utile.
PHP 8.6 peut désormais réutiliser certaines de ces closures lorsque les conditions le permettent.
Le développeur, lui, ne change rien.
Il ne rajoute pas une annotation magique.
Il n’active pas une option.
Il ne réécrit pas son architecture.
C’est le moteur qui fait mieux son travail.
Évidemment, cela ne signifie pas que toutes les applications vont soudainement devenir beaucoup plus rapides avec PHP 8.6. Les gains dépendent énormément du type de code exécuté.
Il faut se méfier des benchmarks transformés en slogans.
Mais c’est exactement le genre d’optimisation que j’aime voir arriver dans PHP : améliorer des patterns déjà utilisés par des millions de développeurs sans leur demander de transformer leur code en laboratoire d’optimisation.
Oui, même trim() change
PHP 8.6 modifie aussi légèrement le comportement par défaut de trim(), ltrim() et rtrim().
Le caractère Form Feed, \f, sera désormais considéré comme un whitespace par défaut.
On doute que beaucoup de développeurs se soient réveillés ce matin en attendant cette fonctionnalité.
Mais ce type de changement raconte aussi quelque chose de l’évolution d’un langage qui approche des trente ans d’existence.
Il reste forcément des comportements historiques, des incohérences ou des choix réalisés à une époque où les usages étaient différents.
Faire évoluer PHP, ce n’est donc pas uniquement ajouter des fonctionnalités.
C’est également revenir progressivement sur ces détails.
Il faut néanmoins faire attention à une différence importante.
Ajouter clamp() ne modifie aucun comportement existant.
Modifier trim(), même légèrement, peut en modifier un.
Si une application dépend volontairement du fait que trim() conserve un caractère \f au début ou à la fin d’une chaîne, son comportement évoluera en PHP 8.6.
Ce cas est probablement extrêmement rare.
Mais les migrations cassent rarement parce qu’un développeur n’a pas compris la fonctionnalité principale affichée sur la page d’accueil d’une nouvelle version.
Elles cassent souvent à cause du petit changement de comportement que personne n’avait regardé.
C’est aussi pour ça que les Betas existent.
Un changement à surveiller côté MySQL et MariaDB
PHP 8.6 fait également évoluer certaines contraintes liées aux versions supportées de son environnement.
Parmi elles, un changement concerne les connexions persistantes MySQL et MariaDB.
Lorsqu’une connexion persistante est réutilisée, il faut être capable de remettre correctement son état à zéro avant de la transmettre à une autre requête.
Sinon, une connexion peut potentiellement conserver des éléments de contexte issus de son utilisation précédente.
PHP 8.6 peut s’appuyer sur COM_RESET_CONNECTION pour effectuer cette réinitialisation.
Pour une infrastructure moderne, ce changement ne devrait généralement pas provoquer de difficulté particulière.
En revanche, cela signifie aussi que certaines très anciennes versions de MySQL ou MariaDB qui ne disposent pas de ce mécanisme ne pourront plus être utilisées exactement de la même manière pour les connexions persistantes.
C’est typiquement le genre de point que j’irais vérifier sur une vieille application e-commerce avant une migration.
Pas parce que PHP 8.6 pose soudainement un problème.
Mais parce qu’une mise à jour PHP est souvent l’occasion de découvrir que le véritable problème se situe deux couches plus bas, sur une brique que personne n’avait mise à jour depuis plusieurs années.
Faut-il tester PHP 8.6 maintenant ?
Pour un site en production : non.
Pour un environnement de développement ou de CI : cela commence à avoir du sens.
La distinction est importante.
Une Beta n’est pas une version « presque stable qu’on peut utiliser si on est prudent ».
C’est une version publiée précisément pour être testée avant la stabilité.
Si vous maintenez un projet PHP, vous pouvez par exemple commencer simplement par faire tourner votre suite de tests sur PHP 8.6.
Vous découvrirez peut-être qu’elle passe immédiatement.
Très bien.
Vous découvrirez peut-être une dépréciation ou un comportement qui change.
Encore mieux : c’est exactement l’information qu’on cherche aujourd’hui.
Vous découvrirez peut-être aussi que ce n’est pas votre code qui bloque, mais une dépendance.
Et vous saurez alors plusieurs mois avant la sortie stable qu’il faudra surveiller sa mise à jour.
C’est beaucoup plus confortable que de découvrir le problème au moment où l’infrastructure doit migrer.
Ce que PHP 8.6 raconte surtout de PHP aujourd’hui
À ce stade, on ne vois pas PHP 8.6 comme une version qui va bouleverser notre manière de développer.
Et on n’en attends pas forcément une.
PHP est désormais un langage mature.
Il possède des types, des enums, des attributs, des propriétés typées, des propriétés readonly, un système d’exceptions solide, des outils d’analyse statique très avancés et un écosystème qui a énormément changé depuis le PHP des années 2000.
La question n’est donc plus de réinventer le langage tous les ans.
Elle est plutôt de continuer à réduire ses incohérences.
clamp() permet d’exprimer une intention plus directement.
#[Override] permet au langage de vérifier davantage ce que le développeur affirme.
Certaines closures peuvent être mieux optimisées sans aucune modification du code applicatif.
Des comportements historiques comme ceux de trim() continuent d’être nettoyés.
Et certaines briques de communication avec les systèmes externes, comme MySQL, sont modernisées.
Pris séparément, aucun de ces changements n’est spectaculaire.
Pris ensemble, ils dessinent pourtant une direction assez claire.
PHP cherche moins à nous donner de nouvelles façons de programmer qu’à rendre les façons existantes plus propres, plus prévisibles et plus faciles à maintenir.
Et pour un langage utilisé depuis des décennies sur des bases de code parfois gigantesques, c’est probablement beaucoup plus utile qu’une nouvelle syntaxe spectaculaire tous les six mois.
PHP 8.6 est encore en Beta.
On ne vais évidemment pas l’installer demain sur une boutique en production.
En revanche, on vais commencer à faire tourner certains projets dessus.
Parce que le meilleur moment pour découvrir qu’une application ne passe pas sur PHP 8.6, ce n’est pas le 19 novembre.
C’est maintenant.
Sources
Cet article s’appuie sur le calendrier officiel de développement de PHP 8.6 ainsi que sur les RFC et propositions PHP relatives à clamp(), à l’extension de #[Override] aux constantes de classe, aux optimisations des closures, à l’évolution de trim() et aux changements de versions minimales supportées.
