Windows PowerShell 5.1 et PowerShell 7 : quelles différences ? — Guide pratique de migration des scripts internes

« Si j’installe PowerShell 7 sur le serveur, est-ce que mes scripts actuels vont casser ? » « Est-ce vraiment un problème de rester sur 5.1 ? » — nous recevons de plus en plus souvent ce type de questions de la part de clients qui gèrent des scripts internes en exploitation. Le PowerShell installé d’office avec Windows (5.1) et PowerShell 7, qu’il faut installer séparément. Comme ils portent le même nom, on croit facilement qu’une « mise à jour de version » remplace l’un par l’autre, mais en réalité, ce sont deux produits distincts qui coexistent.

Adopter 7 sans bien comprendre cette relation mène tôt ou tard à l’un de ces deux écueils : soit « je l’ai installé, mais rien n’a changé (les tâches continuent de tourner sous 5.1) », soit, à l’inverse, « après la migration, les échanges de fichiers en japonais sont devenus illisibles ». Ce second cas est un incident propre à l’environnement japonais, dont la cause tient à la différence d’encodage de caractères par défaut.

Cet article s’adresse aux responsables informatiques et aux équipes d’exploitation qui gèrent des scripts internes : il organise, à partir du mécanisme lui-même, la relation et les différences entre 5.1 et 7, et détaille la procédure concrète de migration, accompagnée de tableaux de décision.

1. La conclusion, d’abord

• Windows PowerShell 5.1 et PowerShell 7 sont des produits distincts qui coexistent en side-by-side. 5.1 est livré avec Windows et construit sur .NET Framework ; 7 s’installe séparément et est construit sur .NET. Installer 7 ne fait pas disparaître 5.1.¹²
• Microsoft n’ajoute plus de nouvelles fonctionnalités à 5.1. Le support de 5.1 est lié au cycle de vie de Windows lui-même, et l’axe principal du développement est désormais 7. Tout nouveau script devrait être écrit en prenant 7 comme référence.¹³
• Les exécutables sont différents. 5.1, c’est powershell.exe ; 7, c’est pwsh.exe. Tant que la commande de lancement dans le Planificateur de tâches ou ailleurs n’est pas réécrite, les mécanismes existants continuent de fonctionner sous 5.1.⁴⁵
• L’encodage de caractères par défaut est différent. Sous 5.1, il varie selon la commande (Out-File utilise UTF-16LE, Get-Content utilise l’ANSI, etc.), tandis que 7 utilise uniformément l’UTF-8 sans BOM. C’est le premier piège rencontré lors d’une migration en environnement japonais.⁶
• Pour un module qui ne fonctionne pas sous 7, il existe la fonctionnalité de compatibilité Windows. Import-Module -UseWindowsPowerShell le charge dans un processus 5.1 en arrière-plan, utilisable via le remoting, mais ce qui revient est un objet sérialisé dont on ne peut pas appeler les méthodes.⁷
• #Requires -Version et $PSVersionTable permettent d’inscrire directement dans le code « sous quelle version ce script doit s’exécuter ». Cela permet d’arrêter avant l’exécution un incident silencieux causé par l’exécution sous une version inattendue.⁸⁹
• La migration se déroule en étapes : inventaire → test d’exécution sous 7 → mise à jour de la commande de lancement. L’installation de 7 elle-même se fait via MSI ou winget, et il faut aussi décider dès le départ de la méthode de distribution des mises à jour (via Microsoft Update, par exemple).⁵²⁴

2. Quelle est la relation entre 5.1 et 7 — coexistence, et non remplacement

Commençons par saisir la vue d’ensemble sous forme de tableau.

7 ne remplace pas 5.1 : il s’installe dans un répertoire distinct et fonctionne en side-by-side. L’emplacement des modules (PSModulePath), le profil et le journal des événements sont tous gérés séparément, mais le PSModulePath côté 7 inclut aussi les chemins de modules de 5.1, ce qui permet à 7 de charger la plupart des modules existants.⁵²

« Dans lequel des deux suis-je ? » se vérifie à tout moment avec ces deux lignes. $PSVersionTable est une variable automatique qui contient les informations de version de PowerShell.⁹

