AWS a décidé de donner un coup d’accélérateur à l’ère des agents intelligents basés sur l’IA. Lors de re:Invent 2025, l’entreprise a dévoilé ses “frontier agents”, une nouvelle catégorie d’agents d’intelligence artificielle conçus pour agir en tant qu’extensions directes des équipes de développement, de sécurité et d’exploitation.

Les trois premiers à voir le jour sont :

• Kiro autonomous agent : un « développeur virtuel » capable de maintenir un contexte et d’exécuter des tâches de développement de bout en bout.
• AWS Security Agent : un « ingénieur sécurité » agissant comme un conseiller permanent et un pentester à la demande.
• AWS DevOps Agent : un « opérateur virtuel » chargé de gérer les incidents et de proposer des améliorations en termes de fiabilité et de performance.

La promesse d’AWS est claire : passer d’assistants apportant une aide ponctuelle à des agents capables de mener à bien des projets complexes, presque comme des membres à part entière de l’équipe.

Comment AWS définit-il les « frontier agents » ?

Dans son annonce, AWS caractérise cette nouvelle catégorie d’agents par trois traits distinctifs :

1. Autonomes
   Ils ne sont pas conçus pour suivre chaque instruction de l’utilisateur, mais pour recevoir un objectif précis (« améliorer la couverture des tests de ce service », « réaliser un pentest sur cette API », « diagnostiquer cet incident critique ») et élaborer le plan d’action, puis l’exécuter.
2. Scalables
   Ils peuvent traiter plusieurs tâches en parallèle, coordonner des sous-tâches et collaborer avec d’autres agents. L’idée est que le goulot d’étranglement ne soit plus « combien de choses une personne peut superviser simultanément ».
3. Persistants
   Conçus pour fonctionner pendant des heures ou des jours sans intervention constante, ils conservent le contexte entre les sessions et apprennent des décisions et ajustements humains.

Ces agents s’appuient sur les leçons internes d’Amazon : plus ils peuvent déléguer de travail « en arrière-plan » à ces agents, plus leurs équipes disposent de temps pour concevoir, architecturer et prendre des décisions réellement stratégiques.

Kiro autonomous agent : le « développeur virtuel » vivant dans votre dépôt

Le premier frontier agent est orienté développement pur et dur. Kiro autonomous agent se présente comme un développeur virtuel partagé par toute l’équipe, capable de comprendre le code, le backlog et les normes internes.

Parmi ses capacités remarquables :

• Maintenir un contexte persistant sur les dépôts, branches, tickets, pull requests et échanges antérieurs.
• Prendre en charge des tâches telles que :
  • Tri des bugs.
  • Refactorisation de services.
  • Amélioration de la couverture des tests.
  • Application de modifications coordonnées sur plusieurs dépôts.
• S’intégrer avec des outils comme GitHub, Jira, Slack ou pipelines CI/CD.
• Proposer des changements sous forme d’éditions et de pull requests, laissant ainsi aux développeurs la dernière décision.

Simultanément, Kiro existe aussi comme agent IDE et CLI axé sur l’engagement : une expérience de développement centrée sur des spécifications et un contexte structuré, au-delà du simple « copier-coller » de prompts. Sa philosophie, le spec-driven development, consiste à :

1. Convertir le langage naturel du développeur en exigences claires et critères d’acceptation.
2. Concevoir l’architecture et le plan de mise en œuvre.
3. Découper le travail en tâches concrètes avec tests et documentation.
4. Exécuter ces tâches à l’aide des agents, en montrant les différences et en permettant à l’humain d’accepter ou modifier.

Le but est d’éloigner le plus possible le « coding chaotique » pour privilégier un flux où l’IA structure d’abord, code ensuite, avec une traçabilité complète des décisions.

AWS Security Agent : un pentester infatigable intégré au cycle de développement

Le second frontier agent s’attaque à l’un des nœuds gordiens : la sécurité. AWS Security Agent souhaite jouer le rôle d’un ingénieur sécurité virtuel qui accompagne les applications dès leur conception jusqu’en production.

Ses fonctionnalités se déploient en trois dimensions :

1. Premiers pas sûrs dès la conception
   • Revoir documents d’architecture et propositions techniques.
   • Comparer ces choix aux politiques de sécurité internes de l’organisation.
   • Identifier les risques liés au design (exposition des données, absence de segmentation, mauvaises pratiques d’authentification, etc.).
2. Sécurité continue durant le développement
   • Analyser les pull requests à la recherche de vulnérabilités, mauvaises pratiques ou non-conformités aux normes internes.
   • Appliquer des exigences d’entreprise et des bases de connaissances sur des vulnérabilités classiques (OWASP, erreurs de configuration, etc.).
