Comment créer un serveur Minecraft PvP compétitif et équilibré ?

Créer un serveur Minecraft PvP en 2026 ne se résume plus à lancer un server.jar et à ouvrir un port : il faut choisir un core adapté, régler le combat, verrouiller l'anti-cheat et garantir un tick rate stable même à 80 joueurs en zone de combat. Ce tutoriel décrit la démarche complète, de l'installation au réglage fin des plugins, sans jargon inutile.

Choisir la base technique de son serveur Minecraft PvP

Avant d'installer quoi que ce soit, trois décisions conditionnent tout le reste : la version du jeu, le core serveur et le type d'hébergement. Se tromper ici, c'est refaire la configuration trois semaines plus tard avec une base de données de kits déjà remplie.

Version et système de combat

Le PvP Minecraft se divise historiquement en deux écoles. Le combat 1.8 (spam clic, knockback rapide, pas de cooldown d'attaque) reste la référence des serveurs compétitifs type PotPvP, HCF ou practice. Le combat moderne (1.9+ jusqu'aux versions récentes) introduit le cooldown d'attaque, les boucliers, les enchantements de mêlée revus et un gameplay plus lent, orienté timing.

Critère	PvP 1.8	PvP moderne (1.9+)
Rythme	Rapide, clic soutenu	Timing, cooldown 0,6 à 1,6 s
Public	Practice, HCF, KitMap	Survie PvP, factions récentes, box PvP
Plugins disponibles	Écosystème très large	Écosystème à jour, moins de legacy
Compatibilité clients	Nécessite ViaVersion pour les clients récents	Nécessite ViaBackwards pour les anciens

En pratique, beaucoup d'administrateurs lancent le serveur sur une version récente (1.21.x) et rétablissent la mécanique 1.8 via un plugin d'old combat, tout en acceptant les clients de 1.8 à la dernière version grâce à ViaVersion et ViaRewind. C'est le meilleur compromis entre audience et maintenance.

Quel core serveur ?

• Paper : la base saine. Optimisations importantes par rapport à Vanilla et Spigot, configuration granulaire, compatibilité plugins Bukkit/Spigot.
• Purpur : fork de Paper avec des options de gameplay supplémentaires (knockback configurable, réglages de mobs). Pratique pour ajuster le ressenti PvP sans plugin.
• Folia : parallélisation par régions, intéressant pour de très gros mondes ouverts, mais compatibilité plugins encore limitée — à réserver aux équipes qui développent leurs propres plugins.
• Velocity : proxy indispensable dès que vous multipliez les instances (lobby, arène practice, HCF, minigames).

Pour un premier serveur Minecraft PvP, Paper ou Purpur en instance unique suffit largement. Le passage à une architecture proxy + backends se fait plus tard, quand la fréquentation le justifie.

Hébergement mutualisé, serveur dédié au jeu ou VPS ?

Minecraft reste très dépendant de la performance mono-thread : le tick principal (20 TPS, soit 50 ms par tick) s'exécute sur un cœur. Un CPU récent à haute fréquence, type Ryzen 9, change concrètement le comportement d'une arène à 60 joueurs. La RAM DDR5 ECC limite les erreurs mémoire sur les longues sessions, et le stockage NVMe accélère le chargement de chunks lors des téléportations d'arène.

Solution	Pour qui	Points d'attention
Offre Serveur Minecraft managée	Communautés qui veulent jouer, pas administrer Linux	Installation instantanée, panel, sauvegardes automatiques
VPS Pterodactyl	Réseau multi-instances (lobby + arènes)	Vous gérez le panel, les eggs et les allocations
VPS Linux nu	Admins autonomes, stack sur mesure	Sécurisation, mises à jour et supervision à votre charge

Côté dimensionnement, une base réaliste pour du PvP :

• 20 à 40 joueurs, arènes fermées : 4 à 6 Go de RAM alloués à la JVM.
• 50 à 100 joueurs, factions ou HCF avec monde ouvert : 8 à 12 Go, world border serrée.
• Réseau multi-serveurs : compter la RAM par instance, plus 512 Mo à 1 Go pour le proxy Velocity.

La latence compte autant que la puissance brute. Un ping de 15 ms contre 60 ms change le ressenti du knockback et des combos. Héberger en France pour un public francophone reste le choix logique, et l'anti-DDoS inclus évite qu'une attaque volumétrique pendant un event ne coupe la partie — un classique sur les serveurs PvP compétitifs.

Installation pas à pas d'un serveur Minecraft PvP

