De quel serveur avez-vous vraiment besoin ? Dimensionner le CPU, la RAM et le stockage par charge de travail

D'abord la réponse : la méthode

Le dimensionnement est le produit de trois chiffres, pas une estimation au hasard :

1. Référence : ce que la charge de travail consomme en charge normale. Mesurez-la si la charge de travail existe déjà quelque part aujourd'hui (un VPS, une machine de staging, votre ordinateur portable sous test de charge) ; estimez-la à partir des règles empiriques ci-dessous si ce n'est pas le cas.
2. Marge : multipliez par 1.5–2×. La marge absorbe les pics de trafic, les tâches de fond et la chute de performance que rencontre tout système près de la saturation (une base de données à 90% de RAM se comporte bien plus mal qu'une à 60%, pas seulement 30% plus mal).
3. Croissance : projetez sur toute la durée d'engagement, pas sur la semaine de lancement. Si les données croissent de 10 GB/mois, un an en demandera 120 GB de plus qu'aujourd'hui.

Et une règle-cadre qui évite la catégorie d'erreur la plus coûteuse : dimensionnez la RAM et le stockage largement, le CPU modérément. Un CPU sous-dimensionné ralentit les choses ; une RAM insuffisante ou des disques pleins les font planter. Le CPU est aussi la ressource que les charges de travail surestiment le plus souvent (la plupart des serveurs sont inactifs la plupart du temps), tandis que la RAM est celle qu'elles sous-estiment le plus souvent.

Si vous voulez simplement des valeurs par défaut, voici des points de départ honnêtes ; le reste de l'article est le raisonnement qui permet de les ajuster :

CPU : cœurs contre fréquence

La course aux cœurs occulte la question qui compte vraiment : votre charge de travail est-elle parallèle ou séquentielle ?

• Les charges de travail parallèles (virtualisation, CI, encodage vidéo, API à fort trafic de requêtes) évoluent avec le nombre de cœurs. Achetez des cœurs.
• Les charges de travail séquentielles (ticks de serveur de jeu, boucles applicatives single-thread, nombreux chemins de requête en base de données) sont limitées par la vitesse d'un seul cœur. Achetez de la fréquence (et une microarchitecture plus récente), pas des cœurs ; soixante-quatre cœurs lents perdent face à huit cœurs rapides, et c'est l'erreur de dimensionnement la plus courante pour les serveurs de jeu.
• Réalité mixte : une stack web est parallèle entre les requêtes, mais chaque requête est elle-même séquentielle, donc un nombre de cœurs intermédiaire avec de bonnes performances par cœur convient le mieux, et c'est pourquoi c'est le point d'équilibre où atterrissent la plupart des charges de travail web.

Notes pratiques : les hyperthreads ne sont pas des cœurs (comptez-les comme ~+20–30% de débit, pas ×2) ; les hôtes de virtualisation peuvent surallouer le CPU de façon significative (les guests atteignent rarement leur pic en même temps, d'où le ×0.7 dans le tableau), mais ne doivent jamais surallouer la RAM.

RAM : la ressource sur laquelle vous regretterez d'avoir lésiné

Des règles empiriques qui tiennent la route :

• Bases de données : l'ensemble de travail (les données réellement touchées régulièrement) doit tenir en RAM, avec de la marge. Le levier de performance le plus important pour une base de données n'est pas le réglage des requêtes, mais le fait que les lectures viennent de la mémoire ou du disque. Estimez l'ensemble actif (souvent 10–30% des données totales), ajoutez les index, multipliez par 1.5.
• Virtualisation : la RAM est la contrainte limitante pour la densité de VM dans presque tous les déploiements réels. Les hôtes manquent de mémoire bien avant de manquer de CPU. Additionnez les allocations de vos guests, ajoutez 4–8 GB pour l'hôte (plus avec ZFS : son cache consommera avec plaisir et utilité tout ce qui est disponible).
• Web/app : processus applicatifs × empreinte par processus, plus les caches d'opcode/objets, plus le cache de fichiers de l'OS (c'est pourquoi de la RAM « inutilisée » accélère vos lectures disque : Linux utilise chaque gigaoctet inactif comme cache).
• Le mode de défaillance à éviter est le swap sous charge : quand la RAM vient à manquer, la performance ne se dégrade pas progressivement, elle s'effondre pendant que le disque thrashe. Si le monitoring montre la moindre activité de swap soutenue en charge normale, le serveur est déjà sous-dimensionné aujourd'hui, pas bientôt.

Stockage : la capacité est la moitié facile

• Capacité : données actuelles × croissance sur la durée + 30% de marge (les disques pleins corrompent les bases de données et bloquent les déploiements aux pires moments). Appliquez ensuite le surcoût du RAID. La capacité utilisable n'est pas la capacité brute, et cette différence est le sujet de notre guide des niveaux RAID : les miroirs la divisent par deux, la parité coûte un disque.
• Performance : pour tout ce qui est sensible à la latence (bases de données, stores de VM, applications web très sollicitées), la réponse en 2026 est le NVMe, un point c'est tout : l'écart d'I/O aléatoire face aux SSD SATA est important, et face aux HDD il est catégorique. Les disques mécaniques ne conservent qu'un seul rôle : la capacité en masse bon marché pour les médias, les archives et les cibles de sauvegarde, idéalement derrière une couche NVMe pour le chemin actif.
• Endurance : les charges de travail à forte écriture (bases de données avec beaucoup de churn, scratch de CI, ingestion vidéo) consomment l'endurance en écriture des SSD. C'est rarement un problème aux intensités habituelles, mais si vous prévoyez de réécrire plusieurs TB par jour, mentionnez-le lors de la spécification : des disques de qualité datacenter avec des indices d'endurance plus élevés existent pour exactement ce cas.

Bande passante : du calcul, pas du feeling

Convertissez le volume mensuel en débit soutenu avec un seul facteur : 1 TB/mois ≈ 3 Mbit/s de moyenne soutenue. Un port à 1 Gbit/s, saturé au maximum, déplace donc ~330 TB/mois, ce qui indique immédiatement que la plupart des charges de travail ne sont absolument pas limitées par le port en volume. Ce qui détermine réellement la spécification réseau :

• Des pics, pas des moyennes. Le trafic est en rafales ; un site qui fait 30 Mbit/s de moyenne peut grimper à plusieurs centaines lors d'un lancement. La vitesse du port achète de l'absorption de rafales.
• Le trafic est-ouest (réplication, sauvegardes, synchronisation de stockage entre vos propres serveurs) est là où le 10 Gbit/s se rentabilise bien avant le trafic public. (Calcul de la fenêtre de sauvegarde : restaurer 4 TB sur 1 Gbit/s prend ~9 heures ; sur 10 Gbit/s, moins d'une heure. Dimensionnez le port pour la restauration que vous devrez un jour affronter en sueur.)
• La latence est une propriété de l'emplacement et du réseau, pas de la vitesse du port ; les serveurs de jeu et les applications temps réel doivent d'abord choisir la proximité du datacenter et la qualité du réseau (c'est là qu'un ASN propre et bien peeré compte plus que le chiffre du port).

Scale up ou scale out ?

Quand vous dépassez les capacités d'un serveur, il y a deux directions possibles, et la bonne dépend de la forme de la charge de travail :

Le scale up (un serveur plus gros) tant que c'est possible : c'est opérationnellement gratuit (pas de changement de code, pas de coût des systèmes distribués), et le matériel dédié monte très haut avant d'atteindre son plafond. Les bases de données préfèrent particulièrement cette voie ; les bases de données distribuées sont un dernier recours, pas un plan de croissance.

Le scale out (plus de serveurs) quand la charge de travail se divise naturellement : des tiers web/app sans état derrière un load balancer (c'est aussi votre stratégie de redondance : deux serveurs moyens battent un gros le jour où l'un des deux a besoin d'un redémarrage), des instances de serveur de jeu par région, des runners CI par file d'attente. La première scission classique consiste à déplacer la base de données sur sa propre machine : une migration, et les deux tiers obtiennent un profil de ressources dédié adapté à leurs besoins réels (les cœurs pour le tier web, la RAM et le NVMe pour la base de données).

Questions fréquentes

De combien de RAM ma base de données a-t-elle vraiment besoin ?

Partez de l'ensemble de données actif, pas du total : une base de 500 GB dont les requêtes touchent au quotidien 50 GB de lignes et d'index tourne très bien avec 96 GB de RAM et mal avec 16 GB, alors qu'une archive de 2 TB rarement interrogée se contente sans problème de bien moins que sa taille ne le laisse penser. Déterminez cet ensemble actif de façon empirique quand c'est possible (taux de succès du cache dans les métriques pg_stat/InnoDB sur votre système existant), ajoutez les index et 50% de marge, et revérifiez chaque année. Les ensembles actifs grandissent.

Ai-je besoin d'un port 10 Gbit/s ?

Pour du trafic public, probablement pas : à pleine saturation, 1 Gbit/s déplace ~330 TB/mois, bien au-delà des besoins de la plupart des sites. Les charges de travail qui ont vraiment besoin de 10 GbE sont celles entre serveurs : réplication de base de données, migration de VM, stockage distribué et surtout les fenêtres de sauvegarde/restauration (une restauration de plusieurs TB sur 1 Gbit/s est un incident qui dure toute la journée ; sur 10 Gbit/s, c'est une pause café). Si votre architecture inclut un transfert de données permanent entre machines, dimensionnez en conséquence ; sinon, mettez la différence dans la RAM.

Faut-il surprovisionner maintenant ou mettre à niveau plus tard ?

Surprovisionnez ce qui est perturbant à modifier (la RAM et le stockage, où une mise à niveau signifie une interruption et une fenêtre de maintenance), et achetez le CPU au plus près du besoin mesuré, car c'est le composant le moins souvent épuisé en pratique. La règle de marge de 1.5–2× intègre déjà une année de croissance confortable pour une charge de travail typique ; au-delà, évaluez honnêtement à quel point une migration serait pénible pour ce système précis. Tier sans état ? Facile à déplacer, achetez juste. Base de données avec état ? Coûteux à déplacer, achetez large.

Quand ai-je vraiment besoin d'un serveur dédié plutôt que d'un VPS ?

Dès que l'une de ces conditions est vraie : une charge CPU ou I/O soutenue que les plateformes mutualisées brident ou facturent de façon punitive ; un besoin en RAM (64 GB+) où la tarification dédiée bat des tiers VPS équivalents ; une sensibilité à la latence qui ne tolère pas de voisins bruyants ; ou le besoin d'un contrôle matériel complet : hyperviseurs, kernels personnalisés, NVMe brut. Les charges de travail en dents de scie et surtout inactives restent le terrain de prédilection du VPS ; les charges stables et sensibles aux performances basculent étonnamment tôt de l'autre côté. La section bare metal de notre guide des distributions approfondit cette frontière.

Déploiement chez Serverside

La méthode se transpose directement dans notre configurateur de serveurs dédiés : choisissez des CPU rapides par cœur ou riches en cœurs selon la forme de votre charge de travail, dimensionnez la RAM et le NVMe avec la règle de marge, et observez le calcul de capacité utilisable du RAID s'appliquer en direct au fil du choix des disques. Chaque configuration atterrit sur notre propre réseau ASN 55285 (bien peeré, avec mitigation DDoS permanente) et se provisionne en moins d'une minute, ce qui rend la stratégie « commencer raisonnablement, redimensionner en redéployant » réellement praticable.

Une fois commandé : la checklist de durcissement de la première heure, et si le plan consiste à découper le serveur en VM, nos guides Proxmox prennent le relais à partir de là.