Comment évaluer, tester et maintenir les scripts FiveM

Ce guide simple et clair sur la maintenance des scripts FiveM est destiné aux propriétaires de serveurs, aux développeurs et aux responsables QA. Vous y trouverez une « ville de tests » de type production dans Docker, une liste de contrôle d'acceptation exécutable de bout en bout, un modèle quantitatif d'évaluation des risques et une grille d'évaluation des fournisseurs pour vous éviter bien des soucis.

TL;DR

• Tourner vers le haut Ville d'essai (Docker) pour isoler et évaluer n'importe quel script en toute sécurité.
• Exécutez le Liste de contrôle d'acceptation avant qu'un centime ne change de mains.
• Utilisez le Score de risque (0–100) décider d'expédier/de retenir/de rejeter.
• Vendeurs vétérinaires avec le Rubrique du fournisseur (ne sautez pas ceci).
• Si vous achetez, privilégiez les magasins réputés — découvrez nos choix : Meilleurs magasins Tebex.

---

Partie 1 — « Test City » (Docker) pour une assurance qualité de script sûre et reproductible

Ce que vous obtenez

• FXServer conteneurisé + MariaDB (+ Adminer)
• Faire le ménage serveur.cfg avec oxmysql et les ressources de base
• Monté sur reliure ressources/personnalisé où vous déposez le script en cours de test
• Noms/ports de réseau déterministes pour les chaînes de base de données simples

Télécharger test-city.zip (Github)

Mode d'emploi :

1. Décompresser → CD-Test-City
2. Copie .env.exemple à .env et définissez votre LICENCE_CLE (et les identifiants DB si vous le souhaitez).
3. Baisse oxmysql dans serveur-données/ressources/[autonome]/oxmysql/.
4. Mettez le script testé dans serveur-données/ressources/personnalisé/ / et ajouter assurer à serveur.cfg.
5. docker compose build && docker compose up -d → se connecter via Direct Connect à localhost:30120.

Prérequis : Docker + Docker Compose, une clé de licence cfx et un oxmysql copie de la ressource (déposer dans serveur-données/ressources/[autonome]/oxmysql).

Disposition des dossiers

test-city/ ├─ docker-compose.yml ├─ fxserver/ │ ├─ Dockerfile │ └─ entrypoint.sh ├─ server-data/ │ ├─ server.cfg │ └─ resources/ │ ├─ [standalone]/oxmysql/ # placer oxmysql ici │ └─ custom/ # placer le script à tester ici (par exemple, myscript/) └─ .env

.env (exemple)

LICENSE_KEY=changeme_cfx_license_key MYSQL_DATABASE=fivem MYSQL_USER=fivem MYSQL_PASSWORD=fivempw MYSQL_ROOT_PASSWORD=rootpw FX_ARTIFACT_URL=https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/LATEST.tar.xz # Astuce : remplacez par une URL d'artefact spécifique à laquelle vous faites confiance pour la reproductibilité.

docker-compose.yml

version: "3.9"

networks:
  testcity:

volumes:
  db_data:

services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
    command: >
      --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
      --innodb_buffer_pool_size=256M
    volumes:
      - db_data:/var/lib/mysql
    networks: [testcity]

  adminer:
    image: adminer:4
    restart: unless-stopped
    ports:
      - "8080:8080"
    networks: [testcity]
    depends_on: [db]

  fxserver:
    build:
      context: ./fxserver
      args:
        FX_ARTIFACT_URL: ${FX_ARTIFACT_URL}
    restart: unless-stopped
    environment:
      LICENSE_KEY: ${LICENSE_KEY}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    depends_on: [db]
    networks: [testcity]
    ports:
      - "30120:30120/udp"
      - "30120:30120/tcp"
      - "40120:40120/tcp" # txAdmin (optional)
    volumes:
      - ./server-data:/opt/fivem/server-data

fxserver/Dockerfile

FROM debian:bookworm-slim

