AWS Professional Services a détaillé un système multi-agents conçu pour automatiser de vastes migrations cloud d’entreprise, en utilisant Amazon Bedrock AgentCore pour coordonner la découverte, la génération de code d’infrastructure, la gouvernance et les opérations post-migration.

Le système vise des programmes de migration impliquant des centaines d’applications, où l’accueil manuel et le développement d’infrastructure peuvent prendre plus de temps que le déplacement lui-même. AWS indique que son cadre interne a réduit le développement d’infrastructure as code de trois ou quatre semaines par application à quelques minutes sur un portefeuille de plus de 300 applications. Ce résultat provient de données internes de suivi de projet et n’a pas été vérifié de manière indépendante.

Cette annonce est importante parce qu’elle présente AgentCore non pas simplement comme un runtime pour des assistants individuels, mais comme la couche de contrôle d’un workflow couvrant l’évaluation, le déploiement et les opérations. Pour les équipes technologiques en entreprise, la question la plus importante est de savoir si l’automatisation agentique peut produire un travail de migration répétable et gouverné sans retirer l’approbation humaine des décisions d’infrastructure à fort impact.

Un workflow de migration réparti entre des agents spécialisés

AWS décrit un cadre conçu par AWS Professional Services avec le SDK Strands Agents. Plutôt que d’attribuer un seul modèle polyvalent à l’ensemble de la migration, l’architecture répartit le travail entre des agents aux responsabilités plus ciblées.

Un Intake Agent automatise la découverte des applications, la cartographie des dépendances et la définition d’une architecture cible. Un IaC Agent génère ensuite de l’infrastructure as code conformément aux pratiques et normes de sécurité d’une organisation. Un Migration Intelligence and Governance Agent produit des rapports de portefeuille, des évaluations Well-Architected et des informations de gouvernance dans des outils tels que Jira, Confluence et Webex.

Après le déploiement, un SRE Agent surveille les charges de travail migrées, identifie les dégradations potentielles et prend en charge la remédiation automatisée. AWS cite également des services adjacents pour des tâches de migration spécifiques, notamment AWS Database Migration Service pour la conversion de schémas assistée et le basculement de bases de données, ainsi que AWS Transform pour la modernisation d’applications héritées.

Cette répartition reflète les différents profils de risque d’un programme de migration. La découverte exige d’extraire des faits à partir de documents et de systèmes existants. La génération de code exige le respect des normes d’infrastructure. La gouvernance exige une visibilité au niveau du portefeuille, tandis que les opérations exigent un accès aux systèmes en direct et une remédiation soigneusement contrôlée. Traiter ces tâches comme des rôles d’agents distincts peut rendre les autorisations et l’évaluation plus gérables que de confier une autorité étendue à un seul agent.

Comment Amazon Bedrock AgentCore s’intègre dans le système

Selon le AWS Machine Learning Blog, chaque agent est défini par un modèle fondation, un prompt système et un ensemble d’outils. Amazon Bedrock AgentCore Runtime héberge les agents dans un environnement serverless avec isolation des sessions et prise en charge de l’orchestration multi-agents.

Les agents accèdent à des capacités externes via des outils Model Context Protocol. AgentCore Gateway peut convertir des API, des fonctions AWS Lambda et des services existants en outils compatibles MCP, ce qui permet au cadre de connecter les agents de migration aux systèmes d’entreprise sans reconstruire chaque intégration autour d’une nouvelle interface.

L’identité est gérée via AgentCore Identity, qui, selon AWS, authentifie les appels à l’aide de rôles AWS Identity and Access Management restreints et du fournisseur d’identité de l’organisation. C’est un détail central pour l’automatisation de l’infrastructure : la frontière de sécurité pratique ne dépend pas seulement des instructions du modèle, mais aussi de ce que chaque agent est techniquement autorisé à lire, modifier ou exécuter.

AWS indique que le cadre applique des contrôles de sécurité tout au long du cycle de vie de la migration et laisse les décisions sous responsabilité humaine. La source ne précise pas les points d’approbation exacts, les mécanismes de retour arrière ou les seuils d’évaluation utilisés dans le déploiement interne, il ne faut donc pas supposer que le modèle décrit fournit automatiquement des contrôles de niveau production pour tous les environnements.

Les éléments à l’appui de la promesse de performance

La revendication d’efficacité la plus forte de l’annonce est fournie par le vendeur. AWS attribue la réduction du développement IaC de trois ou quatre semaines par application à quelques minutes sur un portefeuille dépassant 300 applications à ses données internes de suivi de projet. Le blog ne fournit pas de méthodologie complète avant/après, ni de détails sur la complexité de chaque application, ni sur le volume de revue humaine, ni sur le pourcentage de code généré accepté sans modifications substantielles.

