Les conteneurs de tâches transforment les tâches inactives en puissance de calcul à la demande

Dans la plupart des environnements de production, on trouve un conteneur qui reste actif toute la semaine pour effectuer une seule tâche le vendredi.

Peut-être qu’il réindexe une base de données. Peut-être qu’il exécute un rapport par lots, ou une migration de données qui n’a d’importance qu’à la fin du mois. Dans tous les cas, les ressources sont facturées pour sept jours.

Les conteneurs de tâches comblent cette lacune. Ce sont des conteneurs éphémères, déclenchés par une API, qui se lancent dans un environnement Upsun Cloud, exécutent exactement une commande, puis se suppriment d’eux-mêmes une fois cette commande terminée. Rien ne reste inactif entre deux exécutions. Ils ont été mis à la disposition de tous le 12 août 2026, après une préversion lancée sur Upsun Flex en juin.

Corey Dockendorf, architecte solutions senior chez Upsun, entend sans cesse la même plainte. Un service est provisionné pour une tâche qui s’exécute une fois par semaine, puis il reste inactif. La question que se posent les clients, selon lui : « Pourquoi est-ce que je paie pour ça toute la semaine alors que ça ne fait qu’une seule chose le vendredi ? »

Qu’est-ce qu’un conteneur de tâches, au juste ?

Une tâche est déclarée dans .upsun/config.yaml au même niveau que tes applications et tes services. Deux champs sont obligatoires : une image d’exécution, utilisant la même syntaxe que celle des applications, et la commande à exécuter. Lorsque la tâche est déclenchée, Upsun Cloud injecte un conteneur dans le cluster de l’environnement, exécute la commande jusqu’à son terme, puis supprime le conteneur.

« C’est en gros une ressource de calcul éphémère et à la demande », explique Corey. « Elles se lancent lorsqu’elles sont déclenchées directement par un appel API. Elles exécutent exactement une commande, puis s’arrêtent automatiquement une fois qu’elles ont terminé. »

Le fonctionnement est volontairement simple. Tu peux déclencher une tâche de trois façons :

• Depuis la console
• Depuis l’interface en ligne de commande (CLI), avec la commande `upsun task:run`
• Avec une requête POST vers https://api.upsun.com/projects/{project}/environments/{env}/tasks/{taskname}/run, en transmettant éventuellement des variables dans le corps de la requête

Chaque invocation crée une activité dotée de son propre identifiant, d’un statut « en cours », de journaux diffusés en continu et de la possibilité de l’annuler. Le délai d’expiration par défaut est d’une heure et le maximum est de 24 heures. La facturation s’effectue à la seconde pour chaque exécution, aux mêmes tarifs de CPU et de mémoire que tes applications.

Ce que les tâches ne sont pas : ce ne sont pas des démons, elles ne sont pas planifiées et elles ne sont pas routables. Le traitement en arrière-plan de longue durée reste du ressort d’un worker, et tout ce qui doit s’exécuter selon un calendrier fixe relève toujours d’un cron. Il est important de bien comprendre la différence entre les crons et les workers avant de te tourner vers une tâche, car les tâches répondent au troisième cas de figure : un travail qui doit être effectué maintenant, une seule fois, puis cesser d’exister. 

La planification elle-même se fait en dehors de la tâche. C’est un cron, une tâche d’intégration continue (CI) ou ta propre application qui effectue l’appel d’API ; ainsi, la fréquence reste planifiée tandis que la puissance de calcul reste à la demande.

Les tâches que tu exécutes déjà une fois par semaine

D’après l’expérience de Corey, le concept est plus facile à comprendre quand on le relie à quelque chose de banal.

« Tout le monde réindexe la base de données », dit-il. « C’est juste une de ces choses qu’il faut faire. C’est un nettoyage standard de la base de données. »

C’est aussi l’exemple qui fait changer les mentalités. « C’est celui-là qui accroche vraiment les clients, parce qu’ils se disent : “Ah oui, je fais ça. J’ai ça. Je déclenche ça. Peut-être une fois par semaine, toutes les deux semaines, tous les mois” », explique Corey.

Il observe le même schéma chez les PME, les entreprises de taille moyenne et les grandes entreprises, ce qui est logique quand on dresse la liste des candidats : maintenance des bases de données, exportations de données, rapports de fin de mois, migrations qui s’exécutent une seule fois lors d’une mise à jour et jamais plus.

Les tâches peuvent interagir avec le reste de l’environnement pendant leur exécution. Les relations déclarées permettent à une tâche d’accéder à des services et à des applications ; ainsi, une réindexation dispose bel et bien d’une base de données à interroger, et les identifiants apparaissent dans PLATFORM_RELATIONSHIPS à l’intérieur du conteneur de la tâche. Les relations ne fonctionnent que dans un sens. Ni les applications ni les autres tâches ne peuvent déclarer de relation avec une tâche, car celle-ci n’existe que pendant son exécution. Si ton application a besoin du résultat, la tâche l’envoie quelque part.

