Google Cloud Run Sandboxes : Tutoriel 2026

Le 21 juillet 2026, Google a mis en préversion publique une fonctionnalité que beaucoup d’équipes DevOps attendaient sans le savoir : les Cloud Run Sandboxes. Le principe est simple à énoncer et redoutablement utile en pratique : exécuter du code non fiable, en particulier du code généré par un agent IA, dans un environnement isolé qui démarre en quelques millisecondes à l’intérieur même d’une instance Cloud Run existante. Le 5 août 2026, Google a étendu cette capacité aux jobs et aux worker pools, ce qui couvre désormais l’essentiel des charges de travail asynchrones sur la plateforme.

Ce tutoriel vous montre comment déployer, sécuriser et surveiller une architecture Cloud Run complète intégrant les sandboxes, le failover multi-région automatique et un worker pool pour le traitement asynchrone. Douze étapes, environ 45 minutes, et un projet fonctionnel à la fin que vous pourrez adapter à vos propres agents IA.

Nous prenons le parti d’une architecture ancrée en Europe, avec des régions europe-west1 et europe-west3, pour deux raisons. La première est pratique : la latence entre la Belgique et Francfort reste basse, ce qui rend le failover transparent pour un utilisateur en France. La seconde est réglementaire, un sujet que nous détaillons plus loin dans ce guide, car le choix de la région conditionne directement où transitent les données traitées par vos sandboxes.

Qu’est-ce que Cloud Run Sandboxes et pourquoi ça compte en 2026

Google Cloud Run a longtemps reposé sur un modèle simple : un conteneur, une instance, un isolement au niveau du conteneur via gVisor. Ce modèle fonctionne bien pour des services HTTP classiques, mais il pose un problème dès qu’un agent IA se met à générer et exécuter du code à la volée. Un agent Gemini qui écrit un script Python pour analyser des données, un chatbot qui exécute du code soumis par un utilisateur, un pipeline qui teste des extraits de code non validés : dans tous ces cas, on injecte du code potentiellement dangereux dans le même processus que l’application principale.

Les Cloud Run Sandboxes répondent directement à ce problème. Concrètement, il s’agit d’un environnement d’exécution isolé, léger, que l’on peut instancier depuis l’intérieur d’un service, d’un job ou d’un worker pool Cloud Run déjà en cours d’exécution. Le code non fiable tourne dans cette enveloppe séparée, sans accès direct aux identifiants du conteneur principal ni au système de fichiers de l’application hôte. Si le code sandboxé est compromis ou simplement buggé, l’impact reste confiné.

Trois nouveautés récentes rendent ce sujet particulièrement pertinent à traiter maintenant. D’abord, l’extension aux jobs et worker pools le 5 août 2026, qui couvre désormais les traitements batch et les workloads pull-based, pas seulement les services HTTP. Ensuite, la disponibilité générale de la fonctionnalité Service Health pour Cloud Run, qui permet un failover multi-région automatisé en quelques clics. Enfin, la disponibilité générale des GPU NVIDIA RTX PRO 6000 Blackwell Server Edition sur Cloud Run, annoncée lors de Next ’26, qui change la donne pour l’inférence IA serverless. Ce tutoriel combine ces trois briques dans une architecture cohérente.

Le contexte plus large est celui d’une bascule rapide vers des applications où le code n’est plus uniquement écrit par des développeurs humains avant le déploiement. Un agent IA d’entreprise, construit par exemple sur la Gemini Enterprise Agent Platform présentée à Next ’26, peut désormais écrire, tester et exécuter du code en réponse à une tâche métier, sans supervision humaine à chaque étape. Cette autonomie apporte de la vitesse, mais elle déplace aussi la question de la sécurité : ce n’est plus seulement le code que vous avez écrit et revu qu’il faut protéger, c’est aussi celui que votre propre système génère à la volée. Les sandboxes ne sont pas une fonctionnalité de confort, elles deviennent une brique d’architecture standard pour toute équipe qui construit des agents capables d’agir sur du code.

Prérequis : outils, versions et accès nécessaires

Avant de commencer, assurez-vous de disposer des éléments suivants. Cette liste évite les allers-retours frustrants une fois lancé dans le déploiement.

