Se rendre au contenu

Panne Microsoft : le courriel d'Internet a tenu, celui de Microsoft est tombé

Un changement de configuration chez un seul fournisseur a privé des organisations de 74 pays de leur boîte de réception. Ce n'est pas un accident de parcours : c'est ce que la centralisation produit.

En bref : le 12 novembre 2026 à 11 h 17, heure de Montréal, un changement de configuration réseau chez Microsoft a rendu Exchange, Teams, SharePoint, Copilot et une quinzaine d'autres services inaccessibles. Au soir, 140 000 personnes de 74 pays signalaient le problème. Aucune cyberattaque, aucune sanction, aucune facture impayée : un seul changement, chez un seul fournisseur. Pendant ce temps, le courriel d'Internet, lui, a continué de fonctionner, parce qu'il repose sur une architecture que Microsoft n'opère pas. C'est cette différence d'architecture qui mérite une heure de votre attention, pas la panne elle-même.


Dans cet article

Hier, à 11 h 17, heure de Montréal, des boîtes de réception ont cessé de répondre un peu partout dans le monde. Pas les vôtres si vous n'êtes pas chez Microsoft. Toutes les autres.

Au moment d'écrire ces lignes, le 13 novembre en matinée, Microsoft n'a toujours pas déclaré l'incident réglé. Des hôpitaux britanniques ont annulé des interventions, des services gouvernementaux ont été perturbés en Australie, au Japon et aux Philippines, et aux États-Unis, des corps policiers ont eu du mal à traiter des paiements de cautionnement. Ce n'est pas une panne de messagerie. C'est une panne d'organisation, à l'échelle de plusieurs pays.

L'histoire intéressante n'est pas que Microsoft soit tombé. Tout le monde tombe. L'histoire intéressante, c'est ce qui n'est pas tombé, et pourquoi.


Ce qui s'est passé, dans les faits

L'incident porte deux numéros au registre de Microsoft : EX1550543 pour Exchange Online et MO1550821 pour l'ensemble de Microsoft 365. Si votre service informatique les cherche, c'est là qu'ils sont.

La liste des services touchés s'est allongée toute la nuit : Exchange Online d'abord, donc Outlook sur le web, sur ordinateur et sur téléphone, puis Teams pour la planification et les événements, SharePoint pour le partage externe, OneDrive, Copilot, Defender, Purview, Power BI, Power Apps, Planner, To Do, Intune, l'impression universelle et une partie du centre d'administration. Microsoft Graph aussi, ce qui veut dire que les logiciels tiers branchés sur vos courriels et vos agendas ont cessé de répondre en même temps.

Sur la cause, Microsoft reste prudente, et il faut l'être avec elle. L'entreprise a écarté la piste d'une cyberattaque et attribue la panne à des réglages appliqués à des serveurs après une mise à jour : un processus chargé d'établir les connexions sécurisées s'est retrouvé saturé, les serveurs ont cessé de répondre, et la charge s'est reportée sur ceux qui tenaient encore. Une modification récente de la configuration réseau a été annulée parce qu'elle coïncide avec le début de l'incident. Coïncider n'est pas causer, et aucune cause racine n'a été confirmée à ce jour.

Un détail en dit long : Microsoft a porté à 48 heures le délai avant expiration des courriels en attente. Retenez-le, on y revient.


À qui cet article s'adresse, et à qui il ne s'adresse pas

Avant d'aller plus loin, trois questions fermées. Elles décident si la suite vaut votre temps.

Est-ce que votre facturation s'arrête quand votre courriel s'arrête? Si vos bons de commande, vos approbations ou vos envois de factures passent par la boîte de réception, une journée sans courriel est une journée sans revenus, pas une journée agaçante.

Avez-vous une horloge légale ou contractuelle qui tourne? Un délai de soumission, une paie à déposer, un signalement d'incident de confidentialité à produire dans les meilleurs délais au sens de la Loi 25 : ces échéances ne s'arrêtent pas parce que votre fournisseur est en panne.