1. Créer l'instance et poser le core

Sur une offre managée, l'installation est instantanée : vous choisissez le jeu, la version et le core dans le panel, puis l'instance démarre. Dans NexusPanel, la console live permet de suivre le premier lancement, la génération du monde et les éventuelles erreurs de plugin en temps réel.

Sur un VPS que vous administrez vous-même, la séquence classique reste :

sudo apt update && sudo apt upgrade -y
sudo apt install -y openjdk-21-jre-headless screen wget
sudo adduser --disabled-password --gecos "" minecraft
sudo -u minecraft mkdir -p /home/minecraft/pvp
cd /home/minecraft/pvp
wget -O server.jar https://api.papermc.io/v2/projects/paper/versions/1.21.4/builds/XXX/downloads/paper-1.21.4-XXX.jar
echo "eula=true" > eula.txt

2. Lancer la JVM avec des flags corrects

Les flags par défaut suffisent rarement. Les Aikar's flags restent la référence pour limiter les pauses GC, qui se traduisent en lag spikes très visibles en combat :

java -Xms8G -Xmx8G \
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
  -jar server.jar nogui

Règle simple : -Xms et -Xmx identiques, et jamais toute la RAM de la machine — laissez de la marge au système et aux entrées/sorties. Dans un panel de gestion, ces flags sont généralement paramétrables dans la variable de démarrage de l'instance.

3. Régler server.properties

Le fichier server.properties pose les fondations du gameplay :

gamemode=survival
difficulty=hard
pvp=true
hardcore=false
max-players=100
view-distance=6
simulation-distance=4
spawn-protection=0
allow-flight=true
enable-command-block=false
online-mode=true
enforce-secure-profile=false
network-compression-threshold=256
sync-chunk-writes=false

Quelques précisions terrain :

• view-distance=6 et simulation-distance=4 : sur un serveur PvP, personne n'a besoin de voir à 12 chunks. Vous récupérez énormément de CPU.
• allow-flight=true : obligatoire si vous utilisez des plugins de lobby, de double saut ou d'arène, sinon le serveur kick les joueurs à tort. L'anti-cheat prend le relais sur la détection de fly illégitime.
• spawn-protection=0 : sinon vos joueurs ne peuvent pas casser de blocs autour du spawn, y compris dans une arène mal placée.
• online-mode=true : gardez l'authentification Mojang. Derrière un proxy Velocity, on passe en false côté backend, mais avec la modern forwarding activée et le port backend fermé à l'extérieur.

4. Affiner Paper et Spigot

Dans config/paper-world-defaults.yml, les réglages qui pèsent le plus sur un serveur PvP :

chunks:
  max-auto-save-chunks-per-tick: 8
collisions:
  fix-climbing-bypassing-cramming-rule: true
entities:
  spawning:
    despawn-ranges:
      monster:
        hard: 96
        soft: 32
misc:
  redstone-implementation: ALTERNATE_CURRENT

Et dans spigot.yml, le paramètre le plus décisif : le merge radius des items et la limitation d'entités par chunk. Sur une KitMap, des centaines d'items au sol après un teamfight peuvent faire chuter les TPS plus vite que les joueurs eux-mêmes.

world-settings:
  default:
    item-despawn-rate: 1200
    merge-radius:
      item: 3.5
      exp: 4.0
    entity-tracking-range:
      players: 48
      monsters: 32
      misc: 24

La documentation officielle du jeu et les notes de version restent la source à consulter avant chaque montée de version : Source.

Plugins, gameplay et équilibrage du PvP

La pile de plugins de base

Un serveur Minecraft PvP fonctionnel repose sur une dizaine de plugins, pas cinquante. Chaque plugin supplémentaire, c'est du tick consommé et une surface de bug en plus.

Rôle	Type de plugin	Pourquoi c'est indispensable
Permissions	LuckPerms	Grades, préfixes, permissions par groupe, contexte par monde
Protection de zones	WorldGuard + WorldEdit	Spawn safe, flags pvp deny, zones d'arène
Anti-cheat	Anti-cheat serveur-side réputé	Reach, killaura, fly, autoclicker
Essentiels	EssentialsX ou équivalent	Warps, homes, kits, /msg, économie de base
Compatibilité versions	ViaVersion / ViaBackwards / ViaRewind	Accepter clients 1.8 à dernière version
Interface	Scoreboard / TAB	Kills, deaths, KDR, ping visibles en jeu
Mode de jeu	Practice, HCF, KitPvP ou minigames	Le cœur de l'expérience

