Hébergeur WordPress : comparer sans pièges marketing

Comparer un hébergeur WordPress ne consiste pas à opposer des promesses de rapidité, de simplicité ou de sécurité. Ces mots décrivent une intention commerciale, mais rarement une capacité technique mesurable. Une offre utile se lit plutôt comme un cahier des charges : quelles ressources sont réellement attribuées au site, quelles limites provoquent un ralentissement ou une erreur, quelle disponibilité est contractuelle, quelles données sont sauvegardées, qui intervient lors d’un incident et à quelles conditions la sortie ou l’arrivée chez l’hébergeur est possible.

Ce niveau de lecture est indispensable parce que WordPress n’est pas une application isolée. Son fonctionnement dépend notamment de PHP, d’une base de données, d’HTTPS, du serveur web, du cache, des extensions et des tâches planifiées. WordPress.org recommande actuellement PHP 8.3 ou une version plus récente, MariaDB 10.11 ou une version plus récente, ou MySQL 8.0 ou une version plus récente, ainsi que HTTPS ; le projet indique aussi qu’Apache ou Nginx sont des choix robustes pour l’exécuter.

L’objectif n’est donc pas de trouver l’offre qui affiche le plus de superlatifs, mais celle dont les limites, les responsabilités et les procédures correspondent à votre site. Un blog peu fréquenté, une boutique avec commandes en continu, un site d’adhésion, un multisite ou un média soumis à des pics de trafic n’ont pas le même profil de risque. Voici une méthode pour transformer une page tarifaire en comparaison technique défendable.

Commencer par séparer les promesses des engagements

Une page commerciale mélange souvent des caractéristiques, des options et des engagements. Une caractéristique est par exemple la présence d’un environnement de préproduction. Une option est une sauvegarde horaire facturée en supplément. Un engagement est une condition documentée : disponibilité calculée sur une période donnée, délai de réponse annoncé, durée de conservation des sauvegardes ou crédit applicable en cas de manquement.

Le réflexe à adopter est simple : pour chaque promesse, rechercher la page de documentation, les conditions de service et, si nécessaire, poser la question au support avant achat. L’absence d’information n’est pas une preuve que la fonction n’existe pas ; elle signifie en revanche que vous ne pouvez pas l’intégrer comme un engagement dans votre comparaison. Demandez une réponse écrite lorsqu’un point est déterminant pour votre activité.

Les formulations suivantes exigent particulièrement une vérification. Une offre peut annoncer des migrations gratuites et illimitées, comme le fait Kinsta pour des installations WordPress standard, mais une migration reste soumise à un périmètre. Sa documentation indique notamment que WordPress.com ne permet pas une migration traditionnelle faute d’accès aux fichiers et à la base de données, et que les migrations prises en charge sont des migrations directes à périmètre équivalent pour les installations multisites.

De même, la mention de sauvegardes quotidiennes ne répond pas à elle seule aux questions opérationnelles : conservation, restauration, emplacement de stockage, contenu de la sauvegarde, délai de remise en service et possibilité de tester la restauration. Chez Kinsta, par exemple, les sauvegardes quotidiennes sont documentées, mais la conservation varie selon le forfait, avec quatorze ou trente jours selon les plans cités dans sa documentation.

CPU et RAM : demander la capacité réellement utilisable

Le CPU et la mémoire vive déterminent la marge disponible lors du traitement PHP, des requêtes vers la base de données, des tâches WordPress Cron, des importations, des sauvegardes ou des pics de connexions non servies par le cache. Pourtant, dans l’hébergement mutualisé, le mot ressources peut recouvrir des plafonds très différents : fraction de cœur, nombre de cœurs, puissance CPU exprimée en pourcentage, mémoire physique, mémoire virtuelle, nombre de processus ou nombre de requêtes dynamiques simultanées.

La documentation CloudLinux illustre précisément ce point. Sa limite SPEED exprime une puissance CPU en pourcentage d’un cœur : 100 % correspond à un cœur et 150 % à un cœur et demi. Sa limite PMEM correspond à la mémoire physique utilisable par les processus de l’environnement isolé. L’éditeur distingue aussi le nombre total de processus, NPROC, et les entry processes, ou EP, qui représentent généralement les connexions simultanées vers des scripts dynamiques ainsi que les sessions SSH et les tâches cron.

