Un vieux site passera-t-il sur PHP 7, puis sur PHP 8 ?

Tester la compatibilité des sites avec PHP 7 consiste à passer le code PHP au crible d'un outil de compatibility check, puis à faire tourner une copie du site web sur la nouvelle version de PHP en lisant chaque error du journal. En 2026, PHP 7 est outdated : la version à viser est une branche 8 maintenue, pour un code maison comme pour un site WordPress et ses plugins.

Pourquoi viser PHP 8 alors que la question parle de PHP 7

Un site encore sur PHP 5 ou PHP 7 tourne sur une version que plus personne ne corrige, sur un serveur web exposé à tout le réseau. D'après le calendrier publié sur php.net, la branche 7.4, dernière de la série 7, a cessé de recevoir des correctifs de sécurité le 28 novembre 2022, et PHP 8.0 l'a suivie le 26 novembre 2023. Toute faille découverte depuis reste ouverte sur ces versions, quel que soit le soin apporté au code du site.

Au 15 octobre 2026, la page des versions prises en charge de php.net liste quatre branches : 8.2, 8.3, 8.4 et 8.5. La 8.2 ne reçoit plus que des correctifs de sécurité, jusqu'au 31 décembre 2026. Viser 8.3 ou 8.4 évite donc de refaire la migration dans quelques mois. La démarche de test reste la même que lors du passage historique de PHP 5 à PHP 7 ; seule la valeur de la version visée change dans les commandes.

Ces dates proviennent des pages « Supported Versions » et « Unsupported Branches » de php.net, relues au moment de cette mise à jour.

Les ruptures qui font tomber un code PHP ancien

Un code PHP écrit pour PHP 5 casse presque toujours sur les mêmes points, que le guide de migration du manuel officiel recense version par version. Le premier saut, celui de PHP 7.0, a supprimé l'ancienne extension mysql (les fonctions mysql_connect(), mysql_query()), remplacée par mysqli ou PDO, ainsi que les fonctions ereg. Un site dynamique bâti avant 2015 contient souvent encore ces appels, parfois dans un fichier PHP inclus que plus personne n'ouvre.

Le passage à PHP 8 ajoute une seconde série de ruptures :

• des fonctions supprimées, comme create_function(), each(), money_format() ou get_magic_quotes_gpc() ;
• la comparaison entre un nombre et une chaîne non numérique : 0 == "foo" valait vrai sous PHP 7 et vaut faux sous PHP 8 ;
• l'accès à un caractère par accolades, $chaine{0}, qu'il faut écrire $chaine[0] ;
• les constructeurs qui portent le nom de leur classe, ignorés au profit de __construct() ;
• des avertissements devenus des erreurs fatales, par exemple count() appliqué à une valeur qui n'est ni un tableau ni un objet dénombrable.

Sur la page, ces ruptures se lisent sous la forme d'une erreur fatale du type Fatal error: Uncaught Error: Call to undefined function create_function(), avec le nom du fichier et le numéro de ligne. Quand l'affichage des erreurs est coupé, le visiteur ne voit qu'une page blanche ou une erreur 500 : la piste se trouve alors dans le journal, comme l'explique la page sur l'origine d'une erreur 500 PHP.

Analyser le code avec PHPCompatibility sans l'exécuter

PHPCompatibility est un jeu de règles pour PHP_CodeSniffer (phpcs) qui parcourt le code source sans l'exécuter et signale chaque appel incompatible avec la plage de versions demandée. Le projet open source se trouve sur GitHub sous le nom phpcompatibility/php-compatibility, et s'installe avec Composer dans le dossier du projet :

composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs -p --standard=PHPCompatibility --runtime-set testVersion 8.3- --extensions=php ./

Le paramètre testVersion fixe la version visée : 8.3- signifie « 8.3 et toutes les suivantes », 7.0- reproduit le test historique de compatibilité avec PHP 7. Le rapport indique, pour chaque fichier, la ligne, la nature du problème (fonction supprimée, extension retirée, syntaxe dépréciée) et s'il s'agit d'une erreur bloquante ou d'un simple avertissement.

Le standard PHPCompatibility se combine avec un autre standard dans le même passage : PHPCompatibilityWP, une variante publiée par le même project pour WordPress, écarte les faux positifs dus aux fonctions que le cœur de WordPress recrée lui-même. Côté outil web, plusieurs services en ligne proposent un check de compatibilité à partir d'une URL ; ils ne voient que le HTML servi par la page home, jamais le code PHP, et ne remplacent donc pas l'analyse des fichiers.

