La plupart des joueurs ne voient jamais de serveur relais, mais de nombreux jeux multijoueurs en dépendent. Un relais est ce qui permet à deux joueurs situés derrière des routeurs domestiques, des réseaux mobiles ou des pare-feu stricts de se retrouver dans la même partie.

Ce guide aborde ce que font les relais, ce qu'ils ne font pas, à quoi ressemblent les services de relais gratuits de Steam, Epic Online Services et Unity en production, et quand un jeu est mieux servi par un serveur dédié. Pour une comparaison complète des modèles de réseau, consultez le guide d'Edgegap sur les serveurs faisant autorité, les relais et le peer-to-peer.

Qu'est-ce qu'un serveur relais dans les jeux multijoueurs ?

Un serveur relais relaie le trafic entre les joueurs qui ne peuvent pas se joindre directement. Le glossaire d'Edgegap en pose clairement la limite : il « n'exécute aucune logique de jeu, donc le jeu reste en peer-to-peer hébergé par les joueurs ».

Cela fait du relais un outil réseau, pas un serveur de jeu. Il résout deux problèmes. Les joueurs qui ne peuvent pas se connecter directement en raison du NAT ou d'un pare-feu peuvent désormais se connecter. Et personne n'apprend l'adresse IP d'autrui.

Michal Buras, alors ingénieur réseau principal chez Highwire Games, a décrit l'aspect vie privée lors de son intervention de septembre 2024 au Live Service Game Summit :

« Votre adresse privée n'est partagée avec personne, sauf avec le serveur qui relaie les informations entre vous et l'autre joueur. »

Le coût en est un saut supplémentaire. « Un serveur relais ajoute un nœud supplémentaire par lequel votre paquet de jeu doit passer, ce qui introduit de la latence », a expliqué Buras. Un relais peut tout de même battre la route directe lorsque son réseau est plus rapide que le chemin internet public. Valve affirme que son réseau de relais « améliore dans de nombreux cas le temps de ping et la qualité de la connexion ». Que cela se produise pour un joueur donné dépend de l'endroit où se trouve le relais le plus proche.

Comment fonctionne le réseau Peer-to-Peer ?

Dans la plupart des jeux en peer-to-peer, la machine d'un joueur fait office de serveur. La documentation de Unity Relay décrit la configuration : « vous pouvez utiliser Unity Relay pour établir une connexion entre plusieurs clients et un hôte ». L'hôte gère la partie, et tous les autres s'y connectent.

Cette conception évite les coûts de serveur, puisque les joueurs fournissent le matériel. Elle intègre également la connexion, le matériel et l'honnêteté de l'hôte dans chaque partie. Si l'hôte quitte, la session se termine, à moins que le jeu ne prenne en charge la migration d'hôte.

Connecter les joueurs au départ est la partie difficile. La plupart des joueurs se trouvent derrière un NAT, qui bloque les connexions entrantes non sollicitées, et les fabricants de consoles maintiennent des pages d'assistance uniquement pour expliquer les types de NAT. Lorsqu'une connexion directe ne peut pas être établie, le trafic a besoin d'un relais.

Que résolvent les relais, et que ne résolvent-ils pas ?

Un relais modifie le chemin emprunté par le trafic. Il ne change pas qui fait tourner le jeu. Le glossaire décrit les conséquences sur la latence : l'hôte joue sans délai réseau, tandis que « le trafic de tous les autres joueurs effectue deux sauts à travers le relais ».

Relais : genres, jeux, avantages et inconvénients

• Genres de jeux clés : jeux coopératifs et occasionnels hébergés par les joueurs dont les utilisateurs sont derrière un NAT ou des pare-feu, et sessions de crossplay entre différents réseaux de plateformes.

• Exemples de jeux utilisant des relais : Among Us, qui « utilise toujours des serveurs relais », selon le développeur principal d'Innersloth ; TEKKEN 8, conçu sur le middleware réseau Diarkis ; Street Fighter 6, Deep Rock Galactic et Warhammer: Vermintide 2, qui basculent sur Steam Datagram Relay lorsqu'une connexion directe n'est pas disponible (ticket GitHub GameNetworkingSockets n° 398) ; et les serveurs Valheim démarrés en mode crossplay, où, selon le guide des serveurs d'Iron Gate, « le serveur transmet les données via un serveur relais et ne nécessite donc pas de redirection de port ».

• Avantages clés : traversée du NAT et des pare-feu, adresses IP des joueurs masquées, protection contre les attaques par déni de service entre joueurs, et intégration rapide sans création de serveur.

• Inconvénients majeurs : un saut réseau supplémentaire, aucune validation du gameplay, l'avantage de latence de l'hôte et les limites matérielles persistent, la migration d'hôte est toujours requise, et le routage dépend des emplacements du fournisseur de relais.

