Le 23 juillet, la région West US d’Azure a perdu une partie de sa connectivité avec le reste du réseau de Microsoft pendant près de cinq heures, de 14 h 44 à 19 h 41 UTC. Selon la revue préliminaire publiée par Microsoft, la cause n’est ni une attaque ni une panne matérielle, mais un défaut dans l’outil qui automatise les maintenances réseau.
Ce qui s’est passé
D’après Microsoft, le processus qui transforme les demandes de maintenance en instructions automatisées a, à cause d’un bug, inclus par erreur des équipements supplémentaires dans une opération. Résultat : beaucoup plus de routes IP que prévu ont été retirées. Un datacenter de West US s’est retrouvé coupé du réseau étendu (WAN) de Microsoft. Le trafic entrant et sortant de la région a été perturbé, tandis que les échanges restés à l’intérieur de West US fonctionnaient.
Le diagnostic a pris du temps : l’incident s’est d’abord présenté comme une instabilité de routage à grande échelle sur le WAN, avant que les équipes ne fassent le lien avec la maintenance en cours.
Chronologie (UTC)
| Heure | Événement |
|---|---|
| 14 h 44 | Début de la maintenance, premières perturbations pour les clients |
| 14 h 45 | Les équipes réseau commencent l’investigation |
| 16 h 00 – 17 h 45 | Le routage anormal est relié à la maintenance réseau récente |
| 17 h 45 | Début du retour arrière manuel des changements |
| 18 h 26 | Retour arrière terminé, réseau stabilisé |
| 19 h 41 | Tous les services sont rétablis |
Quels services ont été touchés
Côté Azure, la liste est longue : App Service, Application Gateway, AKS, Cosmos DB, Azure Database for PostgreSQL, Azure Monitor, Azure Firewall, VPN Gateway, Virtual WAN, entre autres, ainsi que Microsoft Sentinel. L’impact a débordé sur Microsoft 365, suivi sous l’incident MO1437424 : SharePoint Online, OneDrive, Teams, le centre d’administration, Power Automate, Copilot Chat et Loop, surtout pour des utilisateurs en Amérique du Nord. Selon BleepingComputer, Downdetector a enregistré plus de 2 400 signalements au plus fort de la panne, dont une large majorité concernait SharePoint.
Une seule région peut tomber, même chez un hyperscaler. Pour les charges critiques, Microsoft recommande lui-même un déploiement multirégion et des alertes Azure Service Health pour être prévenu au plus tôt.
Ce qu’on en retient
Ce scénario n’est pas nouveau : chez les grands fournisseurs de cloud, les pannes les plus étendues viennent souvent de changements internes, et notamment de l’automatisation censée rendre les opérations plus sûres. Un outil qui calcule le périmètre d’une maintenance devient un point de défaillance unique : s’il se trompe, il se trompe vite et partout.
Pour les équipes qui hébergent leurs services sur Azure, quelques réflexes à vérifier après cet incident :
- savoir quelles applications dépendent d’une seule région, y compris les dépendances indirectes (base de données, passerelle VPN, registre de conteneurs) ;
- tester réellement la bascule vers une autre région, plutôt que de supposer qu’elle fonctionnera ;
- configurer les alertes Service Health pour que les bonnes personnes soient prévenues ;
- prévoir un canal de communication interne qui ne dépende pas de Teams ou d’Outlook, puisqu’ils peuvent tomber en même temps.
La revue publiée par Microsoft est préliminaire : la version définitive doit expliquer pourquoi les garde-fous de l’outil de maintenance n’ont pas empêché l’opération.