Aller au contenu
FR

Modèle opérationnel

LocalGuard répartit une même politique entre des composants aux responsabilités distinctes. Le panneau l’administre, le Core détermine la configuration applicable à chaque appareil et l’agent ou l’extension exécute uniquement la mesure correspondante.

Enregistrer une règle ne signifie pas qu’elle est déjà appliquée. Le Core interprète le changement à partir de l’appareil, de sa relation avec le compte et des conditions de la politique. Le composant associé reçoit ensuite la décision et peut en signaler le résultat.

Le panneau permet de définir règles de filtrage, limites de temps, horaires et décisions concernant les appareils. Il regroupe aussi l’appareil, son état connu et les actions en attente. Il ne bloque pas directement le trafic.

Le Core conserve la référence de configuration et évalue la politique applicable à chaque appareil. Le changement demandé, la décision calculée et l’état transmis restent distincts.

L’agent Windows et l’extension de navigateur n’ont pas le même périmètre technique. Chacun reçoit les décisions qu’il peut exécuter et communique l’état qu’il peut observer.

Le panneau n’envoie pas ses écrans à un appareil. Le Core met uniquement à disposition les décisions applicables à ce composant. Les règles, exceptions, horaires et limites restent ainsi interprétés au même endroit, plutôt que résolus séparément par chaque plateforme.

Une configuration enregistrée exprime une intention administrative. Une mesure appliquée confirme son traitement par le composant concerné. L’état opérationnel indique aussi le dernier contact et les informations que l’appareil a pu transmettre.

Après l’enregistrement, le Core évalue la modification pour l’appareil attribué et met la décision résultante à disposition. Le composant se met à jour selon son propre cycle de communication. Un ordinateur peut être éteint, hors ligne ou attendre ce cycle : les appareils ne reflètent donc pas tous un changement au même moment.

L’état transmis indique si le composant a pu communiquer et quelles informations opérationnelles sont disponibles. Il ne remplace pas la configuration enregistrée. L’absence de contact récent ne prouve pas, à elle seule, qu’une politique a été retirée ou a échoué.

Confirmez dans cet ordre la règle enregistrée, son affectation à l’appareil et l’état transmis par le composant avant d’évaluer la mesure elle-même.

N’ajoutez ni ne supprimez de règle avant d’avoir établi cette séquence. Modifier une politique alors qu’un appareil attend une mise à jour ajoute une seconde variable. L’activité et les demandes apportent du contexte, mais ne prouvent pas qu’une configuration a été reçue ou appliquée.

Le parcours ne s’arrête pas à l’enregistrement. Le Core évalue la configuration, rend la décision disponible pour le composant associé et celui-ci transmet les informations opérationnelles qu’il peut fournir. Les appareils ne se mettent pas tous à jour au même moment : un ordinateur peut être hors ligne, éteint ou attendre son prochain cycle de communication.

La configuration enregistrée est la référence des règles, catégories, horaires et limites attendus pour un appareil. C’est le premier point à vérifier pour confirmer qu’une modification concerne le bon appareil.

L’état opérationnel indique le contact et les informations qu’un composant a pu transmettre. Il sert à examiner le résultat, mais ne remplace pas la configuration. L’agent Windows et l’extension peuvent communiquer des informations différentes selon leur plateforme.

Identifiez d’abord l’appareil concerné. Vérifiez ensuite la politique attribuée, le composant responsable et son dernier état transmis. Évaluez seulement après la règle, la limite ou l’horaire concerné. Cette méthode évite de modifier une politique valide avant d’établir si l’appareil attendait simplement une mise à jour.

La centralisation des décisions ne transforme pas LocalGuard en outil d’inspection de contenu privé. Le modèle concerne les politiques, horaires, catégories, appareils et l’état opérationnel nécessaire à leur vérification.