La documentation officielle du serveur dédié d'Iron Gate Studio, publiée en avril 2024 et constituant toujours la référence de travail pour les administrateurs, explique comment faire fonctionner un serveur Valheim. Elle est écrite pour les administrateurs, pas pour les ingénieurs. Si on la rapproche des notes de mise à jour et de la FAQ de la version 1.0 de Valheim sortie le 9 septembre 2026, l'architecture derrière les instructions devient limpide : deux configurations de serveur, une limite stricte de joueurs et un modèle d'hébergement qui s'appuie par nature sur la communauté.

Indirectement, l'approche de Valheim montre ce qui se passe lorsqu'un petit studio prend des décisions d'infrastructure qui se déploient bien au-delà de ce que son équipe aurait pu gérer seule.

La limite de 10 joueurs

Le système de synchronisation des objets de Valheim utilise une structure appelée ZDO (Zone Data Object). Chaque entité du monde (joueurs, créatures, éléments de construction, animaux apprivoisés) est représentée sous forme de ZDO. Lorsqu'un ZDO change d'état, l'objet complet est renvoyé plutôt que les seuls champs modifiés. C'est plus simple à implémenter et plus adapté aux mods, mais très gourmand en bande passante. À mesure que le nombre de joueurs augmente, le volume de ZDO actifs dans une zone donnée augmente également, et les données d'état totales par cycle de rafraîchissement (tick) augmentent avec lui.

L'analyse communautaire du code réseau du jeu, documentée en détail sur le blog de James A. Chambers, a révélé des limites de taux d'envoi et de réception codées en dur dans le gestionnaire ZDO. Les mods peuvent lever ces limites, mais les tests de la communauté ont montré une dégradation notable des performances à l'approche de 5 à 6 joueurs simultanés. Le plafond de 10 joueurs est la partie visible d'un budget de bande passante plus profond. Les grandes structures construites par les joueurs et les populations d'animaux apprivoisés pèsent sur ce même budget, indépendamment du nombre de joueurs.

Cette limite est également celle que la version 1.0 n'a pas modifiée. Iron Gate a sorti le jeu sur quatre plateformes supplémentaires, a mis à jour le moteur et a réécrit la sauvegarde des mondes, mais la limite reste exactement là où elle a toujours été. « Tout comme c'est le cas actuellement, Valheim 1.0 sera un jeu pour 1 à 10 joueurs », indique la FAQ 1.0. Une limite qui tient bon lors d'un lancement de cette envergure n'est pas un paramètre temporaire en attente d'ajustement. C'est la structure même du modèle de synchronisation, et la modifier impliquerait de réécrire la réplication des états plutôt que d'augmenter un chiffre dans un fichier de configuration.

C'est la partie sur laquelle il convient de s'attarder. Les limites de joueurs fixées au début du développement ont tendance à se figer, car au moment où la limite commence à poser problème, l'architecture sous-jacente s'est déjà enrichie de plusieurs années de contenu accumulé.

Un binaire gratuit, un écosystème florissant

L'une des décisions d'infrastructure les plus lourdes de conséquences d'Iron Gate n'était pas technique. Elle était économique.

Le binaire du serveur dédié est gratuit pour tous via Steam Tools, répertorié comme un outil dans la bibliothèque de l'utilisateur, sans obligation d'achat du jeu. Iron Gate publie le guide d'installation complet sur son site officiel, y compris les instructions Docker, les paramètres de lancement, les commandes d'administration et la configuration des sauvegardes. Ils fournissent aux administrateurs tout ce dont ils ont besoin et s'effacent.

Le résultat est que les coûts et la gestion des serveurs incombent à la communauté et aux hébergeurs commerciaux. Des entreprises comme G-Portal, BisectHosting et Nitrado hébergent des milliers de serveurs Valheim, gèrent la protection DDoS, fournissent des interfaces de gestion et assurent le support client, sans qu'Iron Gate n'ait à débourser quoi que ce soit. Ce qui aurait pu être un centre de coûts est à l'inverse une chaîne d'approvisionnement d'hébergement distribuée, financée par les joueurs prêts à payer un abonnement mensuel plutôt que de faire tourner leur propre matériel.

Pour les studios qui envisagent des serveurs communautaires, ce modèle mérite d'être étudié. La stratégie du binaire gratuit fonctionne car elle crée un marché au service des joueurs sans exiger du développeur qu'il le gère. Les studios qui souhaitent une implication plus directe, notamment la possibilité de proposer la location de serveurs directement depuis le jeu avec un provisionnement automatisé et des revenus reversés au studio, peuvent explorer des plateformes d'orchestration conçues spécifiquement à cet effet.

Des mondes portables

Un monde Valheim est un dossier. Chacun se trouve dans son propre répertoire nommé d'après le monde, et une sauvegarde n'écrit que les zones qui ont changé. Les notes de mise à jour de la version 1.0 décrivent un « nouveau système de sauvegarde » qui « fragmente les données du monde en blocs (chunks) pour réduire la quantité de données sérialisées et écrites afin d'améliorer les performances, et est conçu pour résister aux pannes en cours d'écriture ».

Cette conception répond à deux problèmes à la fois. Réécrire un monde entier à chaque sauvegarde automatique ne coûte pas cher sur une carte neuve mais s'avère punitif sur une carte chargée de constructions de joueurs, et un crash en cours d'écriture peut corrompre l'intégralité du fichier. L'écriture par blocs limite ces deux risques.

Ce qui importe pour les administrateurs, c'est que le monde est un dossier sur le disque, détenu par celui qui fait tourner le serveur. Un groupe qui auto-héberge son serveur peut migrer vers un serveur loué en copiant simplement ce dossier. Un groupe qui loue chez un prestataire peut passer chez un autre en téléchargeant une sauvegarde et en la téléversant à nouveau. Il n'y a pas d'enfermement propriétaire dans le cloud, et la documentation d'Iron Gate traite le déplacement de mondes comme une opération de routine.

