Héberger un serveur de jeu en bare metal : pourquoi le matériel dédié l'emporte

La réponse d'abord : pourquoi le bare metal l'emporte pour les serveurs de jeu

Un serveur de jeu n'est pas un serveur web. Il exécute une seule boucle de simulation qui fait avancer tout le monde du jeu sur une horloge fixe : physique, entités, joueurs, tout, dans l'ordre, sur un seul thread. Minecraft fait tourner cette boucle 20 fois par seconde, ce qui lui laisse 50 millisecondes pour terminer chaque tick. Si l'échéance est manquée, le tick déborde, le serveur prend du retard, et les joueurs le ressentent sous forme de rubber-banding, de coups enregistrés en retard et de pics de lag. Les chiffres qui décident si un serveur de jeu est agréable sont donc la vitesse par cœur et la régularité du timing, pas le nombre de cœurs ni le débit.

Voilà tout l'argument en faveur du bare metal en un paragraphe. Un VPS mutualisé place l'ordonnanceur d'un hyperviseur entre votre boucle de tick et le CPU physique. Quand un voisin sur le même hôte s'active, votre thread attend son tour, et cette attente arrive sous forme de gigue au moment précis où un tick doit se terminer à l'heure. Le bare metal vous donne la machine entière, sans rien qui vous retire le CPU pour le confier à un autre. Pour un serveur entre amis qui reste inactif la majeure partie de la journée, rien de tout cela ne compte et un VPS convient. Pour tout serveur à plein effectif avec un budget de tick serré, la machine physique l'emporte parce qu'elle supprime la seule chose qu'une boucle de tick ne supporte pas : quelqu'un d'autre qui décide quand elle a le droit de s'exécuter.

Cet article aborde :

• ce que « bare metal » signifie face à un VPS et à un panel de serveur de jeu managé
• pourquoi une charge de serveur de jeu se comporte autrement que les applications web pour lesquelles la plupart des conseils d'hébergement sont écrits
• pourquoi une fréquence élevée l'emporte sur le nombre de cœurs pour la plupart des titres, et les cas où beaucoup de cœurs se justifient
• combien de RAM les serveurs populaires demandent réellement, avec les chiffres publics pour chacun
• le stockage, les sauvegardes, et la réalité du DDoS quand on expose l'IP d'un jeu sur Internet
• l'exploitation d'un panel comme Pterodactyl ou son fork Pelican sur votre propre matériel
• la liste honnête des cas où le bare metal ne vaut pas la peine

Pour aller plus loin sur le timing, deux articles complémentaires dépassent ce panorama : bare metal contre machines virtuelles chiffre l'écart, et pourquoi la latence compte pour les serveurs de jeu traite du côté réseau.

Ce que « bare metal » veut dire concrètement

Il existe trois façons de faire tourner un serveur de jeu, et ce qui les distingue, c'est qui contrôle le CPU.

L'hébergement de serveur de jeu managé. Vous louez un slot pour un jeu, le fournisseur gère le matériel et un panel, et vous obtenez une page web avec un bouton de démarrage et un éditeur de configuration. C'est le moyen le plus rapide de mettre un serveur en ligne et celui qui vous obligera le moins à penser à la machine. Vous obtenez aussi le CPU, la RAM et le réseau que le fournisseur a jugés suffisants pour un slot, sur du matériel partagé avec les slots d'autres clients.

Un VPS. Vous louez une machine virtuelle : une tranche d'un hôte physique, découpée par un hyperviseur comme KVM ou VMware, ou par une couche de conteneurs comme OpenVZ ou LXC. Vous avez l'accès root et pouvez installer ce que vous voulez. Ce que vous n'avez pas, c'est le CPU entier. L'ordonnanceur de l'hôte donne des cycles réels à vos cœurs virtuels quand ils sont libres, et « quand ils sont libres » dépend de ce que fait chaque autre locataire de la machine.

Le bare metal. Vous louez le serveur physique entier. Pas d'hyperviseur, pas d'autres locataires, pas d'ordonnanceur qui décide quand votre processus s'exécute. La fréquence indiquée sur la fiche technique est celle dont dispose votre boucle de tick, en permanence. Vous héritez aussi de tout ce qui accompagne une vraie machine : la totalité de la RAM, le NVMe, le port réseau, ainsi que les mises à jour et les sauvegardes qu'un hébergeur managé aurait sinon prises en charge.

