QBOX vs QBCore : quel framework FiveM choisir ?

Introduction : Pourquoi les cadres sont importants

Votre infrastructure détermine la vitesse de création de fonctionnalités, la stabilité de votre ville et la facilité de son évolutivité. Dans FiveM, QBCore et QBOX sont les deux choix modernes que la plupart des propriétaires évaluent. Tous deux sont performants, mais leurs compromis sont différents : écosystème étendu et architecture moderne axée sur l'Ox. Ce guide explique les différences et propose des conseils pratiques.

TL;DR

Nouveau serveur, pile moderne, écosystème Ox dès le premier jour ? Service QBOX.
Ville existante avec de nombreuses ressources et du personnel originaires de QB qui connaissent QBCore ? Restez sur QBCore (ou migrer par phases).

Parcourez notre contenu de frameworks organisé et nos bibliothèques de scripts :
• Scripts QBOX → https://fivemx.com/qbox-scripts/
• Scripts QBCore → https://fivemx.com/qbcore-scripts/
• Centre des cadres → https://fivemx.com/frameworks

Définitions (sur une ligne chacune)

QBCore: The most popular Lua RP framework for FiveM, with years of community scripts and tutorials. Cœur repo: qbcore‑framework/qb‑core.
QBOX:Un chemin successeur moderne avec une philosophie Ox-first (ox_lib/oxmysql/ox_inventory), plus un pont de compatibilité QB pour exécuter de nombreuses ressources QB avec peu ou pas de changements.

Problème que cet article résout

Choisissez entre QBOX et QBCore sans repenser entièrement votre solution. Nous comparerons les fonctionnalités, les performances, les spécificités de l'écosystème et vous fournirons des listes de contrôle pour la migration en cas de changement.

Qu'est-ce que QBCore ?

Origines. QBCore est né de la communauté et constitue un framework pragmatique et modulaire pour accélérer le développement de serveurs RP. Il définit des conventions pour les joueurs, les jobs, les inventaires, les finances, les rappels, les exportations et les événements courants. Étant plus ancien que QBOX, il bénéficie des avantages suivants : le plus grand catalogue de scripts prêts à l'emploi (gratuit et premium) et le plus de tutoriels sur YouTube/Discord.

Points forts.

Échelle de l'écosystème. Des milliers de ressources étiquetées QB, des téléphones et des emplois aux outils d'administration et aux packs d'interface utilisateur. Créez une ville plus rapidement à partir de composants existants.
Familiarité du développeur. Les développeurs, l'équipe et les membres de la communauté connaissent souvent les exportations et événements de QBCore par cœur. Le dépannage est rapide.
Conventions stables. Les données des citoyens, les rappels, l'état du serveur/joueur et les modèles courants sont bien compris, ce qui réduit les frictions d'intégration.
Couche DB flexible. La plupart des serveurs QBCore modernes fonctionnent oxmysql Aujourd'hui ; les anciennes piles utilisaient ghmatttimysql/mysql-async. Vous pouvez conserver votre base de données et vos scripts tout en les modernisant.

Faiblesses.

Variance héritée. De nombreux scripts QB « classiques » sont antérieurs aux meilleures pratiques d'Ox : qualité de code mitigée et davantage de refactorisation lorsque vous visez une inactivité de 0,00 à 0,01 ms.
Fragmentation de l'interface utilisateur. La dépendance historique à l'égard des interfaces utilisateur/inventaires plus anciens signifie que vous les remplacez ou les adaptez souvent. ox_inventaire et des kits d'interface utilisateur plus récents de toute façon.
Ménage futur. À mesure que les meilleures pratiques évoluent vers les utilitaires Ox/typés, vous refactoriserez progressivement le code de colle ou ajouterez des adaptateurs.

Explorez notre bibliothèque de contenu QB : Scripts QBCore → https://fivemx.com/qbcore-scripts/
Mode d'emploi : Personnaliser les scripts QBCore → https://fivemx.com/how-to-customize-qbcore-scripts

Site Web QBCore

Qu'est-ce que QBOX ?

