PHP 8.6 sort le 19 novembre : la RC5 est disponible, préparez vos VPS et vos panels

La branche PHP 8.6 arrive au bout de son cycle de test. La RC5 de PHP 8.6.0 est en ligne depuis le 5 novembre 2026 sur la page des pré-versions de php.net, et l'annonce officielle fixe la sortie de la version finale (GA, pour general availability) au jeudi 19 novembre 2026. Le même jour que la RC5, l'équipe a publié PHP 8.5.13RC1 et PHP 8.4.28RC1 : les branches qui tournent aujourd'hui en production recevront donc elles aussi leurs correctifs. Après la série PHP2Shell d'octobre, beaucoup d'administrateurs veulent un calendrier de montée de version clair. Voici ce qu'il faut faire sur un VPS ou un serveur dédié d'ici le 19 novembre : installer php8.6 à côté de la version en place, tester vos sites WordPress, vos panels Pterodactyl ou Pelican et les scripts web de votre serveur FiveM, puis repérer les dépréciations avant qu'elles ne deviennent des erreurs.

Sources : page des pré-versions de php.net, annonces 2026 de php.net, calendrier de PHP 8.6 sur le wiki PHP, fichier UPGRADING de la RC5 et versions supportées.

PHP 8.6 : RC5 le 5 novembre, version finale le 19 novembre

PHP sort une version mineure par an, entre fin novembre et début décembre : PHP 8.3 le 23 novembre 2023, PHP 8.4 le 21 novembre 2024, PHP 8.5 le 20 novembre 2025. Le cycle de PHP 8.6 a démarré le 2 juillet 2026 avec l'alpha 1 ; ses responsables de publication (release managers) sont Daniel Scherzer, Matteo Beccati et Joe Ferguson. Particularité de ce cycle : il n'y a jamais eu de RC1. Le script d'automatisation des responsables de publication n'avait pas relevé les numéros d'API internes (PHP_API_VERSION, ZEND_MODULE_API_NO, ZEND_EXTENSION_API_NO) au bon moment : le code étiqueté RC1 portait donc de mauvais numéros, et l'équipe a publié directement une RC2 le 24 septembre. La RC5 est ainsi, en réalité, la quatrième release candidate.

Un détail à surveiller : le dépôt php-src contient depuis le 10 novembre un commit qui passe le numéro de version à 8.6.0RC6, et le fichier NEWS date cette RC6 du 12 novembre. Elle n'était pas prévue au calendrier et n'a pas encore été annoncée sur php.net au moment où nous écrivons ; le seul correctif que NEWS lui attribue concerne Fileinfo, qui détectait les polices TrueType comme application/octet-stream depuis le passage à libmagic 5.48 (GH-25051). Des builds Windows RC6 sont d'ailleurs déjà proposés sur la page des pré-versions. La date de sortie annoncée, le 19 novembre, n'a pas changé.

Si vous avez installé une préversion de PHP 8.6 avant le 21 octobre (alpha, bêta, RC2 ou RC3), mettez-la à jour : l'annonce de la RC4 précise qu'elle embarque les correctifs des deux vulnérabilités critiques d'exécution de code à distance sans authentification corrigées ce jour-là dans toutes les branches, celles que nous avons détaillées dans notre article sur les failles PHP2Shell CVE-2026-109618 et CVE-2026-109619.

8.5.13RC1 et 8.4.28RC1 : les branches en production aussi

Une nouvelle version mineure ne périme pas les précédentes. Les branches 8.2 à 8.5 continuent de recevoir des correctifs (de sécurité seulement pour 8.2 et 8.3), et la publication simultanée de 8.5.13RC1 et 8.4.28RC1 le 5 novembre annonce les prochaines versions de maintenance de ces deux branches. Une RC n'est pas faite pour la production, mais elle permet de vérifier qu'aucune régression ne touche vos applications avant la version finale. Pour un serveur en production, la règle reste simple : rester sur une branche supportée et appliquer chaque version de maintenance dès sa sortie.

Les branches précédentes ont toutes eu deux ans de support actif puis deux ans de correctifs de sécurité seuls, avec une échéance au 31 décembre. PHP 8.2 ne recevra plus aucun correctif de sécurité après le 31 décembre 2026 : si un de vos serveurs tourne encore en 8.2, la priorité n'est pas PHP 8.6 mais une migration vers 8.4 ou 8.5. Notez aussi que les versions stables actuelles des distributions ne proposent pas PHP 8.6 dans leurs dépôts officiels : Debian 13 « Trixie » fournit PHP 8.4 et Ubuntu 26.04 LTS fournit PHP 8.5. Pour PHP 8.6, il faut passer par un dépôt tiers ou par Docker.

