Alternatives à WP Engine, Kinsta, SiteGround ou Cloudways : comment choisir votre prochain hébergeur WordPress

Ce guide aide les propriétaires de sites WordPress et les agences à décider où aller après un hébergeur WordPress infogéré comme WP Engine, Kinsta, SiteGround ou Cloudways. Peut-être que la facture mensuelle ne cesse de grimper ou qu’une extension dont vous avez besoin est interdite. Ou encore, vous voulez un accès SSH (le terminal distant sécurisé) que votre forfait n’offre pas. Une liste d’hébergeurs de rechange ne peut pas vous dire quel type d’hébergement règle votre problème à vous. La réponse est une méthode courte. Notez pourquoi vous partez, associez chaque raison à la catégorie d’hébergement qui la règle, mesurez votre site et testez une copie chez le nouvel hébergeur avant de toucher au DNS. À la fin, vous aurez une fiche de besoins écrite, une copie de préproduction testée et des mesures de vitesse à comparer côte à côte.

Ce que vous allez accomplir

Une liste écrite des raisons de votre départ, chacune appuyée sur une preuve concrète, comme une ligne de facture ou une réponse du soutien technique.
Chaque raison associée au type d’hébergement qui la règle habituellement, pour cibler la bonne catégorie avant de comparer les fournisseurs.
De vraies mesures de votre site : taille de la base de données, taille des téléversements, extensions actives, version de PHP et trafic de pointe.
Une copie d’essai chez l’hébergeur candidat, avec un TTFB (délai avant le premier octet, soit le temps que prend le serveur pour commencer à répondre) comparé à celui de votre hébergeur actuel.
Une prochaine étape claire : le guide de migration qui correspond à l’hébergeur que vous quittez.

Prérequis

Il vous faut l’accès au tableau de bord de votre hébergeur actuel et, idéalement, un accès SSH avec WP-CLI, l’outil officiel de ligne de commande de WordPress. La plupart des hébergeurs WordPress infogérés offrent le SSH sur au moins certains forfaits. Lancez wp --info une fois connecté ; s’il affiche une version de WP-CLI, vous êtes prêt. La référence complète des commandes se trouve sur developer.wordpress.org/cli/commands.

Il vous faut aussi curl et dig, fournis avec macOS et la plupart des systèmes Linux, ainsi qu’un compte chez au moins un hébergeur candidat pour la migration d’essai.

Les forfaits, les limites et les fonctions incluses changent souvent et varient d’un fournisseur à l’autre. Ce guide n’en cite aucun. Chaque fois qu’une limite compte, vérifiez la page de votre forfait actuel et celle du forfait candidat, puis notez la réponse.

Les quatre fournisseurs nommés ici sont de bons produits qui conviennent très bien à bien des sites. Ils sont aussi différents les uns des autres. Certains sont des plateformes WordPress infogérées, d’autres de l’hébergement mutualisé ou infonuagique avec des outils WordPress par-dessus. Leur point commun, c’est que le fournisseur décide d’une bonne partie de la pile pour vous. Partir est généralement une question d’adéquation, pas d’échec.

Comment ça fonctionne

L’hébergement WordPress se divise en quatre grandes catégories. Chacune partage le travail entre vous et le fournisseur d’une façon différente.

Une autre plateforme WordPress infogérée. Le fournisseur gère le serveur, la mise en cache, les sauvegardes et les mises à jour du cœur. Vous gardez le même modèle clés en main, avec un autre fournisseur. C’est le bon choix si le modèle vous plaît, mais pas le forfait, le soutien ou la performance que vous obtenez aujourd’hui.

Un compte cPanel ou un VPS cPanel. cPanel est un panneau de contrôle qui sert à gérer les sites, les bases de données et le courriel sur un serveur. Un VPS (serveur privé virtuel) est une portion d’un serveur physique qui vous est réservée. C’est vous ou un hébergeur qui l’exploite. Vous obtenez l’accès aux fichiers, les tâches cron (tâches planifiées), les réglages PHP et les boîtes courriel au même endroit, avec moins de règles imposées par la plateforme.

