« Votre version PHP sera bientôt retirée » : beaucoup de propriétaires de sites et d’applications reçoivent ce message de leur hébergeur. Derrière, une vraie inquiétude : que tout casse le jour du changement. C’est un risque réel pour du code ancien, mais une mise à jour PHP 8 se maîtrise. Voici la méthode que j’utilise, notamment sur des applications CakePHP passées en PHP 8.4.

Le calendrier des versions PHP en 2026

Version Correctifs de sécurité jusqu’au Statut
PHP 7.4 et antérieures novembre 2022 abandonnée
PHP 8.1 31 décembre 2025 abandonnée
PHP 8.2 31 décembre 2026 sécurité uniquement, fin imminente
PHP 8.3 31 décembre 2027 sécurité uniquement
PHP 8.4 31 décembre 2028 supportée
PHP 8.5 31 décembre 2029 supportée

Source : php.net. En pratique, viser PHP 8.3 ou 8.4 aujourd’hui donne deux à trois ans de tranquillité, avec un écosystème de bibliothèques mature. Le calendrier détaillé, avec les dernières versions publiées, est dans la page versions de PHP supportées.

Ce qui casse vraiment en passant à PHP 8

La plupart des incidents viennent d’une poignée de changements :

  • Fonctions supprimées : each(), create_function(), les accolades pour accéder à un caractère ($chaine{0}), et bien sûr mysql_* (déjà supprimées en PHP 7).
  • Comparaisons chaîne/nombre : en PHP 8, 0 == "abc" vaut false. Du code qui reposait sur l’ancien comportement change silencieusement de logique.
  • Erreurs plus strictes : beaucoup d’avertissements sont devenus des exceptions (TypeError, ValueError), qui arrêtent le script au lieu de le laisser continuer.
  • Dépréciations en 8.1 à 8.4 : passer null à une fonction native qui attend une chaîne, propriétés dynamiques sur les objets, paramètres implicitement nullables. Ce ne sont que des avertissements, mais ils remplissent les journaux et annoncent les ruptures de PHP 9.
  • Dépendances : un framework (CakePHP 2/3, Laravel ancien, Zend) ou une bibliothèque abandonnée peut tout simplement ne pas fonctionner en PHP 8.

La méthode, étape par étape

1. Inventaire

Version PHP actuelle, framework et version, dépendances Composer (ou bibliothèques copiées à la main), extensions PHP utilisées, tâches planifiées, scripts annexes. On oublie souvent ces derniers, et ce sont eux qui cassent la nuit suivant la bascule.

2. Analyse automatique

  • PHPCompatibility (règles pour PHP_CodeSniffer) détecte les fonctions supprimées et la syntaxe incompatible avec la version cible.
  • PHPStan trouve les erreurs de types et les appels incohérents.
  • Rector applique automatiquement une grande partie des corrections, de façon reproductible.

3. Mise à jour des dépendances

C’est souvent le plus gros du travail : monter le framework de version (avec ses propres changements), remplacer les paquets abandonnés. Sur une application CakePHP ancienne, cela peut représenter l’essentiel du chantier.

4. Tests sur une copie

Copie du site sur un serveur avec la version PHP cible, journaux d’erreurs activés avec E_ALL, et passage sur tous les parcours métier : connexion, formulaires, paiement, exports, emails, tâches cron. S’il existe des tests automatisés, c’est le moment de les faire tourner ; sinon, une liste de contrôle écrite.

5. Bascule et surveillance

Changement de version en production à un moment calme, surveillance des journaux pendant plusieurs jours, et possibilité de revenir à l’ancienne version PHP immédiatement si un parcours oublié pose problème.

Et pour WordPress, Joomla ou PrestaShop ?

Le principe est le même, avec un avantage : le cœur du CMS est déjà compatible si vous êtes à jour. Le risque se concentre sur les extensions, le thème et le code sur mesure. Mettez tout à jour d’abord, testez sur une copie, puis changez la version PHP. Pour Joomla 3, ce n’est pas possible proprement : voir Joomla 3 en fin de support.

Le bénéfice au-delà de la sécurité

PHP 8 est sensiblement plus rapide que PHP 7, consomme moins de mémoire et apporte un code plus sûr (types, énumérations, propriétés en lecture seule). Une mise à niveau bien faite est aussi l’occasion de nettoyer du code mort et de documenter l’application.

Questions fréquentes

Puis-je passer directement de PHP 5.6 ou 7.0 à PHP 8.4 ?

Oui côté serveur, mais le code doit être corrigé pour toutes les versions intermédiaires d’un coup. C’est faisable avec les bons outils ; l’audit dira si une réécriture partielle est plus raisonnable.

Mon hébergeur propose de garder PHP 7 en payant un « support étendu », est-ce une solution ?

Cela achète du temps, pas une solution. C’est utile si la mise à niveau est planifiée dans les mois qui suivent.