PowerShell 7.6 LTS : ce qui change et comment migrer sereinement

PowerShell 7.6 est sorti en version LTS (Long Term Support) le 18 mars 2026, construit sur .NET 10. Si tu gères des scripts de production, c’est la version vers laquelle tu vas devoir migrer tôt ou tard : les versions non-LTS ont un cycle de support beaucoup plus court, et Microsoft pousse clairement PowerShell 7.6 comme socle stable pour les prochaines années. On fait le tour de ce qui change, de ce qui casse, et de la marche à suivre pour migrer sans mauvaise surprise.

Pourquoi la version LTS compte pour toi

Une version LTS de PowerShell bénéficie d’un support étendu (généralement trois ans), contrairement aux versions intermédiaires qui ne sont maintenues que quelques mois. Si tu déploies PowerShell sur des serveurs de production, des runners CI/CD ou des postes de travail à grande échelle, c’est la version que tu dois cibler : moins de montées de version à gérer, plus de stabilité, et des correctifs de sécurité garantis sur la durée.

PowerShell 7.6 tourne sur le runtime .NET 10, lui-même en LTS. Ça t’évite le decalage habituel où le runtime .NET atteint sa fin de support avant la version de PowerShell qui s’appuie dessus.

Les nouveautés qui changent vraiment ton quotidien

Fonctionnalités expérimentales devenues stables

Quatre fonctionnalités passent enfin du statut expérimental au statut stable, ce qui veut dire que tu peux les utiliser en production sans activer de flag :

• PSFeedbackProvider — le système de suggestions contextuelles en cas d’erreur (par exemple, proposer une commande proche quand tu tapes une commande introuvable)
• PSNativeWindowsTildeExpansion — l’expansion du ~ vers ton répertoire utilisateur, y compris pour les commandes natives Windows
• PSRedirectToVariable — la redirection de flux (comme 2> pour stderr) directement vers une variable
• PSSubsystemPluginModel — le modèle de plugin pour les sous-systèmes (complétion, prédiction, etc.)

Deux nouvelles fonctionnalités expérimentales à surveiller

Si tu manipules beaucoup de JSON ou si tu es côté DSC (Desired State Configuration), deux nouveautés expérimentales méritent un test :

• PSSerializeJSONLongEnumAsNumber : ConvertTo-Json traite désormais les grandes valeurs d’énumération comme des nombres plutôt que comme des chaînes, ce qui évite des conversions bancales côté consommateur de l’API
• PSProfileDSCResource : une nouvelle ressource DSC v3 dédiée à la gestion des profils PowerShell, utile si tu standardises les profils sur un parc de machines via DSC

Confort au quotidien : complétion, presse-papiers, process

Une bonne partie du travail sur cette version porte sur la complétion (tab-completion) : complétion par nom court de module, meilleure inférence de type sur les variables, gestion des guillemets dans les chemins, complétion des variables assignées dans une boucle Do… Ce sont des dizaines de petits correctifs qui, cumulés, rendent la console sensiblement plus agréable à utiliser.

Côté cmdlets, retiens surtout :

• Get-Clipboard gagne un paramètre -Delimiter pour contrôler comment les lignes du presse-papiers sont séparées
• Get-Command gagne un paramètre -ExcludeModule pour filtrer les résultats
• Register-ArgumentCompleter -NativeFallback permet d’enregistrer un compléteur générique pour toutes les commandes natives qui n’ont pas de complétion dédiée
• Start-Process -Wait a un polling plus efficace, donc moins de charge CPU inutile quand tu attends la fin d’un process
• Deux nouveaux alias intrinsèques, PSForEach() et PSWhere(), en complément de Foreach() et Where()

Les changements cassants à vérifier avant de migrer

Trois points de vigilance avant de basculer tes scripts de production :

• Module ThreadJob renommé : le module ThreadJob est remplacé par Microsoft.PowerShell.ThreadJob. La cmdlet Start-ThreadJob ne change pas de comportement, mais si tes scripts référencent le nom qualifié du module (ThreadJob\Start-ThreadJob), il faut le mettre à jour en Microsoft.PowerShell.ThreadJob\Start-ThreadJob.
• Join-Path -ChildPath accepte désormais un tableau : le type du paramètre passe à string[]. Si tu as du code qui dépend strictement du typage string unique (réflexion, validation de paramètre custom), teste ce chemin.
• WildcardPattern.Escape() corrige l’échappement des backticks isolés : si tu construis des patterns wildcard à partir de chaînes contenant des backticks, le résultat de l’échappement change légèrement — revérifie les regex/patterns générés dynamiquement.

Ce sont des changements ciblés, pas une refonte : dans la grande majorité des cas, un script qui tourne sous PowerShell 7.4 ou 7.5 tournera tel quel sous 7.6. Mais « dans la grande majorité des cas » ne remplace pas un passage en environnement de test.

Comment migrer sans mauvaise surprise

1. Installe PowerShell 7.6 en parallèle de ta version actuelle plutôt que de l’écraser — PowerShell 7.x supporte les installations côte à côte via MSI (Windows), Homebrew (macOS) ou les paquets natifs (Linux).
2. Fais tourner ta suite de tests / tes scripts critiques sous 7.6 dans un environnement non-prod, en particulier tout ce qui touche à ThreadJob, Join-Path ou à la génération de patterns wildcard.
3. Vérifie tes modules tiers (PSResourceGet, PSReadLine, etc.) : PowerShell 7.6 embarque des versions mises à jour de ces modules, donc si tu épingles des versions précises ailleurs dans ton pipeline, harmonise.
4. Planifie le déploiement en LTS une fois validé : c’est la version que tu veux garder plusieurs années, donc autant prendre le temps de bien la valider une fois, plutôt que de la pousser en urgence.

FAQ

PowerShell 7.6 remplace-t-il Windows PowerShell 5.1 ?

Non, et ce n’est pas prévu à court terme. Windows PowerShell 5.1 reste présent nativement dans Windows et certains modules legacy (notamment certains modules serveur) n’existent encore que pour cette version. PowerShell 7.6 (PowerShell Core) cohabite avec 5.1 sur la même machine.

Dois-je migrer immédiatement si je suis sur PowerShell 7.4 ?

Pas dans l’urgence, mais ne tarde pas trop : la fenêtre de support de PowerShell 7.4 (LTS précédente) se réduit avec la disponibilité de 7.6. Planifie la migration dans les prochains mois plutôt que d’attendre la fin de support.

Où trouver la liste complète des changements ?

Le changelog exhaustif est publié sur le dépôt GitHub officiel de PowerShell, avec chaque pull request référencée individuellement — utile si tu veux vérifier l’impact d’un changement précis sur ton code.

Pour aller plus loin

Si tu es encore en train de construire tes bases d’automatisation PowerShell (modules, gestion des credentials, scripts récurrents), notre guide complet sur l’automatisation IT avec PowerShell couvre les fondamentaux avant même de te poser la question de la version.

Migrer vers une version LTS, ça se prépare : teste tes scripts critiques dès maintenant dans un environnement isolé, note les points de friction, et programme la bascule en production sur un créneau calme plutôt qu’en urgence. Ton futur toi t’en remerciera.

Sources

• Annonce officielle PowerShell 7.6 (LTS) — PowerShell Team Blog
• What’s New in PowerShell 7.6 — Microsoft Learn
• Release notes v7.6.0 — GitHub PowerShell/PowerShell