Positionnement. QBOX adopte le Écosystème du bœuf prêt à l'emploi : ox_lib, oxmysql, et une approche moderne des exportations, des événements et des modules. Il est livré avec un couche de pont qui conserve rétrocompatibilité avec la plupart des ressources QB, vous permettant d'adopter un noyau plus propre sans renoncer à vos scripts préférés.

Caractéristiques principales.

Fondation Ox-first. Des utilitaires cohérents (mathématiques/tableaux/chaînes/dessin) et des modèles modernes favorisent des ressources plus propres et plus rapides.
Pont de compatibilité. De nombreux scripts QB s'exécutent avec des modifications minimes ou nulles, ce qui est utile pour les migrations progressives.
Piles incluses. Les modules multi-personnages, multi-tâches/gangs, files d'attente et autres éléments indispensables sont des modules de première classe plutôt que des modules complémentaires ad hoc.

Avantages.

Valeurs par défaut axées sur la performance. Les modèles basés sur Ox aident à réduire les boucles de sondage et à attirer les appels, en supposant que vous respectiez les meilleures pratiques en matière de ressources.
Posture de sécurité et de qualité. Des conseils clairs pour éviter les modifications de base ; privilégier la configuration aux correctifs. Audits simplifiés.
La pérennité. Conçu pour FiveM 2025+ : Lua 5.4, oxmysql et piles d'interface utilisateur modernes.

Cons.

