Monter un serveur moddé : Forge, Fabric et les modpacks
25 août 2026 · mis à jour le 14 octobre 2026 · 5 min de lecture
Un serveur moddé ne se monte pas comme un serveur à plugins. La différence tient en une phrase : avec des plugins, le joueur se connecte avec son client habituel ; avec des mods, il doit installer exactement les mêmes que vous. Tout le reste en découle.
Moddé ou plugins : ce que ça change vraiment
Un serveur à plugins touche tout le monde. Un serveur moddé touche les gens prêts à installer un lanceur, télécharger deux gigaoctets et attendre. Vous perdez neuf visiteurs sur dix au moment où vous annoncez qu'il faut un modpack.
En échange, ceux qui restent restent longtemps. Un joueur qui a installé votre pack ne va pas tester trois autres serveurs le soir même. C'est le compromis : moins de passage, beaucoup plus de fidélité. Si votre objectif est de remplir un serveur vite, faites du Paper. Si votre objectif est une communauté de trente personnes qui joue la même partie pendant six mois, faites du moddé.
Choisir le chargeur de mods
Quatre noms reviennent, et le choix se fait presque toujours pour vous, parce que c'est le pack qui décide.
- Forge : le plus ancien, le plus fourni en gros mods de contenu. C'est lui qui fait tourner la majorité des packs « kitchen sink » et des grandes aventures.
- NeoForge : une reprise de Forge par une partie de ses développeurs, née en 1.20.1 et devenue incompatible avec Forge à partir de la 1.20.2. Sur les versions récentes, c'est souvent lui qu'il faut, et les mods Forge ne s'y installent pas tels quels.
- Fabric : léger, rapide à suivre les nouvelles versions du jeu. Les packs de performance et de technique s'y trouvent en priorité.
- Quilt : un dérivé de Fabric, compatible avec la plupart de ses mods. Marginal côté serveur.
Retenez surtout qu'ils ne se mélangent pas. Un mod Fabric ne tournera jamais sur Forge, et un mod prévu pour la 1.20.1 ne tournera pas en 1.21. La moitié des serveurs moddés qui refusent de démarrer se heurtent à l'une de ces deux règles.
Partir d'un modpack existant
Assembler soi-même quatre-vingts mods est un excellent moyen de passer trois semaines à chasser des incompatibilités au lieu de jouer. Les modpacks publiés sur CurseForge et Modrinth sont déjà testés, déjà équilibrés, et leurs auteurs ont fait le travail d'accorder les versions.
Regardez trois choses avant d'en choisir un :
- La date de mise à jour. Un pack abandonné depuis un an vous laissera seul devant le premier bug.
- La mémoire recommandée. Elle est presque toujours annoncée, et presque toujours optimiste.
- L'existence d'un server pack. Certains packs ne se distribuent que côté client ; il faut alors retirer à la main les mods qui n'ont pas leur place sur un serveur, ce qui est exactement le genre de travail qu'on voulait éviter.
Installer le pack côté serveur
Un server pack se présente comme une archive contenant le dossier mods, les configurations et un script de démarrage. La marche à suivre est toujours la même :
- Décompressez l'archive dans un dossier vide.
- Vérifiez la version de Java attendue : Java 8 pour les packs en 1.12 et 1.16, Java 17 de la 1.18 à la 1.20.4, Java 21 à partir de la 1.20.5. Lancer l'un avec l'autre produit une erreur qui ne dit pas son nom ; ce guide apprend à la reconnaître.
- Lancez le script fourni, acceptez le contrat dans
eula.txt, relancez. - Laissez-le générer le monde sans vous connecter. La première génération d'un gros pack peut prendre plusieurs minutes.
N'ajoutez aucun mod de votre cru avant que le pack démarre seul. Sinon vous ne saurez jamais si l'erreur vient de lui ou de vous.
La mémoire, et le piège de lui en donner trop
La règle de départ : 6 Go pour un pack léger, 8 à 10 Go pour un gros pack de contenu, davantage seulement si les mesures le réclament.
Le piège est d'allouer toute la mémoire de la machine. Le système d'exploitation en a besoin, et surtout le ramasse-miettes de Java met d'autant plus de temps à faire son travail que le tas est grand : au-delà de 12 Go, on gagne des micro-blocages plutôt que de la fluidité. Laissez toujours 1 à 2 Go à la machine.
Fixez -Xms et -Xmx à la même valeur. Laisser Java agrandir son tas en cours de route ne sert qu'à provoquer des à-coups au pire moment.
Distribuer le pack à vos joueurs
Donnez un lien, une version, et rien d'autre. « Le pack ATM10, version 1.4.2, sur CurseForge » est une consigne qu'on suit ; « installez ATM10 » ne l'est pas, parce que le joueur prendra la dernière version et que la vôtre a deux semaines de retard.
Les lanceurs qui font ce travail proprement : CurseForge, Modrinth, Prism Launcher, GDLauncher. Indiquez-en un, un seul, avec des captures. Chaque lanceur supplémentaire que vous citez multiplie les questions que vous devrez traiter.
Et surtout : épinglez la version du pack, côté serveur comme côté joueurs. Une mise à jour automatique chez le joueur et pas chez vous, et plus personne ne se connecte.
Les erreurs qui reviennent toutes les semaines
- « Incompatible FML modded server » : le joueur n'a pas le pack, ou pas la bonne version.
- Le serveur démarre puis s'arrête sans message clair : ouvrez
logs/latest.loget cherchez la première ligneCaused by. C'est toujours là que se trouve le vrai motif, pas dans les cent lignes qui suivent. - Le monde ne charge plus après le retrait d'un mod : retirer un mod qui a posé des blocs laisse des trous. Ne retirez jamais un mod de contenu en cours de partie sans sauvegarde.
- Des micro-blocages réguliers : c'est presque toujours une ferme à entités quelque part, pas la machine.
Avant chaque mise à jour du pack
Sauvegardez le monde entier, pas seulement le dossier world. Copiez aussi mods et config : quand une mise à jour tourne mal, revenir en arrière suppose de retrouver exactement l'état d'avant, mods compris.
Testez sur une copie avant de toucher au serveur des joueurs. Une heure de test vaut mieux qu'un week-end de restauration.
Une fois le serveur en route, référencez-le ici : les joueurs qui cherchent un serveur moddé cherchent par modpack, et une fiche qui annonce clairement le pack et sa version fait la moitié du travail.