Installer php8.6 en parallèle avec le dépôt Sury

Le dépôt d'Ondřej Surý (packages.sury.org pour Debian, ppa:ondrej/php pour Ubuntu) installe chaque branche de PHP dans des paquets séparés : php8.4-fpm, php8.5-fpm, php8.6-fpm. Plusieurs versions cohabitent donc sur le même VPS Linux, chacune avec son propre service PHP-FPM, son propre socket et ses propres fichiers de configuration dans /etc/php/8.6/. Au 11 novembre 2026, l'état du dépôt est le suivant :

• Debian 12 et Debian 13 : paquets php8.6 en version 8.6.0~rc5 pour l'architecture amd64 depuis le 11 novembre (les architectures ARM en sont encore à la RC3) ;
• Ubuntu 24.04 LTS et 22.04 LTS : le PPA propose 8.6.0~rc3, publiée le 12 octobre ; aucun paquet php8.6 n'y est encore disponible pour Ubuntu 26.04.

Sur Debian, si le dépôt Sury n'est pas encore configuré, voici la méthode documentée par son mainteneur, à lancer en root :

apt-get update
apt-get -y install lsb-release ca-certificates curl
curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
dpkg -i /tmp/debsuryorg-archive-keyring.deb
echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list
apt-get update

Avant d'installer quoi que ce soit, notez la version de PHP que vos sites utilisent et celle que pointe la commande php :

php -v
update-alternatives --display php
ls /run/php/

Installez ensuite PHP 8.6 avec les extensions courantes d'une application web (WordPress, Laravel, phpMyAdmin) :

sudo apt update
sudo apt install php8.6-cli php8.6-fpm php8.6-common php8.6-mysql php8.6-mbstring \
  php8.6-xml php8.6-curl php8.6-zip php8.6-gd php8.6-intl php8.6-bcmath
php8.6 -v

Le piège à connaître : chaque paquet phpX.Y-cli s'enregistre auprès de update-alternatives avec une priorité égale à ses numéros de version accolés (84 pour 8.4, 85 pour 8.5, 86 pour 8.6). En mode automatique, la commande php pointe donc vers la version la plus récente installée, c'est-à-dire la RC de PHP 8.6 dès que vous l'avez installée. Toutes les tâches cron, unités systemd et scripts qui appellent php ou /usr/bin/php sans numéro de version passent alors en 8.6 sans prévenir. Remettez tout de suite la version de production par défaut :

sudo update-alternatives --set php /usr/bin/php8.4
php -v

Adaptez php8.4 à votre branche de production. Côté web, l'installation de php8.6-fpm ne change rien : le nouveau service écoute sur son propre socket, /run/php/php8.6-fpm.sock, et aucun site ne l'utilise tant que vous ne modifiez pas votre configuration Nginx ou Apache. Pour sécuriser ce nouveau pool comme celui de production (utilisateur dédié, disable_functions, open_basedir), reprenez les réglages de notre guide installer PHP-FPM sécurisé sur un VPS Linux.

Tester PHP 8.6 avec l'image Docker officielle

Pour ne rien installer sur l'hôte, l'image Docker officielle php publie les release candidates sous des tags dédiés : 8.6-rc-cli, 8.6-rc-fpm et 8.6.0RC5-apache, avec des variantes Debian (bookworm, trixie) et Alpine. Les tags ont été mis à jour le 10 novembre. Un premier contrôle, sans aucun risque pour la production, consiste à passer tout le code d'un projet au vérificateur de syntaxe de PHP 8.6 :

cd /var/www/mon-site
docker run --rm -v "$PWD":/app:ro -w /app php:8.6-rc-cli \
  sh -c 'find . -name "*.php" -not -path "./vendor/*" -print0 | xargs -0 -n1 php -l | grep -v "^No syntax errors"'

Aucune ligne en sortie signifie qu'aucun fichier ne contient d'erreur de syntaxe. Le volume est monté en lecture seule (:ro), le conteneur ne peut rien modifier. Pour un test complet, lancez la suite de tests du projet dans le même conteneur, ou construisez une image de préproduction à partir de php:8.6-rc-fpm et branchez-la sur une copie de votre base de données. Si Docker n'est pas encore installé, suivez notre guide installer Docker sur un VPS ; pour vérifier les versions de PHP de vos conteneurs existants, notre guide auditer et patcher ses conteneurs Docker PHP donne les commandes.

Brancher un site de test sur PHP-FPM 8.6 et journaliser les dépréciations

Le test le plus parlant reste une copie de votre site servie par PHP-FPM 8.6, sur un sous-domaine de préproduction. Par défaut, le php.ini de production masque les dépréciations : sa valeur error_reporting = E_ALL & ~E_DEPRECATED exclut précisément les avertissements qui vous intéressent ici. Sur l'instance 8.6, qui ne sert qu'aux tests, activez-les et envoyez-les dans un journal dédié :

