--- title: "Migrer un plugin Minecraft de 1.21 vers 26.x : le guide 2026 | Minax" description: "Versionnage calendaire, Adventure 5, disparition du remapper, bloc libraries au lieu du shading : tout ce qu'il faut changer pour migrer un plugin de 1.21 vers 26.x, et quelle version viser vraiment." lang: fr-FR json-ld: | [ { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://minax.fun/#organization", "name": "Minax", "url": "https://minax.fun", "logo": { "@type": "ImageObject", "url": "https://minax.fun/minax-logo-256.png", "width": 256, "height": 256 }, "description": "Plateforme IA pour créer des plugins Minecraft (Paper, Spigot, Bukkit, Folia) sans coder en Java." }, { "@type": "WebSite", "@id": "https://minax.fun/#website", "url": "https://minax.fun", "name": "Minax", "publisher": { "@id": "https://minax.fun/#organization" }, "inLanguage": [ "fr-FR", "en-US", "de-DE" ], "potentialAction": { "@type": "SearchAction", "target": "https://minax.fun/discover?q={search_term_string}", "query-input": "required name=search_term_string" } } ] }, [ { "@context": "https://schema.org", "@type": "Article", "headline": "Migrer un plugin Minecraft de 1.21 vers 26.x : le guide complet", "description": "Minecraft est passé au versionnage calendaire. Voici quoi changer concrètement dans un plugin pour aller de 1.21 vers 26.x, et quelle version viser compte tenu du parc réel des serveurs.", "image": "https://minax.fun/og-image.jpg", "datePublished": "2026-07-25", "dateModified": "2026-07-25", "inLanguage": "fr", "author": { "@type": "Organization", "name": "Minax", "url": "https://minax.fun" }, "publisher": { "@type": "Organization", "name": "Minax", "url": "https://minax.fun" }, "mainEntityOfPage": "https://minax.fun/blog/migrer-plugin-nouvelle-version-minecraft" }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Faut-il abandonner 1.21 maintenant que 26.2 est sortie ?", "acceptedAnswer": { "@type": "Answer", "text": "Non. Sur un relevé bStats de 62 948 serveurs, 1.21.11 pèse 36,4 % et 1.21.4 encore 7,2 %, contre 14,9 % pour 26.1.2 et 7,4 % pour 26.2. La famille 1.21 reste majoritaire : abandonner sa compatibilité coûte plus de serveurs qu'elle n'en fait gagner." } }, { "@type": "Question", "name": "Faut-il compiler en Java 25 pour les versions calendaires ?", "acceptedAnswer": { "@type": "Answer", "text": "Java 25 est le plancher d'exécution des versions calendaires, mais compiler en Java 21 reste le bon choix : un .jar Java 21 se charge sur un runtime plus récent, alors qu'un .jar Java 25 refuse de se charger sur un serveur en Java 21, avec UnsupportedClassVersionError à la clé." } }, { "@type": "Question", "name": "Pourquoi mon code de messages ne compile plus sur Paper 26.x ?", "acceptedAnswer": { "@type": "Answer", "text": "Paper 26.x embarque Adventure 5, qui a supprimé des API auparavant seulement dépréciées. Tout ce qui touche aux messages et au texte affiché aux joueurs est concerné. La sortie propre consiste à passer au type Component partout, ce qui compile aussi sur 1.21." } }, { "@type": "Question", "name": "Faut-il encore embarquer le pilote SQLite dans le .jar ?", "acceptedAnswer": { "@type": "Answer", "text": "Non, le pilote JDBC SQLite est déjà fourni avec Paper. En revanche HikariCP ne l'est pas : déclare-le dans le bloc libraries de plugin.yml plutôt que de le shader." } } ] }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://minax.fun/blog" }, { "@type": "ListItem", "position": 2, "name": "Migrer un plugin vers une nouvelle version", "item": "https://minax.fun/blog/migrer-plugin-nouvelle-version-minecraft" } ] } ] ] --- [Aller au contenu](#main-content) [Minax](/) 15 en ligne [Plugins](/discover)[Blog](/blog)[Tarifs](/pricing) fr Se connecterS'inscrire [Blog](/blog)/ Migration 25 juillet 2026 · Migration # Migrer un plugin de 1.21 vers 26.x : ce qui casse, et ce qu'il faut vraiment viser ![Console de serveur Minecraft pendant la migration d'un plugin vers une version calendaire](/assets/blog-minecraft-update-DQC6XZwv.webp) Minecraft ne compte plus en 1.x. La dernière version s'appelle 26.2 et elle est sortie le 16 juin 2026. Pour qui maintient un plugin écrit pour 1.21, la question n'est pas seulement technique, elle est stratégique. Migrer coûte du temps, et viser la mauvaise version coûte des installations. Ce guide dit exactement quoi changer dans le code, dans quel ordre, et surtout quelle version cibler, parce que la bonne réponse n'est pas la plus récente. ## Ce que le versionnage calendaire change vraiment Le numéro de version encode maintenant l'année et le rang de sortie dans l'année. 26.2 veut dire deuxième version de 2026, rien de plus. Le numéro ne te dit plus si le changement est mineur ou structurel, et c'est le premier réflexe à perdre : tu ne peux plus déduire l'ampleur d'une migration du saut de numéro. Il faut regarder ce qui a bougé sous le capot. Sous le capot, trois choses ont changé et elles comptent toutes les trois. Minecraft est désobfusqué depuis 26.1, ce qui a fait disparaître le remapper de Paper. Paper 26.x embarque Adventure 5, qui a supprimé des API auparavant seulement dépréciées. Et Java 25 est devenu le plancher d'exécution des versions calendaires. Un plugin 1.21 qui touche à ces trois zones ne se contente pas de recompiler. Le chiffre que peu de monde regarde avant de migrer Sur un relevé bStats portant sur **62 948 serveurs**, la répartition réelle est la suivante : 1.21.11 à **36,4 %**, 26.1.2 à **14,9 %**, 26.2 à **7,4 %**, 1.21.4 à **7,2 %**. Autrement dit, ces deux entrées de la famille 1.21 pèsent à elles seules 43,6 % du parc, contre 22,3 % pour les deux branches calendaires réunies. Le parc est presque deux fois plus 1.21 que calendaire. [bStats](https://bstats.org) publie ces distributions en continu, c'est la seule mesure sérieuse disponible. ## Quelle version viser vraiment Il y a un piège de plus. Paper 26.2 n'a pas de build stable : la cible de production raisonnable sur la branche calendaire est 26.1.2, pas 26.2. Livrer un plugin qui n'existe qu'en 26.2, c'est donc demander à tes utilisateurs de tourner sur une base que Paper lui-même ne déclare pas stable. Part du parc Verdict 1.21.11 36,4 % Cible principale, la majorité de tes installations 26.1.2 14,9 % Cible calendaire de production, celle à tester 26.2 7,4 % Pas de build stable Paper, ne pas livrer pour elle seule 1.21.4 7,2 % Compatible sans effort si tu restes sur l'API publique Ma lecture, assumée : abandonner 1.21 aujourd'hui serait une erreur. Ce n'est pas de la nostalgie, c'est de l'arithmétique. Tu renoncerais à une famille majoritaire pour gagner une branche qui pèse deux fois moins, et dont la version la plus récente n'a même pas de build stable. La bonne cible est un plugin unique qui compile contre 1.21, se charge sur 26.x, et n'utilise rien qui ait disparu entre les deux. > "On ne migre pas vers la dernière version, on migre vers la version que font tourner les gens qui installent le plugin." > > **Règle de migration**, valable pour tout l'écosystème Bukkit ## La version d'API et la version de Java Deux réglages distincts, souvent confondus. La version d'API est la génération de l'API Bukkit contre laquelle ton code est écrit, déclarée dans plugin.yml. La version de Java est le format de bytecode produit par le compilateur. Les deux se règlent indépendamment, et se tromper sur la seconde est la cause de refus de chargement la plus banale. pom.xml ``` 21 UTF-8 papermc https://repo.papermc.io/repository/maven-public/ io.papermc.paper paper-api 1.21.11-R0.1-SNAPSHOT provided ``` Compile contre la version la plus _ancienne_ que tu veux supporter, pas la plus récente. Un plugin compilé contre l'API 26.x et installé sur un serveur 1.21 plante dès qu'il appelle une méthode qui n'existe pas encore là-bas. Dans l'autre sens, un plugin compilé contre 1.21 tourne sur 26.x tant qu'il n'utilise pas d'API supprimée. C'est asymétrique, et cette asymétrie est ton amie. Les coordonnées exactes de chaque branche se vérifient sur [docs.papermc.io](https://docs.papermc.io), et les signatures sur [jd.papermc.io](https://jd.papermc.io). Java 25 est un plancher d'exécution, pas une cible de compilation Java 25 est le plancher des versions calendaires. Cela veut dire qu'un serveur 26.x tourne sur Java 25 ou plus, pas que ton plugin doive être compilé en 25. Si tu passes ta cible de compilation à 25, ton .jar refusera de se charger sur toute la famille 1.21 encore en Java 21, avec un `UnsupportedClassVersionError` à la clé. Reste en 21, sauf si tu as besoin d'une fonctionnalité de langage précise, ce qui est rare dans un plugin. ## Adventure 5 : le texte, c'est la zone qui casse C'est le point qui fait le plus de dégâts. Paper 26.x embarque Adventure 5, et Adventure 5 a supprimé des API qui n'étaient jusque-là que dépréciées. La zone touchée est prévisible : tout ce qui concerne les messages et le texte affiché aux joueurs. Un plugin 1.21 qui envoie ses messages à l'ancienne peut tout simplement ne plus compiler. La bonne nouvelle : la sortie est unique et elle marche dans les deux mondes. Adventure est inclus dans Paper depuis longtemps, donc du code écrit avec `Component` compile aussi bien sur 1.21 que sur 26.x. Tu ne fais pas deux versions, tu modernises une fois. Java ``` package fun.example.migration; import net.kyori.adventure.text.Component; import net.kyori.adventure.text.format.NamedTextColor; import net.kyori.adventure.text.minimessage.MiniMessage; import net.kyori.adventure.text.serializer.legacy.LegacyComponentSerializer; public final class Messages { private static final MiniMessage MINI = MiniMessage.miniMessage(); private Messages() { } /** Message construit dans le code, sans aucune chaine de couleur. */ public static Component welcome(String playerName) { return Component.text("Bienvenue ", NamedTextColor.GOLD) .append(Component.text(playerName, NamedTextColor.WHITE)) .append(Component.text(" sur le serveur.", NamedTextColor.GRAY)); } /** Meme principe pour une valeur numerique, sans concatenation coloree. */ public static Component balance(long amount) { return Component.text("Solde : ", NamedTextColor.GRAY) .append(Component.text(amount, NamedTextColor.GOLD)); } /** Ligne ecrite par l'admin dans config.yml, au format MiniMessage. */ public static Component fromConfig(String line) { return MINI.deserialize(line); } /** * Chaine heritee d'un ancien config.yml, du type "&aTexte vert". * On la convertit au lieu de la jeter : les fichiers des utilisateurs * existent deja et personne ne les reecrira a la main. */ public static Component fromLegacy(String stored) { return LegacyComponentSerializer.legacyAmpersand().deserialize(stored); } } ``` Côté appel, plus rien à inventer : `player.sendMessage(Messages.welcome(player.getName()))`. La documentation Adventure vit sur [docs.advntr.dev](https://docs.advntr.dev), l'intégration côté Paper sur [docs.papermc.io](https://docs.papermc.io). Ce qui ne marche pas : le rechercher-remplacer La tentation, c'est de faire une passe mécanique sur tous les appels de messages jusqu'à ce que le compilateur se taise. Deux dégâts classiques. Un : tu supprimes la lecture des chaînes héritées du `config.yml`, et tous les serveurs qui avaient personnalisé leurs messages les perdent au premier démarrage. Deux : tu laisses passer les endroits qui ne cassent pas la compilation mais changent d'apparence en jeu, comme les noms d'items, les titres d'inventaires et les lignes de scoreboard. Fais l'inventaire de ces trois surfaces à la main avant de toucher au code. ## La disparition du remapper Minecraft est désobfusqué depuis 26.1, et le remapper de Paper a disparu avec l'obfuscation. Si ton plugin restait sagement sur l'API publique Bukkit et Paper, tu ne verras absolument rien. Si en revanche il descendait dans les classes internes du serveur, la migration te concerne de plein fouet : l'étape de remapping sur laquelle reposait ton build n'existe plus, et les noms sur lesquels tu réfléchissais ne sont plus les mêmes. Mon conseil est brutal et je l'assume : profite de la migration pour sortir des internes. Une réflexion sur des classes internes est le genre de code qui te réclamera une correction à chaque version, calendaire ou pas. La plupart du temps, l'API publique fait désormais la même chose. Quand ce n'est pas le cas, isole cet accès dans une seule classe, avec un repli propre si la classe attendue est absente, plutôt que de le laisser éparpillé dans le plugin. Ce que la désobfuscation apporte Plus d'étape de remapping dans le build Piles d'appels lisibles dans les rapports d'erreur Code interne lisible quand il faut comprendre un comportement Ce qu'elle casse Les builds qui dépendaient du remapper ne passent plus La réflexion sur les anciens noms obfusqués échoue Les tutoriels NMS d'avant 26.1 sont périmés ## Le bloc libraries au lieu du shading Le réflexe historique consistait à embarquer ses dépendances dans le .jar, autrement dit à les shader. Le bloc `libraries:` de plugin.yml remplace cette pratique : tu déclares la dépendance, et le serveur la télécharge lui-même. Le .jar redevient petit et ne contient que ton code. Avant de déclarer quoi que ce soit, vérifie ce qui est déjà là. Le pilote JDBC SQLite est déjà fourni avec Paper : si tu l'embarquais, tu ajoutais du poids pour rien. HikariCP, en revanche, n'est pas fourni. C'est exactement le genre de dépendance à mettre dans `libraries:`. plugin.yml ``` name: MonPlugin version: 1.0.0 main: fun.example.migration.MonPlugin api-version: '1.21' description: Plugin migre, un seul .jar pour 1.21 et 26.x authors: [ MonPseudo ] # Telecharge par le serveur au premier demarrage. # Le pilote SQLite n'est PAS ici : Paper le fournit deja. libraries: - com.zaxxer:HikariCP:5.1.0 commands: solde: description: Affiche ton solde usage: /solde ``` La valeur d'`api-version` déclare la génération d'API contre laquelle ton code est écrit. Garde-la sur la plus ancienne génération que tu supportes réellement : c'est ce qui te maintient chargeable sur toute la famille 1.21 tout en restant accepté par les serveurs plus récents. Le format exact du fichier est documenté sur [docs.papermc.io](https://docs.papermc.io) et, pour la partie historique Bukkit, sur [hub.spigotmc.org](https://hub.spigotmc.org). Ce qui ne marche pas : croire que libraries est gratuit Deux pièges très concrets. D'abord, le téléchargement se fait sur la machine du serveur au premier démarrage : un hébergeur qui bloque les sorties réseau fait échouer le chargement de ton plugin, et l'utilisateur ne comprendra pas pourquoi. Ensuite, une coordonnée mal écrite ne se voit pas à la compilation. Ton build passe, ton .jar est valide, et l'erreur n'apparaît qu'au démarrage du serveur de l'utilisateur. Teste toujours le .jar sur un serveur réel avant de le publier, pas seulement dans ton IDE. ## Le piège UUID du mode hors ligne Voici la partie que presque aucun guide de migration ne traite, et c'est pourtant celle qui détruit le plus de données. **75,1 % des serveurs tournent en mode hors ligne.** En mode hors ligne, l'UUID d'un joueur est dérivé de son pseudo. Ce n'est pas un détail d'implémentation, c'est une propriété qui change la conception de ta base : si le joueur change de pseudo, ou si le serveur passe un jour en mode en ligne, la clé change et toutes les données stockées sur l'ancien UUID deviennent orphelines. Concrètement, un plugin d'économie qui stocke un solde sur l'UUID sans rien d'autre offre ce scénario à son utilisateur : le joueur renommé perd son argent, l'administrateur ne comprend pas, et personne ne sait reconstituer la correspondance. Le correctif tient en une colonne : garde le pseudo à côté de l'UUID, indexe-le, et tu conserves un chemin de réconciliation. SQL ``` CREATE TABLE IF NOT EXISTS player_data ( uuid TEXT PRIMARY KEY, last_name TEXT NOT NULL, balance INTEGER NOT NULL DEFAULT 0, updated_at INTEGER NOT NULL ); -- Indispensable en mode hors ligne : c'est le seul chemin de retour -- quand un joueur change de pseudo ou quand le serveur bascule en ligne. CREATE INDEX IF NOT EXISTS idx_player_data_name ON player_data(last_name); ``` Java ``` package fun.example.migration; import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException; import java.util.UUID; public final class PlayerRepository { private final Connection connection; public PlayerRepository(Connection connection) { this.connection = connection; } /** * Ecrit toujours le pseudo courant en meme temps que la donnee. * Sans cette ligne, un renommage rend l'enregistrement introuvable * sur les 75,1 % de serveurs en mode hors ligne. */ public void save(UUID uuid, String name, long balance) throws SQLException { String sql = "INSERT INTO player_data(uuid, last_name, balance, updated_at) " + "VALUES(?, ?, ?, ?) " + "ON CONFLICT(uuid) DO UPDATE SET " + "last_name = excluded.last_name, " + "balance = excluded.balance, " + "updated_at = excluded.updated_at"; try (PreparedStatement ps = connection.prepareStatement(sql)) { ps.setString(1, uuid.toString()); ps.setString(2, name); ps.setLong(3, balance); ps.setLong(4, System.currentTimeMillis()); ps.executeUpdate(); } } public long readBalance(UUID uuid) throws SQLException { String sql = "SELECT balance FROM player_data WHERE uuid = ?"; try (PreparedStatement ps = connection.prepareStatement(sql)) { ps.setString(1, uuid.toString()); try (ResultSet rs = ps.executeQuery()) { return rs.next() ? rs.getLong(1) : 0L; } } } } ``` Le test que je fais systématiquement Sur un serveur de test en mode hors ligne, connecte-toi, crée de la donnée, déconnecte-toi, renomme ton compte de test, reconnecte-toi. Si ta donnée a disparu, ton schéma est fragile et il l'était déjà avant la migration. Ce test prend deux minutes et il révèle un défaut que trois quarts du parc peuvent déclencher. ## Folia : le thread principal n'est plus garanti Folia exécute les régions du monde sur plusieurs threads. Un plugin qui suppose un thread principal unique ne ralentit pas, il fait crasher. La migration consiste à passer par le RegionScheduler pour toucher au monde, et à ne jamais faire d'accès base de données sur un thread de jeu, sous peine de voir le TPS s'effondrer. Java ``` import org.bukkit.Bukkit; import org.bukkit.Location; import org.bukkit.entity.Player; import org.bukkit.plugin.Plugin; import java.sql.SQLException; import java.util.UUID; public final class BalanceLookup { private final Plugin plugin; private final PlayerRepository repository; public BalanceLookup(Plugin plugin, PlayerRepository repository) { this.plugin = plugin; this.repository = repository; } public void showBalance(UUID uuid, Location location) { // 1. La base de donnees, hors de tout thread de jeu. Bukkit.getAsyncScheduler().runNow(plugin, task -> { final long balance; try { balance = repository.readBalance(uuid); } catch (SQLException e) { plugin.getLogger().warning("Lecture du solde impossible : " + e.getMessage()); return; } // 2. Le retour au monde, sur le thread qui possede cette region. Bukkit.getRegionScheduler().execute(plugin, location, () -> { Player player = Bukkit.getPlayer(uuid); if (player != null) { player.sendMessage(Messages.balance(balance)); } }); }); } } ``` Ce code n'est pas réservé à Folia : Paper expose ces schedulers, tu peux donc l'écrire dès maintenant sur ta cible 1.21 et rester compatible sans double base de code. Les détails de comportement de Folia sont sur [docs.papermc.io](https://docs.papermc.io), et si tu veux voir le résultat sans monter l'environnement, notre [générateur de plugin Folia](/generateur-plugin-folia) produit directement du code au RegionScheduler. ## Mon arbitrage, en clair Un panorama neutre n'aide personne, alors voilà ce que je recommande, avec les seuils. **Un seul .jar pour la grande majorité des cas.** Compilé en Java 21, contre l'API 1.21, zéro accès aux internes, Adventure partout, schedulers compatibles Folia. Ce plugin couvre la famille 1.21 majoritaire et se charge sur 26.x. Deux builds séparés ne se justifient que si tu touches vraiment aux classes internes du serveur. **Folia, sur un serveur modeste, je ne migre pas.** Le RegionScheduler complique la lecture du code pour un gain que tu ne mesureras pas quand une seule région porte tout le monde. Sur un serveur très fréquenté, ou sur une map très étalée où les joueurs sont dispersés, l'investissement devient rentable. Écris quand même le code compatible dès le départ : il ne coûte rien sur Paper et t'évite une réécriture le jour où tu changes d'échelle. **Base de données : SQLite tant que tu as un seul serveur.** Le pilote est déjà fourni, une seule connexion suffit, et tu n'as strictement rien à déclarer. Le jour où plusieurs serveurs doivent partager les mêmes données, tu passes à MySQL, et c'est là seulement que HikariCP entre dans le bloc `libraries:`. Un pool de connexions sur un fichier SQLite local est de la complexité pure. **26.2 : je n'y livre rien.** Tant qu'il n'y a pas de build Paper stable, la cible calendaire est 26.1.2. Tu peux tester sur 26.2 par curiosité, tu ne construis pas ta compatibilité dessus. ### Faire la migration sans relire ligne par ligne Décris ton plugin et la version visée, Minax écrit du code Adventure, compile un .jar propre et te laisse le tester en ligne avant de l'installer. [Migrer mon plugin](/creer-plugin-minecraft) ## La checklist de migration, dans l'ordre 1. Fixe la cible : compilation contre 1.21, chargement vérifié sur 26.1.2. 2. Vérifie que `maven.compiler.release` vaut 21, pas 25. 3. Recense tous les endroits qui produisent du texte : messages, noms d'items, titres d'inventaires, scoreboards. 4. Passe ces endroits en `Component`, et ajoute une conversion des chaînes héritées du config.yml. 5. Cherche tout accès aux classes internes du serveur et supprime-le, ou isole-le dans une seule classe. 6. Retire du .jar tout ce que Paper fournit déjà, en commençant par le pilote JDBC SQLite. 7. Déclare le reste dans `libraries:` au lieu de le shader. 8. Sors tous les accès base de données des threads de jeu. 9. Remplace les hypothèses de thread principal unique par le RegionScheduler. 10. Ajoute la colonne de pseudo à côté de l'UUID, et fais le test du renommage en mode hors ligne. 11. Installe le .jar sur un vrai serveur, une fois en 1.21 et une fois en 26.1.2, avant de publier. Si une étape casse, lis la première ligne d'erreur et rien d'autre : notre [guide de dépannage des plugins](/blog/erreurs-plugin-minecraft) couvre les messages que produit exactement ce genre de migration. ## Conclusion Le versionnage calendaire a rendu la question de la cible plus visible, pas plus simple. Le travail réel de migration tient en quatre chantiers : le texte via Adventure, la sortie des internes, les dépendances déclarées plutôt qu'embarquées, et l'abandon de l'hypothèse du thread unique. Le reste est du réglage. Et la décision la plus importante n'est pas technique : tant que 1.21 pèse près de deux fois le parc calendaire, la version à viser reste 1.21, avec du code qui tourne aussi sur 26.x. Pour voir ce qui a changé côté versions, notre page [plugins Minecraft 26](/plugins-minecraft-26) détaille la branche calendaire. ## Articles connexes [ ![Plugins Minecraft 26 : ce qui change](/assets/blog-minecraft-update-DQC6XZwv.webp) Versions ### Plugins Minecraft 26 : ce qui change Lire ](/plugins-minecraft-26)[ ![Mon plugin ne charge pas : dépannage](/assets/blog-optimiser-serveur-D9PGend8.webp) Dépannage ### Mon plugin ne charge pas : dépannage Lire ](/blog/erreurs-plugin-minecraft)[ ![Générer un plugin Folia](/assets/blog-create-plugin-1g5qWpiS.webp) Outil ### Générer un plugin Folia Lire ](/generateur-plugin-folia) 12 min de lecture Sommaire [Le versionnage calendaire](#calendrier)[Quelle version viser vraiment](#parc)[Version d'API et Java](#api)[Adventure 5 et le texte](#adventure)[La fin du remapper](#remapper)[libraries au lieu du shading](#libraries)[Le piège UUID hors ligne](#uuid)[Folia et le thread principal](#folia)[Mon arbitrage](#avis)[La checklist de migration](#checklist)[Conclusion](#conclusion) Partager Lien[X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fminax.fun%2Fblog%2Fmigrer-plugin-nouvelle-version-minecraft) Minax L'IA spécialisée qui révolutionne la création de plugins Minecraft. Transformez vos idées en code professionnel en quelques minutes. **408** Plugins créés **0** Membres #### Produit - [Générateur de plugins](/) - [Créer un plugin](/creer-plugin-minecraft) - [Générateur Spigot](/generateur-spigot) - [Avis utilisateurs](/discover) #### Ressources - [Blog & Ressources](/blog) - [Guide serveur Minecraft](/guide-serveur-minecraft) - [Héberger son serveur](/hebergeur-serveur-minecraft) - [Mécaniques SMP](/plugin-smp-minecraft) - [Communauté Discord](https://discord.gg/NG4nR3E5a6) - Contact #### Nous suivre [Minax sur LinkedIn ](https://www.linkedin.com/in/thomas-bidaultt)[Minax sur Discord ](https://discord.gg/NG4nR3E5a6)[Minax sur YouTube ](https://www.youtube.com/@MrFrosasi)[Minax sur Instagram ](https://www.instagram.com/ccsglobal.inc) © 2026 Minax. Tous droits réservés. [Politique de confidentialité](/privacy)[Conditions d'utilisation](/terms)[CGV](/cgv)[Cookies](/cookies)[Mentions légales](/legal)Gérer les cookies Accueil Découvrir Créer Projets Profil Nous utilisons **Google Analytics**, **Microsoft Clarity** et **Reddit Pixel** pour analyser l'utilisation du site et améliorer votre expérience. [En savoir plus](/cookies) Tout refuserTout accepter