Comment créer un serveur Minecraft survie pour ses amis ?
Par Benjamin D. · PDG
· Mis à jour le 12 août 2026 · Lecture 11 min

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 onpuis/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
adventureou 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.
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.