Une semaine après l’incident massif d’Amazon Web Services (AWS), Microsoft Azure a connu mercredi 29 octobre une panne majeure qui a impacté ses propres services ainsi que ceux de tiers. Le problème, qui a débuté à 15h45 UTC (16h45 aux Canaries / 17h45 en Espagne péninsulaire) et a été résolu à 00h05 UTC le 30 octobre, trouve son origine dans Azure Front Door (AFD), le réseau mondial de distribution de contenus et d’applications d’Azure. La conséquence immédiate a été l’apparition de latences, de Timeouts et d’erreurs en cascade pour Microsoft 365, Xbox, Minecraft, les portails d’administration et une série d’applications professionnelles dépendantes d’Azure.

Bien que l’impact n’ait pas atteint le niveau de l’incident d’AWS la semaine dernière, la série d’incidents chez deux des grands fournisseurs de cloud relance le débat sur la résilience d’Internet et la dépendance mondiale à l’égard d’un petit groupe de géants du cloud pour faire fonctionner les entreprises et services critiques.

Que s’est-il passé et pourquoi ?

Microsoft a publié un Rapport d’Examen Préliminaire (PIR) indiquant qu’un changement de configuration involontaire dans Azure Front Door a été le déclencheur de la panne. Ce déploiement de configuration a provoqué un état invalide ou incohérent dans de nombreux nœuds AFD, qui ont cessé de charger correctement. À mesure que ces nœuds « non sains » quittaient le pool global, le trafic a été distribué de manière déséquilibrée entre les nœuds restants, amplifiant la panne avec des pics d’erreurs et de délais d’attente.

La réponse technique a consisté à bloquer immédiatement tout nouveau changement de configuration, à revenir Azure Front Door à son « dernier état connu et stable » et à récupérer progressivement les nœuds, rééquilibrant le trafic pour éviter la surcharge lors du redémarrage. Microsoft attribue la cause racine à un défaut logiciel dans les mécanismes de validation des déploiements, qui a permis à une configuration défectueuse de passer outre malgré les mesures de sécurité existantes.

Chronologie (résumé) :

• 15h45 UTC le 29/10 : début de l’impact client.
• 16h18–16h20 UTC : premières communications publiques et notifications adressées aux clients via Azure Service Health.
• 17h30 UTC : connexion des changements de configuration.
• 17h40–18h45 UTC : déploiement global de la version corrigée et récupération manuelle des nœuds, avec un trafic réorienté progressivement vers les nœuds sains.
• 00h05 UTC le 30/10 : Microsoft considère que l’impact d’AFD est mitigé, avec une petite queue résiduelle pour un nombre restreint de clients.

Quels services ont été impactés ?

La portée a été transversale. Outre Microsoft 365 — avec Word, Excel, PowerPoint et Outlook inaccessibles pour beaucoup durant les heures critiques —, OneDrive et Teams ont connu des intermittences. Il y a aussi eu des échecs de mise à jour sur Windows Defender et des perturbations pour Copilot dans certains environnements. Dans le domaine du divertissement, Xbox Live et Minecraft ont subi des pannes. Sur Azure, plusieurs services ont été affectés, notamment : App Service, Azure SQL Database, Container Registry, Azure Databricks, Azure Virtual Desktop, Media Services, Azure Maps, Azure Portal, Microsoft Entra ID (services d’identités et de gestion), Microsoft Sentinel (Threat Intelligence), Microsoft Purview, Microsoft Copilot for Security, Healthcare APIs, entre autres.

Au-delà de Microsoft, l’effet domino a touché des entreprises qui utilisent ou hébergent leurs applications via AFD ou en consomment dans Azure. Pendant l’incident, des compagnies aériennes, des retailers, et des opérateurs ont signalé des interruptions : Alaska Airlines a rencontré des problèmes lors du check-in ; Starbucks et d’autres marques ont subi des défaillances transactionnelles; Heathrow et Vodafone UK font partie de celles mentionnées dans la couverture internationale. Les pics de signalement sur Downdetector pour Azure et Microsoft 365 ont souligné l’ampleur de l’événement.

Est-ce résolu ?

À 00h05 UTC le 30/10, Microsoft a indiqué que les erreurs et latences étaient revenues à leurs niveaux antérieurs à l’incident, avec une petite queue encore en cours chez quelques clients, en attendant la fin des dernières mitigations. La blocage des changements de configuration chez les clients sur AFD reste temporaire jusqu’à ce que la situation soit stabilisée ; Microsoft prévoit de lever cette mesure et l’annoncera via Azure Service Health.

Pourquoi la panne d’AFD est-elle si critique ?

Azure Front Door agit, grosso modo, comme le front de nombreux services : un CDN et interface d’application globale qui distribue du contenu et oriente les requêtes vers des backends répartis, assurant équilibrage de charge, accélération et sécurité. Si AFD tombe en panne ou perd rapidement de la capacité à l’échelle mondiale, ce n’est pas seulement la livraison de contenu qui est compromise : ce sont aussi l’accès aux portails et APIs critiques, qui gèrent d’autres services Azure. D’où l’effet en cascade : du simple utilisateur ne pouvant ouvrir un document en ligne, au gestionnaire incapable de se connecter à Azure pour intervenir.

La coïncidence avec AWS : deux frayeurs en une semaine