Est-ce que quelqu'un chez vous opère déjà quelque chose? Un serveur de fichiers, un site, une base de données. Pas forcément un service informatique : une personne qui sait ce qu'est un nom de domaine.

Si vous avez répondu non aux trois, la panne d'hier vous a coûté une demi-journée d'irritation et rien d'autre, et changer d'architecture vous coûterait bien plus cher que ce que ça vous rapporterait. Lisez plutôt notre calcul du coût réel d'un incident pour une PME : il vous dira où votre argent est réellement à risque, ce qui n'est probablement pas ici.

Si vous avez répondu oui à au moins deux, la suite est pour vous.


Personne n'a coupé l'accès

On a déjà écrit ici sur le scénario d'une coupure politique du nuage américain : sanctions, décision prise ailleurs, calendrier que personne à Montréal ne contrôle. C'est un risque réel, et il reste entier.

La panne d'hier n'a rien à voir avec ça, et c'est précisément ce qui la rend instructive. Aucune décision politique. Aucun attaquant. Aucun litige commercial. Un changement de configuration, dans une entreprise qui compte parmi les plus compétentes du monde en exploitation de centres de données, et des organisations de 74 pays se retrouvent sans courriel pendant plus de seize heures.

Ce n'est pas non plus un accident isolé. En janvier 2026, une perte de capacité serveur avait déjà fait tomber plusieurs services Microsoft 365 d'un coup en Amérique du Nord, pendant près de dix heures. En juillet 2024, une mise à jour défectueuse d'un fournisseur de sécurité tiers avait mis hors service 8,5 millions d'appareils Windows, soit moins de 1 % du parc mondial selon le chiffre donné par Microsoft, et ça avait suffi à clouer des avions au sol. Et le problème n'est pas propre à Microsoft : le 20 octobre 2025, un enregistrement DNS vide dans une seule région d'Amazon Web Services a fait tomber DynamoDB et une vingtaine d'autres services pendant une quinzaine d'heures, emportant au passage Slack, Atlassian et Snapchat.

Quatre causes complètement différentes. Un seul point commun : quand le service est centralisé, la panne l'est aussi. Le rayon d'explosion n'est pas déterminé par la gravité de l'erreur, il est déterminé par l'architecture.


Le courriel, lui, n'est pas tombé

Voici le fait que presque toute la couverture médiatique a manqué. Pendant ces seize heures, le système de courriel d'Internet a fonctionné normalement. Les messages ont continué de circuler entre tous les serveurs de la planète qui ne sont pas chez Microsoft. Ce qui était inaccessible, ce n'était pas le courriel : c'étaient les boîtes aux lettres hébergées à un seul endroit.

Et les messages qui leur étaient destinés n'ont pas été perdus. Ils ont attendu. Pas par chance : parce que c'est écrit dans la norme. Le protocole SMTP, défini par la RFC 5321, en vigueur depuis octobre 2008, dit noir sur blanc que le courrier qui ne peut pas être transmis immédiatement doit être mis en file d'attente et réessayé périodiquement, que l'intervalle entre deux tentatives devrait être d'au moins trente minutes, et que l'expéditeur ne devrait abandonner qu'après quatre à cinq jours.

Relisez maintenant le détail de tout à l'heure : Microsoft a porté son propre délai d'expiration à 48 heures. Une norme ouverte de 2008 demande à chaque serveur de la planète de persévérer pendant quatre à cinq jours, et c'est cette obstination distribuée, écrite par un comité il y a dix-huit ans, qui a servi de filet pendant que la plateforme centralisée, elle, se contentait de deux jours.

