Pourquoi donner à votre agent une VM jetable

Pourquoi une VM jetable est préférable à votre ordinateur portable

Donnez à un agent de programmation une VM jetable : dans le pire des cas, il détruira une machine que vous pouvez reconstruire en dix minutes. L’agent obtient toujours root, installe toujours des paquets et exécute toujours la suite de tests sans demander votre autorisation à chaque étape. La différence tient à l’endroit où les dégâts se produisent. Sur un ordinateur portable, l’agent partage votre répertoire personnel avec vos clés SSH, votre profil de navigateur, vos fichiers .env et tous les autres dépôts que vous avez déjà clonés. Sur un serveur temporaire, il dispose d’un shell, d’un checkout et de rien d’autre qui mérite d’être récupéré.

C’est tout l’argument. Il porte sur l’asymétrie, pas sur la probabilité. Un agent prudent sur un ordinateur portable correctement protégé ne pose presque jamais de problème. Mais lorsqu’un incident se produit, le coût ne se limite pas à un mauvais commit. Il faut restaurer une sauvegarde, si vous en avez une.

Définissez le périmètre des dommages avant d’en débattre

Le périmètre des dommages correspond à l’ensemble des éléments qu’un processus peut atteindre. Pour un agent exécuté avec votre compte utilisateur habituel sur votre machine habituelle, cet ensemble est plus vaste que la plupart des gens ne l’imaginent.

Il comprend ~/.ssh/id_ed25519, qui n’est généralement pas chiffrée parce que vous en avez eu assez de saisir la phrase secrète. Il comprend ~/.aws/credentials et ~/.config/gh/hosts.yml, qui sont en texte brut par conception. Il comprend tous les dépôts frères sous ~/code, y compris ceux qui contiennent des chaînes de connexion de production dans un fichier env local. Il comprend aussi l’historique de votre shell, qui contient des jetons que vous avez collés une fois. Il comprend enfin le réseau auquel votre ordinateur portable est connecté, souvent un réseau domestique ou professionnel qui héberge des services sans authentification.

Rien de tout cela n’exige un agent malveillant. Une seule commande exécutée avec assurance mais erronée suffit. rm -rf avec une variable non définie qui se développe en /, un git clean -xfd dans le mauvais répertoire, un docker system prune -af --volumes qui supprime aussi votre base de données locale, ou un chmod -R 777 appliqué par erreur au répertoire personnel. Les agents sont entraînés sur le même Internet que celui qui a appris ces commandes à tous les autres.

Ce qui vous protège n’est pas le jugement de l’agent. C’est le fait que la machine susceptible de subir les dommages est une machine que vous étiez prêt à perdre.

Le calcul du coût est rébarbatif, ce qui est précisément le but

Un petit VPS coûte quelques dollars par mois. Récupérer l’ordinateur portable d’un développeur prend une journée, dans le meilleur des cas, lorsque vous vous en rendez compte immédiatement et que vous disposez d’une sauvegarde.

Faites le calcul avec vos propres chiffres. Prenez votre taux horaire et multipliez-le par le nombre d’heures nécessaires pour réinstaller un système d’exploitation, restaurer un répertoire personnel, renouveler une clé SSH, renouveler un jeton d’accès personnel et cloner de nouveau vingt dépôts. Comparez ce montant au coût de douze mois du plus petit serveur proposé par votre fournisseur. Le seuil de rentabilité est inférieur à un incident tous les quelques années. L’incident n’a pas besoin d’être catastrophique pour le dépasser. Un seul après-midi perdu à cause d’un environnement local corrompu suffit déjà à payer l’année.

La deuxième partie du calcul concerne les snapshots. Un snapshot réalisé avant une opération risquée transforme un résultat problématique en « restaurer tout mon environnement » ou « revenir en arrière et essayer une autre invite ». Cette possibilité n’existe pas sur l’ordinateur portable que vous utilisez pour rédiger ce texte, car vous ne pouvez pas créer un snapshot d’une machine qui vous sert de poste de travail.

Le paysage en juillet 2026

Il existe trois réponses honnêtes à la question « où l’agent doit-il s’exécuter ? ». Elles impliquent toujours le même compromis entre deux éléments : la solidité de l’isolation et le niveau de configuration que vous êtes prêt à accepter.

