AWS exécute Claude Code à distance : une microVM pour chaque tâche

Un agent de programmation distant répond à un problème bien connu : Claude Code en local est utile tant que l’ordinateur portable reste ouvert, que l’environnement n’est pas occupé et que la tâche n’exige pas une longue série de tests. AWS propose de déplacer ce processus vers Amazon Bedrock AgentCore. Le développeur décrit la tâche, ferme son ordinateur, puis récupère plus tard un brouillon de pull request contenant les modifications et le résultat des vérifications.

L’intérêt ne réside pas simplement dans l’exécution de Claude dans le cloud. La valeur vient de l’environnement complet : une instance distincte pour chaque tâche, un accès temporaire à GitHub, des connexions privées aux services AWS, un rôle IAM restreint et une revue humaine obligatoire. L’agent peut écrire du code, mais il ne peut pas le fusionner de manière autonome dans la branche principale.

Déroulement d’une tâche

Prenons un petit bug : l’API renvoie une erreur 500 au lieu d’une erreur 404 lorsqu’un enregistrement est introuvable. Le développeur envoie la description via le plug-in Claude Code ou la console web. La requête est signée avec des identifiants AWS, contrôlée par Amazon Bedrock Guardrails, enregistrée dans DynamoDB, puis placée dans une file SQS.

Le répartiteur lance une session AgentCore Runtime distincte. Chaque tâche obtient sa propre microVM avec processeur, mémoire et système de fichiers isolés. Claude Code CLI, Claude Agent SDK, git et make y sont déjà installés. L’agent reçoit un jeton GitHub temporaire, clone le dépôt et consulte les indications conservées lors des exécutions précédentes de ce projet.

Claude Opus élabore ensuite un plan, tandis que Claude Sonnet applique les modifications. L’agent exécute les commandes d’installation et de test déclarées par le dépôt lui-même. Opus vérifie ensuite le résultat et, si nécessaire, renvoie le travail pour un nouveau cycle. Le système prévoit au maximum trois tentatives. Enfin, l’agent crée une branche au format agent/<taskId> et ouvre une pull request en précisant la commande de vérification, son code de sortie et le nombre de tentatives. Si les tests échouent, la pull request reste à l’état de brouillon.

Où se situe la sécurité

Le conteneur ne reçoit aucune clé AWS permanente. Les appels aux modèles passent par Amazon Bedrock avec les identifiants IAM temporaires de l’environnement d’exécution. La GitHub App n’est installée que dans les dépôts sélectionnés, et le jeton remis à l’agent reste valide jusqu’à 8 heures. Les autorisations sont limitées au contenu du dépôt et aux pull requests, tandis que les commits sont signés avec le compte de l’application.

Le réseau est lui aussi restreint : l’environnement fonctionne dans des sous-réseaux VPC privés et accède à Bedrock ainsi qu’aux autres services AWS via des points de terminaison privés. Un accès à Internet reste nécessaire pour GitHub et les registres de paquets. Dans l’exemple, les domaines du fournisseur du modèle sont bloqués au moyen de DNS Firewall. AWS prévient toutefois clairement qu’une liste de domaines interdits ne contrôle pas l’intégralité du trafic HTTPS. En production, une liste d’autorisation appliquée au niveau d’AWS Network Firewall est nécessaire.

Guardrails analyse la tâche initiale pour détecter les tentatives de piratage, les requêtes malveillantes et les secrets. En revanche, les fichiers du dépôt et la sortie des commandes ne passent pas par ce contrôle. Une instruction malveillante dissimulée dans un README ou un script de build demeure donc un risque. L’isolation par microVM protège les autres tâches et l’ordinateur du développeur, mais elle ne rend pas sûr un code non fiable.

Ce que l’équipe doit faire

Il est préférable de commencer par des tâches étroitement délimitées dans un dépôt de confiance : petite fonctionnalité, correction de bug ou ajout de tests. Le projet doit proposer des commandes setup et test reproductibles, et la branche principale doit être protégée par une revue obligatoire. Les recherches exploratoires et les grands refactorings sont moins adaptés : l’agent est limité à trois tentatives et il est plus difficile de le piloter pendant l’exécution qu’une session locale.

Cette solution a également un coût. Le déploiement prend 15 à 25 minutes, et l’enregistrement d’un dépôt demande encore 8 à 12 minutes. NAT Gateway, les points de terminaison réseau, WAF, Cognito, DNS Firewall, le stockage des images et les journaux restent facturés même en l’absence de tâches actives. Un budget de 200 dollars se contente d’envoyer une notification et n’interrompt pas les dépenses.

La conclusion pratique est simple : il ne s’agit pas de « Claude Code sur un serveur distant », mais d’un modèle de fabrique administrée de pull requests. Cette architecture intéressera les équipes qui ont besoin de tâches parallèles en arrière-plan, d’une piste d’audit dans AWS et d’une isolation vis-à-vis des ordinateurs de travail. Elle ne doit toutefois être déployée qu’avec une protection des branches, un contrôle du trafic sortant, des plafonds de dépenses et une règle stricte : l’agent propose les modifications, l’humain décide de ce qui entre en production.