Windows Update bloqué sous Windows 11 : guide de dépannage helpdesk (2026)

Mis à jour : 18 juillet 2026

Quand Windows Update reste bloqué sous Windows 11, la cause la plus fréquente en 2026 est un magasin de composants (Component Store) corrompu ou une base de données SoftwareDistribution qui n'a pas été vidée depuis des mois. Le correctif éprouvé : arrêter les services wuauserv, bits et cryptsvc, renommer les dossiers SoftwareDistribution et catroot2, puis lancer DISM /RestoreHealth suivi de sfc /scannow. Honnêtement, ce guide couvre les cinq solutions que j'applique dans l'ordre sur mon service desk, avec les codes d'erreur 2026 les plus courants, les logs à analyser et les scripts PowerShell prêts à coller.

• Les blocages Windows Update en 2026 se répartissent en trois grandes familles : corruption du magasin de composants, conflit WSUS/Intune et manque d'espace disque sur la partition système.
• L'utilitaire de résolution de problèmes intégré à Windows 11 24H2 résout environ 40 % des cas, mais échoue silencieusement sur les erreurs 0x800f081f, 0x8007000d et 0x80073712.
• La séquence DISM /Online /Cleanup-Image /RestoreHealth puis sfc /scannow reste la référence pour réparer le Component Store. Comptez 20 à 45 minutes.
• Le script de réinitialisation complet (arrêt des services, purge de SoftwareDistribution et catroot2, réenregistrement des DLL) doit être signé et déployé via Intune ou GPO plutôt que copié à la main.
• Pour un parc de plus de cinquante machines, monitorer WindowsUpdate.log reconstruit avec Get-WindowsUpdateLog et corréler avec Intune Update Compliance vaut mieux que résoudre les tickets un par un.

Pourquoi Windows Update reste-t-il bloqué sous Windows 11 ?

Sur le service desk que je gère, les tickets « Windows Update bloqué » représentent environ 8 % du volume mensuel, avec un pic systématique le mardi qui suit le Patch Tuesday. Les causes racines se ramènent presque toujours à cinq scénarios : un magasin de composants corrompu après une interruption d'alimentation, un cache SoftwareDistribution gonflé à plusieurs gigaoctets, un conflit de politique entre WSUS et Intune sur les machines cogérées, une partition système saturée (moins de 8 Go libres) ou une mise à jour cumulative qui échoue faute d'un correctif préalable manquant.

La particularité de Windows 11 24H2 et de la version 25H2 sortie en octobre 2025, c'est le mécanisme de checkpoint cumulative updates, qui rejoue en cas d'échec les correctifs depuis le dernier checkpoint plutôt que depuis la RTM. Ce mécanisme réduit la taille des mises à jour, mais introduit un nouveau mode d'échec : si le checkpoint local est corrompu, la mise à jour boucle indéfiniment à 96 % avec le code 0x800f0922. Dans ce cas, aucun redémarrage ne débloque la situation ; il faut reconstruire le magasin de composants.

Le point que je répète en formation à mes techniciens N1 : ne jamais laisser un utilisateur en autoréparation pendant plus d'une heure. Une mise à jour cumulative légitime dépasse rarement les 40 minutes sur un SSD moderne. Au-delà, c'est un blocage. Et plus on attend, plus le risque de corrompre le profil utilisateur ou la partition de récupération augmente.

Codes d'erreur Windows Update les plus courants en 2026

Voici les codes que je vois passer chaque semaine, classés par fréquence dans nos tickets. La liste officielle est disponible sur Microsoft Learn, mais elle ne donne pas la cause pratique, celle qu'il faut expliquer à l'utilisateur au téléphone.

