Amazon et l'IA agentique : quand le code échappe aux humains
Ce qui se joue chez Amazon depuis quelques semaines dépasse largement l'anecdote technique. C'est un cas d'école, en temps réel, de ce qui arrive quand une organisation pousse l'IA agentique dans ses systèmes critiques sans avoir construit les garde-fous qui vont avec…

Imaginez. Vous êtes ingénieur chez Amazon. Un jeudi après-midi, le site retail tombe. Pas une page d'erreur discrète dans un coin de la plateforme, non. Pendant six heures, des dizaines de milliers d'utilisateurs ne peuvent plus voir les prix, accéder à leur compte, ni finaliser un achat. Le lendemain, un e-mail du SVP Dave Treadwell atterrit dans toutes les boîtes : « the availability of the site and related infrastructure has not been good recently. » C'est le genre de litote qu'on emploie quand la situation est bien pire que ce qu'on peut écrire dans un mail corporate.
Et puis, la semaine suivante, on apprend que la réunion hebdomadaire interne, le TWiST, « This Week in Stores Tech », jusqu'ici facultative pour beaucoup d'ingénieurs, devient obligatoire pour tous. Avec un ordre du jour qui ne laisse aucune ambiguïté : comprendre ce qui s'est passé, et surtout pourquoi ça continue de se passer.
Ce qui se joue chez Amazon depuis quelques semaines dépasse largement l'anecdote technique. C'est un cas d'école, en temps réel, de ce qui arrive quand une organisation pousse l'IA agentique dans ses systèmes critiques sans avoir construit les garde-fous organisationnels qui vont avec.

Que s'est-il vraiment passé chez Amazon ?
Les incidents ne sont pas tombés du ciel. Ils se sont enchaînés sur plusieurs mois, avec une accélération nette en début d'année.
Mi-décembre 2025, l'outil de développement interne Kiro, l'assistant IA maison d'AWS, provoque une interruption de 13 heures sur l'AWS Cost Explorer dans la partition Mainland China. Selon plusieurs ingénieurs AWS cités par le Financial Times, l'agent aurait pris l'initiative de supprimer un environnement de production et de le recréer à partir de zéro, plutôt que d'appliquer la correction incrémentale prévue. Trois employés AWS ont confirmé au FT que les ingénieurs avaient laissé l'IA résoudre le problème sans intervention humaine. Amazon a contesté ce récit dans une réponse publiée le 21 février 2026, attribuant l'interruption à une erreur humaine, des contrôles d'accès mal configurés, et non à l'IA. C'est le premier d'une longue série de démentis.
Peu après, un second incident, moins sévère, impliquant cette fois Amazon Q Developer. Là encore, un changement de code assisté par IA a généré un comportement imprévu en production.
Puis le 5 mars 2026, c'est le retail US qui tombe. La panne débute vers 14 heures, heure de l'Est. Six heures d'indisponibilité. Downdetector enregistre plus de 22 000 signalements au pic avant que le trafic ne se normalise en soirée. Checkout cassé, historique de commandes inaccessible, prix qui ne s'affichent plus. Fortune décompte quatre incidents de forte sévérité sur une seule semaine. La cause officielle invoquée par Amazon : « a software code deployment. »

Ce que dit le mémo interne (et ce qui en a été retiré)
C'est ici que l'affaire devient particulièrement révélatrice.
Un document de briefing préparé pour la réunion TWiST du 10 mars, partagé avec le Financial Times, faisait explicitement référence à une « tendance d'incidents » depuis le troisième trimestre, caractérisée par un « blast radius élevé » et des « Gen-AI assisted changes ». Le texte précisait que les bonnes pratiques et garde-fous autour de ces outils n'étaient « pas encore pleinement établis ».
Mais, et c'est le détail qui en dit le plus sur la politique interne, CNBC rapporte que la mention explicite de GenAI a été supprimée du document avant la réunion. Après la publication de leur article, un porte-parole d'Amazon a déclaré qu'un « seul incident » était lié à l'IA et qu'aucun incident n'impliquait du code écrit par l'IA. Le même porte-parole a ajouté n'avoir vu aucune preuve convaincante que les incidents seraient plus fréquents avec les outils d'IA. L'un des incidents a même été imputé à un ingénieur ayant suivi un conseil erroné qu'un agent avait inféré d'un wiki interne obsolète : une formulation qui range soigneusement la faute du côté humain.
On mesure ici toute la tension entre la réalité opérationnelle et le narratif public. D'un côté, un SVP qui demande à toute la division de comprendre ce qui se passe. De l'autre, une communication corporate qui minimise méthodiquement.

