Panne Outlook : quand le service revient-il ? Chronologie

Panne Outlook : quand Outlook sera-t-il rétabli ?

Réponse courte : Microsoft ne l'a pas dit. À 00:55 UTC le 13 novembre 2026, l'incident était toujours ouvert : le message officiel le plus récent, publié à 00:06 UTC par le compte Microsoft 365 Status sur X, décrivait des serveurs rétablis qui retombaient en panne sous la charge, et aucun message ultérieur ni annonce de fin d'incident n'avait été publié ^[11]. Lors de sa dernière consultation, à 00:30 UTC, la page publique Service Health Status de Microsoft indiquait une dégradation du service pour les services Microsoft 365 destinés aux entreprises, l'impact sur les utilisateurs étant décrit ainsi : « Users may be unable to connect to multiple Microsoft 365 services » ^[1]. La page ne donnait aucune heure estimée de rétablissement complet. Elle promettait seulement la prochaine mise à jour pour 01:30 UTC au plus tard, le vendredi 13 novembre 2026 ^[1]. Le titre de la page indiquait aussi que des produits Microsoft grand public étaient dégradés, sans autre précision dans le texte ^[1].

La mise à jour officielle la plus récente au moment de la vérification, publiée à 00:06 UTC, marquait un recul plutôt qu'une solution. Microsoft a indiqué que les serveurs remis en service « peuvent de nouveau cesser de répondre dès qu'ils reçoivent du trafic » et qu'il analysait des données de diagnostic pour comprendre ce qui déclenche ce phénomène ^[11]. Sa page d'état, mise à jour pour la dernière fois à 00:08:53 UTC lors de la consultation de 00:30 UTC, ajoutait qu'il menait cette analyse avec des experts du réseau et de la plateforme ^[1].

Concrètement, cela signifie trois choses pour ceux qui attendent :

• Le rétablissement ne se fera probablement pas d'un seul coup. Microsoft a indiqué qu'à mesure que la capacité est rétablie, les utilisateurs peuvent constater un retour progressif, au fil de la reconnexion de leurs applications ^[10].
• Le service peut revenir puis retomber. Comme des serveurs rétablis sont retombés en panne sous la charge, une boîte de réception qui fonctionne peut cesser de se charger un moment avant la clôture de l'incident ^[11].
• Seule l'annonce officielle de Microsoft compte. La panne est terminée lorsque la page d'état de Microsoft ou le compte Microsoft 365 Status indique que l'impact est résolu, et non lorsque la boîte de réception d'une seule personne se charge ^[1][2].

Pour les conseils généraux, par exemple comment savoir si Outlook est en panne pour tout le monde, ce que signifient les mentions d'état et comment continuer à travailler hors connexion, consultez le précédent guide de Pouyam Outlook Down? How to Check Status and Keep Working.

Que s'est-il passé, heure par heure (UTC) ?

Toutes les heures ci-dessous sont en temps universel coordonné (UTC). En novembre, l'heure de l'Est des États-Unis a cinq heures de retard sur l'UTC : 17:54 UTC correspond donc à 12:54 pm, heure de l'Est.

Plus tôt dans la journée, un incident distinct sur Teams. Avant la panne de messagerie, Microsoft a traité un incident sur Microsoft Teams, référencé TM1550488, qui selon BleepingComputer a duré de 9:45 à 10:53 am, heure de l'Est (14:45 à 15:53 UTC), et a touché des utilisateurs d'Amérique du Nord et du Sud ^[12]. Microsoft l'a attribué à une contention de ressources et l'a déclaré entièrement résolu ; il n'a pas dit s'il était lié à la panne survenue ensuite ^[12].

17:54 UTC. Le compte Microsoft 365 Status sur X a indiqué que Microsoft enquêtait sur des signalements d'utilisateurs des Amériques ayant des difficultés à accéder à leurs boîtes aux lettres Exchange Online par plusieurs méthodes de connexion, sous l'incident EX1550543 ^[2]. Exchange Online est le service cloud de Microsoft qui héberge les boîtes aux lettres professionnelles et scolaires utilisées par Outlook.