Un projet Google Cloud actif avec la facturation activée (un compte de facturation neuf avec crédits gratuits suffit pour suivre ce tutoriel).
Google Cloud CLI (gcloud) en version récente, avec le composant alpha installé, car certaines commandes sandbox restent en préversion.
Docker Engine installé localement, ou l’accès à Cloud Build pour construire vos images sans Docker local.
Python 3.12 ou une version ultérieure pour le service d’exemple et le script de test d’isolation.
Les droits IAM roles/run.admin, roles/iam.serviceAccountAdmin et roles/artifactregistry.admin sur le projet, ou un rôle équivalent (Éditeur/Propriétaire pour un environnement de test).
Un terminal Unix (Linux, macOS ou WSL2 sous Windows) pour exécuter les commandes de ce guide sans adaptation.
Environ 45 minutes et un budget de test de quelques euros (les ressources créées ici restent dans les paliers gratuits pour un usage ponctuel).

Un point important avant de vous lancer : les sandboxes ne remplacent pas une politique IAM correcte. Elles ajoutent une couche d’isolement supplémentaire, elles ne dispensent pas de configurer des comptes de service à privilèges minimaux, sujet que nous traitons en détail à l’étape 9.

Notez aussi que ce tutoriel s’appuie sur des commandes du canal alpha de gcloud, ce qui signifie que la syntaxe exacte de certains flags peut évoluer d’ici le passage en disponibilité générale. Si une commande renvoie une erreur de flag inconnu, vérifiez d’abord la référence à jour avec gcloud alpha run deploy --help avant de supposer un problème plus profond : Google ajuste régulièrement l’API pendant la phase de préversion, et un renommage mineur de paramètre reste plus probable qu’une régression de la plateforme elle-même.

Partie 1 : mettre en place l’environnement GCP

Étape 1 : créer le projet et activer les API nécessaires

Commencez par créer un projet dédié à ce tutoriel, ou réutilisez un projet de test existant. Activez ensuite les API Cloud Run, Artifact Registry, Cloud Build et Cloud Logging en une seule commande.

gcloud projects create sandbox-tuto-2026 --name="Cloud Run Sandbox Tutoriel"
gcloud config set project sandbox-tuto-2026
gcloud billing projects link sandbox-tuto-2026 --billing-account=VOTRE_ID_FACTURATION

gcloud services enable \
  run.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  logging.googleapis.com \
  monitoring.googleapis.com

Sortie attendue après quelques dizaines de secondes :

Operation "operations/acf.p2-..." finished successfully.

Étape 2 : installer le composant alpha et configurer la région

Les commandes sandbox de Cloud Run vivent encore dans le canal alpha de gcloud à la date de ce tutoriel. Installez ce composant et fixez une région par défaut proche de vos utilisateurs européens.

gcloud components install alpha --quiet
gcloud config set run/region europe-west1
gcloud config set run/platform managed

Pour la partie multi-région que nous verrons à l’étape 5, gardez une seconde région en tête. europe-west1 (Belgique) et europe-west3 (Francfort) forment une paire cohérente pour une architecture haute disponibilité centrée sur l’Europe, avec une latence inter-région raisonnable.

Étape 3 : construire l’image du service d’exemple

Notre projet fil rouge est un petit service qui reçoit des extraits de code Python soumis par un agent IA, les exécute dans une sandbox, puis renvoie le résultat. Voici la structure minimale.

mkdir cloud-run-sandbox-demo && cd cloud-run-sandbox-demo
cat > requirements.txt << 'EOF'
flask==3.1.0
gunicorn==23.0.0
EOF

cat > main.py << 'EOF'
import subprocess
from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route("/execute", methods=["POST"])
def execute():
    code = request.json.get("code", "")
    # L'exécution réelle passe par la sandbox, voir étape 6
    result = subprocess.run(
        ["python3", "-c", code],
        capture_output=True, text=True, timeout=5
    )
    return jsonify({"stdout": result.stdout, "stderr": result.stderr})

@app.route("/health")
def health():
    return jsonify({"status": "ok"}), 200

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)
EOF

cat > Dockerfile << 'EOF'
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY main.py .
CMD ["gunicorn", "-b", "0.0.0.0:8080", "-w", "2", "main:app"]
EOF

Ce code volontairement simplifié exécute le code reçu directement via subprocess, ce qui est exactement le genre de pattern dangereux que les sandboxes existent pour corriger. Nous le remplacerons par un appel sandboxé à l'étape 6. Construisez et poussez l'image vers Artifact Registry.

gcloud artifacts repositories create sandbox-demo \
  --repository-format=docker --location=europe-west1

