Azure : un défaut du calcul de rayon d'impact isole tout un datacenter West US pendant près de cinq heures
2026-07-23 · Éditeur : Microsoft · Domaine : Cloud & DevOps
Le 23 juillet 2026, lors d'une réparation sur un équipement optique, le système d'analyse du rayon d'impact étend la maintenance à tous les équipements de sortie du datacenter West US. Le trafic externe est coupé de 14 h 44 à 19 h 41 UTC.
Ce qui change
- Panne du 23 juillet 2026, de 14 h 44 à 19 h 41 UTC, sur la région West US.
- Cause : le calcul de rayon d'impact a étendu une réparation à tous les équipements optiques en sortie.
- Trafic entrant et sortant coupé ; trafic interne à la région intact.
- Engagements datés : corrections faites, supervision en septembre, récupération automatique en octobre 2026.
### Ce qui change Le 23 juillet 2026, de 14 h 44 à 19 h 41 UTC, des clients d'**Azure** subissent des échecs de connexion, une latence accrue ou des difficultés d'accès à des services de la région **West US**. Le compte rendu post-incident (PIR) de Microsoft explique la cause : lors d'une réparation sur un équipement optique, un **défaut dans le système d'analyse du rayon d'impact** a « étendu à tort le périmètre de l'opération à tous les équipements optiques en sortie » du datacenter. La validation de sécurité n'a pas évalué l'effet cumulé de l'isolement simultané de tous ces équipements. ### Caractéristiques - Seuls les flux entrants et sortants du datacenter ont été touchés ; le trafic interne à la région est resté intact. - Services touchés : App Service, Application Gateway, AKS, Cosmos DB, ExpressRoute, Firewall, Sentinel, entre autres. - Retour arrière manuel lancé à 17 h 45 UTC ; équipements rétablis à 18 h 26 ; services pleinement rétablis à 19 h 41. - Engagements : défaut du calcul de rayon d'impact corrigé, contrôles renforcés pour empêcher la maintenance simultanée de chemins redondants (faits) ; meilleure supervision du trafic (septembre 2026) et récupération automatique plus robuste (octobre 2026). ### Pourquoi c'est important L'incident illustre un risque que les ingénieurs SRE connaissent bien : l'outil censé garantir la sécurité d'un changement a lui-même élargi son impact. Le chemin de maintenance du fournisseur reste une dépendance invisible pour les clients. Pour les DSI : tester des scénarios de perte du trafic externe d'une région, et exiger de chaque fournisseur un PIR détaillé, avec engagements datés, comme ici. ### À retenir Un contrôle de sécurité de maintenance mal calibré a isolé un datacenter entier : la sûreté du changement est un enjeu de plateforme.
Liens
Tags : Incident, Azure, Hyperscaler, Cloud