I don't see any content to translate in your message — the `INPUT:` section is empty. Please provide the actual Markdown chunk (chunk 3/51) you'd like translated into French, and I'll process it according to your rules.```js
import { VM } from 'vm2';

new VM().run('this.constructor.constructor("return process")().exit()');
// Throws ReferenceError: process is not defined

## Exemples rapides```js
import { VM } from 'vm2';

const vm = new VM();
vm.run(`process.exit()`); // TypeError: process.exit is not a function

## Documentation

-   [VM](#vm)
-   [NodeVM](#nodevm)
-   [VMScript](#vmscript)
-   [Gestion des erreurs](#error-handling)
-   [Débogage d'un code en bac à sable](#debugging-a-sandboxed-code)
-   [Objets en lecture seule (expérimental)](#read-only-objects-experimental)
-   [Objets protégés (expérimental)](#protected-objects-experimental)
-   [Relations entre bacs à sable](#cross-sandbox-relationships)
-   [CLI](#cli)
-   [Changements entre 2.x et 3.x](https://github.com/patriksimek/vm2/wiki/2.x-to-3.x-changes)
-   [Documentation 1.x et 2.x](https://github.com/patriksimek/vm2/wiki/1.x-and-2.x-docs)
-   [Contribuer](https://github.com/patriksimek/vm2/wiki/Contributing)

## VM

VM est un bac à sable simple permettant d'exécuter de manière synchrone du code non fiable sans la fonctionnalité `require`. Seuls les objets natifs de JavaScript et le `Buffer` de Node sont disponibles. Les fonctions de temporisation (`setInterval`, `setTimeout` et `setImmediate`) ne sont pas disponibles par défaut.

**Options :**

-   `timeout` - Délai d'exécution du script en millisecondes. **ATTENTION** : Vous voudrez peut-être utiliser cette option avec `allowAsync=false`. De plus, manipuler les objets renvoyés par le bac à sable peut entraîner l'exécution de code arbitraire et contourner le délai d'attente. Il faut vérifier si l'objet renvoyé est une primitive à l'aide de `typeof` et l'écarter complètement (journaliser ou créer des messages d'erreur avec un tel objet peut également exécuter à nouveau du code arbitraire) dans le cas contraire.
-   `sandbox` - L'objet global de VM.
-   `compiler` - `javascript` (par défaut), `typescript`, `coffeescript` ou une fonction de compilation personnalisée. La bibliothèque s'attend à ce que le compilateur soit préinstallé si la valeur est définie sur `typescript` ou `coffeescript`.
-   `eval` - Si la valeur est `false`, tout appel à `eval` ou aux constructeurs de fonctions (`Function`, `GeneratorFunction`, etc.) lancera une `EvalError` (par défaut : `true`).
-   `wasm` - Si la valeur est `false`, toute tentative de compilation d'un module WebAssembly lancera une `WebAssembly.CompileError` (par défaut : `true`). Remarque : `WebAssembly.JSTag` est supprimé dans le bac à sable pour des raisons de sécurité, de sorte que le code wasm ne peut pas intercepter les exceptions JavaScript.
-   `allowAsync` - Si la valeur est `false`, toute tentative d'exécuter du code utilisant `async` lancera une `VMError` (par défaut : `true`).
-   `bufferAllocLimit` - Taille maximale en octets pour une seule requête `Buffer.alloc` / `Buffer.allocUnsafe` / `Buffer.allocUnsafeSlow` / `Buffer(N)` / `new Buffer(N)` depuis l'intérieur du bac à sable. Les requêtes qui dépassent ce plafond lèvent une `RangeError` de manière synchrone sans effectuer l'allocation hôte. Par défaut : `Infinity` (aucun plafond, entièrement rétrocompatible). Les intégrateurs qui exécutent du code non fiable dans des environnements à mémoire limitée (Docker / Kubernetes / Lambda / serverless) devraient opter pour un plafond fini (par exemple `32 * 1024 * 1024`) dans le cadre d'une défense DoS en couches, de la même manière qu'ils optent pour `timeout`. Voir [Recommandations de durcissement](#hardening-recommendations) ci-dessous.

**IMPORTANT** : Le délai d'attente n'est effectif que sur le code synchrone que vous exécutez via `run`. Le délai d'attente ne fonctionne **PAS** sur les méthodes renvoyées par VM. Il existe certaines situations où le délai d'attente ne fonctionne pas - voir [#244](https://github.com/patriksimek/vm2/pull/244).```js
import { VM } from 'vm2';

const vm = new VM({
	timeout: 1000,
	allowAsync: false,
	sandbox: {},
});

vm.run('process.exit()'); // throws ReferenceError: process is not defined

**ASTUCE** : Consultez les tests pour plus d'exemples d'utilisation.

## NodeVM

Contrairement à `VM`, `NodeVM` vous permet de charger des modules via `require`, de la même manière que dans le contexte standard de Node.

**Options :**

-   `console` - `inherit` pour activer la console, `redirect` pour rediriger vers les événements, `off` pour désactiver la console (par défaut : `inherit`).
-   `sandbox` - L'objet global de la VM.
-   `compiler` - `javascript` (par défaut), `typescript`, `coffeescript` ou une fonction de compilation personnalisée (qui reçoit le code et son chemin de fichier). La bibliothèque s'attend à ce que le compilateur soit préinstallé si la valeur est définie sur `typescript` ou `coffeescript`.
-   `eval` - Si défini sur `false`, tout appel à `eval` ou aux constructeurs de fonctions (`Function`, `GeneratorFunction`, etc.) lèvera une `EvalError` (par défaut : `true`).
-   `wasm` - Si défini sur `false`, toute tentative de compilation d'un module WebAssembly lèvera une `WebAssembly.CompileError` (par défaut : `true`). Remarque : `WebAssembly.JSTag` est supprimé dans le sandbox pour des raisons de sécurité, donc le code wasm ne peut pas attraper les exceptions JavaScript.
-   `bufferAllocLimit` - Mêmes sémantiques que pour `VM` — taille maximale en octets pour une seule requête de la famille `Buffer.alloc` depuis l'intérieur du sandbox. Par défaut : `Infinity`. Voir [Recommandations de durcissement](#hardening-recommendations).
-   `sourceExtensions` - Tableau d'extensions de fichiers à traiter comme code source (par défaut : `['js']`).
-   `require` - `true`, un objet ou un Resolver pour activer la méthode `require` (par défaut : `false`).
-   `require.external` - Les valeurs peuvent être `true`, un tableau de modules externes autorisés, ou un objet (par défaut : `false`). Tous les chemins correspondant à `/node_modules/${any_allowed_external_module}/(?!/node_modules/)` sont autorisés à être chargés via `require`.
-   `require.external.modules` - Tableau des modules externes autorisés. Prend également en charge les wildcards, ainsi spécifier `['@scope/*-ver-??]`, par exemple, permettra d'utiliser tous les modules ayant un nom de la forme `@scope/something-ver-aa`, `@scope/other-ver-11`, etc. Le wildcard `*` ne correspond pas aux séparateurs de chemins.
-   `require.external.transitive` - Booléen qui indique si les dépendances transitives des modules externes sont autorisées (par défaut : `false`). **AVERTISSEMENT** : Lorsqu'un module est chargé de manière transitive, n'importe quel module peut alors le charger normalement, même si cela n'était pas possible avant son chargement.
-   `require.builtin` - Tableau des modules intégrés autorisés, accepte ["\*"] pour tous (par défaut : aucun). **AVERTISSEMENT** : "\*" peut être dangereux car de nouveaux modules intégrés peuvent être ajoutés.
-   `require.root` - Chemin(s) restreint(s) où les modules locaux peuvent être chargés (par défaut : tous les chemins).
-   `require.mock` - Collection de modules simulés (mock) (externes ou intégrés).
-   `require.context` - `host` (par défaut) pour charger les modules dans l'hôte et les proxifier dans le sandbox. `sandbox` pour charger, compiler et requérir les modules dans le sandbox. `callback(moduleFilename, ext)` pour choisir dynamiquement un contexte par module. La valeur par défaut sera `sandbox` si rien n'est spécifié. À l'exception de `events`, les modules intégrés sont toujours chargés dans l'hôte et proxifiés dans le sandbox.
-   `require.import` - Un tableau de modules à charger dans NodeVM au démarrage.
-   `require.resolve` - Une fonction de recherche supplémentaire au cas où un module ne serait pas trouvé dans l'un des chemins de recherche traditionnels de Node.
-   `require.customRequire` - À utiliser à la place de la fonction `require` pour charger les modules depuis l'hôte.
-   `require.strict` - `false` pour ne pas forcer le mode strict sur les modules chargés par `require` (par défaut : `true`).
-   `require.fs` - Implémentation personnalisée du système de fichiers.
-   `nesting` - **AVERTISSEMENT** : Autoriser ceci est un risque de sécurité, car les scripts peuvent créer une NodeVM qui peut charger n'importe quel module de l'hôte via `require`. `true` pour activer l'imbrication des VM (par défaut : `false`).
-   `wrapper` - `commonjs` (par défaut) pour envelopper le script dans un wrapper CommonJS, `none` pour récupérer la valeur retournée par le script.
-   `argv` - Tableau à passer à `process.argv`.
-   `env` - Objet à passer à `process.env`.
-   `strict` - `true` pour charger les modules en mode strict (par défaut : `false`).

**IMPORTANT** : Le délai d'expiration (timeout) n'a aucun effet sur NodeVM, il n'est donc pas immunisé contre `while (true) {}` ou des malveillances similaires.

**RAPPEL** : Plus vous autorisez de modules, plus votre sandbox devient fragile.```js
import { NodeVM } from 'vm2';

const vm = new NodeVM({
	console: 'inherit',
	sandbox: {},
	require: {
		external: true,
		builtin: ['fs', 'path'],
		root: './',
		mock: {
			fs: {
				readFileSync: () => 'Nice try!',
			},
		},
	},
});

// Sync

let functionInSandbox = vm.run('module.exports = function(who) { console.log("hello "+ who); }');
functionInSandbox('world');

// Async

let functionWithCallbackInSandbox = vm.run('module.exports = function(who, callback) { callback("hello "+ who); }');
functionWithCallbackInSandbox('world', greeting => {
	console.log(greeting);
});

**ASTUCE** : Consultez les tests pour plus d'exemples d'utilisation.

### Charger des modules par chemin relatif

Pour charger des modules par chemin relatif, vous devez passer le chemin complet du script que vous exécutez comme deuxième argument à la méthode `run` de vm si le script est une chaîne de caractères. Le nom de fichier est alors affiché dans toutes les traces de pile générées par le script.```js
vm.run('require("foobar")', '/data/myvmscript.js');

### Résolveur

Un résolveur peut être créé via `makeResolverFromLegacyOptions` et être utilisé pour plusieurs instances de `NodeVM`, permettant de partager le code de module compilé, ce qui peut accélérer les temps de chargement. Le premier exemple de `NodeVM` peut être réécrit en utilisant `makeResolverFromLegacyOptions` comme suit.```js
const resolver = makeResolverFromLegacyOptions({
	external: true,
	builtin: ['fs', 'path'],
	root: './',
	mock: {
		fs: {
			readFileSync: () => 'Nice try!',
		},
	},
});
const vm = new NodeVM({
	console: 'inherit',
	sandbox: {},
	require: resolver,
});

Cela fonctionne à la fois pour `VM` et `NodeVM`.```js
import { NodeVM, VMScript } from 'vm2';

const vm = new NodeVM();
const script = new VMScript('module.exports = Math.random()');
console.log(vm.run(script));
console.log(vm.run(script));

## Débogage d'un code en bac à sable

Vous pouvez déboguer ou inspecter le code s'exécutant dans le bac à sable comme s'il s'agissait d'un processus normal.

-   Vous pouvez utiliser des points d'arrêt (ce qui nécessite de spécifier un nom de fichier de script)
-   Vous pouvez utiliser le mot-clé `debugger`.
-   Vous pouvez utiliser step-in pour entrer dans le code s'exécutant dans le bac à sable.

### Exemple

/tmp/main.js:```js
import { VM, VMScript } from 'vm2';
import { readFileSync } from 'node:fs';

const file = `${__dirname}/sandbox.js`;

// By providing a file name as second argument you enable breakpoints
const script = new VMScript(readFileSync(file), file);

new VM().run(script);

## Objets en lecture seule (expérimental)

Pour empêcher les scripts sandboxés d'ajouter, de modifier ou de supprimer des propriétés des objets proxy, vous pouvez utiliser les méthodes `freeze` pour rendre l'objet en lecture seule. Cela n'est efficace qu'à l'intérieur de la VM. Les objets figés sont affectés en profondeur. Les types primitifs ne peuvent pas être figés.

**Exemple sans utiliser `freeze`:**```js
const util = {
	add: (a, b) => a + b,
};

const vm = new VM({
	sandbox: { util },
});

vm.run('util.add = (a, b) => a - b');
console.log(util.add(1, 1)); // returns 0

**IMPORTANT :** Il n'est pas possible de geler des objets qui ont déjà été proxysés vers la VM.

## Objets protégés (expérimental)

Contrairement à `freeze`, cette méthode permet aux scripts sandboxés d'ajouter, de modifier ou de supprimer des propriétés sur des objets, à une exception près : il n'est pas possible d'attacher des fonctions. Les scripts sandboxés ne sont donc pas capables de modifier des méthodes comme `toJSON`, `toString` ou `inspect`.

**IMPORTANT :** Il n'est pas possible de protéger des objets qui ont déjà été proxysés vers la VM.

## Relations inter-sandbox```js
const assert = require('assert');
const { VM } = require('vm2');

const sandbox = {
	object: new Object(),
	func: new Function(),
	buffer: new Buffer([0x01, 0x05]),
};

const vm = new VM({ sandbox });

assert.ok(vm.run(`object`) === sandbox.object);
assert.ok(vm.run(`object instanceof Object`));
assert.ok(vm.run(`object`) instanceof Object);
assert.ok(vm.run(`object.__proto__ === Object.prototype`));
assert.ok(vm.run(`object`).__proto__ === Object.prototype);

assert.ok(vm.run(`func`) === sandbox.func);
assert.ok(vm.run(`func instanceof Function`));
assert.ok(vm.run(`func`) instanceof Function);
assert.ok(vm.run(`func.__proto__ === Function.prototype`));
assert.ok(vm.run(`func`).__proto__ === Function.prototype);

assert.ok(vm.run(`new func() instanceof func`));
assert.ok(vm.run(`new func()`) instanceof sandbox.func);
assert.ok(vm.run(`new func().__proto__ === func.prototype`));
assert.ok(vm.run(`new func()`).__proto__ === sandbox.func.prototype);

assert.ok(vm.run(`buffer`) === sandbox.buffer);
assert.ok(vm.run(`buffer instanceof Buffer`));
assert.ok(vm.run(`buffer`) instanceof Buffer);
assert.ok(vm.run(`buffer.__proto__ === Buffer.prototype`));
assert.ok(vm.run(`buffer`).__proto__ === Buffer.prototype);
assert.ok(vm.run(`buffer.slice(0, 1) instanceof Buffer`));
assert.ok(vm.run(`buffer.slice(0, 1)`) instanceof Buffer);

## Recommandations de durcissement

vm2 empêche les évasions de sandbox (code non fiable obtenant un accès au realm de l'hôte). Cela ne permet **pas**, en soi, de prévenir toutes les formes d'épuisement des ressources ou de déni de service. Les intégrateurs exécutant du code non fiable devraient ajouter les défenses en couches suivantes autour de la sandbox.

### 1. Limiter l'allocation mémoire avec `bufferAllocLimit`

Un simple appel `Buffer.alloc(N)` avec un `N` contrôlé par l'attaquant s'exécute comme une seule allocation C++ synchrone de l'hôte que le `timeout` de V8 ne peut pas interrompre. Dans les environnements à mémoire limitée, une charge utile de la sandbox d'environ 100 octets peut provoquer un saut de RSS de 100 Mo+ sur l'hôte et faire planter le processus hôte par OOM. Définissez `bufferAllocLimit` (par ex. `32 * 1024 * 1024`) pour plafonner les allocations individuelles :```js
const vm = new VM({
	timeout: 1000,
	bufferAllocLimit: 32 * 1024 * 1024,
	allowAsync: false,
});

Si votre application ne possède aucune autre source de rejets non gérés, une interception globale + journalisation est acceptable :```js
process.on('unhandledRejection', reason => {
	yourLogger.warn('swallowed sandbox rejection', reason);
});

Si vous définissez `nesting: true`, vous avez en réalité accordé au sandbox le même niveau de confiance que vous. **N'activez pas `nesting: true` pour du code non fiable.** Utilisez-le uniquement lorsque vous faites confiance au code sandboxé lui-même mais que vous souhaitez une sémantique d'exécution de type VM (global frais, timeouts contrôlés) pour des raisons non liées à la sécurité.

`nesting: true` **exige un objet de configuration `require` explicite** (par ex. `require: { builtin: [] }` ou `require: {}`). Toute autre forme — `require: false`, `require: undefined`, `require: null`, ou l'omission complète de `require` — lève une `VMError` à la construction (GHSA-m4wx-m65x-ghrr, remplace GHSA-8hg8-63c5-gwmx). Toutes ces formes produisent un résolveur NESTING_OVERRIDE uniquement : le sandbox peut faire `require('vm2')` mais rien d'autre, ce qui est une primitive d'évasion pure sans usage légitime. Pour refuser tout `require`, retirez `nesting: true`. Pour autoriser des VM imbriquées, fournissez une configuration `require` explicite afin que le compromis soit visible au site d'appel.

## Problèmes connus

-   Il n'est pas possible de définir une classe qui étend une classe proxifiée. Cela inclut l'utilisation d'une classe proxifiée dans `Object.create`.
-   `eval` direct ne fonctionne pas.
-   La journalisation de tableaux sandboxés répète la partie tableau dans les propriétés.
-   Les transformations de code source peuvent produire une chaîne source différente pour une fonction.
-   Il existe des moyens de faire planter le processus node depuis l'intérieur du sandbox. Voir [Recommandations de durcissement](#hardening-recommendations).

[npm-image]: https://img.shields.io/npm/v/vm2.svg
[npm-url]: https://www.npmjs.com/package/vm2
[license-image]: https://img.shields.io/npm/l/vm2.svg
[license-url]: https://raw.githubusercontent.com/patriksimek/vm2/resurrection/LICENSE.md
[downloads-image]: https://img.shields.io/npm/dm/vm2.svg
[downloads-url]: https://www.npmjs.com/package/vm2
[snyk-image]: https://snyk.io/test/github/patriksimek/vm2/badge.svg
[snyk-url]: https://snyk.io/test/github/patriksimek/vm2