# Des erreurs PHP sont apparues après un changement de version

> Changer la version de PHP est le geste qui améliore le plus vite les temps de réponse d’un site, et c’est aussi le plus brutal. Le langage a supprimé au fil des versions des comportements tolérés depuis longtemps : ce qui produisait un avertissement discret devient une erreur qui arrête la page. Le message affiché contient toujours la réponse.

- Source canonique : [https://allaux.fr/problemes/erreurs-php-apres-changement-de-version](https://allaux.fr/problemes/erreurs-php-apres-changement-de-version)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Notez le fichier et la ligne indiqués dans le message avant toute chose, puis remettez la version PHP précédente depuis le sélecteur du panneau d’hébergement : le site rouvre et vous corrigez à froid. Vérifiez ensuite la compatibilité réelle : PrestaShop 1.6 ne dépasse pas PHP 7.1 et la branche 1.7.8 s’arrête à PHP 7.4. Sur WordPress, une extension abandonnée est presque toujours la fautive.

## Lire le message plutôt que le craindre

Un message d’erreur PHP contient quatre informations : la nature du problème, le fichier, la ligne, et la suite d’appels qui y a mené. Le fichier suffit presque toujours à désigner le responsable. S’il se trouve dans le répertoire d’un module ou d’un thème, c’est ce composant qu’il faut mettre à jour ou remplacer — pas le cœur du CMS, et pas la version de PHP.

Les familles de messages sont peu nombreuses. Une fonction supprimée du langage produit une erreur d’appel à une fonction inexistante. Un type de donnée devenu strict produit une erreur sur un argument. Un accès à une valeur absente d’un tableau, longtemps toléré, remonte désormais bien plus fort. Ces trois cas couvrent la grande majorité des ruptures que je rencontre.

## Cadrer avant de corriger

1. **Vérifier la version réellement active** — Beaucoup d’hébergements permettent une version différente pour le site web et pour les commandes en ligne. Une tâche planifiée peut donc échouer alors que le site fonctionne, ou l’inverse.
2. **Compter les composants concernés** — Si un seul module apparaît dans les messages, la correction est bornée. Si le thème et cinq modules apparaissent, la question devient celle de leur remplacement, pas de leur réparation.
3. **Vérifier la compatibilité annoncée du CMS** — Chaque version de PrestaShop ou de WordPress annonce les versions de PHP qu’elle supporte. Utiliser une version plus récente que celle prévue produit des erreurs même sans aucun module tiers.
4. **Regarder les modifications faites dans le cœur** — Un site dont le cœur a été modifié directement ne bénéficie plus des correctifs de compatibilité publiés en amont. C’est souvent là que se concentrent les erreurs.
5. **Tester sur une copie** — La version de PHP se change en quelques secondes dans le panneau d’hébergement, mais l’essai se fait sur une copie du site, jamais en production un jour de forte activité.

## Rester sur une version obsolète n’est pas une option durable

> Une version de PHP en fin de vie ne reçoit plus de correctifs de sécurité, et les hébergeurs finissent par la retirer avec un préavis court. Repousser la montée de version ne fait que transformer une opération planifiée en urgence subie.

## Corriger, remplacer, ou revenir

Corriger quand le code fautif vous appartient : surcharge, module sur mesure, thème adapté. C’est le cas le plus simple et le plus durable.

Mettre à jour quand le composant est maintenu : la version récente est presque toujours compatible, et le problème disparaît sans écrire une ligne.

Remplacer quand le composant est abandonné : maintenir soi-même un module qui n’est plus suivi coûte plus cher qu’il n’y paraît.

Revenir à la version précédente reste possible et immédiat, mais ce n’est qu’un délai supplémentaire, pas une solution.

## Continuer sur la bonne page

- **Passer à PHP 8 sur PrestaShop** — Les points de rupture connus et la marche à suivre côté PrestaShop. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))
- **PHP et WordPress** — La montée de version côté WordPress, extensions comprises. ([/wordpress-woocommerce/mise-a-jour/php-wordpress](/wordpress-woocommerce/mise-a-jour/php-wordpress))
- **Versions de PHP en fin de vie** — Pourquoi rester sur une version ancienne devient un problème de sécurité. ([/securite/versions-de-php-en-fin-de-vie](/securite/versions-de-php-en-fin-de-vie))
- **Activer le mode debug** — Pour faire apparaître le message complet plutôt qu’une page blanche. ([/guides/activer-mode-debug-prestashop](/guides/activer-mode-debug-prestashop))

## FAQ

### Mon hébergeur a changé la version sans me prévenir, est-ce possible ?

Il prévient en général par courriel plusieurs semaines à l’avance, à l’adresse enregistrée sur le compte. Quand cette adresse n’est plus relevée, le changement paraît soudain alors qu’il était annoncé.

### Puis-je revenir à l’ancienne version le temps de corriger ?

Oui, chez la plupart des hébergeurs, en quelques secondes. C’est une bonne mesure d’urgence, à condition de fixer une date pour la correction réelle.

### Une version plus récente rend-elle vraiment le site plus rapide ?

Les versions récentes exécutent le même code sensiblement plus vite, et cet écart se voit sur les pages lourdes. Je ne donne pas de pourcentage : cela dépend entièrement du site et de sa base.

### Faut-il toujours prendre la version la plus récente disponible ?

Non. La bonne version est la plus récente que votre CMS et vos modules déclarent supporter. Aller au-delà crée exactement le problème qu’on cherche à éviter.

### Les erreurs n’apparaissent que sur certaines pages, est-ce normal ?

Oui, et c’est plutôt bon signe : seul le code réellement exécuté produit une erreur. Un module chargé sur une seule page ne casse que celle-là.