Endpoint Analytics : analyser les performances de démarrage et les anomalies

L’essentiel

Endpoint Analytics fournit des indicateurs sur le démarrage, la connexion, la fiabilité applicative et l’expérience du poste. Les scores vont de 0 à 100 et se comparent à des baselines, mais ils restent des instruments de priorisation.

Startup performance sépare notamment le boot, la phase Group Policy, l’accès au desktop et le temps jusqu’au desktop réactif. Les événements de démarrage et de connexion sont conservés pendant une fenêtre limitée, actuellement documentée à 29 jours.

Advanced Analytics ajoute notamment resource performance, battery health, anomalies, device timeline et device query selon licence. Le rapport Anomalies corrèle hangs, crashes ou stop errors avec des changements et des populations affectées.

Endpoint Analytics fournit des indicateurs sur le démarrage, la connexion, la fiabilité applicative et l’expérience du poste. Les scores vont de 0 à 100 et se comparent à des baselines, mais ils restent des instruments de priorisation.

Pourquoi cette technologie existe

Les appareils Intune ou co-managed doivent être enrôlés dans Endpoint Analytics et envoyer les données fonctionnelles requises. Un redémarrage est nécessaire après activation avant d’obtenir toutes les mesures.

Un score insuffisant peut signifier qu’il manque la population minimale ou des événements récents. Je commence par la couverture et la dernière remontée plutôt que par une comparaison du score.

Le startup score mesure le chemin jusqu’à la productivité. Total boot, Group Policy, time to sign-in prompt, time to desktop et time to responsive desktop isolent des phases qui appartiennent à des propriétaires différents.

Endpoint Analytics et anomalies s’appuie sur la chaîne Telemetry → Analytics → Drill-down → Action. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont licences Endpoint Analytics/Advanced Analytics, data collection policy, population et consentement gouvernés, redémarrage après activation. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Score zéro, Peu de devices et Modèle lent. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Telemetry ouvre la séquence: Démarrages, connexions, applications et matériel. Analytics prend ensuite le relais: Scores, baselines et cohortes. Le traitement se poursuit avec Drill-down, où Device, model, process et timeline. Enfin, Action ferme la boucle: Pilote, remédiation et mesure avant/après. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Score zéro » conduit d’abord à vérifier Policy et dernier upload, car la cause possible est Aucune donnée/activation. Pour « Peu de devices », la preuve utile devient Profile status et 25h. Les cas « Modèle lent » et « Anomalie après release » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Endpoint Analytics et anomalies expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions licences Endpoint Analytics/Advanced Analytics, data collection policy, population et consentement gouvernés, redémarrage après activation doivent être réunies en même temps. La validation porte ensuite sur Vérifier couverture et fraîcheur, Créer une baseline avant changement, Segmenter par modèle/version/site et Drill-down vers devices et processus. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

Les appareils Intune ou co-managed doivent être enrôlés dans Endpoint Analytics et envoyer les données fonctionnelles requises. Un redémarrage est nécessaire après activation avant d’obtenir toutes les mesures.

Un score insuffisant peut signifier qu’il manque la population minimale ou des événements récents. Je commence par la couverture et la dernière remontée plutôt que par une comparaison du score.

Le startup score mesure le chemin jusqu’à la productivité. Total boot, Group Policy, time to sign-in prompt, time to desktop et time to responsive desktop isolent des phases qui appartiennent à des propriétaires différents.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose licences Endpoint Analytics/Advanced Analytics, data collection policy, population et consentement gouvernés, redémarrage après activation, baseline avant changement. Ces conditions permettent de distinguer une limite de Endpoint Analytics et anomalies d’un scénario simplement non éligible.

• licences Endpoint Analytics/Advanced Analytics
• data collection policy
• population et consentement gouvernés
• redémarrage après activation
• baseline avant changement
• cohorte témoin
• accès device timeline et logs locaux

Cycle de fonctionnement, étape par étape

Le cycle de Endpoint Analytics et anomalies traverse Telemetry → Analytics → Drill-down → Action. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Endpoint Analytics et anomalies, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de Endpoint Analytics et anomalies

Les appareils Intune ou co-managed doivent être enrôlés dans Endpoint Analytics et envoyer les données fonctionnelles requises. Un redémarrage est nécessaire après activation avant d’obtenir toutes les mesures.

Un score insuffisant peut signifier qu’il manque la population minimale ou des événements récents. Je commence par la couverture et la dernière remontée plutôt que par une comparaison du score.

Le startup score mesure le chemin jusqu’à la productivité. Total boot, Group Policy, time to sign-in prompt, time to desktop et time to responsive desktop isolent des phases qui appartiennent à des propriétaires différents.

