PowerShell 7.7 est sorti : 7.4 et 7.5 ne sont plus supportées, quelle version choisir

Microsoft a publié le 10 novembre 2026 PowerShell 7.7, une version stable bâtie sur .NET 11, le jour même où les branches 7.4 et 7.5 sont sorties du support : pour qui maintient des scripts d’administration ou des pipelines, c’est le moment de choisir sa cible.

Que contient PowerShell 7.7 ? #

L’annonce officielle de l’équipe PowerShell, signée Jason Helmick, présente une version tournée vers la sécurité, de nouvelles commandes, une gestion plus prévisible des paramètres de type switch et une série de corrections de fiabilité dans le moteur, le remoting et le shell interactif.

Côté nouveautés visibles, une cmdlet New-TemporaryDirectory crée un dossier au nom unique dans le répertoire temporaire du système et accepte un préfixe. Join-Path gagne un paramètre -Extension, et les cmdlets Format-Table, Format-List et Format-Custom acceptent désormais -ExcludeProperty.

À lire Fin de support de .NET 8 et .NET 9 : pourquoi viser .NET 10 ou .NET 11 dès maintenant

Les modules PSResourceGet et Archive sont mis à jour. Get-AuthenticodeSignature renvoie maintenant une propriété SubjectAlternativeName, utile pour contrôler les certificats de signature de code.

Quels changements peuvent casser des scripts existants ? #

Le point le plus discret est aussi le plus piégeux : New-Guid génère désormais des UUID de version 7, ordonnés dans le temps, au lieu de la version 4 entièrement aléatoire. Un script qui comptait sur le caractère imprévisible de ces identifiants doit passer par [guid]::NewGuid(), comme le recommande Microsoft.

Autres ruptures listées par l’éditeur : les cmdlets de formatage refusent un -Property nul ou vide, les validations d’arguments vides lèvent une System.ArgumentException, et Export-Csv n’accepte plus -Append combiné à -NoHeader.

Le paramètre -NoTypeInformation des cmdlets CSV affiche désormais un avertissement de dépréciation et n’a plus d’effet. Enfin, Test-Json ne résout plus les références de schéma externes sans le nouveau paramètre -FetchExternalReference.

À lire VS Code 1.145 : agents distants, revue croisée entre agents et automatisations cron

Pourquoi la gestion des switch change-t-elle ? #

Plusieurs cmdlets ignoraient jusqu’ici une valeur explicite comme -Switch:$false. PowerShell 7.7 la respecte pour Split-Path, New-PSSession, Test-Connection, Get-Random, New-Guid ou les opérateurs de Where-Object.

C’est une correction de logique, mais elle peut modifier le résultat d’un script qui passait -EQ:$false à Where-Object en croyant obtenir le comportement par défaut. Un passage en revue des appels générés dynamiquement, via splatting notamment, s’impose avant migration.

Quel renforcement de la sécurité ? #

Le mode de langage contraint (Constrained Language Mode) interdit désormais l’affectation de propriétés sur des objets hors du cœur, y compris via la méthode ForEach(). Le remoting valide plus strictement arguments et trames, et les protections du remoting implicite s’appliquent aussi aux alias résolus.

Sous Unix, le dossier personnel temporaire de secours reçoit des permissions plus restrictives. La télémétrie respecte enfin le réglage de diagnostic de Windows, et la notification de mise à jour au démarrage disparaît.

À lire Discord abandonne Electron pour Rust : ce que la réécriture dit aux développeurs

Faut-il migrer maintenant, et vers quelle version ? #

La page de cycle de vie de Microsoft Learn indique que PowerShell 7.4 (LTS) et 7.5 ont atteint leur fin de support le 10 novembre 2026. Plus aucun correctif de sécurité ne sera publié pour ces branches : les postes et serveurs qui les utilisent encore sont à mettre à jour en priorité.

Pour la production, la cible raisonnable reste PowerShell 7.6, la version LTS bâtie sur .NET 10 et supportée jusqu’au 14 novembre 2028 selon la même page. PowerShell 7.7, version Standard Term Support, convient mieux aux équipes qui veulent les nouveautés et acceptent un rythme de mise à jour plus soutenu.

Microsoft rappelle que le support de PowerShell suit la politique de .NET pour la version sur laquelle chaque branche est construite, et que seule la dernière mise à jour d’une branche est supportée.

Que change la fin de l’installateur MSI ? #

Dès avril, l’équipe avait annoncé dans un billet consacré à l’abandon du MSI que les nouvelles versions ne seraient plus livrées dans ce format, PowerShell 7.7 compris. Le paquet MSIX devient la méthode d’installation principale sous Windows.

À lire C++26 recalé au vote ISO : une première dans l’histoire du langage

Microsoft y reconnaît que MSIX ne couvre pas encore tous les usages permis par le MSI, comme le remoting ou l’exécution par des services système tels que le Planificateur de tâches. Dans les commentaires de l’annonce de la 7.7, l’éditeur précise que l’installation MSIX se fait dans le profil utilisateur et n’est pas prise en charge sur Windows Server Core.

Pour ces scénarios, Microsoft renvoie vers le MSI de PowerShell 7.6, qui continue d’être fourni pendant toute la durée de support de cette LTS. C’est un argument de plus pour garder 7.6 sur les serveurs et réserver 7.7 aux postes de développement.

Questions fréquentes #

PowerShell 7.7 remplace-t-il Windows PowerShell 5.1 ?

Non. Windows PowerShell 5.1 est un composant de Windows, soumis au cycle de vie du système. PowerShell 7.7 s’installe à côté et fonctionne aussi sous Linux et macOS.

Mes scripts 7.4 fonctionneront-ils sous 7.7 ?

Dans la plupart des cas, oui, mais il faut vérifier les usages de New-Guid, des cmdlets CSV, de Test-Json avec des schémas externes et des switch passés explicitement à false.

À lire Node.js 27 alpha : une seule version majeure par an, et toutes deviennent LTS

Comment connaître la version de .NET utilisée par mon PowerShell ?

Microsoft Learn indique la commande [System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription, qui affiche la version complète de .NET embarquée.