OWA : impossible d’ouvrir une boîte partagée — erreur « You might not have permission » [Guide de dépannage Microsoft 365]

Dans Outlook sur le web (OWA), l’ouverture d’une boîte aux lettres partagée peut échouer avec « Can’t complete your request – You might not have permission ». Voici un guide opérationnel, éprouvé sur le terrain, pour identifier la cause, appliquer des contournements rapides et corriger durablement le problème dans Microsoft 365/Exchange Online.

Sommaire

Vue d’ensemble du problème

De nombreux utilisateurs rapportent l’impossibilité d’ouvrir certaines boîtes aux lettres partagées directement dans OWA. Le message observé est le plus souvent : « Can’t complete your request. You might not have permission to perform this action. »

Symptômes typiques

L’erreur se produit sur plusieurs navigateurs (Edge, Chrome, Firefox), comptes et postes.
La même boîte partagée s’ouvre correctement dans Outlook Desktop ou Outlook Mobile.
Un essai en navigation privée/Incognito fonctionne de manière intermittente.
La suppression de l’historique/cookies résout temporairement, puis l’erreur réapparaît.

Pourquoi Outlook Desktop/Mobile ne sont pas impactés

OWA s’appuie sur des sessions web (cookies, stockage local, jetons OAuth) et des appels REST/Graph. Outlook Desktop utilise un chemin d’accès et un cache différents (autodiscover, MAPI/HTTP, profils locaux), et Outlook Mobile opère via des services interposés côté cloud. Un défaut spécifique à OWA peut donc bloquer l’accès web tout en laissant intacts les clients natifs.

Cause principale identifiée

Un incident de service côté Microsoft 365 a été documenté sous la référence EX777095 : une publication OWA défectueuse a provoqué l’échec de certaines requêtes d’accès aux boîtes partagées. Un correctif a été déployé côté service ; toutefois, des effets résiduels ont pu persister le temps de la propagation ou à cause de caches côté navigateur. Même en dehors d’un incident actif, des sessions web incohérentes (cookies obsolètes, extensions interférentes, jetons expirés) peuvent reproduire exactement les mêmes symptômes.

Contournements rapides et efficaces

Se déconnecter d’OWA, purger la session/cookies, puis rouvrir via le lien direct de la boîte partagée et se reconnecter.
Utiliser Outlook Desktop ou Outlook Mobile en attendant la résolution côté web.
Ouvrir OWA en mode privé/Incognito ou depuis un nouveau profil navigateur (profil frais, sans extensions).
Mettre à jour le navigateur et Windows ; redémarrer la machine pour invalider les caches réseau/processus.

Récapitulatif des contournements

Action	Quand l’utiliser	Résultat attendu	Limites
Déconnexion OWA + réouverture via lien direct	Erreur immédiate sur OWA, droits supposés corrects	Nouvelle session propre et routage direct vers la boîte partagée	Peut nécessiter une purge ciblée des cookies si l’erreur réapparaît
Navigation privée/Incognito	Besoin d’un test rapide sans affecter le profil principal	Bypass du cache/cookies, succès fréquent	Session éphémère, non pratique au quotidien
Nouveau profil navigateur	Profil principal « chargé » d’extensions ou de cookies	Environnement propre et reproductible	Nécessite une configuration initiale (favoris, SSO, etc.)
Outlook Desktop/Mobile	Besoins opérationnels immédiats	Accès stable aux boîtes partagées	Ne corrige pas le problème OWA lui‑même
Mise à jour OS/navigateur	Versions anciennes, bugs connus, extensions obsolètes	Compatibilités et sécurité améliorées	Ne résout pas toutes les causes côté service

Procédure de dépannage pas à pas