• licences Endpoint Analytics/Advanced Analytics
• data collection policy
• population et consentement gouvernés
• redémarrage après activation

Traitement, exploitation et cas limites de Endpoint Analytics et anomalies

Les baselines internes figent un point de comparaison avant un changement; la baseline All organizations fournit une médiane anonymisée. Je compare aussi des cohortes similaires en matériel, version et usage.

Les model scores aident à repérer une famille matérielle en difficulté, mais ne prouvent pas un défaut matériel. Drivers, firmware, image, applications et population utilisateur peuvent suivre le même modèle.

Le drill-down vers l’appareil, les processus de démarrage et la device timeline rapproche la mesure des événements concrets. Je vérifie Windows Update, installations, crashes, services et changements de policy autour de l’anomalie.

• Corréler anomalies aux changements
• Piloter une correction avec témoin
• Mesurer plusieurs cycles puis décider

Lire les états propres à Endpoint Analytics et anomalies

Le rapport Anomalies d’Advanced Analytics détecte des variations de hangs, crashes et stop error restarts, puis propose des groupes corrélés. Une corrélation avec un déploiement reste une hypothèse à confirmer sur les postes.

Une remédiation est testée sur une fraction de la population affectée avec une cohorte témoin. Je mesure médiane et percentiles, pas uniquement la moyenne, et j’attends une fenêtre comportant plusieurs démarrages.

La validation opérationnelle combine score, temps réels, tickets support, stabilité applicative et absence de régression. Une amélioration de boot obtenue en retardant un contrôle de sécurité n’est pas un résultat acceptable.

• Score zéro — Policy et dernier upload
• Peu de devices — Profile status et 25h
• Modèle lent — Comparaison cohortes
• Anomalie après release — Timeline et versions

Pilote et suivi opérationnel de Endpoint Analytics et anomalies

Le pilote couvre le périmètre Intune, Endpoint Analytics, Startup performance, Anomalies et contrôle Vérifier couverture et fraîcheur. Créer une baseline avant changement. Segmenter par modèle/version/site. Les résultats sont segmentés selon les populations réellement concernées par Endpoint Analytics et anomalies.

Les cas d’échec « Score zéro », « Peu de devices », « Modèle lent » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve score n’est pas cause, 29 jours de rétention des événements concernés, au moins cinq devices pour certains scores, respecter minimisation et RBAC. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Vérifier couverture et fraîcheur. Créer une baseline avant changement. Segmenter par modèle/version/site. Drill-down vers devices et processus. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Endpoint Analytics et anomalies, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,LastBootUpTime
  Get-CimInstance Win32_StartupCommand | Select-Object Name,Command,Location,User
  Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Diagnostics-Performance/Operational';Id=100,101,102,103,200} -MaxEvents 120 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
} catch { Write-Error "Collecte de démarrage impossible : $($_.Exception.Message)"; exit 1 }

Observabilité : où lire l’état réel

La chronologie de Endpoint Analytics et anomalies relie Telemetry, Analytics, Drill-down, Action. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Vérifier couverture et fraîcheur. Créer une baseline avant changement. Segmenter par modèle/version/site. Drill-down vers devices et processus. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Aucune donnée/activation », « Prérequis ou redémarrage », « Driver/image/application » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Vérifier couverture et fraîcheur.
• Créer une baseline avant changement.
• Segmenter par modèle/version/site.
• Drill-down vers devices et processus.
• Corréler anomalies aux changements
• Piloter une correction avec témoin
• Mesurer plusieurs cycles puis décider

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Vérifier couverture et fraîcheur, Créer une baseline avant changement, Segmenter par modèle/version/site et Drill-down vers devices et processus. Ces contrôles relient la configuration du service au résultat réellement observé.

• Vérifier couverture et fraîcheur.
• Créer une baseline avant changement.
• Segmenter par modèle/version/site.
• Drill-down vers devices et processus.
• Corréler anomalies aux changements
• Piloter une correction avec témoin
• Mesurer plusieurs cycles puis décider

Limites, modes de panne et lecture des erreurs

Les écarts connus de Endpoint Analytics et anomalies incluent Score zéro, Peu de devices, Modèle lent, Anomalie après release. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Endpoint Analytics et anomalies commence sur le périmètre Intune, Endpoint Analytics, Startup performance, Anomalies, Field Notes — Telemetry, Analytics, Drill-down, Action, licences Endpoint Analytics/Advanced Analytics, data collection policy, population et consentement gouvernés. Les limites et actions de réversibilité ci-dessous cadrent la progression.