Voir la démo
Cette page a été traduite automatiquement à partir de l'original allemand. Certaines formulations peuvent donc s'en écarter. Vous pouvez consulter la version allemande ou anglaise d'origine. Vous avez repéré une erreur ? Signalez-la-nous.
Diagnostic Zscaler

Est-ce Zscaler ou le Wi-Fi ? Analyse de cause racine en quelques minutes

Un appel Teams saccade, et la première phrase du ticket est presque toujours la même : « C'est sûrement Zscaler. » Ce n'est souvent pas vrai. Mais prouver le contraire coûte des heures au helpdesk. Il existe plus rapide.

CentaurNexus · Temps de lecture environ 10 minutes
Analyse de cause racine d'une connexion, illustration

Chaque équipe IT connaît la scène. Un collaborateur appelle, l'appel vidéo se bloque, l'application cloud met du temps à charger. Comme Zscaler se trouve en ligne dans le flux de données en tant que couche de sécurité et inspecte tout le trafic, c'est l'élément le plus visible de la chaîne, et donc le premier suspect. Le réflexe « c'est Zscaler » est compréhensible, mais c'est une supposition, pas un diagnostic.

En réalité, la cause est tout aussi souvent un Wi-Fi domestique surchargé, une liaison FAI défaillante, un ordinateur portable gourmand en CPU, ou une application qui rencontre elle-même des problèmes en ce moment. Le hic : le helpdesk doit d'abord le prouver laborieusement. Et tant que la preuve n'est pas établie, le soupçon reste attaché à la passerelle de sécurité, qui objectivement ne fait rien de mal.

Pourquoi la question de la faute coûte si cher

Le processus classique consomme du temps à plusieurs endroits à la fois. Le premier niveau prend le ticket en charge, mais ne peut pas consulter lui-même la chaîne réseau et escalade. Le deuxième niveau ouvre plusieurs vues : le tableau de bord ZDX, peut-être un outil de supervision réseau séparé, l'inventaire des appareils. Il corrèle les horodatages à la main, vérifie si une politique s'appliquait au moment de l'incident, et finit par formuler une évaluation qu'il doit expliquer à l'utilisateur.

Chacune de ces transmissions coûte des minutes, voire des heures. Et parce que le soupçon reste en suspens sans constat solide, il retombe en cas de doute sur l'équipe sécurité, qui doit alors à son tour prouver que tout fonctionne correctement. Au final, c'était le Wi-Fi du télétravail, mais quatre personnes s'en sont occupées.

Problème central : ce n'est pas Zscaler qui est lent, c'est le diagnostic. Les données pour une clarification propre de la cause sont disponibles depuis longtemps, réparties entre les métriques ZDX, le statut de politique et les informations sur l'appareil. Ce qui manque, c'est la mise en relation automatique et un verdict qu'un agent de premier niveau comprend en quelques secondes.

Zscaler fournit déjà les données : ZDX

Zscaler Digital Experience, ZDX en abrégé, mesure l'expérience numérique de l'utilisateur de bout en bout. Il capture les métriques de l'appareil (CPU, mémoire, signal Wi-Fi), la liaison réseau locale, le trajet via le fournisseur d'accès Internet et le trajet à travers le cloud Zscaler jusqu'à l'application cible. Le ZDX Deep Trace montre chaque saut individuel avec la latence et la perte de paquets. L'information sur l'endroit exact où ça coince est donc techniquement disponible.

Le hic n'est pas dans les données, mais dans l'accès et l'interprétation. Le Deep Trace est un outil pour spécialistes. Il montre des valeurs brutes sur l'ensemble du trajet, mais il ne dit pas en une phrase : « Le Wi-Fi de l'utilisateur est le goulot d'étranglement, Zscaler est sans particularité. » C'est précisément cette traduction de la mesure vers l'énoncé qui est l'étape qui consomme du temps au quotidien et qui suppose des droits d'administration que le helpdesk n'a souvent pas.

Connectivity Triage Map : réunir la chaîne, nommer la cause

