Docker Cloud Sandboxes fait passer les agents de code du portable au cloud en une commande

Docker a lancé Cloud Sandboxes, un service qui étend aux serveurs cloud gérés par Docker les environnements isolés qu'il avait conçus pour les agents de code sur les ordinateurs des développeurs, rapportent iThome et le blog de Docker. Les développeurs peuvent confier à un agent de longues tâches, comme de grosses refontes de code ou des séries de tests, dans le cloud, et déplacer un bac à sable entre leur portable et le cloud avec la commande sbx move.

Un bac à sable désigne ici un environnement isolé dans lequel un agent d'IA peut installer des paquets, lancer des commandes et démarrer des conteneurs sans atteindre les ressources de la machine du développeur qui ne lui ont pas été ouvertes. Docker Sandboxes, lancé plus tôt cette année, fait tourner chaque agent dans une micro-VM dotée de son propre noyau Linux, système de fichiers, réseau et démon Docker, explique iThome.

Pourquoi les agents ont besoin d'un lieu où tourner

Le changement le plus important des agents de code en un an est qu'ils peuvent travailler beaucoup plus longtemps, écrit Docker : des tâches qui exigeaient autrefois qu'un développeur vérifie toutes les quelques minutes, comme une migration de dépendances ou une suite de tests d'une heure, peuvent désormais être confiées puis relues à la fin. Un portable est pensé pour une personne, fait valoir l'entreprise : il se met en veille quand on le ferme, ralentit sur batterie et se déconnecte quand on se déplace, ce qui ne compte pas pour une tâche de 30 secondes mais compte pour une tâche qui tourne toute la nuit.

Cloud Sandboxes reprend la même isolation par micro-VM et le même outil en ligne de commande que la version locale, selon Docker. Les développeurs peuvent lancer un agent dans le cloud avant de partir le soir et relire son travail le matin, commencer en local puis déplacer une tâche vers le cloud quand elle dépasse le portable, ou lancer de nombreuses tâches en parallèle, chacune dans sa micro-VM avec ses propres secrets et sa propre politique réseau.

Ce qui est inclus

• Kits : des bacs à sable préconstruits pour Claude Code, Codex, GitHub Copilot, Google Antigravity, OpenCode et Hermes, ou un environnement personnalisé.
• MCP : connexion unique à des serveurs comme Jira, Linear, Grafana ou incident.io, via une passerelle commune.
• Secrets : les clés sont stockées une fois et injectées à chaque requête, l'agent ne voit jamais le secret réel.
• Politiques : des règles réseau définissant les adresses que les agents peuvent atteindre.
• Tarifs : de 0,07 dollar de l'heure pour 1 vCPU et 2 Gio à 1,12 dollar de l'heure pour 16 vCPU et 32 Gio, facturés à la seconde.

La gestion des secrets compte pour la sécurité. Le proxy de Cloud Sandboxes injecte les identifiants dans chaque requête, si bien que les agents ne voient pas le secret réel ; une injection de prompt ne peut pas toucher un secret que l'agent n'a jamais eu, écrit Docker. Une injection de prompt est une attaque dans laquelle des instructions malveillantes cachées dans un contenu lu par l'agent tentent de le faire agir contre son utilisateur. Docker annonce pour bientôt une gouvernance centralisée pour les entreprises, avec un produit baptisé Docker AI Governance.

Les limites du déplacement d'un bac à sable

Le passage entre portable et cloud ne conserve pas les processus en cours, relève iThome. La commande sbx move enregistre le système de fichiers du bac à sable sous forme d'image de conteneur et crée un nouveau bac à sable à destination : les programmes en cours d'exécution et le contenu de la mémoire ne suivent pas. Les répertoires montés localement, les clés gérées par sbx et les règles d'accès réseau ne suivent pas non plus ; la destination demande sa propre configuration, et le bac à sable d'origine est conservé. Docker prévient lui-même que bacs à sable locaux et cloud ont des secrets, des modèles et des politiques réseau distincts.

Cloud Sandboxes est facturé à l'usage : le calcul est compté à la seconde, un bac à sable en pause ne coûte rien, et les volumes, le trafic sortant ainsi que les images et kits publics sont gratuits, selon Docker. Le coût des modèles est facturé à part par le fournisseur du modèle, ajoute iThome, et le client peut utiliser sa propre clé. Les bacs à sable tournent une heure par défaut et jusqu'à 24 heures par session. Le service exige sbx 0.45.1 ou plus récent et l'offre à l'usage des comptes Docker Personal ou Pro ; Docker Sandboxes en local reste gratuit et ne nécessite pas Docker Desktop.

Pourquoi Docker a fait un seul bac à sable pour deux lieux

Docker dit avoir délibérément évité de créer un produit cloud séparé avec ses propres commandes, parce que le degré de confiance qu'on peut accorder à un agent ne devrait pas dépendre de l'endroit où il tourne. À sa connaissance, aucun autre bac à sable pour agents ne fonctionne ainsi, affirme l'entreprise. Le travail interactif relève du portable et le travail qui dure des heures relève du cloud, soutient Docker, et la plupart des développeurs ont besoin des deux. Pour une durée limitée, les nouveaux comptes reçoivent 250 dollars de crédit gratuit sur Cloud Sandboxes.

Ce que cela change pour les entreprises françaises

Pour les équipes de développement qui utilisent déjà des agents de code, Cloud Sandboxes fait des exécutions d'agents une ressource cloud mesurée, avec la même isolation que sur le poste du développeur. Le coût est facile à estimer, mais deux points méritent attention avant l'adoption : le code et les données quittent les machines de l'entreprise pour les serveurs de Docker, ce qui pose la question du lieu d'hébergement et du RGPD, et l'usage des modèles s'ajoute à la facture du fournisseur de modèle. Les équipes doivent aussi définir dès le départ les politiques réseau et les secrets de chaque bac à sable, puisque ces réglages ne suivent pas un bac à sable qui change de lieu.