Une offre qui indique seulement ressources généreuses, performance optimisée ou CPU puissant n’est donc pas comparable à une autre. Demandez au minimum : le nombre de vCPU ou l’équivalent SPEED garanti, la RAM physique par site ou par conteneur, le caractère dédié ou mutualisé de ces ressources, la durée pendant laquelle un éventuel pic est accepté, les limites EP et NPROC, ainsi que la méthode de consultation de la consommation. S’il existe un tableau de ressources dans le panneau client, demandez une capture ou une documentation de ses métriques et de ses alertes.

Il faut également distinguer le plafond de l’allocation et la performance observée. Deux plans annonçant deux vCPU ne garantissent pas nécessairement le même comportement, car le modèle de processeur, le niveau de contention, les limites de base de données, le cache et les politiques de throttling ne sont pas décrits par ce seul chiffre. La bonne question n’est pas seulement combien de CPU, mais aussi que se passe-t-il exactement une fois le seuil atteint.

À demander au commercial : quelle ressource est garantie par site, quelle ressource est mutualisée, quel seuil déclenche une limitation, quel symptôme voit le visiteur et quelles données de suivi seront accessibles au client ?

Cette dernière question a une conséquence directe sur l’exploitation. Selon CloudLinux, atteindre une limite CPU ou I/O ralentit la réponse du site ; atteindre une limite de mémoire ou de processus peut provoquer des erreurs 500 ou 503. Lorsque la limite EP est atteinte, le mécanisme décrit par l’éditeur peut renvoyer une erreur 508. Une offre sérieuse doit donc permettre d’identifier la limite touchée plutôt que de renvoyer le client vers une explication vague de surcharge.

I/O, IOPS et stockage : ne pas confondre NVMe et débit disponible

Le type de disque est devenu un argument marketing courant. Il est utile, mais insuffisant. Un stockage NVMe ne révèle ni le débit attribué à votre compte, ni le nombre d’opérations autorisées, ni le comportement du système lorsque les seuils sont atteints. Or un WordPress réalise des lectures et écritures lors de l’accès aux médias, aux fichiers de cache, aux journaux, aux sauvegardes, aux mises à jour ou à certaines opérations de base de données.

CloudLinux différencie l’I/O, c’est-à-dire le débit de lecture et d’écriture exprimé en kilo-octets par seconde, et les IOPS, qui limitent le nombre total d’opérations de lecture ou d’écriture par seconde. Sa documentation précise que le dépassement de la limite I/O ralentit les processus concernés, tandis que le dépassement de la limite IOPS suspend les opérations de lecture et d’écriture jusqu’au changement de seconde.

Avant de comparer deux offres, notez donc séparément le volume de stockage, le type de stockage, le débit I/O, les IOPS, le nombre d’inodes et la politique appliquée aux sauvegardes. Les inodes comptent les fichiers et dossiers ; ils peuvent devenir une limite concrète pour un site qui accumule images, caches, archives d’extensions ou copies de sauvegarde. CloudLinux documente les limites d’inodes comme des limites de quota de système de fichiers.

Une formulation telle que stockage SSD ou stockage NVMe doit être traitée comme une information matérielle partielle. Vérifiez derrière elle les limites par compte, les éventuels frais de dépassement, la capacité réellement disponible après les sauvegardes, et l’existence d’un quota d’inodes. Une offre qui publie ces valeurs permet une comparaison ; une offre qui ne communique que le nom de la technologie de disque ne permet pas d’estimer les performances lors d’une opération intensive.

SLA : mesurer la promesse de disponibilité et son recours

Un SLA, ou accord de niveau de service, n’est pas synonyme de disponibilité réelle. C’est un mécanisme contractuel qui définit une mesure, des exclusions, une période de calcul, une procédure de réclamation et généralement un avoir. Il faut donc lire la définition de l’indisponibilité avant de comparer les pourcentages affichés.

L’accord de niveau de service d’Amazon EC2 fournit un exemple clair de cette différence. Pour des instances déployées simultanément dans au moins deux zones de disponibilité d’une même région, AWS annonce un objectif mensuel de 99,99 %. Pour une instance EC2 unique, l’objectif indiqué est de 99,5 %. Le document définit le pourcentage mensuel de disponibilité à partir des minutes d’indisponibilité et prévoit des crédits de service selon des seuils.

Ce document ne permet pas d’évaluer un hébergeur WordPress tiers, mais il montre pourquoi un chiffre seul est trompeur. Un SLA peut concerner l’infrastructure sous-jacente et non votre application WordPress, exclure les maintenances planifiées, les erreurs de configuration, les incidents liés à une extension, les services tiers, les attaques ou les actions du client. Il peut aussi couvrir un compte entier, une région, un serveur ou seulement une composante précise.