Code d'erreur	Signification pratique	Solution la plus efficace
0x80070005	Accès refusé : problème de permissions sur SoftwareDistribution ou clés registre.	Solution 2 puis 5 (script de réinitialisation).
0x800f081f	Source des fichiers introuvable : Component Store incomplet.	Solution 3 (DISM /RestoreHealth avec source WIM).
0x8007000d	Données invalides : manifeste de mise à jour corrompu.	Solution 3 puis 4 (installation manuelle).
0x80073712	Fichier CBS manquant.	Solution 3 (DISM avec source /LimitAccess).
0x800f0922	Échec du staging (souvent partition de récupération pleine).	Étendre la partition récupération à 750 Mo min.
0x8024a105	Blocage côté client WU (service défaillant).	Solution 1 puis 2.
0x80244022	Serveur WSUS injoignable ou surchargé.	Vérifier le point de terminaison WSUS/Intune.

Un ticket typique arrive formulé « rien ne se passe, ça tourne depuis ce matin ». La première question à poser (ou à faire remonter par le formulaire de ticket) est le code d'erreur exact affiché dans Paramètres → Windows Update → Historique des mises à jour. Sans ce code, on part à l'aveugle et on brûle 20 minutes en manipulations inutiles.

Diagnostic initial : les cinq vérifications avant tout dépannage

Avant de lancer la moindre commande, je fais valider ces cinq points au technicien qui prend le ticket. Chacune de ces vérifications élimine une famille entière de faux positifs, et le simple fait de les vérifier résout environ 15 % des cas sans autre intervention.

1. Espace disque : minimum 20 Go libres sur C: et 750 Mo sur la partition de récupération. Vérifier avec Get-Volume | Format-Table DriveLetter, SizeRemaining, Size.
2. Date et heure : un décalage supérieur à 5 minutes casse la validation TLS des serveurs WU. Forcer une synchronisation avec w32tm /resync /force.
3. Connectivité : tester Test-NetConnection windowsupdate.microsoft.com -Port 443. En entreprise, valider que le proxy autorise les endpoints Windows Update officiels.
4. Politique WSUS/Intune : lire HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. Si WUServer est défini mais que le serveur est mort, WU boucle. Souvent la vraie cause sur les postes hérités.
5. Antivirus tiers : ESET, Sophos et Kaspersky bloquent parfois trustedinstaller.exe. Suspendre temporairement la protection et retenter.

Solution 1 : L'utilitaire de résolution des problèmes Windows Update

Sur Windows 11 24H2 et versions supérieures, l'utilitaire historique msdt.exe /id WindowsUpdateDiagnostic a été déprécié au profit de l'application Obtenir de l'aide (Get Help). Cette évolution est passée inaperçue dans beaucoup d'équipes, ce qui explique pourquoi les vieux runbooks échouent silencieusement.

La procédure actuelle sous Windows 11 24H2/25H2 :

1. Ouvrir Paramètres → Système → Résolution des problèmes → Autres utilitaires de résolution des problèmes.
2. Cliquer sur Exécuter à côté de « Windows Update ».
3. L'application Get Help s'ouvre et pilote un diagnostic automatisé (vérification des services, du cache, des clés registre).
4. Redémarrer et relancer la vérification des mises à jour.

En scriptable, pour un déploiement sur plusieurs machines via Intune Remediation ou une session PSRemoting :

# Lance le module de diagnostic Windows Update en ligne de commande
# Fonctionne sous Windows 11 24H2 et superieur
Get-TroubleshootingPack -Path "$env:SystemRoot\diagnostics\system\WindowsUpdate" |
    Invoke-TroubleshootingPack -Unattended -Result "C:\Temp\WU-Diag"

# Consulter le rapport genere
Get-ChildItem "C:\Temp\WU-Diag" -Recurse -Filter "*.xml"

D'expérience, l'utilitaire résout environ 40 % des cas simples (services arrêtés, ACL cassées, cache modérément corrompu). Il échoue à peu près systématiquement sur les erreurs de Component Store. Passez directement à la Solution 3 si vous voyez 0x800f081f ou 0x80073712.

Solution 2 : Redémarrer les services et vider SoftwareDistribution

C'est le remède qui débloque la majorité des tickets non résolus par l'utilitaire. Le principe est simple : arrêter proprement la chaîne de services Windows Update, renommer (jamais supprimer) le cache local, puis redémarrer. Windows recrée SoftwareDistribution et catroot2 automatiquement au prochain démarrage.

