Comment choisir un script FiveM : 7 vérifications avant de payer

Dernière vérification : 14 août 2026. Depuis les vagues de sanctions Cfx.re de 2025, acheter la mauvaise ressource ne coûte plus le prix du script. Ça peut coûter le serveur.

Le 8 août 2025, Cfx.re annonce des « two-week suspensions to all servers who are confirmed to have used leaked assets without authorization », en précisant que tout serveur repris une seconde fois serait définitivement supprimé. Le 16 octobre 2025, le bilan tombe : les équipes ont « suspended hundreds of accounts and servers associated with stolen assets, and permanently banned those confirmed to be in violation ».

Ça déplace la question. Choisir un script FiveM était un arbitrage de budget. C’est devenu un arbitrage de risque, et l’essentiel de ce risque est visible avant de payer, à condition de savoir où regarder.

Cette page liste sept vérifications. Chacune prend moins de cinq minutes, chacune se fait avant la transaction, et chacune se termine par une question précise à poser au vendeur ou une commande précise à lancer. Rien ici ne vous demande de nous croire sur parole, et l’essentiel peut être retourné contre nous.

Elles valent pour toute ressource payante, script, MLO, véhicule ou pack de vêtements. Nous écrivons « script » parce que c’est le mot qu’emploie la communauté, mais l’escrow chiffre aussi les modèles et les sanctions portent sur les assets en général.

Précision de vocabulaire, parce que les trois se confondent constamment : un script open source vous laisse lire et modifier tout le code ; un script escrow est chiffré par le système officiel de Cfx.re et n’expose que ce que le vendeur a choisi de laisser ouvert ; un leak est une copie redistribuée sans autorisation, quel que soit son état technique. Les deux premiers sont des choix commerciaux. Le troisième est ce qui fait bannir un serveur.

Pourquoi « lisez les avis » n’est pas une méthode

Tous les guides d’achat de ce secteur finissent sur les trois mêmes conseils : lisez les avis, méfiez-vous du code obfusqué, achetez chez un vendeur de confiance. Le premier se manipule, le deuxième est impossible sur une ressource escrow par construction, et le troisième tourne en rond. Aucun n’est une vérification. Une vérification a une entrée, une procédure, et un résultat qui passe ou qui échoue.

1. Le vendeur est-il un créateur accrédité Tebex ?

Cfx.re l’écrit sans ambiguïté : seuls les créateurs accrédités Tebex sont des revendeurs autorisés d’assets FiveM et RedM. Ce n’est pas un label de qualité, c’est une règle d’autorisation, et elle décide si vous avez le moindre recours.

Trois choses à vérifier, dans cet ordre :

• Le paiement passe par Tebex. Pas un virement Discord, pas un PayPal entre proches, pas une adresse crypto.
• La livraison arrive dans votre Cfx.re Portal, pas en .zip par message privé. Une ressource livrée en archive n’est pas passée par le système escrow, quoi qu’en dise le vendeur.
• Le vendeur a un fil de release sur forum.cfx.re avec un historique daté. Un vendeur actif depuis plusieurs années laisse une trace publique. Sans trace, il débute ou il a changé de nom après un incident.

Hors de ce circuit, il n’y a pas de recours à perdre : il n’y en a aucun

C’est le point que la plupart des acheteurs comprennent trop tard, et il ne demande de faire confiance à personne, il se déduit du fonctionnement.

Un achat hors Tebex ne produit aucune livraison Portal, donc aucun entitlement rattaché à votre compte Cfx.re. Vous n’avez pas une ressource mal achetée : vous avez un dossier de fichiers, et rien qui atteste que vous avez le droit de l’exécuter. Il n’y a pas de recours à faire valoir parce qu’il n’existe aucun enregistrement de la transaction du côté de la plateforme.

Les formes que ça prend sont nombreuses. Des boutiques montées en dehors de Tebex. Des annonces sur des places de marché de prestation généralistes. Et surtout des serveurs Discord dédiés à la revente, souvent aux côtés de cheats et d’autres outils illégaux, où l’on paye d’abord et où l’on espère ensuite.