Un serveur infonuagique avec un panneau de contrôle. Vous louez une machine virtuelle chez un fournisseur infonuagique et vous y ajoutez un panneau pour la gérer. Vous obtenez l’accès root, c’est-à-dire le contrôle administrateur complet, et vous dimensionnez le serveur vous-même. C’est aussi vous qui appliquez les correctifs, à moins que quelqu’un s’en charge pour vous.

Un fournisseur d’opérations infogérées sur votre propre infrastructure. Une entreprise exploite le serveur pour vous, mais le serveur ou le compte infonuagique vous appartient. C’est le bon choix si vous voulez la liberté au niveau du serveur et quelqu’un d’autre responsable des mises à jour, de la surveillance et des incidents.

Le schéma ci-dessous associe les raisons de départ les plus courantes à la catégorie qui règle habituellement chacune.

Tableau qui associe six raisons courantes de quitter un hébergeur WordPress infogéré, comme une facture qui grimpe, des extensions bloquées, l'absence de SSH, l'absence de courriel, la portée du soutien et des pages lentes, au type d'hébergement qui règle habituellement chacune

L’essentiel, c’est que des raisons différentes mènent à des catégories différentes. Si votre seule plainte porte sur le délai de réponse du soutien, un serveur infonuagique que vous entretenez vous-même empirera les choses. Si vous avez besoin d’une extension que votre plateforme interdit, une autre plateforme aux règles semblables ne vous aidera pas. La méthode ci-dessous vous évite d’échanger une mauvaise adéquation contre une autre.

Démarche en cinq étapes pour choisir un nouvel hébergeur WordPress : noter pourquoi vous partez, associer chaque raison, mesurer le site, tester une copie de préproduction, puis migrer avec un guide

Étape par étape

