Quand Microsoft 365 ralentit, que Teams ne répond plus ou qu’Outlook ne reçoit plus les mails, il faut savoir si le problème vient de Microsoft ou de votre environnement. Pour une PME de moins de 50 utilisateurs, Service Health aide à vérifier les incidents connus, mais le prestataire doit surtout traduire l’impact, informer les utilisateurs et piloter les actions utiles.
Un incident Microsoft 365 peut toucher Exchange Online, Teams, SharePoint, OneDrive, Microsoft 365 Apps ou l’authentification. Mais tous les problèmes ne viennent pas de Microsoft. Un poste, un navigateur, une licence, un réseau local ou une configuration Outlook peuvent aussi être en cause.
Réponse courte :
Service Health Microsoft 365 permet de vérifier si un incident connu touche Exchange Online, Teams, SharePoint, OneDrive ou d’autres services. En PME, le prestataire doit consulter cette information, confirmer l’impact réel, expliquer qui est touché, proposer un contournement si possible et documenter le suivi jusqu’au retour à la normale.
Votre PME utilise Microsoft 365 au quotidien, mais personne ne suit clairement les incidents Microsoft, Service Health ou Message Center ? Axorys peut vous aider à surveiller l’état des services, qualifier les incidents, informer les utilisateurs, documenter les preuves et intégrer ce suivi dans une infogérance Microsoft 365.
Faire suivre Service Health dans une infogérance Microsoft 365
Service Health Microsoft 365 est une page du centre d’administration Microsoft 365 qui affiche les incidents, interruptions ou dégradations connus sur les services cloud Microsoft. Microsoft indique que cette page permet de consulter l’état de services comme Office pour le web, Microsoft Teams, Exchange Online ou Dynamics 365, avant d’appeler le support ou de lancer un dépannage inutile. (Microsoft Learn)
Service Health peut indiquer :
Le point important est simple : Service Health ne répare pas l’incident. Il évite surtout de diagnostiquer au mauvais endroit.
Si Exchange Online est en incident, il ne sert à rien de recréer tous les profils Outlook. Si Service Health est vert mais qu’un seul utilisateur est bloqué, il faut plutôt regarder le poste, le compte, le navigateur, Outlook, la licence ou le réseau.
Microsoft 365 propose plusieurs espaces de suivi. Ils ne répondent pas au même besoin.
| Outil | À quoi ça sert | Exemple PME | Limite |
|---|---|---|---|
| Service Health | Voir les incidents et dégradations de services Microsoft 365 | Exchange Online en incident | Ne dit pas tout sur votre poste ou réseau |
| Health dashboard | Voir une synthèse de la santé de l’environnement Microsoft 365 | Vue d’ensemble pour l’admin | Moins détaillé qu’une analyse incident |
| Message Center | Suivre les changements, maintenances et nouvelles fonctions | Changement Teams ou Exchange à venir | Ce n’est pas une page de panne temps réel |
| Support Microsoft | Escalader un incident ou une demande | Ticket Microsoft si nécessaire | Souvent géré par l’admin ou le prestataire |
| Reporting prestataire | Traduire en impact, actions et preuves | Rapport incident ou mensuel | Dépend du contrat d’infogérance |
Le Health dashboard du centre d’administration Microsoft 365 donne une vue d’ensemble de l’état des applications et services de l’organisation, avec des informations sur la santé des services, les mises à jour des applications et certaines recommandations. (Microsoft Learn)
Le Message Center sert à suivre les changements Microsoft 365 à venir : nouvelles fonctionnalités, modifications de services, maintenances planifiées ou actions demandées aux administrateurs. Microsoft le présente comme un outil pour aider les administrateurs à suivre les changements et actions nécessaires sur les services Microsoft 365. (Microsoft Learn)
Dans une petite entreprise sans DSI interne, Service Health sert surtout à éviter deux erreurs : perdre du temps sur un dépannage local pendant un incident Microsoft, ou accuser Microsoft alors que le problème vient d’un poste, d’un compte ou du réseau.
| Symptôme | Peut venir de Microsoft | Peut venir de votre environnement | Premier contrôle |
|---|---|---|---|
| Outlook ne reçoit plus de mails | Incident Exchange Online | DNS, profil Outlook, licence, réseau | Service Health + Outlook Web |
| Teams ne charge plus | Incident Teams | navigateur, poste, cache, proxy | Service Health + test autre poste |
| SharePoint est lent | Incident SharePoint | réseau, droits, navigateur, synchronisation | Service Health + accès web |
| OneDrive ne synchronise plus | Incident OneDrive | client sync, droits, poste, chemin trop long | Service Health + OneDrive web |
| Plusieurs utilisateurs sont touchés | Possible incident Microsoft | réseau local ou pare-feu | Service Health + test réseau |
| Un seul utilisateur est touché | Moins probable | poste, compte, licence, cache | Diagnostic local |
Si plusieurs utilisateurs signalent le même problème au même moment, Service Health devient prioritaire. Si un seul utilisateur est touché, il faut garder l’hypothèse locale ouverte.
Pour un problème Outlook détaillé, l’article Outlook ne se connecte plus à Exchange Online est plus adapté. Pour un problème OneDrive isolé, l’article synchronisation OneDrive bloquée en PME peut compléter le diagnostic.
Service Health se consulte dans le centre d’administration Microsoft 365. Microsoft indique qu’il faut aller dans Health > Service health, ou sélectionner la carte Service health depuis le centre d’administration. (Microsoft Learn)
Procédure courte :
L’accès est réservé aux rôles administrateur adaptés. Le dirigeant n’a pas forcément à gérer cette consultation lui-même. En revanche, le prestataire doit pouvoir fournir un résumé clair : service touché, impact, utilisateurs concernés, contournement possible et prochaine mise à jour.
Service Health peut afficher plusieurs services Microsoft 365. En PME, il faut surtout vérifier ceux qui impactent directement le travail quotidien.
| Service | Impact typique en PME | Exemple utilisateur |
|---|---|---|
| Exchange Online | Mails entrants/sortants, calendriers | “Je ne reçois plus mes mails” |
| Microsoft Teams | réunions, chats, fichiers de canal | “Teams ne charge pas” |
| SharePoint Online | bibliothèques, fichiers Teams, intranet léger | “Je n’accède plus au dossier partagé” |
| OneDrive for Business | synchronisation, fichiers personnels professionnels | “Mes fichiers ne se synchronisent plus” |
| Microsoft 365 Apps | Word, Excel, PowerPoint, activation, mises à jour | “Office demande une activation” |
| Microsoft Defender | sécurité mail ou alertes | “Des emails sont bloqués” |
| Microsoft Entra ID | connexion et authentification | “Impossible de se connecter” |
| Power Platform | formulaires, automatisations, applications | “Un flux ou une app ne fonctionne plus” |
Le Health dashboard donne une vue synthétique, mais le détail utile pendant un incident se trouve souvent dans Service Health. L’objectif n’est pas seulement de savoir “Microsoft est-il en panne ?”, mais de comprendre quel service est touché et quel usage métier est impacté.
Le rôle du prestataire n’est pas de réparer Microsoft. Son rôle est de diagnostiquer correctement, d’éviter les fausses pistes, de communiquer clairement et de documenter l’impact.
| Étape | Action prestataire | Livrable attendu |
|---|---|---|
| Détection | Vérifier Service Health et symptômes utilisateurs | Heure + service touché |
| Qualification | Déterminer si incident Microsoft ou local | Hypothèse documentée |
| Communication | Expliquer l’impact simplement | Message utilisateur |
| Contournement | Proposer une solution temporaire si possible | Procédure courte |
| Suivi | Surveiller les mises à jour Microsoft | Horodatage des updates |
| Escalade | Ouvrir ticket si nécessaire | Référence ticket |
| Clôture | Confirmer retour à la normale | Résumé incident |
| Prévention | Identifier les actions internes utiles | Plan d’action si besoin |
Un bon prestataire ne se contente pas d’écrire “Microsoft est en panne”. Il doit dire ce qui est touché, qui est concerné, ce que les utilisateurs peuvent faire, ce qui ne sert à rien, et quand le prochain point sera donné.
Pour une structure de 10 à 20 postes, un message clair vaut souvent mieux qu’une longue explication technique. Les utilisateurs veulent savoir ce qui est touché, quoi faire et quand ils auront une prochaine information.
Modèle court :
Nous constatons un incident Microsoft 365 affectant actuellement [service]. Les symptômes observés sont : [symptômes]. Microsoft indique que l’incident est en cours d’analyse / correction. Côté Axorys, nous suivons l’évolution, testons les contournements possibles et vous informerons de la prochaine mise à jour à [heure].
Ce message peut être envoyé par email si Exchange fonctionne, par Teams si Teams fonctionne, par SMS ou par un canal interne alternatif si les services Microsoft sont eux-mêmes touchés.
Le message doit éviter deux excès : trop de technique, ou trop peu d’information. Dire “c’est Microsoft” ne suffit pas. Il faut traduire l’impact : mails retardés, réunions Teams perturbées, accès SharePoint lent, synchronisation OneDrive instable.
Un incident Microsoft peut expliquer un problème collectif. Mais un problème local reste possible, même si plusieurs personnes sont touchées.
| Indice | Plutôt Microsoft | Plutôt local |
|---|---|---|
| Service Health confirme un incident | Oui | Non prioritaire |
| Plusieurs utilisateurs dans plusieurs lieux sont touchés | Oui | Possible mais moins probable |
| Un seul utilisateur est touché | Non prioritaire | Oui |
| Le problème disparaît en 4G | Non | Réseau local probable |
| Outlook Web fonctionne mais Outlook classique bloque | Non prioritaire | Poste ou profil Outlook probable |
| Teams web fonctionne mais application Teams bloque | Non prioritaire | Application, cache ou poste probable |
| Tous les services Microsoft sont lents sur le même réseau | Possible | Réseau, proxy ou DNS à vérifier |
| Microsoft publie un contournement | Oui | À appliquer si pertinent |
La bonne méthode consiste à tester plusieurs angles : utilisateur, poste, navigateur, réseau, accès web et Service Health. C’est ce qui évite de modifier des paramètres Microsoft 365 alors que l’incident est déjà connu côté Microsoft.
Un incident Microsoft 365 doit laisser des traces. Cela permet d’expliquer ce qui s’est passé, de répondre aux utilisateurs et d’améliorer les procédures.
| Élément à conserver | Pourquoi c’est utile |
|---|---|
| Heure du premier signalement | Reconstituer la chronologie |
| Utilisateurs touchés | Mesurer l’impact réel |
| Service concerné | Exchange, Teams, SharePoint, OneDrive, Entra |
| Capture Service Health | Prouver l’état Microsoft au moment donné |
| Identifiant d’incident Microsoft | Relier au suivi officiel |
| Mises à jour Microsoft | Suivre l’évolution |
| Contournements proposés | Montrer les actions tentées |
| Messages envoyés aux utilisateurs | Prouver la communication |
| Ticket prestataire | Garder la trace d’intervention |
| Résumé de clôture | Capitaliser pour le prochain incident |
Ces preuves sont importantes dans une infogérance Microsoft 365. Elles évitent les discussions floues après coup : “c’était Microsoft ou notre réseau ?”, “qui était touché ?”, “qu’a fait le prestataire ?”.
Service Health sert à vérifier les incidents connus Microsoft 365. Il ne remplace pas les outils de diagnostic propres à chaque service.
Exemples :
Si le problème concerne une migration récente, consultez la checklist après migration Microsoft 365. Service Health peut aider au diagnostic, mais il ne remplace pas une recette post-migration.
Azure Service Health concerne les services Azure et les régions Azure utilisées par une organisation. Microsoft le décrit comme une vue personnalisée de la santé des services et régions Azure que vous utilisez. (Microsoft Learn)
Ce n’est pas le bon point d’entrée pour un incident Microsoft 365 classique comme :
| Sujet | Service Health Microsoft 365 | Azure Service Health |
|---|---|---|
| Mails Exchange Online | Oui | Non prioritaire |
| Teams | Oui | Non prioritaire |
| SharePoint / OneDrive | Oui | Non prioritaire |
| Microsoft 365 Apps | Oui | Non prioritaire |
| Ressources Azure | Non principal | Oui |
| Régions Azure | Non principal | Oui |
| VM, App Service, services Azure | Non principal | Oui |
| Article Axorys ici | Oui | Non, hors sujet |
Cet article reste donc centré sur Service Health Microsoft 365 dans le centre d’administration Microsoft 365. Azure Service Health ne doit pas être mélangé au diagnostic PME Microsoft 365 standard.
Dans une TPE/PME où l’informatique est souvent gérée à temps partiel, les erreurs viennent souvent d’un manque de méthode pendant l’incident.
À éviter :
Le bon réflexe est simple : qualifier, informer, suivre, documenter.
Lors de nos suivis Microsoft 365, nous voyons souvent des utilisateurs signaler “Outlook est en panne”, alors que le problème concerne en réalité Exchange Online, le poste, le réseau ou un profil Outlook.
Chez certaines PME, Service Health n’est consulté qu’après 30 minutes de tests inutiles. C’est dommage, car cette vérification doit arriver tôt dans le diagnostic.
Nous voyons aussi l’inverse : Service Health est vert, mais tout le monde conclut trop vite que Microsoft n’est pas en cause. Un incident peut aussi être local : DNS, pare-feu, navigateur, licence, MFA ou cache Teams.
Un cas fréquent : le prestataire regarde l’incident, mais ne communique pas clairement aux utilisateurs. Résultat, chacun relance Outlook, redémarre son poste ou appelle le support.
Notre approche consiste à traduire l’information technique en impact simple : ce qui se passe, qui est touché, ce qui peut être fait, quand le prochain point arrive et quelle preuve sera conservée.
| Action | PME | Prestataire | Microsoft |
|---|---|---|---|
| Signaler les symptômes | Responsable | Appui | Non concerné |
| Vérifier Service Health | Appui si accès | Responsable si mandat | Publie l’état du service |
| Qualifier incident Microsoft ou local | Appui métier | Responsable | Fournit informations si incident |
| Communiquer aux utilisateurs | Responsable | Appui / modèle | Non concerné |
| Proposer contournement | Validation métier | Responsable | Peut publier recommandations |
| Ouvrir ticket Microsoft | Appui | Responsable si mandat | Traite selon support |
| Suivre mises à jour | Appui | Responsable | Publie updates |
| Documenter preuves | Appui | Responsable | Fournit identifiant incident |
| Clôturer incident | Validation | Responsable | Confirme résolution service |
| Tirer plan d’action interne | Responsable | Appui | Non concerné |
Ce tableau évite une confusion fréquente. Microsoft est responsable du service cloud. Le prestataire ne répare pas Microsoft. Mais il reste responsable du diagnostic, de la communication, du suivi, des contournements possibles et des preuves côté client si ce rôle est prévu dans son mandat.
| Page proche | Risque | Frontière à respecter |
|---|---|---|
/infogerance-microsoft-365 | L’article devient une page commerciale infogérance | Garder l’article pédagogique, CTA seulement en fin |
/guides-microsoft-365-pme/administration-tenant-microsoft-365-pme | Refaire administration tenant | Rester sur Service Health / Message Center |
/guides-microsoft-365-pme/secure-score-microsoft-365-pme | Confondre santé service et posture sécurité | Service Health = disponibilité, Secure Score = posture |
/guides-microsoft-365-pme/outlook-ne-se-connecte-plus-exchange-online | Devenir dépannage Outlook | Mentionner Outlook uniquement comme symptôme |
/guides-microsoft-365-pme/sync-onedrive-bloquee-pme | Devenir dépannage OneDrive sync | Mention courte seulement |
/guides-microsoft-365-pme/checklist-apres-migration-microsoft-365 | Devenir checklist post-migration | Service Health seulement comme outil de diagnostic |
/depannage-microsoft-outlook-et-exchange | Devenir page support mail | Lien secondaire seulement |
| Contenus Azure | Cannibalisation Azure Service Health | Exclure Azure du corps principal |
La frontière principale est simple : Service Health parle de disponibilité et d’incidents Microsoft 365. Secure Score parle de posture de sécurité. L’article Secure Score Microsoft 365 PME ne doit donc pas être mélangé à celui-ci.
Pour une entreprise qui utilise Microsoft 365 au quotidien sans administrateur dédié, Service Health doit être suivi comme un outil de pilotage, pas comme une page que l’on consulte seulement en panique. Un prestataire peut surveiller, interpréter, communiquer et documenter.
Déclencheurs fréquents :
Ce suivi s’intègre naturellement dans une infogérance Microsoft 365, avec des tickets, des preuves, des synthèses et des actions documentées.
Pour replacer ce sujet dans une vision plus large, consultez le guide Microsoft 365 pour PME de moins de 50 utilisateurs ou les guides Microsoft 365 PME.
Service Health Microsoft 365 est une page du centre d’administration Microsoft 365 qui permet de consulter l’état des services cloud comme Exchange Online, Teams, SharePoint, OneDrive ou Microsoft 365 Apps. Elle aide à savoir si un incident connu est en cours avant de lancer un dépannage local. (Microsoft Learn)
Service Health se trouve dans le centre d’administration Microsoft 365, dans Health > Service health. Microsoft indique aussi qu’il est possible d’y accéder via la carte Service health depuis le centre d’administration. (Microsoft Learn)
Service Health sert à suivre les incidents, interruptions et dégradations de services Microsoft 365. Message Center sert à suivre les changements à venir, fonctionnalités nouvelles ou modifiées, maintenances planifiées et annonces importantes qui peuvent demander une action. (Microsoft Learn)
Non. Service Health aide à identifier un incident Microsoft connu, mais il ne remplace pas un diagnostic complet. Si un seul utilisateur est touché, le problème peut venir du poste, du compte, d’Outlook, du navigateur, du réseau, de la licence ou d’une configuration locale.
Il doit vérifier Service Health, qualifier l’impact réel, informer les utilisateurs, proposer un contournement si possible, suivre les mises à jour Microsoft, conserver les preuves et clôturer l’incident avec un résumé clair.
Pas pour un incident Microsoft 365 classique. Azure Service Health concerne les services et régions Azure utilisés. Cet article reste centré sur Service Health Microsoft 365 dans le centre d’administration Microsoft 365. (Microsoft Learn)
Parce qu’un incident Microsoft 365 peut impacter les mails, Teams, SharePoint, OneDrive ou les applications Office. Dans une infogérance, le prestataire doit transformer l’information technique en impact métier, communication utilisateur, preuve et suivi.
Contactez un prestataire si personne ne consulte Service Health, si les utilisateurs ne sont pas informés pendant les incidents, si les diagnostics partent dans tous les sens, ou si vous voulez un suivi Microsoft 365 avec preuves, reporting et actions documentées.
Service Health Microsoft 365 est un outil simple, mais il doit être utilisé au bon moment. Il permet de vérifier si un incident Microsoft connu touche Exchange Online, Teams, SharePoint, OneDrive ou d’autres services. Il évite de perdre du temps sur de fausses pistes.
Mais Service Health ne remplace pas le diagnostic. Un problème peut aussi venir du poste, du compte, du réseau, du navigateur, d’Outlook, d’une licence ou d’une configuration locale.
Pour une PME, le vrai sujet est le pilotage : qualifier l’incident, informer les utilisateurs, proposer un contournement, suivre les mises à jour Microsoft et conserver les preuves.
Votre PME utilise Microsoft 365 au quotidien, mais personne ne suit clairement les incidents Microsoft, Service Health ou Message Center ? Axorys peut vous aider à surveiller l’état des services, qualifier les incidents, informer les utilisateurs, documenter les preuves et intégrer ce suivi dans une infogérance Microsoft 365.
Faire suivre Service Health dans une infogérance Microsoft 365