Nous ne prétendrons pas mesurer la fréquence des arnaques dans ce circuit, et nous nous méfions des articles qui l’affirment sans le démontrer. Le raisonnement suffit : dans une transaction sans trace, sans plateforme et sans identité vérifiée, le seul mécanisme qui garantit la livraison est la bonne volonté du vendeur. Ne vous précipitez pas parce qu’une offre expire dans deux heures. C’est précisément à ce moment-là qu’on ne vérifie rien.

Cette première vérification porte les six suivantes. Sur une ressource escrow vous ne pouvez pas lire le code : tout ce que vous ne pouvez pas vérifier vous-même se reporte sur la responsabilité du vendeur. C’est pour ça qu’elle vient en premier et pas en dernier.

2. L’asset est-il légitime, et que risque votre serveur ?

C’est le chapitre que les guides d’achat sautent, parce qu’il est inconfortable à écrire pour un vendeur.

« Je ne savais pas que c’était un leak » n’est pas une catégorie reconnue. Les sanctions de 2025 ont visé les serveurs confirmés comme utilisant des assets non autorisés, et une ressource déchiffrée est détectable côté serveur indépendamment de l’intention de l’acheteur. Votre bonne foi n’est pas une propriété technique du fichier.

Cinq signaux qui disqualifient une offre avant même de regarder le code :

• Un pack de trente à quarante scripts premium à moins de vingt euros. L’arithmétique ne tient pas. Les bundles légitimes existent, mais ils regroupent le catalogue d’un seul studio, pas un échantillon des sorties payantes du marché.
• Une livraison par archive plutôt que par le Portal.
• Un script premium connu revendu sous une autre marque, souvent avec le fichier de configuration d’origine intact.
• Aucun changelog. Une ressource maintenue a un historique de versions. Une ressource copiée a une date de téléchargement.
• Un vendeur qui refuse d’indiquer le compte Cfx.re auquel l’achat sera rattaché.

3. Que pourrez-vous encore modifier après avoir payé ?

Sur un script escrow, le code est chiffré par le système officiel de Cfx.re. Mais le développeur choisit ce qu’il laisse en clair, avec la directive escrow_ignore de son fxmanifest.lua.

La conséquence est tout l’enjeu, et presque personne ne la formule : ce qui reste ouvert est une décision du vendeur, pas une propriété de l’escrow. Deux scripts escrow au même prix peuvent être séparés par un gouffre en matière d’adaptation. Si un réglage n’est pas sorti dans un fichier de configuration ouvert, il est inaccessible à vie, ni par vous, ni par votre développeur.

D’où la question à poser avant de payer, celle qui sépare un vendeur sérieux d’un revendeur :

Que contient votre escrow_ignore ?

Quatre choses devraient y figurer, et la quatrième est celle que personne ne réclame :

• La configuration, sinon aucun réglage n’est ajustable.
• Les fichiers de traduction, sinon vous ne pouvez pas adapter un mot à votre univers.
• Les fichiers de bridge, sinon vous ne pouvez pas le brancher sur votre framework.
• Le schéma SQL d’installation. C’est lui qui vous dit quelles tables la ressource va créer dans votre base, et donc ce qu’elle va y faire. Le lire avant d’installer prend deux minutes.

Un vendeur qui ne sait pas répondre, ou qui répond de façon évasive, vient de vous dire quelque chose d’important.

Nous ne réexpliquons pas ici le mécanisme de l’escrow lui-même. Nous tenons une page dédiée et datée sur l’état de l’Asset Escrow sur FiveM Enhanced, qui traite une autre question, celle de sa disponibilité.

4. Peut-on repérer une backdoor avant de lancer la ressource ?

Cette vérification ne s’applique qu’au code que vous pouvez lire : les ressources open source, et les fichiers qu’un vendeur a laissés hors escrow. Sur une ressource entièrement chiffrée elle ne sert à rien, et tout revient à la première vérification. Tout guide qui vous demande d’« inspecter le code » d’un script escrow décrit quelque chose d’impossible.

Une backdoor ne casse pas forcément quelque chose, et c’est le problème

On imagine un script qui détruit la base ou qui vide les comptes en banque. Dans les faits, une backdoor qui se remarque a échoué. Celles qui durent ne cassent rien.

