« Quel VPS pour WordPress ? » est une question à laquelle on répond souvent par un chiffre sorti de nulle part. La vérité est plus simple : ce qui consomme des ressources sur un site WordPress, ce n'est pas le nombre de pages, c'est le nombre de visiteurs simultanés et la part de pages non mises en cache. Une vitrine de 200 pages avec 500 visites par jour demande beaucoup moins qu'une boutique de 30 produits avec 50 paniers actifs.
1. Avez-vous vraiment besoin d'un VPS ?
Commençons par la question honnête. Un VPS n'a d'intérêt que si vous êtes dans l'un de ces cas :
- Votre temps de réponse serveur dépasse 800 ms alors que le site est déjà optimisé.
- Vous vendez en ligne : panier, compte client et paiement ne peuvent pas être servis depuis un cache.
- Vous hébergez plusieurs sites et voulez les isoler.
- Vous avez besoin de choisir votre version de PHP, d'ajouter Redis, de lancer des tâches planifiées lourdes ou d'installer un outil qui n'est pas proposé en mutualisé.
Si aucun de ces points ne vous concerne, un hébergement web avec Plesk fera le travail pour moins cher et sans administration. Mieux vaut un mutualisé bien réglé qu'un VPS mal entretenu.
2. Quelle taille de VPS pour quel site
Les repères ci-dessous partent d'un WordPress correctement configuré, avec un cache de pages actif. Ils supposent un seul site par serveur ; pour plusieurs sites, additionnez.
| Votre site | Offre conseillée | Ressources | Pourquoi |
|---|---|---|---|
| Vitrine, blog, moins de 1 000 visites par jour | VPS NVMe L | 2 vCPU · 4 Go | Confortable avec Nginx, PHP-FPM et MariaDB sur la même machine. |
| Site professionnel, 1 000 à 5 000 visites par jour | VPS NVMe Pro | 4 vCPU · 8 Go | De la marge pour le cache objet Redis et les pics de trafic. |
| Boutique WooCommerce active | VPS NVMe Pro ou Business | 4 à 6 vCPU · 8 à 16 Go | Les pages de panier et de commande ne sont jamais mises en cache : chaque visiteur mobilise PHP et la base. |
| Plusieurs sites, agence, environnement de test | VPS NVMe Business | 6 vCPU · 16 Go | Plusieurs WordPress isolés, plus un site de préproduction. |
Trois précisions qui évitent de surpayer :
- Le disque compte autant que la RAM. Un stockage NVMe divise les temps d'accès à la base par rapport à un disque classique, et WordPress interroge la base à chaque page non mise en cache.
- La fréquence du processeur prime sur le nombre de cœurs. PHP traite une requête sur un seul cœur : mieux vaut 4 cœurs rapides que 12 cœurs lents.
- Prévoyez la croissance, pas le rêve. Vous pouvez monter d'offre sans réinstaller. Pour affiner, notre guide combien de vCPU et de RAM pour un VPS détaille le raisonnement.
3. Panel ou installation manuelle ?
Avec Plesk
Vous retrouvez l'interface du mutualisé : création des sites, bases de données, certificats SSL en un clic, sauvegardes planifiées, changement de version de PHP par site. C'est le choix logique si vous venez d'un hébergement mutualisé ou si vous gérez des sites pour des clients.
En contrepartie, le panel consomme lui-même de la mémoire : prévoyez 4 Go de RAM au minimum sur le serveur.
En ligne de commande
Nginx, PHP-FPM et MariaDB installés directement : plus léger, plus rapide, entièrement sous votre contrôle. C'est la configuration la plus performante à ressources égales.
Il faut être à l'aise en SSH. Notre guide installer WordPress sur un VPS déroule l'installation complète, du serveur web au certificat.
4. Les réglages qui changent vraiment quelque chose
- PHP 8.3 ou plus récent, la version recommandée par WordPress, avec OPcache activé. C'est le gain le plus immédiat.
- MariaDB 10.11 ou MySQL 8.0 au minimum, avec un
innodb_buffer_pool_sizeajusté à la mémoire disponible. - Un cache de pages côté serveur ou via une extension : il évite de régénérer le HTML à chaque visite.
- Un cache objet Redis dès que le site est dynamique. C'est souvent ce qui fait passer un temps de réponse de plusieurs centaines de millisecondes à moins de deux cents.
- La compression et le HTTP/2, activés par défaut dans une configuration Nginx moderne.
Les réglages fins sont détaillés dans notre guide optimiser PHP-FPM et le cache Nginx.
5. Sécurité et sauvegardes : votre responsabilité
C'est la contrepartie du contrôle. Sur un mutualisé, l'hébergeur s'occupe du système ; sur un VPS, c'est vous. Le minimum vital :
- Pare-feu ouvert uniquement sur les ports 22, 80 et 443, et connexion SSH par clé plutôt que par mot de passe.
- fail2ban, car
wp-login.phpest scanné en permanence par des robots. - Mises à jour automatiques de sécurité du système, et mises à jour régulières de WordPress, du thème et des extensions.
- Sauvegardes quotidiennes envoyées hors du serveur, et testées au moins une fois en restauration.
Nos guides sécuriser son serveur VPS et sauvegardes avec Borg couvrent l'essentiel. Côté réseau, la protection Anti-DDoS est incluse sur tous nos VPS.
6. Le coût réel
Un VPS coûte plus cher qu'un mutualisé à l'achat, mais beaucoup moins qu'un hébergement WordPress infogéré, dont les offres démarrent souvent autour de 25 à 30 € par mois pour un seul site. Le vrai coût supplémentaire d'un VPS n'est pas financier, il est en temps : comptez une heure par mois pour les mises à jour et la surveillance des sauvegardes.
Le calcul devient simple : si votre site génère du chiffre d'affaires, une heure par mois pour un temps de réponse divisé par trois est vite rentabilisée. S'il s'agit d'un blog personnel, restez sur du mutualisé et gardez votre temps.
Mesurez d'abord votre temps de réponse actuel avec la méthode de notre article WordPress lent : trouver la vraie cause. Si le serveur est bien le facteur limitant, partez sur un VPS NVMe L pour un site vitrine ou un VPS NVMe Pro pour une boutique, puis suivez notre guide de migration sans coupure.
À lire ensuite
Migrer WordPress vers un VPS sans coupure
Migrer un site WordPress d'un hébergement mutualisé vers un VPS sans interruption : préparation, transfert, test avant bascule, DNS, SSL et vérifications.
WordPress lent : les vraies causes
Diagnostiquez un WordPress lent : mesurer le TTFB, distinguer un problème de site d'un problème de serveur, et savoir quand changer d'hébergement.
Se connecter à un VPS Windows en Bureau à distance
Se connecter à son VPS Windows en Bureau à distance (RDP) depuis Windows, Mac, Linux, iPhone ou Android
Questions fréquentes
Combien de RAM faut-il pour un WordPress sur VPS ?
Quatre gigaoctets suffisent pour un site vitrine ou un blog avec un cache actif. Passez à 8 Go pour un site professionnel à fort trafic ou une boutique WooCommerce, et à 16 Go pour héberger plusieurs sites sur la même machine. Si vous installez Plesk, comptez 4 Go au minimum pour le panel et le site.
WordPress tourne-t-il mieux sur un VPS que sur un mutualisé ?
À configuration égale, oui, parce que les ressources ne sont pas partagées avec d'autres sites et que vous maîtrisez la version de PHP, le cache et la base de données. Mais un VPS mal configuré peut être plus lent qu'un bon mutualisé : le gain vient de la configuration, pas de la machine seule.
Faut-il un VPS pour une boutique WooCommerce ?
C'est fortement conseillé dès que la boutique reçoit des commandes régulières. Les pages de panier, de compte et de paiement ne peuvent pas être mises en cache : chaque visiteur consomme du processeur et des requêtes en base, exactement ce que les hébergements mutualisés limitent.
Puis-je héberger plusieurs sites WordPress sur un seul VPS ?
Oui. Avec Plesk ou avec plusieurs blocs serveur Nginx, un VPS de 8 à 16 Go héberge sans difficulté plusieurs sites de taille modeste. Surveillez la mémoire totale et gardez les bases de données séparées, un site par base et par utilisateur.
Quelle version de PHP utiliser pour WordPress ?
WordPress recommande PHP 8.3 ou une version plus récente. Vérifiez la compatibilité de votre thème et de vos extensions avant de basculer, et faites une sauvegarde. Si vous migrez depuis un autre hébergement, gardez d'abord la version actuelle, puis montez une fois le site stable.
Le VPS inclut-il les sauvegardes de mon site ?
Les sauvegardes du contenu de votre serveur relèvent de votre responsabilité : c'est la contrepartie de l'accès root. Programmez un export quotidien de vos fichiers et de votre base, envoyé hors du serveur, et testez au moins une fois la restauration.










