AWS lance un émulateur local entièrement écrit par des agents d’IA autonomes

Le 11 novembre 2026, AWS a lancé AWS Emulator, un émulateur local désormais disponible pour tous, conçu à partir de 438 modèles d’API AWS couvrant plus de 200 services. Des agents d’IA autonomes en ont écrit et testé le code, permettant aux développeurs et aux agents de programmation de tester les API AWS sur leurs propres machines, sans compte AWS.

L’AWS CLI, les SDK AWS et les agents de programmation se connectent à un point de terminaison HTTPS local et utilisent les mêmes API que dans le cloud. Des variables d’environnement redirigent ces outils vers la machine de l’utilisateur, sans qu’il soit nécessaire de modifier le code de l’application. Une publication d’AWS sur le lancement détaille les paquets RPM et Debian pour Linux, l’utilisation de Docker sur macOS et Windows, ainsi qu’un mode intégré pour les tests Rust. Aucun frais de service supplémentaire n’est facturé, mais les clients continuent de payer les ressources AWS qu’ils déploient dans le cloud.

Pour les agents de programmation, l’émulateur intègre l’infrastructure AWS à une boucle « écrire, exécuter, lire » : un agent peut créer une ressource, examiner le résultat et modifier son code sans attendre le déploiement dans une région AWS. La documentation AWS indique également que l’émulateur peut être utilisé dans des serveurs de développement et des environnements d’intégration continue, les requêtes étant alors dirigées vers des ressources émulées plutôt que vers AWS.

Trois équipes d’agents construisent et maintiennent le code

Matthew Goldberg, ingénieur principal principal chez AWS, a indiqué dans un récit de l’équipe d’ingénierie que son équipe n’avait ni écrit ni examiné le code de l’émulateur. Les humains ont plutôt mis en place le cadre nécessaire à ce travail, notamment les spécifications, les outils de test, les étapes de validation avant fusion et le processus de publication. Le projet a débuté lorsque l’agent de programmation Kiro a produit un émulateur Amazon SQS acceptable en environ 15 minutes, à partir d’une consigne lui demandant d’écrire des tests, de les valider auprès d’AWS réel et de créer une implémentation en mémoire qui les réussisse. Goldberg a ensuite demandé à Kiro d’élargir le prototype au cours d’un week-end ; pour en faire un produit robuste, il a fallu mettre en place les garde-fous nécessaires.

Trois équipes d’agents aux périmètres définis se répartissent désormais le travail. Les agents chargés des tests conçoivent des scénarios à partir de modèles d’API publiques et les vérifient auprès d’AWS réel. Les agents chargés de repérer les problèmes rejouent les tests et regroupent les échecs susceptibles d’avoir une cause commune, tandis que les agents correcteurs traitent chacun un problème. Goldberg fait état de dizaines de milliers de tests de fidélité, et de milliers de problèmes corrigés chaque jour par des centaines d’agents travaillant en parallèle.

Toute correction proposée doit compiler et réussir les vérifications automatisées portant sur les normes de codage, la sécurité et la fidélité avant de pouvoir être fusionnée. Un agent de sécurité indépendant examine les modifications de manière contradictoire pendant le développement, puis à nouveau dans le processus de publication. « Sans cette étape de validation avant fusion, nous ne ferions pas confiance à ce que construisent nos agents », a écrit Goldberg.

Les modifications passent ensuite par AWS CodeCommit et CodePipeline avant leur publication sur GitHub. Le dépôt public présente l’historique des validations, ainsi que des dossiers distincts pour les problèmes de fidélité résolus et non résolus. AWS a publié le code sous CC0, une déclaration de mise dans le domaine public, à l’exception du code de fournisseurs placé sous Apache 2.0 ; le dépôt n’accepte pas les demandes de fusion, mais les utilisateurs peuvent signaler des bogues et des écarts de fidélité dans GitHub Issues.

Les scores de fidélité en définissent les limites

Un test de fidélité est un court flux de travail vérifié auprès d’AWS réel. Pour réussir, l’émulateur doit reproduire la réponse à chaque appel, notamment son code d’état, son corps, ainsi que le code et le message d’erreur exacts, de même que les ressources et les données créées par le flux de travail. Les opérations non implémentées renvoient le code HTTP 501 (Non implémenté), ce qui fait apparaître immédiatement les échecs. Chaque version indique le nombre de tests réussis pour chaque service, et AWS précise que l’ajout de tests peut faire baisser un score, même lorsque l’émulateur s’améliore.

Tous les tests de la suite publique d’évaluation ont été vérifiés dans au moins deux comptes AWS isolés, et le dépôt précise clairement que tout comportement qui n’est couvert par aucun test n’est pas vérifié.

Ces scores ne font pas de l’émulateur un environnement de test de sécurité. Il n’évalue pas la gestion des identités et des accès AWS (IAM) ni les politiques fondées sur les ressources comme le fait AWS ; une requête qu’AWS rejette pourrait donc réussir localement. L’émulateur est destiné au développement et aux tests ; les charges de travail en production et les tests de sécurité des applications ne sont pas couverts. Chaque instance est conçue pour un seul compte et une seule région, conserve les ressources en mémoire et les supprime à l’arrêt.

L’ingénierie se recentre sur les spécifications et les tests

Dans la publication consacrée au lancement, Swaminathan Sivasubramanian a décrit le rôle de l’ingénieur comme consistant à décider ce qu’il convient de construire et à élaborer les spécifications, les tests et les étapes de validation avant fusion qui définissent les critères de conformité, tandis que les agents écrivent et vérifient le code.

La comparaison avec Alf, un ancien service distribué de verrouillage d’Amazon, en donne un exemple concret. La création du moteur de réplication initial a pris environ quatre mois. Sivasubramanian a expliqué qu’une reconstruction avec Kiro avait d’abord nécessité quatre nuits sous supervision, car l’agent ne pouvait pas vérifier ses résultats ; après qu’il lui eut fourni une spécification et un environnement de test, la reconstruction a pris environ deux heures.

AWS Emulator transforme cette leçon en un produit mis sur le marché : les agents génèrent et corrigent l’implémentation, tandis que les ingénieurs définissent le comportement attendu et automatisent son contrôle. Sa portée pratique dépend désormais de l’élargissement de la suite de tests publique et des écarts de fidélité qui subsistent ; la validation de la sécurité et de la production nécessite toujours AWS réel.