Les scripts FiveM essentiels pour un nouveau serveur : une checklist

Construisez un nouveau serveur FiveM en respectant l'ordre des dépendances. Installez d'abord la base de données et le framework, puis l'inventaire et les personnages, ensuite les systèmes qui en dépendent comme les véhicules, les métiers, la police et les téléphones. Testez le framework, les dépendances et l'édition de chaque système sur un serveur de staging avant d'ajouter le suivant.

Mention de transparence : RPScripts vend des ressources FiveM, et les liens de catégories ci-dessous renvoient vers son propre catalogue. Ils indiquent où parcourir un type de ressource, et non une recommandation de produit. La checklist s'appuie sur la documentation des frameworks et de Cfx.re liée à chaque étape, consultée le 13 octobre 2026. Il s'agit d'une revue de documentation, pas d'un test en conditions réelles : RPScripts n'a ni installé ni exécuté les ressources citées ici pour cet article. Le framework que vous utilisez détermine la plupart des réponses ; commencez donc par trancher avec comparatif des frameworks FiveM.

Décidez de trois choses avant d'installer quoi que ce soit

1. Framework. ESX Legacy, QBCore ou Qbox. Chaque ressource que vous achetez doit prendre en charge celui que vous choisissez. Voir comparatif des frameworks FiveM.
2. Édition du jeu. La page Cfx.re Legacy vs Enhanced indique que la voix Mumble est dépréciée sur Enhanced et que l'Asset Escrow n'y est pas encore implémenté. Une ressource qui fonctionne sur Legacy n'est pas pour autant prouvée sur Enhanced.
3. Propriété des données. Pour chaque système ci-dessous, sachez quelle ressource stocke les données (objets d'inventaire, clés, argent, logements) et assurez-vous qu'une seule ressource en soit propriétaire. Deux ressources qui écrivent les mêmes données peuvent provoquer des objets dupliqués ou perdus.

L'ordre d'installation

L'ordre ci-dessous est une suggestion éditoriale, pas une règle de Cfx.re ; les maps et les téléphones en particulier peuvent devoir passer plus tôt si une ressource de métier ou de logement les attend.

1. Clé de licence Cfx.re et recipe txAdmin pour votre framework : ESX, QBCore ou Qbox.
2. Base de données et oxmysql, démarrés avant tout ce qui utilise la base de données.
3. Noyau du framework et ses bibliothèques partagées comme ox_lib.
4. Inventaire, puis personnages et apparition (spawn).
5. HUD, véhicules, logements, métiers et économie.
6. Police, dispatch et médical, qui dépendent des métiers, de l'inventaire et des véhicules.
7. Outils d'administration, voix, téléphone, écran de chargement et maps.

La référence du manifeste de ressource de Cfx.re documente dependency comme exigeant que la ressource nommée soit chargée avant la ressource courante. Utilisez le manifeste et la documentation de chaque ressource pour confirmer son propre ordre. Par exemple, la page ESX d'Overextended liste oxmysql, ox_lib, es_extended et qtarget avant ox_inventory, tandis que la page Qbox indique de démarrer ox_inventory immédiatement après qbx_core.

La checklist, système par système

1. Noyau du framework et recipe

À faire : fournir les données des joueurs et des personnages, les métiers, l'argent et l'API que les autres ressources appellent. À décider : utiliser le recipe officiel plutôt que copier un seul dossier de noyau. À vérifier : la version du recipe et ce qu'il installe déjà, afin de ne pas ajouter de doublon.

2. Base de données et oxmysql

À faire : stocker tout ce qui est persistant. À décider : le serveur de base de données et sa version. La documentation de Qbox exige MariaDB 10.9.0 ou plus récent et indique que MySQL n'est pas pris en charge ; celle d'oxmysql recommande vivement MariaDB, car de nombreuses ressources écrites pour MySQL 5.7 peuvent cesser de fonctionner sous MySQL 8. À vérifier : qu'oxmysql démarre en premier et que la chaîne de connexion est définie avec set mysql_connection_string avant le démarrage des ressources (documentation d'oxmysql). Des ressources plus anciennes peuvent encore appeler mysql-async ; voir migrer les ressources mysql-async. Il s'agit d'infrastructure, il n'y a donc pas de catégorie boutique correspondante.

3. Inventaire

