La stratégie de groupe (GPO) en pratique — fonctionnement, vérification de l'application et répartition des rôles avec Intune

« Ce paramètre est distribué par GPO. » « Les PC du client sont verrouillés par la stratégie de groupe. » — Dès qu’on touche à des systèmes métier sous Windows, ce mot de « GPO » circule au quotidien. Mais au moment où l’on doit soi-même reprendre la gestion informatique d’un environnement AD, ou installer une application sur un PC client joint à un domaine, peu de gens sont finalement capables d’expliquer précisément quand, d’où et selon quel ordre de priorité la stratégie de groupe s’applique.

« J’ai changé le paramètre, mais il ne s’applique pas. » « On m’a dit de lancer gpupdate, mais je ne sais pas ce que ça fait réellement. » « L’application fonctionne sur le poste de développement mais pas chez le client, et en creusant, la cause était la GPO. » — Cet article s’adresse aux développeurs d’applications métier confrontés à ce genre de situations, ainsi qu’aux responsables informatiques de PME qui ont hérité d’un environnement AD. Il fait le point, sur la base de sources primaires datées d’août 2026, sur le fonctionnement de la stratégie de groupe (l’ordre d’application LSDOU), le moment où elle s’applique, le diagnostic via gpresult et le journal d’événements, ADMX et le magasin central, et enfin la répartition des rôles avec Intune (MDM).

1. La conclusion, d’abord

• La stratégie de groupe fonctionne au « dernier arrivé, premier servi ». Elle est traitée dans l’ordre local → site → domaine → OU (LSDOU), et c’est la GPO traitée en dernier qui l’emporte en cas de conflit. La GPO locale (gpedit.msc) constitue la couche la plus faible.¹
• L’application se fait en « premier plan + arrière-plan ». La configuration ordinateur s’applique toujours au démarrage, la configuration utilisateur toujours à la connexion, et par défaut une mise à jour en arrière-plan intervient en plus environ toutes les 90 minutes, avec un décalage aléatoire de 0 à 30 minutes (5 minutes pour les contrôleurs de domaine).²
• gpupdate /force réapplique tous les paramètres, mais ce n’est pas une solution universelle. Certains paramètres, comme l’installation de logiciels ou la redirection de dossiers, ne sont traités qu’à la connexion ou au redémarrage (c’est la raison d’être des options /logoff et /boot).³
• Le point de départ du diagnostic est le rapport RSoP de gpresult /h. Il montre les GPO appliquées et les GPO refusées (avec leur motif). Pour aller plus loin, on utilise le journal d’exploitation GroupPolicy (Microsoft-Windows-GroupPolicy/Operational).⁴⁵
• Les stratégies des modèles d’administration s’écrivent en principe dans les clés de registre réservées aux stratégies (Software\Policies, etc.). La valeur de la stratégie prime sur le paramètre propre de l’application, et l’état « non configuré » n’écrit rien. Certaines stratégies écrivent toutefois en dehors de ces clés réservées (chapitre 5).⁶
• Le magasin central des fichiers ADMX est le dossier PolicyDefinitions de SYSVOL. Une fois créé, GPMC référence les définitions de modèles communes au domaine.⁷
• Le choix entre GPO et Intune se fait selon l’infrastructure d’identité des postes. Configurer le même paramètre des deux côtés ne garantit pas le résultat. Pour envisager une migration, Group Policy analytics est disponible.⁸⁹
• Pour un développeur, la GPO est une cause classique de « ça ne marche que chez nous ». Des paramètres qui modifient les prérequis de l’application — stratégie d’exécution, désactivation de la fusion des règles locales du pare-feu, configuration du proxy ou des lecteurs réseau, etc. — sont distribués de manière centralisée.¹⁰¹¹

2. Qu’est-ce que la stratégie de groupe — GPO locale et GPO de domaine

La stratégie de groupe est un mécanisme par lequel un administrateur définit de manière centralisée des paramètres Windows et les impose de force aux ordinateurs et utilisateurs ciblés. Ce bloc de paramètres est appelé GPO (objet de stratégie de groupe). Une GPO peut résider à deux endroits.

