Serveur sans tête
Un serveur headless exécute la simulation du jeu sans rendu, sans audio et sans périphérique d'entrée connecté. L'allégement des tâches côté client laisse place au socle attendu pour un serveur : la physique, l'état et le réseau, ainsi que tout ce que le développeur choisit d'y exécuter. N'ayant pas besoin d'écran ni de GPU, ce build est également beaucoup plus facile à encapsuler dans un conteneur, ce qui est la méthode courante pour déployer et faire évoluer les serveurs dédiés.
,
Qu'est-ce qu'un serveur headless élimine, et qu'est-ce qui doit rester ?
Une version sans affichage (headless) supprime tout ce qu'un joueur voit, entend ou touche : le moteur de rendu, les shaders et les textures, l'audio, l'interface utilisateur et les périphériques d'entrée. Ce qui reste est ce qui décide du match : la boucle de simulation, la physique, les règles du jeu et le réseau. C'est la base. Le fait que l'IA, la journalisation ou autre chose s'exécute également sur le serveur dépend de la décision du développeur.
La frontière est rarement aussi nette dans le code que sur le papier. La logique du jeu lit souvent à partir de la couche de présentation sans que personne ne l'ait décidé : une hitbox attachée à un os animé, un temps de recharge compté en images affichées (frames), un événement de jeu déclenché depuis une animation ou un rappel (callback) d'interface utilisateur. Dans le client, tout cela fonctionne, car quelque chose est toujours dessiné. Dans une version sans affichage, rien ne l'est, et la logique qui en dépendait s'arrête ou dérive.
L'habitude qui permet d'éviter cela est simple à énoncer : tout ce qui modifie l'issue du match appartient au code qui s'exécute qu'une image soit dessinée ou non. Pour savoir comment la version sans affichage se rapporte aux serveurs dédiés et faisant autorité, voir serveur dédié.
Pourquoi les builds headless cassent-ils des éléments qui fonctionnaient dans l'éditeur ?
Parce que les paramètres par défaut du moteur supposent que quelqu'un regarde. L'éditeur effectue toujours le rendu, de sorte que ces problèmes n'apparaissent généralement qu'une fois que la version serveur s'exécute d'elle-même.
L'animation qui s'arrête quand personne ne la voit. Les moteurs économisent du travail en ignorant l'animation sur les objets qu'aucune caméra ne peut voir, et sur un serveur headless, aucune caméra ne voit rien. Dans Unreal, un maillage squelettique (skeletal mesh) sur un serveur dédié ne rafraîchit pas les positions de ses os à moins d'être configuré pour toujours exécuter le tick de sa pose et rafraîchir ses os, de sorte que la détection de collision (hit detection) par rapport à ces os utilise des positions obsolètes. Dans Unity, un Animator dont le mode de culling arrête l'animation lorsque rien n'est rendu produit le même effet.
Une boucle sans limite de frame rate. Un client est rythmé par son affichage. Un processus headless n'en a pas, de sorte que sans taux de rafraîchissement cible (target frame rate) ou taux de tick du serveur (server tick rate), il s'exécute aussi vite que possible et occupe un cœur de processeur entre les ticks. Sur un serveur facturé au vCPU, c'est un coût sans équivalent.
Des pipelines de build différents. La cible de build Serveur Dédié d'Unity supprime également les assets dont le serveur n'a pas besoin, tels que les textures et l'audio, ce qui réduit la taille du build. Godot 4 exporte un serveur dédié qui supprime les ressources visuelles et s'exécute avec le flag
--headless. Unreal compile une cible de serveur uniquement à partir d'un moteur compilé depuis les sources, et non de la version du launcher, ce qui fait de la première build serveur une étape fastidieuse.
Les étapes de build de base pour chaque moteur se trouvent sur la page serveur dédié.
Comment une architecture headless rend-elle possible l'utilisation des conteneurs et de l'orchestration ?
Un conteneur regroupe un programme avec ce dont il a besoin pour s'exécuter et rien de plus. Il n'a pas d'écran connecté et, sur la plupart des hôtes, pas de GPU. Un build client s'attend aux deux. Un build headless ne s'attend à aucun des deux, ce qui le rend beaucoup plus facile à packager sous forme d'image Linux avec Docker et à exécuter sur n'importe quel hôte qui gère des conteneurs.
Une fois que le serveur est une image, un orchestrateur peut le démarrer à la demande, au plus près des joueurs, et l'arrêter à la fin du match. Un build plus léger aide : une image plus petite se télécharge et démarre plus rapidement sur un hôte qui ne l'a jamais exécutée auparavant. Sur Edgegap, le temps médian de déploiement d'un serveur à partir d'un démarrage à froid est de 2 secondes sur une période glissante de 30 jours, mesuré jusqu'à ce que le conteneur soit prêt, avant le démarrage du moteur de jeu (données de la plateforme, 18 septembre 2026). Le démarrage du moteur vient en plus, et cette partie dépend de la build.
Supprimer les graphiques est également ce qui permet à plusieurs serveurs de partager une même machine. Le nombre de serveurs pouvant y prendre place est déterminé par la mémoire par instance et par la part du budget CPU de chaque tick utilisée par la boucle principale, toutes deux mesurées dans un build profilé. Un serveur multi-salles va plus loin et héberge plusieurs matchs dans un seul processus, de sorte que le nombre qu'il convient de dimensionner devient le nombre de salles par vCPU.
Devriez-vous envoyer votre serveur headless aux joueurs ?
Certains studios le font. Factorio, Valheim, Satisfactory et Enshrouded fournissent aux joueurs une version serveur qui fonctionne sans graphisme, à héberger sur leur propre machine ou sur une machine louée. Ces jeux représentent une grande partie des recherches pour ce terme.
Cela convient aux jeux où un groupe joue dans un monde persistant pendant des semaines, comme les jeux de survie et de construction. Le studio héberge moins, et les communautés peuvent continuer à jouer aussi longtemps qu'elles maintiennent un serveur en marche. Le compromis est le contrôle. Un serveur géré par les joueurs est un serveur que les joueurs peuvent modifier, et un correctif ne l'atteint que lorsque son propriétaire le met à jour. Pour les jeux compétitifs, où l'équité dépend du serveur, les studios gardent généralement la version serveur pour eux-mêmes.
Un mot de notre sponsor (nous-mêmes !)
Les pools chauds rendent l'allocation rapide car vous payez pour des serveurs qui restent inactifs. Edgegap déploie un nouveau serveur de jeu en une médiane de 2 secondes à partir d'un démarrage à froid, mesuré jusqu'à ce que le conteneur soit prêt avant le démarrage de votre moteur, de sorte qu'un serveur n'existe que lorsqu'un match en a besoin.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
Adoptez le headless dès le départ, puis continuez à mesurer
La première build headless est souvent créée peu avant le lancement, et c'est à ce moment-là que ses problèmes font surface, tous en même temps. La réaliser plus tôt permet d'accomplir trois choses.
Elle vous permet de tester le jeu en ligne. Un test sur un hôte local (localhost) masque la latence ; la build headless sur un serveur réel montre comment le jeu se comporte là où se trouvent les joueurs. L'offre gratuite d'Edgegap couvre un test de jeu : pas de carte de crédit, 1,5 vCPU et 3 Go de mémoire, un seul déploiement à la fois, avec une limite de 60 minutes (tarification, consulté le 5 octobre 2026).
Elle instaure une habitude de mesure. Le CPU par tick et la mémoire par instance, suivis dès la première build, vous indiquent combien de parties peuvent tenir sur un vCPU.
Et elle permet une amélioration continue. L'hébergement est facturé à la minute de vCPU, soit 0,00115 $ sur Edge Cloud (même source), de sorte qu'une économie réalisée sur une partie se répercute sur chaque partie que vous hébergez. Cela fait souvent de la build du serveur le levier le plus important sur le coût d'hébergement, qui mérite qu'on y travaille tout au long de la vie du jeu. Pour Unreal, l'obstacle à cette première build est la compilation du moteur à partir des sources. L'extension Docker d'Edgegap construit un serveur Linux sans cela, réduisant le temps de build de 2,5 heures à 8,5 minutes en moyenne (octobre 2025).
,