Une micro-VM locale. Les outils de cette catégorie démarrent une véritable machine virtuelle sur votre propre matériel, y montent votre dépôt et donnent à l’agent les privilèges root à l’intérieur. clawk en est l’exemple actuel. Son principe correspond exactement à la thèse de cet article : fournir aux agents de programmation une VM Linux jetable, plutôt que votre ordinateur portable. En juillet 2026, il cible macOS 14 et les versions ultérieures sur Apple silicon, avec une prise en charge expérimentale de Linux via Firecracker, et s’installe avec brew install clawkwork/tap/clawk. Exécutez clawk dans un dépôt pour démarrer la sandbox et y connecter un agent, clawk down pour l’arrêter et clawk destroy pour la supprimer. L’isolation repose sur un hyperviseur, ce qui offre une protection solide. Sa limite est que la VM s’exécute sur la machine que vous transportez partout : elle consomme votre mémoire et s’arrête lorsque vous refermez l’écran.

Un conteneur. Docker est la solution que la plupart des utilisateurs ont déjà installée, et elle est réellement utile.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm supprime le conteneur à la fin de l’exécution et --network none le prive totalement d’accès au réseau. C’est une bonne configuration par défaut pour une compilation ou une exécution de tests. Il faut toutefois bien comprendre ce que cette solution ne fait pas : un conteneur partage le kernel de l’hôte, donc une vulnérabilité du kernel peut permettre d’en sortir. De plus, l’isolation disparaît dès que vous ajoutez --privileged ou montez /var/run/docker.sock pour que l’agent puisse « utiliser Docker ». Monter le socket Docker dans un conteneur revient à donner à ce conteneur les privilèges root sur l’hôte.

Un VPS classique que vous pouvez reconstruire. Aucun nouvel outil à installer, une véritable isolation par le kernel, des snapshots fournis par l’hébergeur, et une exécution qui se poursuit lorsque vous éteignez votre ordinateur portable. C’est le modèle décrit dans la suite de ce guide. C’est aussi celui qui résiste aux longues exécutions d’agents : un travail qui dure quatre heures ne se soucie pas de votre départ du bureau.

Le modèle VPS : donner à l’agent son propre utilisateur

Commencez par un serveur correctement sécurisé. Les dix premières minutes sur un nouveau VPS couvrent les éléments qui ne concernent pas spécifiquement l’agent : mises à jour, connexion non-root, SSH avec clés uniquement et pare-feu.

Créez ensuite un compte réservé à l’agent. Ainsi, une erreur dans cet environnement ne pourra pas toucher les autres éléments du serveur.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password signifie qu’aucun mot de passe ne peut être deviné. Vous accédez au compte avec sudo -u agent ou avec une clé SSH. Notez que agent ne fait volontairement pas partie du groupe sudo. Un agent avec sudo dispose des privilèges root. root peut lire les fichiers de tous les autres utilisateurs. La séparation que vous venez de créer serait donc purement décorative. Si l’agent doit réellement installer des paquets, il faut plutôt lui attribuer un serveur entier, au lieu de lui accorder sudo sur un serveur partagé. Les règles générales sont présentées dans le principe du moindre privilège pour les utilisateurs Linux sur un VPS.

Vérifiez la séparation avant de faire confiance à l’agent. En tant qu’utilisateur agent, essayez de lire un fichier appartenant à votre propre compte :

sudo -u agent cat /home/you/.ssh/id_ed25519

Vous devriez voir cat: /home/you/.ssh/id_ed25519: Permission denied. Si vous voyez à la place des éléments cryptographiques, votre répertoire personnel est en mode 755 et l’isolation n’est pas encore effective. Corrigez cela avec sudo chmod 700 /home/you.

Conservez les identifiants entièrement hors de la machine

L’objectif d’une machine jetable est compromis si vous y copiez vos secrets de production. La règle est simple : cette machine ne doit contenir aucun identifiant dont la rotation vous poserait problème cet après-midi.

Pour git, transférez votre SSH agent au lieu de copier une clé. La clé privée reste sur votre ordinateur portable et seules les demandes de signature transitent par la connexion.

ssh -A agent@203.0.113.10
ssh -T git@github.com

La deuxième commande doit répondre Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Cela prouve que git push fonctionnera sans aucun fichier de clé présent sur le serveur. Exécutez ensuite ls -la ~/.ssh sur la machine et vérifiez qu’elle ne contient aucune clé privée.

