Oui, la panne Microsoft 365 est réelle. Depuis jeudi 12 novembre au soir, Outlook, Teams et Copilot fonctionnent mal ou pas du tout, et le rétablissement n’est que partiel en Europe ce vendredi après-midi. Votre site WordPress ou PrestaShop, lui, reste en ligne. Mais si la messagerie de votre entreprise est chez Microsoft, des demandes de contact, des alertes de commande et des mails destinés à vos clients sont peut-être en attente, voire bloqués. Voici comment le vérifier en quelques minutes, et ce que nous conseillons de faire.
Panne Microsoft 365 : services touchés, cause et état du rétablissement
L’incident a commencé jeudi peu avant 19 h, heure de Paris, avec des signalements dans 74 pays, dont la France. Il part d’Exchange Online, le service qui héberge les boîtes mail professionnelles. Outlook est donc touché sur tous les supports : la version web, le logiciel de bureau et l’application mobile ne se connectent plus, et les envois partent avec plusieurs heures de retard. Sur Teams, ce sont surtout le calendrier et la planification des réunions qui posent problème. Copilot est perturbé lui aussi.
Microsoft explique qu’un processus serveur chargé des connexions sécurisées a saturé. L’éditeur a commencé à annuler une modification récente de sa configuration réseau, qui coïncide avec le début de l’incident, sans en faire pour l’instant la cause officielle. Il dit n’avoir aucun indice de cyberattaque. Vendredi vers 14 h 30, Microsoft annonçait des améliorations durables dans une grande partie de l’Europe. Des coupures intermittentes restent possibles, et aucune date de retour complet n’a été donnée. Pour suivre l’évolution, consultez la page d’état du service de Microsoft. Si vous administrez le compte, le centre d’administration Microsoft 365 donne le détail de l’incident.
Formulaires, commandes, mails du site : ce qui ne passe plus et comment le vérifier
Le site continue d’enregistrer les commandes et les demandes. Ce qui coince, c’est le trajet des mails, et il faut distinguer deux cas.
Premier cas : les messages adressés à une boîte Microsoft 365. Ce sont par exemple la notification d’un formulaire de contact envoyée à contact@votredomaine, ou l’alerte de nouvelle commande. Le serveur qui les expédie les met en général en file d’attente, puis les remet au retour du service. Ces mails sont retardés, pas perdus, mais vous ne les voyez pas. La mairie de Vichy a ainsi dû prévenir qu’on ne pouvait plus la joindre, ni par mail ni par ses formulaires en ligne.
Second cas : les mails que le site envoie lui-même par le serveur SMTP de Microsoft 365. Le serveur SMTP est le serveur d’envoi de votre messagerie, réglé dans une extension SMTP sous WordPress ou dans les paramètres e-mail de PrestaShop. Pour envoyer, le site doit s’identifier auprès de Microsoft. Or tout ce qui s’authentifie auprès de Microsoft 365 peut échouer en ce moment, y compris les connecteurs d’outils tiers. Si l’envoi est refusé, la confirmation de commande ne part pas, et ni WordPress ni PrestaShop ne retentent l’envoi par défaut. Passer par Thunderbird en IMAP n’y change rien, car les boîtes restent sur l’infrastructure de Microsoft.
Pour faire le point, fiez-vous au site plutôt qu’à votre boîte mail :
- Dans le back-office, listez les commandes passées depuis jeudi 19 h et comparez-les aux alertes reçues. Une boutique qui fait 25 commandes par jour en a peut-être une vingtaine à traiter sans le savoir.
- Consultez les entrées de formulaire enregistrées en base de données, si votre extension les conserve. Ce n’est pas le cas de toutes.
- Ouvrez les journaux d’envoi : celui de votre extension SMTP sous WordPress, ou la rubrique « E-mail » des paramètres avancés sous PrestaShop. Repérez les envois en erreur depuis jeudi soir.
- Envoyez un mail de test depuis le site vers une adresse hors Microsoft, une adresse Gmail personnelle par exemple, et vérifiez qu’il arrive.
Rester joignable pendant la panne, puis ne plus dépendre d’une seule messagerie
Tant que le service n’est pas revenu partout, le but est qu’aucun client ne reste sans réponse. Un bandeau en haut du site, qui signale le problème et donne un numéro de téléphone, suffit souvent. Faites aussi envoyer les notifications des formulaires vers une adresse de secours hébergée hors de Microsoft. Et traitez les commandes depuis le back-office plutôt qu’à partir des alertes mail.
Au bureau, le mode Exchange en cache d’Outlook et la fonction « Travailler hors connexion » donnent accès aux messages déjà synchronisés, mais pas aux nouveaux. Gardez ces solutions de secours en place après les premières améliorations. Microsoft reconnaît en effet que des serveurs remis en service peuvent redevenir indisponibles dès qu’ils reçoivent du trafic.
Si votre site a peu souffert de cette panne, c’est le moment de régler la question de fond. Nous conseillons de séparer les envois du site de la messagerie de bureau. Les confirmations, les factures et les notifications de formulaire passent alors par un service transactionnel, c’est-à-dire spécialisé dans les mails automatiques. L’équipe, elle, garde Microsoft 365 pour son courrier. Ainsi, une panne de messagerie ne coupe plus le parcours d’achat.
Ce service doit être déclaré dans les enregistrements SPF et DKIM de votre domaine. Ce sont deux réglages DNS qui prouvent que le site a le droit d’écrire en votre nom ; sans eux, les confirmations finissent en spam. Attention à un piège : un domaine n’accepte qu’un seul enregistrement SPF. Il faut donc compléter la ligne existante plutôt qu’en ajouter une seconde.
Ajoutez l’enregistrement systématique des formulaires en base, pour qu’aucune demande ne dépende d’un mail. Mettez aussi en place une surveillance de la délivrabilité, avec une alerte dès qu’un envoi échoue : vous serez prévenu avant que vos clients ne s’en plaignent. Le raisonnement vaut aussi pour l’hébergement, comme l’a rappelé la panne OVH du 2 octobre.
Quand Microsoft annoncera un retour complet, refaites les quatre vérifications ci-dessus. Les mails retardés arriveront par paquets ; seuls les envois marqués en erreur dans les journaux seront à renvoyer à la main.
