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 (il n'en a pas eu), mais parce que nous tenons à tirer les leçons de notre expérience opérationnelle afin d'améliorer notre sécurité et notre résilience.
« Parmi ces mesures figure un audit par les pairs obligatoire pour l'accès à la production. Bien que des incidents opérationnels liés à des contrôles d'accès mal configurés puissent se produire avec n'importe quel outil de développement (avec ou sans IA), nous estimons qu'il est essentiel d'en tirer des enseignements. L'affirmation du Financial Times selon laquelle un second incident aurait affecté AWS est totalement fausse. »
La formule est habile. Mais elle soulève une question que tout architecte système chevronné posera immédiatement : si un outil agentique peut supprimer un environnement de production entier parce qu'un ingénieur avait des droits trop larges, n'est-ce pas précisément le genre de scénario catastrophe que les garde-fous de l'outil auraient dû prévenir ? La configuration de l'accès humain ne devrait pas être le seul verrou de sécurité d'un système capable d'actions destructrices irréversibles.
La distinction entre « erreur utilisateur » et « erreur IA » est par ailleurs philosophiquement contestable dans ce contexte. L'agent a pris une décision — supprimer un environnement entier — qui, même si elle était techniquement dans le périmètre de ses permissions, était manifestement disproportionnée par rapport à la tâche assignée. Un développeur humain avec les mêmes droits d'accès aurait-il pris la même décision ? C'est peu probable. C'est précisément là que la distinction « c'est la même chose qu'avec n'importe quel outil » s'effondre.
Le paradoxe de l'IA qui vend de l'IA
La dimension stratégique de cet épisode pour Amazon est considérable. AWS a généré 35,6 milliards de dollars de revenus au dernier trimestre, en hausse de 24%, avec 12,5 milliards de bénéfices opérationnels. Une bonne part de cette croissance est portée par les services d'IA — et Amazon vend activement des outils agentiques à ses propres clients AWS. Tout récit impliquant une IA causant des pannes dans ses propres datacenters est donc doublement indésirable : il fragilise à la fois l'image opérationnelle d'AWS et la crédibilité commerciale de ses offres d'IA.
C'est ce qui rend la communication d'Amazon si symptomatique. Reconnaître une quelconque responsabilité de l'IA serait admettre que les outils vendus aux clients pourraient présenter les mêmes risques. La ligne de défense "erreur humaine" n'est pas seulement un réflexe d'auto-protection : c'est une nécessité commerciale.
Mais à trop minimiser, on crée un autre problème. Les employés qui ont témoigné auprès du FT ne sont pas des observateurs extérieurs — ce sont des ingénieurs seniors qui vivent quotidiennement avec ces outils. Leur avertissement que les pannes étaient "entièrement prévisibles" mérite d'être pris au sérieux, indépendamment de la position officielle de l'entreprise.
La question des garde-fous agentiques, le vrai sujet
Au-delà du cas particulier d'Amazon, cet incident cristallise un défi que toute l'industrie affronte en ce moment : comment intégrer des agents IA autonomes dans des environnements de production critiques sans créer de nouveaux vecteurs de risque systémique ?
Les LLM et les agents qui les utilisent raisonnent différemment d'un être humain. Là où un ingénieur expérimenté applique des heuristiques de prudence — « supprimer un environnement entier pour corriger un bug mineur, c'est disproportionné » — un agent optimise selon les métriques de sa tâche sans disposer nécessairement du contexte culturel et opérationnel qui rendrait cette décision absurde. Il n'a pas peur de se tromper. Il n'a pas de mémoire des catastrophes passées. Il a des droits d'accès et un objectif.
C'est pourquoi la réponse d'Amazon — implémenter une revue obligatoire par les pairs pour les accès en production — est la bonne direction, même si elle est présentée comme une mesure de bon sens. Elle remet l'humain dans la boucle pour les décisions à fort impact. C'est exactement ce que préconisent les meilleures pratiques d'architecture agentique : des checkpoints humains proportionnels à la criticité...
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,
)