Le courriel est le plus vieux service fédéré du monde, et le seul que tout le monde utilise sans y penser. Personne ne possède le courriel. Il n'y a pas de serveur central du courriel. Chaque organisation opère le sien, ou en loue un, et ils se parlent tous par une norme commune. C'est pour ça qu'une panne chez un fournisseur, même énorme, reste une panne chez un fournisseur et pas une panne du courriel.


Changer de fournisseur n'est pas changer d'architecture

La réaction réflexe, après une panne pareille, c'est de regarder ailleurs. Google Workspace, peut-être. Un autre nuage, un autre contrat, un autre logo.

Ça ne change rien au problème. Vous aurez déplacé votre point de défaillance unique, vous ne l'aurez pas supprimé. Le jour où c'est l'autre qui tombe, vous vivrez exactement la même journée, avec le même sentiment d'impuissance et le même nombre de boutons à votre disposition : zéro.

Il y a trois architectures possibles, et seulement la troisième change le résultat.

Architecture À quoi ça ressemble Ce qui arrive quand ça casse
Centralisée Tout le monde chez le même fournisseur, sur la même plateforme Tout le monde tombe en même temps, et personne chez vous ne peut rien faire
Répartie entre fournisseurs Le courriel chez l'un, les fichiers chez l'autre, la visioconférence chez un troisième Une fonction tombe à la fois. C'est déjà mieux, mais chaque fonction reste un point unique
Fédérée Chaque organisation opère ou loue son propre serveur, et les serveurs se parlent par une norme ouverte Un serveur tombe, les autres continuent. Le rayon s'arrête à la frontière de l'organisation touchée

La décentralisation, ce n'est pas un autre fournisseur. C'est l'absence de centre.


Ce que la fédération fait différemment

Le courriel prouve que le modèle fonctionne à l'échelle planétaire depuis quarante ans. Trois autres normes l'appliquent à ce que les PME utilisent vraiment aujourd'hui.

Matrix, pour la messagerie d'équipe et la visioconférence, est la réponse directe à Teams et à Slack. Sa spécification le dit dans sa première phrase : un ensemble d'API ouvertes pour une communication décentralisée, sur une fédération mondiale de serveurs sans point de contrôle unique. Techniquement, la propriété qui compte est celle-ci : les données d'une conversation sont répliquées sur tous les serveurs dont des usagers participent à cette conversation, et aucun serveur ne détient ni ne contrôle une conversation donnée. Si le serveur de votre fournisseur tombe, vos échanges avec les autres organisations existent toujours, chez elles. On a détaillé le déploiement dans notre guide sur Matrix et Element.

ActivityPub fait la même chose pour la diffusion publique. C'est une recommandation du W3C depuis le 23 janvier 2018, ce qui en fait une norme du web au même titre que le HTML. C'est ce qui fait tourner Mastodon et une bonne partie de ce qu'on appelle le fédivers.

Open Cloud Mesh, porté par l'association GÉANT, fait le partage de fichiers entre serveurs indépendants. C'est le mécanisme derrière la fédération de Nextcloud : deux organisations qui ont chacune leur propre instance partagent des dossiers entre elles sans qu'aucune des deux ne dépose ses fichiers chez un tiers commun. Notre présentation de Nextcloud Hub couvre le reste de la suite.

Dans les trois cas, la propriété recherchée est la même, et elle est modeste : votre panne redevient votre panne. Elle dure le temps que vous décidez d'y mettre, et elle ne concerne que vous.


Ce que la fédération ne règle pas

Un article qui s'arrêterait ici vous vendrait quelque chose. Voici l'autre moitié.

Votre serveur peut tomber, et ce sera le vôtre. Hier, les 140 000 personnes qui signalaient le problème vous auraient confirmé en trente secondes que ce n'était pas votre faute. Quand votre propre serveur tombe, il n'y a pas de page d'état, pas de foule, pas de communiqué : il y a vous, et un téléphone qui sonne. Un fournisseur fédéré bien choisi ne fait pas disparaître ce risque, il le rapproche.

