Aller au contenu principal
Les sessions persistantes et l'exécution de commandes shell grâce à la configuration du système de fichiers
InfrastructureAWS ML Blog6sem

Les sessions persistantes et l'exécution de commandes shell grâce à la configuration du système de fichiers

Résumé IASource uniqueImpact UETake éditorial
Source originale ↗·

Amazon a annoncé deux nouvelles fonctionnalités pour son service Bedrock AgentCore Runtime : le stockage de session persistant (en préversion publique) et l'exécution directe de commandes shell via InvokeAgentRuntimeCommand. Ces capacités répondent à deux problèmes concrets que rencontrent les équipes qui déploient des agents IA en production. Chaque session AgentCore Runtime tourne dans une microVM isolée avec son propre noyau, sa mémoire et son système de fichiers. Jusqu'ici, à l'arrêt de la session, tout ce que l'agent avait créé — dépendances installées, code généré, historique git local — disparaissait. Le stockage managé de session règle ce problème en offrant un répertoire persistant, configurable au moment de la création de l'agent via le paramètre filesystemConfiguration, qui survit aux cycles arrêt/reprise même lorsque l'environnement de calcul est remplacé. La seconde fonctionnalité, InvokeAgentRuntimeCommand, permet d'exécuter des commandes shell déterministes comme npm test ou git push directement dans la microVM associée à la session active, sans passer par le modèle de langage.

L'impact est immédiat pour les équipes qui construisent des agents de développement. Avant ces ajouts, un agent de coding pouvait passer vingt minutes à scaffolder un projet — créer l'arborescence, installer les dépendances, configurer les outils de build — pour que tout disparaisse à la première pause. Au redémarrage, tout était à recommencer : vingt minutes de calcul brûlées avant de pouvoir reprendre un travail utile. De même, faire transiter une commande déterministe comme l'exécution de tests via le LLM ajoutait du coût en tokens, de la latence et une non-déterminisme inutile à une opération parfaitement prévisible. Les contournements existants, comme écrire une logique de checkpoint vers Amazon S3 avant chaque arrêt de session ou maintenir les sessions actives en permanence, fonctionnaient mais reportaient la complexité dans le code de l'agent plutôt que de résoudre le problème à la racine.

Ces annonces s'inscrivent dans une évolution plus large du rôle des agents IA dans les workflows de développement. Le système de fichiers est devenu la mémoire de travail principale des agents, leur permettant de dépasser les limites du contexte des LLM. Amazon Bedrock AgentCore Runtime, en intégrant nativement la persistance et l'exécution de commandes shell au niveau de l'infrastructure, cherche à s'imposer comme runtime de référence pour les agents de production. Cette approche concurrence directement des solutions comme les environnements de sandbox de Modal, les DevContainers GitHub Codespaces, ou les outils d'orchestration d'agents open source comme LangGraph et AutoGen, qui proposent leurs propres mécanismes de gestion d'état. La disponibilité en préversion publique du stockage de session laisse anticiper une disponibilité générale dans les prochains mois, vraisemblablement accompagnée d'une tarification spécifique liée au volume de stockage persistant utilisé.

Impact France/UE

Les équipes françaises et européennes développant des agents IA sur AWS Bedrock peuvent directement adopter ces nouvelles capacités de persistance et d'exécution shell, sans impact réglementaire spécifique à l'Europe.

💬 Le point de vue du dev

C'est exactement le problème que personne ne veut admettre publiquement : un agent qui perd son contexte à chaque pause, c'est du calcul jeté à la poubelle. Amazon règle ça au niveau infrastructure plutôt qu'en laissant chaque équipe bricoler ses checkpoints S3, et c'est le bon endroit pour le faire. Reste la question du prix, parce que du stockage persistant managé sur AWS, ça ne va pas rester gratuit longtemps.

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Dégradation du contexte, dérive d'orchestration et montée des défaillances silencieuses dans les systèmes d'IA
1VentureBeat AI 

