En décembre 2025, un outil d'IA développé en interne par Amazon a provoqué une panne de 13 heures sur AWS en décidant, de sa propre initiative, de supprimer et recréer l'environnement de production qu'il était censé corriger. Une mésaventure révélatrice des tensions entre la course à l'automatisation, le contrôle humain et la communication corporative — et qui pose des questions fondamentales sur le déploiement des agents IA en production.L'histoire commence de façon banale : des ingénieurs d'Amazon Web Services confient à Kiro, le nouvel outil de développement agentique maison, la tâche de résoudre un problème mineur dans AWS Cost Explorer — le service qui permet aux clients de visualiser et gérer leurs dépenses cloud. Rien de dramatique en apparence. Kiro est précisément conçu pour ce genre d'interventions : analyser une situation, proposer une solution, agir de manière autonome.
Sauf que l'IA a fait quelque chose de plus... radical. Selon quatre sources ayant directement connaissance des faits, rapportées par le Financial Times, Kiro a déterminé que la solution optimale consistait à supprimer intégralement l'environnement et à le recréer de zéro. Résultat : 13 heures de panne. Un service AWS affecté pendant plus d'une demi-journée, dans l'une des 39 régions géographiques du géant du cloud, la Chine continentale.
Ce serait déjà suffisamment préoccupant pris isolément. Mais des employés d'Amazon ont confié au FT qu'il s'agissait là d'au moins le deuxième incident de ce type en quelques mois impliquant des outils d'IA internes. Un employé senior d'AWS, s'exprimant sous couvert d'anonymat, a déclaré sans ambages que les perturbations étaient « entièrement prévisibles », ajoutant que les ingénieurs avaient laissé l'agent IA résoudre un problème « sans intervention humaine ». Un deuxième incident aurait impliqué Amazon Q Developer, l'assistant de codage précédent.
La montée en puissance de Kiro et d'une culture de l'adoption forcée
Kiro n'est pas un projet expérimental confiné à un laboratoire de recherche. Amazon l'a lancé en juillet 2025 et a depuis activement poussé ses équipes d'ingénierie à l'adopter. La direction a fixé un objectif ambitieux : 80 % des développeurs devaient utiliser un outil d'IA au moins une fois par semaine pour leurs tâches de codage, et les taux d'adoption étaient étroitement surveillés.
C'est là que réside peut-être le vrai problème de fond. Kiro est dit « agentique », c'est-à-dire capable de prendre des actions autonomes au nom de l'utilisateur, sans nécessiter une validation humaine à chaque étape. C'est précisément ce qui en fait un outil puissant — et potentiellement dangereux dans un environnement de production critique. La différence entre un copilote qui suggère du code et un agent qui l'exécute directement est un gouffre que l'industrie commence à peine à mesurer.
Selon les informations recueillies, plusieurs employés d'Amazon se montrent eux-mêmes sceptiques quant à l'utilité des outils d'IA pour la majorité de leur travail, précisément en raison du risque d'erreurs. Cette résistance interne contraste fortement avec la pression institutionnelle à l'adoption. On a ainsi le tableau classique d'une organisation qui déploie une technologie plus vite que ne l'assimile la culture de prudence nécessaire à son encadrement.
La réponse d'Amazon, ou l'art du gaslighting corporatif
Face à l'onde de choc médiatique, AWS a publié un billet de blog au titre explicite : « Correcting the Financial Times report about AWS, Kiro, and AI » (Correction de l'article du Financial Times concernant AWS, Kiro et l'IA). Le ton est ferme, la posture défensive.
La thèse centrale d'Amazon se décline en trois axes. Premièrement, l'incident de décembre était « extrêmement limité » et ne concernait qu'un seul service dans une seule région, sans aucun client affecté visiblement. Deuxièmement, la société affirme que le problème découlait d'un rôle mal configuré — « le même problème qui pourrait survenir avec n'importe quel outil de développement, qu'il soit alimenté par l'IA ou non, ou avec une action manuelle. » Troisièmement, Amazon nie formellement l'existence d'un second incident ayant impacté AWS, qualifiant cette affirmation du FT de « totalement fausse ».
Amazon a également précisé que par défaut, l'outil Kiro « demande une autorisation avant d'entreprendre toute action », mais que l'ingénieur impliqué dans l'incident de décembre disposait de « permissions plus larges que prévu — un problème de contrôle d'accès utilisateur, pas un problème d'autonomie de l'IA. »
« L'incident survenu en décembre dernier était extrêmement limité et n'a affecté qu'un seul service (AWS Cost Explorer, qui permet aux clients de visualiser, comprendre et gérer les coûts et l'utilisation d'AWS au fil du temps) dans l'une de nos 39 régions géographiques à travers le monde. Il n'a eu aucun impact sur les ressources de calcul, de stockage, de base de données, les technologies d'IA, ni sur aucun autre des centaines de services que nous exploitons.
« Le problème provenait d'un rôle mal configuré, un problème qui peut survenir avec n'importe quel outil de développement (avec ou sans IA) ou suite à une action manuelle. Nous n'avons reçu aucune demande de renseignements de la part de nos clients concernant cette interruption. Nous avons mis en place de nombreuses mesures de protection pour éviter qu'un tel incident ne se reproduise, non pas parce qu'il a eu un impact important...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par jnspunk
à tous,
La revue obligatoire par un senior est-elle une réponse suffisante, ou Amazon ne fait-il que déplacer le problème sans résoudre la tension fondamentale entre réduction d'effectifs et exigences de qualité ?