WordPress 7.0 : votre hébergement est-il prêt ?
WordPress 7.0 arrive : découvrez les prérequis à vérifier chez votre hébergeur avant la mise à jour de votre site, sans stress ni surcoût.
WordPress 7.0 : pourquoi vérifier son hébergement avant la mise à jour ?
Une nouvelle version majeure de WordPress est toujours une bonne occasion de faire le ménage sur son site. WordPress 7.0 ne dérogera pas à la règle : avant de cliquer sur le bouton de mise à jour, il est préférable de vérifier que l’hébergement, les extensions et les sauvegardes sont prêts.
Le but n’est pas de transformer cette étape en opération technique compliquée. Pour un blog, un site vitrine ou une petite boutique, l’essentiel consiste à contrôler quelques éléments concrets : la version de PHP disponible, l’état de la base de données, l’espace disque, la compatibilité des extensions et la qualité des sauvegardes.
Les prérequis précis d’une version de WordPress doivent toujours être confirmés dans les documentations et notes de version officielles de WordPress. Ils peuvent évoluer entre les versions. En revanche, les vérifications présentées ici restent utiles avant toute mise à jour majeure, y compris lorsque votre hébergeur affiche un bouton de mise à niveau en un clic.
Une mise à jour WordPress réussie commence rarement par WordPress lui-même : elle commence par un hébergement sain, une sauvegarde exploitable et un plan de retour arrière.
WordPress 7.0 : ce qui peut changer côté hébergement
WordPress est conçu pour fonctionner sur une grande variété d’hébergements mutualisés, de serveurs VPS et d’offres WordPress gérées. Mais une version majeure peut rendre plus visible un problème qui existait déjà : une version de PHP ancienne, une extension non maintenue, une base de données saturée ou un cache mal configuré.
En pratique, WordPress ne modifie pas votre formule d’hébergement. Il n’exige pas automatiquement de passer à une offre plus chère. En revanche, une mise à jour peut révéler que les ressources ou la configuration actuelles ne correspondent plus vraiment à votre site.
Voici quelques situations fréquentes :
- un hébergement propose plusieurs versions de PHP, mais le site utilise encore une version ancienne par défaut ;
- une extension indispensable n’a pas été testée avec les versions récentes de WordPress ou de PHP ;
- le dossier de sauvegarde occupe une grande partie de l’espace disque disponible ;
- un cache serveur, un CDN ou une extension de cache continue à servir d’anciens fichiers après la mise à jour ;
- les identifiants de connexion à l’hébergement, à la base de données ou au compte WordPress ne sont plus accessibles.
Les hébergeurs comme Infomaniak, o2switch, OVHcloud, LWS ou Hostinger donnent généralement accès aux réglages PHP, aux sauvegardes et aux bases de données depuis leur interface client. L’emplacement exact varie selon le panneau d’administration utilisé : cPanel, Plesk, hPanel ou une interface propriétaire.
Si vous débutez, ne cherchez pas à modifier tous les réglages. L’objectif est d’identifier ce qui est en place, de corriger les écarts évidents et de pouvoir revenir en arrière si nécessaire. Pour choisir ou réévaluer une offre, notre comparatif des critères d’un hébergeur pour petit site peut également vous aider.
Les 6 vérifications à faire avant toute mise à jour
1. Vérifier la version de PHP réellement utilisée
PHP est le langage exécuté par WordPress sur le serveur. C’est l’un des premiers points à contrôler. Une version de PHP trop ancienne pose des questions de compatibilité, de performances et surtout de sécurité, car elle peut ne plus recevoir de correctifs de sécurité.
Dans l’administration WordPress, allez dans Outils > Santé du site > Informations > Serveur. Vous y trouverez la version de PHP détectée. Vous pouvez aussi la consulter depuis le tableau de bord de votre hébergeur.
Ne changez pas de version de PHP à l’aveugle sur un site en production. Vérifiez d’abord que votre thème et vos extensions sont à jour. Si votre hébergeur propose un environnement de préproduction, testez le changement de PHP sur cette copie avant de le faire sur le site public.
Pour approfondir ce choix, consultez notre guide PHP 8.4 ou 8.5 : quelle version choisir chez son hébergeur ?. Retenez surtout qu’il vaut mieux utiliser une version encore maintenue, proposée par votre hébergeur et validée avec votre installation.
2. Contrôler l’état de la base de données
WordPress stocke les articles, pages, réglages, comptes utilisateurs et de nombreuses données d’extensions dans une base MySQL ou MariaDB. Une mise à jour du cœur peut lancer une mise à niveau de cette base lorsque cela est nécessaire.
Depuis Outils > Santé du site, WordPress peut signaler des recommandations liées au serveur. Dans le panneau de l’hébergeur, cherchez la rubrique Bases de données, MySQL, MariaDB ou phpMyAdmin. Notez la version affichée, sans la modifier si vous n’êtes pas certain de la procédure.
Une erreur de base de données n’est pas systématiquement causée par WordPress. Elle peut aussi venir d’un manque d’espace disque, d’identifiants erronés dans le fichier de configuration ou d’une table corrompue. Dans tous les cas, une exportation de la base avant la mise à jour est une précaution essentielle.
3. Vérifier l’espace disque disponible
Il faut de l’espace libre pour télécharger les fichiers de mise à jour, générer des sauvegardes, conserver les journaux techniques et permettre aux extensions de travailler correctement. Une offre qui annonce beaucoup d’espace disque n’est pas forcément le problème : ce qui compte est l’espace réellement utilisé par votre compte.
Regardez notamment la taille de ces éléments :
- le dossier wp-content/uploads, qui contient vos images et médias ;
- les sauvegardes stockées sur le même hébergement ;
- les archives créées par des extensions de migration ou de sauvegarde ;
- les fichiers de cache ;
- les anciens thèmes et extensions inutilisés.
Supprimer un thème inutilisé ou un fichier ZIP ancien peut être utile, mais ne supprimez jamais une sauvegarde sans avoir vérifié qu’une copie récente existe ailleurs. Pour les petits budgets, il est aussi utile de distinguer l’économie pertinente de la fausse économie : notre article 5 astuces pour réduire le coût d’hébergement détaille les leviers à privilégier.
4. Mettre à jour et trier les extensions
Les extensions sont souvent la principale source de problème après une mise à jour majeure. Une extension abandonnée peut utiliser des fonctions PHP obsolètes, modifier l’administration WordPress ou entrer en conflit avec une extension de sécurité, de cache ou de constructeur de pages.
Avant WordPress 7.0, ouvrez Extensions > Extensions installées et posez-vous trois questions simples :
- cette extension est-elle indispensable au site ?
- est-elle encore maintenue par son éditeur ?
- dispose-t-elle d’une mise à jour à appliquer avant celle de WordPress ?
Les extensions désactivées mais inutiles devraient être supprimées après sauvegarde. Elles ne sont pas nécessaires au fonctionnement du site et peuvent rester exposées à des vulnérabilités si elles ne sont plus mises à jour. Gardez uniquement les extensions nécessaires, connues et suivies.
La même logique s’applique au thème actif. Si vous utilisez un thème enfant, vérifiez que ses personnalisations restent compatibles avec le thème parent. Évitez de modifier directement les fichiers du thème juste avant une mise à jour : vous rendriez le diagnostic beaucoup plus difficile en cas de souci.
5. Identifier les couches de cache et le CDN
Le cache accélère l’affichage, mais il peut aussi donner l’impression qu’une mise à jour a échoué alors que le serveur utilise simplement une ancienne version d’une page, d’un fichier CSS ou d’un script JavaScript.
Un site peut cumuler plusieurs caches : une extension comme WP Super Cache, W3 Total Cache ou LiteSpeed Cache, un cache géré par l’hébergeur, et un CDN tel que Cloudflare. Avant la mise à jour, identifiez les outils actifs. Après celle-ci, videz les caches dans un ordre logique : extension WordPress, cache de l’hébergeur, puis CDN si vous en utilisez un.
Ne désactivez pas définitivement le cache pour autant. Il suffit de savoir comment le purger et de vérifier le site depuis une fenêtre de navigation privée. Si vous hésitez sur l’intérêt d’un CDN pour un petit projet, lisez notre analyse un CDN intégré est-il utile pour un petit site ?.
6. Tester l’accès aux comptes et aux outils de secours
Avant toute intervention, assurez-vous d’avoir accès à :
- l’administration WordPress avec un compte administrateur ;
- l’espace client de l’hébergeur ;
- la gestion des fichiers, via un gestionnaire web ou SFTP ;
- la gestion de la base de données ;
- l’adresse e-mail associée au compte hébergeur ;
- la procédure de restauration des sauvegardes.
Ce point semble élémentaire, pourtant un mot de passe oublié, une double authentification inaccessible ou une adresse e-mail obsolète peuvent compliquer une restauration urgente. Si votre hébergeur propose des passkeys ou une double authentification, activez-les après avoir vérifié vos méthodes de récupération. La sécurité du compte hébergeur protège directement votre site.
PHP, base de données et cache : les réglages à contrôler sans se perdre
Pour la plupart des débutants, les réglages techniques doivent rester simples. Il n’est pas nécessaire de modifier la mémoire PHP, les limites d’exécution ou les paramètres de base de données si le site fonctionne correctement et si aucun message ne les signale. Commencez par observer.
Dans Outils > Santé du site, WordPress sépare les éléments critiques des recommandations. Prenez le temps de lire les messages : ils peuvent signaler une version de PHP à mettre à niveau, une extension inactive ou un problème lié aux tâches planifiées.
Les journaux d’erreurs disponibles chez l’hébergeur peuvent également être utiles après un test. Un message contenant le nom d’une extension ou d’un thème donne souvent une piste concrète. En revanche, évitez de copier des identifiants, des chemins complets de serveur ou des clés secrètes dans une demande d’assistance publique.
Si votre offre inclut un cache applicatif ou serveur, documentez sa procédure de purge. Certains hébergeurs proposent cette action depuis leur interface, d’autres la connectent à une extension WordPress. Avec LiteSpeed Cache, par exemple, l’action de purge est accessible depuis l’administration WordPress lorsque l’environnement est compatible.
Enfin, gardez à l’esprit que des performances insuffisantes ne justifient pas toujours un changement immédiat d’hébergement. Un nettoyage des extensions, des images optimisées et un cache correctement configuré peuvent suffire. À l’inverse, un site WooCommerce actif, très fréquenté ou utilisant de nombreuses tâches en arrière-plan peut nécessiter une offre plus adaptée qu’un hébergement mutualisé d’entrée de gamme.
Sauvegarder correctement : la condition d’une mise à jour sereine
Une sauvegarde utile n’est pas seulement un fichier présent dans un dossier. Elle doit être récente, complète, accessible et restaurable. Pour WordPress, une sauvegarde complète comprend au minimum les fichiers du site et la base de données.
Les fichiers comprennent notamment WordPress, le thème, les extensions et les médias envoyés dans wp-content/uploads. La base de données contient le contenu et les réglages. Sauvegarder seulement l’un des deux ne garantit pas un retour à l’état exact du site.
Avant la mise à jour, vérifiez les points suivants :
- la date et l’heure de la dernière sauvegarde ;
- la présence des fichiers et de la base de données ;
- le lieu de stockage ;
- la durée de conservation proposée par l’hébergeur ;
- la méthode de restauration et son éventuel coût.
Une sauvegarde conservée uniquement sur le même compte d’hébergement reste préférable à aucune sauvegarde, mais elle n’est pas idéale. Une copie sur un emplacement distinct renforce votre protection. Certains propriétaires de sites utilisent un stockage cloud ou une sauvegarde fournie par une extension, mais il faut alors vérifier que la restauration est possible et que l’espace de destination est suffisant.
Les sauvegardes immuables peuvent apporter une protection supplémentaire contre certaines suppressions ou modifications malveillantes, mais elles ne remplacent pas une procédure de restauration testée. Notre guide sur les sauvegardes immuables en hébergement explique leur rôle et leurs limites.
Tester WordPress 7.0 sur une copie du site
La méthode la plus rassurante consiste à mettre à jour une copie du site avant le site public. Selon votre hébergeur, cette copie peut s’appeler environnement de préproduction, staging, site de test ou clone.
Les hébergements WordPress gérés incluent souvent un outil de staging. Sur un hébergement mutualisé classique, vous pouvez créer un sous-domaine de test, par exemple test.votredomaine.fr, puis y installer une copie avec un outil de clonage fourni par l’hébergeur ou une extension adaptée. Cette opération demande davantage de rigueur, car il faut éviter que le site de test envoie des e-mails aux vrais clients ou soit indexé par les moteurs de recherche.
Sur la copie, reproduisez les actions importantes :
- ouvrir les pages principales depuis un navigateur privé ;
- envoyer un formulaire de contact de test ;
- vous connecter et vous déconnecter de l’administration ;
- rechercher un article ;
- tester le panier, le paiement ou les e-mails transactionnels pour une boutique, avec les précautions nécessaires ;
- vérifier l’affichage sur mobile ;
- purger le cache et contrôler l’absence d’erreurs visibles.
Notez les anomalies constatées. Si une fonction ne marche plus sur la copie, ne mettez pas encore à jour le site public. Vérifiez l’extension concernée, son journal des modifications et ses canaux de support. Une mise à jour de l’extension, du thème ou de PHP peut résoudre le problème ; parfois, il faut attendre un correctif de l’éditeur.
Mettre à jour sans risque : un ordre de travail simple
Lorsque le test est satisfaisant, choisissez un moment calme. Évitez une période de campagne publicitaire, de lancement commercial ou de forte activité. Pour une boutique, évitez aussi les heures où les commandes sont les plus nombreuses.
Un déroulé prudent ressemble à ceci :
- effectuer une dernière sauvegarde complète juste avant l’intervention ;
- noter les versions actuelles de WordPress, PHP, du thème et des principales extensions ;
- mettre à jour les extensions et le thème si leurs éditeurs le recommandent ;
- appliquer la mise à jour de WordPress ;
- vider les caches ;
- contrôler immédiatement les pages et parcours essentiels ;
- surveiller les messages d’erreur et les formulaires dans les heures qui suivent.
Ne lancez pas plusieurs opérations non liées au même moment. Changer de version de PHP, remplacer le thème, installer une nouvelle extension de sécurité et passer à WordPress 7.0 dans la même heure rendrait tout diagnostic difficile. Une modification à la fois est plus lente, mais beaucoup plus sûre.
Prévoir le retour arrière avant qu’il ne soit nécessaire
Un retour arrière ne signifie pas forcément que WordPress 7.0 est défaillant. Il peut être nécessaire à cause d’une extension précise, d’un thème sur mesure ou d’un réglage propre au site. Le plus important est de revenir rapidement à un état fonctionnel, puis d’analyser le problème à tête reposée.
Si une erreur grave apparaît après la mise à jour, commencez par relever le message affiché et l’heure du problème. Si vous identifiez clairement une extension responsable, désactivez-la depuis l’administration. Si l’accès à WordPress est impossible, l’outil de gestion de fichiers de l’hébergeur ou une connexion SFTP peut permettre de renommer temporairement son dossier dans wp-content/plugins.
Si le site reste inaccessible ou si le problème touche la base de données, restaurez la sauvegarde complète réalisée juste avant la mise à jour. Ne restaurez pas une sauvegarde ancienne sans nécessité : vous risqueriez de perdre des contenus, commentaires, commandes ou formulaires reçus depuis sa création.
Après restauration, vérifiez que le site fonctionne, puis recherchez l’origine du conflit sur votre environnement de test. Vous pouvez aussi transmettre à l’assistance de l’hébergeur des informations précises : heure du souci, URL concernée, message d’erreur et actions déjà tentées. Cela accélère généralement le diagnostic.
Conclusion : un hébergement prêt, c’est surtout une méthode prête
Préparer WordPress 7.0 ne demande pas forcément de changer d’hébergeur ni d’acheter une option supplémentaire. Dans la majorité des cas, une version de PHP adaptée, une base de données saine, des extensions maintenues, un cache maîtrisé et une sauvegarde vérifiée suffisent à aborder la mise à jour avec confiance.
Avant de mettre votre site à jour, prenez donc quelques minutes pour suivre ces six vérifications et, si possible, tester sur une copie. Cette préparation vous évitera bien des interruptions inutiles et vous aidera à profiter sereinement des évolutions de WordPress.