Nous avons vu des serveurs faire tourner des ressources compromises, et la fréquence est nettement plus élevée sur les scripts issus d’un leak que sur les ressources achetées à un créateur ayant une boutique officielle. Deux familles reviennent.

La récupération de données. La plus connue : la ressource lit votre base et fait remonter ce qui pourrait être exploitable. Rien ne tombe en panne, rien n’alerte, et le serveur fonctionne parfaitement pendant que ses données sortent.

Les évènements laissés ouverts pour permettre la triche. Celle-là est moins connue et plus sournoise. La ressource embarque des évènements exploitables, qui permettent à un cheat de faire des choses indétectables sur votre serveur. Ce n’est pas toujours une négligence : cela se fait parfois en collaboration avec des créateurs de cheat, dont l’outil paraît alors plus puissant que celui des concurrents. Ce qui est vendu, ce n’est pas le script, c’est la porte.

La conséquence pratique est simple : la réputation du créateur n’est pas un détail de confort. Quelques recherches sur son nom, son historique et ses fils publics suffisent le plus souvent à savoir à qui l’on parle.

Trois motifs à chercher dans le code lisible

Un évènement serveur qui écrit sans vérifier qui l’appelle. N’importe quel client peut déclencher un évènement réseau enregistré. Si le gestionnaire fait confiance à ses arguments, n’importe quel joueur peut lui passer n’importe quoi.

RegisterNetEvent('shop:giveItem', function(item, amount)
  MySQL.update('UPDATE users SET money = money + ?', { amount })
end)

Le signe est l’absence de validation de source et l’absence de contrôle serveur sur la légitimité de la demande. C’est aussi exactement la forme que prend un évènement laissé ouvert à dessein.

Un appel HTTP vers un hôte qui n’est pas celui du vendeur. Les vérifications de licence existent et sont normales. Une vérification de licence vers un domaine sans rapport avec le vendeur, qui envoie plus qu’un identifiant, ne l’est pas.

Une chaîne décodée puis exécutée au chargement. Une ressource légitime n’a aucune raison de construire du code à l’exécution depuis une chaîne encodée.

Un balayage rapide de votre dossier resources, avant tout démarrage :

grep -rn "PerformHttpRequest|load(|assert(load|_G[" resources/

La communauté décrit aussi un symptôme récurrent qu’il faut savoir nommer : du code qui réapparaît en bas de client.lua, config.lua ou server.lua après avoir été supprimé. Si ça arrive, la ressource n’est pas à réparer, elle est à retirer.

5. Combien le script coûte-t-il réellement en performance ?

Les fiches produit affichent 0.00 ms par dizaines. Le chiffre est généralement vrai et presque toujours sans intérêt, parce qu’il est mesuré au repos : ressource chargée, personne dedans, rien qui se passe. C’est l’équivalent d’une consommation annoncée moteur éteint.

Une ressource se mesure dans trois états :

État	Ce que vous mesurez
Au repos	Le script est chargé, personne ne l’utilise
En usage	Un joueur interagit activement avec
En pic	Le pire cas réaliste, plusieurs joueurs à la fois

Les repères, en reprenant les conventions de travail de la communauté plutôt qu’une norme officielle : à 60 Hz, le budget d’une frame entière est de 16,67 ms pour tout ce qui tourne. Une ressource saine se tient entre 0,00 et 0,05 ms au repos. Au-delà de 0,10 ms on regarde de près. Au-delà de 0,5 ms au repos, quelque chose ne va pas, et c’est avant qu’un joueur y ait touché.

Pour mesurer vous-même : F8, puis resmon 1.

À quoi ressemble un relevé honnête

Puisque nous demandons trois états, voici les nôtres sur avenida_interact, avec le banc de test qui va avec. Sans le protocole, un chiffre ne veut rien dire.

Le banc : 100 points d’interaction fixes, 100 points d’interaction avec PNJ et fenêtre de dialogue, et la détection liée à 50 modèles d’entités différents. C’est ce que représente un serveur au développement déjà avancé, pas une scène de démonstration.