Cette distinction est importante. « Quelques minutes » peut décrire la génération initiale plutôt que le chemin complet vers une infrastructure approuvée, testée, sécurisée et déployée. Dans le travail de migration en entreprise, la validation, la gestion des exceptions, les décisions de réseau, les dépendances de données, l’examen de conformité et la gestion du changement peuvent rester importants même lorsque la rédaction du code est automatisée.

Les preuves disponibles établissent toutefois ce que présente AWS : une architecture interne opérationnelle combinant des agents IA dédiés, des outils d’entreprise et des services de migration AWS. Elles n’établissent pas encore un gain de temps généralement reproductible à travers les secteurs ou les portefeuilles d’applications. La deuxième source de ce groupe est un blog contrôlé par AWS, tandis que le texte fourni par l’agence ne contient aucun texte d’article supplémentaire ni reportage indépendant.

Ce que cela signifie pour les équipes de migration cloud

Pour les développeurs, le cadre offre un modèle de référence pour relier des agents IA à des données de migration et à des systèmes opérationnels existants. L’idée la plus réutilisable est la séparation des agents par phase du cycle de vie et par périmètre d’autorisation. Un agent de découverte pourrait avoir accès aux inventaires et aux documents d’architecture, tandis qu’un agent d’infrastructure pourrait générer des fichiers sans disposer de droits directs de déploiement en production. Un agent d’exploitation pourrait inspecter la télémétrie et proposer des remédiations avant qu’un humain ou un moteur de règles n’approuve les changements.

Cette structure peut aussi rendre les tests plus concrets. Les équipes peuvent évaluer la précision de la découverte via les résultats de cartographie des dépendances, évaluer l’IaC généré par rapport aux contrôles de politique et de sécurité, et mesurer les agents opérationnels sur la précision des alertes, le succès des remédiations et le comportement de retour arrière. Ce sont des mesures plus utiles que la seule vitesse de réponse d’un modèle.

Pour les acheteurs d’entreprise, le compromis clé se situe entre un travail standard plus rapide et le coût de la gouvernance de l’accès des agents. Les capacités de runtime, de passerelle et d’identité d’AgentCore couvrent une partie du déploiement et de l’autorisation, mais les organisations ont encore besoin de politiques de sélection des modèles, de journaux d’audit, d’isolation des environnements, de gestion des secrets, d’approbations humaines et d’un processus pour gérer les applications qui ne correspondent pas aux schémas standards.

L’approche peut être particulièrement pertinente pour les programmes de sortie de datacenter avec des délais fixes, où la découverte répétitive et la préparation du code créent une file de travail. Il est moins clair dans quelle mesure le système fonctionne sur des systèmes hautement personnalisés, des dépendances non documentées ou des migrations nécessitant une refonte importante des applications. L’inclusion d’AWS DMS et d’AWS Transform suggère que la couche d’orchestration est destinée à combiner des agents génériques avec des services spécialisés plutôt qu’à remplacer tous les outils de migration.

Ce qu’il faudra surveiller ensuite

Les prochains signaux utiles seront des études de cas indépendantes montrant le temps total de migration, et pas seulement le temps de génération de l’IaC. Les acheteurs devraient rechercher des chiffres couvrant l’effort de revue, le succès du déploiement, les taux de retour arrière, les constats de sécurité et la part des applications gérées sans ingénierie sur mesure.

Des détails supplémentaires sur les points d’approbation humaine du cadre clarifieraient aussi sa maturité opérationnelle. Des exemples de sorties d’agents rejetées ou corrigées, des pistes d’audit issues d’AgentCore Identity et des politiques régissant la remédiation automatisée aideraient les équipes à évaluer le risque.

Enfin, la disponibilité d’implémentations de référence réutilisables, de modèles pris en charge par région AWS et d’intégrations au-delà des outils nommés dans le blog indiquera si cela reste un modèle AWS Professional Services ou devient une architecture de plateforme largement adoptable. L’adoption par des partenaires de migration et les preuves provenant de clients hors AWS fourniraient un signal de marché plus fort que le résultat interne actuel.

Point de vue Creati.ai

AWS positionne AgentCore comme une infrastructure pour des agents d’IA d’entreprise coordonnés, et la migration cloud est un cas d’usage crédible parce que le travail est répétitif tout en dépendant encore d’un jugement spécialisé. La valeur de l’architecture viendra probablement moins de la prise de décision autonome que de la transformation de tâches de migration dispersées en workflows contrôlés et inspectables.

L’accélération annoncée est notable, mais elle doit être lue comme un benchmark interne plutôt que comme un résultat à l’échelle du marché. Pour les développeurs IA et les équipes d’entreprise, l’enseignement durable est de combiner des responsabilités d’agents restreintes avec des frontières d’identité strictes, des points de contrôle mesurables et des preuves opérationnelles avant de laisser l’infrastructure générée ou la remédiation automatisée affecter des systèmes de production.