Quand le nuage tombe : la panne Microsoft 365 et ce qu'une entreprise doit en retenir

Le 12 novembre à 18 h 17, heure de Kyiv, une panne a commencé sur Microsoft 365 et elle se poursuit au moment où nous publions ce texte. Les boîtes aux lettres, les agendas, Teams et SharePoint ne s'ouvraient plus. Des entreprises du monde entier ont été touchées, dont des entreprises ukrainiennes, car ici la plus grande partie de la messagerie professionnelle tourne sur Microsoft 365.

Nous l'avons constaté sur notre propre boîte et avons vérifié ce qui était exactement cassé. Ci-dessous, les faits que nous avons vérifiés nous-mêmes, la position officielle de Microsoft et surtout : ce qu'un chef d'entreprise doit en retenir, qu'il utilise Microsoft ou non.

Ce qui ne fonctionne pas, exactement

La première réaction devant « la messagerie ne s'ouvre pas » est toujours la même : c'est nous, le mot de passe, l'internet, les réglages du domaine. Nous avons donc commencé par vérifier notre côté, et le tableau était net.

• La connexion au compte fonctionne. Microsoft reconnaît l'utilisateur et accorde l'accès : ni le mot de passe, ni les droits, ni les réglages d'accès n'y sont pour quelque chose.
• La demande des messages renvoie une erreur serveur — code 502. Pas « pas d'accès », pas « mot de passe incorrect », mais « le serveur n'a pas pu répondre ».
• L'agenda tombe de la même façon — code 503. Il ne s'agit donc pas de la messagerie seule, mais de tout ce qui repose sur Exchange Online.
• Les enregistrements de messagerie du domaine (MX) n'ont pas changé et pointent toujours vers Microsoft. Le courrier part là où il doit partir.

La conclusion est simple : notre côté est intact, c'est le service lui-même qui ne répond pas. Quiconque a un doute devrait faire la même vérification : elle prend quelques minutes et règle la moitié des questions.

La chronologie officielle

Microsoft suit la panne sous deux numéros : EX1550543 — l'accès aux boîtes Exchange Online, et MO1550821 — tout ce qui dépend d'Exchange. Une panne distincte de Teams (TM1550488) est déjà close. Il était d'abord question de l'Amérique ; la formulation est ensuite devenue « peut toucher des utilisateurs dans n'importe quelle région ».

Les heures ci-dessous sont celles de Kyiv.

• 18 h 17, 12 novembre. Les utilisateurs ne peuvent pas ouvrir leurs boîtes. Microsoft indique enquêter sur un problème d'accès à la messagerie.
• 20 h 19. Charge accrue constatée dans plusieurs régions à la fois.
• 21 h 18. Précision : la charge a augmenté non à cause d'un afflux de trafic. Une partie des serveurs est brusquement devenue indisponible et les autres ont repris leur travail.
• 21 h 43. On découvre que les serveurs touchés échouent au contrôle automatique d'état de santé — et que le système les met lui-même hors service.
• 21 h 57. « Nous n'avons relevé aucun changement récent lié au début de la panne. »
• 00 h 00, 13 novembre. « Le processus principal sur les serveurs touchés se surcharge, d'où une perte de capacité. »
• Dans la nuit. Précision : ce qui se surcharge, c'est précisément le processus chargé d'établir les connexions sécurisées. En parallèle, Microsoft commence à revenir sur un changement récent de configuration réseauqui coïncide dans le temps avec le début de la panne.
• 06 h 11. « Nous le confirmons : rien n'indique qu'il s'agisse de la conséquence d'actes malveillants. »
• 13 h 04. La restauration est achevée en Asie-Pacifique ; le trafic est rétabli progressivement et le travail est étendu aux autres régions.

La cause : toujours pas nommée

Le plus honnête que l'on puisse dire au moment de publier : il n'y a pas de cause officielle. Les explications de Microsoft ont changé au fil de la journée — de « nous ne voyons aucun changement récent » à « nous revenons sur un changement récent de configuration réseau qui coïncide avec le début de la panne ». L'entreprise promet de publier une analyse complète avec la cause une fois la restauration terminée.

Ce que Microsoft affirme sans ambiguïté, c'est que ce n'est pas une cyberattaque. Cette formulation a été employée deux fois, à quelques heures d'intervalle.

Le plus intéressant dans cette histoire n'est pas la cause mais la raison pour laquelle la réparation a traîné. Les serveurs remis en service retombaient dès qu'on y laissait passer du trafic. Microsoft a ouvertement reconnu que les changements « ne fonctionnent pas comme prévu ». Ensuite, le travail a tourné en rond : arrêt de toutes les mises à jour et modifications de configuration, redémarrages, contournement du contrôle d'état de santé, reconstruction d'une partie des serveurs sur la configuration précédente, ajout de capacité par machines virtuelles. Les choses n'ont bougé qu'après un correctif sur le composant chargé de l'autorisation et de l'acheminement des requêtes.

Ce qu'il advient des messages