Un PC en groupe de travail (non joint à un domaine) ne traite que la GPO locale.¹ Autrement dit, quand on dit « géré par GPO », cela désigne en pratique presque toujours la GPO de domaine.

Le contenu de toute GPO se divise globalement en deux volets.

• Configuration ordinateur : paramètres qui s’appliquent à toute personne se connectant à ce PC. Appliquée au démarrage.
• Configuration utilisateur : paramètres qui s’appliquent quel que soit le PC sur lequel cet utilisateur se connecte. Appliquée à la connexion.

Cet axe — « paramètre lié au PC ou paramètre lié à la personne » — revient constamment, aussi bien dans l’ordre d’application que dans la vérification. Certains paramètres existent dans les deux configurations à la fois, alors prenez l’habitude de toujours regarder les deux volets lorsque vous cherchez un réglage.

3. Le mécanisme d’application — le « dernier arrivé, premier servi » du LSDOU et le contrôle de l’héritage

3.1. LSDOU : local → site → domaine → OU

Sur un PC joint à un domaine, les GPO sont traitées dans l’ordre suivant.¹

1. GPO locale
2. GPO liées au site
3. GPO liées au domaine
4. GPO liées à l’OU (unité d’organisation) — traitées à partir de l’OU la plus haute, la GPO de l’OU à laquelle appartient directement l’ordinateur/utilisateur cible étant traitée en dernier

C’est l’ordre appelé LSDOU, d’après les initiales. Ce qui importe, c’est que cet ordre n’est pas un « ordre de priorité décroissante » mais un ordre de traitement. Lorsque plusieurs GPO configurent le même paramètre, c’est la GPO traitée en dernier qui l’emporte (les paramètres non conflictuels s’additionnent simplement).¹ Autrement dit, la GPO de l’OU la plus proche de la cible est la plus forte, et la GPO locale la plus faible. Si « la correction faite dans gpedit.msc revient toujours en arrière », ce n’est pas un dysfonctionnement mais exactement le comportement prévu par cette spécification.

Lorsque plusieurs GPO sont liées au même site, domaine ou OU, c’est l’ordre des liens de l’onglet « Objets de stratégie de groupe liés » de GPMC qui décide. La GPO dont le numéro d’ordre de lien est le plus petit est traitée en dernier et bénéficie donc de la priorité la plus élevée.¹

3.2. Blocage de l’héritage et application forcée (Enforced)

Il est possible de créer des exceptions à cet ordre par défaut.¹

• Blocage de l’héritage : configuré sur un domaine ou une OU, il arrête l’héritage des GPO en provenance des niveaux supérieurs. C’est l’outil à utiliser quand « seule cette OU ne doit pas recevoir le standard de toute l’entreprise ».
• Application forcée (Enforced, anciennement « Interdiction de la substitution ») : configurée sur le lien d’une GPO, elle garantit que cette GPO s’applique toujours, même si l’héritage est bloqué à un niveau inférieur, et qu’elle ne peut plus être écrasée par une GPO de niveau inférieur. En cas de conflit entre blocage d’héritage et application forcée, c’est l’application forcée qui l’emporte.¹

L’application forcée casse le principe du « dernier arrivé l’emporte » ; l’utiliser à outrance multiplie les résultats contre-intuitifs même en lisant le RSoP. La bonne pratique est de la réserver aux paramètres de sécurité que toute l’entreprise doit absolument respecter.

3.3. Le filtrage de sécurité

Au-delà de l’emplacement du lien, on peut aussi restreindre à qui une GPO s’applique, GPO par GPO. Pour qu’une GPO s’applique, l’utilisateur ou l’ordinateur cible doit disposer, sur cette GPO, des deux autorisations « Lecture » et « Appliquer la stratégie de groupe ». Par défaut, les deux sont accordées à Authenticated Users (qui inclut à la fois les utilisateurs et les ordinateurs), si bien que la GPO s’applique à tout le monde sous l’emplacement lié. Restreindre cela à des groupes de sécurité spécifiques, c’est le filtrage de sécurité. Le filtre agit sur la GPO entière ; il ne peut pas être différencié paramètre par paramètre à l’intérieur d’une même GPO.¹³

