Hébergement WordPress : Ce Que Vous Payez Vraiment

L’hébergement WordPress se vend dans une fourchette qui va d’environ 3 £ par mois à plusieurs centaines, et les formules situées aux deux extrémités se décrivent avec presque les mêmes mots. Rapide. Sécurisé. Sauvegardé. Accompagné. La spécification qui permettrait de les distinguer, à savoir quelle branche de PHP exécute le site, quel moteur de base de données se trouve derrière, combien de couches de cache existent et lesquelles sont réellement activées, est presque toujours absente de la page où l’on vous demande d’acheter.

Cette absence fait partie du produit. « Infogéré » est une catégorie marketing et non technique, et aucun organisme de normalisation ne la définit. Deux prestataires employant ce mot peuvent différer sur la présence d’un cache d’objets persistant, sur le droit de garder votre propre extension de cache, sur la possibilité qu’une sauvegarde quitte leur infrastructure, et sur l’accès à un shell.

Ce qui suit est la spécification que ces pages omettent : ce que WordPress exige, quelles parties de la pile déplacent la vitesse des pages, ce que l’infogérance ajoute et retire discrètement, et des fourchettes mensuelles réalistes par palier.

Que payez-vous réellement avec un hébergement WordPress ? Quatre choses. Une version de PHP et un moteur de base de données conformes au socle publié par WordPress. Des couches de cache que vous devriez sinon installer et régler vous-même. Du travail d’exploitation, c’est-à-dire mises à jour, préproduction, sauvegardes et pare-feu. Et de la marge pour les requêtes qu’on ne peut pas mettre en cache. Un site vitrine n’a presque aucun besoin de ce quatrième point. Une boutique ou un site à adhésion y dépense l’essentiel de son budget.

L’hébergement WordPress est un nom de catégorie, pas une spécification

L’écart de prix à l’intérieur d’une même catégorie est le signe révélateur. Deux formules portant toutes deux l’étiquette hébergement WordPress infogéré peuvent se situer à 20 £ et à 250 £ par mois, et le discours commercial n’expliquera pas l’écart, parce que l’écart est fait de choses que ce discours ne mentionne pas.

Du côté bon marché, vous achetez une part d’une machine partagée avec un pool PHP-FPM, un cache de page et un panneau de contrôle. Du côté cher, vous achetez du calcul isolé, un cache d’objets persistant, un environnement de préproduction, un pare-feu géré, une équipe de support qui lira votre journal d’erreurs, et quelqu’un de contractuellement responsable quand une mise à jour du cœur casse un gabarit.

Les deux sont des produits légitimes. Le problème est que l’acheteur ne peut pas voir lequel il a devant lui, si bien que la décision se prend sur le prix et sur des sites d’avis classés par commission d’affiliation. Le résultat est prévisible dans les deux sens. Des sites vitrines se retrouvent sur des formules à 150 £ qu’ils n’épuiseront jamais, et des boutiques WooCommerce sur des formules à 5 £ qui s’effondrent au paiement le premier samedi chargé.

La sortie consiste à acheter selon quatre questions plutôt que selon le nom du palier : quelle branche de PHP, quelles couches de cache, combien de requêtes non cachables la formule absorbe, et ce qu’il advient de vos données quand vous partez.

Ce que WordPress exige réellement d’un serveur

WordPress publie une page de prérequis, et elle est courte, ce qui explique précisément qu’on la saute. Lisez-la comme une spécification d’achat, car une formule qui échoue là est disqualifiée avant même qu’on parle de performance.

La version de PHP

La page des prérequis WordPress fixe le socle recommandé à « PHP version 8.3 ou supérieure ». Elle porte aussi un avertissement qui compte davantage que la recommandation : WordPress « fonctionnera toujours avec PHP 7.4+ et MySQL 5.5.5+, mais ces versions ont atteint leur fin de vie officielle et peuvent exposer votre site à des vulnérabilités de sécurité ».

Tout le piège tient dans cette phrase. WordPress ne refusera pas de démarrer sur une branche de PHP ancienne. Il tourne, paraît normal, et repose discrètement sur un interpréteur qui n’a pas reçu de correctif de sécurité depuis des années.

La base de données

La même page demande « MariaDB 10.11+ ou MySQL 8.0+ ». Les moteurs plus anciens fonctionnent encore, ce qui explique que tant de sites soient dessus. Les statistiques d’usage publiées par WordPress montrent qu’environ une installation sur six déclare une version MySQL 5.x, bien en dessous du plancher annoncé, MySQL 5.7 représentant à lui seul près de 12 pour cent des sites déclarants.

La conséquence n’est pas que le site casse. C’est que vous perdez des améliorations du moteur qui comptent précisément pour les charges difficiles à mettre en cache, et que vous héritez d’une migration qu’il faudra de toute façon faire un jour.

HTTPS et les extensions PHP

HTTPS est listé comme « requis pour toute installation », et non recommandé. Un hébergeur qui traite encore un certificat comme une option payante en 2026 vous dit quelque chose sur le reste de la formule.

