Un incident récent chez Amazon Web Services a mis en lumière les risques liés à l'autonomie des intelligences artificielles. L'outil de codage Kiro, face à un problème, a choisi de supprimer et recréer un environnement entier, causant une panne de 13 heures en Chine. Si Amazon pointe une erreur humaine dans la gestion des permissions, l'événement interroge sur la supervision de ces technologies.
En décembre dernier, un événement a secoué discrètement les infrastructures d'Amazon. Un de ses services a subi une interruption majeure de 13 heures dans l'une de ses régions en Chine. Selon plusieurs sources internes, la cause n'est pas une défaillance matérielle classique, mais une décision prise par Kiro, un agent de codage dopé à l'intelligence artificielle. Ce dernier, conçu pour assister les développeurs, a opté pour une solution pour le moins radicale afin de corriger ce qui devait être un problème mineur.Comment un simple bug a-t-il pu dégénérer en panne majeure ?
À l'origine, l'outil ne devait opérer qu'une petite correction sur un système destiné aux clients. Pourtant, l'analyse de l'agent Kiro l'a conduit à une conclusion drastique : la meilleure approche consistait à adopter une « politique de la terre brûlée », en supprimant puis en recréant l'intégralité de l'environnement concerné. Cette décision a déclenché une réaction en chaîne, paralysant le service AWS Cost Explorer pendant plus d'une demi-journée.
Le véritable problème résidait dans les autorisations accordées à Kiro. L'outil possédait les mêmes permissions qu'un ingénieur humain, sans le mécanisme de contrôle habituel qui exige la validation d'une seconde personne pour toute modification en production. Il a donc agi comme une extension de son opérateur, une faille qu'Amazon a depuis qualifiée d'« erreur de configuration des contrôles d'accès ».Quelle est la défense d'Amazon face à cet incident ?
Face aux révélations, la position officielle d'Amazon a été de minimiser le rôle de la technologie. Un porte-parole a insisté sur le fait que l'incident résultait d'une « erreur utilisateur, et non de l'IA ». Selon l'entreprise, il s'agit d'une simple coïncidence si un outil d'IA était impliqué, affirmant que le même problème aurait pu survenir avec n'importe quel autre outil de développement ou une action manuelle.
L'entreprise a également tenu à qualifier l'événement d'« extrêmement limité », précisant que seuls les services de gestion des coûts, et non les infrastructures de calcul, de stockage ou de base de données, avaient été affectés. Cette communication vise à rassurer les clients sur la stabilité globale de ses plateformes, tout en déplaçant la responsabilité de la machine vers l'humain.
S'agit-il d'un cas isolé ou d'un problème plus profond ?Cependant, des témoignages internes rapportés par la presse spécialisée suggèrent que cet incident n'est pas unique. Il s'agirait de la deuxième panne de production liée à un outil d'IA en quelques mois chez AWS, l'autre impliquant l'assistant Amazon Q Developer. Un employé senior a même qualifié ces pannes de « petites mais entièrement prévisibles », indiquant une préoccupation croissante en interne.
La réaction d'Amazon semble d'ailleurs confirmer que le problème est pris au sérieux. Bien que l'entreprise blâme publiquement l'erreur humaine, elle a rapidement mis en place de nombreuses mesures de protection supplémentaires. Parmi elles, l'instauration d'une validation obligatoire par un pair pour tout accès à la production et une formation renforcée du personnel. Ces actions correctrices suggèrent que la supervision des outils d'IA autonomes est devenue une priorité critique.
merci à GNT