Il y a une précaution importante à noter. Lorsque vous restreignez la cible, ne retirez pas jusqu’à l’autorisation « Lecture » d’Authenticated Users. Depuis la mise à jour de sécurité MS16-072 (2016), les stratégies côté utilisateur sont récupérées dans le contexte de sécurité de l’ordinateur : si le compte ordinateur ne peut pas lire la GPO, celle-ci ne s’appliquera plus côté utilisateur, même si vous avez accordé les deux autorisations à l’utilisateur cible.¹⁴ La bonne pratique, lors d’une restriction, est d’accorder « Lecture + Appliquer la stratégie de groupe » au groupe cible tout en laissant uniquement « Lecture » à Authenticated Users (ou à Domain Computers).¹⁴

En pratique, les pièges classiques sont : « ajouté au groupe mais toujours pas appliqué (le paramètre est côté ordinateur alors que seul l’utilisateur a été ajouté au groupe) », ou « retiré du groupe mais toujours appliqué ». Ce dernier cas ne se résout pas en attendant la mise à jour en arrière-plan. L’appartenance à un groupe est évaluée à partir du jeton de sécurité créé à la connexion : un changement de groupe côté utilisateur ne se reflète dans le filtre qu’après une déconnexion puis reconnexion, et un changement de groupe côté ordinateur qu’après un redémarrage — le temps qu’un nouveau jeton soit créé.

Il existe par ailleurs un mode spécial, le traitement en boucle de rappel (loopback), destiné aux cas comme les PC partagés ou les serveurs Bureau à distance où l’on souhaite « remplacer la configuration utilisateur pour toute personne se connectant à ce PC » (un mécanisme qui applique les paramètres utilisateur en fonction de l’emplacement de l’ordinateur, avec deux modes : remplacement et fusion).¹⁵ C’est une fonctionnalité avancée utilisée sur les bornes kiosque ou les PC de salle de classe ; cet article se contente ici de signaler son existence.

4. Quand l’application a-t-elle lieu — traitement au premier plan et mise à jour en arrière-plan

La moitié des cas de « paramétré mais pas appliqué » tiennent simplement au fait que le moment de l’application n’est pas encore arrivé. Il existe deux types d’application.²

Autrement dit, pour un poste allumé capable d’atteindre le contrôleur de domaine, un paramètre compatible avec la mise à jour en arrière-plan se propage en environ deux heures, sans rien faire de plus après la modification de la GPO. Un poste hors ligne, ou un portable emporté qui n’est pas connecté au VPN, ne le reçoit qu’à la prochaine connexion au contrôleur de domaine. Un paramètre qui ne s’applique qu’en traitement de premier plan attend en plus un démarrage ou une connexion. Pour aller plus vite, exécutez gpupdate sur le PC concerné. Par défaut, seuls les paramètres modifiés sont appliqués ; avec /force, tous les paramètres sont réappliqués, qu’ils aient changé ou non.³

rem Mise à jour des seuls paramètres modifiés (suffisant dans la plupart des cas)
gpupdate

rem Réapplique tous les paramètres (en cas de doute sur un état mis en cache)
gpupdate /force

Il faut noter qu’il existe des paramètres que gpupdate ne fait pas apparaître. L’installation de logiciels côté utilisateur et la redirection de dossiers ne sont traitées qu’à la connexion, et l’installation de logiciels côté ordinateur qu’au démarrage. gpupdate propose pour cela les options /logoff (déconnexion après la mise à jour) et /boot (redémarrage après la mise à jour).³ Avant de vous inquiéter que « gpupdate /force a été exécuté mais rien ne change », vérifiez si ce paramètre ne fait pas partie de ceux qui nécessitent un redémarrage ou une connexion.

5. Diagnostiquer quand ça ne s’applique pas — gpresult, journal d’événements, registre

5.1. Vérifier le RSoP avec gpresult /h

L’outil standard pour consulter le résultat final (RSoP : Resultant Set of Policy) de la superposition de plusieurs GPO est gpresult. Générer un rapport HTML depuis une invite de commandes avec droits administrateur est la méthode la plus lisible.⁴⁵