Écosystème plus petit (pour l'instant). Vous vous appuierez sur le pont de compatibilité ou sur les scripts de port qui s'appuient sur les QB-ismes.
Courbe d’apprentissage de l’équipe. Le personnel habitué aux événements/exportations QBCore devra s'adapter aux idiomes Ox/Qbox.

Centre QBOX → https://fivemx.com/qbox-ox-stack
Scripts QBOX (organisés) → https://fivemx.com/qbox-scripts/

Site Web QBOX

QBOX vs QBCore — Comparaison directe (matrice des fonctionnalités)

Tableau récapitulatif

Zone	QBOX	QBCore	Verdict pratique
Modèles de performance	Ox d'abord, modules allégés, moins de composants obsolètes. Maintenir le processeur inactif à 0,00–0,02 ms est plus facile en suivant les pratiques Ox.	Varie selon l'ancienneté de la ressource ; de nombreux excellents scripts modernes, certains plus anciens, lourds en boucles de ticks.	Pour une ville fraîche qui vise un ralenti ultra-faible, QBOX a l'avantage ; une pile QBCore bien organisée peut l'égaler.
Écosystème et scripts	Catalogue natif plus petit ; s'appuie sur le pont QB-compat + les ressources Ox.	Le plus grand catalogue de scripts et de tutoriels prêts à l'emploi.	Si vous avez besoin de rapidité pour le contenu, QBCore est gagnant aujourd'hui.
Couche de base de données	oxmysql par défaut ; schéma et requêtes généralement de style Ox.	Les serveurs modernes utilisent également oxmysql; les piles héritées peuvent être mysql-async/ghmatti.	Attachez-vous en 2025 si vous êtes déjà sur oxmysql ; la migration n'est nécessaire que si vous êtes toujours sur mysql-async.
Inventaire/interface utilisateur	Ox-aligné (communément ox_inventaire). Interfaces utilisateur propres et extensibles.	Historiquement qb-inventory et de nombreux forks ; de nombreux administrateurs standardisent sur ox_inventaire de toute façon.	Si vous souhaitez des conventions Ox UI, QBOX convient mieux.
Dépendances/outillage	ox_lib, oxmysql, modules intégrés ; exportations/événements cohérents.	qb-core plus de nombreuses ressources qb- ; la qualité varie.	QBOX est plus opiniâtre ; QBCore est plus ouvert.
Personnalisation/DX	Modules pilotés par la configuration, séparation claire ; poussez les développeurs vers des API basées sur l'exportation.	Exportations/événements familiers ; des tonnes d’exemples de code en ligne.	QBCore est plus simple pour les équipes ayant une expérience QB ; QBOX est plus pratique pour les développeurs greenfield/Ox.
Communauté et documentation	Une documentation plus petite mais ciblée et des mainteneurs actifs.	Large communauté, nombreux guides non officiels.	Besoin de réponses rapidement ? QBCore propose davantage de contenu communautaire ; la documentation QBOX s'améliore.
Préparer l'avenir	Construit autour des meilleures pratiques actuelles (Lua 5.4, Ox stack, utilitaires typés).	Toujours en évolution ; de nombreux serveurs se modernisent pièce par pièce.	Léger avantage QBOX pour la propreté à long terme ; QBCore reste viable.
Position de sécurité	Encourage les modifications sans noyau, l'isolation des modules et des flux d'autorisation plus propres.	Cela dépend de ressources spécifiques ; beaucoup sont solides, certaines plus anciennes le sont moins.	Les paramètres par défaut de QBOX réduisent les modifications sujettes aux accidents ; avec QBCore, appliquez les révisions et le linting.
recettes txAdmin	Guide officiel et recettes disponibles ; démarrage rapide.	Des recettes et des modèles testés au combat partout.	Attachez ; choisissez la recette la plus proche de votre pile.
Frictions migratoires	Le pont QB réduit les frictions ; l’alignement Ox minimise les refactorisations futures.	Minimal si vous restez au pays des QB ; migrer plus tard demande des efforts.	Si vous prévoyez Ox partout, lancez QBOX.
Courbe d'apprentissage	Nouveau si votre équipe ne connaît que le QB ; habitudes de bœuf à adopter.	Moins cher pour les administrateurs existants ; la plupart des employés connaissent déjà les flux QB.	Choisissez en fonction des compétences actuelles de votre personnel.

Notes qui comptent dans la pratique

Votre pire ressource dicte la performance. Le choix du framework est utile, mais les plus importants sont l'interface utilisateur, les ressources en streaming et les boucles mal synchronisées. Toujours profiler avec résmon et la police à chaque PR.
L'alignement du bœuf est la tendance. Que vous utilisiez QBOX ou QBCore, passer à oxmysql, ox_lib, et ox_inventaire tend à améliorer la fiabilité et l'expérience du développeur.

Quand choisir QBOX

Prendre QBOX si la plupart de ces affirmations sont vraies :

Vous lancez un nouveau serveur et vous n'avez pas besoin de dizaines de scripts QB hérités uniquement dès le premier jour.
Tu veux Du bœuf partout: ox_lib, oxmysql, ox_inventory, ox_target.
Vous vous souciez de maintenabilité à long terme plus que le nombre maximal de scripts du premier jour.
Votre équipe est à l’aise avec l’adoption de nouveaux modèles et la lecture de documents officiels.

Avantages opérationnels :

Une approche plus propre de configuration plutôt que de correctif réduit le risque de « modifications de base ».
Moins de couches de colle pour obtenir une interface utilisateur/expérience utilisateur moderne.
Il est plus facile de normaliser les pratiques de codage entre les contributeurs.

Commencer: Hub QBOX → https://fivemx.com/qbox-ox-stack • Scripts → https://fivemx.com/qbox-scripts/

Quand choisir QBCore

Choisir QBCore si la plupart sont vrais :

Vous exécutez déjà un QB city avec des joueurs et du personnel en direct formés aux flux QB.
Vous avez besoin couverture maximale de l'écosystème aujourd'hui (téléphones, emplois, interfaces utilisateur, CAO, packs d'administration) avec un portage minimal.
Vous prévoyez de moderniser sur place: adopter oxmysql, remplacer les anciens inventaires/interfaces utilisateur, refactoriser les boucles lourdes et renforcer les autorisations.

Avantages opérationnels :

Embauche et intégration plus rapides : la plupart des candidats connaissent les exportations/événements QB.
Le temps de mise en œuvre est court grâce aux ressources et aux guides existants.

Guides internes utiles:

Catalogue de scripts QBCore → https://fivemx.com/qbcore-scripts/
Mode d'emploi : Personnaliser les scripts QBCore → https://fivemx.com/how-to-customize-qbcore-scripts

Migration : QBCore → QBOX (en toute sécurité, par étapes)

Vous pouvez passer à QBOX sans casser votre serveur si vous le traitez comme une migration de produit : audit → adaptation → double exécution → basculement.

1) Audit pré-migration

Inventaire et interface utilisateur : Listez tout ce qui est lié à l'inventaire QB et aux anciennes interfaces utilisateur. Décidez s'il convient de les adopter. ox_inventaire (recommandé) et un kit d'interface utilisateur cohérent.
Base de données: Confirmez que vous êtes sur oxmysql. Sinon, migrez d'abord : MySQL‑Async → oxmysql guide → https://fivemx.com/mysql-async-to-oxmysql
Identifiants : Standardisez votre modèle d'identifiant (Steam, licence, citizenID, Discord). Cartographiez son stockage et son référencement. Voir : Migration des identifiants SQL → https://fivemx.com/sql-identifiers-migration
Scripts à porter : Étiqueter les ressources par effort : compatible tel quel, nécessite un adaptateur mineur, réécrire/remplacer. Gardez une feuille de calcul en direct.

2) Construire des adaptateurs là où cela est rentable

