Chaque jeu multijoueur doit répondre à la même question : quelle machine décide de ce qui s'est passé pendant une partie ? La réponse influence la triche, l'équité, ce qui se produit lorsqu'un joueur quitte la partie et le coût d'exploitation du jeu.

Ce guide résume et compare les cinq principales configurations possibles parmi lesquelles les développeurs peuvent choisir, ce à quoi chacune convient, et quand envisager une autre configuration.

Pour une analyse plus approfondie des modèles réseau eux-mêmes, consultez le guide d'Edgegap sur les serveurs faisant autorité, les relais et le pair-à-pair.

Aperçu des cinq configurations

Toutes les cinq partagent une même structure, le modèle client-serveur : chaque joueur se connecte à une copie du jeu qui décide de ce qui s'est passé. Ce qui change, c'est qui exécute cette copie — le jeu d'un joueur ou un serveur — et l'étendue de ses tâches. Dans le pair-à-pair et les relais, le « serveur » est le jeu du joueur hôte, un modèle souvent appelé hôte-client.

1. Pair-à-pair

Ce que c'est : Dans la plupart des jeux commercialisés, le pair-à-pair correspond au modèle hôte-client. Le jeu d'un joueur détient l'état de la partie et fait office de serveur pendant que ce joueur joue, et tous les autres s'y connectent. Une catégorie plus restreinte de jeux, principalement des jeux de stratégie et de combat, exécute chaque simulation sur chaque machine et n'échange que les commandes (inputs), en lockstep ou avec du rollback.

Convient pour : Les prototypes, les game jams, les versions non commerciales, le jeu local ou de type LAN, et les petites sessions entre amis.

Avantages :

• Aucune facture d'hébergement : Les joueurs fournissent le matériel et la bande passante.

• Rapide à mettre en place : La plupart des moteurs prennent en charge un mode hôte, souvent appelé listen server.

Limites :

• Échecs de connexion : La plupart des joueurs se trouvent derrière un routeur effectuant de la traduction d'adresses réseau (NAT). Le hole punching échoue souvent avec des routeurs stricts et le CGNAT (carrier-grade NAT), très répandu sur les réseaux mobiles.

• L'hôte peut tricher : Quiconque détient l'état de la partie peut le modifier, en éditant des valeurs en mémoire, en utilisant un lag switch ou en transmettant un résultat qui ne s'est jamais produit.

• Les joueurs voient les adresses IP des autres : Cela les expose à des attaques par déni de service de la part des joueurs avec lesquels ils sont associés (les coûts cachés du P2P).

• L'hôte s'en va, la partie se termine : À moins que le jeu n'intègre une migration d'hôte. Highwire Games a estimé le coût de la migration d'hôte pour Six Days in Fallujah à un développeur et un testeur supplémentaires, soit environ 15 000 $ par mois (conférence du Live Service Game Summit, septembre 2024).

Le pair-à-pair peut également nuire à la latence, car la route directe entre les joueurs n'est pas toujours la plus courte. Dans une analyse réalisée en 2020 sur 122 000 parties en pair-à-pair d'un jeu de console en 1c1, le routage de chaque match via un serveur placé entre les deux joueurs a réduit le temps d'aller-retour moyen de 23 % dans 70 % des cas (rapport 1v1).

Envisagez une autre configuration lorsque : Les joueurs signalent qu'ils ne parviennent pas à se rejoindre. C'est précisément le problème pour lequel un relais a été conçu.

2. Service de relais partagé (ex. Steam, Epic Online Services, Unity Relay)

Ce que c'est : Un serveur relais achemine le trafic entre les joueurs qui ne peuvent pas se joindre directement. Chaque joueur établit une connexion sortante vers le relais, qui transmet les paquets entre l'hôte et les invités. Un service de relais partagé est géré par une plateforme pour tous les jeux hébergés sur celle-ci.

Convient pour : Une solution réseau pour les connexions défaillantes, dans un jeu déjà conçu en mode hôte-client.

Avantages :

• Évite la plupart des problèmes de NAT : Personne n'a besoin d'accepter de connexion entrante, de sorte que le NAT et les pare-feu cessent de bloquer les joueurs.

• Sécurisé, masque les adresses IP des joueurs : Les joueurs se connectent au relais, et non les uns aux autres.

• Peu d'intégration requise : Les SDK de plateforme associent souvent le relais aux salons (lobbies).

Limites :

• Le jeu reste hébergé par le joueur : Le relais n'exécute aucune logique de jeu. L'hôte peut toujours tricher, joue toujours sans aucun délai réseau et met fin à la partie s'il la quitte.