Au-delà, le manuel d’hébergement WordPress désigne json et mysqli comme requis, et curl, dom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, xml et zip comme fortement recommandés. Deux méritent d’être cités à un commercial. Sans zip, les paquets de mise à jour des extensions et du cœur ne peuvent pas être décompressés. Sans imagick, les envois de médias retombent sur une bibliothèque d’images plus faible et vos images ressortent moins bonnes avant même qu’on installe la moindre extension d’optimisation.

La version de PHP est la ligne la plus rentable de la facture

De tout ce qu’un hébergeur contrôle, la branche de PHP offre le meilleur rapport entre effet et effort. Sur la plupart des panneaux, c’est une liste déroulante. Rien n’est reconstruit, rien n’est migré, et un site déjà compatible se met simplement à tourner sur un interpréteur plus rapide et mieux suivi.

Si elle reste inchangée pendant des années, la raison est organisationnelle et non technique. Personne n’en est propriétaire. L’agence qui a construit le site est passée à autre chose, l’hébergeur ne la changera pas unilatéralement parce qu’une erreur fatale dans une extension abandonnée deviendrait sa faute, et l’entreprise n’a aucune raison de penser à un chiffre qu’on ne lui a jamais montré.

La première question à poser à un hébergeur potentiel ne porte donc pas sur la vitesse. Elle porte sur la branche de PHP exécutée par défaut, sur les branches proposées, et sur votre capacité à en changer vous-même sans ouvrir de ticket. Un hébergeur qui ne propose qu’une branche que WordPress ne recommande plus a répondu à toutes les autres questions du même coup.

Testez en préproduction, ne basculez jamais la production. Un site qui passe de PHP 7.4 à 8.3 fait généralement remonter deux ou trois avis de dépréciation venus d’extensions non maintenues, et c’est là qu’est le coût réel. Prévoyez d’une demi-journée à une journée de développement, détaillée dans notre guide sur les tarifs des développeurs WordPress et les questions à poser.

La moitié sécurité de l’argument PHP

La performance est la raison que l’on invoque pour mettre PHP à jour. La sécurité est la raison qui compte vraiment, et elle se mesure au lieu de se discuter.

PHP publie son propre calendrier des versions prises en charge. Chaque branche reçoit deux ans de support actif puis deux ans de correctifs de sécurité seulement. En septembre 2026, cela place PHP 8.2 en mode sécurité seule jusqu’au 31 décembre 2026, et PHP 8.3 en mode sécurité seule jusqu’au 31 décembre 2027, son support actif ayant pris fin le 31 décembre 2025. PHP 8.4 reste en support actif jusqu’au 31 décembre 2026 avec des correctifs de sécurité jusqu’au 31 décembre 2028, et PHP 8.5 jusqu’au 31 décembre 2027 avec des correctifs jusqu’au 31 décembre 2029. Tout ce qui est plus ancien est terminé : PHP 8.1 s’est arrêté le 31 décembre 2025, PHP 8.0 le 26 novembre 2023 et PHP 7.4 le 28 novembre 2022.

Comparez cela à ce que les sites WordPress exécutent vraiment. La page de statistiques WordPress fait état d’environ 38,8 pour cent des installations sur une branche entièrement en fin de vie, dont à peu près 23,2 pour cent encore sur PHP 7.4 ou antérieur. Seuls 36,4 pour cent environ atteignent le socle PHP 8.3 recommandé par WordPress, et 24,8 pour cent de plus restent sur PHP 8.2, qui perd son support de sécurité à la fin de cette année.

Une majorité de sites WordPress tourne donc sur un interpréteur qui ne reçoit plus de correctifs de sécurité ou qui en est à quelques mois, et c’est presque toujours un réglage d’hébergement que personne n’a regardé. Le corriger coûte moins qu’une licence d’extension, et c’est pourquoi notre check-list de renforcement de la sécurité WordPress en fait la première étape.

Les couches de cache, dans l’ordre où une requête les rencontre

Presque toute promesse de performance faite par un hébergeur est une promesse sur le cache, et presque tout acheteur l’entend comme un engagement unique et indifférencié. Il existe quatre couches distinctes, elles se succèdent dans un ordre fixe, et chacune économise un travail différent. L’ordre ci-dessous est celui que suit une requête, et une requête servie par une couche antérieure n’atteint jamais les suivantes.

Le cache en périphérie ou CDN

La première chose qu’une requête rencontre est un cache entièrement extérieur à votre serveur, sur un réseau de points de présence proches du visiteur. Si la réponse y est déjà stockée, votre hébergeur ne voit jamais la requête.

Cette couche économise de la distance réseau autant que du calcul. Un visiteur de Manchester qui atteint un nœud à London évite un aller-retour transatlantique. Pour les ressources statiques, elle est quasiment gratuite et toujours utile. Pour le HTML, elle est puissante mais conditionnelle, car il faut indiquer à la périphérie quelles réponses sont personnelles et ne doivent jamais être partagées.

