Pools de lobbys dans OpenFront : guide OpenFront.io étape par étape

Réponse directe

Un pool de lobbys est un groupe de deux à huit lobbys identiques qu’un hôte crée d’un seul coup ; seul le premier apparaît dans la liste publique. Quand vous rejoignez cette carte listée, le serveur choisit un salon frère pour vous via un hachage déterministe de votre identité persistante et envoie une redirection que votre client suit automatiquement. Vous êtes routé uniquement en tant que nouvel arrivant : les joueurs qui se reconnectent, les spectateurs, les joueurs sur liste blanche et les administrateurs restent dans leur lobby. La fonctionnalité est annoncée dans v0.34.19 (2026-09-25) mais ne fonctionne réellement qu’à partir de v0.34.20 (2026-09-26). Si vous atterrissez dans un frère sans votre ami, la redirection s’est déjà produite une fois — rechargez le lobby listé d’origine et réessayez.

Ce qui se passe ensuite, en détail. Vous cliquez sur la carte listée, le client ouvre une connexion vers la pièce d’entrée, et avant que l’entrée ne réponde « ouverte » ou « pleine », le serveur exécute une classification : à quel pool ce joueur appartient-il ? S’il appartient à un pool, le serveur calcule le hachage de votre identité, sélectionne la sœur de ce hachage, et vous y envoie directement — vous ne verrez jamais la liste complète de l’entrée pendant ce temps. Cet ordre est essentiel, car il montre que le routage de pool n’est pas une porte supplémentaire « après » l’entrée, mais la toute première classification de votre tentative de connexion. Cela explique plusieurs contre-intuitions : lorsque vous êtes « redirigé », vous n’avez pas d’abord rejoint l’entrée puis été renvoyé ; la sœur où vous atterrissez est précisément celle que le serveur a choisie pour vous ; et le terme « redirigeur » est en fait imprécis — vous n’êtes jamais entré dans la pièce correspondant à la carte que vous avez vue, vous êtes allé directement dans sa sœur. Une fois cela compris, la réponse à « pourquoi suis-je allé dans une autre pièce » passe de « c’est un bug » à « le routage de pool fonctionne comme prévu », et votre seule tâche devient de confirmer que cette pièce est bien une sœur de ce pool (même mode, même carte, même compte à rebours), plutôt que de traquer un échec de connexion qui n’a jamais eu lieu. C’est aussi le point de départ de chaque étape de dépannage de ce guide : confirmer d’abord que ce que vous voyez est le routage de pool et non une déconnexion/reconnexion ou un renvoi anti-triche, puis décider si vous devez agir.

Pourquoi une carte listée peut être plusieurs lobbys

Dans toutes les versions avant v0.34.19, une carte de lobby du navigateur public était exactement un lobby : une seule liste de joueurs, un seul minuteur de départ, une seule salle. Si cette salle était pleine ou pas encore ouverte, le serveur vous le disait et vous restiez sur le navigateur. À partir de v0.34.19, un hôte qui crée un lobby listé via la route pool administrateur peut créer jusqu’à sept salons frères en même temps, tous partageant la configuration de l’entrée. La liste publique n’affiche toujours qu’une seule carte — l’entrée — parce que les identifiants des frères sont traités comme des secrets de connexion et le serveur les retire de chaque trame lobby_info qu’il envoie. Ce qui change, c’est ce qui se passe au moment où vous cliquez sur rejoindre : au lieu de répondre « plein » ou « ouvert » pour une seule salle, le serveur demande désormais quel membre d’un petit groupe de salles doit vous accueillir.

Cette conception répond à un problème réel signalé par les joueurs avant les pools. La liste de lobbys publics est mince ; les fils communautaires demandaient régulièrement une liste filtrable ou se plaignaient qu’attendre un jeu listé prenne vingt minutes ou plus. Une carte listée unique qui absorbe une foule entière dans huit salles est une solution de capacité qui ne modifie pas le navigateur du tout : la carte a la même apparence, le mode et les pastilles de modificateurs sont identiques, le compte à rebours de départ aussi, mais la taille effective de la salle est multipliée. C’est le but des pools en une phrase, et c’est aussi pourquoi la fonctionnalité est invisible jusqu’à ce que vous constatiez que le lobby que vous avez chargé n’est pas celui que votre ami a chargé. Pour le contexte sur ce que la carte publique promet elle-même — mode, départ choisi par l’hôte de 1 à 5 minutes, capacité de 10 à 100 joueurs, et le seuil d’abonnement pour héberger — lisez le guide des lobbys publics. Si la carte que vous voulez lister est derrière un plan payant, le guide des lobbys publics spéciaux couvre le seuil qui décide si vous pouvez créer un lobby listé du tout.

La mécanique est délibérément à sens unique. Le serveur peut router un arrivant de l’entrée vers un frère, et il peut aussi router un arrivant qui atteint directement un frère de nouveau dans le pool pour équilibrer la charge, mais il ne déplace jamais de joueurs déjà dans un lobby, et n’expose jamais le groupe de frères aux clients. Il n’y a pas de liste de membres du pool en jeu, pas de badge « pool de 8 » sur la carte, et aucun moyen de parcourir les frères. Les seuls effets observables sont l’endroit où vous apparaissez et dans quelle liste de joueurs vous atterrissez.

Comment le serveur choisit votre frère

La fonction de routage est petite et entièrement déterministe : un hachage de votre identité persistante, mélangé à l’identifiant du pool lui-même, modulo le nombre de frères. Écrit explicitement, le serveur calcule index = hash(poolId + ":" + votreIdentifiantPersistant) % nombreDeFrères, puis cherche le frère à cet index dans la liste ordonnée du pool. Si cet index correspond au lobby que vous aviez déjà visé, la redirection est entièrement ignorée et vous rejoignez la salle que vous avez cliquée — un pool ne force donc pas la redirection à tout le monde, seulement à la majorité des arrivants.