Si cette distinction pèse plus lourd pour les jeux que pour la plupart des charges, c'est à cause de cet ordonnanceur, et de la façon dont un serveur de jeu utilise un CPU au départ.

Pourquoi une charge de serveur de jeu sort de l'ordinaire

La plupart des charges serveur sont des machines à débit. Un serveur web traite mille requêtes indépendantes sur tous les cœurs que vous lui donnez ; une base de données répartit les requêtes sur ses connexions. Ajoutez des cœurs et tout va plus vite. Un serveur de jeu fait l'inverse. Il fait avancer un état du monde partagé dans un ordre strict, parce que la position de l'entité B à ce tick dépend de la position de l'entité A à ce même tick : le travail ne peut pas être réparti entre cœurs sans que la simulation se contredise. La plupart des serveurs de jeu exécutent donc leur boucle principale sur un seul thread et ne s'appuient sur quelques threads supplémentaires que pour des tâches annexes comme le réseau, la génération de chunks et les E/S fichiers.

Cette boucle unique tourne contre une échéance. Les 20 ticks par seconde de Minecraft représentent un budget de 50 ms par tick ; d'autres moteurs choisissent leur propre fréquence, mais le principe reste le même. Quand le travail d'un tick tient dans son budget, le serveur conserve son tick rate complet et le monde répond bien. Quand ce n'est pas le cas, le tick déborde, le suivant démarre en retard, et le serveur soit descend à un tick rate effectif plus bas, soit accumule du lag jusqu'à rattraper son retard. Les joueurs le perçoivent comme une détection des coups défaillante et des entités qui se téléportent. L'indicateur qui le prédit n'est pas la charge CPU moyenne. C'est le temps le plus long pour terminer un tick, et le pire cas est justement ce qu'un ordonnanceur partagé rend imprévisible.

Deux autres caractéristiques s'y ajoutent :

• La sensibilité à la latence. Un tick terminé à l'heure ne sert à rien si le paquet met 120 ms à atteindre le joueur. Les serveurs de jeu se soucient du temps d'aller-retour et de la qualité du routage bien plus que de la bande passante brute, et c'est pourquoi l'emplacement du datacenter et le peering réseau comptent autant que le CPU. L'article sur la latence détaille le budget d'aller-retour par genre.
• Un CPU en rafales. La charge n'est pas constante. Un raid sur une base Rust, une machine en redstone qui se déclenche, quarante joueurs qui atterrissent au même endroit au même moment : le tick qui doit simuler tout cela est celui qui fait exploser le budget. On dimensionne pour le pic, pas pour la moyenne.

L'ennemi, c'est la gigue, pas le débit. Un serveur qui termine chaque tick en 20 ms sauf un blocage de 80 ms par minute paraît pire qu'un serveur qui prend régulièrement 35 ms, car ce blocage est l'instant où un joueur se fait tirer dessus derrière un abri. C'est la principale raison pour laquelle l'hébergement mutualisé joue contre les charges de jeu, et c'est le sujet de bare metal contre machines virtuelles.

La fréquence prime sur les cœurs, jusqu'à un certain point

La conséquence pratique de cette boucle monothread : pour un seul serveur de jeu, un CPU avec moins de cœurs, mais plus rapides, bat systématiquement un CPU avec beaucoup de cœurs lents. Notre guide de dimensionnement le dit sans détour : soixante-quatre cœurs lents perdent face à huit cœurs rapides, et c'est l'erreur de dimensionnement la plus courante pour un serveur de jeu. Une puce moderne au-delà de 5 GHz avec de fortes performances par cœur, comme le Ryzen 9950X de nos configurations pour serveurs de jeu à 4,3 GHz de base et 5,7 GHz en boost, termine un tick Minecraft ou Rust chargé plus vite qu'une plateforme serveur de 64 cœurs cadencée à 2,5 GHz, quel que soit le nombre de cœurs de la grosse puce, car la boucle ne peut en utiliser qu'un seul à la fois.

Les cœurs ne sont pas inutiles pour autant. Ils deviennent rentables dès que vous passez d'un serveur à plusieurs :