Le cache de page complète

La deuxième couche stocke le HTML fini d’une page pour que PHP et la base de données ne s’exécutent pas de nouveau. Le manuel d’hébergement WordPress recommande un proxy inverse comme NGINX ou Varnish, qui « stocke la sortie directement dans la mémoire du serveur ou sur le disque dur », et ajoute la règle qui décide si la couche fonctionne : « c’est une bonne idée d’exclure du cache tous les utilisateurs connectés, car ils sont censés voir du contenu personnalisé ».

C’est la couche qui flatte l’hébergement bon marché. Quand elle fonctionne, un visiteur reçoit un fichier, et la version de PHP, le moteur de base de données et le nombre d’extensions cessent de compter pour cette requête, puisque aucun d’eux ne s’exécute.

Le cache d’objets

La troisième couche met en cache les résultats de requêtes individuelles à la base et des valeurs calculées. WordPress la fournit par défaut, mais pas de façon persistante. La documentation de WP_Object_Cache est explicite : « Par défaut, le cache d’objets n’est pas persistant. Cela signifie que les données stockées dans le cache résident uniquement en mémoire et seulement pour la durée de la requête. »

La rendre persistante consiste à placer Redis ou Memcached derrière elle via un drop-in, ce qui transforme le cache, reconstruit à chaque chargement de page, en quelque chose de partagé entre les requêtes et les visiteurs. C’est la couche qui compte dès que les pages cessent d’être cachables en entier, et celle qui manque le plus souvent aux formules bon marché.

Le cache d’opcode

La quatrième couche est OPcache, qui conserve en mémoire partagée le bytecode compilé de vos fichiers PHP pour que l’interpréteur n’ait pas à les analyser et à les recompiler à chaque requête. Le manuel d’hébergement indique que « pour les environnements WordPress de production, il est recommandé qu’OPcache soit activé pour les requêtes web et dimensionné pour le site ou la plateforme d’hébergement ».

Il y a une conséquence côté déploiement. Puisque OPcache conserve du code compilé, un déploiement doit le réinitialiser ou invalider les fichiers modifiés, sinon le serveur continue d’exécuter la version précédente. Un hébergeur incapable de vous dire comment OPcache est invalidé est un hébergeur où une mise à jour d’extension semble ne rien faire pendant plusieurs minutes.

Pourquoi un site vitrine est rapide chez presque n’importe quel hébergeur

Suivez ces quatre couches jusqu’au bout et la conclusion est inconfortable pour le secteur de l’hébergement. Si chaque visiteur est anonyme et chaque page cachable, le cache de page complète répond à presque tout le trafic, et la fiche technique de la machine derrière ne pèse presque rien.

C’est pourquoi un site d’entreprise de cinq pages sur une formule à 4 £ avec un cache de page correct peut afficher un meilleur temps de réponse serveur qu’un site surchargé sur une formule à 200 £. Le site bon marché sert des fichiers. Le site cher exécute du PHP.

Le chiffre à surveiller est le temps jusqu’au premier octet, qui n’est pas lui-même un Core Web Vital. L’aperçu des Web Vitals de Google le classe parmi les métriques de soutien, utiles au « diagnostic des problèmes de LCP » causés par des temps de réponse serveur lents. C’est exactement la part de la vitesse d’une page que l’hébergeur contrôle.

WordPress est assez d’accord pour l’avoir écrit dans le cœur. Le test de santé du site ajouté dans WordPress 6.1 vérifie « si le site utilise une solution de cache de page complète et si le temps de réponse est acceptable », avec un seuil par défaut de 600 millisecondes. Si votre site dépasse ce seuil alors qu’un cache de page est censé être actif, le cache ne fonctionne pas, et du processeur en plus ne le masquera pas.

Pour un site vitrine, une montée en gamme d’hébergement est donc rarement le bon achat. Ce qui le ralentit, c’est plus souvent une image d’en-tête surdimensionnée, un constructeur de pages qui livre des centaines de kilo-octets de CSS, ou six graisses de police, ce qui est l’argument de notre comparaison entre Elementor et un thème sur mesure.

Le trafic connecté et WooCommerce cassent le modèle

Tout ce qui précède suppose que le cache de page peut répondre. Dès l’instant où les visiteurs se connectent, cette hypothèse s’effondre et l’économie de l’hébergement s’inverse.

WooCommerce le documente directement. Ses recommandations sur le cache demandent d’exclure Panier, Mon compte et Commande du cache de page parce que ces pages « doivent rester dynamiques puisqu’elles affichent des informations propres au client courant et à son panier ». Elles listent aussi les cookies qui doivent contourner le cache, dont woocommerce_cart_hash, woocommerce_items_in_cart et wp_woocommerce_session_, et conseillent d’exclure _wc_session_ du cache de base de données.