Vérifier l’état du service Microsoft 365
Dans le Centre d’administration, ouvrez État du service et cherchez des mentions relatives à OWA/Exchange Online (ex. EX777095). S’il existe un incident actif : privilégiez les contournements rapides ci‑dessus et surveillez la résolution.
Isoler un problème de session
Essayez immédiatement en navigation privée. Si cela fonctionne, le problème est local au profil navigateur. Poursuivez avec un nouveau profil pour confirmer.
Nettoyer les données site de manière ciblée
Supprimez cache/cookies uniquement pour les domaines Microsoft concernés : *.office.com, *.outlook.com, outlook.office.com. Évitez un « vider tout » qui déconnecterait inutilement d’autres services.
Tester l’URL directe de la boîte partagée
Accédez au format :
https://outlook.office.com/mail/<boite-partagee>@domaine.tld/
puis authentifiez‑vous. Ce test contourne certaines étapes d’initialisation OWA qui échouent lorsqu’on passe par « Ouvrir une autre boîte aux lettres ».
Confirmer les droits Exchange Online
La combinaison minimale pour ouvrir et lire une boîte partagée est FullAccess. Pour envoyer au nom de la boîte, ajoutez SendAs. Vérifiez que les entrées ne sont pas Deny et qu’aucune délégation obsolète ne subsiste.
Retirer puis réajouter les droits
En présence d’artefacts historiques (ancien compte, groupe supprimé), retirez explicitement les délégations puis réappliquez‑les proprement. Attendez la propagation et renouvelez la session OWA.
Vérifier les permissions de dossier
Certaines organisations imposent des ACL au niveau des dossiers (ex. Boîte de réception). Si l’ouverture passe mais que le contenu reste vide, contrôlez Mailbox Folder Permissions sur les dossiers clés.
Contrôler les politiques OWA et la conformité
Des politiques OWA restrictives, une étiquette de confidentialité ou une DLP agressive peuvent bloquer certaines actions. Comparez le comportement entre utilisateurs, boîtes et sites.
Écarter les interférences navigateur/SSO
Désactivez temporairement les extensions : bloqueurs de contenu, SSO corporate, gestionnaires de cookies. Testez également sans inspection TLS ou réécriture d’URL par un proxy de sécurité.
Mettre à jour et redémarrer
Mettez à jour le navigateur, Windows et redémarrez pour invalider les processus figés ou modules obsolètes.
Comparer sur un autre poste/réseau
Un test croisé (poste propre, autre réseau) permet de trancher entre cause locale et service.
Documenter, ouvrir un ticket si nécessaire
En cas de persistance généralisée, regroupez les journaux (heure, tenant, UPN, ID de corrélation OWA si disponible) et escaladez au support.

Commandes PowerShell utiles

Exécutez ces commandes avec le module ExchangeOnlineManagement ; démarrez par Connect-ExchangeOnline avec un compte disposant des rôles nécessaires.

Vérifier l’accès complet

# Vérifier FullAccess (sans entrées Deny)
Get-MailboxPermission "SharedMBX" | Where-Object {
  $_.User -match "user@domaine.tld" -and
  $_.AccessRights -contains "FullAccess" -and
  -not $_.Deny
}

Vérifier SendAs

Get-RecipientPermission "SharedMBX" | Where-Object {
  $_.Trustee -match "user@domaine.tld" -and
  $_.AccessRights -contains "SendAs"
}

Ajouter/retirer des droits

# Ajouter FullAccess (sans mappage auto Outlook Desktop si souhaité)
Add-MailboxPermission -Identity "SharedMBX" -User user@domaine.tld -AccessRights FullAccess -AutoMapping:$false

# Retirer puis réajouter pour « nettoyer » les entrées obsolètes

Remove-MailboxPermission -Identity "SharedMBX" -User [user@domaine.tld](mailto:user@domaine.tld) -AccessRights FullAccess -Confirm:\$false
Add-MailboxPermission -Identity "SharedMBX" -User [user@domaine.tld](mailto:user@domaine.tld) -AccessRights FullAccess

# Ajouter SendAs

