BungeeCord ou Velocity : choix de proxy pour réseau Minecraft

Ce comparatif oppose BungeeCord, l’implémentation historique, à Velocity, présenté par PaperMC comme une solution « next‑generation », pour vous aider à choisir le proxy adapté à votre réseau Minecraft selon votre usage. Sources consultées le 04/09/2026.

Pourquoi un proxy ?

Un proxy sert de point d’entrée unique pour les joueurs et redirige les connexions vers des serveurs backend. Il permet de changer de serveur sans déconnecter le joueur, de répartir les sessions et d’organiser un réseau composé de plusieurs serveurs dédiés à des activités distinctes. Dans un réseau multi‑serveur, le proxy centralise la connexion et offre des mécanismes de routage entre instances.

Le choix d’un proxy influe sur la compatibilité des plugins, sur la manière dont les paquets sont traités et sur la gestion des versions ou des instances moddés. Ce comparatif présente les différences pertinentes entre BungeeCord et Velocity et indique, par type d’usage, lequel correspond le mieux à un besoin donné.

Ce qu’ils ont en commun

BungeeCord et Velocity remplissent les fonctions de base attendues d’un proxy : point d’entrée central, redirection vers des backends, et facilitation du changement de serveur sans coupure apparente pour le joueur. Les deux solutions s’intègrent avec des serveurs Paper/Spigot comme backends lorsque la configuration côté serveur backend est adaptée pour accepter le forwarding des connexions.

Les deux projets ont une communauté et une documentation publiques. BungeeCord est documenté via SpigotMC et conserve un historique d’utilisation étendu. Velocity dispose d’une documentation officielle hébergée par PaperMC qui décrit ses objectifs et ses différences vis‑à‑vis d’autres proxies.

Sur le plan fonctionnel, les deux permettent d’implémenter des architectures de réseau avec répartition de charge logique, gestion des permissions via plugins et interconnexion d’instances. Les détails d’implémentation et les modèles d’API divergent, mais la finalité — relier plusieurs serveurs pour former un réseau — reste identique.

Architecture et conception

Velocity est présenté comme une conception plus moderne, pensée pour des API récentes et des objectifs de stabilité et d’évolutivité, selon la documentation PaperMC. BungeeCord, de son côté, est l’implémentation historique du proxy, avec une origine ancienne et une base de code liée à son parcours depuis 2012.

Cette différence d’origine se traduit par des choix d’API et par la manière dont chaque projet expose des points d’extension pour les développeurs de plugins. La documentation PaperMC met en avant l’approche de Velocity comme une réécriture axée sur les besoins actuels des réseaux, tandis que les ressources sur SpigotMC rappellent le rôle historique de BungeeCord.

Performance et scalabilité

La communication autour de Velocity insiste sur des objectifs de performance et d’optimisation pour des réseaux modernes, d’après la documentation PaperMC et plusieurs guides techniques. BungeeCord et ses forks, comme Waterfall, restent largement utilisés, notamment lorsqu’un écosystème de plugins déjà existant est à préserver.

Les sources consultées évoquent des avantages revendiqués pour Velocity en termes de performance et de conception, et des notes sur l’écosystème BungeeCord concernant son adoption et sa compatibilité historique. Ce comparatif ne publie aucun chiffre de charge, de latence ou de nombre de joueurs maximal : ces valeurs requièrent des benchmarks indépendants et datés qui ne sont pas inclus ici.

Sécurité

La documentation PaperMC évoque des préoccupations de sécurité et des choix de conception pour Velocity destinés à limiter certaines classes de vulnérabilités. Les notes publiques comparent les approches de gestion des paquets et des surfaces d’attaque entre proxies. BungeeCord, avec son ancienneté et son écosystème, fait l’objet de retours d’expérience communautaires qui mettent en lumière des pratiques d’atténuation et des extensions de sécurité via plugins ou forks.

Il est recommandé, pour tout opérateur, de consulter les pages officielles et les discussions communautaires pour connaître les vulnérabilités documentées et les correctifs disponibles, et d’appliquer des mises à jour selon les préconisations publiées.

Compatibilité plugins et écosystème

BungeeCord bénéficie d’un long historique et d’un grand nombre de plugins développés pour son API. Velocity n’est pas compatible nativement avec l’ensemble des plugins BungeeCord, et des efforts de portage ou des adaptateurs existent lorsqu’ils sont documentés publiquement. Plusieurs guides et articles techniques listent les différences de compatibilité et les solutions proposées par la communauté pour porter des plugins.

Si votre réseau repose sur des plugins legacy développés pour BungeeCord, la compatibilité peut être un critère déterminant. Si vous démarrez un réseau en visant des APIs modernes, la documentation de Velocity met en avant son modèle pour de nouveaux développements.

