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.

57% des entreprises ont vu leurs agents IA se tromper avec assurance, la solution est une couche de contexte pour agents, mais qui en dispose?

Un agent IA d'entreprise répond avec une confiance totale, mais le chiffre est faux. Personne ne s'en aperçoit avant qu'on ne remonte la source jusqu'à une définition de métrique obsolète ou un document que le système de récupération n'a jamais consulté. Le modèle n'a pas échoué : c'est le contexte qui lui a été fourni qui a fait défaut. Selon une enquête VB Pulse menée en juin 2026 auprès de 101 entreprises qualifiées de plus de 100 salariés, 57% d'entre elles ont retracé, au cours des six derniers mois, une réponse d'agent IA fausse mais formulée avec assurance jusqu'à un contexte métier manquant ou incohérent, et 31% affirment que le problème s'est reproduit plusieurs fois. La cause est simple à identifier : la récupération de documents (retrieval) reste la méthode par défaut pour fournir du contexte métier aux agents dans 38% des entreprises, presque deux fois plus que l'approche suivante. Or le choix du système de récupération privilégie la facilité d'ingestion et la simplicité opérationnelle, la précision de récupération arrivant loin derrière, un problème qui ne se révèle qu'une fois le système déjà en production. Il existe une solution connue: une couche de contexte gouvernée, que chaque agent consulte au lieu d'improviser. Cette couche est censée constituer un modèle partagé de ce que signifient réellement les données de l'entreprise, construit une fois pour toutes plutôt que redérivé par chaque agent. Mais 75% des entreprises n'en possèdent pas encore. Seules 25% des répondants en exploitent une en production, 34% sont en train d'en construire une, et 41% n'ont rien entamé. Fait notable, parmi les entreprises qui construisent ou exploitent déjà une couche de contexte gouvernée, 78% rapportent avoir déjà subi une réponse faussement assurée, contre seulement 20% chez celles qui n'ont aucun projet en ce sens. Autrement dit, ce sont surtout les entreprises déjà échaudées qui se mettent à construire le correctif, tandis que les autres ne perçoivent pas encore l'urgence. Tous les grands éditeurs de plateformes de données et d'IA développent désormais leur propre version de cette couche de contexte, sans converger vers une architecture commune. DataHub traite les métadonnées de catalogue et des années de comportement de requêtes analystes comme une base de connaissances vivante. Microsoft, avec Fabric IQ, construit une ontologie métier interrogeable par tout agent via le protocole MCP. Couchbase parie sur une mémoire d'agent proche de la base de données opérationnelle plutôt que sur une couche de recherche greffée après coup. Pinecone, avec Nexus, précompile la logique structurelle dans la couche de métadonnées avant l'exécution. Snowflake combine deux systèmes, Horizon Context pour les définitions gérées par le client et Cortex Sense pour le contexte inféré automatiquement. Oracle, avec Unified Memory Core, fusionne données vectorielles, graphes et relationnelles dans un seul moteur transactionnel afin d'éliminer toute couche de synchronisation susceptible de se périmer. Google et AWS misent tous deux sur des graphes de connaissances qui s'affinent à partir des journaux de requêtes et de l'usage réel des agents. Pour Michael Ni, vice-président et analyste principal chez Constellation Research, l'enjeu est clair: qui contrôle le contexte au moment de l'exécution contrôle la couche de décision de l'IA sur les données de l'entreprise, la mémoire vectorielle seule ne suffisant pas à garantir un sens métier fiable.

💬 57% des entreprises se sont fait avoir par un agent qui répond faux avec un aplomb total, et 75% n'ont toujours pas la couche de contexte qui corrigerait ça. Le vrai enseignement du papier, c'est que ce sont surtout les boîtes déjà brûlées qui se mettent à la construire, les autres n'ont pas encore compris l'urgence. Microsoft, Snowflake, Oracle, chacun bâtit sa version maison sans converger vers un standard commun, et aucun acteur européen n'est dans la partie sur un sujet qui va peser lourd sur qui contrôle la donnée métier des agents IA.

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.