Deux propriétés de cette formule comptent pour la sensation de la fonctionnalité. Premièrement, l’identifiant du pool est mélangé avant le modulo, ce qui signifie que le même joueur pointant vers deux pools différents de même taille peut atterrir sur des ordinaux différents : vous n’êtes pas cloué à « toujours le lobby 3 » dans tous les pools de taille égale du serveur. Deuxièmement, le hachage est stable par joueur, donc dans un pool donné vous serez toujours envoyé vers le même frère tant que la taille du pool ne change pas. Vous ne pouvez pas tirer à nouveau pour un autre lobby en rejouant, parce que l’entrée du hachage ne change pas à la réentrée. Ce qui change l’entrée, c’est la taille du pool : un hôte ne peut ni ajouter ni retirer des frères après la création, mais deux groupes de pools de tailles différentes répartiront le même joueur différemment.

Parce que le hachage est calculé à partir d’une identité de joueur stable, le routage est aussi cohérent d’une manière qui compte pour les lobbys d’équipe : le serveur ne sépare pas les coéquipiers délibérément, et ne brise jamais une liste existante, parce que la reconnexion est exemptée (voir la section suivante). Ce qu’il fait, c’est répartir les nouveaux arrivants. Un pool de huit se comporte donc comme une carte unique avec huit listes : les premiers arrivants atterrissent chacun dans un frère différent, et après le premier tour la distribution est ce que dit le hachage. Il n’y a pas d’ordre « remplir la salle 1, puis la salle 2 » — le modulo ne privilégie pas la première salle vide, il privilégie un bucket déterministe. C’est pourquoi un pool peut avoir un frère presque plein et un autre presque vide au même moment, et pourquoi vous ne devriez pas lire le nombre de joueurs sur un frère comme un signal de la remplissage du pool dans son ensemble.

La redirection elle-même est une trame de contrôle, pas un message de lobby. Le serveur envoie un message de type redirect portant l’identifiant du lobby cible, et il l’envoie avant toute réponse de complet ou démarré. Dans le code serveur, le commentaire sur cet ordre est explicite : être routé n’est pas un refus. Cette distinction est le fait le plus important pour interpréter les renvois, parce qu’elle signifie qu’un résultat « vous avez été envoyé ailleurs » et un résultat « ce lobby est plein » sont deux décisions serveur différentes, et une erreur côté joueur suivant une tentative de redirection doit être diagnostiquée par rapport au chemin de redirection, pas au chemin de lobby complet.

Qui est routé, et qui ne l’est pas

Le chemin d’admission exécute la vérification de pool dans un ordre fixe, et cet ordre définit les exemptions. Premièrement, le serveur vérifie si le client qui rejoint existe déjà dans la liste cible en tant que joueur : si c’est le cas, le jeu est une reconnexion et la logique de pool est ignorée. Deuxièmement, le serveur vérifie les rôles et les listes : un administrateur rejoignant le lobby, un joueur sur la liste blanche du lobby, et un client dont le rôle est spectateur contournent tous la redirection. Troisièmement, pour tous les autres qui sont vraiment nouveaux dans la liste, le serveur calcule la cible du hachage et, si elle diffère du lobby que vous avez visé, émet la redirection.

Conséquences pratiques à mémoriser :

La reconnexion ne ré-route jamais. Si vous êtes déconnecté en cours de match et que vous revenez au même lobby, vous atterrissez là où vous étiez. Le serveur vous identifie dans la liste existante avant la vérification de pool, et cette vérification est ignorée. L’expérience « j’ai été renvoyé au menu et j’ai rejoué » n’est donc jamais une redirection de pool ; les kicks et les déconnexions sont une autre classe de pannes, traitée hors du routage de pool.
Les spectateurs sont cloués. Activer le mode spectateur dans l’entrée d’un pool refuse le commutateur si la cible du hachage est un autre membre : vous ne pouvez pas specter le lobby dans lequel vous auriez été routé en tant que joueur. Vous spectez exactement le lobby que vous visez.
La liste blanche prime sur le pool. Un joueur sur la liste blanche de l’entrée rejoint l’entrée elle-même, que le hachage dise quoi que ce soit. Si vous et un ami voulez être dans la même salle dans un environnement de pool, le seul mécanisme pris en charge est la liste blanche.
Les administrateurs sont cloués. Le personnel rejoignant l’entrée d’un pool reste dans l’entrée, c’est ainsi que les opérateurs peuvent surveiller la carte d’entrée sans être dispersés dans le pool.
Les nouveaux arrivants sont répartis. Tout le monde d’autre — le cas normal — est haché vers l’un des frères.

Une asymétrie de plus : la redirection ne se fait que vers le pool pour un nouvel arrivant. Le serveur ne déplace jamais un joueur d’un frère à un autre au fur et à mesure que les listes se remplissent, il n’y a donc pas de comportement de « complément » qui tirerait un joueur hors d’un lobby où il est déjà. Le pool répartit les arrivants à la porte ; une fois que vous êtes dedans, vous êtes dedans.

La frontière de version : v0.34.19 l’annonce, v0.34.20 la fait fonctionner

L’histoire de la fonctionnalité fait deux versions d’épaisseur et la frontière compte, parce que les deux versions font des affirmations différentes. Les notes de version v0.34.19 (publiées le 2026-09-25) annoncent la fonctionnalité : un lobby listé peut répartir les arrivants dans un pool de lobbys frères. Les notes de version v0.34.20 (publiées le 2026-09-26) donnent ensuite la correction : les pools de lobbys qui ne se formaient jamais en production se forment désormais, et les lobbys listés peuvent réellement répartir les arrivants entre des lobbys frères. La seconde puce existe parce que la première version a livré du code qui ne produisait pas de pools fonctionnels dans l’environnement en production ; entre les deux dates de version, le code de routage était présent sur le serveur mais les pools n’étaient effectivement pas créés.

