Développer un Copilot SRE autonome pour AWS utilisant MCP, Bedrock Nova et l’approbation humaine.

Pendant environ un an, l’industrie s’est concentrée sur le ChatOps : intégration de modèles LLM dans Slack ou Telegram en tant que couches d’encapsulation autour des pipelines CI/CD. Cependant, les chatbots ne représentent que l’aspect visible. La véritable valeur pour les entreprises réside dans le passage de chatbots réactifs à des agents autonomes. Un copilote autonome pour l’ingénierie de fiabilité des sites (Site Reliability Engineering, SRE), développé sur Amazon Bedrock (Nova), le Model Context Protocol (MCP) et AWS, illustre ce concept. Il va au-delà du simple déclenchement de pipelines : il analyse en autonomie les incidents en production, récupère des métriques et des journaux, identifie les causes profondes et applique des correctifs, tout cela au sein d’une zone de confiance sécurisée avec un intervenant humain impliqué.

L’option gérée : AWS DevOps Agent

Au lieu de créer des solutions sur mesure, un architecte devrait d’abord vérifier si AWS propose déjà cette fonctionnalité. En effet, elle existe sous une certaine forme. AWS a lancé le DevOps Agent lors de re:Invent 2025, en version bêta à partir de décembre 2025 et disponible en général à partir de mars 2026. Il s’agit d’un système multi-agents puissant conçu pour une réponse autonome aux incidents sur AWS.

Il dépasse de loin des outils plus anciens tels que DevOps Guru :

• Réponse autonome aux incidents. Un alarme déclenchée par CloudWatch lance une enquête qui corrèle les données de télémétrie, les journaux, les traces, les modifications de code et l’historique des déploiements afin d’identifier la cause racine et de rédiger des plans d’atténuation.
• Prévention proactive. Il analyse les schémas d’incidents historiques et propose des améliorations en matière de capacités d’observation, d’infrastructure et de pipelines.

Études de prêt à la mise en production. Elles examinent les modifications de code et les pipelines de déploiement avant qu’ils n’atteignent la production.

Conception multi-agents. Un orchestrateur principal dirige des sous-agents spécialisés pour l’analyse des journaux, la recherche de la cause racine et des tâches similaires, selon le même modèle utilisé dans cette construction.

Intégrations étendues. Datadog, Dynatrace, New Relic, Splunk, PagerDuty, GitHub, GitLab, ServiceNow et Slack se connectent directement sans configuration supplémentaire.

En théorie, cela couvre tout ce qu’une équipe SRE pourrait souhaiter.

Pourquoi en créer une personnalisée

Le problème réside dans l’accès. L’agent DevOps est inclus dans les forfaits AWS Support de niveau Business+ et Enterprise, et n’est pas disponible au grand public sur demande. Une organisation utilisant le forfait Developer Support, une startup, une équipe indépendante ou un consultant travaillant sur le compte d’un client sans forfait Enterprise ne peut tout simplement pas l’utiliser.

Le service géré convient aux équipes déjà bénéficiant du support Enterprise qui travaillent selon les modèles standards d’AWS, puisque AWS s’occupe de la majeure partie du travail et que les intégrations sont nombreuses. Pour un architecte en intelligence artificielle, la question plus intéressante est de savoir si ce modèle est suffisamment bien compris pour pouvoir le développer indépendamment et l’étendre là où le produit géré s’arrête. C’est ce que montre ce projet.

Le problème principal : les outils à grande échelle

Des modèles comme Amazon Nova comprennent les systèmes distribués, les architectures d’AWS et le débogage complexe. Prêts à l’emploi, ils restent néanmoins des « cerveaux dans un bocal » : ils ne peuvent pas consulter les métriques CloudWatch ni interagir avec les tables DynamoDB.

Fournir un LLM en dehors des outils traditionnels signifiait généralement recourir à du code personnalisé fragile :

1. Définir un schéma JSON pour l’outil.
2. Rédiger une fonction Python qui le fait fonctionner.
3. Insérer manuellement les identifiants AWS dans l’exécution de l’agent.

Cela lie étroitement l’agent à l’infrastructure, ce qui crée des problèmes de sécurité et des goulots d’étranglement en matière de maintenance.

Apparition du MCP

Le Model Context Protocol, introduit par Anthropic et devenu rapidement une norme du secteur, résout ce problème de manière efficace. Il s’agit d’un protocole standardisé, un peu comme USB-C pour l’IA, qui relie les modèles à des sources de données et des outils externes. Au lieu d’intégrer directement des outils AWS dans l’agent, on crée un serveur MCP distinct. Ce dernier se trouve au sein de l’environnement AWS, doté des rôles IAM nécessaires, et expose des outils strictement typés et sémantiques via le protocole standard. L’agent, qui peut fonctionner n’importe où, se connecte en tant que client MCP. Il n’a pas besoin de crédentielles AWS, car il demande simplement au serveur d’exécuter des outils pour lui.

Liberté de choisir le modèle

Puisque le MCP ne se soucie pas du modèle situé de l’autre côté, l’orchestrateur d’agents SRE peut utiliser celui qui convient le mieux :

Amazon Nova  ─┐
Claude 3.5   ─┼──→  SRE Agent Orchestrator  ──→  MCP Server  ──→  AWS Cloud
OpenAI GPT-4o─┘          (agent.py)                (server.py)

Évaluer un modèle provenant d’un autre fournisseur signifie modifier une ligne de code. Le serveur MCP ainsi que tous les outils sécurisés d’AWS qu’il expose restent exactement identiques.

