Retour au blog

Changer de version PHP sur cPanel : passer à PHP 8.3, 8.4 ou 8.5 sans casser son site

Publié le 19 octobre 2026 par Admin
Code PHP d'un fichier de configuration affiché dans un éditeur sur fond sombre

Depuis le 1er janvier 2026, PHP 8.1 ne reçoit plus aucun correctif de sécurité, et PHP 8.2 suivra le 31 décembre 2026. Si votre site tourne encore sur l'une de ces versions, il est temps de changer de version PHP dans cPanel. Ce guide vous montre comment choisir entre PHP 8.3, 8.4 et 8.5, tester la nouvelle version sur une copie de votre site, puis basculer en production avec un retour arrière possible en un clic.

Pourquoi changer de version PHP maintenant

PHP suit un cycle de vie fixe : chaque branche reçoit deux ans de corrections de bugs (support actif), puis deux ans de correctifs de sécurité uniquement. Une fois cette période terminée, plus aucune faille découverte n'est corrigée. Un site WordPress ou PrestaShop qui reste sur une version en fin de vie s'expose donc à des vulnérabilités connues et publiques.

Il y a aussi un intérêt pratique : les extensions et thèmes récents abandonnent progressivement les vieilles versions de PHP, et chaque nouvelle branche apporte des gains de performances. Rester en arrière finit par bloquer les mises à jour de votre CMS.

Le calendrier officiel des versions PHP

Voici les dates publiées par le projet PHP sur php.net (pages « Supported Versions » et « Unsupported Branches »), vérifiées en octobre 2026 :

VersionSortieFin du support actifFin des correctifs de sécuritéÉtat en octobre 2026
PHP 8.1novembre 202125 novembre 202331 décembre 2025Fin de vie (dernière version : 8.1.34)
PHP 8.28 décembre 202231 décembre 202431 décembre 2026Sécurité seulement, plus que quelques semaines
PHP 8.323 novembre 202331 décembre 202531 décembre 2027Sécurité seulement
PHP 8.421 novembre 202431 décembre 202631 décembre 2028Support actif
PHP 8.520 novembre 202531 décembre 202731 décembre 2029Support actif

En pratique, PHP 8.4 est aujourd'hui le meilleur compromis : il est couvert jusqu'à fin 2028 et largement pris en charge par les CMS et les extensions. PHP 8.5 vous donne une année de plus, à condition que tout votre écosystème le supporte. PHP 8.3 reste une étape intermédiaire acceptable si une extension bloque, mais sa fin de vie arrive dès fin 2027.

Quelle version choisir selon votre CMS

WordPress

Selon le manuel officiel de WordPress (page « PHP Compatibility and WordPress Versions »), WordPress 6.9 et les versions suivantes prennent en charge PHP 8.5, et PHP 8.4 est pris en charge depuis WordPress 6.7. Le libellé « bêta » que WordPress appliquait à ces versions a été retiré en mai 2026. Depuis WordPress 7.0, la version minimale de PHP exigée est 7.4.

Le cœur de WordPress n'est cependant que la moitié de l'histoire : ce sont surtout les extensions et le thème qui posent problème lors d'un changement de version. Vérifiez sur la fiche de chaque extension la mention « Version PHP requise » et la date de dernière mise à jour. Une extension qui n'a pas été mise à jour depuis deux ans est un risque.

PrestaShop

La documentation officielle de PrestaShop donne un tableau de compatibilité précis :

PrestaShopPHP 8.1PHP 8.2PHP 8.3PHP 8.4PHP 8.5
8.0 à 8.2RecommandéNon pris en chargeNon pris en chargeNon pris en chargeNon pris en charge
9.0OuiOuiOuiRecommandéNon pris en charge
9.1OuiOuiOuiOuiRecommandé

Le point important : une boutique PrestaShop 8 est bloquée sur PHP 8.1, une version qui ne reçoit plus de correctifs. Pour sortir de cette impasse, il faut d'abord migrer la boutique vers PrestaShop 9, puis changer de version PHP. Faire l'inverse (passer en PHP 8.3 sur un PrestaShop 8) mène presque toujours à des erreurs. PrestaShop 9 demande aussi plusieurs extensions PHP (intl, gd, zip, curl, mbstring, fileinfo, entre autres) et recommande un memory_limit d'au moins 512M.