Trois conséquences en découlent. Premièrement, tout rapport communautaire ou stream de la fenêtre v0.34.19 disant « les pools ne marchent pas » est cohérent avec l’enregistrement de version, pas un rapport de bug contre v0.34.20. Deuxièmement, le comportement en production que vous lisez dans ce guide est le comportement v0.34.20 et ultérieur ; si vous lisez un ancien guide ou regardez une ancienne vidéo décrivant le comportement des pools, vérifiez sa ligne de version avant de lui faire confiance. Troisièmement, la borne de taille du pool de deux à huit, le listing de l’entrée seulement, et la configuration figée à la création viennent tous de la même révision de code que v0.34.20 a livrée, donc chaque nombre dans ce guide est un nombre v0.34.20.

La configuration elle-même est aussi verrouillée par version d’une seconde manière, plus silencieuse : le bloc pool est uniquement à la création. La route de correctif de lobby ne copie pas un champ pool, ce qui signifie qu’un hôte ne peut pas ajouter de frères à un lobby listé existant ni redimensionner un pool après la création. Si vous voulez un pool, vous créez le pool au début ; il n’y a pas de chemin de mise à niveau en jeu de « lobby listé unique » à « lobby listé avec sept frères ». C’est une décision de conception, pas une fonctionnalité manquante : l’échéance de départ automatique partagée et la configuration partagée font du pool un objet atomique unique, et l’enregistrement de versions ne contient aucune version ultérieure qui étend le bloc pool via la route de correctif à la frontière de version documentée ici.

Cadre décisionnel : que faire avant de cliquer sur rejoindre

Appliquez cet ordre à toute carte listée du navigateur public :

Décidez si la même salle compte. Si vous rejoignez pour jouer avec un ami spécifique, le pool est par défaut hostile à votre objectif : chacun de vous est haché indépendamment, et deux hachages indépendants atterrissent dans le même frère seulement par coïncidence (probabilité 1 sur N pour un pool de taille N). La solution prise en charge est la liste blanche sur le lobby d’entrée ; si l’hôte ne vous met pas sur liste blanche, acceptez que vous puissiez être séparés.
Décidez si la liste exacte compte. Pour le jeu compétitif ou pertinent pour le classement où la composition de votre équipe d’ouverture est une variable, la liste d’un membre du pool est inconnue jusqu’à ce que vous chargiez. Si vous tenez à l’équipe que vous formez, traitez le pool comme un tirage aléatoire sur huit listes possibles et planifiez le pire cas d’un tirage ; si vous n’y tenez pas, le pool est strictement meilleur qu’une salle unique complète, parce que la carte reste rejoignable.
Vérifiez le minuteur de départ sur la carte. Le pool partage une seule échéance de départ entre tous les membres (l’échéance de l’entrée est copiée à chaque frère à la création du pool), donc le compte à rebours que vous voyez sur la carte est le compte à rebours de chaque membre. Vous n’êtes jamais envoyé dans un frère qui démarre plus tôt ou plus tard que ce que la carte promet ; le minuteur que vous lisez est le minuteur que vous obtenez.
Supposez que le groupe de frères est fermé. Vous ne pouvez pas voir les autres membres, vous ne pouvez pas choisir entre eux, et vous ne pouvez pas voir leur nombre de joueurs. Toute stratégie ayant besoin de ces informations (par ex. « rejoindre le frère le plus vide ») n’est pas prise en charge ; la seule variable contrôlable est votre identité persistante, et ce n’est pas quelque chose que vous devriez faire tourner pour tricher sur le hachage.
Si vous êtes l’hôte, décidez la taille du pool avant la création. Deux frères doublent la salle effective ; huit rend la carte quasi jamais « pleine ». Choisissez la taille pour la foule attendue, pas la plus petite qui fonctionne, parce que vous ne pouvez pas faire grandir le pool ensuite.

La raison pour laquelle la liste de contrôle commence par la stabilité de la connexion est que le rapport le plus courant de « j’ai été redirigé » n’est pas un redirigeur de pool — c’est une déconnexion-et-reconnexion, ou un renvoi par anti-triche, qui fait croire au joueur qu’il a « atterri » dans une pièce différente. La différence pratique est importante : une déconnexion laisse généralement des traces dans le journal ou l’interface (un message « déconnecté », un écran noir), tandis qu’un routage de pool n’en laisse aucune — la transition est transparente côté client, et vous passez directement de la liste à la sœur sans message d’erreur. Pour trancher entre les deux, regardez deux choses : d’abord, y a-t-il eu un moment où vous étiez « hors » du jeu (écran de connexion, message de déconnexion) ? Si oui, c’est probablement une déconnexion et non un pool. Deuxièmement, la pièce où vous atterrissez a-t-elle exactement le même mode et la même carte que la carte que vous aviez cliquée ? Si oui, c’est très probablement un routage de pool. Si non, vous êtes dans une pièce réellement différente, et la cause est quelque chose d’autre (un autre lobby, un changement de file, un bug de liste). Ce simple tri — déconnexion contre routage de pool — règle la majorité des rapports, car il sépare les deux causes les plus confondues et vous amène directement vers le bon ensemble de vérifications suivantes.

Scénario A : vous avez cliqué sur la carte listée et atterri sans votre ami

Mise en place : vous et un ami ouvrez tous deux la même carte FFA listée dans un pool de quatre. Vous cliquez sur rejoindre, votre ami clique sur rejoindre, et vous chargez dans des lobbys différents. C’est le résultat attendu, pas un bug : vos deux identités persistantes produisent deux valeurs de hachage indépendantes, et avec quatre frères la probabilité que vous atterrisez ensemble est 1 sur 4. Rien n’est cassé, et il n’y a pas d’option côté serveur « restons ensemble » pour les nouveaux arrivants.