À faire : gérer les objets, les armes, les coffres (stashes) et les métadonnées. À décider : l'inventaire que toutes les autres ressources vont appeler. ox_inventory requiert oxmysql et ox_lib ; son paramètre de framework liste ox, esx, qbx et nd. Sur ESX, il remplace entièrement les systèmes d'objets, d'inventaire et d'armes, et la page ESX liste les boutiques et coffres standards (esx_shops, esx_weaponshop, esx_policejob) comme incompatibles. QBCore documente qb-inventory. À vérifier : que chaque script de boutique, de craft et de métier prend en charge votre inventaire. Catalogue : scripts d'inventaire. Pour aller plus loin : compatibilité des inventaires.

4. Multipersonnage et spawn

À faire : sélection et création de personnage, et premier spawn. ESX fournit esx_multicharacter comme système par défaut, avec quatre emplacements par défaut et une commande /relog (documentation). QBCore documente qb-multicharacter, y compris une option d'appartement de départ et un spawn par défaut (documentation). À décider : le nombre d'emplacements et si les joueurs peuvent supprimer leurs personnages. À vérifier : comment le remplaçant stocke les identifiants de personnage, et s'il attend vos ressources de logement et de spawn. Catalogue : scripts multipersonnage.

5. HUD

À faire : afficher les données d'état fournies par le framework. Les PlayerData de QBCore incluent hunger, thirst et stress dans metadata, et les HUD lisent ces valeurs. À décider : garder une seule source d'état ; deux systèmes de besoins se disputent les valeurs. À vérifier : le framework, la ressource d'état ou de besoins, ainsi que les intégrations carburant et voix indiquées dans la description. Guide pratique : installer et tester un HUD.

6. Véhicules, garage, clés et carburant

À faire : vendre, ranger, verrouiller, ravitailler et récupérer les véhicules. qb-vehiclekeys documente le verrouillage, le crochetage et le car-jacking, mais sa page ne liste aucun export ; un remplaçant demande donc de vérifier le contrat dans le code source. À décider : exactement une ressource pour les clés, une pour les garages, une pour le carburant. À vérifier : quelle ressource détient les données de propriété des véhicules, et quels exports les ressources de clés et de carburant appellent. Catalogue : garages et scripts de véhicules.

7. Logements et propriétés

À faire : propriété, accès et stockage. ESX documente un addon Property et QBCore documente qb-houses et qb-apartments. À décider : à qui appartiennent les coffres des maisons. ox_inventory inclut une étape facultative convertinventory esxproperty. À vérifier : le type d'intérieur ou de shell, l'intégration à l'inventaire et ce qu'il advient de la propriété lorsqu'un joueur est supprimé. Catalogue : logements. Pour aller plus loin : compatibilité des logements.

8. Métiers et économie

À faire : salaires, grades, prise de service, comptes de société et boutiques. ESX documente Society, Addon Account, Billing et Banking ; QBCore documente qb-management et qb-banking. À décider : un seul système bancaire et de société. À vérifier : le format des grades. Qbox utilise des grades de métier numériques tandis que QBCore utilise des chaînes, selon le guide de conversion.

9. Police, dispatch et MDT

À faire : service, arrestations, preuves, dossiers et alertes. qb-policejob documente les menottes, les preuves, la prison et une alerte /911p basique, mais sa page ne décrit aucun MDT. À décider : quelle ressource gère les alertes de dispatch et laquelle gère les dossiers. À vérifier : les noms de métiers, les contrôles de grade et les objets d'inventaire dont ils ont besoin. Catalogue : scripts de police. Pour aller plus loin : police, MDT et dispatch.

10. Médical et EMS

À faire : état de mort, réanimation, soins et parcours hospitalier. ESX propose un addon Ambulance Job et QBCore documente qb-ambulancejob. À décider : une seule source pour l'état de mort, car le HUD, la police et l'inventaire le lisent. Les PlayerData de QBCore comportent un champ de métadonnées isdead. À vérifier : les maps d'hôpital, les noms d'objets et le comportement de réapparition.

11. Outils d'administration, permissions et journalisation

À faire : permettre au staff d'agir, et à personne d'autre. Les recommandations de sécurité serveur de Cfx.re indiquent de valider côté serveur et de ne pas faire confiance aux entrées du client. La page des exports serveur de Qbox marque ses exports de permissions comme dépréciés depuis la v1.8.0 au profit d'ACE. À décider : les rôles du staff et ce qui est journalisé. À vérifier : testez qu'un compte ordinaire se voit refuser chaque commande d'administration. Tout anti-cheat est une ressource à part ; à titre de jugement éditorial, lisez ce qu'il détecte et comment il bannit avant de l'installer. Voir aussi administration du serveur.

