Le 11 novembre 2026, Amazon Web Services (AWS) a publié AWS Emulator, un logiciel gratuit que des agents d’IA ont écrit sans relecture humaine, selon Amazon. AWS est la filiale d’Amazon qui loue des serveurs et des logiciels à distance, ce qu’on appelle le cloud. L’émulateur imite plus de 200 services d’AWS sur l’ordinateur d’un développeur, qui peut ainsi tester son code sans toucher au vrai cloud.
Matthew Goldberg, ingénieur principal senior chez AWS, raconte la construction de l’outil dans un billet publié sur About Amazon. Il affirme que l’émulateur « a été entièrement écrit par des agents autonomes » et que « notre équipe n’a écrit ni relu aucune partie du code ». Un agent d’IA est un programme qui enchaîne des tâches sans attendre d’instruction à chaque étape.
Le code de l’émulateur est public sur GitHub, la plateforme où les développeurs publient et partagent leur code. Dans la nuit du 12 au 13 novembre, nous avons interrogé son API, l’interface qui permet à un programme d’y lire des données. Le dépôt de l’émulateur, le dossier en ligne qui rassemble son code, comptait 30 681 commits entre le 21 octobre et le 12 novembre. Un commit est une modification enregistrée dans l’historique du code.
Tous ces commits sont signés par des identités automatiques, comme IssueFixerAgent, et aucun ne porte un nom de personne. Environ 13 500 sont des corrections. Environ 8 800 enregistrent des signalements de bugs, et environ 8 300 sont des fusions automatiques, qui tiennent à jour la copie du code d’un agent.
La même semaine, trois autres chantiers d’ingénierie qui demandaient des mois ou des années ont été annoncés comme bouclés en quelques heures, jours ou semaines. Google DeepMind, le laboratoire d’IA de Google, dit avoir prouvé en quatre semaines des propriétés de sécurité clés du code qui chiffre les messages de la messagerie Signal.
Anthropic, l’entreprise qui développe l’assistant d’IA Claude, a affirmé aux investisseurs que son modèle Mythos avait fait tourner l’un de ses modèles sur des puces du fabricant AMD en trois jours environ. Swami Sivasubramanian, vice-président d’AWS, raconte qu’un agent a reconstruit en deux heures environ un composant logiciel qu’il avait mis environ quatre mois à construire à la main avec un collègue.
Trois équipes d’agents et un contrôle avant fusion
Goldberg décrit trois équipes d’agents. Selon le site d’information technologique GeekWire, elles tournent sur Amazon Bedrock AgentCore, le service d’AWS qui héberge des agents d’IA. La première équipe écrit des « tests de fidélité », qui vérifient que l’émulateur répond comme le vrai AWS. Ce sont des scénarios concrets, comme créer une file de messages, y envoyer un message puis la supprimer.
Les agents tirent ces tests des modèles d’API publics d’AWS, plus de 400 au total. Ces modèles décrivent, sous une forme lisible par une machine, ce que chaque service accepte et renvoie. Les agents vérifient ensuite chaque test sur le vrai AWS avant de le soumettre. Selon AWS, il en existe « des dizaines de milliers ».
La deuxième équipe fait passer ces tests à l’émulateur. Elle ouvre des tickets pour les échecs, des fiches qui décrivent chaque problème, en regroupant ceux qui semblent avoir la même cause. La troisième équipe confie chaque ticket à un agent, qui le corrige.
Au départ, écrit Goldberg, il n’y avait qu’« un serveur web vide ». Il pouvait recevoir des requêtes pour les 438 modèles d’API d’AWS, mais « ne faisait rien ».
Chaque modification passe un contrôle avant d’être fusionnée, c’est-à-dire intégrée au code principal. Ce contrôle écarte le code qui ne compile pas, que la machine ne parvient pas à transformer en programme. Des agents y vérifient aussi les règles d’écriture et la sécurité, et traquent les régressions, ces tests déjà réussis qui se mettraient à échouer. Une modification refusée retourne à son agent.
« Sans ce contrôle, nous ne ferions pas confiance à ce que construisent nos agents », écrit Goldberg. Il évoque « des milliers de tickets corrigés chaque jour » par « des centaines d’agents » qui travaillent en même temps sur le code.
GitHub indiquait en octobre que plus de 40 % des pull requests ouvertes sur sa plateforme en septembre partaient d’un premier jet d’agent. Une pull request est une modification proposée à la relecture avant d’être intégrée au code. Chez AWS, selon Amazon, personne ne relit ce que les agents intègrent.
L’historique public des commits
Le code passe d’abord par les dépôts internes d’AWS. Il n’est publié sur GitHub qu’à la fin de chaque version, sous licence CC0, qui le verse dans le domaine public. Le premier commit, intitulé « Initial emulator scaffold », est signé « Scaffolder ». Il date du 21 octobre à 20 h 54 en temps universel (UTC).
La liste des contributeurs fournie par GitHub compte cinq auteurs, tous automatiques. IssueFinderAgent, signe 17 122 commits, et IssueFixerAgent, en signe 13 520. Scaffolder en signe 29, TraceIdMigration 6 et ReleaseManagerAgent 4. Ces noms sont des étiquettes inscrites par les outils d’AWS : ils indiquent quelle partie du système a fait une modification et ne disent rien du degré de surveillance humaine.
Les commits d’IssueFinderAgent se partagent en deux groupes. Environ 8 800 déposent des signalements de bugs, enregistrés sous forme de fichiers. Les quelque 8 300 autres sont les fusions automatiques qui tiennent sa copie du code à jour. Les signalements en attente sont rangés dans un dossier nommé things-that-do-not-work (« ce qui ne marche pas »).
Tôt le 12 novembre, quand notre article sur une preuve de physique produite par l’IA a cité l’émulateur, le dépôt affichait 29 684 commits. À la dernière mise à jour du dépôt, tard dans la soirée, il en comptait 997 de plus. Par comparaison, Anthropic a indiqué en octobre avoir intégré 30 401 modifications de code dans son dépôt de code principal en une seule journée de septembre.
Ces 22 jours ne couvrent que l’historique de la version publique actuelle. Goldberg précise que les agents ont construit « de nombreuses versions » de l’émulateur.
Dans l’une d’elles, ils avaient « décidé de construire leur propre interpréteur Python », le logiciel qui exécute les programmes écrits dans ce langage. Cet interpréteur devait faire tourner les fonctions AWS Lambda, de petits programmes que le service Lambda d’AWS exécute à la demande. L’équipe a fini par demander aux agents de réutiliser des bibliothèques existantes.
Un prototype bâti en un week-end
Goldberg dit s’être inspiré d’une démonstration d’Anthropic. Plus tôt dans l’année, des agents y avaient construit un compilateur C, le programme qui traduit ce langage de programmation en instructions pour la machine.
Il a donné à Kiro, l’agent de programmation d’AWS, une consigne en trois étapes. Kiro devait d’abord écrire des tests à partir de l’outil en ligne de commande d’AWS, qui pilote le cloud par des instructions tapées au clavier. Il devait ensuite les ajuster jusqu’à ce qu’ils passent sur le vrai AWS, puis construire une version en mémoire qui réussisse ces mêmes tests.
Au bout de 15 minutes, Kiro a rendu une « première version passable » d’Amazon SQS, le service de files de messages d’AWS, qui transmet des messages entre programmes. En un week-end, il a bâti une version grossière du reste d’AWS, et l’équipe de Goldberg s’en servait dès le lundi. Goldberg ajoute : « En faire un produit solide a pris plus d’un week-end. »
Trois autres chantiers raccourcis, annoncés la même semaine
Le premier chantier concerne Signal. Le 10 novembre, Google DeepMind a expliqué que ses chercheurs, aidés de plusieurs modèles d’IA, avaient traduit les objectifs de sécurité de Signal en spécifications formelles, « chacune relue par des experts humains ». Une spécification formelle décrit en langage mathématique ce que le code doit garantir.
Des agents fondés sur Gemini Carbon, un modèle d’IA de Google, ont ensuite écrit « plus de six millions de lignes de Lean ». Lean est un langage de preuve dont le vérificateur contrôle chaque étape d’une preuve. Ces lignes de preuve montrent que le code cryptographique compilé de Signal, c’est-à-dire sa version traduite en instructions pour la machine, respecte les spécifications.
Selon DeepMind, le travail a pris quatre semaines, « une tâche qui prend historiquement des années à des équipes d’experts ». Les agents n’ont signalé qu’« un pour cent du code » à revoir par un humain. Nous avions décrit une méthode voisine de vérification par la machine lorsque Claude avait écrit des preuves d’absence de plantage dans 123 bibliothèques open source.
Le deuxième chantier vient d’Anthropic. L’annonce figure dans la vidéo de la tournée de présentation de l’introduction en Bourse d’Anthropic, la série de rencontres avec les investisseurs lancée le 10 novembre. Tom Brown, cofondateur de l’entreprise, y explique qu’intégrer une nouvelle famille de puces « mobilisait des dizaines d’ingénieurs pendant des mois ». Cette fois, selon lui, Mythos a fait « tourner Claude sur AMD en seulement trois jours, quasiment sans intervention humaine ».
Une diapositive de cette présentation annonce environ 3 jours, contre environ 6 à 12 mois avec la méthode classique. Sa note de bas de page réduit la portée du chiffre. Il s’agit de faire fonctionner, à un niveau de performance utile, le traitement des requêtes d’un seul modèle d’Anthropic sur des processeurs graphiques AMD MI355X. Le traitement des requêtes est l’étape où le modèle lit ce qu’on lui soumet.
Le troisième cas est celui de Swami Sivasubramanian, qui le raconte sur le blog de Werner Vogels, directeur technique d’Amazon. Il y a une vingtaine d’années, il a construit avec Al Vermeulen le moteur de réplication d’Alf, un service de verrous qui empêche plusieurs programmes de modifier la même donnée en même temps. Alf reposait sur Paxos, un protocole qui permet à un groupe de serveurs de se mettre d’accord sur une valeur. Ce moteur leur avait pris « environ quatre mois ».
Pour la reconstruction, il a d’abord supervisé Kiro « pendant quatre nuits », avant de comprendre que l’agent « n’avait aucun moyen de vérifier ses résultats ». Il ajoute : « Une fois qu’il a eu une spécification et un environnement de test, la reconstruction a pris environ deux heures. »
Les limites reconnues par AWS et relevées par d’autres
Le fichier de présentation du dépôt sur GitHub demande de ne pas utiliser l’émulateur « pour des charges de production ni pour tester la sécurité ». Une charge de production est une application en service pour de vrais utilisateurs.
Le guide d’utilisation précise que l’émulateur n’évalue pas les règles d’autorisation comme le fait AWS. Ces règles fixent qui a le droit de faire quoi ; l’émulateur, lui, « ne refuse jamais une requête signée avec sa propre clé ». Il ne sépare pas non plus les comptes AWS ni les régions, ces groupes de centres de données situés dans une même zone géographique.
Le code que l’émulateur exécute pour l’utilisateur, une fonction Lambda par exemple, n’est pas isolé du reste de l’ordinateur. Il « peut lire et modifier vos fichiers ».
L’émulateur colle au plus près d’AWS pour les appels qui créent, décrivent, modifient ou suppriment des ressources ; ailleurs, sa fidélité dépend du service. Il n’est comparé au vrai cloud que dans une seule région, US West (Oregon), hors services globaux, ceux qui ne dépendent d’aucune région.
Devin Pratt, directeur de recherche au cabinet d’études IDC, a déclaré au site InfoWorld qu’à son lancement l’émulateur « ne simule pas les limitations de débit ni les pannes ». Il s’agit des plafonds de requêtes et des défaillances des services d’AWS. Selon lui, ces manques figurent parmi ceux qui « comptent le plus pour la résilience », la capacité d’une application à tenir malgré les incidents.
Le contrôle avant fusion qui remplace la relecture humaine confie lui-même la relecture du code à des agents. AWS ne publie pas d’autre mesure d’erreur que ses propres scores de fidélité, version par version.
Sur Signal, le magazine Wired, repris par le site Ars Technica, note que DeepMind n’a trouvé aucune nouvelle faille dans les parties examinées. Le travail ne couvre pas toute l’application Signal. Il a aussi profité de vérifications menées auparavant par Signal, et Google a refusé d’en donner le coût.
Le site d’actualité sur l’IA The Decoder rappelle que les chiffres d’Anthropic sur AMD viennent de documents destinés aux investisseurs. Ils n’ont pas été vérifiés de façon indépendante. Les deux heures de Sivasubramanian concernent un seul composant, reconstruit par l’un de ses concepteurs d’origine.
Notre analyse
Dans chaque cas, une machine pouvait vérifier le résultat. Les tests de l’émulateur sont confirmés sur le vrai cloud d’AWS, et les preuves de DeepMind passent ou échouent dans Lean. Une puce fait tourner le modèle d’Anthropic à une vitesse utile, ou non. Là où ce contrôle existait, le délai annoncé est passé de plusieurs mois ou années à quelques heures, jours ou semaines.
Le travail humain s’est déplacé vers la définition de ce que la machine vérifie. Sivasubramanian écrit que le rôle de l’ingénieur consiste à « construire les spécifications, les tests et les contrôles avant fusion qui décident quand ce travail est correct ». Selon lui, AWS s’attend à ce que « des agents construisent et vérifient la plupart des logiciels ». Chez DeepMind, des experts ont relu chaque spécification ; chez AWS, des ingénieurs ont conçu le contrôle.
Aucune de ces annonces ne dit combien de fois un contrôle réussi cache une réponse fausse. Les tests d’AWS couvrent ce que ses agents ont pensé à tester, et la liste des écarts connus est publique.
Goldberg annonce de prochains billets sur la manière dont AWS mesure la fidélité et tient son niveau de qualité et de sécurité. Sivasubramanian promet d’en dire plus à re:Invent, la conférence annuelle d’AWS.
Sources
- How we built the agents that built AWS Emulator, Matthew Goldberg, About Amazon, 11 novembre 2026
- AWS Emulator and the engineer’s job when agents write the code, Swami Sivasubramanian, All Things Distributed, 11 novembre 2026
- aws/aws-emulator (repository, README and commit history), Amazon Web Services, GitHub, version 1.0.338 du 12 novembre 2026
- What is AWS Emulator?, Guide d’utilisation d’AWS Emulator, Amazon Web Services, consulté le 13 novembre 2026
- AWS unveils local emulator service to help enterprises accelerate app development and testing, Anirban Ghoshal, InfoWorld, 11 novembre 2026
- Introducing AlphaProof Code: a breakthrough in verifying complex software at depth, Pushmeet Kohli et Swarat Chaudhuri, Google DeepMind, 10 novembre 2026
- Anthropic IPO: roadshow video, chapter « Approach to compute », Anthropic, 10 novembre 2026
- Anthropic says AI is eroding Nvidia’s CUDA lead, cutting an AMD chip switch from months to three days, Matthias Bastian, The Decoder, 11 novembre 2026
Image d’en-tête : graphique MACCUS, données de l’API GitHub pour github.com/aws/aws-emulator, lecture du 13 novembre 2026
