Après des pannes à répétition, Amazon impose l’approbation d’ingénieurs seniors pour les modifications de code assistées par l’IA

• Face à une série récente de pannes de service liées à l’utilisation d’outils de codage IA, Amazon a mis en place une procédure d’approbation préalable par un ingénieur senior pour toute modification de code assistée par l’IA
• Selon une note interne, la cause des incidents serait liée à de « nouveaux usages de la GenAI dont les bonnes pratiques et garde-fous ne sont pas encore totalement établis »
• Ce mois-ci, le site web d’Amazon et son application de shopping ont été hors service pendant environ 6 heures, empêchant les clients de finaliser des transactions, consulter les informations de leur compte ou vérifier les prix, à cause du déploiement d’un code logiciel erroné
• Côté AWS, l’assistant de codage IA Kiro a lui aussi provoqué une panne de 13 heures en supprimant puis recréant un environnement, parmi au moins deux incidents liés à l’IA signalés
• Le risque opérationnel lié à l’usage d’outils de codage IA en production s’étant concrétisé, une mesure immédiate impose désormais aux ingénieurs junior et de niveau intermédiaire d’obtenir la validation d’un ingénieur senior pour tout changement assisté par l’IA

---

Réunion interne chez Amazon et mesures de réponse

• La division e-commerce d’Amazon a convoqué une grande réunion d’ingénierie pour analyser les interruptions de service successives survenues récemment
  • L’ordre du jour comprenait des incidents liés à l’utilisation d’outils de codage IA
  • Une note de briefing interne indique qu’au cours des derniers mois, les incidents à « haut rayon d’impact (high blast radius) » se sont multipliés, et que les « modifications assistées par Gen-AI » ont été citées comme facteur majeur
• Le document précise que des « cas d’usage GenAI nouveaux, pas encore totalement établis » ont été identifiés comme facteur contributif
• Dans un e-mail, le vice-président senior Dave Treadwell a déclaré que « la disponibilité récente du site et de l’infrastructure n’avait pas été bonne »

Exemples de pannes liées à l’IA

• Le site web d’Amazon et son application de shopping ont subi une interruption d’environ 6 heures au début du mois, due à un « déploiement de code logiciel erroné »
  • Les clients n’ont alors pas pu finaliser leurs achats, consulter les informations de leur compte ni vérifier le prix des produits
• Un autre problème est également survenu chez AWS lors de l’utilisation de l’assistant de codage IA Kiro
  • Mi-décembre, Kiro a décidé de « supprimer puis recréer » un environnement, provoquant une interruption de 13 heures du service de calcul des coûts
  • Amazon a décrit cet incident comme un « événement très limité, cantonné à un seul service dans certaines zones de Chine continentale »
  • Amazon a ajouté que le second incident « n’avait eu aucun impact sur les services AWS destinés aux clients »

Nouvelle procédure d’approbation et amélioration opérationnelle

• Treadwell prévoit de discuter des causes des problèmes et des mesures correctives à court terme lors de la réunion hebdomadaire « This Week in Stores Tech (TWiST) »
  • Cette réunion, auparavant facultative, est désormais fortement recommandée à l’ensemble du personnel
• Désormais, toute modification de code assistée par l’IA effectuée par des ingénieurs junior ou de niveau intermédiaire devra être approuvée et signée par un ingénieur senior
• Amazon présente cette revue comme faisant partie « du cours normal des activités » et affirme viser une amélioration continue

Polémique sur les réductions d’effectifs et la hausse des incidents

• Le Financial Times rapporte que certains ingénieurs estiment que les incidents de niveau « Sev2 » — des pannes intermédiaires nécessitant une réponse rapide — ont augmenté après les réductions d’effectifs
• Amazon a mené plusieurs vagues de restructuration ces dernières années et a supprimé 16 000 postes corporate rien qu’en janvier 2026
• L’entreprise rejette toutefois l’idée que les réductions d’effectifs soient à l’origine de l’augmentation des pannes

Orientation future

• Amazon formalise des revues régulières de la disponibilité de son site web et de ses performances opérationnelles
• L’entreprise poursuit en parallèle le renforcement de l’usage sûr des outils de codage IA et des dispositifs de prévention des pannes
• Cette décision est perçue comme un exemple qui remet en lumière l’importance des procédures de vérification humaine à mesure que l’adoption de l’IA s’accélère

[click]

Le fait qu’un senior relise du code généré par l’IA ne garantit pas que ce soit sûr.
L’incident CrowdStrike n’était pas dû à l’IA,
et Heartbleed aussi date d’une époque où l’IA n’existait pas.