sudo touch /var/log/php8.6-test.log
sudo chown www-data:www-data /var/log/php8.6-test.log
sudo nano /etc/php/8.6/fpm/php.ini

Dans ce fichier, réglez les directives suivantes, puis redémarrez le service :

error_reporting = E_ALL
log_errors = On
error_log = /var/log/php8.6-test.log

sudo systemctl restart php8.6-fpm

Dans le bloc server Nginx du sous-domaine de test, faites pointer PHP vers le socket de la version 8.6 :

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.6-fpm.sock;
}

Rechargez Nginx (sudo nginx -t && sudo systemctl reload nginx), parcourez le site, connectez-vous à l'administration, passez une commande de test si c'est une boutique, puis comptez ce que PHP 8.6 a signalé :

grep -c "PHP Deprecated" /var/log/php8.6-test.log
grep -E "PHP (Fatal error|Warning)" /var/log/php8.6-test.log | sort | uniq -c | sort -rn | head

Une dépréciation ne casse rien aujourd'hui : elle annonce une suppression dans une version future. Une erreur fatale, en revanche, est un blocage à corriger avant toute bascule. Si vous n'avez jamais monté de bloc serveur Nginx, notre guide Nginx en reverse proxy sur un VPS Linux détaille la structure des fichiers.

WordPress et PHP 8.6 : tester les extensions avant le cœur

La page de compatibilité PHP tenue par l'équipe du cœur de WordPress s'arrête aujourd'hui à PHP 8.5, pris en charge (d'abord en bêta) depuis WordPress 6.9 : PHP 8.6 n'y figure pas encore. Sur un site WordPress, le risque vient surtout des extensions et des thèmes, rarement mis à jour au rythme de PHP. Sur la copie de préproduction, activez le journal de débogage de WordPress dans wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Les messages s'écrivent alors dans wp-content/debug.log, avec le chemin du fichier fautif : le dossier de l'extension ou du thème concerné apparaît directement dans wp-content/plugins/ ou wp-content/themes/. Gardez votre site de production sur sa branche actuelle et à jour de ses correctifs, comme expliqué dans notre article sur WordPress 7.1.4 et ses correctifs de sécurité.

Pterodactyl et Pelican : ne basculez pas le panel

Les panels de serveurs de jeu sont des applications Laravel en PHP, et aucun des deux n'annonce encore la prise en charge de PHP 8.6 :

Pelican exige déjà au minimum PHP 8.4 : un VPS qui l'héberge a de toute façon quitté PHP 8.3. Pour Pterodactyl comme pour Pelican, attendez que la documentation du projet liste PHP 8.6 avant de toucher au panel. Le vrai risque de la semaine est ailleurs : le piège update-alternatives décrit plus haut. La documentation de Pterodactyl fait tourner l'ordonnanceur par une ligne de crontab qui appelle php /var/www/pterodactyl/artisan schedule:run et le worker de file d'attente par l'unité pteroq.service, dont la commande commence par /usr/bin/php. Si vous installez php8.6-cli sur la machine du panel sans remettre la version par défaut, ces deux processus passent en 8.6 au prochain lancement. Vérifiez :

php -v
sudo systemctl restart pteroq
sudo systemctl status pteroq

Pour figer le panel sur sa version quoi qu'il arrive, vous pouvez aussi écrire le chemin complet (/usr/bin/php8.3) dans la crontab et dans ExecStart de l'unité systemd, puis lancer sudo systemctl daemon-reload. Wings, le démon qui pilote les conteneurs des serveurs de jeu, est écrit en Go et n'utilise pas PHP : vos serveurs FiveM, Minecraft ou Rust ne sont pas concernés par la montée de version. Pour la maintenance du panel lui-même, voir notre guide mettre à jour Pterodactyl 1.15.2 et notre tutoriel installer Pterodactyl pour gérer ses serveurs de jeu.

Scripts web autour d'un serveur FiveM : ce qui peut casser

Le serveur FiveM lui-même (FXServer et ses ressources Lua ou JavaScript) ne dépend pas de PHP. Mais beaucoup de communautés font tourner, sur le même VPS ou à côté, des pages web en PHP : site vitrine, formulaire de candidature pour la whitelist, panneau d'administration maison qui lit la base MySQL du serveur, page de dons, phpMyAdmin. Ce sont souvent de vieux scripts, écrits avec mysqli et les sessions natives de PHP, et donc les plus exposés aux changements de PHP 8.6 :