Notez pourquoi vous partez. Ouvrez un fichier texte et écrivez chaque raison en une phrase simple. À côté de chacune, notez la preuve. Les raisons courantes se regroupent en six familles :
- Une facture qui grimpe avec le trafic. Votre forfait compte les visites ou la bande passante, et les frais de dépassement ou les mises à niveau forcées reviennent sans cesse. Preuve : les lignes de facture.
- Une extension nécessaire est interdite. Certaines plateformes bloquent les extensions qui font double emploi avec leur propre mise en cache, leurs sauvegardes ou leur sécurité. WP Engine, par exemple, publie une liste d’extensions interdites. Preuve : l’entrée de la liste ou la réponse du soutien.
- Aucun accès au niveau du serveur. Vous avez besoin du SSH, de l’accès root, d’une extension PHP ou d’un réglage serveur particulier, et le forfait ne le permet pas. Preuve : la fonction demandée et la réponse reçue.
- Le courriel n’est pas inclus. Bien des plateformes WordPress infogérées n’hébergent pas de boîtes courriel, donc le courriel vit chez un autre fournisseur. Ça convient à certaines équipes, alors que pour d’autres c’est une facture et une connexion de plus.
- La portée du soutien. Le soutien d’une plateforme couvre habituellement la plateforme, pas votre thème, vos extensions ni votre code personnalisé. Si vous avez besoin de quelqu’un pour régler ces éléments, c’est un autre service.
- La performance sous votre vrai trafic. Les pages sont lentes pour les utilisateurs connectés, au paiement de la boutique ou aux heures de pointe. Preuve : les mesures de TTFB que vous recueillerez à l’étape 7.
Ne gardez que les raisons que vous pouvez appuyer sur une preuve.
Associez chaque raison à une catégorie. Servez-vous du schéma des raisons ci-dessus. Écrivez la catégorie correspondante à côté de chaque ligne. Si la plupart des lignes mènent à une même catégorie, voilà votre liste restreinte. Si elles partent dans des directions différentes, classez les raisons selon ce qui vous coûte le plus, en argent ou en heures, et laissez les deux premières trancher.
Mesurez le site. Connectez-vous en SSH, placez-vous dans le dossier WordPress et lancez ces commandes une à la fois :
```
wp core version
wp eval 'echo PHP_VERSION . PHP_EOL;'
wp db size --human-readable
wp plugin list --status=active --format=count
du -sh wp-content/uploads
```
Vous devriez voir une version de WordPress comme 6.8.2, puis une version de PHP comme 8.2.28. Vient ensuite un petit tableau avec le nom de votre base de données et sa taille, par exemple 412 MB. Puis un seul nombre pour les extensions actives, et enfin une ligne comme 4.1G wp-content/uploads. Inscrivez chaque valeur dans votre fiche de besoins. Si wp est introuvable, votre forfait n’inclut peut-être pas WP-CLI ; le tableau de bord de votre hébergeur affiche alors habituellement la version de PHP et l’espace disque utilisé.
Sauvegardez la liste des extensions actives. Un nouvel hébergeur doit toutes les faire tourner, alors gardez la liste complète :
```
wp plugin list --status=active --fields=name,version > active-plugins.txt
wc -l active-plugins.txt
```
La deuxième commande affiche un nombre de lignes, soit une de plus que votre nombre d’extensions à cause de la ligne d’en-tête. Vérifiez chaque extension selon les règles de l’hébergeur candidat. Repérez aussi les extensions de cache ou de sauvegarde qui n’existent qu’à cause de votre plateforme actuelle. Elles peuvent devenir inutiles, ou entrer en conflit avec le cache du nouvel hébergeur.
Estimez la quantité de travail PHP simultané. Les pages servies depuis le cache ne coûtent presque rien. Les pages qui font tourner PHP, comme le panier, le paiement, l’administration et les pages des utilisateurs connectés, occupent chacune un processus PHP jusqu’à ce qu’elles aient fini. Certains hébergeurs les appellent des « PHP workers ». Téléchargez un journal d’accès brut depuis le tableau de bord de votre hébergeur et trouvez vos minutes les plus achalandées. La partie grep écarte les requêtes d’images, de feuilles de style et de scripts, qui ne font jamais tourner PHP :
```
grep -vE '\.(css|js|png|jpe?g|gif|svg|webp|woff2?|ico)' access.log | awk '{print $4}' | cut -d: -f1-3 | sort | uniq -c | sort -rn | head -5
```
Chaque ligne affiche un nombre de requêtes et une minute, par exemple 1843 [22/Sep/2026:14:05. Divisez le nombre le plus élevé par 60 pour obtenir les requêtes par seconde. Une partie de ces pages venait quand même du cache, alors traitez ce nombre comme un plafond. Appliquez ensuite cette règle : les requêtes non mises en cache par seconde, multipliées par le temps de réponse PHP moyen en secondes, donnent le nombre de processus PHP occupés au même moment. Par exemple, 6 requêtes non mises en cache par seconde à 0,5 seconde chacune occupent environ 3 processus. Prévoyez au moins le double, pour qu’une pointe ne crée pas de file d’attente. Si votre format de journal diffère et que le résultat semble faux, demandez plutôt à votre hébergeur actuel votre utilisation PHP simultanée de pointe.
Vérifiez où vivent le courriel et le DNS. Changer d’hébergement ne doit pas briser le courriel. Lancez :
```
dig +short MX example.com
dig +short NS example.com
```
La première commande liste vos serveurs de courriel, par exemple 10 mx1.example-mail.com.. La deuxième liste les serveurs de noms qui contrôlent votre DNS. Notez les deux. Si les enregistrements MX pointent vers un service de courriel distinct, le courriel reste où il est. Si vous voulez des boîtes courriel chez le nouvel hébergeur, ajoutez-le à la fiche de besoins comme ligne distincte.
Faites une migration d’essai et comparez le TTFB. Copiez le site chez l’hébergeur candidat sans modifier le DNS, en suivant le guide propre à votre hébergeur actuel, listé à la dernière étape. Mesurez ensuite les deux hébergeurs depuis le même ordinateur. D’abord le site actuel :
```
for i in 1 2 3 4 5; do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; done
```
Puis la copie sur le nouveau serveur, en remplaçant 203.0.113.10 par son adresse IP. L’option --resolve envoie la requête là-bas tout en gardant votre vrai nom de domaine :
```
for i in 1 2 3 4 5; do curl -o /dev/null -s -w '%{time_starttransfer}\n' --resolve example.com:443:203.0.113.10 https://example.com/; done
```
Chaque commande affiche cinq nombres en secondes, comme 0.184. Ignorez le premier, qui inclut souvent un cache froid, et comparez les quatre autres. Refaites les deux tests sur une page qui ne peut pas être mise en cache, comme votre panier ou une adresse de résultats de recherche comme https://example.com/?s=test. Ce deuxième nombre montre la vraie vitesse de PHP et de la base de données. Si le nouvel hébergeur exige un certificat valide pour le test, la plupart peuvent en émettre un pour un domaine temporaire ; testez alors ce domaine.
Migrez avec le guide correspondant. Une fois que la copie a passé vos vérifications, suivez le guide complet pour l’hébergeur que vous quittez. Chacun couvre les restes propres à la plateforme, l’exportation de la base de données et une bascule DNS sûre :
Les étapes d’exportation et de nettoyage s’appliquent même si votre destination n’est pas cPanel.

Valider que ça fonctionne

Votre décision est solide quand trois conditions sont réunies. Chaque raison de l’étape 1 a une catégorie à côté d’elle. Chaque mesure des étapes 3 à 6 entre dans le forfait candidat. La copie d’essai est au moins aussi rapide que l’hébergeur actuel, sur la page en cache comme sur la page non mise en cache.

Après le vrai déménagement, confirmez le site en production avec les mêmes vérifications :

wp core version
wp plugin list --status=active --format=count
curl -o /dev/null -s -w '%{http_code} %{time_starttransfer}\n' https://example.com/

Les deux premières doivent correspondre aux nombres notés à l’étape 3. La dernière doit afficher 200 suivi d’un TTFB proche de celui mesuré sur la copie d’essai. Envoyez aussi un courriel de test vers votre domaine et depuis celui-ci, et passez une commande de test si vous avez une boutique.

Dépannage

La copie d’essai est plus lente que l’hébergeur actuel. Vérifiez si la mise en cache des pages est activée chez le nouvel hébergeur. Une copie fraîche démarre souvent avec le cache désactivé, ou avec l’extension de cache de l’ancienne plateforme encore active qui ne fait rien. Comparez aussi le nombre non mis en cache. Si seul le test en cache est plus lent, il faut configurer le cache. Si le test non mis en cache est plus lent, le serveur est sous-dimensionné pour le travail PHP estimé à l’étape 5.

curl --resolve renvoie une erreur de certificat. Le nouveau serveur n’a pas encore de certificat pour votre vrai domaine. Utilisez le domaine temporaire fourni par l’hébergeur, ou ajoutez -k pour sauter la vérification pendant ce test seulement. Ne laissez jamais -k dans un script de surveillance.

wp db size indique bien moins que prévu. La commande mesure seulement la base de données qu’utilise WordPress. D’anciens sites de préproduction ou des tables laissées par une ancienne extension peuvent vivre dans la même base avec un autre préfixe de table. Lancez wp db tables --all-tables | wc -l pour voir combien de tables existent vraiment.

Une extension cesse de fonctionner après la copie. Elle attend peut-être une fonction propre à l’ancienne plateforme que le nouvel hébergeur ne fournit pas. C’est souvent un cache d’objets, soit une mémoire qui garde les résultats de la base de données. Les guides ci-dessus listent les restes habituels de chaque plateforme, y compris les fichiers object-cache.php.

La commande sur le journal d’accès n’affiche rien d’utile. Votre hébergeur utilise peut-être un autre format de journal, où l’heure n’est pas dans le quatrième champ. Ouvrez la première ligne du journal, repérez l’horodatage et remplacez $4 par la position de ce champ.

Quand ce n’est pas la bonne approche

Si votre seule plainte porte sur une extension ou une limite, parlez d’abord à votre hébergeur actuel. Les forfaits changent, et un changement de forfait ou une exception du soutien peut coûter bien moins cher qu’une migration.

Personne dans votre équipe ne veut s’occuper des mises à jour, de la sécurité et des sauvegardes ? Évitez alors un serveur que vous gérez vous-même, même s’il semble moins cher. Restez sur une plateforme infogérée ou confiez le serveur à un fournisseur qui l’exploite. Infogérance WordPress ou serveur auto-géré détaille ce partage du travail et du risque.

Un très gros site qui a besoin de plusieurs serveurs ou d’une grappe de recherche distincte dépasse cette méthode. Traitez-le d’abord comme un projet d’architecture.

Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.