# Vérifier dans lequel des deux PowerShell on se trouve
$PSVersionTable.PSVersion   # 5.1.x = Windows PowerShell, 7.x = PowerShell 7
$PSVersionTable.PSEdition   # Desktop = Windows PowerShell / Core = PowerShell 7

Le positionnement officiel est clair. Windows PowerShell est la version livrée avec Windows ; Microsoft ne la met plus à jour avec de nouvelles fonctionnalités, et son support est lié à la version de Windows utilisée. PowerShell (la branche 7), de son côté, est construit sur un .NET plus récent, et chaque version reçoit une durée de support alignée sur la politique de support du .NET sous-jacent.¹³ 5.1 ne va pas disparaître demain, mais la conclusion pratique est que la référence pour « ce que l’on écrit désormais » et « ce que l’on utilisera longtemps » doit être 7.

3. Le premier piège — la différence d’encodage par défaut et les caractères corrompus

Le problème de migration le plus fréquent en environnement japonais, ce sont les caractères corrompus. La cause est limpide : l’encodage de caractères par défaut diffère entre les deux.⁶

# Même ligne, mais la séquence d'octets du fichier produit diffère entre 5.1 et 7
'こんにちは' | Out-File -FilePath C:\temp\hello.txt
# Exécuté sous 5.1 -> fichier en UTF-16LE (avec BOM)
# Exécuté sous 7   -> fichier en UTF-8 sans BOM

Cela a deux implications concrètes.

Premièrement, les échanges de fichiers qui supposent du Shift_JIS peuvent produire des caractères corrompus, en lecture comme en écriture, dès l’instant où l’on bascule sur 7. C’est parce que Get-Content sous 5.1 lit un fichier sans BOM comme de l’ANSI (Shift_JIS en environnement japonais), alors que 7 le lit comme de l’UTF-8. La parade consiste à préciser explicitement -Encoding pour toutes les entrées/sorties de fichiers. Sous 7, on peut le préciser par numéro de page de codes (-Encoding 932) ou par nom enregistré, et à partir de 7.4, la valeur ansi est également disponible.⁶ Les façons concrètes de l’écrire pour le traitement CSV sont détaillées dans « Automatiser les traitements Excel et CSV avec PowerShell », publié le même jour.

Deuxièmement, le format d’enregistrement du fichier de script lui-même. Si un script contenant des commentaires en japonais est enregistré en UTF-8 sans BOM, 5.1 l’interprète à tort comme de l’ANSI, ce qui produit des caractères corrompus ou des erreurs de syntaxe. Conformément à la recommandation de la documentation officielle, enregistrer en UTF-8 avec BOM tout script contenant des caractères non-ASCII garantit une interprétation correcte, aussi bien sous 5.1 que sous 7.⁶

4. Compatibilité — ce qui ne fonctionne pas sous 7, et les capacités réelles de la fonctionnalité de compatibilité Windows

4.1. Qu’est-ce qui cesse de fonctionner ?

7 peut charger tel quel un grand nombre de modules existants⁵, mais certains ne passent pas. Voici les exemples représentatifs cités officiellement.

• Modules qui ne sont plus inclus : PSWorkflow/PSWorkflowUtility (workflow), PSScheduledJob, les modules destinés à l’ISE, Microsoft.PowerShell.LocalAccounts, etc. ne sont pas inclus dans 7.⁴
• Les snap-ins : cet ancien format d’extension, antérieur aux modules, n’est pas pris en charge sous 7.⁴
• Le code fortement dépendant de .NET Framework : comme le .NET sous-jacent de 7 est différent, un script qui appelle directement des méthodes .NET peut voir son comportement changer.⁵⁴
• Des changements de comportement subtils : Export-Csv n’écrit plus la ligne #TYPE par défaut, Group-Object retourne désormais des groupes triés, et d’autres changements de ce genre affectent les scripts qui dépendent de la sortie exacte.⁴