Lu comme une spécification d’hébergement, cela dit quelque chose de brutal. Sur une boutique, les pages qui génèrent du chiffre d’affaires sont précisément celles que le cache de page ne peut pas toucher. Le catalogue et les fiches produit se mettent en cache pour les visiteurs anonymes. Le panier et le paiement, jamais, pour personne.

Il en va de même des sites à adhésion, des plateformes d’apprentissage, des forums et de tout site doté d’un espace client. Dès qu’un cookie de session est posé, la plupart des extensions de cache cessent totalement de servir du HTML mis en cache à ce visiteur, si bien que chaque clic exécute du PHP et interroge la base. C’est là que le cache d’objets cesse d’être une optimisation et devient porteur, et là qu’une formule bon marché fait mal d’une façon qu’aucun test synthétique de page d’accueil ne révèle, comme l’explique pourquoi votre boutique WooCommerce est lente.

Ce que l’hébergement WordPress infogéré comprend réellement

Retirez les adjectifs et l’infogérance se ramène à un ensemble assez constant de travail d’exploitation. Il vaut la peine de chiffrer ce travail honnêtement, car pour une entreprise sans personnel technique, il coûte souvent moins cher acheté que fait soi-même.

Les mises à jour

Les formules infogérées appliquent en général les mises à jour du cœur automatiquement, parfois aussi celles des extensions, occasionnellement avec un contrôle visuel de régression avant et après. Ce qu’il est utile de savoir, c’est tout ce que WordPress fait déjà gratuitement.

WordPress met à jour automatiquement les versions mineures du cœur et les fichiers de traduction depuis des années, et depuis la 5.6 les nouvelles installations ont les mises à jour automatiques activées pour les versions mineures comme majeures du cœur, sauf si un dépôt de gestion de versions est détecté, tandis que les installations existantes conservent l’ancien comportement. La partie payante n’est donc pas la mise à jour mineure du cœur. Ce sont les mises à jour d’extensions, le retour en arrière quand l’une d’elles casse, et quelqu’un qui remarque qu’elle a cassé.

Préproduction et sauvegardes

Un environnement de préproduction en un clic a une vraie valeur et est vraiment pénible à construire soi-même. Jugez-le sur deux détails plutôt que sur son existence : si la remise en production de la préproduction écrase la base de données en ligne, ce qui jetterait les commandes et les commentaires reçus depuis la copie, et si le site de préproduction est bloqué pour les moteurs de recherche et pour l’envoi d’e-mails.

Pare-feu et analyse antimalware

La plupart des formules infogérées incluent un pare-feu applicatif en périphérie et une forme d’analyse antimalware. Le pare-feu a une valeur réelle, car le correctif virtuel au niveau réseau achète du temps entre la divulgation d’une faille d’extension et votre mise à jour.

L’analyse est plus faible qu’elle n’en a l’air. Elle détecte en général des signatures de fichiers malveillants connus, donc elle attrape les infections de masse et manque les attaques ciblées. Traitez-la comme un détecteur de fumée plutôt que comme une serrure, et gardez le travail de renforcement de votre côté de la ligne.

Ce que l’hébergement infogéré retire

Les restrictions sont la moitié que personne ne lit, et elles pèsent d’ordinaire plus lourd que les fonctionnalités. Elles existent pour des raisons défendables, mais ce sont les raisons du prestataire, pas les vôtres.

L’exemple publié le plus clair est la liste d’extensions interdites de WP Engine, qui bannit des catégories entières plutôt que des fautifs isolés. Les extensions de cache sont interdites parce qu’elles « peuvent entrer en conflit avec la structure de cache intégrée de notre plateforme ». Les extensions de sauvegarde sont interdites au motif qu’elles « alourdissent inutilement votre site ». Les extensions d’articles similaires sont interdites comme « extrêmement gourmandes en base de données ». Les extensions présentant des failles documentées sont interdites purement et simplement, tout comme celles qui doublent une fonction de la plateforme.

Chacune de ces règles est une décision d’ingénierie raisonnable. Ensemble, elles signifient que votre site n’est pas portable comme vous le supposiez. Si votre construction dépend de la configuration d’une extension de cache précise, cette configuration ne déménage pas avec vous.

L’accès au shell est l’autre omission courante. Beaucoup de formules infogérées ne fournissent aucun SSH, ou un shell restreint sans WP-CLI, ce qui transforme un travail de routine comme un remplacement en masse après un changement de domaine en ticket de support. Deux autres points surprennent : les processus longs sont fréquemment plafonnés, si bien qu’un import de 50 000 produits doit être découpé, et le courrier sortant est souvent bloqué ou limité, en partant du principe qu’un site compromis servira au spam.

Les promesses de performance qui ne survivent pas au test

Le marketing de l’hébergement repose sur un petit jeu d’affirmations qui se défont dès qu’on demande ce qui a été mesuré.

« Vingt fois plus rapide » ne nomme presque jamais une référence. Plus rapide que quoi, sur quelle page, avec quelles extensions, sous quelle concurrence ? Sans ces quatre éléments, le chiffre est un rapport entre deux quantités inconnues.