gcloud builds submit --tag \
  europe-west1-docker.pkg.dev/sandbox-tuto-2026/sandbox-demo/agent-service:v1

Partie 2 : déployer et isoler le code avec les sandboxes

Étape 4 : déployer le service Cloud Run en multi-région

Déployez le service dans les deux régions choisies. Chaque déploiement crée une révision indépendante, ce qui vous permettra ensuite de configurer un failover automatique entre elles.

gcloud run deploy agent-service \
  --image=europe-west1-docker.pkg.dev/sandbox-tuto-2026/sandbox-demo/agent-service:v1 \
  --region=europe-west1 \
  --allow-unauthenticated \
  --memory=512Mi --cpu=1 --min-instances=0 --max-instances=10

gcloud run deploy agent-service \
  --image=europe-west1-docker.pkg.dev/sandbox-tuto-2026/sandbox-demo/agent-service:v1 \
  --region=europe-west3 \
  --allow-unauthenticated \
  --memory=512Mi --cpu=1 --min-instances=0 --max-instances=10

Sortie type après un déploiement réussi :

Deploying container to Cloud Run service [agent-service] in project [sandbox-tuto-2026] region [europe-west1]
✓ Deploying new service... Done.
Service URL: https://agent-service-xxxxx-ew.a.run.app

Étape 5 : activer Service Health et le failover automatique

Service Health, passé en disponibilité générale cet été, détecte les perturbations régionales à partir de probes de disponibilité (readiness) au niveau des instances et bascule automatiquement le trafic vers une région saine. C'est ce que Google appelle la configuration en « deux clics », ici traduite en commandes.

gcloud run services update agent-service \
  --region=europe-west1 \
  --update-annotations=run.googleapis.com/health-check-path=/health

gcloud alpha run multi-region-services create agent-service-global \
  --regions=europe-west1,europe-west3 \
  --service-mapping=europe-west1=agent-service,europe-west3=agent-service \
  --failover-policy=automatic

Une fois activé, un incident sur europe-west1 bascule le trafic vers europe-west3 sans intervention manuelle, avec un délai de détection typiquement inférieur à la minute selon la documentation officielle de Cloud Run.

Étape 6 : configurer une sandbox pour exécuter du code non fiable

Voici le cœur du tutoriel. Remplacez l'appel direct à subprocess par un appel à une sandbox lancée depuis l'intérieur de l'instance Cloud Run. Le SDK sandbox expose une API qui spawn un environnement isolé, y exécute le code, puis détruit l'environnement.

from flask import Flask, request, jsonify
from google.cloud.run.sandbox import Sandbox

app = Flask(__name__)

@app.route("/execute", methods=["POST"])
def execute():
    code = request.json.get("code", "")
    with Sandbox.create(timeout_seconds=5, memory_mb=128) as box:
        result = box.run_python(code)
    return jsonify({
        "stdout": result.stdout,
        "stderr": result.stderr,
        "sandbox_id": result.sandbox_id
    })

@app.route("/health")
def health():
    return jsonify({"status": "ok"}), 200

Redéployez le service avec le flag qui active le support sandbox sur l'instance.

gcloud alpha run deploy agent-service \
  --image=europe-west1-docker.pkg.dev/sandbox-tuto-2026/sandbox-demo/agent-service:v2 \
  --region=europe-west1 \
  --sandbox-launcher \
  --execution-environment=gen2

Le flag --sandbox-launcher autorise l'instance à instancier des sandboxes, tandis que --execution-environment=gen2 est requis car les sandboxes s'appuient sur le second environnement d'exécution de Cloud Run, plus proche d'une VM complète que la génération 1.

Étape 7 : étendre les sandboxes aux jobs et worker pools

Jusqu'au 5 août 2026, les sandboxes ne fonctionnaient que dans des services Cloud Run classiques, ceux qui répondent à des requêtes HTTP. Cette limite excluait tout le traitement batch. Depuis cette extension, un job Cloud Run peut lui aussi lancer des sandboxes, ce qui couvre par exemple le cas d'un pipeline qui exécute des scripts générés par un agent sur un lot de fichiers.

gcloud alpha run jobs create batch-code-review \
  --image=europe-west1-docker.pkg.dev/sandbox-tuto-2026/sandbox-demo/agent-service:v2 \
  --region=europe-west1 \
  --sandbox-launcher \
  --execution-environment=gen2 \
  --tasks=10 \
  --max-retries=1

