# Stratégie de contrôle d’exécution des logiciels

Canonical: https://www.nsecsoft.com/fr/docs/ping64-endpoint-management/software/execution-control/policy/

Language: fr-FR

Updated: 2026-11-15T03:27:13.772862Z

Dans Ping64, le contrôle logiciel utilise des règles pour identifier l’exécution des logiciels et applique à une correspondance l’action « aucune action » ou « blocage ». L’audit peut être activé séparément pour chaque règle. Le contrôle des installations, la boutique logicielle et la gestion des licences sont configurés séparément : l’activation de l’un n’active pas automatiquement les autres.

L’enregistrement d’une stratégie, sa réception par un terminal, la correspondance d’un logiciel, son blocage effectif et la transmission d’un enregistrement sont des étapes distinctes. Un blocage ne produit pas nécessairement un audit, et un enregistrement ne prouve pas à lui seul que le logiciel a bien été arrêté.

## Préparation

-   Modifier les stratégies de conformité logicielle et consulter les enregistrements d’audit exigent les droits correspondants. Définissez les terminaux pilotes, la période d’application et les exigences de contrôle.
-   Identifiez le logiciel et ses conditions réelles d’exécution. Pour une correspondance par liste ou catégorie, vérifiez les objets logiciels existants dans Objects & Templates : nom, catégorie et applications associées. Réutilisez les objets adaptés ; créez-les ou modifiez-les uniquement si nécessaire et enregistrez ces changements avant de les sélectionner dans une règle.
-   Choisissez quelques terminaux pilotes dont le fonctionnement peut être rétabli. Préparez le logiciel à contrôler et un logiciel témoin qui ne doit pas être affecté. Une règle de blocage trop large peut perturber l’activité ; convenez au préalable d’une procédure de rétablissement avec les responsables concernés.
-   La prise en charge des logiciels, catégories, chemins de processus, noms de fenêtres et conditions SHA256 peut varier selon la plateforme. La présence d’une condition dans la page ne signifie pas que tous les terminaux l’exécutent de manière identique ; testez le système et la version réellement utilisés.

## Configurer les règles de contrôle

1.  Dans Software, ouvrez Policy et créez ou modifiez la stratégie cible. Vérifiez son nom, le périmètre des terminaux et sa période d’application.
2.  Activez **Software Control** dans les paramètres de la stratégie et ouvrez ses paramètres.
3.  Ajoutez une règle et indiquez son nom. Dans les conditions de correspondance, choisissez une liste ou une catégorie de logiciels, ou configurez selon le besoin des chemins de processus, noms de fenêtres, valeurs SHA256 et autres conditions proposées. Chaque règle doit comporter au moins une condition valide.
4.  Pour une condition de processus, vérifiez le chemin réel et les autres champs. Une condition structurée de processus exige au moins un champ sans valeur générique : ne remplacez pas une cible précise par des valeurs génériques dans tous les champs.
5.  Dans les paramètres d’action, choisissez aucune action ou blocage. Pour enregistrer les correspondances, activez séparément l’audit ; choisir le blocage n’active pas l’audit automatiquement.
6.  Vérifiez le nom, les conditions et l’action de chaque règle. L’ordre des règles peut être modifié. Si des conditions se recoupent, vérifiez d’abord les correspondances et l’exécution réelles sur les terminaux pilotes ; ne supposez pas que toutes les règles correspondantes s’exécutent successivement.
7.  Confirmez les fenêtres de conditions et de paramètres de contrôle, puis enregistrez la stratégie entière. Attendez sa réception par les terminaux cibles avant de tester. Un enregistrement réussi dans la console ne prouve pas que le terminal a exécuté la stratégie.

**Périmètre de correspondance sous Windows :** les différents éléments d’une règle ordinaire n’ont pas tous à correspondre simultanément. Par exemple, si une condition de processus et une valeur SHA256 sont ajoutées, l’une ou l’autre peut déclencher la règle : elles ne constituent pas une double restriction. En revanche, les champs renseignés dans une même condition structurée de processus doivent tous correspondre ; vérifiez le chemin complet réel du programme. Ajouter des éléments peut élargir le périmètre de la règle. Avant d’activer le blocage, testez séparément des exemples correspondant à un seul élément et des exemples ne correspondant à aucun des deux.

Par exemple, commencez par le chemin exact du processus d’un logiciel de test, choisissez aucune action et activez l’audit pour vérifier le périmètre de correspondance. Après validation, évaluez le passage au blocage selon la procédure de changement de l’organisation. Cet exemple n’est pas une règle par défaut et ne garantit pas un comportement identique sur toutes les plateformes.

Sous Linux, les chemins d’exécution des conditions de processus et SHA256 diffèrent de ceux des autres conditions. Pour une règle ne contenant qu’une liste de logiciels, une catégorie ou un nom de fenêtre, ne supposez pas un comportement identique à celui des autres plateformes. Effectuez un essai dans l’environnement réel.

Dans certains cas de règles ordinaires sous Windows, le terminal vérifie les règles dans l’ordre reçu et s’arrête à la première correspondance ordinaire. Par exemple, si une règle **No action** placée avant correspond, une règle de blocage ou d’audit ultérieure ne s’applique pas à cette correspondance. Le traitement lié aux approbations suit une évaluation distincte ; ne généralisez pas cet ordre à toutes les plateformes et situations. Après réorganisation, vérifiez séparément l’autorisation, le blocage et les enregistrements sur un terminal pilote.

## Résolution des problèmes

1.  **Une règle ne peut pas être enregistrée :** vérifiez son nom, la présence d’au moins une condition de correspondance et d’au moins un champ sans valeur générique dans chaque condition structurée de processus. Vérifiez que les fenêtres de paramètres et la stratégie entière ont été enregistrées.
2.  **Le logiciel n’est pas bloqué comme prévu :** vérifiez les terminaux et la période concernés, la réception de la stratégie, l’action, les conditions, l’ordre des règles et la prise en charge par la plateforme. Si nécessaire, effectuez un nouveau test avec une condition de processus précise sur un terminal pilote.
3.  **Un blocage se produit sans enregistrement :** vérifiez l’activation de l’audit pour la règle, puis la transmission par le terminal, la date, le mot-clé, les filtres de la page courante et le périmètre visible par l’administrateur.
4.  **Les enregistrements ou leurs détails ne sont pas accessibles :** vérifiez les droits du compte, le périmètre de visibilité des terminaux et les messages de la page. Si le problème persiste, contactez un administrateur ou le support technique ; ne contournez pas les contrôles en transmettant des chemins sensibles.
5.  **Un logiciel métier est bloqué par erreur :** rétablissez d’abord les opérations essentielles selon la procédure d’incident de l’organisation. Vérifiez la règle correspondante, son périmètre et son ordre ; corrigez et validez sur des terminaux contrôlés avant d’étendre le déploiement.

-   [Audit du contrôle d’exécution des logiciels](https://www.nsecsoft.com/fr/docs/ping64-endpoint-management/software/execution-control/audit/)