« Bande passante illimitée » voisine avec un quota mensuel de visites dans le même tableau. La bande passante est de toute façon rarement la contrainte sur un site WordPress. La contrainte est l’exécution simultanée de PHP, que la formule ne mentionne généralement pas du tout.

« 99,9 pour cent de disponibilité » sonne absolu et ne l’est pas. Sur un mois de trente jours, cela autorise environ 43 minutes d’indisponibilité. Trois neuf est un chiffre normal en mutualisé, quatre neuf autorise environ quatre minutes par mois, et l’écart sépare un désagrément d’une panne que personne ne remarque. Lisez ce que l’avoir paie réellement quand l’engagement est manqué, sujet traité à part dans les SLA de disponibilité qui veulent dire quelque chose.

La dernière affirmation est la plus fréquente et la plus trompeuse : une capture d’un test de vitesse sur une page d’accueil en cache. Cela mesure le cache de page, pas l’hébergeur, et le cache de page est le seul composant à peu près équivalent partout.

Comment tester correctement un hébergeur

Tester un hébergement n’est pas difficile, mais il faut le faire sur le chemin qui sollicite vraiment le serveur. Cinq étapes, dans l’ordre.

D’abord, testez un chemin non mis en cache. Ajoutez une chaîne de requête unique pour déjouer le cache de page, ou demandez une page qui n’est jamais mise en cache, comme un panier ou une page de compte. Si vous ne pouvez pas émettre une requête qui exécute du PHP, vous testez un serveur de fichiers.

Ensuite, répétez. Une requête isolée ne dit rien de la variance, et c’est dans la variance que l’hébergement bon marché se montre. Prenez au moins vingt échantillons et lisez le 75e centile, la statistique que Google utilise pour les données de terrain.

Troisièmement, testez depuis l’endroit où sont vos visiteurs. Une réponse mesurée depuis un centre de données voisin du serveur n’est pas celle que reçoivent vos clients à Leeds.

Quatrièmement, testez sous concurrence. Lancez dix ou vingt requêtes non cachables simultanées. C’est le seul test qui révèle l’épuisement des workers PHP, et c’est cet épuisement qui met une boutique à terre pendant une promotion.

Cinquièmement, comparez à conditions égales : même branche de PHP, même jeu d’extensions, même thème, même volume de contenu. Une migration qui change la pile d’extensions en même temps que l’hébergeur n’a rien prouvé sur l’un ni sur l’autre. Si vous voulez cela sur un site réel plutôt que sur un hébergeur candidat, c’est précisément ce que fait un audit de performance WordPress.

Quels Core Web Vitals l’hébergement déplace vraiment

Les Core Web Vitals sont l’endroit où les promesses d’hébergement et le classement de recherche se confondent, d’où l’intérêt d’être précis sur la métrique qu’un serveur peut influencer.

Il y en a trois, évaluées au 75e centile des chargements et séparées entre mobile et ordinateur. Largest Contentful Paint mesure le chargement : bon à 2,5 secondes ou moins, à améliorer entre 2,5 et 4,0 secondes, mauvais au-delà de 4,0. Interaction to Next Paint mesure la réactivité : bon à 200 millisecondes ou moins, à améliorer jusqu’à 500 millisecondes, mauvais au-dessus. Cumulative Layout Shift mesure la stabilité visuelle : bon à 0,1 ou moins, à améliorer jusqu’à 0,25, mauvais au-delà. First Input Delay a été retiré et remplacé par INP, devenu un Core Web Vital stable en 2024.

L’hébergement en déplace exactement un directement. Le temps de réponse serveur fait partie du LCP, donc un hébergeur qui en retire 400 millisecondes retire 400 millisecondes de LCP à chaque visiteur. Sur un hébergeur lent, cela peut faire la différence entre réussir et échouer.

Il ne fait presque rien pour le CLS, qui vient d’images sans dimensions et de polices chargées tard, et très peu pour l’INP, dominé par le JavaScript sur le fil principal. La règle : si le LCP est mauvais et que votre réponse serveur non mise en cache dépasse le seuil de 600 millisecondes signalé par WordPress, l’hébergement fait partie du problème. Si la réponse est confortable et que le LCP reste mauvais, le défaut est dans la page, et notre guide pour réussir les Core Web Vitals en 2026 est un meilleur emploi du budget.

Les sauvegardes, et la part que personne ne vérifie

Toute formule au-dessus de la moins chère annonce des sauvegardes. Presque personne, en achetant, ne pose les questions qui décident si la sauvegarde vaut quelque chose.

Est-ce que quelqu’un en a déjà restauré une

Le NCSC le dit simplement dans son guide pour les petites structures : une fois la sauvegarde faite, « il est important de savoir comment la restaurer et de vérifier qu’elle contient toutes vos données importantes ». Une sauvegarde non testée est une croyance, pas un contrôle.

