Depuis le jeudi 12 novembre 2026 à 17 h 17, heure de Paris, Microsoft 365 connaît une panne mondiale. La messagerie Outlook et le calendrier sont les plus touchés : connexions refusées, boîtes aux lettres qui ne se chargent pas, envois retardés. Teams pour les appels et les conversations, SharePoint et OneDrive fonctionnent. Microsoft indique qu’il ne s’agit pas d’une attaque. Ce suivi rassemble ce que Microsoft a publié, traduit et daté, et ce que nous avons constaté chez nos clients.
En bref
- Ce qui est touché : Outlook (bureau, web et mobile), le calendrier, une partie des consoles d'administration, Copilot, Planner, la liste des fichiers récents, et par intermittence l'inscription et la conformité des appareils gérés. Microsoft précise que seules les fonctions qui s'appuient sur la messagerie sont touchées.
- Ce qui fonctionne : les appels et conversations Teams, SharePoint, OneDrive.
- Cause : chez Microsoft, pas chez vous. Le mécanisme qui établit les connexions sécurisées sur les serveurs de messagerie est submergé et les serveurs cessent de répondre.
- Vos messages : Microsoft a porté à 48 heures le délai de conservation des messages en attente. Un message retardé n'est pas perdu.
- Votre action : rien à faire sur les postes. Ne réinstallez pas Outlook, ne recréez pas de profil, ne changez pas de mot de passe à cause de la panne.
- Fin prévue : Microsoft n'annonce aucune heure de rétablissement.
Chronologie
Heures de Paris. Microsoft publie deux avis en parallèle, visibles par les administrateurs dans le centre d’administration Microsoft 365, rubrique Intégrité du service : EX1550543 pour la messagerie et MO1550821 pour les autres services Microsoft 365.
Jeudi 12 novembre
- 17 h 17 : premières erreurs de connexion aux boîtes aux lettres. Microsoft ouvre l'incident messagerie EX1550543.
- 18 h 45 : Microsoft repère des erreurs de connexion sur la partie de son infrastructure qui reçoit les demandes d'accès des utilisateurs.
- 19 h 19 : la cause apparente est une surcharge des serveurs dans plusieurs régions. Microsoft redémarre et répare les serveurs touchés.
- 19 h 26 : l'incident s'étend à d'autres services. Microsoft ouvre l'avis MO1550821.
- 19 h 29 à 19 h 57 : Microsoft détourne une partie du trafic des serveurs touchés, d'abord aux États-Unis, puis redistribue les connexions Outlook sur son infrastructure mondiale.
- 20 h 06 : par précaution, Microsoft suspend toutes ses mises en production et ses changements de configuration, le temps de vérifier si l'un d'eux est en cause.
- 20 h 18 : la surcharge ne vient pas d'une hausse du trafic. Un grand nombre de serveurs devient indisponible et reporte sa charge sur ceux qui restent.
- 20 h 43 à 21 h 56 : les serveurs échouent aux contrôles de santé automatiques qui décident s'ils restent en service. Microsoft teste puis étend une autre méthode de contrôle, qui permet à un premier groupe de serveurs de revenir.
- 23 h 00 : Microsoft reconnaît que les actions menées n'ont pas apporté le soulagement attendu. Un processus essentiel des serveurs est submergé.
- 23 h 57 : une partie des serveurs revient en service et reste stable. Retour limité dans certaines régions.
Vendredi 13 novembre
- 0 h 59 : les serveurs remis en service retombent dès qu'ils reçoivent du trafic. Les équipes réseau et plateforme de Microsoft analysent les diagnostics.
- 2 h 06 : cause technique identifiée. Sur les serveurs touchés, le processus qui établit les connexions sécurisées est submergé, et le serveur cesse de traiter les demandes. Microsoft prépare un changement de configuration.
- 2 h 45 : premiers résultats positifs des redémarrages.
- 3 h 54 : le changement appliqué ne donne pas l'effet attendu. Microsoft cherche d'autres pistes pour augmenter la capacité.
- 5 h 10 : retour partiel dans plusieurs régions, grâce à la limitation, la redirection et le blocage ciblé d'une partie du trafic.
- 5 h 59 : Microsoft observe un afflux d'appels de ses services d'aiguillage vers ses serveurs de messagerie et cherche son origine.
- 7 h 16 : Microsoft étudie de nouvelles mesures de régulation du trafic pour soulager ses serveurs.
- 8 h 25 : un correctif sur le composant d'authentification et d'aiguillage stabilise les serveurs où il est appliqué.
- 9 h 06 : la stabilité se confirme. Microsoft étend le correctif en priorité aux régions qui entrent dans leurs heures de bureau, dont l'Europe.
- 10 h 03 : premiers signes de stabilisation, mais la capacité n'est pas revenue à la normale et le service reste variable pendant la remise en charge progressive. Les serveurs sont vidés, redémarrés, réparés puis remis en service un à un. Microsoft porte à 48 heures la conservation des messages en attente.
- 10 h 57 : Microsoft constate une amélioration progressive sur plusieurs services, d'après ses mesures et les retours de ses clients. Le service reste variable et la capacité n'est pas encore revenue à la normale. Les messages en attente sont traités en priorité.
Pourquoi le service paraît pire en matinée
La panne touche les serveurs qui reçoivent les connexions. Quand l’Europe arrive au bureau, des millions d’utilisateurs se reconnectent en même temps, sur une infrastructure dont une partie n’a pas encore reçu le correctif. Le service peut donc sembler plus lent ou plus instable à 9 h qu’à 7 h, alors que la situation d’ensemble s’améliore. Microsoft remet le trafic en charge progressivement, région par région, pour ne pas faire retomber les serveurs réparés.
Ce que nous avons vérifié chez nos clients
Dès le premier signalement, jeudi soir, nous avons contrôlé l’accès Internet des bureaux, la surveillance de sécurité et la protection des postes. Aucun de ces contrôles n’a montré d’anomalie : la panne ne vient ni des postes, ni des réseaux, ni d’un incident de sécurité. Les mêmes symptômes sont apparus en même temps en Espagne et aux États-Unis, chez des sociétés sans lien entre elles, ce qui désignait un problème chez Microsoft avant même sa confirmation.
Un constat ponctuel : un collaborateur à l’étranger a retrouvé l’envoi de ses messages en se connectant au réseau privé de son bureau parisien. Son trafic passait alors par un autre point d’entrée chez Microsoft. Ce contournement a fonctionné dans ce cas, sans garantie ailleurs.
Que faire, que ne pas faire
- Ne rien réinstaller : ni Outlook, ni Office, ni le profil de messagerie. Le poste n'est pas en cause et une réinstallation fait perdre du temps sans rien régler.
- Ne pas renvoyer en boucle un message bloqué : il est conservé et partira au rétablissement. Le renvoyer crée des doublons chez le destinataire.
- Utiliser Teams pour l'urgent : appels et conversations fonctionnent.
- Partager un fichier par lien SharePoint ou OneDrive plutôt qu'en pièce jointe.
- Se méfier des faux messages « Microsoft » qui profitent de la panne pour demander de se reconnecter ou de valider un code. Microsoft ne demande pas vos identifiants par courriel pour rétablir le service.
- En cas de doute sur un symptôme qui ne ressemble pas à la panne, appeler le support plutôt que d'attendre.
Pour les sociétés soumises à DORA
Une panne d’un prestataire TIC critique qui touche la messagerie relève du suivi des incidents liés aux TIC. Trois réflexes :
- consigner l'incident dans votre registre, avec ses heures de début et de fin, les services touchés et l'effet sur votre activité ;
- évaluer sa classification au regard des critères réglementaires (durée, nombre de clients touchés, services critiques concernés) ;
- conserver les avis publiés par Microsoft (EX1550543, MO1550821) et le rapport d'incident que Microsoft s'est engagé à publier après le rétablissement.
Pour nos clients, nous fournissons la chronologie et les éléments de preuve à joindre au registre.
Prochaine étape
Microsoft n’annonce aucune heure de fin. Son prochain point est attendu à 12 h, heure de Paris. Nous mettons cet article à jour à chaque nouvel avis, puis nous publierons la synthèse du rapport d’incident de Microsoft, avec la cause et les mesures annoncées pour éviter qu’une telle panne se reproduise.
Nos clients touchés sont informés directement par leur ticket de suivi.