Ce qui peut casser en passant à PHP 8.4 ou 8.5

Les changements entre versions mineures de PHP 8 sont surtout des dépréciations : le code fonctionne encore, mais génère des avertissements dans les journaux. Les vraies pannes viennent en général de vieux modules ou d'extensions PHP absentes. Voici les dépréciations qui touchent le plus souvent les extensions WordPress et les modules PrestaShop :

  • PHP 8.4 : les paramètres implicitement nullables (function f(Type $a = null) doit devenir ?Type $a = null), l'utilisation de E_USER_ERROR avec trigger_error(), la constante E_STRICT, et l'appel de fgetcsv() ou fputcsv() sans préciser le paramètre escape.
  • PHP 8.5 : les transtypages non canoniques comme (integer) ou (boolean), l'opérateur « backtick » qui exécute une commande système, l'utilisation de null comme clé de tableau, la variable $http_response_header, et certaines constantes PDO spécifiques à MySQL au profit de leurs équivalents dans Pdo\Mysql.

Le cas le plus fréquent de « page blanche » ou d'erreur 500 juste après une bascule reste pourtant une extension PHP manquante dans la nouvelle version : chaque version de PHP installée sur le serveur a ses propres extensions. Si intl ou imagick est activé pour PHP 8.2 mais pas pour PHP 8.4, votre CMS échouera en 8.4.

Étape 1 : faire l'inventaire avant de toucher à quoi que ce soit

  1. Notez la version PHP actuelle de chaque domaine. Elle est affichée dans l'outil MultiPHP Manager de cPanel (section Logiciel).
  2. Mettez à jour votre CMS, votre thème et toutes vos extensions ou modules avant de changer de version PHP. Une mise à jour corrige souvent les incompatibilités.
  3. Faites une sauvegarde complète : fichiers et base de données. L'outil Sauvegarde (ou l'assistant de sauvegarde) de cPanel permet de télécharger une archive du répertoire personnel et un export de chaque base MySQL.
  4. Repérez les extensions abandonnées et cherchez une alternative maintenue.

Étape 2 : tester la nouvelle version sur une copie du site

C'est l'étape que la plupart des tutoriels oublient. MultiPHP Manager permet de choisir une version de PHP par domaine et par sous-domaine. Vous pouvez donc faire tourner une copie de votre site en PHP 8.4 pendant que le site principal reste sur sa version actuelle.

  1. Créez un sous-domaine de test, par exemple test.votresite.fr, depuis l'interface Domaines de cPanel, avec son propre dossier racine.
  2. Copiez le site : pour WordPress, l'outil de « staging » de Softaculous le fait en quelques clics si votre hébergeur le propose. Sinon, copiez les fichiers avec le Gestionnaire de fichiers (compresser, déplacer, extraire), puis dupliquez la base de données avec phpMyAdmin (export puis import dans une nouvelle base).
  3. Adaptez la configuration de la copie : nom de la base dans wp-config.php (WordPress) ou app/config/parameters.php (PrestaShop), puis l'adresse du site (options siteurl et home pour WordPress, URL de la boutique dans la table ps_shop_url pour PrestaShop).
  4. Protégez la copie avec l'outil Confidentialité des répertoires de cPanel (mot de passe), pour qu'elle ne soit ni indexée ni accessible au public.
  5. Passez uniquement le sous-domaine de test sur la nouvelle version PHP dans MultiPHP Manager.

Activez ensuite le journal des erreurs sur la copie. Pour WordPress, dans wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );     // écrit dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // n'affiche rien aux visiteurs

Pour PrestaShop, activez le mode debug dans Paramètres avancés > Performances. Parcourez ensuite les pages clés : accueil, fiche produit, panier, paiement en mode test, formulaire de contact, connexion à l'administration, envoi d'un e-mail. Consultez le fichier debug.log, les fichiers error_log des dossiers du site et l'outil Erreurs de cPanel. Une ligne « Deprecated » n'est pas bloquante ; une ligne « Fatal error » l'est.

Étape 3 : changer la version PHP dans cPanel

