Héberger plusieurs sites sur un seul hébergement : limites

Héberger plusieurs sites sur un seul hébergement : ce que permet un abonnement Plesk

Héberger plusieurs sites sur un seul hébergement est le cas le plus courant chez un indépendant, une petite agence ou une PME qui gère plusieurs marques. Sur un hébergement web mutualisé NovaHoster, chaque formule correspond à un abonnement Plesk, et cet abonnement peut porter plusieurs domaines. Le nombre de domaines inclus dépend de la formule choisie.

Plesk distingue trois objets, et le choix n’est pas anodin :

Domaine additionnel : un site complet, avec son propre dossier (un répertoire au nom du domaine, contenant son httpdocs), sa version de PHP, son certificat Let’s Encrypt, ses boîtes e-mail, ses bases de données et ses journaux. C’est l’objet à utiliser pour un second site réel.
Sous-domaine : blog.exemple.fr ou demo.exemple.fr. Il a son dossier, peut avoir sa version de PHP et son certificat, mais il dépend du domaine parent pour la zone DNS et la messagerie.
Alias de domaine : un second nom (exemple.com, une faute de frappe fréquente) qui mène au même site. Pas de dossier séparé ni de boîtes propres ; Plesk propose une redirection 301 vers le domaine principal, à activer pour éviter un contenu indexé en double.

Objet Plesk	Dossier séparé	PHP propre	Certificat propre	E-mail propre	Usage typique
Domaine additionnel	Oui	Oui	Oui	Oui	Deuxième site, autre marque
Sous-domaine	Oui	Oui	Oui	Non, boîtes sur le domaine parent	Blog, préproduction, extranet
Alias de domaine	Non	Non	Inclus dans celui du principal si l’alias est coché à l’émission	Non, le courrier arrive sur les boîtes du principal	Variante du nom, .com en plus du .fr

Le guide Abonnement Plesk : fichiers, domaines, sécurité décrit l’organisation générale d’un abonnement. Ici, on se concentre sur ce qui change quand plusieurs sites cohabitent.

Ajouter un domaine additionnel dans Plesk, pas à pas

Le nom de domaine doit être enregistré et vous devez pouvoir modifier ses DNS. La création prend une dizaine de minutes ; la propagation DNS peut ajouter quelques heures.

Connectez-vous à Plesk depuis l’Espace client, puis ouvrez Sites web & domaines.
Cliquez sur Ajouter un domaine. Plesk propose plusieurs points de départ : site vierge, envoi de fichiers, Sitejet, dépôt Git ou WordPress.
Saisissez le nom de domaine. Un avertissement DNS est normal tant que le domaine ne pointe pas vers le serveur.
Vérifiez le répertoire racine. Par défaut, Plesk crée un dossier au nom du domaine avec son propre httpdocs. Ne pointez jamais deux domaines vers le même dossier, sauf choix délibéré.
Validez. Plesk crée l’hébergement, la zone DNS et le service de messagerie du domaine.
Faites pointer le domaine : enregistrement A vers l’adresse IP de l’hébergement, visible dans Plesk.
Une fois le domaine résolu, ouvrez Certificats SSL/TLS et installez un certificat Let’s Encrypt gratuit, en cochant le nom nu et sa version www.
Dans Paramètres PHP, choisissez la version adaptée à ce site. Chaque domaine a la sienne.
Créez la base dans Bases de données et les boîtes dans Messagerie, en vérifiant que le bon domaine est sélectionné.

Ajouter un sous-domaine ou un alias

Ajouter un sous-domaine demande un nom et un dossier ; Plesk crée l’enregistrement DNS lui-même quand la zone est gérée sur le serveur. Ajouter un alias de domaine propose de synchroniser la zone DNS, d’accepter le courrier et d’activer une redirection 301 : cochez-la dans la quasi-totalité des cas.

Ce qui reste partagé : les ressources CloudLinux de l’abonnement