Il existe aussi une incompatibilité dans l’autre sens. Un script utilisant une syntaxe ou une fonctionnalité ajoutée dans 7, comme l’opérateur ternaire ou ForEach-Object -Parallel, ne fonctionne pas sous 5.1.⁵ Il faut donc décider, script par script, si l’on « écrit pour que ça fonctionne dans les deux cas » ou si l’on « précise explicitement sous quelle version il doit s’exécuter ».

L’état de compatibilité des modules Microsoft peut être vérifié sur la page officielle de compatibilité des modules.¹⁰

Il faut aussi décider, en même temps, vers quoi migrer l’environnement d’édition (ISE). Windows PowerShell ISE n’est pas prévu pour être supprimé de Windows, et les correctifs de sécurité et de priorité élevée continuent d’être fournis, mais le développement de nouvelles fonctionnalités y est terminé, et il ne prend en charge que PowerShell 5.1 et les versions antérieures.¹¹ Autrement dit, un usage où l’on écrirait et exécuterait dans l’ISE des scripts destinés à tourner sous 7 ne tient pas debout. La destination de migration recommandée officiellement est Visual Studio Code avec l’extension PowerShell : une fois l’extension installée, on peut basculer la version de PowerShell utilisée dans la console intégrée (des chemins supplémentaires peuvent aussi être ajoutés dans les paramètres). Un guide « reproduire dans VS Code les sensations d’utilisation de l’ISE » est également disponible pour les habitués de l’ISE, ce qui en fait un bon point de départ pour accompagner la transition.¹¹ Sur le terrain des services informatiques, les utilisateurs de l’ISE sont nombreux : présentez donc le plan de migration des scripts et le changement d’environnement d’édition en même temps.

4.2. Le fonctionnement et les limites de la fonctionnalité de compatibilité Windows (-UseWindowsPowerShell)

7 dispose d’une fonctionnalité de compatibilité Windows destinée aux modules qui ne fonctionnent que sous 5.1.

# Charger, via la fonctionnalité de compatibilité, un module non pris en charge par 7 (exemple de la documentation officielle)
Import-Module -Name ScheduledTasks -UseWindowsPowerShell

Le mécanisme est une application du remoting. Un processus Windows PowerShell 5.1 démarre en arrière-plan, le module est chargé dans une session appelée WinPSCompatSession, et un module proxy, généré par du remoting implicite, est importé côté 7. Les modules réservés à 5.1 situés sous System32 sont eux aussi chargés implicitement par ce mécanisme, que ce soit par désignation explicite du nom ou par détection automatique de commande.⁷

Le schéma ci-dessous rend claire la relation entre les deux processus.

flowchart LR
    subgraph PS7["pwsh.exe — le processus PowerShell 7"]
        SCRIPT["Le script lui-même"]
        PROXY["Module proxy<br/>Un point d'entrée généré par le remoting implicite.<br/>Ce n'est pas le module réel"]
    end
    subgraph PS51["powershell.exe — le processus 5.1 lancé en arrière-plan"]
        SESSION["WinPSCompatSession<br/>Tous les modules chargés via la fonctionnalité de compatibilité<br/>partagent un seul et même runspace"]
        MOD["Le module réel, qui ne fonctionne que sous 5.1"]
    end
    SCRIPT --> PROXY
    PROXY -->|"Transmet l'appel de la commande"| SESSION
    SESSION --> MOD
    MOD -->|"Résultat"| SESSION
    SESSION -.->|"Seule une copie de la valeur sérialisée revient<br/>Impossible d'appeler une méthode"| SCRIPT

Comme le montre le schéma, ce qui se trouve côté 7, ce n’est pas le module réel, mais seulement un point d’entrée. La réalité n’est pas « installer 7 fait tout fonctionner sous 7 », mais plutôt « 7 délègue à 5.1 et en reçoit une copie du résultat » ; toutes les limites décrites plus loin découlent de cette structure.

C’est pratique, mais l’utiliser sans en comprendre les limites conduit à des échecs silencieux. Voici les limites explicitement documentées.⁷