rem Génère un rapport HTML avec le RSoP à la fois utilisateur et ordinateur
gpresult /h C:\temp\gp-report.html /f

rem Pour un simple résumé dans la console
gpresult /r
gpresult /scope computer /r

Les trois points à examiner en premier dans le rapport sont les suivants.

1. La liste des GPO appliquées — la GPO recherchée y figure-t-elle ?
2. La liste des GPO refusées et leur motif — le rapport affiche le motif de non-application : filtre de sécurité, filtre WMI, GPO vide, etc.⁵
3. La « GPO gagnante » pour chaque paramètre — quelle GPO détermine la valeur du paramètre recherché. Si une autre GPO l’emporte, revoyez l’ordre de priorité du chapitre 3.

5.2. Le journal d’exploitation GroupPolicy

Quand gpresult ne suffit pas (le traitement échoue carrément, prend trop de temps, etc.), consultez le journal d’exploitation GroupPolicy dans l’Observateur d’événements. Il se trouve sous « Journaux des applications et des services > Microsoft > Windows > GroupPolicy > Operational » (nom du journal : Microsoft-Windows-GroupPolicy/Operational). Il y enregistre le déroulement complet du traitement des stratégies, du début à la fin, avec la liste des GPO appliquées et celle des GPO refusées (avec motif). Chaque exécution du traitement des stratégies se voit attribuer un ActivityID unique ; la procédure recommandée par Microsoft consiste à récupérer cet ActivityID depuis les événements d’avertissement ou d’erreur du journal Système, puis à filtrer une seule instance avec une vue personnalisée.⁵

5.3. La relation avec la clé Policies du registre

Les stratégies des modèles d’administration (chapitre suivant) finissent par être écrites sous forme de valeurs de registre. En principe, elles sont écrites dans les clés réservées aux stratégies suivantes.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (configuration ordinateur ; emplacement recommandé)
• HKEY_CURRENT_USER\Software\Policies (configuration utilisateur ; emplacement recommandé)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Il y a ici une philosophie de conception importante. Une application compatible avec les stratégies fonctionne ainsi : elle lit d’abord la clé Policies, privilégie sa valeur si elle existe, et sinon utilise son propre paramètre (préférence) ou sa valeur par défaut. Une stratégie « non configurée » n’écrit rien dans le registre.⁶ Autrement dit, une stratégie de modèle d’administration ne réécrit pas le paramètre propre de l’application en y laissant une « marque indélébile » (tattooing) : c’est un mécanisme où une valeur impérative placée ailleurs est consultée en priorité. Dès que l’on cesse de configurer la stratégie, l’application peut revenir à suivre sa propre valeur.

Cependant, toutes les stratégies n’écrivent pas dans la clé réservée. Certains paramètres intégrés au système d’exploitation (par exemple, « Activer les chemins longs Win32 » écrit dans LongPathsEnabled sous HKLM\SYSTEM\CurrentControlSet\Control\FileSystem), ainsi que certains modèles anciens ou tiers, écrivent vers un chemin quelconque en dehors de la clé réservée. Pour ce type de paramètre, la valeur reste en place même après avoir cessé de configurer la stratégie. Pour savoir dans quelle clé un paramètre donné écrit réellement, consultez la définition ADMX, le texte explicatif du paramètre, ou le rapport gpresult.

Autrement dit, la bonne conduite décrite plus haut ne vaut que dans le cadre des modèles d’administration (clé réservée aux stratégies). Une valeur écrite par un script ou par les paramètres de base de la stratégie de groupe (Preferences) en dehors de la clé Policies est une valeur de registre ordinaire, sans mécanisme de retour automatique une fois la distribution arrêtée. En pratique, pour diagnostiquer, le plus rapide et le plus sûr est de vérifier directement si le paramètre recherché est écrit dans la clé Policies.

# Exemple de vérification directe d'une valeur distribuée par une stratégie (la plupart des stratégies s'écrivent sous Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

6. Modèles d’administration (ADMX) et magasin central