Chacune des dix tâches du job peut lancer sa propre sandbox indépendante, ce qui isole chaque exécution des neuf autres même si elles tournent en parallèle sur des instances distinctes.

Étape 8 : ajouter un worker pool pour le traitement asynchrone

Les worker pools Cloud Run, désormais en disponibilité générale, ciblent les workloads pull-based : un worker qui consomme des messages Pub/Sub en continu, par exemple, plutôt que de répondre à des requêtes HTTP entrantes. C'est le pattern idéal pour une file d'attente de code à évaluer soumise par des utilisateurs.

gcloud pubsub topics create code-eval-queue
gcloud pubsub subscriptions create code-eval-sub --topic=code-eval-queue

gcloud alpha run worker-pools create code-eval-worker \
  --image=europe-west1-docker.pkg.dev/sandbox-tuto-2026/sandbox-demo/agent-service:v2 \
  --region=europe-west1 \
  --sandbox-launcher \
  --execution-environment=gen2 \
  --min-instances=1 --max-instances=5

Contrairement à un service HTTP qui peut descendre à zéro instance, gardez au moins une instance active (--min-instances=1) sur un worker pool pull-based, sinon il ne consommera jamais les messages en attente.

Étape 9 : sécuriser les sandboxes avec IAM et comptes de service dédiés

La sandbox isole l'exécution, mais un compte de service mal configuré reste un risque. Créez un compte de service séparé, dédié uniquement à l'instance principale, sans aucun rôle IAM au-delà du strict nécessaire pour écrire des logs.

gcloud iam service-accounts create agent-service-runner \
  --display-name="Agent Service - compte restreint"

gcloud projects add-iam-policy-binding sandbox-tuto-2026 \
  --member="serviceAccount:[email protected]" \
  --role="roles/logging.logWriter"

gcloud run services update agent-service \
  --region=europe-west1 \
  --service-account=agent-service-runner@sandbox-tuto-2026.iam.gserviceaccount.com

Point clé à retenir : le processus sandboxé n'hérite pas automatiquement des identifiants du compte de service de l'instance hôte. C'est précisément ce qui empêche un agent compromis de voler le jeton du compte de service principal, même s'il parvient à exécuter du code arbitraire dans la sandbox.

Partie 3 : résilience, observabilité et maîtrise des coûts

Étape 10 : mettre en place logs et alertes sur les sandboxes

Chaque exécution sandbox génère un identifiant unique que vous pouvez utiliser pour corréler les logs. Créez une alerte Cloud Monitoring qui se déclenche si le taux d'erreurs de sandbox dépasse un seuil, signe potentiel d'une tentative d'exploitation ou d'un bug dans le code généré par l'agent.

gcloud logging metrics create sandbox_errors \
  --description="Erreurs d'exécution sandbox" \
  --log-filter='resource.type="cloud_run_revision"
    jsonPayload.sandbox_id!="" severity>=ERROR'

gcloud alpha monitoring policies create \
  --notification-channels=VOTRE_CANAL_NOTIFICATION \
  --display-name="Taux d'erreur sandbox élevé" \
  --condition-display-name="Erreurs sandbox > 5/min" \
  --condition-threshold-value=5 \
  --condition-threshold-duration=60s

Étape 11 : tester l'isolation et simuler un incident

Avant de mettre quoi que ce soit en production, validez concrètement que l'isolation fonctionne. Envoyez un extrait de code qui tente d'accéder au système de fichiers de l'hôte ou de lire les métadonnées de l'instance : cela doit échouer.

curl -X POST https://agent-service-xxxxx-ew.a.run.app/execute \
  -H "Content-Type: application/json" \
  -d '{"code": "import urllib.request; print(urllib.request.urlopen(\"http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token\", headers={\"Metadata-Flavor\": \"Google\"}).read())"}'

Réponse attendue si l'isolation est correctement configurée :

{"stdout": "", "stderr": "urllib.error.URLError: ", "sandbox_id": "sbx-a1b2c3d4"}

Si au contraire la requête aboutit et renvoie un jeton, votre sandbox n'est pas correctement isolée du réseau interne de l'instance hôte : reprenez l'étape 6 et vérifiez que le flag --sandbox-launcher est bien actif sur la révision en cours de trafic, pas seulement sur une révision précédente.

Étape 12 : estimer et maîtriser les coûts

