Ce que l’agent AWS couvre dans vos revues d’architecture

AWS automatise les revues d’architecture tandis que les entreprises conservent leur pouvoir de décision

Le Well-Architected Agent d’AWS automatise l’analyse initiale de l’architecture cloud tandis que les entreprises conservent les décisions d’approbation. AWS indique que ce service basé sur l’IA, désormais en préversion publique, examine les environnements AWS des clients, recommande des améliorations et fournit des conseils de mise en œuvre. Les entreprises peuvent fournir des objectifs métier pour aider à classer les constats, tandis que leurs dirigeants décident quels coûts, risques et arbitrages opérationnels accepter. AWS vend à la fois l’infrastructure examinée et les offres Support requises pour y accéder, et a donc un intérêt commercial à son adoption.

L’Agent s’appuie sur plus d’une décennie de produits de gestion de l’architecture : AWS a lancé le Well-Architected Framework en 2015 et le Well-Architected Tool en 2018. Le nom Well-Architected provient de cet historique de framework et de produit. Pour les architectes et les équipes plateforme, la question est de savoir dans quelle mesure l’analyse directe de l’environnement peut réduire le travail de revue, compte tenu du rythme d’actualisation du service, de sa couverture et de ses exigences d’accès.

L’analyse directe modifie le travail de revue

Pour comprendre ce changement, il faut partir du Well-Architected Tool existant. Les équipes décrivent leurs charges de travail en répondant à des questions structurées, les évaluent au regard des bonnes pratiques du Framework et reçoivent un plan d’amélioration. Leurs réponses constituent les éléments de preuve ; préparer cette description fait donc partie de la revue.

L’Agent prend en charge la collecte initiale des éléments de preuve en examinant directement l’environnement AWS, selon AWS. Les équipes peuvent ensuite ajouter le contexte applicatif et les objectifs métier, que l’Agent utilise pour hiérarchiser ses constats. Les évaluateurs commencent donc avec des constats tirés de l’environnement et y ajoutent les informations nécessaires pour les interpréter.

AWS indique que les constats couvrent les ressources individuelles, les applications et l’architecture globale. Un évaluateur peut donc apprécier une modification proposée sur une ressource dans le contexte de l’application qui l’utilise et de la conception plus large du système. Les recommandations décrivent également les actions correctives et leurs effets possibles sur les coûts, aidant les équipes à comprendre à la fois le travail d’ingénierie et ses conséquences financières.

Une fois qu’une équipe choisit une action, AWS indique que les conseils de mise en œuvre peuvent refléter l’environnement examiné. Ils peuvent fournir des étapes pour la console AWS, des commandes pour l’interface en ligne de commande AWS, ou AWS CLI, ainsi que des modifications proposées de l’infrastructure as code, les fichiers de configuration utilisés pour définir et gérer l’infrastructure. Les ingénieurs disposent ainsi d’un point de départ plus concret pour la mise en œuvre que ne le permet le plan d’amélioration du Tool existant.

Mais ces instructions doivent toujours passer par le processus d’approbation et de gestion du changement de l’entreprise. Qualifier le service d’agentique, c’est-à-dire capable d’exécuter des tâches à l’aide de l’IA, n’établit pas qu’il applique de manière autonome des changements correctifs. Les ingénieurs doivent décider si et comment utiliser les instructions pour la console, les commandes et les mises à jour de configuration dans le cadre de leurs procédures d’exploitation.

Siddharth Mehta, responsable de recherche au sein du cabinet de conseil et de services Avasant, voit dans cette approche un moyen d’accélérer l’optimisation pour les architectes cloud, les équipes DevOps qui combinent développement logiciel et opérations, ainsi que les ingénieurs plateforme. L’activité de conseil et de services d’Avasant lui donne un intérêt commercial dans la manière dont les entreprises adoptent et gèrent les technologies cloud. Mehta estime que l’analyse directe et des conseils détaillés peuvent aider les équipes à passer de revues ponctuelles et de corrections réactives à une optimisation plus continue, assistée par l’IA.

Le rythme d’actualisation limite la durée de validité des constats