3. Tests de pénétration à la demande et à grande échelle
   • Faire passer les tests d’intrusion d’un processus coûteux et ponctuel à une capacité récurrente.
   • Lancer des campagnes d’évaluation automatiques sur plusieurs applications.
   • Fournir des constats validés avec des propositions de remédiation, voire des extraits de code pour corriger la faille.

Un exemple cité est celui de SmugMug, qui a intégré AWS Security Agent dans sa stratégie de tests. Selon la société, l’agent a été capable de repérer une faille logique métier qui avait échappé à d’autres outils automatisés et qui, a priori, n’aurait été détectée que par un pentester humain.

La conclusion pour l’écosystème IA est claire : des agents ayant un accès approfondi au contexte métier, au code et aux APIs peuvent dépasser les scanners de sécurité traditionnels, en réfléchissant sur les flux et conséquences, et pas seulement sur des motifs connus.

AWS DevOps Agent : passer de la gestion des incidents à l’amélioration basée sur les données

Le troisième agent opère dans le domaine des opérations et de l’observabilité. AWS DevOps Agent se comporte comme un ingénieur DevOps expérimenté toujours en alerte.

Sa proposition couvre deux scénarios :

1. Incidents en temps réel
   • Réagit immédiatement face aux alertes.
   • Relie des signaux issus de :
     • Outils d’observabilité (CloudWatch, Datadog, New Relic, Dynatrace, Splunk, etc.).
     • Runbooks et documentation interne.
     • Dépôts de code.
     • Pipeline de déploiement.
   • Construit une carte des dépendances et des corrélations pour identifier la cause racine.
   • Au sein d’Amazon, l’agent a géré des milliers d’escalades avec un taux estimé de réussite dans la détection de cause racine supérieur à 86 %, selon l’entreprise.
2. Amélioration continue de la plateforme
   • Analyse l’historique des incidents pour repérer des modèles récurrents.
   • Propose des améliorations dans quatre domaines :
     • Observabilité.
     • Optimisation de l’infrastructure.
     • Qualité des pipelines de déploiement.
     • Résilience des applications.

Lors de tests avec la Commonwealth Bank of Australia, AWS souligne que l’agent a pu localiser la cause d’un problème réseau complexe et d’identité en moins de 15 minutes, ce qui aurait habituellement nécessité plusieurs heures d’un ingénieur senior.

Une étape supplémentaire dans la course vers l’IA agentifiée

Pour l’écosystème de l’IA, ces frontier agents s’inscrivent dans une tendance plus large : le passage des copilotes centrés sur l’interface (chat, IDE, console) vers des agents autonomes intégrés aux systèmes.

Les axes principaux de cette évolution :

• Persistance du contexte : les agents ne « perdent » plus la mémoire entre les sessions ; ils accumulent des connaissances sur le code, les normes internes et les failles potentielles.
• Orchestration des tâches : un agent ne se limite pas à répondre à une question, il planifie, exécute, retente, coordonne les sous-tâches et renvoie des résultats prêts à l’évaluation.
• Intégration poussée avec l’ensemble de l’écosystème : dépôts, CI/CD, observabilité, gestionnaires d’incidents et outils de sécurité… tout devient partie intégrante du « monde » accessible à l’IA.

Simultanément, des outils comme Kiro mettent l’accent sur l’expérience développeur, proposant un environnement orienté agents, spécifications et hooks déclenchés par des événements (enregistrer un fichier, ouvrir une PR, etc.).

Enjeux : confiance, gouvernance et dépendance à la plateforme

Le déploiement d’agents aussi puissants soulève plusieurs questions, notamment dans un contexte d’IA d’entreprise :

• Confiance et supervision
  Dans quelle mesure peut-on laisser un agent exécuter des changements de façon autonome ? La démarche d’AWS privilégie un modèle où l’agent propose et l’humain approuve, mais la volonté d’automatiser davantage demeure forte.
• Sécurité et accès aux données sensibles
  Ces agents requièrent des permissions étendues sur les dépôts, pipelines, métriques et parfois même en environnement de production. La frontière entre outil utile et risque potentiel est très fine.
• Dépendance à l’écosystème AWS
  Bien qu’AWS affirme que Security Agent et DevOps Agent fonctionnent aussi en multicloud ou hybride, cette tendance tend à renforcer la centralisation des capacités critiques (développement, sécurité, opérations) chez le fournisseur cloud.
• Impact sur les rôles et compétences
  A moyen terme, l’arrivée d’agents spécialisés obligera à redéfinir les missions des développeurs, SRE et équipes sécurité : moins de tâches routinières, plus de supervision, de conception, de prompting avancé et de gouvernance technique.

Ce qui apparaît clair, c’est qu’AWS ne propose pas simplement des prompts» améliorés, mais une vision d’intégration de l’IA agéntique de bout en bout dans le cycle de vie software.