Les sandboxes ne facturent pas de ligne séparée sur votre facture : elles consomment du CPU et de la mémoire au sein de l'allocation déjà attribuée à l'instance Cloud Run qui les lance. Le coût additionnel réel vient plutôt du fait que vous devez provisionner un peu plus de mémoire par instance pour laisser de la marge à la sandbox, et du temps CPU consommé pendant l'exécution du code sandboxé.

Ressource	Configuration sans sandbox	Configuration avec sandbox	Impact budgétaire estimé
Mémoire par instance	256 Mi	512 Mi (marge sandbox)	+100 % sur la ligne mémoire
Temps CPU par requête	~50 ms	~50 ms + durée d'exécution du code	Variable selon le code exécuté
Instances min (worker pool)	0	1 (pull-based)	Coût de veille permanent
Cloud Run jobs (batch sandboxé)	Facturé à la tâche	Facturé à la tâche + sandbox	Proportionnel au nombre de tâches
Cloud Monitoring / alertes	Inclus (paliers gratuits)	Inclus (paliers gratuits)	Neutre pour un usage modéré

Pour un service à faible trafic comme celui de ce tutoriel, le surcoût lié aux sandboxes reste marginal, de l'ordre de quelques centimes par jour. L'enjeu principal n'est pas le budget mais le dimensionnement mémoire : sous-provisionner la mémoire d'une instance qui lance des sandboxes est la cause la plus fréquente d'échecs silencieux, un point que nous détaillons dans la section suivante.

Exemple de projet complet : agent IA sécurisé de bout en bout

En assemblant les douze étapes précédentes, vous obtenez une architecture à trois composants qui couvre les scénarios réels d'un agent IA en production : un service HTTP pour les requêtes synchrones, un job pour le traitement batch, et un worker pool pour la file d'attente asynchrone. Les trois partagent la même image de conteneur et le même compte de service restreint, mais chacun lance ses propres sandboxes indépendamment.

agent-service (europe-west1 + europe-west3, failover automatique) : reçoit les requêtes synchrones d'un agent conversationnel et exécute le code généré en sandbox avant de renvoyer le résultat.
batch-code-review (job, 10 tâches parallèles) : traite un lot de fichiers soumis en une fois, chaque tâche isolée dans sa propre sandbox.
code-eval-worker (worker pool, min 1 instance) : consomme en continu une file Pub/Sub de code à évaluer, pour les cas où la latence synchrone n'est pas critique.

Ce découpage en trois composants suit exactement la logique que Google met en avant dans ses notes de version Cloud Run pour l'été 2026 : unifier les patterns HTTP, batch et pull-based sur une même plateforme serverless, tout en gardant une isolation cohérente d'un composant à l'autre.

Pour automatiser le déploiement de ces trois composants plutôt que de répéter les commandes gcloud à chaque mise à jour, intégrez-les dans un pipeline Cloud Build déclenché à chaque push sur votre dépôt. Un fichier cloudbuild.yaml minimal peut construire l'image une seule fois, puis la propager vers le service, le job et le worker pool en trois étapes séquentielles. Cela garantit que les trois composants tournent toujours sur la même version de code, ce qui évite les incohérences de comportement entre la sandbox du service HTTP et celle du worker pool si une correction de sécurité vient d'être appliquée.

Pièges courants à éviter

Ces erreurs reviennent régulièrement lors d'un premier déploiement de sandboxes Cloud Run. Les connaître en amont vous fait gagner un temps considérable.

Déployer sans --execution-environment=gen2. Les sandboxes exigent la génération 2 de l'environnement d'exécution Cloud Run. Sans ce flag, la commande de déploiement peut réussir mais les appels sandbox échoueront silencieusement au runtime.
Sous-dimensionner la mémoire de l'instance hôte. Une sandbox consomme de la mémoire prélevée sur l'allocation de l'instance qui la lance. Avec seulement 256 Mi alloués, une sandbox de 128 Mi laisse trop peu de marge à l'application principale, provoquant des OOM kill imprévisibles.
Oublier le timeout sur la sandbox. Un code généré par un agent peut contenir une boucle infinie. Sans timeout_seconds explicite, une sandbox mal configurée peut monopoliser l'instance jusqu'à la limite de timeout globale de la requête HTTP, ce qui dégrade l'expérience pour les autres requêtes.
Donner au compte de service de l'instance des rôles trop larges. Même avec une sandbox parfaitement isolée, un compte de service principal doté du rôle Éditeur transforme n'importe quelle faille de configuration en risque majeur. Restez sur le principe du moindre privilège, comme à l'étape 9.
Confondre les anciennes sandboxes gVisor et les nouvelles Cloud Run Sandboxes. Cloud Run utilise gVisor depuis des années pour isoler les conteneurs entre eux au niveau de l'hôte. Les Cloud Run Sandboxes sont une couche supplémentaire, à l'intérieur du conteneur, pour isoler du code non fiable du reste de l'application. Ce ne sont pas deux noms pour la même chose.
Ne pas tester le failover avant un vrai incident. Configurer Service Health ne suffit pas : simulez une coupure régionale en environnement de test pour vérifier le délai de bascule réel et l'absence d'effet de bord sur les sessions en cours.
Laisser un worker pool à zéro instance minimum. Un pattern pull-based comme Pub/Sub ne se réveille pas tout seul : sans --min-instances=1, les messages s'accumulent dans la file sans jamais être traités.

