Depuis le jeudi 12 novembre 2026 au soir, Outlook, Teams et plusieurs services de Microsoft 365 sont perturbés dans le monde entier. Selon Downdetector, cité par Le Monde, des utilisateurs ont signalé des problèmes dans 74 pays et territoires. Le vendredi 13 au matin, Microsoft parlait d’une « récupération partielle », sans heure de retour à la normale, et écartait la piste d’une cyberattaque.
Pour une entreprise, une panne de messagerie n’est pas qu’une boîte mail vide. Une partie des commandes, des confirmations et des rendez-vous de livraison circule encore par e-mail. Voici ce qui est tombé, ce qui continue de tourner, et pourquoi une commande peut rester bloquée alors que l’ERP fonctionne parfaitement.
Ce qui est tombé, et ce qui marche encore
D’après l’avis d’état de service cité par Reuters, seules les fonctions qui dépendent d’Exchange Online sont touchées. Exchange Online, c’est la plateforme qui gère les e-mails, les calendriers, les contacts et les tâches de Microsoft 365. Microsoft explique la panne par une surcharge d’une partie de ses serveurs dans plusieurs régions. Ses premiers correctifs n’ont pas tenu : dans la nuit, l’éditeur a reconnu que les mesures appliquées ne fonctionnaient « pas comme prévu ».
Les logiciels qui pilotent les flux physiques sont d’une autre nature : l’ERP, le WMS de l’entrepôt ou le TMS du transport tournent sur leurs propres serveurs ou leur propre cloud. Tant qu’ils ne passent pas par la messagerie, ils continuent de fonctionner. Le problème se situe à la jonction : là où un document créé dans l’ERP part chez un partenaire sous forme d’e-mail.
Les flux qui passent encore par la messagerie
Dans beaucoup d’entreprises, surtout avec les petits fournisseurs et transporteurs, l’e-mail sert de canal de transmission pour :
- la commande fournisseur, envoyée en PDF depuis l’ERP ;
- la confirmation de commande du fournisseur, avec la quantité et la date qu’il s’engage à livrer ;
- la réservation d’un transport auprès d’un affréteur ou d’un transporteur ;
- la prise de rendez-vous de quai, quand l’entrepôt n’a pas de portail dédié ;
- l’avis d’expédition, qui prévient l’entrepôt de ce qui arrive et quand.
Quand la messagerie tombe, aucun de ces documents ne disparaît : ils attendent. Mais une commande qui part avec 12 heures de retard, c’est un fournisseur qui la prépare un jour plus tard. Une confirmation qui n’arrive pas, c’est un approvisionneur qui ne sait pas si sa date de livraison tient. Pour un article déjà tendu, ce décalage peut suffire à créer une rupture.
Dans SAP : la commande est créée, mais pas envoyée
Prenons une commande d’achat créée dans SAP avec la transaction ME21N (le pas-à-pas est ici). À l’enregistrement, SAP génère un message de sortie : c’est lui qui transmet la commande au fournisseur, selon le canal paramétré pour ce fournisseur (impression, EDI ou e-mail).
Quand le canal est l’e-mail, SAP ne l’envoie pas lui-même : il le confie à un serveur de messagerie. Si ce serveur est Exchange Online, l’envoi échoue ou reste en file d’attente. Côté SAP, tout semble normal : la commande existe, elle a un numéro, le stock attendu apparaît. Côté fournisseur, rien n’est arrivé.
C’est le genre de situation qu’un key user doit savoir lire. Les envois en attente se suivent dans SAPconnect (transaction SOST), et le statut du message de sortie se vérifie dans la commande elle-même. Le paramétrage varie d’une entreprise à l’autre, mais le principe reste le même : une commande enregistrée n’est pas une commande reçue.
L’EDI, le flux qui ne dépend pas de la boîte mail
Les grands distributeurs et industriels échangent leurs commandes, confirmations et avis d’expédition par EDI : des messages structurés, transmis de machine à machine par un réseau ou un prestataire dédié. Ces flux ne passent pas par Exchange Online, ils n’ont donc aucune raison d’être touchés par cette panne.
Ce n’est pas qu’une question de technologie. L’EDI coûte cher à mettre en place, et il est rarement rentable avec un fournisseur qui reçoit dix commandes par an. C’est pour cela que l’e-mail reste le canal par défaut d’une grande partie des petits flux. Une panne comme celle-ci rappelle ce que ce choix implique : un seul fournisseur de messagerie devient un point de passage obligé pour des commandes. Le panorama des logiciels supply chain aide à situer qui fait quoi.
Ce que fait un approvisionneur le jour d’une panne
Le réflexe utile n’est pas d’attendre que la messagerie revienne. Pour un approvisionneur, la journée ressemble plutôt à ceci :
- Lister les commandes créées depuis le début de la panne qui devaient partir par e-mail.
- Trier par urgence : articles en rupture ou proches du stock de sécurité d’abord.
- Passer les urgences par un autre canal : téléphone, portail fournisseur, ou une autre messagerie si la politique de sécurité de l’entreprise l’autorise.
- Surveiller le retour à la normale : quand la file d’attente se vide d’un coup, un fournisseur prévenu par téléphone peut aussi recevoir la commande par mail. Il faut lui dire laquelle compte, pour éviter une commande en double.
- Relancer les confirmations manquantes dans les jours qui suivent, pour savoir quelles dates de livraison tiennent encore.
Le même raisonnement valait lors de la cyberattaque qui a touché des supermarchés en octobre : quand un maillon informatique tombe, les flux physiques ne s’arrêtent pas tout de suite, mais l’information qui les pilote prend du retard. Et c’est ce retard qui finit par se voir en rayon ou sur le quai.
Sources
- Solutions-Numériques, Panne Microsoft 365 : Exchange Online a cédé sous la charge, et les correctifs n’ont pas tenu, 13 novembre 2026 (d’après Reuters, Le Monde et l’AFP).
- BFM Business, Microsoft annonce une « reprise partielle » d’Outlook, 13 novembre 2026.
- ITdaily, Microsoft 365 toujours hors service : Outlook et Teams perturbés, 13 novembre 2026.
- franceinfo, Une panne mondiale touche la messagerie Outlook de Microsoft, 13 novembre 2026.
Laisser un commentaire