• Plusieurs instances. Dix serveurs Minecraft, ou un serveur Rust plus un cluster ARK plus quelques mondes Valheim, cela fait dix boucles monothread indépendantes ou davantage. Le nombre de cœurs redevient une question de débit : chaque instance obtient un ou deux cœurs et elles tournent en parallèle.
• Un panel. Utiliser Pterodactyl ou AMP pour héberger de nombreux serveurs de jeu sur une seule machine est par définition le cas où beaucoup de cœurs servent ; nous y revenons plus bas.
• Les tâches annexes. Même un serveur unique utilise des threads supplémentaires pour la génération de chunks, la compression et les sauvegardes. De la marge au-delà du cœur principal les tient à l'écart du chemin critique.

La règle tient donc en une ligne : des cœurs rapides pour un serveur, davantage de cœurs pour plusieurs. Une fréquence élevée est le choix par défaut, et le nombre de cœurs est ce que vous ajoutez quand la machine doit faire tourner une flotte plutôt qu'un seul monde.

Combien de RAM les serveurs populaires demandent réellement

La RAM est le domaine où des chiffres publics existent, les voici donc, tirés des recommandations de chaque jeu et du consensus des opérateurs. Considérez-les comme des chiffres par instance, et gardez en tête que les plugins, les mods et le nombre de joueurs font grimper chacun d'eux.

Les chiffres de Minecraft découlent de la façon dont le serveur Java utilise la mémoire. Les recommandations de réglage de PaperMC conseillent de lancer le serveur avec les flags d'Aikar, un ensemble d'arguments pour le garbage collector G1, et de fixer le heap initial et le heap maximal à la même valeur pour que la JVM ne le redimensionne jamais en plein tick. Sa propre remarque mérite d'être reprise : un heap de 6 GB bien réglé fait mieux qu'un heap de 12 GB mal réglé, donc ici plus de RAM ne signifie pas automatiquement plus de performances. La distance d'affichage est le multiplicateur auquel personne ne s'attend : chaque cran charge davantage de chunks par joueur et augmente à la fois la RAM et le coût par tick.

Counter-Strike 2 est léger en mémoire et exigeant sur le timing. Un serveur à vide tourne autour de 2,5–3 GB et dépasse 6 GB dès qu'on ajoute des plugins, des cartes personnalisées du Workshop et un effectif complet de 64 slots. Il est limité par sa boucle de tick et la vitesse par cœur, pas par la RAM. Valve décrit CS2 comme un serveur à 64 ticks doté d'une couche d'entrée « subtick » qui horodate chaque tir et chaque déplacement à l'instant exact où il a eu lieu, indépendamment du tick, ce qui rend encore plus important que le serveur termine son travail de façon prévisible ; la description figure sur la page Counter-Strike 2 de Valve.

Vient ensuite le haut de gamme. La configuration requise officielle de Palworld recommande 16 GB, précise que 8 GB « permet aussi de démarrer, mais augmente le risque de plantage du serveur par manque de mémoire », et renvoie à 32 GB pour les serveurs plus grands. Les opérateurs rapportent largement que sa consommation mémoire augmente à mesure que le serveur tourne, et le contournement habituel est un redémarrage planifié toutes les quelques heures. ARK: Survival Ascended est plus lourd encore ; les retours de la communauté placent le binaire serveur à 6–10 GB avant toute connexion, 16 GB comme minimum pour une seule carte, et 12–18 GB de plus pour chaque carte supplémentaire d'un cluster. Rust se situe entre les deux, à 8–16 GB selon la taille de la carte et la population, et, en tant que serveur Unity, dépend autant de la fréquence que de la RAM. Valheim est le plus modeste : sa propre documentation indique un minimum de 2 GB, même si 4–8 GB est le chiffre confortable pour un petit groupe sur un monde de longue durée.

Deux règles valent pour tous. Dimensionnez pour le soir d'affluence, pas pour l'après-midi désert ; et gardez de la marge, car un serveur de jeu à court de RAM ne ralentit pas en douceur : il plante ou se fait tuer par le noyau en pleine session. Le guide de dimensionnement détaille le calcul de la marge en termes généraux.

Stockage : NVMe, sauvegardes du monde et backups

