{"id":159060,"date":"2024-09-28T13:32:40","date_gmt":"2024-09-28T11:32:40","guid":{"rendered":"https:\/\/hifivem.com\/?p=159060"},"modified":"2026-08-15T19:30:00","modified_gmt":"2026-08-15T17:30:00","slug":"utilisation-simultanee-desx-qbcore","status":"publish","type":"post","link":"https:\/\/rpcrate.com\/fr\/simultaneous-use-esx-qbcore\/","title":{"rendered":"Utilisation simultan\u00e9e d'ESX et de QBCore : pourquoi ce n'est pas faisable"},"content":{"rendered":"

R\u00e9ponse directe :<\/strong> N\u2019ex\u00e9cutez pas ESX et QBCore comme deux c\u0153urs faisant autorit\u00e9 pour les m\u00eames joueurs. Les deux peuvent techniquement d\u00e9marrer comme ressources FiveM, mais ils mod\u00e9lisent diff\u00e9remment l'identit\u00e9, les m\u00e9tiers, l'argent, l'inventaire, les callbacks et les \u00e9v\u00e9nements. Sans un pont con\u00e7u \u00e0 cet effet et une source de v\u00e9rit\u00e9 d\u00e9clar\u00e9e, l'\u00e9tat dupliqu\u00e9 devient dangereux et difficile \u00e0 r\u00e9cup\u00e9rer.<\/p>\n

Pourquoi deux c\u0153urs entrent en conflit<\/h2>\n
\n\n\n\n\n\n\n\n\n\n
Domaine<\/th>\nRisque avec deux autorit\u00e9s<\/th>\nContr\u00f4le requis<\/th>\n<\/tr>\n<\/thead>\n
Identit\u00e9<\/th>\nUn joueur peut recevoir des enregistrements ESX et QBCore non li\u00e9s.<\/td>\nUne identit\u00e9 canonique et un mappage explicite.<\/td>\n<\/tr>\n
Argent et m\u00e9tiers<\/th>\nLes mises \u00e0 jour peuvent diverger ou \u00eatre appliqu\u00e9es deux fois.<\/td>\nUn seul syst\u00e8me responsable des \u00e9critures et des r\u00e8gles de conversion test\u00e9es.<\/td>\n<\/tr>\n
Inventaire<\/th>\nLes \u00e9l\u00e9ments, les m\u00e9tadonn\u00e9es et la s\u00e9mantique de stockage diff\u00e8rent.<\/td>\nUne seule autorit\u00e9 d'inventaire ; des adaptateurs \u00e0 la fronti\u00e8re.<\/td>\n<\/tr>\n
\u00c9v\u00e9nements et rappels<\/th>\nDes actions de jeu similaires peuvent d\u00e9clencher des gestionnaires de framework non li\u00e9s.<\/td>\nDes adaptateurs v\u00e9rifi\u00e9s avec des espaces de noms distincts plut\u00f4t qu\u2019une r\u00e9plication globale.<\/td>\n<\/tr>\n
D\u00e9pendances<\/th>\nUne ressource peut d\u00e9tecter le mauvais c\u0153ur ou utiliser une API non prise en charge.<\/td>\nTests de d\u00e9pendance et d'ordre de d\u00e9marrage exacts.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Ce qui est r\u00e9alisable<\/h2>\n

Un serveur peut ex\u00e9cuter un adaptateur de compatibilit\u00e9 pour une ressource sp\u00e9cifique lorsque l'adaptateur a un contrat \u00e9troit et qu'un framework reste faisant autorit\u00e9. Qbox, par exemple, documente un pont QB et ses limites. C'est diff\u00e9rent de l'ex\u00e9cution de deux \u00e9conomies et mod\u00e8les de joueurs complets c\u00f4te \u00e0 c\u00f4te.<\/p>\n

Liste de contr\u00f4le des d\u00e9cisions<\/h2>\n
    \n
  1. Nommez le c\u0153ur faisant autorit\u00e9 pour l'identit\u00e9, les m\u00e9tiers, l'argent et l'inventaire.<\/li>\n
  2. Listez les ressources h\u00e9rit\u00e9es pr\u00e9cises qui bloquent la migration.<\/li>\n
  3. Privil\u00e9giez le remplacement ou le portage de chaque ressource ; utilisez un pont uniquement si son contrat est document\u00e9 et testable.<\/li>\n
  4. Testez les appels non autoris\u00e9s, les reconnexions, les red\u00e9marrages et les d\u00e9faillances partielles des d\u00e9pendances.<\/li>\n
  5. Si les deux c\u0153urs doivent \u00e9crire dans le m\u00eame domaine, arr\u00eatez-vous et revoyez la conception avant la mise en production.<\/li>\n<\/ol>\n

    Port\u00e9e et limites<\/h2>\n

    Il n'y a pas de r\u00e9ponse universelle pour chaque fork ou adaptateur personnalis\u00e9. Un pont soigneusement con\u00e7u peut traduire une surface API limit\u00e9e, mais il doit pr\u00e9ciser les responsabilit\u00e9s sur les donn\u00e9es, le comportement en cas d'\u00e9chec et les r\u00e8gles de persistance. N'interpr\u00e9tez pas \u201ccompatible QB\u201d comme une preuve de compatibilit\u00e9 QBCore compl\u00e8te sur un autre framework.<\/p>\n

    Sources primaires<\/h2>\n