Vers 18:00 UTC (environ 1 pm, heure de l'Est). Les signalements de problèmes avec Outlook sur Downdetector ont culminé à 138058, selon Reuters ^[13].

18:07 UTC. Microsoft a indiqué que le problème pouvait affecter la connectivité aux services Microsoft 365 pour les utilisateurs de toutes les régions ^[3].

18:26 UTC (1:26 pm, heure de l'Est). Selon BleepingComputer, Microsoft donne cette heure comme début de l'incident Microsoft 365 plus large, référencé sous l'avis MO1550821 ^[12].

18:35 UTC. Microsoft a indiqué qu'une partie de son infrastructure subissait une charge élevée dans plusieurs régions, ce qui contribuait probablement aux erreurs de connexion ^[4].

19:31 UTC. Microsoft a corrigé sa première explication : la charge élevée ne venait pas d'une hausse du trafic, mais de l'indisponibilité inattendue d'un certain nombre de serveurs, qui pesait sur le reste de l'infrastructure ^[5].

20:19 UTC. Microsoft a indiqué n'avoir identifié aucune modification récente corrélée au début de l'impact, mais que les échecs des contrôles d'intégrité pouvaient provenir d'un composant précis chargé de traiter l'état des serveurs ^[6].

21:00 UTC. Microsoft a indiqué qu'une autre méthode de contrôle d'intégrité avait permis à une partie des serveurs touchés de reprendre du service, et qu'il étendait ce changement ^[7].

21:40 UTC. Microsoft a indiqué évaluer si l'annulation d'un petit nombre de mises à jour de configuration récentes qu'il avait identifiées pouvait accélérer le rétablissement ^[8].

22:09 UTC. Microsoft a indiqué que ses actions n'avaient pas apporté le soulagement attendu et qu'un processus central des serveurs touchés était submergé, entraînant une perte de capacité ^[9].

23:04 UTC. Microsoft a indiqué qu'une partie des serveurs touchés avait repris du service et restait stable pour l'instant, qu'il redirigeait le trafic vers d'autres itinéraires et observait un rétablissement limité ^[10].

00:06 UTC le 13 novembre. Microsoft a indiqué que des serveurs rétablis pouvaient de nouveau cesser de répondre dès qu'ils recevaient du trafic, qu'il limitait temporairement les types de trafic pouvant atteindre l'infrastructure touchée à certains endroits, et qu'il reconstruisait une partie des serveurs avec une configuration antérieure pour vérifier si cela les empêchait de tomber en panne ^[11].

Quelle est la cause de la panne Outlook ?

Microsoft n'a annoncé aucune cause profonde. Il a décrit comment la défaillance se manifeste, et son explication a changé plusieurs fois au cours de la journée, comme le montre la chronologie ci-dessus. Voici ce que Microsoft a réellement dit, dans ses propres termes :

• Pas d'afflux de trafic. Le problème de charge venait de l'indisponibilité inattendue d'un certain nombre de serveurs, et non d'une hausse du trafic ^[5].
• Des contrôles d'intégrité en échec. Des serveurs échouaient aux contrôles d'intégrité automatiques, et ces échecs pouvaient provenir d'un composant précis chargé de traiter l'état des serveurs ^[6]. Un contrôle d'intégrité est un test automatique qu'un système exécute sur chaque serveur ; un serveur qui échoue est retiré du service.
• Aucune modification correspondante trouvée, dans un premier temps. À 20:19 UTC, Microsoft a indiqué n'avoir identifié aucune modification récente corrélée au début de l'impact ^[6]. À 21:40 UTC, il a indiqué évaluer si l'annulation d'un petit nombre de mises à jour de configuration récentes pouvait aider au rétablissement ^[8]. Microsoft n'a pas dit que ces mises à jour avaient causé la panne.
• Un processus central submergé. À 22:09 UTC, Microsoft a indiqué qu'un processus central des serveurs touchés était submergé, entraînant une perte de capacité ^[9].
• Déclencheur inconnu. À 00:06 UTC, Microsoft a indiqué qu'il analysait toujours ce qui fait que des serveurs rétablis cessent de nouveau de répondre ^[11].

Aucune de ces déclarations ne dit ce qui a déclenché le problème. Microsoft n'a pas dit que la panne était une cyberattaque, ni qu'elle n'en était pas une. Les affirmations relayées sur les réseaux sociaux à propos d'un piratage, d'une mise à jour logicielle précise ou d'un centre de données en particulier ne s'appuient sur aucune déclaration de Microsoft au moment de la vérification.

Pourquoi le rétablissement prend-il autant de temps ?

Les propres mises à jour de Microsoft montrent un rétablissement qui s'est heurté à plusieurs reprises au même obstacle. Selon la description de Microsoft, le schéma a été le suivant :

1. Redémarrer les serveurs et déplacer le trafic. Microsoft a suspendu les déploiements, déplacé le trafic hors de l'infrastructure touchée et redémarré les serveurs concernés ^[12].
2. Changer la méthode de contrôle d'intégrité. Une autre méthode de contrôle d'intégrité a permis de rétablir une partie des serveurs, et Microsoft a commencé à l'appliquer plus largement ^[7].
3. Reconnaître que les premières mesures ne suffisaient pas. À 22:09 UTC, Microsoft a indiqué que ses actions n'avaient pas apporté le soulagement attendu et qu'il isolait une partie de l'infrastructure, redémarrait des composants et réintroduisait du trafic pour confirmer la stabilité avant un changement plus large ^[9].
4. Rétablissement partiel. À 23:04 UTC, certains serveurs avaient repris du service et étaient stables, avec un rétablissement limité observé ^[10].
5. Rechute sous la charge. À 00:06 UTC, Microsoft a indiqué que des serveurs rétablis pouvaient de nouveau cesser de répondre dès que le trafic les atteignait ^[11].

Ce dernier point explique la lenteur. Rétablir un serveur ne suffit pas s'il s'effondre dès que des millions d'applications de messagerie s'y reconnectent. La dernière approche de Microsoft comporte deux volets. D'abord, il limite temporairement les types de trafic pouvant atteindre l'infrastructure touchée à certains endroits. Ensuite, il reconstruit une partie des serveurs touchés avec une configuration antérieure pour vérifier si cela les empêche de cesser de répondre ^[11].

Cette approche est prudente par nature et laisse présager un retour progressif plutôt qu'un moment unique où tout revient. Microsoft a aussi redirigé le trafic vers d'autres itinéraires partout où c'était possible et signalé un rétablissement limité ^[10].

Quelle est l'ampleur de la panne et quels services sont touchés ?

Outlook et Exchange Online sont au centre, mais pas seuls. La page d'état de Microsoft cite comme services potentiellement touchés Exchange Online, Microsoft Teams, SharePoint Online, Microsoft 365 Copilot (indiqué sous le nom « Microsoft Copilot 365 »), Microsoft Defender XDR, Microsoft Planner, Microsoft To Do, Microsoft Intune, Microsoft Defender for Office 365, plusieurs services Microsoft Purview, les exportations Power BI au format PDF avec étiquettes de confidentialité, certaines parties du Microsoft 365 Apps admin center, Universal Print et certains Cloud PC Windows 365 qui utilisent Purview Customer Key ^[1].

Signalements d'utilisateurs. Downdetector, qui recueille les signalements envoyés par les utilisateurs, a enregistré un pic de 138058 signalements de problèmes avec Outlook vers 1 pm, heure de l'Est, retombé à environ 34490 dans la soirée, selon Reuters ^[13]. Reuters a aussi rapporté qu'à 5:47 pm, heure de l'Est, on comptait près de 13000 signalements pour Microsoft 365 et 763 pour Teams ^[13]. Ces chiffres comptent les plaintes envoyées par des utilisateurs, pas le nombre de personnes touchées.

Effets en cascade. Reuters a rapporté que les connecteurs utilisés par les services d'IA d'OpenAI et d'Anthropic pour accéder à Microsoft 365 avaient eux aussi été touchés, et que le fabricant de camions électriques Workhorse Group avait reporté la publication de ses résultats du troisième trimestre du 12 au 16 novembre, en invoquant les perturbations causées par la panne ^[13].

Ce que Microsoft a dit à la presse. Un porte-parole de Microsoft a déclaré que l'entreprise était « au courant et enquêtait sur des signalements d'utilisateurs rencontrant des problèmes avec les services Microsoft 365, principalement avec Exchange Online », selon Reuters et The Verge ^[13][14]. The Verge a rapporté qu'à partir d'un peu avant 1 pm, heure de l'Est, jeudi, des signalements sont arrivés du monde entier de personnes incapables d'accéder à leurs e-mails Outlook sur le web ou dans les applications ^[14].

Que faire pendant la panne d'Outlook ?

La défaillance se situe dans les centres de données de Microsoft : rien sur un téléphone ou un ordinateur ne la corrigera. Les mesures les plus utiles sont simples :

Pour tout le monde

• Suivez une seule source officielle. La page publique Service Health Status de Microsoft et le compte Microsoft 365 Status sur X publient les mises à jour officielles ; Microsoft renvoie vers la page d'état lorsque le centre d'administration n'est pas accessible ^[1][11].
• Ne reconfigurez rien. Microsoft décrit un problème côté serveur avec un rétablissement progressif au fil de la reconnexion des clients ^[10]. Supprimer puis rajouter un compte pendant la panne vous donnera du travail plus tard sans rien accélérer.
• Attendez-vous à des retards, puis vérifiez. Une fois le service rétabli, vérifiez le dossier Éléments envoyés et la boîte d'envoi pour voir ce qui est réellement parti, et ne renvoyez que ce qui manque.
• Pour la liste complète, y compris le travail hors connexion, Outlook sur le web par rapport aux applications, la lecture des codes d'erreur et la protection contre l'hameçonnage exploitant la panne, consultez Outlook Down? How to Check Status and Keep Working. Elle n'est pas reprise ici.

Pour les administrateurs Microsoft 365

• Suivez EX1550543 (Exchange Online) et MO1550821 (Microsoft 365 au sens large) dans État du service du Microsoft 365 admin center, ou sur la page d'état publique si le centre d'administration ne se charge pas ^[2][11].
• Informez le personnel une seule fois, en indiquant l'heure de la prochaine mise à jour, plutôt que de répondre à chaque ticket. La prochaine mise à jour de Microsoft était attendue pour 01:30 UTC au plus tard le 13 novembre, selon la page d'état consultée à 00:30 UTC ^[1].
• Attendez-vous à ce que certains utilisateurs retrouvent l'accès avant d'autres, et que certains le perdent de nouveau, car Microsoft remet les serveurs en service par étapes et limite certains types de trafic à certains endroits ^[10][11].

Ce qu'il faut surveiller ensuite

Trois signaux montreront si la panne touche à sa fin :

• Si les serveurs reconstruits tiennent. Microsoft a indiqué reconstruire une partie des serveurs avec une configuration antérieure pour vérifier si cela les empêche de tomber en panne ^[11]. L'annonce d'un déploiement à grande échelle serait le signe le plus clair d'une solution.
• Si les limites de trafic sont levées. Microsoft limite temporairement les types de trafic pouvant atteindre l'infrastructure touchée à certains endroits ^[11]. Leur levée indiquerait que les serveurs peuvent de nouveau supporter une charge normale.
• Une annonce claire de fin d'incident et une cause. Tant que Microsoft n'indique pas que l'impact est résolu, l'incident reste ouvert. Tant qu'il ne nomme pas de cause, toute explication sur les réseaux sociaux relève de la spéculation ^[6][11].

Chaque état décrit ci-dessus est valable à 00:55 UTC le 13 novembre 2026 (la page d'état elle-même a été consultée pour la dernière fois à 00:30 UTC). La situation évoluait d'heure en heure ; c'est la page d'état de Microsoft qui permet de confirmer la situation actuelle ^[1].