Comment les conteneurs de tâches fournissent aux agents IA une véritable infrastructure sans coût lié à l'inactivité

L'infrastructure des agents IA t'oblige généralement à choisir entre deux mauvaises options. Un bac à sable est sûr mais aveugle, coupé des données et des services qui rendraient les résultats de l'agent utiles. Un accès complet implique de payer pour garder un conteneur inactif entre deux exécutions, en attendant une invite qui pourrait ne pas arriver avant des heures. 

Les conteneurs de tâches, lancés par Upsun le 12 août 2026, ont été conçus pour éviter ce choix.

Un conteneur de tâche est un conteneur à usage unique défini dans le fichier .upsun/config.yaml d’un projet. Il exécute exactement une commande, et dès que cette commande se termine, le conteneur disparaît. Il n’y a pas de démon à maintenir en vie ni de conteneur inactif à payer. 

La documentation décrit son cycle de vie : une tâche est « injectée dans le cluster de ton environnement, exécute une seule commande, puis est supprimée lorsque la commande se termine ». La facturation ne porte que sur les secondes pendant lesquelles la commande s’exécute.

Ça va bien au-delà du simple travail d’IA. La documentation répertorie trois types de tâches auxquelles un conteneur est destiné :

• Une session d’agent IA en arrière-plan : un agent qui lit une base de code, appelle des outils comme des commandes shell ou des requêtes de base de données, et réécrit les résultats dans le projet
• Une tâche ponctuelle nécessitant l’accès à un service : maintenance d’une base de données, exportation de données, rapport
• Une tâche par lots déclenchée depuis une application plutôt que selon un calendrier

Pourquoi les agents IA ont fait pencher la balance en faveur des tâches

Nicolas Gommenginger, directeur produit chez Upsun, explique que son équipe réfléchissait aux conteneurs de tâches depuis un certain temps déjà, avant même la vague d'activité autour des agents de cette année. Ce sont les agents IA qui ont permis de passer de l'idée à la mise en œuvre.

« C’est quelque chose qu’on envisageait d’ajouter depuis un bon moment, parce qu’on peut voir ça un peu comme une fonction sans serveur : tu l’appelles et elle exécute une action. Et quand c’est fini, il n’y a pas de ressources inactives », explique Nicolas. « Mais ce qui nous a vraiment poussés à passer à l’action, c’est l’essor des agents IA, car les tâches sont idéales pour faire tourner des agents IA. »

La charge de travail d’un agent prend la forme d’une tâche. Elle démarre, effectue un travail défini, puis s’arrête. Maintenir un conteneur « au chaud » entre deux invites permet certes de réduire la latence au démarrage, mais pour les tâches qui arrivent par rafales, ça revient à payer pour les temps morts. Nicolas a tenu à préciser que cette fonctionnalité n’est pas spécifique aux agents. Une tâche convient tout aussi bien à une exportation volumineuse qu’à une migration ponctuelle. Tout ce qui s’exécute une seule fois puis s’arrête convient.

Ce que font les conteneurs de tâches que les sandbox ne font pas

Le rôle d’un bac à sable, c’est l’isolation : empêcher un agent d’accéder à Internet ou au reste du système de fichiers. C’est un argument qu’Upsun a développé dans ses propres articles sur les bacs à sable « zero-trust » pour les agents d’IA. Un conteneur de tâches ne t’offre pas ce type d’isolation dès le départ, même s’il est loin d’être sans protection : les tâches s’exécutent avec le même isolement d’espace de noms, la même réduction des capacités, le même profil seccomp, les mêmes limites cgroup et la même isolation réseau que les conteneurs d’applications. Nicolas a déclaré que les primitives de sécurité des conteneurs d’Upsun Cloud « sont déjà à un très haut niveau ».

Pour transformer une tâche en véritable sandbox, il faut ajouter quelques réglages supplémentaires : des règles de pare-feu pour limiter les connexions sortantes, ainsi qu’une configuration des montages et des variables pour restreindre ce que le processus peut lire. Pour le code non fiable, la documentation suggère d’envisager l’utilisation de « bubblewrap » à l’intérieur du conteneur de tâches, afin de restreindre l’accès du processus de l’agent au système de fichiers, aux variables d’environnement et aux appels système.

Ce qu’une tâche a par défaut, c’est l’accès au reste du projet. C’est justement cet accès que Nicolas n’a cessé de mettre en avant.

« Le gros avantage d’une tâche, c’est qu’elle a accès à tous tes services sur Upsun Cloud », a-t-il expliqué. « Tu peux créer un environnement de test, exécuter tes tâches sur cet environnement avec un accès à des données similaires à celles de production, puisque nous clonons les données depuis ton environnement parent. »

