Votre application se charge. La base de données fonctionne. Un client clique sur le bouton censé faire avancer son dossier, puis attend un e-mail qui n’arrive pas.

Sur votre tableau de supervision, le produit est disponible. Pour le client, il est inutilisable. La panne de Microsoft 365 des 12 et 13 novembre 2026 a révélé une faille dans la continuité des activités liées à la messagerie : **votre application peut fonctionner alors que l’étape suivante dépend de la boîte de réception d’un tiers**.

Pour connaître l’état actuel des services Outlook et Microsoft 365, consultez [la page d’état de Microsoft](https://status.cloud.microsoft/m365).

Pour comprendre cette dépendance, suivez une tâche jusqu’à son aboutissement. Votre indépendance vis-à-vis d’un fournisseur dépend de la capacité des personnes à recevoir le message, à entrer dans l’application, à prendre une décision et à vous joindre en cas de problème. Posséder le serveur ne couvre qu’une partie de ce parcours.

## Une panne d’Outlook peut bloquer la réception des demandes d’assistance

Vendredi matin, [CloudTree a prévenu ses clients qu’il ne recevait plus les e-mails destinés à créer des tickets d’assistance](https://status.cloud-tree.co.uk/). Pour les problèmes techniques sans rapport avec la panne, l’entreprise leur demandait d’appeler son assistance afin que son agent téléphonique puisse ouvrir un ticket. À 14 h 03, CloudTree a annoncé que ses comptes Microsoft étaient de nouveau connectés. L’entreprise s’attendait à ce que la création de tickets par e-mail reprenne et poursuivait sa surveillance.

Ce détail révèle un problème plus vaste. La panne avait supprimé un moyen de signaler une autre panne au fournisseur. Un client pouvait rencontrer un problème d’hébergement distinct, alors que le moyen habituel de le signaler était indisponible.

Transposez cette situation à votre entreprise. Une file de demandes d’assistance opérationnelle n’est utile qu’une fois la demande reçue. Un formulaire qui transmet les messages à la même boîte de réception en panne peut sembler offrir un second canal, tout en aboutissant au même point de blocage.

La solution de secours doit permettre de transmettre réellement la demande. Quelqu’un répond à l’appel, consigne le problème dans un outil accessible à l’équipe et donne au client un moyen d’en suivre le traitement. Publier un numéro de téléphone constitue un début. Préciser qui peut l’utiliser et ce qui se passe ensuite en fait une solution utile.

C’est pourquoi un avis d’incident doit nommer l’action touchée. « Nos serveurs fonctionnent » laisse le client se demander s’il doit attendre, réessayer ou contacter quelqu’un. « Les e-mails à l’assistance sont retardés ; utilisez ce moyen de contact pour les problèmes urgents » lui permet de décider quoi faire.

## Un second fournisseur ne peut pas ouvrir la boîte du destinataire

Vous pouvez changer de fournisseur de messagerie et devoir toujours communiquer avec un client qui utilise Microsoft 365. Son infrastructure de réception reste nécessaire à l’échange.

[L’avis d’incident de Bright Software Group](https://status.brightsg.com/incident/1124108) illustrait cette limite : ses applications et son service d’envoi d’e-mails distinct fonctionnaient, mais l’acheminement vers les destinataires utilisant les services Microsoft était perturbé. Le bon fonctionnement de ses propres systèmes ne supprimait pas la dépendance du côté de la réception.

Pour une startup, cette distinction change la lecture des indicateurs d’e-mail. Un traitement terminé dans votre application prouve que le code a atteint cette étape. L’acceptation d’un message par le service d’envoi prouve qu’une autre étape a été franchie. Aucune de ces observations ne garantit que le destinataire peut ouvrir sa boîte de réception et agir.

Prenons un exemple fictif de recrutement. Vous préparez une invitation à un entretien, le prestataire d’envoi l’accepte, mais la boîte de réception du candidat est indisponible. Vous attendez toujours sa réponse. Changer de prestataire d’envoi ne peut pas rétablir l’accès à sa boîte de réception.

Vous ne pouvez pas maîtriser l’infrastructure de chaque destinataire. Vous pouvez en revanche décider de ce que votre produit considère comme acquis après l’envoi. L’écran affirme-t-il que la personne a été prévenue ? Un délai commence-t-il immédiatement à courir ? Peut-elle retrouver l’invitation dans son compte après s’être authentifiée, ou l’e-mail contient-il le seul moyen d’y accéder ?

Ce sont des décisions de conception du produit. Elles méritent autant d’attention que les nouvelles tentatives d’envoi et la configuration du serveur de messagerie, car elles déterminent si un message retardé devient une obligation non tenue.

## Connexion, planification et assistance dépendent parfois des mêmes services

[Les informations publiées par l’université de Bath pendant la panne](https://status.bath.ac.uk/index.json) ont révélé une autre dépendance. Selon ses premières constatations, les fonctions de base de Teams semblaient fonctionner et l’authentification paraissait épargnée, tandis qu’Outlook était inaccessible au personnel. L’université a également signalé des perturbations de TOPdesk et de son CRM de gestion des candidatures, qui dépendaient d’Outlook pour les e-mails. Son avis prévenait que la planification, les invitations et les opérations sur les calendriers pouvaient échouer.

La répartition inégale des perturbations est révélatrice. Certaines fonctions restaient utilisables alors que les tâches associées étaient interrompues. Une formule générale comme « Teams en panne » ou « Microsoft fonctionne » aurait masqué la distinction dont les utilisateurs avaient besoin pour organiser leur journée.

Examinez vous aussi les dépendances au-delà du nom du fournisseur. Une session déjà ouverte, une nouvelle connexion, une réinitialisation de mot de passe et une invitation à créer un compte suivent des parcours différents. L’un peut fonctionner tandis qu’un autre reste suspendu à l’arrivée d’un e-mail.

Une seconde application de collaboration peut être accessible aux salariés déjà connectés, mais exiger un code reçu par e-mail sur un nouvel appareil. Une page d’état des services peut être publique, alors que la personne chargée de la mettre à jour doit passer par le service d’identité touché. Un canal de secours auquel on accède grâce au canal en panne est moins utile qu’il n’y paraît.

Vérifiez ces parcours avec les personnes qui devraient réellement les emprunter. Le navigateur déjà ouvert du fondateur ne prouve pas qu’un nouveau client ou un collègue habilité de l’assistance peut se connecter. Notez précisément l’action qui échoue, plutôt que de déclarer toute l’application disponible ou indisponible.

## Construisez le plan de continuité de la messagerie autour des tâches

Un plan de continuité de la messagerie commence par les tâches qui ne peuvent pas attendre : un entretien prévu aujourd’hui, une demande d’assistance urgente ou une approbation soumise à une véritable échéance. Acheter un second outil pour chaque fonction donne à une petite équipe davantage de systèmes à entretenir. Cela n’aide que si les personnes concernées peuvent mener ces tâches à bien.

Pour chaque engagement, décrivez brièvement comment il est tenu. Incluez la personne qui reçoit le message et les accès dont elle a besoin. Les exemples suivants servent à préparer cette réflexion ; ils ne décrivent pas des défaillances constatées pendant cet incident :

| Engagement | Dépendance cachée à l’e-mail | Solution de secours à examiner |
|---|---|---|
| Un client accède à son compte | Message de connexion ou de récupération | Une méthode d’authentification déjà établie et approuvée |
| Un candidat participe à un entretien | Invitation et mise à jour du calendrier | Des coordonnées convenues et les détails du rendez-vous accessibles ailleurs |
| Un client signale un problème urgent | L’e-mail crée le ticket d’assistance | Un moyen de contact publié qui rejoint une file prise en charge par l’équipe, sans dépendre de l’e-mail |
| L’équipe explique un incident | L’e-mail annonce la page d’état des services | Une adresse publique connue, accessible directement |

Dans ses [recommandations pour atténuer les effets des incidents](https://learn.microsoft.com/en-us/compliance/assurance/assurance-microsoft-365-mitigations), Microsoft préconise des canaux parallèles par e-mail, téléphone et SMS lorsque la réponse à un incident dépend d’Exchange. Appliquez le même critère aux parcours clients : la solution de secours peut-elle joindre la bonne personne sans passer par la boîte de réception indisponible ?

Une solution de secours peut consister à suspendre volontairement une étape. Si vous ne pouvez pas authentifier quelqu’un de manière sûre sans sa boîte de réception, expliquez le délai et conservez sa place dans le processus. Une panne ne justifie pas d’improviser des vérifications d’identité ou d’accorder un accès sur la foi d’un message non vérifié.

Notre [exercice de continuité en l’absence du fondateur](/blog/founder-unavailable-continuity-rehearsal) examine si un collègue habilité peut travailler sans lui. La question posée ici est différente : ce collègue peut-il terminer la tâche lorsqu’un moyen de communication nécessaire manque ? Il faut à la fois les autorisations et une infrastructure accessible.

## Le rétablissement se termine quand les tâches en attente sont traitées

Dans une déclaration relayée par la [BBC le 13 novembre à 16 h 51 GMT](https://www.bbc.com/news/live/cq5y10ge3dp3t), Microsoft a attribué l’incident à un problème introduit lors d’une précédente augmentation de la capacité réseau, puis révélé par une modification récente du réseau. L’entreprise a déclaré que le problème n’était lié ni à une activité malveillante ni à l’IA ou aux agents, que sa cause sous-jacente avait été corrigée et que le rétablissement se poursuivait. Le rapport complet après incident était encore attendu.

Toute explication de la cause doit s’en tenir à ces éléments. Votre équipe doit aussi répondre à une autre question : que sont devenues les tâches suspendues à l’arrivée de ces messages ?

Lorsque l’accès revient, examinez les engagements en suspens avant de considérer que le retard est résorbé. Dans vos propres processus, recherchez les demandes sans réponse, les liens expirés et les rendez-vous modifiés par un autre canal. Comparez les notes temporaires aux informations du système habituel, afin que les collègues ne travaillent pas à partir de versions contradictoires.

Corrigez ensuite une hypothèse concrète que cet examen a remise en cause. Rendez une invitation accessible ailleurs que dans l’e-mail. Faites parvenir les demandes urgentes à l’assistance par un moyen indépendant. Indiquez qu’un message attend d’être acheminé au lieu de laisser entendre que le destinataire a agi.

Le tableau de supervision peut vous dire quand l’application fonctionne. Pour savoir si l’activité a repris, suivez le client au-delà du bouton d’envoi.