VPS ou sandbox : votre agent IA a-t-il besoin de son propre serveur ?

Un agent qui écrit du code a besoin d'un endroit pour l'exécuter. La réponse habituelle est « donnez-lui un serveur », et pour beaucoup d'agents c'est plus de machine que nécessaire. L'erreur inverse est tout aussi fréquente : quelqu'un construit un bot permanent dans une sandbox, puis se demande pourquoi il a disparu pendant la nuit.

Nous vendons les deux, donc nous voyons les deux erreurs. Voici comment nous déciderions.

Ce qu'est chacun

Une sandbox est une microVM Firecracker. Elle démarre en une seconde environ, avec Python 3.12, Node.js 22, bash et git, a Internet en sortie, sans ports entrants ni SSH. Vous lui parlez via l'API, le SDK ou MCP : lancer une commande, envoyer un fichier, lire la sortie. Une commande peut durer jusqu'à 55 secondes ; un travail plus long tourne en tâche de fond. Une sandbox éphémère vit jusqu'à 24 heures et disparaît d'elle-même si elle reste inactive.

Un VPS est un serveur virtuel classique. Root en SSH, un disque qui reste, et il tourne jusqu'à ce que vous le résiliiez. Sur les offres avec IPv4 propre, tous les ports entrants sont à vous. Sur les offres NAT, vous avez un port redirigé pour SSH, et l'adresse sortante n'est pas la vôtre.

Même solde, même compte, même serveur MCP. La différence : la durée de vie, et la possibilité de joindre la machine depuis l'extérieur.

Trois questions

1. Doit-il tourner quand personne ne le sollicite ? Un bot Telegram, une boucle de trading, un scraper planifié, un agent qui vérifie quelque chose toutes les dix minutes. Tout cela, c'est un VPS. Une sandbox inactive se supprime toute seule, et une sandbox persistante facturée à l'heure pendant un mois entier coûte plusieurs fois un petit VPS.

2. Quelque chose doit-il se connecter à lui ? Des webhooks, une API, un serveur MCP pour votre équipe, un tableau de bord ouvert dans le navigateur. Les sandboxes n'acceptent aucune connexion entrante. Donc un VPS, et en pratique un VPS avec IPv4 propre : Nano-IP à partir de $8 par mois.

3. Quelqu'un a-t-il lu ce code ? La sortie d'un modèle, un paquet que l'agent a décidé d'installer, une pull request d'un inconnu. C'est là que la sandbox se rend utile. Si le code fait quelque chose de nuisible, il le fait dans une machine supprimée une minute plus tard et qui ne contient aucune de vos clés. Lancer la même chose sur le VPS qui détient aussi les jetons de votre bot, c'est un pari qu'on préfère éviter.

Si vous avez répondu « non, non, oui », prenez une sandbox. Un « oui » à l'une des deux premières questions veut dire un VPS. Beaucoup d'agents finissent sur « oui, peut-être, oui », et ceux-là ont besoin des deux.

Où les coûts se croisent

Les sandboxes sont facturées à la seconde selon les vCPU et la RAM allouées, avec un minimum de 60 secondes. Les offres VPS ont un prix mensuel fixe. Aux prix actuels :

Si le code de votre agent tourne quelques minutes par tâche, même des centaines de tâches par mois coûtent quelques centimes en sandbox. Dès que le total dépasse environ trois heures par jour, le VPS revient moins cher, et beaucoup moins cher en 24/7 : une sandbox standard persistante pendant un mois complet coûte au maximum $36.14, contre $5 pour Micro.

Les lignes ne sont pas des jumelles exactes : le VPS a plus de vCPU et un disque plus grand, et les offres NAT n'acceptent pas de connexions entrantes. Pour la question « où tourne mon code », qui est celle qui nous occupe, la comparaison est honnête.

Ce que nous recommanderions

Pour un agent qui fait un vrai travail, les deux :

• Un VPS comme maison de l'agent. Il y fait tourner sa boucle, garde sa mémoire et ses clés d'API, et expose ce qui doit l'être. Nano à $3 suffit pour un agent qui appelle un modèle par API ; l'inférence locale demande beaucoup plus.
• Une sandbox pour chaque tâche non fiable. L'agent écrit du code, l'envoie dans une microVM neuve, lit le résultat et jette la machine. La sandbox ne reçoit aucun secret dont elle n'a pas besoin.

Les deux sont accessibles depuis la même connexion MCP, et l'agent choisit à chaque tâche. Fixez une limite de dépenses pour les sandboxes avant de le laisser faire. Une boucle qui lance des sandboxes sans fin butera sur la limite au lieu de vider le solde.

Quand ce conseil ne convient pas

Si vous exécutez déjà du code non fiable dans des conteneurs sur votre propre serveur et que cette frontière vous suffit, une sandbox séparée peut sembler superflue. Tout dépend de la confiance que vous accordez au code. Notre comparaison des niveaux d'isolation explique ce qu'un conteneur arrête et ce qu'il n'arrête pas.

Si l'agent écrit des applications entières plutôt que des extraits, il existe une troisième option entre les deux : un VPS où chaque branche qu'il pousse devient un aperçu avec sa propre adresse.

Et si l'agent ne fait qu'appeler des API sans jamais exécuter ce qu'il écrit, il n'a besoin ni d'une sandbox ni d'un gros serveur. Un VPS à $3 avec sa boucle suffit largement.

Pour aller plus loin : les sandboxes à partir de $0.0165 de l'heure (un nouveau compte avec e-mail confirmé reçoit une fois $1 pour sa première sandbox, valable 14 jours) et les offres VPS à partir de $3 par mois. Si l'agent doit gérer son propre serveur, lisez ce qu'il fait après la commande.