L'historique d'état de Microsoft Azure a publié coup sur coup deux analyses post-incident fin septembre. Aucune ne concerne une panne mondiale, mais leurs causes profondes sont des cas d'école à comparer avec votre propre architecture.

Incident 1 : services d'IA en Sweden Central (identifiant de suivi 7QL5-Z50)

De 10:03 à 15:58 UTC le 29 septembre 2026, Azure OpenAI, Foundry Agent Service, Foundry Models et Cognitive Services ont connu, dans la région Sweden Central, des échecs de requêtes intermittents, une latence accrue et des erreurs HTTP 5XX. Cause profonde selon Microsoft : un service backend de récupération de métadonnées a subi des délais d'attente de base de données, et ses instances, ayant atteint leurs seuils, ont redémarré en boucle, réduisant la capacité saine. La hausse des échecs a été détectée à 10:14, les délais d'attente identifiés à 11:29, les services étendus et les limites de ressources relevées à 15:22, et le rétablissement atteint à 15:58.

C'est la même catégorie de risque que celle décrite dans notre article sur la perturbation des services d'IA du 3 septembre : votre application va bien, mais l'API de modèle dont elle dépend est lente ou en échec dans une région.

Incident 2 : services de passerelle dans cinq régions (identifiant de suivi 7Q30-010)

De 20:30 UTC le 30 septembre à 02:15 UTC le 1er octobre, ExpressRoute Gateway, Azure Firewall, Application Gateway, WAF, VPN Gateway et Azure VMware Solution ont eu des problèmes de connectivité dans les régions UK South, France Central, North Europe, Southeast Asia et UK West — Southeast Asia étant la région d'Azure à Singapour. Cause profonde selon l'analyse préliminaire : une modification récente de la gestion des passerelles régionales a provoqué une charge excessive pendant une maintenance du système d'exploitation sans rapport, et le service n'a pas pu s'adapter automatiquement en raison de contraintes d'un service dépendant. Microsoft a relié l'incident à cette maintenance et l'a suspendue à 23:05, le rétablissement a progressé à 01:36 et l'atténuation a été confirmée à 02:15.

Lire les deux ensemble

  • « La machine tourne » ne veut pas dire « le service est joignable ». Dans le second incident, beaucoup de machines virtuelles étaient peut-être parfaitement saines, mais avec la passerelle, le pare-feu ou le VPN en panne devant elles, les utilisateurs ne pouvaient toujours pas se connecter. La surveillance au niveau de l'hôte ne suffit pas : sondez tout le chemin d'accès depuis l'extérieur.
  • Un changement qui croise une maintenance est un mode de défaillance ancien. L'un ou l'autre seul est inoffensif ; ensemble, ils cassent. Il en va de même pour vos serveurs : échelonnez mises à jour, redémarrages et changements de configuration, et gardez un chemin de retour arrière.
  • Dessinez vos dépendances. Dans notre article sur les pannes du premier semestre, nous suggérions de recenser quelles requêtes passent par quelle région de quel fournisseur, et si vous pouvez basculer en cas de panne.

Si vous servez des utilisateurs en Asie du Sud-Est

Si vos utilisateurs sont surtout en Asie du Sud-Est et que votre point d'entrée critique repose sur une seule région d'un seul fournisseur, un incident de ce type vous laisse dans l'attente. Une configuration plus robuste garde un point d'entrée capable de prendre le relais chez un autre fournisseur ou dans une autre région, couplé à une bascule DNS. Choisir un centre de données à faible latence pour sa charge de travail explique comment choisir les emplacements, et notre nœud de Singapour peut servir de point d'entrée de secours.