L'installation se fait par glisser-déposer dans le dossier plugins/ via le gestionnaire de fichiers du panel, ou par SFTP. Un redémarrage propre via la console (stop, jamais un kill brutal) évite les corruptions de configuration.

Régler les zones avec WorldGuard

Le schéma classique : spawn sans PvP, arènes avec PvP, reste du monde selon le mode de jeu.

/rg define spawn
/rg flag spawn pvp deny
/rg flag spawn build deny
/rg flag spawn invincible allow
/rg flag spawn entry-deny-message &cZone protégée
/rg define arene1
/rg flag arene1 pvp allow
/rg flag arene1 build deny
/rg flag arene1 item-drop deny

Le flag item-drop deny en arène évite les tapis d'items au sol et le farm de stuff hors combat. Petit détail, gros impact sur la stabilité.

Équilibrer le ressenti du combat

Un PvP « qui se sent bien » tient à quelques variables :

• Knockback : sur Purpur ou via un plugin de knockback, on ajuste horizontal, vertical, friction et hauteur maximale. Un knockback trop vertical rend les combos impossibles, trop horizontal fait fuir tout le monde.
• Enchantements : plafonner Protection IV, interdire les combinaisons Thorns III + Prot IV sur les serveurs kit, sinon les combats durent trois minutes.
• Potions : sur du HCF ou du practice, la gestion des potions instantanées et de la régénération naturelle (naturalRegeneration) définit le rythme.
• Cooldown de téléportation : bloquer /home, /spawn et /tpa pendant un combat via un tag de combat (combat log de 10 à 20 secondes) est non négociable.

/gamerule naturalRegeneration false
/gamerule doImmediateRespawn true
/gamerule announceAdvancements false
/gamerule keepInventory false

Anti-cheat : configuration et faux positifs

Un anti-cheat mal réglé sanctionne les joueurs à 120 ms de ping et laisse passer les clients modernes. Trois principes :

1. Démarrer en mode log only pendant une à deux semaines, analyser les alertes, puis activer les sanctions module par module.
2. Exclure le staff en vanish et les zones de lobby des vérifications de mouvement.
3. Croiser avec un plugin de replay ou de logs de combat : une alerte seule ne vaut pas une preuve, surtout sur un serveur compétitif où les bans injustifiés font fuir la communauté.

Performance, sécurité et exploitation au quotidien

Surveiller les TPS et le MSPT

Le TPS seul ment. Un serveur à 20 TPS avec un MSPT (millisecondes par tick) de 45 est au bord de la rupture : au moindre teamfight, il décroche. Surveillez le MSPT et visez moins de 30 ms en charge normale.

/tps
/mspt
/timings on        # puis /timings paste après 10 min de charge
/spark profiler start --timeout 300

Les coupables les plus fréquents sur un serveur PvP : génération de chunks (téléportations aléatoires), entités accumulées, plugins qui bouclent sur des tâches synchrones, et sauvegardes de monde mal planifiées. Sur du stockage NVMe, l'auto-save pèse nettement moins qu'un disque classique, mais planifiez tout de même les sauvegardes lourdes hors des heures de pointe.

Réduire la charge en teamfight

• Pré-générer le monde avec un plugin de pregen et poser une worldborder ferme : plus de génération à la volée pendant les events.
• Limiter les entités par chunk et purger automatiquement les items au sol toutes les 5 minutes avec un avertissement.
• Désactiver les mécaniques inutiles au PvP : propagation du feu, explosions destructrices hors zones dédiées, redstone complexe dans les zones publiques.
• Sur un réseau, isoler les modes de jeu sur des instances séparées derrière un proxy plutôt que de tout empiler sur un seul serveur.

/worldborder set 4000
/worldborder warning distance 20
/gamerule doFireTick false
/gamerule mobGriefing false

Sauvegardes et procédure de restauration

Sur un serveur PvP, une corruption de monde ou une base de données de kits perdue, c'est une communauté qui part. Les sauvegardes automatiques couvrent le gros du risque, mais gardez une copie manuelle avant chaque changement majeur : montée de version, ajout d'un plugin d'économie, reset de map.

Testez la restauration au moins une fois : une sauvegarde jamais restaurée n'est pas une sauvegarde. La procédure type : arrêt propre du serveur, restauration depuis le panel, vérification des fichiers de configuration des plugins, redémarrage, contrôle console.

Sécuriser l'accès administrateur

Côté serveur de jeu :