Les définitions des paramètres qui apparaissent sous « Modèles d’administration » dans GPMC sont décrites par des fichiers ADMX (le corps de la définition du paramètre) et des fichiers ADML (les chaînes d’affichage par langue). Chaque PC possède, dans C:\Windows\PolicyDefinitions, les définitions fournies avec le système d’exploitation, et l’outil d’administration les charge pour construire l’écran de configuration.⁷

Pour une exploitation en domaine, la base est de créer un magasin central. En créant un dossier PolicyDefinitions sous le SYSVOL d’un contrôleur de domaine (par exemple \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), son contenu se réplique sur tous les contrôleurs de domaine du domaine, et les outils de stratégie de groupe se mettent à référencer par défaut le magasin central.⁷ Cela élimine le problème où « la version du modèle diffère selon le poste d’administration utilisé pour l’édition, et les paramètres visibles ne concordent pas ». Les fichiers ADML se placent dans des sous-dossiers par langue (ja-JP pour le japonais, par exemple).⁷

Il y a deux précautions d’exploitation. Premièrement, Microsoft distribue les fichiers ADMX pour les nouvelles versions de Windows version par version, et pour les mettre à jour, il faut remplacer ceux du magasin central. Remplacer le C:\Windows\PolicyDefinitions de chaque PC par la version téléchargée n’est pas pris en charge.⁷ Deuxièmement, pour mettre à jour un magasin central existant, la procédure recommandée n’écrase pas directement le dossier PolicyDefinitions de production : elle consiste à rassembler l’ensemble des ADMX de l’OS et des applications (Office, Edge, etc.) dans un dossier de travail nommé selon la version, du type PolicyDefinitions-24H2, à renommer le dossier actuel pour le mettre de côté (par exemple en PolicyDefinitions-23H2), puis à renommer le dossier de travail en PolicyDefinitions pour le mettre en production.⁷ Comme les outils de stratégie de groupe ne référencent que le dossier nommé exactement PolicyDefinitions, le placer dans un dossier nommé par version ne suffit pas à le faire prendre effet. L’avantage de cette méthode est de pouvoir revenir à l’ancien dossier mis de côté en cas de problème.⁷

7. GPO vs Intune (MDM/CSP) vs déploiement manuel/scripté — tableau de décision

La GPO n’est plus la seule option pour la gestion de la configuration des postes Windows. Le MDM, dont Intune est le représentant, configure les paramètres du système d’exploitation via un mécanisme appelé CSP (fournisseur de services de configuration). Voici un tableau pour décider lequel privilégier.

L’axe de décision est simple : l’infrastructure d’identité du poste (AD ou Microsoft Entra) et l’endroit où se trouve le poste. Pour un parc de PC fixes en entreprise pleinement joints à l’AD sur site, la GPO reste la plus fiable ; pour des PC mobiles joints à Entra, la GPO ne les atteint tout simplement pas.

En réalité, les PME se trouvent souvent dans une situation intermédiaire, c’est-à-dire hybride (jointe au domaine + inscrite dans Intune), et le pire scénario ici est de « configurer le même paramètre à la fois par GPO et par MDM ». Policy CSP dispose d’une stratégie appelée MDMWinsOverGP qui fait gagner le MDM en cas de conflit avec la GPO, mais sa portée se limite aux stratégies prises en charge à l’intérieur de Policy CSP. Microsoft affirme lui-même que configurer par GPO et par MDM un paramètre non couvert par ce contrôle crée un état de conflit dont l’issue n’est pas garantie, et recommande explicitement d’éviter la double configuration.⁸ Le premier principe d’une exploitation hybride est de décider, domaine de configuration par domaine de configuration, « ceci relève de la GPO, cela relève d’Intune », et de s’y tenir d’un seul côté.

Au stade où l’on envisage une migration de GPO vers Intune, Group Policy analytics d’Intune constitue le point d’entrée. En important les GPO exportées depuis GPMC (au format XML), on peut analyser si chaque paramètre est pris en charge par le MDM, déconseillé ou non pris en charge, et migrer les paramètres pris en charge vers une stratégie de catalogue de paramètres d’Intune.⁹ Il est plus juste de considérer cet outil non pas comme un moyen de « tout migrer », mais comme un outil pour « trier ce qui peut être migré, ce qui ne peut pas l’être, et ce qu’il faut abandonner ». Notez que la répartition de la gestion des mises à jour Windows connaît elle aussi une réorganisation dans le même contexte. Voir aussi « La gestion des mises à jour Windows après l’abandon de WSUS ».

