Corriger les applications tierces sous Windows avec winget

Le guide pilier sur les correctifs se termine par un avertissement : une grande partie de ce que les attaquants exploitent sur les postes Windows n'est pas Windows. Navigateurs, lecteurs PDF, environnements Java et .NET, outils d'archivage, clients VPN et logiciels d'accès à distance ont leurs propres mécanismes de mise à jour, leurs propres rythmes de publication et, souvent, aucune gestion centralisée. Les stratégies du client Windows Update ne les concernent pas.

Ce guide est un point de départ pratique pour les parcs de petite et moyenne taille : identifier ce qui est installé, décider de ce qui compte le plus, et le corriger avec les outils dont vous disposez déjà, principalement le gestionnaire de paquets Windows (winget) et les stratégies de mise à jour automatique des éditeurs.

Étape 1 : inventorier ce qui est installé

On ne peut pas corriger ce qu'on ne connaît pas. Si vous disposez de Microsoft Defender for Endpoint, son inventaire logiciel (dans Defender Vulnerability Management) est la meilleure source, car il rapproche les versions installées des CVE. Le rapport Discovered apps d'Intune et l'inventaire matériel de Configuration Manager sont de bonnes alternatives.

À défaut, lisez les clés de désinstallation, c'est-à-dire ce que fait Programmes et fonctionnalités. Évitez Get-CimInstance Win32_Product : interroger cette classe déclenche une vérification de cohérence de chaque paquet MSI et peut lancer des réparations.

$paths = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
         'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
  Where-Object DisplayName |
  Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
  Sort-Object DisplayName |
  Export-Csv "C:\Temp\apps-$env:COMPUTERNAME.csv" -NoTypeInformation

Les installations par utilisateur (de nombreux navigateurs, clients collaboratifs et outils de développement) s'enregistrent plutôt sous HKCU et atterrissent dans %LOCALAPPDATA%. Elles échappent aux inventaires à l'échelle de la machine et sont souvent les versions les plus anciennes de l'appareil. Vérifiez-les aussi, ou bloquez les programmes d'installation par utilisateur avec App Control.

winget peut aussi afficher ce qu'il reconnaît et ce qui dispose d'une mise à jour :

winget upgrade --include-unknown

Étape 2 : prioriser selon l'exposition

Toutes les applications ne méritent pas la même rapidité. Un modèle simple à trois niveaux fonctionne :

Remontez tout élément en tête de liste dès qu'il apparaît dans le catalogue CISA Known Exploited Vulnerabilities ou que l'avis de l'éditeur indique qu'il est exploité. Les applications de niveau 1 analysent du contenu non fiable toute la journée ; c'est là que l'exploitation a lieu.

Étape 3 : laisser les éditeurs mettre à jour là où ils le font bien

Le correctif le moins coûteux est celui que l'application applique elle-même. Pour le niveau 1, activez le programme de mise à jour de l'éditeur et imposez une fenêtre de redémarrage, plutôt que de reconditionner chaque version :

• Microsoft Edge se met à jour lui-même via EdgeUpdate. Laissez ses stratégies de mise à jour à leur valeur par défaut (mises à jour autorisées) et définissez Notify a user that a browser restart is recommended or required (RelaunchNotification) avec une période de relance. Les détails figurent dans le guide de durcissement d'Edge.
• Google Chrome dispose de stratégies RelaunchNotification et RelaunchNotificationPeriod équivalentes, et les stratégies Google Update déterminent si les mises à jour sont autorisées. Utilisez les modèles ADMX de l'éditeur.
• Mozilla Firefox se gère via ses stratégies d'entreprise (policies.json ou ADMX) ; assurez-vous que DisableAppUpdate n'est pas défini.
• Les environnements .NET reçoivent leurs mises à jour de maintenance via Microsoft Update si les appareils sont autorisés à recevoir des mises à jour pour d'autres produits Microsoft. Dans les anneaux de mise à jour Intune, il s'agit de Microsoft product updates ; en stratégie de groupe, de l'option « Install updates for other Microsoft products » de Configure Automatic Updates.

Vérifiez ce que fait le programme de mise à jour de l'éditeur lorsque l'utilisateur n'a pas de droits d'administration. Certains installent un service à l'échelle de la machine qui fonctionne pour tous ; d'autres échouent silencieusement pour les utilisateurs standard, ce que vous voulez justement que tout le monde soit après la suppression des droits d'administrateur local.

Étape 4 : combler les manques avec winget

Pour les applications dépourvues d'un mécanisme de mise à jour fiable, winget peut détecter et installer les mises à jour depuis son dépôt. L'usage interactif est simple :

winget upgrade                                  # lister les mises à niveau disponibles
winget upgrade --id 7zip.7zip --silent --accept-package-agreements --accept-source-agreements
winget pin add --id Oracle.JavaRuntimeEnvironment   # exclure une application qui doit rester sur une version

Pour un usage à l'échelle du parc, exécutez-le en SYSTEM depuis une tâche planifiée, une correction (remediation) Intune ou votre RMM. winget fait partie du paquet App Installer et n'est pas dans le PATH du compte SYSTEM : résolvez donc d'abord l'exécutable :

$winget = Resolve-Path "$env:ProgramFiles\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe\winget.exe" |
  Sort-Object Path | Select-Object -Last 1 -ExpandProperty Path

