Héberger plusieurs sites clients sur un seul VPS — sans frais par compte

Voici un chiffre qui surprend à la première estimation : un Hetzner CAX21 à 13 €/mois (4 vCPU, 8 Go de RAM) héberge confortablement une douzaine de sites WordPress de petites entreprises, avec encore de la marge. Le matériel pour faire tourner de nombreux sites sur une seule machine est bon marché depuis des années. Alors pourquoi héberger cinq clients coûte-t-il si souvent cinq fois plus cher ?

La réponse tient à la licence, pas à la puissance de calcul. cPanel, Plesk et la plupart des plateformes infogérées facturent par compte — chaque client ajouté alourdit votre facture, que le serveur travaille davantage ou non. Ce guide explique comment y échapper : faire tourner plusieurs sites clients sur un seul VPS en toute sécurité, ce que « en toute sécurité » exige réellement, et comment le faire sans payer une taxe sur chaque compte.

La taxe par compte, en chiffres réels

La facturation par compte semble anodine à deux clients. Elle s'aggrave à mesure que vous grandissez. Voici en gros ce que coûte la même poignée de sites selon les options courantes (tarifs affichés, mi-2026) :

Les chiffres exacts bougent avec les promotions et les paliers, mais la forme ne change jamais : la facturation par compte fait croître votre coût avec votre succès. Le 40ᵉ client vous coûte autant en calcul que le 4ᵉ et rapporte autant — mais la licence grignote discrètement la marge. Un modèle forfaitaire rompt ce lien : vous payez une fois, et chaque client supplémentaire est de la marge pure face à une facture de VPS qui bouge à peine.

Voilà l'argument commercial. Mais si les gens ne se contentent pas d'entasser tous les sites sur une machine, c'est pour une raison technique — et c'est la partie qu'il faut réussir.

Le vrai défi : l'isolation, pas la capacité

Mettre dix sites sur un serveur est facile. Mettre dix sites sur un serveur en toute sécurité — pour qu'un site piraté ou mal élevé ne puisse pas lire, affamer ni faire tomber les neuf autres — voilà le vrai métier de l'hébergement mutualisé. Ces principes valent sur n'importe quelle machine Linux, avec n'importe quel panel ou aucun :

1. Un utilisateur Linux par site

La règle la plus importante. Chaque site doit tourner sous son propre utilisateur système dédié, fichiers possédés par cet utilisateur et droits empêchant les autres de les lire. Si tous les sites tournent en www-data, un seul plugin WordPress compromis peut lire le wp-config.php de tous les autres sites — mots de passe de base compris. Des utilisateurs séparés transforment une brèche au niveau d'un site en problème limité à ce site, plutôt qu'au serveur entier.

2. Un pool PHP-FPM dédié par site

Ne partagez pas un seul pool de processus PHP entre locataires. Donnez à chaque site son propre pool PHP-FPM tournant sous son utilisateur Linux. Cela fait deux choses : cela impose l'isolation ci-dessus au niveau de PHP, et cela permet de plafonner les ressources par site (pm.max_children, limites mémoire) pour qu'un site chargé ne monopolise pas tous les workers PHP et ne bloque pas les autres. Bonus : chaque pool peut tourner sous une version de PHP différente — client legacy en 7.4, app moderne en 8.4, sur le même serveur.

3. open_basedir, pour que PHP ne s'égare pas

Même avec des utilisateurs séparés, un script mal configuré peut tenter de lire hors de son répertoire. Définissez open_basedir par pool pour épingler le PHP de chaque site à sa propre racine (et à son dossier temporaire). C'est un filet de sécurité en défense en profondeur, peu coûteux : si l'isolation nº 1 flanche un jour, celui-ci rattrape l'égaré.

4. Une base de données et un utilisateur SQL par site

Ne partagez jamais un utilisateur MySQL/MariaDB entre sites clients, et n'accordez jamais à un site un compte à privilèges globaux. Chaque site reçoit sa propre base et un utilisateur dédié n'ayant de droits que sur cette base. Un identifiant qui fuit expose alors les données d'un seul client, pas tout votre parc.

5. Des quotas disque, pour que personne n'affame la machine

Sur une machine partagée, les logs galopants, les uploads pléthoriques ou les sauvegardes oubliées d'un client peuvent remplir le disque — et un disque plein fait tomber tous les sites, y compris le panel lui-même. Fixez un quota disque par site. Cela transforme « le serveur est en panne » en « un client a atteint sa limite » : un ticket de support, pas une interruption.

6. Logs, sauvegardes et pare-feu indépendants

Donnez à chaque site ses propres logs d'accès/erreur pour diagnostiquer un client sans fouiller un flot partagé. Sauvegardez chaque site indépendamment pour en restaurer un sans toucher aux autres. Et durcissez la machine dans son ensemble — pare-feu (UFW), bannissement anti-force brute (Fail2ban), et idéalement une couche comportementale (CrowdSec) — car sur un serveur mutualisé, une attaque contre un site est une attaque contre tout le voisinage.