C'est ici qu'intervient Connectivity Triage Map de CentaurNexus. Le module réunit, via l'OneAPI officielle de Zscaler, la chaîne ZDX complète et la complète avec le statut de politique actuel pour l'utilisateur et l'application concernés. À partir de ces signaux, il forme un verdict en langage clair : la cause se situe au niveau du FAI, du Wi-Fi, de l'appareil ou de Zscaler.

La différence n'est pas l'accès à de nouvelles données, mais le diagnostic au lieu des données brutes. Plutôt que d'ouvrir cinq onglets et de comparer des horodatages, l'agent voit un constat nommé et, en dessous, dépliable, la preuve du Deep Trace saut par saut. Qui veut vérifier plus en profondeur voit la chaîne ; qui doit seulement agir voit le verdict.

Comment se déroule une analyse Connectivity Triage Map
  1. Sélectionner l'utilisateur et l'application à partir du ticket (un nom suffit, aucune console d'administration Zscaler n'est nécessaire).
  2. Connectivity Triage Map réunit la chaîne ZDX et le statut de politique via l'OneAPI et les évalue.
  3. Le verdict en langage clair apparaît : FAI, Wi-Fi, appareil ou Zscaler, avec le point le plus faible de la chaîne.
  4. Le ZDX Deep Tracing montre au besoin chaque saut avec latence et perte de paquets, à titre de preuve.
  5. Le constat peut être exporté comme preuve et joint au ticket, à l'utilisateur ou au fournisseur.

Langage clair, aussi pour le premier niveau

Le levier pratique tient à qui peut mener l'analyse. Comme Connectivity Triage Map formule le résultat dans un langage compréhensible, tous les cas n'ont pas besoin d'escalader vers un spécialiste réseau. Un agent de premier niveau lit « goulot d'étranglement dans le Wi-Fi local, Zscaler sans particularité » et peut donner directement la bonne recommandation : se rapprocher du routeur, vérifier la bande passante, décharger l'appareil. L'escalade disparaît précisément dans les cas où elle n'aurait jamais été nécessaire.

Équitable plutôt que réflexe : l'objectif de Connectivity Triage Map n'est pas de dédouaner Zscaler, mais de nommer proprement la cause, où qu'elle se situe. Si une politique ou un trajet cloud est réellement le problème, le verdict le dit exactement, avec la même preuve à l'appui. Moins d'attribution erronée signifie : l'équipe sécurité passe moins de temps à prouver son innocence et plus de temps sur de vrais sujets.

Le constat comme preuve

Un point souvent sous-estimé : lorsque la cause se situe en dehors de sa propre sphère d'influence, par exemple chez un fournisseur d'accès Internet ou sur une connexion de télétravail, l'IT a besoin d'une preuve solide pour transmettre le sujet. Un constat Connectivity Triage Map exportable avec preuve ZDX Deep Tracing est exactement cette preuve. Il documente de façon traçable à quel endroit de la chaîne la latence ou la perte de paquets est apparue, et retire la spéculation de la discussion.

CentaurNexus sépare les contextes de tenant, attribue les droits selon les rôles et journalise les opérations de façon traçable. Le helpdesk voit son périmètre autorisé sans droits d'administration Zscaler étendus. Pour les clients européens, l'exploitation en production se fait entièrement sur STACKIT dans l'UE ; les trajets de protection des données sont documentés dans la déclaration de confidentialité.

Voir Connectivity Triage Map sur un cas réel

Dans la démo préparée, nous menons une analyse de cause racine de bout en bout : du signalement « ça saccade » jusqu'au verdict en langage clair avec preuve ZDX Deep Tracing, sans droits d'administration Zscaler étendus.

Ouvrir la démo préparée

ZDX et CentaurNexusAgent se complètent

ZDX fournit l'expérience numérique sur l'application, le trajet réseau et l'appareil. CentaurNexusAgent complète ce regard par les signaux de terminal nécessaires au flux CentaurNexus pris en charge, lorsque ces informations ne sont pas disponibles via l'OneAPI. CentaurNexusAgent complète le contexte ZDX par des signaux de terminal pour les workflows CentaurNexus pris en charge.

