Si vous mettez en place un serveur FiveM roleplay, la première grande décision que vous prendrez concerne votre framework. ESX, QBCore et QBox dominent la scène FiveM — chacun a ses forces, ses compromis et ses cas d'usage idéaux.
Ce comparatif analyse les trois frameworks en toute transparence. Nous vendons des scripts compatibles avec tous, donc nous n'avons pas de parti pris — nous voulons simplement vous aider à choisir la bonne fondation pour votre projet.
Si vous débutez sur FiveM, nous vous recommandons de lire d'abord Comment créer un serveur FiveM.
Table des matières
- Qu'est-ce qu'un framework FiveM ?
- Tableau comparatif rapide
- ESX (Extended) — le vétéran
- QBCore — le standard moderne du RP
- QBox — le fork axe performance
- Comparaison fonctionnalité par fonctionnalité
- Quel framework choisir ?
- Questions courantes sur le changement de framework
- FAQ
Qu'est-ce qu'un framework FiveM ?
Un framework est la couche fondatrice de votre serveur FiveM. Il gère :
- Les comptes joueurs et la persistance (personnages, identifiants, métadonnées)
- Les systèmes monétaires (espèces, banque, argent sale)
- Les métiers et gangs (police, mécanicien, ambulancier, etc.)
- L'inventaire et les objets
- La propriété des véhicules
- Le logement/les garages
- La logique de mort et de réapparition
Tableau comparatif rapide
| Fonctionnalité | ESX | QBCore | QBox |
|---|---|---|---|
| Première version | 2018 | 2021 | 2023 |
| Licence | GPL-3 | GPL-3 | GPL-3 |
| Maintenance active | ✅ Active | ✅ Très active | ✅ Très active |
| Écosystème de scripts | ⭐ Massif | ⭐ Large | ⭐ Large (compatible QBCore) |
| Qualité du code | ⚠️ Dette héritée | ✅ Moderne | ✅ Très moderne |
| Performance | ⚠️ Variable | ✅ Bonne | ⭐ Excellente |
| Documentation | ✅ Complète | ✅ Complète | ⚠️ En croissance |
| Accessibilite débutant | ⭐ Facile | ✅ Modéré | ⚠️ Modere-Difficile |
| Utilise par les grands serveurs RP | ✅ Beaucoup | ⭐ La majorité | ⚠️ En croissance |
| Taille de la communauté (2026) | Large | ⭐ La plus large en activité | Plus petite mais engagée |
ESX (Extended) — le vétéran
ESX est le plus ancien et historiquement le plus populaire des frameworks FiveM. Lance en 2018 comme un fork de l'original ES (EssentialMode), il a propulsé des milliers de serveurs RP FiveM au fil des années.Pourquoi ESX reste pertinent en 2026
Écosystème de scripts massif. ESX possède le plus grand catalogue de scripts communautaires de tous les frameworks. Scripts open-source sur GitHub, scripts payants sur Tebex, ressources personnalisées de serveurs disparus — la majeure partie de l'histoire de FiveM a été écrite sous ESX. Si vous cherchez "un script qui fait X", il y a de fortes chances qu'une version ESX existe. Facile de trouver des tutoriels. Cherchez "FiveM roleplay tutorial" sur YouTube et 80 % des résultats seront bases sur ESX. La courbe d'apprentissage est plus douce que pour les alternatives. Connu de la plupart des développeurs. Si vous engagez un développeur FiveM en freelance, il connaît presque certainement ESX.Les inconvénients d'ESX
Dette technique accumulée. ESX a été patche et enrichi pendant plus de 6 ans. Certaines parties du code de base montrent leur age. Les performances peuvent varier considérablement d'une configuration serveur a l'autre. Versions fragmentées. "ESX" désigne aujourd'hui généralement ESX Legacy (la version maintenue), mais il existe aussi des forks : ESX 1.x, ESX V1 Final, etc. Choisissez ESX Legacy — tout le reste est abandonne. Les scripts nécessitent souvent une optimisation. De nombreuses ressources ESX de 2018-2020 ont été écrites avant que l'optimisation via resmon ne devienne une priorité communautaire. Prévoyez d'optimiser ou de remplacer les scripts anciens.Idéal pour
- Les débutants absolus qui veulent un maximum de tutoriels et de support communautaire
- Les serveurs privilégiant la variété de scripts plutôt que la modernité du code
- Les communautés migrant depuis d'anciens serveurs ESX qui connaissent déjà le framework
Ressources ESX
- Documentation : docs.esx-framework.org
- GitHub : github.com/esx-framework/esx-legacy
- Ressources principales :
esx_addonaccount,esx_addoninventory,esx_property,esx_society
QBCore — le standard moderne du RP
QBCore à emerge en 2021 comme une alternative propre et moderne à ESX. Construit de zéro avec une meilleure architecture, il est rapidement devenu le choix de référence pour les nouveaux serveurs RP.Pourquoi QBCore domine en 2026
Meilleure architecture du code. QBCore a été conçu avec la modularité en tete. Systèmes de métiers, inventaire, métadonnées — tout est séparé de manière plus propre que sous ESX. Communauté active massive. QBCore à dépasse ESX en termes de contributions communautaires actives. Les nouveaux scripts sortent d'abord pour QBCore, puis sont parfois retroportes vers ESX. Composants UI soignes. Les HUD, téléphones et designs d'inventaire modernes sont de plus en plus conçus d'abord pour QBCore. Les refontes majeures d'interface (comme le passage deqb-inventory à ox_inventory) sortent pour QBCore.
Meilleur système de métadonnées. Le système de métadonnées joueur de QBCore facilite grandement l'ajout de statistiques, attributs ou progressions personnalises sans toucher au schéma de la base de données.
Les inconvénients de QBCore
Moins de variété de scripts qu'ESX (en volume brut). Si QBCore à plus de nouveaux scripts, ESX en à davantage au total grâce a ses 5 ans d'avance. Courbe d'apprentissage légèrement plus raide. L'architecture plus propre implique que les nouveaux venus ont plus de concepts à assimiler : métadonnées, state bags, séparation shared/server/client. Certains systèmes de base sont opiniatres. QBCore fait des choix spécifiques (par exemple, son système de métiers, son flux de création de personnage) qui ne correspondent pas forcement à votre vision. Prévoyez de redéfinir certains modules de base.Idéal pour
- Les communautés RP sérieuses qui construisent de zéro en 2026
- Les propriétaires de serveurs qui veulent un code moderne et maintenable
- Les communautés qui prévoient d'écrire ou de modifier des scripts personnalisés
Ressources QBCore
- Documentation : docs.qbcore.org
- GitHub : github.com/qbcore-framework
- Ressources principales :
qb-core,qb-inventory,qb-phone,qb-management,ox_lib
QBox — le fork axe performance
QBox (parfois appele QBX) est un fork de QBCore datant de 2023, centre sur la performance et la modularité. Maintenu par d'anciens contributeurs de QBCore, il vise à corriger les problèmes architecturaux tout en restant largement compatible avec les ressources QBCore.Pourquoi QBox gagne du terrain
Meilleures performances dès le départ. QBox exploite les fonctionnalités natives de FiveM (state bags,ox_lib, oxmysql) de manière plus agressive que QBCore. Résultat : resmon plus bas, empreinte mémoire réduite, moins de boucles de tick.
Noyau plus propre. QBox à supprime les patterns de code hérites de QBCore. Le code source est plus petit, plus lisible et plus facile à étendre.
Compatible avec la plupart des scripts QBCore. C'est l'atout majeur. La majorité des scripts QBCore fonctionnent sur QBox avec des modifications minimales. Vous héritez de tout l'écosystème QBCore.
Développement actif. QBox avance vite. De nouvelles fonctionnalités arrivent chaque mois, et l'équipe de développement est réactive aux retours de la communauté.
Les inconvénients de QBox
Communauté plus petite (pour l'instant). QBox est plus jeune. Le Discord est plus petit, il existe moins de tutoriels, moins de contenu sur Stack Overflow. Vous devrez peut-être lire le code source plus souvent. Certains scripts QBCore nécessitent des adaptations. Si la majorité fonctionne, un pourcentage de ressources QBCore ont des chemins codes en dur ou des présupposes qui cassent sur QBox. Prévoyez un debugging occasionnel. Documentation encore en maturation. La doc de QBox est bonne mais moins exhaustive que celle de QBCore. Certaines fonctionnalités sont principalement documentées dans le code source.Idéal pour
- Les propriétaires de serveurs à l'aise avec le code source et prêts à s'y plonger
- Les serveurs critiques en performance qui tournent près de leur capacité maximale
- Les propriétaires de serveurs qui construisent des frameworks personnalises sur les patterns QBCore
Ressources QBox
- Documentation : qbox.re
- GitHub : github.com/Qbox-project
- Ressources principales :
qbx_core,qbx_management,ox_inventory,ox_lib
Comparaison fonctionnalité par fonctionnalité
Système d'inventaire
- ESX : livre avec
esx_inventory, souvent remplace parox_inventory. Correct par défaut, très remplacable. - QBCore : livre avec
qb-inventory. La plupart des serveurs le remplacent parox_inventorypour la performance. - QBox : livre avec
ox_inventoryintégré. Meilleure expérience d'inventaire par défaut.
ox_inventory pour une utilisation sérieuse.
Système de métiers
- ESX : système society classique. Fonctionnel, interface datée.
- QBCore :
qb-managementfournit des panneaux de metiers/gangs. Plus moderne. - QBox :
qbx_managementest encore plus propre.
Intégration téléphone
- ESX : n'importe quel téléphone fonctionne (
gks-phone,lb-phone,qs-smartphone). Pas de téléphone "officiel". - QBCore :
qb-phoneest l'option officielle, mais la plupart des serveurs utilisentlb-phoneouqs-smartphonepour le rendu. - QBox : comme QBCore — choisissez votre téléphone.
Système vocal
- ESX, QBCore, QBox : les trois utilisent couramment
pma-voice. Agnostique du framework.
Schéma de base de données
- ESX : schéma ancien, avec plusieurs tables héritées (
addon_account,addon_inventory_items). - QBCore : schéma plus propre avec une table
playerscontenant la majorité des données. - QBox : très similaire à QBCore, légèrement plus normalise.
Performance
Benchmark sur le même serveur RP 32 slots avec des scripts comparables :
| Framework | Tick serveur moyen (repos) | Tick serveur moyen (plein) |
|---|---|---|
| ESX Legacy | 2.8ms | 8.5ms |
| QBCore | 1.9ms | 6.2ms |
| QBox | 1.4ms | 4.8ms |
Compatibilité des scripts
- ESX : le plus grand catalogue de scripts, mais beaucoup vieillissent.
- QBCore : large catalogue moderne. La plupart des nouveaux scripts ciblent QBCore en premier.
- QBox : hérite d'environ 85 % du catalogue QBCore avec des adaptations mineures.
Quel framework choisir ?
Il n'existe pas de framework universellement "meilleur". Choisissez en fonction de votre situation :
Choisissez ESX si...
- Vous êtes un débutant absolu et voulez un maximum de tutoriels
- Vous héritez d'un serveur ESX existant
- Vous privilégiez la variété de scripts plutôt que la modernité du code
- Vous avez un développeur à l'aise avec les patterns ESX
Choisissez QBCore si...
- Vous construisez un serveur RP sérieux de zéro
- Vous voulez la plus grande communauté active
- Vous prévoyez d'installer de nombreux scripts communautaires
- Vous voulez un code moderne avec une stabilité eprouvee
Choisissez QBox si...
- La performance est critique pour votre serveur
- Vous êtes à l'aise pour lire le code source quand il faut trouver des solutions
- Vous partez de zéro et voulez la fondation la plus moderne
- Une communauté plus petite (mais engagée) ne vous dérange pas
Choisissez Standalone si...
- Vous ne construisez pas un serveur RP traditionnel
- Vous faites tourner des mini-jeux, du drift, du DM, des courses ou d'autres modes de jeu
- Vous voulez un contrôle maximal sans les présupposes d'un framework
Une approche agnostique du framework
Chez HZ-Scripts, nous concevons délibérément nos ressources pour être agnostiques du framework. Chaque HZ-Script détecté automatiquement si votre serveur tourne sous ESX, QBCore, QBox ou Standalone, et s'adapte en conséquence.
Cela signifie :
- Vous pouvez changer de framework par la suite sans racheter nos scripts
- Vous pouvez faire tourner plusieurs serveurs de test sur différents frameworks avec le même catalogue de scripts
- Vous évitez le verrouillage fournisseur sur les scripts individuels
- HZ-Weather — fonctionne sur ESX, QBCore, QBox, Standalone. Détection automatique, aucune configuration nécessaire.
- hz_television — idem. Plug-and-play sur tous les frameworks.
- hz_audiomixer — entièrement standalone, aucune dépendance framework.
Questions courantes sur le changement de framework
Peut-on migrer d'ESX vers QBCore par la suite ?
Oui, mais c'est un travail conséquent. Prévoyez :
- Migration de base de données — mapper la table
usersversplayers, transférer inventaires, métiers, argent - Remplacement de scripts — la plupart des scripts ESX ne fonctionneront pas sur QBCore. Trouvez les équivalents QBCore.
- Preservation des données joueurs — gérez les personnages existants avec précaution (ou acceptez la perte de données)
- Délai — 2 à 4 semaines de travail dédié pour un serveur moyen, souvent plus
esx-to-qbcore-converter) mais aucun n'est clé en main.
Peut-on faire tourner deux frameworks sur le même serveur ?
Pas vraiment. S'il est techniquement possible de charger à la fois es_extended et qb-core, vous aurez des conflits constants sur les identifiants joueurs, les systèmes monétaires et les noms d'événements. Choisissez-en un seul.
Mon framework risque-t-il de disparaître ?
Peu probable pour ESX, QBCore ou QBox. Les trois sont activement maintenus avec des communautés solides. Le risque est plus élevé avec des forks plus petits (anciennes versions ESX, alternatives moins populaires). Restez sur l'un des trois grands pour la sécurité.
Peut-on écrire son propre framework ?
Oui, et certains grands serveurs le font. NoPixel fonctionne sur un framework maison fortement personnalise. Mais partir de zéro demande une expertise significative en Lua et 6 à 12 mois de travail avant d'atteindre la parité fonctionnelle avec QBCore. Ne faites pas cela sauf raison spécifique — commencez avec QBCore ou QBox, puis personnalisez progressivement.
Et ensuite ?
Maintenant que vous avez choisi (ou que vous penchez vers) un framework :
- Configurez correctement votre serveur — Guide complet pour créer un serveur FiveM
- Maîtrisez votre panneau de gestion — Guide de configuration txAdmin
- Choisissez vos premiers scripts — Premiers scripts à installer sur votre serveur FiveM
Le choix du framework n'est pas une question de vie ou de mort — la plupart des serveurs à succès tournent sur l'un des trois. Ce qui compte davantage, c'est la cohérence : choisissez-en un, apprenez-le bien, et construisez votre communauté sur une fondation stable.
FAQ
Consultez la FAQ ci-dessus pour chaque section, ou accédez à nos autres guides pour des approfondissements sur des sujets spécifiques.