Deux pannes Azure en 40 heures coupent les passerelles hybrides de 18 régions

29 septembre 2026, 10 h 00 UTC. Azure OpenAI, Azure AI Foundry et les Cognitive Services de la région Suède centrale commencent à renvoyer des erreurs HTTP 5xx pendant près de six heures. 30 septembre 2026, 20 h 30 UTC. Les services de passerelle d’Azure basculent en panne dans 18 régions pour 5 h 45. 1er octobre 2026. Microsoft, sans publier de post-mortem complet, relie l’incident à un « changement de gestion des passerelles régionales ». Pourquoi c’est important : ce n’est pas le calcul ni le stockage qui ont lâché, mais la couche qui relie vos datacenters au cloud — et c’est la deuxième fois en deux jours.

Une panne de connectivité, pas une panne de calcul

Ce qui distingue cet incident, c’est ce qui est resté debout. Les machines virtuelles, les bases de données et les applications hébergées dans les régions touchées continuaient de tourner. Ce qui s’est cassé, c’est la couche de passerelle : ExpressRoute Gateway, VPN Gateway, Azure Firewall, Application Gateway/Web Application Firewall et Azure VMware Solution.

La nuance est décisive pour un SRE. Une panne de calcul se voit immédiatement : l’application répond en erreur, l’alerte part. Une panne de passerelle est silencieuse côté cloud : vos machines sont « up » dans la console, mais le lien qui raccorde votre site au cloud est rompu. Un commerce voit ses terminaux de caisse perdre la connexion à la base d’inventaire ; un hôpital voit ses serveurs sur site cesser de synchroniser les dossiers patients. Le symptôme est sur site, alors que la cause est dans le cloud.

Les 18 régions touchées dessinent un périmètre presque mondial : West US, West US 3, North Europe, West Europe, France Central, UK West, UK South, Switzerland North, Southeast Asia, East Asia, Japan West, Korea Central, South Africa North, UAE North, Mexico Central, Germany North, South India et Jio India Central. Soit près de la moitié de l’empreinte publique d’Azure.

Ce que Microsoft reconnaît, mot pour mot

Microsoft n’a pas encore publié de post-mortem technique complet — un contraste avec le Front Door d’octobre 2025, dont la décomposition avait été livrée en quelques jours. Le récit officiel tient en une phrase, portée par sa page de statut puis reprise par The Register et NeoTeo : un changement du service de gestion des passerelles régionales a déclenché une charge plus élevée que prévu, pendant que la maintenance du système d’exploitation de l’infrastructure progressait sur plusieurs régions.

La formulation est précise et instructive. Le changement de gestion des passerelles et la maintenance de l’OS étaient deux opérations distinctes, dont la coïncidence temporelle a produit la panne. La maintenance de l’OS n’a pas causé l’incident à elle seule, et le changement de gestion non plus : c’est la superposition des deux qui a empêché les services régionaux de monter en charge. Microsoft indique avoir annulé le changement de gestion fautif, ce qui a réduit la charge et permis la reprise.

Deux détails complètent le tableau. D’abord, la récupération n’a pas été instantanée : certains composants de gestion réseau « ne se sont pas rétablis automatiquement », prolongeant les erreurs du plan de gestion (portail, opérations réseau) après le retour de la connectivité brute. Ensuite, des clients ont signalé des défaillances sur Azure OpenAI de Suède centrale dès le 28 septembre à 23 h 00 UTC, soit onze heures avant l’ouverture officielle de l’incident — un rappel que le statut public suit toujours la panne réelle avec un retard.

Le schéma de panne qui se répète chez les hyperscalers

Cette panne n’est pas un accident isolé, c’est la troisième occurrence d’un même schéma en un peu plus d’un an. Le 29 octobre 2025, Azure Front Door tombait pendant 8 h 24, victime de métadonnées de configuration incompatibles générées par deux versions du plan de contrôle. En novembre 2025, Cloudflare subissait une panne quasi jumelle : un changement de permissions de base de données doublait la taille d’un fichier de Bot Management et faisait planter le logiciel qui le lisait.

