Le 30 septembre 2026 à 20h30 UTC, une partie de l’infrastructure réseau d’Azure a cessé de fonctionner normalement. Pendant près de six heures, des entreprises connectées à Microsoft via ExpressRoute ou un VPN Gateway ont vu leurs passerelles perdre en fiabilité, parfois jusqu’à l’interruption complète. Dix-huit régions ont été touchées, dont France Central, North Europe, West Europe, UK South et UK West. Pour un fournisseur qui détient 20 % du marché mondial du cloud d’infrastructure selon Synergy Research Group, l’incident remet sur la table une question que beaucoup d’entreprises européennes préfèrent éviter : que se passe-t-il quand le réseau qui relie leur datacenter à leur cloud public tombe en panne en même temps qu’une partie du cloud lui-même ?
L’incident n’a rien d’un cataclysme façon panne généralisée. Mais il touche deux services précis : ExpressRoute et VPN Gateway, dont la fonction est justement de garantir la continuité entre un siège d’entreprise et le cloud. Et il s’ajoute à une liste déjà longue de pannes cloud en 2026, à un moment où le règlement européen DORA impose aux institutions financières de documenter chaque incident jugé “majeur”. Cet article revient sur les faits, remet l’incident en perspective face aux autres pannes de l’année, et examine ce que cela signifie pour les entreprises françaises et européennes qui misent sur Azure pour leurs infrastructures hybrides.
Chronologie précise de la panne Azure des 30 septembre et 1er octobre 2026
Selon la page de statut officielle d’Azure, l’incident a débuté à 20h30 UTC le 30 septembre 2026 et s’est résorbé à 2h15 UTC le 1er octobre, soit une durée totale de 5 heures et 45 minutes. Microsoft a qualifié le problème de dégradation ou d’interruption de la connectivité réseau touchant un sous-ensemble de clients utilisant des services de passerelle dans plusieurs régions. La formulation est volontairement prudente : elle ne dit pas que tout le trafic s’est arrêté, mais que la fiabilité du lien s’est effondrée pour une partie des utilisateurs, sans préciser combien.
The Register, qui a suivi l’incident en direct, a publié un extrait du journal de statut dans lequel Microsoft reconnaît avoir “mis en pause l’activité de maintenance de l’infrastructure associée au déclenchement de cet événement”. Autrement dit, la panne est probablement liée à une opération de maintenance planifiée sur le système d’exploitation de l’infrastructure réseau, et non à une cyberattaque ou à une défaillance matérielle soudaine. Une mise à jour ultérieure, publiée à 23h13 UTC, indiquait que les équipes observaient “une reprise continue sur les passerelles ExpressRoute impactées” et qu’elles surveillaient cette reprise pour s’assurer qu’elle tienne dans la durée.
Certains VPN Gateway n’ont pas totalement perdu la connexion : ils ont fonctionné avec une redondance réduite plutôt qu’avec une coupure complète, ce qui a limité l’ampleur visible de l’incident pour une partie des clients. Mais Microsoft a aussi admis que “certains composants de gestion réseau ne se sont pas rétablis automatiquement”, provoquant des échecs d’opérations de gestion dans un sous-ensemble de régions affectées. Les équipes d’ingénierie ont dû restaurer ces composants manuellement, en utilisant des instances saines disponibles ailleurs dans l’infrastructure.
Les 18 régions Azure touchées, et pourquoi la France est concernée
La liste communiquée par Microsoft et reprise par plusieurs médias techniques comprend : 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. Quatre de ces régions, Mexico Central, Germany North, South India et Jio India Central, n’ont pas vu leur service Azure VMware Solution impacté, même si d’autres services y ont pu l’être.
La présence de France Central dans cette liste est le détail qui compte le plus pour les lecteurs français. C’est la région Azure physiquement installée en France, utilisée par de nombreuses entreprises et administrations pour des raisons de souveraineté des données et de conformité réglementaire. Qu’elle figure aux côtés de North Europe et West Europe, les deux régions historiques utilisées par la majorité des déploiements européens avant l’arrivée de France Central, montre que la panne n’a pas épargné une zone géographique précise : elle a touché un service transversal, partagé entre plusieurs datacenters, et non une seule installation physique.
C’est là que réside la vraie leçon technique de l’incident. Une architecture multirégion, pensée pour résister à la panne d’un seul site, ne protège pas automatiquement contre la panne d’un service réseau transversal comme ExpressRoute ou VPN Gateway. Si une entreprise avait répliqué ses charges de travail entre France Central et West Europe pour se couvrir contre un sinistre local, cette redondance n’aurait servi à rien le 30 septembre, puisque les deux régions dépendaient du même service de connectivité touché.
ExpressRoute et VPN Gateway : des services au cœur du cloud hybride
ExpressRoute Gateway est le service qui connecte un réseau sur site à un réseau virtuel Azure via une liaison dédiée, hors de l’internet public. C’est l’option privilégiée des grandes entreprises et des administrations qui veulent éviter de faire transiter leur trafic sensible par le web ouvert. Azure VPN Gateway, de son côté, crée un tunnel chiffré entre une infrastructure sur site et Azure, une solution plus légère mais tout aussi critique pour les PME et ETI qui n’ont pas les moyens d’une liaison dédiée.
Azure VMware Solution complète ce trio : il permet de migrer des charges de travail VMware existantes vers Azure sans réécrire les applications, une option choisie par de nombreuses entreprises qui modernisent leur infrastructure par étapes plutôt que par une refonte complète. Ces trois services forment, ensemble, l’épine dorsale du cloud hybride chez Microsoft : ils permettent à une entreprise de garder une partie de son infrastructure sur site tout en profitant de la capacité de calcul d’Azure. Quand ils tombent en panne simultanément, ce n’est pas une fonctionnalité secondaire qui est touchée, c’est la connexion même qui tient l’architecture hybride.
Microsoft a précisé que son enquête “continue de montrer une corrélation entre cet événement et l’activité de maintenance du système d’exploitation de l’infrastructure”, sans toutefois identifier de cause technique précise comme un défaut logiciel, une erreur de configuration ou une panne matérielle. Cette prudence dans la communication est habituelle chez les hyperscalers : elle évite d’exposer des détails d’architecture interne tant que l’analyse post-incident n’est pas finalisée.
Une année 2026 chargée en pannes pour les trois grands clouds
Cette panne Azure ne sort pas de nulle part. Elle s’inscrit dans une série d’incidents similaires qui ont touché les trois principaux fournisseurs cloud cette année. Google Cloud a connu une interruption dans la région us-central1-b ayant coupé 15 services pendant 4 heures et 8 minutes, puis une seconde panne dans us-west1 d’une durée de 3 heures et 40 minutes, touchant cette fois 27 services. À chaque fois, le constat est similaire : des dizaines de services dépendants d’une même brique d’infrastructure tombent en cascade, même quand le cœur du cloud reste disponible.
Le tableau ci-dessous compare les trois incidents majeurs documentés sur les grands clouds publics en 2026, à partir des éléments publiés par les fournisseurs eux-mêmes et repris par la presse technique.
| Incident | Fournisseur | Durée | Services ou régions touchés | Cause déclarée |
| 30 sept. – 1er oct. 2026 | Microsoft Azure | 5h45 | 18 régions, ExpressRoute, VPN Gateway, Azure VMware Solution | Maintenance de l’infrastructure réseau (cause précise non confirmée) |
| Panne us-central1-b | Google Cloud | 4h08 | 15 services dans une zone de disponibilité | Non détaillée publiquement dans les mêmes termes |
| Panne us-west1 | Google Cloud | 3h40 | 27 services dans une région | Non détaillée publiquement dans les mêmes termes |
Ce qui distingue l’incident Azure des deux pannes Google Cloud, c’est sa nature. Les pannes Google Cloud ont touché des services applicatifs dans une zone géographique précise, un scénario classique de panne régionale. La panne Azure, elle, a touché un service de connectivité répliqué dans 18 régions à la fois, ce qui signifie qu’elle n’était pas limitée par la géographie mais par une dépendance logique partagée entre tous ces sites. C’est un profil de risque différent, et probablement plus difficile à couvrir par une architecture de reprise classique.
Azure, AWS, Google Cloud : qui domine le marché du cloud en 2026
Pour comprendre l’impact réel de cette panne, il faut regarder le poids d’Azure dans le marché. Selon Synergy Research Group, le marché mondial des services d’infrastructure cloud a atteint environ 143 milliards de dollars au deuxième trimestre 2026, en hausse d’environ 43 % sur un an. Amazon Web Services conserve la première place avec 28 % de parts de marché, devant Microsoft Azure à 20 % et Google Cloud à 15 %. À eux trois, ces fournisseurs représentent 63 % des dépenses mondiales en infrastructure cloud.
La comparaison avec l’année précédente est révélatrice d’un mouvement de fond : au deuxième trimestre 2025, AWS détenait 30 % du marché, Azure 20 % (stable) et Google Cloud seulement 13 %. Google Cloud est donc le fournisseur qui progresse le plus vite en part de marché relative, tandis qu’AWS recule légèrement et qu’Azure fait du surplace en pourcentage, malgré une croissance en valeur absolue soutenue par la demande liée à l’intelligence artificielle.
| Fournisseur | Part de marché T2 2025 | Part de marché T2 2026 | Évolution |
| Amazon Web Services | 30 % | 28 % | -2 points |
| Microsoft Azure | 20 % | 20 % | Stable |
| Google Cloud | 13 % | 15 % | +2 points |
| Autres fournisseurs cumulés | 37 % | 37 % | Stable |
Rester stable à 20 % de parts de marché pendant qu’un concurrent comme Google Cloud gagne du terrain n’est jamais une bonne nouvelle pour Microsoft, même si le marché dans son ensemble continue de croître fortement. Un incident de connectivité touchant des services structurants comme ExpressRoute ou VPN Gateway, même limité à quelques heures, n’aide pas à rassurer les grands comptes qui hésitent encore entre consolider leur infrastructure chez un seul fournisseur ou répartir le risque entre plusieurs clouds.
Pourquoi les architectures hybrides sont les plus exposées
L’ironie de cet incident, c’est qu’il touche précisément les entreprises qui ont fait le choix jugé le plus prudent : garder une partie de leur infrastructure sur site plutôt que de tout migrer vers le cloud public. Ces entreprises paient pour une liaison ExpressRoute justement parce qu’elles veulent un contrôle renforcé sur leur trafic, une latence prévisible et une séparation claire entre leur réseau et l’internet public. Quand ce service tombe en panne, c’est le socle même de leur stratégie hybride qui vacille, pas une fonctionnalité annexe.
Pour une entreprise qui a migré ses charges de travail VMware vers Azure VMware Solution sans réécrire ses applications, souvent dans une logique de modernisation progressive plutôt que de refonte totale, la dépendance à la connectivité réseau Azure est encore plus directe. Si le lien entre le site et le cloud se dégrade, l’application continue de tourner sur l’infrastructure Azure, mais les équipes IT perdent une partie de leur capacité à la gérer, la surveiller ou la faire évoluer depuis leur environnement habituel.
Les opérations de gestion réseau ont justement été l’un des points faibles signalés par Microsoft pendant l’incident : certains gateways refusaient de se charger correctement dans le portail Azure, rendant plus difficile tout diagnostic ou intervention manuelle pendant la panne elle-même. C’est un effet domino classique dans les systèmes distribués : le service censé permettre de réparer le problème est lui-même affecté par le problème.
DORA, NIS2 : ce que dit la réglementation européenne sur les pannes cloud
En Europe, cet incident ne reste pas seulement une question technique. Depuis le 17 janvier 2025, le règlement sur la résilience opérationnelle numérique (DORA) s’applique à toutes les entités financières de l’Union européenne : banques, assureurs, sociétés d’investissement, établissements de paiement. DORA impose une gestion des risques liés aux prestataires informatiques tiers, une classification des incidents, des plans de continuité d’activité et des tests de résilience réguliers.
Concrètement, une banque française dont les systèmes dépendent d’une liaison ExpressRoute vers Azure doit évaluer si une coupure de 5h45 touchant 18 régions dépasse le seuil de matérialité fixé par DORA pour un incident ICT majeur. Si c’est le cas, elle doit le documenter et potentiellement le notifier à son régulateur national. C’est la responsabilité de l’entité régulée, pas de Microsoft, de faire cette évaluation : le fournisseur cloud subit l’incident, le client régulé porte l’obligation de déclaration.
La directive NIS2 ajoute une couche supplémentaire pour les secteurs considérés comme essentiels ou importants : infrastructures numériques, énergie, transport, santé, administration publique. Elle impose des mesures de gestion des risques liés à la chaîne d’approvisionnement et aux prestataires de services, ainsi qu’une notification aux autorités nationales compétentes en cas d’incident significatif. Une panne purement opérationnelle, sans composante malveillante, n’est pas automatiquement qualifiée d’incident de cybersécurité au sens strict, mais elle reste pertinente pour les obligations de continuité d’activité prévues par le texte.
Pour les entreprises françaises, c’est un rappel concret que la conformité réglementaire ne se limite pas à cocher des cases sur un document de gouvernance. Elle implique de savoir, en temps réel, quelles liaisons critiques dépendent d’un seul fournisseur, et de disposer d’une procédure déjà rédigée pour documenter un incident le jour où il survient, plutôt que de l’improviser sous pression.
Ce que les entreprises devraient vérifier dès maintenant
Le premier réflexe après un incident comme celui-ci est de vérifier la redondance réelle de ses liaisons ExpressRoute. Beaucoup d’entreprises pensent être protégées parce qu’elles ont souscrit deux circuits ExpressRoute, sans vérifier que ces deux circuits ne transitent pas par les mêmes passerelles régionales ou par le même point de présence chez l’opérateur télécom. Une redondance de façade ne protège contre rien si les deux liens dépendent, en coulisses, de la même infrastructure partagée.
Le deuxième point à auditer est la dépendance aux VPN Gateway comme solution de secours pour ExpressRoute. C’est une pratique courante : utiliser un tunnel VPN comme filet de sécurité en cas de défaillance de la liaison dédiée. Le problème, dans cet incident précis, est que les deux services ont été touchés en même temps, ce qui annule l’intérêt de ce plan de secours. Une architecture de résilience doit prévoir des chemins de secours qui ne dépendent pas du même composant d’infrastructure que le chemin principal.
Enfin, les équipes IT devraient revoir leurs procédures de gestion de crise pour le cas précis où le portail de gestion lui-même devient inaccessible. Si les gateways ne se chargent plus dans le portail Azure, comme cela a été rapporté pendant l’incident, il faut un plan B pour diagnostiquer et agir sans dépendre entièrement de l’interface web du fournisseur.
Impact sur le marché et la confiance dans le cloud hybride
Sur le plan commercial, un incident de 5h45 touchant 18 régions ne va pas faire fuir les grands comptes d’Azure du jour au lendemain. Changer de fournisseur cloud est un projet qui se compte en mois, voire en années, et les coûts de migration dépassent largement le coût d’indisponibilité d’une poignée d’heures. Mais l’incident alimente un argumentaire que les équipes commerciales d’AWS et de Google Cloud ne manqueront pas d’utiliser dans leurs discussions avec des clients hésitants, surtout ceux qui évaluent une stratégie multicloud pour répartir le risque opérationnel.
Pour Microsoft, l’enjeu dépasse la simple réputation technique. L’entreprise mise fortement sur la croissance de son segment Intelligent Cloud, porté par la demande en intelligence artificielle, pour justifier des investissements en capex qui comptent parmi les plus élevés de son histoire. Chaque incident de ce type, même mineur en durée, s’ajoute à un historique que les analystes financiers et les clients entreprise surveillent de près quand ils évaluent la fiabilité opérationnelle d’un fournisseur censé héberger des charges de travail critiques.
Les prévisions pour la suite de l’année 2026
Plusieurs tendances se dessinent pour les mois qui suivent cet incident. Premièrement, Microsoft devrait publier une analyse post-incident plus détaillée dans les semaines à venir, probablement sous la forme d’un rapport officiel identifiant la cause technique précise de la corrélation observée avec l’activité de maintenance. Les entreprises clientes vont scruter ce document pour savoir si le risque identifié est structurel ou ponctuel.
Deuxièmement, les discussions autour de la résilience multicloud vont s’intensifier dans les comités de direction IT, en particulier dans les secteurs régulés par DORA. Attendez-vous à voir davantage d’entreprises françaises documenter formellement leurs chemins de connectivité redondants plutôt que de supposer qu’ils existent.
Troisièmement, la bataille de parts de marché entre AWS, Azure et Google Cloud va continuer de se jouer sur la fiabilité perçue autant que sur le prix ou les fonctionnalités IA. Si Google Cloud continue de grappiller des points de marché comme il l’a fait entre le T2 2025 et le T2 2026, chaque panne chez un concurrent devient un argument marketing de fait, sans qu’il soit besoin de le formuler explicitement.
Quatrièmement, les régulateurs européens, déjà mobilisés sur la question de la souveraineté cloud via des textes comme le CADA, pourraient se saisir de ce type d’incident pour renforcer les exigences de transparence imposées aux hyperscalers opérant en Europe, notamment sur la publication de rapports post-incident détaillés et chiffrés, plutôt que des formulations prudentes évitant tout chiffre précis.
Cinquièmement, il faut s’attendre à ce que les fournisseurs de connectivité réseau tiers, opérateurs télécoms et intégrateurs spécialisés dans l’architecture hybride, voient leur rôle de conseil renforcé auprès des entreprises qui veulent concevoir des circuits ExpressRoute réellement indépendants plutôt que des redondances de façade.
Conclusion : une panne courte, un signal qui ne l’est pas
Cinq heures et quarante-cinq minutes, ce n’est pas une éternité à l’échelle d’une panne cloud. Mais le fait qu’elle touche simultanément ExpressRoute, VPN Gateway et Azure VMware Solution dans 18 régions, dont France Central, en dit plus sur la fragilité structurelle du cloud hybride que sur la gravité immédiate de l’incident. Le takeaway pour les équipes IT françaises et européennes est simple : vérifier dès maintenant que leurs circuits redondants ne partagent pas une dépendance cachée, et s’assurer que leurs procédures de gestion de crise fonctionnent même quand le portail de gestion du fournisseur, lui aussi, vacille.
Questions fréquentes sur la panne Azure de septembre-octobre 2026
Quelle a été la durée exacte de la panne Azure ?
L’incident a duré 5 heures et 45 minutes, du 30 septembre 2026 à 20h30 UTC au 1er octobre 2026 à 2h15 UTC, selon la page de statut officielle d’Azure.
La région France Central a-t-elle été affectée ?
Oui, France Central figure dans la liste des 18 régions touchées, au même titre que North Europe, West Europe, UK South et UK West.
Quelle est la cause de la panne ?
Microsoft a indiqué que son enquête montre une corrélation entre l’incident et une activité de maintenance du système d’exploitation de l’infrastructure réseau, sans confirmer de cause technique précise comme un bug logiciel ou une erreur de configuration.
Combien de clients ont été concernés ?
Microsoft parle d’un sous-ensemble de clients sans donner de chiffre précis de comptes ou de pourcentage de trafic affecté.
Cette panne est-elle liée à une cyberattaque ?
Non, rien dans les éléments publiés par Microsoft ou repris par la presse technique n’indique une composante malveillante. L’origine évoquée est une activité de maintenance planifiée sur l’infrastructure.
Les entreprises françaises doivent-elles déclarer cet incident à un régulateur ?
Cela dépend du secteur. Les entités financières couvertes par DORA doivent évaluer si l’incident dépasse le seuil de matérialité défini pour un incident ICT majeur et, le cas échéant, le notifier. Les entités couvertes par NIS2 doivent évaluer la pertinence au regard de leurs obligations de continuité d’activité.
Comment éviter d’être affecté par une panne similaire à l’avenir ?
En vérifiant que les circuits ExpressRoute redondants ne partagent pas les mêmes passerelles régionales, en évitant de dépendre d’un VPN Gateway comme seul plan de secours à ExpressRoute, et en préparant des procédures de gestion de crise qui ne reposent pas entièrement sur le portail de gestion du fournisseur cloud.
Azure est-il moins fiable qu’AWS ou Google Cloud ?
Les trois grands fournisseurs ont connu des pannes significatives en 2026. Google Cloud a subi deux interruptions régionales documentées cette année, et Azure cet incident de connectivité réseau. Aucune donnée publique ne permet d’établir un classement fiable de fiabilité globale entre les trois à partir de ces seuls incidents.