Au fond, l’essentiel est qu’on veut pouvoir faire porter la responsabilité à quelqu’un,
et ça me rappelle l’humour noir de ces experts-comptables qui disaient que, puisqu’il faut qu’un humain soit juridiquement responsable, nous ne serons pas remplacés.

[sea715]

Oui, c’est ça, donc à moins d’intégrer une sorte de signature légale aux agents IA, j’ai l’impression que ça va continuer…

[click]

Alors les coûts d’utilisation d’Anthropic ou d’OpenAI vont devoir devenir astronomiquement élevés
Il faudra payer une prime d’assurance à chaque appel d’API

[sea715]

Hum... c'est peut-être une élucubration, mais j'ai l'impression qu'il pourrait se passer quelque chose du genre d'IAM...

[yeobi222]

On disait que l’expert-comptable était celui qui allait en prison, mais comme l’assureur n’ira pas en prison à sa place, au final...

[GN⁺]

Commentaires sur Hacker News

• Cette « mandatory meeting » est en fait la réunion opérationnelle hebdomadaire à l’échelle de toute l’entreprise
  La participation est simplement plus élevée cette semaine parce qu’il y a eu un gros incident opérationnel la semaine dernière
  J’ai l’impression que les médias exagèrent beaucoup

  • Quand on connaît la situation en interne, la couverture médiatique donne toujours une impression très différente de la réalité
  • L’article disait que « d’habitude la participation est facultative, mais que cette fois il y a eu une demande de présence » ; je me demande si c’est vrai
    Il mentionnait aussi la politique selon laquelle les modifications de code faites avec l’IA par des ingénieurs junior et intermédiaires nécessitent l’approbation d’un senior
    Même s’il s’agit d’une réunion régulière, je pense que l’annonce d’une nouvelle politique a une vraie valeur d’actualité
  • À New York, la vitrine Amazon est restée en panne tout l’après-midi de vendredi dernier
    Les prix ne s’affichaient pas et il était impossible d’ajouter des articles au panier
    Si cela avait été un concurrent comme Walmart, cela aurait fait la une, donc c’est étrange
  • Ce fil semble avoir été fusionné avec un autre post au titre différent. Les horaires des commentaires sont bien antérieurs à ceux du post d’origine
  • Je suis d’accord avec l’idée que « les médias exagèrent ». C’est comme ça depuis l’apparition des chaînes d’info en continu

• La politique selon laquelle « les ingénieurs junior et intermédiaires ne peuvent pas pousser de code IA sans approbation d’un senior »
  semble partir de l’illusion qu’une review par un senior est une solution universelle
  En pratique, si un senior veut valider complètement le code, cela lui prend à peu près autant de temps que de l’écrire lui-même
  Autrement dit, la review a de la valeur, mais elle ne transforme pas du mauvais code en bon code
  Au fond, le problème, c’est que lorsqu’on construit un système « idiot proof », on finit par croire qu’on peut embaucher des idiots

  • Au début de ma carrière, un mentor m’a dit que « la revue de code ne sert pas à traquer les bugs, mais à partager le contexte »
    Détecter des bugs n’est qu’un effet secondaire ; le plus important, c’est de rendre les tests plus simples et de réduire la complexité du code
    Mais ce genre de travail n’aide pas à obtenir une promotion
  • Si on veut que le code produit par l’IA soit exploitable, une review par un expert est indispensable
    Il faut superviser le modèle pendant qu’il travaille pour que ce soit efficace
    Sinon, l’IA déverse une bombe de code de mauvaise qualité
    Si un expert passe 5 à 15 fois plus de temps à corriger, ça peut aller, sinon la base de code se dégrade
  • Relire le code de quelqu’un d’autre est souvent plus lent et plus confus que de l’écrire soi-même
    Surtout quand le code est mauvais, le temps nécessaire pour le comprendre explose
  • J’ai l’impression que corriger du code bâclé est plus difficile que réécrire à neuf
    Il faut garder simultanément en tête l’existant et la nouvelle solution, ce qui crée une forte charge cognitive
  • Si l’IA multiplie par 10 la productivité des juniors, il faut alors se demander s’il faut multiplier le nombre de seniors par 10 ou réduire le nombre de juniors
    Au final, cela ressemble à une évolution naturelle vers des entreprises centrées sur la gestion de la performance moyenne

