Votre agent IA réinstalle ses packages

Votre agent IA réinstalle ses packages à chaque session. On peut faire mieux.

Toutes les sandboxes pour agents IA fonctionnent pareil : on crée un environnement, on exécute du code, on détruit. Ça dure quelques secondes ou minutes, puis tout disparaît. Pour évaluer un bout de code, ça fait le job. Pour un agent qui doit maintenir un codebase ou mener une recherche sur plusieurs jours, c'est un frein.

Les agents font bien plus qu'exécuter des fonctions maintenant. Ils gèrent des projets, font de la recherche sur plusieurs jours, maintiennent des repos, pilotent des processus métier. Tout ça nécessite de l'état. Et l'état ne survit pas à un teardown.

Ce que "persistant" veut dire concrètement

Un environnement persistant, c'est quatre choses. Le système de fichiers survit entre les sessions : les fichiers de mardi sont encore là jeudi. L'état du système (services actifs, cron, variables d'environnement) se maintient d'une session à l'autre. L'agent n'a pas besoin de sérialiser et restaurer quoi que ce soit via une API, de la même façon que votre laptop ne perd pas vos fichiers quand vous fermez le couvercle. Et il n'y a pas de timeout de session qui force l'agent à tout boucler dans un délai arbitraire.

Les sandboxes éphémères n'offrent rien de tout ça. C'est voulu. Mais ça limite sérieusement ce qu'un agent peut accomplir.

La taxe que vous payez

Si votre agent tourne dans un environnement éphémère, chaque workflow paie trois taxes. Elles se cumulent de façon non évidente.

Le setup. Chaque session repart de zéro. Installer les dépendances. Cloner le repo. Configurer les outils. Reconstruire le contexte. Dans un environnement persistant, ça se fait une seule fois. Dans une sandbox, c'est à chaque session. À 10 sessions par jour, on crame du compute pour du travail qui ne produit rien.

Le contexte. Les agents accumulent de la connaissance en travaillant. Un agent de recherche construit un corpus. Un agent de dev cartographie le codebase. Un agent de test repère les tests instables. Dans un environnement éphémère, tout ça doit être sérialisé dans un store externe et restauré la fois suivante. On finit par construire une couche de gestion d'état par-dessus une infra conçue pour être stateless :

## Sauvegarder l'état avant la mort de la sandbox
state = {
    "files_analyzed": files_analyzed,
    "findings": findings,
    "next_steps": next_steps,
    "installed_packages": installed_packages,
}
save_to_external_store(state)

## Session suivante : tout restaurer
state = load_from_external_store()
reinstall_packages(state["installed_packages"])
restore_files(state["files_analyzed"])

Chaque ligne de ce code existe parce que l'infra ne gère pas la persistance. C'est du overhead pur.

La continuité. Les tâches longues se font découper en morceaux calibrés sur la durée d'une session. Un agent qui refactorise un codebase ne peut pas bosser 8 heures si les sessions expirent au bout d'une heure. Alors le workflow devient : bosser 55 minutes, sérialiser, détruire, recréer, restaurer, reprendre. Chaque passage de relais risque un bug de restauration, un mismatch de version, une sérialisation incomplète. Des problèmes qui n'existent pas quand l'environnement reste en vie.

Où la persistance compte le plus

Le développement logiciel, c'est le cas le plus évident. Un agent qui implémente une feature doit cloner le repo, comprendre l'archi, installer les dépendances, écrire du code, lancer les tests, corriger, itérer. Les étapes 2 à 5 tournent en boucle. La compréhension du codebase, l'outillage installé, les résultats de tests : c'est de l'état. Dans un environnement persistant, l'agent traite son bureau comme vous traitez votre laptop : il est là quand on revient, dans l'état où on l'a laissé.

La recherche multi-jours, même logique. Un agent de recherche accumule des bookmarks, des papiers téléchargés, des notes, des résultats intermédiaires, et une organisation de workspace qui encode son modèle mental. Lui demander de tout emballer entre les sessions, c'est comme demander à un chercheur de ranger tout son bureau chaque soir et de tout réinstaller chaque matin.

L'automatisation de workflows, c'est là que l'éphémère casse complètement. Un agent qui traite des factures ou surveille des dashboards a besoin de cron jobs et de services en arrière-plan. Les sandboxes éphémères ne peuvent pas faire tourner de cron : l'environnement n'existe pas entre les exécutions.

Les agents qui apprennent de leur environnement (quels outils marchent le mieux, les conventions du projet, les analyses en cache) perdent tout à chaque reset. La persistance permet à un agent de progresser dans le temps, d'une session à l'autre.

L'approche la plus simple : une VM qui reste allumée

L'environnement persistant le plus direct, c'est une machine virtuelle qu'on ne détruit pas. L'agent reçoit un bureau Linux avec un disque de données qui survit aux redémarrages. Pas d'API de gestion d'état, pas de sérialisation. Un ordinateur qui reste dans l'état où l'agent l'a laissé.

C'est ce qu'on a construit avec Le Bureau. Chaque agent reçoit un bureau Ubuntu 22.04 avec 20 à 80 Go de stockage persistant sur un disque de données séparé. Le bureau est livré avec navigateur, terminal, VS Code et le framework agent OpenClaw. L'agent fait npm install une fois. Clone un repo une fois. Configure ses outils une fois. À la prochaine session, tout est encore là.

D'autres approches existent à différents niveaux. Fly.io Sprites propose des VMs Linux persistantes avec 100 Go NVMe et des temps de démarrage rapides, mais sans GUI. Les volumes Docker persistent les données entre les runs de conteneurs, mais on perd l'état système. E2B ajoute des fonctionnalités GUI et se dirige vers la persistance, signe que le marché converge dans cette direction.

Un pattern qu'on aime bien, c'est l'hybride : un bureau persistant comme base, des sandboxes éphémères pour l'exécution de code isolé quand on doit faire tourner quelque chose de non fiable. Le Bureau supporte ça. Le bureau persiste, et l'agent peut lancer des sandboxes E2B pour les opérations risquées.

Quand rester éphémère

La persistance n'est pas toujours la bonne réponse. Si on exécute du code non fiable, on veut que l'environnement disparaisse après : une session compromise ne doit pas affecter les suivantes. Si la charge de travail c'est "exécuter cette fonction 10 000 fois avec des entrées différentes", les environnements jetables sont moins chers et plus simples. Si l'architecture de l'agent externalise déjà tout l'état dans une base de données, la persistance infra est redondante. Et si l'agent ne bosse que 10 minutes par jour, payer une VM 24/7 n'a pas de sens.

Essayez

Pour voir la différence, faites ça : chronométrez l'initialisation de session de votre agent. S'il passe plus de 30 secondes à se configurer avant de pouvoir bosser, la persistance vous fera gagner du temps et de l'argent à chaque session.

Le Bureau a un tier gratuit avec 2 vCPU, 4 Go RAM et 20 Go de stockage persistant. Déployez votre agent, laissez-le configurer son workspace, coupez-le, relancez-le. Voyez ce qui change quand l'état marche tout seul.

---

Le Bureau fournit des bureaux cloud persistants pour agents IA. Environnement Linux complet, accès VNC, monitoring temps réel et support de plugins. Gratuit pendant la bêta.