Vers l'IA Agentique chez AWS

Le re:Invent 2025 a marqué un tournant côté AWS passant de l’IA générative vers une IA agentique, avec des agents autonomes capables de collaborer avec les membres de l’équipe. Bedrock agentcore en est l’exemple.

La famille des Frontier Agents

Dans cette vision, AWS introduit une nouvelle famille de Frontier Agents qui couvrent l’ensemble du cycle de vie logiciel :

• Kiro Autonomous Agent, le « développeur virtuel » orienté spec‑driven development dont on a déjà parlé sur le blog, qui part d’une spécification exécutable pour concevoir, implémenter et faire évoluer vos applications.
• AWS DevOps Agent, l’agent dont nous allons parler ici est positionné comme un SRE virtuel chargé de maintenir les services en condition opérationnelle.
• AWS Security Agent, l'ingénieur sécurité virtuel qui industrialise les revues de conception, les revues de code et les tests d’intrusion sur tout le cycle de vie applicatif.

Fonctionnement de l'AWS DevOps Agent

AWS Devops Agent est un agent IA autonome qui cartographie votre infrastructure, consomme vos signaux d’observabilité et automatise une bonne partie du run. Il peut être déclenché par une alerte (CloudWatch, Datadog, Dynatrace, New Relic, Grafana, Splunk, etc.), par un ticket ou par une simple interaction chat. Il enquête sur l’incident, propose des actions de remédiation, et peut dialoguer avec l’équipe de run via Slack, ServiceNow ou PagerDuty pour partager ses analyses et plans d’actions.

Pour s’intégrer à des systèmes externes, il s’appuie sur des serveurs MCP (Model Context Protocol), ce qui permet de brancher des outils maison ou des plateformes SaaS. Ses appels aux services AWS restent encadrés par des politiques IAM, ce qui délimite précisément son périmètre d’action (lecture seule, remédiations automatisées, etc.) et facilite l’audit.

Rôle de SRE Virtuel

AWS présente le DevOps Agent comme un SRE d’astreinte virtuel, toujours disponible, qui enquête sur les incidents et propose des plans de remédiation comme le ferait un SRE.

Il apprend la topologie de vos applications (services, bases, files de messages, dépendances externes) en croisant les métadonnées AWS, les métriques, logs et traces, il puise aussi les informations issues des pipelines CI/CD et de dépôts Git.

Lorsqu’une alerte arrive l’agent démarre automatiquement une investigation, corrèle les signaux, remonte une ou plusieurs causes probables et propose un plan d’action détaillé (rollback, ajustement de capacité, modification de configuration, etc.).

Tout au long de l’incident, il documente sa démarche (hypothèses, métriques consultées, traces, changements de code associés) ce qui remplace en partie les traditionnels tickets d’incident et simplifie le post‑mortem.

Intégrations

En entrée, l’agent se connecte :

• Aux services d’observabilité : CloudWatch, mais aussi Datadog, Dynatrace, New Relic, Grafana, Splunk, etc.
• Aux outils de ticketing / incidents : ServiceNow, PagerDuty, et plus généralement tout ce qui peut émettre des webhooks (par exemple des alertes Grafana ou des incidents PagerDuty).
• Aux systèmes de CI/CD et de gestion de code : GitHub, GitLab, Azure DevOps, pour corréler chaque incident avec les derniers déploiements et changements de code.

Cette vision full‑stack lui permet de ne pas se limiter à ”il y a plus d’erreurs 500”, mais de remonter jusqu’au commit ou au changement d’infra qui a déclenché le problème.

En sortie, le DevOps Agent peut :

• Partager ses analyses dans Slack, ServiceNow ou PagerDuty, avec un fil d’investigation qu’on peut suivre comme on suivrait un channel de war room.
• Déclencher de l’automatisation côté AWS : appels d’API, playbooks, intégrations EventBridge, voire exécuter des procédures internes encapsulées dans des skills personnalisées.
• Escalader vers un humain, y compris en ouvrant un ticket AWS Support pré‑rempli avec tout le contexte de l’enquête.

Pour une équipe de run, cela ressemble beaucoup à un collègue qui prend le relais sur l’investigation, poste ses hypothèses dans le channel d’incident, et propose un plan d’action que l’on peut ensuite valider ou laisser exécuter automatiquement.

La vraie différence avec agent branché à CloudWatch, c’est l’intégration via Model Context Protocol (MCP).

MCP permet d’exposer des outils externes (API internes, plateformes SaaS, bases de documentation, CMDB maison, etc.) que l’agent peut appeler.
Plutôt que d’écrire une intégration spécifique pour chaque outil, vous exposez côté MCP un ensemble de fonctions (par exemple : récupérer la topologie réseau d’un datacenter on‑prem, interroger des logs applicatifs historiques, lire une CMDB) et le DevOps Agent les découvre et les orchestre comme n’importe quel autre outil.

