Le code 0x80244022 n’est pas une panne de Windows : c’est le client de mise à jour qui reçoit un HTTP 503 de la source qu’il interroge, autrement dit un serveur temporairement indisponible ou surchargé. Microsoft le documente sous le libellé WU_E_PT_HTTP_STATUS_SERVICE_UNAVAILABLE, avec une seule conclusion pratique : le problème est côté réseau, proxy ou serveur de mises à jour, pas côté fichiers système.
Points clés
- 0x80244022 correspond à l’état HTTP 503 : la source de mise à jour répond, mais se déclare indisponible ou surchargée.
- Le libellé officiel est WU_E_PT_HTTP_STATUS_SERVICE_UNAVAILABLE, et la description Microsoft est « impossible de se connecter à la source de mise à jour configurée ».
- La piste indiquée par Microsoft est la résolution des problèmes réseau, en particulier un proxy qui exige une authentification de l’utilisateur.
- Sur un poste isolé, l’erreur est souvent passagère : elle disparaît en relançant la recherche quelques heures plus tard.
- Sur un parc, elle désigne presque toujours le serveur WSUS ou le proxy sortant, pas les postes.
Ce que le code veut dire, exactement
Le code appartient à la famille des erreurs de transport du client Windows Update. Ces codes reprennent un à un les états HTTP renvoyés par la source interrogée. La référence des codes d’erreur Windows Update associe 0x80244022 à WU_E_PT_HTTP_STATUS_SERVICE_UNAVAIL avec la mention « identique à l’état HTTP 503 : le service est temporairement surchargé ». Ses voisins immédiats sont parlants : 0x80244021 pour un 502, 0x80244023 pour une expiration côté passerelle, 0x80244024 pour une version de protocole refusée.
La conséquence est importante pour le diagnostic. Un 503 signifie que la requête est bien partie, qu’elle a atteint une machine, et que cette machine a répondu. Rien n’indique un fichier corrompu sur le poste. Chercher une solution du côté de sfc ou de DISM revient donc à réparer ce qui n’est pas cassé.

Les trois sources possibles d’un 503
Le client de mise à jour ne parle pas toujours au même interlocuteur. Trois cas se présentent, et ils n’ont pas les mêmes solutions.
Les serveurs Microsoft. Poste grand public non géré : la requête part vers l’infrastructure de mise à jour publique. Un 503 y est presque toujours temporaire, lié à une charge ponctuelle ou à un point de présence saturé.
Un serveur WSUS interne. Poste en entreprise avec une source configurée par stratégie de groupe : le 503 vient du serveur interne, souvent parce que le pool applicatif du service est arrêté, saturé, ou que le port déclaré ne correspond plus à celui écouté.
Un proxy ou un filtrage sortant. Le proxy peut répondre 503 à la place du serveur cible, notamment quand il n’arrive pas à joindre le domaine demandé ou quand une règle de sécurité coupe la connexion.
Commencer par le geste le moins risqué
Avant toute manipulation, relancez simplement la recherche de mises à jour, puis redémarrez le poste et relancez-la de nouveau. Un 503 franchement temporaire tombe à ce stade. Si l’erreur revient trois fois de suite sur plusieurs heures, le problème est structurel et le reste de la procédure devient utile.
Testez ensuite l’accès depuis un navigateur sur le même poste. Si les pages Microsoft s’ouvrent normalement alors que la recherche de mises à jour échoue, la différence tient au chemin réseau : le navigateur utilise ses propres réglages, tandis que le client de mise à jour passe par les services Windows HTTP.
Le proxy, cause la plus fréquente en entreprise
Microsoft décrit précisément ce point : le client Windows Update s’appuie sur les services Windows HTTP pour rechercher les mises à jour, et sur le service de transfert intelligent en arrière-plan ou l’optimisation de distribution pour les télécharger. Ces composants sont indépendants des réglages du navigateur de l’utilisateur. Un proxy déclaré uniquement dans le profil utilisateur reste donc invisible pour eux.
Deux vérifications se suivent. D’abord la configuration vue par les services Windows HTTP, avec netsh winhttp show proxy dans une invite de commandes ouverte en administrateur. Ensuite l’exigence d’authentification : la page de dépannage Microsoft demande explicitement de confirmer avec les équipes réseau que l’appareil atteint la source de mise à jour sans que le proxy réclame une authentification de l’utilisateur. Un proxy en mode authentifié bloque un service qui, lui, tourne sous un compte système.
Quand un proxy hérité traîne dans la configuration, netsh winhttp reset proxy remet les services Windows HTTP en accès direct. Ce geste est réversible et sans effet sur le navigateur.
Côté parc : vérifier la source configurée
Sur un poste géré, la source de mise à jour est imposée par stratégie. Un 503 renvoyé par un serveur interne se traite sur ce serveur, pas sur les postes. Trois points reviennent : le service web du serveur de mises à jour arrêté ou en recyclage, un pool saturé qui refuse les nouvelles connexions, et un décalage entre le port déclaré aux clients et le port réellement écouté.
Signe utile : si l’erreur apparaît sur des dizaines de postes en même temps, aucun poste n’est en cause. Inutile de réinitialiser les composants un par un dans ce cas.