C’est le point que l’on découvre souvent trop tard. Un abonnement Plesk correspond à un utilisateur système, et CloudLinux attribue ses limites (processeur, mémoire, nombre de processus, entrées-sorties disque) à cet utilisateur, pas à chaque domaine. Tous les sites de l’abonnement puisent dans la même enveloppe LVE.

Concrètement : si une boutique reçoit le trafic d’une campagne d’e-mailing et consomme toute la mémoire allouée, le site vitrine de l’autre marque ralentit ou renvoie des erreurs 503, alors qu’il n’a rien fait. Un robot qui martèle un vieux site oublié produit le même effet. Les graphiques de Plesk montrent les pics de l’abonnement entier, sans désigner le domaine responsable.

Le guide CloudLinux, LVE et CageFS expliqués détaille ce que chaque limite mesure, et celui sur les ressources garanties en hébergement mutualisé explique comment les comparer d’une formule à l’autre. Pour un hébergement multi-sites, retenez une règle simple : la formule se dimensionne pour la somme des sites, pas pour le plus gros d’entre eux.

Repérer le site qui consomme

Comparez les journaux d’accès de chaque domaine à l’heure du pic : le domaine qui reçoit le plus de requêtes est le premier suspect.
Vérifiez les tâches planifiées de chaque site : un cron lancé toutes les minutes pénalise tout l’abonnement.

Espace disque et sauvegardes : un seul lot pour tous les sites

L’espace disque de l’abonnement est commun. Un WordPress qui accumule des années de médias, ou une boutique qui conserve ses exports, peut remplir le quota et empêcher les autres sites d’écrire : envois de fichiers en échec, e-mails refusés. Plesk affiche la répartition par domaine dans Statistiques ; consultez-la une fois par mois.

Les sauvegardes suivent la même logique. La sauvegarde quotidienne de NovaHoster et celles que vous lancez depuis le Gestionnaire de sauvegarde portent sur l’abonnement entier. Deux conséquences :

Une restauration complète remet tous les sites à la date choisie. Si le site A a été compromis mardi mais que le site B a publié dix articles depuis, restaurer l’abonnement à lundi efface les articles de B.
Le Gestionnaire de sauvegarde permet heureusement une restauration ciblée : ouvrez l’archive, choisissez la restauration d’objets sélectionnés et cochez uniquement le domaine concerné, voire seulement ses fichiers ou sa base. Prenez l’habitude de passer par là plutôt que par la restauration globale.

Un site vitrine mis à jour deux fois l’an et une boutique qui enregistre des commandes chaque jour n’ont pas les mêmes besoins ; le guide sur la règle 3-2-1 appliquée à une PME aide à régler la fréquence et à conserver une copie en dehors de l’hébergeur.

Accès et sécurité : plusieurs sites, un hébergement, un seul utilisateur système

Dans un abonnement Plesk, tous les domaines appartiennent au même utilisateur système. L’identifiant Plesk principal et le compte FTP principal donnent accès à tous les dossiers. Si vous confiez cet identifiant à un prestataire pour intervenir sur la marque B, il voit et peut modifier la marque A.

Le même principe vaut pour la sécurité. Un script PHP exécuté sur le site A tourne avec les droits de l’utilisateur de l’abonnement : il peut lire et écrire dans les dossiers du site B. Un site compromis par une extension obsolète sert donc souvent de porte d’entrée vers les autres : fichiers injectés dans chaque httpdocs, redirections ajoutées dans tous les .htaccess.

CageFS, le composant de CloudLinux, isole les abonnements entre eux : un utilisateur ne voit ni les fichiers ni les processus des autres clients du serveur. En revanche, il n’isole pas les domaines d’un même abonnement, puisqu’ils partagent le même utilisateur. C’est une limite de conception, et la raison principale pour laquelle des sites de clients différents ne devraient pas cohabiter dans un abonnement.

Imunify360 analyse les fichiers de tous les domaines et bloque les attaques au niveau du serveur, ce qui réduit le risque sans remplacer la séparation. Le guide des bonnes pratiques de sécurité pour un hébergement NovaHoster donne les réglages de fond ; celui pour supprimer un malware avec Imunify360 explique quoi faire quand une alerte apparaît sur l’un des domaines.

