Juillet 2026 a été le mois le plus intense de l'histoire de YorkHost sur la partie game hosting. En quelques jours, les commandes de serveurs Palworld sont passées de quelques unités par semaine à plusieurs centaines par jour. Une bonne nouvelle sur le papier, sauf que notre infrastructure n'était pas dimensionnée pour ça, et surtout, elle n'était pas configurée correctement pour ce jeu précis.
Cet article est un retour d'expérience honnête. On y explique ce qu'on a mal fait, ce qu'on a corrigé, et ce qu'on a mis en place pour que ça ne se reproduise pas. On préfère écrire ce genre de contenu plutôt que de faire comme si tout s'était déroulé parfaitement.
Le point de départ : un mauvais choix de plateforme CPU
Notre parc de nodes de jeu reposait historiquement sur des processeurs Intel. Ce choix se défendait très bien pour une bonne partie de notre catalogue : hébergement web, VPS, bots Discord, et une majorité de jeux qui répartissent correctement leur charge.
Le problème, c'est qu'on a appliqué ce raisonnement à Palworld sans le tester sérieusement en amont.
Palworld est extrêmement dépendant des performances mono-cœur. Le serveur dédié est peu parallélisé, la simulation du monde (Pals, structures, bases, chargement de chunks) tape essentiellement sur un thread principal. Résultat : sur nos nodes Intel, dès qu'un serveur montait en charge, le tick rate s'effondrait. Les joueurs ressentaient du rubber banding, des Pals qui se téléportaient, des délais sur les interactions, alors que le monitoring global de la machine affichait une charge CPU tout à fait raisonnable.
La leçon numéro un, celle qu'on aurait dû intégrer plus tôt : chaque jeu a son propre profil de consommation. Un serveur Minecraft moddé, un FiveM, un ARK et un Palworld n'usent pas les mêmes ressources. On ne peut pas se contenter d'une plateforme unique pour tout le catalogue et espérer que ça tienne. Le benchmark doit se faire jeu par jeu, en conditions réelles, avec des joueurs et un monde vieilli, pas sur un serveur vide fraîchement démarré.
Le pic : plusieurs centaines de commandes par jour
Le timing n'a rien arrangé. Le pic est tombé en pleine période de vacances scolaires, au moment où la demande sur le game hosting est structurellement la plus forte. Les joueurs ont du temps, les groupes d'amis se montent, et la conversion sur ce type de produit explose.
En quelques jours, on est passés à plusieurs centaines de commandes Palworld par jour. Nos nodes Intel dédiés au jeu se sont saturés très vite, et le problème s'est aggravé de lui-même : plus il y avait de serveurs par machine, plus le ressenti se dégradait, y compris pour les clients déjà en place qui, eux, n'avaient rien demandé.
On assume totalement : c'est une erreur de notre part. On n'avait pas anticipé le volume, et on avait surtout mal qualifié la plateforme matérielle pour ce jeu. Les clients touchés ont subi une dégradation qu'ils n'auraient pas dû connaître.
Réponse d'urgence : louer plutôt qu'acheter
La réaction évidente aurait été de commander de nouveaux serveurs Ryzen et de les faire installer dans nos baies. Sauf que sur ce type de matériel, entre la commande, la livraison, le rackage, le câblage et la mise en production, on parle de plusieurs semaines. Les clients, eux, avaient besoin d'une solution en quelques jours.
On a donc pris une décision assumée : louer des nodes AMD Ryzen chez des partenaires européens de confiance, plutôt que d'acheter.
- Délai de mise à disposition de quelques heures au lieu de plusieurs semaines.
- Élasticité : si le pic retombait (spoiler : c'est ce qui s'est passé), on n'était pas coincés avec du matériel amorti sur trois ans et sous-utilisé.
- Zéro risque d'approvisionnement, dans un contexte où les délais sur certaines références serveur peuvent déraper.
- Concentration de nos efforts sur ce qui apportait de la valeur immédiate au client : la configuration, la migration et l'optimisation, pas le rackage.
C'est un arbitrage classique entre coût unitaire et vitesse d'exécution. Sur le long terme, posséder son matériel dans ses propres baies reste plus rentable, et c'est ce qu'on continue de faire pour le socle de notre infrastructure. Mais en gestion de pic, la vitesse valait largement le surcoût.
Migration des clients et refonte de la couche logicielle
Le matériel n'était que la moitié du travail. En parallèle, on a repris entièrement notre stack Palworld côté panel de jeu.
Migration des clients existants
Tous les serveurs Palworld hébergés sur les nodes Intel saturés ont été migrés vers les nouveaux nodes Ryzen. Les gains ont été immédiats et visibles sur le tick rate, sans que le client ait quoi que ce soit à faire de son côté.
Refonte de nos eggs
Notre image de déploiement Palworld a été reprise en profondeur, avec plusieurs itérations successives en quelques jours. Les points principaux :
Normalisation de la configuration
Palworld a la fâcheuse habitude de disperser sa configuration entre plusieurs fichiers, et de régénérer des valeurs par défaut au démarrage. On a mis en place une normalisation systématique pour que la configuration définie par le client soit celle réellement appliquée, sans écrasement silencieux.
Purge de WorldOption.sav
Ce fichier, généré par le jeu, peut prendre le pas sur les paramètres définis dans les fichiers de configuration. C'est une source de confusion majeure pour les joueurs, qui modifient un réglage sans jamais le voir appliqué. Notre script gère désormais ce cas proprement.
Application stricte des limites
Les paramètres qui ont un impact direct sur la charge CPU (nombre de joueurs, densité de Pals, limites de construction) sont désormais bornés côté serveur. C'est une contrainte pour le client, mais c'est ce qui garantit que le voisin de node ne dégrade pas votre expérience de jeu.
Monitoring dédié
On a développé un outil interne qui expose en temps réel les performances de l'ensemble de notre flotte, node par node et service par service. Il ne remonte pas seulement la charge moyenne, mais les indicateurs pertinents pour du game hosting. Cet outil a été central pour piloter les migrations : on voyait immédiatement quels nodes approchaient de leur limite réelle, et non de leur limite théorique.
Une nouvelle grille tarifaire Palworld sur Ryzen
La refonte de l'infrastructure s'est accompagnée d'une refonte de l'offre. On a construit une grille dédiée Palworld sur Ryzen, structurée en cinq paliers, de 8,99 € à 30,99 € par mois.
L'objectif était double :
Refléter la réalité de la consommation du jeu
Un serveur Palworld à 4 joueurs et un serveur à 32 joueurs avec des bases massives n'ont rien à voir en termes de charge. Facturer la même chose n'a aucun sens, ni pour le client, ni pour nous.
Garantir la densité par node
En calibrant les paliers sur ce qu'une machine peut réellement absorber, on s'assure de ne pas reproduire la saturation de juillet.
Le palier d'entrée reste volontairement accessible, pour les petits groupes d'amis qui représentent la majorité de la demande sur ce jeu.
Stabilisation
Au bout d'environ deux semaines, le pic est retombé. C'est le comportement typique de ce type de vague : un afflux massif, un plateau court, puis un retour à un niveau plus élevé qu'avant mais parfaitement gérable.
La situation est aujourd'hui stabilisée. Le parc Palworld tourne intégralement sur Ryzen, la capacité louée nous laisse de la marge pour le prochain pic (rentrée, fêtes de fin d'année, prochaine mise à jour majeure du jeu), et notre monitoring nous alerte désormais bien avant le point de rupture.
Ce qu'on retient
Cinq enseignements qu'on applique désormais à l'ensemble de notre catalogue.
- 1
Tester chaque jeu individuellement, en conditions réelles
Aucune plateforme matérielle n'est bonne pour tout. Le profil de charge se qualifie jeu par jeu, sur un monde vieilli et peuplé.
- 2
La charge CPU globale n'est pas un indicateur de qualité de service
Sur les jeux mono-thread, il faut monitorer ce que le joueur ressent, pas ce que la machine affiche.
- 3
Louer est parfois la bonne décision
En gestion de pic, la vitesse de mise à disposition prime sur le coût unitaire. On garde nos machines en propre pour le socle, et on reste flexible sur les pointes.
- 4
Les vacances scolaires sont un événement infra, pas seulement commercial
Elles se planifient en capacité, au même titre que la sortie d'une mise à jour majeure.
- 5
Communiquer et assumer
On s'est trompés sur le choix initial de plateforme. Ce sont nos clients qui en ont subi les conséquences pendant quelques jours, et c'est exactement pour ça qu'on publie ce retour d'expérience.
Si vous hébergez un serveur Palworld chez nous, ou si vous envisagez de le faire, l'ensemble de nos offres tourne désormais sur AMD Ryzen. Et si vous avez des questions techniques sur ce qu'on a mis en place, notre équipe support est disponible pour en discuter.
