PowerShell 7.6.6 : ce qui change dans la dernière mise à jour LTS

Le 8 septembre 2026, l’équipe PowerShell a livré trois mises à jour de maintenance le même jour : 7.6.6, 7.5.11 et 7.4.20. Rien d’exceptionnel en soi — ce sont des « patch releases », pas des montées de version majeures. Mais la 7.6.6 embarque un changement qui casse silencieusement certains scripts, et un réglage de sécurité qui mérite qu’on s’y attarde si tu geres des postes sous Windows Defender Application Control. Voici ce qui change concrètement, et ce qu’il faut vérifier avant de déployer.

Ce qui a changé dans PowerShell 7.6.6

La version tourne sur .NET 10.0.12. Trois modules embarqués ont été mis à jour :

• Microsoft.PowerShell.PSResourceGet passe en v1.2.0
• PSReadLine passe en v2.4.5
• Microsoft.PowerShell.ThreadJob passe en v2.2.0

Tu peux vérifier ta version installée avec :

$PSVersionTable.PSVersion
Get-Module -ListAvailable Microsoft.PowerShell.ThreadJob, PSReadLine, Microsoft.PowerShell.PSResourceGet

Le piège ThreadJob : vérifie tes scripts avant de monter en version

C’est le point qui va en surprendre plus d’un. Le module Microsoft.PowerShell.ThreadJob remplace désormais l’ancien module ThreadJob. La cmdlet Start-ThreadJob continue de fonctionner normalement en usage courant — ce n’est pas elle le problème. Le piège, c’est si un de tes scripts appelle la cmdlet par son nom pleinement qualifié avec l’ancien module :

# Ancien appel qualifié — ne résout plus rien après la mise à jour
ThreadJob\Start-ThreadJob -ScriptBlock { Get-Process }

# Appel qualifié correct depuis 7.6.6
Microsoft.PowerShell.ThreadJob\Start-ThreadJob -ScriptBlock { Get-Process }

Si tu ne fais jamais d’appel qualifié par module dans tes scripts (la grande majorité des usages), tu n’as rien à changer. Mais si une partie de ton code d’automatisation — modules internes, scripts de déploiement hérités — référence explicitement ThreadJob\Start-ThreadJob, fais un grep -r "ThreadJob\\\\" sur ton dépôt de scripts avant de pousser la mise à jour en production. C’est le genre de breaking change qui ne remonte qu’en prod, trois semaines après le déploiement, quand personne ne se souvient plus avoir mis à jour PowerShell.

Un nouveau réglage WLDP pour les environnements WDAC

Si tu administres des postes sous Windows Defender Application Control, la 7.6.6 ajoute la prise en charge du paramètre EnableFileOnlyEntry dans la Windows Lockdown Policy (WLDP). Ce réglage fait suite à un correctif livré dans la version précédente (7.6.5, 14 août 2026) qui corrigeait un comportement incohérent du dot-sourcing (pwsh -File) pour les fonctions avancées signées sous WDAC. Autre ajout lié : un repli (fallback) vers AppLocker après l’appel à WldpCanExecuteFile, pour les environnements où WDAC n’est pas la seule couche de contrôle d’exécution en place.

Si WDAC n’est pas ton quotidien, tu peux ignorer ce point sans arrière-pensée — il ne change rien au comportement par défaut.

Autres changements à noter

Trois correctifs plus discrets, mais qui valent d’être connus si tu tombes dessus en debuggant :

• WildcardPattern.Escape échappe désormais correctement les accents graves isolés (un bug qui affectait les chemins ou motifs contenant un seul backtick)
• Le paramètre -ChildPath de Join-Path accepte maintenant un tableau de chaînes (string[]) plutôt qu’une seule chaîne — rétrocompatible pour un usage simple, mais à connaître si tu scriptes la construction de chemins dynamiquement
• Les espaces en fin de nom de source d’événement sont désormais supprimés automatiquement (évite des entrées de journal d’événements mal formées)

Pourquoi trois versions sorties le même jour ?

PowerShell maintient plusieurs branches en parallèle, chacune alignée sur un cycle de support .NET différent : 7.4 est une branche LTS (Long Term Support) construite sur .NET 8, 7.5 une branche STS (Standard Term Support, cycle de support plus court) sur .NET 9, et 7.6 — la branche courante — vient de basculer sur .NET 10. Microsoft livre les correctifs de sécurité et de maintenance sur les trois branches actives simultanément plutôt que de forcer une montée de version majeure à chaque patch. Concrètement, si tu es encore en 7.4 pour des raisons de stabilité en production, tu bénéficies des mêmes correctifs de fond sans devoir sauter sur 7.6.

FAQ

Dois-je mettre à jour immédiatement vers 7.6.6 ?

Si tu es déjà sur la branche 7.6, oui, sans urgence particulière — c’est un patch release, pas une version majeure avec son lot d’incertitudes. Vérifie juste l’usage de ThreadJob\Start-ThreadJob qualifié dans ton code avant de déployer à grande échelle.

Je suis encore en PowerShell 7.4, dois-je migrer vers 7.6 ?

Pas forcément. 7.4 reste une branche LTS activement maintenue (7.4.20 est sortie le même jour). Migre vers 7.6 si tu as besoin des nouveautés spécifiques à cette branche, pas uniquement pour suivre le numéro de version le plus récent.

Le changement ThreadJob va-t-il casser Invoke-Command ou les jobs en arrière-plan classiques ?

Non. Ce changement concerne uniquement le module ThreadJob et la cmdlet Start-ThreadJob utilisée en mode qualifié. Les jobs PowerShell standards (Start-Job, Invoke-Command -AsJob) ne sont pas concernés.

En résumé

Une mise à jour de maintenance sans drame, à condition de vérifier un seul point avant de la déployer en masse : les appels qualifiés à ThreadJob\Start-ThreadJob dans ton code existant. Le reste — modules à jour, réglage WDAC pour qui en a besoin, corrections mineures — s’installe sans accroc. Si ton parc utilise encore PSGallery par défaut pour ses modules, ça vaut aussi le coup de relire notre article sur le basculement vers Microsoft Artifact Registry, qui touche directement PSResourceGet mis à jour dans cette même release.

Pour la vue d’ensemble des évolutions attendues sur PowerShell, OpenSSH et DSC v3 cette année, on avait détaillé la feuille de route 2026 de Microsoft — la 7.6.6 s’inscrit dans cette continuité, pas comme une rupture.

Source officielle pour le détail complet des correctifs : What’s New in PowerShell 7.6 (Microsoft Learn) et le changelog complet sur le dépôt GitHub PowerShell/PowerShell.