Group Policy qui ne s'applique pas sous Windows 11 : le guide de dépannage helpdesk 2026

Mis à jour : 21 juillet 2026

Une Group Policy qui ne s'applique pas sous Windows 11, c'est presque toujours l'un de sept problèmes : filtrage de sécurité mal configuré, filtre WMI qui échoue, résolution DNS vers un mauvais contrôleur de domaine, réplication SYSVOL cassée, héritage bloqué au niveau de l'OU, cache client hors service, ou tout bêtement une GPO ciblant l'utilisateur alors que vous attendez une politique ordinateur. La procédure de diagnostic standard, pour un technicien helpdesk, tient en trois commandes : gpresult /r, un rapport HTML gpresult /h C:\rapport.html, et une inspection ciblée du journal GroupPolicy dans l'Observateur d'événements. Cet article vous donne la démarche complète, avec les scripts PowerShell que j'utilise au quotidien sur mes postes clients (et que j'ai raffinés à force de tickets un peu trop similaires le lundi matin).

• La commande gpresult /h est le point de départ obligatoire : elle liste les GPO appliquées, refusées, et la raison exacte du refus (filtre WMI, filtrage de sécurité, désactivation d'un côté).
• Les identifiants d'événement 4016, 5312, 5326 et 7016 dans le journal Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational pointent la phase du traitement qui échoue.
• Sous Windows 11, l'actualisation en arrière-plan tourne toutes les 90 minutes ± 30 minutes d'offset aléatoire ; gpupdate /force réapplique toutes les GPO, pas seulement les modifications.
• Un filtrage de sécurité correct exige à la fois « Read » et « Apply group policy » sur l'objet cible ; oublier « Read » casse silencieusement la GPO.
• La réplication SYSVOL doit être fonctionnelle sur tous les DC ; utilisez dfsrdiag ReplicationState avant de blâmer le client.
• Sur Windows 11 24H2, le cache de stratégies est stocké dans %windir%\System32\GroupPolicy et ...\GroupPolicyUsers ; le vider force un traitement synchrone au prochain logon.

Comment vérifier qu'une GPO est réellement appliquée

Avant d'ouvrir un ticket ou de blâmer le contrôleur de domaine, exécutez gpresult. Franchement, c'est l'outil qui a plus de vingt ans de bons et loyaux services, et il reste plus fiable que la console Group Policy Modeling quand vous êtes assis devant le poste client. Deux formes vous intéressent : le résumé texte et le rapport HTML complet.

# Résumé texte : quelles GPO sont appliquées à l'utilisateur et à l'ordinateur ?
# À exécuter dans une console cmd/PowerShell ÉLEVÉE (Run as administrator).
gpresult /r /scope:computer
gpresult /r /scope:user

# Rapport HTML complet : liste GPO appliquées, refusées, ET la raison du refus.
# C'est le rapport le plus utile ; envoyez-le en pièce jointe au ticket.
gpresult /h C:\temp\rsop.html /f
Start-Process C:\temp\rsop.html

Dans le rapport HTML, allez directement à la section « Denied GPOs ». Chaque GPO refusée est accompagnée d'un motif : Empty (aucun paramètre configuré côté utilisateur ou ordinateur, selon le scope), Access Denied (Security Filtering) (le principal n'a pas les droits requis), ou WMI Filter Failed. Ces trois motifs couvrent à eux seuls 80 % des tickets « ma GPO ne s'applique pas » que j'ai vus passer.

Attention à un piège récurrent sous Windows 11 24H2. Si vous exécutez gpresult sans élévation, la section ordinateur est vide, et les techniciens tier-1 concluent à tort que « aucune GPO n'est appliquée à l'ordinateur ». Toujours ouvrir un terminal Administrator. Pour éviter l'erreur, câblez ce raccourci PowerShell dans le profil de vos techniciens :

# À placer dans $PROFILE des techniciens helpdesk
# Ouvre gpresult HTML en un mot-clé, et lance le rapport automatiquement
function Show-GPResult {
    $path = "$env:TEMP\rsop-$(Get-Date -Format 'yyyyMMdd-HHmm').html"
    # /f = overwrite silencieux, /h = format HTML
    gpresult /h $path /f
    Start-Process $path
}
Set-Alias grh Show-GPResult

Les 7 causes les plus fréquentes d'une GPO qui ne s'applique pas

Depuis Windows 10 1607, la logique de traitement des Group Policy n'a pas fondamentalement changé, mais Windows 11 24H2 a durci deux comportements silencieux : le cache local est purgé plus agressivement lors des mises à jour cumulatives, et le client Group Policy exige désormais un canal LDAP signé pour interroger le DC. Voici les sept causes que je vois chaque semaine sur mon service desk :

1. Filtrage de sécurité incomplet. Vous avez retiré « Authenticated Users » de l'onglet Delegation et ajouté un groupe personnalisé sans lui donner « Read ». La GPO est ignorée en silence.
2. Filtre WMI qui échoue. Une requête WMI qui interroge Win32_OperatingSystem sur une version obsolète, ou qui utilise Win32_ComputerSystem.PartOfDomain = TRUE alors que la machine est en workgroup temporaire.
3. DNS pointe vers un DC qui n'a pas la GPO répliquée. Nouveau DC ajouté, SYSVOL pas encore répliqué. Le client tire une version obsolète.
4. Héritage bloqué au niveau de l'OU. Un administrateur zélé a coché Block Inheritance sur l'OU cible. Seules les GPO marquées Enforced passent.
5. GPO côté utilisateur appliquée à un ordinateur (ou l'inverse). Vous avez configuré la section utilisateur d'une GPO liée à une OU qui ne contient que des ordinateurs. RIEN ne s'appliquera sans loopback.
6. Cache client corrompu. Après une image WIM déployée à la va-vite, %windir%\System32\GroupPolicy\Machine\Registry.pol contient des GUIDs qui ne correspondent plus à aucune GPO.
7. Slow link detection. Sur les postes VPN, le client considère la liaison comme lente (< 500 Kbps par défaut) et saute les extensions de politique lourdes (redirection de dossiers, Software Installation).

Diagnostic avec l'Observateur d'événements et le journal GroupPolicy

Quand gpresult ne suffit pas, le journal opérationnel Group Policy est votre meilleur ami. Il se trouve dans l'Observateur d'événements sous Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Chaque cycle de traitement est encadré par un événement de début (Event ID 4001 pour utilisateur, 4004 pour ordinateur) et un événement de fin (Event ID 8001, 8004). Entre les deux, chaque phase émet ses propres événements.

Les identifiants à retenir pour un diagnostic rapide :

Event ID	Phase	Signification
4016 / 5016	Extension côté client	Début / fin d'une extension (Registry, Folder Redirection, etc.)
5312	Liste des GPO	Liste des GPO à appliquer, dans l'ordre LSDOU
5326	Filtrage	Filtrage WMI ou de sécurité évalué avec succès
6017	Extension	Extension terminée en erreur (regardez le message pour la CSE fautive)
7016	Extension	Extension a rapporté un état d'erreur au moteur GP
1055 / 1006	Discovery	Échec de discovery du DC (DNS ou LDAP), cause fréquente sous VPN

Pour extraire tous les événements Group Policy des dernières 24 heures en une commande PowerShell, utilisez Get-WinEvent avec un filtre XPath. C'est nettement plus rapide qu'un clic dans l'interface graphique, surtout sur un poste distant via WinRM :

# Récupère les événements Group Policy des 24 dernières heures
# Utile pour diagnostiquer un utilisateur distant sans ouvrir eventvwr.msc
$since = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-GroupPolicy/Operational'
    StartTime = $since
    Level     = 1,2,3  # Critical, Error, Warning uniquement
} | Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-Table -AutoSize -Wrap

Si vous voyez Event ID 1055 ou 1006 répétés, ce n'est pas un problème de GPO mais un problème de résolution DNS ou de connectivité LDAP vers votre DC. Traitez la couche réseau avant de retoucher quoi que ce soit dans GPMC (c'est un point que je répète à chaque nouveau tier-1, et croyez-moi, vous éviterez trois heures perdues à chercher au mauvais endroit). Pour les incidents où c'est en réalité l'ouverture de session distante qui échoue, consultez notre guide RDP ne se connecte pas sous Windows 11 qui couvre les mêmes couches DNS et Kerberos.