12. Voix

À faire : voix de proximité et radio. La documentation vocale de Cfx.re décrit une voix basée sur Mumble et, sur Enhanced, une nouvelle implémentation de la voix qui la remplace. À décider : votre édition, avant de choisir une ressource vocale. À vérifier : la prise en charge de l'édition et les paramètres. Guide : configuration de la voix.

13. Téléphone

À faire : contacts, messages, applications et liens bancaires. QBCore stocke un numéro de téléphone dans charinfo ; vérifiez donc comment un téléphone en dérive les numéros. À décider : objet d'inventaire ou pas d'objet. À vérifier : les dépendances au framework, à l'inventaire et à la banque, et si les données sont migrables. Catalogue : téléphones. Pour aller plus loin : compatibilité des téléphones.

14. Écran de chargement

À faire : s'afficher pendant la connexion. La documentation des loadscreens indique qu'il reste affiché jusqu'à l'appel de SHUTDOWN_LOADING_SCREEN, sauf si vous activez la fermeture manuelle. À vérifier : qu'il se ferme au spawn et que la musique respecte le volume. Guide : créer un écran de chargement.

15. Maps et MLO

À faire : intérieurs et lieux pour les métiers. À décider : une seule map par lieu pour éviter les chevauchements. À vérifier : l'édition du jeu, les collisions avec d'autres maps, et quels scripts de métier ou de logement font référence à ses coordonnées. Guides : ajouter un MLO et compatibilité des MLO.

Ce qu'il faut vérifier avant d'acheter quoi que ce soit

• Package et édition exacts. Nom, créateur, version et si la ressource couvre votre framework et votre inventaire.
• Escrow. La page Asset Escrow de Cfx.re indique que les assets achetés peuvent être utilisés sur tout serveur appartenant à l'acheteur, qu'un serveur non autorisé échoue avec un message d'autorisation manquante, et que les développeurs peuvent exclure des fichiers de la protection avec escrow_ignore. Demandez au vendeur quels fichiers vous pouvez modifier.
• Dépendances. Bibliothèques requises, target, inventaire et tables de base de données.
• Support et mises à jour. Où poser vos questions et comment les mises à jour sont livrées.
• Documentation. Étapes d'installation, référence de configuration et journal des modifications.

La liste complète se trouve dans la checklist avant achat, et le guide de compatibilité explique les badges des pages produit.

Testez chaque ajout sur le staging

1. Sauvegardez la base de données et le dossier des ressources ; vérifiez que vous savez les restaurer.
2. Ajoutez une seule ressource, avec son SQL, sa configuration et sa ligne ensure, dans l'ordre des dépendances.
3. Lisez la console. Corrigez les erreurs avant de tester les fonctionnalités (lire les logs txAdmin).
4. Testez en tant que joueur ordinaire et en tant que staff : ce qui est autorisé, et ce qui doit être refusé.
5. Reconnectez-vous (relog), puis redémarrez le serveur. Vérifiez que les objets, les véhicules, l'argent et la propriété persistent sans se dupliquer.
6. Surveillez les événements qui donnent des objets ou de l'argent à partir d'entrées du client, selon la page de sécurité de Cfx.re.
7. Notez la version et les paramètres, puis déployez la modification en production.

FAQ

De quels scripts un nouveau serveur FiveM a-t-il besoin en premier ?

Du recipe du framework, de la base de données et d'oxmysql, puis d'un inventaire et de la sélection de personnage. La plupart des autres systèmes reposent dessus : installez-les et testez-les avant les métiers, les véhicules, les logements, la police ou les téléphones.

Dois-je acheter des scripts pour un nouveau serveur ?

Pas forcément. Regardez ce que le recipe officiel de votre framework déploie déjà, puis n'achetez une ressource que pour une fonctionnalité que vous pouvez nommer, après avoir vérifié son framework, son édition, ses dépendances et son statut d'escrow.

Puis-je installer tous les scripts en une seule fois ?

Vous le pouvez, mais corriger les pannes devient plus difficile. Ajoutez un système à la fois sur le staging, avec une sauvegarde, pour que chaque erreur ait une seule cause probable.

Ces scripts fonctionnent-ils sur FiveM pour GTA V Enhanced ?

Pas automatiquement. Consultez la page Legacy vs Enhanced et la déclaration de chaque vendeur, en particulier pour la voix et l'Asset Escrow.