Le 29 février 2024, un incident d’Outlook sur le Web a fait que « Ouvrir une autre boîte aux lettres » renvoyait la boîte personnelle. Voici une analyse complète : symptômes, cause probable, résolution, contournements et bonnes pratiques pour éviter de revivre ce scénario.
La fonction « Ouvrir une autre boîte aux lettres » d’Outlook ne redirige plus vers la boîte partagée
Vue d’ensemble de la question
Le 29 février 2024, de nombreux utilisateurs rapportent que, dans Outlook sur le Web (OWA), l’option « Ouvrir une autre boîte aux lettres » ouvre systématiquement leur propre boîte de réception au lieu de la boîte partagée ou déléguée sélectionnée. Le phénomène apparaît simultanément dans plusieurs entreprises et locataires Microsoft 365, signe d’un incident côté service et non d’un problème localisé à un poste ou un navigateur isolé.
Le dysfonctionnement est cohérent avec une défaillance transitoire du back‑end Outlook hébergé (Microsoft 365), possiblement liée au traitement de la date bissextile 2024 (leap day). Même si la cause racine officielle n’a pas été publiée en détail, les indices contextuels et la simultanéité globale vont dans ce sens.
Réponse et solution
- Origine : dysfonctionnement transitoire du service Outlook dans le cloud (back‑end Microsoft 365), possiblement en lien avec la gestion de la date bissextile.
- Résolution : correctif côté service déployé par Microsoft. Le rétablissement a été constaté par vagues, avec des confirmations dès ~13 h UTC le 29 février, puis entièrement stabilisé le 1er mars.
- Action requise : aucune action corrective durable côté client. Les contournements (vider le cache, navigation privée, autre profil, client Outlook Desktop) n’étaient que temporaires.
Chronologie synthétique
Période (UTC) | Événement | Commentaire |
---|---|---|
29 févr. 2024 08:00–12:30 | Multiplication des signalements | Impossible d’ouvrir une boîte partagée : l’OWA recharge la boîte personnelle. |
29 févr. 2024 ~13:00 | Début de la récupération | Retour progressif à la normale selon les régions/locataires. |
1er mars 2024 | Stabilisation | Fonction nominale confirmée de manière générale. |
Symptômes observables
- Après avoir choisi Ouvrir une autre boîte aux lettres et saisi l’adresse d’une boîte partagée ou déléguée, la page se rouvre sur la boîte personnelle de l’utilisateur.
- Le comportement est identique sur plusieurs navigateurs et postes, y compris en mode privé.
- Les utilisateurs disposant du client Outlook Desktop (où la boîte partagée est déjà montée) n’observent pas toujours le problème.
- Le phénomène touche plusieurs locataires Microsoft 365 simultanément.
Tableau de décision rapide
Symptôme | Lecture | Pertinence pour cet incident |
---|---|---|
Se produit sur plusieurs navigateurs/postes | Fort indice d’un problème de service | ✓ |
Se résout seul sans changement local | Correctif côté Microsoft probable | ✓ |
Uniquement un utilisateur impacté | Contexte local ou permissions | ✗ (peu probable ici) |
Outlook Desktop fonctionne | Problème spécifique à OWA | ✓ |
Impact métier typique
- Équipes support : impossibilité d’accéder à la boîte partagée du centre de services, retards de traitement.
- Back‑office : boîtes partagées financières/RH inaccessibles via OWA pendant la fenêtre d’incident.
- Dirigeants/assistants : délégations de boîtes direction non utilisables depuis le web, nécessité de basculer vers Outlook Desktop.
Diagnostic côté client : la checklist éclair
- Valider l’étendue : même symptôme pour plusieurs utilisateurs ? dans plusieurs équipes ? Si oui, suspecter un incident de service.
- Tester rapidement : autre navigateur/profil, fenêtre privée, session propre. Si l’erreur persiste, c’est un bon indice côté service.
- Comparer avec Outlook Desktop : si la boîte partagée y est accessible, le problème est probablement circonscrit à l’OWA.
- Consigner un identifiant de corrélation : ouvrir les Outils de développement du navigateur (onglet Réseau), rejouer l’action, relever l’ID dans les en‑têtes (utile pour un ticket).
- Contrôler l’état du service dans le Centre d’administration Microsoft 365 (Service Health) pour confirmer l’incident en cours.
Contournements éprouvés pendant l’incident
- Mode privé / autre profil de navigateur : parfois efficace mais non garanti (atténue des effets de cache, pas la cause).
- Outlook Desktop : si la boîte partagée est montée, c’est la voie la plus fiable pendant une panne OWA.
- Client mobile : l’application Outlook iOS/Android peut permettre l’accès si la délégation est déjà configurée.
Important : ces mesures servent uniquement à continuer l’activité le temps que le service soit corrigé. Elles ne résolvent pas la cause racine.
Ce qui n’apporte pas de correction durable
- Vider le cache / cookies : peut masquer temporairement le symptôme, mais l’erreur réapparaît selon la session.
- Réinstaller le navigateur : coûteux et inutile dans un incident back‑end.
- Modifier les autorisations de la boîte partagée sans raison avérée : risque de perturber des accès fonctionnels.
Informations complémentaires utiles
- Centre d’administration Microsoft 365 → État du service : lorsque plusieurs utilisateurs sont affectés simultanément, c’est le premier indicateur fiable. Les avis y apparaissent souvent avant les billets communautaires.
- Contournements immédiats :
- Ouvrir la boîte partagée dans un autre profil de navigateur ou en mode privé.
- Utiliser Outlook Desktop si la boîte est déjà montée.
- Signalement efficace : lors de l’ouverture d’un ticket, fournir l’identifiant de corrélation extrait des en‑têtes de requête OWA pour faciliter la corrélation avec les journaux serveur.
- Prévention : documenter les accès critiques (boîtes partagées, délégations) et garder un client lourd prêt à l’emploi pour limiter l’impact d’une panne OWA.
Récupérer un identifiant de corrélation dans OWA
- Ouvrez Outlook sur le Web et lancez Ouvrir une autre boîte aux lettres.
- Avant de valider, appuyez sur F12 (ou Outils de développement) et activez l’onglet Réseau.
- Validez l’ouverture de la boîte partagée, repérez la requête
owa.service
ou similaire, et inspectez les en‑têtes de réponse/demande. - Relevez l’ID indiqué (exemples d’en‑têtes à vérifier) :
X-OWA-CorrelationId: 3b1f3c1e-3d0b-4be9-9e0a-7d2b2e0f9a8b x-ms-diagnostics: 2000002;reason="...";activityId=3b1f3c1e-3d0b-4be9-9e0a-7d2b2e0f9a8b
- Incluez cet identifiant, l’heure UTC et l’adresse de la boîte concernée dans votre ticket.
Plan de communication interne
En cas d’incident de service, une communication claire et brève limite l’impact organisationnel. Modèle suggéré :
Objet : Accès aux boîtes partagées via Outlook Web – incident en cours
Message : Depuis hh:mm UTC, la fonction « Ouvrir une autre boîte aux lettres » peut rediriger vers votre boîte personnelle. Microsoft travaille à une correction côté service. Recommandation : utiliser Outlook Desktop pour les boîtes déjà montées. Prochaine mise à jour à hh:mm UTC.
Bonnes pratiques d’anticipation et de résilience
- Documenter toutes les boîtes partagées critiques (propriétaires, délégués, SLA, plans de continuité).
- Standardiser l’ajout des boîtes partagées dans Outlook Desktop pour tous les profils concernés.
- Automatiser des alertes Service Health (vers Teams/courriel du support) pour réduire le temps de détection.
- Préparer un kit de bascule : procédures de switch vers Desktop, FAQ interne, messages d’information prêts.
- Journaliser les incidents récurrents (Known Issues) et les décisions prises (playbook).
FAQ
Pourquoi cela s’est‑il produit le 29 février 2024 ? La coïncidence avec un jour bissextile rend plausible un défaut de gestion de date dans un composant de service. Sans note publique de cause racine, cette explication demeure probable mais non officiellement confirmée.
<dt>Devons‑nous changer des paramètres de sécurité ou d’authentification ?</dt>
<dd>Non. La résolution a été effectuée côté Microsoft. Aucun changement pérenne côté client n’est requis.</dd>
<dt>Pourquoi vider le cache semble‑t‑il « réparer » parfois ?</dt>
<dd>Ce n’est qu’un <strong>effet de bord</strong> : vous forcez une nouvelle session/route côté service. Le problème peut réapparaître jusqu’au déploiement complet du correctif.</dd>
<dt>Comment réduire l’impact la prochaine fois ?</dt>
<dd>Maintenez un <strong>client Outlook Desktop</strong> prêt, documentez les boîtes partagées critiques et mettez en place des alertes d’état du service. Tenez un <em>playbook</em> de contournements.</dd>
Tableau d’impact et priorisation
Scénario | Impact | Urgence | Contournement recommandé |
---|---|---|---|
Helpdesk ne voit plus la boîte partagée | Ralentissement du traitement des tickets | Élevée | Basculer vers Outlook Desktop ou mobile |
Direction/assistants | Blocage d’agenda/délégation | Élevée | Utiliser le client lourd avec délégation préconfigurée |
Équipes projet | Retard non critique | Moyenne | Mode privé/ autre profil en attendant |
Procédure d’ouverture de ticket efficace
- Décrire le symptôme exact (chemin cliqué, boîte ciblée, résultat constaté).
- Joindre l’heure UTC, l’identifiant de corrélation, le locataire, l’UPN, le navigateur et la version.
- Préciser l’étendue (nombre d’utilisateurs/équipes/locataires touchés, zones géographiques).
- Indiquer les contournements testés et leur efficacité observée.
Annexe : inventaire des boîtes partagées et délégations (PowerShell)
Pour améliorer la résilience, maintenez un inventaire à jour des boîtes partagées et des accès. Exemples d’extractions avec Exchange Online PowerShell (à adapter) :
# Connexion Exchange Online
Connect-ExchangeOnline
# Lister les boîtes partagées
Get-Mailbox -RecipientTypeDetails SharedMailbox |
Select-Object DisplayName,PrimarySmtpAddress,WhenCreated |
Sort-Object DisplayName
# Délégations "FullAccess" par boîte
Get-Mailbox -RecipientTypeDetails SharedMailbox | ForEach-Object {
$mbx = $*.PrimarySmtpAddress
Get-MailboxPermission -Identity $mbx |
Where-Object { $*.User -notlike "NT AUTHORITY*" -and -not $_.IsInherited } |
Select-Object @{n="SharedMailbox";e={$mbx}},User,AccessRights
}
# SendAs
Get-Mailbox -RecipientTypeDetails SharedMailbox | ForEach-Object {
$mbx = $*.PrimarySmtpAddress
Get-RecipientPermission -Identity $mbx |
Where-Object { $*.Trustee -notlike "NT AUTHORITY*" } |
Select-Object @{n="SharedMailbox";e={$mbx}},Trustee,AccessRights
}
Conservez ces exports en lieu sûr et réactualisez‑les régulièrement afin de pouvoir orchestrer rapidement une bascule vers Outlook Desktop si nécessaire.
Annexe : modèle de journal d’incident
Heure (UTC) | Signal/Source | Observation | Décision/Action | Responsable |
---|---|---|---|---|
12:15 | Users/Support | Ouverture autre boîte → boîte perso | Activer contournement Desktop | Support N1 |
12:25 | Admin M365 | Incident de service détecté | Communication interne envoyée | Admin M365 |
13:05 | Tests ciblés | Signes de rétablissement | Élargir tests / surveiller | Support N2 |
01 mars | Validation | Retour à la normale confirmé | Clôture incident / REX | Incident Manager |
Leçons apprises
- Défaillances back‑end : elles peuvent mimer des problèmes locaux (sessions, cookies) mais ne se règlent pas côté client. Appliquer la checklist « étendue/temps » avant d’engager des remédiations invasives.
- Pré‑équipement : avoir les boîtes partagées critique déjà montées sur Outlook Desktop accélère la continuité d’activité.
- Traçabilité : capturer systématiquement un CorrelationId, l’heure UTC et le navigateur pour toute anomalie OWA.
- Communication : des messages courts, horodatés et réguliers maintiennent la confiance des métiers.
Conclusion
L’incident du 29 février 2024 autour de l’option « Ouvrir une autre boîte aux lettres » dans Outlook sur le Web illustre un point essentiel : lorsqu’un symptôme touche simultanément plusieurs utilisateurs et locataires, il faut penser service avant de soupçonner les postes. La résolution est intervenue côté Microsoft sans action durable côté client ; les contournements (mode privé, autre profil, client Desktop) n’ont servi qu’à maintenir l’activité. En adoptant une hygiène d’administration (inventaire des boîtes partagées, alertes d’état du service, procédures de bascule), votre organisation sera prête à absorber sereinement toute panne similaire.