> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2025/w43-lessons-learned-from-the-aws-incident.md).

# W43-Les leçons de l'incident AWS

La semaine dernière, AWS a subi une panne majeure de quinze heures. Plus de mille entreprises dans le monde ont connu des interruptions, pour plusieurs milliards de dollars de pertes. J'en retiens une leçon profonde : la conception la plus ingénieuse ne résiste pas à une dépendance unique.

L'incident a touché us-east-1, la région la plus critique d'AWS. Une condition de course dans l'automatisation de la gestion DNS de DynamoDB a effacé par erreur les enregistrements IP du point d'accès régional, empêchant sa résolution. us-east-1 n'est pas un centre de données ordinaire. C'est le système nerveux central de l'infrastructure mondiale d'AWS. Les plans de contrôle communs de presque toutes les régions en dépendent, notamment des services essentiels comme l'ordonnancement EC2, NLB et Lambda, d'où l'effondrement en cascade.

Ironie supplémentaire, soixante-quinze minutes après le début, la page d'état d'AWS indiquait encore que tout allait bien. CloudWatch dépendant lui aussi de DynamoDB, la supervision était devenue aveugle.

Le rétablissement n'a pas été simple. Les enregistrements DNS pouvaient être réparés vite, mais DynamoDB est un point central de contrôle. L'ordonnanceur EC2 devait reconstruire les baux de dizaines de milliers de serveurs, le gestionnaire réseau résorber la congestion et distribuer les états retardés, et les répartiteurs de charge excluaient sans cesse des instances dont ils évaluaient mal la santé. AWS a finalement dû désactiver les contrôles de santé automatiques et le basculement. L'intervention humaine a empêché les avalanches répétées.

Après avoir observé cet incident, regardons nos services. Les dépendances uniques systémiques risquent surtout de se cacher dans les services fondamentaux qui reçoivent peu d'attention lors des évolutions métier : points d'entrée des services numériques ou services de vérification, par exemple. Le premier a une logique simple, mais un rayon d'impact énorme puisqu'il contrôle 80 % du trafic. Sa conception devrait suivre les principes de dépendances minimales et d'entropie maximale, en restant extrêmement claire et simple.

Ce petit composant attire les ingénieurs ambitieux, car ses défis sont visibles : maintenir plusieurs versions pour plusieurs piles techniques, avec des cycles de publication longs dépendant des pages hôtes. En regardant ce que nous avons fait cette année, je pense qu'il faut vérifier si nous avons choisi la bonne direction. Pour permettre les mises à jour dynamiques, raccourcir les cycles métier et assouplir les publications, nous avons beaucoup travaillé, ajouté des dépendances, complexifié l'architecture et ralenti la prise d'effet des retours arrière. Dans cette logique, l'étape suivante pourrait être un composant dynamique commun à tous les conteneurs, réunissant les différentes versions pour maximiser dynamisme et réutilisation. Mais une fois le pic d'itérations passé, la fonctionnalité commence à ressembler à une dette.

Je constate que mon attention est restée cette année sur l'entraînement aux capacités d'ingénierie, donnant à chacun l'occasion d'exercer des techniques spectaculaires. Elle ne s'est pas assez déplacée en amont, vers la qualité des décisions techniques. Il nous manquait un cadre clair, des faits et un raisonnement explicite. La seule chose juste, selon moi, a été d'introduire la démocratie et la décision collective.

Chaque ingénieur traverse une phase où il déteste la redondance, veut tout abstraire et valorise la complexité comme signe de technicité. Il faut oser abandonner ces représentations intermédiaires et rechercher la clarté et la simplicité issues d'arbitrages réfléchis. Comme dans la philosophie Unix, il faut développer le goût des choses de grande qualité.