Dégradation du contexte, dérive d'orchestration et montée des défaillances silencieuses dans les systèmes d'IA

Les systèmes d'intelligence artificielle déployés en entreprise souffrent d'un angle mort critique : leurs pannes les plus coûteuses ne déclenchent aucune alarme. Un système peut afficher un uptime parfait, une latence dans les clous et un taux d'erreur nul, tout en produisant des réponses fausses, construites sur des données périmées ou des contextes corrompus. C'est ce que les ingénieurs spécialisés en infrastructure IA appellent le « reliability gap », l'écart entre la santé opérationnelle d'un service et sa fiabilité comportementale. Contrairement aux bugs classiques, ces défaillances silencieuses n'apparaissent ni dans Prometheus, ni dans Datadog, ni dans aucun tableau de bord traditionnel. Le modèle lui-même est rarement en cause : c'est la couche d'infrastructure qui l'entoure, pipelines de données, systèmes de récupération d'information, logique d'orchestration, workflows aval, qui dérive sans être détectée. Quatre patterns de rupture reviennent systématiquement dans les déploiements en production. La dégradation du contexte survient quand le modèle raisonne sur des données obsolètes ou incomplètes sans que l'utilisateur final ne s'en aperçoive : la réponse paraît soignée, le grounding a disparu, et la détection n'arrive que des semaines plus tard via des conséquences indirectes. La dérive d'orchestration touche les pipelines agentiques : stables en test, ils se comportent très différemment en charge réelle, quand les latences se cumulent et que les cas limites s'enchaînent. Les pannes partielles silencieuses, elles, font basculer un système dans la méfiance des utilisateurs bien avant qu'un ticket d'incident ne soit créé. Enfin, le blast radius de l'automatisation est propre aux workflows IA : une mauvaise interprétation tôt dans la chaîne se propage à travers plusieurs systèmes et décisions métier, avec des conséquences organisationnelles très difficiles à inverser. Ce problème prend de l'ampleur à mesure que les entreprises industrialisent leurs usages de l'IA dans des domaines critiques, opérations réseau, logistique, plateformes d'observabilité. Les deux dernières années ont été consacrées à évaluer les modèles eux-mêmes : benchmarks, scores de précision, red-teaming. Mais en production, c'est l'infrastructure qui cède. La réponse technique passe par l'ajout d'une couche de télémétrie comportementale en complément des outils existants, non pour les remplacer, mais pour capturer ce que le modèle a réellement fait avec le contexte reçu, et pas seulement si le service a répondu. La question n'est plus « le service est-il en ligne ? » mais « le service se comporte-t-il correctement ? » Ce sont deux instruments différents, et l'industrie commence à peine à construire le second.

InfrastructureOpinion
1 source
Google et AWS répartissent la pile des agents IA entre contrôle et exécution
2VentureBeat AI 

Google et AWS répartissent la pile des agents IA entre contrôle et exécution