Règles pratiques pour un hébergement multi-sites sain

Puisque l’isolation technique est limitée à l’intérieur d’un abonnement, l’organisation compense.

Un compte FTP par domaine

Dans Sites web & domaines, ouvrez le domaine, puis Accès FTP et Ajouter un compte FTP. Donnez un mot de passe long et surtout un répertoire racine limité au dossier de ce domaine : un compte additionnel ne sort pas de son répertoire. C’est celui à transmettre à un prestataire, en FTPS ou SFTP plutôt qu’en FTP en clair ; supprimez-le à la fin de la mission. Le compte principal reste à vous seul.

Une base et un utilisateur par site

Créez une base de données distincte par site, avec son propre utilisateur MySQL limité à cette base. Ne réutilisez jamais un mot de passe de base d’un site à l’autre et changez le préfixe de tables par défaut (wp_, ps_) à l’installation. Si un site est compromis, l’attaquant n’obtient que les identifiants de sa propre base.

Mettre à jour tous les sites, pas seulement le principal

Le site oublié est le maillon faible. Un WordPress de démonstration jamais mis à jour expose les sites en production du même abonnement. Planifiez un passage mensuel sur chaque CMS : cœur, thèmes, extensions, puis version de PHP.

Surveiller et nettoyer

Consultez Imunify360 chaque semaine : un fichier mis en quarantaine désigne le domaine fautif.
Supprimez les sites abandonnés. Un domaine sans trafic mais avec un dossier plein reste attaquable ; si vous gardez le nom, videz le dossier.
Tenez un tableau des domaines : qui détient quel accès, quelle version de PHP, quel CMS, quelle date de dernière mise à jour.

Un abonnement, plusieurs abonnements ou hébergement revendeur : le comparatif

Trois organisations permettent d’héberger plusieurs sites. Chacune répond à un besoin différent, et le prix n’est pas le seul critère.

Critère	Un abonnement avec domaines additionnels	Plusieurs abonnements séparés	Hébergement revendeur
Isolation entre sites	Aucune : même utilisateur système	Complète : CageFS sépare les abonnements	Complète : chaque compte client est un abonnement isolé
Ressources CPU, RAM, I/O	Une enveloppe partagée	Une enveloppe par abonnement	Une enveloppe par compte, que vous répartissez
Sauvegardes	Une archive pour tous les sites, restauration ciblée possible	Une archive par site	Une archive par compte client
Accès client ou prestataire	Comptes FTP limités à un dossier, Plesk commun	Un identifiant Plesk par abonnement	Un Plesk complet par client, à votre marque
Facturation	Une facture NovaHoster	Une facture par abonnement	Une facture NovaHoster pour vous ; vous facturez vos clients à votre tarif
Coût indicatif HT	Dès 99 €/an	Dès 99 €/an par abonnement	Dès 349 €/an, jusqu’à 40 comptes clients
Pour qui	Indépendant ou PME avec ses propres marques	Deux ou trois sites qui ne doivent pas se gêner	Agence, freelance avec des clients, groupe à plusieurs filiales

Ordre de grandeur : à partir de quatre ou cinq sites gérés pour des tiers, le revendeur revient en général moins cher que des abonnements séparés. Pour deux marques qui vous appartiennent, un seul abonnement bien tenu reste la solution la plus simple.

Quand passer à l’hébergement revendeur

L’hébergement revendeur NovaHoster vous donne un accès Plesk de niveau revendeur : vous créez des abonnements clients, chacun avec son utilisateur système, ses limites de ressources, ses sauvegardes et son accès Plesk. Quatre signaux indiquent qu’il est temps d’y passer.

