Hébergement mutualisé
L'hébergement mutualisé place plusieurs sites de clients différents sur un même serveur, dont ils partagent la puissance.
Définition
L’hébergement mutualisé place plusieurs sites de clients différents sur un même serveur, dont ils partagent la puissance. C’est la formule la plus répandue, et la seule dont le défaut principal ne se corrige par aucun réglage du site : la charge des voisins entre dans votre temps de réponse.
Que partage-t-on réellement ?
La machine, sa mémoire et son processeur. Pas les fichiers, pas la base de données.
Sur un serveur mutualisé, chaque compte client dispose de son propre espace de fichiers et de ses propres bases, inaccessibles aux autres. Ce qui est commun, c’est le matériel : le processeur, la mémoire vive, les disques et la bande passante réseau. L’hébergeur répartit ces ressources entre les comptes, et cette répartition est ce que l’on achète.
La conséquence est mécanique. Quand un autre site de la même machine reçoit un pic de trafic, ou qu’une de ses tâches consomme beaucoup, il reste moins de puissance disponible au même instant. Aucune optimisation de votre site ne compense ce phénomène, parce qu’il ne se passe pas dans votre site. Reste à savoir si la lenteur vient bien de là : c’est ce que tranche un diagnostic des temps de chargement.
Où se situent les limites, concrètement ?
Dans le nombre de traitements simultanés, pas dans l’espace disque.
Les offres mutualisées communiquent volontiers sur l’espace de stockage et la bande passante, deux ressources qu’un site vitrine ne sature à peu près jamais. Les limites qui se rencontrent réellement sont ailleurs : nombre de processus PHP exécutables en même temps, mémoire allouée à chacun, durée maximale d’un traitement, nombre de connexions simultanées à la base.
Ces plafonds ne se manifestent pas par un ralentissement progressif mais par des refus nets. Une page qui répond en quelques centièmes de seconde avec une erreur serveur, alors que la même page répond normalement l’instant d’après, est le symptôme typique d’un plafond de processus atteint, pas d’une panne.
Le raccourci à éviter. Conclure à un serveur saturé parce qu’un test a renvoyé une erreur. Une rafale de requêtes lancée par un outil d’audit atteint un plafond de concurrence qu’un trafic réel de même volume n’atteindrait jamais, parce qu’il est étalé dans le temps. La mesure utile espace les requêtes et compare avec une page témoin qui n’a pas été modifiée.
Quand le mutualisé suffit, et quand il ne suffit plus
Il suffit tant que la majorité des visites n’exécute pas de code.
C’est le point que la comparaison entre familles d’hébergement laisse souvent de côté. Un site dont les pages sont servies depuis un cache de page ne demande presque rien au processeur : la page existe déjà, il n’y a qu’à l’envoyer. Le partage de puissance devient alors marginal, et un site vitrine bien réglé se comporte très bien sur du mutualisé.
La situation change dès qu’une part importante des visites doit être calculée. Un espace client, un panier, un moteur de recherche interne, un catalogue filtrable : ces pages ne se mettent pas en cache, et chacune consomme un processus. C’est là que le plafond se rapproche.
| Situation observée | Ce qu’elle indique |
|---|---|
| Le temps de réponse est bon sur les pages en cache, mauvais sur les autres | Le travail à faire est dans le site, pas dans l’hébergement |
| Le temps de réponse varie fortement d’une heure à l’autre, sans changement du site | Le voisinage se lit dans la mesure |
| Le temps de réponse reste élevé une fois le cache et les extensions traités | Le plafond de l’offre est atteint |
| Des erreurs serveur apparaissent aux pics de trafic réels | Le nombre de traitements simultanés est la contrainte |
Ce qu’il faut avoir fait avant de changer d’offre
Changer d’hébergement relève un plafond, cela ne corrige rien en dessous.
Mettre en cache ce qui peut l’être
C’est le levier qui retire le plus de travail au serveur, et le seul qui agisse sur toutes les visites anonymes à la fois. Tant qu’il n’est pas en place, aucune mesure de temps de réponse ne dit quoi que ce soit sur l’hébergement.
Retirer ce qui s’exécute pour rien
Une extension désactivée ne consomme rien, une extension active consomme à chaque page, y compris quand elle ne sert nulle part. L’inventaire de ce qui tourne vraiment est souvent le deuxième gain le plus large.
Mesurer, plusieurs fois, sur des pages non mises en cache
Une mesure unique sur une page déjà en cache donne un excellent chiffre qui ne veut rien dire. La mesure utile porte sur une page qui doit être calculée, répétée à des heures différentes, pour voir si la variabilité vient du voisinage.
Si le temps de réponse reste élevé après ces trois étapes, la démonstration est faite et le changement d’offre se justifie. C’est aussi l’ordre inverse de celui qui se pratique le plus souvent, où l’on change d’hébergeur d’abord et où l’on découvre ensuite que le site était la cause.
Ce qu’un incident de sécurité fait à un compte partagé
Le partage de machine ne se lit pas seulement dans le temps de réponse. Il se lit aussi le jour où un site est compromis.
La documentation de WordPress consacrée aux sites piratés contient une recommandation qui ne figure sur aucune page de présentation d’offre : prévenir son hébergeur, parce qu’une intrusion peut avoir touché davantage que le seul site concerné, et que c’est particulièrement vrai sur un hébergement partagé. L’hébergeur est aussi le seul à pouvoir dire si ce que l’on prend pour une intrusion n’est pas une interruption de service.
Le même document décrit un effet de bord propre au partage, et qui surprend toujours. Quand un site est détourné pour envoyer du courrier indésirable, ce sont les adresses réseau du serveur qui se retrouvent signalées, et ces adresses sont souvent celles qui servent aussi à la messagerie. Le courrier légitime part alors en indésirable, y compris celui qui n’a rien à voir avec le site en cause.
La conséquence pratique est que la remise en état d’un site ne se termine pas au nettoyage des fichiers. Il reste à constater où le domaine ou le serveur a été signalé, ce que la documentation recommande de suivre en inscrivant le site aux consoles pour webmestres des moteurs de recherche. C’est aussi ce qui distingue une restauration après piratage d’une simple remise en ligne de sauvegarde.
Questions fréquentes
Un site mutualisé est-il moins sécurisé ?
Le partage de machine n’expose pas vos fichiers aux autres comptes, qui sont cloisonnés. La documentation de WordPress recommande toutefois de demander à l’hébergeur sous quel compte les applications PHP sont exécutées : un serveur qui les exécute sous le nom de chaque compte plutôt que sous un utilisateur partagé isole mieux les sites entre eux. La question se pose donc au moment de choisir.
Comment savoir si mes voisins me ralentissent ?
En regardant la variabilité plutôt que la moyenne. Un temps de réponse stable à une valeur élevée désigne le site. Un temps de réponse qui passe du simple au triple selon l’heure, sur une page inchangée, désigne l’environnement. La comparaison avec une page témoin, non modifiée, sert exactement à faire cette part.
Mutualisé ou serveur virtuel privé ?
La différence utile n’est pas la puissance brute mais la prévisibilité et la responsabilité. Un serveur virtuel privé donne des ressources réservées, et transfère au client l’administration système : mises à jour du système, pare-feu, supervision. Ce transfert est un coût, en argent ou en temps, qu’il faut compter dans la comparaison.
Le mutualisé pénalise-t-il le référencement ?
Ce qui compte pour la mesure d’expérience de page est le temps réellement vécu par les visiteurs, quelle que soit la famille d’hébergement. Un site rapide sur du mutualisé n’est pas désavantagé. Ce qui pénalise, c’est un temps de réponse élevé, et il se constate avant de s’expliquer.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.