Amazon a livré DevOps Agent en disponibilité générale le 17 avril 2026, le lancement en production d'un enquêteur d'incidents autonome qui était en preview depuis décembre 2025. Quand une alarme CloudWatch, une alerte PagerDuty, un problème Dynatrace ou un ticket ServiceNow se déclenche, l'agent prend le relais sans prompt humain : il corrèle la télémétrie, trace les dépendances à travers les services, ramène les changements de déploiement pis de code récents, pis propose une cause-racine. Le lancement atterrit une semaine après le préprint Auto-Diagnose de Google, qui utilisait Gemini 2.5 Flash pour le triage de logs de tests d'intégration avec 90,14% de précision cause-racine. Que deux gros fournisseurs cloud livrent du triage SRE par LLM dans la même semaine, c'est ça l'histoire, pas l'un ou l'autre pris tout seul.
En dessous du capot, c'est Amazon Bedrock AgentCore, le runtime d'agents d'AWS, pas une pile de modèles sur mesure. La surface d'intégration est large dès le premier jour : CloudWatch, Datadog, Dynatrace, New Relic, Splunk pis Grafana côté observabilité ; GitHub, GitLab pis Azure DevOps côté code pis CI-CD ; support Azure pis on-premises ajouté en GA. Model Context Protocol (MCP) est le mécanisme d'extension pour les skills custom, ce qui met l'agent SRE d'AWS pis la spec MCP originale d'Anthropic sur le même rail de standards. La facturation, c'est à la seconde de runtime d'agent, les clients AWS Support reçoivent des crédits DevOps Agent mensuels proportionnels au niveau de support, pis les régions de lancement incluent North Virginia, Irlande, Francfort plus trois autres.
Métriques du preview par AWS : jusqu'à 75% de réduction du MTTR pis 94% de précision cause-racine. Compare avec Auto-Diagnose à 90,14% sur le corpus de tests de Google, pis la convergence est dure à ignorer. Deux bases de code différentes, deux modèles frontières différents, deux charges cibles différentes (tests d'intégration vs incidents en prod), qui atterrissent dans 4 points de pourcentage l'un de l'autre. Ce que ça te dit : les modèles frontières plus le prompting soigné plus la télémétrie structurée plus une règle de refus-sur-ambiguïté sont maintenant le plafond pour cette tâche. Aucun des deux fournisseurs a fine-tuné un modèle custom ; les deux se sont appuyés sur la discipline du prompting pis une intégration serrée. La différence qui compte pour les développeurs, c'est que l'agent d'AWS est cross-fournisseur par design (il lit ton Datadog pis parle à ton PagerDuty), tandis que celui de Google est interne seulement pis sort pas comme produit.
Si tu roules sur AWS pis que t'as du volume d'incidents réel, le playbook flippe du jour au lendemain. La surface d'intégration, c'est les outils que t'utilises déjà, pis la facturation à la seconde veut dire que tu paies pour le runtime d'agent réel, pas de la capacité idle. Deux affaires à surveiller avant de faire confiance en production. Premièrement, la tarification à la seconde à cadence d'incidents plein : à des runs de 10 minutes par agent sur quelques centaines d'incidents par mois, c'est pas la même affaire qu'ajouter un pipeline de logs de plus. Deuxièmement, le comportement de refus. La contrainte anti-hallucination dure d'Auto-Diagnose était le choix d'ingénierie le plus important pour garder la précision haute. C'est pas évident dans l'annonce GA d'AWS si Bedrock AgentCore impose la discipline équivalente, ou si ça livre des réponses confidemment fausses quand la télémétrie est mince. Pour les développeurs qui sont pas sur AWS, le signal, c'est que l'enquête d'incident autonome est maintenant une catégorie de produit avec deux fournisseurs en live pis un standard d'interopérabilité de facto dans MCP. Attends-toi à ce qu'Azure livre un équivalent dans le trimestre, pis commence à réécrire les runbooks en formats agent-lisibles maintenant plutôt que plus tard.