Microsoft Azure Down: L'effondrement du cloud du 29 octobre 2025

Ou pourquoi les «modifications de configuration involontaires» devraient devenir le nouveau mot d’ordre de l’année

Avez-vous pensé, après le Le grand désastre d'AWS du 20 octobre (et le Relecture technique détaillée) Aurions-nous appris notre leçon? Haha, ce serait bien! Neuf jours plus tard, hier 29 octobre 2025, Microsoft a prouvé qu'il était possible de paralyser Internet même sans conditions de course DNS.
Il suffit d’un «changement de configuration involontaire» dans Azure Front Door pour que le monde numérique s’arrête à nouveau. Bienvenue au deuxième acte du chaos du cloud en octobre!

Timeline: Un après-midi dans le chaos numérique

17h00 HEC – Début

Vers 16h00 UTC (17h00 chez nous), les premiers messages ont commencé: les services Microsoft ne répondaient plus ou seulement très lentement. Ce qui ressemblait initialement à un petit hoquet s'est rapidement avéré être un trouble à part entière.

17:06 HEC – Microsoft détecte le problème

Microsoft a publié le premier message d'erreur officiel dans le centre d'administration avec l'ID de problème MO1181369. Les services concernés se lisent comme une liste des meilleurs du cloud Microsoft:

Exchange Online (bye bye, e-mails !)
Microsoft 365 suite (Excel, Word, PowerPoint dans le coma)
Microsoft Defender XDR (Sécurité? Quelle sécurité ?)
Microsoft Entra (anciennement Azure AD – Authentification vers le bas!)
Microsoft Intune (Device Management ade)
Microsoft Purview (Cauchemar de conformité)
Power Apps (toutes vos applications personnalisées : mortes)

Particulièrement piquant : cela aussi Centre d'administration Microsoft 365 elle-même a été touchée. C'est comme si les pompiers brûlaient alors que des incendies éclataient partout. Les administrateurs se tenaient là et ne pouvaient littéralement rien faire, sauf regarder impuissant.

17 h 21 HEC – Première analyse

