Hébergement pour WordPress

Ce que WordPress demande vraiment à un serveur

Le projet WordPress publie sa configuration attendue, et cette liste est courte. Il faut PHP en version 8.3 ou supérieure, une base de données MariaDB 10.11 ou supérieure ou MySQL 8.0 ou supérieure, et une connexion chiffrée en HTTPS, exigée pour toute installation. Côté serveur web, Apache et Nginx sont recommandés, mais n’importe quel serveur capable de faire tourner PHP et une base de données fait l’affaire.

À cela s’ajoute un module de réécriture d’URL, recommandé pour que les permaliens propres fonctionnent. Sans lui, les adresses de vos articles gardent une forme technique avec un point d’interrogation et un identifiant, et les réglages de permaliens de WordPress restent sans effet.

Une nuance mérite d’être posée tout de suite, parce qu’elle explique la moitié des malentendus. WordPress continue de tourner sur des versions bien plus anciennes, PHP 7.4 et MySQL 5.5.5 par exemple. Techniquement, le site s’affiche. Sauf que ces versions ont atteint leur fin de vie officielle : elles ne reçoivent plus de correctifs de sécurité, et le projet WordPress le dit explicitement.

La conséquence pratique est simple. La question à poser n’est pas « prenez-vous en charge WordPress » — tout le monde répond oui — mais « quelles versions de PHP et de base de données proposez-vous, et puis-je en changer moi-même depuis le panneau d’administration ». Cette deuxième partie compte autant que la première.

Vérifier la configuration en deux clics

WordPress embarque un outil de diagnostic que la plupart des guides ignorent, et qui répond à la question mieux qu’aucune fiche commerciale. Il se trouve dans le menu Outils, sous le nom Santé du site, et se divise en deux onglets.

L’onglet État affiche une série de tests et une note globale, en séparant ce qui fonctionne, ce qui mérite attention et ce qui est critique. C’est là que remontent les versions périmées, l’absence de connexion chiffrée, les extensions abandonnées et les modules PHP recommandés qui manquent. Ces derniers apparaissent sous leur nom technique — intl pour la gestion des langues, zip pour l’archivage, imagick pour le traitement d’images — et la liste des modules recommandés évolue avec les versions de WordPress. Chez les hébergeurs les plus économiques, il en manque souvent un ou deux.

L’onglet Informations donne la fiche technique complète de l’installation : version exacte de PHP, version du serveur de base de données, limites de configuration en vigueur, espace disque, taille de la base. Un seul écran suffit à savoir sur quoi tourne réellement le site.

Avant de souscrire, on n’a évidemment pas accès à cet écran. Deux substituts existent : la page des spécifications techniques de l’offre, où les versions doivent être écrites noir sur blanc, et une question directe au support avant paiement. Un hébergeur incapable de répondre précisément à cette question répond déjà quelque chose.

Ce qui consomme réellement des ressources

Les offres présentent ensemble trois ressources pourtant distinctes. L’espace disque stocke les fichiers et la base. La mémoire allouée à PHP détermine ce qu’une page peut charger en une exécution. La puissance de calcul décide de la vitesse à laquelle les pages se construisent. Un hébergement généreux en espace peut se révéler très serré sur les deux autres.

Sur un site réel, la charge vient d’abord des médias. Des photos envoyées telles quelles depuis un appareil, en pleine résolution, remplissent un espace disque bien plus vite que des années d’articles, et chaque image envoyée génère en plus plusieurs formats intermédiaires. Redimensionner avant l’envoi coûte quelques secondes et économise beaucoup.

C’est aussi la réponse à la question du volume à prévoir : elle n’a pas de valeur universelle, parce qu’elle dépend presque entièrement de la médiathèque. Le chiffre utile n’est pas un total mais une vitesse. Regardez de combien l’espace occupé progresse en un mois d’activité normale, multipliez par douze, et vous saurez si l’offre tient deux ans ou six mois.

Viennent ensuite les extensions actives. Le nombre importe moins que leur nature : une extension de cache soulage le serveur, un constructeur de pages, un module de statistiques ou une boutique le sollicitent à chaque affichage. Une extension désactivée mais présente ne consomme rien à l’affichage, en revanche elle continue d’occuper de l’espace et reste une surface à mettre à jour.

La base de données grossit plus discrètement. Trois postes méritent le ménage en priorité : les révisions d’articles conservées indéfiniment, les données laissées derrière elles par des extensions supprimées, et les tables de journalisation créées par certains modules. Rien de dramatique, mais un passage périodique évite les surprises.

