Depuis le jeudi 12 novembre 2026, une panne de Microsoft 365 prive de nombreuses organisations de leur messagerie Exchange Online et d’une partie de Teams, SharePoint ou Copilot. Pour un responsable de traitement, la question dépasse Outlook : sa PSSI, son PCA et son PRA tiennent-ils encore quand le fournisseur principal tombe ?
L’incident tel que Microsoft le décrit
Microsoft suit la panne sous deux références dans son centre d’administration : EX1550543 pour Exchange Online et MO1550821 pour les autres services de la suite. Les premiers signalements portaient sur l’accès aux boîtes aux lettres sur le continent américain. L’avis MO1550821 a été ouvert à 18 h 26 UTC, soit 19 h 26 à Paris.
Les bulletins citent Exchange Online, Microsoft Teams, SharePoint Online, Microsoft 365 Copilot et Microsoft Defender XDR, puis Planner et To Do. Microsoft précise que les fonctions de ces services qui ne dépendent pas d’Exchange Online continuent de marcher. Chaque client a donc vécu une panne un peu différente, selon ses usages et les composants sollicités.
Sur la cause, l’éditeur décrit des serveurs qui échouent à leurs contrôles de santé automatisés, sortent du service et reportent leur charge sur les autres, alors que le trafic global n’a pas augmenté. Pour rétablir le service, Microsoft a suspendu tous ses déploiements, redistribué les connexions sur son infrastructure mondiale, redémarré les serveurs touchés, isolé un processus central saturé et testé une modification de configuration. Le 13 novembre, les deux incidents restaient ouverts, avec un rétablissement annoncé par étapes. Aucun rapport définitif sur la cause racine n’était publié à cette date, et les bulletins ne font état d’aucune activité malveillante.
L’épisode s’ajoute à d’autres. Le 22 janvier 2026, plusieurs services Microsoft 365 ont été dégradés pendant une dizaine d’heures. Le 31 août, une configuration d’authentification centrale, partagée par plusieurs services, avait déjà provoqué une panne d’Exchange Online étendue à Teams, SharePoint, Purview et Defender XDR. Plusieurs incidents majeurs en dix mois justifient de sortir le sujet de l’exploitation informatique pour le porter devant la direction.
La résilience du fournisseur et ses limites
La réponse de l’éditeur montre des mécanismes de reprise rodés. Elle montre aussi leur plafond : déplacer le trafic vers d’autres serveurs sert peu quand ces serveurs dépendent du même mécanisme défaillant ou saturent à leur tour.
La redondance géographique reste indispensable, sans garantir l’indépendance technique. Plusieurs régions peuvent partager l’authentification, le routage, la configuration ou la supervision. Le nombre de centres de données ne dit rien de la capacité à maintenir le service quand un composant commun cède.
Microsoft documente un dispositif de résilience et de continuité pour ses services cloud, avec une répartition des responsabilités entre l’éditeur et ses clients. Un dispositif formalisé ne prouve pas qu’il couvre tous les scénarios, ni que ses délais de rétablissement conviennent à chaque client.
PSSI et GPSSI : faire entrer les dépendances cloud dans les décisions de sécurité
La PSSI fixe les règles de protection des systèmes et des informations. Sa gouvernance, la GPSSI, valide les risques, les confie à des responsables nommés et suit les mesures décidées. Une forte dépendance à Microsoft 365 relève de ce circuit de décision, au même titre que tout autre risque majeur.
Cartographiez les activités qui reposent sur Exchange Online, Teams, SharePoint, Microsoft Graph, Purview ou les services d’identité et de sécurité associés. Pour chacune, précisez la criticité, les conséquences d’une indisponibilité et les moyens de contournement réellement utilisables.
En théorie, on ne devrait pas avoir ses mails et son outils metier chez microsoft !
La gouvernance doit aussi trancher des questions très concrètes : qui décide d’activer le PCA, qui prévient les utilisateurs et les partenaires, comment les responsables accèdent aux consignes quand les outils habituels sont coupés, et qui accepte les risques résiduels.
PCA : continuer l’activité quand Microsoft 365 est coupé
Le PCA maintient les activités prioritaires pendant l’indisponibilité ; la restauration de Microsoft 365 reste l’affaire de Microsoft. Les scénarios de continuité prévoient donc des moyens de communication indépendants, des listes de contacts accessibles hors ligne, des procédures manuelles et un mode dégradé pour les opérations essentielles.
Une boîte mail ouverte chez un autre fournisseur peut dépanner la cellule de crise. Elle ne reçoit pas pour autant les messages envoyés aux adresses Exchange Online habituelles. Une vraie continuité de messagerie, si elle se justifie, suppose une architecture de secours conçue et testée à froid. Les solutions bricolées pendant la panne ouvrent d’autres risques : fuite d’informations, perte de messages, absence de traçabilité.
PRA : retrouver l’accès, puis remettre les processus d’aplomb
Le PRA ramène les systèmes et les processus à un état maîtrisé. Une fois Microsoft rétabli, il reste à contrôler les messages retardés ou non distribués, les échanges indispensables à l’activité, les automatisations, les connecteurs et les opérations faites à la main pendant la coupure.
Un contrôle de non-duplication des traitements peut s’imposer. Vérifiez aussi que les fonctions de protection, d’audit et de journalisation ont retrouvé leur niveau habituel. Une sauvegarde indépendante de Microsoft 365 protège contre certaines pertes ou altérations de données ; elle ne permet pas, à elle seule, de continuer à échanger pendant une panne d’Exchange Online.
| Dispositif | Question à poser | Mesure attendue |
|---|---|---|
| PSSI / GPSSI | Quels services critiques dépendent d’un composant ou d’un fournisseur commun ? | Cartographie des dépendances, analyse de risques, responsabilités et critères de décision. |
| PCA | Comment poursuivre les activités prioritaires sans Outlook, Teams ou les outils associés ? | Communication de secours, procédures dégradées et exercices documentés. |
| PRA | Comment vérifier le retour à la normale après plusieurs heures d’indisponibilité ? | Priorités de restauration, contrôles d’intégrité et réconciliation des opérations. |
Les conséquences au regard du RGPD
L’article 32 du RGPD impose des mesures appropriées pour garantir la disponibilité et la résilience des systèmes, et pour rétablir l’accès aux données personnelles dans des délais appropriés en cas d’incident. Confier sa messagerie à Microsoft ne dispense pas le responsable de traitement d’évaluer les risques propres à ses activités.
Une panne n’impose pas pour autant de notifier la CNIL. Il faut d’abord établir s’il y a violation de données personnelles, notamment de disponibilité, puis apprécier le risque pour les droits et libertés des personnes. La décision, dans un sens comme dans l’autre, doit être motivée et documentée. Lorsqu’une notification s’impose, le délai de 72 heures de l’article 33 court à partir du moment où le responsable de traitement a pris connaissance de la violation ; le début de la panne chez le prestataire ne le déclenche pas à lui seul.
Les enjeux pèsent plus lourd dans le secteur de la santé, qu’il s’agisse d’établissements, d’EHPAD ou de services de prévention et de santé au travail, quand des informations nécessaires à une prise en charge urgente deviennent inaccessibles. La qualification dépend alors des traitements réellement touchés, des moyens alternatifs disponibles et des conséquences concrètes pour les personnes.
Les actions à engager dans les organisations
- Dès l’incident : enregistrer les services et processus touchés, conserver les communications du fournisseur, identifier les conséquences opérationnelles et les éventuels effets sur les données personnelles.
- À court terme : tester un canal de communication indépendant et vérifier que la cellule de crise accède aux procédures, aux contacts et aux décisions sans Microsoft 365.
- Lors de la revue PSSI, PCA et PRA : définir des objectifs de reprise proportionnés aux activités, formaliser les procédures dégradées et organiser un exercice simulant une coupure simultanée de la messagerie et des outils collaboratifs.
- Après le rapport de Microsoft : confronter la chronologie réelle, les mesures correctives et les engagements du fournisseur aux hypothèses de l’analyse de risques et aux contrats applicables.
À retenir pour les responsables de traitement
Cette panne ne démontre ni une défaillance générale de Microsoft ni un manquement contractuel. Elle illustre un risque bien connu : des services distincts en apparence dépendent de composants techniques communs.
Le plan de continuité de Microsoft couvre les services de Microsoft ; la continuité de vos activités vous revient, comme le prévoit le modèle de responsabilité partagée du cloud. Si votre organisation ne peut plus communiquer, traiter ses opérations essentielles ou réunir sa cellule de crise quand sa plateforme principale tombe, son dispositif est à revoir. Connaître ses dépendances, assumer les risques retenus et tester des solutions de repli réellement indépendantes suffit souvent, sans changer de fournisseur.
Sources
- Microsoft, état officiel des services cloud : status.cloud.microsoft
- Microsoft 365 Status, messages publiés sur X les 12 et 13 novembre 2026 : @MSFT365Status
- StatusStack, chronologie des incidents EX1550543 et MO1550821 : Microsoft 365 and Exchange Online connectivity issues
- SecurityWeek, 12 novembre 2026 : Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams
- BleepingComputer, 12 novembre 2026 : Massive Microsoft 365 outage disrupts Outlook, Teams, Copilot worldwide
- BleepingComputer, 31 août 2026 : Microsoft Exchange Online outage causes email failures, auth issues
- CNIL, Guide de la sécurité des données personnelles
- Règlement (UE) 2016/679 (RGPD), articles 32 et 33 : EUR-Lex