• Ce qui s’échange, ce sont des valeurs sérialisées, pas des objets bruts. On ne peut pas appeler les méthodes de l’objet retourné ; on ne reçoit qu’un instantané de ses propriétés.
• Cela ne fonctionne que sur un Windows local, et nécessite Windows PowerShell 5.1.
• Tous les modules chargés via la fonctionnalité de compatibilité partagent un seul runspace (un seul processus 5.1).
• Certains modules (comme PSScheduledJob) refusent d’être chargés par défaut.

Un traitement comme « appeler une méthode sur le résultat obtenu » ou « avoir besoin d’un objet brut au milieu du pipeline » ne fonctionne pas avec la fonctionnalité de compatibilité. Dans ce cas, il est possible d’exécuter le pipeline entier côté 5.1 et de ne récupérer que le résultat final⁷, mais dans la pratique, si cela devient compliqué, laisser cette partie du traitement tourner telle quelle sous 5.1 reste plus facile à maintenir.

5. Écrire de façon défensive — #Requires et la répartition par version

Pendant la période de migration, un état où « on ne sait pas sous quelle version le script va s’exécuter » finit toujours par apparaître. Le pire scénario étant qu’il tourne sous une version inattendue et casse en cours de route, il faut intégrer une protection côté script.

Écrire une directive #Requires fait rejeter le script avant même son exécution si les conditions ne sont pas remplies.⁸

#Requires -Version 7.0
# Ce script est réservé à 7 (il utilise ForEach-Object -Parallel, entre autres).
# S'il est lancé avec powershell.exe (5.1), rien au-delà de cette ligne ne s'exécute

À l’inverse, pour un script réservé à 5.1, on écrit #Requires -PSEdition Desktop. Desktop est le nom d’édition de la branche 5.1, Core celui de la branche 7.⁸⁹

Pour un script conçu pour fonctionner dans les deux cas, mais dont on veut modifier le comportement à certains endroits seulement, on effectue une répartition à l’exécution avec $PSVersionTable.⁹

# Dans un script compatible 5.1 et 7, ne diviser que le traitement qui diffère selon la version
if ($PSVersionTable.PSVersion.Major -ge 6) {
    $enc = 932            # 7 : on peut préciser Shift_JIS par numéro de page de codes
} else {
    $enc = 'Default'      # 5.1 : Default = la page de codes ANSI du système
}
Get-Content -LiteralPath $path -Encoding $enc

L’important est d’ajouter cette précision « au moment de l’inventaire », et non « une fois la migration terminée ». Une seule ligne #Requires suffit à ce que n’importe qui puisse voir immédiatement à quel monde appartient ce script.

6. Comment mener la migration — de l’inventaire à la mise à jour du Planificateur de tâches

La migration concrète se déroule dans l’ordre suivant. Un basculement en une seule fois est source d’incidents, la migration progressive est donc le principe à suivre.

Étape 1 : l’inventaire. Recensez, à partir des emplacements de scripts et du Planificateur de tâches, les fichiers .ps1 en activité et leurs commandes de lancement.

# Recenser, dans le Planificateur de tâches, les tâches qui lancent PowerShell
Get-ScheduledTask | ForEach-Object {
    foreach ($action in $_.Actions) {
        # On regarde à la fois l'exécutable et les arguments pour capter aussi les lancements indirects comme cmd.exe /c powershell ...
        if ("$($action.Execute) $($action.Arguments)" -match 'powershell|pwsh') {
            [pscustomobject]@{
                TaskPath  = $_.TaskPath        # Le nom de tâche n'est unique qu'à l'intérieur d'un dossier, on conserve donc aussi le chemin
                TaskName  = $_.TaskName
                Execute   = $action.Execute    # powershell.exe ou pwsh.exe
                Arguments = $action.Arguments
            }
        }
    }
} | Export-Csv -Path .\ps-tasks.csv -NoTypeInformation -Encoding UTF8

Le fichier ps-tasks.csv obtenu comporte 4 colonnes. Voici la signification des colonnes et des exemples de format (les valeurs sont des exemples de forme ; le contenu réel varie selon l’environnement).