Une optimisation plus fréquente soulève une question pratique : à quelle vitesse les recommandations reflètent-elles les changements de l’environnement ? Nhat Bui, directeur adjoint de l’ingénierie chez Scopic Software, soutient que les applications agentiques, dans lesquelles des agents IA exécutent des tâches, entraînent à la fois des changements plus rapides et un besoin accru de revue. Son point de vue vient d’une entreprise logicielle ayant un intérêt commercial dans la manière dont les entreprises conçoivent et maintiennent leurs applications.

« Premièrement, les applications d’IA évoluent plus vite et présentent des profils de coûts moins prévisibles que les charges de travail traditionnelles ; une revue réalisée le trimestre dernier devient donc rapidement obsolète. Deuxièmement, davantage d’infrastructure est désormais écrite par des outils de codage IA, et les évaluateurs humains ne peuvent pas suivre ce volume », a déclaré Bui. Il identifie deux pressions sur les équipes de revue : les évaluations perdent en pertinence à mesure que les systèmes évoluent, tandis que les outils de codage IA augmentent la quantité d’infrastructure que les personnes doivent examiner.

Le calendrier d’actualisation de l’Agent détermine sa réponse à ces pressions. « L’Agent actualise chaque semaine les recommandations au niveau des ressources et des applications, tandis que les recommandations au niveau de l’architecture sont générées via des revues à la demande », a déclaré Bui. Les équipes reçoivent donc des mises à jour planifiées aux niveaux ressource et application et doivent demander des revues pour les constats au niveau de l’architecture.

Entre deux mises à jour, l’infrastructure et la consommation peuvent évoluer, en particulier dans les applications agentiques, a ajouté Bui. Avant d’agir, les évaluateurs doivent prendre en compte ce qui a changé depuis la génération d’une recommandation. L’attente de Mehta d’une optimisation plus continue décrit une évolution des pratiques de travail, mais l’explication de Bui sur le calendrier d’actualisation fixe une limite temporelle aux informations qui soutiennent ce travail.

Les objectifs métier guident le classement tandis que le contexte de l’entreprise guide l’approbation

Même une recommandation à jour a besoin d’un contexte métier avant qu’une équipe puisse décider d’agir. Pareekh Jain, analyste principal chez Pareekh Consulting, voit dans le classement par rapport aux objectifs métier un moyen d’accélérer les décisions cloud. Son activité de conseil a un intérêt commercial dans les décisions technologiques des entreprises, et son analyse vise à aider les DSI à allouer les investissements et les efforts d’ingénierie.

« Au lieu de donner aux DSI des centaines de recommandations techniques, l’agent peut aider à identifier quelles améliorations comptent le plus pour l’entreprise. Cela signifie que les DSI peuvent décider où prioriser les investissements cloud et les ressources d’ingénierie, et où accepter des arbitrages », a déclaré Jain. Selon lui, le classement facilite le tri des recommandations tout en laissant au DSI les priorités d’investissement et les compromis acceptables.

Pour que ce classement soit utile, l’entreprise doit fournir des objectifs qui reflètent ses besoins. Mehta avertit que des informations pertinentes peuvent aussi se trouver hors de l’environnement AWS, notamment les accords contractuels de niveau de service, ou SLA, qui définissent les engagements de fourniture de service, ainsi que l’appétence au risque, c’est-à-dire le niveau de risque qu’une organisation est prête à accepter. Ces considérations peuvent modifier la pertinence d’une recommandation techniquement utile pour une charge de travail.

« L’Agent ne comprend que le contexte auquel il a accès. Il peut ne pas connaître les obligations réglementaires, les dépendances à des tiers, les dépendances aux processus métier, les SLA contractuels, l’appétence interne au risque, les dépendances multi-cloud et les politiques organisationnelles non représentées dans AWS », a déclaré Mehta. Les évaluateurs doivent intégrer ces obligations et ces relations dans la décision lorsque l’Agent ne peut pas les voir.

Ces relations peuvent déterminer ce qui se passe lorsqu’un changement proposé est mis en œuvre. Un prestataire externe ou un processus métier peut dépendre de la ressource en cours de modification, tandis qu’une application s’étendant sur plusieurs fournisseurs cloud peut nécessiter une évaluation plus large. Les obligations réglementaires et les politiques internes peuvent également limiter les choix ; les entreprises ayant des exigences importantes dans ces domaines doivent donc compléter le contexte détenu dans AWS.