L’agent forwarding présente un seul inconvénient réel, qu’il faut énoncer clairement : pendant que vous êtes connecté, toute personne disposant de root sur ce serveur peut utiliser le socket transféré pour s’authentifier à votre place. Sur un serveur dont vous êtes l’unique autre utilisateur, c’est un compromis acceptable. Sur une machine partagée, ce n’est pas le cas ; une deploy key limitée à un seul dépôt est alors préférable. Les différentes options sont présentées dans Notions de base sur la gestion des clés SSH.

Pour les clés d’API, attribuez à l’agent sa propre clé, avec sa propre limite de dépense, stockée dans un fichier appartenant à l’utilisateur agent et protégé par le mode 600. Lorsque la machine est détruite, révoquez cette clé au lieu de vous demander si elle a pu fuiter. Le suivi des dépenses du modèle par clé permet également de garder prévisibles les montants présentés dans Maîtriser le coût d’un agent IA sur un VPS.

Limiter les connexions réseau de l’agent

L’isolation du système de fichiers ne constitue que la moitié de la frontière. L’autre moitié concerne le trafic sortant : les services auxquels le processus peut se connecter. Linux peut filtrer le trafic sortant selon l’utilisateur qui l’a créé, ce qui correspond exactement à ce modèle.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

Les règles sont lues dans l’ordre. La dernière règle REJECT intercepte donc tout ce que les lignes précédentes n’ont pas autorisé. Testez-la avec l’utilisateur de l’agent :

sudo -u agent curl -sS -m 5 http://example.com

La commande doit échouer avec curl: (7) Failed to connect to example.com port 80: Connection refused, car la règle de rejet répond immédiatement au lieu de laisser la connexion attendre. Une requête HTTPS vers le même hôte doit toutefois fonctionner.

Deux limites doivent être clairement comprises. Premièrement, ces règles sont perdues au prochain redémarrage si vous ne les enregistrez pas avec sudo apt install -y iptables-persistent, puis sudo netfilter-persistent save. Deuxièmement, ce filtrage porte sur les ports et les adresses, pas sur les noms. Une règle qui autorise le port 443 autorise tous les hôtes HTTPS d’Internet. Elle permet donc d’atteindre l’API du modèle, mais aussi un service pastebin. Une véritable liste blanche de domaines nécessite de faire passer le trafic par un proxy qui lit le nom d’hôte demandé. Cette configuration est plus complexe que ce que souhaitent la plupart des environnements utilisés par un seul développeur. Limitez vos affirmations à ce que vous avez réellement mis en place : un contrôle du trafic sortant au niveau des ports, sur une machine dont vous étiez prêt à accepter la perte.

Revenir à un état propre entre les tâches

Un état propre pour chaque tâche est un avantage souvent sous-estimé. Un agent qui a passé trois heures sur le ticket précédent a laissé des paquets installés, des migrations partiellement appliquées, un node_modules obsolète et un arbre de travail git contenant des modifications que personne n’a relues. La tâche suivante récupère tout cet état, et vous consommez votre budget de revue à déterminer quelle partie du désordre appartient à quelle exécution. Un agent plus ciblé laisse moins de traces dès le départ. Associer une machine jetable à une compétence qui pousse l’agent à effectuer la modification minimale fonctionnelle permet donc de conserver un diff et un état résiduel suffisamment limités pour être revus.

La solution simple consiste à utiliser un nouveau clone pour chaque tâche.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

La solution plus robuste consiste à créer un snapshot du fournisseur juste après la configuration de la machine, avant qu’un agent ne l’ait utilisée. La restauration de ce snapshot remet tout le système dans un état connu, y compris les paquets. La plupart des fournisseurs proposent cette fonction dans le panneau de contrôle ou via une API, plutôt que sous la forme d’une commande à exécuter sur la machine. Les étapes exactes dépendent donc de votre fournisseur. L’important est de créer le snapshot tant que la machine est encore dans un état neutre.

Conservez hors de la machine jetable tout ce qui vous est important. Cela signifie généralement pousser les branches plutôt que les conserver localement. Si la machine contient malgré tout quelque chose que vous regretteriez de perdre, sauvegardez-le correctement avec restic sur un VPS. Une machine que vous pouvez détruire n’est utile que si sa destruction ne crée réellement aucun problème.

