Installer un modpack Minecraft sur ton serveur
Un modpack change tout : nouveaux mods, dimensions, mécaniques, parfois cinq cents mods d'un coup. Lancer un serveur moddé n'a rien de compliqué — à condition de comprendre trois choses que les tutoriels passent sous silence : d'où vient le loader, combien de mémoire le serveur reçoit réellement, et pourquoi le premier démarrage prend vingt minutes.
Modrinth ou CurseForge : ce qui change vraiment
Les deux plateformes couvrent l'essentiel des modpacks, mais elles ne se distribuent pas de la même façon.
- Modrinth est ouvert : le pack se télécharge sans clé d'API, et la redistribution par un tiers est autorisée. Colle l'URL (
modrinth.com/modpack/…) ou même simplement le slug du pack — les deux sont acceptés. - CurseForge demande une clé d'API côté hébergeur pour installer automatiquement. Il faut ici coller l'URL complète (
curseforge.com/minecraft/modpacks/…) : un slug nu serait ambigu avec Modrinth, il est donc refusé.
C'est la raison pour laquelle un pack Modrinth s'installe toujours et un pack CurseForge dépend de l'hébergeur. Si tu t'héberges toi-même, la même règle s'applique : Modrinth se récupère directement, CurseForge demande une clé.
Tu n'as pas à choisir le loader ni la version
C'est le point qui fait perdre le plus de temps quand on installe à la main : Fabric, Forge et NeoForge ne sont pas interchangeables, et un pack ne tourne que sur le sien, dans une version de Minecraft précise.
Bonne nouvelle : le pack porte cette information. Le loader et la version de Minecraft sont imposés par le modpack, pas par toi. Tu colles un lien, le reste est déduit. Il en va de même pour Java — chaque version de Minecraft exige une version minimale (Java 21 depuis Minecraft 1.20.5, Minecraft Wiki) et elle est choisie pour toi.
Ce que tu dois vérifier en revanche, c'est la version du pack que tes amis installent côté client. Un mod de contenu doit être présent des deux côtés, dans la même version : c'est la cause n°1 des « connexion refusée » et des « mod mismatch ».
Les modpacks prêts à l'emploi
Dix packs sont proposés directement, sans avoir à chercher de lien :
| Pack | Loader | Minecraft | Genre |
|---|---|---|---|
| All the Mods 10 | NeoForge | 1.21.1 | kitchen-sink |
| COBBLEVERSE | Fabric | 1.21.1 | Pokémon |
| Cobblemon Official | Fabric | 1.21.1 | Pokémon |
| Vault Hunters 3ᵉ édition | Forge | 1.18.2 | RPG |
| Prominence II | Fabric | 1.20.1 | RPG |
| Better MC (BMC2) | Fabric | 1.20.1 | aventure |
| SkyFactory 4 | Forge | 1.12.2 | skyblock |
| RLCraft | Forge | 1.12.2 | hardcore |
| Create: Live 5 | Forge | 1.20.1 | technique |
| Adrenaline | Fabric | 1.20.1 | performances |


La RAM : ce que le serveur reçoit vraiment
Voici la chose la plus utile de ce guide, et celle qu'aucune page de modpack n'explique.
Quand un auteur de pack écrit « alloue 8 Go », il parle du tas de la JVM (-Xmx) — pas de la mémoire de la machine. Or les deux ne sont jamais égales : le système, Docker et la mémoire hors-tas de Java (metaspace, buffers) vivent à côté du tas. Donner toute la RAM à la JVM, c'est se faire tuer le serveur par le noyau en pleine partie.
Le tas est donc calculé automatiquement, et il vaut le plus petit de « RAM − 2 Go » et de « 75 % de la RAM » :
| Palier choisi | Tas JVM réel | Ce que ça couvre |
|---|---|---|
| 4 Go | 2 Go | vanilla, ou un pack très léger |
| 8 Go | 6 Go | Cobblemon, RLCraft, Create: Live 5 |
| 16 Go | 12 Go | All the Mods, COBBLEVERSE, SkyFactory |
| 32 Go | 24 Go | gros pack + groupe nombreux |
Traduis toujours dans ce sens : un pack qui demande 8 Go de tas ne tient pas sur le palier 8 Go, qui n'en rend que 6 — il faut le palier 16 Go. C'est pour ça que l'écran de création t'avertit quand le palier choisi ne couvre pas le pack : il compare des tas, pas des tailles de machine.
Et si l'exploration saccade alors que le tas est confortable, ce n'est plus la mémoire : c'est le CPU. Le niveau CPU dédié existe pour ça.
Le premier démarrage prend quinze à vingt-cinq minutes
Il ne « plante » pas. Un serveur moddé, au premier boot, télécharge le pack, résout les dépendances de mods, écrit la configuration, puis génère le monde — et la génération d'un monde moddé est bien plus lourde que celle d'un monde vanilla, parce que chaque mod ajoute ses structures et ses biomes.
Un serveur vanilla est prêt en 1 à 2 minutes. Un gros pack, 15 à 25 minutes. Les démarrages suivants sont rapides, le monde étant déjà là.
C'est la panne fantôme classique : on croit à un échec, on coupe, on relance, et on ne finit jamais ce premier boot. Laisse-le aller au bout.
Ce qui est conservé, et ce qui ne l'est pas
Le dossier de données est archivé avant chaque arrêt et restauré à la session suivante, avec un save-all flush juste avant l'archivage. Une sauvegarde automatique tourne toutes les 30 minutes en cours de partie, dont les 5 dernières sont gardées.
Ce qui n'est pas archivé, volontairement : les bibliothèques et les binaires du serveur, que l'image re-télécharge à chaque session. Ton archive ne contient que ce qui est à toi — monde, configuration, mods — et reste donc petite.
Changer de pack, ou revenir en arrière
Un monde moddé est indissociable de ses mods : chargé sans eux, il perd ses blocs, définitivement. Ne change donc pas de pack sur un monde existant — crée un second serveur. Et si tu importes un monde moddé venu d'ailleurs, colle le même pack dans la même version avant l'import : voir le guide de migration de monde.
Prêt ? Crée ton serveur Minecraft et colle ton modpack. Ta 1re partie est offerte.