Situation	Mesure	Pourquoi
Joueur au repos, aucune interaction en vue	0,00 ms	Rien à évaluer
Joueur en voiture, le client évalue s’il doit afficher quelque chose	0,01 ms	Le temps d’une fraction de seconde, pendant la vérification
Un point d’interaction affiché en 3D dans le monde	0,08 ms	Coût du rendu, tant qu’il reste visible
Fenêtre de dialogue PNJ ouverte	0,06 ms	Le point 3D est libéré à l’ouverture au lieu de rester affiché

Ce dernier chiffre est le plus instructif, et c’est une décision de conception plutôt qu’une mesure : ouvrir un dialogue libère le point 3D au lieu de le laisser vivre derrière la fenêtre. Le coût baisse au moment où le joueur regarde ailleurs. C’est le genre d’arbitrage qu’un relevé en trois états rend visible, et qu’un 0.00 ms au repos cache entièrement.

Un angle mort que presque tous les guides partagent : un script peut être léger côté client et écraser votre base de données. Comptez aussi les requêtes SQL par action. Une ressource qui interroge la base à chaque frame d’une interaction n’apparaîtra pas dans le chiffre client, et c’est elle qui fera mal à soixante joueurs. C’est aussi pour ça que le schéma SQL ouvert, à la vérification 3, n’est pas un détail.

6. La compatibilité framework est-elle réelle ou seulement annoncée ?

« Compatible ESX et QBCore » ne veut rien dire en soi, parce qu’aucun des deux n’est une chose unique.

Quatre questions à poser :

• Quel ESX ? Legacy et 1.2 ne sont pas interchangeables.
• Quel QBCore ? qb-core et Qbox ont divergé, et la réponse dépend de la version.
• Et vRP ? La question paraît secondaire vue d’Europe, elle ne l’est pas. Le Brésil est le premier marché FiveM hors anglophone en nombre de joueurs, et la majorité de ses serveurs tournent sous vRP, pas sous ESX ni QBCore. Un vendeur qui n’a jamais entendu la question n’a pas regardé au-delà de son propre marché.
• Les exports et les évènements sont-ils exposés dans un fichier non chiffré ?

La quatrième est le vrai test. Un vendeur qui expose le bridge vous dit qu’il s’attend à ce que vous adaptiez. Un vendeur qui ne l’expose pas vous demande d’adapter votre serveur à ses choix à lui.

Et la bonne question suivante est celle du repli : que fait la ressource quand aucun framework connu n’est présent ? Une compatibilité sérieuse prévoit un mode autonome qui ne dépend de rien, pas seulement deux branches pour les deux frameworks les plus répandus.

Sur la question que les gens tapent juste avant de cliquer sur acheter, à savoir si un script QBCore tourne sur Qbox, la réponse honnête est : en grande partie oui, pas systématiquement. Les dépendances et certains exports diffèrent. Qui répond oui sans nuance est en train de vendre, pas de conseiller.

7. Que se passe-t-il après l’achat ?

Trois pièges d’après-vente qu’aucune page ne réunit habituellement.

L’erreur d’entitlement. Tôt ou tard vous croiserez You lack the required entitlement to use this resource, et c’est très fréquent. Elle signifie que la clé serveur utilisée a été générée par un compte Cfx.re différent de celui qui a fait l’achat. Un serveur tourne avec une seule clé, et vous pouvez vérifier laquelle avec sv_licenseKey dans la console. La façon classique de tomber dedans tient à la précipitation : on achète avec le compte qu’on a sous la main, pas avec celui qui a généré la clé. La bonne nouvelle, c’est que ça se rattrape : un transfert de propriété depuis le Portal Cfx.re corrige l’erreur. Mais ce transfert n’est normalement possible qu’une seule fois, donc autant ne pas le dépenser par distraction.

Le remboursement. Pour un contenu numérique, le droit de rétractation s’éteint dès que l’exécution commence avec votre accord, ce qui pour un script signifie le premier téléchargement. Les politiques observées sur ce marché vont de quatorze jours sans justification à strictement non remboursable. Ce qui compte, c’est que la politique soit écrite et lue avant de payer.