Pour les joueurs, cela signifie une véritable propriété de leur monde. Pour les développeurs, cela rappelle que l'architecture de persistance façonne la confiance des joueurs. Les mondes qui peuvent être possédés, déplacés et sauvegardés sont des mondes dans lesquels les joueurs s'investissent à long terme. Verrouiller l'état du monde sur un service propriétaire peut simplifier le développement, mais cela crée précisément le type de dépendance que les joueurs remarquent lorsque les choses tournent mal.

Deux configurations de serveur, un seul jeu

La plupart des jeux intègrent un seul backend réseau et s'accommodent de ses limites. Valheim en propose deux.

Le backend Steam connecte directement les joueurs via la couche réseau de Valve. Il est propre, consomme peu de ressources et ne nécessite aucun intermédiaire. En revanche, il ne s'adresse qu'aux joueurs Steam sur PC.

Le backend crossplay achemine le trafic via les serveurs relais Microsoft Azure PlayFab Party, et c'est ce qui permet de réunir dans le même monde les joueurs de Steam, du Microsoft Store, du Mac App Store, de Humble, de la Xbox, de la PlayStation 5 et de la Nintendo Switch 2. La FAQ 1.0 d'Iron Gate est sans ambiguïté : « Valheim prendra en charge le crossplay entre toutes les plateformes ».

Un argument technique permet de choisir entre les deux. Le paramètre -crossplay est activé par défaut dans les scripts de lancement d'exemple fournis avec le serveur dédié, faisant de l'accès à toutes les plateformes la solution de facilité, tandis que l'utilisation directe de Steam devient une démarche volontaire. Pour un jeu dont le public se trouve largement en dehors de Steam, cette valeur par défaut matérialise une stratégie en un seul paramètre.

Le relais d'Azure

PlayFab Party est le réseau de relais de Microsoft pour le multijoueur de jeux vidéo. Un serveur Valheim en mode crossplay se connecte à l'un des nœuds de relais régionaux d'Azure plutôt que d'accepter directement les connexions des joueurs. Les joueurs se connectent à ce relais, et non au serveur lui-même. Le relais gère le routage entre eux, ainsi que l'affichage public du serveur et l'identité des joueurs multiplateformes.

La documentation est honnête quant au coût de cette infrastructure. Les joueurs en crossplay sont plus susceptibles de subir des latences, des expirations de délai et des déconnexions que les joueurs connectés via le backend Steam direct. Le relais ajoute un saut réseau, et son emplacement est choisi automatiquement en fonction de la proximité avec l'une des quelque 17 régions Azure. Les administrateurs n'ont aucun contrôle sur le relais sur lequel leurs joueurs atterrissent. Un serveur situé dans une région peut finir par acheminer le trafic via un relais éloigné d'une partie de ses joueurs, sans aucun recours possible.

C'est un compromis classique pour les architectures basées sur des relais, et il convient de bien le comprendre avant d'en choisir une. Pour une analyse comparative des relais par rapport aux serveurs faisant autorité et au pair-à-pair, lisez le guide explicatif d'Edgegap sur les types de réseaux.

Une alternative consiste à remplacer un relais généraliste par une petite instance de serveur dédié déployée à proximité du groupe de joueurs. Un serveur de jeu de moins de 0,25 vCPU situé en périphérie de réseau (edge) offre l'autorité du serveur sans le saut de relais supplémentaire. Des plateformes comme le réseau d'orchestration d'Edgegap rendent viables des déploiements fractionnés sur plus de 615 emplacements mondiaux, ce qui associe l'accessibilité des configurations de type relais au profil de latence d'une connexion directe.

Crossplay ou Mods : il faut choisir

Cette double configuration s'accompagne d'une conséquence que les administrateurs doivent anticiper : le crossplay et les mods ne fonctionnent pas ensemble.

Le chargeur de mods BepInEx, très largement utilisé, se greffe sur la couche réseau Steam de Valheim. L'activation du crossplay remplace cette couche par la pile PlayFab, et BepInEx ne se charge pas. Les deux piles réseau ne partagent aucune couche d'abstraction commune, il n'y a donc pas d'option hybride.

Iron Gate est très claire sur la situation des mods. Comme ils ne proposent aucun support officiel pour les mods, ils « ne peuvent garantir le bon fonctionnement d'aucun mod », et les versions consoles n'en intègrent aucun. La mise à niveau du moteur de la version 1.0 a rendu cela bien concret pour les administrateurs qui ont passé la semaine de lancement à reconstruire des listes de mods face à une cible mouvante.

La décision dépend simplement de la composition de votre groupe de joueurs. Un groupe exclusivement sur Steam peut faire tourner un serveur moddé sur le backend Steam. Un groupe comprenant des joueurs sur console a besoin du crossplay et, de ce fait, d'un serveur sans mods (vanilla). C'est une contrainte pratique, pas un défaut de conception.

—

[Note de l'éditeur] Contrairement à d'autres articles de cette série, cet article s'appuie sur la documentation officielle du serveur dédié d'Iron Gate Studio, sur la FAQ et les notes de mise à jour de Valheim 1.0, ainsi que sur le wiki de la communauté Valheim, plutôt que sur une conférence de développeurs ou un post-mortem. Les faits d'architecture sont documentés et vérifiables. L'interprétation des raisons pour lesquelles ces décisions ont été prises nous est propre et n'est pas formulée directement par Iron Gate.

Cet article est basé sur et cite la documentation originale et les notes de mise à jour d'Iron Gate Studio, publiées sur valheimgame.com, avec des analyses réseau complémentaires de James A. Chambers. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.