Où faire tourner un agent IA qui exécute du code

Tant qu'une IA se contente de répondre, la question de l'hébergement se règle en une ligne de contrat. Le jour où elle écrit un script, ouvre un terminal ou modifie une table, tout change : ce n'est plus un outil de rédaction, c'est un utilisateur de plus dans votre système. En comité, la question arrive vite, et elle est bonne. Voici comment j'y réponds, du bac à sable jusqu'aux droits que je refuse de donner, avant même de parler de passage en production.

La question qui tombe dans les cinq premières minutes

Elle se formule toujours pareil : « ça tourne où ? » Derrière, trois inquiétudes empilées, et elles sont légitimes. Ce que cette chose peut lire. Ce qu'elle peut casser. Et qui répond si elle casse. Le réflexe est de traiter le sujet comme de la sécurité applicative, à régler une fois la démo passée. C'est l'inverse : la réponse détermine l'architecture, donc elle se donne avant la première ligne de code. Un agent sans lieu d'exécution défini finit toujours sur la machine de quelqu'un.

Le poste du développeur, la mauvaise réponse par défaut

Elle s'installe quand personne n'a tranché, et elle a l'air inoffensive. Le poste d'un développeur contient pourtant ses clés SSH, ses jetons d'API, ses accès aux dépôts, son historique de commandes et souvent une connexion ouverte vers la prod. Vous ne donnez pas un environnement d'exécution à l'agent, vous lui donnez un contexte d'administrateur avec tout ce qui traîne autour. La vulnérabilité référencée sous CVE-2026-22708 décrit exactement ce scénario : l'empoisonnement de l'environnement d'exécution d'un éditeur assisté par IA, à travers des commandes pourtant autorisées. Un poste de travail n'est pas un bac à sable.

Où ça tourne : microVM ou conteneur durci

La bonne réponse tient en une phrase : ailleurs, et pour un temps borné. Concrètement, l'agent s'exécute dans une microVM ou dans un conteneur durci, créé pour la tâche et détruit après elle. Ce n'est plus un montage artisanal : en avril 2026, l'Agents SDK d'OpenAI a intégré nativement le support de bac à sable avec sept fournisseurs officiels, dont Cloudflare, E2B, Modal et Vercel. Restent les quatre propriétés qui font qu'un bac à sable en est vraiment un.

• Isolation forte : une microVM pose une frontière au niveau du noyau, là où un conteneur standard partage celui de l'hôte.
• Durée de vie bornée : l'environnement naît avec la tâche et meurt avec elle. Un shell qui reste ouvert accumule un état que plus personne ne relit.
• Rien de persistant : pas de volume monté par confort, pas de cache de jetons, pas de configuration héritée. Ce qui doit survivre sort par un chemin explicite.
• Ressources plafonnées : processeur, mémoire, durée maximale. Une boucle qui part en vrille doit coûter un plafond connu d'avance.

Ce qui n'entre jamais dans le bac à sable

• Les secrets de production : mots de passe de base, clés de signature, identifiants de paiement. Un agent qui travaille sur du code n'a aucune raison de les voir.
• Les identifiants à longue durée : on émet un jeton court, pour la tâche, périmé après. Un jeton qui ne meurt jamais reste valable le jour où il fuit.
• L'écriture par défaut : la lecture d'abord, l'écriture demandée cas par cas. L'inverse se justifie surtout par le confort de celui qui installe.
• La configuration du poste : historique de commandes, profils cloud, clés SSH montées dans le conteneur. Ce sont elles qui élargissent un incident.

Le réseau en liste blanche, ce qui coupe l'exfiltration

Le bac à sable protège votre système de l'agent. Le réseau, lui, protège vos données du dehors. Par défaut, la sortie est grande ouverte : le paquet installé au passage, la requête qui emporte un fichier. On inverse la règle. Sortie fermée, puis une liste blanche de destinations, écrite et relue. C'est ce qui attaque la trifecta mortelle décrite par les chercheurs en sécurité des agents : des données privées, du contenu non fiable et un canal de sortie réunis dans le même processus. Le top dix des applications agentiques publié en 2026 par l'OWASP, la référence ouverte en sécurité applicative, rattache l'injection de prompt à six de ses dix catégories, et le mécanisme est détaillé dans prompt injection, expliquée. Une liste blanche ne supprime pas le canal de sortie, elle le réduit aux destinations que vous avez acceptées, et c'est ce qui ramène une injection à un dérapage local.

Une identité par agent, et une révocation qui marche

Un agent agit, donc il doit être identifiable. Ça veut dire une identité propre, distincte de celle de la personne qui l'a lancé. Le constat de terrain est le même partout où je regarde : beaucoup d'intégrations tournent avec le jeton personnel d'un développeur, parce que c'était le plus rapide le jour où il fallait que ça marche. Ce n'est pas un scandale, c'est un point d'audit immédiat. Je ne peux pas vous dire à quelle fréquence ça finit mal : personne ne publie ces chiffres, moi compris. La spécification MCP du 28 juillet 2026 durcit d'ailleurs l'authentification, jusqu'à déprécier l'enregistrement dynamique de client (sécuriser les serveurs MCP).

• Une identité par agent : pas un compte partagé, pas le jeton d'un humain. Un journal ne sert à rien s'il ne sait pas dire qui a agi.
• Les droits strictement nécessaires : le dépôt et l'environnement de la tâche, pas le reste du système d'information.
• Un journal exploitable : chaque appel d'outil, ses arguments, son résultat. Sans ça, l'analyse après incident se fait de mémoire.
• Une révocation testée : couper l'agent en une action, et vérifier chaque trimestre que la coupure fonctionne. Une révocation jamais essayée n'en est pas une.

Le même bac à sable, sur une infrastructure française

Rien de ce qui précède n'oblige à sortir d'Europe. Une microVM, une liste blanche réseau et un journal se déploient aussi bien chez un hébergeur français que chez un fournisseur américain : ce sont des propriétés d'architecture, pas un produit à acheter. L'isolation sert même l'argument souverain : elle rend le lieu d'exécution explicite. Le drapeau sur le datacenter ne dit rien de ce que l'agent peut atteindre depuis l'intérieur. C'est l'isolation qui le dit. Le lieu d'exécution est une décision d'architecture, au même titre que l'hébergement de vos modèles.

L'irréversible : la validation humaine et l'interdit pur

Un agent ne doit pas pouvoir faire ce que vous ne sauriez pas défaire. Tout le reste se discute.

Il reste à trier les actions, et trois catégories suffisent : ce que l'agent fait seul, ce qui passe par une validation humaine explicite, et ce qui lui est interdit sans exception configurable. Une suppression de base, une migration de schéma, un déploiement en production : validation, ou interdit. En 2025, l'agent de code de Replit a supprimé une base de production pendant un gel de code. Un droit d'écriture non borné rend ça possible. Ce tri prend une journée, parfois deux, et il n'impressionne personne en démo : je ne le vends pas comme un livrable, je le fais avant le reste, avec les garde-fous de la fiabilité en production. Si un agent doit bientôt exécuter du code chez vous et que la question du comité n'a pas de réponse écrite, un premier échange suffit souvent à l'écrire, sans engagement : parlons-en.