L’AWS DevOps Agent en pratique : espaces d’agent, enquêtes, vérifications de versions et compétences.

Les équipes opérationnelles passent de nombreuses heures à effectuer des tâches répétitives : déterminer pourquoi un pipeline a échoué, vérifier l’état de l’infrastructure, comparer les journaux avec les métriques, et répondre quotidiennement à la question « Qu’est-ce qui ne fonctionne pas en ce moment ? ». AWS propose de bons éléments pour cela, tels que CloudWatch, IAM, CodePipeline et Lambda, mais il subsiste un écart entre les signaux bruts et des conclusions sur lesquelles on peut agir.

Ce qui suit est une présentation pratique de l’AWS DevOps Agent : comment configurer un Agent Space, à quoi ressemble une enquête de bout en bout, quels sont les nouveaux fonctionnalités de gestion des versions ajoutées, et comment les Agent Skills permettent à l’agent d’absorber les procédures propres à une équipe. Le public cible est composé de professionnels DevOps, SRE, d’ingénieurs en plateformes et en IA qui exécutent déjà des charges de travail sur AWS et souhaitent une automatisation allant au-delà de simples scripts.

Qu’est-ce qu’un agent DevOps, et ce qu’il n’est pas

Ici, ce terme désigne un assistant opérationnel qui ne remplace pas les ingénieurs. Il s’agit d’un système qui :

• a un accès en lecture aux ressources AWS, et parfois un accès d’écriture limité
• comprend le contexte opérationnel de l’environnement
• peut répondre à des questions telles que la raison d’un échec de déploiement, ce qui a changé au cours de la dernière heure, ou quel service est à l’origine d’une augmentation des erreurs
• fonctionne comme une couche de liaison entre les API AWS, les journaux, les métriques et les personnes de garde

Il ne remplace pas les ingénieurs. Son rôle est de réduire la charge mentale liée aux investigations routinières et d’accélérer ces dernières.

Création d’un espace Agent

Recherche du service

Ouvrez la console de gestion AWS et recherchez AWS DevOps Agent. Les fonctionnalités principales relatives aux opérations en production sont généralement disponibles. Les capacités plus récentes de gestion des versions, décrites ci-dessous, sont encore en version bêta.

Créer l’espace

Sélectionnez « Créer un espace d’agent » et saisissez deux éléments : un nom, par exemple Demo-DevOps-Agent, ainsi qu’une brève description de l’environnement ou de son objectif. Cet espace d’agent constitue la limite logique entourant les investigations, la topologie et les recommandations.

Accorder l’accès aux ressources

Dans la section permettant d’accorder à l’espace accès aux ressources AWS, sélectionnez l’option qui crée automatiquement un nouveau rôle DevOps Agent. AWS génère et associe alors un rôle IAM doté de permissions ciblées lui permettant de lire les métriques et les journaux CloudWatch, d’inspecter les ressources EC2 et apparentées, ainsi que de créer des graphiques de topologie. La plupart des difficultés liées à IAM qui entravent habituellement l’adoption disparaissent à ce stade.

Activer l’application web

Dans la section Activer l’application web, conservez la sélection de l’option de création automatique du rôle. Cela active l’interface interactive utilisée pour les investigations, la messagerie et les tableaux de bord. Ensuite, créez l’Agent Space.

Ouvrir la vue de l’opérateur

Allez dans le nouvel Agent Space et ouvrez Accès à l’opérateur. Trois zones s’y trouvent : le DevOps Center, la Réponse aux incidents et la Prévention.

DevOps Center et visibilité basée sur la topologie

Dans cet espace, le DevOps Center affiche un graphique de topologie en temps réel de l’environnement AWS. Plusieurs éléments se distinguent immédiatement : les ressources semblent connectées et non isolées, les dépendances entre services sont visibles, et l’agent s’appuie sur ces relations plutôt que uniquement sur des métriques. Cette topologie est extrêmement importante pour l’analyse des causes racines ultérieure.

Mener une enquête

C’est dans la fonction de réponse aux incidents que l’agent commence à se montrer utile. Depuis le tableau de bord, sélectionnez « Démarrer une enquête ». Le problème peut être décrit en langage simple, ou un déclencheur courant peut être choisi, comme une utilisation élevée de la CPU, une augmentation soudaine des taux d’erreur, ou l’absence de métriques et de journaux.

