Maintenir PHP à jour : support, fin de vie et migration

Maintenir PHP à jour demande de suivre deux informations différentes : le support de la branche et les correctifs réellement installés. Au 21 octobre 2026, PHP 8.2 et 8.3 reçoivent uniquement des correctifs de sécurité critiques ; PHP 8.4 et 8.5 restent en support actif. Une migration maîtrisée associe inventaire, vérification des incompatibilités, préproduction, sauvegarde restaurable et contrôle après bascule. « Sans casse » désigne cette méthode de réduction du risque, jamais une garantie de zéro régression.

Quelle différence entre branche supportée et version corrigée ?

Une branche supportée peut héberger une installation qui manque des correctifs. « PHP 8.4 » désigne une branche ; le numéro complet identifie une version précise. Le calendrier indique jusqu’à quand le projet PHP maintient la branche. Les annonces de publication indiquent quels correctifs installer.

Les annonces officielles du 21 octobre 2026 présentent ainsi PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 comme des versions de sécurité corrigeant deux vulnérabilités critiques. Ce repère daté concorde avec la nécessité de corriger les branches maintenues ; il ne constitue pas une liste à conserver indéfiniment. Lors de chaque intervention, vérifiez les nouvelles annonces et les paquets fournis par votre distributeur.

Il faut donc séparer la mise à jour corrective, dans une branche encore maintenue, de la migration de branche, qui impose une revue de compatibilité. Installer un correctif sur PHP 8.2 ne prolonge pas sa période de support.

Quelles versions PHP sont supportées et jusqu’à quand ?

Le projet PHP distingue le support actif, les correctifs de sécurité critiques uniquement, puis la fin de vie. La politique actuelle prévoit deux années de support actif puis deux années de support de sécurité ; pour planifier, utilisez les échéances calendaires publiées dans la page Supported Versions.

PHP 8.1 est en fin de vie depuis le 31 décembre 2025. La liste officielle des branches non supportées classe aussi PHP 8.0 et PHP 7.4 parmi les branches abandonnées. Un site encore fonctionnel ne démontre donc pas que son moteur reçoit des corrections.

Ces échéances concernent le projet PHP. Si un prestataire annonce des correctifs rétroportés pour une ancienne branche, demandez son périmètre, ses avis de sécurité et sa durée contractuelle de maintenance. Les annonces PHP précisent que certains distributeurs et fournisseurs de support prolongé proposent de tels correctifs ; leur couverture doit être vérifiée auprès du fournisseur.

Comment connaître la version PHP réellement utilisée ?

L’inventaire doit couvrir le moteur qui sert le site et les traitements en arrière-plan. Sur un environnement que vous administrez, les options officielles de la ligne de commande PHP permettent ces lectures locales :

php -v
php --ini
php -m

Ces commandes affichent respectivement la version du binaire invoqué, les fichiers de configuration et les modules. Elles ne prouvent pas que le site web utilise ce même binaire. La documentation du fichier de configuration décrit notamment les configurations propres à chaque interface d’exécution, ou SAPI.

Faites donc confirmer par l’hébergeur ou l’administrateur la version affectée au site, le mode PHP-FPM, module Apache ou CGI, les extensions, ainsi que les versions des tâches planifiées. Conservez aussi les versions du CMS, du framework et des dépendances.

N’exposez pas une page phpinfo() au public : cette fonction peut afficher chemins, configuration et variables d’environnement, comme l’indique sa documentation officielle. Préférez un relevé administratif restreint. Si l’application fournit des données à des agents IA, complétez l’inventaire par leurs droits et leurs accès, selon notre guide pour sécuriser les agents IA contre les fuites de données.

Quelle branche PHP choisir pour la migration ?

La cible doit être supportée et compatible avec l’application. Ne choisissez pas uniquement le numéro le plus récent : demandez une compatibilité documentée pour le CMS, ses extensions, le framework, les bibliothèques et les modules PHP nécessaires.

Pour une nouvelle cible, examinez d’abord les branches encore en support actif. Si une contrainte impose une branche en support de sécurité uniquement, consignez cette contrainte et la prochaine migration. Cette priorité constitue une recommandation de maintenance Noolya, à adapter aux dépendances réelles.

Les guides PHP demandent de tester les incompatibilités avant la production. Exemple concret : lors du passage à PHP 8.4, certaines fonctions GD, dont imagejpeg() et imagepng(), lèvent une ValueError pour une qualité invalide, selon le guide des incompatibilités PHP 8.4. Un parcours de génération d’images mérite donc un test ciblé.

Comment mettre PHP à jour en limitant les régressions ?

Une mise à jour maîtrisée prépare la preuve de fonctionnement et la restauration avant la bascule. Le protocole suivant est une recommandation opérationnelle Noolya. Il s’appuie sur la revue des changements demandée par les guides PHP, notamment le guide de migration vers PHP 8.5.

La restauration et les critères de validation se préparent avant la bascule.

1. Définir le périmètre et les critères de réussite

Listez les sites, interfaces, traitements planifiés et échanges externes concernés. Pour chaque parcours critique, notez le résultat attendu : connexion, formulaire, paiement si présent, export ou génération documentaire. Désignez la personne qui valide la recette et celle qui peut décider un retour arrière.

2. Préparer une restauration cohérente

