Ressources garanties hébergement : ce qu’un serveur mutualisé partage vraiment
Sur un hébergement mutualisé, votre site n’a pas de machine à lui. Il partage avec des dizaines d’autres comptes un même serveur physique : processeur, mémoire, disques, serveur web et base de données. Ce partage explique le prix, dès 99 €/an HT pour les packs d’hébergement web, et il pose la seule question qui compte derrière l’expression « ressources garanties hébergement » : que vous reste-t-il de réservé le jour où un voisin a besoin de tout ?
Sans mécanisme d’isolation, la réponse est : rien. Un voisin piraté qui envoie du courrier indésirable, une boutique dont un module tourne en boucle ou un robot qui aspire un catalogue de 20 000 pages occupent les cœurs et saturent le disque. Vos pages attendent leur tour, et rien ne l’explique dans vos journaux : le site est lent par à-coups, à des heures sans rapport avec votre activité.
Le « voisin bruyant », un problème de file d’attente
Un serveur web a quatre files d’attente : le processeur, la mémoire, le disque et le nombre de processus PHP simultanés. Comme devant une imprimante partagée, quand un seul compte remplit l’une d’elles, tous les autres patientent ; si la file des processus est pleine, le serveur renvoie une erreur 503 à tout le monde.
Des ressources garanties posent une cloison dans chaque file : chaque compte reçoit sa part, ne peut pas la dépasser et personne ne peut la lui prendre. Chez NovaHoster, cette cloison est posée par CloudLinux et son mécanisme LVE. Le guide CloudLinux, LVE et CageFS expliqués en décrit le fonctionnement technique ; celui-ci reste côté client : lire son offre et ses statistiques.
Ce que CloudLinux LVE garantit, ressource par ressource
LVE (Lightweight Virtual Environment) place chaque compte dans une enveloppe à six compteurs, chacun plafonné par la formule.
- CPU (SPEED) : la puissance de calcul attribuée au compte, en pourcentage d’un cœur (100 % équivaut à un cœur entier, 200 % à deux). Exemple : un WordPress avec cinq extensions bien choisies et un cache de page consomme quelques pourcents de cœur ; sans cache, avec un constructeur de pages et une extension de statistiques, il mobilise un cœur entier dès quelques visiteurs simultanés.
- Mémoire physique (PMEM) : la mémoire vive occupée par tous vos processus additionnés. Exemple : un processus PHP de WordPress pèse souvent plusieurs dizaines de Mo ; dix visiteurs au même instant plus une sauvegarde par extension, et la mémoire d’une petite formule est vite approchée.
- Entrées-sorties disque (IO) : le débit de lecture et d’écriture, en Mo par seconde. Exemple : une boutique en promotion qui régénère des miniatures, écrit des journaux et exporte des commandes ; au plafond, ses processus ne sont pas arrêtés mais ralentis.
- IOPS : le nombre d’opérations disque par seconde, quel que soit le volume. Exemple : des milliers de petits fichiers de cache lus un à un épuisent les IOPS alors que le débit reste minuscule.
- Nombre de processus (NPROC) : tous les processus du compte, PHP, cron, scripts, SSH. Exemple : une tâche planifiée lancée chaque minute qui ne se termine jamais s’empile jusqu’à occuper tous les emplacements.
- Processus entrants (EP) : les requêtes HTTP traitées par PHP en même temps, c’est-à-dire les connexions simultanées. Exemple : une newsletter à 5 000 contacts crée un pic de clics dans la même minute ; au-delà de la limite, les visiteurs reçoivent une erreur 508 au lieu d’attendre.
Le mot « garanti » a ici un sens précis. Votre plafond est aussi un plancher : un voisin qui sature sa propre enveloppe y est ralenti ou bloqué et ne mord pas sur la vôtre. En contrepartie, vous ne pouvez pas emprunter la part inutilisée d’un autre compte.
Tableau : chaque ressource, ce qu’elle limite, son symptôme et où la voir dans Plesk
La dernière colonne renvoie à l’écran Statistiques → Utilisation des ressources de Plesk, décrit plus bas.
| Ressource | Ce qu’elle limite | Symptôme quand elle manque | Où la voir dans Plesk |
|---|---|---|---|
| CPU (SPEED) | Temps de calcul : pages PHP, requêtes SQL, redimensionnement d’images | Pages lentes aux heures de pointe, tableau de bord qui rame, aucune erreur | Courbe « CPU Usage » et défauts CPU |
| Mémoire physique (PMEM) | Mémoire vive cumulée de tous vos processus | Erreur 500 ou page blanche aléatoire, import ou sauvegarde interrompu | Courbe « Physical Memory Usage » et défauts mémoire |
| Entrées-sorties (IO) | Débit disque en Mo/s | Lenteurs pendant téléversements, exports et sauvegardes | Courbe « IO Usage » |
| IOPS | Opérations disque par seconde | Lenteur sans débit visible, liée à des milliers de petits fichiers | Courbe « IOPS » |
| Processus (NPROC) | Nombre total de processus du compte | Erreur 503, tâches planifiées qui ne se lancent plus, SSH ou FTP refusé | Courbe « Number of processes » et défauts |
| Processus entrants (EP) | Requêtes PHP simultanées | Erreur 508 « Resource Limit Is Reached » lors d’un pic ou d’un robot | Courbe « Entry processes » et défauts EP |
Deux quotas ne relèvent pas de LVE mais apparaissent au même endroit : l’espace disque et le nombre de fichiers (inodes). Un compte plein ne peut plus écrire journaux, cache et sessions, ce qui produit des erreurs qui ressemblent à une limite LVE sans en être une.
« Hébergement illimité » : ce que cachent les offres du marché
Beaucoup d’offres affichent « espace illimité », « trafic illimité », parfois « sites illimités ». Aucune de ces promesses ne porte sur ce qui fait la vitesse d’un site : un processeur et une mémoire sont finis et partagés, donc toujours plafonnés par compte, que la fiche le dise ou non.
Ce qui est réellement illimité, et ce qui ne l’est jamais
- Espace « illimité » : le volume en Go n’est pas compté, mais le nombre de fichiers (inodes) l’est presque toujours, et une clause d’usage raisonnable exclut sauvegardes, archives et vidéos.
- Trafic « illimité » : les Go transférés ne sont pas facturés, mais le nombre de visiteurs servis en même temps dépend des processus entrants et du CPU, qui restent limités.
- Sites « illimités » : tous les sites du compte partagent la même enveloppe LVE.
- Clause d’usage raisonnable : elle autorise l’hébergeur à limiter ou suspendre un compte qui gêne les autres. Elle existe précisément parce que rien n’est illimité.
Lire une offre d’hébergement mutualisé avant de signer
- Cherchez la ligne CPU, mémoire ou processus dans la fiche détaillée des formules. Son absence est déjà une information.
- Vérifiez que l’hébergeur nomme sa technologie d’isolation (CloudLinux LVE ou équivalent). Sans isolation, les chiffres sont partagés, pas garantis.
- Lisez la clause d’usage raisonnable : dépassement sanctionné par un avertissement ou par une suspension immédiate ?
- Demandez au support, par écrit, la limite CPU en pourcentage de cœur, la mémoire physique en Mo et le nombre de processus entrants.
- Regardez le disque : un NVMe sert bien plus d’opérations par seconde qu’un SATA, à limite d’IOPS égale.
Lire les statistiques de ressources dans Plesk, courbes et « faults »
Sur un hébergement Plesk équipé de CloudLinux, les compteurs LVE sont visibles par le client. Inutile d’ouvrir un ticket pour savoir si votre site touche ses limites.
- Connectez-vous à Plesk depuis l’Espace client NovaHoster (dash.novahoster.fr) ou avec vos identifiants Plesk.
- Dans le menu de gauche, ouvrez Statistiques, puis Utilisation des ressources. Selon la version, un bloc du même nom figure aussi sur la page de l’abonnement.
- Choisissez la période : les dernières heures pour un incident en cours, 24 heures pour le rythme d’une journée, 7 ou 30 jours pour une tendance.
- Lisez chaque courbe. La ligne horizontale est la limite de votre formule ; la courbe est votre usage. Une courbe qui touche la ligne signifie que la limite a été atteinte à cet instant.
- Regardez les compteurs de défauts (« faults » en anglais). Un défaut est compté chaque fois qu’une demande a été refusée ou ralentie faute de ressource. Zéro défaut sur 30 jours signifie que la limite n’a jamais gêné votre site.
- Rapprochez l’heure des défauts de vos événements : newsletter, tâche planifiée, mise à jour, campagne, robot visible dans les journaux.
- Faites une capture d’écran de la période : c’est la pièce que le support attend pour répondre vite.
Si la rubrique n’apparaît pas, vérifiez que vous êtes connecté avec le compte propriétaire de l’abonnement.
Site lent sur un hébergement mutualisé : reconnaître une limite atteinte
Un site lent sur hébergement mutualisé n’est pas forcément un site qui manque de ressources. Avant d’accuser la formule, faites parler les symptômes : chacun pointe vers une ressource différente.
- Erreur 508 « Resource Limit Is Reached » : signature des processus entrants saturés. Elle arrive par vagues, lors d’un pic de visites, d’un robot ou d’une newsletter, puis disparaît.
- Erreur 503 « Service Unavailable » : souvent le nombre de processus ou la mémoire au plafond. À heure fixe, cherchez une tâche planifiée.
- Erreur 500 ou page blanche aléatoire : un processus PHP tué pour dépassement mémoire, ou une erreur du site sans rapport avec les ressources. Le guide Erreur 500 site web : comprendre et corriger sur Plesk explique comment distinguer les deux à partir des journaux.
- Lenteurs par pics, sans erreur : CPU ou entrées-sorties bridés. CloudLinux ne coupe pas, il ralentit : le site répond, mais chaque page met plusieurs secondes à démarrer.
- Tâches planifiées qui échouent : sauvegardes incomplètes, imports arrêtés à mi-chemin : la mémoire ou les processus manquent au moment où la tâche tourne.
- Accès FTP ou SSH refusé par intermittence : tous les processus du compte sont occupés.
Lenteur côté serveur ou lenteur côté page ?
Une limite LVE atteinte allonge le délai avant le premier octet. Elle n’a aucun effet sur le poids des images ou les scripts tiers qui ralentissent l’affichage ensuite. Aucun défaut dans Plesk et un site toujours lent : le problème est dans la page, pas dans l’hébergement. Le guide Vitesse site web et hébergement : Core Web Vitals expliqués montre comment séparer les deux.
Réduire la consommation avant de changer d’offre
Le plus souvent, un site touche ses limites à cause de sa configuration, pas de son audience. Voici les actions classées par rapport effet sur effort.
- Activer un cache de page. Une page servie depuis le cache ne consomme ni PHP ni base de données : CPU et processus entrants chutent immédiatement. Sur un hébergement WordPress NovaHoster, le cache serveur se règle dans Plesk ; sinon, une extension de cache réputée fait le travail.
- Auditer les extensions. Désactivez une à une les extensions de statistiques internes, de « contenus similaires », de sécurité qui scannent en continu, et mesurez entre chaque : une seule extension peut représenter l’essentiel de la consommation.
- Reprendre la main sur les tâches planifiées. Sur WordPress, remplacez le déclenchement de WP-Cron à chaque visite par une tâche planifiée Plesk toutes les 5 à 15 minutes, et décalez les sauvegardes par extension la nuit.
- Alléger les images. Redimensionnez avant téléversement, servez du WebP, activez le chargement différé, et ne régénérez pas toutes les miniatures en pleine journée.
- Freiner les robots agressifs. Dans les journaux d’accès de Plesk, un seul robot peut représenter la moitié des requêtes, sur des pages jamais mises en cache. Bloquez les agents inutiles par
.htaccess; Imunify360 freine déjà les comportements abusifs. - Passer à une version PHP 8.x récente. Dans Plesk, Paramètres PHP change la version en quelques clics ; chaque version récente exécute le même code plus vite et avec moins de mémoire, une fois la compatibilité du thème et des extensions vérifiée.
- Nettoyer la base de données. Transients expirés, révisions, tables laissées par des extensions supprimées : une base allégée réduit CPU et entrées-sorties.
Le guide Sauvegarder, accélérer et sécuriser WordPress sur NovaHoster détaille ces réglages. Après chaque action, comparez les défauts sur 7 jours dans Utilisation des ressources : c’est la seule mesure qui compte.
Quand passer à la formule supérieure, à l’hébergement e-commerce ou à un VPS
Changer d’offre se justifie quand les défauts persistent après optimisation et correspondent à une activité légitime : plus de visiteurs, plus de commandes. Trois paliers existent.
- La formule mutualisée supérieure : même Plesk, mêmes fichiers, aucune migration ; seules les limites LVE augmentent. C’est la réponse quand une seule ressource manque, en général le CPU ou les processus entrants.
- L’hébergement e-commerce : des ressources garanties dimensionnées pour une boutique, dont le panier, le paiement et le compte client ne passent jamais par le cache. Le guide Hébergement WooCommerce : dimensionner selon sa boutique donne les paliers selon le catalogue, les visites et les commandes.
- Le serveur VPS : des ressources réservées à vous seul, l’accès root et la liberté d’installer Redis ou Node.js, en contrepartie de l’administration du système. Un serveur VPS démarre à 10 €/mois HT. Les VPS NovaHoster sont hébergés en Roumanie, en Moldavie ou en Russie. Le mutualisé, lui, reste dans des datacenters situés en France.
Les trois signaux qui tranchent
- Des défauts sur plusieurs ressources à la fois, pendant plusieurs semaines, après cache et audit des extensions : la formule supérieure s’impose.
- Un service que le mutualisé n’installe pas (cache objet Redis, moteur de recherche, application Node.js permanente) : c’est un VPS, pas une formule plus grande.
- Un chiffre d’affaires qui dépend de la disponibilité à la minute, avec des pics de commandes prévisibles : hébergement e-commerce d’abord, puis VPS ou serveur dédié avec infogérance.
Le guide Mutualisé ou VPS ou serveur dédié : lequel choisir ? compare les trois formules par profil. Dans le doute, le passage à la formule supérieure est réversible et sans coupure ; le passage à un VPS est une migration et un changement de métier.
Ressources garanties hébergement chez NovaHoster : où lire les valeurs de votre pack
Sur l’hébergement mutualisé NovaHoster, chaque compte tourne sous CloudLinux : LVE encadre CPU, mémoire physique, entrées-sorties, IOPS, processus et processus entrants, et CageFS isole les fichiers de chaque client. Les serveurs utilisent des disques NVMe et exécutent PHP 8.x avec OPcache, ce qui réduit le coût en CPU et en entrées-sorties de chaque page. Le mutualisé est couvert par un SLA de 99,99 %.
Les valeurs chiffrées de chaque limite ne figurent pas dans ce guide, volontairement : elles dépendent de la formule et peuvent évoluer. Vous les trouvez à deux endroits, qui doivent concorder :
- sur la page des packs d’hébergement web, dans le détail de chaque formule, dès 99 €/an HT ;
- dans votre Plesk, rubrique Statistiques → Utilisation des ressources, où la ligne de limite de chaque courbe correspond à votre formule actuelle.
Si les deux ne concordent pas, ouvrez un ticket depuis dash.novahoster.fr : le support, assuré 7j/7 par des développeurs, vérifie la configuration du compte. Un changement de formule se fait sans migration ni coupure, et l’hébergement web reste couvert par la garantie satisfait ou remboursé de 30 jours.
Liste de contrôle : lire son offre et ses statistiques de ressources
À parcourir avant de commander, puis une fois par trimestre ou dès qu’un ralentissement est signalé.
Avant de choisir une offre
- La technologie d’isolation (CloudLinux LVE ou équivalent) est nommée dans l’offre.
- Les limites CPU, mémoire physique et processus entrants sont écrites ou obtenues par écrit auprès du support.
- La clause d’usage raisonnable et les conséquences d’un dépassement sont lues.
- Les mentions « illimité » ont été traduites : espace, trafic et nombre de sites, jamais CPU ni processus.
Une fois le site en ligne
- Utilisation des ressources consultée sur 30 jours, nombre de défauts par ressource noté.
- Cache de page actif et vérifié sur une page publique.
- WP-Cron ou équivalent piloté par une tâche planifiée Plesk, pas par les visites.
- Extensions inutilisées supprimées, pas seulement désactivées.
- Version PHP 8.x récente, testée sur le thème et les extensions.
- Journaux d’accès lus à la recherche de robots trop insistants.
- Espace disque et nombre de fichiers sous les quotas.
Avant de changer d’offre
- Les défauts persistent au moins deux semaines après les optimisations.
- La ressource manquante est identifiée : une seule ressource oriente vers la formule supérieure, un besoin de service vers un VPS.
- Une capture des statistiques Plesk est jointe au ticket pour que le support confirme le diagnostic.
Questions fréquentes
Que veut dire « ressources garanties » sur un hébergement mutualisé ?
Un hébergement illimité existe-t-il vraiment ?
Comment savoir si mon site atteint sa limite CPU sur l’hébergement ?
Quelle est la différence entre une erreur 503 et une erreur 508 ?
Pourquoi mon site est lent sur un hébergement mutualisé alors que le trafic est faible ?
Faut-il passer sur un VPS dès que les limites LVE sont atteintes ?
Les limites LVE CloudLinux sont-elles les mêmes que les réglages PHP de Plesk ?
Guides liés
Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :
Sources techniques
[1] CloudLinux — Limits : SPEED, PMEM, IO, IOPS, NPROC et EP (documentation CloudLinux OS) [2] Plesk — Plesk Obsidian Customer’s Guide (statistiques, utilisation des ressources, paramètres PHP) [3] WordPress.org — Advanced Administration Handbook : Performance (cache, extensions, optimisation) [4] WordPress.org — Hooking WP-Cron into the system task scheduler
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