NVHCloud
English
Español
Allemagne
États-Unis
CanadaC'est la première vraie décision quand on monte un serveur roleplay FiveM, et celle qui coûte le plus cher à changer ensuite. ESX et QBCore font globalement la même chose : gérer les joueurs, l'argent, l'inventaire, les métiers et les véhicules. Ils le font différemment, et surtout ils n'ont pas le même écosystème de scripts.
1. À quoi sert un framework
FiveM, seul, ne connaît ni les personnages, ni l'argent, ni les métiers : il ne fournit qu'un serveur de jeu et un système de ressources. Un framework ajoute cette couche commune, sur laquelle tous les scripts viennent se greffer. Le choix compte donc moins pour ce que le framework fait lui-même que pour tout ce qui est écrit pour lui.
2. ESX Legacy
ESX est le plus ancien des deux et, de loin, le plus répandu dans la communauté francophone. C'est la version Legacy qui est maintenue aujourd'hui ; les anciennes versions 1.1 et 1.2 sont abandonnées, et tout tutoriel qui s'y réfère est périmé.
- Ce qui plaît : un nombre considérable de scripts disponibles, gratuits comme payants, et une documentation francophone abondante. Pour un serveur en français, c'est l'écosystème le plus fourni.
- Ce qui coince : une base de code héritée de plusieurs générations, où la qualité varie fortement d'une ressource à l'autre. Les scripts ESX anciens sont souvent mal optimisés.
3. QBCore
QBCore est plus récent, structuré dès le départ de façon plus homogène, et dominant dans la communauté anglophone.
- Ce qui plaît : une architecture plus cohérente, un inventaire et un système de métiers plus modernes dès l'installation, et des ressources souvent mieux écrites.
- Ce qui coince : moins de ressources en français, et une partie de la communauté anglophone s'est déplacée vers d'autres bases récentes, ce qui rend le paysage moins lisible.
4. Le comparatif
| ESX Legacy | QBCore | |
|---|---|---|
| Scripts disponibles | Très nombreux, qualité inégale | Moins nombreux, souvent plus propres |
| Communauté francophone | Dominante | Présente mais minoritaire |
| Prise en main | Beaucoup de tutoriels, dont beaucoup d'obsolètes | Documentation plus claire, surtout en anglais |
| Inventaire fourni | Basique, presque toujours remplacé | Plus complet dès le départ |
| Performances | Dépendent entièrement des scripts installés | Dépendent entièrement des scripts installés |
| Recrutement de développeurs | Plus facile en France | Plus facile à l'international |
Sur les performances, méfiez-vous des affirmations tranchées : aucun des deux n'est intrinsèquement plus rapide. Ce qui fait ramer un serveur roleplay, ce sont les vingt ou trente ressources ajoutées par-dessus, pas le framework lui-même. Un ESX allégé tourne mieux qu'un QBCore surchargé, et l'inverse est tout aussi vrai.
5. Comment trancher
Prenez ESX si
- Votre serveur et votre équipe sont francophones.
- Vous voulez le plus grand choix de scripts existants.
- Vous partez d'un pack ou d'une base déjà construite sous ESX.
- Vous comptez recruter des développeurs en France.
Prenez QBCore si
- Vous partez de zéro et voulez une base plus homogène.
- Votre équipe lit l'anglais sans difficulté.
- Vous préférez un inventaire et des métiers complets dès l'installation.
- Vous visez un public international.
Un critère décisif passe souvent inaperçu : les scripts payants que vous comptez acheter. Faites la liste avant de choisir. Si les trois quarts n'existent que pour l'un des deux, la décision est déjà prise.
6. Et si on veut changer plus tard ?
Soyons clairs : passer d'ESX à QBCore, ou l'inverse, sur un serveur en production, ce n'est pas une migration, c'est une reconstruction. Il faut réécrire ou remplacer chaque script, refaire le schéma de la base de données, et convertir les données des joueurs. Beaucoup de serveurs qui s'y lancent perdent leur population en route.
Prenez donc le temps de tester les deux sur un serveur de développement pendant quelques jours avant d'ouvrir. Une petite offre suffit pour ça, et c'est infiniment moins coûteux qu'un changement six mois plus tard.
7. Ce que ça change côté serveur
Techniquement, presque rien : les deux frameworks demandent une base de données MariaDB, la ressource oxmysql et un serveur correctement dimensionné. Dans les deux cas, prévoyez au minimum 8 Go de mémoire pour un serveur roleplay actif, et davantage dès que les scripts s'accumulent.
Notre générateur de server.cfg produit la configuration de départ pour l'un comme pour l'autre, et le calculateur de dimensionnement estime la mémoire nécessaire selon votre nombre de joueurs. Pour la base de données, voyez aussi sécuriser MariaDB.
À lire ensuite
Serveur FiveM qui ne démarre pas : solutions
Les erreurs de démarrage les plus fréquentes d'un serveur FiveM et leur solution : licence refusée, port occupé, connexion impossible, ressources en échec.
FiveM : quel build d'artefacts choisir ?
Comprendre les artefacts FXServer : build recommandé ou dernier build, comment changer de version sans casser son serveur, et le rôle de…
Installer un serveur FiveM sur un VPS : le guide complet
Guide pas à pas pour installer un serveur FiveM sur un VPS Linux : préparation, artefacts, clé Cfx.re, server.cfg, txAdmin, base MariaDB, service systemd,…
Questions fréquentes
ESX ou QBCore : lequel est le plus performant ?
Ni l'un ni l'autre par nature. Les ralentissements d'un serveur roleplay viennent presque toujours des ressources ajoutées, pas du framework. Un serveur ESX allégé tourne mieux qu'un QBCore chargé de scripts mal écrits, et réciproquement.
Peut-on utiliser des scripts ESX sur QBCore ?
Pas directement : les deux frameworks exposent des fonctions différentes. Certains scripts sont publiés en deux versions, et des ponts de compatibilité existent, mais ils ajoutent de la complexité. Prévoyez d'utiliser des ressources conçues pour votre framework.
Quel framework choisir pour un serveur francophone ?
ESX Legacy dans la plupart des cas : l'écosystème francophone, les scripts et les développeurs disponibles y sont bien plus nombreux. QBCore reste un bon choix si vous partez de zéro et que l'anglais ne vous gêne pas.
Combien de RAM faut-il pour un serveur ESX ou QBCore ?
Comptez environ 6 Go pour le framework et ses ressources de base, avant le premier joueur, puis environ 80 Mo par joueur connecté. Un serveur de 48 places demande donc en pratique 8 à 16 Go selon le nombre de scripts.
Est-il possible de migrer d'ESX vers QBCore ?
Techniquement oui, mais cela revient à reconstruire le serveur : chaque script doit être remplacé, le schéma de base de données refait et les données des joueurs converties. Mieux vaut trancher avant l'ouverture.