Filtrage de sécurité, filtres WMI et exceptions

Le filtrage de sécurité, c'est là où je vois le plus de dégâts. La règle de fer : pour qu'une GPO s'applique à un principal (utilisateur ou ordinateur), ce principal doit avoir à la fois « Read » et « Apply group policy » sur l'objet GPO. Quand vous ajoutez un groupe dans l'onglet Scope → Security Filtering de GPMC, ces deux permissions sont accordées automatiquement. Mais si vous manipulez l'onglet Delegation, il est facile de casser cette symétrie.

Pour auditer rapidement les ACL d'une GPO depuis PowerShell, sans passer par la GUI :

# Nécessite le module GroupPolicy (RSAT-GPMC) et RSAT-AD-PowerShell
# Liste les permissions d'une GPO donnée par son nom
Import-Module GroupPolicy
$gpoName = 'STD_Verrouillage_Session_10min'

Get-GPPermission -Name $gpoName -All | Select-Object `
    @{n='Trustee';    e={$_.Trustee.Name}}, `
    @{n='Permission'; e={$_.Permission}},   `
    @{n='Inherited';  e={$_.Inherited}}

Vous devez voir GpoApply pour le groupe cible et GpoRead pour les ordinateurs ou utilisateurs qui doivent traiter la GPO. Si vous voyez seulement GpoApply, la GPO échouera avec un événement 5313 « Access is denied » côté client.

Les filtres WMI sont l'autre mine à trous. Un filtre trop restrictif ou syntaxiquement invalide fait échouer l'ensemble de la GPO. Testez-les avec Get-WmiObject depuis le poste client avant de lier le filtre :

# Simule le filtre WMI côté client pour Windows 11 22H2 et supérieur
# Retourne un objet si le filtre s'applique, rien sinon
Get-CimInstance -Query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '10.0.2%' AND ProductType = 1"
# ProductType = 1 : workstation ; = 2 : DC ; = 3 : server

Réplication SYSVOL, DNS et contrôleurs de domaine

Toute GPO stocke ses données à deux endroits : les métadonnées dans AD (partition Domain), et les fichiers de politique (Registry.pol, GPT.ini, scripts) dans le partage SYSVOL répliqué entre tous les DC. Si la réplication SYSVOL est en panne, un client qui interroge un DC « en retard » verra une version obsolète, ou pire, une divergence entre GPT.ini (fichier) et gPCFileSysPath (attribut AD). Le symptôme classique : la GPO s'applique parfaitement dans un site, pas dans l'autre.

La procédure officielle Microsoft repose sur DFSR depuis Windows Server 2012 R2 ; FRS a été supprimé dans Server 2019. Vérifiez l'état de réplication avec dfsrdiag sur chaque DC :

# À exécuter sur chaque DC pour vérifier l'état DFSR SYSVOL
dfsrdiag ReplicationState /verbose

# Vérifie qu'aucun fichier n'est bloqué en backlog
dfsrdiag Backlog /ReceivingMember:DC02.contoso.local /SendingMember:DC01.contoso.local `
    /RGName:"Domain System Volume" /RfName:"SYSVOL Share"