Pour chaque candidat, vérifiez cinq éléments : le périmètre couvert, la formule de calcul, les exclusions, le crédit prévu et le délai de réclamation. Demandez aussi si l’hébergeur supervise le simple fait que le serveur répond, ou la disponibilité HTTP du site, et si cette surveillance porte sur l’URL publique. Un crédit de quelques pourcents de la mensualité ne compense pas forcément le coût commercial d’une boutique inaccessible : le SLA est un filet contractuel, pas un plan de continuité.

Sauvegardes : fréquence, rétention, restauration et copie externe

Une sauvegarde fiable se définit par quatre propriétés : la fréquence, la durée de conservation, le contenu et la capacité de restauration. La fréquence mesure le point de récupération potentiel. La conservation détermine jusqu’à quand vous pouvez revenir en arrière. Le contenu précise si fichiers, base de données, réglages et éléments spécifiques sont inclus. La restauration indique si l’opération peut être effectuée sur la production, sur un environnement de test, et avec quel impact.

La documentation de Kinsta précise que ses sauvegardes WordPress quotidiennes constituent un instantané comprenant les fichiers, la base de données, les redirections, la configuration Nginx et les réglages MyKinsta. Elle indique aussi qu’une restauration fait revenir ces éléments à l’état du point de sauvegarde choisi. Cette précision est plus utile que la seule formule sauvegardes quotidiennes, car elle définit ce qui revient réellement en arrière.

Vérifiez ensuite l’emplacement. Chez Kinsta, la documentation indique que les sauvegardes sont stockées sur la même machine hôte que le site, tandis qu’une option de sauvegarde externe vers Amazon S3 ou Google Cloud Storage est proposée selon une fréquence hebdomadaire ou mensuelle. Il ne s’agit pas d’un jugement général sur cette architecture, mais d’un rappel méthodologique : demandez toujours si une copie est séparée de l’environnement de production et quelle partie de cette protection est incluse.

Testez enfin le processus avant d’en avoir besoin. WordPress.org recommande de disposer d’une sauvegarde courante avant une mise à jour et rappelle qu’un problème après mise à niveau peut nécessiter une restauration. Dans votre grille, attribuez une valeur supérieure à un hébergeur qui permet de restaurer rapidement vers un environnement de préproduction, documente les conséquences de la restauration et offre une exportation exploitable indépendamment de son panneau.

Sécurité et infogérance : définir ce que le prestataire prend réellement en charge

Hébergement managé, sécurité renforcée et mises à jour automatiques sont des expressions qui ne disent pas, à elles seules, qui agit et sur quel périmètre. L’infogérance de l’infrastructure peut couvrir les correctifs du système d’exploitation, le pare-feu applicatif, les certificats TLS, la surveillance, les sauvegardes et la remédiation d’incidents. Elle ne signifie pas automatiquement qu’un prestataire corrigera le code d’un thème, réglera une incompatibilité entre extensions ou validera chaque mise à jour fonctionnelle.

WordPress.org rappelle que maintenir WordPress, les extensions et les thèmes à jour est l’action la plus importante pour la sécurité, et conseille de choisir des thèmes et extensions activement maintenus. Les mises à jour automatiques d’extensions et de thèmes peuvent être activées par l’administrateur depuis WordPress ; WordPress indique également que ces mises à jour reposent sur les tâches Cron et peuvent être neutralisées par l’hébergeur ou une extension.

Il faut donc demander : les correctifs système sont-ils gérés par l’hébergeur, les mises à jour du cœur WordPress sont-elles gérées, les extensions sont-elles mises à jour automatiquement ou sur demande, une sauvegarde est-elle créée avant l’opération, un contrôle fonctionnel est-il réalisé, et quelle est la procédure de retour arrière ? Chez Kinsta, le périmètre de support documenté comprend notamment l’aide sur les sauvegardes, les environnements de test, les redirections, les changements de version PHP et l’investigation des erreurs serveur ; cela ne doit pas être extrapolé à une prise en charge illimitée du développement applicatif.

La sécurité doit aussi être séparée en couches : isolation des comptes, contrôle des accès, SFTP ou SSH, certificats, pare-feu applicatif, protection contre les attaques par déni de service, analyse de logiciels malveillants, journalisation et réponse après compromission. Une promesse de nettoyage après piratage vaut moins qu’une politique qui précise les conditions, les exclusions, les délais et les actions couvertes. Ne supposez pas qu’une protection d’infrastructure élimine le risque issu d’une extension vulnérable ou d’un mot de passe réutilisé.