Reste le trafic non humain. Les robots d’indexation et les outils d’analyse frappent un site en continu, et sur un hébergement mutualisé ce trafic pèse autant que les visiteurs réels. C’est souvent lui qui explique une lenteur inexplicable aux heures creuses.

Les limites qui bloquent au quotidien

Aucune de ces limites n’apparaît dans un comparatif, et ce sont elles qui produisent les blocages les plus fréquents.

La mémoire allouée à PHP arrive en tête. Quand une page demande plus que la limite en vigueur, elle ne ralentit pas : elle s’arrête, sur un écran blanc ou un message d’épuisement de mémoire. Le plafond se lit dans l’onglet Informations, et se relève selon les hébergeurs depuis le panneau d’administration ou par une ligne ajoutée au fichier de configuration wp-config.php. Chez les plus restrictifs, il ne se relève pas du tout, et cela ne se découvre qu’une fois le site en place.

La taille maximale d’envoi de fichiers vient juste après. Elle décide de ce que vous pouvez déposer dans la médiathèque, et elle est le plus souvent en cause quand une vidéo ou un thème un peu lourd est refusé sans explication claire. La valeur en vigueur est affichée par WordPress lui-même, y compris dans l’écran d’envoi de médias.

La durée maximale d’exécution d’un script limite les opérations longues : import de contenu, sauvegarde complète, mise à jour massive. Un script coupé en pleine opération laisse parfois un travail à moitié fait, ce qui rend cette limite plus gênante qu’un simple ralentissement.

Les sauvegardes forment le troisième réglage décisif, et le plus mal lu. Trois questions comptent, dans cet ordre : à quelle fréquence la sauvegarde tourne, combien de temps les copies sont conservées, et surtout si vous pouvez déclencher une restauration vous-même depuis votre panneau d’administration. Une sauvegarde quotidienne dont la restauration passe par un ticket au support et un délai de plusieurs heures ne vaut pas une sauvegarde hebdomadaire que vous restaurez en trois clics. Vérifiez aussi que la sauvegarde couvre bien la base de données et pas seulement les fichiers.

Les accès techniques suivent la même logique. Un accès de transfert de fichiers et un accès à la base de données déterminent ce que vous pouvez réparer seul : désactiver une extension fautive quand l’administration ne répond plus, remettre un fichier de thème en place, exporter la base avant une manipulation. Sans ces accès, chaque incident devient une demande d’assistance.

Enfin, les tâches planifiées méritent une explication, parce qu’elles fonctionnent de manière contre-intuitive. Le planificateur interne de WordPress n’est pas une horloge : il se déclenche à l’occasion des visites du site. Sur un site peu fréquenté, une publication programmée à six heures du matin peut donc partir en retard, simplement parce que personne n’est passé. La solution consiste à désactiver ce comportement et à confier le déclenchement à une vraie tâche planifiée côté serveur, à intervalle régulier. Encore faut-il que l’hébergement permette d’en créer une, ce qui n’est pas toujours le cas.

Reconnaître un hébergement sous-dimensionné

Les symptômes sont assez caractéristiques pour remonter à la cause sans outil de mesure.

Le tri se fait donc en deux temps. Si le symptôme est reproductible et localisé, cherchez la limite de configuration correspondante et tentez de la relever. S’il est diffus et lié à la fréquentation, la question n’est plus un réglage : c’est la ressource elle-même qui manque.

Installer WordPress chez un hébergeur

Trois voies existent, et le choix se fait selon ce que vous acceptez de faire vous-même.

L’installateur automatique du panneau d’administration de l’hébergeur pose le site en quelques minutes, base de données comprise. Point de vigilance : certains installateurs ajoutent des extensions maison ou une page d’accueil promotionnelle qu’il faut retirer ensuite, et il faut contrôler que la version de PHP retenue est bien la version récente et non celle par défaut du compte.

L’installation manuelle consiste à transférer l’archive officielle, créer une base de données et renseigner ses identifiants. C’est plus long, et cela reste la voie la plus lisible : vous savez exactement ce qui est installé. Prévoyez un accès de transfert de fichiers et les droits de création de base.

La migration d’un site existant est la seule des trois qui demande une vraie méthode. Il faut déplacer les fichiers et la base, corriger les adresses du site dans la configuration et dans la base, et surtout ne pas basculer le nom de domaine avant d’avoir vérifié que la copie fonctionne. Une extension de migration fait le gros du travail, mais la vérification de fin reste manuelle : pages, formulaires, envoi d’e-mails, permaliens.

Dans les trois cas, un dernier geste s’impose avant de considérer le site en ligne : ouvrir l’écran de diagnostic et lire les alertes. C’est le moment où elles se corrigent le plus facilement.