Ce CSV sert à repérer trois choses. Les lignes où Execute vaut powershell.exe sont des tâches encore exécutées sous 5.1, donc à migrer. Les lignes où Execute vaut cmd.exe cachent un lancement de PowerShell à l’intérieur d’Arguments ; il faut donc ouvrir le contenu pour vérifier. Et les lignes où ni -File ni -Command n’apparaissent dans Arguments correspondent à des appels passés sous forme positionnelle, dont l’interprétation change au moment du remplacement par pwsh à l’étape 5 (la raison est expliquée à l’étape 5). Il suffit de classer ces trois cas pour déterminer le périmètre du plan de migration.

Étape 2 : l’installation de 7. Installez-le via le paquet MSI (adapté au déploiement par un outil de gestion) ou via winget.⁵²

Décidez de la version à installer et de la méthode selon les repères suivants.³²

# Installation via winget. Les mises à jour passent aussi par la même voie avec winget upgrade
winget install --id Microsoft.PowerShell --source winget

# Pour installer le paquet MSI (adapté aux serveurs et aux outils de gestion de déploiement)
winget install --id Microsoft.PowerShell --source winget --installer-type wix

winget lui-même a aussi ses propres préalables. Depuis le paquet winget 7.6.0, winget install --id Microsoft.PowerShell installe désormais un paquet MSIX par défaut ; si vous voulez le MSI, ajoutez donc --installer-type wix comme ci-dessus. Par ailleurs, winget n’est pas utilisable sous Windows Server 2022 et versions antérieures (il est inclus avec l’édition Desktop Experience de Windows Server 2025). Pour un déploiement sur un parc de serveurs, il est plus prudent de tout planifier en partant du MSI.²

Décidez aussi dès le départ de la manière de gérer les mises à jour. Le MSI à partir de la version 7.2 propose une option (activée par défaut) pour recevoir les mises à jour via Microsoft Update, ce qui permet de l’intégrer au flux habituel de mise à jour de WSUS ou d’un outil de gestion de configuration.⁴ Le pire scénario est de laisser traîner une installation sauvage, avec une vieille version de 7 qui ne bouge plus.

Étape 3 : le test d’exécution sous 7. Exécutez chaque script inventorié avec pwsh et vérifiez qu’il fonctionne, et que le fichier de sortie n’est pas corrompu. Comme 7 coexiste avec 5.1, l’avantage de la conception side-by-side est qu’on peut tester sans arrêter les tâches en production.² En cas d’erreur, isolez le problème de compatibilité (module, API .NET, changement de comportement) évoqué au chapitre 4.

Sans avoir défini au préalable ce que signifie « ça fonctionne », les tests ne se terminent jamais ; voici donc les critères de réussite sous forme de liste de contrôle.

• pwsh -NoProfile -File <script> s’exécute jusqu’au bout et $LASTEXITCODE se termine à 0
• Rien n’apparaît dans le flux d’erreurs (les avertissements attendus sont acceptés après vérification de leur contenu)
• Tous les modules dépendants se chargent sous 7 (Import-Module réussit ; vérifiez aussi qu’il ne bascule pas vers la fonctionnalité de compatibilité)
• Le contenu du fichier de sortie correspond à la version 5.1 (voir Compare-Object ci-dessous)
• L’encodage du fichier de sortie correspond à ce qu’attend le destinataire (chapitre 3 ; indispensable s’il existe un correspondant qui suppose du Shift_JIS)
• Pour les traitements de modification, vérifié avec -WhatIf que la cible est identique à ce qu’elle était sous 5.1
• Le temps d’exécution ne s’est pas allongé de façon anormale (cela peut ralentir si l’on passe par la fonctionnalité de compatibilité)

Pour rapprocher les sorties, la méthode la plus fiable est d’exécuter le même script sous 5.1 et sous 7, puis de comparer les différences.

# Exécuter le même script sous 5.1 et sous 7, puis comparer les fichiers de sortie
& "$Env:windir\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -File .\daily-report.ps1
Move-Item .\report.csv .\report-51.csv -Force
& "$Env:ProgramFiles\PowerShell\7\pwsh.exe" -NoProfile -File .\daily-report.ps1
Move-Item .\report.csv .\report-7.csv -Force

