Microsoft a reconnu que la panne généralisée ayant touché les services Microsoft 365 le 12 novembre 2026 était le résultat d'un défaut technique latent introduit lors d'une précédente mise à niveau de la capacité réseau, dont l'impact n'est apparu qu'après l'exécution d'un changement réseau plus récent. Les enquêtes opérationnelles ont précisé que l'incident n'était pas dû à une augmentation soudaine de la charge des utilisateurs, mais à la perte de capacité d'un grand nombre de serveurs à traiter les requêtes, entraînant un déséquilibre dans la distribution des connexions et une pression accrue sur les ressources disponibles.
Série de défaillances techniques
L'incident a débuté par une perturbation au niveau de la couche de réception des requêtes, où un processus logiciel responsable de l'établissement des connexions sécurisées a été soumis à une charge dépassant ses capacités, provoquant l'arrêt de la réponse des serveurs. Cela a conduit à l'échec des serveurs lors des contrôles de santé automatisés (Health Checks), ce qui a poussé le système à les exclure automatiquement, réduisant ainsi la capacité opérationnelle disponible et menant à un schéma de défaillance en cascade.
Les équipes d'ingénierie ont fait face à un défi supplémentaire lié à l'instabilité des serveurs après leur redémarrage, ces derniers reprenant leur activité avant de s'effondrer à nouveau lors de la réception du trafic, en plus de difficultés à synchroniser les paramètres sur les appareils bloqués, ce qui a entravé l'application de correctifs rapides.
Pourquoi cette nouvelle est-elle importante ?
Cet incident met en lumière la nature de l'interdépendance des infrastructures cloud modernes ; la panne du service Exchange Online a entraîné des effets secondaires à grande échelle touchant Teams, Copilot, SharePoint et des services de sécurité comme Defender, en raison de la dépendance de ces services aux données de messagerie, de calendrier et d'identité partagées. L'incident démontre que l'isolement fonctionnel entre les produits n'empêche pas toujours la propagation de l'impact technique à travers les composants partagés.
Mesures de rétablissement
Microsoft a adopté une stratégie de rétablissement graduelle comprenant :
- L'application d'un correctif pour un composant de configuration dans le chemin d'authentification et de routage amont.
- L'isolement de parties de l'infrastructure touchée et la redirection du trafic vers des chemins alternatifs.
- L'augmentation de la capacité virtuelle et le test de santé des serveurs avant leur remise en service.
- L'extension du délai de livraison des courriers électroniques à 48 heures pour garantir le traitement des messages accumulés sans perte de données.
La société a confirmé que l'incident était purement technique et n'avait aucun lien avec des cyberattaques ou des systèmes d'intelligence artificielle, précisant qu'elle publierait un rapport d'ingénierie détaillé après la fin de l'examen complet de l'incident.