Aujourd'hui, les équipes DevOps font face à une réalité paradoxale : plus les infrastructures cloud gagnent en maturité, plus la complexité opérationnelle s'intensifie. Logs épars, clusters Kubernetes à surveiller, incidents nocturnes à déchiffrer… L'observabilité et la résolution d'incidents restent des activités chronophages, souvent artisanales. Le MTTR (Mean Time To Resolution) pénalise la velocité opérationnelle.
Lors de l'AWS Summit Paris 2026, Amazon Web Services a présenté une série d'annonces visant à changer radicalement cette équation, en plaçant l'intelligence artificielle au cœur du quotidien des ingénieurs.
CloudWatch : deux nouveautés discrètes mais bienvenues
- Le Prompt Generator : le langage naturel pour requêter ses logs
CloudWatch Logs Insights dispose désormais d'un Prompt Generator. Le principe est simple : vous décrivez en langage naturel ce que vous cherchez dans vos logs, et l'outil traduit automatiquement votre intention en une requête SQL directement exécutable. Fini le blocage sur la syntaxe à 3h du matin, vous posez votre question comme vous la formuleriez à un collègue, et vous obtenez la requête correspondante, prête à être lancée ou affinée.
- Le MCP CloudWatch : l'observabilité au cœur des agents IA
Dans la continuité de cette ouverture, AWS propose également un serveur MCP CloudWatch. Le protocole MCP (Model Context Protocol) est un standard ouvert qui permet à un agent IA de se connecter à des outils et sources de données externes de façon standardisée. Concrètement, votre agent IA favori, Kiro, Amazon Q, ou tout autre outil compatible, peut désormais interroger vos logs CloudWatch directement dans son contexte, sans friction. L'observabilité devient un citoyen de première classe dans les workflows agentiques.
AWS DevOps Agent : automatisation de la réponse aux incidents
C'est l'annonce phare du Summit côté ops. L'AWS DevOps Agent est un agent IA conçu spécifiquement pour la résolution et la prévention d'incidents. Son rôle : analyser une erreur remontée par CloudWatch, en comprendre l'origine, et produire un plan d'action détaillé et contextualisé.
Un point essentiel à préciser d'emblée : à ce stade, l'agent n'exécute rien. Il observe, raisonne, et recommande. AWS a mentionné lors du Summit que la capacité à agir directement, et non plus seulement recommander, pourrait constituer une prochaine étape pour l'outil. Aucune date ni engagement ferme n'a été communiqué à ce stade.
Les capacités clés du DevOps Agent:
- L'analyse CloudWatch constitue son point d'entrée naturel. Mais là où l'agent se distingue vraiment, c'est dans sa capacité à croiser plusieurs sources pour reconstruire l'histoire complète d'un incident.
- L'investigation de l'infrastructure. L'agent ne se limite pas à CloudWatch : il peut explorer l'ensemble de votre infrastructure AWS pour reconstituer le contexte d'un incident. Côté Kubernetes par exemple, il se connecte à vos clusters EKS, publics ou privés, pour décrire les objets du cluster, consulter les logs des pods et les événements, et cartographier automatiquement comment vos services s'interconnectent. Quand un pod est en CrashLoopBackOff, il ne se contente pas de lire le message d'erreur : il remonte la chaîne de dépendances, vérifie les connexions aux bases de données, inspecte les NetworkPolicies, et identifie si le problème vient du code, de la configuration réseau, ou d'une ressource AWS en amont.
- La remontée jusqu'au code source via GitLab. Grâce à l'intégration MCP GitLab, l'agent peut consulter le code de vos applications pour contextualiser une erreur. Mieux encore : il peut corréler l'incident avec l'historique des commits et identifier quel push a introduit la régression. Ce n'est plus simplement « une erreur est apparue », c'est « cette erreur est apparue suite au déploiement de 17h42, voici le diff concerné ».
- L'apprentissage progressif de votre infrastructure. Chaque investigation enrichit la connaissance de l'agent. Plus il est sollicité, plus il comprend les patterns de votre infrastructure, les dépendances entre services, les erreurs récurrentes. Cette mémoire lui permet de basculer en mode proactif : si une même classe d'erreur revient régulièrement, l'agent peut anticiper et proposer des améliorations structurelles avant que l'incident suivant ne se produise.
- La connaissance de vos process internes. Vous pouvez lui enseigner les procédures propres à votre organisation. Si le renouvellement de certificats SSL dans votre contexte suit un processus spécifique, un outil interne, un ticket ServiceNow, une validation d'équipe, l'agent intégrera ces étapes dans son plan d'action. Il ne produit pas des recommandations génériques, mais des recommandations adaptées à votre façon de travailler.
L'astreinte réinventée : on-call automation et incident response
Il est 3h du matin. Une alerte CloudWatch se déclenche. Dans le schéma classique, vous ouvrez votre ordinateur et commencez à explorer les logs, souvent une heure de travail, parfois plus, avant même de savoir par où commencer.
Avec le DevOps Agent, vous vous réveillez sur un rapport déjà rédigé. L'agent a analysé les logs, inspecté le cluster, remonté jusqu'au commit responsable, et produit un plan d'action étape par étape, adapté à votre infrastructure et à vos processus. Vous lisez, vous validez, et vous agissez, ou vous confiez le rapport à votre agent de code pour que la correction soit démarrée avant même que vous n'ayez bu votre café.
Vision future
AWS a insisté sur sa volonté de conserver un Human-in-the-Loop, l'humain restant le décisionnaire final avant toute action sur l'infrastructure. La suite logique serait néanmoins que l'agent puisse, à terme, appliquer lui-même les corrections via de l'auto-remediation
En attendant, l'agent dans son état actuel représente déjà un gain de temps concret : son rapport peut être transmis directement à un agent de code pour accélérer la correction, sans passer par la longue phase d'exploration manuelle des logs.