Un backlog supérieur à zéro qui ne se vide pas en 5 minutes indique un vrai problème (contention disque, partition pleine, DFSR service arrêté). Consultez la documentation Microsoft Learn sur le dépannage Group Policy pour le catalogue complet des scénarios DFSR/SYSVOL.

Côté DNS, la commande nltest /dsgetdc:contoso.local vous dit quel DC votre client sélectionne à cet instant. Si c'est un DC dans un site distant à cause d'un enregistrement SRV mal pondéré, vos GPO « nouvelles » ne seront pas visibles. La correction est côté DC : vérifier la pondération SRV et le site AD auquel le sous-réseau du client est associé.

# Diagnostic : quel DC le client utilise pour Group Policy ?
nltest /dsgetdc:contoso.local /gc

# Force la sélection d'un DC spécifique (temporaire, pour tester)
nltest /sc_reset:contoso.local\DC01
gpupdate /force

Loopback, héritage et ordre de traitement LSDOU

Les GPO sont traitées dans l'ordre LSDOU : Local, Site, Domain, OU (de la racine vers la feuille). À chaque niveau, les GPO liées sont traitées dans l'ordre inverse de leur ordre de lien (la GPO liée avec Link Order 1 est traitée en dernier, ce qui la fait gagner en cas de conflit). C'est contre-intuitif, et c'est la source de nombreux tickets « pourquoi ma GPO n'a-t-elle aucun effet alors qu'elle est bien liée ? ». Réponse : une autre GPO liée à la même OU la surcharge.