Que faire, par ordre de préférence :

Demandez à l’hôte de vous mettre tous deux sur liste blanche. L’exemption de liste blanche se déclenche avant le hachage, donc vous rejoignez tous deux l’entrée directement. C’est le seul mécanisme de même salle pris en charge dans un pool, et il requiert l’hôte, alors envoyez un message au hôte du lobby avant le prochain événement de pool, pas pendant.
Ré-entrez via l’entrée ensemble. Si l’hôte ne peut pas vous mettre sur liste blanche, re-rejoignez le lobby d’entrée (la carte listée) plutôt que le frère où vous avez atterri. Votre cible de hachage est stable, donc re-rejoindre vous remettra dans le même frère — ce qui signifie que re-rejoindre ne vous aide pas à trouver votre ami ; cela n’aide votre ami que s’il re-rejoint l’entrée et que son hachage atteint par hasard votre frère (encore 1 sur 4). N’attendez pas qu’une boucle de recharge corrige ça ; l’entrée du hachage ne change pas à la réentrée.
Acceptez la séparation et coordonnez en chat. En FFA, la séparation est souvent sans importance ; en modes d’équipe, elle change votre équipe, donc si la composition de l’équipe vous importe, traitez le pool comme un tirage au sort et choisissez des modes ou des lobbys où votre équipe ne dépend pas d’un duo pré-arrangé.

Ce qu’il ne faut pas faire : n’interprétez pas la séparation comme un kick ou une panne de détection anti-bot, et ne la signalez pas comme « renvoyé du lobby » sans le contexte qu’un pool était présent — le support et les fils communautaires confondront sinon cela avec les pannes de refus couvertes dans la section de pannes ci-dessous.

Comment confirmer que c’est bien le pool et pas un autre problème, avant de conclure. La séparation par défaut dans un pool de quatre est attendue, mais il faut quand même éliminer les deux autres causes qui partagent le même signe visible. Première vérification, la version : si l’un de vous est sur un client antérieur à la v0.34.19, le pool ne peut tout simplement pas s’exécuter dans ce client, donc la séparation ne vient pas du routage mais d’une autre cause (rebond anti-bot, déconnexion) — vérifiez les deux clients, pas seulement le vôtre. Deuxième vérification, le mode : dans un mode d’équipe, si vous atterrissez dans des équipes différentes, c’est cohérent avec le pool (deux hachages indépendants), mais si vous atterrissez dans le même lobby d’entrée et que l’un de vous a été éjecté vers le menu avec un message d’erreur, ce n’est pas le pool, c’est un refus de connexion — le pool ne renvoie jamais personne au menu, il ne fait que choisir une sœur. Troisième vérification, le compte à rebours : un vrai redirigeur de pool vous met dans une sœur qui a le même compte à rebours de démarrage que l’entrée ; si la pièce où vous atterrissez a un compte à rebours totalement différent ou un mode différent, ce n’est pas une sœur du pool, c’est un autre lobby. Ces trois vérifications prennent une minute et séparent le « c’est le pool, c’est normal » du « il y a un vrai problème de connexion ». Dans les modes compétitifs et classés, la séparation par le pool est plus coûteuse qu’en FFA décontracté, car la composition de l’équipe compte davantage : le conseil de la section précédente de « choisir des modes où votre équipe ne dépend pas d’un duo pré-arrangé » est encore plus pertinent ici, et la mise sur liste blanche par l’hôte devient presque obligatoire si vous tenez à jouer avec votre partenaire.

Scénario B : vous êtes l’hôte d’un lobby listé et la carte se remplit pendant que vos frères sont vides

Mise en place : vous hébergez un lobby d’équipe listé dans un pool de huit et la carte publique montre l’entrée près de sa capacité, tandis que vous savez que le pool a six autres frères vides. Vous vous attendez à ce que la carte continue d’absorber des joueurs, mais les nouveaux arrivants continuent d’atterrir sur l’entrée et le nombre de la carte monte vers le plein.

Deux choses se passent en même temps. Premièrement, le hachage répartit les nouveaux arrivants entre les huit frères, donc l’entrée ne se remplit pas linéairement : chaque nouvel arrivant a une chance de 1 sur 8 d’atterrir sur l’entrée elle-même. Le nombre de la carte est la liste de l’entrée, pas le total du pool, et le serveur ne vous montre jamais le total du pool. Deuxièmement, l’état « plein » de la carte est l’état « plein » de l’entrée : quand la liste de l’entrée atteint sa capacité, le serveur répond « plein » pour l’entrée — et la logique de redirection s’exécute avant la réponse de plein, donc un arrivant pointant vers une entrée pleine peut encore être routé vers un frère non plein. La carte peut donc montrer un nombre qui semble plein alors que le pool a encore de la place, et c’est la fonctionnalité qui fonctionne comme conçue, pas un lobby bloqué.

Votre procédure d’exploitation en tant qu’hôte :

Ne lisez pas le nombre de la carte comme la santé du pool. La seule déclaration fiable que vous puissiez faire depuis la carte concerne l’entrée. Si vous avez besoin de l’occupation au niveau du pool, les outils d’administration sont la source, pas la carte publique.
Taillez le pool pour le pic, puis acceptez la queue. Parce que le pool est fixé à la création, un pool sous-taillé (deux frères pour une foule de quarante) montrera l’entrée se remplir pendant que le pool a encore de la place seulement brièvement ; un pool sur-taillé (huit frères pour une foule de dix) laissera six frères quasi vides et dispersera votre communauté entre des lobbys. Pour un événement listé récurrent, huit est la valeur par défaut sûre ; pour un lobby décontracté de duo-plus-amis, deux.
Utilisez la liste blanche pour votre noyau. Vos réguliers peuvent être mis sur liste blanche sur l’entrée pour qu’ils partagent toujours une salle avec vous, tandis que la foule publique se répartit dans le pool. Cela garde votre noyau stable sans sacrifier l’avantage de capacité du pool.

