Guide de dimensionnement d’un VPS adapté à vos besoins
Publié le 20 octobre 2026
Un VPS qui semble lent ne manque généralement pas de toutes les ressources. Il lui manque une ressource au mauvais moment : de la mémoire lors d’un pic de trafic, du CPU pendant la génération de rapports, des E/S disque pendant les sauvegardes ou de la bande passante pendant une campagne très active. Ce guide de dimensionnement des VPS vous aide à déterminer vos besoins réels avant de payer pour une capacité que vous n’utiliserez pas ou, pire encore, de déployer un serveur qui perd ses moyens dès le premier lundi chargé.
L’objectif n’est pas de choisir l’offre la plus importante. Il s’agit de donner à chaque charge de travail suffisamment de ressources pour fonctionner normalement, absorber les pics prévisibles et se rétablir correctement lorsqu’une opération prend plus de temps que prévu. Un VPS bien dimensionné doit fonctionner sans difficulté en charge normale tout en conservant une marge mesurable.
Commencez par la charge de travail, pas par l’offre
Le dimensionnement commence par déterminer ce que le serveur fera réellement. Un site vitrine, une boutique WooCommerce, une application SaaS, un environnement de développement et un serveur d’agence hébergeant plusieurs sites clients peuvent avoir un nombre de visiteurs similaire, tout en nécessitant des ressources très différentes.
Commencez par identifier les services qui partagent le VPS. Un serveur web, une base de données, des processus PHP, un cache, un relais de messagerie, des tâches en arrière-plan, des conteneurs Docker, des agents de supervision et des tâches de sauvegarde consomment chacun les ressources selon leurs propres besoins. La base de données peut nécessiter de la mémoire et un accès rapide au disque, tandis qu’un processus de traitement de file d’attente peut n’avoir besoin de CPU que quelques minutes par heure.
Examinez également les moments les plus critiques. La consommation moyenne est utile, mais c’est la consommation maximale qui détermine si les clients bénéficient d’un service réactif ou voient une page d’expiration de délai. Une boutique en ligne peut être calme pendant la nuit, puis recevoir une vague de commandes après une campagne par e-mail. Une plateforme SaaS peut fonctionner sans problème toute la journée, jusqu’au lancement des imports planifiés à minuit. Les journaux racontent la même histoire : les moyennes sont parfois flatteuses, les pics sont plus révélateurs.
Si vous remplacez un serveur existant, recueillez au moins une ou deux semaines de mesures avant de choisir la nouvelle taille. Examinez l’utilisation du CPU, la mémoire disponible, l’activité du swap, l’espace disque, le temps d’attente des E/S disque, le trafic réseau et le temps de réponse de l’application. Dans la mesure du possible, incluez l’activité normale et une période de forte activité connue.
Les quatre ressources qui déterminent la taille d’un VPS
CPU : la puissance nécessaire aux tâches actives
Le nombre de cœurs CPU détermine la quantité de tâches actives que votre VPS peut effectuer simultanément. Les sites dynamiques utilisent le CPU pour PHP, Node.js, Python, Java, les requêtes API, le traitement des images, l’indexation de recherche, le chiffrement et les tâches planifiées. Un nombre de cœurs plus élevé est particulièrement utile lorsque plusieurs requêtes ou tâches en arrière-plan doivent s’exécuter simultanément.
Pour un petit site de contenu avec mise en cache, 1 à 2 vCPU peuvent suffire. Un site WordPress ou WooCommerce très fréquenté, une petite pile applicative ou plusieurs sites à faible trafic fonctionneront généralement plus confortablement avec 2 à 4 vCPU. Les applications qui effectuent régulièrement des imports, de la conversion d’images, des tâches d’intégration continue ou exécutent plusieurs conteneurs peuvent nécessiter au moins 4 vCPU, même si le trafic est modeste.
Surveillez l’utilisation soutenue du CPU plutôt que les pics de courte durée. Un serveur qui atteint 90 % d’utilisation du CPU pendant quelques secondes lors d’un déploiement n’est pas nécessairement sous-dimensionné. Un serveur dont l’utilisation dépasse environ 70 % pendant les périodes de forte activité normales dispose de moins de marge pour absorber les pics de trafic, les analyses de sécurité et la maintenance courante.
Le dimensionnement du CPU dépend également de la conception logicielle. Une mise en cache agressive des pages peut réduire considérablement les besoins en CPU. Des requêtes de base de données mal optimisées peuvent mobiliser tous les cœurs disponibles avec une efficacité remarquable. Ajouter du CPU peut aider, mais ne devrait pas remplacer la correction d’un problème applicatif évitable.
RAM : la ressource qui évite les problèmes
La mémoire est souvent la première ressource à dimensionner avec soin. La RAM est utilisée par le système d’exploitation, les processus web, les tampons de la base de données, le cache, les conteneurs et les outils de supervision. Lorsque la mémoire physique est épuisée, Linux commence à utiliser l’espace de swap sur le disque. Le swap constitue une réserve de secours utile, mais une activité fréquente du swap est un signal d’alerte, pas une stratégie d’amélioration des performances.
Un serveur Linux léger doté d’une pile web simple peut fonctionner avec 1 à 2 Go de RAM. Pour un site web en production utilisant une base de données et un cache, 2 à 4 Go constituent un point de départ plus réaliste. Les boutiques, les installations CMS plus importantes, les sites de plusieurs clients et les serveurs d’applications nécessitent souvent 4 à 8 Go, voire plus, selon le nombre de processus de traitement et l’activité de la base de données.
Ne calculez pas les besoins en RAM uniquement à partir de la documentation de l’application. Tenez compte du comportement réel des processus. Par exemple, chaque processus PHP peut consommer une quantité importante de mémoire, et l’augmentation du nombre de visiteurs simultanés peut rapidement multiplier cette consommation. Les moteurs de base de données utilisent également la mémoire pour conserver les données fréquemment consultées et éviter de les relire constamment sur le disque.
En pratique, il est préférable de conserver de la mémoire disponible pendant les périodes de pointe et d’éviter une utilisation soutenue du swap. Si votre serveur dispose de RAM libre, mais que les temps de réponse restent médiocres, recherchez une saturation du CPU, des E/S disque, des verrous de base de données ou des retards d’API externes avant d’augmenter simplement la mémoire.
Stockage : la capacité ne fait pas tout
Le dimensionnement du stockage comporte deux aspects : l’espace nécessaire et la rapidité de réponse du disque. Un VPS peut disposer de beaucoup d’espace disque libre et malgré tout afficher de mauvaises performances si la charge de travail génère plus d’opérations disque que la couche de stockage ne peut en traiter.
Calculez l’espace nécessaire pour le système d’exploitation, les fichiers de l’application, les bases de données, les téléversements, les journaux, les fichiers temporaires et la conservation locale des sauvegardes. Prévoyez ensuite une marge de croissance. Les bases de données croissent progressivement, jusqu’à ce que ce ne soit plus le cas. Les fichiers journaux peuvent croître très rapidement en cas d’erreur applicative ; découvrir que le disque est plein à ce moment-là est particulièrement désagréable.
Pour la plupart des charges de travail en production, le stockage SSD ou NVMe constitue une base raisonnable. Un stockage rapide est important pour les requêtes de base de données, les commandes WooCommerce, l’administration d’un CMS, les mises à jour logicielles et la compression des sauvegardes. Si le temps d’attente des E/S disque augmente pendant les périodes de forte activité, le serveur attend peut-être le stockage plutôt que de manquer de CPU.
Évitez de stocker votre seule sauvegarde sur le même VPS que le service en production. Les instantanés locaux peuvent accélérer la restauration, mais des sauvegardes indépendantes vous protègent contre un éventail plus large de défaillances, notamment les suppressions accidentelles et les problèmes au niveau du serveur.
Bande passante et transfert de données : mesurez le sens du trafic
La bande passante correspond à la vitesse de la connexion. Le transfert correspond à la quantité totale de données échangées pendant une période de facturation. Les deux sont importants, mais ils répondent à des besoins différents.
Un site riche en médias, un service de téléchargement, une plateforme API ou une boutique proposant de grandes images de produits peut transférer beaucoup plus de données qu’un site web textuel ayant le même nombre de visiteurs. L’utilisation d’un CDN, l’optimisation des images, la mise en cache du navigateur et le stockage objet peuvent tous réduire le trafic provenant du VPS. Pour le trafic applicatif, tenez également compte des données sortantes : les réponses API, les sauvegardes envoyées hors site, la réplication et les données exportées par les outils de supervision quittent toutes le serveur.
La capacité réseau doit pouvoir absorber les pics prévus, tandis que le volume de transfert autorisé doit couvrir l’utilisation mensuelle avec une marge suffisante. Si votre équipe marketing prépare un lancement, dimensionnez les ressources en fonction de la campagne avant son démarrage. Les serveurs n’apprécient pas non plus les surprises.
Base de dimensionnement pratique pour un VPS
Il s’agit de points de départ, pas de règles absolues. Votre logiciel, le profil de trafic, la configuration du cache et les exigences de gestion peuvent modifier le résultat.
- Un petit site vitrine ou un serveur de développement peut généralement se contenter de 1 à 2 vCPU, de 1 à 2 Go de RAM et de 20 à 40 Go de stockage rapide.
- Un site professionnel, une petite installation CMS ou une application à faible volume de trafic fonctionne généralement bien avec 2 vCPU, 2 à 4 Go de RAM et 40 à 80 Go de stockage rapide.
- Un CMS très fréquenté, une boutique WooCommerce, un environnement d’hébergement d’agence ou un petit service SaaS nécessite souvent 2 à 4 vCPU, 4 à 8 Go de RAM et au moins 80 Go de stockage rapide.
- Une application très sollicitée en base de données, une boutique de plus grande taille, une pile conteneurisée ou une charge de travail avec des traitements réguliers en arrière-plan peut nécessiter au moins 4 vCPU, 8 Go de RAM ou plus, ainsi qu’un stockage choisi spécifiquement pour ses performances d’E/S.
La taille initiale appropriée devrait laisser une marge d’environ 25 à 40 % pendant les périodes de pointe normales. Cette marge n’est pas du gaspillage. Elle permet au service de faire face à la croissance du trafic, aux sauvegardes, aux mises à jour de sécurité et aux comportements occasionnels de l’application qui surviennent sans prévenir.
Validez le dimensionnement après le déploiement
Le dimensionnement n’est pas une décision ponctuelle. Déployez la charge de travail, surveillez-la et ajustez les ressources en fonction des données observées. Les indicateurs les plus utiles sont la charge CPU soutenue, la pression sur la mémoire, l’utilisation du swap, le temps d’attente des E/S disque, la croissance du stockage, l’utilisation du réseau et les temps de réponse réels de l’application.
Les métriques Prometheus et Grafana sont particulièrement utiles aux équipes qui souhaitent établir un lien entre l’activité de l’infrastructure et l’expérience utilisateur. Par exemple, un pic du temps de réponse qui coïncide avec un temps d’attente élevé des E/S disque indique une piste différente d’un pic associé à l’épuisement des processus PHP. La supervision transforme le redimensionnement, auparavant fondé sur des suppositions, en une tâche opérationnelle maîtrisée.
L’assistance gérée modifie également le calcul pour de nombreuses entreprises. Une équipe techniquement compétente peut préférer ajuster les processus de traitement, les caches, les paramètres de la base de données et les calendriers de sauvegarde avant de passer à un VPS plus puissant. Chez kodu.cloud, cette vérification opérationnelle contribue à rétablir le bon fonctionnement du service, plutôt que de considérer chaque alerte comme un prétexte pour acheter davantage de ressources serveur.
Anticipez la croissance sans payer pour de l’espace inutilisé
Choisissez un VPS capable de gérer votre charge de pointe actuelle tout en conservant une marge, puis vérifiez que la mise à niveau du CPU, de la RAM ou du stockage sera simple lorsque les chiffres la justifieront. Commencer avec une offre trop modeste peut entraîner des migrations urgentes. Commencer avec une offre beaucoup trop puissante peut masquer un code inefficace et grever le budget sans améliorer l’expérience client.
Examinez chaque mois l’évolution des ressources, en particulier après le lancement de nouvelles fonctionnalités, l’ajout de sites clients, la modification des politiques de sauvegarde ou une campagne marketing réussie. Un serveur devrait évoluer parce que la charge de travail a démontré qu’elle en avait besoin, pas parce que le nom de l’offre semblait rassurant. Grâce à des métriques claires et à une petite réserve de capacité, vous pouvez vous reposer pendant que l’infrastructure continue de faire son travail.
Andres Saar, ingénieur du service client