Architecture du copilote SRE

1. L’infrastructure cible

Afin de fournir à l’agent quelque chose à réparer, un microservice serverless standard est déployé à l’aide de Terraform : API Gateway en amont d’une fonction Lambda qui écrit dans une table DynamoDB. La faille intentionnelle consiste en une table affaiblie, dotée uniquement d’une unité de capacité de lecture et d’une unité de capacité d’écriture. Sous toute charge réelle, cette API génère des erreurs de type ProvisionedThroughputExceededException.

2. Le serveur MCP

Un serveur FastMCP en Python sert de médiateur, exposant quatre fonctionnalités SRE :

• describe_architecture permet de trouver tous les ressources AWS (ARN) portant une étiquette d’application.

query_cloudwatch_metrics récupère des données en série temporelle telles que ThrottledRequests.

query_cloudwatch_logs exécute des requêtes CloudWatch Logs Insights pour localiser les traces d’erreur.

remediate_dynamodb_capacity est un outil mutant qui augmente la capacité de la table.

La frontière de confiance est l’endroit où intervient l’humain. Les outils en lecture seule sont entièrement autonomes, ce qui permet au modèle de les utiliser autant qu’il le souhaite pour mener des investigations. Cependant, l’outil de correction impose une stricte procédure d’intervention humaine. Avant d’appeler l’API AWS, il s’arrête et demande à l’opérateur dans la console une approbation sous forme de [y/N], en affichant la justification du modèle. Disposer d’un point de contrôle auditable pour chaque action modifiant l’état, défini selon les règles propres à une organisation, est quelque chose que DevOps Guru et Amazon Q ne proposent pas.

3. L’agent autonome

Cet agent est un petit script Python qui communique avec l’API Amazon Bedrock Converse via boto3, le modèle de la famille Amazon Nova ayant été choisi pour ses capacités et son faible coût. Il exécute une boucle while autonome :

1. Il reçoit une instruction telle que "Les utilisateurs signalent que l’API de paiement rencontre des temps d’attente excessifs. Corrigez-le."
2. Il demande au serveur MCP quels outils sont disponibles.
3. Il convertit directement les schémas des outils MCP en format Bedrock Converse.
4. Il commence à raisonner : il trouve les ressources de l’API de paiement, vérifie leurs métriques, puis lit les journaux.
5. Il utilise les outils via MCP, renvoie les résultats à Bedrock et continue jusqu’à trouver une solution avant d’activer l’outil de correction.

La boucle en action

Lorsqu’on lui demande d’identifier la raison pour laquelle l’API de démonstration renvoie des réponses 429 et 500, en se concentrant sur la table DynamoDB soumise à des restrictions de fréquence, l’agent suit ces étapes :

1. Il appelle describe_architecture pour trouver les ARN des tables Lambda et DynamoDB.
2. Il appelle query_cloudwatch_metrics sur la table, examine la valeur ProvisionedThroughputExceededRequests et détecte une forte augmentation.
3. Afin de s’en assurer, il appelle query_cloudwatch_logs sur la fonction Lambda, analyse les journaux JSON et confirme l’existence d’une exception ProvisionedThroughputExceededException.
4. Il en conclut que la capacité est insuffisante et appelle remediate_dynamodb_capacity en demandant 50 RCU et 50 WCU.

Ici, le serveur MCP intercepte l’appel et demande confirmation à l’opérateur humain :

=======================================================
⚠️ URGENT: AGENT REQUESTING PERMISSION TO MODIFY INFRASTRUCTURE
=======================================================
Action: Scale DynamoDB Table 'sre-copilot-payments-dev'
New Capacity: Read=50, Write=50
Agent's Reason: The table is experiencing severe throttling (ProvisionedThroughputExceededException). Scaling up to mitigate the incident.
=======================================================
Approve this change? [y/N]: y

Celui-ci fonctionne également en tant qu’application de chat Streamlit, affichant la solution proposée ainsi que l’étape d’approbation. Une fois approuvée par un humain, la capacité est mise à jour et l’incident est résolu.

Avantages de cette architecture

En séparant le « cerveau » (Amazon Nova via Bedrock) des « mains » (APIs AWS) grâce à MCP, on obtient une flexibilité que les outils gérés par AWS ne peuvent pas égaler :

• Portabilité des LLM. Remplacer Nova par Claude ou GPT-4o ne nécessite qu’un changement de configuration.
• Sécurité. Les identifiants bruts n’atteignent jamais l’environnement d’exécution du LLM.
• Sécurité supplémentaire. Les actions modifiées passent par une étape d’approbation humaine personnalisable.
• Extensibilité. Ajouter un nouvel outil, qu’il s’agisse de PagerDuty, d’une requête API Datadog ou d’une vérification de ticket ServiceNow, se fait simplement avec une fonction @mcp.tool().

Autonomie. L’agent explore librement les données de télémétrie en lecture seule, ce qui lui permet de diagnostiquer des problèmes inhabituels que des outils de correspondance de motifs comme DevOps Guru manqueraient.

Les opérations cloud semblent sur le point de passer des services gérés monolithiques qui enferment les équipes à des agents composables, indépendants du modèle et auditable, que les équipes peuvent créer, gérer et améliorer continuellement. Il s’agit d’un modèle prêt à être mis en production, et non simplement d’une démonstration.

À titre de référence, la spécification MCP est disponible sur modelcontextprotocol.io, et AWS Labs propose des serveurs MCP open source de référence.