Dimensionner un VPS pour le site d'un client : RAM, CPU

Un client demande « quel VPS faut-il pour mon site ? » et la réponse, trop souvent, est une intuition. Deux erreurs en découlent. La première est de prendre le plan du dessus « par précaution » : sur un portefeuille de vingt clients, cette marge morte se paie chaque mois et grignote la marge de l'agence. La seconde est de prendre trop juste : le premier pic de trafic, une sauvegarde ou un import de catalogue fait tomber le site, et le client l'apprend avant vous.

L'objection habituelle est « pas le temps de mesurer ». La mesure tient pourtant en une heure d'observation active, avec des outils déjà présents sur toute distribution Linux. Et le premier choix n'est pas définitif : un VPS se redimensionne verticalement, c'est-à-dire que l'on passe à un plan plus gros sans reconstruire l'architecture. L'enjeu n'est donc pas de deviner juste du premier coup, mais de choisir avec des chiffres et une marge écrite, que l'on peut défendre devant le client.

Le raisonnement vaut aussi pour le professionnel qui gère son propre site, par exemple une boutique en ligne : le coût d'un plan trop gros se lit sur la facture mensuelle, celui d'un plan trop juste sur le chiffre d'affaires perdu pendant un pic de commandes. Les mêmes relevés servent alors à arbitrer en connaissance de cause, sans intermédiaire.

Ce guide traite la mesure avant achat et le choix du plan. Pour décider entre VPS et hébergement mutualisé, lisez d'abord VPS ou mutualisé pour un site client. Pour l'alerte continue une fois le VPS en production, voir alertes disque et RAM sur VPS.

La mesure se fait sur le serveur actuel du client, celui qui porte la vraie charge, et non sur une copie vide. Il vous faut un accès SSH en lecture, les droits pour lancer ps, free et df, et si possible la possibilité d'installer le paquet sysstat, qui fournit sar et conserve un historique de la charge.

Côté durée, comptez au minimum une semaine d'historique si sysstat tourne déjà, sinon une fenêtre d'observation d'au moins une heure qui contient volontairement un moment chargé : un pic de trafic connu, la sauvegarde nocturne, une tâche planifiée ou un import. Mesurer un mardi à 3 heures du matin ne dit rien du jour des soldes. Notez enfin le contexte : application (WordPress, boutique, application sur mesure), présence de conteneurs, base de données sur la même machine ou non.

Un serveur qui affiche 25 % de CPU en moyenne sur 24 heures peut être saturé pendant dix minutes chaque soir. La moyenne écrase exactement ce qui fait tomber un site. Pour dimensionner, retenez la valeur maximale observée sur la fenêtre, et vérifiez qu'elle contient le pire moment connu : pic de trafic, sauvegarde, cron lourd, import.

Si le client ne sait pas quand sont ses pics, croisez avec les journaux d'accès du serveur web et avec la date des campagnes d'emailing ou des promotions. Une semaine d'historique sar couvre un cycle complet, week-end compris. Quand le site est déjà lent, un relevé pris pendant le ralentissement vaut plus que dix relevés au calme.

La règle suivante est éditoriale, ce n'est ni une norme ni une promesse du catalogue : mémoire nécessaire = consommation au pic, plus une marge de 30 %. Le chiffre de 30 % est l'hypothèse de cet article ; elle couvre la croissance à court terme et les pics que votre fenêtre n'a pas vus. Pour le disque, comptez l'espace utilisé, plus la croissance prévue sur six mois, plus au moins 20 % libres.

Pour un site PHP-FPM, calculez la mémoire des processus plutôt que de la lire globalement : mémoire PHP = RAM mesurée par processus multipliée par pm.max_children. Mesurez la RAM par processus avec ps -eo rss,args | awk '/[p]hp-fpm: pool/ {s+=$1; n++} END {print s/n/1024 " Mo"}'. Le résultat surestime un peu, car une partie de la mémoire est partagée entre processus.

Exemple chiffré fictif : 600 Mo pour le système, le serveur web et la base de données, plus 20 processus de 60 Mo, soit 1 200 Mo, font 1 800 Mo au pic. Avec 30 % de marge, il faut environ 2,4 Go : on choisit le plan dont la RAM est immédiatement supérieure.

Une fois le site en production, quelques signaux disent que le plan est trop juste. Chacun laisse une trace précise que vous pouvez chercher sans attendre la plainte du client.

Avant de monter de plan, vérifiez que le problème est bien une question de ressources. Une requête SQL lente sature le CPU quel que soit le plan : l'index manquant se corrige, il ne se compense pas. L'absence de cache objet oblige PHP à recalculer les mêmes pages à chaque visite. Une image de 8 Mo servie telle quelle consomme de la bande passante et du temps de traitement. Enfin, augmenter pm.max_children sans augmenter la RAM provoque exactement le tué-par-le-noyau que l'on voulait éviter.

La démarche saine est de corriger ces points d'abord, de refaire un relevé, puis de dimensionner sur le résultat. Vous évitez ainsi de facturer au client un plan plus gros pour masquer un défaut de configuration.

Une fois le besoin chiffré, rapprochez-le de la gamme. Le plan VPS Start offre 2 vCPU, 4 GB de RAM et 50 GB SSD de stockage ; le plan VPS Power offre 4 vCPU, 8 GB et 100 GB SSD ; le plan VPS Business offre 8 vCPU, 16 GB et 200 GB SSD. Tarif d'entrée de la gamme : 99 DH/mois.

Choisissez le plus petit plan qui couvre votre besoin avec la marge écrite, puis laissez la scalabilité verticale faire le reste : si le relevé suivant montre que la marge fond, vous passez au plan supérieur sans changer d'architecture. Pour ne pas attendre ce relevé, branchez des alertes continues, et pour savoir si le site répond depuis l'extérieur, une sonde de disponibilité : voir le suivi de disponibilité des sites clients.