---
title: "Comment activer la whitelist sur un serveur 7 Days to Die ?"
description: "Restreignez l'accès à votre serveur 7 Days to Die Winheberg avec la whitelist, activation automatique dès la première entrée, commandes de console et section whitelist de serveradmin.xml."
category: jeux
subcategory: 7-days-to-die
icon: tabler:lock-check
date: 2026-09-08
author: Winheberg
slug: "activer-whitelist-7-days-to-die"
order: 89
image: /statics/images/docs/fr/gaming/7-days-to-die/activer-whitelist-7-days-to-die.webp
tags: [7 Days to Die, Whitelist, Sécurité, Panel gaming]
keywords: [whitelist 7 days to die, serveradmin.xml, whitelist add, serveur prive 7 days to die, restreindre acces serveur, eos id]
link_en: "/en/docs/7-days-to-die/enable-whitelist-7-days-to-die"
---

## Contexte

Un mot de passe de serveur se partage, se recopie et finit toujours par circuler. Quand vous voulez réserver un serveur 7 Days to Die à un groupe précis, amis, communauté fermée ou serveur de test, la whitelist est un contrôle plus solide, puisqu'elle s'appuie sur l'identifiant de chaque joueur et non sur un secret partagé.

Son fonctionnement réserve une surprise. Il n'existe aucune option à cocher pour l'activer, et aucune propriété correspondante dans `serverconfig.xml`. La whitelist s'active toute seule dès qu'elle contient au moins une entrée, et se désactive dès qu'elle est vidée.

Ce guide couvre son activation depuis le panel gaming Winheberg, la gestion des entrées et les erreurs classiques qui coupent l'accès à tout le monde.

## Prérequis