ARG FX_ARTIFACT_URL
ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y --no-install-recommends 
    xz-utils curl ca-certificates tini bash && 
    rm -rf /var/lib/apt/lists/*

# Fetch & extract FXServer artifact (URL provided via build-arg)
RUN mkdir -p /opt/fivem && 
    curl -fsSL "$FX_ARTIFACT_URL" -o /opt/fivem/fx.tar.xz && 
    tar -xJf /opt/fivem/fx.tar.xz -C /opt/fivem && 
    rm -f /opt/fivem/fx.tar.xz

# Non-root
RUN useradd -ms /bin/bash fivem
USER fivem

WORKDIR /opt/fivem
COPY --chown=fivem:fivem ../server-data /opt/fivem/server-data
COPY --chown=fivem:fivem entrypoint.sh /entrypoint.sh

ENTRYPOINT ["/usr/bin/tini","--"]
CMD ["/bin/bash","/entrypoint.sh"]

fxserver/entrypoint.sh

#!/usr/bin/env bash set -euo pipefail # Fournissez la chaîne de base de données pour oxmysql via server.cfg (déjà définie ici), # assurez-vous simplement que la base de données est accessible avant le démarrage pour éviter les erreurs de spam. echo "En attente de la base de données..." until nc -z db 3306; do sleep 1; done echo "DB ready." # Exécutez FXServer avec notre server.cfg # La plupart des artefacts Linux intègrent un run.sh dans la racine de l'artefact. exec bash /opt/fivem/run.sh +exec /opt/fivem/server-data/server.cfg

Si votre artefact utilise un chemin de lancement différent, ajustez la dernière ligne en conséquence (par exemple, /opt/fivem/alpine/opt/cfx-server/run.sh).

serveur-données/serveur.cfg (maigre, prêt pour les tests)

# ---------- Identity ----------
sv_licenseKey "%LICENSE_KEY%"            # injected by env in entrypoint command or replace manually
sv_hostname "Test City — Script QA"
sets tags "qa,testing,fivemx"
sv_maxclients 2
onesync on
sv_scriptHookAllowed 0
sv_enforceGameBuild 3095

# ---------- Networking ----------
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# ---------- Database (oxmysql) ----------
set mysql_connection_string "mysql://%MYSQL_USER%:%MYSQL_PASSWORD%@db:3306/%MYSQL_DATABASE%?charset=utf8mb4"

# ---------- Core / Base resources ----------
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure hardcap
ensure baseevents

# ---------- Datastore ----------
ensure oxmysql

# ---------- Under test ----------
# Drop your script folder into resources/custom/<scriptname> and enable here:
# ensure myscript

# ---------- QA helpers ----------
# Verbose logging in dev
setr con_minSeverity info

# Enable txAdmin panel (optional)
setr txAdminPort 40120

Activez votre script : copiez-le dans serveur-données/ressources/personnalisé/monscript/ et ajouter assurer myscript jusqu'au bloc inférieur.

Exécutez-le

cd test-city docker compose build docker compose up -d # Administrateur à http://localhost:8080 (serveur : db, utilisateur : fivem, mot de passe : fivempw) # Connecter le client FiveM → Connexion directe : your-docker-host:30120

---

Partie 2 — Liste de contrôle d'acceptation du script (à ne pas ignorer)

Utilisez-le à chaque fois. Copiez-le dans votre suivi et cochez les éléments.

A. Pré-vol (avant l'installation)

• Type de source : Open source / partiellement ouvert / sous séquestre uniquement.
• Dépendances répertoriées : cadre (ESX/QBCore/QBOX), ox_lib, oxmysql, PolyZone, etc.
• fxmanifest.lua : lua54 'oui', correct jeu 'gta5', version_fx pas ancien.
• Documents : étapes d'installation, exemples de configuration, autorisations, paramètres régionaux, conflits connus.
• Licence/Conditions d'utilisation : droits d'utilisation, politique de remboursement, mises à jour, canal d'assistance.

B. Installabilité

• Aucune erreur de console sur assurer: aucune trace de pile ni spam d'actifs manquants.
• Non natifs dépréciés courrier indésirable.
• La configuration se charge proprement : aucune erreur de syntaxe JSON/Lua.
• Migrations de bases de données : créer des tables une fois ; les redémarrages ne s'appliquent pas à nouveau et ne s'interrompent pas.

C. Fonctionnel

• Cœur les flux fonctionnent : chemin heureux testé (par exemple, achat, flux de travail, artisanat).
• Cas limites : entrées erronées, permissions manquantes, quantités hors limites.
• Localisation: pas de chaînes codées en dur si les paramètres régionaux le promettent.
• Autorisations : commandes du personnel/administrateur bloquées ; pas d'accès gratuit côté client.

D. Performances (client et serveur)

• résmon: ralenti ≤ 0,10 ms, actif ≤ 0,50 ms (client).
• État de santé du serveur : aucun avertissement de longs problèmes dans des conditions normales d'utilisation.
• Requêtes de base de données : pas de boucles serrées ; instructions préparées utilisées ; N+1 minimal.

E. Sécurité

• Validation côté serveur : chaque événement du serveur valide source, les permissions et les types d'entrée.
• Aucune confiance dans le client : les changements d'argent/d'inventaire dépendent uniquement de la logique du serveur.
• Aucune évaluation/chaîne de chargement/code à distance motifs.
• Anti-abus : limites de débit/limites sur les points de terminaison spammés.
• Intégrité du séquestre : pas de portes dérobées dans les chargeurs de configuration sans séquestre.

Bon modèle d'événement (exemple) :

RegisterNetEvent('myscript:buy', function(item, amount) local src = source si type(item) ~= 'string' ou type(amount) ~= 'number' ou amount < 1 alors renvoyer end si non HasPermission(src, 'shop.buy') alors renvoyer end local xPlayer = GetPlayer(src) -- adaptateur de framework si non xPlayer alors renvoyer end -- valider le prix côté serveur, vérifier les limites d'inventaire, faire la base de données dans une transaction end)

F. Compatibilité et propreté

• Adaptateurs de framework présents (ESX/QBCore/QBOX) ou clairement déclaré non pris en charge.
• Aucune fuite globale, noms d'événements uniques, aucune hypothèse de nom de ressource.
• Désinstaller proprement : supprimer la ressource ne brise pas les autres.

---

Partie 3 — Modèle de notation quantitative des risques (0–100)

Utilisez ceci pour décider « expédier/retenir/rejeter ». Une valeur plus basse est préférable.

Facteur	Poids	Comment noter (0 = bon → 5 = mauvais)
Performance	0.20	résmon inactif : 0 = ≤ 0,10 ms, 1 = ≤ 0,20, 3 = ≤ 0,50, 5 => 0,50 ; les pics ajoutent +1
Sécurité	0.25	0 = tous validés par le serveur + limites de débit ; 3 = quelques écarts ; 5 = fait confiance au client / événements non sécurisés
Stabilité	0.15	0 = aucune erreur ; 3 = avertissements occasionnels ; 5 = erreurs/problèmes fréquents
Compatibilité	0.10	0=adaptateurs/tests ; 3=un seul framework ; 5=interrompt les dépendances communes
Maintenabilité	0.10	0=docs/changelog/versions sémantiques ; 5=pas de docs/abandonné
Chaîne d'approvisionnement/Fournisseur	0.20	0 = réputé, historique, remboursements ; 5 = inconnu, aucune politique

Formule

RiskScore = 100 * Σ(weight_i * (score_i / 5))

Bandes et actions

• 0–24 (faible) : Expédition vers la plateforme de mise en scène, surveillance.
• 25–49 (Modéré) : Corrections requises avant la mise en ligne.
• 50–74 (élevé) : Attendre ; demander des correctifs au fournisseur ou remplacer.
• 75–100 (critique) : Rejeter.

Exemple

• Perf=1, Sec=3, Stabilité=1, Compat=1, Maint=2, Fournisseur=1
• Risque = 100*(0,2*0,2 + 0,25*0,6 + 0,15*0,2 + 0,1*0,2 + 0,1*0,4 + 0,2*0,2) = 34 → Modéré

---

Partie 4 — Grille d'évaluation des fournisseurs (attribuez une note de 0 à 5 à chaque fournisseur, la plus élevée étant mieux)

Critère	À quoi ressemble le « bien »	Remarques
Identité et antécédents	Marque claire, années d'activité, poignée cohérente	Évitez les magasins de brûleurs
Documentation	Installation + configuration + autorisations + dépannage	Aide aux captures d'écran/gifs
Cadence de mise à jour	Journal des modifications, versions sémantiques, commits/versions récents	Trimestriel+ c'est bien
Qualité du support	Contrats de niveau de service (SLA) pour les tickets/Discord, correctifs reproductibles, pas seulement « redémarrage »	Exemples de réponses
Transparence des problèmes	Problèmes connus du public et feuille de route	L'honnêteté > la perfection
Clarté des conditions d'utilisation et des remboursements	Fenêtre de remboursement, conditions, termes de licence	Pas de motifs sombres
Preuve de test	Vidéo de mise en scène, mesures de performance, liste des frameworks	Encore mieux : serveur de démonstration
Hygiène de sécurité	Mentionne les vérifications côté serveur, pas de clés sensibles, pas d'évaluation	Renseignez-vous sur les audits
Politique de compatibilité	ESX/QBCore/QBOX déclarés, adaptateurs, matrice de versions	Constructions soutenues par l'État
Prix et valeur	Équitable pour la complexité, pas de barrières de dépendance	Attention aux pièges de la vente incitative

Score de la rubrique (0–50) :

• 40–50 : Fort — fournisseur privilégié
• 30–39 : Acceptable — surveiller
• 20–29 : Faible — procéder avec prudence
• <20 : À éviter

Conseil de pro : Comparez les offres avec celles de places de marché réputées. Commencez ici : Meilleurs magasins Tebex.

---

Partie 5 — Manuel de maintenance (après l'expédition)

1. Épinglage de version : versions de script de verrouillage + versions de dépendances (par exemple, oxmysql, ox_lib).
2. Mise en scène d'abord : toutes les mises à jour atterrissent dans Ville d'essai; exécutez à nouveau la liste de contrôle d'acceptation.
3. Sauvegardes et restaurations : Capture instantanée de la base de données et fichiers de ressources avant chaque mise à jour. Conservez-en un Rollback.md avec des étapes exactes.
4. Test de fumée CI (facultatif, recommandé) : connexion client sans tête + macro de commande pour atteindre les flux principaux ; analyser la console du serveur pour les erreurs.
5. Indicateurs opérationnels : tenir un registre simple par script : rappel moyen (inactif/actif), nombre d'erreurs/session, notes d'incident.
6. Discipline du journal des modifications : exiger des journaux des modifications des fournisseurs ; conserver vos propres notes d'intégration.
7. Réduire les risques liés aux événements programmés : mettre à jour en dehors des heures de pointe ; annoncer les fenêtres de maintenance.

---

Partie 6 — Modèles que vous pouvez copier

A. Plan de test (par script)

# Script Test Plan — <name> <version>

## Context
Framework(s): ESX/QBCore/QBOX
Dependencies: oxmysql vX, ox_lib vY, PolyZone vZ
DB Migrations: yes/no
Escrow: yes/no

## Functional Cases
- [ ] Case 1:
- [ ] Case 2:
- [ ] Negative 1:

## Performance
resmon idle: ____ ms
resmon active: ____ ms (scenario: ______)

## Security Checks
- [ ] All server events validate source/perm/input
- [ ] Rate limits present
- [ ] No client-trusted money/inventory mutations

## Logs & Errors
Paste snippet (server + F8): 

## Result
Pass/Fail + Notes

B. Rollback.md (squelette)

# Rollback — <date> <script> <from→to>

1) Disable script: `stop <resource>`
2) Restore resource files from backup: <path>
3) Restore DB snapshot: <path/command>
4) Restart FXServer
5) Verify: console clean, perf normal, flows ok

C. Modèle de problème

**Résumé** Ce qui s'est passé par rapport aux attentes, avec horodatages. **Étapes de reproduction** 1) ... 2) ... **Environnement** Construction de l'artefact : Framework et versions : Version du script : Autres dépendances : **Journaux** Console du serveur : F8 : **Pièces jointes** Écrans/vidéo si possible.

---

Comment utiliser ce guide efficacement

1. Ville de test Bootstrap une fois, gardez-le propre.
2. Pour chaque script candidat :
   • Laissez tomber dans ressources/personnalisé/, activer dans serveur.cfg.
   • Exécutez le Liste de contrôle d'acceptation.
   • Calculer le Score de risque.
   • Vérifiez le vendeur avec le Rubrique du fournisseur.
3. Si le projet est approuvé, fusionnez avec la phase de préparation ; sinon, demandez des correctifs ou éloignez-vous.

---

Besoin de plus de guides de test ? Découvrez la section