Le Loopback Processing est un mécanisme spécifique et souvent mal compris. Il permet d'appliquer des paramètres utilisateur en fonction de l'ordinateur où l'utilisateur ouvre sa session. Deux modes :

• Replace : les paramètres utilisateur des GPO de l'ordinateur remplacent complètement ceux de l'utilisateur. Utile pour les kiosques et postes partagés.
• Merge : les paramètres utilisateur des GPO de l'ordinateur sont fusionnés avec ceux de l'utilisateur, et gagnent en cas de conflit. Utile pour les serveurs RDS/Citrix.

L'héritage se bloque au niveau d'une OU avec Block Inheritance. Pour forcer une GPO à passer malgré un blocage, marquez-la Enforced (anciennement No Override). Une GPO Enforced gagne également en cas de conflit avec une GPO plus proche de la feuille : c'est le seul cas où l'ordre LSDOU s'inverse.

gpupdate /force et redémarrage : quand et pourquoi

La question « quelle différence entre gpupdate et gpupdate /force ? » revient toutes les semaines dans mon service desk. La réponse courte : sans /force, Windows compare les numéros de version des GPO côté client et côté DC, et n'applique que ce qui a changé. Avec /force, il applique toutes les GPO, quel que soit leur numéro de version.

/force est utile dans trois cas précis :

1. Quand vous soupçonnez un cache client corrompu (les Registry.pol locaux).
2. Quand vous avez modifié une extension côté serveur (par exemple un script de démarrage) sans changer un paramètre de politique. Le numéro de version ne bouge pas, et seul /force redéclenche l'exécution.
3. Après avoir vidé manuellement le dossier %windir%\System32\GroupPolicy pour reconstruire le cache.

Certaines extensions (Software Installation, Folder Redirection, Group Policy Preferences avec cible « Applies Once ») ne se réappliquent pas lors d'un gpupdate, même avec /force. Elles n'agissent qu'à l'ouverture de session ou au démarrage. Un redémarrage est alors nécessaire. Le script suivant enchaîne un vidage de cache, un gpupdate /force asynchrone et une élévation propre, à réserver aux postes vraiment récalcitrants :

# Recovery script : vide le cache et force un traitement synchrone au prochain logon
# À exécuter en tant qu'administrateur ; le redémarrage est OBLIGATOIRE ensuite.

# 1. Purge le cache local Group Policy (machine et utilisateurs)
Remove-Item -Path "$env:windir\System32\GroupPolicy\Machine\*" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item -Path "$env:windir\System32\GroupPolicy\User\*"    -Recurse -Force -ErrorAction SilentlyContinue

# 2. Force le prochain logon à être synchrone (une seule fois)
# Sous HKLM\Software\Microsoft\Windows\CurrentVersion\Winlogon
$reg = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Winlogon'
New-ItemProperty -Path $reg -Name 'SyncForegroundPolicy' -PropertyType DWord -Value 1 -Force | Out-Null

# 3. Applique les GPO ordinateur et utilisateur immédiatement, puis planifie le reboot
gpupdate /force /wait:0
Write-Host "Redémarrage nécessaire pour Folder Redirection / Software Installation" -ForegroundColor Yellow

Scripts PowerShell pour l'audit de masse