# Script vidage SoftwareDistribution : a executer en administrateur
# Fonctionne sur Windows 10 22H2 et toutes versions Windows 11
$services = @('wuauserv', 'cryptsvc', 'bits', 'msiserver')

Write-Host "Arret des services Windows Update..." -ForegroundColor Cyan
foreach ($svc in $services) {
    Stop-Service -Name $svc -Force -ErrorAction SilentlyContinue
    # Attendre l'arret complet (bits met parfois 30s)
    $timeout = 0
    while ((Get-Service $svc).Status -ne 'Stopped' -and $timeout -lt 30) {
        Start-Sleep -Seconds 1; $timeout++
    }
}

Write-Host "Renommage des caches..." -ForegroundColor Cyan
$backup = Get-Date -Format 'yyyyMMdd-HHmmss'
Rename-Item "$env:SystemRoot\SoftwareDistribution" "SoftwareDistribution.bak-$backup" -ErrorAction Stop
Rename-Item "$env:SystemRoot\System32\catroot2" "catroot2.bak-$backup" -ErrorAction Stop

Write-Host "Redemarrage des services..." -ForegroundColor Cyan
foreach ($svc in $services) { Start-Service -Name $svc }

Write-Host "Lancer maintenant : Parametres > Windows Update > Rechercher" -ForegroundColor Green

Points d'attention que je fais valider à chaque exécution :

• Renommer et non supprimer. Si la mise à jour échoue à nouveau, on peut revenir en arrière.
• Ne jamais purger catroot2 sans arrêter cryptsvc d'abord, sous peine d'invalider les signatures de tous les paquets en cours.
• Sur une machine BitLocker, aucun impact particulier, mais si l'utilisateur redémarre pendant la reconstruction du cache, la clé de récupération peut être demandée. Gardez sous la main la procédure de récupération de clé BitLocker avant d'appliquer ce script à distance.

Solution 3 : Réparer le magasin de composants avec DISM et SFC

Quand l'erreur pointe vers un fichier système manquant (0x800f081f, 0x8007000d, 0x80073712), la seule vraie solution est de réparer le Component Store. L'ordre compte : d'abord DISM (qui vérifie et répare la source), puis SFC (qui utilise cette source pour restaurer les fichiers système).

# Sequence complete de reparation Component Store
# Duree : 20-45 minutes sur SSD, plus long en cas de telechargement Windows Update

# 1. Diagnostic rapide (ne repare pas, ne modifie rien)
DISM.exe /Online /Cleanup-Image /CheckHealth

# 2. Analyse approfondie (5-15 min)
DISM.exe /Online /Cleanup-Image /ScanHealth

# 3. Reparation (peut telecharger depuis Windows Update - 15-30 min)
DISM.exe /Online /Cleanup-Image /RestoreHealth

# 4. Verification et reparation des fichiers systeme proteges (5-10 min)
sfc /scannow

# 5. Redemarrer imperativement avant de relancer Windows Update
Restart-Computer -Force

Si la machine n'a pas accès à Windows Update (poste en zone isolée, WSUS cassé), il faut fournir une source locale via un fichier install.wim monté depuis un ISO Windows 11 de même version :

# Monter l'ISO Windows 11 (adapter la lettre de lecteur)
$iso = "C:\ISO\Win11_25H2_French_x64.iso"
Mount-DiskImage -ImagePath $iso
# Identifier l'index de l'edition (souvent 6 = Pro, 3 = Entreprise)
Get-WindowsImage -ImagePath "E:\sources\install.wim"