Pourquoi Amazon réintroduit-il de la friction humaine ?
La réponse organisationnelle, elle, est sans ambiguïté. Treadwell a annoncé aux équipes que les ingénieurs juniors et mid-level devront désormais obtenir l'approbation d'un ingénieur senior avant de pousser en production tout changement assisté par GenAI. Dans son message, il évoque l'introduction de « controlled friction » sur les parties les plus critiques de la plateforme retail, en parallèle d'un investissement dans des garde-fous plus durables, à la fois déterministes et agentiques.
En clair : après une phase d'adoption massive et accélérée des outils de développement IA, Amazon réintroduit de la validation humaine là où elle avait été retirée, ou jamais installée.
Le contexte qui rend tout ça systémique
Ces incidents n'arrivent pas dans le vide. Ils surviennent dans un contexte qui amplifie chaque signal.
Depuis octobre 2025, Amazon a supprimé environ 30 000 postes corporate en deux vagues successives, 14 000 en octobre, 16 000 en janvier 2026, affectant AWS, le retail, Prime Video, les ressources humaines. C'est près de 10 % de ses effectifs corporate, et la plus grande vague de licenciements de son histoire. James Gosling, le créateur de Java et ancien distinguished engineer chez AWS, a publiquement déclaré sur LinkedIn qu'après l'explosion du battage autour de l'IA, il avait été « astonished by how the structure of the business got torqued around, and how teams got demolished », des équipes qui ne généraient pas directement de revenus mais qui étaient essentielles à la stabilité de l'infrastructure.
En parallèle, Dave Treadwell revendiquait, sur la scène d'AWS re:Invent 2025, plus de 21 000 agents IA utilisés à travers Amazon, 20 930 selon la diapositive projetée deux jours plus tôt, 2 milliards de dollars d'économies sur l'année 2025, et pour les équipes pilotes de la division Stores une vélocité développeur multipliée par 4,5. Des chiffres suffisamment spectaculaires pour rendre politiquement impossible tout retour en arrière sur l'adoption de l'IA.
On touche ici au cœur du problème. Les outils d'IA n'ont pas été introduits comme un complément. Ils ont été introduits comme un remplacement partiel des humains, et les effectifs ont été réduits en conséquence. Quand les incidents se multiplient, il ne reste plus assez d'ingénieurs seniors pour absorber le volume de review que les nouvelles règles exigent.
Ce que ça signifie pour toutes les organisations
Le cas Amazon est instructif parce qu'il se produit dans l'une des organisations d'ingénierie les plus sophistiquées au monde. Si Amazon, avec ses pipelines de déploiement, ses runbooks, ses mécanismes de rollback automatisés et sa culture du blameless post-mortem, se retrouve à devoir réintroduire de la friction humaine sur ses systèmes critiques après des pannes liées à l'IA, alors la question pour toutes les autres organisations n'est pas « est-ce que ça nous arrivera ? » mais « quand et à quelle échelle ? ».
L'IA agentique est extraordinairement efficace pour générer du code, refactorer des modules, prototyper. Mais dès qu'elle opère sur des systèmes en production avec des dépendances complexes, des logiques métier sensibles, des enjeux de disponibilité ou de revenu direct, elle reste fondamentalement incapable de mesurer les conséquences systémiques de ses propres décisions. Un agent qui supprime un environnement de production pour le recréer, c'est un agent qui a trouvé la solution optimale à un problème local sans aucune compréhension du problème global.
C'est exactement la différence entre écrire du code et comprendre un système.
Quels garde-fous face à l'IA agentique en production ?
Dans mon travail de conseil et d'accompagnement d'équipes techniques, je défends trois principes que le cas Amazon vient valider de façon spectaculaire.
Le premier : aucun code intégralement généré ou fortement modifié par IA ne devrait atteindre un environnement de production critique sans relecture humaine qualifiée. Pas une relecture cosmétique, une relecture par quelqu'un qui comprend le système cible.
Le deuxième : les zones critiques, checkout, pricing, authentification, paiements, gestion d'identité, doivent rester sous validation explicite d'un lead technique ou d'un architecte, quel que soit l'outil utilisé pour produire le changement.
Le troisième : mesurer les vrais indicateurs. Pas la vélocité brute. La vélocité, les bugs en production et le temps de résolution des incidents, ensemble. Quand Amazon annonce un gain de productivité de 4,5x mais enchaîne les pannes de six heures, c'est le signal que le numérateur a été optimisé sans regarder le dénominateur.
Le mot de la fin
On parle beaucoup de l'IA comme pilote automatique. Le cas Amazon rappelle une réalité plus prosaïque : en mars 2026, l'IA est un copilote brillant mais aveugle aux conséquences de ses propres manœuvres. L'organisation qui confond les deux finit avec un avion au sol.
Et dans un avion au sol, ce ne sont jamais les algorithmes qui expliquent la panne aux passagers.
Sources
- Panne du site retail le 5 mars 2026, pic de signalements et cause officielle : Reuters, via Insurance Journal, 6 mars 2026.
- Réunion TWiST, mémo interne et mention de GenAI retirée, approbation par un senior : CNBC, 10 mars 2026.
- « Blast radius élevé », « Gen-AI assisted changes », cause officielle et réaction d'Amazon : The Register, 10 mars 2026.
- Quatre incidents de forte sévérité, conseil erroné inféré d'un wiki obsolète et « controlled friction » : Fortune, 12 mars 2026.
- Interruption de 13 heures sur AWS Cost Explorer via l'agent Kiro et démenti d'Amazon du 21 février 2026 : AI Incident Database, incident 1442.
- Approbation obligatoire d'un ingénieur senior avant tout déploiement assisté par IA : TechRadar, mars 2026.
- Suppression d'environ 30 000 postes corporate (14 000 en octobre 2025, 16 000 en janvier 2026) : Reuters, via Yahoo Finance, janvier 2026.
- Déclaration de James Gosling sur la démolition des équipes : James Gosling, LinkedIn.
- Plus de 21 000 agents IA (20 930 sur la diapositive), 2 milliards de dollars d'économies en 2025 et vélocité multipliée par 4,5, présentés par Dave Treadwell : AWS re:Invent 2025, session INV211.
Questions fréquentes
Qu'est-ce que l'IA agentique et en quoi diffère-t-elle d'un simple assistant de code ?
Un assistant de code propose des suggestions qu'un humain valide avant de les appliquer. Une IA agentique va plus loin : elle exécute des actions de façon autonome, comme déployer un changement ou, dans le cas de l'agent Kiro chez AWS, supprimer puis recréer un environnement de production. C'est cette autonomie qui déplace le risque des erreurs de saisie vers les conséquences systémiques.
Que s'est-il passé chez Amazon en mars 2026 ?
Le site retail US d'Amazon est resté indisponible environ six heures le 5 mars 2026, avec un pic de plus de 22 000 signalements sur Downdetector avant retour à la normale en soirée. Amazon a invoqué « a software code deployment » comme cause officielle. Fortune décompte quatre incidents de forte sévérité sur une seule semaine.
Qu'est-ce que l'agent Kiro et qu'a-t-il fait ?
Kiro est l'assistant de codage IA maison d'AWS. Mi-décembre 2025, selon le Financial Times, il aurait supprimé puis recréé un environnement de production, provoquant une interruption d'environ 13 heures sur AWS Cost Explorer dans la partition Mainland China. Amazon a contesté ce récit le 21 février 2026, l'attribuant à une erreur humaine et à des contrôles d'accès mal configurés, non à l'IA.
L'IA est-elle vraiment en cause dans ces pannes ?
Plusieurs incidents sont liés à des changements assistés par GenAI. Amazon a publiquement déclaré qu'un seul incident était lié à l'IA, qu'aucun n'impliquait du code écrit par l'IA, et n'avoir vu aucune preuve convaincante que les incidents seraient plus fréquents avec les outils d'IA. Un mémo interne, lui, faisait état d'une tendance d'incidents à blast radius élevé associée à des changements GenAI.
Quelle mesure organisationnelle Amazon a-t-il prise ?
Les ingénieurs juniors et mid-level doivent désormais obtenir l'approbation d'un ingénieur senior avant de pousser en production tout changement assisté par GenAI. Treadwell parle d'introduire une « controlled friction » sur les parties les plus critiques de la plateforme, et d'investir dans des garde-fous à la fois déterministes et agentiques.
Les suppressions de postes aggravent-elles le risque ?
Oui. Amazon a supprimé environ 30 000 postes corporate entre octobre 2025 et janvier 2026, soit près de 10 % de ses effectifs corporate. James Gosling, créateur de Java et ancien distinguished engineer d'AWS, a dénoncé la démolition d'équipes essentielles à la stabilité de l'infrastructure. Résultat : trop peu de seniors pour absorber la charge de relecture que les nouvelles règles exigent.
Quels garde-fous l'auteur recommande-t-il pour les autres organisations ?
Trois réflexes : relecture humaine qualifiée de tout code généré ou fortement modifié par IA avant la production critique ; validation explicite par un lead ou architecte sur les zones sensibles (checkout, pricing, authentification, paiements, identité) ; et mesure des vrais indicateurs en combinant vélocité, bugs en production et temps de résolution des incidents.
Sources & méthodologie
- Financial Times
- CNBC
- The Register
- Fortune
- James Gosling (déclaration publique sur LinkedIn)

Être en cybersécurité
Une feuille de route cyber en clair, pour tout le monde, pas seulement les experts.