Une limite mérite d'être connue : la version stable 9.3.5 de PHPCompatibility date de 2019 et ne détecte pas toutes les ruptures de PHP 8. La branche de développement 10 en couvre davantage ; la documentation du projet sur GitHub explique comment l'installer. Un contrôle de syntaxe avec le binaire de la version visée complète ce premier passage, le nom du binaire variant selon le système :

find . -name "*.php" -exec php8.3 -l {} \; | grep -v "No syntax errors"

Et sans accès en ligne de commande ?

Un hébergement mutualisé sans accès SSH n'empêche pas l'analyse : il suffit de télécharger le site par FTP sur un poste où PHP et Composer sont installés, puis de lancer phpcs en local. Pour un site WordPress, l'extension PHP Compatibility Checker, publiée par WP Engine et bâtie sur les mêmes règles, a longtemps rempli ce rôle depuis le tableau de bord ; avant de l'installer, vérifier sur le répertoire wordpress.org qu'elle reste maintenue et compatible avec la version de WordPress du site.

Monter une copie du site sur la nouvelle version de PHP

Une copie du site sur un sous-domaine de test permet d'essayer la nouvelle version de PHP sans toucher au site public. Copier les fichiers et exporter la base MySQL vers une seconde base, puis attribuer la version visée à ce seul sous-domaine depuis le panneau d'administration de l'hébergement. La plupart des offres règlent la version de PHP dossier par dossier ou sous-domaine par sous-domaine, ce qui laisse le site en ligne intact pendant l'essai.

Un développeur web peut aussi monter la copie en local, sur son poste, avec Docker : les images officielles php existent pour chaque branche avec un serveur web Apache intégré (par exemple php:8.3-apache), et un fichier Compose qui déclare un service PHP et un service MySQL reproduit l'application web complète. Changer de version de PHP revient alors à changer une ligne, ce qui permet de tester la même application sur 8.3 puis 8.4 dans la même journée, sans dépendre du panneau de l'hébergeur.

Sur la copie, la journalisation complète s'active sans afficher les messages aux visiteurs, par exemple avec un fichier .user.ini à la racine :

; .user.ini de la copie de test
error_reporting = E_ALL
display_errors = Off
log_errors = On
error_log = /chemin/vers/php-erreurs.log

Parcourir ensuite les pages qui comptent : accueil, recherche, formulaire de contact, espace membre, fiche product et panier d'une boutique WooCommerce, tunnel de commande, interface d'administration. Chaque ligne du journal donne le fichier et la ligne en cause. Les messages Deprecated ne cassent rien aujourd'hui mais annoncent les ruptures de la version suivante : les corriger tout de suite prépare la prochaine montée. Un projet doté de tests automatisés (PHPUnit, par exemple) les relance sur la copie, ce testing couvre alors les cas que la navigation manuelle oublie.

Le cas d'un site WordPress

Sur un site WordPress, le cœur suit les versions de PHP de près, et les erreurs viennent presque toujours d'un thème ou d'une extension. La page des prérequis de wordpress.org recommande une version de PHP maintenue, et l'outil Santé du site, dans le menu Outils du tableau de bord, signale une version de PHP outdated. Avant tout test, mettre à jour le cœur, puis chaque extension et le thème, sur la copie d'abord.

Il faut ensuite comparer, pour chaque plugin, la mention « Version PHP minimale » de sa fiche sur le répertoire avec la version visée. Une extension abandonnée depuis plusieurs années, ou un thème acheté une fois et jamais mis à jour, se remplace plutôt qu'il ne se corrige. La version de MySQL ou de MariaDB attendue par WordPress compte aussi : l'extension mysql requise par les très anciennes installations n'existe plus depuis PHP 7.0, et le cœur passe par mysqli depuis longtemps. Une fois la copie stable, un site WordPress devenu lent après la montée relève des réglages listés dans les causes d'un WordPress pas assez rapide.

Chercher une erreur PHP sur Stack Overflow et GitHub

Les réponses les plus précises sur la compatibilité PHP sont en anglais, sur Stack Overflow et dans les tickets GitHub des projets concernés. Une recherche formulée en english trouve plus vite : « how to check PHP 8 compatibility », « upgrade custom plugin to PHP 8 », ou le message d'erreur copié tel quel, entre guillemets, sans le chemin du fichier qui est propre au serveur web.

