---
title: "Sandboxes : exécution de code sûre avec E2B, Daytona et compagnie"
description: "Exécuter du code généré par agent et non fiable en sécurité dans des sandboxes isolées et jetables au lieu de votre propre machine"
type: "lesson"
locale: "fr"
course: "Automatisation et systèmes agentiques"
number: "4.3"
canonical: "https://agenticschool.dev/fr/cours/automation-agentic-systems/sandboxes-safe-code-execution-with-e2b-daytona-and-co"
datePublished: "2026-06-12"
dateModified: "2026-06-12"
---

# Sandboxes : exécution de code sûre avec E2B, Daytona et compagnie

- Course: Automatisation et systèmes agentiques
- Lesson: 4.3
- Duration: 24 min
- Level: fortgeschritten
- Status: published
- Canonical URL: https://agenticschool.dev/fr/cours/automation-agentic-systems/sandboxes-safe-code-execution-with-e2b-daytona-and-co
- Locale: fr

> Exécuter du code généré par agent et non fiable en sécurité dans des sandboxes isolées et jetables au lieu de votre propre machine

## Summary

Laisser un agent exécuter du code arbitraire sur votre machine est un vrai risque, pas hypothétique. Une sandbox donne au code un environnement isolé et jetable, pour qu'un run mauvais ou hostile ne puisse pas toucher votre système ou vos données. Cette leçon explique pourquoi le sandboxing compte, ce qu'est vraiment une sandbox, comment fonctionnent E2B et Daytona et exactement quand vous en avez besoin.

## What you learn

- Pourquoi exécuter localement du code généré par IA ou non fiable est vraiment risqué
- Ce qu'est une sandbox et comment E2B et Daytona fournissent des environnements jetables
- Les trois situations où vous devez sandboxer : code soumis par l'utilisateur, output d'agent non fiable, expériences parallèles

## Vue d'ensemble

Un agent qui peut écrire du code est aussi un agent qui veut l'exécuter, et dès l'instant où vous laissez du code arbitraire s'exécuter sur votre laptop ou serveur, une mauvaise ligne peut supprimer des fichiers, fuiter des secrets de votre environnement ou ouvrir une connexion que vous n'aviez pas prévue. Une sandbox résout cela en donnant au code un ordinateur frais, isolé et jetable où tourner. Si le run tourne mal, vous jetez la sandbox et ne perdez rien. Cette leçon explique le risque honnêtement, définit ce qu'est une sandbox, présente les principaux services et vous donne une règle claire pour savoir quand en utiliser une et quand un run local convient.

## Ce que vous allez apprendre

Vous allez apprendre pourquoi exécuter du code généré par IA sur votre propre machine est un risque de sécurité et de fiabilité, ce qu'une sandbox offre réellement (isolation, jetabilité, limites de ressources), comment des services managés comme E2B et Daytona en montent une à la demande pour votre agent, et les trois situations concrètes qui exigent toujours une sandbox. Vous repartez capable de décider par tâche si le code peut tourner localement ou doit être enfermé.

## Prérequis

Les Cours 1 à 3, surtout le matériel sur les secrets et la sécurité du Cours 3. Vous devez comprendre que votre machine tient des variables d'environnement, des clés SSH et des sessions connectées que tout processus local peut lire, car c'est exactement ce qu'une sandbox protège. Les bases d'API comptent aussi, puisque vous pilotez ces services via leurs SDK.

## Le problème

Les workflows agentiques génèrent du code puis doivent l'exécuter, pour voir s'il marche, transformer des données ou satisfaire une requête. La tentation est de le laisser simplement tourner - et pour du code que vous avez écrit et examiné, c'est bien. Mais l'output d'agent n'est pas toujours correct, et si un input est venu d'un utilisateur ou du web ouvert, il n'est pas toujours amical. Une seule commande rm, une boucle infinie qui met votre CPU à genoux, un script qui lit process.env et téléphone à la maison : ce ne sont pas des cas exotiques, ce sont les modes d'échec standard quand on exécute du code non fiable avec plein accès à votre vrai système.