Sauvegardez fichiers, données et configuration dans un emplacement protégé. Vérifiez la restauration sur un environnement isolé. Si le changement comporte une migration de données, précisez comment conserver ou réconcilier les opérations reçues après la bascule : remettre un ancien code ne garantit pas la compatibilité avec des données transformées.

3. Tester la cible en préproduction

Reproduisez les paramètres utiles de production, avec des données adaptées et protégées. Consultez les guides de chaque transition traversée, leurs incompatibilités et leurs dépréciations. Vérifiez les extensions et les dépendances, puis jouez les parcours définis. Prévenez tout envoi réel de courriel, paiement ou synchronisation depuis les tests.

4. Basculer avec une décision de repli explicite

Fixez une fenêtre adaptée à l’activité et conservez les éléments nécessaires au retour arrière. Évitez de mêler une mise à jour PHP, une refonte fonctionnelle et des changements de données sans rapport : chaque changement supplémentaire complique l’identification d’une régression. Faites confirmer l’activation de la version cible sur les processus concernés.

5. Vérifier le service réellement rendu

Contrôlez de nouveau la version utilisée par le site et les tâches, puis rejouez la recette. Examinez les erreurs, les traitements différés et les parcours métier. Conservez les versions avant et après, les résultats et la décision de validation. Pour une application reliée à un système IA, la checklist d’auditabilité complète cette traçabilité.

En présence d’une régression bloquante, appliquez le repli préparé en tenant compte du risque de sécurité. Réexposer une ancienne version vulnérable ne résout pas l’incident : une restriction temporaire du service peut être nécessaire pendant la correction.

Comment éviter de retrouver une version PHP en fin de vie ?

Chaque application PHP doit avoir un responsable de maintenance et une prochaine échéance. Tenez un inventaire des versions exactes, du fournisseur des paquets, des dépendances bloquantes et de la dernière restauration testée. Associez à chaque annonce de sécurité une décision documentée et un responsable.

Planifiez la migration avant l’échéance officielle, avec une marge adaptée à vos tests. Pour les applications connectées à des modèles ou à des agents, rattachez ces responsabilités à la gouvernance de l’IA. La disponibilité du moteur, les accès aux données et la continuité des usages doivent être suivis ensemble.

Comment Noolya intervient sur la maintenance et les failles PHP ?

Noolya intervient pour vérifier l’exposition et préparer la correction. L’accompagnement peut comprendre le diagnostic des versions et modes d’exécution, le plan de mise à jour, la correction avec tests de non-régression, le durcissement et la vérification après intervention. Le périmètre dépend de l’application, de l’hébergement et des accès disponibles.

Lorsqu’une application PHP soutient un projet IA, notre audit IA en entreprise permet aussi de relier les contraintes techniques aux usages et aux priorités métier.

Commencez par le diagnostic faille PHP, une auto-évaluation déclarative qui ne réalise aucun scan et ne constitue pas un test de sécurité. Pour une vérification détaillée, contactez Noolya ou prenez rendez-vous sur Cal.com.

Questions fréquentes

PHP 8.2 est-il encore maintenu en octobre 2026 ? PHP 8.2 reçoit uniquement des correctifs de sécurité critiques jusqu’au 31 décembre 2026, selon le calendrier officiel. Il faut installer les correctifs disponibles et préparer la migration avant cette échéance ; une mise à jour corrective ne repousse pas la fin du support.

Faut-il passer par chaque branche PHP intermédiaire ? Les guides PHP documentent les transitions entre branches successives. Notre recommandation est de lire tous les guides correspondant au chemin parcouru et de tester la cible complète en préproduction ; cela ne signifie pas déployer chaque branche intermédiaire en production.

Une sauvegarde suffit-elle pour sécuriser la mise à jour ? Une sauvegarde doit pouvoir être restaurée dans un état cohérent. Le protocole proposé demande de tester la restauration et de prévoir le traitement des données reçues après la bascule, particulièrement si des changements applicatifs ou de données accompagnent la migration PHP.

Un site fonctionnel est-il nécessairement à jour ? Le fonctionnement visible ne renseigne ni sur la fin du support ni sur les correctifs installés. Comparez la version complète et la provenance des paquets aux annonces officielles, puis vérifiez le moteur réellement utilisé par le site et les traitements associés.

Sources

Sources primaires PHP consultées le 21 octobre 2026. Les recommandations de migration et d’organisation sont celles de Noolya ; elles doivent être adaptées au système concerné.

• Supported Versions : politique de support et échéances des branches maintenues.
• Unsupported Branches : branches en fin de vie, dont PHP 8.1.
• News Archive - 2026 : annonces du 21 octobre et précision sur les correctifs des distributeurs.
• Command line options : version, configuration et modules du binaire invoqué.
• The configuration file : fichiers de configuration et interfaces d’exécution.
• phpinfo : informations techniques et variables susceptibles d’être affichées.
• Backward Incompatible Changes : changements incompatibles de PHP 8.4, notamment GD.
• Migrating from PHP 8.4.x to PHP 8.5.x : tests avant production et liens vers les autres guides de migration.

Couverture : logo PHP de Colin Viebrock, CC BY-SA 4.0, intégré à une composition éditoriale diffusée sous la même licence. Référence officielle PHP. Aucune approbation de PHP n’est suggérée.