Among Us illustre également les limites de la catégorie. Son développeur principal a expliqué en 2020 que ses serveurs relais « font partiellement autorité afin que je puisse éviter des calculs physiques coûteux sur les serveurs (ce qui me permet d'évoluer à moindre coût) tout en gérant la plupart des hacks, la migration d'hôte, etc. » Un relais qui vérifie le jeu accomplit le travail d'un serveur.

Les relais empêchent-ils la triche ?

Non. Ils limitent l'exposition par rapport au peer-to-peer brut, et l'avantage s'arrête là.

Le gain est réel sur un point. Les joueurs ne peuvent pas voir l'adresse IP des autres, ils ne peuvent donc pas cibler les personnes avec lesquelles ils sont associés au moyen d'attaques par déni de service.

La partie elle-même reste hébergée par un joueur. L'hôte possède l'état du jeu et peut l'altérer via l'édition de mémoire, le lag switch ou de faux résultats de match, avec ou sans relais sur le chemin. La logique faisant autorité est également intégrée dans la version du jeu que chaque joueur télécharge. N'importe qui peut décompiler cette version pour comprendre comment l'hôte valide la partie, puis la modifier. Un relais ne voit jamais rien de tout cela. Il ne fait que transférer des paquets.

Les données entourant la session peuvent aussi fuiter. Buras a montré des données de salon d'un jeu commercialisées en train d'être lues avec un outil de débogage standard : « À l'aide d'une simple application appelée Fiddler, vous pouvez accéder à ce stockage d'informations du salon et exposer toutes les données privées des autres joueurs en texte clair. » Son verdict : « c'est un risque énorme à porter pour un jeu commercial. »

Ajouter des vérifications au relais ne modifie pas sa nature fondamentale. « Dès que vous calculez, ce n'est plus un serveur relais », a déclaré Buras. « Cela devient une forme de serveur dédié. »

Les services de relais sont-ils gratuits ?

Plusieurs plateformes incluent des relais sans frais. Valve propose Steam Datagram Relay via Steamworks, et Epic Online Services, qu'Epic décrit comme « la suite modulaire et gratuite », inclut la mise en réseau peer-to-peer avec des relais.

Gratuit ne signifie pas sous votre contrôle. Le studio ne choisit pas l'emplacement des relais, la façon dont les joueurs sont routés ni le moment où les bugs de routage sont corrigés. Buras a souligné le problème de localisation : « Compte tenu du nombre limité de relais, un joueur peut être redirigé vers des relais distants en fonction de la disponibilité du moment. »

La migration d'hôte est l'autre coût qui n'apparaît pas sur une facture. Comme l'a formulé Buras : « bien que le coût initial des relais soit faible, la solution de migration d'hôte que vous devez développer devient extrêmement coûteuse. » Son analyse complète se trouve dans le récapitulatif de la présentation d'Edgegap.

À quoi ressemble un basculement vers des relais en production

Il est facile d'approuver ces deux premiers points de manière abstraite. Un incident survenu en 2026 sur Steam Networking les a rendus concrets.

Vers la mi-mars 2026, les joueurs ont commencé à signaler que les matchs en peer-to-peer s'étaient considérablement détériorés. Dans Street Fighter 6, des joueurs israéliens se connectant de PC à PC constataient des pings d'environ 120 ms, tandis que les joueurs européens sur le même jeu obtenaient 60 à 80 ms. Ces mêmes joueurs israéliens se connectant à une PlayStation 5 en cross-play avaient un ping de 5 à 10 ms.

La connexion des joueurs n'était pas en cause. Le paramètre « Partager l'adresse IP » de Steam n'était pas respecté, de sorte que les tentatives de connexion directe basculaient silencieusement sur Steam Datagram Relay, et le relais le plus proche n'était pas assez près pour compenser l'écart. Le problème s'est répété sur Warhammer: Vermintide 2, Deep Rock Galactic, Melty Blood et d'autres jeux, avec des rapports venant d'Israël, d'Égypte et de Chine. Une seule régression dans une couche réseau partagée, ressentie dans chaque jeu qui en dépendait.

Le comportement de routage lui-même était délibéré. La documentation peer-to-peer de Valve note que sur Steam, les adresses IP ne sont souvent pas partagées entre pairs non approuvés, afin que des joueurs malveillants ne puissent pas lancer d'attaques DoS. C'est une raison valable de préférer un relais. Cela signifie également que le chemin du relais doit être rapide partout où se trouvent vos joueurs, car c'est le chemin qu'ils emprunteront.

Ce qui mérite réflexion, c'est ce que les studios pouvaient y faire. Très peu de choses. Capcom ne pouvait pas publier de correctif pour s'en sortir, car la décision de routage n'appartenait pas à Capcom. Les joueurs ont improvisé, d'abord avec un mod communautaire puis en copiant manuellement steamwebrtc64.dll dans leurs dossiers de jeu, une solution de contournement qui ne fonctionnait que si les deux joueurs le faisaient. Valve a confirmé le bug sur GitHub, a déployé un correctif dans une version bêta du client Steam, puis dans le client principal. Environ trois mois se sont écoulés entre le premier signalement et le correctif déployé (ticket GitHub GameNetworkingSockets n° 398).

Les relais gratuits ne sont pas exempts de conséquences. Ils s'accompagnent des décisions de routage de quelqu'un d'autre, selon le calendrier de quelqu'un d'autre, mesuré par rapport à la carte de quelqu'un d'autre indiquant où vivent réellement les joueurs. Ce dernier aspect est celui que les studios sous-estiment, et c'est pourquoi la densité de couverture compte plus que n'importe quel benchmark isolé. Pour en savoir plus, lisez notre analyse expliquant pourquoi la seule vraie réponse à la latence est d'avoir plus d'emplacements.

Les relais de jeu Unity sont-ils gratuits ?

La réponse était auparavant « non, et cela évolue avec l'utilisation ». Depuis 2026, la question a changé, car Unity ne propose plus du tout d'hébergement de serveurs de jeu.

Multiplay Game Server Hosting a été abandonné le 1er avril 2026, après une date limite de migration fixée au 31 mars. Le propre avis de service de Unity le formule sans détour : « À compter du 1er avril 2026, Multiplay Game Server Hosting par Unity est obsolète. Les clients ne peuvent plus faire évoluer de nouveaux serveurs de jeu ni effectuer de nouvelles allocations vers le service Multiplay. » Les studios qui avaient déclaré leur intention de migrer vers Multiplay by Rocket Science avant la date limite ont été autorisés à continuer à fonctionner pendant leur transition.

Les relais n'ont pas disparu pour autant. Unity Relay, ainsi que Lobby, Friends et Vivox, font toujours partie de Unity Gaming Services. Selon la page de tarification de Unity, le prix de Relay dépend du nombre d'utilisateurs simultanés et de la bande passante, avec un niveau gratuit de 50 CCU mensuels en moyenne. Les studios disposant d'une large base de joueurs ou d'un trafic réseau important doivent modéliser ce que cela coûte à grande échelle.

Cette combinaison place un studio Unity dans une situation inhabituelle. Le relais est toujours là. L'hébergement faisant autorité ne l'est plus. Les équipes qui avaient prévu de commencer sur Relay pour passer à Multiplay dès que leur jeu deviendrait compétitif doivent désormais choisir un partenaire d'hébergement quoi qu'il en soit, et elles le choisissent dans l'urgence plutôt que selon leur propre calendrier.

Relais pour WebGL et jeux par navigateur

Les jeux par navigateur ont moins d'options de mise en réseau que les jeux natifs. Un jeu conçu sur WebSockets ne peut pas connecter les joueurs directement entre eux, de sorte que chaque partie passe par un serveur. Un jeu conçu sur WebRTC peut tenter une connexion directe et bascule sur un relais en cas d'échec.

Ce relais porte un nom spécifique. Les serveurs STUN aident un navigateur à découvrir son adresse publique, mais ils ne transportent pas le trafic de jeu. Ce sont les serveurs TURN (RFC 8656) qui assurent le relais.

Pour les jeux par navigateur, le relais est souvent le chemin par défaut plutôt que la solution de repli. Son emplacement définit le plancher de latence pour chaque partie, et les limites d'autorité de l'hôte mentionnées ci-dessus s'appliquent toujours. Un jeu par navigateur qui a besoin de parties équitables et validées achemine déjà tout par un serveur, de sorte que rendre ce serveur autoritaire est une étape moins importante que pour un jeu natif en peer-to-peer.

Évoluer au-delà du relais : serveurs de jeu faisant autorité ?

Un relais change par qui passe votre trafic. Il ne change pas qui décide de ce qui est vrai. Presque toutes les autres limites d'une configuration avec relais découlent de cette unique distinction.

• Les triches mentionnées plus tôt fonctionnent toujours. L'état du jeu réside sur la machine d'un joueur, de sorte que la modification de la mémoire, le lag switch et les faux résultats restent possibles. Un relais masque les adresses IP et résout le NAT. Il ne valide pas le moindre paquet de gameplay.

• Chaque paquet effectue deux sauts. Le trafic va de joueur à relais puis à joueur, au lieu de joueur à serveur. L'emplacement du relais définit le plancher de latence de toute la partie, et aucune astuce de netcode ne peut récupérer ce qu'un relais mal situé ajoute.

• L'hôte reste un point de défaillance unique. Lorsque le joueur hôte quitte, plante ou ferme brutalement le jeu, la partie soit s'arrête, soit boîte à travers une migration d'hôte. Ni l'un ni l'autre ne fait bonne impression dans un mode classé.

• Le matériel de l'hôte plafonne le jeu. Le tickrate de simulation, le nombre d'entités, le nombre de joueurs et le plafond de bande passante dépendent tous du joueur sélectionné et de la connexion dont il dispose.

• Il n'y a pas de côté serveur sur lequel s'appuyer. Aucune validation faisant autorité, aucune persistance entre les matchs, aucune télémétrie gérée par le serveur, aucun replay, aucun tickrate contrôlé. Les fonctionnalités incontournables des jeux compétitifs n'ont nulle part où exister.

L'hébergement de serveurs de jeu apporte la solution à cette liste. Il s'agit de fournir une infrastructure en ligne pour les jeux multijoueurs, y compris des serveurs dédiés qui exécutent la partie sur une machine qu'aucun joueur ne contrôle. L'hébergement peut être géré par les développeurs de jeux eux-mêmes ou par des sociétés tierces.

L'hébergement façonne tout, de la latence au matchmaking. À mesure que le multijoueur devient plus central dans un plus grand nombre de jeux, sa qualité, sa fiabilité et son évolutivité importent tant aux développeurs qu'aux joueurs.

Il remet également la décision de routage entre les mains du studio. Lorsqu'une région subit soudainement 120 ms, l'équipe qui gère le déploiement est celle qui peut corriger le problème, au lieu d'ouvrir un ticket et d'attendre la mise à jour client de quelqu'un d'autre.

L'objection historique à tout cela concernait le coût et la charge opérationnelle. L'exécution de serveurs dédiés impliquait de réserver une capacité payée que les joueurs soient là ou non, et d'embaucher des compétences DevOps pour la maintenir. C'est ce calcul qui a poussé toute une génération de studios vers le P2P et les relais gratuits à l'origine, et c'est la partie qui a le plus changé. L'orchestration juste-à-temps démarre un serveur à la demande en environ 3 secondes, sur plus de 615 emplacements dans le monde, à un tarif unique quelle que soit la région. Un studio AAA a mesuré une réduction moyenne de latence de 58 % après avoir adopté ce modèle, avec une latence inférieure à 50 ms pour 78 % de ses joueurs (étude de cas de studio AAA).

Ce qui recadre la comparaison. L'attrait d'un relais n'a jamais été de produire de meilleures parties. C'était d'être économique et simple là où les serveurs dédiés n'étaient ni l'un ni l'autre.

Quelle option convient à votre jeu ?

Un serveur dédié n'a pas besoin d'exécuter une simulation complète. Le glossaire des serveurs dédiés d'Edgegap décrit quatre niveaux d'envergure, chacun coûtant plus de CPU par joueur que le précédent.

Un serveur de type relais ou multi-salles peut tourner sur une fraction de vCPU, ce qui rapproche son coût de celui d'un relais tout en ôtant l'autorité des machines des joueurs. C'est le point de départ par défaut recommandé.

Un jeu en peer-to-peer derrière un relais convient encore à un ensemble restreint de cas : sessions entre amis uniquement sans mode classé, sans économie de jeu et sans inconnus dans le salon, et jeux déterministes en lockstep où chaque pair exécute déjà la simulation complète.

Conclusion

Les relais ont un rôle bien réel. Ils corrigent le NAT, masquent les adresses IP et s'intègrent rapidement. Pour un jeu coopératif entre amis ou un premier prototype, cela peut suffire.

Ce qu'un relais ne peut pas faire, c'est maîtriser le jeu. Dès que l'intégrité compétitive, une économie, la persistance ou des performances régulières d'une région à l'autre deviennent indispensables, la question n'est plus de savoir comment le trafic est routé, mais où la simulation s'exécute. L'incident Steam de 2026 a révélé l'autre revers de la médaille : quand l'itinéraire appartient à quelqu'un d'autre, la solution dépend aussi de lui.

—

Cet article cite les travaux répertoriés dans les Sources. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.

Sources

• Michal Buras, alors ingénieur réseau principal chez Highwire Games, intervention au Live Service Game Summit, 10 septembre 2024 (transcription intégrale).

• Valve, Steam Networking, documentation Steamworks.

• Valve, README P2P de GameNetworkingSockets et ticket n° 398, GitHub, 2026.

• Epic Games, Epic Online Services.

• Unity Technologies, Relay, documentation Netcode for GameObjects ; avis d'obsolescence de Multiplay, 31 mars 2026 ; tarification Unity Gaming Services.

• Iron Gate Studio, Guide des serveurs dédiés, support Valheim.

• Développeur principal d'Innersloth (u/fwfb), commentaire sur r/gamedev sur l'architecture des serveurs d'Among Us, 2020.

• IETF, RFC 8656 (TURN).

• Glossaire Edgegap : serveur relais, serveur dédié.