Depuis début avril 2024, de nombreux locataires Microsoft 365 subissent des déconnexions automatiques dans Outlook sur le Web malgré « Rester connecté ». Voici un guide concret pour comprendre la cause, appliquer des contournements fiables et outiller les admins jusqu’au correctif officiel.
Vue d’ensemble du problème
À partir du 1er avril 2024, des vagues de déconnexions intempestives touchent Outlook sur le Web (OWA). Les utilisateurs sont renvoyés vers la page d’authentification, parfois plusieurs fois par jour, même après avoir coché « Rester connecté ». Dans le même temps, d’autres symptômes apparaissent : impossibilité d’afficher certaines images intégrées, échecs lors de l’enregistrement ou de la pré‑visualisation de pièces jointes, et messages d’erreur sporadiques lors de l’ouverture de liens sécurisés.
Plusieurs identifiants d’incident Microsoft (notamment EX764050, EX766938, EX764043 et EX772176) ont circulé dans les centres d’administration. Leur point commun suggère une régression côté service impliquant la gestion des cookies et des sessions OWA : quand le jeton ou le cookie de session est invalidé trop tôt ou mal interprété, la session est fermée brutalement, ce qui se manifeste aussi par l’échec de chargement de ressources telles que les images et pièces jointes.
À qui cela arrive et dans quelles conditions ?
- Utilisateurs exclusivement Web : celles et ceux qui n’utilisent que OWA sont les plus exposés, puisqu’ils dépendent entièrement des cookies et de la persistance des sessions dans le navigateur.
- Environnements avec politiques renforcées : des stratégies Conditional Access (CA) incluant Sign-in frequency courte, session non persistante ou Continuous Access Evaluation (CAE) très stricte amplifient l’impact.
- Navigateur & extensions : le bug semble indépendant du navigateur (Chrome, Edge, Firefox, Safari), mais des extensions de confidentialité/antitracking ou un blocage des cookies tiers aggravent les déconnexions.
Synthèse des solutions et contournements
| Piste | Détails | Efficacité constatée |
|---|---|---|
| Rafraîchir l’URL après la déconnexion | Au lieu de se reconnecter, retaper ou recharger l’URL d’OWA : la boîte de réception s’ouvre parfois sans authentification supplémentaire. | Workaround rapide mais pas toujours fiable. |
| Vider le cache et les cookies du navigateur | Supprime les jetons corrompus susceptibles de provoquer une invalidation prématurée de session. | Soulagé momentanément ; l’effet peut disparaître après quelques minutes ou heures. |
| Vérifier les paramètres cookies/extension | S’assurer que le navigateur ne supprime pas les cookies à la fermeture ; désactiver les extensions de sécurité, d’ad‑blocking ou de confidentialité susceptibles d’intercepter les cookies Microsoft. | Variable selon l’environnement utilisateur. |
| Changer ou mettre à jour de navigateur | Testé sur Chrome, Edge et Safari : le bug est plutôt côté service, mais une version à jour limite les conflits. | Limité : le problème persiste pour la plupart. |
| Surveiller « État du service » (M365 Admin Center) | Les références d’incident indiquent que Microsoft enquête déjà. Suivre les mises à jour officielles ou ouvrir un ticket pour faire remonter l’impact. | Recommandé : seule action permettant une résolution définitive côté Microsoft. |
| Ajuster les stratégies de session Azure AD (administrateurs) | Vérifier la durée de vie des sessions (Sign-in frequency), la persistance du navigateur et la configuration CAE. Des réglages trop agressifs amplifient l’effet d’un bug côté service. | Utile si votre organisation applique des politiques personnalisées. |
| Alternatives temporaires | Utiliser Outlook Desktop ou les apps mobiles iOS/Android (le plus souvent non impactées). Ouvrir OWA en fenêtre de navigation privée pour isoler les cookies. | Réduit la gêne en attendant le correctif. |
Symptômes détaillés
- Déconnexions récurrentes malgré « Rester connecté » (Keep me signed in).
- Images intégrées qui ne s’affichent plus, placeholders vides ou icônes d’erreur.
- Pièces jointes impossibles à pré‑visualiser ou à enregistrer (blob inaccessible, erreurs temporaires).
- Demandes d’autorisation répétées (consentement, cookies, notifications) qui ne sont pas mémorisées.
- Problèmes plus fréquents lors d’un basculement de réseau (Wi‑Fi <> 4G, VPN), typiquement déclenchés par CAE.
Cause probable : sessions et cookies OWA invalidés trop tôt
OWA s’appuie sur un enchaînement d’éléments : authentification (Azure AD), jetons (accès/actualisation), cookies de session et en‑têtes de sécurité (SameSite, Secure, HttpOnly). Un changement coté service début avril 2024 semble avoir introduit une incohérence : le navigateur pense que la session est valide alors que le service la considère expirée, ou inversement. Résultat : rafraîchissement forcé, perte d’état, et impossibilité d’accéder à des ressources comme les images et pièces jointes qui dépendent de cette session.
Ce phénomène est accentué lorsque :
- Les cookies tiers sont bloqués (paramètres du navigateur ou extensions anti‑tracking), empêchant la bonne circulation des informations entre domaines Microsoft (ex. outlook.office.com et login.microsoftonline.com).
- Des stratégies CA imposent des expirations agressives (Sign-in frequency de quelques heures, session non persistante) ou une évaluation continue (CAE) sensible aux variations de réseau, d’IP publique ou d’emplacement.
- Des proxys d’entreprise et l’inspection TLS altèrent les en‑têtes, cassant la persistance des cookies marqués SameSite=None; Secure.
Procédures détaillées côté utilisateur
Vérifications rapides
- Après une déconnexion, rechargez l’URL d’OWA (F5 ou Ctrl/Cmd+R). Si la boîte de réception réapparaît sans retaper le mot de passe, votre cookie était encore présent mais mal reconnu : c’est un bon indicateur du bug décrit.
- Ouvrez OWA dans une fenêtre privée (InPrivate/Incognito). Si le problème disparaît, suspectez des extensions ou un profil de navigateur corrompu.
- Désactivez temporairement les extensions de confidentialité/ad‑blocking/antivirus navigateur, puis réessayez.
Chrome / Edge (Chromium)
- Paramètres > Confidentialité et sécurité > Cookies et autres données des sites.
Assurez‑vous que Bloquer les cookies tiers n’est pas activé, ou ajoutez des exceptions pour :
- outlook.office.com
- login.microsoftonline.com
- office.com et office365.com si utilisés dans votre tenant
- Paramètres > Confidentialité et sécurité > Effacer les données de navigation > Cookies et autres données + Images et fichiers en cache. Redémarrez le navigateur.
- Edge uniquement : Paramètres > Confidentialité > Choisir ce qui est effacé à chaque fermeture : désactivez la suppression automatique des cookies.
- Essayez en mode Invité (profil vierge) pour isoler le problème.
Firefox
- Options > Vie privée et sécurité > Protection renforcée contre le pistage = Standard (évitez Strict pour OWA) ou ajoutez des exceptions pour outlook.office.com et login.microsoftonline.com.
- Cookies et données de sites > Gérer les données > supprimez les entrées liées à OWA puis reconnectez‑vous.
Safari (macOS / iOS/iPadOS)
- Réglages > Safari > Confidentialité : ne pas activer « Bloquer tous les cookies ».
- Effacer historique et données de site, puis forcez la fermeture de Safari et réessayez.
- Sur iOS/iPadOS, vérifiez que la prévention du suivi ne bloque pas inadvertamment des cookies inter‑sites nécessaires à OWA.
Nouvelle application Outlook pour Windows (WebView2)
Si vous utilisez la « nouvelle » application Outlook basée sur WebView2, sachez qu’elle s’appuie sur une enveloppe Web. Les mêmes recommandations en matière de cookies s’appliquent. En cas de doute, basculez temporairement sur Outlook Desktop classique (canal MAPI) ou l’application mobile.
Procédures côté administrateur
Suivi de l’état du service et ouverture de ticket
- Dans le centre d’administration Microsoft 365, consultez Santé du service (Exchange Online / Outlook) et suivez les incidents EX764050, EX766938, EX764043, EX772176 ou ultérieurs.
- Ouvrez un ticket de support si votre impact est significatif : nombre d’utilisateurs, régions, fréquence des déconnexions, captures HAR (voir plus bas). Votre signalement améliore la priorisation du correctif.
Vérifier et adoucir les stratégies Conditional Access (CA)
Un paramétrage trop strict peut transformer un bug transitoire côté service en panne quotidienne. Contrôlez en priorité :
- Sign-in frequency (fréquence de reconnexion) : si vous avez fixé quelques heures ou 1 jour, remontez à 7–30 jours ou revenez à Non configuré le temps du correctif.
- Persistent browser session (persistance de session navigateur) : positionnez sur Always persistent pour les comptes utilisateurs standards (ou un groupe pilote) afin d’éviter les pertes de session.
- Continuous Access Evaluation (CAE) : laissez activé pour la sécurité, mais temporairement, vous pouvez exclure un groupe test ou OWA pour valider l’impact.
Exemple PowerShell (Microsoft Graph) pour auditer rapidement
# Nécessite le module Microsoft.Graph
Install-Module Microsoft.Graph -Scope CurrentUser
Import-Module Microsoft.Graph
Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All","ServiceHealth.Read.All"
# 1) Lister les politiques Conditional Access pertinentes
$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | Select-Object DisplayName,
@{n="PersistentBrowser";e={$*.SessionControls.PersistentBrowser.Mode}},
@{n="SignInFrequencyEnabled";e={$*.SessionControls.SignInFrequency.IsEnabled}},
@{n="SignInFrequencyValue";e={$*.SessionControls.SignInFrequency.Value}},
@{n="SignInFrequencyType";e={$*.SessionControls.SignInFrequency.Type}} | Format-Table -AutoSize
# 2) Repérer les incidents Outlook/Exchange récents
Get-MgServiceAnnouncementIssue -All |
Where-Object { $_.Service -match "Outlook|Exchange" } |
Select-Object Id, Title, Status, StartDateTime, LastUpdatedDateTime |
Sort-Object LastUpdatedDateTime -Descending Examiner les politiques d’effacement de cookies
Vérifiez les GPO/MDM qui effacent les données à la fermeture du navigateur :
- Edge/Chrome : ClearBrowsingDataOnExit, DefaultCookiesSetting, listes d’exceptions de sites approuvés.
- Firefox : paramètres de suppression à la fermeture, protection stricte, politiques Enterprise.
Recommandation : suspendre l’effacement automatique des cookies pour les domaines Microsoft le temps de la résolution.
Proxys, inspection TLS et IP flottantes
- Évitez l’inspection TLS sur les domaines d’authentification Microsoft : l’altération des en‑têtes peut invalider les cookies (SameSite=None; Secure).
- Assurez une sortie Internet stable (NAT egress) pour limiter les déclencheurs CAE lors de changements d’IP publique.
- Ajoutez des exceptions pour les domaines d’authentification et OWA si une passerelle web filtre agressivement.
Diagnostic avancé côté navigateur
- Ouvrez les outils de développement (F12), onglet Network, cochez Preserve log, puis reproduisez la déconnexion.
- Repérez les requêtes vers outlook.office.com et login.microsoftonline.com qui renvoient 302/401 immédiatement avant la déconnexion.
- Inspectez les cookies et en‑têtes Set-Cookie : vérifiez la présence d’attributs SameSite=None; Secure, la date d’expiration et le domaine.
- Exportez un HAR du scénario et joignez‑le à votre ticket de support (masquez les données sensibles).
Checklist en un coup d’œil
- Informer les utilisateurs du rechargement d’URL comme contournement.
- Mettre à jour le navigateur et tester en mode privé / profil Invité.
- Vider cookies/cache OWA et désactiver provisoirement les extensions de confidentialité.
- Autoriser les cookies tiers (ou exceptions) pour outlook.office.com et login.microsoftonline.com.
- Assouplir Sign-in frequency et activer Persistent browser session pour un groupe pilote.
- Surveiller la Santé du service M365 et ouvrir un ticket si impact notable.
Bonnes pratiques jusqu’au correctif officiel
- Communiquer aux utilisateurs le contournement par rechargement d’URL et la possibilité d’utiliser Outlook Desktop / mobile.
- Centraliser les remontées (fréquence, heure, navigateur, extensions, réseau) pour étayer le ticket Microsoft.
- Limiter le nettoyage automatique des cookies dans les GPO/MDM tant que la panne subsiste.
Modèle de message à adresser aux utilisateurs
Objet : Déconnexions OWA – contournement et suivi
Nous rencontrons actuellement des déconnexions automatiques dans Outlook sur le Web. En attendant le correctif, merci de recharger la page lorsque cela se produit, ou d’utiliser Outlook Desktop / l’application mobile. Nous suivons l’incident côté Microsoft et vous tiendrons informés.
FAQ
« Pourquoi “Rester connecté” ne fonctionne pas ? »
Parce que la session est invalidée par le service ou ses cookies ne sont pas reconnus. La case « Rester connecté » persiste le contexte, mais si un composant côté service invalide prématurément ou si le navigateur bloque des cookies inter‑sites, la promesse ne peut pas être tenue.
« Est‑ce un problème de notre configuration ? »
Les paramètres locaux (cookies, extensions, politiques CA) peuvent aggraver la situation, mais la source est avant tout un bug côté service observé mondialement depuis début avril 2024.
« Outlook Desktop ou mobile est‑il impacté ? »
Dans la plupart des cas, non. Ces clients utilisent des mécanismes d’authentification différents et ne dépendent pas des cookies du navigateur. Ils constituent une alternative temporaire fiable.
« Quand cela sera‑t‑il corrigé ? »
La correction définitive dépend d’un déploiement Microsoft. D’où l’importance de surveiller Santé du service et d’ouvrir un ticket pour signaler l’impact.
Tableau récapitulatif : paramètres clés à vérifier
| Zone | Paramètre | Valeur conseillée (temporaire) | Objectif |
|---|---|---|---|
| Navigateur | Cookies tiers | Autoriser (ou exceptions ciblées) | Permettre l’échange entre domaines Microsoft (OWA & login). |
| Navigateur | Suppression des cookies à la fermeture | Désactivée | Éviter la perte de session à chaque relance. |
| Conditional Access | Sign-in frequency | ≥ 7 jours, ou non configuré | Réduire les reconnexions forcées. |
| Conditional Access | Persistent browser session | Always persistent | Stabiliser la session OWA. |
| Réseau | Inspection TLS / Proxy | Exclure OWA & auth Microsoft | Éviter la corruption des cookies/en‑têtes. |
Plan d’action suggéré (administrateurs)
- Jour 1–2 : informer, activer les contournements (rechargement d’URL, clients alternatifs), collecter les preuves (HAR), désactiver l’effacement auto des cookies.
- Jour 2–3 : ajuster CA (Sign-in frequency, session persistante), isoler un groupe pilote, vérifier proxy/inspection TLS, répertorier les extensions problématiques.
- Jour 3+ : suivre Santé du service et alimenter le ticket Microsoft, mesurer la baisse des incidents, consolider les changements utiles (tout en prévoyant un retour en arrière après correctif officiel).
Quand escalader au support Microsoft ?
- Le taux de déconnexion reste > 5–10 % des sessions malgré les contournements.
- Les déconnexions touchent des groupes entiers ou plusieurs régions.
- Les erreurs de pièces jointes/images persistent en navigation privée et sur plusieurs navigateurs.
Incluez : captures HAR anonymisées, heures précises (UTC), type de navigateur/version, extensions, changements CA récents, présence de proxy/inspection TLS, et l’incident de référence (EX764050, EX766938…).
Conclusion
Les déconnexions intempestives d’Outlook sur le Web observées depuis avril 2024 résultent d’une régression côté service aggravée par certains réglages client et politiques d’entreprise. Les actions côté utilisateur (rechargement d’URL, cookies, extensions) n’apportent qu’un soulagement partiel. La stabilisation durable dépend d’un correctif Microsoft, d’où l’importance de surveiller la Santé du service et d’ouvrir un ticket de support en consolidant les preuves. En attendant, combinez : rechargement manuel d’OWA, assouplissement ciblé des politiques CA (session persistante, fréquence raisonnable), suspension du nettoyage automatique des cookies, et bascule vers Outlook Desktop ou mobile pour les profils les plus exposés.
Mémo rapide
- Contournements utilisateurs : recharger l’URL, navigation privée, désactiver les extensions, vider cookies/cache.
- Paramètres admins : Sign-in frequency ≥ 7 jours, session persistante, surveiller CAE, exceptions proxy/TLS, suspendre l’effacement auto des cookies.
- Suivi : Santé du service, incidents EX764050 / EX766938 / EX764043 / EX772176, ticket avec HAR et métriques d’impact.