En décembre 2025, AWS a perdu treize heures sur AWS Cost Explorer, un service de suivi des dépenses cloud utilisé par ses clients en Chine continentale. Quatre sources internes ont parlé au Financial Times et leur version contredit celle d'Amazon.
Vous ne vous êtes rendu compte de rien, mais mi-décembre 2025, AWS Cost Explorer a disparu des écrans de ses clients pendant treize heures dans deux régions de Chine continentale. Ce service permet aux clients d'Amazon de visualiser et de gérer leurs dépenses cloud. Quatre employés ont rapporté au Financial Times que Kiro, l'outil de codage agentiel lancé par AWS en juillet 2025, avait pris la décision de supprimer puis recréer un environnement entier pour résoudre un problème, sans que personne valide cette action en temps réel. Amazon a publié sa propre version des faits peu après, en attribuant la panne à la mauvaise configuration des contrôles d'accès par un ingénieur interne qui disposait de permissions trop larges. Erreur humaine, dit l'entreprise, pas erreur d'IA.
Un cadre supérieur d'AWS a pourtant déclaré au journal américain qu'il s'agissait de la deuxième panne de production en quelques mois dans des circonstances comparables, des ingénieurs ayant laissé l'IA résoudre des problèmes sans supervision. Il les qualifie de pannes « mineures mais parfaitement prévisibles ».
Un détail procédural au cœur du désaccord
Par défaut, Kiro demande une autorisation avant d'agir, ce qu'Amazon précise dans sa déclaration. Mais l'outil opère avec les droits de l'utilisateur qui l'active, et cet ingénieur n'avait pas besoin d'une validation par un second collègue, contrairement à la procédure habituelle en vigueur chez AWS. Un outil autonome s'est donc retrouvé avec des permissions larges, sans double regard, et a tranché pour la solution la plus radicale à sa disposition, supprimer l'environnement entier.
Pour Amazon, la présence de Kiro dans cet incident est une « coïncidence » et n'importe quel outil de développement ou action manuelle aurait pu produire le même résultat. Techniquement, c'est défendable. Un développeur humain avec ces mêmes droits aurait eu à répondre de son choix devant un collègue, tandis que Kiro, lui, n'avait aucun interlocuteur pour valider ou bloquer sa décision.
Il n'empêche, depuis l'incident, AWS a rendu obligatoire l'examen par un pair avant tout accès à la production, une règle qui n'existait pas en décembre. Le tout, suivi d'une formation du personnel, selon Amazon.
L'objectif des 80 % et ce qu'il révèle en interne
Amazon s'est fixé un objectif interne assez précis car elle veut que 80 % de ses développeurs utilisent des outils d'IA pour des tâches de programmation au moins une fois par semaine, avec un suivi régulier des chiffres d'adoption à la clé.
Or, plusieurs employés interrogés par le FT se sont dits sceptiques sur l'utilité réelle de ces outils pour leur travail quotidien, puisque le risque d'erreur leur paraît supérieur au gain de temps. Cette pression sur les chiffres d'adoption explique peut-être pourquoi des ingénieurs ont utilisé Kiro dans des environnements de production avec des droits larges, sans que les procédures de sécurité aient été adaptées à un outil capable d'agir de façon autonome.
AWS, qui vient de lancer son cloud indépendant à destination d'une clientèle européenne, représente 60 % des bénéfices opérationnels d'Amazon, et Andy Jassy, son DG, veut commercialiser ces agents auprès de clients externes au plus vite. Kiro avait pourtant déjà connu des débuts agités, avec un bug de tarification au lancement, une liste d'attente imposée en urgence et des limites d'utilisation introduites face à une demande que l'équipe n'avait pas anticipée
Ces incidents de production renvoient à la panne bien plus grave d'Amazon en octobre dernier, qui avait mis hors ligne plusieurs clients dont Snapchat et Perplexity pendant quinze heures.
Ce que cet épisode révèle concrètement, c'est qu'un outil configuré pour demander la permission avant d'agir peut se retrouver à opérer librement dès lors que les droits de son utilisateur le permettent, et qu'AWS n'avait pas anticipé ce scénario avant que la panne ne survienne.
Source : Financial Times (accès limité), The Register
