Baie de serveurs, infrastructure réseau

Créer un serveur Minecraft : tutoriel complet 2026

by

J’ai monté mon premier serveur Minecraft en 2019, pour le fils d’un client dont j’infogérais par ailleurs trois serveurs de production. Ce qui devait être un service de dépannage d’une heure s’est transformé en audit complet : le « serveur » tournait sur une Freebox avec un port forwardé à la va-vite, zéro sauvegarde, et un mot de passe RCON laissé à la valeur par défaut. Le monde du gamin a été supprimé par un intrus trois semaines plus tard. Depuis, j’ai remonté une bonne dizaine de serveurs Minecraft pour des clients ou pour moi-même, et j’applique systématiquement les mêmes réflexes que sur mes serveurs de prod : dimensionnement réaliste, exposition réseau maîtrisée, sauvegardes automatiques testées. Ce guide reprend cette méthode, avec les chiffres et les pièges que j’ai rencontrés sur le terrain.

Pourquoi l’approche « infrastructure » change tout

La plupart des tutoriels Minecraft traitent le serveur comme une simple appli à lancer. C’est une erreur qui coûte cher plus tard. Un serveur Minecraft, c’est un processus Java qui consomme de la RAM de façon prévisible, qui écrit sur disque en continu (le monde grandit littéralement à chaque exploration), et qui expose un port ouvert sur Internet 24h/24. Autrement dit : c’est un serveur de production miniature, avec les mêmes risques qu’un serveur web mal configuré — sauf que personne ne le traite comme tel.

Sur mes missions chez des PME, je vois régulièrement la même erreur inversée : des serveurs applicatifs professionnels dimensionnés à la louche, « on verra si ça tient ». Pour Minecraft c’est pareil, sauf qu’ici les conséquences d’un sous-dimensionnement sont immédiates et visibles : lag, « TPS » (ticks par seconde, la fréquence à laquelle le serveur met à jour le monde) qui s’effondre, joueurs qui décrochent. C’est en réalité un excellent terrain d’entraînement pour comprendre le dimensionnement serveur sans les enjeux d’un vrai client en production.

Le cas client : contexte et diagnostic

Prenons le cas type sur lequel je vais dérouler ce tutoriel : une association de quartier qui voulait un serveur Minecraft privé pour une dizaine d’enfants dans le cadre d’un atelier informatique périscolaire, accessible depuis chez eux en dehors des heures d’atelier. Cahier des charges réel : 8 à 12 joueurs simultanés maximum, des mods légers (pas de modpack lourd type « All the Mods »), un besoin de sauvegardes fiables parce que les enfants construisent depuis des mois, et un budget serré — pas question de payer 40€/mois pour ça.

Premier réflexe, comme pour n’importe quelle mission d’infogérance : je n’ai pas commencé par choisir un hébergeur. J’ai d’abord posé trois questions au client, celles que je pose systématiquement avant de dimensionner quoi que ce soit :

  • Combien de joueurs simultanés réellement (pas « potentiellement un jour »)
  • Quels mods ou plugins, et à quel point ils sont gourmands en calcul
  • Quelle tolérance à la coupure — un serveur Minecraft associatif n’a pas besoin d’un SLA 99,99%

Cette étape de cadrage prend 15 minutes et évite de sur-payer un serveur 4 vCPU / 8 Go pour 8 joueurs vanilla, ou à l’inverse de sous-dimensionner et de devoir migrer en urgence trois semaines plus tard — ce qui, sur un monde Minecraft de plusieurs Go, n’est jamais une opération anodine.

Dimensionnement du VPS : les chiffres qui comptent

Voici les repères que j’utilise réellement, basés sur des mesures faites avec l’outil htop et le plugin Spark (profiler de performance intégrable au serveur) sur mes déploiements :

  • 1 à 5 joueurs, vanilla ou peu de plugins : 2 vCPU, 4 Go de RAM suffisent. J’alloue 2,5 Go à Java, le reste au système.
  • 6 à 15 joueurs, quelques plugins (Essentials, WorldGuard) : 2 à 4 vCPU, 6 à 8 Go de RAM. C’est le cas de mon association : j’ai retenu 4 vCPU / 8 Go.
  • 15 joueurs et plus, ou modpack lourd : 4 vCPU minimum dédiés (pas mutualisés), 12 à 16 Go de RAM, et là il faut sérieusement envisager un stockage NVMe plutôt que SSD classique.

