Développeurs : Amazon sort un logiciel écrit à 100 % par des agents IA, et personne ne l'a relu

30 681 modifications de code, plus de trente mille, et pas une seule écrite par un humain. C'est le compteur que j'ai relevé ce matin sur la page GitHub d'AWS Emulator, le nouveau logiciel gratuit qu'Amazon a sorti mercredi 11 novembre. Et ce n'est pas une démo de labo qu'on regarde derrière une vitre : c'est un vrai outil, téléchargeable, que des milliers de développeurs vont brancher sur leur travail dès cette semaine. L'équipe qui l'a lancé l'écrit noir sur blanc : « Notre équipe n'a écrit ni relu aucune ligne de ce code. » Ni relu ! Vous imaginez ?

Une copie du cloud d'Amazon qui tient sur ton bureau

Un cloud en miniature, sur ton ordinateur

Petit rappel pour ceux qui ne vivent pas dedans. AWS, pour Amazon Web Services, c'est la branche d'Amazon qui loue des serveurs et des services à des entreprises du monde entier : stockage de fichiers, bases de données, envoi de mails, files d'attente de messages... Une bonne partie des sites et des applis que tu utilises tous les jours tournent dessus sans que tu le saches.

Le problème des développeurs qui travaillent avec AWS, c'est de tester. Pour vérifier que ton programme sait bien ranger un fichier dans le stockage d'Amazon, il faut... le ranger pour de vrai, chez Amazon. Il te faut un compte, une connexion, et chaque essai peut coûter quelques centimes. Sur des milliers de tests par jour, ça finit par se voir sur la facture.

AWS Emulator, c'est un faux AWS qui tourne sur ta machine. Ton programme croit parler à Amazon, et en réalité il parle à un logiciel installé chez toi, qui répond exactement comme Amazon répondrait. Pas de compte, pas de facture, pas besoin d'Internet. C'est le principe du simulateur de vol : on apprend à poser l'avion sans risquer l'avion.

Personne n'a écrit une ligne. Vraiment personne.

Le plus fou, c'est comment il a été fabriqué. Tout est parti d'un week-end. Matthew Goldberg, un ingénieur d'Amazon, a donné une consigne en trois temps à Kiro, l'assistant de programmation maison d'Amazon : écris des tests à partir de la documentation officielle d'AWS, vérifie qu'ils passent sur le vrai AWS, puis construis une imitation qui passe les mêmes tests. Un quart d'heure plus tard, il avait une première copie d'un service d'Amazon. À la fin du week-end, Kiro avait attaqué tout le reste. Avec des trous, évidemment.

Pour boucher les trous, Amazon a monté trois équipes d'agents IA, des programmes qui travaillent seuls sur une tâche du début à la fin. La première écrit des tests et vérifie chacun sur le vrai AWS. La deuxième passe ces tests sur l'imitation et note chaque échec dans une fiche. La troisième prend une fiche, cherche la cause, corrige le code. D'après le billet d'Amazon, des centaines d'agents travaillent en même temps, et des milliers de corrections tombent chaque jour.

Pas de relecture humaine, mais un portique automatique que chaque correction doit franchir

Mais pas n'importe comment. Chaque correction doit passer un portique automatique avant d'entrer dans le code : elle doit compiler, respecter les règles d'écriture de la maison, passer une revue de sécurité faite par d'autres agents, et ne rien casser de ce qui marchait déjà. Si elle échoue, retour à l'envoyeur. Amazon le dit sans détour : sans ce portique, ils ne feraient pas confiance à ce que fabriquent leurs agents.

J'ai vérifié les chiffres moi-même sur GitHub ce matin : 30 681 modifications, 438 dossiers de services (un par morceau d'AWS imité), et une version 1.0.338 publiée hier soir à 22 h 58, heure de Bruxelles. Elle corrige des petites différences avec le vrai AWS, une par une. Ça ne dort jamais, ce truc.

Le métier de développeur, version Amazon

Ce qui m'intéresse le plus, en tant que développeur, c'est ce qu'Amazon en tire sur notre métier. Werner Vogels, le directeur technique d'Amazon, l'a écrit sur son blog : le travail de l'ingénieur, c'est désormais de « leur laisser de la place pour travailler seuls ». En clair, l'humain n'écrit plus le code. Il écrit la description de ce qu'il faut obtenir, les tests qui disent si c'est juste, et les barrières qui empêchent les agents de faire n'importe quoi.

Et il donne un exemple qui m'a scotché. Un responsable d'Amazon avait réécrit à la main, il y a des années, un morceau de système qui fait que plusieurs serveurs restent d'accord entre eux. Ça lui avait pris quatre mois. Il a demandé à Kiro de le refaire. Pendant quatre soirées, il l'a surveillé sans résultat, parce que l'agent n'avait aucun moyen de vérifier son propre travail. Avec une description précise et un environnement de test, c'est tombé en deux heures !

Ça rejoint exactement ce que je disais quand Anthropic annonçait que Claude écrivait 90 % de son propre code : la vraie question n'est plus qui écrit, c'est qui relit. Amazon répond « une machine qui ne laisse rien passer ». Moi, j'ai des boucles qui relisent mon code avec l'IA jusqu'à zéro avertissement, donc je comprends la logique. Mais je conseille toujours la même chose : regarde le code que l'IA produit. Un portique vérifie ce qu'on lui a demandé de vérifier, pas ce qu'on a oublié de lui demander.