Google et Amazon Web Services viennent de redéfinir leurs approches respectives pour orchestrer les agents IA d'entreprise, révélant une fracture profonde dans la façon de concevoir l'infrastructure agentique. Google a lancé une nouvelle version de Gemini Enterprise, regroupant sous une même bannière sa plateforme Gemini Enterprise et son application éponyme, tout en rebaptisant Vertex AI en Gemini Enterprise Platform. De son côté, AWS a enrichi Bedrock AgentCore d'un système de harness, un dispositif de configuration automatique alimenté par Strands Agents, son framework open source. Ce harness permet aux équipes de définir ce que l'agent doit faire, quel modèle utiliser et quels outils appeler, le reste étant pris en charge automatiquement. Dans le même temps, Anthropic a dévoilé ses Claude Managed Agents et OpenAI a renforcé son Agents SDK, confirmant que l'ensemble de l'industrie cherche simultanément à résoudre le même problème : comment gérer des agents IA qui tournent durablement en production. L'enjeu dépasse la simple question de l'outillage développeur. À mesure que les agents passent de courtes tâches ponctuelles à des workflows autonomes de longue durée, un nouveau type de défaillance émerge : la dérive d'état (state drift). Un agent qui fonctionne en continu accumule de la mémoire, des réponses et un contexte évolutif. Avec le temps, ce contexte devient obsolète : les sources de données changent, les outils renvoient des réponses contradictoires, et l'agent perd en fiabilité sans que personne ne s'en rende forcément compte. C'est ce problème systémique que Google et AWS cherchent à prévenir, par deux chemins opposés. Google mise sur un plan de contrôle à la manière de Kubernetes, centré sur la gouvernance et la visibilité. AWS privilégie la vitesse de déploiement et la simplification de la configuration, en déléguant la coordination à la couche d'exécution. Cette divergence illustre une transformation plus profonde de la pile IA, qui se stratifie désormais en couches spécialisées. Google positionne Gemini Enterprise comme une porte d'entrée unifiée vers l'ensemble de ses systèmes IA, avec des outils de sécurité et de gouvernance inclus dans l'abonnement, selon Maryam Gholami, directrice senior produit chez Google. AWS, Anthropic et OpenAI s'orientent davantage vers la vélocité et la flexibilité d'exécution. La question de savoir quelle approche s'imposera reste ouverte : Gholami elle-même reconnaît que ce sont les clients qui dicteront les usages des agents longue durée, un domaine où les bonnes pratiques restent encore à définir. Le vrai test viendra lorsque les entreprises feront tourner ces systèmes en conditions réelles, avec des agents qui devront remonter de l'information, demander des validations humaines, et résister à la dégradation progressive de leur contexte.

UELes entreprises européennes qui déploient des agents IA en production sur Google Cloud ou AWS devront arbitrer entre les deux approches d'orchestration pour leurs workflows agentiques durables.

InfrastructureOpinion
1 source
Amazon S3 Files offre aux agents IA un espace de travail fichier natif, mettant fin à la séparation objet/fichier
3VentureBeat AI 

Amazon S3 Files offre aux agents IA un espace de travail fichier natif, mettant fin à la séparation objet/fichier

Amazon Web Services a lancé S3 Files, une nouvelle fonctionnalité qui permet de monter directement un bucket S3 dans l'environnement local d'un agent IA ou d'un développeur, comme s'il s'agissait d'un répertoire ordinaire. Disponible dès maintenant dans la plupart des régions AWS, cette solution repose sur la technologie Elastic File System (EFS) d'Amazon, connectée directement à S3 pour offrir une sémantique de fichiers complète et native. Aucune migration de données n'est nécessaire : les fichiers restent dans S3, accessibles simultanément via l'API objet classique et via le système de fichiers monté. Andy Warfield, vice-président et ingénieur distingué chez AWS, a expliqué à VentureBeat que cette approche a produit "une accélération considérable" pour des outils comme Kiro et Claude Code lors de tests internes. Le problème que S3 Files résout est fondamental pour les pipelines d'IA agentique. Les agents IA fonctionnent naturellement avec des chemins de fichiers et des outils de navigation de répertoires, mais l'essentiel des données d'entreprise réside dans des systèmes de stockage objet comme S3, accessibles uniquement via des appels API. Jusqu'ici, les équipes devaient télécharger les données localement avant que l'agent puisse les traiter, ce qui créait un problème critique de persistance d'état : lorsque l'agent compressait sa fenêtre de contexte, il "oubliait" ce qu'il avait déjà téléchargé, forçant l'utilisateur à répéter les instructions. Dans des pipelines multi-agents, où plusieurs agents doivent accéder simultanément aux mêmes données, la situation devenait ingérable. Avec S3 Files, un développeur peut simplement indiquer le chemin d'un répertoire de logs, et l'agent y accède directement sans étape intermédiaire. AWS annonce que des milliers de ressources de calcul peuvent se connecter simultanément à un même système de fichiers S3. Les tentatives précédentes de combler le fossé entre stockage objet et système de fichiers reposaient sur des couches logicielles dites FUSE (Filesystems in USErspace), comme Mount Point d'AWS, gcsfuse de Google ou blobfuse2 de Microsoft. Ces outils simulaient un système de fichiers en surface, mais butaient sur des limitations profondes : S3 ne supporte pas le déplacement atomique d'objets et ne possède pas de répertoires au sens strict. Ces pilotes bricolaient des métadonnées supplémentaires dans les buckets, cassant la vue API objet, ou refusaient les opérations fichier que le stockage ne pouvait pas exécuter. S3 Files rompt avec cette approche en intégrant directement EFS à S3, sans compromis entre les deux interfaces. Cette évolution s'inscrit dans la course des grands fournisseurs cloud à rendre leurs infrastructures compatibles avec les nouveaux usages de l'IA agentique, où la fluidité d'accès aux données devient un avantage concurrentiel direct.