# Différence ligne par ligne. S'il y a une colonne qui change à chaque exécution (date/heure, etc.), exclure cette colonne avant de comparer
Compare-Object (Get-Content .\report-51.csv) (Get-Content .\report-7.csv)

# Vérifier même la correspondance octet par octet (une différence de BOM ou de fin de ligne apparaît ici)
(Get-FileHash .\report-51.csv).Hash -eq (Get-FileHash .\report-7.csv).Hash

Quand une différence apparaît, distinguez d’abord si « la valeur est différente » ou si « l’apparence est identique mais seule la séquence d’octets diffère ». Si Compare-Object ne signale aucune différence mais que Get-FileHash ne correspond pas, la cause est un écart d’encodage ou de fin de ligne (chapitre 3). Définissez la fin de la migration non pas comme « ça se termine sans exception sous 7 », mais comme « le même livrable est produit qu’avec 5.1 ».

Étape 4 : préciser sous quelle version le script doit s’exécuter. Ajoutez #Requires -Version 7.0 à ce qui a passé les tests, et #Requires -PSEdition Desktop à ce qui reste sous 5.1 (chapitre 5).

Étape 5 : la mise à jour de la commande de lancement. Réécrivez l’action dans le Planificateur de tâches. Oublier cette étape mène au scénario « on croyait avoir migré vers 7, mais ça continue de tourner sous 5.1 ».

# Avant modification (exécuté sous 5.1) :
#   powershell.exe -NoProfile -ExecutionPolicy RemoteSigned -File C:\scripts\daily-report.ps1
# Après modification (exécuté sous 7) :
#   "C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -File C:\scripts\daily-report.ps1

Notez que, pour pwsh.exe, le premier paramètre positionnel est passé de -Command à -File. Remplacer mécaniquement un appel équivalent à powershell.exe -Command "..." change donc l’interprétation ; précisez toujours explicitement -File ou -Command.⁴

Pour la gestion de la politique d’exécution et de la signature de scripts, consultez « Politique d’exécution PowerShell et signature de scripts », publié le même jour ; pour la décision de migrer depuis un fichier batch (.bat), consultez « Ce fichier bat, faut-il le migrer vers PowerShell ? ».

7. Bonnes pratiques (tableau de décision)

8. Conclusion

• 5.1 et 7 sont des produits distincts qui coexistent en side-by-side. Installer 7 ne casse pas les mécanismes existants, mais à l’inverse, rien n’est migré tant que la commande de lancement n’est pas changée.
• 5.1 est en mode statu quo : aucune nouvelle fonctionnalité, un support lié à Windows lui-même. 7 est l’axe principal du développement. Écrivez tout nouveau script en prenant 7 comme référence.
• Le plus grand piège en environnement japonais est la différence d’encodage par défaut (variable sous 5.1, UTF-8 sans BOM uniforme sous 7). On s’en protège en précisant -Encoding pour les entrées/sorties et en enregistrant les scripts en UTF-8 avec BOM.
• Un module qui ne fonctionne pas sous 7 peut être sauvé par la fonctionnalité de compatibilité Windows, avec la limite de ne renvoyer que des valeurs sérialisées. Si ce n’est pas viable, laissez seulement ce traitement sous 5.1.
• Avec #Requires et $PSVersionTable, inscrivez dans le code sous quelle version le script doit s’exécuter, pour empêcher une exécution sous une version inattendue.
• Menez la migration par étapes : inventaire → installation de 7 (MSI/winget) → test d’exécution → ajout de #Requires → mise à jour de la commande de lancement dans le Planificateur de tâches.

Articles connexes

• Les bases des commandes PowerShell — Les opérations à connaître en premier et comment les utiliser en toute sécurité
• PowerShell avancé — automatiser en toute sécurité l’investigation, l’archivage et le reporting des journaux
• Automatiser les traitements Excel et CSV avec PowerShell — recettes pratiques pour l’agrégation, le rapprochement et la génération de rapports
• Se préparer à l’abandon de VBScript : guide d’audit pour VBA, les macros Excel et les outils internes
• Liste de vérification avant de migrer de .NET Framework vers .NET
• Ce fichier bat, faut-il le migrer vers PowerShell ?

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge l’inventaire des actifs de scripts internes, la planification et la mise en œuvre d’une migration progressive vers PowerShell 7, l’isolement des traitements dépendant de modules réservés à 5.1, ainsi que l’investigation de bugs du type « après la migration, les caractères sont corrompus » ou « ça ne fonctionne plus ».