# Reparation avec source locale, sans acces reseau WU
DISM.exe /Online /Cleanup-Image /RestoreHealth `
    /Source:WIM:E:\sources\install.wim:6 /LimitAccess

Solution 4 : Installer la mise à jour depuis le Catalogue Microsoft Update

Quand une mise à jour cumulative précise (par exemple KB5040442) refuse obstinément de s'installer via Windows Update, la solution la plus rapide est de la télécharger et de l'installer manuellement depuis catalog.update.microsoft.com. Ce contournement fonctionne parce qu'il court-circuite l'agent WU et attaque directement wusa.exe.

1. Identifier le numéro KB dans l'historique des mises à jour (Paramètres → Windows Update → Historique).
2. Rechercher ce KB sur le Catalogue Microsoft Update.
3. Filtrer par architecture (x64 pour la plupart des postes) et version Windows 11 (24H2, 25H2).
4. Télécharger le fichier .msu et lancer wusa.exe C:\Temp\windows11.0-kb5040442-x64.msu /quiet /norestart.
5. Redémarrer et vérifier le succès avec Get-HotFix -Id KB5040442.

Pour un déploiement Intune, préférez packager le .msu dans une application Win32 (.intunewin) avec la commande d'installation wusa.exe *.msu /quiet /norestart. C'est ma méthode par défaut pour les correctifs de sécurité urgents que je ne veux pas attendre du cycle Patch Tuesday normal.

Solution 5 : Réinitialiser complètement Windows Update par script

Bon, on arrive à la « bombe atomique », à sortir en dernier recours, ou en préventif sur une machine qui n'a pas reçu de mise à jour depuis six mois. Elle combine : arrêt de tous les services, purge des caches, réenregistrement des DLL Windows Update, réinitialisation des clés registre, remise à zéro de BITS et Winsock. Comptez 5 à 10 minutes d'exécution et un redémarrage obligatoire.

# Reset-WindowsUpdate.ps1
# Runbook helpdesk - reinitialisation complete Windows Update
# A signer avant deploiement Intune ou GPO

#Requires -RunAsAdministrator

Write-Host "[1/6] Arret des services..." -ForegroundColor Cyan
$svc = 'wuauserv','cryptsvc','bits','msiserver','appidsvc'
$svc | ForEach-Object { Stop-Service $_ -Force -EA SilentlyContinue }

Write-Host "[2/6] Suppression des fichiers de tache BITS..." -ForegroundColor Cyan
Remove-Item "$env:ALLUSERSPROFILE\Application Data\Microsoft\Network\Downloader\qmgr*.dat" `
    -Force -EA SilentlyContinue

Write-Host "[3/6] Purge des caches (backup avec timestamp)..." -ForegroundColor Cyan
$ts = Get-Date -Format 'yyyyMMdd-HHmmss'
Move-Item "$env:SystemRoot\SoftwareDistribution" `
    "$env:SystemRoot\SoftwareDistribution.old-$ts" -Force -EA SilentlyContinue
Move-Item "$env:SystemRoot\System32\catroot2" `
    "$env:SystemRoot\System32\catroot2.old-$ts" -Force -EA SilentlyContinue

Write-Host "[4/6] Reenregistrement des DLL Windows Update..." -ForegroundColor Cyan
$dlls = 'atl.dll','urlmon.dll','mshtml.dll','shdocvw.dll','browseui.dll',
        'jscript.dll','vbscript.dll','scrrun.dll','msxml.dll','msxml3.dll',
        'msxml6.dll','actxprxy.dll','softpub.dll','wintrust.dll','dssenh.dll',
        'rsaenh.dll','gpkcsp.dll','sccbase.dll','slbcsp.dll','cryptdlg.dll',
        'oleaut32.dll','ole32.dll','shell32.dll','initpki.dll','wuapi.dll',
        'wuaueng.dll','wuaueng1.dll','wucltui.dll','wups.dll','wups2.dll',
        'wuweb.dll','qmgr.dll','qmgrprxy.dll','wucltux.dll','muweb.dll','wuwebv.dll'
Push-Location "$env:SystemRoot\System32"
$dlls | ForEach-Object { regsvr32.exe /s $_ }
Pop-Location

Write-Host "[5/6] Reset BITS + Winsock..." -ForegroundColor Cyan
netsh winsock reset | Out-Null
netsh int ip reset  | Out-Null