Dépannage : problèmes fréquents et solutions

Voici les incidents les plus signalés lors des premières semaines d'usage des sandboxes en preview, avec la cause probable et la correction associée. Gardez en tête que la fonctionnalité étant encore en préversion publique, certains de ces comportements peuvent évoluer d'une mise à jour de gcloud à l'autre : si un symptôme ne correspond à aucun de ces cas après vérification, consultez la page des notes de version Cloud Run avant de conclure à un bug de votre côté.

Erreur « sandbox launcher not enabled » au déploiement. Le flag --sandbox-launcher n'a pas été appliqué à la révision active. Vérifiez avec gcloud run revisions list que la révision qui reçoit 100 % du trafic est bien celle qui porte le flag.
Sandbox qui met plusieurs secondes à démarrer au lieu de millisecondes. C'est généralement le signe d'un cold start de l'instance elle-même, pas de la sandbox. Augmentez temporairement --min-instances à 1 pour isoler la cause.
Échec « memory limit exceeded » côté sandbox. La mémoire allouée à la sandbox dépasse ce qui reste disponible sur l'instance après réservation pour l'application principale. Réduisez memory_mb dans l'appel Sandbox.create() ou augmentez la mémoire globale de l'instance.
Le failover multi-région ne se déclenche jamais lors des tests. Vérifiez que le chemin de health check configuré à l'étape 5 correspond exactement à la route exposée par votre service (/health dans notre exemple), sensible à la casse.
Messages Pub/Sub qui s'accumulent sans être traités par le worker pool. Confirmez que le worker pool a bien au moins une instance active et que le compte de service associé dispose du rôle roles/pubsub.subscriber sur la souscription.
Logs de sandbox absents de Cloud Logging. Les logs générés à l'intérieur d'une sandbox ne remontent pas automatiquement comme ceux du conteneur hôte. Assurez-vous que votre code sandbox écrit explicitement sur stdout/stderr, capturés ensuite par l'appel Sandbox.create() côté hôte.
Erreur d'authentification lors de l'appel à gcloud alpha run. Les commandes alpha nécessitent parfois une ré-authentification distincte. Exécutez gcloud auth login --update-adc puis relancez la commande.
Job batch qui échoue systématiquement sur certaines tâches seulement. Vérifiez que chaque tâche dispose d'assez de mémoire pour sa propre sandbox : sur un job à 10 tâches parallèles partageant les mêmes instances, une répartition inégale de la charge peut faire échouer les tâches les plus tardives.
Coûts qui grimpent plus vite que prévu sur le worker pool. Un --min-instances=1 permanent facture une instance en veille 24 h/24. Si votre file Pub/Sub reste souvent vide, envisagez un déclenchement par Cloud Scheduler plutôt qu'un worker pool toujours actif.

Astuces avancées pour aller plus loin

Une fois la base posée, plusieurs pistes permettent de tirer davantage parti de l'écosystème Cloud Run 2026. D'abord, le remote MCP server pour Cloud Run, désormais en disponibilité générale, permet à des agents IA d'appeler et de déployer des services Cloud Run via le Model Context Protocol sans que vous ayez à opérer vous-même un serveur MCP. Cela s'intègre naturellement avec l'architecture sandboxée de ce tutoriel : l'agent pilote le déploiement via MCP, le code qu'il génère s'exécute en sandbox.

