"C'est pas moi, c'est l'IA" : après des pannes en cascade, Amazon impose la supervision humaine sur son code IA

Vibe debugging is the new vibe coding — Le 5 mars dernier, Amazon.com s'est retrouvé hors-jeu pendant près de six heures.

Paiement cassé, connexion à son compte client impossible, affichage des prix complètement, Amazon Fresh (son service de livraison de courses) à l'arrêt : du beau monde côté dégâts, avec pas moins de 21 000 signalements sur Downdetector au pic de l'incident.

La cause officielle communiquée par Amazon ? "Un déploiement de code logiciel." Classique, me direz-vous.

Sauf qu'un mémo interne du géant du e-commerce récemment fuité va un peu plus loin dans l'explication, en pointant des "genAI-assisted changes" comme facteur contributif à une série d'incidents en chaîne depuis le troisième trimestre 2025. Le paragraphe en question a depuis été discrètement supprimé du document.

La faute à qui ? La faute à Kiro !

Kiro, c'est l'assistant de coding interne d'Amazon. Et ce n'est pas la première fois qu'il se distingue de la sorte : en décembre 2025, lors d'une panne touchant les services AWS, il avait tout simplement supprimé puis recréé l'environnement. En production, tout seul comme un grand, et surtout sans qu'on le lui demande. Pas mal, non ?

Amazon, de son côté, a une formulation plus "diplomatique" pour décrire ce fail d'un genre nouveau : le Financial Times rapporte que ces incidents sont désignés en interne comme une utilisation "novatrice" de l'IA générative, pour laquelle les bonnes pratiques et les garde-fous ne seraient "pas encore totalement établis". 👀 Traduction courtoise d'un constat assez brutal : on a poussé des outils IA en production avant d'avoir le mode d'emploi.

Ce qui donne une saveur toute particulière à l'affaire, c'est que le mémo de mise en garde a été signé par Dave Treadwell, SVP en charge des fondations techniques d'Amazon.com. Le même Dave Treadwell qui, en novembre 2025, avait lui-même imposé à ses équipes l'adoption de la solution Kiro pour accélérer leur production de code via l'IA générative.

Quand l'architecte de l'accélération IA devient le pompier de ses propres incendies, c'est au moins cohérent.

Le code review, ce truc révolutionnaire

La réponse opérationnelle d'Amazon tient en une ligne : tout code généré avec assistance IA par un ingénieur junior ou mid-level devra désormais être validé par un senior avant tout déploiement en production.

Ce qui n'est rien d'autre que, disons-le bien (roulements de tambours), une revue de code.

Quelque chose qui existait déjà donc, mais que la pression à l'adoption IA avait visiblement contribué à effacer (voire à faire complètement disparaître). Quand un assistant de code peut produire dix fois plus de pull requests qu'un humain, le processus de relecture devient rapidement un goulot d'étranglement. Et dans ces conditions, certains ont choisi la vitesse.

Que l'on ne s'y méprenne pas : Amazon est loin d'être un cas isolé. D'autres boîtes vivent actuellement les mêmes tensions, sans avoir encore eu le loisir de savourer leur moment Downdetector.

Prod is not a sandbox

Le géant américain nie toujours publiquement que l'IA soit en cause. Ce qui ne les a pas empêchés d'imposer en urgence du code review sur tous les changements assistés par IA (hum).

Ce qui est moins drôle, c'est que ce scénario, certains l'avaient annoncé. Après une panne AWS à l'automne dernier, James Gosling — le créateur de Java, qui a quitté AWS en 2024 — écrivait que des équipes entières avaient été sacrifiées au nom du sacro-saint ROI de l'IA, sans que personne ne mesure réellement ce qu'elles maintenaient.

Ces systèmes sont des structures complexes et interdépendantes : toucher à une brique sans comprendre l'ensemble, c'est jouer à Jenga avec une infra critique.

Depuis, les suppressions de postes se sont poursuivies chez Amazon, officiellement justifiées par la transformation IA. La direction est claire, les garde-fous un peu moins.

Le vibe coding peut avoir toute sa place sur un prototype ou un side project. En production, chez un acteur dont les pannes se mesurent en dizaines de millions de dollars par heure, le "ça devrait marcher" n'est pas la stratégie de déploiement idéale.

Adopter l'IA trop lentement, c'est prendre le risque de se faire distancer. L'adopter trop vite (et mal), c'est prendre le risque de se faire exploser de l'intérieur. De son côté, Amazon a commencé à régler le curseur un peu trop tard.