Add-RecipientPermission -Identity "SharedMBX" -Trustee [user@domaine.tld](mailto:user@domaine.tld) -AccessRights SendAs -Confirm:\$false

Contrôler les permissions de dossiers

# Lire les permissions sur la Boîte de réception de la boîte partagée
Get-MailboxFolderPermission "SharedMBX:\Boîte de réception"

# Accorder un accès lecture

Add-MailboxFolderPermission "SharedMBX:\Boîte de réception" -User [user@domaine.tld](mailto:user@domaine.tld) -AccessRights Reviewer

Automatiser sur une liste d’utilisateurs

$csv = Import-Csv .\delegations.csv # colonnes: Mailbox,User
foreach ($row in $csv) {
  try {
    Add-MailboxPermission -Identity $row.Mailbox -User $row.User -AccessRights FullAccess -ErrorAction Stop
    Add-RecipientPermission -Identity $row.Mailbox -Trustee $row.User -AccessRights SendAs -Confirm:$false -ErrorAction Stop
    Write-Host "OK: $($row.Mailbox) -> $($row.User)"
  } catch {
    Write-Warning "ERREUR: $($row.Mailbox) -> $($row.User) : $_"
  }
}

Vérifications navigateur détaillées

Procédez d’abord à des tests sans extensions. Ensuite, faites un nettoyage ciblé des données site, uniquement sur les domaines Microsoft nécessaires.

Navigateur	Chemin d’accès aux données site	Domaines à nettoyer	Notes
Microsoft Edge	`edge://settings/siteData`	`outlook.office.com`, `.office.com`, `.outlook.com`	Vérifier les politiques d’entreprise et profils synchronisés
Google Chrome	`chrome://settings/siteData`	`outlook.office.com`, `.office.com`, `.outlook.com`	Supprimer en priorité cookies, stockage local et cache
Mozilla Firefox	Paramètres → Vie privée → Cookies et données	Rechercher et supprimer les entrées `office` / `outlook`	Vider le cache web sans toucher aux mots de passe enregistrés

Si votre entreprise utilise un proxy d’inspection TLS : vérifiez que les hôtes outlook.office.com, substrate.office.com, graph.microsoft.com ne sont pas altérés (certificats réécrits, en-têtes modifiés). Une inspection trop intrusive peut invalider les jetons OWA.

Scénarios fréquents et corrections rapides

Scénario	Diagnostic	Correction
OWA échoue, mode privé fonctionne	Cookies/stockage local corrompus	Nettoyage ciblé des domaines Microsoft, déconnexion/reconnexion
OWA échoue pour un seul utilisateur	Jeton ou extension spécifique à son profil	Nouveau profil navigateur, désactivation des extensions SSO/bloqueurs
OWA échoue pour plusieurs utilisateurs	Incident de service OWA (ex. EX777095) ou proxy d’entreprise	Appliquer les contournements, surveiller l’état du service, exclure l’inspection TLS
Ouverture OK mais courrier vide	ACL de dossiers insuffisantes	Ajouter des Mailbox Folder Permissions sur les dossiers clés
Lecture OK, envoi impossible	Droit SendAs manquant	Ajouter `SendAs` en plus de `FullAccess`
Problème uniquement en Wi‑Fi invité	Filtrage réseau/DNS	Autoriser les domaines Microsoft 365, vérifier le split‑DNS

Bonnes pratiques pour éviter les récidives

Standardiser une procédure de purge ciblée des données site Microsoft pour le support de niveau 1.
Généraliser les profils navigateur séparés pour l’usage professionnel (moins d’extensions, SSO maîtrisé).
Documenter un runbook d’administration pour retirer/réappliquer les droits de manière reproductible.
Mettre en place une veille de l’état du service et prévenir proactivement les utilisateurs en cas d’incident OWA.
Éviter l’inspection TLS sur les hôtes Microsoft 365 critiques pour l’authentification et les API.
Auditer régulièrement les délégations pour supprimer les entrées orphelines liées à d’anciens comptes ou groupes.
Tenir à jour navigateurs et OS, et imposer des politiques d’extensions claires.