Un point d’hébergement que le scénario précédent ne couvre pas : ce qui arrive à la date limite de démarrage automatique du pool une fois que les joueurs sont répartis entre les sœurs. La date limite est définie au niveau du groupe, elle ne compte donc qu’une seule fois, et non par sœur — ce qui signifie qu’un pool de huit sœurs peut démarrer alors que l’une d’elles est vide, car le compte à rebours n’attend pas que chaque sœur soit pleine. Si vous hébergez et tenez à une salle pleine dans chaque pièce, le levier que vous avez réellement est le nombre de sœurs, pas la date limite : moins de sœurs (deux ou trois) garde le groupe serré et rend plus probable que chaque pièce soit pleine à la date limite, tandis que plus de sœurs (six à huit) disperse les joueurs et rend les pièces vides au moment du départ plus probables. La date limite elle-même doit être assez courte pour qu’une sœur à moitié pleine n’attende pas des minutes, mais assez longue pour qu’un retardataire qui est hashé vers une sœur encore ouverte ait le temps d’y atterrir avant le départ. La seule chose que l’hôte ne peut pas faire est de « tirer » un joueur spécifique d’une sœur vers une autre — le redirigeur est unidirectionnel et aucune action admin ne déplace un joueur déjà installé dans une sœur vers la pièce d’entrée. Si vous avez besoin d’un joueur spécifique dans une pièce spécifique, le seul chemin fiable est de caler son arrivée : le faire arriver fraîchement à un moment où la sœur voulue a encore une place, ou le faire reconnecter (s’il est déjà dans le pool) pour que le serveur le remet là où il était. Cette contrainte de calage est la version côté hôte de la règle côté joueur du scénario A, et c’est pour cela que le conseil du cadre décisionnel de « faire de vous deux des connexions fraîches au même moment » fonctionne : c’est l’hôte qui contrôle le moment, pas le serveur, qui garde une paire ensemble.

Pannes et contre-mesures

Le chemin de redirection est petit, mais il a quatre formes de panne distinctes, et chacune a une cause différente et une contre-mesure différente. Diagnostiquer laquelle vous regardez est le jeu entier ici, parce que le symptôme côté joueur pour au moins deux d’entre elles est « j’ai essayé de rejoindre et j’ai eu une erreur ».

Redirection suivie, puis erreur de connexion. Le gestionnaire de redirection du client met un verrou dans sessionStorage quand il suit une redirection de pool et traite une seconde redirection comme une connexion refusée, pour que le client ne puisse pas boucler entre deux frères. Si vous obtenez un « connection refused » immédiat juste après une carte listée, les causes probables sont : le frère cible a été supprimé ou fermé entre la décision de redirection et la tentative de connexion (rare, côté serveur), ou le verrou est déjà mis par une tentative échouée précédente dans le même onglet et la seconde redirection est traitée comme une boucle. Contre-mesure : fermez entièrement l’onglet (effaçant sessionStorage) et re-entrez via la carte listée. Ne réessayez pas plus d’une fois dans le même onglet.
Redirection suivie, cible pas dans le pool attendu. Si vous atterrissez dans un lobby dont le mode ou la carte ne correspond pas à la carte, ce n’est pas le pool : tous les frères d’un pool partagent la configuration de l’entrée par construction (les frères sont frappés depuis la même config, et la route de correctif ne peut pas les faire diverger). Un écart de mode ou de carte signifie que vous avez rejoint la mauvaise carte, pas que le pool vous a mal routé. Contre-mesure : re-vérifiez les pastilles de mode et de carte de la carte par rapport au lobby que vous avez chargé ; si elles diffèrent, vous avez cliqué sur un autre listing.
Refus qui ressemble à un renvoi de pool mais est un refus de détection anti-bot. « Connection refused: Unauthorized: Turnstile token rejected » est la détection anti-bot de Cloudflare refusant le jeu, et c’est sans rapport avec le routage de pool. Les fils communautaires de 2026 rapportent cela comme la plainte « renvoyé des lobbys » la plus courante, et elle précède les pools. Contre-mesure : les remèdes standard de détection anti-bot (redémarrer, essayer un autre lobby, essayer un autre réseau) s’appliquent, et aucun d’eux n’implique le pool. Si vous êtes renvoyé par cette erreur d’un lobby mais pas d’un autre, la cause est le jeton, pas le lobby.
Kick vers le menu en cours de match. Un retour soudain à l’écran de démarrage est une déconnexion ou un kick, et la reconnexion est exemptée du routage de pool, donc un kick n’est jamais une redirection de pool. Si vous êtes kické puis re-rejoignez, vous atterrissez dans votre lobby d’origine, pas un frère. Contre-mesure : vérifiez les causes habituelles (redémarrage du serveur, inactivité, expiration de session) avant d’attribuer un kick en cours de match au pool.

Un tableau de diagnostic rapide pour les quatre formes :

Symptôme	Cause	Contre-mesure
« Connection refused » immédiatement après avoir rejoint une carte listée	Verrou anti-boucle de redirection, ou cible fermée entre décision et connexion	Fermer l’onglet, re-entrer via la carte listée
Le mode/carte du lobby chargé diffère de la carte	Mauvaise carte, pas un mauvais routage du pool (les frères partagent la config)	Re-vérifier les pastilles de la carte ; re-rejoindre le bon listing
« Turnstile token rejected »	Refus de la détection anti-bot de Cloudflare, sans rapport avec les pools	Remèdes standard anti-bot ; signaler comme un problème de jeton, pas de pool
Kické vers le menu en cours de match, le re-jeu m’atterrit dans le même lobby	Déconnexion/kick ; la reconnexion est exemptée du routage	Voir le guide des causes de kick