Ensuite, si vos charges d'inférence deviennent plus lourdes, les GPU NVIDIA RTX PRO 6000 Blackwell Server Edition sur Cloud Run, en disponibilité générale depuis Next '26, combinent scaling automatique et facturation à l'usage pour des workloads d'IA générative directement dans ce même modèle serverless. Un service qui bascule entre sandboxes CPU pour le code léger et instances GPU pour l'inférence lourde reste une architecture Cloud Run cohérente de bout en bout.

Enfin, pour les équipes qui gèrent déjà des clusters Kubernetes, GKE propose désormais un mécanisme comparable via l'Autopilot compute classes, disponible sur les clusters Standard depuis KubeCon EU 2026. Si votre organisation a besoin d'un plan de contrôle Kubernetes commun pour d'autres workloads en plus de vos services Cloud Run, ce rapprochement entre les deux plateformes mérite d'être évalué plutôt que de dupliquer la logique d'isolation sur deux systèmes séparés.

Un dernier conseil, souvent ignoré jusqu'au premier incident : documentez le comportement attendu de vos sandboxes dans un test automatisé qui tourne à chaque déploiement, sur le modèle du script d'isolation de l'étape 11. Un test qui vérifie que l'accès aux métadonnées de l'instance échoue bien, intégré à votre pipeline Cloud Build, transforme une vérification manuelle ponctuelle en garde-fou permanent. C'est la différence entre découvrir une régression d'isolation lors d'un audit de sécurité, et la bloquer avant même qu'elle atteigne la production.

Cloud Run Sandboxes face aux alternatives

Cloud Run Sandboxes n'est pas la seule option pour isoler du code non fiable sur GCP. Le tableau suivant compare les approches les plus courantes, à date d'août 2026.

Approche	Niveau d'isolation	Latence de démarrage	Cas d'usage typique
Cloud Run Sandboxes	Environnement isolé intra-instance	Millisecondes	Code IA généré à la volée, requêtes synchrones et batch
GKE Autopilot avec Agent Sandbox	Pod Kubernetes isolé (gVisor/Kata)	Secondes	Isolation forte pour agents dans un cluster déjà existant
Cloud Functions (2e génération)	Isolation par instance, sans sandbox interne	Centaines de millisecondes à secondes	Fonctions événementielles simples, sans exécution de code tiers
Machine virtuelle Compute Engine dédiée	Isolation matérielle complète	Dizaines de secondes à minutes	Charges très sensibles nécessitant une isolation maximale

Pour la grande majorité des cas d'usage d'agents IA en 2026, la combinaison latence en millisecondes et absence de gestion d'infrastructure fait des Cloud Run Sandboxes le point de départ le plus pragmatique, avec GKE Autopilot comme option de repli si vous avez déjà un cluster à gouverner pour d'autres raisons.

Un critère de décision souvent négligé est la fréquence d'exécution. Si votre application lance des dizaines de sandboxes par seconde en pointe, la latence de démarrage en millisecondes de Cloud Run Sandboxes fait une différence mesurable sur l'expérience utilisateur par rapport à un pod Kubernetes qui met plusieurs secondes à s'initialiser. À l'inverse, si l'isolation sert à traiter des lots ponctuels et peu fréquents, quelques secondes de démarrage supplémentaires sur GKE Autopilot n'ont pas le même impact, et l'intégration avec un cluster existant peut alors peser davantage dans la balance que la latence brute.

Conformité RGPD et souveraineté des données en Europe

Pour une équipe basée en France ou ailleurs en Europe, l'isolation technique ne suffit pas à elle seule à répondre aux obligations du RGPD. Une sandbox qui exécute du code généré par un agent IA peut manipuler des données personnelles, que ce soit dans les extraits de code eux-mêmes, dans les fichiers qu'elle traite, ou dans les journaux qu'elle produit. Trois points méritent une attention particulière avant de mettre ce type d'architecture en production.

D'abord, la localisation des données. En choisissant europe-west1 et europe-west3 comme régions de déploiement, vous gardez le traitement des requêtes, y compris l'exécution en sandbox, dans des centres de données situés dans l'Union européenne. Cela ne dispense pas de vérifier votre contrat de traitement des données avec Google Cloud (le Cloud Data Processing Addendum), mais cela simplifie l'argumentaire face à un client ou un auditeur qui demande où résident physiquement les données transitant par vos agents IA.