Le 20 octobre, AWS a également connu un incident majeur avec une panne prolongée sur le site US-EAST-1, causée par un problème DNS dans l’automatisation du système (un enregistrement vide généré par erreur dans la gestion DNS liée à DynamoDB). La panne a mis hors service des milliers d’applications et de services à travers le monde, obligeant à désactiver temporairement l’automatisation affectée, en introduisant des mesures de sécurité supplémentaires.

Que deux géants du cloud rencontrent des incidents majeurs en si peu de temps n’est pas habituel. Cependant, la cause expliquée par la majorité des experts convergent : la complexité et l’automatisation à grande échelle sont à la fois des avantages… mais aussi des fardeaux lorsqu’il s’agit de valider ou non des modifications qui peuvent se révéler défaillantes.

Que peuvent faire les entreprises (au-delà du buzz) ?

Aucun prestataire — cloud public, privé ou en local — n’est à l’abri d’incidents. L’essentiel est de concevoir en partant du principe que tout peut échouer. Voici quelques stratégies de défense recommandées et que cet incident rappelle ce qu’il faut renforcer :

• Segregation du contrôle et des données. En cas de défaillance du plan de contrôle (ports ou APIs), disposer de moyens programmatiques alternatifs (CLI/PowerShell, automatisations hors portail) pour éviter de rester bloqué.
• Multi-région authentique. Déployer en plusieurs régions avec une convergence automatique ou manuelle, accompagnée de tests réguliers de type « journées de test » (game days) pour minimiser la durée des indisponibilités.
• Définir des dépendances explicites. Cartographier quels services passent par AFD (ou des équivalents CDN/WAF dans d’autres fournisseurs) et réduire la dépendance à une seule solution, par exemple, en incorporant un multi-CDN pour des sites très critiques.
• Utiliser des caches et modes dégradés. Sur des applications à forte transaction, prévoir des modes réduits permettant d’opérer des fonctions essentielles même si le backend est indisponible (lecture en cache, contenus critiques).
• Mises en copies et plans de reprise d’activité (DR). Conserver des copies immuables (WORM), des snapshots et des plans de continuité testés. Connaître aussi les modes hors ligne pour des suites comme Microsoft 365 (ex. Outlook en cache, OneDrive avec fichiers locaux) pour limiter l’impact.
• Alertes de supervision. Utiliser Azure Service Health (ou ses équivalents) pour recevoir des alertes par mail, SMS, push ou webhooks et automatiser des procédures (playbooks) en cas de dégradation.

Leçons d’ingénierie (et de produit)

1. Barrages de validation de configuration. Les contrôles en pipelines doivent être irréfutables avec un double contrôle pour les déploiements multitenant ou globaux. Un changement apparemment innocent ne doit pas pouvoir se propager sans contrôle strict.
2. Réversions rapides et état stable dernier. Maintenir des snapshots et des disjoncteurs (circuit breakers) pour pouvoir couper immédiatement la propagation des problèmes.
3. Récupérations progressives. Réintégrer les nœuds dans un pool global pas à pas permet d’éviter une nouvelle surcharge ou défaillance (re-failure), même si cela prend plus de temps.
4. Communication claire. Documenter les Rapports d’incidents (PIR) avec une chronologie, les causes techniques, actions, mesures préventives pour rassurer les clients et orienter les améliorations internes.

Contexte : le cloud persiste, mais avec vigilance

Les avantages du cloud — élasticité, catalogue de services, scalabilité — ne disparaissent pas après deux incidents. Cependant, ces événements rappellent que externaliser l’infrastructure ne signifie pas externaliser la responsabilité : l’architecture et la continuité d’activité restent du ressort de chaque entreprise. Pour beaucoup, le modèle hybride (pas uniquement sur site, mais combinant infrastructures privées et public) offre un équilibre entre contrôle, coût et agilité.

Foire aux questions

Qu’est-ce exactement qu’Azure Front Door, et pourquoi sa panne impacte-t-elle autant de services ?
Azure Front Door est une interface frontale globale (CDN + équilibrage + sécurité) qui intermédie des millions de requêtes vers des services Microsoft et clients. En cas de défaillance à l’échelle, cela brise les routes d’accès et déclenche une cascade d’erreurs et de latences dans les portails, APIs et applications dépendants.

Combien de temps a duré l’incident et comment Microsoft l’a-t-elle surmonté ?
L’impact a commencé à 15h45 UTC le 29/10 et a été considéré comme « résolu » à 00h05 UTC le 30/10. Microsoft a bloqué les changements, rétabli la configuration précédente, récupéré les nœuds manuellement, et rééquilibré le trafic de façon progressive pour retrouver la stabilité.

Est-ce lié à la panne d’AWS la semaine dernière ?
Pas directement. En octobre, chez AWS, c’était une erreur DNS sur US-EAST-1 liée à l’automatisation. Chez Azure, c’était un changement de configuration dans AFD à cause d’un bug logiciel. Les deux partagent cependant un schéma : une automatisation mal contrôlée et des validations insuffisantes dans des environnements critiques.

Que peuvent faire les entreprises pour atténuer ces risques ?
Adopter une infrastructure multi-régions, utiliser des méthodes programmatiques alternatives, déployer en multi-CDN pour les sites critiques, mettre en place des modes dégradés et caches, maintenir des copies sûres et des plans de reprise testés, mais aussi configurer des alertes santé qui activent des procédures automatiques en cas de problème.

Sources (sélection) :