8. Le piège vu du développeur — quand la GPO du client modifie le comportement de l’application

Pour finir, un point à retenir du point de vue du développement sous contrat. La GPO du client réécrit silencieusement les prérequis de votre application. Parmi les causes classiques de « ça marche sur le poste de développement mais pas chez le client », la GPO figure en bonne place, aux côtés du pare-feu et de l’antivirus. Voici quelques exemples concrets.

• La stratégie d’exécution PowerShell : la stratégie d’exécution peut être configurée de manière centralisée par GPO, et les portées MachinePolicy/UserPolicy issues de la GPO sont toujours prioritaires sur les valeurs configurées localement ou au niveau du processus.¹⁰ Si un installeur ou un script d’exploitation part du principe que « ajouter -ExecutionPolicy Bypass devrait suffire à le faire fonctionner », il ne démarrera même pas sous le contrôle d’une GPO. Voir « La stratégie d’exécution PowerShell et la signature de script » pour plus de détails.
• La désactivation de la fusion des règles locales du pare-feu : dans un environnement où le pare-feu est géré de manière centralisée par GPO ou Intune, on peut désactiver, par profil, la « fusion des règles locales » (AllowLocalPolicyMerge). Dans un environnement où elle est désactivée, une règle entrante enregistrée localement par un installeur existe mais ne s’applique pas.¹¹ C’est un point à vérifier impérativement avant le déploiement d’une application de type serveur ; nous le détaillons dans « Le pare-feu Windows et les applications métier ».
• La configuration de l’environnement, comme l’affectation des lecteurs réseau ou le proxy : l’affectation des lecteurs réseau, des imprimantes, etc., est classiquement distribuée via les paramètres de base de la stratégie de groupe (Preferences).¹⁶ Des hypothèses d’environnement comme « le lecteur Z doit exister » ou « le proxy doit être en connexion directe » peuvent s’effondrer selon l’utilisateur connecté ou l’OU d’appartenance du PC. Le fait qu’un paramètre distribué via la configuration utilisateur ne s’applique évidemment pas au compte d’exécution d’un service ou d’une tâche planifiée est aussi un point souvent négligé pour les applications résidentes.
• Le paramètre ne peut tout simplement pas être « remis à l’état d’origine » : un paramètre issu d’un modèle d’administration n’est normalement plus modifiable par l’utilisateur depuis l’écran (l’option apparaît grisée). Le fait que « il suffit de demander au client de changer le paramètre » ne fonctionne pas a un impact direct sur la conception de votre stratégie d’assistance.

Il y a trois précautions réalistes à prendre côté développement. Premièrement, documenter comme prérequis d’installation les hypothèses d’environnement dont dépend l’application (stratégie d’exécution, ports d’écoute, dossier d’écriture, chemin du proxy, etc.) et demander au service informatique du client de les vérifier avant l’installation. Deuxièmement, en cas de problème, vérifier non pas par supposition mais avec le rapport gpresult /h et les valeurs réelles sous HKLM\Software\Policies (chapitre 5). Troisièmement, séparer dès la conception les traitements qui nécessitent des droits administrateur de ceux qui n’en ont pas besoin (cette distinction est traitée dans « Quand les privilèges administrateur sont-ils nécessaires »). La GPO n’est pas un ennemi, c’est une caractéristique de l’environnement. Traitée comme telle, le diagnostic devient mécanique.

9. Conclusion