Demandez au prestataire comment une restauration se déclenche, combien de temps elle prend pour un site de votre taille, et si restaurer la base restaure aussi le répertoire des envois. Puis faites-le une fois en préproduction, avant d’en avoir besoin. Le mode de défaillance à guetter est une restauration qui rend les fichiers mais pas la base, ou qui réussit en perdant discrètement tout ce qui a été créé depuis la copie.

Rétention et fréquence

Des sauvegardes quotidiennes avec sept jours de rétention semblent généreuses jusqu’à ce qu’on regarde comment un site WordPress tombe vraiment. Un site défiguré se remarque en quelques heures. Une compromission qui injecte discrètement des liens de spam dans d’anciens articles se remarque en quelques semaines, et d’ici là chaque copie conservée contient l’injection.

Trente jours sont un plancher plus utile pour tout usage commercial, et une copie mensuelle séparée est une assurance peu coûteuse. Une boutique a en outre besoin d’un intervalle de sauvegarde de base mesuré au volume de commandes, car perdre quatre heures de commandes n’est pas le même genre de problème que perdre quatre heures de modifications de blog.

Où vit la copie, et sous quel format

L’autre remarque du NCSC est qu’une sauvegarde restée attachée au système en production n’est pas séparée : un appareil qui contient des sauvegardes « ne devrait pas rester connecté à votre appareil lorsqu’il n’est pas utilisé », car ce qui compromet la source peut l’atteindre. Appliqué à l’hébergement, une sauvegarde stockée sur le même compte et restaurable uniquement depuis le même panneau partage le sort de ce qu’elle protège.

Le format est la version plus subtile du même problème. Si le seul moyen de lire une sauvegarde est le bouton de restauration du prestataire, vous avez une commodité et non une copie portable. Le test consiste à savoir si vous pouvez télécharger aujourd’hui un simple export SQL et une archive de fichiers qu’un développeur compétent pourrait remonter ailleurs. Sinon, la migration cesse d’être une décision technique et devient une négociation.

Où résident les données, et pourquoi cela compte pour les acheteurs britanniques

Les décisions d’hébergement sont des décisions de protection des données, et pour une entreprise britannique la question n’est pas où la société est immatriculée mais où les données personnelles reposent et qui peut les atteindre.

Le guide de l’ICO sur les transferts internationaux pose un test en trois étapes. Si le RGPD britannique s’applique à votre traitement, que c’est vous qui initiez le transfert et que l’organisation destinataire est une entité juridique distincte, vous effectuez un transfert restreint. L’ICO précise que les règles « s’appliquent à tous les transferts restreints, même petits et peu fréquents » et couvrent toute organisation traitant des données personnelles, « y compris les entrepreneurs individuels et les travailleurs indépendants ».

Notez ce qui compte comme transfert. L’ICO y inclut aussi bien l’envoi de données personnelles que le fait de « les rendre accessibles » à une organisation hors du Royaume-Uni. Une équipe de support à l’étranger disposant d’un accès à votre administration, ou une sauvegarde externalisée répliquée dans une autre région, peuvent chacune répondre à cette définition.

Tout transfert restreint doit être couvert par l’une de trois choses : des règles d’adéquation britanniques pour la destination, des garanties appropriées comme l’International Data Transfer Agreement, l’avenant ou des règles d’entreprise contraignantes, ou une dérogation. Lorsque vous vous appuyez sur des garanties, l’ICO attend aussi une évaluation du risque de transfert montrant que la protection n’est pas sensiblement moindre ensuite. Rien de tout cela ne rend inutilisable un hébergeur étranger. Cela en fait une décision qu’il faut documenter, et documenter coûte bien moins cher avant une migration que pendant une demande d’accès.

Ce que doit dire un contrat de sous-traitance

Votre hébergeur est sous-traitant et vous êtes responsable de traitement, un contrat écrit n’est donc pas optionnel. L’ICO énumère ce que ce contrat doit contenir, et quatre de ses clauses se lisent directement comme des questions d’hébergement.

Les sous-traitants ultérieurs viennent d’abord. En vertu de l’article 28(3)(d), le sous-traitant ne doit pas recruter un autre sous-traitant sans votre autorisation, doit vous informer des changements prévus pour que vous puissiez vous y opposer, et doit imposer des obligations équivalentes en aval. En termes d’hébergement, il s’agit du CDN, de la destination des sauvegardes, du relais de messagerie et du fournisseur cloud sous-jacent. Demandez la liste.

La sécurité vient ensuite. L’article 28(3)(c) exige des mesures satisfaisant à l’article 32, et l’ICO détaille ce qu’elles comprennent : chiffrement et pseudonymisation, résilience des systèmes de traitement, « la capacité de rétablir l’accès aux données personnelles en cas d’incident », et « des procédures de test et d’évaluation réguliers de l’efficacité des mesures ». C’est le test de restauration inscrit dans la loi plutôt que dans un article de bonnes pratiques.