C’est ce qui lui permet, par exemple, d'investiguer des incidents sur des workloads on‑premises en utilisant vos propres outils de supervision exposés via MCP. d’enrichir une investigation avec des données issues de systèmes hors AWS (CMDB, inventaire de clusters Kubernetes, observabilité maison, etc.).

Devops Agent hors AWS

Au-delà de la gestion des infrastructures hors AWS avec le devops agent via du mcp il est également possible de construire en interne un DevOps Agent sur mesure. En effet AWS met à disposition des serveurs MCP pour plusieurs services en preview. Ils couvrent notamment la documentation, l’observabilité, les bases de données, les files de messages et plusieurs briques IA. Dans un environnement largement AWS, on peut donc orchestrer un agent DevOps avec le LLM de son choix, le déclencher sur des alertes CloudWatch ou d’outils d’observabilité externe. Ainsi on conserve une logique proche de celle d’un Frontier Agent, tout en maîtrisant son modèle de coût et son déploiement.

La liste des serveurs mcp disponibles sur aws : https://awslabs.github.io/mcp/

Sécurité et Gouvernance

Donner à un agent IA le droit d’agir sur votre prod pose évidemment des questions de sécurité et de gouvernance.

Le périmètre d’action du DevOps Agent est défini par :

• Des rôles iam et policies que vous lui assignez, qui limitent strictement les API qu’il peut appeler (lecture seule, actions de remédiation ciblées, création de tickets, etc.).
• Les Agent Spaces, qui définissent quel environnement l’agent voit (quelques comptes AWS, un ensemble de projets, un périmètre d’équipe) et à quelles intégrations externes il a accès.

Vous pouvez ainsi, par exemple, commencer avec un espace en lecture seule sur un environnement de staging, ou limiter l’agent à l’investigation (pas de remédiation automatisée) en prod. Toute l’activité passe par les logs et CloudTrail, ce qui facilite le suivi.

Pricing

Côté facturation, le mode de calcul change un peu nos réflexes d’ingénieur cloud.

Le DevOps Agent est facturé au temps d’agent, en secondes, correspondant au temps passé à mener des investigations, des analyses préventives ou des tâches SRE à la demande, indépendamment du mode de déclenchement (alerte, ticket, chat, tâche planifiée).

Il ne sera pas ici question de token comme on peut le retrouver sur des modèles classiques de LLM.
Il n’y a pas de coût d’ownership : tant que l’agent ne travaille pas vous ne payez rien.

Un gros incident analysé en profondeur peut coûter quelques centaines ou milliers de secondes d’agent, mais en échange d’un temps de rétablissement du service réduit et de moins de personnes mobilisées ainsi qu’un CA sauvegardé.

Des tâches de revue préventive (analyse régulière des incidents passés, recommandations d’amélioration) peuvent être planifiées mais doivent être pensées comme n’importe quel batch coûteux côté cloud.

Pour une équipe FinOps / run, il va falloir intégrer ce nouveau type de coût dans les modèles de coût total de possession du run : comparer le coût d’un agent à la réduction du temps d’astreinte, aux gains de productivité et aux incidents prévenus.

Même si cet article est centré sur le DevOps Agent, il vaut la peine de situer brièvement l’AWS Security Agent dans le tableau.

Ce Frontier Agent applique une logique similaire, mais orientée sécurité : il industrialise les revues de conception, les revues de code, les scans d’infra et les tests d’intrusion continus, en s’intégrant très tôt dans le cycle de développement.
On peut, par exemple, lui confier l’analyse d’un nouveau projet dès la phase d’architecture, puis la revue automatique des MR sensibles et campagnes régulières de pentest as code sur des environnements de pré‑production ou même de production sous contrôle.

Une vision globale

La combinaison Kiro + DevOps Agent + Security Agent dessine la vision d’AWS de gestion du run avec une architecture agentique : une chaîne complète où des agents spécialisés collaborent sur tout le cycle de vie, de la spec, l’implémentation à l’exploitation en passant par la sécurité.

Le Frontier Agent DevOps ne remplace pas la compétence SRE, mais change la répartition du travail : L’agent prend en charge une partie de l’investigation, de la corrélation de signaux et de la documentation d’incident.

Les humains peuvent ainsi se recentrer sur la définition des bonnes guardrails (IAM, périmètres, skills), sur l’architecture et sur les décisions à fort impact.

Le run devient plus ”as code” : les compétences SRE se cristallisent sous forme de skills, de playbooks et d’intégrations MCP réutilisables par les Frontier Agents.

Kiro est sorti en GA en novembre 2025 et Frontier Agent Devops le 31 Mars 2026. Il est, à la date de cet article (2 juin 2026) disponible dans 6 régions AWS uniquement. AWS Security Agent est également passé en GA le 31 mars et est déployé dans les mêmes régions que Frontier Agent.