Ensuite, la rétention des logs. Les logs générés par les sandboxes, notamment ceux mis en place à l'étape 10, peuvent contenir des fragments de code ou de données envoyées par les utilisateurs. Configurez une politique de rétention explicite sur vos buckets Cloud Logging plutôt que de laisser la valeur par défaut, et excluez des champs sensibles du filtre de log si votre cas d'usage manipule des données personnelles identifiables.

Enfin, la documentation de l'analyse d'impact. Si votre service sandboxé traite des données personnelles à grande échelle, une analyse d'impact relative à la protection des données (AIPD) reste recommandée par la CNIL pour ce type de traitement automatisé, même lorsque l'infrastructure technique limite déjà les risques de fuite grâce à l'isolation sandbox. Documenter que l'isolement technique constitue une mesure de sécurité au sens de l'article 32 du RGPD renforce ce dossier.

Foire aux questions

Les Cloud Run Sandboxes sont-elles disponibles en production ?

Elles sont en préversion publique depuis le 21 juillet 2026, étendue aux jobs et worker pools le 5 août 2026. Une préversion publique GCP peut techniquement être utilisée en production, mais Google ne garantit pas encore de niveau de service (SLA) formel tant que la fonctionnalité n'est pas passée en disponibilité générale.

Combien coûte l'utilisation des sandboxes sur Cloud Run ?

Il n'existe pas de ligne de facturation séparée : la sandbox consomme du CPU et de la mémoire déjà comptabilisés dans l'instance Cloud Run qui la lance. Le coût réel dépend donc surtout du dimensionnement mémoire supplémentaire que vous provisionnez pour laisser de la marge à la sandbox, détaillé à l'étape 12 de ce tutoriel.

Quelle différence entre gVisor et les Cloud Run Sandboxes ?

gVisor isole chaque conteneur Cloud Run des autres conteneurs et de l'hôte physique, au niveau de l'infrastructure Google. Les Cloud Run Sandboxes ajoutent une isolation supplémentaire à l'intérieur d'un même conteneur, pour séparer le code non fiable exécuté par votre application du reste de cette même application.

Peut-on utiliser les sandboxes avec un langage autre que Python ?

Oui. L'API sandbox n'est pas limitée à Python : elle permet d'exécuter n'importe quel binaire ou interpréteur présent dans l'image de la sandbox. Ce tutoriel utilise Python par simplicité, mais le même pattern fonctionne pour du JavaScript via Node.js ou pour des scripts shell, tant que l'environnement sandbox embarque les runtimes nécessaires.

Faut-il migrer vers GKE Autopilot si on utilise déjà des sandboxes sur Cloud Run ?

Pas nécessairement. Les deux plateformes répondent à des besoins différents. Cloud Run reste le choix le plus simple pour des services stateless sans gestion de cluster. GKE Autopilot devient pertinent si vous avez besoin d'un plan de contrôle Kubernetes commun pour d'autres workloads, ou si vous utilisez déjà des outils spécifiques à l'écosystème Kubernetes.

Le failover multi-région fonctionne-t-il entre régions hors Europe ?

Oui, la fonctionnalité Service Health n'est pas limitée aux régions européennes. Ce tutoriel utilise europe-west1 et europe-west3 pour une audience française et européenne, mais le même mécanisme fonctionne avec n'importe quelle paire de régions Cloud Run disponibles dans votre organisation.

Les sandboxes protègent-elles contre l'exfiltration de données via le réseau ?

L'isolation limite l'accès direct au système de fichiers et aux identifiants de l'instance hôte, mais elle ne remplace pas des règles de sortie réseau (egress) restrictives si vous voulez empêcher toute connexion sortante non désirée depuis le code sandboxé. Combinez sandboxes et contrôles réseau VPC Service Controls pour une défense en profondeur.

Que se passe-t-il si une sandbox dépasse son timeout ?

La sandbox est terminée de force et l'appel retourne une erreur de timeout à l'application hôte, sans affecter le reste de l'instance ni les autres requêtes en cours. C'est précisément l'un des bénéfices recherchés : un code qui boucle indéfiniment reste confiné à sa propre sandbox plutôt que de bloquer l'ensemble du service.

Sujets connexes sur shattered.io

Sources et documentation officielle utilisées pour ce tutoriel : les notes de version Cloud Run, l'annonce Cloud Run à Next '26, le récapitulatif des nouveautés Google Cloud, le compte-rendu GKE à KubeCon EU 2026 et la documentation de référence Cloud Run.

Google Cloud Run Sandboxes : 12 Étapes, 45 Min [2026]