Ajustements par mode et par carte

Les pools ne changent pas le mode, la carte ou les pastilles de modificateurs : tous les frères héritent de la configuration de l’entrée, et le serveur ne retire rien de la trame de config sauf les identifiants de frères. Ce que les pools changent, c’est le mélange de joueurs dans un mode, et les ajustements ci-dessous sont des notes par mode sur ce que cela signifie pour vos décisions d’ouverture.

FFA. Le pool est un avantage net. Votre position d’ouverture est tirée de vos propres choix, pas de la liste, donc la seule chose qui change est la taille de la foule disponible pour la carte. Si vous jouez FFA contre une carte listée, traitez la carte comme « rejoignable tant que le pool n’est pas réellement plein », et ne vous retirez pas parce que le nombre de l’entrée semble élevé.
Modes d’équipe. Le pool est la variable qui compte. Votre équipe est ce que la liste actuelle du frère plus vous produit, et le frère est inconnu jusqu’à ce que vous chargiez. Si vous êtes le leader de fait d’une équipe que vous voulez contrôler, la liste blanche est votre outil ; si vous êtes un joueur flexible, le pool est une fonctionnalité : vous atterrissez sur la liste qui a besoin de votre rôle. Planifiez votre construction d’ouverture pour le pire tirage de composition d’équipe, pas pour le tirage attendu.
Lobbys nucléaires / à enjeux élevés. Si votre mode a de longues préparations (préparation nucléaire, réseaux SAM), une séparation entre frères est coûteuse : votre contre-plan prévu à la base d’un adversaire spécifique peut être dans un frère que vous ne verrez jamais. Pour les lobbys où vous contrez un joueur nommé, la liste blanche ou un lobby privé bat le pool ; pour le jeu public ouvert, acceptez la séparation.
Lectures spécifiques à la carte. Un pool ne change pas quelle carte est chargée, donc la connaissance de la carte se transfère inchangée entre les frères. Ce qui ne se transfère pas, c’est l’état de la carte : les deux frères exécutent la même carte au même moment de départ, mais avec des joueurs différents et donc une expansion précoce différente. Ne supposez pas que votre coéquipier de l’entrée est dans le frère que vous avez chargé ; re-identifiez votre liste dans les trente premières secondes.

Les angles mode et carte concernent la même fonctionnalité en différentes tenues, et les différences comptent pour votre réaction. En mode classé et compétitif, un redirigeur de pool est généralement moins perturbateur qu’en FFA décontracté, car les règles de mise en relation et de lobby du mode sont plus strictes et le pool est moins susceptible de se former dans un premier temps. Si vous êtes redirigé dans un contexte classé, la conséquence pratique est la même (vous atterrissez dans une sœur avec le même mode et le même compte à rebours), mais l’enjeu d’être dans une pièce différente de celle de votre coéquipier est plus élevé, donc le conseil de coordination du cadre décisionnel compte davantage. En FFA décontracté et dans les lobbys spéciaux publics, les pools sont le cas plus courant, et le redirigeur fait partie normale de l’expérience plutôt qu’une exception. Sur les cartes, le pool ne change pas la carte — chaque sœur exécute la même carte que l’entrée, car le groupe de pool partage la config de l’entrée. Ce qui change est la composition de la pièce : une sœur peut avoir un mélange de joueurs différent, un écart de compétence différent, et un ensemble de vétérans différent de l’entrée que vous regardiez dans la liste. C’est la chose pratique à internaliser quand un redirigeur change votre plan de jeu : la carte et le mode sont identiques, mais les gens avec ou contre qui vous jouez sont différents, et une sœur qui ressemble à « la même » dans la liste peut se jouer très différemment en pratique. La seule considération spécifique à la carte est que les groupes de pool sont créés par l’hôte et que l’hôte choisit la carte, donc si vous hébergez un pool vous choisissez aussi quelle carte chaque sœur exécute, et le choix de carte est le même pour les huit sœurs (ou combien qu’il y en a) du groupe. Cela signifie qu’un choix de carte qui fonctionne bien pour un lobby unique est un choix de carte qui fonctionne bien pour chaque sœur du pool, et qu’une carte qui est maladroite pour un lobby est maladroite pour tout le groupe.

Tableau : le pool en un coup d’œil

Propriété	Valeur	D’où ça vient
Taille du pool	2 à 8 frères	La route `create_pool` valide `count` avec `min(2).max(MAX_POOL_MEMBERS)`, `MAX_POOL_MEMBERS = 8`
Listing	Seule l’entrée est listée	`applyListing` est appliqué à `lobbies[0]` seulement à la création du pool
Configuration	Partagée, figée à la création	Les frères sont frappés depuis la config de l’entrée ; la route de correctif ne copie pas `pool`
Heure de départ	Une seule échéance partagée pour tout le pool	L’échéance de départ automatique de l’entrée copiée à chaque frère (`setPoolAutoStartAt`)
Entrée du routage	`hash(poolId + ":" + identifiantPersistant) % taille`	`poolIndexFor` / `poolTargetFor` dans `PoolRouting.ts`
Cible de redirection	Frère à l’index haché ; ignoré si égal à l’entrée visée	`poolTargetFor` renvoie `null` quand la cible égale l’entrée
Exemptions	Reconnexion, rôle administrateur, `publicId` sur liste blanche, spectateurs	Chemin d’admission dans `GameServer.ts`
Commutateur spectateur	Refusé si la cible du hachage est un autre membre	Vérification de pool de `setSpectateur`
Comportement client	Suit la redirection via une navigation complète de page ; verrou `sessionStorage` empêchant une seconde redirection (traitée comme refusée)	Gestionnaire de redirection de `Transport.ts`
Identifiants de frères	Retirés de chaque trame `lobby_info` (secrets de connexion)	`configWithoutPool` dans `GameServer.ts`
Fixes d’équipe	Rejetés pour les pools (`teams_unsupported_for_pool`)	Validation de `create_pool`
Frontière de version	Annoncée v0.34.19 (2026-09-25) ; fonctionnelle depuis v0.34.20 (2026-09-26)	Notes de version v0.34.19 et v0.34.20