Vient troisièmement la sortie. En vertu de l’article 28(3)(g), le sous-traitant doit, à votre choix, supprimer ou restituer toutes les données personnelles à la fin du contrat et supprimer les copies existantes. Un prestataire dont les sauvegardes ne peuvent pas quitter la plateforme a un problème contractuel autant que pratique. Quatrièmement l’audit, qui en vertu de l’article 28(3)(h) vous donne droit aux informations nécessaires pour démontrer la conformité ainsi qu’à ses certifications et rapports.

Les paliers, et ce qu’ils coûtent au Royaume-Uni

Quatre paliers couvrent presque tous les sites WordPress, et les frontières entre eux sont fixées par la charge non cachable plutôt que par le trafic. Les fourchettes ci-dessous sont ce que les acheteurs britanniques paient typiquement par mois. Ce sont des fourchettes de catégorie et non le tarif d’un prestataire donné, traitez-les donc comme un contrôle de vraisemblance sur un devis plutôt que comme un devis.

Hébergement mutualisé, 3 à 15 £ par mois

Parfaitement adéquat pour un site vitrine cachable, et vraiment mauvais rapport qualité-prix dès que quelqu’un se connecte. Vous partagez la capacité PHP avec des voisins invisibles, donc c’est la variance sous charge qui mord, pas la moyenne. Vérifiez d’abord la branche de PHP, car c’est dans ce palier que se concentrent les interpréteurs en fin de vie.

WordPress infogéré, 20 à 400 £ par mois

Le bon choix par défaut pour les sites de contenu et les petites boutiques. Vous achetez des mises à jour, une préproduction, un pare-feu, un cache d’objets persistant et une équipe de support, et vous le payez avec les restrictions ci-dessus. La tranche de 20 à 100 £ couvre un site unique à trafic modéré. Au-delà, vous payez généralement pour plus de sites, plus de visites ou plus de workers PHP.

VPS ou cloud avec votre propre pile, 15 à 120 £ plus l’administration

Une instance cloud modeste coûte 15 à 120 £ par mois, mais la machine est la partie bon marché. Quelqu’un doit corriger le système d’exploitation, régler le proxy inverse, faire tourner le cache d’objets et gérer les sauvegardes, et acheter cela coûte 150 à 600 £ de plus par mois. Justifié quand la charge non cachable est réelle, ou quand votre pile a des exigences qu’une plateforme infogérée interdit.

Infrastructure sur mesure, à partir de 400 £ par mois

Déploiements multirégions, événements à forte concurrence, résidence des données stricte, ou architecture où WordPress n’est qu’un composant parmi d’autres. L’hébergement cesse d’être une décision de produit et devient une partie de la construction, c’est ainsi que nous l’abordons dans une mission de développement de site web.

Dimensionner par requêtes non cachables, pas par pages vues

Les formules d’hébergement se vendent en visites mensuelles parce que c’est un chiffre que les acheteurs reconnaissent. Il est presque inutile pour dimensionner, car 100 000 pages vues anonymes en cache ne coûtent presque rien alors que 10 000 pages vues connectées peuvent saturer un petit serveur.

Le chiffre qui compte est le nombre de requêtes non cachables simultanées, et le calcul est simple. Un worker PHP traite une requête non cachable à la fois. Le nombre de workers nécessaires vaut à peu près le pic de requêtes non cachables par seconde multiplié par le temps de réponse PHP moyen en secondes. Vingt requêtes non cachables par seconde à 400 millisecondes chacune demandent environ huit workers pour suivre, et il en faut au moins la moitié en plus comme marge.

Posez donc deux questions auxquelles aucune page tarifaire ne répond : combien de workers PHP cette formule fait-elle tourner, et quelle est la limite de mémoire par processus ? Les deux chiffres existent et ni l’un ni l’autre n’est publié d’ordinaire. Le support vous les donnera normalement si vous demandez directement, et la réponse en dit plus sur la formule que tous les tests de la page.

Estimez ensuite votre propre côté honnêtement. Comptez la proportion de sessions connectées, le trafic de paiement et de compte à votre heure la plus chargée plutôt qu’à votre heure moyenne, et tout le trafic admin-ajax ou REST que vos extensions génèrent en arrière-plan, invisible dans les statistiques et très visible dans un journal serveur.

Le nombre d’extensions et le volume éditorial sont des décisions d’hébergement

Deux choses à l’intérieur du site déterminent la quantité d’hébergement nécessaire, et toutes deux sont d’ordinaire traitées comme des décisions de contenu prises par des gens qui ne voient jamais la facture.

La première est la pile d’extensions. Chaque extension active ajoute des options chargées automatiquement à chaque requête, des événements planifiés qui se déclenchent sur les requêtes des visiteurs parce que le cron de WordPress n’est pas un vrai cron, et des requêtes par construction de page. Trente extensions sur un site vitrine mis en cache, cela se supporte. Trente extensions sur une boutique où rien ne se met en cache, cela veut dire trente extensions exécutées à chaque étape du paiement. Le cœur de WordPress a une idée approximative du moment où cela commence à mordre : le contrôle de santé du cache d’objets persistant suggère un cache d’objets dès qu’un site dépasse des seuils tels que 2 000 articles, 2 000 comptes ou 600 options chargées automatiquement.

