J’ai une vraie app SaaS avec un backlog de trucs cassés, et je l’ai filé à 10 agents Cloud Code. Chacun dans sa propre box, qui tourne la nuit pendant que mon laptop est fermé. Voilà ce qui s’est passé.
Le problème avec un seul agent
Si vous utilisez Cloud Code en ce moment, vous lancez un agent sur votre laptop, un terminal, un repo, une tâche à la fois. Et dès que vous fermez le capot, tout s’arrête. C’est parfait pour un bug. Mais quand vous avez un vrai backlog qui dort, cette session unique devient le goulot d’étranglement.
La solution, c’est Upstash Box. Upstash Box vous permet de donner un ordinateur à vos agents IA. Au lieu d’emprunter votre machine, l’agent récupère sa propre machine dans le cloud, avec ses propres fichiers, son propre git, son propre shell. Et ce qu’on construit avec, c’est ni plus ni moins une usine logicielle.
Comment fonctionne une Upstash Box
Direction la doc d’Upstash Box, parce que ça marche différemment des outils sandbox que vous avez probablement vus. Chaque box est un conteneur cloud sécurisé et isolé avec un agent IA intégré. Et cette dernière partie, c’est ce qui compte.
Avec la plupart des outils sandbox, l’agent tourne de votre côté et le sandbox sert juste à exécuter du code. Ici, l’agent vit à l’intérieur de la box. Vous lui donnez un prompt et il lance ses propres commandes, édite ses propres fichiers, fait tourner ses propres tests, directement là où se trouve le code.
Une box récupère un runtime, git, et un vrai shell. Son cycle de vie : running, paused, et snapshots. On va utiliser les trois.
L’application et le backlog
Voici l’app. Login, une base de données, des utilisateurs, un dashboard. Construite vite, comme la plupart d’entre nous construisons les choses maintenant. Elle a donc une liste de problèmes très familiers, et cette liste se trouve dans un fichier : backlog.md. Du plain English.
Item un : le endpoint de login n’a pas de rate limiting. Item deux : le dashboard charge toutes les lignes, pas de pagination. Item trois : la nav mobile ne se ferme pas après avoir tapé sur un lien. Item quatre : une requête N+1 sur la liste des utilisateurs. Et ça descend jusqu’à dix.
Une règle qui compte dès que vous passez en parallèle : chaque item doit toucher une partie différente de l’app. Ce sont 10 agents dans 10 box, et ils ne peuvent pas se voir. Si deux d’entre eux éditent le même fichier, vous obtenez deux branches qui se battent au moment du merge.
L’orchestrateur qui lance tout
Il faut maintenant quelque chose qui lise ce fichier et spawn les box. Je ne vais pas écrire ça à la main. Je vais demander à Claude Code de l’écrire en utilisant la doc d’Upstash comme source.
Claude Code tourne en local. Je lui donne le lien de la doc et je lui dis ce que je veux : lis le quickstart d’Upstash Box, puis écris un orchestrateur qui lit backlog.md et, pour chaque item, crée une box avec l’agent Cloud Code, clone mon repo dedans, et donne à l’agent l’item comme tâche.
Première passe. Et regardez ça. C’est faux. Il devine des noms de méthodes qui n’existent pas. On le lance, on obtient une erreur. Très normal quand vous pointez un agent vers un SDK tout neuf. Le correctif, c’est d’être spécifique. Récupérer la vraie page de quickstart et suivre l’API qui est dessus.
Deuxième passe. Il installe le SDK, lit backlog.md, le découpe en items. Et voici la partie importante : Box.create. À l’intérieur, on définit le runtime et on définit l’agent sur Claude Code. Ce bloc, c’est ce qui met un agent Claude Code à l’intérieur du conteneur. Note rapide sur les clés : les miennes sont dans un fichier .env que je garde hors écran. Faites pareil.
Le test avec un seul agent
Avant de passer à dix, on en lance un seul. Toujours voir un seul fonctionner d’abord. Juste l’item un, le bug de rate limiting.
La box se crée, on récupère un box ID. Et maintenant, regardez. L’agent streame directement depuis le conteneur. Il clone le repo, lance npm install, ouvre la route, lit le middleware. Rien de tout ça n’est sur ma machine. Quelques minutes plus tard, le voilà. Rate limiting sur la route de login. Un test pour ça. Test qui passe. Commit sur une branche. Toute cette boucle s’est déroulée dans un conteneur dans le cloud.
Passer à 10 agents en parallèle
Maintenant, la partie amusante. On prend la même chose et on passe à l’échelle. Pas une session Cloud Code sur votre laptop, mais 10 agents qui bossent sur vos repos en même temps, chacun dans sa propre box.
On mappe sur les 10 items du backlog, on crée une box pour chacun, et on les lance tous d’un coup. Une chose qui vaut le coup d’être faite avant : cloner et lancer npm install prend quelques minutes, et vous ne voulez pas payer pour ça 10 fois. Donc j’ai configuré une box, clone et install, snapshot, puis créé les neuf autres à partir de ce snapshot.
Et c’est parti. 10 box réparties sur des panneaux pour toutes les voir en même temps. Et c’est la partie que je veux que vous remarquiez. Les ventilateurs de mon laptop ne tournent pas. 10 agents Claude Code à pleine vitesse et ma machine ne fait rien.
Là où ça devient vraiment utile : puisque les agents vivent dans les box et pas sur mon laptop, je n’ai pas besoin de rester assis à regarder. Il est 23h. Les 10 agents travaillent et je ferme mon laptop pour aller dormir. Ce n’est pas un trucage. Les box continuent de tourner. Il n’y a aucune session sur ma machine à perdre.
Le lendemain matin : les résultats
C’est le lendemain matin. Voyons ce qu’on a obtenu.
Six des dix sont revenus propres et ont poussé une branche. Pagination sur le dashboard, états d’erreur et états vides, le README, export PDF, expiration du token de reset de mot de passe, et le bug de fuseau horaire du digest quotidien. Six branches qui m’attendent.
Deux d’entre elles méritent qu’on s’y arrête. Avant de spawn quoi que ce soit, l’orchestrateur a fait tourner la suite de tests une fois et a imprimé une baseline. Ce repo avait déjà deux tests qui échouaient sur main. Celui du digest et celui du reset de mot de passe. Le matin, les deux sont verts, corrigés par deux agents différents dans deux box différentes qui ne se sont jamais parlé.
Maintenant, les échecs. Et ils sont plus intéressants que les réussites.
Trois agents ont atteint leur plafond de dépenses et sont morts en cours de tâche. J’avais mis une limite de 3 $ par agent, donc 10 agents, c’est 30 $ dans le pire des cas. Le rate limiting, la requête N+1, et le script de seed ont tous brûlé leur budget. Quand vous lisez les logs, c’est la même erreur à chaque fois. L’agent fait sa modification, lance npm test, voit ces deux échecs préexistants, décide que c’est peut-être de sa faute, revert son propre travail, relance, s’embrouille, réessaie. Il a dépensé 3 $ à se disputer avec lui-même à propos de tests qu’on ne lui avait jamais demandé de toucher.
Ensuite, la nav mobile. Elle a réussi. Elle a fait le correctif. Elle a dit : « I will now commit the change. » Et puis pas de commit. Il y a donc une box qui traîne avec le bon changement dans le working tree et une branche vide.
Et puis il y a celle-ci, et c’est celle que vous devez voir. L’export PDF. Il a décidé d’utiliser un package appelé fast PDF, l’a ajouté au package.json, a lancé l’installation, et npm ne l’a pas trouvé. Mais ensuite il s’est rattrapé, a basculé sur JSPDF, et a livré un export fonctionnel. Tout ça dans une seule branche. Il a halluciné, il a récupéré, et la seule raison pour laquelle je sais que ça s’est passé, c’est que j’ai lu le log.
Donc, six propres, une qui n’est pas allée jusqu’au commit, trois qui se sont dépensées à mort. Et c’est la vraie réponse à « est-ce que je peux laisser ça tourner sans surveillance ». Vous pouvez laisser le travail sans surveillance. Vous ne pouvez pas laisser le merge sans surveillance.
Pause et reprise : ne pas jeter le travail
Ces trois qui sont tombés à court de budget, je ne veux pas les jeter. Et je ne veux pas non plus payer pour qu’ils restent là à mouliner. Voici donc la pause. Gelez une box à tout moment et continuez des jours, voire des semaines plus tard, avec une reprenabilité parfaite.
Je mets celle-ci en pause. Dans la console, vous voyez le statut passer de running à paused. Et maintenant, regardez. Je la reprends, je liste le dossier, j’ouvre le fichier sur lequel je travaillais. Le repo est là, node_modules est là. Les modifications à moitié finies sont là. Et la branche est encore checkoutée. Rien n’a été reconstruit. Vous pouvez donc commencer quelque chose un lundi, le geler, et reprendre exactement cet environnement plus tard.
Combien ça coûte
Parlons argent, parce que je sais que c’est la question. Upstash Box vous facture le CPU actif, pas le wall clock time. Quand une box est en pause, vous ne payez pas pour le calcul, juste un petit montant pour le stockage. Ce qui compte ici, parce que les agents passent une grande partie de leur vie à ne rien faire.
Voici la facture. 10 box. Et c’était environ un centime. Mais ça, c’est juste les box. Vous payez Anthropic séparément pour les tokens que ces agents ont brûlés. Et ça, c’était le plus gros chiffre. L’infrastructure pour faire tourner 10 agents pendant la nuit, c’est cheap. L’utilisation du modèle, c’est ce que vous surveillez vraiment.
Trois choses qui vont vous mordre
Plutôt que vous les découvriez tout seul, voici trois choses qui vont vous mordre.
Premièrement, vous ne pouvez pas encore apporter votre propre Dockerfile. Vous choisissez parmi les runtimes qu’ils fournissent : Node, Python, Go, etc. Si votre app a besoin d’un package système bizarre, vous l’installez dans une étape de setup, ou vous faites comme moi : vous l’installez une fois et vous le snapshottez. Les runtimes personnalisés sont sur la roadmap.
Deuxièmement, et c’est le point important, les variables d’environnement à l’intérieur d’une box sont visibles par tout ce qui s’y trouve, y compris l’agent. Si vous balancez un token GitHub dedans, l’agent peut le lire. Et si vous le passez dans une commande shell, cette commande peut finir dans les logs. La doc couvre ça. Il y a une fonctionnalité qui s’appelle attach headers, où vous mappez le secret à un domaine et Upstash l’injecte à la sortie. Comme ça, il ne touche jamais le conteneur. Utilisez ça.
Troisièmement, par défaut, une box peut accéder à tout internet. Ce qui veut aussi dire qu’un agent qui part en vrille peut accéder à n’importe quoi. Vous pouvez verrouiller ça avec une politique réseau et n’autoriser que les domaines dont vous avez besoin. Et je fais ça avant de lancer quoi que ce soit sans surveillance.
À qui ça s’adresse vraiment
Si vous lancez un agent à la fois et que ça vous va, vous n’avez pas besoin de ça. Cloud Code sur votre laptop, c’est très bien. Ça commence à avoir du sens au moment où le goulot d’étranglement, c’est vous. Un backlog qui n’avance jamais, quelques projets en même temps, ou simplement l’envie d’avoir du travail qui se fait pendant que vous dormez.
Ce qui m’a vraiment surpris, ce n’était pas les 10 agents. C’était de fermer mon laptop. Votre travail arrête d’être lié à votre machine qui reste ouverte et devient quelque chose que vous mettez en file d’attente et que vous allez vérifier. Ce n’est pas de la magie. Vous avez vu les échecs. Trois d’entre eux ont dépensé tout leur budget à tourner en rond. Mais six vrais correctifs qui vous attendent sur des branches le matin pour quelques dollars. C’est un bon échange.
Points clés à retenir
- Une Upstash Box est un conteneur cloud isolé avec un agent IA intégré qui vit dedans, pas sur votre machine
- Vous pouvez lancer 10 agents en parallèle, chacun dans sa propre box, sans que votre laptop ne chauffe
- Les box continuent de tourner même quand vous fermez votre laptop : le travail n’est plus lié à votre session locale
- Faites toujours un snapshot après l’installation initiale pour ne pas payer le clone et le
npm install10 fois - Les agents peuvent s’embrouiller avec des tests préexistants et brûler leur budget à essayer de les corriger
- Vous pouvez laisser le travail sans surveillance, mais jamais le merge
- La pause vous permet de geler une box et de reprendre exactement le même environnement des jours plus tard
- La facturation se fait au CPU actif, pas au temps écoulé : l’infrastructure est cheap, c’est l’utilisation du modèle qui coûte
- Utilisez attach headers pour les secrets, ne les mettez jamais directement dans les variables d’environnement de la box
- Verrouillez l’accès réseau avant de lancer quoi que ce soit sans surveillance