Bon, et ça marche ?

À peu près, et Amazon ne fait pas semblant. Le dépôt GitHub contient un dossier au nom très honnête, « things-that-do-not-work » (les choses qui ne marchent pas), où sont listées toutes les différences connues avec le vrai AWS. D'après le site MarkTechPost, l'imitation colle au vrai AWS sur un peu plus de la moitié des tests. La documentation prévient aussi : ne pas s'en servir pour tester la sécurité ni pour la mise en production.

Un simulateur, pas l'avion : pour la sécurité et le vrai décollage, on passe toujours par le vrai cloud

Les développeurs sont partagés. Sur Hacker News, le forum des développeurs, l'un d'eux trouve que ça « ressemble plus à une expérience scientifique qu'à un produit ». D'autres sont ravis, parce que le concurrent le plus connu, LocalStack, a réservé cette année sa version gratuite à un usage non commercial, avec un compte obligatoire. Là, c'est gratuit, et même versé dans le domaine public : tu peux en faire ce que tu veux.

Deux détails moins sympas, quand même. Le logiciel envoie des statistiques d'utilisation à Amazon par défaut, c'est écrit dans la page d'accueil du projet. Et si tu veux le fabriquer toi-même à partir du code, le README demande au moins 100 Go de libre sur ton disque. Cent gigas, pour un faux cloud ! Heureusement, des paquets tout prêts existent.

Et pour toi, qui n'es pas développeur ?

Tu ne vas pas installer AWS Emulator, c'est sûr. Mais l'appli de ta banque, le site où tu commandes tes courses ou le service de streaming du soir ont de bonnes chances de tourner en partie sur AWS. Quand tester devient gratuit et instantané, les développeurs testent plus, plus souvent, et laissent passer moins de bugs. Le jour où l'appli de ta banque plante un peu moins le 1er du mois, une partie du mérite pourrait venir de là.

Ça a un précédent. En 1929, un Américain, Edwin Link, fabrique un drôle d'engin dans l'usine d'orgues de son père : une cabine d'avion posée au sol, qui penche et tourne grâce à des soufflets. Au début, ce sont surtout les fêtes foraines qui l'achètent, comme manège. En 1934, l'armée américaine en commande six, et aujourd'hui aucun pilote de ligne ne vole sans des dizaines d'heures de simulateur. L'émulateur, c'est pareil pour le code : on s'entraîne au sol, et on ne décolle que quand ça passe.

L'échéance ? Pour les développeurs, c'est dès aujourd'hui. Pour toi, l'effet sera indirect, lent, et impossible à mesurer de chez toi. Par contre, la façon dont il a été fabriqué, elle, va se voir bien plus vite : si Amazon peut sortir un logiciel de cette taille sans écrire une ligne, toutes les grandes boîtes vont vouloir faire pareil. Et ça, ça change la tête des équipes de développement qui fabriquent tes applis.

Si tu es développeur

Tu peux sauter cette partie si tu n'as jamais programmé pour AWS. Sinon, voilà comment démarrer, d'après le README du projet. Le SDK, c'est la bibliothèque que ton programme utilise pour parler à AWS, et la CLI, l'outil en ligne de commande d'Amazon : les deux peuvent être redirigés vers l'émulateur.

Le plus simple, si tu travailles avec un agent de code : installe la compétence prévue pour lui (il faut la CLI AWS en version 2.35.0 au moins), puis demande-lui de mettre l'émulateur en place.

aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1

Sous Linux, installe le paquet RPM ou Debian et lance aws-emulator. Sous Windows et macOS, ça passe par un conteneur Docker. Ensuite, quelques variables d'environnement suffisent pour pointer ton SDK ou la CLI vers l'émulateur au lieu d'AWS. Tout vit en mémoire : quand tu l'arrêtes, tout disparaît, ce qui est plutôt une bonne chose pour des tests. En Rust, il existe aussi un mode embarqué, une instance isolée par test, sans réseau ni certificat.

Avant de t'y fier, regarde le score de fidélité de chaque service sur la page des versions, et le dossier issues/things-that-do-not-work/. Et pense à couper la télémétrie si tu n'en veux pas : elle est active par défaut, la documentation explique comment faire.

Pour moi, le plus malin n'est pas l'émulateur, c'est l'arbitre. Les agents écrivent tout, même les tests, mais chaque test passe d'abord sur le vrai AWS : l'original sert de juge à sa propre copie. Sur un projet où personne ne relit rien, c'est franchement la seule chose qui me rassure !

Sources

• Amazon, 11 novembre 2026 : comment des agents IA autonomes ont construit AWS Emulator (en anglais)
• Werner Vogels, All Things Distributed, 11 novembre 2026 : AWS Emulator et le métier d'ingénieur quand les agents écrivent le code (en anglais)
• Le dépôt GitHub d'AWS Emulator, son README et son historique de modifications (en anglais)
• GeekWire : AWS offre aux développeurs une copie locale gratuite de son cloud, construite par des agents IA (en anglais)

Article écrit avec l'aide de Claude Code, relu et corrigé par moi.