Passez de l’hébergement mutualisé à un VPS lorsque votre application nécessite des logiciels, une configuration ou des ressources que l’environnement partagé ne peut pas fournir, et que quelqu’un peut administrer le serveur. Un VPS non infogéré vous donne le contrôle du système invité. Il vous rend aussi responsable de sa maintenance et de celle des applications qui s’y exécutent.
La croissance seule ne justifie pas une migration. Partez d’une limite précise, de preuves de ses effets et d’un plan d’exploitation.
Qu’est-ce que l’hébergement mutualisé ? WordPress, TYPO3 et Joomla expliqués
L’hébergement mutualisé signifie que plusieurs comptes clients utilisent une plateforme exploitée par un fournisseur et partagent ses ressources serveur. Vous gérez votre site dans un compte, généralement sans administrer le système du serveur.
Les offres peuvent être appelées hébergement web, hébergement de sites, hébergement WordPress, hébergement TYPO3 ou hébergement Joomla. Une appellation liée à un CMS décrit l’application prise en charge, pas nécessairement l’infrastructure : WordPress peut fonctionner en mutualisé ou sur VPS. Vérifiez le contenu de l’offre, pas seulement son nom.
Une offre classique d’hébergement web infogéré fournit généralement :
- Serveur web et PHP : pour servir les pages et exécuter les applications web compatibles.
- Service de base de données : généralement MySQL ou MariaDB pour le contenu et les réglages du CMS.
- Accès aux fichiers : FTP, FTPS, SFTP ou gestionnaire de fichiers dans le navigateur, selon l’offre ; privilégiez une option chiffrée.
- Messagerie, souvent incluse : boîtes accessibles par IMAP ou POP3, envoi par SMTP et parfois webmail. La messagerie peut aussi être un service distinct.
Le fournisseur maintient les services serveur inclus. Vous gérez le contenu, les utilisateurs et la configuration du site. Ne supposez pas que « entièrement infogéré » couvre aussi les mises à jour du CMS, des plugins, des extensions et des thèmes, les tests de compatibilité ou la restauration du site : vérifiez le responsable de chaque tâche. Les conseils d’hébergement WordPress présentent les mises à jour et les sauvegardes comme des fonctionnalités supplémentaires qu’un hébergeur peut proposer.
Un VPS non infogéré repose sur un autre modèle : vous installez et maintenez les logiciels web, ou confiez ce travail à quelqu’un. Un panneau de gestion de sites prêt à l’emploi et un service de messagerie ne sont pas automatiquement inclus. Vous pouvez déplacer le site tout en gardant la messagerie ailleurs.
Une vérification rapide pour décider
- Restez en hébergement mutualisé si votre site fonctionne de façon fiable, si les logiciels disponibles répondent à ses besoins et si vous appréciez que l’environnement soit maintenu pour vous.
- Analysez et optimisez d’abord si le seul symptôme est un site lent. Vérifiez le cache, les images trop lourdes, les plugins, les requêtes de base de données et les services externes avant de changer d’infrastructure.
- Envisagez un VPS si une restriction confirmée empêche le travail nécessaire et si vous, ou un administrateur désigné, pouvez assumer la sécurité, la maintenance et la récupération.
Comparaison entre hébergement mutualisé et VPS non infogéré
Les offres mutualisées varient : vérifiez les limites et le périmètre réels de votre fournisseur. Le comparatif ci-dessous décrit des pratiques courantes, pas des garanties applicables à toutes les offres.
| Domaine | Hébergement mutualisé | VPS non infogéré |
|---|---|---|
| Souplesse logicielle | Choix parmi les logiciels et versions pris en charge par le fournisseur. | Installation de logiciels compatibles dans les limites du système invité et du service. |
| Accès root | Généralement indisponible ; accès limité à votre compte. | Accès administratif au système de votre serveur virtuel. |
| Contraintes de ressources | Quotas du compte et limites de processus définis par le fournisseur. | Allocations de l’offre et limites imposées par les logiciels et la plateforme. |
| Administration | Le fournisseur maintient la plateforme ; vous maintenez votre site. | Vous administrez le système invité, les services et les applications. |
| Mises à jour de sécurité | Le fournisseur met à jour la plateforme ; un responsable reste nécessaire pour les applications. | Vous planifiez et appliquez les mises à jour du système invité et des applications. |
| Sauvegardes | Inclusion, conservation et restauration selon l’offre. | Vous organisez et testez vos sauvegardes et votre récupération. |
| Coût total d’exploitation | Abonnement, éventuels suppléments et maintenance applicative. | Serveur, temps d’administration, sauvegardes, surveillance et licences éventuelles. |
Un VPS est une machine virtuelle, pas un serveur physique dédié. Une allocation vCPU ne signifie pas qu’un cœur physique vous est réservé exclusivement. Consultez le fonctionnement de la plateforme VPS KVM d’EDIS Global pour comparer le service sous-jacent.
Les signes qu’un VPS peut résoudre un vrai problème
Vous avez besoin de logiciels absents de la plateforme mutualisée
Un environnement d’exécution, un paquet système, Docker ou une extension de base de données peut être indisponible dans votre compte. Demandez à l’hébergeur s’il le prend en charge. Un VPS est pertinent si vous devez installer et configurer vous-même un ensemble logiciel compatible.
Vous avez besoin de processus persistants
Les environnements mutualisés peuvent restreindre les tâches en arrière-plan, les files, les services persistants ou les tâches planifiées. Sur un VPS, vous les configurez, surveillez leurs défaillances et empêchez les processus incontrôlés d’épuiser la mémoire.
Une limite de ressources mesurée interrompt régulièrement le travail
Analysez les erreurs mémoire répétées, les limites de processus ou la pression CPU à l’aide des journaux et des mesures. Optimisez d’abord, puis testez une charge représentative sur le VPS envisagé. Un serveur plus gros ne corrige pas automatiquement une requête lente.
Vos déploiements nécessitent plus de contrôle
Des réglages personnalisés du serveur web, des déploiements reproductibles et la préproduction peuvent justifier un VPS. Documentez les dépendances et la configuration. Une préproduction sur le même VPS partage toujours les ressources et les risques de panne ; elle ne constitue pas une infrastructure de récupération indépendante.
Quand rester en mutualisé est judicieux
Si les fonctions standard du site suffisent et les temps de réponse sont acceptables, migrer peut ajouter du travail sans résoudre de problème. Vérifiez si une modification de configuration ou une autre offre mutualisée répond plus simplement à la limite réelle.
Un VPS non infogéré convient mal si personne ne peut le maintenir. Un panneau facilite certaines tâches, mais n’assume pas les mises à jour, les incidents ou les restaurations. Prévoyez un administrateur compétent ou choisissez un service dont le contrat d’infogérance couvre votre besoin.
Plus de contrôle implique une administration continue
EDIS Global gère l’infrastructure sous-jacente. Vous gérez le système invité et les applications du VPS. Son périmètre d’assistance documenté comprend l’aide sur l’infrastructure et les conseils de dépannage ; il ne comprend pas la connexion à votre serveur pour installer des logiciels ou effectuer la migration.
Avant de migrer, désignez un responsable des mises à jour système et applicatives, de l’accès administratif, du pare-feu, des certificats TLS et de leurs renouvellements. Déterminez qui reçoit les alertes et comment agir en cas d’indisponibilité. Conservez les notes de configuration et une procédure de récupération accessibles hors du VPS.
Les sauvegardes nécessitent un plan distinct. Ne supposez pas que les sauvegardes automatiques ou les instantanés immédiats sont inclus. Conservez des copies restaurables hors du serveur, protégez leur accès et testez la restauration. La documentation de sauvegarde EDIS Global explique les limites actuelles du service. Le guide des responsabilités sur un VPS non infogéré détaille la répartition des tâches.
Dimensionnez le VPS à partir de mesures
Mesurez votre charge actuelle en période normale et chargée. Incluez les tâches planifiées, les imports et les sauvegardes, qui peuvent consommer plus que les requêtes web habituelles. Si l’hébergeur mutualisé ne fournit pas de mesures utiles, recueillez les temps et journaux applicatifs, puis testez une copie réaliste avant de vous engager.
- CPU : examinez la charge soutenue et les pointes, notamment la compression, la génération de rapports et les tâches simultanées.
- RAM : additionnez les besoins du système, de l’application, de la base et des processus simultanés. Gardez une marge pour les déploiements et les pics.
- Stockage : prévoyez les données actives, la croissance des bases, les journaux, les fichiers temporaires et la préparation des sauvegardes. Une sauvegarde conservée uniquement sur le même disque n’est pas une copie de récupération indépendante.
- Trafic : estimez les transferts dans les deux sens, y compris les téléchargements, la réplication et les sauvegardes hors serveur. Comparez le quota séparément du débit de la liaison hôte.
Il n’existe pas de formule fiable liant le nombre de visiteurs à la RAM. Une page statique en cache et une application sollicitant fortement une base peuvent avoir des besoins très différents avec le même public. Utilisez les pages VPS 2 Go et VPS 4 Go pour comparer les configurations de base actuelles après estimation de vos besoins, pas comme des garanties de capacité de trafic. Les mises à niveau payantes ajoutent des ressources et un coût ; vérifiez l’offre choisie et le total à la commande.
Préparez la migration avant de changer le DNS
- Inventoriez les dépendances et la messagerie. Listez les environnements d’exécution, extensions, bases, tâches planifiées, permissions, enregistrements DNS et boîtes mail. Décidez où restera la messagerie ; déplacer le site n’oblige pas à déplacer les e-mails.
- Sauvegardez et testez une restauration. Enregistrez les fichiers, les exports de bases et la configuration. Vérifiez que la sauvegarde permet de reconstruire l’application avant de vous y fier.
- Préparez et sécurisez le VPS. Choisissez un système compatible, configurez les accès et le pare-feu, appliquez les mises à jour et mettez en place la surveillance et les sauvegardes. Utilisez la documentation de démarrage pour les procédures d’accès et de gestion de la plateforme.
- Testez l’application et TLS. Vérifiez l’authentification, les formulaires, les téléversements, les tâches, les e-mails sortants et le renouvellement des certificats. Utilisez un nom de préproduction ou une entrée locale dans le fichier hosts, sans exposer de données de test privées.
- Coordonnez le DNS et la synchronisation finale. Prévoyez une fenêtre de maintenance si les écritures doivent être arrêtées. Tenez compte du cache DNS, synchronisez les changements récents et évitez les écritures contradictoires sur les deux copies.
- Conservez un retour arrière possible. Gardez l’ancien environnement jusqu’à validation du nouveau. Définissez les critères de retour arrière et la conservation des données écrites après le basculement avant de rétablir le trafic.
Une migration réussie signifie que l’application fonctionne, que les données sont cohérentes et que quelqu’un peut les restaurer ; le chargement de la nouvelle page d’accueil ne suffit pas.
Questions fréquentes
Non. Les performances dépendent de l’application, de sa configuration et des ressources disponibles. Identifiez le facteur limitant et testez l’environnement envisagé. Davantage de ressources ne corrige pas automatiquement des requêtes inefficaces, des images trop lourdes ou des services tiers lents.
Partez de la consommation mémoire mesurée, de la pile logicielle et du nombre de processus simultanés. Incluez les besoins du système et une marge. Il n’existe pas de quantité unique de RAM ni de seuil de visiteurs qui impose le passage au VPS.
Oui, si votre service de messagerie reste disponible indépendamment. Conservez les enregistrements DNS nécessaires au courrier et vérifiez l’envoi et la réception après la migration du site. Vérifiez les dépendances de votre offre avant de résilier l’ancien hébergement.
Vous devez avoir les compétences nécessaires ou désigner une personne pour exploiter le serveur. Si personne ne peut prendre en charge les mises à jour, la supervision, la sécurité et la restauration, organisez l’administration avant de migrer un site de production vers un VPS non infogéré.
Choisissez l’environnement nécessaire à votre application, puis comparez les ressources. Découvrez les offres VPS Linux pour examiner les systèmes disponibles, ou consultez la présentation de l’hébergement VPS pour choisir un emplacement et une offre. Fondez toujours la décision de migrer sur un besoin vérifiable.