UEDisponible dès maintenant dans la plupart des régions AWS, cette fonctionnalité est accessible aux développeurs et entreprises européens utilisant S3 pour leurs pipelines d'IA agentique.

InfrastructureActu
1 source
Les émissions de gaz à effet de serre des data centers pourraient dépasser celles de nations entières
4Ars Technica AI 

Les émissions de gaz à effet de serre des data centers pourraient dépasser celles de nations entières

Onze campus de centres de données en cours de construction aux États-Unis sont associés à des projets de centrales au gaz naturel dont les émissions combinées pourraient dépasser 129 millions de tonnes de gaz à effet de serre par an, soit plus que l'ensemble des émissions du Maroc en 2024. Ces chiffres proviennent de documents de demandes de permis atmosphériques examinés par WIRED, soumis auprès d'agences étatiques américaines. Les infrastructures concernées alimenteront des centres de données au service de quelques-unes des entreprises d'IA les plus puissantes du pays : OpenAI, Meta, Microsoft et xAI figurent parmi les bénéficiaires identifiés. Ces projets sont soit déjà annoncés, soit en cours de construction. Ce que révèlent ces chiffres dépasse largement un problème local : ils illustrent le coût climatique concret de la course mondiale à l'IA. La particularité de ces installations est qu'elles contournent le réseau électrique public pour alimenter directement et exclusivement les centres de données, un modèle dit "behind-the-meter". Résultat : leurs émissions échappent aux mécanismes habituels de régulation et de comptabilisation carbone. Pour les consommateurs, la dynamique est aussi préoccupante : cette stratégie est partiellement motivée par la volonté des géants technologiques d'éviter d'alourdir les factures d'électricité des ménages, qui subissent déjà une résistance publique croissante face à la hausse des tarifs. Cette tendance s'inscrit dans un contexte de saturation du réseau électrique américain : les délais de raccordement aux opérateurs traditionnels s'allongent considérablement, poussant les développeurs de centres de données à produire leur propre énergie. Les projets listés ne représentent selon WIRED que la partie émergée de l'iceberg, alors que les grandes entreprises technologiques s'engagent dans des centaines de nouveaux centres à travers le pays. La question de la compatibilité entre les objectifs climatiques des États-Unis et l'expansion effrénée de l'infrastructure IA se pose désormais avec une acuité nouvelle, au moment où plusieurs États commencent à examiner plus attentivement les permis accordés à ces projets énergétiques hors réseau.

UEL'UE, engagée dans des objectifs climatiques contraignants et le reporting carbone obligatoire, pourrait faire face à des pressions similaires si le modèle d'alimentation directe hors réseau se généralise dans ses propres projets d'infrastructure IA.

InfrastructureActu
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour