La charge de travail des agents est structurellement différente

Les agents sont des processus avec état de longue durée. Ils raisonnent dans le temps, appellent des outils externes, génèrent des sous-processus, écrivent et exécutent du code et prennent des décisions qui dépendent de ce qui s’est passé cinq étapes plus tôt dans la même tâche. Un flux de travail à agent unique peut s’exécuter pendant des minutes ou des heures, touchant une douzaine de systèmes externes et générant des résultats intermédiaires dont dépendent les étapes suivantes. La couche de calcul pour ce type de travail doit faire des choses que l’ancien modèle n’a jamais été invité à faire. C’est le nouveau modèle : une infrastructure d’exécution conçue autour de la sémantique des agents plutôt que de la sémantique des requêtes.

La communauté Kubernetes elle-même a reconnu cette inadéquation. En mars 2026, Kubernetes SIG Apps a publié une introduction à Agent Sandbox, une nouvelle abstraction basée sur CRD conçue spécifiquement pour les charges de travail d’agent avec état unique. Le cadre est direct : l’écosystème passe de tâches isolées de courte durée au déploiement de plusieurs agents d’IA coordonnés qui s’exécutent en continu, et le mappage de ces charges de travail aux primitives Kubernetes traditionnelles nécessite une abstraction entièrement nouvelle. Le fait que les responsables de Kubernetes aient construit une primitive dédiée à cet effet, plutôt que de recommander aux équipes d’en composer une à partir des ressources existantes, est en soi le signal le plus clair que l’exécution des agents ne correspond pas à l’ancien modèle.

Ce que nécessite réellement l’exécution de l’agent

Concrètement, cela nécessite quatre choses. Premièrement, des environnements d’exécution isolés qui provisionnent en millisecondes et non en minutes, de sorte que chaque tâche d’agent dispose de son propre bac à sable pour l’exécution du code et les appels d’outils sans bloquer la boucle de raisonnement. La différence entre un environnement de deux secondes et un environnement de deux minutes ne constitue pas une optimisation des performances ; il détermine si l’architecture est viable ou non. Deuxièmement, une gestion durable de l’état tout au long du cycle de vie des tâches, afin qu’un agent puisse mettre en pause, transférer ou reprendre sans réinitialiser à partir de zéro et graver des jetons pour reconstruire le contexte qu’il a déjà créé. Troisièmement, les primitives de coordination pour le travail multi-agents : la possibilité de générer des sous-agents, de transmettre des sorties structurées entre eux et de suivre les dépendances des tâches sur un graphique de processus simultanés. Les systèmes d’agents de production sont rarement des agents uniques ; ce sont des pipelines d’agents spécialisés avec des transferts qui doivent être fiables et inspectables. Quatrièmement, la gestion des informations d’identification et des secrets évolue avec le contexte d’exécution, afin que les agents puissent s’authentifier auprès des services externes en toute sécurité sans exposer les informations d’identification dans la définition de tâche, les journaux ou les variables d’environnement d’un conteneur partagé.

A lire également