L’exemple présenté ici concernait un incident de données manquantes. La demande était la suivante : pouvez-vous vérifier pourquoi les données CPU de CloudWatch ne sont pas visibles pour mes instances EC2 ? L’agent a immédiatement identifié les instances affectées, les a affichées dans la vue de topologie et a consulté les métriques CloudWatch dans la région concernée.

Chronologie et constats

La chronologie de l’enquête montre comment les travaux se sont déroulés : collecte des informations contextuelles, identification des ressources, évaluation des métriques et formulation des constats. Un choix de conception mérite d’être souligné : lorsque des métriques sont absentes, l’agent le signale clairement sans fonctionner en silence. Il s’agit d’une petite décision ayant un impact important sur la confiance.

Analyse de la cause racine

Dans l’onglet « Cause racine », l’agent a indiqué plusieurs causes contributives, et non une seule :

• Le suivi détaillé est désactivé sur les instances EC2. Ces instances affichaient Monitoring: disabled, et sans suivi détaillé, ces métriques de CPU ne sont jamais publiées dans CloudWatch.
• Aucun agent CloudWatch n’est installé. Rien n’a été configuré sur les instances, ce qui rend les données de CPU plus fines indisponibles.
• Les instances sont arrêtées. Elles ont été arrêtées pendant une longue période, et les instances arrêtées ne génèrent aucune métrique.

Ce qui compte, c’est la manière dont l’agent a fonctionné. Il n’a retenu aucune explication unique, il a classé les causes de manière logique et les a toutes étayées par des preuves extraites des API d’AWS.

Lorsque ne pas agir est la bonne réponse

L’onglet « Plan d’atténuation » indiquait qu’aucune mesure d’atténuation immédiate ne pouvait être identifiée. C’est un bon résultat, et non un mauvais. Le système se comportait exactement comme configuré. Aucune régression ni modification récente n’avait causé ce symptôme. Toute correction reviendrait à une modification de configuration planifiée et non à une atténuation d’incident. Tracer cette frontière est important en environnement de production, car cela évite des retraits inutiles.

Prévention

L’onglet « Prévention » examine les investigations antérieures afin de déterminer s’il est justifié de donner des recommandations proactives. Rien de nouveau n’a été généré ici, et l’agent a correctement constaté l’absence de risque opérationnel récurrent. Les catégories qu’il évalue sont l’infrastructure, l’observabilité, la gouvernance et l’optimisation du code.

Pourquoi les équipes s’y intéressent

Ce n’est pas simplement un autre produit de surveillance. Sa valeur réside en quatre aspects : des délais d’enquête plus courts, une analyse structurée des causes racines, moins de fatigue due aux alertes, et un moyen pour les équipes de comprendre pourquoi leurs systèmes se comportent de la sorte. Sans cela, les ingénieurs devraient rassembler manuellement les informations provenant de CloudWatch, des paramètres EC2, de l’état IAM et de l’historique des déploiements. L’agent effectue cette corrélation à leur place.

Fonctionnalités de gestion des versions (bêta)

Une nouvelle fonctionnalité permet d’activer l’agent plus tôt, avant même que le code n’atteigne l’environnement de production.

Évaluation de la prêté à la mise en production. Chaque modification de code est évaluée selon des critères de prêté à la production, les risques liés aux dépendances entre répertoires ainsi que toute norme définie par l’organisation ; en l’absence de telles règles, on se réfère aux meilleures pratiques générales. Les vérifications spécifiques comprennent l’impact d’une modification sur les services dépendants dans d’autres répertoires, ainsi que les modifications relatives aux IAM ou au contrôle d’accès, évaluées à l’aide du cadre AWS Well-Architected. L’agent lance en outre la compilation dans un environnement isolé géré par AWS et l’ teste à l’aide de quelques tests simples liés aux parcours utilisateurs. Cela permet de s’assurer que la compilation réussit, que l’application fonctionne et que les vérifications fonctionnelles de base sont satisfaites, tout cela avant que la modification ne soit intégrée au pipeline.