En combinant les deux, un agent bénéficie de quelque chose qu’un simple bac à sable ne peut pas lui offrir : un environnement fermé et jetable qui contient tout de même une copie fonctionnelle de la production. Upsun a longuement défendu cet argument dans son plaidoyer en faveur des bacs à sable IA avec état, et ce sont les environnements de test qui rendent cela possible, en clonant les données, les fichiers et les services d’un environnement parent en moins d’une minute.

« Un agent qui tourne dans un bac à sable est généralement assez limité », a expliqué Nicolas. « Mais si tu ajoutes l’environnement de test comme bac à sable, tu peux faire tourner l’agent dans un environnement fermé, tout en ayant accès à une réplique de tes services de production, ce qui est très précieux pour les agents : avoir accès aux logs, consulter les données, pouvoir itérer et atteindre un véritable état de fonctionnement, pas seulement en se basant sur le code. »

La démo : une invite devient une pull request

Dans la démo enregistrée, Nicolas a présenté une petite application d’administration qui déclenche des conteneurs de tâches. Une requête en langage naturel saisie dans l’application, comme l’ajout d’un arrière-plan dégradé à la section « hero » d’une interface front-end, déclenche une tâche. La tâche appelle l’API Anthropic, clone le dépôt front-end, applique la modification et ouvre une pull request. Upsun Cloud crée ensuite automatiquement un environnement de test pour la nouvelle branche, et le dégradé est apparu sur l’URL de prévisualisation quelques minutes plus tard.

La tâche s’arrête là. Elle ne déploie rien, et c’est la fusion de la pull request qui permettrait de mettre la modification en production, la décision revenant à un humain. Dans la démo, ça ne s’est pas produit : GitHub a connu des dysfonctionnements tout au long de l’enregistrement, donc la fusion est restée théorique. « Je peux simplement fusionner une pull request, ce qui n’est pas possible aujourd’hui avec GitHub », a déclaré Nicolas. « Mais en théorie, il suffit de fusionner, et ça se déploierait sur ton front-end de production principal. »

Le même projet utilise une deuxième tâche, sans IA, pour exporter chaque requête envoyée à l’outil d’administration ainsi que la sortie du modèle sous forme de fichier JSON. Si tu veux faire des évaluations sur des sessions passées, tu peux les rejouer plus tard. Un conteneur de tâches ne se soucie pas de savoir si la commande qu’il exécute concerne un modèle.

Dans la configuration, une tâche a besoin d’un type d’exécution et d’une commande run.command. Les champs facultatifs concernent source.root, les autorisations, les hooks de build, les relations avec d’autres services, les montages et les variables. Il en va de même pour run.timeout, dont la valeur par défaut est d’une heure et qui peut être portée à 86 400 secondes, soit un jour, après quoi la plateforme envoie un SIGTERM puis un SIGKILL. Les relations sont unidirectionnelles. Une tâche peut accéder à une application ou à une base de données, mais rien ne peut s’adresser à une tâche, car celle-ci n’existe que tant qu’elle s’exécute et Upsun Cloud ne lui achemine pas de trafic entrant.

Une tâche qui doit transmettre des résultats doit les envoyer elle-même, par exemple vers une application via une relation HTTP, ou vers un service partagé ou un montage. Les exécutions parallèles sont limitées à trois par défaut ; les déclencheurs supplémentaires sont mis en file d’attente plutôt que supprimés, et cette limite est inférieure pendant la période d’essai.

L’agent de performance arrive ensuite

Upsun développe ses propres agents sur cette même infrastructure, à commencer par un agent dédié aux performances.

« Le premier, qui sortira bientôt, est l’agent de performances que tu pourras utiliser pour obtenir des rapports détaillés et des recommandations de performances pour ton application », a déclaré Nicolas.

Il s’exécute sous forme de tâche sur les données d’observabilité d’un projet et renvoie des recommandations pour améliorer les performances. Le principe est le même que dans la démo : déclencher une tâche, la laisser s’exécuter avec accès aux services du projet, récupérer le résultat, puis arrêter de payer pour le conteneur.

Les conteneurs de tâches sont désormais disponibles sur tous les projets Upsun Cloud, aux côtés des autres fonctionnalités de la plateforme Upsun Cloud. Les détails de configuration, notamment les périmètres d’autorisation et le déclenchement via l’API, se trouvent dans la documentation d’Upsun consacrée aux tâches. 

Tu peux visionner l’intégralité de la conversation avec Nicolas, y compris la démo, ici.