Bien que souvent invisible pour les joueurs, l'infrastructure de jeu multijoueur qui assure une connectivité sécurisée des joueurs et la stabilité du jeu est tout aussi cruciale que le gameplay lui-même.

L'un des composants clés de cette infrastructure, souvent négligé, est le serveur relais.

Dans cet article, nous allons approfondir le rôle des serveurs relais dans les réseaux peer-to-peer (P2P), aborder les spécificités des services de relais de base tels que Unity, Steam et Epic Online Services et leurs cas d'utilisation, ainsi que les cas où les services de relais améliorés sont préférables, tout en abordant le sujet plus large de l'hébergement de serveurs de jeux et les raisons pour lesquelles les serveurs se déconnectent parfois.

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

En résumé, dans le contexte des jeux en ligne, un serveur relais atténue et résout les problèmes courants du peer-to-peer en agissant comme un serveur « intermédiaire » qui transmet les communications entre les joueurs.

En d'autres termes, les relais agissent comme des ponts (ou des routeurs/proxys), relayant les messages entre des pairs qui ne peuvent pas établir de connexions directes. En relayant les données entre les joueurs, ils jouent un rôle crucial dans l'établissement de connexions entre des joueurs susceptibles de rencontrer des obstacles tels que des pare-feux ou des problèmes de traduction d'adresses réseau (NAT). Ces problèmes de NAT sont si extrêmement courants que des entreprises comme Xbox ou PlayStation y consacrent des pages d'assistance entières.

Les relais améliorent généralement l'expérience de jeu en réduisant la latence et la perte de paquets, à condition que le serveur relais lui-même soit robuste et que le service d'orchestration qui le soutient place les relais à proximité géographique des joueurs. Dans le cas contraire, le relais introduira de la latence, ce qui risque de réduire l'équité entre les joueurs proches du relais et ceux qui ne le sont pas (si l'un des clients du jeu agit en tant que serveur faisant autorité).

Comprendre l'architecture Peer-to-Peer dans le jeu vidéo moderne

L'architecture réseau peer-to-peer est un élément bien ancré de la structure backend des jeux multijoueurs. Dans une configuration P2P, l'une des machines des joueurs fait office de serveur, gérant la logique du jeu et la synchronisation pour tous les participants.

Cette approche minimise souvent les coûts des développeurs, car un joueur se charge de l'hébergement de la partie, et elle est plus simple à mettre en œuvre. Pour les petits titres ou les studios qui trouvent les frais d'hébergement trop élevés, c'est un excellent choix.

Cependant, cela se traduit souvent par une expérience de jeu moins qu'idéale, avec des performances de jeu incohérentes, en particulier si le joueur hôte ne dispose pas d'une connexion Internet haut débit ou d'un matériel adéquat. Pire encore, le P2P peut facilement être exploité par des tricheurs pour manipuler le jeu et par des attaquants qui peuvent cibler vos joueurs. Cela en fait une mauvaise solution pour tout studio qui souhaite faire du jeu compétitif une stratégie de rétention à long terme, et cela réduit la rétention à long terme car les joueurs très engagés ne voient plus le retour sur leur investissement continu dans le jeu.

