Amazon et l'IA agentique : quand le code échappe aux humains

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.

La séquence des faits

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.

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. Six heures d'indisponibilité. Plus de 22 000 signalements sur Downdetector au pic de la panne. Checkout cassé, historique de commandes inaccessible, prix qui ne s'affichent plus. 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.

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.

La décision qui change la donne

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. 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, Amazon revendiquait le déploiement de 21 000 agents IA au sein de sa division Stores, avec des économies annoncées de 2 milliards de dollars et 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.

Les trois réflexes que je recommande

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.