Write-Host "[6/6] Redemarrage des services..." -ForegroundColor Cyan
$svc | ForEach-Object { Start-Service $_ -EA SilentlyContinue }

Write-Host "OK - REDEMARRER IMPERATIVEMENT LA MACHINE" -ForegroundColor Green
Write-Host "Puis Parametres > Windows Update > Rechercher les mises a jour" -ForegroundColor Green

Ce script fait partie de la boîte à outils standard que je distribue à toute nouvelle recrue N2. Il est important de le signer avec le certificat de code de l'organisation : Windows 11 bloque les scripts non signés déployés via Intune avec la politique d'exécution AllSigned, et je préfère ne pas relâcher cette politique juste pour un utilitaire de dépannage. Voir aussi la logique équivalente pour dépanner un VPN qui ne se connecte pas. La démarche « scripter, signer, déployer » est identique.

Comment analyser CBS.log et WindowsUpdate.log ?

Quand aucune des cinq solutions ne fonctionne, ou que le même utilisateur revient une troisième fois, il faut passer à l'analyse de logs. Windows 11 tient deux journaux principaux pour tout ce qui concerne les mises à jour :

• C:\Windows\Logs\CBS\CBS.log : trace du Component Based Servicing. Chaque manipulation de composant Windows y est écrite. Les lignes marquées [SR] proviennent de SFC, les lignes [HRESULT = 0x...] pointent l'erreur exacte.
• WindowsUpdate.log : depuis Windows 10, ce fichier n'existe plus sous forme texte ; il faut le reconstruire depuis les ETL avec Get-WindowsUpdateLog.

# Reconstruire WindowsUpdate.log a partir des traces ETL
# Deposera un fichier texte sur le Bureau
Get-WindowsUpdateLog

# Extraire les 50 derniers evenements d'erreur (HRESULT != 0)
Get-Content "$env:USERPROFILE\Desktop\WindowsUpdate.log" |
    Select-String -Pattern 'FATAL|ERROR|HRESULT = 0x[89ABCDEF]' |
    Select-Object -Last 50

# Extraire les operations en echec du CBS.log
Get-Content "$env:SystemRoot\Logs\CBS\CBS.log" |
    Select-String -Pattern '(\[SR\].*Cannot|Corrupt|Failed)' |
    Select-Object -Last 30

Une fois le HRESULT identifié, je le fais correspondre à la table de la Solution 2 puis je repars sur la bonne action. Sur un ticket vraiment récalcitrant, je joins CBS.log compressé (5 à 30 Mo) au ticket avant de l'escalader au N3, ça évite au niveau supérieur de repartir de zéro. Cette culture du « log-first » avant escalade est celle que je décris dans notre guide sur le dépannage des verrouillages de compte Active Directory, où la logique est exactement la même.

Gestion à l'échelle : WSUS, Intune et Delivery Optimization

Résoudre un ticket, c'est bien. Empêcher que 200 postes présentent le même problème le mardi suivant, c'est mieux. En 2026, les trois leviers de gestion à l'échelle sont WSUS (encore présent dans beaucoup de grandes entreprises malgré son annonce de dépréciation par Microsoft), Intune Update Rings et Delivery Optimization.

WSUS en fin de vie

Microsoft a officiellement déprécié WSUS en septembre 2024. Le produit continue de fonctionner mais ne recevra plus de nouvelles fonctionnalités. Pour un parc supérieur à 100 postes, ma recommandation est de planifier la migration vers Windows Update for Business + Intune sur 12 à 18 mois. Les erreurs 0x80244022 que je vois passer trois fois par semaine viennent quasi toutes de serveurs WSUS surchargés ou mal configurés.

Intune Update Rings

Les anneaux de mise à jour Intune permettent de déployer par vagues (10 %, 30 %, 60 %, 100 %) avec des délais configurables. C'est le mécanisme que j'utilise pour absorber les mises à jour cumulatives problématiques : un anneau pilote de 20 machines de test reçoit les correctifs 7 jours avant le reste, ce qui donne le temps de détecter les régressions avant d'impacter la production.

