Pas de production
Une Release Candidate reste une préversion. Elle sert à identifier et signaler les problèmes, non à remplacer immédiatement une branche stable sur le serveur principal.
Traitement en cours…
Compatibilité et migration
PHP 8.6 entre dans sa dernière phase de stabilisation avant une sortie générale planifiée le 19 novembre 2026. Pour les applications PHP et les sites WordPress, le moment est venu de tester la compatibilité, pas de migrer la production.
Le développement de PHP 8.6 a franchi le hard feature freeze le 22 septembre 2026 : les fonctionnalités sont désormais gelées et les efforts se concentrent sur la stabilisation. Le calendrier prévoit plusieurs Release Candidates avant la version stable, mais le statut exact de chaque préversion doit être vérifié dans les annonces officielles.
PHP 8.6 est suffisamment avancé pour lancer des essais représentatifs. Il reste toutefois une préversion : les tests doivent être réalisés dans un environnement isolé couvrant le code, les dépendances, les sessions, la base de données et les parcours métier.
Le calendrier du projet fixe le hard feature freeze au 22 septembre 2026. Il positionne une Release Candidate le 24 septembre, puis d’autres versions candidates les 8 et 22 octobre et le 5 novembre, avant une sortie stable actuellement planifiée le 19 novembre 2026.
Le calendrier a été ajusté : RC1 y apparaît comme abandonnée et RC2 est positionnée au 24 septembre. Au moment de la rédaction, le 24 septembre 2026, php.net affiche toutefois encore PHP 8.6 Beta 3 comme dernière version de test officiellement annoncée.
RC2 est donc inscrite au calendrier pour cette date, mais elle ne doit pas être considérée comme publiée avant la mise en ligne de l’annonce officielle. Cette distinction illustre une règle utile pendant tout le cycle : consulter à la fois le calendrier prévisionnel et les publications effectives du projet.
Une Release Candidate reste une préversion. Elle sert à identifier et signaler les problèmes, non à remplacer immédiatement une branche stable sur le serveur principal.
Les résultats n’ont de valeur que si la configuration PHP, les extensions, la base de données et les services externes sont proches de la production.
Le contrôle doit couvrir le code sur mesure, le framework ou le CMS, les bibliothèques Composer, les extensions et les traitements planifiés.
Les erreurs, avertissements et dépréciations doivent être examinés, même lorsque les pages semblent fonctionner normalement.
Une application fonctionnant sous PHP 8.5 ne peut pas être déclarée automatiquement compatible avec PHP 8.6. Les chemins rarement exécutés — imports, exports, tâches CRON, traitements de fichiers ou scénarios d’erreur — sont souvent ceux qui révèlent les écarts.
PHP 8.6 doit modifier trois valeurs par défaut : session.use_strict_mode passe de 0 à 1, session.cookie_httponly de 0 à 1, et session.cookie_samesite d’une valeur non définie à Lax.
Ces choix visent une configuration plus sûre face à certains risques liés aux sessions et aux requêtes intersites. Ils devraient être transparents pour de nombreuses applications modernes, notamment lorsque ces protections sont déjà configurées explicitement.
Avec session.cookie_httponly=1, le cookie devient inaccessible depuis document.cookie. Toute application qui récupère l’identifiant de session dans le navigateur doit être contrôlée et, en principe, orientée vers un mécanisme d’authentification dédié.
Le cookie n’est normalement pas envoyé lors de certaines requêtes cross-site. Les SSO, formulaires entre domaines, retours de services tiers et architectures multidomaines demandent donc des essais de bout en bout.
Un mécanisme de connexion peut réussir dans un test unitaire et échouer lorsqu’un navigateur traverse plusieurs domaines. L’authentification, la déconnexion, les redirections et les retours de passerelles externes font partie des premiers scénarios à rejouer.
Il faut également vérifier le comportement des sessions existantes, la rotation des identifiants et les éventuelles hypothèses historiques du code. Le mode strict peut révéler des implémentations qui acceptaient auparavant des identifiants non initialisés par le serveur.
Les applications qui lisent le cookie PHP en JavaScript ou font circuler une session entre plusieurs domaines présentent un risque plus élevé. Elles doivent être examinées avant toute décision de migration.
Le document UPGRADING de PHP 8.6 répertorie plusieurs comportements devenant plus stricts. Des fonctions liées aux tableaux, aux chemins, aux locales, aux processus, aux archives ou à certaines extensions peuvent désormais lever plus clairement une ValueError ou une TypeError.
array_filter() doit notamment refuser un mode invalide avec une ValueError. pathinfo() vérifie davantage son paramètre de drapeau, tandis que d’autres fonctions ne tolèrent plus certaines valeurs hors périmètre.
Une vérification limitée à la page d’accueil ne suffit donc pas. Les formulaires, appels API, imports, exports, traitements asynchrones et scénarios dégradés doivent être exécutés avec des données valides comme invalides.
mbstring disparaisse. Les appels directs et indirects via Composer doivent être identifiés.COM_RESET_CONNECTION.configure.COM_RESET_CONNECTION permet de remettre une connexion dans son état initial avant sa réutilisation. Les versions de base de données antérieures peuvent continuer à fonctionner avec PHP 8.6, mais plus avec les connexions persistantes de la même manière.
Une application qui dépend involontairement d’un état laissé par une requête précédente peut également changer de comportement. Ce risque est limité dans les environnements modernes, mais mérite un contrôle sur les logiciels métier et serveurs conservés depuis plusieurs années.
Le prérequis Autoconf 2.71 concerne surtout les environnements personnalisés et les pipelines construisant PHP directement depuis ses sources Git. Il ne s’applique pas de la même façon aux compilations réalisées à partir des archives officielles de publication.
Les images internes doivent donc être auditées pour déterminer leur origine, leurs outils de compilation et leur prise en charge du standard C11.
Le but de cette phase n’est pas de prouver qu’une page s’affiche, mais de découvrir maintenant ce qui pourrait casser lors de la future migration.
Les tests de compatibilité peuvent aussi servir à étudier les possibilités offertes par PHP 8.6. Plusieurs évolutions concernent l’écriture du code, les objets immuables et la manipulation des URI.
L’application partielle de fonctions permet de fixer certains arguments et d’en laisser d’autres à compléter. Une expression telle que $replaceHello = str_replace('hello', 'bonjour', ?); produit une Closure attendant la valeur manquante.
PHP 8.6 autorise aussi une valeur par défaut sur certaines propriétés d’instance readonly. L’API URI progresse avec des fonctions de construction et d’identification, une meilleure gestion du percent-encoding et la classe Uri\Rfc3986\UriBuilder.
Une incompatibilité peut provenir d’une bibliothèque plutôt que du code métier. Le changelog de Composer 2.10.3, publié le 27 août 2026, mentionne explicitement des corrections de messages de dépréciation liés à PHP 8.6.
Une démarche raisonnable consiste à créer une branche dédiée, installer PHP 8.6 dans un environnement isolé, puis exécuter composer update et composer check-platform-reqs. Les tests automatisés et l’analyse des avertissements viennent ensuite.
Au 24 septembre 2026, la matrice officielle de compatibilité de WordPress documente PHP jusqu’à la version 8.5. PHP 8.6 n’y figure pas encore, ce qui est cohérent avec le stade actuel de son développement.
Le travail de prise en charge des nouvelles versions de PHP commence généralement après le feature freeze et les versions bêta. Le simple accès à l’administration ne permet donc pas de conclure qu’un site est prêt pour la production.
WordPress Core, le thème actif, le thème enfant, chaque extension, le code personnalisé, les éventuelles dépendances Composer, les tâches planifiées et les services externes doivent être validés séparément.
Elle indique le niveau de prise en charge de WordPress Core, mais ne couvre pas automatiquement les thèmes, extensions et développements propres au site.
Elle dépend de l’ensemble réellement installé et configuré, y compris les intégrations externes, les tâches planifiées et les parcours éditoriaux ou commerciaux.
Le niveau de priorité dépend de l’architecture du projet. Les sessions et les flux multidomaines méritent néanmoins une attention particulière en raison des nouvelles valeurs par défaut.
| Zone | Contrôles | Risque recherché |
|---|---|---|
| Sessions | Connexion, déconnexion, SSO, POST intersites et retours externes | Cookie absent ou inaccessible |
| Code et dépendances | Tests, dépréciations, types et paramètres invalides | Exceptions ou comportements modifiés |
| Données | Imports, exports, fichiers, archives et génération de documents | Chemins peu testés devenus bloquants |
| Infrastructure | Extensions, Docker, compilation, MySQL ou MariaDB | Prérequis non satisfaits |
| CMS | Cœur, thème, extensions, tâches planifiées et code personnalisé | Compatibilité partielle du site |
| Performances | Temps de réponse, mémoire, traitements et charge SQL | Régression propre au projet |
Les notes de PHP 8.6 signalent des optimisations concernant notamment printf(), certains appels de constructeurs, array_map(), JSON, DOM et les builds ZTS. Ces évolutions doivent être mesurées sur l’application réelle plutôt qu’extrapolées depuis un microbenchmark.
Temps de réponse, consommation mémoire, durée des traitements en arrière-plan et charge de la base de données fournissent des indicateurs plus utiles pour décider d’une migration.
La préparation peut commencer avant la version stable à condition de préserver la production et de documenter chaque résultat. L’objectif est d’obtenir une photographie fiable des blocages, dépréciations et travaux nécessaires.
La sortie stable de PHP 8.6 est actuellement planifiée le 19 novembre 2026, mais cela ne crée pas d’obligation de basculer immédiatement. PHP 8.5, sorti le 20 novembre 2025, reste activement supporté jusqu’à la fin de 2027, puis doit recevoir des correctifs de sécurité jusqu’à fin 2029. PHP 8.4 demeure également une branche supportée.
Une application stable peut donc attendre que ses dépendances et son infrastructure soient prêtes. À l’inverse, différer les premiers tests pendant plusieurs années transforme une migration planifiable en dette technique.
La période des Release Candidates offre du temps aux équipes, aux mainteneurs de bibliothèques et aux éditeurs d’extensions pour identifier les incompatibilités. Les correctifs peuvent ainsi être préparés avant que la nouvelle version ne devienne une cible de production.
Le passage effectif doit intervenir après validation de l’environnement complet, sauvegarde, plan de retour arrière et contrôle des composants tiers.
PHP 8.6 apporte de nouvelles API et plusieurs améliorations, mais sa valeur en production dépendra d’abord de la qualité de la préparation. Les changements de session, la validation plus stricte des paramètres et les prérequis techniques constituent les priorités de test.
Pour WordPress comme pour une application PHP sur mesure, la méthode reste identique : éprouver une copie représentative, observer les journaux, tester les parcours réels et ne modifier le serveur principal qu’après validation.
Le calendrier des préversions peut encore évoluer. Le statut des Release Candidates et de la version stable doit donc être confirmé dans les publications officielles avant toute décision opérationnelle.
Calendrier officiel du projet PHP 8.6 et document de migration UPGRADING, à consulter sur les espaces officiels du projet PHP pour confirmer le statut des préversions et les changements techniques.
Matrice officielle de compatibilité PHP de WordPress et changelog de Composer 2.10.3, cités pour situer l’état de prise en charge et l’outillage au 24 septembre 2026.
DÉVELOPPEMENT WEB
Migration PHP, mise à jour de CMS ou évolution de framework : identifiez les points de compatibilité et validez les parcours essentiels avant la mise en ligne.
Saisissez au moins 2 caractères pour lancer la recherche.