Un monde de jeu est un ensemble de chunks ou de régions que le serveur lit et écrit en permanence au fil des déplacements des joueurs. Sur un disque mécanique, ces E/S aléatoires deviennent ce que ressentent les joueurs quand une nouvelle zone saccade au chargement. Le NVMe est la réponse, et pour un serveur de jeu ce n'est pas un luxe. Le chargement des chunks, les sauvegardes du monde et les écritures de données joueurs tombent toutes sur le chemin du tick ou à proximité, et la latence de lecture aléatoire du NVMe appartient à une autre catégorie que celle des SSD SATA, sans parler des disques durs.

Les sauvegardes du monde sont la partie que l'on sous-estime. Un monde Minecraft ou Rust très fréquenté peut atteindre des dizaines de gigaoctets, et la sauvegarde périodique en écrit une large part sur le disque. Sur un disque lent, la sauvegarde provoque elle-même un pic de lag ; sur NVMe, elle se termine assez vite pour rester hors du chemin critique. La documentation de Palworld le dit sans détour, en avertissant qu'un stockage peu performant « peut corrompre les données sauvegardées ».

Les backups sont distincts du disque rapide et ne sont pas optionnels. Un monde n'est qu'à un arrêt brutal de sa perte, et un monde saccagé par des griefers ou à remettre en arrière se restaure, il ne se répare pas. La discipline s'énonce simplement : des snapshots fréquents, conservés ailleurs que sur le même disque, testés au moins une fois pour savoir que la restauration fonctionne. Les backups hors machine couvrent aussi la panne que le NVMe rapide ne couvre pas : la mort du disque lui-même. Un RAID 1 sur deux disques NVMe vous permet de continuer à tourner après la panne d'un disque, mais ce n'est pas un backup, puisqu'il reproduit fidèlement une suppression ou une corruption sur les deux disques au même instant.

Le réseau et la réalité du DDoS

Mettre un serveur de jeu sur une IP publique, c'est publier une cible. Les serveurs de jeu attirent les attaques par déni de service plus que presque toute autre charge, pour une raison précise : les joueurs connaissent l'IP, les jeux fonctionnent en UDP, et un rival, un tricheur banni ou un service de booter payant peut diriger un flood dessus sans aucune compétence. Les floods UDP sont la forme la plus courante, car l'UDP n'a pas de handshake sur lequel limiter le débit et le trafic est facile à usurper et à amplifier.

C'est là qu'une connexion domestique ou un VPS non protégé cède. Une ligne grand public n'a ni la capacité d'absorber un flood ni aucun nettoyage en amont : l'attaque sature le lien et tous les joueurs sont déconnectés, que le processus serveur soit touché ou non. L'atténuation doit avoir lieu dans le réseau, en amont du serveur, là où la capacité suffit à absorber le volume et où un filtrage écarte les mauvais paquets tout en laissant passer le vrai trafic UDP du jeu. Le fonctionnement de ces attaques et les défenses correspondantes sont traités dans types d'attaques DDoS et protection.

Deux remarques pratiques. Un filtrage qui connaît les jeux compte, car des règles DDoS génériques qui conviennent à un site web peuvent casser un jeu : un filtre anti-flood UDP doit savoir à quoi ressemble le trafic de jeu légitime, sinon il écarte de vrais joueurs en même temps que l'attaque. Et la machine doit quand même être durcie au niveau de l'hôte, quelle que soit la protection en amont, car un flood n'est pas la seule menace pour un serveur public ; la checklist de durcissement d'un serveur Linux est la base de la première heure.

Faire tourner un panel sur votre propre matériel

Dès que vous gérez plus d'un ou deux serveurs, vous voudrez un panel plutôt qu'un empilement de sessions tmux et de scripts shell. Trois méritent d'être connus.

Pterodactyl est le standard open source. Il se compose de deux parties : le Panel, une application web PHP qui nécessite une base de données (MySQL 8.0+ ou MariaDB 10.6+), un serveur web et idéalement Redis ; et Wings, le daemon qui exécute chaque serveur de jeu dans un conteneur Docker sur l'hôte. C'est cette dépendance à Docker qui détermine votre matériel. Wings a besoin d'un hôte Linux capable de faire tourner Docker, et la documentation de Pterodactyl précise que les VPS basés sur des conteneurs, OpenVZ, LXC et Virtuozzo, ne peuvent généralement pas faire tourner Docker du tout ; KVM est le seul qu'elle garantit. En bare metal, la question ne se pose jamais, puisque le noyau vous appartient.

