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

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

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é.

💬 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.

Definity intègre des agents dans les pipelines Spark pour détecter les erreurs en amont des systèmes d'IA autonomes

Definity, une startup spécialisée dans la fiabilité des pipelines de données, basée à Chicago, a annoncé mercredi une levée de fonds de 12 millions de dollars en série A, menée par GreatPoint Ventures avec la participation de Dynatrace, StageOne Ventures et Hyde Park Venture Partners. La société a développé une approche radicalement différente de la surveillance des pipelines : plutôt que d'analyser ce qui s'est passé après l'exécution d'un job, elle intègre un agent directement à l'intérieur du moteur Spark ou DBT, pendant que le pipeline tourne. Concrètement, un agent JVM s'installe en une seule ligne de code sous la couche plateforme, capturant en temps réel le comportement des requêtes, la pression mémoire, le déséquilibre des données et les patterns de shuffle. L'agent peut alors intervenir activement : réallouer des ressources à mi-parcours, stopper un job avant que des données corrompues ne se propagent, ou bloquer un pipeline en aval si la table d'entrée en amont est périmée. Un client entreprise a identifié 33 % de ses opportunités d'optimisation dès la première semaine de déploiement, réduit de 70 % l'effort de débogage, et résout désormais les problèmes Spark complexes jusqu'à dix fois plus vite. L'enjeu va bien au-delà de l'efficacité opérationnelle : avec l'essor des systèmes d'IA agentiques, la fiabilité des données en entrée devient critique. Un pipeline qui échoue silencieusement ou livre des données obsolètes ne casse plus seulement un tableau de bord, il compromet l'ensemble du système d'IA qui en dépend. La distinction est fondamentale : la détection et la prévention sont en temps réel, tandis que l'analyse des causes profondes et les recommandations d'optimisation s'effectuent à la demande, avec tout le contexte d'exécution déjà assemblé. L'agent n'ajoute qu'environ une seconde de calcul sur un job d'une heure. Seules les métadonnées transitent à l'extérieur, et un déploiement entièrement on-premises est disponible pour les environnements sensibles. Les outils existants, qu'il s'agisse de Datadog (qui a racheté Metaplane l'an dernier), des system tables Databricks, ou de plateformes comme Unravel Data et Acceldata, lisent tous les métriques une fois le job terminé. Comme le résume Roy Daniel, CEO et co-fondateur de Definity : « Le moment où vous apprenez qu'un problème s'est produit, il s'est déjà produit. » Le marché de l'observabilité des données est en pleine structuration, porté par la multiplication des pipelines complexes et l'exigence croissante des systèmes d'IA en production. Nexxen, plateforme adtech opérant de large pipelines Spark pour la publicité en temps réel, fait partie des premiers clients en production. La participation de Dynatrace au tour de table est notable : l'entreprise, spécialiste de l'observabilité IT, investit ainsi dans une approche concurrente à ses propres capacités de monitoring, signe que la niche de l'exécution inline commence à être prise au sérieux.

L'architecture de contexte remplace le RAG à mesure que les agents IA poussent la récupération d'information en entreprise à ses limites

Redis a lancé lundi Redis Iris, une plateforme de contexte et de mémoire conçue pour les agents d'intelligence artificielle en production. L'annonce vient du CEO Rowan Trollope et marque une évolution majeure dans la stratégie de l'entreprise, historiquement connue comme couche de cache pour les applications web. Redis Iris se positionne entre l'agent et les données dont il a besoin pour agir, en combinant cinq composants : Redis Data Integration (désormais en disponibilité générale), qui synchronise en continu les bases relationnelles, entrepôts et documents via des connecteurs pour Oracle, Snowflake, Databricks et Postgres ; un Context Retriever (en préversion) qui génère automatiquement des outils MCP à partir de modèles de données métier définis en Pydantic, avec contrôles d'accès appliqués côté serveur ; un serveur de mémoire agent pour conserver le contexte à court et long terme entre les sessions ; et Redis Flex, un moteur de stockage réécrit faisant tourner 99 % des données sur SSD et 1 % en RAM, réduisant le coût à un dixième du stockage purement en mémoire. La raison d'être de cette architecture tient à un déséquilibre structurel entre agents et humains. Trollope le formule clairement : les entreprises auront un nombre d'agents plusieurs ordres de grandeur supérieur à celui de leurs employés humains, ce qui génère une charge équivalente sur les systèmes backend. Les pipelines RAG classiques, construits pour des requêtes humaines ponctuelles, ne tiennent pas face au volume que produisent des agents opérant en continu. Redis inverse la logique : plutôt que de présupposer quelles données injecter dans le pipeline, il laisse l'agent tirer lui-même l'information via des interfaces construites pour lui. Le marché confirme l'urgence : selon le VB Pulse RAG Infrastructure Market Tracker du premier trimestre 2026, l'intention d'adoption du retrieval hybride a triplé de 10,3 % à 33,3 % entre janvier et mars, l'optimisation du retrieval est devenue la première priorité d'investissement enterprise devant l'évaluation, et les stacks de retrieval maison sont passées de 24,1 % à 35,6 % du marché. Redis n'est pas le seul acteur à repositionner son offre autour des couches de contexte agent, plusieurs fournisseurs de plateformes de données ayant fait des annonces similaires ces dernières semaines. Trollope tire le parallèle avec l'ère mobile : quand les systèmes bancaires conçus pour les guichets ont dû absorber des millions d'utilisateurs smartphone, Redis est devenu la couche de cache qui a évité une refonte totale des backends. La différence aujourd'hui, c'est que les agents ne peuvent pas écrire leur propre middleware : ils ont besoin, au moment de l'exécution, d'interfaces préparées en amont, ou ils s'arrêtent. La transition de l'infrastructure RAG vers des architectures de contexte dédiées aux agents semble donc moins être une tendance émergente qu'un basculement déjà en cours dans les grandes entreprises.

Ce que les benchmarks IA ne mesurent pas dans les conditions réelles

Les benchmarks utilisés par les équipes d'infrastructure IA ne reflètent pas les conditions réelles de production, et cet écart coûte cher aux entreprises. C'est le constat que dressent des ingénieurs de F5 et MinIO, qui ont mené des tests de débit dans des conditions réseau dégradées. Leurs résultats sont frappants : dès qu'on introduit une latence modeste dans le chemin vers le stockage objet S3, le débit chute drastiquement. Et à mesure que la latence augmente, comme c'est le cas sur des distances longue portée, la dégradation devient sévère. Autre surprise : la latence s'est révélée bien plus destructrice que le jitter réseau, à l'inverse de ce que l'équipe anticipait. Paul Pindell, architecte solutions chez F5, le formule clairement : "Les tests benchmark sont construits pour produire les meilleurs résultats possibles, pas les plus réalistes. Introduire une latence constante dans le chemin de test est indispensable pour que les chiffres aient un sens." Le problème concret est que les GPU, ressource la plus visible et la plus coûteuse de tout déploiement IA, ne génèrent de la valeur que si le chemin de données qui les alimente fonctionne correctement. Or ce chemin passe par le stockage, le réseau, les bases de données, les couches de sécurité et d'orchestration, souvent assemblées depuis plusieurs fournisseurs. Quand ce chemin se dégrade, les effets se cumulent : sous-utilisation des GPU, dégradation des sorties IA, hausse des coûts de transfert liés à la réplication inutile de données, et complexité opérationnelle croissante. Tanu Mutreja, directrice produit chez F5, souligne que les charges de travail IA sont structurellement plus exposées à ces défaillances que les applications traditionnelles. Contrairement aux bases de données ou aux systèmes ERP, qui absorbent les délais transitoires via des caches et des tampons, les clusters GPU massivement parallèles n'ont aucun mécanisme équivalent. Le moindre pic de latence ou goulot d'étranglement peut se propager immédiatement à l'ensemble du pipeline. Cette prise de conscience change la manière dont les architectes d'entreprise doivent concevoir leur infrastructure IA. Hunter Smit, responsable marketing produit chez F5, résume le paradoxe : "Les entreprises achètent suffisamment de GPU et de stockage, puis supposent que le chemin entre les deux tiendra. Mais le trafic IA est par rafales, très concurrent, et aléatoire dans ses lectures, d'une manière que les réseaux de stockage classiques n'ont jamais été conçus pour absorber." La réponse qui émerge dans l'industrie est le déploiement de contrôleurs de livraison applicative (ADC) ou de plateformes de livraison et sécurité (ADSP) en amont du stockage, pour créer un point de contrôle résilient. Le message central est que les décisions d'infrastructure fondées sur des benchmarks en environnement contrôlé exposent les organisations à des surprises coûteuses en production, et que la performance du chemin de données est devenue un levier stratégique au même titre que la capacité de calcul brute.