← Blog

Comment créer un serveur Minecraft survie pour ses amis ?

Par Benjamin D. · PDG

· Mis à jour le 12 août 2026 · Lecture 11 min

Illustration de l'article : Comment créer un serveur Minecraft survie pour ses amis ?
Sommaire

Créer un serveur Minecraft survie en 2026 demande un peu plus qu'un simple double-clic sur un fichier .jar : version, core, plugins anti-grief, réglages de distance de simulation, sauvegardes et protection contre les intrusions. Ce tutoriel couvre l'ensemble du processus, du choix de l'hébergement jusqu'à l'optimisation fine du fichier server.properties et des configurations Paper.



Préparer son projet de serveur Minecraft survie

Avant de lancer quoi que ce soit, il faut cadrer trois choses : le nombre de joueurs visé, la version de jeu, et le type de core serveur. Ces trois décisions conditionnent la RAM nécessaire, les plugins disponibles et la stabilité du monde sur le long terme.

Vanilla, Paper, Fabric ou Forge ?

Un serveur survie « classique » se construit presque toujours sur Paper. C'est un fork de Spigot qui apporte des optimisations lourdes sur le tick des entités, le chargement des chunks et la redstone, tout en gardant la compatibilité avec l'écosystème de plugins Bukkit/Spigot.

Core Extensions Performance Usage typique
Vanilla Aucune (datapacks uniquement) Moyenne Survie entre amis, 2 à 8 joueurs
Paper Plugins Bukkit/Spigot/Paper Élevée Survie publique, 10 à 200 joueurs
Fabric Mods Fabric Élevée (avec Lithium/Ferrite) Survie moddée légère
Forge / NeoForge Modpacks lourds Variable, gourmande Survie moddée type Create, ATM

Pour une survie vanilla+ (avec économie, protections de terrain, home et warps), Paper reste le choix le plus pragmatique. Pour une survie moddée, orientez-vous vers Fabric si le modpack le permet : la consommation CPU par tick y est généralement plus contenue que sur Forge.

Dimensionner la RAM et le CPU

Minecraft est un jeu monothread sur le tick principal. Autrement dit, ce n'est pas le nombre de cœurs qui compte le plus, mais la fréquence et l'IPC du processeur. Un Ryzen 9 avec de la DDR5 ECC et du stockage NVMe fait une différence directement mesurable sur les MSPT (millisecondes par tick), surtout quand les joueurs construisent des fermes à entités.

  • 2 à 10 joueurs, vanilla/Paper : 4 Go de RAM suffisent largement.
  • 10 à 40 joueurs, Paper + 15 plugins : 6 à 8 Go.
  • 40 à 100 joueurs, monde étendu : 10 à 16 Go.
  • Survie moddée (Forge, 150+ mods) : 8 à 12 Go minimum, même à 10 joueurs.

Attention au piège classique : allouer 16 Go à un serveur qui n'en a pas besoin allonge les pauses du garbage collector au lieu de les réduire. Mieux vaut une allocation juste et des flags JVM correctement réglés.

Hébergement managé ou VPS ?

Deux approches valables selon votre niveau d'administration système :

  • Offre managée : le Serveur Minecraft chez Nexus Games est installé instantanément, l'anti-DDoS est actif par défaut, les sauvegardes automatiques tournent en arrière-plan et le NexusPanel gère la console live, les fichiers et l'installation des plugins. C'est la voie la plus rapide pour un serveur survie.
  • VPS : un VPS Linux vous donne la main complète (plusieurs instances, proxy Velocity, base de données, site web). Un VPS Pterodactyl ajoute une couche de gestion multi-serveurs si vous prévoyez un réseau lobby + survie + créatif.


Installer et configurer son serveur Minecraft survie

Installation via panel (voie rapide)

Sur un hébergement managé, la séquence est courte : choix du jeu, choix du core (Paper), choix de la version, démarrage. Le panel télécharge le .jar, génère les fichiers et accepte l'EULA. Vous arrivez directement sur la console live où le premier démarrage génère le monde.

Le premier lancement affiche typiquement :

[Server thread/INFO]: Starting minecraft server version 1.21.4
[Server thread/INFO]: Preparing level "world"
[Server thread/INFO]: Preparing spawn area: 0%
[Server thread/INFO]: Done (18.442s)! For help, type "help"

Installation manuelle sur VPS Linux

Si vous partez sur un VPS, voici une base propre sous Debian/Ubuntu. On crée un utilisateur dédié — jamais de serveur de jeu sous root.

apt update && apt upgrade -y
apt install -y openjdk-21-jre-headless screen wget ufw fail2ban

adduser --disabled-password --gecos "" mcserver
su - mcserver
mkdir -p ~/survie && cd ~/survie

wget -O server.jar https://api.papermc.io/v2/projects/paper/versions/1.21.4/builds/200/downloads/paper-1.21.4-200.jar
echo "eula=true" > eula.txt
java -Xms6G -Xmx6G -jar server.jar nogui

Pour éviter de dépendre d'une session screen, créez un service systemd (à exécuter en root) :

cat > /etc/systemd/system/minecraft-survie.service <<'EOF'
[Unit]
Description=Serveur Minecraft Survie
After=network.target

[Service]
User=mcserver
WorkingDirectory=/home/mcserver/survie
ExecStart=/usr/bin/java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC \
  -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -jar server.jar nogui
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now minecraft-survie
systemctl status minecraft-survie

Ces flags G1GC (dits « flags Aikar ») réduisent nettement les micro-freezes liés au garbage collector sur un serveur survie chargé.

Le fichier server.properties, ligne par ligne

C'est ici que se joue l'identité de votre serveur Minecraft survie. Les paramètres à traiter en priorité :

gamemode=survival
difficulty=hard
hardcore=false
pvp=true
max-players=40
view-distance=8
simulation-distance=6
spawn-protection=16
allow-nether=true
enable-command-block=false
white-list=false
enforce-whitelist=false
online-mode=true
enable-rcon=true
rcon.port=25575
rcon.password=REMPLACER_PAR_UN_MOT_DE_PASSE_LONG
motd=\u00A76Survie \u00A7f| \u00A7aSaison 3 \u00A7f| \u00A77Economie & Claims
max-world-size=15000
network-compression-threshold=256

Quelques points de vigilance issus du terrain :

  • view-distance : c'est le paramètre le plus coûteux. Passer de 12 à 8 divise presque par deux le nombre de chunks chargés par joueur. Sur un serveur de 40 joueurs, l'impact sur les MSPT est énorme.
  • simulation-distance : gardez-le inférieur ou égal à la view-distance. À 6, les fermes fonctionnent normalement tout en limitant la charge sur les entités.
  • online-mode=true : à conserver absolument. Le mode offline ouvre la porte à l'usurpation de pseudo et donc au vol de rang admin.
  • max-world-size : bornez le monde dès le départ. Un monde de 15 000 blocs de rayon reste immense et évite les téraoctets de région files après six mois.
  • enable-command-block=false sur une survie publique, sauf si vous maîtrisez les permissions.

Optimisations Paper spécifiques à la survie

Dans config/paper-world-defaults.yml, quelques réglages font gagner beaucoup de TPS sans dénaturer le gameplay :

chunks:
  max-auto-save-chunks-per-tick: 8
  delay-chunk-unloads-by: 10s
collisions:
  max-entity-collisions: 2
entities:
  spawning:
    per-player-mob-spawns: true
    despawn-ranges:
      monster:
        hard: 96
        soft: 32
  behavior:
    disable-chest-cat-detection: true
hopper:
  disable-move-event: true
misc:
  redstone-implementation: ALTERNATE_CURRENT

Le passage à ALTERNATE_CURRENT pour la redstone est particulièrement efficace sur une survie où les joueurs construisent des fermes automatisées. disable-move-event sur les hoppers allège fortement les bases avec des dizaines d'entonnoirs.



Plugins essentiels, gestion et sécurité au quotidien

La stack plugins d'une survie qui tient dans la durée

Inutile d'empiler 60 plugins. Une survie stable repose sur une base restreinte et bien configurée :

Besoin Plugin Pourquoi
Commandes de base EssentialsX /home, /tpa, /warp, kits, économie intégrée
Permissions LuckPerms Groupes, héritage, édition web
Anti-grief GriefPrevention ou Lands Claims automatiques à la pelle en or
Rollback CoreProtect Inspection des blocs, restauration ciblée
Pré-génération Chunky Génère le monde à l'avance, évite les lags d'exploration
Diagnostic Spark Profiling CPU, identification des sources de lag

La pré-génération avec Chunky est un réflexe que beaucoup d'admins découvrent trop tard. Générer le monde à l'avance décharge le CPU pendant les sessions de jeu :

chunky world world
chunky center 0 0
chunky radius 8000
chunky start

Lancez cette opération serveur vide, la nuit, et surveillez l'espace disque : 8 000 blocs de rayon représentent plusieurs Go de fichiers de région sur NVMe.

Diagnostiquer un serveur qui lag

Le TPS seul ne dit pas grand-chose. Le bon indicateur, c'est le MSPT : le temps réel passé à calculer un tick. En dessous de 50 ms, tout va bien. Au-delà, le serveur commence à sauter des ticks.

/spark tps
/spark profiler start --timeout 120
/spark profiler stop

Le rapport généré pointe précisément le coupable : une ferme à fer surdimensionnée, un plugin qui scanne les chunks à chaque tick, ou un joueur qui fait tourner une machine à mobs de 10 000 entités. Complétez avec :

/paper entity list
/paper mobcaps

Sécurité : les réflexes à ne pas négliger

L'anti-DDoS volumétrique est déjà géré côté infrastructure chez Nexus Games, donc concentrez vos efforts sur ce qui dépend de vous :

  • Mot de passe RCON : long, aléatoire, jamais celui du panel. Le RCON envoie les commandes en clair, ne l'exposez pas publiquement.
  • Whitelist pendant la phase de construction ou pour une survie privée : /whitelist on puis /whitelist add Pseudo.
  • Permissions strictes : aucun joueur ne doit avoir * dans LuckPerms. Créez un groupe modérateur avec uniquement les nœuds nécessaires.
  • Mises à jour : suivez les builds Paper, notamment après une faille de sécurité sur une bibliothèque tierce.
  • Plugins de sources fiables uniquement : un jar téléchargé sur un forum obscur est un backdoor potentiel avec accès total à votre système de fichiers.

Sur un VPS, ajoutez la couche système classique :

ssh-keygen -t ed25519 -C "admin-mc"
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@IP_DU_VPS

# Désactiver l'authentification par mot de passe
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 25565/tcp
ufw enable

systemctl enable --now fail2ban
fail2ban-client status sshd

Sauvegardes : la seule vraie assurance

Un grief massif, une corruption de région ou une mauvaise commande WorldEdit peuvent effacer des mois de construction. Les sauvegardes automatiques du panel couvrent le gros du risque, mais gardez une copie hors serveur avant chaque opération sensible (changement de version, ajout d'un plugin majeur, migration de monde).

# Sauvegarde manuelle sur VPS avant une mise à jour
cd /home/mcserver
tar -czf backup-survie-$(date +%F-%H%M).tar.gz survie/world survie/world_nether survie/world_the_end survie/plugins
ls -lh backup-survie-*.tar.gz

Pensez aussi à exécuter save-all flush puis save-off avant une copie à chaud, et save-on ensuite, pour éviter d'archiver des fichiers de région en cours d'écriture.



Lancer la communauté et faire durer la saison

Version, compatibilité et Bedrock

Vérifiez toujours la version exacte que vous annoncez. La liste officielle des versions et des notes de patch est disponible sur le site officiel de Minecraft. Si vous voulez accueillir les joueurs Bedrock (mobile, console), ajoutez Geyser et Floodgate côté serveur : les joueurs Bedrock rejoignent alors votre survie Java sans proxy externe.

Nom de domaine et adresse propre

Une adresse du type play.monserveur.fr est plus mémorisable qu'une IP. Configurez un enregistrement A vers l'IP du serveur, et un enregistrement SRV si le port n'est pas 25565 :

_minecraft._tcp.play    SRV    0 5 25580 mc.monserveur.fr.
mc                      A      203.0.113.42

Structurer la saison

Une survie qui survit six mois repose sur des règles claires dès le jour un : rayon de claim, taille maximale des fermes à entités, politique sur les duplications de blocs, gestion du nether-hub. Annoncez-les avant l'ouverture, pas après le premier conflit.

  • Fixez la bordure du monde dès le début avec /worldborder set 15000.
  • Prévoyez un spawn protégé en adventure ou avec claim administratif.
  • Mettez en place un bot Discord pour les annonces, le statut du serveur et les tickets de support — l'hébergement de bot Discord tourne en continu sans mobiliser votre PC.
  • Gardez un serveur de test séparé pour valider les mises à jour de plugins avant production.

Si votre communauté grandit et que vous voulez ajouter d'autres univers de jeu, l'ensemble des offres est regroupé sur tous nos serveurs de jeux, et d'autres guides d'administration sont publiés régulièrement sur le Blog Nexus Games.

Enfin, gardez une routine de maintenance simple : vérifier les MSPT une fois par semaine avec Spark, purger les anciennes sauvegardes, contrôler l'espace disque, et lire les changelogs Paper avant chaque montée de build.

Un serveur survie bien réglé ne se distingue pas par le nombre de plugins installés, mais par la constance de ses 20 TPS un vendredi soir à 40 joueurs connectés.



Conclusion

Monter un serveur Minecraft survie tient à trois piliers : un core adapté (Paper dans la majorité des cas), des réglages de distance et de spawn cohérents avec votre CPU, et une discipline de sauvegarde. Le reste — plugins, claims, économie — se construit progressivement. Commencez petit, mesurez vos MSPT, et n'ajoutez une fonctionnalité que lorsqu'elle est réellement demandée par vos joueurs.



FAQ

Combien de RAM faut-il pour un serveur Minecraft survie de 20 joueurs ?

Sur Paper avec une quinzaine de plugins, 6 Go suffisent confortablement pour 20 joueurs, avec une view-distance à 8 et une simulation-distance à 6. Au-delà de 8 Go sans besoin réel, les pauses du garbage collector s'allongent. Si votre survie est moddée (Forge, 150+ mods), comptez plutôt 8 à 12 Go dès 10 joueurs.

Comment corriger un serveur survie qui lag alors que le CPU semble libre ?

Le lag Minecraft vient presque toujours du tick principal, monothread. Lancez /spark profiler start pendant 2 minutes puis analysez le rapport : fermes à entités, hoppers en cascade ou plugin mal codé ressortent immédiatement. Réduisez ensuite la simulation-distance, activez per-player-mob-spawns et passez la redstone en ALTERNATE_CURRENT.

Peut-on changer de version Minecraft sans perdre le monde de la survie ?

Oui, dans la plupart des cas : Minecraft convertit automatiquement les fichiers de région au premier démarrage sur la nouvelle version. Faites impérativement une sauvegarde complète du dossier world avant, vérifiez la compatibilité de chaque plugin avec la nouvelle version, et testez la migration sur une copie du monde avant de l'appliquer en production. La rétrogradation, elle, n'est pas supportée.