$approved = 'Google.Chrome', 'Mozilla.Firefox', '7zip.7zip', 'Adobe.Acrobat.Reader.64-bit'
foreach ($id in $approved) {
  & $winget upgrade --id $id --exact --silent --scope machine `
    --accept-package-agreements --accept-source-agreements --disable-interactivity
}

Utilisez une liste explicite d'ID approuvés plutôt que winget upgrade --all. --all met à jour tout ce que winget reconnaît, y compris des applications dont vous n'avez pas testé la nouvelle version majeure. Le module PowerShell Microsoft.WinGet.Client (Get-WinGetPackage, Update-WinGetPackage) fournit une sortie structurée si vous préférez manipuler des objets plutôt qu'analyser du texte.

Les parcs plus importants passent généralement à un outil dédié : Intune Enterprise App Management (une fonctionnalité d'Intune Suite, incluse dans Microsoft 365 E5 depuis juillet 2026), les catalogues de mises à jour logicielles tierces de Configuration Manager, ou un produit de correctifs commercial. Les étapes de priorisation et de vérification restent les mêmes.

Étape 5 : verrouiller App Installer et winget

winget est aussi un canal d'installation : contrôlez-le donc avec les stratégies App Installer sous Computer Configuration > Policies > Administrative Templates > Windows Components > Desktop App Installer (registre : HKLM\SOFTWARE\Policies\Microsoft\Windows\AppInstaller) :

Ces noms correspondent au fichier DesktopAppInstaller.admx actuel, et Intune expose les mêmes paramètres dans la zone DesktopAppInstaller du Policy CSP. Les modèles plus anciens n'en contiennent pas certains : utilisez donc le plus récent. Sur les appareils où les utilisateurs standard ne doivent installer aucun logiciel, App Control ou AppLocker est le véritable contrôle ; la stratégie winget ne fait que restreindre un chemin parmi d'autres.

Étape 6 : retirer ce que vous ne pouvez pas corriger

Chaque application retirée, c'est un flux de mises à jour de moins. Une fois l'inventaire en place, triez-le par propriétaire et par dernière utilisation, et remettez en question tout ce qui n'a pas les deux :

• Versions non prises en charge : les logiciels arrivés en fin de vie chez leur éditeur (anciens builds Java 8 sans contrat de support, anciennes versions d'Adobe Reader, Python 2, plug-ins abandonnés) ne reçoivent plus aucun correctif. Remplacez-les ou désinstallez-les.
• Doublons : trois lecteurs PDF ou deux outils d'archivage sur le même appareil triplent la surface d'attaque sans aucun bénéfice. Standardisez sur un outil par fonction.
• Les outils d'accès à distance que l'IT n'a pas installés (AnyDesk, TeamViewer et similaires) posent à la fois un problème de correctifs et constituent une méthode de persistance courante chez les attaquants. Supprimez-les et bloquez-les par contrôle des applications.
• Les extensions de navigateur et environnements d'exécution fournis avec d'anciennes applications métier. Demandez à l'éditeur une version prise en charge, et isolez l'application s'il n'en existe pas.

Désinstallez avec le programme de désinstallation silencieuse de l'éditeur ou winget uninstall --id <id> --silent, et consignez chaque retrait. Le retrait est aussi la réponse pour les logiciels dépourvus de tout chemin de mise à jour silencieuse.

Vérifier

Relancez l'inventaire et comparez les versions avec la version actuelle de l'éditeur. Sur un appareil :

winget upgrade --include-unknown           # ne doit rien lister de votre ensemble approuvé

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; Id=1033,11707} -MaxEvents 20 |
  Format-Table TimeCreated, Id, Message -Wrap

Les installations MSI journalisent l'événement 11707 (installation terminée avec succès) et 1033 (produit installé, avec son statut) dans le journal Application, source MsiInstaller. Les journaux propres à winget se trouvent sous %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir pour le compte qui l'a exécuté (pour SYSTEM, sous le dossier systemprofile).

À l'échelle du parc, suivez le pourcentage d'appareils sur la version actuelle de chaque application de niveau 1, ainsi que la plus ancienne version encore présente. C'est cette plus ancienne version qu'un attaquant trouvera.

Ce qui casse

• Les mises à jour qui nécessitent un redémarrage de l'application. Les navigateurs téléchargent mais n'appliquent la mise à jour qu'à la relance ; sans notifications de relance, des appareils « à jour » exécutent l'ancien binaire pendant des semaines.
• Les sauts de version majeure. Java, les éditeurs PDF et les plug-ins métier peuvent casser lors d'une version majeure. Figez-les et testez.
• Les installations par utilisateur et par machine côte à côte. Une mise à jour à l'échelle de la machine laisse intacte une copie par utilisateur plus ancienne, et c'est celle-là que l'utilisateur continue de lancer.
• winget en SYSTEM ne peut pas atteindre les paquets de la source Microsoft Store et échoue sur certains programmes d'installation par utilisateur. Détectez-les et traitez-les séparément.

Liste de contrôle

• Inventaire logiciel couvrant les installations par machine et par utilisateur
• Applications de niveau 1 identifiées, avec des objectifs de correction en jours
• Mise à jour automatique de l'éditeur activée et notifications de relance imposées pour les navigateurs
• .NET et les autres produits Microsoft reçoivent leurs mises à jour via Microsoft Update
• winget (ou un outil de correctifs) met à jour une liste approuvée en SYSTEM
• Stratégies App Installer : pas de contournement du hachage, pas de manifestes locaux, sources approuvées uniquement
• Logiciels sans propriétaire et en fin de vie retirés
• Rapport de la plus ancienne version par application de niveau 1 revu chaque mois

Les correctifs des applications tierces comblent le plus grand manque laissé par Windows Update. Pour le volet Microsoft du processus, voir stratégies Windows Update et le reste du domaine correctifs et mises à jour.