Vous hébergez des clients distincts. Dès que les sites appartiennent à des entreprises différentes, la cohabitation dans un même abonnement pose un problème de confidentialité et de responsabilité en cas d’incident.
Vos clients veulent un accès. Pour gérer leurs boîtes e-mail, leurs DNS ou leurs fichiers, ils ont besoin d’un Plesk à eux. Un compte FTP limité à un dossier ne suffit plus.
Vous facturez par client. Chaque client a un espace disque et des ressources identifiables ; vous facturez l’hébergement avec vos prestations, à votre tarif.
Vous voulez une marque blanche. Le panneau porte votre nom et le client ne voit pas l’hébergeur sous-jacent.

Le passage ne demande pas de réécrire les sites : chaque domaine additionnel est déplacé vers son propre abonnement client, avec ses fichiers, sa base et ses boîtes. Le support NovaHoster peut accompagner ce découpage ; prévoyez une mise à jour des DNS si l’adresse IP change.

Ce que le revendeur ne règle pas

Un compte revendeur reste du mutualisé : les ressources de chaque compte client sont plafonnées par CloudLinux et vous n’avez pas d’accès root. Pour une application qui exige un service absent de la plateforme, la question du serveur se pose.

Quand un VPS devient plus logique

Le serveur VPS répond à d’autres besoins que le revendeur : accès root, choix libre des logiciels, ressources attribuées à votre machine. Il devient pertinent dans trois situations :

un site a besoin d’un composant que l’hébergement Plesk mutualisé ne fournit pas (file d’attente, moteur de recherche, service en écoute permanente) ;
vous voulez répartir vous-même les ressources entre vos sites, par exemple avec un conteneur par application ;
la somme de vos sites dépasse durablement ce que la plus grosse formule mutualisée accepte.

En contrepartie, vous devenez administrateur : mises à jour du système, pare-feu, sauvegardes et surveillance sont à votre charge, ou à celle d’une infogérance. Sans compétence système en interne, le revendeur reste souvent le meilleur compromis.

Un point à vérifier pour une PME soucieuse de la localisation des données : les VPS NovaHoster sont hébergés en Roumanie, en Moldavie ou en Russie. Le mutualisé, le revendeur et les serveurs dédiés, eux, sont en France. Si vos sites traitent des données personnelles de clients, ce critère pèse dans la décision.

Liste de contrôle avant d’ajouter un site à votre hébergement

Passez cette liste à chaque nouveau domaine ; elle tient en dix minutes.

Le site appartient à ma structure ou à une marque que je contrôle ; sinon, il va dans un abonnement séparé ou dans un compte revendeur.
L’espace disque restant couvre le nouveau site avec une marge confortable, après vérification dans Statistiques.
Les ressources de la formule actuelle absorbent le trafic cumulé ; sinon, changer de formule avant la mise en ligne.
Le domaine a son propre dossier, sa version de PHP vérifiée et un certificat Let’s Encrypt actif sur le nom nu et le www.
Un compte FTP additionnel limité à son dossier existe pour chaque intervenant extérieur, en FTPS ou SFTP.
La base de données a son propre utilisateur, un mot de passe unique et un préfixe de tables non standard.
Le CMS, ses thèmes et ses extensions sont à jour le jour de la mise en ligne et inscrits dans le calendrier mensuel.
Une sauvegarde manuelle a été prise avant l’ajout, et je sais restaurer un seul domaine depuis le Gestionnaire de sauvegarde.
Les sites abandonnés de l’abonnement ont été supprimés ou vidés.
Le tableau des domaines (accès, versions, contacts, échéances) est à jour.

Si la première case reste décochée, ou si plus de deux autres le restent, le site mérite son propre abonnement ou l’offre revendeur est devenue la bonne organisation.

Questions fréquentes

Combien de sites peut-on héberger sur un seul hébergement mutualisé ?

Le nombre de domaines inclus dépend de la formule choisie, et Plesk ne limite pas lui-même les sous-domaines. La vraie limite est ailleurs : tous les sites partagent le processeur, la mémoire, les entrées-sorties et l’espace disque de l’abonnement. Deux ou trois sites modestes cohabitent sans problème ; une boutique active et plusieurs vitrines demandent une formule supérieure ou des abonnements séparés.

