À retenir
- La panne a débuté le 12 novembre 2026 à 17 h 17 (heure de Paris) sur Exchange Online, la messagerie d’Outlook, puis a gagné d’autres services Microsoft 365. Elle n’était pas résolue au matin du 13 novembre.
- Le rétablissement avance par à-coups : plusieurs correctifs ont semblé fonctionner avant de ne pas tenir. À 8 h 29, Microsoft faisait état de « résultats positifs » après un correctif appliqué à une partie de son infrastructure, sans parler de retour complet.
- Microsoft n’a connaissance d’aucune activité malveillante, mais la cause exacte n’est pas confirmée.
- Il est conseillé aux administrateurs de suivre l’incident dans le centre d’administration ou sur la page d’état publique de Microsoft, et de prévenir leurs équipes par un canal extérieur à Microsoft 365.
Mise à jour le 13 novembre 2026 : la dernière information que nous avons pu confirmer date de 8 h 50, heure de Paris, et ne signale aucun rétablissement complet. La page d’état de Microsoft et son compte X d’information n’étaient pas lisibles de notre côté, si bien que les messages de l’éditeur nous parviennent par la presse et par un suivi tiers.
Une panne qui part de la messagerie
Tout commence le jeudi 12 novembre à 17 h 17, quand des utilisateurs n’arrivent plus à ouvrir leur boîte aux lettres Exchange Online. Les signalements affluent vite : vers 19 h, Downdetector recensait déjà plus de 100 000 signalements concernant Outlook, dans plus de 70 pays, d’après ITdaily. Microsoft a d’abord évoqué un problème sur le continent américain, puis admis qu’il pouvait toucher des utilisateurs de n’importe quelle région.
Les effets se sont ensuite propagés aux services qui dépendent d’Exchange. Microsoft a signalé des perturbations possibles pour Teams, SharePoint Online, Copilot et Defender XDR, et d’autres services, dont OneDrive et Planner, sont aussi cités. L’ampleur varie toutefois d’un client à l’autre : le chat, les réunions en ligne et SharePoint fonctionneraient en grande partie normalement. Le 13 novembre au matin, Power Apps a rejoint la liste des services touchés.
Ce que Microsoft explique, et ce qu’elle ne sait pas encore
Le diagnostic a évolué au fil de la nuit. Microsoft a d’abord constaté une charge très élevée, qui ne venait pas d’un surcroît de trafic : un grand nombre de serveurs étaient devenus indisponibles après avoir échoué à leurs contrôles de santé automatiques, et le reste de l’infrastructure absorbait leur travail. Vers 21 h, l’éditeur disait ne pas avoir identifié de changement récent lié au début de l’incident. Vers 23 h, il reconnaissait que ses premières actions n’avaient rien amélioré et signalait un processus central saturé sur les serveurs touchés, un processus chargé, précise SecurityWeek, d’établir les connexions sécurisées.
Dans la nuit, avant 2 h 50, le discours a changé : Microsoft a commencé à annuler une modification récente de la configuration réseau qui, selon SecurityWeek, « coïncidait avec le début » de la perturbation. L’éditeur n’a pas confirmé que ce changement était la cause. On ignore donc s’il a déclenché l’effondrement des serveurs ou s’il n’a fait que précéder une défaillance née ailleurs. Une explication définitive n’est attendue que dans le rapport d’incident que Microsoft promet de publier une fois la situation stabilisée.
Un rétablissement en dents de scie
Depuis la nuit, les annonces de Microsoft alternent espoir et revers. Vers 2 h 50, le redémarrage des serveurs donnait des résultats encourageants, mais un changement appliqué dans la foulée ne produisait pas l’effet voulu. Vers 6 h, des machines restées dans un état défaillant et un afflux d’appels venus des services de routage empêchaient la propagation de la correction. C’est un problème typique d’une grande infrastructure : un serveur relancé ne prouve rien tant qu’il ne tient pas la charge, et des serveurs redémarrés retombaient en panne dès qu’ils recevaient du trafic.
À 8 h 29, Microsoft annonçait des « résultats positifs » sur la stabilité des serveurs après un correctif appliqué à une partie de l’infrastructure, qu’elle comptait étendre, avec un nouveau point prévu à 9 h 30. CNBC relève toutefois que des utilisateurs pouvaient encore ne pas réussir à se connecter et qu’aucun calendrier de retour complet n’était communiqué. Nous n’avons pas trouvé de message postérieur à 8 h 50 annonçant la fin de l’incident.
Est-ce une cyberattaque ?
Rien ne le laisse penser à ce stade. Microsoft a déclaré ne pas avoir connaissance d’activité malveillante à l’origine de l’incident (« we are not aware of any malicious activity », traduit par nos soins), et SecurityWeek comme ITdaily ne relèvent eux non plus aucun indice d’attaque. L’absence de preuve n’est pas une preuve d’absence, mais tout ce que décrivent les sources évoque une défaillance interne, de configuration ou de capacité, plutôt qu’une intrusion.
Des utilisateurs d’Amazon Web Services et de Google ayant aussi signalé des difficultés le 12 novembre, la question d’un lien s’est posée. AWS a indiqué que ses services fonctionnaient normalement et que des informations inexactes circulaient à cause d’une perturbation sans rapport ailleurs sur Internet. Aucune de nos sources n’établit de lien avec la panne de Microsoft.
Que faire en attendant
Pour un utilisateur, il n’y a rien à réparer de son côté. Les recommandations qui suivent ne viennent pas de Microsoft mais d’un suivi tiers de l’incident, et sont à prendre avec cette prudence. Il est conseillé aux administrateurs de ne pas demander de réinstaller Office, de supprimer des profils Outlook ou de réinitialiser des mots de passe, car ces gestes n’y changent rien et brouillent le diagnostic. Il est aussi conseillé de suspendre ses propres modifications de configuration jusqu’au retour à la normale, afin qu’un éventuel nouveau problème ne se confonde pas avec l’incident.
Pour suivre l’évolution, la documentation de Microsoft indique de consulter la page « État du service » (Service health) du centre d’administration et, en cas d’impossibilité de s’y connecter, la page d’état publique. Microsoft invite aussi à suivre le compte X @MSFT365Status pour certains événements. Comme Outlook et Teams peuvent être touchés ensemble, il vaut mieux informer les équipes par un canal extérieur à Microsoft 365. Les courriels retardés devraient arriver une fois le service revenu.
FAQ
La panne est-elle terminée ?
Pas à notre connaissance. À 8 h 50 le 13 novembre, des résultats positifs étaient annoncés après un correctif, mais, depuis la nuit, des serveurs redémarrés retombaient en panne dès qu’ils recevaient du trafic, et aucun calendrier de retour complet n’était donné.
Mes courriels sont-ils perdus ?
Les messages retardés devraient arriver une fois le service rétabli. Aucune de nos sources ne fait état de courriels perdus.
Est-ce un piratage ?
Microsoft dit n’avoir connaissance d’aucune activité malveillante, et aucune source consultée ne soutient la thèse d’une attaque. La cause exacte reste à confirmer.
Quels services sont concernés ?
Exchange Online et Outlook en premier lieu, puis, selon les clients, Teams, Copilot, Defender, Power Apps et d’autres. SharePoint et le chat Teams seraient en grande partie épargnés.
Où suivre l’évolution ?
Dans le centre d’administration Microsoft 365, sur la page d’état de Microsoft ou sur le compte X @MSFT365Status.
Sources
- Microsoft — Page d’état des services cloud (consultée le 13 novembre 2026 ; contenu d’incident non lisible)
- Microsoft Learn — How to check Microsoft 365 service health (mise à jour de la page le 30 octobre 2026)
- SecurityWeek — Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams (12 novembre 2026)
- CNBC — Widespread Microsoft outage takes down Outlook and other 365 services (12 novembre 2026, mis à jour le 13)
- ITdaily — Microsoft 365 nog offline: Outlook en Teams haperen (13 novembre 2026, mise à jour de 8 h 50)
- azureblog.co.uk — Microsoft 365 outage, 12 November 2026 (13 novembre 2026 ; recopie horodatée des messages de Microsoft, seule source détaillée sur la chronologie)