Le point que les tutoriels génériques ratent systématiquement : Minecraft (en version serveur Java, la Paper/Spigot que j’utilise pour ses gains de performance par rapport au serveur vanilla officiel) est mono-thread pour l’essentiel de la logique de jeu. Ajouter des vCPU au-delà de 4 n’accélère quasiment rien sur les TPS — ça aide seulement si vous avez beaucoup de plugins qui parallélisent des tâches annexes. J’ai vu un client payer pour un VPS 8 vCPU en pensant que ça réglait un problème de lag, alors que le vrai goulot d’étranglement était le disque. Vérifiez toujours le type de stockage avant le nombre de cœurs : le monde Minecraft fait beaucoup d’I/O disque (sauvegarde des chunks, régions), un SSD/NVMe change plus la donne qu’un vCPU de plus.

Pour l’association, j’ai retenu un VPS chez un hébergeur européen (OVH, Scaleway ou Hetzner selon la localisation des joueurs — privilégiez toujours un datacenter proche géographiquement de la majorité des joueurs pour réduire la latence) à 4 vCPU / 8 Go / 80 Go NVMe, facturé environ 15€/mois. C’est le sweet spot pour ce profil : largement suffisant, avec de la marge pour ajouter des plugins sans re-dimensionner.

Étape 1 : préparation du serveur (0 à 30 minutes)

Je pars toujours d’une image Ubuntu 22.04 LTS minimale. Premiers gestes, identiques à n’importe quel serveur que je monte pour un client professionnel :

  1. Mise à jour système : apt update && apt upgrade -y
  2. Création d’un utilisateur dédié non-root : adduser minecraft — ne jamais faire tourner le serveur en root, c’est une négligence que je vois encore trop souvent et qui transforme une faille applicative mineure en compromission totale du serveur
  3. Installation de Java 21 (requis pour les versions 1.20.5+ de Minecraft) : apt install openjdk-21-jre-headless -y
  4. Configuration du pare-feu avec UFW, en n’ouvrant QUE le strict nécessaire

Sur le pare-feu, exactement comme je le fais pour un serveur web client : j’ouvre le port 22 (SSH, idéalement restreint à mon IP fixe), le port 25565 (port par défaut de Minecraft, en TCP), et rien d’autre. Pas de port RCON exposé publiquement — j’y reviens plus bas, c’est le piège numéro un.

ufw allow 22/tcp
ufw allow 25565/tcp
ufw enable

Étape 2 : installation du serveur Minecraft (Paper)

J’utilise systématiquement Paper plutôt que le serveur vanilla officiel de Mojang. Sur mes tests comparatifs avec le même monde et les mêmes 10 joueurs connectés, Paper tenait un TPS stable à 19,8-20 (le maximum théorique est 20) là où le vanilla tombait à 14-16 dès qu’un joueur générait du nouveau terrain. Paper reste 100% compatible avec le jeu vanilla côté joueur — seuls les administrateurs voient la différence de performance et l’accès aux plugins.

  1. Connectez-vous en SSH avec l’utilisateur minecraft créé plus haut
  2. Créez un dossier dédié : mkdir ~/server && cd ~/server
  3. Téléchargez le jar Paper correspondant à la version cible depuis le site officiel de Paper (je recommande de rester sur une version stable sortie depuis au moins 3-4 semaines, jamais la toute dernière release le jour de sa sortie — j’ai eu deux cas de plugins cassés sur des releases trop fraîches)
  4. Premier lancement pour générer les fichiers : java -Xms2G -Xmx6G -jar paper.jar nogui
  5. Acceptez l’EULA dans le fichier généré eula.txt (passez la ligne à eula=true)

Sur les paramètres -Xms et -Xmx : c’est la mémoire minimale et maximale allouée à la JVM (la machine virtuelle Java). Une erreur fréquente est de mettre -Xms et -Xmx à la même valeur en pensant « optimiser » — en réalité sur un VPS partagé avec d’autres services (panel de gestion, bot Discord de modération, etc.), je préfère laisser une marge dynamique. Sur mon VPS 8 Go pour l’association, j’ai alloué -Xms4G -Xmx6G, laissant 2 Go au système et aux autres processus.