Connectivity Triage Map relie les signaux disponibles en une chaîne cause-effet traçable. Elle montre si l'indice le plus fort se situe au niveau de l'appareil, du réseau local, du trajet Zscaler ou de l'application. Source, ancienneté des données et couverture restent partie intégrante du résultat.

Un constat doit mener à l'action suivante

Un diagnostic n'est utile au helpdesk que lorsqu'il explique l'étape de vérification suivante. Un signal Wi-Fi local mène à une action différente d'un App Connector inaccessible ou d'une panne centrale de service. L'agent voit le classement motivé et peut résoudre ou transmettre de façon ciblée.

Lors de la recette, des sources complètes, partiellement disponibles et délibérément manquantes sont testées. Connectivity Triage Map reste ainsi compréhensible même lorsqu'un tenant ne fournit pas chaque source ZDX ou d'agent.

Questions fréquentes

Comment déterminer si un problème de performance vient de Zscaler ou du réseau ?

Le point déterminant est d'examiner l'ensemble de la chaîne, de l'appareil au Wi-Fi, au FAI et à Zscaler jusqu'à l'application. Zscaler ZDX fournit précisément ces métriques saut par saut. Connectivity Triage Map de CentaurNexus réunit automatiquement la chaîne ZDX et le statut de politique et nomme en langage clair le point le plus faible, au lieu qu'un analyste rassemble manuellement les données brutes.

Qu'est-ce que le ZDX Deep Trace ?

Zscaler Digital Experience (ZDX) mesure l'expérience utilisateur de bout en bout. Le Deep Trace montre chaque saut réseau entre l'appareil et l'application cible avec la latence et la perte de paquets, ainsi que des métriques d'appareil et de Wi-Fi. Cela permet de voir si le goulot d'étranglement est local, chez le fournisseur, ou sur le trajet cloud.

Le helpdesk a-t-il besoin de droits d'administration Zscaler pour cela ?

Non. CentaurNexus lit via l'OneAPI officielle de Zscaler et présente le constat de façon basée sur les rôles. Les premier et deuxième niveaux voient le verdict et le Deep Trace sans avoir besoin d'un accès complet à l'administration Zscaler. Tous les accès sont séparés par tenant et auditables.

Pourquoi mon Internet devient-il lent avec Zscaler ?

Souvent, ce n'est pas le cas : Zscaler se trouve en ligne dans le flux de données et inspecte le trafic, ce qui en fait l'élément le plus visible de la chaîne et le premier suspect. Tout aussi souvent, la cause est un Wi-Fi surchargé, une liaison FAI défaillante, un appareil saturé ou une application ayant ses propres problèmes. Connectivity Triage Map réunit la chaîne ZDX et le statut de politique et nomme la cause réelle, au lieu d'en rester à une supposition.

Si un appel Teams ou une application cloud saccade, est-ce toujours la faute de Zscaler ?

Non. La passerelle de sécurité n'est qu'un maillon d'une chaîne qui comprend aussi l'appareil, le Wi-Fi local, le fournisseur d'accès Internet et l'application elle-même. Le maillon réellement faible diffère d'un cas à l'autre. C'est exactement pourquoi un verdict en langage clair sur l'ensemble de la chaîne aide davantage qu'une supposition réflexe.

Que puis-je vérifier moi-même avant d'accuser Zscaler d'une connexion lente ?

Se rapprocher du routeur, vérifier la bande passante disponible et fermer les applications en arrière-plan gourmandes en CPU résolvent une grande partie des plaintes quotidiennes, car le Wi-Fi local ou un appareil saturé en sont des causes fréquentes. Si le problème persiste ensuite, il vaut la peine de faire réaliser par l'IT une véritable vérification de cause racine sur l'ensemble de la connexion.

L'IT peut-elle prouver à un utilisateur ou à un fournisseur que la cause se situe réellement en dehors de Zscaler ?

Oui. Un constat exportable avec preuve ZDX Deep Trace documente, saut par saut, l'endroit exact où la latence ou la perte de paquets est apparue. Une discussion fondée sur un soupçon devient ainsi une discussion fondée sur une preuve, que la cause se révèle finalement être le FAI, le Wi-Fi, l'appareil ou, parfois, Zscaler lui-même.

Sources et pour aller plus loin :