## Ce qu'est vraiment une sandbox

Une sandbox est un environnement d'exécution isolé et jetable - en pratique une machine virtuelle légère ou un conteneur durci - qui n'a aucun accès à votre vrai système de fichiers, vos secrets ou votre réseau, sauf ce que vous autorisez explicitement. Le code y tourne avec son propre système de fichiers, ses propres limites de mémoire et de CPU et un budget de temps dur. Quand le run est fini, vous démolissez la sandbox et rien ne persiste. Le modèle mental est une salle blanche : le code reçoit exactement les inputs que vous lui donnez, produit exactement les outputs que vous collectez, et ne peut rien atteindre en dehors de la salle.

- Isolation : le code ne peut pas voir votre système de fichiers hôte, vos variables d'environnement ni d'autres processus.
- Jetabilité : chaque run est un environnement frais ; une sandbox compromise ou cassée est simplement détruite.
- Limites de ressources : CPU, mémoire et temps d'horloge sont plafonnés, pour qu'une boucle emballée ne puisse pas mettre votre machine à genoux.
- I/O contrôlé : vous décidez quels fichiers entrent et ce qui sort ; l'accès réseau peut être restreint ou refusé.

## E2B, Daytona et amis

Vous ne bâtissez pas les sandboxes vous-même - vous appelez un service qui en monte une via un SDK en moins d'une seconde. E2B est spécifiquement bâti pour que les agents d'IA exécutent du code : vous créez une sandbox, y exécutez du code ou des commandes shell, lisez l'output et la terminez, tout depuis quelques lignes dans votre app. Daytona offre des environnements de development rapides et éphémères dans le même esprit, utiles quand un agent a besoin d'un workspace plus complet qu'une exécution unique. Les deux abstraient la plomberie de VM et de conteneur, pour que votre agent obtienne un endroit sûr où exécuter du code à la demande. Le pattern ci-dessous est à quoi ressemble presque chaque intégration.

```typescript
import { Sandbox } from '@e2b/code-interpreter'

// Monter une sandbox fraîche et isolée juste pour ce run
const sandbox = await Sandbox.create()

try {
  // Exécuter du code généré par l'agent là où il ne peut pas vous nuire
  const execution = await sandbox.runCode(agentGeneratedPython)
  console.log(execution.logs.stdout)
  console.log(execution.error) // enfermé : une erreur ici n'est pas votre problème
} finally {
  // Toujours démolir - rien ne persiste
  await sandbox.kill()
}
```
Le pattern sandbox central : créer, y exécuter du code non fiable, collecter l'output, détruire. La surface d'API exacte évolue, alors vérifiez les docs E2B à jour.

Les détails produit et les noms de SDK changent vite dans ce domaine, alors traitez le snippet comme la forme du pattern et confirmez les noms de méthodes actuels contre les docs officielles E2B et Daytona avant de construire. Le concept - créer, exécuter, collecter, détruire - est stable, même si les API bougent.

## Quand vous avez vraiment besoin d'une sandbox

Tout run de code n'a pas besoin d'isolation, et le sur-sandboxing ajoute latence et coût. La règle est simple : sandboxez chaque fois que le code ou ses inputs ne sont pas pleinement fiables, et tournez localement quand ils le sont. Trois situations franchissent toujours cette ligne.

- Code soumis par l'utilisateur : tout ce qu'un produit laisse les utilisateurs écrire et exécuter (une fonctionnalité « exécute ce snippet », un champ de transformation de données, un moteur de formules) doit être sandboxé. Vous exécutez du code étranger sur votre infrastructure.
- Output d'agent non fiable : si un agent génère du code à partir d'un input non fiable (une page scrapée, une requête utilisateur, un document tiers) et que vous l'exécutez sans lire chaque ligne, enfermez-le. L'agent n'est aussi sûr que le pire input qu'il a vu.
- Expériences parallèles : quand vous voulez faire tourner beaucoup de variantes à la fois - tester un script généré contre dix jeux de données, fuzzer une idée, laisser plusieurs agents tenter des solutions - les sandboxes vous donnent des environnements propres, isolés et parallèles qui ne peuvent pas se perturber mutuellement ni perturber votre hôte.
- Quand le local convient : du code que vous avez écrit ou pleinement examiné, exécuté contre des inputs fiables, sur une machine dont vous contrôlez les secrets. Ne payez pas la taxe sandbox pour ça.