Staging, support et migration : les détails qui évitent les incidents évitables

Un environnement de test, souvent appelé staging, doit être séparé de la production et ne doit pas être confondu avec une simple copie ponctuelle. Kinsta décrit son environnement de staging gratuit comme séparé du site de production et destiné aux essais de versions WordPress, d’extensions, de code et au développement. Sa documentation précise aussi que le staging n’est pas conçu pour héberger un site de production et peut être mis en veille après vingt-quatre heures d’inactivité.

Pour le comparer, demandez si l’environnement reproduit la version PHP, les règles de cache, les variables d’environnement et les ressources de production ; s’il est protégé contre l’indexation ; s’il permet de cloner ou restaurer une sauvegarde ; et si le déploiement vers la production inclut une sauvegarde préalable. Un staging qui ne reflète pas les contraintes importantes de production est utile pour des tests de contenu, mais moins probant pour valider une mise à jour technique.

Le support doit être évalué selon ses canaux, ses horaires, ses temps de réponse et son périmètre. WP Engine indique proposer une assistance permanente via chat, téléphone et tickets. Ce type de promesse doit être complété par vos questions : quel canal est disponible sur le forfait visé, le support intervient-il sur un incident applicatif, dispose-t-il d’accès aux journaux nécessaires, et existe-t-il un délai de première réponse contractuel ou seulement un objectif interne ? Une disponibilité permanente du canal ne garantit pas à elle seule la résolution immédiate.

Enfin, une migration doit être préparée comme un changement de production. Kinsta indique que les sites à mises à jour continues, notamment les boutiques ou sites d’adhésion, peuvent nécessiter une fenêtre planifiée et un mode maintenance afin d’éviter les pertes de données. Vérifiez donc ce qui est inclus : audit préalable, copie initiale, test sur URL temporaire, synchronisation finale de la base de données, bascule DNS, fenêtre d’intervention, responsabilité du contrôle post-bascule et plan de retour arrière. Demandez explicitement si les e-mails, tâches cron, DNS, redirections, certificats et intégrations de paiement font partie du périmètre.

Une méthode de scoring simple pour choisir entre deux hébergeurs

Pour départager deux offres, attribuez une note de zéro à cinq à chaque critère, puis appliquez une pondération adaptée à votre activité. Le but n’est pas de produire une vérité universelle : il est de rendre visible un compromis qui resterait autrement caché derrière le prix mensuel.

• Ressources et limites : 25 points. CPU réellement attribué, RAM, EP, NPROC, I/O, IOPS, inodes, visibilité sur la consommation et comportement au dépassement.
• Sauvegardes et reprise : 20 points. Fréquence, conservation, contenu, copie externe, restauration testable et délai de récupération.
• Sécurité et infogérance : 15 points. Correctifs d’infrastructure, isolation, accès sécurisés, protections documentées, responsabilités sur les mises à jour et procédure de remédiation.
• Disponibilité et exploitation : 15 points. SLA lisible, exclusions, crédits, supervision, journaux et transparence sur les incidents.
• Staging et déploiement : 10 points. Séparation de la production, fidélité de l’environnement, clonage, restauration et procédure de mise en ligne.
• Support et migration : 10 points. Canaux, horaires, niveau d’expertise, périmètre documenté, migration, bascule et retour arrière.
• Prix et réversibilité : 5 points. Coût au renouvellement, suppléments, frais de dépassement, export des données et absence de dépendance inutile au prestataire.

Multipliez la note de chaque axe par sa pondération, puis additionnez les résultats pour obtenir une note sur 100. Mais ajoutez une règle éliminatoire : une offre ne doit pas être retenue si elle échoue sur une exigence indispensable, même si sa note globale est élevée. Pour une boutique, une sauvegarde restaurable et une procédure de migration sans perte de commandes peuvent être non négociables. Pour un site éditorial, la transparence sur les ressources et le support lors des pics peuvent peser davantage.

La meilleure offre WordPress n’est donc pas forcément celle qui promet le plus. C’est celle qui décrit le plus clairement ses ressources, ses limites, ses responsabilités et ses procédures, puis qui accepte de les confirmer avant signature. En matière d’hébergement, une information technique vérifiable vaut davantage qu’un adjectif rassurant.