AWS Emulator : Amazon publie un émulateur local et gratuit de ses API, écrit et maintenu par des agents d'IA

Tester du code qui appelle AWS a toujours eu un coût : un compte, des ressources à créer et à détruire, des déploiements qui prennent des minutes. Pour un agent de programmation qui veut vérifier son travail en boucle, c’est un frein majeur. Amazon y répond avec AWS Emulator, disponible depuis le 11 novembre : un émulateur local de ses API, gratuit, qui répond aux mêmes commandes que le cloud.

Comment ça marche

L’émulateur est un programme en ligne de commande, écrit en Rust pour rester léger, qui sert un point d’accès HTTPS sur 127.0.0.1:9297. Il génère ses propres clés (qui commencent par EMULATOR, pour éviter toute confusion avec de vraies clés) et refuse les requêtes signées autrement. On fait pointer la CLI AWS ou un SDK vers lui avec quelques variables d’environnement, et le code de l’application ne change pas. Sous Linux, il s’installe par paquet RPM ou Debian ; sous macOS et Windows, il faut construire une image Docker à partir du Dockerfile de la documentation, AWS n’en publiant pas de toute faite. Pour les tests écrits en Rust, un mode embarqué lance une instance isolée par test, sans réseau.

Côté couverture, AWS ne dresse pas de liste fermée : l’émulateur est généré à partir des modèles d’API publics d’AWS, ceux qui servent aussi à produire les SDK, si bien que les requêtes et les erreurs ont la même forme que sur AWS. Une opération pas encore implémentée renvoie une erreur 501, ce qui fait échouer un test immédiatement plutôt que de le laisser passer à tort.

Un logiciel écrit par des agents, et ça se voit

Le plus inhabituel est la fabrication. Selon AWS, l’émulateur est construit et maintenu par des agents d’IA : un groupe compare les réponses de l’émulateur à celles d’AWS et ouvre un ticket pour chaque écart, un autre écrit les tests et le correctif, puis un agent de sécurité indépendant relit la modification avant qu’elle ne parte en production. Le dépôt n’accepte d’ailleurs pas de contributions extérieures, seulement des signalements.

Le rythme est sans commune mesure avec un projet classique. La page des versions passe de la v1.0.269 le 8 novembre à la v1.0.341 le 13 novembre, soit plus de 70 versions en cinq jours, chacune listant des dizaines de correctifs générés automatiquement. Beaucoup portent la mention « stub », signe qu’une opération n’était encore qu’une coquille vide. Pour un utilisateur, c’est à double tranchant : les manques se comblent vite, mais le comportement change plusieurs fois par jour. AWS publie à chaque version un score de fidélité par service (tests réussis sur tests existants) et les tests eux-mêmes dans un dépôt séparé, pour que chacun puisse les rejouer.

Les limites à connaître avant de s’y fier

AWS est explicite sur ce que l’outil ne fait pas. Surtout, il n’évalue pas les politiques IAM comme le fait AWS : une requête refusée dans le cloud peut réussir dans l’émulateur. Il ne faut donc jamais s’en servir pour valider des réglages de sécurité. Il simule un seul compte et ne sépare pas les Régions ; son comportement n’est vérifié que dans la Région de l’Oregon ; il n’est pas prévu pour un usage prolongé ni pour des tests de charge ; et il envoie par défaut des données d’usage anonymes, que l’on peut couper. AWS reconnaît enfin que la fidélité est meilleure sur la création et la gestion des ressources que sur les opérations de données, et qu’elle varie avec les outils d’infrastructure comme CloudFormation, Terraform ou le CDK.