Vous tapez une commande winget dans l'Invite de commandes ou PowerShell et Windows répond que le terme n'est pas reconnu, ou la commande se ferme sans rien afficher. WinGet, le gestionnaire de paquets de Windows, n'est pas un programme séparé : il est fourni par le composant Programme d'installation d'application (App Installer), distribué par le Microsoft Store. La panne vient presque toujours de ce composant, de son alias d'exécution ou du PATH.
Problème
- winget n'est pas reconnu dans l'Invite de commandes ou dans PowerShell.
- La commande fonctionne pour un compte Windows mais pas pour un autre.
- winget se ferme sans aucun message.
- Message « Program 'winget.exe' failed to run: The file cannot be accessed by the system ».
Messages typiques (en anglais dans la documentation Microsoft ; le libellé français affiché peut différer) :
'winget' is not recognized as an internal or external command,
operable program or batch file.
winget : The term 'winget' is not recognized as the name of a cmdlet, function, script file, or operable program.
Observer avant d'agir
| Ce que vous constatez | Cause la plus probable | Étape |
|---|---|---|
| PC neuf ou compte tout juste créé | WinGet pas encore enregistré pour ce compte | Étape 1 |
| Commande inconnue partout, Programme d'installation d'application absent ou ancien | Composant manquant ou trop ancien | Étape 2 |
| Le chemin complet fonctionne, pas le mot winget seul | Alias désactivé ou PATH modifié | Étape 3 |
| winget se ferme sans message | Version ancienne qui utilise un CDN retiré | Étape 4 |
| Erreur « cannot be accessed by the system » ou paquet visiblement abîmé | Enregistrement du paquet corrompu | Étape 5 |
Système concerné : WinGet est pris en charge sur Windows 10 version 1809 (build 17763) et ultérieures, Windows 11 et Windows Server 2025. Il n'est pas disponible dans le Bac à sable Windows (Windows Sandbox), ni dans une session exécutée en tant que SYSTEM.
Étape 1 : enregistrer WinGet pour votre compte
Quand l'utiliser : sur un PC neuf, juste après une installation de Windows ou lors de la première connexion d'un nouveau compte. Microsoft indique que WinGet n'est disponible qu'après la première ouverture de session : le Microsoft Store l'enregistre de façon asynchrone.
Solution proposée
Patientez quelques minutes après la première connexion, puis rouvrez le terminal. Si la commande reste inconnue, forcez l'enregistrement dans une fenêtre PowerShell normale (pas besoin des droits administrateur) :
Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
Fermez puis rouvrez PowerShell et testez :
winget --version
Résultat attendu : un numéro de version s'affiche.
Retour arrière : aucun, la commande ne fait qu'enregistrer un paquet déjà présent pour votre compte.
Étape 2 : installer ou mettre à jour le Programme d'installation d'application
Quand l'utiliser : la commande reste inconnue après l'étape 1, ou le composant est absent (édition réduite de Windows, Microsoft Store supprimé, image d'entreprise).
Solution proposée
- Vérifiez la version installée dans PowerShell :
Get-AppxPackage microsoft.desktopappinstaller
- Si rien ne s'affiche ou si la ligne Version est ancienne (le dépôt officiel indique qu'il faut une version supérieure à 1.11.11451), installez ou mettez à jour Programme d'installation d'application depuis sa page du Microsoft Store, ou via le lien officiel aka.ms/getwinget.
- Rouvrez le terminal et relancez winget --version.
Résultat attendu : la commande répond après la mise à jour.
Retour arrière : inutile, il s'agit d'un composant Windows maintenu par Microsoft.
Si le Microsoft Store lui-même ne s'ouvre pas, réglez d'abord ce point : Microsoft Store qui ne s'ouvre pas ou téléchargements bloqués.
Étape 3 : vérifier l'alias d'exécution et le PATH
Quand l'utiliser : le composant est bien installé (étape 2) mais le mot winget seul n'est pas trouvé.
Solution proposée
- Testez le chemin complet de l'alias dans PowerShell :
& "$env:LOCALAPPDATA\Microsoft\WindowsApps\winget" --version
- Si cela fonctionne, le problème vient de la façon dont Windows trouve la commande :
- ouvrez le menu Démarrer, cherchez Gérer les alias d'exécution d'application et vérifiez que l'alias winget.exe (Programme d'installation d'application) est sur Activé ;
- vérifiez que le PATH de votre compte contient toujours %LOCALAPPDATA%\Microsoft\WindowsApps (Démarrer, cherchez Modifier les variables d'environnement pour votre compte, puis la variable Path). Cette entrée est présente par défaut ; un logiciel ou une modification manuelle a pu la supprimer.
- Si l'entrée manque, ajoutez-la avec le bouton Nouveau, validez, puis ouvrez un nouveau terminal.
Résultat attendu : winget --version répond dans une nouvelle fenêtre.
Retour arrière : l'alias peut être désactivé de nouveau au même endroit ; une entrée ajoutée au PATH se supprime dans la même fenêtre.
Étape 4 : winget se ferme sans aucun message
Quand l'utiliser : la commande est reconnue mais ne produit aucune sortie.
Solution proposée
Le dépôt officiel de WinGet explique que les versions antérieures à 1.6.3482 utilisent un CDN retiré. Mettez à jour Programme d'installation d'application (étape 2), puis actualisez les sources :
winget source update
Résultat attendu : winget search affiche de nouveau des résultats.
Retour arrière : aucun.
Étape 5 : réparer le composant
Quand l'utiliser : après les étapes 1 à 4, ou si l'erreur « Program 'winget.exe' failed to run » apparaît. Les deux méthodes ci-dessous viennent de la documentation Microsoft et du dépôt officiel ; commencez par la première.
Solution proposée
Méthode A, réinitialiser le paquet (Windows 11) dans PowerShell :
Get-AppxPackage Microsoft.DesktopAppInstaller | Reset-AppxPackage
Méthode B, outil de réparation officiel dans PowerShell ouvert en administrateur :
Install-PackageProvider -Name NuGet -Force | Out-Null
Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-Null
Repair-WinGetPackageManager -Force -Latest
Si PowerShell refuse d'exécuter le module à cause de la stratégie d'exécution, consultez « L'exécution de scripts est désactivée » dans PowerShell au lieu de désactiver une protection à l'aveugle.
Résultat attendu : winget --version répond après fermeture et réouverture du terminal.
Retour arrière : la réinitialisation remet le composant à son état d'origine ; les logiciels déjà installés avec WinGet ne sont pas désinstallés.
Cas particuliers
| Situation | Explication |
|---|---|
| Fonctionne pour un compte, pas pour un autre | Le composant est enregistré par utilisateur : refaites l'étape 1 dans la session concernée. |
| Script lancé par une tâche planifiée en SYSTEM | Le client WinGet en ligne de commande n'est pas pris en charge dans ce contexte. |
| Bac à sable Windows | WinGet et le Microsoft Store n'y sont pas inclus. |
| PC d'entreprise | Une stratégie peut bloquer le Store ou WinGet : voyez votre service informatique. |
Vérification finale
- ☐ winget --version affiche un numéro de version.
- ☐ winget search renvoie des résultats.
- ☐ La commande fonctionne dans une nouvelle fenêtre, Invite de commandes et PowerShell.
Pour un diagnostic plus poussé, winget --info affiche notamment l'emplacement des journaux (par défaut %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir).
Sources
- Microsoft Learn : Utiliser WinGet pour installer et gérer des applications
- Microsoft Learn : Résolution des problèmes de WinGet
- Dépôt officiel de WinGet (problèmes courants) : microsoft/winget-cli sur GitHub
- Microsoft Store : Programme d'installation d'application
Le problème continue ?
Répondez à ce sujet en indiquant votre version de Windows (touche Windows + R, winver), le message exact obtenu, le résultat de Get-AppxPackage microsoft.desktopappinstaller (ligne Version seulement) et si le PC est géré par une entreprise ou une école. Retirez votre nom d'utilisateur des chemins avant de les copier.