Une fois la copie validée, la bascule du site principal prend moins d'une minute :

  1. Connectez-vous à cPanel et ouvrez MultiPHP Manager dans la section Logiciel.
  2. Cochez la case du domaine à modifier (vous pouvez en cocher plusieurs).
  3. Choisissez la version dans le menu PHP Version en haut à droite. Les versions s'affichent sous la forme PHP 8.4 (ea-php84) ; celles marquées « Recommended » sont conseillées par l'administrateur du serveur.
  4. Cliquez sur Apply. La colonne de version du domaine est mise à jour immédiatement.

Concrètement, cPanel ajoute un bloc dans le fichier .htaccess à la racine du domaine. Ne le modifiez pas à la main, cPanel le réécrit :

# php -- BEGIN cPanel-generated handler, do not edit
# Set the "ea-php84" package as the default "PHP" programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php84 .php .php8 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

Si un domaine affiche la mention « Inherited », il utilise la version par défaut du serveur, choisie par l'hébergeur : elle peut changer sans action de votre part. Mieux vaut fixer explicitement la version de chaque site.

Pour vérifier la version réellement utilisée, déposez temporairement un fichier au nom difficile à deviner dans la racine du site, ouvrez-le dans le navigateur, puis supprimez-le :

<?php echo PHP_VERSION;

Si la version voulue n'apparaît pas

Une version absente du menu n'est pas installée sur le serveur ou n'est pas ouverte à votre compte. Son installation se fait côté serveur, dans EasyApache 4 : vous ne pouvez pas l'ajouter vous-même depuis cPanel. Contactez le support de votre hébergeur. Sur certains hébergements, la version se choisit aussi dans un outil « Select PHP Version », qui permet en plus d'activer ou de désactiver des extensions PHP vous-même.

Étape 4 : vérifier vos réglages PHP après la bascule

Chaque version de PHP a sa propre configuration par défaut. Après le changement, ouvrez le MultiPHP INI Editor (juste à côté de MultiPHP Manager), sélectionnez votre domaine et vérifiez au minimum :

  • memory_limit : 256M pour WordPress avec un constructeur de pages, 512M minimum pour PrestaShop 9 ;
  • upload_max_filesize et post_max_size : à ajuster selon la taille de vos médias ;
  • max_execution_time : à relever si vos imports de produits ou vos sauvegardes s'interrompent ;
  • display_errors : désactivé en production.

Videz enfin les caches : extension de cache WordPress, cache Smarty et Symfony de PrestaShop (Paramètres avancés > Performances > Vider le cache), et cache CDN si vous en utilisez un.

Revenir en arrière en cas de problème

Le changement de version PHP ne touche ni vos fichiers ni votre base de données. Si un problème apparaît, retournez dans MultiPHP Manager, cochez le domaine, sélectionnez l'ancienne version et cliquez sur Apply : le site retrouve son état précédent en quelques secondes. Gardez cependant une échéance en tête : revenir sur PHP 8.2 ne vous laisse que jusqu'au 31 décembre 2026 pour corriger le problème.

Questions fréquentes

Changer de version PHP peut-il effacer mon site ?

Non. MultiPHP Manager change seulement l'interpréteur utilisé pour exécuter vos fichiers. Le contenu, les fichiers et la base de données restent intacts, et le retour à l'ancienne version est immédiat.

Puis-je avoir une version différente par site ?

Oui. MultiPHP Manager fonctionne domaine par domaine : un blog WordPress peut tourner en PHP 8.5 et une boutique PrestaShop 9.0 en PHP 8.4 sur le même compte cPanel. Les domaines parqués (alias) suivent leur domaine principal.

Mon site affiche une erreur 500 après le changement, que faire ?

Revenez d'abord à l'ancienne version pour rétablir le site. Consultez ensuite l'outil Erreurs de cPanel ou le fichier error_log : la cause est presque toujours une extension PHP absente dans la nouvelle version ou un module incompatible. Corrigez sur la copie de test avant de retenter la bascule.

PHP 8.5 ou PHP 8.4 ?

Si votre site tourne sur WordPress à jour ou sur PrestaShop 9.1 et que toutes vos extensions le supportent, PHP 8.5 vous laisse le plus de marge (sécurité jusqu'à fin 2029). Pour PrestaShop 9.0, ou si une extension importante n'annonce pas encore sa compatibilité, choisissez PHP 8.4.