Les applications peuvent tout de même lancer des tâches. Accorde à l’appli l’autorisation d’exécuter une tâche spécifique, et elle demandera un jeton à durée de vie courte au moment de l’exécution auprès du point de terminaison de jetons local à l’adresse localhost:8200, plutôt que de conserver un identifiant à longue durée de vie. Ces jetons expirent par défaut au bout de 60 secondes, et tu peux prolonger leur durée jusqu’à 900 secondes avec l’en-tête x-token-ttl si tu souhaites réduire le nombre d’allers-retours.

Les agents ont besoin du contexte de production, pas d’un accès à la production

Le deuxième cas d’utilisation est plus récent, et c’est là que Corey poursuit la discussion dans le dernier épisode de « Product Highlights ».

Un agent IA qui effectue un vrai travail « a en fait besoin du contexte de production », explique-t-il. « Les logs, les métriques, l’historique des déploiements. » Ce qu’il ne doit pas avoir, c’est l’accès à l’application en production. « Tu ne veux vraiment pas non plus laisser un agent faire ce qu’il veut sur l’application en production », ajoute Corey. Lui donner les clés et se mettre en retrait est, selon ses propres termes, « une idée terrifiante ».

C’est le problème auquel la plupart des équipes se heurtent au même moment. Un agent qui ne peut pas accéder à l’environnement de production ne sert à rien sur le plan opérationnel. Un agent disposant d’identifiants pour accéder à la production représente un risque que personne ne veut assumer. Upsun a déjà abordé la version « zero-trust » de cet argument : la question n’est pas tant de faire confiance au modèle que de savoir si la plateforme qui l’entoure est capable de maintenir les limites.

Un conteneur de tâches est un moyen de définir cette limite. La session de l’agent s’exécute dans son propre conteneur avec les relations et les autorisations API que tu lui as accordées, et rien d’autre. Les tâches s’exécutent dans des conteneurs Linux avec le même niveau d’isolation que les applications : capacités restreintes, profil seccomp, limites cgroup, isolation réseau. Pour le code auquel tu ne fais vraiment pas confiance, la documentation suggère d’associer une tâche à « bubblewrap » pour restreindre encore davantage l’accès au système de fichiers et aux appels système.

« Avec un conteneur de tâches, tu peux donner à cet agent un vrai contexte, tout en bénéficiant d’un isolation adéquate au niveau du conteneur », explique Corey. « Et ensuite, cet agent peut lancer un environnement de test, valider ses propres modifications avant que quoi que ce soit ne soit fusionné en production. »

Cette dernière étape est plus importante que l’isolation en soi. Un agent qui propose une modification, ça ne coûte pas grand-chose. Un agent autorisé à créer une branche d’un environnement peut d’abord vérifier que la modification fonctionne sur des données similaires à celles de production, tout en laissant à un humain le soin de valider la fusion, et c’est ça qui rend le résultat exploitable.

Une maîtrise des coûts qui tient la route quand les agents se multiplient

La facturation à la seconde ressemble à un simple détail tarifaire jusqu’à ce que les agents entrent en scène. Les charges de travail des agents sont par nature irrégulières, et le risque ne réside pas dans une seule exécution coûteuse. C’est plutôt dans les centaines d’exécutions peu coûteuses que personne ne comptabilise.

Les ressources allouées aux tâches sont configurées comme pour n’importe quel autre conteneur : un petit job reçoit donc une petite allocation. Et les exécutions parallèles sont plafonnées, par défaut à trois (voire moins pendant la période d’essai), les exécutions supplémentaires étant mises en file d’attente plutôt qu’exécutées. Ce plafond sert autant de garde-fou financier que de limite de planification.

Ce qu’Upsun développe à partir de ça

Upsun a développé ses propres agents à partir de cette même base. Comme l’a dit l’animateur Jack Creighton dans l’épisode, le premier agent à voir le jour sera un agent de performance, et d’autres suivront.

Ce modèle est un enseignement utile, même si tu n’utilises jamais d’agent. Une ressource de calcul qui n’existe que lorsqu’elle est active élimine une catégorie de décision que tu devais auparavant prendre à l’avance : quelle quantité provisionner pour quelque chose qui, la plupart du temps, ne sert à rien. Tu n’as plus besoin de dimensionner en fonction de l’inactivité.

Commence par consulter la documentation sur les tâches et par la seule tâche de ta stack que tu sais déjà que tu lances une fois par semaine.