Les résultats apparaissent dans la console de l’agent DevOps ainsi que dans les commentaires des demandes de pull sur GitHub ou GitLab. Ils peuvent également être générés sur demande depuis un IDE grâce à l’outil Kiro power ou au plugin Claude Code, permettant aux développeurs de détecter les risques liés aux dépendances, les violations des normes et les problèmes de contrôle d’accès avant d’effectuer un commit.

Tests de déploiement autonomes. Cette fonctionnalité fait progresser l’idée vers l’étape pré-intégration. Au lieu d’exécuter un ensemble de tests fixe, elle génère des plans de test spécifiques à la modification, à exécuter dans des environnements similaires à la production fournis par le client, pour les applications web et API. Comme elle analyse le sens des différences, elle peut créer des tests de correction fonctionnelle, de régression et d’intégration entre services que des ensembles de tests gérés manuellement ne pourraient jamais prévoir. Chaque exécution produit des artefacts structurés, à savoir des métriques, des journaux, des traces et un résumé de l’exécution, qui offrent aux évaluateurs un historique cohérent et auditable de la couverture des tests et des résultats pour chaque modification.

Ces deux fonctionnalités sont en version bêta et ne coûtent rien de supplémentaire pendant cette période. Elles sont disponibles dans la région Est des États-Unis (Virginie du Nord).

Qu’est-ce que les compétences d’agent ?

Les compétences sont des ensembles d’instructions modulaires qui élargissent les capacités de l’agent en lui fournissant des connaissances spécialisées dans un domaine donné ainsi que des méthodes d’enquête adaptées à l’infrastructure et aux pratiques d’une équipe. Une compétence correspond à un répertoire autonome d’instructions Markdown qui confère à l’agent une nouvelle capacité. Le service prend en charge un sous-ensemble de la spécification ouverte Agent Skills, n’acceptant que des éléments non exécutables : instructions Markdown, PDF, images et fichiers de données.

Chaque compétence nécessite un fichier SKILL.md contenant les instructions. En outre, une compétence peut inclure :

• Flux de travail d’enquête pour des scénarios ou des types d’infrastructure spécifiques
• Matériel de référence, tel que des modèles architecturaux et des procédures opérationnelles

Ciblage par type d’agent, qui vise une compétence vers des types d’agents spécifiques (Générique, Sur demande, Tri des incidents, Analyse des causes racines des incidents, Atténuation des incidents ou Évaluation) afin d’économiser du contexte et de cibler plus précisément.

Pourquoi se donner cette peine ?

Les compétences transforment un assistant polyvalent en un spécialiste pour un environnement donné. Une instruction saisie une seule fois dans la messagerie disparaît ensuite, tandis qu’une compétence est réutilisable et s’active automatiquement lorsque une tâche l’exige. Voici quatre avantages :

• Specialisation. L’agent maîtrise les procédures d’enquête, les bonnes pratiques et les connaissances organisationnelles propres à l’infrastructure.
• Moins de répétitions. Un flux de travail écrit une seule fois est utilisé automatiquement pour chaque enquête pertinente, ce qui évite de devoir réexpliquer les mêmes indications.
• Composition. Plusieurs compétences s’assemblent pour former un flux de travail complet. L’agent peut en utiliser plusieurs lors d’une exécution, par exemple une qui récupère des déploiements depuis un pipeline CI/CD personnalisé et une autre qui recherche dans des dépôts de code.
• Mieux utiliser les outils personnalisés. Une compétence peut indiquer à l’agent quand appeler un outil serveur MCP donné, quels paramètres conviennent à différents scénarios, et comment interpréter les résultats.

Comment elles sont utilisées

Lorsque l’agent rencontre une tâche pertinente, il charge les compétences correspondantes et les suit. Une compétence nommée « Investigation de la performance de la base de données », par exemple, peut contenir des procédures étape par étape pour gérer le ralentissement de RDS, guidant l’agent de manière systématique à travers l’état des alertes, les métriques de connexion et les requêtes lentes.

Structure des compétences

Une compétence est un répertoire :

my-skill/
├── SKILL.md              # Main skill instructions
├── references/           # Optional: additional reference documentation
└── assets/               # Optional: images, diagrams, data files