Contrôler les services de transfert sur le poste
Deux services portent la mise à jour : le service Windows Update lui-même et le service de transfert intelligent en arrière-plan, connu sous le nom BITS. Un service arrêté ne produit pas un 503, mais un service en échec répété brouille le diagnostic. La vérification est rapide dans une fenêtre d’invite de commandes ouverte en administrateur.
Appuyez sur les touches Windows et R, tapez cmd, puis validez avec Ctrl et Maj enfoncés pour obtenir les droits d’administrateur. Exécutez ensuite sc query wuauserv et sc query bits pour lire l’état de chacun. Si l’un des deux est arrêté, redémarrez-le avec net start bits puis net start wuauserv, dans cet ordre, et relancez la recherche de mises à jour.
Accédez ensuite aux paramètres de mise à jour de Windows et regardez l’historique. L’information utile est le nom de la mise à jour en échec, sous la forme d’un numéro de correctif KB. Notez-le : il permet de télécharger le paquet manuellement depuis le catalogue Microsoft Update et de terminer l’installation sans passer par la source qui répond 503.
Ce contournement manuel a une limite. Il installe un correctif précis, il ne rétablit pas la recherche automatique. Le vrai sujet reste le chemin réseau tant que le code revient.
Réinitialiser les composants, seulement ensuite
La réinitialisation du cache et des services de mise à jour ne corrige pas un 503 par elle-même, mais elle nettoie les états bloqués laissés par des échecs répétés. Elle a du sens quand le 503 a disparu du réseau et que le poste continue d’échouer. La marche à suivre détaillée est décrite dans notre article sur la réinitialisation des composants Windows Update en ligne de commande.
Si le service lui-même est arrêté ou désactivé, le code renvoyé change et devient 0x80070422. Ce cas est traité à part dans l’article sur l’erreur 0x80070422.
Lire le journal quand rien ne bouge
Depuis Windows 8.1, le client de mise à jour n’écrit plus directement un fichier lisible : il produit des traces au format ETW. La commande PowerShell Get-WindowsUpdateLog fusionne ces traces en un fichier WindowsUpdate.log exploitable, écrit par défaut sur le bureau de l’utilisateur courant. C’est le seul moyen fiable de voir quelle adresse a été appelée et quel état HTTP a été reçu.
Ce que vous cherchez dans le journal est simple : l’URL de la source contactée. Si elle pointe vers un serveur interne alors que le poste devrait interroger les serveurs Microsoft, la stratégie appliquée est le vrai sujet.
Quand ça ne vient pas de là
Un code voisin change complètement le diagnostic. Une impossibilité de joindre les serveurs, sans réponse HTTP du tout, ressemble davantage à l’erreur 0x8024402c. Un téléchargement qui démarre puis s’interrompt relève plutôt de l’erreur 0x80246007. Une coupure réseau franche pendant l’opération donne l’erreur 0x800704cf.
Autre cas courant : un logiciel de filtrage ou un VPN d’entreprise qui inspecte le trafic chiffré. Le client de mise à jour est sensible à ces interceptions. Tester le poste hors du réseau d’entreprise, sur un partage de connexion mobile, permet de trancher en quelques minutes.
Questions fréquentes
0x80244022 vient-il de mon ordinateur ou du serveur ?
Du serveur, ou du chemin réseau qui y conduit. Le code traduit un état HTTP 503 reçu en réponse, ce qui suppose que la requête est bien sortie du poste.
Faut-il lancer sfc et DISM ?
Pas en première intention. Ces outils réparent l’image système et les fichiers protégés, pas une réponse HTTP. Ils gardent un intérêt si l’erreur change après le rétablissement du réseau.
Combien de temps attendre avant d’agir ?
Deux ou trois tentatives espacées de quelques heures suffisent à écarter un incident temporaire côté serveur. Au-delà, la piste réseau ou proxy devient prioritaire.
Le même code peut-il apparaître pendant une mise à niveau de version ?
Oui, puisque la phase de téléchargement utilise le même transport. Un blocage plus tard dans le processus de mise à niveau relève en général d’un autre code, comme 0xc1900101.
Désactiver l’antivirus change-t-il quelque chose ?
Rarement sur ce code précis. En revanche, un module de filtrage web ou un proxy local installé par la suite de sécurité peut renvoyer un 503 à la place du serveur : la question à poser porte sur le filtrage réseau, pas sur l’analyse antivirus.
Photo d’en-tete : ecran de traitement des mises a jour de Windows 10 par PantheraLeo1359531, Wikimedia Commons, domaine public. La capture montre un ecran de mise a jour generique en allemand, pas ce code d’erreur precis.
Sources : Microsoft Learn, référence des codes d’erreur Windows Update ; Microsoft Learn, erreurs courantes de Windows Update ; Microsoft Learn, détection du proxy par le client Windows Update ; Microsoft Learn, Get-WindowsUpdateLog ; Microsoft Support, résoudre les problèmes de mise à jour de Windows. Consultés le 14 septembre 2026.

Michel, dirigeant d’une PME informatique et formateur, expert en logiciels professionnels tels que CRM et ERP. Sa connaissance approfondie des outils de gestion d’entreprise lui permettant de conseiller et former efficacement d’autres sociétés à leur utilisation.