• La stratégie de groupe est un mécanisme qui traite les paramètres GPO par GPO dans l’ordre local → site → domaine → OU (LSDOU), le conflit se résolvant en faveur du dernier traité. La GPO de l’OU la plus proche de la cible est la plus forte, la GPO locale la couche la plus faible.
• Le blocage de l’héritage, l’application forcée (Enforced) et le filtrage de sécurité permettent de contrôler ce flux par défaut. L’application forcée l’emporte même sur le blocage de l’héritage, il ne faut donc pas en abuser.
• L’application se compose de deux volets : le traitement de premier plan au démarrage/à la connexion, et la mise à jour en arrière-plan, par défaut environ toutes les 90 minutes plus un décalage aléatoire. gpupdate /force réapplique tous les paramètres, mais reste sans effet sur les paramètres qui ne se traitent qu’à la connexion ou au redémarrage.
• Quand rien ne s’applique, diagnostiquez mécaniquement dans l’ordre gpresult /h → journal d’exploitation GroupPolicy → clé Policies du registre. Les GPO refusées affichent leur motif.
• Les définitions des modèles d’administration sont au format ADMX/ADML, et une exploitation en domaine les centralise dans le magasin central de SYSVOL. Pour une mise à jour, on remplace le contenu du magasin central, pas le PolicyDefinitions local.
• Le choix entre GPO et Intune se décide selon l’infrastructure d’identité et l’emplacement du poste ; en hybride, évitez la double configuration du même paramètre et confiez-en la gestion à un seul des deux. Group Policy analytics est disponible pour trier une migration.
• Pour un développeur, la GPO du client fait partie des caractéristiques de l’environnement. En documentant les prérequis — stratégie d’exécution, pare-feu, configuration des lecteurs et du proxy — et en mettant en place les moyens de les vérifier avec gpresult, la plupart des cas de « ça ne marche que chez le client » perdent de leur inquiétude.

Articles connexes

• Le pare-feu Windows et les applications métier — enregistrer les règles entrantes depuis l’installeur
• La gestion des mises à jour Windows après l’abandon de WSUS — comment choisir entre WUfB, Autopatch et Intune
• La stratégie d’exécution PowerShell et la signature de script — guide pratique pour sortir de l’habitude « Bypass en guise de solution »
• Automatiser le kitting de PC avec winget + PowerShell — rendre exécutable le manuel de procédure
• Guide pour sortir de la dépendance au mode IE
• Quand les privilèges administrateur sont-ils nécessaires sous Windows - UAC, zones protégées et comment les distinguer dès la conception

Domaines de conseil associés

KomuraSoft LLC (合同会社小村ソフト) prend en charge l’investigation des causes lorsqu’une application métier ne fonctionne pas dans un environnement client géré par GPO, la clarification des prérequis d’installation (stratégie d’exécution, pare-feu, hypothèses réseau), ainsi que le conseil technique sur l’inventaire des stratégies et la politique de combinaison avec Intune pour les responsables informatiques ayant hérité d’un environnement AD. N’hésitez pas à nous solliciter dès le stade « j’aimerais qu’on relise ensemble un rapport gpresult ».

• Conseil technique et revue de conception
• Investigation de bugs et analyse des causes
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

J'ai exécuté gpupdate /force, mais le paramètre ne s'applique pas. Pourquoi ?

Vérifiez d'abord si ce paramètre fait partie des « types qui ne s'appliquent pas lors d'une mise à jour en arrière-plan ». L'installation de logiciel côté utilisateur et la redirection de dossiers ne sont traitées qu'à la connexion, et l'installation de logiciel côté ordinateur ne l'est qu'au démarrage : une fois gpupdate terminé, une déconnexion (/logoff) ou un redémarrage (/boot) est donc nécessaire. Ensuite, générez un rapport RSoP avec gpresult /h et vérifiez si cette GPO figure bien dans les « GPO appliquées », ou si elle figure dans les « GPO refusées » avec un motif. Si elle est bien appliquée mais que le comportement ne change pas, soupçonnez qu'une autre GPO de priorité plus élevée écrase le même paramètre (c'est la dernière traitée qui l'emporte). Le rapport affiche la « GPO gagnante » pour chaque paramètre, ce qui permet d'identifier précisément quelle GPO l'emporte.

Que signifie l'indication « Refusé (filtre) » dans gpresult ?