- Un [serveur 7 Days to Die](https://winheberg.com/gaming/7-days-to-die) actif sur le panel gaming Winheberg
- Les joueurs à autoriser doivent s'être connectés au moins une fois, afin de relever leur identifiant
- Un accès à l'onglet **Console** du serveur sur [panel.winheberg.com](https://panel.winheberg.com/)

> [!CAUTION]
> Dès la première entrée ajoutée, plus personne d'autre ne peut rejoindre le serveur. Ajoutez vos joueurs habituels avant de considérer la bascule comme terminée, sous peine de vous retrouver seul en ligne.

## 1. Comprendre le mécanisme d'activation

Le fichier `serveradmin.xml` contient une section `<whitelist>`, vide par défaut. Son commentaire interne est sans ambiguïté, dès qu'un élément y figure, le mode whitelist est actif, et personne ne peut rejoindre le serveur en dehors des joueurs listés et des administrateurs.

::MdTable{caption="État de la whitelist selon son contenu" variant="info" striped}
| Contenu de la section | Comportement du serveur |
|---|---|
| Aucune entrée | Serveur ouvert à tous, whitelist inactive |
| Au moins une entrée | Accès réservé aux joueurs listés et aux administrateurs |
::

> [!IMPORTANT]
> Les administrateurs déclarés dans la section `<users>` conservent l'accès même s'ils ne figurent pas dans la whitelist. C'est votre filet de sécurité si vous vous verrouillez dehors, à condition d'avoir déclaré votre compte comme administrateur au préalable.

## 2. Relever l'identifiant des joueurs

Comme pour les droits d'administration, le jeu identifie un joueur par un couple plateforme et identifiant, l'EOS ID pour la plupart des joueurs PC.

Demandez à chaque joueur de se connecter une fois au serveur, puis exécutez la commande suivante depuis l'onglet **Console** du panel.

```text
listplayerids
```

L'identifiant apparaît dans la sortie sous la forme `crossid=EOS_0002a2eacfff46808543ffdab9380672`. Seule la partie située après le préfixe `EOS_` est à conserver.

Pour la marche à suivre détaillée, consultez notre guide [Comment devenir administrateur sur un serveur 7 Days to Die ?](https://winheberg.com/docs/devenir-admin-7-days-to-die)

## 3. Ajouter des joueurs à la whitelist

La gestion se fait par commandes de console, sans barre oblique.

```text
whitelist add <joueur>
```

Tant qu'un joueur est connecté, son nom suffit.

```text
whitelist add Maxime
```

Le retrait et l'affichage suivent la même logique.

::MdTable{caption="Commandes de gestion de la whitelist" variant="info" striped}
| Commande | Effet |
|---|---|
| `whitelist add` | Ajoute un joueur à la whitelist |
| `whitelist remove` | Retire un joueur de la whitelist |
| `whitelist list` | Affiche la liste des joueurs autorisés |
::

> [!TIP]
> Commencez par vous ajouter vous même, puis vérifiez avec `whitelist list` avant d'ajouter le reste du groupe. Vous confirmez ainsi que la commande produit bien l'effet attendu avant que la restriction ne s'applique à tous.

## 4. Vérifier le contenu du fichier

La section correspondante de `serveradmin.xml` ressemble à ceci une fois remplie.

```xml
<adminTools>
  <whitelist>
    <user platform="EOS" userid="0002a2eacfff46808543ffdab9380672" name="Maxime" />
  </whitelist>
</adminTools>
```

L'attribut `name` est optionnel et purement décoratif. Les entrées de type `<group>` permettent d'autoriser un groupe Steam entier, identifié par son `steamID` de groupe.

Pour localiser le fichier, lisez la ligne `UserDataFolder` en tête du log de démarrage du serveur, le fichier se trouvant dans le sous dossier `Saves` de ce répertoire.

Sur les serveurs Winheberg, ce dossier est `.local/share/7DaysToDie/Saves`, à ouvrir depuis l'onglet **Files** en affichant les dossiers cachés.

<img src="/statics/images/docs/fr/gaming/7-days-to-die/activer-whitelist-7-days-to-die-1793565574167-666c1911a3c286ae34252a70.webp" alt="Dossier .local/share/7DaysToDie/Saves dans l onglet Files du panel Winheberg avec le fichier serveradmin.xml entoure en rouge" width="800" />

## 5. Désactiver la whitelist

Il n'y a rien à décocher. Videz la section de toutes ses entrées et le serveur redevient accessible à tous au redémarrage suivant.

```text
whitelist remove <joueur>
```

Répétez l'opération pour chaque entrée, puis confirmez avec `whitelist list` que la liste est bien vide.

## En cas de problème

### ❌ Plus personne ne peut rejoindre le serveur, moi compris

- Vérifiez que votre compte est déclaré comme administrateur dans la section `<users>`, les administrateurs contournent la whitelist
- Si vous n'avez pas d'accès administrateur, videz la section `<whitelist>` du fichier depuis l'onglet **Files** du panel, serveur arrêté
- Redémarrez le serveur après modification, le fichier est relu au démarrage

### ❌ Un joueur autorisé est quand même refusé

- Comparez son identifiant avec la sortie de `lpi`, un caractère erroné suffit à faire échouer la correspondance
- Vérifiez que le préfixe `EOS_` a bien été retiré de l'identifiant enregistré
- Confirmez que l'entrée figure dans la section `<whitelist>` et non ailleurs dans le fichier

### ❌ La whitelist ne semble pas s'appliquer

- Vérifiez que la section contient réellement au moins une entrée active et non uniquement les exemples mis en commentaire du fichier livré
- Les lignes situées entre les balises de commentaire XML ne sont pas prises en compte
- Redémarrez le serveur pour forcer la relecture du fichier

## Bonnes pratiques

- Déclarez vous administrateur avant d'activer la whitelist, c'est le seul moyen de garder un accès en cas de fausse manipulation
- Tenez à jour une correspondance entre pseudonymes et identifiants, les pseudonymes changent au fil du temps
- Ajoutez les joueurs par petits lots et vérifiez avec `whitelist list` après chaque série
- Prévenez votre communauté avant l'activation, un joueur refusé sans explication pense à un problème de serveur
- Conservez une copie de `serveradmin.xml` avant toute intervention manuelle, une erreur de syntaxe XML peut empêcher son chargement

## Besoin d'aide ?

Si un joueur correctement listé reste refusé, ou si vous avez perdu l'accès à votre propre serveur, ouvrez un ticket auprès de notre support depuis votre [espace client](https://billing.winheberg.com), département **Technique**, avec le serveur concerné dans le champ **Produit lié**. Notre équipe pourra intervenir sur le fichier avec vous.

Votre serveur n'accueille plus que les joueurs de votre choix. 🔒