Les titres de toutes tailles, des indépendants aux AAA, se tournent vers un modèle de serveur de jeu complet ou hybride qui combine des serveurs de jeu faisant autorité avec des relais. Pour savoir quel modèle est le plus adapté, consultez notre guide sur les [serveurs faisant autorité, relais et peer-to-peer](https://edgegap.com/blog/explainer-series-authoritative-servers-relays-peer-to-peer-understanding-networking-types-and-their-benefits-for-each-game-types).

Techniques de triche dans les réseaux Peer-to-Peer

L'un des défis majeurs du P2P réside dans le fait que des acteurs malveillants exploitent les vulnérabilités de l'hébergement P2P. Les tricheurs ont mis au point diverses méthodes pour obtenir un avantage injuste ou perturber l'expérience de jeu des autres :

• Lag Switching : Les tricheurs peuvent intentionnellement introduire du lag pour perturber le déroulement du jeu. En retardant la transmission de leurs données, ils peuvent « figer » temporairement le jeu et effectuer des mouvements sans que les autres joueurs puissent réagir en temps réel.

• Manipulation de données : Étant donné que les données de jeu résident sur les clients individuels, un tricheur peut modifier ses données pour s'octroyer une santé infinie, des munitions illimitées ou même changer de position instantanément.

• Ghosting : Dans les jeux où les joueurs sont censés avoir une visibilité limitée de la carte ou des autres joueurs, un tricheur pourrait obtenir une visibilité totale, ce qui lui confère un avantage injuste.

Pourquoi les serveurs de jeux tombent-ils en panne ou s'arrêtent-ils ?

Les interruptions de serveur sont toujours une période frustrante pour les joueurs. Elles surviennent souvent en raison d'opérations de maintenance, de mises à jour, de problèmes imprévus ou même de cyberattaques. Dans certains cas, les serveurs de jeu sont définitivement fermés, une décision généralement motivée par la baisse de la base de joueurs, des considérations financières, la sortie de suites et de nouveaux titres, ou encore par les ressources limitées du studio.

Service de relais : gratuit ou payant ?

Les relais sont des serveurs de jeu utilisés pour aider les joueurs à se connecter sans générer de coûts de calcul, ce qui signifie que les joueurs eux-mêmes restent les gardiens chargés d'autoriser les actions du jeu. Ainsi, les serveurs nécessaires sont minimaux. Des entreprises comme Epic, avec Epic Online Services, et Steam, avec Steamworks, fournissent gratuitement des relais aux développeurs de jeux lorsqu'ils utilisent leurs solutions backend.

Bien qu'ils constituent un excellent premier pas, ces services sont extrêmement limités en termes d'emplacements et ne sont pas réputés pour être les plus fiables. Voici pourquoi les services de relais gratuits ne sont pas idéaux pour les jeux produits commercialement :

• Latence accrue : L'introduction d'un intermédiaire peut augmenter la latence du jeu si le serveur relais est géographiquement éloigné des joueurs. Il est donc essentiel de l'associer à un système d'orchestration automatisé qui déploie les relais au plus près des utilisateurs. Avec une faible densité de couverture, ces services sont connus pour introduire de la latence.

• Fiabilité : Si un serveur relais tombe en panne, cela perturbera l'expérience de jeu des joueurs connectés. Si tous les relais sont hébergés chez le même fournisseur et qu'une panne survient, tous les joueurs seront déconnectés. Par conséquent, seul un réseau d'orchestration de relais multi-cloud peut garantir une grande fiabilité.

• Autorité : Les réseaux de relais ne sont pas des serveurs faisant autorité. Ils ne peuvent pas remplacer l'autorité d'un serveur central pour les jeux hautement compétitifs et au rythme rapide.

À quoi ressemble un repli sur les relais en production

Ces deux premiers points sont faciles à accepter dans l'abstrait. Un incident survenu en 2026 sur Steam Networking les a rendus concrets.

À partir de 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 connectés de PC à PC ont constaté des pings d'environ 120 ms, tandis que les joueurs européens sur le même titre ont constaté 60 à 80 ms. Les mêmes joueurs israéliens se connectant à une PlayStation 5 via le cross-play ont constaté un ping de 5 à 10 ms.

Les connexions des joueurs n'étaient pas en cause. Le paramètre « Partager l'adresse IP » de Steam n'était pas respecté, de sorte que les tentatives de connexion directe se rabattaient silencieusement sur le Steam Datagram Relay, et le relais le plus proche n'était pas assez près pour compenser la différence. Le même schéma s'est répété sur Warhammer: Vermintide 2, Deep Rock Galactic, Melty Blood et d'autres, avec des signalements provenant 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 propre documentation de Valve sur le peer-to-peer indique que sur Steam, ils relaient toujours le trafic et ne partagent pas les adresses IP entre pairs non approuvés, afin que des joueurs malveillants ne puissent pas lancer d'attaques DoS. C'est une excellente raison de préférer un relais. Cela signifie également que le chemin de relais doit être rapide partout où se trouvent vos joueurs, car c'est le chemin qu'ils emprunteront.

Ce qu'il convient de retenir, c'est ce que les studios pouvaient faire pour y remédier. Très peu de choses. Capcom ne pouvait pas publier de correctif, car la décision de routage n'était pas de son ressort. 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 publié 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 rapport et le correctif déployé (problème GameNetworkingSockets #398).

Les relais gratuits ne sont pas sans conséquences. Ils s'accompagnent des décisions de routage de quelqu'un d'autre, selon le calendrier de quelqu'un d'autre, mesurées par rapport à la carte d'un autre pour savoir où vivent réellement les joueurs. Ce dernier point est celui que les studios sous-estiment, et c'est pourquoi la densité de couverture importe plus que n'importe quel benchmark individuel. Pour en savoir plus, lisez notre analyse sur les raisons pour lesquelles [la seule véritable réponse à la latence est d'avoir plus d'emplacements](https://edgegap.com/blog/for-true-latency-reduction-the-only-answer-is-more-locations).

Les relais de jeu Unity sont-ils gratuits ?

La réponse était auparavant « non, et le tarif s'ajuste en fonction de l'utilisation ». En 2026, la réponse est différente, car Unity ne propose plus du tout d'hébergement de serveurs de jeux.

L'hébergement de serveurs de jeu Multiplay a été abandonné le 1er avril 2026, suite à une date limite de migration fixée au 31 mars. L'avis de service de Unity le dit clairement : « À compter du 1er avril 2026, l'hébergement de serveurs de jeu Multiplay par Unity est obsolète. Les clients ne peuvent plus dimensionner de nouveaux serveurs de jeu ni effectuer de nouvelles allocations sur le service Multiplay. » Les studios ayant déclaré leur intention de migrer vers Multiplay de Rocket Science avant la date limite ont été autorisés à continuer de fonctionner pendant leur transition.

Les relais n'ont pas disparu pour autant. Unity Relay, ainsi que Lobby, Friends et Vivox, font toujours partie des Unity Gaming Services, et la tarification de Relay est toujours basée sur l'utilisation : bande passante, utilisateurs simultanés, nombre de requêtes et autres variables. Son but est de simplifier l'établissement et le maintien des connexions réseau pour les jeux multijoueurs, et c'est une option plus fiable et évolutive que le P2P brut. Les développeurs doivent tout de même évaluer ce que cela coûte à grande échelle, en particulier pour les jeux ayant une base de joueurs importante ou un volume de trafic réseau élevé.

Il est intéressant de voir ce que cette combinaison laisse entre les mains d'un studio Unity. Le relais est toujours là. L'hébergement faisant autorité ne l'est plus. Les équipes qui avaient prévu de commencer avec Relay puis de passer à Multiplay une fois leur jeu devenu compétitif doivent désormais choisir un partenaire d'hébergement quoi qu'il arrive, et elles le choisissent sous la contrainte d'une date limite plutôt que selon leur propre calendrier.

Relais pour les jeux WebGL

Les jeux WebGL sont particulièrement sensibles aux problèmes liés aux relais traditionnels. Les jeux WebGL ont tendance à avoir facilement 2 à 5 fois plus de latence, car sur WebGL, un websocket ne peut pas effectuer de perforation NAT en direct. Il a besoin d'un serveur relais (serveur STUN) pour la NAT (traduction d'adresses réseau).

Cela renforce encore le besoin d'un service d'orchestration capable d'aider à surmonter ce défi de latence, comme Edgegap, qui se déploie au plus près des utilisateurs sur un réseau mondial très dense afin d'atténuer ce problème inhérent aux jeux WebGL multijoueurs.

Présentation du réseau de relais : une solution potentielle

Un moyen pratique et facile à intégrer pour contrer certaines des vulnérabilités de l'hébergement P2P consiste à utiliser un réseau de relais.

Au lieu de se connecter directement les uns aux autres, les joueurs se connectent à des serveurs relais, qui gèrent ensuite la transmission des données entre eux. Ceux-ci sont beaucoup plus faciles à intégrer que des serveurs faisant autorité, moins coûteux à exploiter et offrent des avantages considérables par rapport à un hébergement purement P2P.

Les avantages comprennent :

• Masquage des adresses IP : Les adresses IP des joueurs sont masquées les unes des autres car ils se connectent uniquement au serveur relais. Les relais empêchent les attaques basées sur l'IP et protègent la vie privée des joueurs.

• Équité de la qualité de connexion : Comme tout le monde se connecte au relais, tous les avantages réseau (comme le fait d'être l'hôte dans un scénario P2P) sont neutralisés. Tout le monde bénéficie d'une qualité de connexion plus cohérente.

• NAT : Par conception, les relais résolvent les problèmes de connectivité NAT bien documentés du P2P en agissant comme intermédiaire pour les utilisateurs, offrant des connexions fluides et une expérience de jeu optimale. Plus précisément, ils surmontent les restrictions de traversée NAT et de pare-feu.

• Possibilité de détection de la triche : Les serveurs relais peuvent être équipés d'algorithmes anti-triche qui surveillent les données de jeu en temps réel. Les schémas suspects ou les anomalies peuvent être signalés, ce qui facilite la détection et la dissuasion des tricheurs.

Ces avantages ne valent qu'à une seule condition, que l'incident de Steam Networking mentionné plus haut illustre bien : le relais doit être proche du joueur. Un relais qui neutralise l'avantage de l'hôte mais ajoute 60 ms pour toute une région a simplement remplacé un problème d'équité par un autre.

Passer du relais aux serveurs de jeu faisant autorité ?

Un relais modifie la trajectoire de votre trafic. Il ne change pas qui décide de ce qui est vrai. Presque toutes les limites restantes d'une configuration de relais découlent de cette seule distinction.

• Les tricheries mentionnées précédemment fonctionnent toujours. L'état du jeu réside sur la machine d'un joueur, la manipulation des données, le lag switching et le ghosting sont donc toujours 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 du joueur au relais, puis au joueur, plutôt que du joueur au serveur. L'emplacement du relais détermine le seuil minimal de latence pour l'ensemble de la partie, et aucune astuce de netcode ne permet de récupérer ce qu'un relais mal placé ajoute.

• L'hôte reste un point de défaillance unique. Lorsque le joueur hôte quitte, subit un plantage ou ferme le jeu par dépit, la partie s'arrête ou continue tant bien que mal via une migration d'hôte. Aucune de ces situations n'est acceptable dans un mode classé.

• Le matériel de l'hôte limite le jeu. Le tickrate de simulation, le nombre d'entités, le nombre de joueurs et le plafond de bande passante sont tous décidés par le joueur qui a été choisi, quelle que soit la connexion dont il dispose.

• Il n'y a pas de côté serveur sur lequel s'appuyer. Pas de validation faisant autorité, pas de persistance entre les matchs, pas de télémétrie propre au serveur, pas de rediffusions, pas de tickrate contrôlé. Les systèmes qu'un jeu compétitif est censé proposer n'ont aucun endroit où résider.

L'hébergement de serveurs de jeux est la réponse à cette liste. Il s'agit de fournir une infrastructure en ligne pour les jeux multijoueurs, y compris des serveurs dédiés qui fonctionnent 24 h/24 et 7 j/7, garantissant que les joueurs peuvent se connecter et jouer ensemble quel que soit leur emplacement. L'hébergement peut être géré par les développeurs de jeux eux-mêmes ou par des entreprises tierces.

Un hébergement de serveur de jeu efficace est crucial pour les composants en ligne d'un jeu, impactant tout, de la latence au matchmaking. Alors que les expériences multijoueurs deviennent de plus en plus centrales dans le jeu vidéo, la qualité, la fiabilité et l'évolutivité de l'hébergement de serveurs deviennent primordiales pour les développeurs comme pour les joueurs.

Cela remet également la décision de routage entre les mains du studio. Lorsqu'une région voit soudainement son ping monter à 120 ms, l'équipe qui gère le déploiement est celle qui peut résoudre le problème, plutôt que de soumettre un rapport et d'attendre la mise à jour du client d'un tiers.

L'objection historique à tout cela était le coût et la complexité opérationnelle. Exploiter des serveurs dédiés signifiait provisionner de la capacité que vous payiez que les joueurs soient présents ou non, et recruter les compétences DevOps nécessaires pour la maintenir en état de marche. 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 précisément ce qui a le plus changé. L'[orchestration](https://edgegap.com/platform/orchestration-hosting) juste-à-temps démarre un serveur à la demande en environ 3 secondes, sur [plus de 615 emplacements à travers le monde](https://edgegap.com/blog/world-s-largest-distributed-network-edgegap-continues-to-expand-with-615-locations-worldwide), à un [tarif unique quelle que soit la région](https://edgegap.com/pricing). Un studio AAA a mesuré une réduction moyenne de la latence de 58 % après être passé à ce modèle, avec une latence inférieure à 50 ms pour 78 % de sa base de joueurs ([étude de cas](https://edgegap.com/gaming/case-studies/AAA-Studio)).

Ce qui redéfinit la comparaison. L'attrait d'un relais n'a jamais été de produire de meilleures parties. C'était qu'il était bon marché et facile à utiliser, alors que les serveurs dédiés ne l'étaient pas.

Pour plus de détails sur les raisons et les moments où les serveurs faisant autorité peuvent être plus adaptés que les relais, consultez notre guide sur les types de réseaux.

Conclusion

Comprendre les nuances de l'infrastructure des serveurs de jeux, des serveurs relais aux solutions d'hébergement, est essentiel pour les développeurs de jeux et la communauté des joueurs.

Les services de relais de base offrent des solutions simplifiées, mais ils s'accompagnent de coûts et de considérations pour votre jeu et l'expérience de vos joueurs. Ces coûts ne sont pas toujours visibles sur une facture. Parfois, ils se traduisent par une région entière de joueurs qui cessent discrètement de rejoindre la file d'attente.

Les relais ont une réelle utilité. Ils corrigent le NAT, masquent les adresses IP, s'intègrent rapidement et, pour un titre en coopération ou une version préliminaire, ils constituent souvent le bon choix. Un réseau de relais avec orchestration automatisée sur une infrastructure dense et sans contrainte de région représente une amélioration substantielle par rapport au P2P brut et à une offre gratuite limitée.

Ce qu'un relais ne peut pas faire, c'est gérer le jeu en lui-même. Dès que l'intégrité compétitive, la persistance ou les performances constantes d'une région à l'autre commencent à impacter la rétention, le facteur décisif n'est plus la manière dont le trafic est routé, mais l'endroit où la simulation s'exécute. Deux des trois problèmes évoqués dans cet article, à savoir une région bloquée à 120 ms et un studio incapable de corriger son propre netcode, découlaient du fait de ne pas maîtriser cette réponse.

En savoir plus sur l'orchestration et l'hébergement de serveurs de jeux d'Edgegap, lire les études de cas ou plonger dans notre Documentation.