Étape 3 : le script de démarrage et la persistance

Un piège classique du tutoriel copier-coller : lancer le serveur dans une session SSH toute nue. Dès que vous fermez le terminal, le processus meurt (sauf usage de nohup ou screen, qui restent fragiles). J’utilise systématiquement systemd, exactement comme pour n’importe quel service backend que je déploie chez un client — ça permet un redémarrage automatique en cas de crash, un démarrage au boot du serveur, et des logs centralisés via journalctl.

Fichier /etc/systemd/system/minecraft.service :

[Unit]
Description=Serveur Minecraft Paper
After=network.target

[Service]
User=minecraft
WorkingDirectory=/home/minecraft/server
ExecStart=/usr/bin/java -Xms4G -Xmx6G -jar paper.jar nogui
Restart=on-failure
RestartSec=15

[Install]
WantedBy=multi-user.target

Puis systemctl enable --now minecraft. Résultat mesuré chez l’association : sur 6 mois d’exploitation, deux crashs liés à un plugin buggé, redémarrage automatique en moins de 20 secondes à chaque fois, sans intervention manuelle. C’est exactement le niveau de résilience qu’on attend d’un service même non-critique.

Sécurité : les trois pièges que j’ai vus casser des serveurs

C’est la partie que 90% des tutoriels grand public bâclent complètement, et c’est exactement là que j’apporte le plus de valeur par rapport à un guide générique.

Piège 1 : RCON exposé publiquement

RCON (Remote Console) permet d’administrer le serveur à distance via un mot de passe défini dans server.properties. Le cas que j’ai ouvert cette histoire avec : port RCON (25575) ouvert sur Internet, mot de passe laissé vide ou par défaut. C’est une porte d’entrée root déguisée — un attaquant avec accès RCON peut exécuter n’importe quelle commande serveur, y compris supprimer le monde ou installer un plugin malveillant qui donne un accès système plus large. Règle simple : enable-rcon=false sauf si vous en avez un usage précis (panel d’admin externe type Pterodactyl), et dans ce cas, RCON doit être bindé sur 127.0.0.1 uniquement, jamais exposé sur l’IP publique.

Piège 2 : whitelist désactivée sur un serveur « privé »

Un serveur Minecraft sur port par défaut se fait scanner en permanence par des bots qui recensent les serveurs ouverts (des sites comme des « trackers » de serveurs publics les indexent automatiquement en quelques heures, même sans annonce). Sans whitelist, n’importe qui peut rejoindre. Pour un serveur destiné à un groupe fermé, la whitelist est non négociable :

whitelist=true
white-list=true

Puis ajout des joueurs autorisés via /whitelist add pseudo en console. Pour l’association, ça a aussi évité un problème annexe auquel je n’avais pas pensé initialement : sans whitelist, le serveur recevait des tentatives de connexion de bots toutes les 4-5 minutes en moyenne, ce qui gonflait inutilement les logs et consommait un peu de bande passante pour rien.

Piège 3 : op donné trop largement

La commande /op pseudo donne les droits administrateur complets en jeu (destruction de blocs sans limite, mode créatif, commandes serveur). Je limite systématiquement le statut op à une seule personne responsable côté client — pour l’association, l’animatrice de l’atelier — et j’installe un plugin de permissions (LuckPerms) pour donner des droits granulaires aux autres sans passer par op complet. C’est le même principe que la gestion des accès admin sur un CMS client : le compte « super-admin » doit rester l’exception, pas la norme.

Sauvegardes : ce qui a vraiment évité une catastrophe

C’est le point sur lequel j’insiste le plus avec mes clients, quel que soit le type de serveur. Une sauvegarde qui n’a jamais été testée en restauration n’est pas une sauvegarde, c’est un espoir. J’ai mis en place un script cron simple, exécuté chaque nuit à 4h (heure creuse, quand personne n’est connecté) :

#!/bin/bash
DATE=$(date +%Y%m%d-%H%M)
tar -czf /home/minecraft/backups/world-$DATE.tar.gz -C /home/minecraft/server world world_nether world_the_end
find /home/minecraft/backups -type f -mtime +14 -delete