« Libre » n'est pas « gratuit ». Le droit d'usage ne coûte rien, le reste coûte le temps de quelqu'un. Mises à jour, sauvegardes vérifiées, certificats, surveillance : c'est une charge récurrente, pas un projet qui se termine. La vraie question n'est jamais « est-ce que c'est gratuit », c'est « qui s'en occupe le mardi matin ».

N'hébergez pas votre courriel vous-même. C'est la recommandation la plus constante qu'on donne, et elle vaut la peine d'être répétée dans un article qui fait l'éloge du courriel. Réputation d'envoi, listes noires, filtrage : c'est un métier à temps plein et un mauvais premier projet. Un hébergeur indépendant sur une norme ouverte vous donne la réversibilité sans la charge.

Tout ne se fédère pas. Votre comptabilité ne se réplique pas chez vos partenaires, et c'est tant mieux. Pour un ERP, la bonne question n'est pas la fédération, c'est la licence et l'endroit où tourne l'instance.

Et le confort baisse, au moins au début. Les plateformes centralisées sont agréables parce qu'une seule équipe contrôle tout de bout en bout. Un monde fédéré a des coutures visibles. On les accepte en échange d'autre chose.


Réduire le rayon, pas tout arracher

Rien de ce qui précède n'implique une migration. Une migration complète est un projet de plusieurs trimestres, et ce n'est pas ce qu'une panne de seize heures devrait déclencher.

Ce qu'elle devrait déclencher, c'est un inventaire honnête : qu'est-ce qui, chez vous, s'arrête quand un seul fournisseur s'arrête? La réponse est presque toujours plus longue que prévu, parce que l'authentification unique relie des choses qu'on croyait indépendantes.

Trois gestes qui tiennent dans une semaine, avant même de parler de changer quoi que ce soit :

  1. Écrivez le chemin de secours pour joindre vos dix clients les plus importants sans votre messagerie habituelle, et testez-le une fois.
  2. Vérifiez qu'au moins un service essentiel ne dépend pas de la même authentification que les autres, pour qu'une panne d'identité ne ferme pas toutes les portes d'un coup.
  3. Sortez une copie de vos données hors de la plateforme, lisible sans elle, et ouvrez le fichier pour confirmer qu'il s'ouvre.

Ensuite seulement vient la question de l'ordre, et elle se décide couche par couche plutôt que d'un bloc. Les sept décisions à prendre avant d'installer quoi que ce soit couvrent ce terrain, et le comparatif Collabora et OnlyOffice traite la couche bureautique, qui est souvent la première.

Un deuxième article suivra dans quelques jours avec le tableau complet : pour chaque produit Microsoft qu'une PME achète réellement, le remplacement libre, sa licence et son piège honnête.


Chez Blue Fox

On déploie des outils libres hébergés au Québec, sous le contrôle du client, et on privilégie les protocoles ouverts chaque fois qu'il en existe un : Matrix plutôt qu'une messagerie propriétaire, Nextcloud et sa fédération pour les fichiers, une boîte IMAP chez un hébergeur indépendant pour le courriel.

Avec une réserve qu'on préfère écrire que taire : nous confier votre hébergement reste une dépendance. On tombera aussi, un jour. Ce qui change n'est pas la promesse de ne jamais tomber, c'est la taille du rayon et la nature de la sortie. Quand le logiciel est sous licence libre et que le protocole est ouvert, partir se résume à une copie de vos données et à un changement d'enregistrement DNS. Il n'y a pas de renégociation, pas de format captif, pas de permission à demander. C'est la seule garantie qui vaut quelque chose, parce que c'est la seule qui ne dépend pas de notre bonne volonté.

Si l'inventaire de la section précédente vous a donné une liste plus longue que prévu, on jase de votre situation.


Sources

Un incident cyber sans assurance : ce que ça coûte vraiment à une PME
Statistique Canada n'arrive pas à publier le chiffre. Voici comment calculer le vôtre.