Le vrai critère : qui applique les correctifs
La question « lequel est le plus puissant ? » mène presque toujours au VPS. La question utile pour une agence est une autre : quand une faille critique sort un mardi soir, qui applique le correctif sur le serveur de ce client ? Sur un hébergement mutualisé cPanel, c'est l'hébergeur. Le noyau, l'interpréteur PHP, le pare-feu du serveur et la supervision de la machine ne sont pas à votre charge, et vous gardez la relation avec le client. Sur un VPS, tout cela devient votre périmètre dès la première minute, week-ends compris. Ce n'est pas un défaut du VPS : c'est le prix de la liberté qu'il offre, avec le root, les services persistants et une pile sur mesure. Le tableau suivant place chaque critère face à la personne qui s'en charge, parce que cette ligne, bien plus que les chiffres de RAM, change votre charge de travail. Ici, on raisonne en responsabilités, pas en performance brute.
Mutualisé et VPS, critère par critère
Faites défiler le tableau
| Critère | Hébergement mutualisé (qui s'en charge) | VPS (qui s'en charge) |
|---|---|---|
| Accès root | Non, comptes cPanel cadrés : l'hébergeur | Oui, complet : l'agence |
| Isolation entre sites | Comptes cPanel isolés les uns des autres : l'hébergeur | Un VPS par client, ou rayon d'explosion commun si plusieurs sites cohabitent : l'agence |
| Mises à jour du noyau | Appliquées sur la machine mutualisée : l'hébergeur | Mise à jour puis redémarrage planifiés : l'agence |
| Mises à jour de PHP | Correctifs poussés sur le serveur : l'hébergeur | Paquets à mettre à jour et à tester : l'agence |
| Pare-feu | Pare-feu du serveur : l'hébergeur | À configurer et à tenir à jour : l'agence |
| Sauvegardes | Selon le plan, hebdomadaires en entrée de gamme et quotidiennes sur Pro et Agency : l'hébergeur | Stratégie à définir et à tester : l'agence |
| Supervision | Machine supervisée par l'hébergeur, site surveillé par vous : partagé | Disponibilité, disque, certificats, services : l'agence |
| Montée en charge | Limites par compte, puis plan supérieur ou VPS : l'hébergeur et l'agence | Ressources ajustées à la demande, architecture à votre main : l'agence |
PHP2Shell : le correctif PHP, côté mutualisé et côté VPS
Le 21 octobre 2026, le projet PHP a publié l'avis de CVE-2026-109619, surnommée PHP2Shell, une exécution de code à distance classée critique et corrigée dans PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Sur mutualisé, l'hébergeur applique le correctif ; sur VPS, c'est à vous de mettre PHP à jour sur chaque machine, puis de recharger PHP-FPM. L'article dédié à PHP2Shell détaille l'inventaire et les parades.
Fragnesia : quand le noyau est celui de l'agence
Fragnesia (CVE-2026-46300) est une faille du noyau Linux qui permet une élévation locale vers root. Sur mutualisé, l'hébergeur planifie la mise à jour du noyau ; sur VPS, le noyau est celui de l'agence, donc sa fenêtre de maintenance et son redémarrage, car un VPS jamais redémarré garde l'ancien noyau en mémoire. Contrôlez le noyau actif avec uname -r. L'article dédié à Fragnesia détaille la faille et les parades.
Isolation et sauvegardes : ce qui protège un client des autres
Sur un hébergement mutualisé, chaque site vit dans un compte cPanel isolé : un site compromis ne donne pas, en principe, accès aux fichiers du voisin. Sur VPS, l'isolation dépend de votre découpage. Un VPS par client trace une frontière nette, mais multiplie les machines à tenir à jour. Plusieurs sites mélangés sur un même VPS réduisent la facture, mais partagent un rayon d'explosion commun : un plugin vulnérable sur un site expose tous les autres, et un accès root volé les emporte tous. Pour les sauvegardes, ne généralisez pas. Sur mutualisé, la fréquence dépend du plan : hebdomadaire en entrée de gamme, quotidienne sur les plans Pro et Agency. Vérifiez la fiche du plan avant de promettre une fréquence de restauration à un client. Sur VPS, rien n'est décidé à votre place : la stratégie de sauvegarde, sa destination hors de la machine et surtout le test de restauration sont à définir et à vérifier par l'agence. Une sauvegarde jamais restaurée reste une hypothèse.
Combien d'heures de maintenance par mois et par site
Les chiffres du tableau ci-dessous ne sont pas un benchmark : ce sont les hypothèses de cet article, à remplacer par vos propres mesures. Elles supposent un VPS Linux standard par client, tenu par une personne compétente, face à un site sur compte mutualisé dont l'hébergeur tient la machine. Le total donne l'ordre de grandeur : environ 0,75 h par mois et par site en mutualisé, contre environ 4,5 h par mois et par VPS. Pour douze clients, cela représente 9 h contre 54 h par mois. Comparez avec votre taux horaire interne : si l'écart d'heures, valorisé à ce taux, dépasse l'écart de prix mensuel, à période de facturation égale, entre 799 DH/an et 99 DH/mois, le VPS coûte plus cher que son tarif affiché. Regrouper plusieurs sites sur un VPS divise les heures par site, mais agrandit le rayon d'explosion. L'option administration VPS peut déplacer une partie de ces heures vers ServOrbit ; vérifiez son périmètre sur la page VPS. Les guides du blog sont fournis, sans prise en charge.
Hypothèse de l'article : heures de maintenance par mois
Faites défiler le tableau
| Tâche | Mutualisé (par site) | VPS (par serveur) |
|---|---|---|
| Noyau et redémarrages | 0 h | 0,5 h |
| PHP et paquets système | 0 h | 1 h |
| Pare-feu et durcissement | 0 h | 0,5 h |
| Sauvegardes et test de restauration | 0,25 h | 1 h |
| Supervision et alertes | 0,25 h | 0,75 h |
| Incidents et astreinte | 0,25 h | 0,75 h |
| Total | 0,75 h | 4,5 h |
Grille de décision : cinq questions oui ou non
Le trafic dépasse-t-il durablement les limites du plan ?
Non : le mutualisé suffit. Oui, de façon soutenue et pas sur un pic isolé : passez à la question 2. Un pic ponctuel se traite d'abord par le cache et par le plan supérieur.
Le client a-t-il plusieurs sites ou des services lourds ?
Non : restez en mutualisé tant que les limites de processus tiennent. Oui : le VPS devient crédible, passez à la question 3.
Avez-vous besoin de root ou de services persistants ?
Non : le mutualisé reste le choix par défaut. Oui, pour un démon, une file de tâches, un moteur de base spécifique ou une pile non standard : le VPS est justifié, passez à la question 4.
Faut-il isoler ce client des autres ?
Oui, pour des données sensibles ou une exigence contractuelle : prévoyez un VPS dédié à ce client. Non : l'isolation par compte cPanel du mutualisé suffit déjà.
Avez-vous la compétence d'administration et l'astreinte ?
Non : n'ouvrez pas de VPS sans administration prévue, restez en mutualisé ou étudiez l'option administration VPS. Oui : le VPS est validé, et vous budgétez les heures du tableau précédent.
Les signaux qui justifient de changer de modèle
Un hébergement ne se choisit pas une fois pour toutes. Deux familles de signaux déclenchent une migration, dans un sens comme dans l'autre. Vers le VPS, ce sont des contraintes techniques qui se répètent : le même plafond atteint chaque mois, un service que le mutualisé n'autorise pas. Vers le mutualisé, c'est l'inverse : la machine coûte plus de temps qu'elle ne rapporte. Notez la date et la cause de chaque incident lié aux limites ou à l'administration. Règle pratique de cet article : un incident isolé est un accident, trois en un trimestre sont un signal.
Sept signaux de migration
- Vers le VPS : processus ou mémoire limités — les erreurs de limite reviennent malgré l'optimisation du site, le plafond du plan est atteint.
- Vers le VPS : root ou services persistants — le projet exige un démon, un worker, un moteur de recherche ou une version système que le mutualisé n'offre pas.
- Vers le VPS : charge soutenue — la charge reste haute sur plusieurs semaines, pas seulement lors d'une campagne ponctuelle.
- Vers le VPS : pare-feu ou pile spécifique — une règle réseau, un reverse proxy ou un runtime précis devient une exigence du client.
- Vers le mutualisé : peu de trafic — le site tient largement dans un plan mutualisé et le VPS dort la plupart du temps.
- Vers le mutualisé : aucune compétence d'admin disponible — personne dans l'équipe ne peut appliquer un correctif noyau ou PHP dans la journée.
- Vers le mutualisé : astreinte supérieure à la valeur — les heures de maintenance dépassent ce que le client paie pour le site.
Migrer en limitant l'interruption : six étapes
Sauvegarder la source
Faites une sauvegarde complète des fichiers et de la base, puis vérifiez qu'elle se restaure sur une machine de test avant de toucher à quoi que ce soit.
Réduire le TTL du DNS
Au moins 24 à 48 heures avant la bascule, ramenez le TTL des enregistrements à 300 secondes, puis contrôlez avec
dig +short votre-domaine.com.Monter la cible
Installez la pile sur le VPS, ou créez le compte cPanel, copiez les fichiers et la base, puis reprenez la configuration PHP et les tâches planifiées.
Tester avant la bascule
Testez la cible sans toucher au DNS avec
curl -I --resolve votre-domaine.com:443:IP_CIBLE https://votre-domaine.com/, puis parcourez formulaires, paiement et envoi de mails.Basculer
Gelez les écritures côté source si le site en reçoit, refaites une copie finale de la base, puis changez l'enregistrement A. Gardez le TTL court pendant la bascule.
Surveiller et clôturer
Surveillez les journaux pendant 48 heures, gardez la source intacte quelques jours, puis remontez le TTL et retirez l'ancien environnement.
Règle d'arbitrage pour un portefeuille
Partez du mutualisé pour chaque nouveau site client, et ne passez au VPS que sur un signal écrit : une limite atteinte, un besoin de root, une exigence d'isolation. Tenez un tableau par client avec le modèle, la date de la dernière mise à jour du noyau et de PHP, et la dernière restauration testée. Un VPS dont la ligne n'est pas à jour est une dette que vous portez à la place du client.
La documentation officielle
Avis de sécurité PHP2Shell (GitHub, projet PHP) : https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
Fiche Debian de Fragnesia : https://security-tracker.debian.org/tracker/CVE-2026-46300
Présentation de Fragnesia par Security Affairs : https://securityaffairs.com/192145/security/linux-kernel-bug-fragnesia-allows-local-root-access-attacks.html
Versions de PHP prises en charge : https://www.php.net/supported-versions.php