C'est la question qui inquiète le plus, elle a donc sa propre section.

• La distribution est retardée — Microsoft le reconnaît directement dans la description de la panne.
• La fenêtre d'attente d'un message a été portée à 48 heures. D'ordinaire, un serveur qui n'a pas pu distribuer un message dans un certain délai le renvoie à l'expéditeur avec une mention d'échec. Une fenêtre allongée signifie que les messages ne reviendront pas mais attendront dans la file.
• Microsoft n'a pas signalé de perte de données. Mais soyons précis : elle n'a pas dit non plus, en toutes lettres, que « rien n'a été perdu ». Ce qui a été dit littéralement, c'est que les messages retardés sont conservés.

Conséquence pratique : ne renvoyez pas vos messages. Ils sont dans la file et, quand le service les libérera, le client recevra des doublons. Attendez-vous à une vague : une journée entière arrivera d'un coup.

Ce qu'une entreprise doit faire tout de suite

1. Assurez-vous que le problème ne vient pas de vous. Si la connexion au compte passe mais que le message ne s'ouvre pas, c'est du côté du fournisseur. L'état de la panne est visible dans le centre d'administration Microsoft 365, rubrique « Intégrité des services », sous les numéros EX1550543 et MO1550821.
2. Ne touchez pas aux réglages. Pendant la panne d'un autre, ce sont les tentatives de « réparer » chez soi qui font le plus de dégâts : enregistrements de domaine modifiés, logiciels de messagerie réinstallés, mots de passe réinitialisés. Quand le service reviendra, il faudra démêler vos propres conséquences.
3. Activez un canal de secours. Basculez les questions urgentes avec les clients vers une messagerie instantanée ou le téléphone le temps de la panne. Prévenez ceux qui attendent une réponse : un bref « notre messagerie est en panne, écrivez-nous sur Telegram » vaut mieux que le silence.
4. Consignez l'arrêt. Si l'interruption vous a coûté de l'argent, notez l'heure et les conséquences. Microsoft a des engagements de niveau de service ; savoir si cette panne ouvre droit à compensation dans votre cas précis est une question pour votre contrat de licence et pour le partenaire par lequel les licences ont été achetées.

Quatre leçons pour l'avenir

Une panne de cette ampleur est rare, et en conclure que « le nuage, c'est mauvais » serait faux : le serveur maison dans un débarras tombe plus souvent et se relève plus lentement. Les leçons sont ailleurs.

1. Le canal de secours doit exister avant la panne, et non s'inventer pendant. Si toute la communication avec les clients passe par la messagerie d'un seul fournisseur, sa défaillance vous arrête complètement. Un bot Telegram, une messagerie d'entreprise, le téléphone — n'importe quoi que les clients connaissent à l'avance.
2. Ne mettez pas tout dans le même panier. Messagerie, documents, communication, authentification et protection chez un seul fournisseur, c'est commode jusqu'au jour exact où quelque chose casse chez lui. Alors tout s'arrête d'un coup. C'est précisément ce qui s'est passé : avec la messagerie sont tombés Teams, SharePoint et Defender.
3. Ce qui rapporte doit être sous votre contrôle. Le site, les commandes, le catalogue, les demandes : gardez-les là où vous pouvez vérifier l'état vous-même, relever une copie et répondre au client sans attendre le rapport d'un autre.
4. Sachez distinguer « chez nous » de « chez eux ». La simple vérification du début de cet article épargne des heures de panique et prévient des modifications inutiles dans les réglages.

Comment c'est organisé chez nous

Nous utilisons Microsoft 365 pour la messagerie et les documents — et pendant cette panne, notre boîte non plus ne s'ouvrait pas. En revanche, ce que nous faisons pour les clients fonctionnait et fonctionne : les sites sur notre système Smart CMS, les agents conversationnels, les espaces clients et la téléphonie vivent sur nos propres serveurs, séparés de la messagerie. Aucun site client n'a souffert de cette panne.

C'est exactement la répartition du risque dont parlent les leçons : les outils de bureau chez un fournisseur extérieur fiable, et ce qui vend et reçoit les commandes là où nous en répondons nous-mêmes.

À propos des sources

Les vérifications d'accès, des enregistrements de messagerie et des codes de réponse, nous les avons faites nous-mêmes. La chronologie et les citations de Microsoft proviennent de ses messages dans le centre d'administration et sur la page d'état des services — tels que relayés par des observateurs du secteur, recoupés entre eux, car ces deux sources ne sont accessibles qu'aux administrateurs du client concerné. Pour chaque propriétaire, la source première est son propre centre d'administration.

---

Ce texte a été préparé par l'équipe SmartGT. Si vous n'êtes pas sûr du degré de dépendance de votre entreprise à un fournisseur unique, ni de ce qu'il adviendrait de votre site un jour pareil, écrivez-nous : center@uvc.in.net ou +38 073 949 61 79. Nous regarderons ensemble et vous dirons franchement ce qu'il vaut mieux répartir dans des paniers différents.