• Chaque invité fait deux sauts : De l'invité au relais, puis vers l'hôte, et retour. L'emplacement du relais détermine la latence de chaque invité, et plus les joueurs sont éloignés d'un emplacement de relais, moins la partie est équitable. Les jeux web le ressentent le plus : les navigateurs utilisant des WebSockets ne peuvent pas du tout se connecter d'un joueur à un autre, de sorte que chaque paquet de chaque partie transite par le relais, et le WebRTC bascule vers un relais, un serveur TURN, dès qu'une connexion directe échoue (serveur relais).

• Le réseau d'un seul fournisseur détermine la route et la disponibilité : En évaluant les relais gratuits d'Epic Online Services, Michal Buras de Highwire Games a constaté qu'il n'y avait « absolument aucun contrôle sur la façon dont ces joueurs sont routés » (conférence du Live Service Game Summit, septembre 2024). Il a également montré que les données de lobby sur cette configuration pouvaient être lues en clair à l'aide d'un outil de débogage classique. La route et sa disponibilité sont tributaires du réseau de ce fournisseur.

Envisagez une autre configuration lorsque : Vous souhaitez avoir le plein contrôle sur le routage, les emplacements et le code exécuté sur le relais.

3. Relais extensible (ex. LightNet)

Ce que c'est : Un relais que vous hébergez sur un serveur dédié, avec la possibilité de l'étendre en ajoutant de la logique de jeu. Ajoutez de la logique de jeu et il devient un serveur dédié multi-salons offrant l'efficacité en ressources d'un relais. Par défaut, il s'agit avant tout d'un relais : il achemine le trafic, et le jeu de l'hôte gère la partie. Le guide du relais LightNet d'Edgegap en exécute un pour les jeux Unity en hôte-client, les joueurs hébergeant et rejoignant des parties via un code de salon.

Convient pour : Les joueurs qui se font confiance : jeux en coop, amis et salons privés. Dans ce cadre, les jeux mobiles et hybrides-casual, les TCG et le JcJ en temps réel sans logique serveur.

Avantages :

• Sécurisé, masque les adresses IP des joueurs : Tout le monde se connecte vers l'extérieur au relais, ce qui élimine les attaques visant la connexion d'un joueur, comme la saturation de l'hôte.

• Évite la plupart des problèmes de NAT : Aucune redirection de port, y compris sur les réseaux mobiles.

• Votre itinéraire, vos emplacements : Vous déployez le relais là où se trouvent vos joueurs.

• Un réseau dédié exclusivement à votre jeu, sur plusieurs clouds : Une modification de routage ou une panne sur un autre réseau de relais ne l'affecte pas. Sur une plateforme multicloud comme Edgegap, qui compte plus de 17 fournisseurs, un nouveau relais peut être lancé chez un autre fournisseur en cas de défaillance d'un emplacement.

• Votre propre code : Les services de relais partagés ne vous permettent pas d'ajouter du code. Sur votre propre relais, vous pouvez intégrer une logique telle que des mots de passe de salon, des vérifications de joueurs, la limitation de débit, l'expulsion et le bannissement, les données de salon, la télémétrie ou des hooks vers votre lobby. Rien de tout cela n'est fourni de base, c'est donc à vous de l'écrire.

• Peut éliminer la triche dès l'ajout de logique de jeu : Tel quel, le jeu de l'hôte conserve l'état de la partie, un tricheur peut donc encore gâcher une partie pour tout le monde. L'ajout d'une validation du gameplay confère au serveur l'autorité sur le même code et déploiement, comme décrit ci-dessous.

• Pas de réécriture pour commencer : Votre netcode hôte-client reste inchangé, et un seul relais gère plusieurs salons à la fois.

Limites, par défaut :

• La partie se termine lorsque l'hôte quitte : La migration d'hôte n'étant pas intégrée, le jeu doit s'en charger. Dans l'exemple LightNet, le relais ferme également le salon.

• Ne chiffre pas le trafic : Les transports de l'exemple LightNet utilisent du TCP et UDP standard non chiffré.

• Aucun matchmaking ni mise à l'échelle autonome : Les joueurs partagent des codes de salon, et vous choisissez où déployer les relais.

Où se situe la frontière : Une logique externe au gameplay, comme les mots de passe, les limites de débit ou la télémétrie, en fait toujours un simple relais. Valider le gameplay, comme les coups portés, les résultats ou l'économie, le transforme en un serveur de jeu multi-salons, l'étape suivante. Comme l'a souligné Michal Buras : « Si vous effectuez des calculs, ce n'est plus un serveur relais. » Cette transition est envisageable, mais représente un travail important : le relais ne traitant que le trafic netcode brut, il doit apprendre à interpréter les messages de votre jeu avant de pouvoir les vérifier.

Hébergement : Edge Cloud convient parfaitement à une utilisation à la demande, au développement, aux playtests et à la préproduction. À plus grande échelle, les Private Fleet sont généralement plus rentables pour les relais qui fonctionnent 24 h/24 : des hôtes réservés dans 58 emplacements, avec 6 To de trafic sortant inclus par hôte. Dans les deux cas, le recyclage régulier des relais constitue une bonne pratique.