Comment lire le tableau, car les lignes ne sont pas une liste à cocher qu’on parcourt de haut en bas mais un ensemble de faits sur une fonctionnalité, et l’ordre est choisi pour que chaque ligne réponde à la question que la précédente soulève. Les trois premières lignes sont le quoi (ce qu’est un pool, ce que fait le redirigeur, qui est exempt), et ce sont les lignes à lire en premier si vous êtes nouveau sur la fonctionnalité. Les lignes du milieu sont le quand (la limite de version et la date limite de démarrage automatique), et ce sont les lignes à lire si vous essayez de comprendre pourquoi un pool s’est formé ou non sur une version donnée. Les lignes du bas sont le comment (la commande admin, le redirigeur côté client, la garantie de redirigeur-une-fois), et ce sont les lignes à lire si vous êtes l’hôte ou l’admin et devez créer ou inspecter un pool. Le tableau est volontairement bref — c’est une référence, pas un tutoriel — donc la ligne qui compte le plus pour vous est celle qui répond à la question avec laquelle vous êtes venu, et le reste est là pour quand vous devez croiser un détail. Si vous êtes joueur, les lignes qui comptent sont « qui est exempt » et « le redirigeur est unidirectionnel » ; si vous êtes hôte, les lignes qui comptent sont « create_pool » et « date limite de démarrage automatique » ; si vous êtes admin, la ligne qui compte est « la config de pool est partagée entre les sœurs ». L’usage pratique le plus courant est de l’ouvrir quand un comportement vous surprend et de chercher la ligne qui correspond au symptôme : un joueur qui atterrit dans une pièce inattendue regarde la ligne « le redirigeur est unidirectionnel » pour rappeler qu’il ne peut pas « revenir » dans l’entrée ; un hôte dont le pool ne démarre pas regarde la ligne sur la date limite de démarrage automatique pour vérifier que le compte à rebours n’est pas trop court ; un admin qui vérifie un pool regarde la ligne sur la config partagée pour rappeler que toutes les sœurs héritent du mode et de la carte de l’entrée. Le tableau sert donc de point d’ancrage rapide : au lieu de relire tout le guide quand un détail précis vous échappe, vous trouvez la ligne qui porte ce détail et vous y revenez, ce qui fait gagner du temps par rapport à une recherche dans le texte complet.

Un outil vérifiable : la route pool d’administration

Le seul endroit où vous pouvez voir un pool plutôt que seulement le vivre est l’API bot d’administration. La route POST /api/adminbot/create_pool est la seule façon dont un pool entre en existence, et sa forme de requête documente les contraintes de la fonctionnalité en forme lisible par machine :

POST /api/adminbot/create_pool
{
  "count": 4,                    // 2..8, le nombre de frères (entrée comprise)
  "lobby": { ...config... }      // la config complète du lobby d'entrée ; les frères la copient
}

Trois propriétés de la requête rendent les contraintes concrètes. Le champ count est le seul régulateur de taille, et il est validé contre min(2).max(8) — une requête pour un frère est refusée, et une requête pour neuf est refusée, donc la borne de taille du tableau ci-dessus n’est pas une affirmation de documentation, c’est une erreur de validation que vous pouvez déclencher. La config lobby est la source unique pour chaque frère : il n’y a pas de champ par frère dans la requête, c’est pourquoi les frères ne peuvent pas diverger en mode, carte ou pastilles de modificateurs. Et la réponse renvoie les identifiants de lobbys frappés, avec seulement le premier listé — la réponse elle-même montre la forme du pool (N identifiants, un listing public), qui est exactement la forme qu’un joueur ne voit jamais depuis le côté client.

Vous n’appellerez probablement pas cette route vous-même : c’est un point d’accès bot d’administration, et le chemin joueur public est simplement « rejoindre une carte listée et laisser le serveur vous router ». La route compte pour ce guide parce qu’elle est la vérité de fait pour chaque nombre du tableau ci-dessus — borne de taille, listing de l’entrée seulement, config partagée, existence seulement à la création — et si une version future change l’un de ces nombres, la forme de validation et de réponse de cette route est là que le changement sera visible en premier.

Que fait la route d’admin, du point de vue de l’hôte. La commande create_pool est le moyen par lequel un pool prend existence : l’hôte (ou un admin ayant la permission) nomme un pool et spécifie combien de sœurs il faut, et le serveur crée alors un groupe de pièces identiques, où seule la première apparaît dans la liste publique. Comprendre cette commande permet de lire la ligne « la config de pool est partagée entre les sœurs » de la table — le partage n’est pas un accident, c’est le résultat de create_pool écrivant une seule config dans chaque sœur en une fois. Pour l’hôte, la signification pratique est que la taille du pool (deux à huit sœurs) détermine combien de joueurs vous « étalez » en une fois, et à quelle fréquence la pièce d’entrée paraît « pleine » dans la liste — car la liste n’affiche que l’entrée, et les joueurs ne savent pas qu’il y a des sœurs derrière. Si vous créez un pool pour décharger une pièce FFA encombrée, l’arbitrage est : plus le pool est grand, plus chaque sœur est vide et facile à rejoindre, mais plus le signal de « popularité » de l’entrée dans la liste est faible (les joueurs sont étalés) ; plus le pool est petit, plus l’entrée semble animée, mais plus chaque sœur se remplit vite. Cet arbitrage n’a pas de bonne réponse unique — cela dépend de ce que vous voulez : un « départ rapide » ou une « attractivité dans la liste ».

