# WordPress 7.0 et les hébergeurs mutualisés : lesquels ne suivront pas

> La hausse des prérequis serveur de la version majeure met certains hébergeurs d'entrée de gamme hors jeu. Comment le vérifier avant que les clients ne soient bloqués.

- Auteur : Clément Hadrot
- Publié le : 2026-04-14
- Mis à jour le : 2026-04-14
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/wordpress-70-hebergeurs-mutualises-qui-suivront-pas/

## L’essentiel

- Certains mutualisés d'entrée de gamme restent bloqués sur une version PHP insuffisante
- Vérifier les prérequis ne suffit pas, il faut tester en conditions réelles
- Anticiper le changement d'hébergeur avant que le client ne soit bloqué en pleine mise à jour

WordPress 7.0 a relevé la barre des prérequis serveur, et cette hausse, déjà annoncée bien en amont sur ce blog, produit maintenant ses effets concrets sur le terrain : certains hébergeurs mutualisés d'entrée de gamme, ceux dont le modèle économique repose sur des infrastructures figées depuis plusieurs années, ne suivent tout simplement pas. Sur un échantillon de quatre offres mutualisées testées ce trimestre, une seule s'est révélée incapable de proposer une version PHP suffisante par défaut.

Le problème ne se limite pas à un simple message d'avertissement affiché dans le tableau de bord : sur les hébergements les plus contraints, une mise à jour vers WordPress 7.0 peut tout simplement échouer silencieusement, ou pire, provoquer un site cassé si l'administrateur force la mise à jour malgré l'avertissement. Nous ne revenons pas ici sur le détail des exigences serveur de WordPress 7.0, déjà couvertes précédemment.

## Comment vérifier concrètement, au-delà de la fiche produit

La fiche commerciale d'un hébergeur mutualisé annonce presque toujours « PHP à jour » sans jamais préciser la version par défaut réellement activée sur un compte standard, ni la facilité à en changer. La seule méthode fiable consiste à ouvrir un compte de test, ou à interroger directement le support technique, pour connaître la version PHP effectivement disponible sans surcoût.

- Version PHP activée par défaut sur un compte standard, pas sur l'offre la plus chère
- Possibilité de changer de version PHP soi-même, sans ticket support obligatoire
- Version de MariaDB ou MySQL disponible, souvent oubliée dans la communication
- Délai de montée de version historique de l'hébergeur sur les versions PHP précédentes

## Ce que révèle le test sur quatre offres mutualisées

| Hébergeur testé | PHP par défaut | Changement possible sans support |
| --- | --- | --- |
| Offre A | Version récente compatible | Oui, en un clic |
| Offre B | Version récente compatible | Oui, en un clic |
| Offre C | Version compatible sur demande | Via ticket support uniquement |
| Offre D | Version insuffisante, non modifiable | Non, changement d'offre requis |

> L'essentiel à retenir : Certains mutualisés d'entrée de gamme restent bloqués sur une version PHP insuffisante ; Vérifier les prérequis ne suffit pas, il faut tester en conditions réelles ; Anticiper le changement d'hébergeur avant que le client ne soit bloqué en pleine mise à jour

## Le signal d'alerte le plus fiable : l'historique, pas la promesse

Le critère le plus prédictif n'est pas la version actuellement proposée, mais la vitesse à laquelle l'hébergeur a historiquement suivi les montées de version précédentes. Un hébergeur qui a mis plus d'un an à proposer PHP 8.3 par défaut après sa sortie ne suivra probablement pas plus vite pour les prérequis de WordPress 7.0, quelles que soient ses annonces commerciales du moment.

## Checklist à appliquer avant chaque migration de client

1. Vérifier la version PHP réellement active sur le compte du client, pas la documentation générique
2. Tester la mise à jour sur un environnement de staging avant toute bascule en production
3. Confirmer la disponibilité de la version de base de données requise par le nouveau cœur WordPress
4. Anticiper un changement d'hébergeur si l'offre actuelle ne peut techniquement pas suivre
5. Documenter la décision, en particulier si le client refuse de changer d'hébergeur malgré l'alerte

> Un client qui refuse de changer d'hébergeur malgré une incompatibilité technique avérée doit signer une décharge explicite avant toute tentative de mise à jour forcée : cela évite bien des malentendus quand le site casse ensuite.

## Ce qui distingue les hébergeurs qui suivront

Les hébergeurs mutualisés qui ont anticipé la hausse des prérequis partagent un point commun : une infrastructure PHP-FPM modulaire, permettant à chaque client de choisir sa version indépendamment des autres comptes hébergés sur la même machine. Ceux qui restent figés sur une version unique pour l'ensemble de leur parc, souvent pour des raisons de coût de maintenance interne, sont structurellement les moins agiles face à ce type de changement.

## Notre recommandation

Face à un client encore sur un mutualisé bas de gamme, le diagnostic doit être posé avant que la mise à jour vers WordPress 7.0 ne devienne disponible dans son tableau de bord, pas après un blocage constaté. Sur les parcs que nous suivons, cette vérification systématique a permis d'anticiper, plusieurs mois à l'avance, les quelques clients pour lesquels un changement d'hébergeur serait inévitable.