Envisagez une autre configuration lorsque : Vos joueurs commencent à affronter des inconnus, ou si vous souhaitez que le serveur prenne les décisions relatives à la partie.

4. Serveur de jeu multi-salons

Ce que c'est : Un serveur de jeu multi-salons est un processus serveur unique qui héberge plusieurs parties simultanément, chacune dans son propre salon avec son état et ses joueurs distincts. Les coûts fixes du processus, tels que le moteur et les données de jeu chargées, sont payés une seule fois et partagés entre tous les salons. C'est également ce que devient un relais extensible dès que vous y intégrez la validation du gameplay.

Convient pour : Les jeux pouvant partager un même processus : jeux au tour par tour, jeux de cartes, jeux de réflexion et casual, jeux de stratégie en temps réel (qui fonctionnent souvent en lockstep), MOBA (qui n'ont pas de moteur physique lourd mais nécessitent un serveur faisant autorité), et de nombreux jeux de sport et de course, ainsi que les lobbies et espaces sociaux.

Avantages :

• Empêche la triche de l'hôte : Le serveur gère la logique et détermine ce qui s'est produit.

• Sécurisé, masque les adresses IP des joueurs et élimine la plupart des soucis de NAT : Chaque joueur établit une connexion sortante vers le serveur.

• Aucune migration d'hôte requise : La partie continue même si un joueur la quitte.

• Plusieurs parties par processus : Les frameworks basés sur des salons tels que Colyseus et Nakama sont conçus pour cela, et Mirror permet d'attribuer une sous-scène propre à chaque partie. Edgegap n'impose aucune limite de processus : un déploiement exécute autant de processus et de salons que le processeur et la mémoire le permettent.

• Dimensionnement flexible : Sur un service comme Edgegap, les serveurs débutent à 0,25 vCPU et peuvent aller jusqu'à un hôte Private Fleet de 14,7 vCPU. Le dimensionnement se calcule par salons par vCPU, évalué sur un build profilé, plutôt que par match individuel.

• Mise à l'échelle simple : Un matchmaker procède au backfill des joueurs dans un salon ouvert, ou déploie un nouveau serveur si aucun salon n'est disponible.

Limites :

• Emplacement souvent centralisé : L'emplacement d'un serveur multi-salons est choisi une seule fois, au démarrage, et il est souvent déployé de façon centrale, là où la concentration de joueurs est élevée. Dans ce modèle centralisé, les joueurs éloignés subissent une latence et une équité moins favorables que les joueurs situés à proximité.

• Les salons doivent être isolés dans le code : La conversion d'un serveur dédié à une seule partie implique que l'état partagé (des singletons aux moteurs physiques) devienne propre à chaque salon. Unreal exécute généralement un seul match par processus.

Envisagez une autre configuration lorsque : Chaque match nécessite son propre serveur à proximité de ses joueurs, ou si le monde doit persister pendant que les joueurs vont et viennent.

5. Serveur dédié

Ce que c'est : Un serveur dédié exécute une session par déploiement, sur une machine qu'aucun joueur ne contrôle. Il remplace le rôle de l'hôte ; ainsi, pour un jeu conçu en hôte-client, la logique de l'hôte peut souvent tourner sous forme de build headless. Une partie légère et une simulation complète s'exécutent sur le même type de serveur ; la seule variable est la quantité de CPU requise, qui commence généralement à un niveau élevé avant de diminuer au fil des optimisations de l'équipe. Un serveur dédié dimensionné pour une petite partie est parfois appelé un petit serveur dédié.

Il existe en deux variantes, qu'il vaut mieux comparer selon leur comportement plutôt que par genre :

Convient pour :

• Par session : Jeux de tir, battle royales, JcJ en temps réel, modes compétitifs et classés, jeux de combat, réalité virtuelle et XR, Web3, jeux en coopération avec des inconnus, et JcJ mobile ou casual hybride.

• Persistant : MMO, jeux de survie, mondes bac à sable (sandbox) et espaces communautaires.

Avantages :

• Empêche la triche de l'hôte : Les clients envoient des commandes et le serveur valide les résultats, éliminant ainsi les méthodes de triche qui reposent sur le contrôle de l'état de la partie par un joueur. L'autorité du serveur ne bloque pas à elle seule les aimbots ou les wallhacks, qui s'exécutent sur la machine du joueur ; c'est pourquoi les contrôles côté serveur fonctionnent de concert avec l'anti-triche côté client.

• Connexions fiables, sans dépendance envers la disponibilité de l'hôte : Chaque joueur se connecte à un serveur indépendant, ce qui masque son IP et élimine la majorité des problèmes de NAT. Aucun joueur n'agissant en tant qu'hôte, son départ n'exige aucune procédure de migration.

• Positionné pour les joueurs de la session : Chaque serveur par session démarre là où il peut servir au mieux les participants à ce match. Des replays indépendants du trafic réel d'un studio ont mesuré une réduction moyenne de latence de 58 % pour un serveur dédié par rapport à un relais hébergé sur le cloud public (données de la plateforme, 18 septembre 2026).

• S'adapte à l'évolution du jeu : Le dimensionnement fractionné débute à 0,25 vCPU pour une partie légère. À l'autre extrémité, une simulation complète prend en charge la physique, les déplacements et la détection des tirs à un tick rate constant pour 2 à 100 joueurs ou plus. Les mondes persistants et les MMO fonctionnent selon le même principe : The Isle, le jeu de survie de dinosaures en monde ouvert d'Afterthought LLC accueillant plus de 100 joueurs par serveur, exploite ses serveurs persistants sur Edgegap ; de son côté, Loftia, le MMO chaleureux de Qloud Games, a fait évoluer des centaines de serveurs de jeu, y compris des hubs de 100 joueurs simultanés, tout au long de sa phase de bêta fermée.

Limites :

• Une seule session par déploiement : Chaque match par session démarre et arrête son propre serveur, nécessitant ainsi un orchestrateur capable d'initialiser rapidement les instances et de les localiser en fonction des joueurs.

• L'utilisation des ressources augmente avec la complexité de la simulation : Héberger un jeu de cartes avec l'infrastructure d'un battle royale entraîne des coûts excessifs ; les jeux légers sont souvent mieux adaptés à un serveur multi-salons.

Hébergement : Les jeux basés sur des sessions utilisent généralement une formule hybride : une flotte réservée pour couvrir économiquement le trafic de base, complétée par une capacité à la demande pour absorber les pics d'activité. Les mondes persistants sont parfaitement adaptés aux Private Fleets.

Bloody Bastards, un jeu mobile totalisant plus de 40 millions de téléchargements, a migré d'un système peer-to-peer basé sur la confiance envers l'hôte — où le studio qualifiait la triche d'endémique — vers des serveurs faisant autorité couplés à un matchmaker, avec « zéro tricheur constaté depuis » (blog Edgegap, 2026).

Quelle configuration choisir selon le genre et le mode de jeu ?

De nombreux jeux combinent deux approches : des salons privés sur un relais et des matchs publics sur un serveur. Lorsqu'un serveur multi-salons est déployé de manière centralisée, les utilisateurs éloignés subissent une latence et une équité moindres par rapport aux participants situés à proximité.

Étape suivante : Comment les joueurs accèdent au serveur

Déterminer l'endroit où s'exécute le match ne représente que la moitié du travail. L'autre consiste à définir comment les joueurs s'y connectent. Un relais extensible, un serveur multi-salons et un serveur dédié peuvent chacun employer les solutions ci-dessous ; ce choix dépend de la conception du jeu : le rattachement est-il automatisé selon une règle ou choisi par le joueur ?

• Un matchmaker : Fonctionnement basé sur des règles. Il regroupe les joueurs selon des critères de niveau et de latence, puis les intègre dans un salon ouvert ou initialise un nouveau serveur si aucune option n'est disponible. Il convient particulièrement aux jeux par session où des inconnus sont mis en relation. Le matchmaker d'Edgegap provisionne le serveur à proximité immédiate des joueurs réunis.

• Un navigateur de serveurs : Le joueur choisit. Il affiche la liste des serveurs ou salons actifs disposant de places libres, à la manière d'un lobby. Il est idéal pour les univers persistants et les jeux orientés communauté.

De nombreux jeux tirent parti des deux systèmes, et cette décision gagne à être prise parallèlement au choix du type de serveur plutôt qu'après coup.

Fondez votre choix sur le niveau de confiance entre joueurs

Les équipes ont souvent opté pour le pair-à-pair et les relais parce que provisionner un serveur par match était autrefois financièrement inabordable, et rarement parce qu'un relais offrait une meilleure expérience. Cet écart s'est résorbé : un serveur multi-salons mutualise un processus sur un large volume de parties, et un serveur dédié peut être dimensionné à partir d'une fraction de vCPU.

Une interrogation utile avant de vous décider : listez avec qui vos joueurs vont interagir. S'ils ne jouent qu'entre amis, un relais extensible stabilise les connexions, sécurise les adresses IP et autorise l'intégration de votre propre code. Si des joueurs inconnus s'affrontent, en mode détente ou classé, confiez ces parties à un serveur dimensionné en fonction de la logique à arbitrer.

Prêt à basculer vos parties sur un serveur ? Consultez le guide adapté à votre moteur : Unreal Engine, Unity, Godot ou jeux sur navigateur.