Delivery Optimization

Sur un site avec 50 machines ou plus, activer Delivery Optimization en mode GroupPolicy (téléchargement peer-to-peer au sein d'un même sous-réseau) réduit la bande passante WAN de 60 à 80 %. À configurer via Intune → Configuration Profiles → Delivery Optimization.

Bonnes pratiques ticketing pour les incidents Windows Update

La différence entre un service desk qui souffre chaque Patch Tuesday et un service desk qui glisse dessus, c'est la structure des tickets et la culture de post-mortem. Voici ce que j'impose dans mon équipe :

1. Formulaire de ticket enrichi : le champ « Code d'erreur exact » est obligatoire. Sans code, le ticket est renvoyé à l'utilisateur. Dur au début, mais ça change tout après trois semaines.
2. Runbook par code d'erreur : la table des codes de la section 2 est notre décision tree officiel. Un N1 doit pouvoir résoudre 60 % des tickets sans escalade en suivant la ligne correspondante.
3. Fenêtre de maintenance annoncée : je bloque tous les mardis 22h-minuit pour laisser les patches se dérouler sur les serveurs. Communiqué 5 jours avant à toute l'entreprise.
4. Post-mortem systématique après chaque incident Update touchant plus de 10 machines. Cause racine, mesure corrective, ajout au runbook. Nos runbooks internes ont doublé de volume en 18 mois, et le MTTR moyen a baissé de 47 %.
5. Communication utilisateur claire : jamais « votre PC est cassé ». Toujours « une mise à jour de sécurité tarde à se terminer, voici le délai estimé et l'action que je vais entreprendre ». Le vocabulaire du ticket influence directement la satisfaction utilisateur mesurée en fin d'intervention.

Questions fréquemment posées

Combien de temps une mise à jour Windows 11 doit-elle prendre normalement ?

Une mise à jour cumulative mensuelle prend 15 à 30 minutes sur un SSD moderne et jusqu'à 60 minutes sur un HDD. Une mise à jour de fonctionnalités (24H2 vers 25H2) demande 30 à 90 minutes. Au-delà de 2 heures sans progression visible, considérez la mise à jour bloquée et lancez le diagnostic.

Puis-je forcer l'arrêt d'une mise à jour Windows bloquée sans risquer de casser Windows ?

Non, jamais pendant la phase « Configuration des mises à jour » qui manipule des fichiers système. Attendez au minimum 4 heures avant tout redémarrage forcé. Si vous devez couper, faites-le en mode arrêt long presse (bouton power 10s) puis démarrez en mode récupération pour lancer Startup Repair. Un arrêt sauvage à 30 % de progression corrompt souvent le Component Store.

Pourquoi Windows Update échoue-t-il avec l'erreur 0x800f0922 sous Windows 11 ?

Le code 0x800f0922 signale un échec de staging, presque toujours causé par une partition de récupération trop petite (moins de 750 Mo). Depuis Windows 11 24H2, Microsoft exige un minimum de 250 Mo libres sur cette partition. Étendez-la avec diskpart ou l'outil KB5028997 fourni par Microsoft.

L'utilitaire de résolution des problèmes Windows Update est-il toujours disponible sous Windows 11 24H2 ?

Oui, mais son interface a été remplacée par l'application Get Help. On y accède via Paramètres → Système → Résolution des problèmes → Autres utilitaires. La commande héritée msdt.exe /id WindowsUpdateDiagnostic ne fonctionne plus sous 24H2 et supérieur.

Comment relancer manuellement Windows Update après avoir vidé SoftwareDistribution ?

Après un redémarrage, ouvrez Paramètres → Windows Update → Rechercher les mises à jour. En PowerShell, on peut forcer la détection avec usoclient.exe StartScan puis usoclient.exe StartDownload puis usoclient.exe StartInstall. Le module PSWindowsUpdate (à installer depuis PowerShell Gallery) offre aussi Get-WindowsUpdate -Install -AcceptAll.