Pelican est un fork de Pterodactyl, lancé en 2024, qui a changé la licence du panel de MIT à AGPLv3. Sa FAQ reconnaît franchement qu'il s'agit encore d'un logiciel en bêta en 2026 : considérez-le comme l'option qui évolue vite. Choisissez-le si vous voulez un rythme de développement plus récent et acceptez une bêta, et restez sur Pterodactyl si vous préférez la version installée de plus longue date. Les deux suivent la même architecture panel plus daemon et la même dépendance à Docker, donc côté matériel la situation est identique.

AMP, l'Application Management Panel de CubeCoders, est l'alternative commerciale. Il est payant, tourne sous Linux comme sous Windows, et échange la licence open source contre la finition et le support. Si vous préférez acheter un produit supporté plutôt qu'assembler une pile, c'est celui qu'il faut regarder.

Les trois transforment un seul serveur dédié en hôte de jeux multi-locataires, c'est-à-dire le cas des nombreux cœurs évoqué plus haut, rendu concret. Chaque instance de jeu est sa propre boucle monothread, donc une machine qui fait tourner un panel a besoin à la fois de fréquences élevées, pour que la boucle de tick de chaque instance reste rapide, et d'assez de cœurs et de RAM pour en exécuter plusieurs en même temps sans que leurs boucles se disputent le temps CPU. Dimensionner la machine revient à additionner les chiffres de RAM par instance du tableau ci-dessus, plus quelques gigaoctets pour le panel et l'hôte, puis à choisir un nombre de cœurs qui couvre vos instances les plus chargées tournant toutes en même temps.

Dans notre catalogue, la configuration pour un panel et cinq à dix serveurs est le Ryzen 9 9950X : 16 cœurs à 4,3 GHz de base et 5,7 GHz en boost, 192 GB de DDR5, un disque NVMe de 1,92 TB et un réseau à 10 Gbit/s, affiché à 415 $ par mois le 24 septembre 2026 (la liste des serveurs de jeu donne le prix et le stock du jour). En appliquant le tableau de RAM, huit instances totalisent 92 GB : deux serveurs Rust à 16 GB, trois serveurs Minecraft moddés à 12 GB et trois serveurs CS2 de 24 joueurs à 8 GB. Ajoutez quelques gigaoctets pour le panel et l'hôte, et la machine utilise à peine plus de la moitié de sa mémoire, avec de la place pour une carte ARK de 32 GB. Chacune des huit boucles de tick dispose de son propre cœur, et les huit autres prennent en charge la génération de chunks, les sauvegardes et les backups. Avec un seul disque, les backups hors machine de la section sur le stockage sont la seule réponse à une panne de disque.

Quand le bare metal n'est pas nécessaire

Le bare metal est le bon outil pour un serveur plein avec un budget de tick serré. C'est le mauvais outil dans de nombreux cas réels, et prétendre le contraire vous coûterait de l'argent.

Un VPS est le meilleur choix quand :

• C'est pour quelques amis. Trois à cinq personnes sur un Valheim vanilla ou un petit SMP Minecraft ne chargent presque pas la machine, et une milliseconde de gigue de l'ordonnanceur de temps à autre passe inaperçue à cette échelle. Le minimum de 2 GB de Valheim tourne sans problème sur un petit VPS.
• C'est une seule instance légère. Un serveur peu peuplé pour un jeu peu gourmand en CPU n'a pas besoin d'une machine physique entière. Vous paieriez des cœurs qui restent inactifs.
• C'est une machine de test ou de développement. Un serveur que vous lancez, cassez et redéployez ne gagne rien à du matériel dédié. Le bon marché et le jetable l'emportent.
• La charge vient par pics et le serveur est surtout inactif. Un serveur vide la majeure partie de la semaine et plein pour une soirée de raid correspond exactement au profil pour lequel une plateforme mutualisée est tarifée.

