Hier, nous avons signalé à tort qu'AWS était en panne. Nos reportages n’ont pas été à la hauteur. Nous voulions donc faire deux choses : vous raconter ce qui s'est passé et vous expliquer les changements que nous apportons à la façon dont nous signalons les pannes de service cloud afin de maintenir votre confiance dans nos rapports.

Au début, il semblait qu'Amazon Web Services (AWS) rencontrait des problèmes hier (29 octobre), alors que les rapports de panne commençaient à augmenter sur le site de surveillance DownDetector.

Dans le même temps, nous avons commencé à recevoir des rapports non confirmés d'utilisateurs nous envoyant des courriers électroniques concernant leurs propres problèmes avec des erreurs « UnfillableCapacity » et une perte de Fire TV, apparemment causées par des problèmes avec le service d'Amazon.

Que s’est-il réellement passé ?


Panne Microsoft 29/10/25 14h05 Pac.

Cela se résume à deux choses : l’interdépendance et l’impact généralisé de la panne bien réelle de Microsoft qui a frappé hier. En particulier, Azure Front Door (AFD). Un « changement de configuration involontaire » a provoqué une panne du réseau et du service de routage de Microsoft (échecs de résolution DNS).

Considérez-le comme un standard téléphonique massif et complexe qui connecte instantanément un grand nombre d’applications et de sites Web sur la planète. L'AFD est l'opérateur principal et a accidentellement actionné le mauvais interrupteur central.

Pendant ce temps, les rapports de pannes d'utilisateurs pour AWS ont également augmenté. Ma boîte de réception de courrier électronique a explosé avec les lecteurs qui écrivent et X/Twitter a pris le train en marche. Mais de nombreuses grandes entreprises et applications utilisent une stratégie multi-cloud, en s'appuyant à la fois sur AWS et Azure pour différents services.

Une fois qu'Azure a basculé le mauvais commutateur central, il a perturbé les services qui utilisent également AWS dans ses composants, mais le problème ne venait pas d'AWS lui-même. « Nous sommes conscients qu'un problème opérationnel chez un autre fournisseur d'infrastructure peut avoir eu un impact sur les applications et les réseaux de certains clients », précise AWS sur sa page sur l'état des services.

Puis vint l’effet domino perçu. AWS n'était pas en panne et la panne d'Azure n'a pas eu d'impact sur les services AWS. Mais les rapports de pannes faussement positives ont fortement augmenté parallèlement aux rapports Azure. Même les rapports de panne de Google Cloud ont également augmenté. Cela arrive régulièrement lorsqu’un autre fournisseur de cloud connaît des temps d’arrêt – en fait, un volant d’inertie qui se perpétue pendant un certain temps.

Comment nous signalons les pannes

Il est important que nous le disions clairement. Nous vous servons. Nos lecteurs, et personne d'autre. C'est pourquoi nous sommes guidés par une combinaison de trois éléments : les rapports de panne des utilisateurs sur des plateformes telles que Down Detector, les e-mails soumis par les utilisateurs documentant leurs propres expériences et les pages d'état des services de l'entreprise.

Cela étant dit, nous pouvons apporter une modification à notre processus de reporting en direct sur d'éventuelles pannes de service cloud. Nous devons d’abord nous poser des questions avant d’annoncer une réponse dans nos gros titres et dans nos reportages, car comme vous l’avez vu hier, les interdépendances peuvent semer la confusion sur ce qui ne va pas et ce qui ne va pas.

Ce n'est que lorsque nous verrons quelque chose de concret sur une page d'état d'un service cloud, un commentaire d'entreprise ou des preuves vérifiées de nos lecteurs que nous changerons de position et ne dirons plus « quelque chose ne va pas ? à « quelque chose ne va pas ».

Nous pensons que c’est la manière la plus équitable d’aborder les pannes à l’avenir. Cela étant dit, si vous avez des suggestions, des questions ou des préoccupations, n'hésitez pas à me contacter dans la section commentaires.