• Mot de passe RCON long et unique, jamais le même que le panel. Si vous n'utilisez pas RCON, désactivez-le : enable-rcon=false.
• Sous-utilisateurs du panel avec des droits limités : un modérateur n'a pas besoin d'accéder au gestionnaire de fichiers ni aux sauvegardes.
• Whitelist activée pendant les phases de build et de test : /whitelist on.
• Op restreint à deux ou trois personnes maximum, le reste des permissions passe par LuckPerms.
• Désactiver les command blocks en production si aucun système ne les utilise.

Côté VPS Linux auto-géré, la base à ne pas négliger :

ssh-keygen -t ed25519 -C "admin-mc"
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@IP_DU_VPS
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

sudo apt install -y ufw fail2ban
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 25565/tcp
sudo ufw enable
sudo systemctl enable --now fail2ban

La protection contre les attaques volumétriques est gérée en amont par l'infrastructure d'hébergement, avec l'anti-DDoS inclus par défaut. Votre travail porte donc sur les accès applicatifs : SSH, panel, base de données, et le port du serveur qui ne doit jamais exposer un backend en online-mode=false.

Automatiser le démarrage sur VPS

sudo tee /etc/systemd/system/minecraft-pvp.service > /dev/null <<'EOF'
[Unit]
Description=Serveur Minecraft PvP
After=network.target

[Service]
User=minecraft
WorkingDirectory=/home/minecraft/pvp
ExecStart=/usr/bin/java -Xms8G -Xmx8G -jar server.jar nogui
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now minecraft-pvp
sudo journalctl -u minecraft-pvp -f

Si vous prévoyez plusieurs instances (lobby, practice, HCF), un panel comme Pterodactyl simplifie fortement la gestion des allocations de ports, des limites de RAM et des redémarrages planifiés. C'est l'usage typique d'un VPS Pterodactyl. D'autres jeux compétitifs suivent la même logique d'exploitation, comme un Serveur Rust ou un serveur de jeux en général : dimensionnement CPU, sauvegardes, supervision.

Checklist avant ouverture publique

1. TPS stable à 20 et MSPT sous 30 ms avec 20 joueurs de test.
2. Anti-cheat en mode sanction, avec staff exclu et logs conservés.
3. Zones WorldGuard vérifiées : impossible de PvP au spawn, impossible de casser un bloc en arène.
4. Combat tag actif, téléportations bloquées en combat.
5. Sauvegarde manuelle effectuée et restauration testée.
6. Grades LuckPerms créés, permissions du staff limitées au strict nécessaire.
7. Message du jour, règles et procédure de signalement en place.
8. ViaVersion testé avec un client 1.8 et un client dernière version.

Pour aller plus loin sur les autres jeux et les guides d'administration, le Blog Nexus Games regroupe les tutoriels de configuration, et Nexus Games propose l'installation instantanée des instances Minecraft avec panel, console live et sauvegardes.

Conclusion

Monter un serveur PvP solide tient à trois choses : un core bien réglé, une pile de plugins minimale mais maîtrisée, et une surveillance régulière du MSPT. Le reste — knockback, kits, arènes — s'affine avec les retours des joueurs. Gardez toujours une sauvegarde testée avant chaque modification importante, et documentez vos réglages pour les reproduire.

FAQ

Combien de RAM faut-il pour un serveur Minecraft PvP de 100 joueurs ?

Comptez 8 à 12 Go alloués à la JVM pour 100 joueurs sur une map fermée avec world border, en gardant de la marge système. Au-delà de 12 Go, augmenter la RAM n'aide plus : le facteur limitant devient la performance mono-thread du CPU. Réduisez plutôt view-distance à 6, simulation-distance à 4, et limitez les entités par chunk.

Comment garder la mécanique de combat 1.8 sur une version récente ?

Installez ViaVersion, ViaBackwards et ViaRewind pour accepter tous les clients, puis un plugin d'old combat qui supprime le cooldown d'attaque et restaure le knockback historique. Sur Purpur, plusieurs paramètres de knockback sont directement configurables dans purpur.yml. Testez systématiquement avec un client 1.8 et un client récent avant l'ouverture publique.

Mon serveur lag uniquement pendant les gros combats, que vérifier en priorité ?

Lancez un profiling avec spark pendant le pic de charge et regardez le MSPT, pas le TPS. Les causes fréquentes : items au sol non fusionnés (réglez merge-radius dans spigot.yml), entity-tracking-range trop élevé, génération de chunks à la volée faute de pré-génération, et sauvegardes automatiques planifiées en pleine heure de pointe.