Que vérifier dans votre propre session

Parce que les pools sont invisibles depuis le client, la seule vérification honnête que vous puissiez faire est comportementale, et elle prend un seul jeu :

Rejoignez une carte listée que vous croyez être un pool (un lobby listé créé par un hôte pendant un événement est le cas probable) et notez dans quel lobby vous chargez.
Demandez à un ami qui a rejoint la même carte au même moment dans quel lobby il a chargé. S’il est dans un lobby différent avec le même mode, la même carte et le même moment de départ, la carte était un pool et le routage a fonctionné comme documenté.
Si vous êtes tous deux dans le même lobby, soit la taille du pool est un (pas de pool), soit vos deux hachages ont collisionné ; avec un pool de huit, la probabilité de collision est 1 sur 8, donc un même-lobby unique est une preuve faible des deux côtés — répétez avec plus d’amis pour une lecture plus forte.
Si vous êtes renvoyé par un « Turnstile token rejected » ou un kick vers le menu au lieu, ce n’est pas un résultat de pool : appliquez les contre-mesures de pannes ci-dessus avant d’attribuer quoi que ce soit au routage.

Le cas négatif est aussi important que le cas positif : si une carte listée ne vous sépare jamais d’un ami sur plusieurs jeux indépendants, la carte n’est pas un pool (ou la taille du pool est un). « Cette carte me fait toujours atterrir dans le même lobby que mon ami » est, dans un environnement de pool, le signal que le pool n’est pas présent.

La liste de vérification est ordonnée de la moins coûteuse à la plus coûteuse, car les trois premières vérifications ne prennent que quelques secondes et écartent la plupart des cas. La vérification de version (est mon client à ou après la v0.34.20) vient en premier, car elle distingue immédiatement « le pool n’existe pas » de « le pool fonctionne comme prévu ». Ensuite, la vérification de mode et de carte (la pièce où vous atterrissez a-t-elle le même mode et la même carte que l’entrée), qui confirme que vous voyez un routage de pool et non une pièce vraiment différente. La troisième, la vérification du compte à rebours (la date limite de démarrage automatique est-elle dans une plage raisonnable), distingue « le pool a démarré comme prévu » de « la date limite était trop courte et a démarré tôt ». Une fois ces trois passées, on passe aux vérifications plus lourdes : confirmer que les sœurs partagent réellement la config (point de vue admin), et confirmer que le routage est à sens unique (vous ne pouvez pas « revenir » à l’entrée). L’essentiel de la liste n’est pas « les faire toutes dans l’ordre » mais « face à un symptôme, faire d’abord la moins coûteuse » : si vous suspectez d’être allé dans la mauvaise pièce, commencez par la vérification de mode et carte ; si vous suspectez que le pool n’a pas démarré comme prévu, commencez par la vérification du compte à rebours ; si vous suspectez que votre client est trop vieux, commencez par la vérification de version. Le bénéfice pratique est que la majorité des rapports « j’ai été redirigé » trouvent leur réponse dans les trois premières vérifications, sans avoir à atteindre la vérification admin la plus lourde.

En résumé

Un pool de lobbys est un dispositif de capacité, pas un choix de destination : une carte listée, jusqu’à huit salles, un départ partagé, une config figée, et un hachage déterministe qui répartit les nouveaux arrivants entre les salles. Vous ne choisissez pas le frère, vous ne pouvez pas voir les frères, et vous ne pouvez pas voir l’occupation totale du pool — la carte est tout ce que vous obtenez, et le mode, la carte et le minuteur de la carte sont encore exactement ce qu’ils promettaient. Les décisions qui changent sont les décisions sociales : le jeu en même salle a besoin d’une liste blanche, le jeu d’équipe a besoin d’un plan de pire tirage, et un symptôme « renvoyé » a besoin du diagnostic en quatre formes avant d’être reproché au routage. Depuis v0.34.20, le mécanisme fonctionne comme les notes de version le décrivent ; avant cela, il était annoncé mais pas en production.

La version courte pour le joueur qui ne veut pas lire la suite. Un pool est un groupe de deux à huit pièces identiques que l’hôte crée en une fois ; seule la première apparaît dans la liste publique. Quand vous cliquez sur cette carte listée, le serveur choisit une sœur pour vous en fonction du hachage de votre identité, et vous y envoye directement — « être redirigé » signifie en réalité « atterrir dans une sœur », pas « être expulsé de l’entrée ». Trois choses à retenir : première, le routage est à sens unique, vous ne pouvez pas « revenir » à l’entrée ; deuxième, la sœur où vous atterrissez a le même mode et la même carte que l’entrée, seule la composition de joueurs change ; troisième, cette fonctionnalité est complète depuis la v0.34.20, et si votre client est antérieur, les pools n’existent tout simplement pas pour vous et vous voyez des connexions ordinaires. Face à « pourquoi suis-je allé dans une autre pièce », vérifiez d’abord la version du client, puis la concordance de mode et carte, enfin la plausibilité du compte à rebours — la plupart des cas trouvent leur réponse là. Si vous êtes hôte, la taille du pool détermine combien de joueurs vous étalez en une fois et à quelle fréquence l’entrée paraît pleine dans la liste ; choisissez selon que vous voulez un « départ rapide » ou une « attractivité dans la liste ». Si vous êtes admin, rappelez-vous que chaque sœur hérite de la config de l’entrée, donc modifier un point modifie tout le groupe.

Pools de lobbys dans OpenFront : quand un lobby listé vous envoie dans un salon frère