- Cette panne dans la région AWS US-EAST-1 est analysée non comme un simple incident technique, mais comme le signal d’un affaiblissement organisationnel lié à la perte de personnel clé
- La cause de l’incident s’est révélée être un classique problème de DNS, et une erreur d’endpoint d’API DynamoDB a provoqué l’arrêt en chaîne d’autres services
- Avec le départ des ingénieurs vétérans qui se souvenaient des schémas de panne passés, l’identification du problème et la vitesse de rétablissement ont manifestement ralenti
- Chez Amazon, les licenciements massifs et un “regretted attrition rate” élevé (69 à 81 %) se combinent et fragilisent la stabilité opérationnelle d’AWS
- Il ne s’agit pas d’une crise liée au vieillissement technologique, mais à l’absence de personnes, et cela est interprété non comme un incident isolé, mais comme le signe avant-coureur d’une érosion durable de la confiance
Panne DNS et interruption de services
- Comme le veut la vieille blague chez les administrateurs système, "It's always DNS", de nombreuses pannes de services ont souvent pour origine un problème de DNS
- Le 20 octobre 2025 à 00:11 (PDT), une forte hausse du taux d’erreurs des services AWS dans la région US-EAST-1 a été signalée
- À 1:26, les échecs de requêtes vers l’endpoint DynamoDB se sont généralisés
- À 2:01, une erreur de résolution DNS de l’endpoint d’API DynamoDB a été identifiée comme la cause, entraînant une panne en cascade de nombreux services dépendants
- DynamoDB est un service fondamental de l’infrastructure AWS ; quand les services de cette région tombent, c’est l’ensemble d’Internet qui en subit les effets
- Banques, jeux, réseaux sociaux, services publics, achats sur Amazon.com : une paralysie à grande échelle s’est produite
- Il a fallu 75 minutes entre la détection du problème et l’identification de la cause, une réaction inhabituellement lente au regard de la réputation d’AWS en matière de rétablissement rapide
- Cette durée importante entre la prise de conscience de l’incident et l’identification de sa cause s’explique, selon l’analyse, moins par un manque de transparence que par un manque d’expérience
- Pendant ce laps de temps, la page d’état affichait uniquement le message « fonctionnement normal », suscitant les critiques de la communauté
La « prophétie » réalisée : les avertissements des partants
- Traditionnellement, AWS faisait valoir une capacité d’exploitation d’infrastructure de très haut niveau, au point qu’une panne dans une seule région devenait déjà un sujet majeur ; mais à mesure que la complexité augmente et que des incidents similaires au passé se répètent, l’expérience de terrain devient cruciale
- L’ancien ingénieur AWS Justin Garrison a averti lors de son départ en 2023 que les « événements à grande échelle (LSE) » étaient en augmentation
- Il avait prédit qu’« une panne majeure surviendrait en 2024 », et cette affaire semble lui donner raison
- Les départs en chaîne de profils techniques seniors au sein d’AWS se poursuivent, tandis que disparaît avec eux un savoir tribal accumulé sur des décennies (connaissance interne fondée sur l’expérience)
- Dans un incident DNS, il ne suffit pas de connaître la cause technique : il faut aussi des personnes capables de se souvenir si ce système a déjà provoqué un problème similaire dans le passé
- Or, ceux qui détenaient cette mémoire ont quitté l’entreprise à cause de la politique de retour au bureau (RTO) et des licenciements
Les preuves de la fuite des talents
- Entre 2022 et 2025, plus de 27 000 employés d’Amazon ont été licenciés ; même si les chiffres par département ne sont pas publics, on estime qu’AWS a lui aussi été directement touché
- Selon des documents internes, le « regretted attrition rate » atteindrait 69 à 81 %, ce qui signifie que ce sont les personnes que l’entreprise souhaitait retenir qui sont parties
- Le mécontentement provoqué par l’ordre de retour au bureau (Return to Office) a explosé, et de nombreux témoignages font état du départ massif d’ingénieurs vétérans expérimentés
- En conséquence, AWS a été réorganisé autour d’équipes moins expérimentées et moins coûteuses, ce qui affaiblit progressivement sa capacité à exploiter une infrastructure complexe
Problème structurel : la dénaturation de la « frugality »
- Par le passé, Frugality était une valeur centrale d’Amazon, une philosophie consistant à maximiser l’efficacité avec peu de ressources
- Mais récemment, elle semble avoir dérivé vers l’idée de tout faire avec presque aucune ressource
- La réduction des effectifs a atteint un point où même la maintenance de base devient difficile
- Le problème n’est pas que la technologie soit ancienne, mais que ceux qui la maintiennent sont nouveaux
Perspectives
- Le marché verra sans doute cette panne comme un incident ponctuel, mais la structure du problème demeure
- Les profils expérimentés partent, la complexité des systèmes augmente, et un cercle vicieux se forme, rendant le prochain incident de plus en plus probable
- AWS présentera probablement cet événement comme une « panne unique et isolée », mais si le vide interne continue de se creuser, le risque de répétition de pannes massives similaires restera élevé
- Comme le dit l’expression « chickens are coming home to roost », c’est désormais la perte de capital humain plus que la technologie qui s’impose comme le principal risque pour AWS
8 commentaires
Au fond, les gens sont les mêmes partout...
C’est une histoire qu’on retrouve sur tous les marchés.
On dirait qu’il faudrait traiter le savoir-faire des technologies IT de la même manière que celui d’un soudeur qualifié.
Ça me rappelle un article que j’ai lu il y a peu.
Je repense à cette idée qu’il est vraiment très difficile, chez Amazon, de passer du niveau senior engineer 2 à l’échelon suivant.
J’ai l’impression que ce genre de départs regrettables se produit particulièrement souvent à ce niveau.
À l’inverse, certains se disent peut-être en haut lieu : « Après avoir autant taillé dans les effectifs, on arrive quand même à s’en sortir à ce point-là… »
En Corée, dès que les ingénieurs atteignent un certain niveau, ils deviennent tous managers et ça coupe la progression...
Aux États-Unis, le problème, c’est qu’au nom de l’efficacité, on licencie tous les seniors...
Franchement, ce n’est pas simple...
On a bien mis en place du multi-AZ, mais... il faut peut-être aussi se préparer à des pannes à l’échelle d’une région..
Je pense qu’il faut aussi se demander si ce coût est vraiment supérieur au coût des pertes.
Commentaire Hacker News
Entre les ingénieurs et les ouvriers d’entrepôt, j’ai l’impression qu’à force de continuer à licencier des employés, le jour où même les gens qui ont déjà travaillé ici autrefois auront tous disparu n’est plus très loin.
Même avec des centaines de milliers de candidats ingénieurs en H-1B et des dizaines de millions d’ouvriers d’entrepôt immigrés en situation irrégulière, une entreprise de cette taille qui enchaîne rapidement les licenciements massifs finit forcément par épuiser ses ressources humaines.
Cette situation me rappelle l’épisode parodique Star Wars de Robot Chicken. Les officiers impériaux y font semblant que Dark Vador les étrangle avec la Force et feignent la mort pour éviter de se faire découper au sabre laser, puis ils reviennent ensuite sous un autre nom ; Amazon, c’est encore pire. Personne n’a envie de revenir.
https://www.youtube.com/watch?v=fFihTRIxCkg
Honnêtement, je n’ai jamais vu un ingénieur un tant soit peu compétent vouloir retravailler chez Amazon une seconde fois.
Il y a vraiment autant d’immigrés sans papiers dans les entrepôts ? Il me semble qu’Amazon vérifie l’identité et contrôle les documents de très près ; il peut y avoir des cas ponctuels d’usurpation d’identité, mais j’ai du mal à croire que ce soit si fréquent.
Le problème ne se limite pas aux licenciements : je me souviens avoir reçu un déluge d’e-mails de recruteurs dès qu’Amazon a imposé le RTO généralisé.
On sent un certain préjugé qui consiste à juger le niveau d’un ingénieur simplement parce qu’il est en H-1B.
J’ai moi-même travaillé autrefois avec un H-1B, et je suis maintenant de retour en Inde où je développe mon activité. J’ai travaillé chez Amazon. C’était un endroit difficile, mais au milieu des années 90, il y avait des stock-options, donc ça valait le coup.
Je suis convaincu que je code mieux qu’une bonne partie des gens ici. Et parmi les titulaires de H-1B autour de moi, il y en avait aussi beaucoup de vraiment très forts.
Il ne faut pas avoir de préjugés : il faut évaluer directement les compétences. Sous-estimer ses concurrents, c’est finir par se nuire à soi-même.
Le vrai avenir, c’est de garder ses employés et de leur fournir les meilleurs outils pour bien faire leur travail.
Les outils de développement progressent chaque jour, et on peut certes réduire les effectifs à court terme, mais les effets ne seront pas immédiats.
On sacrifie le présent en hypothéquant la croissance future et la pérennité de l’organisation. Se faire des illusions ne rendra pas le downsizing plus efficace.
En pratique, la stratégie semble fonctionner. Ils ont licencié un quart des ingénieurs principal juniors, le cours de l’action a monté, puis il y a eu une panne majeure et l’action a encore monté. À court terme, leur stratégie semble marcher.
Même les anciens géants de la big tech autrefois « naissants » entrent désormais dans leur ère de vieux grands groupes à la IBM.
Ce n’est pas qu’ils ignorent qu’un fort turnover est néfaste ; on dirait plutôt qu’ils conçoivent délibérément le terrain de sorte à niveler l’ensemble des employés vers une moyenne et à les transformer en ressources humaines interchangeables.
On en est même arrivé au point où le simple fait d’être très bon est relégué au rang de « culture cowboy ».
Il était assez suspect que le début de la vraie résolution de l’incident coïncide avec le début de journée sur la côte ouest des États-Unis.
Les mises à jour précédentes disaient seulement « surveillance en cours, travaux d’atténuation en cours », sans informations concrètes.
De ce que je sais, le rétablissement a eu lieu vers 4 h du matin, heure de Seattle. La journée de travail commence généralement à 9 h, mais peut-être que ça a commencé vers 6 h du matin si on se place sur l’heure de New York.
Un post que j’ai lu ce matin sur Reddit prend maintenant beaucoup plus de sens.
AWS reste malgré tout mon cloud préféré, et je l’utilise de manière vraiment efficace.
Moi aussi, j’ai déjà envisagé de travailler un jour chez AWS, mais tant que certains points d’inquiétude ne sont pas clairement réglés, ça me fait hésiter.
Si un futur manager n’est même pas capable de protéger un candidat dans ce processus, ça fait craindre qu’il ne puisse pas davantage le protéger face à des problèmes culturels plus graves.
J’ai une idée qui pourrait s’appliquer à l’ensemble des FAANG aujourd’hui : il faut continuer à entretenir l’image d’endroits où les gens vraiment compétents ont envie d’aller.
Meta a surtout travaillé son image avec des salaires plus élevés et des publications open source et open hardware, tandis que Google a longtemps mis en avant sa supériorité technique et une culture d’entreprise chaleureuse (a.k.a. la culture de formation des juniors, aujourd’hui plus formelle qu’autre chose).
AWS dispose déjà de nombreux talents techniques dont elle peut être fière, et je pense qu’elle devrait investir pour mieux les attirer et les retenir, puis faire connaître activement cette image dans le secteur.
J’ai vu exactement la même chose dans des startups.
Après un rachat, les talents clés partent souvent une fois leurs actions vestées, ou bien le grand groupe les pousse dehors pour mettre quelqu’un d’autre à leur place.
Tous ceux qui comprennent réellement la technologie s’en vont, et il ne reste finalement qu’une codebase ingérable que plus personne ne sait réparer.
J’adore la manière dont El Reg met le doigt exactement sur l’essence du problème.
Je ne m’étais rendu compte qu’aujourd’hui que l’auteur de l’article était Corey Quinn, qui écrit depuis longtemps sur AWS.
J’aime aussi la façon dont leurs auteurs écrivent avec esprit et personnalité.
Quoi qu’il arrive, ils savent viser juste sur le fond.
« Le problème a été circonscrit à un endpoint de service spécifique 75 minutes après le début de l’incident. »
Est-ce que c’est vraiment si long ? Je ne fais pas du développement web, mais trouver d’où vient le problème en 75 minutes me paraît plutôt rapide.
Quand je travaillais comme ingénieur firmware, il n’était pas rare que l’identification de l’origine d’une panne prenne des semaines.
Si la fréquence réelle du problème est de 0,01 %, qu’il n’a aucune corrélation apparente et qu’il disparaît au retry, alors oui, ça peut vraiment prendre des semaines.
Mais ce genre de cas n’est généralement pas un incident prioritaire ; les vrais accidents urgents sont en général reproductibles, et concernent quelque chose qui fonctionnait encore il y a une heure avant de soudainement casser.
En règle générale, dans un système cœur de métier correctement conçu, le diagnostic ne devrait pas prendre plus de 75 minutes. Bien sûr, la correction peut demander plus de temps.
Cela dit, on ne peut pas prétendre que de tels systèmes idéaux soient courants dans la réalité.
Dans une entreprise ordinaire, 75 minutes n’est peut-être pas long. Mais quand il s’agit du plus grand cloud du monde et qu’une grande partie d’Internet se retrouve paralysée, c’est une autre histoire.
En réalité, l’avis officiel disait encore « enquête en cours », mais en interne ils avaient peut-être déjà formulé l’hypothèse de la cause bien plus vite.
Mieux vaut rester prudent avant de publier une mise à jour trop hâtive, au risque d’induire inutilement les utilisateurs en erreur.
À mon avis, 75 minutes, c’est presque un temps de tout premier ordre pour diagnostiquer n’importe quel problème grave.
Amazon est réputé disposer d’une infrastructure parmi les meilleures du secteur.
Comme beaucoup d’autres entreprises reposent sur l’infrastructure d’Amazon, on est en droit d’attendre de talents de niveau SRE qu’ils identifient ce type d’incident très rapidement.
L’expérience accumulée et le savoir-faire qui disparaissent au sein d’une organisation, voilà une valeur réellement cruciale qu’il est difficile de faire tenir dans une simple feuille Excel.
Une organisation commence à se dérégler quand elle privilégie ceux qui construisent leur marque personnelle ou les recrutements de façade plutôt que les vrais experts et les spécialistes de long terme, et que son noyau technique, celui qui comprend réellement les systèmes, se retrouve marginalisé.
Quand ce déséquilibre prend l’ampleur d’AWS, les célébrités LinkedIn et les recrutements DEI à checklist finissent par prendre le dessus sur les vrais builders, et la qualité d’exécution, le sens des responsabilités et la solidité technique s’érodent progressivement.
On commence à voir assez clairement que le leadership d’Andy Jassy n’est pas efficace, et il n’est peut-être plus très loin le moment où Wall Street demandera officiellement son remplacement.
À propos de l’idée que The Register serait un média respecté, j’ai l’impression qu’en réalité eux-mêmes n’auraient pas envie qu’on les qualifie ainsi…