Si vous voulez plusieurs environnements isolés sans payer plusieurs serveurs, un VPS plus puissant peut héberger directement des machines virtuelles invitées. La virtualisation imbriquée sur un VPS explique son fonctionnement, notamment comment vérifier si votre fournisseur l’autorise. L’isolation fonctionne dans les deux sens. Si vous préférez que deux agents présents sur la même machine se coordonnent plutôt que de rester complètement séparés, une session Claude Code peut envoyer directement du texte à une autre au lieu de faire transiter chaque transmission par vous.

Quand un laptop correctement configuré suffit réellement

Soyez honnête sur ce point, car surestimer l’isolation finit par faire perdre l’attention des utilisateurs.

Si vous vérifiez chaque commande avant son exécution, un laptop convient. La demande d’autorisation constitue un véritable contrôle, et exécuter Claude Code en toute sécurité sur un serveur explique ce que bloque réellement chaque niveau. Si votre travail se limite à un seul dépôt et qu’aucun identifiant de production ne se trouve sur la machine, le rayon d’impact est déjà réduit. Si vos sessions avec l’agent sont courtes et supervisées, la fenêtre d’exposition l’est également.

La réponse change dès que vous ignorez les demandes d’autorisation. Il faut y réfléchir maintenant, puisque le mode automatique devient le mode par défaut de Claude Code le 14 août 2026 et qu’une nouvelle installation ne demande plus d’autorisation avant de modifier des fichiers ou d’exécuter des commandes. Les exécutions sans supervision, les tâches nocturnes et tout workflow où vous approuvez un plan avant de vous éloigner suppriment le contrôle humain qui assurait le confinement. La machine doit alors prendre le relais. Il en va de même pour tout ce qui étend la portée de l’agent, notamment exécuter un agent de programmation sur un VPS dans plusieurs dépôts à la fois.

La décision ne dépend pas vraiment du niveau de confiance que vous accordez au modèle. Elle dépend de ce qui se trouve à côté de lui lorsqu’il se trompe.

FAQ

Un conteneur offre-t-il une isolation suffisante pour un agent de programmation ?

Pour la plupart des tâches, oui, à deux conditions. Le conteneur ne doit pas s’exécuter avec --privileged et ne doit pas avoir /var/run/docker.sock monté à l’intérieur, car l’un ou l’autre donne au processus un accès vers root sur l’hôte. Un conteneur partage le noyau de l’hôte. La séparation est donc moins forte qu’avec une machine virtuelle. Si l’agent exécute du code non fiable récupéré sur Internet, préférez une véritable machine virtuelle ou un serveur séparé.

L’agent a-t-il besoin de sudo sur le serveur ?

Non. Lui donner sudo annule l’isolation mise en place, car root peut lire les données de tous les autres comptes de la machine. Créez l’utilisateur de l’agent sans sudo et donnez-lui un accès en écriture uniquement à son propre répertoire de travail. Si la tâche nécessite réellement l’installation de paquets, attribuez à l’agent une machine entière dont il est responsable plutôt que root sur une machine partagée.

Comment permettre à l’agent de pousser vers git sans installer ma clé SSH sur la machine ?

Transférez votre agent SSH avec ssh -A lors de la connexion. Les demandes de signature transitent par la connexion, tandis que la clé privée reste sur votre ordinateur portable. Ainsi, ssh -T git@github.com s’authentifie et git push fonctionne sans clé privée sur le serveur. Attention : root sur ce serveur peut utiliser le socket transféré pendant votre connexion. Utilisez donc une deploy key limitée au dépôt sur toute machine que vous partagez avec d’autres personnes.

Quelle taille de VPS faut-il à un agent ?

Le travail de l’agent consiste principalement à modifier des fichiers, exécuter des builds et lancer des tests. Dimensionnez donc la machine en fonction du build, pas du modèle. Un modèle hébergé s’exécute sur l’infrastructure du fournisseur. Cela ajoute du trafic réseau et presque aucune charge locale. Commencez avec 2 GB de RAM pour les tâches de scripting et passez à 8 GB si le dépôt construit des conteneurs ou compile des éléments importants.

À quelle fréquence dois-je détruire et reconstruire la machine ?

Reconstruisez-la lorsque son état n’est plus explicable et, au minimum, lorsqu’un identifiant ou un secret présent sur la machine a pu être exposé. Un nouveau checkout entre les tâches suffit à gérer la dérive quotidienne. Un snapshot pris avant la première exécution de l’agent vous permet de revenir à une image système propre. Si la reconstruction semble coûteuse, cela indique qu’un élément important réside sur une machine que vous considériez comme jetable.