Mehta formule directement cette limite : « Par conséquent, l’alignement sur les objectifs métier améliore la priorisation mais ne remplace pas l’architecture d’entreprise ni la gouvernance des risques. » Pour les responsables de l’architecture et des plateformes, la préparation du contexte fait donc partie de la revue. Les équipes ont besoin d’un moyen d’intégrer les politiques, les engagements et les dépendances externes dans les décisions d’approbation, même lorsque l’Agent a déjà classé une recommandation très haut.

L’accès, la couverture et la consommation façonnent l’évaluation

Au-delà de la préparation de ce contexte, une entreprise doit déterminer si elle peut accéder à la préversion. AWS met l’Agent à disposition des clients disposant des offres AWS Business+, Enterprise On-Ramp, Enterprise Support ou Unified Operations. Le Well-Architected Tool ne nécessite aucune offre AWS Support payante ; les produits ont donc des conditions d’accès différentes.

Jain considère l’exigence d’une offre Support de niveau supérieur comme une contrainte potentiellement importante pour l’adoption par les entreprises. Une organisation disposant déjà d’une offre éligible remplit la condition, tandis qu’une organisation sans offre doit prendre une décision d’achat distincte pour Support. L’éligibilité détermine donc quelles organisations peuvent tester si l’analyse directe réduit leur charge de travail de revue.

Pour les organisations éligibles, la question suivante est de savoir si l’Agent couvre l’évaluation envisagée. Mehta indique qu’il traite actuellement le coût, la sécurité, la performance et la résilience, tandis que le Tool couvre les six domaines, ou piliers, du Well-Architected Framework. L’excellence opérationnelle et la durabilité complètent ces six piliers ; une revue complète du Framework exige donc une couverture plus large que celle fournie actuellement par l’Agent.

La couverture est distincte des frais. AWS indique que ni l’Agent ni le Tool n’ont de frais additionnels spécifiques, mais les entreprises peuvent encourir des frais liés aux ressources, services et données AWS sous-jacents qu’elles consomment. Cette consommation peut impliquer Trusted Advisor, Compute Optimizer, Security Hub CSPM (cloud security posture management), Resilience Hub, Cost Optimization Hub et Cost Explorer.

Une évaluation doit donc prendre en compte les services et les données utilisés pendant la revue. Une offre Support éligible établit l’accès, mais la consommation associée peut toujours entraîner des frais. Les équipes doivent évaluer les coûts au regard des ressources et services réellement utilisés par leur évaluation, puisque les frais potentiels mentionnés ne s’appliquent pas nécessairement à chaque évaluation.

Points clés

• Automatiser le point de départ de la revue : le Well-Architected Agent d’AWS examine directement les environnements cloud et fournit des constats ainsi que des conseils de mise en œuvre. Les équipes d’architecture et de plateforme conservent la responsabilité de valider les recommandations et de faire passer les changements par les processus d’approbation de l’entreprise.
• Vérifier l’actualité des recommandations : les recommandations au niveau des ressources et des applications sont actualisées chaque semaine, tandis que les constats au niveau de l’architecture nécessitent des revues à la demande. Les responsables de plateforme doivent vérifier les changements intervenus dans l’infrastructure et la consommation avant d’agir.
• Intégrer les obligations métier dans l’approbation : les objectifs métier aident l’Agent à classer les constats, tandis que les obligations réglementaires, les engagements contractuels et les dépendances externes peuvent se situer hors du contexte auquel il a accès. Les responsables de l’architecture et des risques doivent évaluer les recommandations hautement prioritaires au regard de ces obligations.
• Définir le périmètre et le coût de l’évaluation : l’accès nécessite une offre AWS Support éligible, et la couverture actuelle porte sur le coût, la sécurité, la performance et la résilience. Les responsables des plateformes cloud et de la finance doivent traiter séparément l’excellence opérationnelle et la durabilité, et évaluer les frais des services sous-jacents, même si l’Agent n’entraîne pas de frais supplémentaires.