• En interne chez Amazon, la plupart des gens ne pensent qu’à ne pas se faire licencier et à être promus
  L’évaluation des développeurs se fait sur « la vitesse de traitement des tickets », « le nombre de commentaires sur les PR » et « la rédaction de documentation »
  Si on n’utilise pas l’IA, on est désavantagé dans la compétition
  Dans une telle structure, demander de « limiter l’usage de l’IA » est difficilement applicable en pratique

  • On est pénalisé aussi bien s’il y a trop de commentaires sur sa PR que si l’on ne laisse pas de commentaires sur les PR des autres
  • Beaucoup de discussions sur une PR peuvent aussi signaler qu’on a travaillé seul sans collaboration
    Plus une équipe collabore bien, moins il y a de discussions sur les PR
  • Conclusion : il ne faut pas travailler dans une culture de compétition façon Hunger Games

• Je pense que ce qu’il faut vraiment, c’est un processus de self-review
  Pousser tel quel du code généré par l’IA est dangereux
  Il faudrait ajouter sur des plateformes comme GitHub une option « self-review obligatoire » pour que l’auteur indique explicitement qu’il a relu lui-même son travail

  • Se contenter de parcourir rapidement la sortie de l’IA, ce n’est pas une review. Il faut un niveau de compréhension à la grok au sens de Heinlein
  • J’utilise git et Sublime Merge, et j’ai pris l’habitude de séparer l’édition et la review
    Comme l’interface locale est rapide, cela aide à mieux suivre le flux du projet
  • Ajouter un bouton de plus ne sert à rien pour ceux qui ne lisent déjà pas leur propre code
  • Une self-review permet déjà d’attraper des erreurs comme des sorties de debug laissées par mégarde
  • Notre équipe a ajouté une checklist de self-review dans le template de PR
    Ça paraît évident, mais en pratique c’est utile

• La crédibilité du leadership d’Amazon est en train de s’éroder
  Entre le départ des vétérans, la baisse de qualité liée à l’IA et les pannes répétées, on a l’impression que l’ingénierie se délite

  • Il est naturel que des seniors expérimentés n’aient pas envie de passer leur temps à ne faire que de la review de code IA

• On dirait que les décideurs ne comprennent pas les goulots d’étranglement du pipeline
  Même si l’IA produit des diff 10 fois plus vite, si la review reste le goulot, la vitesse globale ne change pas
  Au final, cela ne fait qu’augmenter les coûts et l’incertitude

  • La prochaine étape sera sans doute l’idée de faire « relire du code IA par une autre IA »

• Si la review du code IA se fait au stade de la PR, l’avantage de productivité disparaît
  L’IA peut produire une fonctionnalité en 10 minutes, mais une review humaine prend 10 à 20 fois plus de temps
  La vraie difficulté, c’est de savoir « quoi construire et pourquoi » et « si cela a été correctement construit »
  L’IA ne sait toujours pas faire ces deux choses

  • Du point de vue d’un CEO, si au final un humain doit tout relire, l’avantage de vitesse de l’IA devient sans intérêt
    Tant que les LLM ne sont pas bons à la fois en production et en review, le risque ne fait qu’augmenter
  • Si les seniors doivent approuver toutes les PR, ils deviennent en pratique des relecteurs de code à plein temps
    C’est une politique irréaliste
  • Les partisans de l’IA pensent qu’un jour les modèles s’amélioreront et que le goulot de la review disparaîtra
    Selon eux, on passera alors à une époque où l’on déploiera juste après les tests
  • Il est surprenant que le leadership ne voie pas cette réalité
  • En fait, le leadership le sait probablement aussi. C’est simplement un frein pour éviter une dégradation de la qualité du code

• L’essence même de la revue de code n’est pas la détection d’erreurs, mais la synchronisation de l’équipe et l’apprentissage
  La review permet de partager les choix de conception et les standards, de former les juniors et d’intégrer des points de vue variés
  C’est ce processus qui réduit vraiment les erreurs à la source

  • Comme le disait Deming, le principe selon lequel « l’inspection n’améliore pas la qualité » s’applique aussi au logiciel
    Parce qu’une fois engagé dans une mauvaise direction de conception, il est difficile de revenir en arrière

• On consacre beaucoup trop de temps et d’argent à la vague IA

  • Mais pour l’instant, il n’y a rien d’autre à poursuivre
  • Ne pas vérifier le code revient au fond à jouer aux dés

• Je m’inquiète pour l’avenir des logiciels d’infrastructure critiques
  Si même les logiciels aéronautiques se laissent emporter par cette tendance, les conséquences pourraient être catastrophiques

  • Malgré tout, le code des infrastructures critiques continuera sans doute à être écrit de manière centrée sur l’humain
    L’IA sera probablement utilisée comme outil d’assistance pour améliorer la qualité