Un domaine additionnel Plesk peut-il avoir sa propre version de PHP et son certificat SSL ?

Oui. Chaque domaine additionnel a ses Paramètres PHP, son certificat Let’s Encrypt, son dossier, ses bases et ses boîtes e-mail. Un ancien site peut rester sur une version de PHP plus ancienne le temps d’être mis à jour, pendant que le nouveau tourne sur la dernière version. Les sous-domaines disposent des mêmes réglages, à l’exception de la messagerie, qui reste celle du domaine parent.

Si un de mes sites est piraté, les autres sites du même abonnement sont-ils en danger ?

Oui, c’est le principal risque d’un hébergement multi-sites. Les domaines d’un abonnement partagent le même utilisateur système : un script malveillant exécuté sur un site peut lire et modifier les fichiers des autres. CageFS isole les abonnements entre eux, pas les domaines d’un même abonnement. Imunify360 limite les dégâts, mais la séparation en abonnements distincts reste la seule protection complète.

Puis-je donner un accès FTP à un prestataire sans qu’il voie mes autres sites ?

Oui. Dans Plesk, ouvrez le domaine, puis Accès FTP et Ajoutez un compte FTP avec un répertoire racine limité au dossier de ce domaine. Le compte additionnel ne peut pas remonter au-dessus de ce dossier. Ne transmettez jamais le compte FTP principal ni l’identifiant Plesk, qui donnent accès à tous les sites, et supprimez le compte additionnel une fois l’intervention terminée.

Peut-on restaurer un seul site quand plusieurs sont sur le même hébergement ?

Oui, à condition de choisir la restauration ciblée. Dans le Gestionnaire de sauvegarde de Plesk, ouvrez l’archive, sélectionnez la restauration d’objets précis et cochez uniquement le domaine concerné, ou seulement ses fichiers ou sa base de données. Une restauration complète de l’abonnement remettrait tous les sites à la même date et effacerait les modifications récentes des autres domaines.

Hébergement revendeur ou plusieurs abonnements séparés : que choisir ?

Plusieurs abonnements conviennent pour deux ou trois sites qui vous appartiennent et doivent être isolés. Dès que vous gérez des sites pour des clients distincts, que ceux-ci veulent leur propre accès Plesk ou que vous facturez l’hébergement, le revendeur s’impose : un seul panneau, un abonnement isolé par client, une marque blanche, dès 349 €/an HT pour jusqu’à 40 comptes.

Un sous-domaine compte-t-il comme un site supplémentaire ?

Techniquement, un sous-domaine est un site : il a son dossier, sa version de PHP, son certificat et ses propres fichiers. Il consomme donc les mêmes ressources partagées qu’un domaine additionnel et présente les mêmes risques de sécurité. Il ne compte en revanche pas dans le nombre de domaines de la formule et dépend du domaine parent pour la zone DNS et les boîtes e-mail.

Pourquoi mon deuxième site ralentit-il le premier ?

Parce que les deux sites partagent les limites CloudLinux de l’abonnement : processeur, mémoire, processus et entrées-sorties. Quand l’un d’eux sature, par un pic de trafic, un robot, une tâche planifiée trop fréquente ou une extension lourde, l’autre attend. Comparez les journaux d’accès des deux domaines à l’heure du ralentissement, allégez le site fautif ou donnez-lui son propre abonnement.

Guides liés

Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :

Sources techniques

[1] Plesk — Customer Guide Obsidian : Adding and Removing Domains [2] Plesk — Customer Guide Obsidian : Adding Subdomains [3] Plesk — Customer Guide Obsidian : Adding Domain Aliases [4] Plesk — Customer Guide Obsidian : Adding FTP Accounts [5] CloudLinux — CloudLinux OS components : CageFS

Votre situation ne correspond pas exactement à ce guide ?

Les options visibles et les formules dépendent de votre abonnement. Faites vérifier le contexte depuis l’Espace client, sans transmettre de mot de passe.

Demander une vérification

Héberger plusieurs sites sur un seul hébergement : bonnes pratiques, limites et quand passer au revendeur