À 20h17, heure de Dubaï, jeudi, le courrier s'est arrêté.
Pas pour une entreprise. Pas pour une région. Pour une très large part de la planète, au même instant, le même soir. Outlook s'est vidé. Les boîtes Exchange Online refusaient de s'ouvrir. Les appels Teams tombaient dans le silence. Copilot répondait par des excuses. Les liens SharePoint tournaient dans le vide. Environ 131 000 personnes ont ouvert Downdetector dans les premières heures pour vérifier si le problème venait d'elles, et les signalements sont arrivés de 74 pays et territoires en une soixantaine de minutes.
Nous l'avons observé de la façon la moins glamour possible : un terminal, quelques sondes et une horloge. À 16h44 heure de Dubaï le lendemain après-midi, plus de vingt heures après le début, outlook.office.com et outlook.office365.com ne parvenaient toujours pas à terminer une poignée de main TCP depuis ici, tandis que graph.microsoft.com, login.microsoftonline.com et teams.microsoft.com répondaient en millisecondes. Cette seule asymétrie racontait presque toute l'histoire avant que Microsoft ne dise un mot : ce n'était pas Internet qui cassait, ni un accident de routage quelque part dans le Golfe. C'était la porte d'entrée de Microsoft, et elle était bloquée.
Notre propre messagerie n'a jamais bougé. aratech.ae tourne sur Migadu, nos boîtes sont restées accessibles tout du long. Ce n'est pas une fanfaronnade, c'est la leçon entière de cette panne compressée en une phrase, et nous y reviendrons.
Ce qui a réellement cassé
Le flux de statut de Microsoft le décrit d'une manière qui devrait faire lever la tête à tout ingénieur infrastructure : un processus central sur les serveurs concernés, celui qui établit les connexions sécurisées, a été submergé. Quand ce processus sature, le serveur cesse de traiter les requêtes. Pas lentement. Pas partiellement. Il s'arrête. Les serveurs ont ensuite échoué à leurs propres contrôles de santé internes, le trafic a été déplacé ailleurs, et la plateforme a commencé à les redémarrer.
C'est là que la reprise est devenue une boucle. Les serveurs redémarrés revenaient sains, prenaient du trafic, puis redevenaient insensibles. Microsoft l'a dit sans détour : les serveurs à l'origine de la panne peuvent redevenir insensibles dès qu'ils reçoivent du trafic. D'où le fait que, pendant une partie de la nuit, l'entreprise limitait délibérément les types de trafic autorisés à atteindre l'infrastructure concernée dans certains emplacements. Quand un fournisseur commence à jeter les requêtes de ses propres clients pour protéger un service d'un excès d'amour, vous ne regardez pas un bug. Vous regardez une défaillance de capacité et de plan de contrôle, avec une boucle de redémarrage par-dessus.
ThousandEyes, qui observait de l'extérieur, a vu exactement à quoi cela ressemble sur le fil : réinitialisations de connexion, refus de connexion, expirations de délai, erreurs HTTP serveur et perte de paquets significative à l'intérieur du réseau de Microsoft. Pas en périphérie. À l'intérieur.
La première chronologie de Microsoft situe le début à 16h17 UTC le 12 novembre. ThousandEyes a observé un impact dès 17h30 UTC environ. Cet écart compte, car c'est la différence entre le moment où un système casse et le moment où il l'admet.
Deux choses ont été claires côté Microsoft, et les deux méritent d'être répétées plutôt qu'enterrées : aucune preuve d'activité malveillante ou cyber, et un rapport complet post-incident avec cause racine et actions de défense en profondeur suivra une fois l'atténuation terminée. Tant que ce rapport n'est pas là, toute explication assurée que vous lisez, y compris une version plus détaillée de celle-ci, est une inférence déguisée en fait.
Pourquoi un processus a fait tomber onze produits
Voici la partie qui devrait vous inquiéter plus que la panne elle-même.
La liste des services touchés n'était pas une liste de produits qui partagent par hasard un centre de données. C'était Outlook, Exchange Online, Teams, SharePoint Online, Copilot, Defender XDR, Defender for Office 365, Planner, To Do et Intune. Relisez la liste et notez le point commun : presque tous lisent dans Exchange Online, y écrivent ou s'y authentifient.
Exchange n'est pas que du courrier. Dans un tenant Microsoft 365, c'est le bus de notifications, la colonne vertébrale du calendrier, l'invitation à la réunion, l'e-mail d'approbation, la réinitialisation de mot de passe, l'alerte de sauvegarde échouée, le ticket qui dit qu'un serveur est tombé. Quand le plan du courrier cale, le plan de contrôle de l'entreprise cale avec lui, et il cale de façons que personne n'a documentées parce que personne n'a jamais dessiné le graphe.
C'est la vraie découverte de cette semaine, et ce n'est pas une découverte sur Microsoft. C'est une découverte sur l'architecture. Le graphe de dépendances d'une entreprise moderne est un schéma en étoile avec un logo de fournisseur au centre, et la plupart des sociétés n'ont jamais vu leur propre copie.
La fenêtre de 48 heures, et ce qu'elle signifie
À 04h15 ET vendredi, Microsoft a porté la fenêtre de timeout du courrier à 48 heures.
Lisez cela comme un aveu d'ingénierie. La fenêtre de timeout, c'est le temps qu'un serveur ou un client de messagerie attend un message avant d'abandonner et de renvoyer une erreur. La porter à 48 heures signifie que Microsoft s'attend à ce que les messages restent très longtemps en file pendant qu'il résorbe le retard, et qu'il préfère les retenir plutôt que de les faire rebondir. Conséquences pratiques, classées par coût :
Les messages envoyés à vos utilisateurs depuis Gmail, Outlook.com et d'autres fournisseurs sains pendant la panne sont probablement en file, pas perdus. Ils arriveront en retard, en rafale, dans le désordre et mélangés à tout le reste.
Les messages que vos utilisateurs ont envoyés pendant la panne peuvent apparaître comme envoyés et ne jamais partir, ou partir deux fois, selon la façon dont le client les a mis en cache. Factures en double et relances de paiement en double sont un risque réel cette semaine.
Tout ce qui avait une échéance dans la fenêtre a été manqué. Appels d'offres, documents de visa, instructions bancaires, signatures de contrats. L'e-mail reste la trace légale de la plupart de ces éléments dans la région, et la trace a un trou.
Ce que le monde a réellement perdu
La liste d'impact se lit comme un test de résistance de l'infrastructure civile, et c'en était un.
Le système de messagerie du NHS britannique a été perturbé au point que certains patients risquaient de manquer leurs ordonnances. Les polices du Merseyside, du Grand Manchester, du Bedfordshire, du Dorset et du Hertfordshire ont demandé au public d'appeler le 101 parce que les formulaires en ligne étaient morts. Le réseau du Parlement à Westminster a été touché. Aux États-Unis, la Chambre des représentants a indiqué que ses ingénieurs travaillaient avec Microsoft, des municipalités de Miami Beach à Austin en passant par le comté de Baltimore ont demandé aux habitants de prendre le téléphone, et le bureau du shérif du comté d'Arapahoe a signalé des paiements de caution retardés. Workhorse Group a reporté sa conférence de résultats trimestriels. OpenAI a signalé des problèmes avec les connecteurs Microsoft, et Anthropic a dû déployer un correctif après une vague d'erreurs Claude.
Aucune de ces organisations ne manquait de service informatique. La plupart avaient un plan de continuité. Ce qu'elles n'avaient pas, c'était un plan pour le cas précis où le plan de contrôle du fournisseur tourne en boucle de redémarrage et où votre fournisseur d'identité se trouve à l'intérieur.
L'arithmétique inconfortable pour cette région
Microsoft 365 est utilisé par des centaines de millions de personnes, et la concentration n'est pas également répartie. Dans le Golfe, c'est proche du choix par défaut. Banques, autorités de zones franches, cliniques, écoles, logisticiens et un très grand nombre de PME font tourner toute leur journée de travail sur un tenant qui a été, pendant environ un jour, le logiciel le moins fiable qu'elles possédaient.
Maintenant la partie qui doit piquer. Cette panne a commencé à 20h17 un jeudi à Dubaï. Dans une semaine de travail du dimanche au jeudi, c'est le meilleur moment possible : après l'envoi du travail de la semaine, avant que quiconque ait besoin d'une réponse. Si la même défaillance avait frappé à 09h00 un dimanche, la semaine de la région aurait commencé avec une boîte morte et aucun moyen d'expliquer aux clients pourquoi.
Ce n'est pas de la résilience. C'est de la chance, et la chance n'est pas un contrôle que l'on inscrit dans un registre des risques.
Ce que nous ferions lundi matin
Pas un argumentaire commercial. Une liste. L'essentiel coûte du temps, pas de l'argent, et tout est moins cher que la soirée de jeudi.
1. Dessinez le graphe de dépendances, honnêtement. Notez chaque processus métier qui s'arrête quand le courrier s'arrête : facturation, codes à usage unique et codes à deux facteurs envoyés par e-mail, signature électronique, tickets, réinitialisations de mot de passe, notifications CRM, alertes de sauvegarde, validations de paie. Puis marquez ceux qui ont un chemin sans e-mail. Dans la plupart des entreprises, la réponse honnête est aucun, et c'est là le constat.
2. Sortez l'identité du chemin du courrier. Si la réinitialisation de mot de passe, l'enrôlement MFA et la récupération de compte passent tous par la même boîte qui vient de s'éteindre, une panne devient un verrouillage total. Des comptes administrateurs de secours avec clés matérielles, des codes de récupération stockés hors ligne et un canal d'administration hors bande ne sont pas de la paranoïa. C'est la différence entre un incident et un arrêt complet.
3. Gardez une seconde porte ouverte. Un fournisseur de messagerie secondaire sur un enregistrement MX séparé, ou au minimum une procédure documentée et testée pour basculer les MX et monter une boîte de secours, transforme une panne de 20 heures en désagrément de 20 minutes. Ce n'est ni gratuit ni pour tout le monde, mais le calcul a changé cette semaine.
4. Surveillez le parcours utilisateur, pas le ping. Un contrôle ICMP vert sur une IP Microsoft ne vous a rien dit jeudi. Ce qu'il vous fallait, c'était une connexion synthétique au webmail, un vrai message de test en envoi et réception toutes les cinq minutes, et une alerte quand l'aller-retour casse. Surveillez ce que font vos équipes, pas ce qui est facile à graphiquer.
5. Écrivez le runbook de communication avant d'en avoir besoin. Qui prévient les clients, sur quel canal, avec quels mots, et qui décide de changer de canal. SMS et WhatsApp ont parfaitement fonctionné jeudi. Presque personne n'avait de message pré-approuvé prêt à y envoyer.
6. Sachez ce que vaut vraiment votre SLA. Les crédits de service de Microsoft pour une panne de cette durée sont une erreur d'arrondi face à une journée perdue pour une entreprise commerciale. Le SLA est une politique de remboursement, pas un plan de continuité. Budgétez en conséquence.
7. Lisez le rapport post-incident quand il sortira, et traduisez-le dans votre registre des risques. Microsoft a promis cause racine et actions de défense en profondeur. Quoi qu'ils publient, la question n'est pas ce que Microsoft a raté, mais ce qui, dans notre pile, a la même forme.
La facture arrive plus tard
Les pannes comme celle-ci sont retenues comme un mauvais vendredi et oubliées le mercredi suivant. Le coût ne disparaît pas, il se répartit : l'affaire qui a glissé, la facture payée deux fois, le client qui a commencé à se demander en silence si votre e-mail est un moyen fiable de vous joindre.
Le résumé honnête est celui-ci. Un seul processus saturé dans l'infrastructure d'un fournisseur a fait tomber le courrier, le chat, les fichiers, les assistants IA, la télémétrie de sécurité et la gestion des postes pour une grande partie du monde, pendant une bonne partie d'une journée, et la reprise n'a tenu qu'une fois que le fournisseur a commencé à brider ses propres clients. Aucun attaquant requis. Aucun zero-day requis. Juste un graphe de dépendances que personne n'avait dessiné, et une boucle de redémarrage que personne n'avait répétée.
Nous construisons et exploitons de l'infrastructure pour vivre, et nous ne sommes exemptés d'aucun des points ci-dessus. La seule différence, c'est que nous avons passé la soirée de jeudi à regarder les sondes plutôt que la boîte de réception, et que nous savions déjà quels clients le sentiraient en premier. Si vous ne savez pas cela de votre propre entreprise, cette semaine vous a offert une répétition gratuite. Servez-vous-en avant que la suivante ne vous coûte quelque chose.