L’abonnement. Sur une ressource vendue par abonnement, l’expiration retire l’asset du compte et le script cesse de démarrer. Rien ne casse, rien n’est supprimé, ça s’arrête.

Notre observation sur le terrain

Nous n’avons pas écrit cette page depuis un bureau d’études. Nous l’avons écrite parce que nous avons fait à peu près toutes les erreurs qu’elle décrit.

Notre équipe a commencé par monter son propre serveur, entre amis. Aucun d’entre nous ne savait vraiment comment fonctionnait un serveur FiveM, et encore moins ce qu’on y risquait. Nous avons appris comme tout le monde, avec des tutoriels de mise en service trouvés en ligne.

Nous avons acheté pour gagner du temps

La communauté a grandi plus vite que notre capacité à développer. Chaque semaine apportait des demandes que nous n’avions pas les heures de traiter. Acheter des scripts n’était pas un confort, c’était le seul moyen de tenir le rythme sans faire attendre nos joueurs.

C’est exactement la situation dans laquelle on vérifie le moins. C’est aussi exactement celle dans laquelle il faudrait vérifier le plus.

Ce que nous avons fini par comprendre

Trois choses, qui revenaient si régulièrement qu’elles ont fini par structurer cette page.

Des performances qui n’avaient rien à voir avec l’annonce. Des ressources vendues comme les plus optimisées du marché nous coûtaient des millisecondes que nous ne pouvions pas nous permettre. Le chiffre affiché n’était pas faux. Il était mesuré dans des conditions qui ne ressemblaient à rien.

Des scripts annoncés adaptables à tout type de serveur, et impossibles à adapter au nôtre. Souvent sans mauvaise volonté du vendeur : rien n’était sorti en configuration. Quand nous demandions une modification, elle n’était pas prévue, et nous n’avions aucun moyen de la faire nous-mêmes.

Des ressources mises en ligne, puis abandonnées. Celles-là ne cassent pas le jour de l’achat. Elles cassent plus tard, quand FiveM évolue et que plus personne ne maintient de l’autre côté. À ce moment-là, vous n’avez pas acheté un script, vous avez loué un délai.

Ce que ça a changé dans notre façon de construire

Nos scripts exposent leur configuration, leurs traductions, leurs bridges et leur schéma SQL en clair. Ce n’est pas une faveur commerciale, c’est la réponse directe à ce que nous avons subi : nous ne voulions pas vendre ce que nous avions détesté acheter.

Nous n’écrivons pas cette page pour vendre. Nous l’écrivons parce que personne ne nous l’avait donnée.

La checklist en sept lignes

1. Le paiement passe-t-il par Tebex, avec livraison dans le Cfx.re Portal ? C’est impératif.
2. Le vendeur a-t-il un historique de releases daté sur forum.cfx.re ? Il doit exister.
3. Le prix est-il plausible au vu de ce qui est vendu ? Un pack de trente scripts premium à vingt euros ne l’est pas.
4. Que contient l’escrow_ignore ? Config, locales, bridges, et le schéma SQL.
5. Y a-t-il des relevés resmon dans les trois états, avec le protocole ? Demandez les trois et le banc de test.
6. Quelles versions exactes de framework, quel repli sans framework, et le bridge est-il lisible ? Des numéros de version, pas des noms.
7. Quel compte Cfx.re possédera l’asset, et quelle est la politique de remboursement écrite ? Avant de payer, pas après.

Questions fréquentes

Peut-on se faire bannir à cause d’un leak acheté de bonne foi ? Les sanctions de 2025 ont visé les serveurs confirmés comme utilisant des assets non autorisés. L’intention n’est pas une propriété technique d’un fichier, et c’est pour ça que la vérification doit se faire avant l’achat plutôt qu’après la suspension.

Peut-on modifier un script escrow ? Uniquement les parties que le développeur a laissées hors chiffrement via escrow_ignore. Tout le reste est fermé définitivement. Demandez ce que contient cette directive avant d’acheter, pas après.

Un script à 0,00 ms, ça existe ? Au repos, beaucoup. En usage, non. Un chiffre sans état de mesure ni protocole annoncés ne vous apprend rien.

