ESX, QBCore ou Qbox : comprendre et choisir

Ton serveur démarre avec les ressources de base (chapitre 01). Il est vide : pas de personnage, pas de métier, pas d'argent, pas d'inventaire. C'est le rôle d'un framework RP. Ce chapitre explique ce qu'est un framework, compare les trois que TeamKit documente, t'aide à choisir, puis montre ce que txAdmin faisait pour toi et comment tu fais pareil sur AMP.

Tu ne choisis qu'une fois. Changer de framework après six mois, c'est refaire le serveur.

1. Un framework RP, c'est quoi #

FiveM ne sait rien du roleplay. Il charge des ressources, synchronise des joueurs, et c'est tout. Un framework RP est un paquet de ressources qui ajoute la couche « ville » :

• Le personnage : création, apparence, plusieurs personnages par joueur, sauvegarde en base de données.
• L'économie : argent liquide, banque, salaires, comptes de société.
• Les métiers : police, ambulance, mécano, avec leurs grades et leurs permissions.
• L'inventaire : objets, poids, coffres, échanges.
• Les API : des fonctions et des événements que tous les autres scripts utilisent (donner de l'argent, vérifier un métier, retirer un objet).

Le dernier point est le vrai enjeu. Un script de concessionnaire ESX appelle des fonctions ESX. Il ne tourne pas sur QBCore sans réécriture. Le framework décide donc du catalogue de scripts que tu pourras installer.

Les trois frameworks comparés ici stockent tout dans une base MariaDB via la ressource oxmysql. Chez TeamKit, ta base est fournie (chapitre 06). Elle doit être en MariaDB, le moteur recommandé par TeamKit pour FiveM, pas en MySQL 8.4 : quatre constructions SQL courantes des packs FiveM échouent sur MySQL 8.4, et ce ne sont pas des bugs des packs.

✅ À retenir

• Un framework = personnage, économie, métiers, inventaire, et surtout une API commune.
• Le framework décide des scripts compatibles. On ne mélange pas.
• Les trois tournent sur oxmysql et MariaDB.

2. L'écosystème ox : le socle commun #

Avant de comparer les frameworks, un mot sur quatre ressources que tu croiseras partout. Elles viennent du projet Overextended, documenté sur https://overextended.dev/docs/resources :

Pourquoi c'est important pour ton choix :

• ESX Legacy (1.9 et plus) et QBCore dépendent de oxmysql, et ox_lib est recommandé pour les deux. L'inventaire et le target restent au choix.
• Qbox est bâti sur les quatre : ox_lib, oxmysql, ox_inventory, ox_target. Ce n'est pas une option, c'est le socle.

Ces quatre ressources lisent des ConVars au démarrage (langue, options d'inventaire). Sur AMP, ces ConVars se placent en tête de Starting Resources, avant le premier ensure. Le chapitre 07 explique pourquoi et le chapitre 05 donne les lignes exactes pour Qbox.

✅ À retenir

• oxmysql, ox_lib, ox_inventory, ox_target : le socle moderne, documenté sur overextended.dev.
• Qbox les impose. ESX et QBCore les acceptent.

3. ESX Legacy #

• Origine : le plus ancien des trois, lancé en 2017 selon https://docs.esx-framework.org/. Le plus répandu en France.
• Structure : une ressource cœur es_extended et des modules esx_* (esx_ambulancejob, esx_policejob, esx_society, esx_vehicleshop…). Le dépôt officiel est https://github.com/esx-framework.
• Version : la lignée actuelle s'appelle « Legacy ». À partir de la 1.9, elle tourne sur ox_lib et oxmysql. Vérifie le numéro exact sur la page des releases du dépôt esx_core.
• Inventaire : au choix. L'inventaire intégré, ou ox_inventory, ou un inventaire tiers.
• Catalogue de scripts : énorme. Des années de scripts gratuits et payants, dont une grosse part en français. Beaucoup sont vieux : un script ESX de 2019 peut demander des adaptations sur ESX Legacy.
• Communauté : la plus grande communauté francophone. Des tutos vidéo en français, des Discords FR actifs. Documentation en anglais sur https://docs.esx-framework.org/, avec un guide d'installation basé sur la recette txAdmin « ESX Legacy » (https://docs.esx-framework.org/en/tutorial/install) : sur TeamKit tu fais l'équivalent à la main, chapitre 03.
• Mises à jour : projet actif. Regarde la date du dernier commit sur https://github.com/esx-framework avant de te décider.

✅ À retenir

• ESX = choix FR, catalogue le plus large, scripts d'âge variable.

4. QBCore #

• Origine : un ancien fork d'ESX devenu un framework à part entière. Très répandu dans le monde anglophone.
• Structure : une ressource cœur qb-core et des modules qb-* (qb-inventory, qb-garages, qb-policejob, qb-multicharacter…). Le dépôt officiel est https://github.com/qbcore-framework. Le fichier SQL de base s'appelle qbcore.sql et se trouve dans le dépôt qb-core.
• Dépendances : oxmysql obligatoire, ox_lib recommandé.
• Inventaire : qb-inventory (documenté sur https://qbcore.org/docs/qbcore-resources/qb-inventory) ou ox_inventory.
• Catalogue de scripts : très large, surtout en anglais. Beaucoup de scripts payants récents visent QBCore en priorité.
• Communauté : immense, anglophone. Des tutos YouTube pour chaque étape. Documentation en anglais sur https://qbcore.org/docs/ (l'ancienne adresse docs.qbcore.org redirige dessus), avec des guides d'installation Windows et Linux.
• Mises à jour : vérifie la date du dernier commit sur https://github.com/qbcore-framework.

✅ À retenir

• QBCore = catalogue anglais, tutos partout, qb-* + qbcore.sql.

5. Qbox #

• Origine : un fork moderne de QBCore, créé le 27 septembre 2022 par une partie de son équipe, selon https://docs.qbox.re/. Le but : corriger les défauts de QBCore tout en restant compatible avec ses scripts.
• Structure : une ressource cœur qbx_core et des modules qbx_*. Le dépôt officiel est https://github.com/Qbox-project.
• Dépendances : ox_lib, oxmysql, ox_inventory. Le manifeste de qbx_core déclare ox_lib et oxmysql en dépendances, et ox_inventory figure dans son README. oxtarget est l'interaction standard de ses ressources `qbx*`. La documentation exige MariaDB (version minimale indiquée sur https://docs.qbox.re/installation).
• Le pont QBCore : le manifeste de qbx_core contient provide 'qb-core'. Autrement dit, qbx_core se présente aux autres scripts comme qb-core. Un « bridge layer » reprend les fonctions documentées de qb-core : selon la FAQ (https://docs.qbox.re/faq), la plupart des scripts QBCore tournent sans modification. Ceux qui tapent directement dans les tables ou dans des fichiers internes de qb-core cassent. Une ConVar set qbx:acknowledge true coupe le message de bienvenue que qbx_core affiche à chaque démarrage ; le pont, lui, s'active avec setr qbx:enableBridge "true" (chapitre 05).
• Inventaire : ox_inventory, point.
• Catalogue de scripts : le catalogue QBCore via le pont, plus les scripts qbx_* et ox natifs.
• Communauté : plus petite, anglophone, exigeante sur la qualité du code. Documentation en anglais sur https://docs.qbox.re/, avec un guide de conversion depuis QBCore (https://docs.qbox.re/converting).
• Mises à jour : projet actif, versions numérotées dans le manifeste de qbx_core. Regarde https://github.com/Qbox-project/qbx_core.

Un point d'attention : Qbox est plus strict. Il refuse des choses que QBCore tolérait. Un serveur Qbox réel de 230 ressources tourne sur ce même AMP TeamKit ; les pièges rencontrés sont détaillés aux chapitres 07 et 08. Deux à connaître dès maintenant : un export s'appelle par le vrai nom de la ressource (qbx_core, pas qb-core), et deux ressources qui font la même chose (deux inventaires) donnent des comportements aléatoires.

✅ À retenir

• Qbox = QBCore modernisé, bâti sur ox, compatible via provide 'qb-core'.
• Plus propre, plus strict, communauté plus petite.

6. Comparatif point par point #

Migration : ce que ça coûte vraiment #

• ESX ↔ QBCore : les tables, les fonctions et les événements diffèrent. Chaque script est à remplacer par son équivalent. Compte une réécriture complète.
• QBCore → Qbox : le pont fait tourner la plupart des scripts. Le guide officiel https://docs.qbox.re/converting liste les étapes. C'est la seule migration « raisonnable » entre les trois.
• Qbox → QBCore : possible, puisque les scripts QBCore tournaient déjà. Tu perds ce qui est spécifique qbx_*.

Fréquence des mises à jour #

Ne te fie pas à ce qu'on raconte sur Discord. Ouvre les trois dépôts, regarde la date du dernier commit et le nombre de releases sur douze mois :

• https://github.com/esx-framework
• https://github.com/qbcore-framework
• https://github.com/Qbox-project

Mises à jour fréquentes = correctifs rapides, mais scripts tiers qui cassent parfois. Peu de mises à jour = l'inverse.

✅ À retenir

• Aucun des trois n'est « meilleur ». Ils visent des serveurs différents.
• Seule migration confortable : QBCore → Qbox.

7. Tableau de décision #

Réponds aux questions dans l'ordre. Arrête-toi à la première qui te correspond.

Trois règles pour trancher un cas limite :

1. Choisis le framework de tes scripts déjà achetés ou de ceux que tu vises.
2. Choisis le framework de la personne qui va t'aider (ton dev, ton Discord de référence).
3. En cas d'égalité, choisis Qbox si tu pars de zéro, ESX si tu vises un public FR sans dev.

Ensuite, va au chapitre correspondant : 03 (ESX), 04 (QBCore) ou 05 (Qbox).

✅ À retenir

• Scripts visés + personne qui aide = ton framework.
• Un seul framework par serveur, décidé une fois.

8. Ce que txAdmin faisait, et comment on fait sans #

Tous les tutos que tu trouveras commencent par txAdmin. Sur TeamKit tu n'as pas txAdmin : AMP le remplace. Voici la correspondance, fonction par fonction, d'après la page officielle https://docs.fivem.net/docs/resources/txAdmin/.

Les recettes (« recipes ») #

txAdmin propose un déploiement par recette : tu choisis « ESX Legacy », « QBox Framework » ou la recette QBCore dans « Popular Recipes », tu donnes les accès à la base, et il télécharge les ressources, importe le SQL et écrit server.cfg.

Sur AMP TeamKit, il n'y a pas de recette. Tu fais les quatre étapes toi-même. Plus long la première fois, mais tu sais ensuite exactement ce qui tourne :

1. Télécharge les archives des ressources depuis les releases GitHub du framework et de ses dépendances (ox_lib, oxmysql, etc.).
2. Dépose chaque dossier par SFTP dans server-data/resources/ (chapitre 01, section 4).
3. Importe le .sql fourni par le framework dans ta base via l'interface web liée sur ton tableau de bord (chapitre 06).
4. Règle Configuration → FiveM → Starting Resources (les ensure dans le bon ordre, précédés des set/setr) et Additional Server Settings (dont la chaîne de connexion à la base).

# Additional Server Settings — la ligne que chaque recette écrivait pour toi
set mysql_connection_string "mysql://UTILISATEUR:MOT_DE_PASSE@HOTE:PORT/BASE?charset=utf8mb4"

Les valeurs viennent de ton tableau de bord teamkit.fr. Les chapitres 03, 04 et 05 donnent la liste complète des ensure pour chaque framework.

Le reste du panel txAdmin #

Le compte admin en jeu #

txAdmin donnait un menu admin au premier connecté. Sur AMP, l'admin en jeu se déclare dans Configuration → FiveM → Access Control Commands :

add_ace group.admin command allow
add_principal identifier.license:XXXX group.admin

La licence XXXX se lit dans Console au moment où tu te connectes, ou dans ton profil Cfx.re. Redémarre l'instance après. Le chapitre de ton framework précise comment lui donner aussi le grade admin côté framework.

✅ À retenir

• Recette txAdmin = télécharger, déposer par SFTP, importer le SQL, régler Starting Resources et Additional Server Settings.
• Chaque bouton txAdmin a son équivalent AMP, sauf la gestion des joueurs : c'est un script de ton framework.

✅ Checklist du chapitre #

• Je sais ce qu'un framework ajoute à FiveM et pourquoi il fixe mon catalogue de scripts.
• Je sais ce que sont oxmysql, ox_lib, ox_inventory et ox_target.
• J'ai choisi entre ESX Legacy, QBCore et Qbox, et je sais pourquoi.
• J'ai regardé la date du dernier commit du dépôt de mon framework.
• J'ai noté la documentation officielle de mon framework.
• Ma base de données TeamKit est en MariaDB, pas en MySQL 8.4.
• Je sais que je remplace la recette txAdmin par : téléchargement, SFTP, import SQL, Starting Resources.
• Je sais où déclarer mon compte admin (Access Control Commands).

❓ Si ça ne marche pas #

Un tuto me dit « ouvre txAdmin dans ton navigateur ». Tu n'as pas txAdmin. Cherche l'étape équivalente dans le tableau de la section 8. Pour la recette : chapitres 03, 04 ou 05.

J'ai trouvé un script génial, mais il est prévu pour un autre framework. Il ne tournera pas tel quel. Cherche son équivalent pour ton framework, ou vérifie s'il annonce un support multi-framework (beaucoup de scripts payants le font). Exception : un script QBCore sur Qbox tourne souvent grâce au pont.

Je veux Qbox mais un script appelle exports['qb-core'] et plante avec « No such export ». Le pont couvre les fonctions documentées de qb-core, pas les autres. Regarde la FAQ https://docs.qbox.re/faq, puis le chapitre 08.

L'import du .sql échoue sur ma base. Si ta base est en MySQL 8.4, quatre constructions courantes des packs échouent. Demande une base MariaDB ou vérifie le moteur sur ton tableau de bord. Détail au chapitre 06.