## Erreurs fréquentes

Les dangereuses : exécuter du code généré par agent localement « juste cette fois » et fuiter une clé API de votre environnement ; bâtir une fonctionnalité produit qui exécute l'input utilisateur sans isolation, ce qui est une vulnérabilité d'exécution de code distant de manuel ; oublier de poser des limites de CPU, mémoire et temps, si bien qu'un run emballé vous nuit quand même ; et laisser les sandboxes en vie au lieu de les démolir, ce qui gaspille de l'argent et annule la jetabilité. L'erreur inverse existe aussi : sandboxer du code trivial et fiable et vous ralentir sans gain de sécurité.

## ROI business

Le sandboxing est la différence entre une fonctionnalité agentique que vous pouvez mettre en sécurité devant les utilisateurs et une responsabilité que vous ne pouvez pas livrer. Un seul incident enfermé - un input hostile qui aurait supprimé un serveur et qui ne détruit maintenant qu'une sandbox jetable - paie toute la pratique. Pour les produits qui exécutent du code utilisateur ou agent, les sandboxes ne sont pas une finition optionnelle ; ce sont le contrôle qui vous permet d'offrir la fonctionnalité tout court. Et pour l'expérimentation interne, des sandboxes parallèles bon marché laissent une petite équipe tenter dix idées dans le temps qu'il faudrait pour en faire tourner une soigneusement.

## Checklist

Vous êtes prêt à avancer quand chacun de ces points est acquis, car la prochaine leçon vous fait bâtir des outils qui peuvent exécuter du code généré.

- Expliquer en une phrase pourquoi exécuter du code non fiable localement est risqué.
- Définir les quatre propriétés d'une sandbox (isolation, jetabilité, limites, I/O contrôlé).
- Décrire le pattern créer-exécuter-collecter-détruire avec un service comme E2B.
- Nommer les trois situations qui exigent toujours une sandbox, et une qui ne l'exige pas.

## Ressources

Gardez en favoris les docs E2B et Daytona, car leurs SDK évoluent et les noms de méthodes actuels comptent quand vous construisez. Le matériel de sécurité du Cours 3 sur les secrets et les variables d'environnement est ici le fondement - une sandbox n'aide que si vous tenez aussi les vrais secrets hors du code que vous lui donnez. Dans le doute sur le sandboxing, penchez vers Oui pour tout ce qui touche à un input utilisateur ou tiers.

## Votre mission

Inscrivez-vous à E2B (il a un quota gratuit), puis écrivez un tout petit script qui monte une sandbox, y exécute quelques lignes de Python généré, affiche l'output et la démolit. Faites délibérément tourner une ligne qui serait destructrice sur votre vraie machine (par exemple écrire un fichier poubelle) et confirmez qu'elle reste enfermée. Cette preuve pratique est ce qui transforme le sandboxing d'une idée abstraite en une habitude.

## Prochaine leçon

L'exécution sûre couverte, vous êtes prêt à bâtir de vrais outils par-dessus des API de modèles. La prochaine leçon montre comment, à travers deux études de cas de fondateur : un outil d'attribution de factures et un catalogueur de cartes à collectionner suisses, qui transforment une photo en enregistrement de base de données.

## Transcript

Laisser un agent exécuter du code arbitraire sur votre machine est un vrai risque, pas hypothétique. Une sandbox donne au code un environnement isolé et jetable, pour qu'un run mauvais ou hostile ne puisse pas toucher votre système ou vos données. Cette leçon explique pourquoi le sandboxing compte, ce qu'est vraiment une sandbox, comment fonctionnent E2B et Daytona et exactement quand vous en avez besoin.