Sur Stack Overflow, l'answer acceptée n'est pas toujours la plus récente : une réponse de 2016 sur la migration vers PHP 7 peut proposer un correctif qui ne passe plus sous PHP 8. Lire la date, les commentaires et les réponses suivantes avant de copier du code. Sur GitHub, l'onglet Issues d'un project (thème, plugin, bibliothèque) dit souvent si l'incompatibilité est connue, si une update la corrige déjà, ou si le support du project a cessé : dans ce dernier cas, aucune correction ne viendra et il faut remplacer l'outil. Pour un thème ou un plugin custom, développé à la demande par une agence web, le client reste le seul à pouvoir demander la mise à jour du file source à son prestataire.

Corriger le code incompatible

Chaque ligne signalée par PHPCompatibility ou par le journal se corrige en remplaçant l'appel retiré par son équivalent moderne. Quelques correspondances reviennent sans cesse :

mysql_*

réécrire les accès à la base avec mysqli ou PDO, en profitant du changement pour passer aux requêtes préparées ;

create_function()

remplacer par une fonction anonyme, function ($x) { … }, ou une fonction fléchée ;

each()

réécrire la boucle avec foreach ;

ereg() et split()

passer à preg_match() et preg_split(), en ajoutant les délimiteurs du motif.

Sur un gros code, l'outil open source Rector automatise une partie de ces réécritures à partir de règles par version de PHP. Il produit un diff à relire avant de l'appliquer, et ne dispense pas de repasser la copie au journal d'erreurs.

Une fois le code compatible, la nouvelle version apporte aussi des fonctions utiles au développement web : arguments nommés, opérateur nullsafe ?-> et expression match depuis PHP 8.0, énumérations et propriétés en lecture seule depuis PHP 8.1. Rien n'oblige à les adopter pendant la migration ; les garder pour une seconde étape limite le risque de casser une application web qui vient tout juste de passer les tests.

Basculer le site public, et revenir en arrière si besoin

La bascule du site public sur la nouvelle version de PHP se fait une fois la copie propre, après une sauvegarde complète des fichiers et de la base. Sur un site à fort trafic, un mode maintenance (page d'accueil temporaire, ou extension dédiée sous WordPress) évite qu'un visiteur tombe sur une page cassée pendant les quelques minutes de l'opération. Depuis le panneau d'hébergement, changer la version du site principal, vider les caches (OPcache, extension de cache, CDN), puis reparcourir les pages testées sur la copie. Si une erreur surgit malgré tout, rétablir l'ancienne version depuis le panneau ne prend qu'un instant, le temps de corriger le code sur la copie.

Une nouvelle version modifie parfois la consommation de mémoire d'un script : le message correspondant est détaillé dans l'erreur Allowed memory size of 268435456 bytes exhausted. Garder le journal d'erreurs actif quelques jours après la bascule permet de repérer les pages rarement visitées que le test a manquées.

Compatibilité PHP : trois cas qui bloquent la migration

Comment savoir quelle version de PHP tourne sur le site ?

Le panneau de l'hébergement affiche la version de PHP de chaque domaine. À défaut, un fichier temporaire contenant <?php echo PHP_VERSION;, appelé une fois dans le navigateur puis supprimé, donne la réponse ; sous WordPress, l'écran Santé du site l'indique aussi.

Un code chiffré avec ionCube ou SourceGuardian peut-il passer sur PHP 8 ?

Un fichier encodé dépend d'un chargeur propre à chaque version de PHP. Il passe seulement si l'éditeur fournit une version encodée pour la branche visée et si l'hébergeur installe le chargeur correspondant ; sinon, il faut contacter l'éditeur du logiciel ou le remplacer.

Que faire d'un site que personne ne sait plus maintenir ?

Un site sans développeur ni documentation se teste quand même par l'analyse statique, qui chiffre l'ampleur du travail en nombre de lignes signalées. Au-delà de quelques centaines d'erreurs, la reconstruction sur un CMS à jour revient souvent moins cher que la correction ligne par ligne. Les autres réglages du serveur sont rassemblés dans la rubrique PHP et serveurs.

Sources : php.net, pages des versions prises en charge et des branches en fin de vie, guides de migration vers PHP 7.0 et PHP 8.0 ; documentation du projet PHPCompatibility sur GitHub ; page des prérequis de wordpress.org.