VPS ou hébergement mutualisé : à partir de quand passer au VPS

La différence, point par point

Sur un hébergement mutualisé, l'hébergeur administre un serveur qu'il partage entre de nombreux clients : même système, mêmes versions de logiciels, mêmes réglages pour tous, et des limites par compte pour qu'aucun site ne pénalise les autres. Sur un VPS (serveur privé virtuel), vous disposez d'un serveur isolé, avec ses propres ressources, son système et l'accès root : vous y installez ce que votre projet demande.

Les signes qu’il est temps de passer au VPS

1. Votre application n’est pas un site PHP

Une application Node.js, Python, Go ou Java tourne en continu : un processus attend les requêtes et garde son état en mémoire. Le mutualisé est construit pour l'inverse, des scripts PHP lancés à chaque requête puis arrêtés. Certains hébergeurs acceptent Node.js ou Python dans un cadre restreint (versions imposées, processus arrêtés après inactivité) ; dès que l'application grandit, ce cadre devient la contrainte principale.

2. Il vous faut un service que l’hébergeur ne propose pas

PostgreSQL, Redis, une file de tâches (RabbitMQ, Celery, BullMQ), un moteur de recherche, un navigateur sans interface pour générer des PDF ou des captures, ffmpeg pour traiter des vidéos, un modèle d'IA : tout ce qui s'installe et tourne comme un service demande un serveur où vous avez la main.

3. Vous touchez les limites du compte

Un hébergeur mutualisé borne chaque compte : temps processeur, mémoire, nombre de processus simultanés (entry processes), nombre de fichiers (inodes). Les symptômes : une page « 508 Resource Limit Is Reached », des erreurs 503 aux heures de pointe, un site lent quand un voisin est chargé, des imports interrompus. Le panneau de gestion affiche souvent ces compteurs ; s'ils touchent leur plafond régulièrement, le site a dépassé son offre.

4. Des tâches doivent tourner seules

Tâches planifiées chaque minute, traitements de fond, envois d'e-mails par lots, synchronisations : le mutualisé espace les tâches planifiées et interrompt les scripts trop longs. Sur un VPS, un worker tourne en permanence et une tâche dure le temps qu'il lui faut.

5. Vous avez besoin de régler le serveur

Une version précise de PHP ou d'une extension, la mémoire allouée à PHP, un serveur web configuré pour votre application, un pare-feu à vous, des déploiements automatisés par git ou par conteneurs Docker : autant de réglages qu'un serveur partagé ne peut pas ouvrir à chaque client.

6. Vos exigences de sécurité montent

Données de clients, obligations contractuelles, audit de sécurité : un serveur isolé, dont vous maîtrisez les accès et les journaux, se documente et se contrôle plus simplement qu'un compte sur un serveur partagé.

Et pour un site vitrine ?

Un site vitrine qui présente une activité n'a besoin ni de processus permanents ni d'une base de données réglée sur mesure. S'il vous faut surtout un site rapide, sûr et à jour, sans rien administrer, la bonne réponse n'est ni le mutualisé ni le VPS, c'est un site géré : Simafri crée votre site, l'héberge, le sécurise et le tient à jour, et vous n'avez aucun serveur à entretenir.

Ce que change le passage au VPS

Avec l'accès root vient l'entretien du système. Sur un mutualisé, l'hébergeur s'en charge sans que vous le voyiez ; sur un VPS, quatre sujets demandent une réponse :

• Les mises à jour de sécurité du système et des logiciels installés, appliquées régulièrement. Debian et Ubuntu savent installer seules les correctifs de sécurité (unattended-upgrades).
• Le pare-feu et les accès : connexion SSH par clé, ports ouverts limités au nécessaire.
• Les sauvegardes : savoir ce que l'hébergeur sauvegarde, à quelle fréquence, et ce que vous exportez en plus, à commencer par la base de données.
• La supervision : être prévenu quand le serveur ne répond plus, que le disque se remplit ou qu'un certificat arrive à expiration.

Trois façons de s'en occuper : le faire vous-même, avancer avec une assistance qui diagnostique et vous indique quoi faire, ou confier l'exploitation à une infogérance. Le choix dépend de qui, dans votre équipe, connaît Linux, et de ce que coûte une heure d'arrêt à votre activité.

Passer au VPS sans coupure

1. L'inventaire : version de PHP ou du langage, extensions, base de données et sa taille, tâches planifiées, certificats, et l'endroit où vivent vos adresses e-mail.
2. La préparation du VPS : système à jour, serveur web, langage et base de données, dans les mêmes versions que l'existant.
3. La copie : les fichiers, par rsync ou une archive, et la base, par un export puis un import.
4. Le test avant bascule : sur votre poste seulement, faites pointer le domaine vers le nouveau serveur par le fichier hosts, et parcourez le site comme un visiteur.
5. La baisse du TTL des enregistrements DNS du site à quelques minutes, la veille de la bascule, pour que le changement se propage vite.
6. La bascule : dernière copie de la base, enregistrements DNS du site pointés vers le nouveau serveur, puis surveillance des journaux. Gardez l'ancien hébergement quelques jours, le temps que tous les visiteurs arrivent sur le nouveau.

rsync -avz --progress utilisateur@ancien-serveur:/chemin/du/site/ /var/www/site/

203.0.113.10  www.votre-site.com votre-site.com

Si vos adresses e-mail sont hébergées sur le même compte mutualisé, ne changez que les enregistrements DNS du site et laissez les enregistrements MX en place : la messagerie continue de fonctionner pendant et après la bascule, et se migre à part.