Le mobile pour des décisions courtes et claires
L'app affiche le contexte de tenant nécessaire, la demande et les informations pertinentes pour la décision. Elle prend en charge les décisions d'accès simples. N'en font pas partie les refontes de règles complexes ni les droits d'écriture administratifs étendus.
Les changements complexes restent dans le cockpit web
Dépendances entre règles, inclusions et exclusions, tunnels, changements de Policy étendus et analyses approfondies ont besoin de suffisamment d'espace et de contexte. Ces processus restent dans l'interface web. Le mobile doit faciliter les décisions, pas comprimer l'administration complète sur un petit écran.
- Vérifier le tenant et la demande.
- Lire la source, le statut et le contexte pertinent pour la décision.
- Décider une approbation simple ou la laisser ouverte pour examen complémentaire.
- Suivre le résultat et le read-back dans le cas.
iOS et Android
L'app native est distribuée via l'Apple App Store et Google Play. Rôles et isolation des tenants s'appliquent comme sur le web. Un MSP ne voit que les tenants réellement gérés.
La vue de décision d'accès réunit demandeur, destination, justification, tenant, validité et statut actuel. L'administrateur n'a pas besoin de rassembler ces informations depuis plusieurs interfaces. Après la décision, le résultat reste synchronisé avec le cas dans le cockpit web, de sorte que le travail mobile et sur poste fixe affichent le même état de traitement.
Ce qui rend une décision mobile complète
Un bouton « Approuver » ou « Refuser » ne suffit pas. Avant une décision, l'app doit au moins montrer pour quel tenant et quelle demande elle s'applique, qui a déclenché le cas, quelle justification existe et quel statut actuel fait foi. Selon le processus, s'y ajoutent source, ancienneté des données, couverture et état cible attendu.
La présentation est volontairement réduite au besoin de décision. Les informations détaillées restent accessibles sans forcer l'utilisateur à naviguer dans une interface d'administration complète. Si le contexte ne suffit pas pour une décision fiable, le cas reste ouvert et peut être examiné plus avant dans le cockpit web.
Décisions d'accès simples typiques
Le mobile convient à des demandes clairement délimitées, comme une décision d'accès à un seul site ou une seule application, pour autant que la Policy du tenant et le rôle autorisent ce circuit de décision. La demande contient le motif métier et le contexte de risque ou de Policy disponible. L'app n'affiche jamais de décision groupée portant sur plusieurs changements indépendants.
Même un cas apparemment simple reste rattaché à un tenant. Pour un MSP, il doit donc être clairement visible, avant chaque décision, à quel client géré la demande appartient. Changer de tenant ne doit jamais emporter la décision sélectionnée.
De la décision à l'effet confirmé
La décision mobile n'est qu'une étape du processus global. Si elle déclenche un changement sur le système cible Zscaler, l'adaptateur responsable prend en charge l'exécution contrôlée. CentaurNexus ne confirme le succès qu'une fois l'effet obtenu et lorsqu'un read-back montre l'état attendu.
L'administrateur peut ensuite suivre le statut dans l'app. « Décidé » et « effectif » restent distincts. En cas d'écart, l'app renvoie vers le cas plutôt que de masquer une erreur technique derrière une décision réussie.
Pourquoi le travail complexe sur les Policy demande plus d'espace
Une règle peut contenir inclusions, exclusions, ordre, tunnels, groupes, conditions temporelles et d'autres dépendances. Ces relations doivent être visibles ensemble avant un changement. Un petit écran n'est pas le bon endroit pour une refonte approfondie comportant de nombreux points de comparaison.
Le cockpit web offre pour cela l'espace de travail plus large et les circuits de contrôle complets. L'app facilite la partie qui a du sens et reste délimitée sur mobile. Cette répartition des tâches réduit les erreurs de manipulation et rend l'interface mobile plus rapidement compréhensible.
Sécurité et limites de session
L'app utilise le même modèle de rôles et de tenants que l'interface web. Une connexion mobile n'étend aucun droit. Statut de session, accès révoqués et rattachement à l'opérateur authentifié doivent être valides avant une décision.
La protection des appareils et la distribution via les stores sont coordonnées avec le mode d'exploitation du client. Le déploiement ZCC assisté par MDM et le premier connecteur MDM concret sont des décisions distinctes et dépendantes, non préjugées par la disponibilité de l'app d'administration.
Une notification sans pression décisionnelle
Des notifications push peuvent signaler une décision d'accès nouvelle ou en retard. La notification elle-même ne devrait contenir que le contexte nécessaire. La décision proprement dite intervient après ouverture du cas protégé.
L'app ne doit créer aucune urgence artificielle. Priorité, échéance et impact doivent provenir du cas lui-même. Si une demande nécessite un examen plus approfondi, « à examiner plus tard sur le web » est une décision correcte, pas une erreur du parcours mobile.
Comportement en cas de mauvaise connexion
Une interface mobile est plus souvent utilisée dans des réseaux changeants. Si le statut actuel ne peut pas être chargé de façon fiable, l'app ne doit jamais présenter d'information obsolète comme base de décision. Ancienneté des données et statut de connexion doivent rester identifiables.
Une décision n'est acceptée qu'après transmission confirmée. Des décisions d'accès groupées mises en cache hors ligne ne seraient pas compatibles avec ce modèle. L'utilisateur reçoit à la place une réponse claire et peut rouvrir le cas une fois la connexion rétablie.
Mesurer utilement l'usage mobile
Pour la recette produit, le nombre d'installations seul n'est pas pertinent. Ce qui compte : les décisions d'accès simples menées à bien, les cas interrompus faute de contexte, le temps jusqu'à la décision, le rattachement correct au tenant et la part des cas volontairement poursuivis sur le web.
Un passage au web n'est pas automatiquement négatif. Pour des tâches complexes, il démontre que la limite prévue fonctionne. Les indicateurs sont évalués par tenant et par phase de déploiement, et non publiés comme une revendication générale de performance.
Une journée de travail mobile typique
Une administratrice reçoit, en déplacement, le signal d'une demande d'accès à une seule application. Elle ouvre le cas protégé, vérifie tenant, demandeur, justification et contexte disponible, et prend la décision simple. L'exécution technique se poursuit ensuite indépendamment de la connexion mobile, dans le backend contrôlé.
Une demande de Policy comportant plusieurs dépendances apparaît plus tard. L'app indique qu'un examen complet est nécessaire sur le web. Le cas reste ouvert, conserve sa priorité et peut être poursuivi sur notebook sans nouvelle recherche.
Accessibilité et lisibilité sur petits écrans
Motif de décision, tenant et action principale doivent rester compréhensibles même avec un texte agrandi et un lecteur d'écran. La couleur seule ne doit jamais porter un statut de risque ou d'erreur. Ordre de focus, zones tactiles et boîtes de dialogue de confirmation sont vérifiés séparément sur iOS et Android.
Recette avant la distribution en store
- Fixer de façon contraignante la liste des décisions d'accès mobiles simples.
- Tester rôles et changement de tenant pour les équipes internes et les MSP.
- Vérifier le contexte de décision sur petits et grands appareils.
- Valider read-back, statuts d'erreur et sessions révoquées.
- Vérifier le contenu des notifications push et la confidentialité sur écran verrouillé.
- Vérifier l'empaquetage pour l'Apple App Store et Google Play.
L'app native facilite les décisions administratives courtes. Elle reste partie de la même gouvernance que le cockpit web et garde le travail complexe là où le contexte requis peut être présenté intégralement.
Questions fréquentes
Quels systèmes l'app prend-elle en charge ?
L'app native est prévue pour iOS et Android, avec distribution via les stores respectifs.
Puis-je remanier des règles complexes depuis le mobile ?
Non. L'app prend en charge les décisions d'accès simples. Les refontes de règles complexes restent dans le cockpit web.
Les mêmes rôles s'appliquent-ils sur mobile ?
Oui. Contexte de tenant, rôles et Policy d'approbation s'appliquent aussi dans l'app.
L'app d'administration est-elle la même chose que l'app Zscaler Client Connector sur mon téléphone ?
Non. Zscaler Client Connector est l'app utilisateur final propre à Zscaler, qui relie un appareil au service Zscaler. CentaurNexusMobile est une app d'administration distincte pour examiner et décider des décisions d'accès simples. Les deux fonctionnent indépendamment et s'adressent à des publics différents.
Quelles décisions d'accès puis-je réellement traiter depuis mon téléphone ?
Des demandes clairement délimitées, comme une décision d'accès à un seul site ou une seule application, pour autant que la Policy du tenant et votre rôle autorisent ce circuit de décision. L'app ne transforme jamais plusieurs changements indépendants en une décision groupée, et ne prend pas en charge les refontes de règles complexes.
Serai-je averti quand une décision d'accès m'attend ?
Oui, des notifications push signalent une décision d'accès nouvelle ou en retard, mais la notification elle-même ne contient que le contexte nécessaire. La décision proprement dite n'intervient qu'après ouverture du cas protégé, jamais depuis la notification.
Que se passe-t-il si ma connexion se coupe pendant que je décide sur mon téléphone ?
L'app ne présente jamais d'information obsolète comme base de décision actuelle, et une décision n'est acceptée qu'après transmission confirmée. En cas de connexion instable, le cas reste ouvert et peut être repris une fois la connexion rétablie.
En tant que MSP gérant plusieurs clients, un tenant peut-il être confondu pendant une décision ?
Non. Chaque cas reste rattaché à son tenant, et un MSP ne voit que les tenants qu'il gère réellement. Changer de tenant n'emporte jamais une décision sélectionnée vers le contexte d'un autre client.
Sources et pour aller plus loin
Voir le déroulement dans son contexte
Choisissez le rôle correspondant dans le lanceur de démo. La démo utilise des données d'exemple préparées.
Ouvrir le lanceur de démo