Ce script conserve 14 jours de rétention en local, et je le complète toujours par une copie hors du serveur — via rsync vers un stockage objet (type S3 compatible chez l’hébergeur ou un NAS distant). La règle que j’applique partout, y compris en environnement professionnel : jamais de sauvegarde qui reste uniquement sur la même machine que la donnée source. Si le VPS tombe ou est compromis, la sauvegarde locale tombe avec.

Chiffre concret : le monde de l’association pesait environ 1,8 Go après 4 mois d’activité. Compressé en tar.gz, la sauvegarde tombait à 620 Mo, avec un temps d’exécution de 12 secondes — largement acceptable pour ne pas geler le serveur pendant la sauvegarde (Paper continue de tourner pendant que tar lit les fichiers, léger risque de corruption de chunk en cours d’écriture, mais négligeable statistiquement sur une fenêtre de 12 secondes à 4h du matin).

Et le test de restauration : je l’ai fait une fois par mois sur un second VPS de test à 3€/mois, pour vérifier que l’archive était bien exploitable. Sur 6 mois, une seule archive s’est révélée partiellement corrompue (chunk illisible), détectée uniquement parce que je testais activement — sans ce test, je l’aurais découvert seulement le jour où j’en aurais eu besoin en urgence.

Résultats mesurés après mise en production

Après 6 mois d’exploitation pour l’association, voici les chiffres que j’ai suivis :

  • TPS moyen mesuré via Spark : 19,7/20, stable même à 10 joueurs simultanés avec 4 plugins actifs
  • Utilisation RAM moyenne : 4,2 Go sur les 6 Go alloués à la JVM
  • Uptime réel : 99,6% (2 coupures liées à un crash de plugin, résolues automatiquement par systemd)
  • Coût mensuel total : 15€ VPS + 0€ (stockage backup mutualisé sur un espace déjà payé par ailleurs)
  • Temps de mise en place initiale : 2h30, sécurisation et sauvegardes comprises

À titre de comparaison, un serveur Minecraft hébergé chez un fournisseur spécialisé « clé en main » pour ce même profil (10 joueurs, quelques plugins) coûte généralement entre 8€ et 20€/mois, mais sans accès root, avec des limitations sur les plugins autorisés, et surtout sans maîtrise réelle de la sécurité — vous faites confiance à la configuration par défaut du fournisseur. Pour un usage ponctuel ou pour quelqu’un qui ne veut vraiment rien gérer, ça reste une option valable. Mais dès qu’on veut des plugins spécifiques, un contrôle réel sur la sécurité, ou simplement comprendre ce qui tourne, l’auto-hébergement sur VPS reste largement supérieur pour un budget quasi identique.

Ce que je ferais différemment aujourd’hui

Honnêtement, deux choses. D’abord, j’installerais dès le départ un monitoring léger (Netdata ou un simple script qui pousse le TPS et l’usage RAM vers un webhook Discord) plutôt que de vérifier manuellement — je l’ai ajouté seulement au 3ème mois, après le premier crash silencieux découvert par un joueur plutôt que par moi. Ensuite, je testerais la restauration de sauvegarde dès la première semaine et pas au premier mois : c’est le seul moyen de savoir si votre processus de sauvegarde fonctionne réellement avant d’en avoir besoin sous pression.

Action à faire dans les 24h

Si vous avez déjà un serveur Minecraft qui tourne, ne relancez pas tout — vérifiez juste ces trois points ce soir, ça prend 10 minutes : premièrement, ouvrez votre server.properties et vérifiez que enable-rcon est à false ou que le port RCON n’est pas ouvert dans votre pare-feu (ufw status) ; deuxièmement, vérifiez que vous avez au moins une sauvegarde qui date de moins de 24h et testez-en une restauration sur un dossier temporaire pour confirmer qu’elle est exploitable ; troisièmement, si vous n’avez pas de whitelist et que le serveur n’est pas censé être public, activez-la maintenant. Ces trois vérifications m’ont évité, sur mes déploiements, la quasi-totalité des incidents graves que j’ai rencontrés en 15 ans côté infrastructure — Minecraft ou pas, les fondamentaux ne changent jamais.