FAQ

Pourquoi l’URL directe fonctionne quand « Ouvrir une autre boîte aux lettres » échoue ?

L’URL directe force OWA à initialiser la session sur la boîte cible, évitant certaines étapes de navigation interne où des cookies/jetons défaillent.

Combien de temps faut‑il pour que les nouveaux droits soient actifs ?

La plupart des délégations se propagent en quelques minutes, mais prévoyez jusqu’à une heure. Une nouvelle session OWA est parfois nécessaire.

Faut‑il accorder SendOnBehalf en plus de SendAs ?

Non, ce sont des modèles différents. SendAs envoie comme la boîte partagée ; SendOnBehalf indique « au nom de ».

Nettoyer tous les cookies du navigateur est‑il recommandé ?

Privilégiez le nettoyage ciblé sur les domaines Microsoft pour éviter de perturber d’autres services.

Pourquoi un seul utilisateur est touché ?

Le plus souvent : extension, profil navigateur corrompu, ou jeton d’authentification incohérent uniquement sur son poste.

Comment vérifier les permissions sans droits d’admin ?

Demandez à un administrateur Exchange Online l’extraction des permissions via PowerShell et la capture d’écran des résultats.

Les groupes de sécurité dynamiques posent‑ils problème ?

Ils peuvent introduire un délai de propagation. Pour lever le doute, testez temporairement avec une délégation directe à l’utilisateur.

Quelles traces fournir au support ?

Date/heure, UPN, boîte partagée, navigateur/version, capture de l’erreur et, si possible, ID de corrélation OWA figurant parfois dans les détails techniques.

Un changement de mot de passe peut‑il causer l’erreur ?

Oui, s’il invalide des sessions, surtout avec des extensions ou un SSO qui conservent des jetons périmés. Une reconnexion propre résout en général.

Faut‑il récréer la boîte partagée ?

Très rarement. Avant une action destructrice, épuisez les pistes : session, permissions, politiques, réseau, incident côté service.

Journal de correction type pour l’équipe support

Confirmer l’incident de service (si présent) et informer les utilisateurs.
Appliquer les contournements : déconnexion + URL directe, navigation privée, nouveau profil.
Nettoyer les données site Microsoft, désactiver les extensions bloquantes.
Vérifier/reposer FullAccess et SendAs, puis permissions de dossiers.
Tester sur un second poste et réseau pour isoler l’environnement.
Documenter et, si nécessaire, escalader avec pièces jointes (captures, logs, ID de corrélation).

Exemples de messages d’erreur et interprétation

Message affiché	Traduction/interprétation	Piste prioritaire
Can’t complete your request. You might not have permission to perform this action.	OWA ne valide pas l’opération (permissions/session)	Session/cookies, FullAccess, incident OWA
Something went wrong	Erreur générique côté client/service	Recharger, navigation privée, vérifier état du service
Access denied	Rejet d’autorisation	Vérifier délégations, dossiers, politiques OWA

Résumé exécutif

La majorité des cas où OWA refuse l’ouverture d’une boîte partagée provient soit d’un incident côté service (ex. EX777095), soit d’un état de session navigateur corrompu. Les trois actions les plus efficaces sont : déconnexion + lien direct, mode privé/nouveau profil et utilisation d’Outlook Desktop/Mobile. Pour une remédiation durable, combinez nettoyage ciblé des données site, mise à jour du poste et vérification/remise à plat des droits (FullAccess/SendAs et permissions de dossiers). Une surveillance attentive de l’état du service et une politique d’extensions maîtrisée réduisent fortement les récidives.

OWA : impossible d’ouvrir une boîte partagée — erreur « You might not have permission » [Guide de dépannage Microsoft 365]