50 sites. Pas le même sujet que 5. À cette échelle, l’hébergement n’est plus un détail budgétaire. C’est une décision d’architecture. Un mauvais choix se paie en lenteurs, en failles, en nuits à gérer des crashs. Voici ce qu’il faut savoir.
Quel est le meilleur setup pour héberger 50 sites ?
La réponse courte : un Serveur VPS bien dimensionné, ou un dédié si les sites génèrent du trafic réel.
8 Go de RAM minimum. 4 vCPU. SSD NVMe. En dessous, ça coincera. Pas tout de suite. Mais ça coincera.
Ce que la plupart des guides ne disent pas, le vrai goulot d’étranglement sur 50 sites WordPress, c’est rarement le CPU. C’est la RAM. Un WordPress sans cache bien configuré consomme facilement 80 à 150 Mo par processus PHP. Multipliez. Comptez le nombre de requêtes simultanées. Les chiffres parlent d’eux-mêmes.
Hébergement mutualisé, VPS, dédié : quelle option ?
Mutualisé : non. Pas à cette échelle. Même les offres « illimitées » ont des limites réelles dans les CGU. Inode counts, CPU throttling, mémoire partagée. Ça tient pour 3 sites perso. Pas pour 50 sites clients.
VPS : oui, pour la grande majorité des cas. Ressources isolées, environnement virtualisé, évolutif. Un freelance SEO qui gère 50 sites vitrines avec un trafic combiné de 100 000 visites mensuelles sera parfaitement servi par un VPS 16 Go.
Dédié : dès que les projets deviennent hétérogènes. E-commerce, pics imprévisibles, sites sous WordPress avec WooCommerce et catalogue produit, hébergement de données sensibles. La machine entière pour vous. Pas de voisins. C’est là que ça compte vraiment.
Un point rarement mentionné : sur un VPS mutualisé de type hyperconvergé, les performances I/O disque peuvent fluctuer selon la charge des autres locataires sur le même nœud physique. C’est le phénomène dit du « noisy neighbor ». Pour un parc de 50 sites, privilégiez un hébergeur qui garantit des I/O dédiées ou qui isole les workloads.
Peut-on vraiment héberger 50 sites sur un VPS ?
Oui. Mais le diable est dans la configuration.
Un VPS 16 Go / 6 vCPU / NVMe tient 50 sites WordPress sans problème, à une condition : chaque site doit être configuré proprement. Cache full-page actif. PHP-FPM avec un pool dédié par domaine. Limite de workers PHP par site pour éviter qu’un site mal codé n’aspire toute la RAM disponible.
Ce dernier point est critique. Sans isolation des pools PHP-FPM, un seul site qui connaît un pic de trafic peut consommer 4 Go de RAM et ralentir les 49 autres. C’est le scénario le plus fréquent en gestion de parc multi-sites. Et c’est entièrement évitable avec deux lignes de configuration.
Autre angle mort : la base de données. 50 sites WordPress, c’est potentiellement 50 bases de données sur la même instance MySQL/MariaDB. Sans query cache et sans ajustement des paramètres innodb_buffer_pool_size, les performances se dégradent vite. Ce paramètre doit représenter environ 70 % de la RAM disponible pour MariaDB sur un serveur dédié à WordPress.
Le setup technique recommandé
Serveur : 16 Go RAM, 6 à 8 vCPU, NVMe 200 Go minimum.
Stack : NGINX + PHP-FPM 8.2+ + MariaDB 10.6+. Pas Apache. Sur 50 sites avec connexions concurrentes, NGINX gère le préfork sans bloquer. Apache en MPM prefork consomme un processus par connexion. Ce n’est pas la même chose.
Cache : Redis pour le cache objet WordPress, combiné à un plugin full-page cache (LiteSpeed Cache si le serveur tourne sous LiteSpeed, sinon WP Rocket ou NginxHelper). Redis évite les requêtes répétitives en base. Sur un parc de 50 sites, l’économie de requêtes SQL est massive.
Gestion multi-sites : MainWP ou GridPane. MainWP est gratuit et open source. GridPane est payant mais inclut des fonctionnalités avancées d’isolation et de sécurité spécifiques aux agences WordPress. Les deux permettent de centraliser mises à jour, sauvegardes et monitoring depuis un tableau de bord unique.
Ce que personne n’explique sur la gestion multi-sites : les sauvegardes des 50 sites ne doivent pas se déclencher simultanément. Un cron de backup qui lance 50 mysqldump en même temps à 3h du matin sature le disque et la RAM. Planifiez les sauvegardes en fenêtres décalées, 4 à 5 sites par tranche de 15 minutes.
Performance : les bons réflexes
Cache full-page. Toujours.
CDN. Cloudflare suffit dans 95 % des cas et la version gratuite fait le travail pour des assets statiques. Pour des sites à fort trafic, Cloudflare Pro avec les règles de cache personnalisées change significativement les temps de réponse.
PHP 8.2 minimum. La différence de performances entre PHP 7.4 et PHP 8.2 sur WordPress est mesurable : entre 15 et 40 % selon les benchmarks Kinsta et Cloudways. Pourtant, une part non négligeable des parcs hébergés tourne encore sur PHP 8.0 ou 8.1.
Thèmes et plugins : élagage brutal. Un site WordPress avec 40 plugins actifs n’est pas un site WordPress géré, c’est un risque permanent. Sur un parc de 50 sites, un plugin vulnérable non mis à jour est une porte d’entrée pour compromettre l’infrastructure entière.
Sécurité : penser infrastructure, pas site par site
L’erreur classique : sécuriser chaque site individuellement. Firewall applicatif sur site A, plugin de sécurité sur site B, rien sur site C.
La bonne approche : sécurité au niveau serveur.
Chaque site est sous son propre système utilisateur. PHP-FPM avec des pools isolés, chacun tournant sous un user dédié. Un fichier compromis sur site A ne peut pas lire les fichiers de site B. C’est ce qu’on appelle l’isolation par utilisateur. Sans ça, une injection de code sur un site peut se propager horizontalement via les permissions fichiers.
SSL sur tous les domaines. Certbot en renouvellement automatique via cron. Pas négociable.
Fail2ban configuré pour bloquer les tentatives de brute force sur wp-login.php. Sur 50 sites exposés publiquement, les bots scannent en continu. Sans protection, les logs d’erreurs auth deviennent inutilisables et les tentatives de connexion génèrent une charge serveur inutile.
Sauvegardes déportées. Pas sur le même serveur. S3, Backblaze B2, ou un VPS secondaire dédié au stockage. Une sauvegarde locale ne protège de rien si le disque lâche ou si le serveur est compromis.
Combien ça coûte vraiment ?
VPS 16 Go / 6 vCPU / NVMe : entre 40 et 80 €/mois selon l’hébergeur. Scaleway, Hetzner, OVHcloud et PlanetHoster sont dans cette fourchette. Hetzner est souvent cité comme le meilleur rapport prix/performance en Europe, mais les data centers sont exclusivement en Allemagne et en Finlande. Pour des données hébergées en France, PlanetHoster propose des configurations équivalentes avec infrastructure française.
Serveur Dédié entrée de gamme : 80 à 150 €/mois. Justifié dès que le trafic agrégé dépasse 200 000 visites mensuelles ou que les projets incluent de l’e-commerce.
Ce que les comparatifs oublient souvent : le coût réel inclut aussi les outils de gestion. Une licence GridPane coûte entre 30 et 100 $/mois selon le plan. MainWP de base est gratuit mais certaines extensions avancées sont payantes. À budgétiser dès le départ.
Recommandation finale selon votre profil
Freelance, 50 sites WordPress, trafic modéré : VPS 16 Go + NGINX + PHP-FPM + Redis + MainWP. Budget serveur : 50 à 70 €/mois. C’est cohérent, stable et gérable seul.
Agence, projets hétérogènes, clients e-commerce : serveur dédié + GridPane. La surcharge de gestion se justifie par la stabilité et l’isolation.
Fort trafic ou architecture critique : cloud scalable avec load balancer et base de données externalisée (RDS ou équivalent). Le coût monte mais la résilience aussi.
Dans tous les cas : choisissez un hébergeur qui documente ses limites réelles, pas seulement ses arguments marketing. Support réactif, infrastructure transparente, données en Europe. PlanetHoster répond à ces critères avec des solutions pensées pour un usage professionnel.