Le point de bascule arrive quand le serveur est assez chargé, assez souvent, pour que le budget de tick devienne serré ; ou quand les besoins en RAM dépassent le seuil où le prix d'un dédié bat celui d'une offre VPS équivalente ; ou quand l'IP publique d'un jeu a besoin d'une vraie protection DDoS en amont. En dessous de cette ligne, un VPS n'est pas un compromis : c'est la bonne réponse.

Tableau de décision rapide

Où se place chaque scénario, et le facteur qui tranche :

Déployer chez Serverside.com

Un serveur de jeu récompense les deux points forts du bare metal : donner à un processus le CPU entier et rapide, et se tenir derrière un réseau capable d'encaisser une attaque. Une machine Serverside.com pour serveur de jeu tourne sur notre propre réseau (AS55285), avec une atténuation DDoS permanente devant le port UDP public et des profils de filtrage réglés par titre de jeu, si bien que le flood qui ferait tomber un serveur hébergé à domicile n'atteint jamais la boucle de tick. Les configurations à haute fréquence, comme le Ryzen 9950X, sont choisies précisément pour la boucle monothread dont parle cet article, et le provisionnement prend moins d'une minute : une machine neuve est en ligne avant que vous ayez fini de planifier le monde qu'elle fera tourner.

Si vous comparez le matériel plus largement, la gamme complète de serveurs dédiés et le guide de dimensionnement couvrent le reste, et choisir un emplacement proche de vos joueurs est un levier de performance à part entière ; notre datacenter d'Amsterdam est le point d'ancrage européen. Une fois la machine à vous, la checklist de durcissement est la première chose à y appliquer.

FAQ

Faut-il du bare metal pour un serveur de jeu, ou un VPS suffit-il ?

Cela dépend de la charge. Pour quelques amis sur un monde vanilla, un VPS suffit et coûte moins cher. Le bare metal l'emporte dès que le serveur tourne à plein effectif avec un budget de tick serré, parce qu'un VPS mutualisé place l'ordonnanceur d'un hyperviseur entre votre boucle de tick et le CPU, et que cela se traduit par de la gigue au moment précis où un tick doit se terminer à l'heure.

Pourquoi la fréquence d'horloge compte-t-elle plus que le nombre de cœurs pour un serveur de jeu ?

Parce qu'un serveur de jeu exécute sa boucle de simulation sur un seul thread. Le monde avance dans l'ordre, un tick après l'autre, et ce travail ne peut pas être réparti entre plusieurs cœurs. Un cœur plus rapide termine chaque tick plus tôt, tandis que les cœurs supplémentaires restent inutilisés par la boucle principale. Davantage de cœurs ne commencent à aider que lorsque vous faites tourner de nombreuses instances, ou un panel qui héberge plusieurs serveurs à la fois.

De combien de RAM un serveur de jeu a-t-il besoin ?

Cela varie beaucoup selon le titre. Valheim tourne avec 2 GB, un serveur Minecraft Paper avec 3–4 GB pour un petit groupe, Rust avec 8–16 GB, et Palworld comme ARK: Survival Ascended avec 16 GB ou plus par instance. Dimensionnez pour un serveur plein un soir d'affluence et gardez de la marge, car un serveur de jeu à court de RAM plante au lieu de simplement ralentir.

Peut-on faire tourner Pterodactyl sur un VPS ?

Seulement sur le bon type de VPS. Le daemon Wings de Pterodactyl exécute chaque serveur dans un conteneur Docker, et les VPS basés sur des conteneurs comme OpenVZ et LXC ne peuvent généralement pas faire tourner Docker du tout. Un VPS KVM fonctionne, et un serveur dédié fonctionne toujours puisque le noyau vous appartient. Si vous comptez héberger de nombreux serveurs derrière un panel, le bare metal est de toute façon l'endroit naturel pour le faire.

Les serveurs de jeu subissent-ils vraiment des attaques DDoS ?

Oui, plus que la plupart des charges de travail. Les joueurs connaissent l'IP, les jeux fonctionnent en UDP, et lancer un flood ne demande aucune compétence. Une ligne domestique ou un VPS non protégé sature et tous les joueurs sont déconnectés. L'atténuation doit se trouver dans le réseau, en amont du serveur, avec la capacité d'absorber le volume et un filtrage capable de distinguer le trafic de jeu d'une attaque.