• mysqli : mysqli_get_charset(), mysqli::get_charset(), mysqli_stmt_init(), mysqli::stmt_init() et le constructeur de mysqli_stmt appelé sans requête sont dépréciés. Préférez mysqli_prepare() ou $mysqli->prepare(), qui préparent la requête en une seule étape, et mysqli_character_set_name() pour lire le jeu de caractères de la connexion ;
• sessions : trois valeurs par défaut changent. session.use_strict_mode passe à 1, session.cookie_httponly à 1 et session.cookie_samesite à Lax. C'est plus sûr, mais un script qui lit le cookie de session en JavaScript, ou qui attend ce cookie au retour d'un POST venu d'un autre site (certains retours de paiement ou de connexion externe), peut perdre la session ;
• fonctions de type : is_integer(), is_long(), is_double() et doubleval() sont dépréciées au profit de is_int(), is_float() et floatval(), très présentes dans le code ancien ;
• chaînes : trim(), ltrim() et rtrim() retirent désormais aussi le caractère de saut de page (\f) par défaut.

Testez ces pages sur l'instance 8.6 avec le journal décrit plus haut, en pointant vers une copie de la base de données plutôt que vers la base de production du serveur. Notre guide pour sauvegarder MySQL avec mysqldump donne la commande d'export, et celui pour lier la base de données MySQL d'un serveur FiveM rappelle où se trouvent les identifiants utilisés par oxmysql.

Les dépréciations de PHP 8.6 à repérer dans votre code

Le fichier UPGRADING de la RC5 liste l'ensemble des changements. Voici les dépréciations que l'on retrouve le plus souvent dans du code d'applications web, avec leur remplacement :

Pour les repérer avant même de lancer l'application, une recherche dans le code suffit à dégrossir :

grep -rnE "\b(is_integer|is_long|is_double|doubleval|spl_object_hash|strcoll|mysqli_get_charset|mysqli_stmt_init|metaphone|mb_ereg)\s*\(" \
  --include="*.php" --exclude-dir=vendor /var/www/mon-site

Deux changements de comportement concernent directement l'administration système. D'abord, en cas de dépassement mémoire fatal (hard OOM), PHP appelle désormais abort() au lieu de exit(1) : le processus se termine avec le code 134 et peut générer un fichier core. Surveillez l'espace disque et la configuration de systemd-coredump sur les machines où des scripts lourds tournent en CLI. Ensuite, Fileinfo passe à la version 5.48 de la bibliothèque file : une base « magic » personnalisée compilée avec une version plus ancienne doit être régénérée.

Ce que PHP 8.6 apporte

Côté développement, PHP 8.6 n'est pas qu'une liste de dépréciations. Parmi les nouveautés listées dans UPGRADING :

• l'application partielle de fonctions (partial function application), qui permet de créer une fonction à partir d'une autre en fixant une partie de ses arguments ;
• des valeurs par défaut pour les propriétés readonly ;
• la fonction clamp(), la classe Time\Duration, l'énumération SortDirection et une nouvelle API de polling des entrées-sorties (Io\Poll) ;
• mysqli_quote_string(), une API d'erreurs pour les flux (stream_last_errors()) et, côté OpenSSL, la reprise de session TLS et l'envoi de données anticipées TLS 1.3 (0-RTT) ;
• des gains de performance sur array_map(), l'encodage JSON et plusieurs fonctions de tableaux et de chaînes. Sous Windows, les builds officiels passent à Visual Studio 2026 et à OpenSSL 4.

Le calendrier conseillé pour vos serveurs

1. D'ici le 19 novembre : installer php8.6 en parallèle (Sury ou Docker), remettre la commande php sur la version de production, tester vos sites sur un sous-domaine de préproduction et collecter les dépréciations. Les bogues trouvés sur la RC se signalent sur le gestionnaire de tickets GitHub de php-src.
2. Le 19 novembre : PHP 8.6.0 sort. Ne basculez pas la production le jour même : attendez que vos dépendances (WordPress, Laravel, panels, extensions PECL) annoncent la prise en charge, et laissez passer les premières versions de maintenance.
3. Dès leur sortie : appliquez PHP 8.5.13 ou 8.4.28 sur les serveurs en production, puis redémarrez PHP-FPM pour que les processus chargent le nouveau binaire.
4. Avant le 31 décembre 2026 : sortez de PHP 8.2, qui ne recevra plus aucun correctif de sécurité, vers 8.4 ou 8.5.

Pour que les versions de maintenance s'installent sans attendre une intervention manuelle, voyez notre guide pour automatiser les mises à jour de sécurité. Et si vous voulez une machine à part pour vos tests de PHP 8.6, sans risque pour la production, un VPS Linux de préproduction fait l'affaire ; pour plusieurs sites, un panel et une base de données sur la même machine, un serveur dédié laisse de la marge.