Faites les six et un VPS devient un foyer réellement sûr pour de nombreux clients. Sautez-en un seul et vous avez bâti un point de défaillance catastrophique, propagé d'un locataire à l'autre.

Le faire à la main est fastidieux — et subtilement faillible

Aucun des six n'est ésotérique. Mais les câbler correctement pour chaque nouveau site — un utilisateur Linux neuf, un pool FPM avec le bon open_basedir et les bonnes limites, une base et un utilisateur isolés, un quota, des chemins de logs, un vhost, un certificat auto-renouvelé — fait beaucoup de pièces à assembler à la main, à chaque fois, sans la faute de frappe qui casse discrètement l'isolation que vous croyiez avoir. C'est précisément la configuration répétitive et critique pour la sécurité qu'un panel existe pour standardiser.

C'est là qu'un panel que vous possédez prend toute sa valeur. ShadowPanel provisionne chaque nouveau site avec toute la checklist d'isolation appliquée par défaut :

• Un utilisateur Linux dédié par site, fichiers possédés par cet utilisateur, groupe www-data et droits verrouillés.
• Un pool PHP-FPM isolé tournant sous cet utilisateur, avec open_basedir imposé et sa propre version de PHP (5.6 → 8.4).
• Sa propre base et son propre utilisateur SQL, limités à ce seul site.
• Des quotas disque par site définis dans l'interface, avec suivi de l'usage en direct.
• Un vhost nginx et des logs séparés, plus un SSL Let's Encrypt gratuit à renouvellement automatique par domaine.
• Une machine durcie par défaut — UFW, Fail2ban, CrowdSec et scan ClamAV des uploads.

Et c'est une licence forfaitaire, pas un tarif par compte — donc l'isolation que vous devriez bâtir à la main pour chaque client vient gratuitement avec chaque client.

Une mise en place concrète : cinq clients sur un CAX21

Voici un déroulé réaliste :

1. Provisionnez un VPS — un Hetzner CAX21 (4 vCPU, 8 Go de RAM, ~13 €/mois) est un point de départ sensé pour une douzaine de petits sites.

2. Installez ShadowPanel et activez votre licence :

   curl -fsSL https://shadowpanel.de/install.sh | bash
   

3. Ajoutez le site de chaque client. Pointez le domaine, et le panel provisionne l'utilisateur Linux, le pool FPM, la base, le quota, le vhost et le SSL en une étape — toute la checklist d'isolation, appliquée à l'identique à chaque fois.

4. Fixez un quota disque par site pour qu'aucun client ne puisse remplir la machine.

5. Surveillez l'usage des ressources. À mesure que le serveur se remplit, les limites par pool empêchent un site chargé d'affamer les autres ; quand vous dépassez la machine, déplacez un client lourd sur un second VPS — la licence forfaitaire ne vous pénalise pas si vous faites tourner plusieurs panels.

Cinq clients, un serveur, une facture prévisible — et chaque site scellé des autres.

Réserves honnêtes

• Une machine, c'est un seul panier. L'isolation protège les locataires les uns des autres ; elle ne les protège pas d'une défaillance au niveau de l'hôte. Pour tout ce qui est critique, répartissez les clients sur deux ou trois VPS plutôt que de miser tout un portefeuille sur une seule machine.
• La RAM est le vrai plafond, pas la licence. Une douzaine de sites vitrines au repos ne pèse rien ; une douzaine de boutiques WooCommerce actives, si. Surveillez la mémoire et montez d'un palier de VPS (ou passez à une seconde machine) avant de faire du swap.
• Un panel automatise la mise en place, pas le jugement. ShadowPanel applique l'isolation pour vous, mais la planification de capacité, les mises à jour et les sauvegardes restent à vous. C'est le prix de posséder la pile plutôt que de la louer par compte.

En résumé

Héberger de nombreux sites clients sur un seul VPS n'a jamais été bloqué par le matériel — un serveur bon marché en a la capacité depuis des années. Ça l'était par deux choses : réussir l'isolation par site, et ne pas payer un tarif par compte pour ce privilège. Maîtrisez les six principes d'isolation — utilisateurs séparés, pools FPM par site, open_basedir, bases isolées, quotas, logs et sauvegardes indépendants — et une machine héberge en sécurité une douzaine de clients. ShadowPanel applique toute cette checklist à chaque site par défaut, sur une seule licence forfaitaire, pour que vos coûts restent plats pendant que votre portefeuille grandit.

Si vous faites cela pour revendre l'hébergement sous votre marque, associez-y la marque blanche : voir Hébergement en marque blanche pour agences.

Voir les tarifs → · Télécharger ShadowPanel →