Trois entreprises, trois systèmes, un même motif : un petit changement en apparence sûr dans un plan de contrôle se propage globalement avant que quiconque ne le rattrape. Le plan de contrôle est l’endroit où l’on applique les changements — il est par nature global et synchronisé, donc toute erreur y devient instantanément globale. C’est l’inverse d’un bug de nœud, qui reste local. La leçon pour un SRE ne tient pas dans « ne plus rien changer », mais dans le rayon de souffle : un changement de plan de contrôle doit être traité comme un changement de production critique, avec déploiement progressif et observabilité de la charge, pas comme de la « maintenance de routine ».

Le cas de Suède centrale mérite une lecture séparée. La région hébergeait Azure OpenAI et Azure AI Foundry, les rampes d’accès de Microsoft vers l’IA générative d’entreprise, et l’Agent Service de Foundry, la plateforme d’agents autonomes poussée tout au long de 2026. Un site de suivi a recensé 326 signalements de problèmes sur les services d’IA d’Azure en 24 heures. Quand la panne frappe l’IA, elle frappe désormais la charge de production que les entreprises ont déployée le plus vite cette année.

Ce qu’il faut tester avant la prochaine panne

La parade n’est pas de fuir Azure — aucun hyperscaler n’échappe à ce schéma — mais de tester la bascule hybride comme on teste les sauvegardes, c’est-à-dire réellement, régulièrement, et pas seulement sur le papier. Trois vérifications concrètes.

Premièrement, cartographiez les processus qui dépendent d’une seule région ou d’un seul chemin de passerelle. La panne d’octobre 2026 a touché le plan de contrôle des passerelles : les tunnels VPN existants continuaient souvent de passer, mais créer, modifier ou dépanner un tunnel était impossible. Une architecture qui ne peut plus être administrée est à moitié en panne, même si le trafic passe encore.

Deuxièmement, surveillez le flux de statut par programme. Les alertes humaines arrivent après le début de l’incident — les flux RSS de statut d’Azure permettent d’automatiser la détection et d’enclencher la bascule avant que vos utilisateurs n’appellent. Croisez-les avec vos propres sondes BGP et site-to-site : la panne d’octobre a produit des sessions BGP tombées et des tunnels site-to-site en échec.

Troisièmement, ne traitez pas les incidents répétés comme des nouvelles. Deux pannes en deux jours, après Front Door en 2025 et Cloudflare en 2025, forment une fréquence, pas une anecdote. Relancez vos exercices de continuité : un plan de bascule qui n’a pas été exécuté en conditions réelles n’est pas un plan, c’est un vœu.

Verdict

Si vous exploitez un cloud hybride sur Azure, cartographiez ce soir la liste de vos ExpressRoute, VPN Gateway et Azure Firewall, et vérifiez que chaque lien critique a un chemin de secours testé — cette panne a prouvé que la connectivité hybride est un point de défaillance à part entière, distinct du calcul qu’elle dessert. Si vous déployez de l’IA générative, rappelez-vous que Suède centrale a tenu le rôle de région pilote de l’incident : une stratégie qui concentre Azure OpenAI sur une seule région concentre aussi votre exposition à sa panne. Et si vous concevez une architecture en 2026, intégrez l’hypothèse qu’un changement de plan de contrôle hyperscaler tombera, tôt ou tard : le vrai critère n’est pas « mon fournisseur ne tombe jamais », mais « mon système survit quand il tombe ».

Références

• Shattered.io — Azure Outage 2026: 2 Incidents Hit 18 Regions in 40 Hours, 2 octobre 2026
• The Register — Azure maintenance mess disrupted hybrid clouds, VPNs, cloudy VMware services, 1er octobre 2026
• NeoTeo — Microsoft’s account of Azure’s Sept. 30–Oct. 1, 2026 connectivity disruption
• Microsoft Azure — Status history