Infrastructure

AWS Prolonge les Sessions d'Agents IA de 8 Heures à 14 Jours

AWS a lancé le 6 août 2026 du calcul persistant avec GPU pour agents IA, prolongeant les sessions de 8 heures à 14 jours, disponible à Francfort et en Irlande. Pourquoi cela transforme le calcul IA en problème de budget serveur.

InfrastructurePar Servola Tech Desk2026-08-133 min de lecture

Assisté par IA, relu et corrigé par des humains. | Editor-in-Chief: Leon Soliman | Charte éditoriale

AWS Prolonge les Sessions d'Agents IA de 8 Heures à 14 Jours

Points clés

AWS a lancé le 6 août 2026 les Runtime Instances pour Amazon Bedrock AgentCore, qui permettent aux agents IA de fonctionner sur une infrastructure EC2 persistante et accélérée par GPU pendant jusqu'à 14 jours par session, soit une extension d'environ 40 fois par rapport au plafond de 8 heures qui s'appliquait aux invocations d'origine, basées sur des microVM, de la plateforme.
La fonctionnalité est disponible dès le lancement dans dix régions AWS, dont deux dans l'UE, Francfort et l'Irlande, aux côtés de US East Ohio et Virginie du Nord, US West Oregon et quatre régions Asie-Pacifique, ce qui met les charges de travail d'agents de longue durée à portée de la résidence des données de l'UE dès le premier jour.
Plusieurs agents déployés sur la même instance runtime collaborent en lisant et en écrivant des fichiers dans un répertoire de session partagé plutôt qu'en s'appelant mutuellement via des API, ce qui constitue une frontière de confiance sensiblement différente de celle que suppose la plupart des architectures agent à agent, et que les auditeurs de sécurité évaluant le service doivent modéliser explicitement.
La tarification combine les tarifs standards des instances EC2 avec des frais de gestion d'orchestration AgentCore supplémentaires, et les sessions peuvent être arrêtées puis redémarrées pour éviter de payer les périodes d'inactivité, mais le passage d'une facturation d'inférence par appel à un calcul provisionné sur plusieurs jours signifie que les charges de travail IA apparaissent désormais sur la facture cloud comme des serveurs persistants traditionnels, et non comme des appels API sans état.
Ce lancement répond discrètement à une question que les entreprises se posent depuis que l'IA agentique est passée des démonstrations à la production : les agents qui doivent fonctionner pendant des jours, se coordonner via un état partagé ou solliciter un GPU sur des périodes soutenues ne correspondent plus au modèle d'agent sans serveur d'origine d'AWS, si bien qu'AWS en a construit un second, en forme de serveur, à côté du premier plutôt que d'étirer celui-ci.

Ce Qui a été Lancé le 6 Août, et Où

L'annonce d'AWS décrit elle-même les Runtime Instances comme une 'infrastructure EC2 persistante et gérée pour agents IA en production, avec collaboration multi-agents, prise en charge GPU et sessions pouvant durer jusqu'à 14 jours'. Ce chiffre est le changement principal : les microVM d'AgentCore Runtime qu'AWS proposait jusque-là plafonnaient à 8 heures par invocation, ce qui convient à une tâche ponctuelle mais pas à un agent destiné à continuer de travailler, de surveiller ou d'attendre des événements externes sur plusieurs jours.

La disponibilité régionale au lancement couvre US East (Ohio, Virginie du Nord), US West (Oregon), Asie-Pacifique (Mumbai, Singapour, Sydney, Tokyo) et l'Europe (Francfort, Irlande). Pour toute organisation de l'UE tenue de maintenir le traitement des données de ses charges de travail d'agents à l'intérieur de l'UE pour des raisons de résidence ou contractuelles, la disponibilité de Francfort et de l'Irlande dès le lancement, et non des mois plus tard, est le détail à retenir.

Comment les Agents Communiquent Vraiment Entre Eux : un Répertoire Partagé, pas une API

L'exemple concret fourni par AWS est parlant : un agent qui écrit du code enregistre sa sortie dans un chemin comme /tmp/agentcore-session/{session-id}/code.py, et un second agent relecteur lit ce même chemin en utilisant le même identifiant de session, en se coordonnant via le système de fichiers partagé qu'une instance runtime met à disposition au sein d'une session, plutôt que par des appels API directs entre les deux agents.

C'est une architecture nettement différente du modèle requête-réponse qu'utilisent la plupart des cadres d'orchestration d'agents, et cela compte au-delà de la simple commodité. Un répertoire de session partagé est une frontière de confiance partagée : tout agent disposant d'un accès en écriture à ce chemin peut, en principe, modifier ce qu'un autre agent lit, ce qui constitue une surface de mouvement latéral à l'intérieur de ce qu'AWS présente comme une session isolée unique, et que toute revue de sécurité d'AgentCore doit tester explicitement plutôt que de le tenir pour acquis.

Le Vrai Changement : le Calcul IA Apparaît Désormais sur la Facture Comme un Serveur

