Le 13 octobre 2026, des utilisateurs de Microsoft 365 en Allemagne et au Royaume-Uni ont perdu l’accès à Outlook, Teams, OneDrive ou SharePoint pendant près de onze heures. La cause ne venait pas des applications elles-mêmes, mais de la couche réseau par laquelle ils y accédaient : Global Secure Access, le service de connexion sécurisée de Microsoft.
- Incident du 13 octobre 2026, de 07 h 40 à 18 h 31 UTC selon la mise à jour finale de Microsoft.
- Seuls les utilisateurs passant par Global Secure Access (GSA) étaient concernés.
- Cause avancée en cours d’incident : une partie de l’infrastructure GSA sous ses seuils de performance.
- Contournement proposé : désactiver GSA, mais seulement en fin de journée.
Les points :
Que s’est-il passé le 13 octobre ? #
D’après le relevé des messages publiés sur la page d’état de Microsoft 365, compilé par IncidentHub, des utilisateurs passant par GSA ne parvenaient plus à joindre plusieurs services : Outlook et Outlook sur le web, OneDrive, SharePoint Online, Microsoft Teams et les PC cloud Windows 365.
À lire Comprendre le cast en C : conversion explicite et implicite expliquées
La zone touchée couvrait l’Allemagne et le Royaume-Uni. Le libellé de l’incident, repris par l’agrégateur IsDown, visait « certains utilisateurs en Allemagne et au Royaume-Uni » accédant à Microsoft 365 via GSA. En fin d’après-midi, le périmètre a été réduit à l’Allemagne seule.
Global Secure Access, c’est quoi ? #
Global Secure Access est la brique de Microsoft Entra qui fait transiter le trafic des postes de travail par le réseau de Microsoft avant qu’il n’atteigne ses destinations. Microsoft la présente dans sa documentation officielle comme sa solution de type SSE (Security Service Edge), qui regroupe l’accès aux applications internes, à Internet et à Microsoft 365.
Ce modèle s’inscrit dans l’approche « zero trust » : au lieu d’un VPN d’entreprise classique, chaque connexion est contrôlée par un service cloud placé entre l’utilisateur et l’application. L’avantage est la sécurité. Le revers, c’est que ce point de passage devient lui-même une dépendance critique.
Comment Microsoft a-t-il rétabli le service ? #
La chronologie relevée par IncidentHub montre une remise en route en trois temps, tous en heure UTC :
À lire Comprendre le cast en C : conversions de type explicites et applications
| Heure (UTC) | Étape |
|---|---|
| 07 h 40 | Début de l’impact, selon la mise à jour finale (les premiers messages indiquaient 08 h 00) |
| 14 h 38 | Optimisations du trafic déployées, baisse des erreurs sans résolution |
| 15 h 24 | Trafic redirigé vers une infrastructure saine |
| 16 h 25 | Redémarrage de la partie d’infrastructure vidée de son trafic |
| 18 h 20 | Désactivation de GSA conseillée en contournement |
| 18 h 31 | Fin de l’impact, confirmée par la télémétrie |
À 14 h 38 puis 14 h 59 UTC, Microsoft expliquait qu’« une section de l’infrastructure GSA fonctionne en dessous des seuils de performance acceptables ». Cette phrase a disparu des messages suivants, et la mise à jour finale ne la reprend pas. Au moment où IncidentHub publiait son analyse, aucun rapport post-incident n’était disponible.
Pourquoi l’incident a-t-il duré si longtemps ? #
Le point le plus marquant tient au contournement. Désactiver GSA permettait de revenir à une connexion directe vers Microsoft 365. Mais cette consigne n’est apparue sur la page d’état publique qu’à 18 h 20 UTC, soit environ dix heures et quarante minutes après le début annoncé, relève IncidentHub.
Pour une équipe informatique, la différence est nette : avec la consigne dès le matin, une bonne partie des utilisateurs aurait pu retrouver sa messagerie en quelques minutes, au prix d’un contrôle de sécurité temporairement allégé.
Un incident réseau, pas applicatif
Outlook, Teams et SharePoint fonctionnaient. C’est le chemin pour y arriver qui était dégradé. Les messages de Microsoft ne précisent d’ailleurs pas si des utilisateurs hors GSA ont été gênés, ce qui laisse penser que l’impact restait cantonné à ceux dont le trafic transitait par le service.
À lire Aide au codage CIM 10 : Comprendre la classification et ses applications
Ce que les administrateurs peuvent en retenir #
Placer un proxy cloud devant toutes ses applications revient à créer un point de passage unique. Si ce maillon faiblit dans une région, tout ce qui est derrière devient injoignable, même quand les services finaux tournent normalement.
La leçon pratique est de préparer à l’avance un mode dégradé : savoir qui peut désactiver le client GSA, pour quels postes, et avec quelles règles d’accès conditionnel en remplacement. Attendre la consigne de l’éditeur peut coûter une journée, comme le 13 octobre.
Enfin, la page d’état publique ne suffit pas toujours. Le centre d’administration Microsoft 365 et son tableau de bord « Service Health » donnent souvent des informations plus fines aux clients concernés, et il vaut mieux les surveiller en parallèle.
Questions fréquentes #
Tous les utilisateurs de Microsoft 365 étaient-ils touchés ?
Non. L’incident concernait les utilisateurs accédant à Microsoft 365 via Global Secure Access, en Allemagne et au Royaume-Uni, puis seulement en Allemagne en fin de journée.
À lire Calcul du contrat de maintenance informatique : Guide complet et conseils pratiques
Combien de temps a duré la panne ?
Environ dix heures et cinquante minutes, de 07 h 40 à 18 h 31 UTC, selon la mise à jour finale de Microsoft relevée par IncidentHub.
Microsoft a-t-il publié la cause exacte ?
Pas de manière définitive. En cours d’incident, Microsoft a évoqué une partie de l’infrastructure GSA sous ses seuils de performance, sans reprendre cette explication dans son message final.