Support multi‑version et moddé

Les sources indiquent que Velocity aborde le forwarding et les mécanismes modernes de transport de paquets selon des choix de conception documentés par PaperMC. BungeeCord a, au fil du temps, été adapté pour des usages multi‑version via des plugins et des middlewares. Pour des architectures moddés ou multi‑version, la manière dont chaque proxy gère les paquets et les headers de forwarding devra être vérifiée dans la documentation et par des tests en environnement contrôlé.

Ce comparatif n’affirme pas la supériorité d’un système sur l’autre pour les réseaux moddés ; il renvoie à la documentation officielle et aux retours communautaires pour évaluer la compatibilité avec des modpacks ou des middlewares spécifiques.

Expérience d’administration et documentation

PaperMC fournit une documentation détaillée expliquant les objectifs et certaines procédures autour de Velocity. SpigotMC conserve la documentation historique de BungeeCord. La qualité perçue de la documentation varie selon les besoins : certains administrateurs trouvent la documentation PaperMC orientée vers des usages modernes, d’autres préfèrent la richesse historique des ressources et des tutoriels existants pour BungeeCord.

Pour une migration, la disponibilité de guides, de retours d’expérience et d’outils communautaires influe sur la facilité de passage d’une solution à l’autre.

Cas particuliers : Geyser, proxies en chaîne, migration Bungee→Velocity

Des cas d’usage spéciaux—comme l’intégration de Geyser pour Bedrock, l’empilement de proxies ou la migration d’un parc existant—sont abordés dans des guides et retours d’expérience. La documentation officielle et les articles techniques cités décrivent des méthodes et des limitations rencontrées publiquement par des administrateurs. Chaque cas demande une vérification des plugins et des adaptations nécessaires avant toute migration.

Tableau synthétique

Verdict par usage

Plutôt BungeeCord — vous avez un parc de plugins legacy développé pour BungeeCord et vous dépendez d’extensions non portées. La base historique et l’écosystème documentaire facilitent la maintenance sans porter ou remplacer massivement des plugins.

Plutôt Velocity — vous construisez un réseau moderne et souhaitez une architecture pensée pour des APIs récentes et des objectifs de performance documentés par PaperMC. Velocity est présenté comme adapté aux besoins actuels des grands réseaux.

Plutôt BungeeCord (petit réseau) — pour un petit réseau de 50 joueurs qui mise sur la simplicité et sur des plugins éprouvés, l’écosystème BungeeCord peut suffire et limiter le travail de migration.

Plutôt Velocity (réseau compétitif) — pour un réseau compétitif avec exigences de sécurité et d’optimisation, les arguments avancés dans la documentation PaperMC et dans plusieurs guides techniques orientent vers Velocity, sous réserve de tester la compatibilité des plugins.

Plutôt BungeeCord ou Velocity selon la compatibilité modded/multi‑version — si le réseau repose sur des modpacks ou sur des middlewares spécifiques, choisir selon la prise en charge effective documentée des composants que vous utilisez.

Comment migrer (repères)

• Faire une sauvegarde complète du réseau et tester en environnement de staging avant tout changement.
• Vérifier la compatibilité des plugins avec la cible : lister les plugins essentiels et rechercher leur état de portage ou d’adaptation documenté publiquement.
• Consulter la documentation officielle indiquée pour les paramètres de forwarding et les recommandations de configuration.
• Planifier une fenêtre de tests pour valider le comportement des sessions, des permissions et des systèmes tiers (authentification, mesures, monitoring).

Liens utiles / documentation officielle (consulté le 04/09/2026)

• Velocity (GitHub) — https://github.com/Na1A1/velocity-proxy
• PaperMC — Pourquoi Velocity / documentation — https://docs.papermc.io/velocity/why-velocity/
• PaperMC — Comparaisons aux autres proxies — https://docs.papermc.io/velocity/comparisons-to-other-proxies/
• SpigotMC — BungeeCord page officielle — https://www.spigotmc.org/wiki/bungeecord/
• Arvoris guide « Velocity vs BungeeCord (2026) » — https://arvor.is/guides/velocity-vs-bungeecord
• MineGuard article « Velocity vs BungeeCord: why switch » — https://mineguard.pro/en/blog/velocity-vs-bungeecord-why-switch
• Comparatif / hébergeur (guide) — https://mc-node.net/blog/en/velocity-vs-bungeecord-server-network/
• Exemples vidéos explicatives — https://www.youtube.com/watch?v=bDJFF0em2FE
• Discussions communautaires / retours d’expérience (r/adminecraft) — https://www.reddit.com/r/admincraft/