Comparatif de frameworks
QBCore vs QBox
C’est le même débat que QBox vs QBCore, posé dans l’autre sens, et il mérite sa propre page parce que l’intention de recherche diffère. Si vous connaissez déjà QBCore et vous demandez si QBox vaut le changement, ce comparatif est écrit pour vous. Mêmes données de fond, angle différent.
QBCore
Framework modulaire d’origine avec une équipe principale active
Découvrir les scripts QBCore →Réponse courte
Verdict
Restez sur QBCore si vous avez un serveur en production, une base de code remplie de scripts personnalisés ou un besoin de script de niche. Passez à QBox si vous partez de zéro, misez tout sur ox_* et voulez le framework le plus épuré. Le reste de cette page explique pourquoi.
Côte à côte
Comparaison point par point
12 critères. La cellule en surbrillance indique l’option qui a l’avantage ; les égalités restent neutres.
| Critère | QBCore | QBox (qbx_core) |
|---|---|---|
| Origine Égalité | Projet d’origine, 2020 | Fork communautaire, 2023 |
| Étendue de l’écosystème | La plus large : catalogue de 2020 à 2026 Avantage | Plus restreinte mais en croissance |
| Resmon au repos | ~0.02ms de base | ~0.01ms de base Avantage |
| Temps de démarrage | Standard | Plus rapide (moins de couches de compatibilité) Avantage |
| Liberté d’inventaire | qb-inventory / ox_inventory, au choix Avantage | ox_inventory obligatoire |
| Liberté de menus | qb-menu / ox_lib Avantage | ox_lib obligatoire |
| Liberté de target | qb-target / ox_target Avantage | ox_target obligatoire |
| Nouveaux scripts (2025-2026) | La plupart visent QBCore en premier Avantage | Beaucoup via la compatibilité QBCore, certains natifs |
| Build FiveM visé | 1868+ Avantage | 2802+ |
| Effort de migration | Sans objet (référence) Avantage | 1 à 3 jours pour un serveur moyen |
| Orientation à long terme Égalité | Stable, progressive | Résolument moderne |
| Support communautaire | La plus grande communauté FiveM en nombre de membres Discord Avantage | Ciblée, plus petite, plus soudée |
Choisir
Lequel choisir et quand
Choisir QBCore
- Vous faites déjà tourner un serveur QBCore
Le coût de la migration dépasse son bénéfice dans presque tous les cas. Rester sur QBCore est généralement le bon choix pour un serveur existant.
- Vous voulez choisir librement inventaire, menus et target
QBCore vous laisse choisir entre l’ancien système et ox_* pour chaque composant. QBox vous impose ox_* : parfait si c’est ce que vous voulez, pénible sinon.
- Il vous faut le plus grand catalogue de scripts aujourd’hui
QBCore compte plus de scripts en valeur absolue et davantage de nouveautés le visent en premier. Rien ne vaut la profondeur du catalogue quand vous faites vos achats.
- Vous visez une compatibilité de builds FiveM plus large
QBCore prend en charge le build FiveM 1868 et supérieurs. QBox abandonne tout ce qui est inférieur au 2802. Si vos joueurs utilisent des builds variés, QBCore garde tout le monde en ligne.
Choisir QBox (qbx_core)
- Vous partez de zéro, sans scripts hérités
QBox est plus propre pour un serveur créé de toutes pièces. Vous évitez complètement l’étape de migration de QBCore vers QBox.
- Vous misez de toute façon sur la stack ox_*
Si ox_inventory, ox_lib et ox_target sont déjà ce que vous voulez, le modèle de dépendances obligatoires de QBox est un atout, pas une limite.
- Le resmon minimal et le temps de démarrage comptent pour vous
QBox démarre plus vite et consomme un poil moins au repos, car il supprime les couches de compatibilité que QBCore conserve pour la rétrocompatibilité.
- Vous voulez écrire de nouveaux scripts sur une API propre
L’API de QBox est plus réduite et plus cohérente, car elle a moins d’héritage à prendre en charge. Plus agréable pour les auteurs de scripts.
Bon à savoir
FAQ QBCore vs QBox
Dois-je passer de QBCore à QBox ?
QBox prend-il en charge tous les scripts QBCore ?
ox_* : une modification généralement mineure, mais obligatoire.