Choisir un hébergement WordPress : les critères qui décident vraiment
Un site WordPress tient moins à son thème qu'à la plateforme qui le porte : version de PHP, mémoire allouée, accès à la base, sauvegardes réellement restaurables. Ce site décrit ce qu'il faut vérifier avant de souscrire, ce que la plupart des offres ne disent pas, et comment changer d'hébergeur sans perdre le site.
Les ressources que WordPress consomme réellement
WordPress est une application PHP qui interroge une base MySQL ou MariaDB. La version de PHP compte plus que le nombre de sites autorisés : une version ancienne ralentit tout et n'est plus maintenue, ce qui en fait une faille. Vérifier la version proposée, et la possibilité d'en changer depuis le panneau, est le premier contrôle.
La mémoire allouée à PHP (memory_limit) décide de ce qui passe ou casse : import d'un thème lourd, génération d'images, sauvegarde via une extension. Un hébergement mutualisé bridé à 64 Mo suffit pour un blog simple et bloque net sur un site de catalogue.
Les limites d'entrées (max_input_vars) et le nombre de processus simultanés déterminent aussi le comportement sous charge : un site qui fonctionne en test peut renvoyer des erreurs 500 dès deux visiteurs simultanés si le quota de processus est atteint.
Accès : SSH, SFTP, base de données
Un accès SSH, même restreint, change la pratique : déploiement par git, export de base, recherche dans les journaux, correction d'un site bloqué sans passer par une interface graphique. Sans SSH, tout passe par FTP ou par un gestionnaire de fichiers, ce qui rend certaines réparations impossibles.
L'accès à la base (phpMyAdmin ou client direct) doit être disponible sans surcoût ni ouverture de ticket. Un site WordPress se sauvegarde en deux parties — les fichiers et la base — et une offre qui ne donne pas accès à la base rend la restauration dépendante du bon vouloir de l'hébergeur.
Vérifier aussi la politique de courriel sortant : beaucoup d'hébergements mutualisés bloquent l'envoi SMTP direct, ce qui casse les formulaires de contact et les notifications. Un relais SMTP dédié règle le problème, encore faut-il savoir que la limite existe.
HTTPS, certificat et en-têtes
Le certificat TLS doit être fourni et renouvelé automatiquement, sans intervention : un certificat expiré coupe le site et fait chuter le référencement. Vérifier la date d'expiration réelle et le mécanisme de renouvellement fait partie de la mise en service, pas de l'option.
Au-delà du certificat, ce sont les en-têtes qui protègent : HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy. Un hébergement qui n'autorise aucun en-tête personnalisé interdit de durcir le site, quelle que soit la qualité du code WordPress installé dessus.
La redirection systématique de HTTP vers HTTPS, et le choix d'un seul nom de domaine (avec ou sans www), évitent le contenu dupliqué et les cookies partagés entre deux versions du site.
Performance : cache, CDN, mesure
Le cache de page est ce qui distingue un WordPress rapide d'un WordPress lent : sans lui, chaque visite exécute PHP et interroge la base. Un cache serveur (au niveau de l'hébergeur) est plus efficace qu'une extension, mais doit s'entendre avec les extensions de e-commerce et de membre, qui exigent des pages non mises en cache.
Le CDN devant le site allège les images et absorbe les pics, à condition que le cache soit purgé à chaque publication. Un CDN mal configuré sert d'anciennes pages pendant des heures, ce qui est pire que pas de CDN.
La mesure qui compte est le temps de réponse serveur sur une page non cachée, et le temps de génération côté WordPress. Un test de vitesse sur la page d'accueil seule ne dit rien du parcours de commande.
Sauvegardes : la seule question qui vaille
Une sauvegarde n'existe que si elle a été restaurée au moins une fois. La bonne question n'est pas « combien de sauvegardes » mais « à quelle heure remonte la dernière, où est-elle stockée, et qui la restaure ». Une copie sur le même serveur ne protège ni d'une panne matérielle ni d'une suppression accidentelle.
La fréquence doit correspondre à l'activité : quotidienne pour un site qui publie, plus fréquente pour une boutique. La rétention compte autant — pouvoir revenir trois jours en arrière après une mise à jour qui casse un plugin est un besoin courant.
Les sauvegardes gérées par l'hébergeur ne dispensent pas d'une copie exportée et vérifiée : lors d'une migration ou d'une résiliation, c'est cette copie qui permet de repartir.
Migration : changer d'hébergeur sans coupure
Une migration propre se fait en quatre temps : copie complète (fichiers et base), installation sur la nouvelle plateforme, test avec le domaine de préproduction ou un fichier hosts, puis bascule du DNS. Le TTL du domaine doit être abaissé la veille — un TTL à vingt-quatre heures rallonge la bascule d'autant.
Le piège est l'adresse du site enregistrée en base : un WordPress migré sans mise à jour des URL garde les anciennes adresses, liens et images cassés. Les outils de migration modifient ces valeurs ; une migration manuelle impose de les corriger après import.
Enfin, garder l'ancien hébergement actif quelques jours après la bascule : le temps que la propagation se termine et que les courriels suivent, c'est la seule façon de revenir en arrière sans perte.
En images
Questions fréquentes
Quelle version de PHP faut-il pour WordPress ?
Une version encore maintenue, et la possibilité d'en changer depuis le panneau. Une version ancienne ralentit le site et n'est plus corrigée, ce qui en fait une faille de sécurité.
Un hébergement mutualisé suffit-il pour WordPress ?
Pour un site éditorial à trafic modéré, oui, si la mémoire PHP et le nombre de processus ne sont pas bridés trop bas. Un catalogue ou une boutique demandent davantage et se heurtent vite aux quotas.
Faut-il un accès SSH ?
Ce n'est pas obligatoire, mais sans SSH ni accès à la base, certaines réparations et migrations deviennent impossibles ou dépendent entièrement du support de l'hébergeur.
À quelle fréquence sauvegarder un site WordPress ?
Quotidiennement pour un site qui publie, davantage pour une boutique. Une sauvegarde ne vaut que si elle a déjà été restaurée une fois depuis un emplacement distinct du serveur.
Comment migrer sans perdre le référencement ?
Copier fichiers et base, tester sur un environnement de préproduction, abaisser le TTL avant la bascule, mettre à jour les URL en base et conserver l'ancien hébergement quelques jours après le changement de DNS.