• Valorisation et migration des actifs existants
• Modernisation et maintenance de logiciels Windows existants
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Quelle est la différence entre Windows PowerShell 5.1 et PowerShell 7 ?

Ce sont des produits distincts. 5.1 est livré avec Windows, fonctionne sur .NET Framework, et Microsoft a cessé d'y ajouter de nouvelles fonctionnalités ; son support suit le cycle de vie de Windows lui-même. 7 est un produit installé séparément qui fonctionne sur .NET (l'ancien .NET Core) et constitue l'axe de développement actuel. 7 ne remplace pas 5.1 : il s'installe dans un autre répertoire et coexiste en side-by-side, avec des exécutables distincts, powershell.exe et pwsh.exe.

L'installation de PowerShell 7 casse-t-elle les scripts existants sous 5.1 ?

Non. 7 s'installe dans un répertoire séparé (par défaut Program Files\PowerShell\7), et son emplacement de modules comme son profil sont gérés indépendamment de 5.1. Les mécanismes existants qui lancent powershell.exe, comme le Planificateur de tâches, continuent de fonctionner sous 5.1 comme avant. C'est précisément pour cela qu'il faut faire attention au fait inverse : « installer 7 ne migre rien à lui seul » — pour qu'un script s'exécute sous 7, il faut explicitement faire basculer la commande de lancement vers pwsh.exe.

Pourquoi mes anciens scripts produisent-ils des caractères corrompus sous PowerShell 7 ?

Parce que l'encodage de caractères par défaut a changé. Sous 5.1, il varie selon la commande (Out-File utilise UTF-16LE, Get-Content utilise l'ANSI, etc.), tandis que 7 utilise uniformément l'UTF-8 sans BOM. Dans un environnement japonais, de nombreux échanges de fichiers supposent du Shift_JIS, si bien qu'une migration réalisée avec les valeurs par défaut peut produire des caractères corrompus, à la lecture comme à l'écriture. Deux mesures suffisent presque toujours à l'éviter : préciser explicitement -Encoding pour toutes les entrées/sorties de fichiers, et enregistrer en UTF-8 avec BOM tout script contenant des caractères non-ASCII.

Que faire d'un module qui ne fonctionne pas sous PowerShell 7 ?

Vérifiez d'abord s'il fonctionne avec un Import-Module ordinaire sous 7. Si ce n'est pas le cas, la fonctionnalité de compatibilité Windows (Import-Module -UseWindowsPowerShell) charge le module dans un processus 5.1 en arrière-plan, utilisable depuis 7 via le remoting. Cela comporte cependant des limites : les objets retournés sont sérialisés et leurs méthodes ne peuvent pas être appelées, et cela ne fonctionne que sur un Windows local. Pour le traitement qui se heurte à ces limites, la solution la plus réaliste est de ne pas forcer les choses et de laisser cette partie tourner sous 5.1.

Comment mener la migration des scripts internes de 5.1 vers 7 ?

Optez pour une migration progressive plutôt qu'un basculement en une fois. Commencez par inventorier les fichiers .ps1 dans le Planificateur de tâches et les emplacements de scripts, puis testez chacun d'eux en l'exécutant sous 7 (pwsh) pour vérifier qu'il fonctionne. Pour ceux qui fonctionnent, ajoutez #Requires -Version 7 et mettez à jour la commande de lancement du Planificateur de tâches de powershell.exe vers pwsh.exe. Ne forcez pas la migration de ce qui ne fonctionne que sous 5.1 : laissez-le tel quel, en indiquant clairement sous quelle version il doit s'exécuter. Installez 7 lui-même via MSI ou winget, et décidez en même temps de la méthode de distribution des mises à jour.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.