La tarification des Runtime Instances correspond aux tarifs standards des instances EC2 plus des frais de gestion d'orchestration AgentCore, et la configuration d'exemple d'AWS elle-même, une instance c7g.2xlarge avec 8 vCPU et 16 Gio de mémoire, faisant tourner Linux Arm64 ou x86_64, se lit comme une fiche technique de serveur parce que c'en est une. Les sessions peuvent être arrêtées puis redémarrées pour éviter de payer les périodes d'inactivité, mais une instance provisionnée qui persiste jusqu'à 14 jours est un objet de coût fondamentalement différent d'un appel d'inférence sans état facturé au token.

Pour toute équipe financière ou plateforme qui budgétait jusqu'ici les dépenses d'IA générative purement comme un poste de coût d'inférence, c'est le moment où les charges de travail d'IA agentique commencent à se comporter comme le reste du parc de calcul : la planification de capacité, la gestion des temps d'inactivité et le choix du type d'instance redeviennent des questions budgétaires actives, tout comme avant que le modèle sans serveur ne les fasse disparaître.

Ce Qu'un Acheteur de l'UE Devrait Vérifier Avant d'Adopter les Runtime Instances

Deux questions méritent d'être tranchées avant un déploiement en production. Premièrement, pour toute charge de travail traitant des données personnelles ou réglementées, vérifier que la disponibilité à Francfort ou en Irlande satisfait réellement les exigences propres de l'organisation en matière de résidence et de localisation du traitement, car la disponibilité régionale du service n'équivaut pas automatiquement à une garantie sur l'endroit où atterrissent chaque donnée de session et chaque sortie de journal.

Deuxièmement, pour tout déploiement multi-agents utilisant le modèle de répertoire de session partagé, se poser la même question qu'une équipe de sécurité poserait pour toute architecture de système de fichiers partagé : quels agents peuvent écrire dans le chemin partagé, que se passe-t-il si la sortie d'un agent est malveillante ou corrompue, et si l'isolation qu'offre AWS entre sessions distinctes correspond à la frontière d'isolation dont l'organisation a réellement besoin entre les agents individuels qui fonctionnent au sein d'une même session.

Questions fréquentes

Cela remplace-t-il les microVM d'origine d'AgentCore Runtime de 8 heures ?

Non. AWS propose les Runtime Instances aux côtés des invocations existantes basées sur des microVM plutôt que de les remplacer ; le modèle microVM reste disponible pour les tâches plus courtes et sans état, tandis que les Runtime Instances ciblent les charges de travail nécessitant spécifiquement une persistance au-delà de 8 heures, un accès GPU ou une coordination multi-agents via un état partagé.

Le lancement à Francfort et en Irlande signifie-t-il que les données des agents restent automatiquement dans l'UE ?

La disponibilité régionale signifie que le calcul peut fonctionner dans ces régions, mais elle ne garantit pas en soi que chaque donnée de session, chaque journal ou chaque métadonnée reste à l'intérieur des frontières de l'UE ; une organisation soumise à des obligations de résidence devrait vérifier la documentation spécifique d'AWS sur les flux de données pour les Runtime Instances plutôt que de déduire une résidence complète des données à partir de la seule disponibilité régionale du service.

En quoi la tarification des Runtime Instances diffère-t-elle de celle d'une instance EC2 standard ?

Le calcul sous-jacent est facturé aux tarifs standards EC2, mais AWS ajoute par-dessus des frais de gestion d'orchestration AgentCore pour la gestion des sessions, la prise en charge de l'accélération GPU et les fonctionnalités de coordination par système de fichiers partagé propres au service ; AWS n'a pas publié ce tarif comme un chiffre fixe distinct du coût de base EC2.

AWS n'a pas simplement allongé son runtime d'agents sans serveur : l'entreprise en a construit un second, en forme de serveur, à côté du premier, car 14 jours de calcul persistant avec GPU et système de fichiers partagé ne sont pas une fonction sans serveur étirée, c'est un serveur. Les acheteurs qui continuent de le budgéter et de le réviser comme s'il s'agissait du premier passeront à côté à la fois du poste de coût et de la question de frontière de confiance que le second exige réellement.

AWSAmazon BedrockAgentCoreAI agentscloud computeEU data residency

Plus dans le Servola Journal

Cybersécurité

Des agents IA autonomes ont attaqué le gouvernement taïwanais

Pendant quatre jours en juillet 2026, jusqu'à huit agents IA basés sur des outils open source ont compromis plus de 85 comptes du gouvernement taïwanais et atteint le réseau électrique. Pourquoi cela concerne aussi l'UE.

4 min de lecture

Intelligence artificielle

Le Routeur de Nvidia Réduit de 58% la Facture IA de Ramp

Le nouveau routeur NeMo Switchyard de Nvidia réduit déjà de 58% les coûts des agents de code de Ramp, et de 74% selon LangChain, en n'appelant que rarement les modèles de pointe. Ce que cela change pour le budget IA.

7 min de lecture

Décisions

Le troisième virage était l'alerte que Magic Leap a ratée

Magic Leap a notifié 193 licenciements effectifs le 1er octobre 2026, son quatrième virage stratégique après 4 milliards de dollars levés. La leçon est dans le schéma, pas dans le virage.