Le fichier SKILL.md est l’élément obligatoire. Il doit décrire quand et comment la compétence s’applique, fournir des procédures d’enquête étape par étape, inclure des arbres de décision pour différents scénarios, ainsi que préciser les résultats attendus et les critères de succès.

Exemples de compétences et téléchargement d’une

AWS publie une collection d’exemples de compétences conçues pour ce runtime dans l’organisation GitHub aws-samples. Il ne s’agit pas de compétences Agent génériques ; elles sont adaptées au runtime DevOps Agent, à ses types d’agents et aux workflows qu’il exécute à l’intérieur d’un Agent Space.

Pour en utiliser une, téléchargez le zip souhaité depuis le répertoire, ou créez un paquet avec cette structure :

<skill-name>.zip
├── SKILL.md              # Required: main instructions + YAML frontmatter
├── references/           # Optional: reference documentation
│   ├── architecture.md
│   └── troubleshooting.md
└── assets/               # Optional: images, diagrams, data files

Placez SKILL.md à la racine du fichier zip, avec un frontmatter valide contenant name et description. Un exemple de frontmatter pourrait comporter un nom tel que eks-resilience-checker-skill-devops ainsi qu’une description indiquant des procédures d’enquête pour l’évaluation de la résilience d’Amazon EKS, couvrant la santé du plan de contrôle, l’échelle du plan de données, les lacunes en matière de réseau et d’observabilité, à utiliser lors de l’évaluation ou de la correction de la résilience du cluster.

Ensuite, suivez les étapes de téléversement :

1. Vérifiez que le fichier zip ne contient pas de dossier scripts/ et qu’il fait 6 MB au maximum.
2. Ouvrez l’application web Operator et allez à la page des compétences.
3. Sélectionnez « Ajouter une compétence », puis « Téléverser une compétence ».
4. Faites glisser le fichier .zip dans la fenêtre de téléversement, ou cherchez-le manuellement. Seuls les fichiers zip de 6 MB au maximum sont acceptés.

Sélectionnez les types d’agents qui doivent utiliser cette compétence. Generic est précoché et s’applique à tous les types. Désélectionnez-le pour cibler On-demand, Incident Triage, Incident RCA, Incident Mitigation ou Evaluation.

Lisez les résultats de validation affichés par le formulaire, puis choisissez « Upload » pour ajouter la compétence dans l’Espace de l’agent.

Gestion des compétences ultérieurement

• Liste et affichage : toute compétence présente sur la page des Compétences peut être ouverte afin de parcourir ses fichiers (SKILL.md, references/, assets/) ; l’accès est en lecture seule.
• Activation ou désactivation : activez ou désactivez l’option Active ou Inactive dans la vue détaillée. Les compétences désactivées restent stockées mais ne sont pas chargées pour de nouvelles investigations.

Ciblage ultérieur : le choix des types d’agents peut être modifié à tout moment si nécessaire.

Remplacement : une compétence provenant d’un fichier zip est mise à jour en téléchargeant une version plus récente.

Création d’une compétence dans l’interface utilisateur

Un seul fichier SKILL.md ne contenant ni références ni ressources peut éviter complètement l’utilisation d’un zip :

1. Sur la page des compétences, choisissez « Ajouter une compétence », puis « Créer une compétence ».
2. Saisissez un nom en lettres minuscules, chiffres et tirets, d’une longueur maximale de 64 caractères, qui ne commence ni ne se termine par un tiret.
3. Saisissez une description, de préférence d’au moins 100 caractères et de pas plus de 1024.
4. Choisissez un statut (Actif ou Inactif) ainsi qu’un ou plusieurs types d’agents.
5. Collerez le Markdown dans le champ des instructions.
6. Choisissez « Créer ». Le système génère automatiquement le fichier SKILL.md avec les métadonnées appropriées.

Où il s’intègre

Pour toute personne qui gère AWS à grande échelle, ce service vaut la peine d’être essayé, en particulier pour le tri des incidents et l’analyse post-incident. En termes simples, il fonctionne comme un collègue de garde autonome qui travaille 24 heures sur 24. Il commence à enquêter dès que l’alerte est déclenchée, réduit le temps de résolution en corrélant les données telemétriques, le code et l’historique des déploiements, et aide à prévenir d’éventuels pannes dans les environnements AWS, hybrides et multi-cloud.