Comment savoir si un script contient une backdoor ? Sur du code lisible, en cherchant les trois motifs décrits plus haut. Sur une ressource escrow, c’est impossible, et la question devient celle de la réputation du créateur. Sachez aussi qu’une backdoor ne casse rien : elle récupère des données, ou elle laisse une porte ouverte à un cheat.

Les scripts gratuits sont-ils compatibles avec tous les frameworks ? Pas plus que les payants. La question est identique dans les deux cas : quelle version de framework, quel repli sans framework, et le bridge est-il lisible.

Tebex rembourse-t-il ? Tebex encaisse le paiement, le vendeur fixe la politique. Elle va de quatorze jours à rien du tout, et le droit de rétractation sur un contenu numérique s’éteint au premier téléchargement.

Où trouver des scripts gratuits fiables ? Les vraies organisations de référence, sur GitHub : esx-framework, qbcore-framework, overextended pour ox_lib et ox_inventory, et citizenfx. Commencer ailleurs pour une ressource gratuite est la façon la plus courante de récupérer une backdoor.

Ce que ces vérifications donnent sur nos propres scripts

Cette page vaut surtout si elle peut être retournée contre nous. Voici donc où chaque critère se vérifie chez Avenida, et ce que nous ne tenons pas encore.

Ce qui est ouvert. Notre escrow_ignore expose la configuration, les traductions, les bridges, le changelog et le schéma SQL d’installation. Vous pouvez donc lire ce que la ressource va créer dans votre base avant de l’installer, et ajuster le comportement sans nous demander la permission. Seule la logique interne reste protégée. Un cas concret : les 368 corrections de zones du salon de tatouage vivent dans un fichier de config que vous pouvez continuer à corriger vous-même.

La compatibilité. Nos scripts détectent ESX, QBCore et vRP, et retombent sur un mode autonome quand aucun framework n’est présent, en s’appuyant sur les natives du jeu. Un mode personnalisé permet de brancher le reste, et les systèmes d’inventaire, de notification et d’interaction les plus répandus sont préconfigurés. Les fichiers de bridge sont lisibles, donc cette affirmation est vérifiable et pas seulement déclarative : la fiche du barbier liste ses sept bridges et dit ce que chaque cible vous coûte, vRP compris.

Le remboursement. Notre politique est écrite, et elle est stricte : pas de remboursement à titre standard, avec une exception si le script est non fonctionnel et que le problème n’est pas résolu sous sept jours ouvrés. Nous l’assumons plutôt que de la cacher. Un produit numérique livré, fonctionnel et utilisé pendant des semaines ne se rend pas, et l’énergie que nous ne passons pas à arbitrer des demandes non recevables, nous la passons à faire évoluer les scripts.

La performance. Chaque fiche produit porte désormais son relevé au repos et les conditions de mesure, ce qui était précisément le manque que cet article pointait à sa publication. Ce qui manque encore, ce sont les états en charge et sous contrainte au même endroit : demandez-les-nous pour n’importe quelle ressource, et tenez-nous-y tant qu’ils ne sont pas sur les fiches.

Voir comment ces critères se vérifient sur le catalogue.

Historique de cette page

• 19 août 2026. Deux affirmations de la dernière section avaient vieilli et ont été corrigées : vRP est une cible détectée et non une branche personnalisée, et le relevé au repos est désormais publié sur chaque fiche produit.
• 14 août 2026. Publication initiale. Vérification des annonces Cfx.re du 8 août et du 16 octobre 2025, et de la documentation Asset Escrow.

Sources officielles

Toutes les affirmations factuelles de cette page proviennent de la documentation et des communications officielles de Cfx.re, l’éditeur de FiveM. Les mesures de performance sont les nôtres, avec leur protocole.

• Asset Security Update, forum Cfx.re : les annonces de sanctions du 8 août et du 16 octobre 2025.
• Documentation Asset Escrow : formats chiffrés et directive escrow_ignore.
• What’s a leaked asset then ? : la discussion de référence sur la définition.

---

Une question sur un script avant d’acheter, chez nous ou ailleurs ? Le plus simple est de rejoindre notre Discord. Nous répondons aussi sur les scripts que nous ne vendons pas.