Microsoft a déclaré: «Nous étudions les notifications d’un problème affectant Microsoft Azure et les services Microsoft 365.» Pas de panique, tout est sous contrôle! (Spoiler : Ce n'était pas le cas.)

17 h 28 HEC – DNS strikes again!

Et c'était là, le vieux traumatisme de l'administrateur: «It’s always DNS!» Microsoft a confirmé que les problèmes DNS en étaient la cause. Concrètement, il s’agissait de l’infrastructure de réseau et d’hébergement, qui était dans un «état malsain».

Pour les non-techniciens d'entre vous, le DNS (Domain Name System) est presque l'annuaire téléphonique d'Internet. Si cela ne fonctionne pas, les ordinateurs ne peuvent plus se parler parce qu'ils ne savent pas où se trouver. Pas de DNS, pas d'Internet. C'est aussi simple que ça.

17 h 36 HEC – le trafic est redirigé

Microsoft a tenté de rediriger le trafic vers une infrastructure alternative et saine. C'est comme si, dans un embouteillage sur l'autoroute, on essayait de rediriger toutes les voitures par des chemins de terre. Ça sonne bien dans la théorie …

18h17 HEC - La cause est trouvée

Maintenant, c'est devenu concret: «We’ve identified a recent configuration change to a portion of Azure infrastructure which we believe is causing the impact.»

Un «changement de configuration involontaire» – c’est-à-dire un discours en nuage pour «quelqu’un a appuyé sur un mauvais bouton quelque part». Le problème concernait spécifiquement Azure Front Door, Réseau de diffusion de contenu (CDN) de Microsoft.

18 h 24 UTC – retour en arrière en cours

Microsoft a commencé à déployer la «last known good configuration», c’est-à-dire à revenir au dernier paramètre opérationnel. Durée estimée : 30 minutes. (Spoiler n ° 2: Il a fallu beaucoup plus de temps.)

En parallèle, Microsoft a temporairement bloqué toutes les modifications de configuration des clients afin d'éviter d'autres désordres. Imaginez que vous essayiez d'éteindre une maison en feu pendant que les gens continuent à transporter des meubles à l'intérieur.

19h57 UTC – Premiers signes d’amélioration

Le retour en arrière était terminé et Microsoft a commencé à restaurer les nœuds et à acheminer le trafic à travers des nœuds sains. Restauration complète prévue: jusqu'à 23h20 UTC (00h20 HEC). Attendre encore quatre heures.

Peu après 02h00 HEC (30 octobre) – désalerte

Après plus de 8 heures d'indisponibilité Microsoft a déclaré que le problème avait été résolu. Huit heures! Dans le monde numérique, une demi-éternité.

Qu'est-ce qu'Azure Front Door?

Avant d'aller plus loin, voici une brève explication pour tous ceux qui n'ont pas affaire à l'infrastructure cloud tous les jours:

Azure Front Door Microsoft est le réseau mondial de diffusion de contenu (CDN) et le réseau de diffusion d'applications (ADN). Plus simplement, c’est la «porte d’entrée» pour pratiquement tous les services Azure et Microsoft 365 dans le monde.

Front Door effectue plusieurs tâches critiques:

Équilibrage de charge: Distribue le trafic entrant sur différents serveurs
Caching: Stocke le contenu fréquemment consulté entre pour le charger plus rapidement
Protection contre les attaques DDoS: Filtre les attaques et les bots
Terminaison SSL: Décrypte les connexions cryptées
routage: Dirige les requêtes vers les serveurs géographiquement les plus proches ou les moins occupés

Si la porte d’entrée tombe en panne, c’est comme si la porte principale d’un vaste complexe de bâtiments était fermée: plus personne n’entre, quelle que soit l’importance du problème.

La dimension technique : que s'est-il passé exactement?

Le scénario suivant peut être reconstruit à partir des messages d'état et des rapports officiels:

Phase 1 : Le changement de configuration fatal

Avant 16h00 UTC, un changement de configuration a été apporté à l'infrastructure Azure Front Door. Microsoft l’appelle «inadvertent» (involontaire), ce qui signifie probablement que:

Un processus automatisé a effectué une modification incorrecte
Un changement manuel a eu des effets secondaires inattendus
Un processus de déploiement a mal tourné

Ce changement a entraîné des problèmes DNS. Concrètement, cela signifie que les enregistrements DNS qui indiquent aux clients où trouver les services Azure étaient soudainement incorrects, incomplets ou inexistants.

Phase 2 : La cascade commence

Parce que Front Door agit comme un composant central, une réaction en chaîne a commencé:

Les services primaires touchés: Outlook, Microsoft 365, Exchange Online ont été directement touchés
Les outils d'administration échouent: Le centre d’administration Microsoft 365 et le portail Azure étaient partiellement inaccessibles, en particulier les outils dont les administrateurs ont besoin pour résoudre les problèmes
L'authentification échoue: Microsoft Entra (Azure AD) avait des problèmes, ce qui signifiait que de nombreux utilisateurs ne pouvaient plus se connecter du tout
Outils de sécurité vers le bas: Microsoft Defender XDR et Microsoft Purview ont été touchés – la sécurité et la conformité étaient littéralement aveugles

Étape 3: Essayer de sauver le portail

Microsoft a pris une mesure intéressante: elle a «failed the portal away from AFD», c’est-à-dire qu’elle a redirigé le portail Azure afin qu’il contourne la porte d’entrée et soit directement accessible. Cela a fonctionné en partie, mais certaines extensions de portail (comme Marketplace) sont restées problématiques.

C’est comme si l’on installait une échelle d’urgence sur un bâtiment en feu – cela fonctionne, mais de manière limitée.

Phase 4 : Le marathon du rollback

Le retour à la dernière configuration fonctionnelle a pris des heures. Pourquoi si longtemps? Parce qu'Azure Front Door est distribué à l'échelle mondiale et que les changements ont dû être propagés sur des centaines de serveurs dans des dizaines de centres de données à travers le monde.

Pendant le rollback, les techniciens ont dû:

Identifier la «last known good configuration»
Déploiement de cette configuration (30+ minutes)
Restaurer les nœuds pièce par pièce
Transférer progressivement le trafic à travers des nœuds sains
S'assurer qu'il n'y a pas plus de casse

Les dommages collatéraux: qui a tout touché?

Les compagnies aériennes dans le chaos

Alaska Airlines et Hawaiian Airlines Ils ont signalé qu'ils n'avaient pas accès aux systèmes critiques en raison des problèmes d'Azure. Les sites Web des compagnies aériennes étaient en panne, l'enregistrement en ligne n'a pas fonctionné. Les passagers devaient faire de longues files d'attente à l'aéroport et être enregistrés manuellement.

Imaginez : vous êtes à l'aéroport, votre vol part dans une heure et tout d'un coup, tous les passagers doivent être enregistrés manuellement parce que le cloud ne fonctionne pas. Bienvenue dans les années 1990!

Commerce de détail et restauration

Aux États-Unis, plusieurs grandes chaînes ont signalé des problèmes:

Kroger (Fabricant d'installations sanitaires)
Costco (grossiste)
Starbucks (chaîne de café)

Chez Starbucks, cela signifiait concrètement que l'application mobile ne fonctionnait pas, que le paiement mobile était mort et que le personnel devait recourir à d'anciens systèmes manuels.

Jeux et divertissements

Xbox Live: Les joueurs ne pouvaient pas se connecter, les jeux multijoueurs étaient inaccessibles
Minecraft: Encore une fois! Après la panne d'AWS, la panne d'Azure s'est également produite. La communauté Minecraft a connu un mois d'octobre noir.

Services critiques pour les entreprises

L'échec a été particulièrement douloureux pour les utilisateurs professionnels:

CodeTwo (Gestion des signatures électroniques) a signalé des problèmes de performances globales dans plusieurs régions:

Allemagne West Central
Australie-Orientale
Canada Est
13 autres composants

SpeechLive (solution de dictée en nuage pour les avocats et les médecins) était complètement en panne. Imaginez que vous êtes médecin, que vous avez un besoin urgent de dicter les dossiers médicaux et que votre logiciel cloud est en grève. Ce n'est pas une bonne situation.

TeamViewer (web.teamviewer.com) a été touchée et l’assistance à distance est devenue un défi.

La perspective allemande

En Allemagne aussi, il y a eu des effets allant au-delà des services directs de Microsoft:

Différents FAI (1&1, Vodafone Cable) ont signalé une augmentation des messages d’erreur, probablement parce que de nombreux utilisateurs pensaient que leur internet était cassé alors qu’il s’agissait «seulement» du nuage.
Certains utilisateurs ont signalé que même les pages qui ne sont pas hébergées sur Azure se chargeaient plus lentement, ce qui indique l’ampleur des problèmes DNS.
Le blog BornCity.com a subi des pannes à court terme, même si elle est hébergée sur all-inkl.com, peut-être en raison de problèmes de propagation DNS

AWS : le même jeu il y a une semaine

Revenons au 20 octobre 2025. À 9h30 du matin, heure française, le grand tremblement a commencé : AWS, le plus grand fournisseur de cloud au monde, a rencontré des problèmes massifs dans la région US-EAST-1. Et parce que cette région est si centrale, pratiquement la moitié d'Internet a échoué.

L'effet domino

La liste des services concernés se lit comme un who’s who de l’internet:

signal, Snapchat, zoom, Slack
Fortnite, Roblox, Minecraft (oui, encore une fois)
Tinder (Pas de rendez-vous pour vous !)
Amazon Prime Video, Alexa
Coinbase, Robinhood, Venmo
Perplexité AI, Canva, Duolingo
Autodesk (Les installations locales ne fonctionnaient pas parce que les serveurs de licences étaient inaccessibles)
En Allemagne : les Gématique avait des problèmes de TI avec eRezept et ePA parce que les compagnies d'assurance maladie utilisaient AWS

À propos 8,1 millions de plaintes sont entrés, plus de 2 000 sites et applications ont été touchés. Même «Eight Sleep», un système de lit intelligent qui ajuste automatiquement la température et l’inclinaison, ne fonctionnait plus. Les gens ne pouvaient même plus dormir confortablement!

La cause technique: une condition de course

Quelle en était la cause? Une condition dite «de course» dans le système DNS d’AWS. Deux processus automatisés ont tenté simultanément d’apporter des modifications dans différentes régions et – Puff! – toute la table DNS était vide. Soudain, les serveurs ne savaient plus comment communiquer entre eux.

Le service principalement concerné était DynamoDB, un service de base de données qu'AWS utilise également en interne. Lorsque DynamoDB a échoué, une cascade s'est produite : EC2 (serveur virtuel) et Lambda (code sans serveur) ont également été touchés. Un point de défaillance classique.

Il a fallu environ trois heures à AWS pour trouver et résoudre la cause. Mais les séquelles étaient encore perceptibles des heures plus tard.

La grande image: la dépendance au cloud comme risque

Deux pannes massives en neuf jours. Les deux fois la même cause: Problèmes de DNS dans des infrastructures cloud centralisées. Que pouvons-nous en apprendre?

1. Le Single Point of Failure est réel

Quelle que soit la taille et la puissance d’un fournisseur de services en nuage, la moitié de l’internet tombe souvent en panne. AWS et Azure sont si dominants que leurs pannes ont un impact mondial. Ensemble, AWS, Microsoft Azure et Google Cloud contrôlent environ 65% du marché mondial du cloud. C'est une énorme concentration de pouvoir.

2. Le multicloud n’est pas un luxe, mais une obligation

Les experts mettent en garde depuis longtemps : si vous mettez tous vos services sur un seul fournisseur de cloud, vous prenez un risque énorme. Les stratégies multi-cloud dans lesquelles vous répartissez votre infrastructure entre plusieurs fournisseurs sont aujourd'hui indispensables. Oui, c’est plus complexe et plus coûteux, mais une panne de huit heures peut vous coûter beaucoup plus cher.

3. Les stratégies de basculement doivent

Avez-vous un plan B? Et un plan C? Les entreprises ont besoin:

Systèmes de basculement automatique, qui basculent vers une infrastructure alternative en cas de panne
Sauvegardes redondantes sur différentes plates-formes
CDN avec origines multiples, de sorte que le contenu puisse être fourni à partir de différentes sources
Tests réguliers vos plans d’urgence (pas avant qu’ils ne brûlent !)

4. L'ADN reste le talon d'Achille

Les deux défaillances étaient dues à des problèmes d'ADN. Le système de noms de domaine est le système nerveux de l’internet – en cas de panne, le chaos est préprogrammé. Les entreprises devraient:

Utiliser les stratégies DNS distribuées
Utilisation de plusieurs fournisseurs DNS
Configurer intelligemment la mise en cache DNS

5. La composante humaine

Dans les deux cas, ce sont des «modifications de configuration involontaires» ou des processus automatisés qui sont devenus incontrôlables. Cela montre que même chez les géants de la technologie, la complexité des systèmes est si élevée que des erreurs se produisent. Et quand ils se produisent, ils ont un impact mondial.

Les utilisateurs de Microsoft ont commenté sarcastiquement: «Si ce n’est pas cassé, ne le répare pas!» Le vieil adage «If it’s not broken, don’t fix it» semble avoir été oublié par Microsoft et Cie.

Qu'est-ce que cela signifie pour vous?

Que vous gériez une entreprise, que vous soyez un administrateur informatique ou que vous utilisiez simplement des services en nuage, ces pannes sont un signal d’alarme:

Pour les entreprises:

Diversifiez votre infrastructure cloud. Ne mettez pas tout sur une carte.
Testez vos plans d'urgence régulièrement. En cas de panne d'AWS ou d'Azure, savez-vous quoi faire?
Communique de manière proactive avec vos clients en cas de problème. La transparence crée la confiance.
Conserve les fonctions critiques localement. Tout n'est pas forcément dans le cloud.

Pour les utilisateurs privés:

Avoir des solutions de sauvegarde pour des services importants. Lorsque Outlook est en panne, pouvez-vous accéder à votre programme de messagerie ou à votre webmail?
Utilise différentes plates-formes à des fins différentes. Tous les œufs dans un panier n'est jamais une bonne idée.
Télécharge les données importantes localement. Le cloud est pratique, mais ne remplace pas les sauvegardes locales.

Pour la politique:

L'UE travaille déjà à des règles plus strictes, telles que Loi sur la cyber-résilience, qui Directive SRI 2 et le Règlement sur la cybersolidarité. Ces lois visent à assurer une meilleure protection des infrastructures critiques. Chris Dimitriadis, expert AWS de l’ISACA, parle de «pandémies numériques», et c’est exactement ce que ces pannes ressentent.

Conclusion: Bienvenue dans le monde numérique fragile

Deux pannes massives de cloud en neuf jours nous montrent clairement une chose : l'infrastructure numérique moderne est plus fragile que nous ne le pensons. Nous sommes devenus dépendants d'une poignée de géants de la technologie, et quand ils trébuchent, nous trébuchons tous avec eux.

La bonne nouvelle? Ces défaillances peuvent être évitées ou, à tout le moins, leurs effets peuvent être minimisés. Il faut:

Diversification technique (Multi-Cloud, multi-région, multi-fournisseur)
Résilience organisationnelle (plans d'urgence, modes de fonctionnement réduits)
Cadre réglementaire (Législations cybernétiques plus strictes)

La question n'est plus de savoir si la prochaine panne majeure du cloud se produira, mais quand. Et si vous faites partie des gagnants ou des perdants, cela dépend de votre préparation.

TL:DR

En ce sens, restez vigilant, restez résilient et n'oubliez pas de vérifier vos sauvegardes locales de temps en temps. On ne sait jamais quand le prochain «changement involontaire de configuration» viendra au coin de la rue.