La seconde est le volume éditorial. Les révisions s’accumulent sans limite par défaut, les médiathèques atteignent des dizaines de milliers de fichiers comportant chacun plusieurs tailles générées, et les deux gonflent la base et la fenêtre de sauvegarde. Un site qui publie chaque jour depuis cinq ans est un problème d’hébergement nettement différent du même design publiant chaque mois, et rien sur la page tarifaire ne le reflète. Auditer la construction, pas la formule, voilà ce qu’un développeur WordPress devrait faire avant de chiffrer une migration.

Choisir, dans l’ordre

Déroulez cette séquence et la décision se prend souvent d’elle-même. Établissez quelle proportion de votre trafic est non cachable, car ce seul chiffre choisit votre palier. Vérifiez que la branche de PHP et la version de base de données atteignent le socle publié, car une formule qui échoue là est disqualifiée quel que soit le prix. Établissez quelles couches de cache sont incluses et lesquelles vous devez fournir. Demandez où vivent les sauvegardes, sous quel format, et si vous pouvez en télécharger une aujourd’hui. Lisez ensuite les clauses de sous-traitance sur les sous-traitants ultérieurs, la localisation des données et la suppression en fin de contrat. Ce n’est qu’après tout cela que le prix veut dire quelque chose, car jusque-là vous comparez des produits qui ne sont pas le même produit.

Mecanik fait cela comme un lot de travail à prix fixe avant toute migration, généralement aux côtés d’une mission de développement de site web, et le prend en charge en accompagnement continu via notre service de développeur WordPress à louer. Si vous vous demandez où va la plateforme elle-même, notre article sur WordPress 7.0 et le client IA dans le cœur accompagne bien celui-ci.

Questions fréquentes

Combien devrait coûter un hébergement WordPress au Royaume-Uni ? Cela dépend presque entièrement de la part de votre trafic qui peut être mise en cache. Un site vitrine à visiteurs anonymes est bien servi à 3 à 15 £ par mois en mutualisé. Un site de contenu ou une petite boutique relève en général d’un hébergement WordPress infogéré à 20 à 100 £ par mois, montant à 100 à 400 £ pour les formules chargées ou multisites. Une boutique ou un site à adhésion au trafic connecté important demande typiquement un VPS ou une pile cloud à 15 à 120 £ pour la machine, plus 150 à 600 £ par mois si quelqu’un d’autre l’administre.

L’hébergement WordPress infogéré vaut-il le supplément ? Oui si vous n’avez personne aux opérations, car vous achetez des mises à jour, une préproduction, des sauvegardes, un pare-feu et un cache d’objets persistant que vous devriez sinon configurer vous-même. La contrepartie est faite de restrictions réelles. Les prestataires interdisent couramment les extensions de cache, de sauvegarde et gourmandes en base de données, retiennent souvent l’accès au shell, plafonnent les processus longs et bloquent le courrier sortant. Vérifiez ces limites face à votre construction avant de vous engager, pas après.

Quelle version de PHP WordPress demande-t-il en 2026 ? WordPress recommande PHP 8.3 ou supérieur. Il fonctionne encore sur PHP 7.4 et au-dessus, mais ces branches sont en fin de vie et ne reçoivent aucun correctif de sécurité. PHP 8.1 s’est arrêté le 31 décembre 2025, PHP 8.0 le 26 novembre 2023 et PHP 7.4 le 28 novembre 2022, tandis que PHP 8.2 est en mode sécurité seule jusqu’au 31 décembre 2026. Environ 38,8 pour cent des installations WordPress déclarent encore une branche entièrement en fin de vie.

Un meilleur hébergement améliore-t-il les Core Web Vitals ? Une seule des trois, et seulement indirectement. Le temps de réponse serveur fait partie du Largest Contentful Paint, donc un hébergeur plus rapide abaisse le LCP pour chaque visiteur. Il ne fait presque rien pour le Cumulative Layout Shift, qui vient d’images sans dimensions et de polices chargées tard, et très peu pour l’Interaction to Next Paint, dominé par le JavaScript sur le fil principal. Si votre réponse serveur est déjà confortable, le problème restant est dans la page.

Pourquoi ma boutique WooCommerce est-elle lente sur une formule qui se dit rapide ? Parce que les pages qui comptent ne peuvent pas être mises en cache. WooCommerce exige que Panier, Mon compte et Commande restent dynamiques, et pose des cookies de session qui contournent le cache de page pour les acheteurs connectés. Le test de vitesse sur votre page d’accueil mesure un fichier en cache, alors que le paiement exécute du PHP et interroge la base à chaque requête. La capacité pour les requêtes non cachables, et non le chiffre de la page d’accueil en cache, est ce qu’une boutique achète réellement.