Utiliser modèles d'adaptateur pour exposer les mêmes exportations/événements attendus par vos scripts existants, tout en appelant en interne les modules QBOX ou les utilitaires Ox. Référence : Conversion des scripts FiveM → https://fivemx.com/converting-fivem-scripts et Modèles d'adaptateur → https://fivemx.com/adapter-patterns
Dans la mesure du possible, privilégiez remplacements d'Ox instantanés (par exemple, les fonctionnalités ox_inventory) sur le calage des anciennes API.

3) Stratégie de migration des données

Joueurs et personnages : Écrire du code SQL idempotent pour mapper/renommer les colonnes et garantir l'existence des clés/index pour les modules QBOX. Conserver un script de restauration.
Articles/boutiques/véhicules : Adaptez les tables à vos nouveaux systèmes d'inventaire/garage. Testez les flux d'achat, de stockage, de dépôt, de boîte à gants, de coffre et de preuves.
Autorisations : Recréez le personnel et les rôles professionnels à l'aide des nouvelles exportations/événements ; vérifiez les portes de commande et les outils d'administration.

4) Double exécution et vérification

Exécutez un ville de mise en scène avec des instantanés de base de données en miroir et des ensembles de ressources de type production.
Valider résmon Au repos et sous charge (points chauds, pics, rapports). Budgétisez des plafonds stricts par ressource et corrigez les valeurs aberrantes avant la mise en service.
Test de fumée : intégration, multi-personnage, logement, véhicules, téléphone, facturation, fabrication, maintien de l'ordre, services médicaux d'urgence, preuves, vols.

5) Découpe et durcissement

Annoncer une fenêtre de maintenance ; migrer les données ; changer de recette ; réamorcer les caches.
Surveillez attentivement les journaux (txAdmin, console serveur, enregistreur Ox). Ajoutez des alertes d'exécution pour les pics d'erreurs.
Planifier un fenêtre de correctif avec vos développeurs en ligne.

Listes de contrôle et guides de migration

Conversion des scripts FiveM → https://fivemx.com/converting-fivem-scripts
MySQL-Async vers oxmysql → https://fivemx.com/mysql-async-to-oxmysql
Migration des identifiants SQL → https://fivemx.com/sql-identifiers-migration
Centre de conversion de cadres → https://fivemx.com/framework-conversion

Recommandations pour 2025

Si vous recommencez à zéro : choisir QBOX pour vous aligner sur les meilleures pratiques d'Ox dès le premier jour. Vous rédigerez des ressources plus propres, minimiserez la dette technologique héritée et continuerez à exécuter de nombreux scripts créés par QB via le pont.

Si vous exploitez une ville QB mature : reste sur QBCore et modernisez-les en place : oxmysql, ox_inventory, budgets de resmon agressifs et normes de révision de code. Planifiez un Pilote QBOX en phase de mise en scène pour quantifier les bénéfices avant tout changement.

Si vous êtes indécis : Prototypez les deux avec des packs de contenu identiques et mesurez : le temps de mise en œuvre, la réactivité au ralenti/en charge et la satisfaction du personnel. Choisissez celui qui réduit vos coûts de changement permanents.

Conclusion et prochaines étapes

Les deux systèmes peuvent gérer une ville de premier plan. La différence réside dans l'importance de l'héritage que vous souhaitez transmettre et dans le degré de standardisation que vous souhaitez pour votre avenir.

Prochaines étapes :