Un ticket, c'est un poste. Une classe de tickets, c'est un audit. Quand vous voyez la même GPO échouer sur 40 postes le lundi matin, vous ne voulez pas exécuter gpresult à la main sur chacun (personne n'a envie de vivre ça deux fois). Le script ci-dessous parcourt une liste de postes (fichier texte ou requête AD), collecte le rapport RSoP au format XML, et détecte les GPO refusées. Il tourne en parallèle avec ForEach-Object -Parallel (PowerShell 7+, natif sur Windows 11 24H2 avec le paquet AppX PowerShell 7).

# Audit multi-postes : détecte les GPO refusées sur un lot de machines
# Requiert PowerShell 7+ et WinRM activé sur les clients (Enable-PSRemoting -Force)
# Sortie : CSV avec colonnes Computer, GPO, Reason

$computers = Get-ADComputer -Filter "OperatingSystem -like '*Windows 11*'" |
             Select-Object -ExpandProperty Name

$results = $computers | ForEach-Object -Parallel {
    $c = $_
    try {
        # Récupère le RSoP XML depuis le poste distant
        $xml = Invoke-Command -ComputerName $c -ScriptBlock {
            $tmp = "$env:TEMP\rsop.xml"
            gpresult /x $tmp /f | Out-Null
            [xml](Get-Content $tmp -Raw)
        } -ErrorAction Stop

        # Trouve les GPO refusées dans la partie Computer
        $denied = $xml.Rsop.ComputerResults.DeniedGPO
        foreach ($d in $denied) {
            [PSCustomObject]@{
                Computer = $c
                GPO      = $d.Name
                Reason   = $d.DenyReason
            }
        }
    } catch {
        [PSCustomObject]@{
            Computer = $c
            GPO      = 'N/A'
            Reason   = "Unreachable: $($_.Exception.Message)"
        }
    }
} -ThrottleLimit 20

$results | Export-Csv -Path ".\gpo-audit-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
Write-Host "Rapport écrit dans le CSV. Filtrez par colonne Reason pour trouver les motifs récurrents."

Pour un audit encore plus poussé au niveau du domaine, exportez la définition complète des GPO en XML avec Backup-GPO, puis analysez les rapports HTML. La documentation du module PowerShell GroupPolicy sur Microsoft Learn détaille toutes les cmdlets disponibles. Enfin, pour les scénarios où vous devez piloter Microsoft 365 en plus de vos GPO (redirection OneDrive, préférences Outlook, politiques Intune qui se superposent), notre guide sur l'administration Microsoft 365 en PowerShell et Graph API couvre l'autre moitié de la surface d'attaque du poste de travail moderne.

Pour la référence officielle des identifiants d'événement Group Policy, consultez la table complète des événements du client Group Policy publiée par Microsoft. Elle est ancienne mais toujours à jour ; le schéma d'événements n'a pas bougé depuis Windows 7.

Questions fréquentes

Comment forcer l'application d'une GPO sur Windows 11 ?

Ouvrez un terminal en administrateur et exécutez gpupdate /force. Pour les extensions Folder Redirection ou Software Installation, un redémarrage est requis en plus. Si le cache local est corrompu, videz %windir%\System32\GroupPolicy avant de relancer gpupdate.

Pourquoi ma stratégie de groupe ne s'applique-t-elle pas à certains utilisateurs ?

Dans 90 % des cas, c'est un filtrage de sécurité incomplet (« Read » manquant après retrait d'Authenticated Users), un filtre WMI qui échoue, ou une GPO configurée côté utilisateur mais liée à une OU d'ordinateurs sans loopback. Le rapport gpresult /h section « Denied GPOs » donne le motif exact.

Combien de temps faut-il pour qu'une nouvelle GPO s'applique ?

L'actualisation en arrière-plan tourne toutes les 90 minutes ± 30 minutes d'offset aléatoire pour les postes de travail, toutes les 5 minutes pour les DC. Prévoyez donc jusqu'à 2 heures dans le pire cas, ou forcez avec gpupdate /force. Certaines politiques (Software Installation, Folder Redirection) n'agissent qu'au prochain démarrage ou logon.

Quelle est la différence entre gpupdate et gpupdate /force ?

gpupdate ne réapplique que les GPO dont le numéro de version a changé côté DC. gpupdate /force réapplique toutes les GPO, ce qui est utile après une modification côté serveur qui n'a pas incrémenté la version (script modifié en place) ou pour reconstruire un cache client corrompu.

Comment consulter les erreurs de traitement Group Policy ?

Ouvrez l'Observateur d'événements et allez dans Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Filtrez sur les niveaux Error et Warning. Les identifiants 6017, 7016 et 1055 pointent respectivement une extension en erreur, un état d'erreur remonté, et un problème de discovery du DC.

Pourquoi ma GPO fonctionne-t-elle sur un site mais pas sur un autre ?

Presque toujours un problème de réplication SYSVOL entre DC. Vérifiez avec dfsrdiag ReplicationState et dfsrdiag Backlog. Vérifiez aussi que les sous-réseaux AD sont correctement associés aux sites : un client peut interroger un DC distant si le mapping site est mauvais.