Cela signifie que la GPO figure bien parmi les cibles au niveau de l'emplacement du lien, mais qu'elle a été exclue de l'application par un traitement de filtrage. La cause la plus courante est le filtrage de sécurité : pour qu'une GPO s'applique, l'utilisateur ou l'ordinateur doit disposer à la fois de l'autorisation « Lecture » et de l'autorisation « Appliquer la stratégie de groupe » sur cette GPO. Par défaut, les deux sont accordées à Authenticated Users, mais si l'exploitation restreint l'application à des groupes spécifiques, un oubli d'ajout au groupe ou l'omission du compte ordinateur entraîne un refus. De plus, pour les GPO côté utilisateur, il ne suffit pas d'accorder les deux autorisations à l'utilisateur cible : depuis MS16-072, les stratégies utilisateur sont récupérées dans le contexte de sécurité de l'ordinateur, il faut donc laisser l'autorisation « Lecture » (l'« Appliquer » n'est pas nécessaire) à Authenticated Users ou à Domain Computers. On rencontre aussi des cas de non-correspondance de filtre WMI, ou de désactivation côté GPO du volet utilisateur ou ordinateur. Le motif du refus est consigné à la fois dans le rapport gpresult et dans le journal d'exploitation GroupPolicy.

Faut-il gérer avec la GPO ou avec Intune ?

La règle de base est de s'aligner sur l'infrastructure d'identité des postes. Si la majorité des postes sont joints à un domaine AD sur site et connectés en permanence au réseau interne, la GPO reste l'option la plus fiable et la plus fine. Si les postes joints à Microsoft Entra ou les postes en télétravail qui ne se connectent jamais à un contrôleur de domaine se multiplient, Intune (MDM/CSP), dont la configuration peut atteindre l'appareil même hors de l'entreprise, est plus adapté. Dans un environnement hybride où les deux coexistent, configurer le même paramètre à la fois par GPO et par MDM crée un conflit dont le résultat n'est pas garanti : le principe est de décider, domaine de configuration par domaine de configuration, lequel des deux gère, et de s'y tenir. Au stade où l'on envisage une migration, importer les GPO existantes dans Group Policy analytics d'Intune permet de trier les paramètres déjà pris en charge par le MDM de ceux qui ne le sont pas ou qui sont déconseillés.

Le contenu que j'ai configuré dans la stratégie de groupe locale (gpedit.msc) est écrasé par le paramètre du domaine. Est-ce normal ?

C'est normal. La stratégie de groupe est traitée dans l'ordre local → site → domaine → OU (LSDOU), et c'est le dernier élément traité qui l'emporte en cas de conflit ; la GPO locale constitue donc la couche la plus faible. Si la GPO de domaine configure le même paramètre, la modification locale sera toujours écrasée. À l'inverse, si le domaine a laissé ce paramètre « non configuré », la valeur de la GPO locale reste effective telle quelle. Même si, pour des besoins de test, vous voulez absolument faire primer le paramètre local, il n'existe aucun moyen d'inverser cet ordre de priorité sur un PC joint à un domaine : le plus réaliste est de créer une OU de test et d'y ajuster la GPO côté domaine, ou d'utiliser une machine de test non jointe au domaine.

L'application métier que nous avons développée ne fonctionne que chez le client. Existe-t-il un moyen de vérifier si la GPO en est la cause ?

La première étape consiste à demander à l'administrateur du client d'exécuter gpresult /h report.html depuis une invite de commandes avec droits administrateur sur le PC concerné, puis de consulter le rapport RSoP. Vérifiez si des paramètres susceptibles de modifier le comportement de l'application sont appliqués : blocage de script par la stratégie d'exécution, désactivation de la fusion des règles locales du pare-feu, configuration du proxy ou des lecteurs réseau, etc. Vérifiez également, sous les clés de registre HKLM\Software\Policies et HKCU\Software\Policies, si des valeurs de stratégie liées au produit concerné y sont écrites, ce qui permet d'identifier mécaniquement les paramètres imposés issus des modèles d'administration. Côté développement, la précaution possible consiste à documenter dans le guide d'installation les prérequis dont dépend l'application (stratégie d'exécution, ports d'écoute, dossier d'écriture, etc.) et à demander au service informatique du client de les vérifier avant l'installation.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.