Choisir un plan VPS ne consiste pas à acheter les plus gros chiffres que vous pouvez vous permettre — il s'agit d'adapter le CPU, la RAM et le NVMe à ce que votre charge de travail fait réellement, afin de payer pour la capacité que vous utilisez plutôt que pour des spécifications inutiles.
Les trois caractéristiques qui décident de tout
Au final, chaque plan VPS est un ensemble de trois ressources plus le réseau. Comprenez ce que chacune contrôle, et vous pourrez dimensionner un serveur en moins d'une minute.
vCPU
La quantité de travail exécutée en parallèle et à quelle vitesse. Détermine le débit de requêtes, la compilation, le transcodage et tout ce qui dépend du CPU.
RAM
La mémoire de travail. Les bases de données, les caches et les environnements d'exécution des applications y résident. Si elle vient à manquer, le système bascule vers le disque (swap) ou le noyau tue des processus.
Stockage NVMe
Capacité et vitesse. Le NVMe offre des IOPS bien supérieurs à un SSD SATA ou à un disque mécanique, ce qui compte pour les bases de données et les systèmes de fichiers très sollicités.
Bande passante
La quantité de données que vous pouvez transférer. Les liaisons illimitées vous évitent d'avoir à surveiller un compteur de trafic.
vCPU : cœurs contre fréquence, et pourquoi le partage compte
Un vCPU est un thread sur un cœur physique, alloué à votre VM selon un ordonnancement. Deux plans peuvent tous deux annoncer « 4 vCPU » et se comporter très différemment selon le CPU hôte et le nombre de voisins qui le partagent.
- Les tâches limitées par le CPU (encodage vidéo, compilations, traitements par lots) s'améliorent avec le nombre de cœurs et la fréquence — ajoutez des cœurs.
- Les tâches limitées par les E/S (applications web classiques en attente d'une base de données ou du réseau) saturent rarement le CPU — n'achetez pas trop de cœurs.
- Une charge soutenue à 100 % nécessite des cœurs dédiés ou non partagés ; une charge par pics se satisfait très bien de cœurs partagés.
- Ajouter des cœurs n'accélère pas un processus mono-thread — cela n'aide que si votre charge de travail s'exécute en parallèle.
Règle empirique : si votre graphique CPU dépasse rarement 60 % aux heures de pointe, vous avez assez de cœurs. Investissez plutôt cet argent dans la RAM ou un disque plus rapide.
RAM : la caractéristique la plus souvent sous-dimensionnée
La RAM est la ressource qui pose le plus de problèmes quand elle vient à manquer. Une pression sur le CPU ne fait que vous ralentir ; une pression sur la mémoire déclenche le swap et l'out-of-memory killer, qui peut mettre une base de données hors service en pleine requête.
Les bases de données adorent la RAM car elles y mettent en cache les données les plus sollicitées au lieu de solliciter le disque. Si votre working set tient en RAM, les requêtes restent rapides ; s'il déborde sur le disque, la latence grimpe fortement.
Gardez toujours une marge. Dimensionner la RAM exactement sur votre pic signifie que le premier pic de trafic ou la première fuite mémoire vous fera basculer dans le swap. Visez une utilisation de 60-70 % de la mémoire installée.
NVMe : la capacité, la moitié facile de l'équation
Le stockage a deux dimensions : la quantité que vous stockez et la vitesse à laquelle vous lisez et écrivez. Le NVMe l'emporte nettement sur la seconde, en offrant un ordre de grandeur d'IOPS en plus par rapport à un SSD SATA.
- Les bases de données, les files de messages et les serveurs de messagerie sont gourmands en IOPS — le NVMe élimine le disque comme goulot d'étranglement.
- Les applications générant beaucoup de logs ou d'écritures profitent de la faible latence d'écriture du NVMe.
- Pour les archives froides ou les sauvegardes, la capacité brute compte plus que la vitesse — un plan de stockage revient moins cher au GB.
- Dimensionnez la capacité pour vos données plus l'OS, le swap, les logs et une marge de croissance ; faire tourner un disque à 100 % corrompt les écritures.
Si vous avez surtout besoin d'espace en masse pour des sauvegardes ou des médias plutôt que d'E/S aléatoires rapides, un plan de stockage dédié vous donne la capacité sans payer le prix du NVMe sur tout le volume.
Une méthode reproductible pour dimensionner n'importe quel plan
- 1
Nommez la charge de travail
Notez précisément ce qui tourne : application web, base de données, conteneurs, serveur de jeu, VPN. Chacun a un profil de ressources différent.
- 2
Identifiez la ressource goulot d'étranglement
Déterminez si la tâche est limitée par le CPU, la mémoire ou les E/S. Cette ressource détermine le plan ; les autres doivent simplement suivre.
- 3
Dimensionnez le goulot d'étranglement avec une marge
Estimez la demande de pointe, puis ajoutez environ 30-40 % pour que les pics et la croissance ne vous forcent pas à une migration d'urgence.
- 4
Équilibrez le reste
Ajustez les autres caractéristiques pour qu'aucune ne devienne le nouveau goulot d'étranglement — des cœurs sans RAM, ou de la RAM sans NVMe, gaspillent tous deux de l'argent.
- 5
Commencez petit, ajustez selon les données
Déployez, observez les métriques réelles pendant une semaine, puis redimensionnez. Des chiffres mesurés valent toujours mieux que des estimations.
La localisation et le réseau font partie de la spécification
Le serveur le mieux dimensionné, au mauvais endroit, paraîtra quand même lent. La latence perçue par vos utilisateurs dépend de la distance physique : choisissez donc un datacenter proche de votre audience — ou, si la confidentialité est la priorité, un datacenter situé dans une juridiction favorable.
Chez ChainVPS, chaque plan est livré avec une bande passante illimitée et une protection DDoS incluse, sur 15 emplacements dont six régions à confidentialité renforcée — les Pays-Bas, la Suisse, la Roumanie, l'Islande, la Moldavie et le Luxembourg. Si vous voulez un VPS offshore payé depuis un solde crypto prépayé, cette combinaison de juridiction et d'inscription sans KYC est la raison de démarrer avec les plans /offshore-vps.
Erreurs de dimensionnement courantes
Acheter des cœurs pour une application liée aux E/S
Une application web qui attend sa base de données n'utilisera pas 8 cœurs. La RAM et le NVMe auraient été bien plus utiles.
Aucune marge de RAM
Dimensionner exactement sur le pic signifie que le prochain pic déclenchera un swap sur disque ou tuera un processus. Laissez de la marge.
Ignorer la vitesse du disque
Un disque volumineux mais lent affame une base de données. Adaptez les IOPS à la charge de travail, pas seulement les gigaoctets.
Deviner au lieu de mesurer
Déployer à l'aveugle gaspille de l'argent dans les deux sens. Les métriques vous diront la vérité en une semaine.
Faire correspondre le type de plan à la tâche
Une fois votre goulot d'étranglement identifié, le type de produit s'impose naturellement.
À retenir : dimensionnez en priorité la ressource sur laquelle votre charge de travail s'appuie le plus, gardez les autres en équilibre, laissez de la marge, et laissez les métriques réelles guider votre première montée en puissance.
De combien de vCPU ai-je vraiment besoin ?
Pour la plupart des applications web et des bases de données, 2 à 4 vCPU suffisent largement, car le travail est limité par les E/S, pas par le CPU. Seules les charges parallèles soutenues comme le transcodage ou la compilation justifient d'en prendre plus. Surveillez votre graphique CPU — s'il dépasse rarement 60 % aux heures de pointe, vous en avez suffisamment.
Vaut-il mieux plus de RAM ou un CPU plus rapide pour une base de données ?
La RAM, dans la plupart des cas. Les bases de données mettent en cache leur working set actif en mémoire, donc plus de RAM signifie moins de lectures disque lentes. Associez cette RAM à un stockage NVMe et le CPU devient rarement le facteur limitant pour des charges de requêtes classiques.
Le NVMe fait-il vraiment une différence, ou n'importe quel SSD suffit-il ?
Cela fait une différence pour tout ce qui est intensif en E/S — bases de données, messagerie, files d'attente, logs très sollicités — où le NVMe offre bien plus d'IOPS et une latence plus faible qu'un SSD SATA. Pour des sauvegardes froides ou des médias où seule la capacité compte, un volume plus lent et moins cher convient très bien.
Faut-il surdimensionner par précaution ?
Gardez de la marge, mais n'achetez pas trop. Dimensionner à environ 60-70 % de la capacité absorbe les pics sans payer pour des ressources inutilisées. Commencez de façon prudente, observez une semaine de métriques réelles, puis redimensionnez — vous pouvez recharger votre solde et monter en puissance dès que les données le justifient.
