Installer PowerShell sur Windows sans se tromper

Pour installer PowerShell sur Windows, commencez par séparer deux choses : Windows PowerShell 5.1, déjà présent dans Windows, et PowerShell 7, la version moderne à installer séparément. Les deux peuvent cohabiter. Le vrai sujet n’est donc pas “avoir PowerShell”, mais choisir la bonne édition, la bonne méthode d’installation et les vérifications qui évitent de casser vos scripts.

Pour approfondir ce point, consultez Installer une caméra de surveillance sans internet, qui traite plus précisément de installer une caméra de surveillance sans internet sans se tromper.

Pour un poste personnel, winget ou le Microsoft Store suffisent souvent. Pour un parc d’entreprise, un fichier MSI contrôlé et documenté reste plus lisible. Dans les deux cas, ne modifiez pas les stratégies de scripts ou le remoting avant d’avoir compris pourquoi vous en avez besoin.

Une installation propre doit pouvoir être répétée, documentée et comprise par quelqu’un d’autre que la personne qui a lancé l’assistant.

Choisir entre Windows PowerShell et PowerShell 7

Windows PowerShell 5.1 reste utile pour la compatibilité avec d’anciens scripts, certains modules historiques et des habitudes d’administration Windows. Il est installé par défaut et fonctionne avec le framework .NET Framework. PowerShell 7, lui, repose sur .NET moderne, reçoit des évolutions actives et vise un usage multiplateforme. Sur un poste récent, PowerShell 7 est généralement le meilleur choix pour un nouvel environnement de travail.

Il ne faut pas désinstaller l’ancien PowerShell pour autant. Beaucoup d’outils Windows, d’anciens scripts internes ou de procédures d’assistance supposent encore la présence de Windows PowerShell. Le bon réflexe consiste donc à conserver les deux et à savoir lequel vous ouvrez. Le raccourci “Windows PowerShell” n’est pas le même que pwsh.

Avant toute installation, vérifiez votre point de départ dans la console actuellement ouverte, car c’est ce résultat qui servira de comparaison après la mise à jour :

$PSVersionTable

La ligne PSVersion indique la version, et PSEdition aide à distinguer l’édition historique de l’édition moderne. Cette vérification paraît simple, mais elle évite beaucoup de diagnostics inutiles, notamment quand un script fonctionne dans une console et échoue dans une autre.

Installer PowerShell avec winget

Sur Windows 10 ou Windows 11 à jour, winget est souvent la méthode la plus directe. Elle évite de chercher manuellement le bon fichier, elle documente l’identifiant du paquet et elle simplifie les mises à jour. Pour un poste de travail standard, c’est le meilleur compromis entre simplicité et traçabilité.

Ouvrez Terminal Windows, Invite de commandes ou PowerShell, puis cherchez le paquet officiel pour vérifier l’identifiant avant de lancer l’installation :

winget search Microsoft.PowerShell

Installez ensuite PowerShell avec l’identifiant officiel, en gardant la commande dans votre procédure si vous devez refaire l’opération plus tard :

winget install --id Microsoft.PowerShell --source winget

Si vous installez dans un environnement professionnel, notez la commande utilisée, le compte employé et le résultat. Une procédure qui tient en deux lignes peut sembler évidente aujourd’hui, mais la traçabilité compte dès qu’un collègue doit reproduire l’installation ou comprendre pourquoi une version diffère sur un autre poste.

Après installation, fermez puis rouvrez le terminal si pwsh n’est pas reconnu immédiatement. Le PATH peut nécessiter une nouvelle session pour être relu proprement, et ce détail explique beaucoup de faux échecs sur des postes pourtant correctement installés.

Installer avec le MSI officiel

Le MSI reste la méthode la plus rassurante quand vous voulez contrôler la version téléchargée. Elle convient bien aux équipes qui préparent une procédure, gardent une copie de l’installateur ou valident l’installation sur un poste pilote avant diffusion. Dans ce scénario, le fichier n’est pas un simple téléchargement : c’est un artefact de déploiement.

Pour approfondir ce point, consultez Installer un package APPX ou MSIX sans, qui traite plus précisément de installer un package appx ou msix sans casser windows.

Récupérez le MSI depuis la page officielle Microsoft ou le dépôt de publication indiqué par la documentation, choisissez l’architecture adaptée à votre Windows, puis lancez l’assistant. Les options importantes concernent généralement l’ajout au PATH, l’association des fichiers, les mises à jour et l’intégration dans le menu contextuel. Ne cochez pas tout mécaniquement : chaque option doit avoir un usage clair.

Pour un poste individuel, l’ajout de PowerShell au PATH est pratique. Pour un parc géré, il faut surtout décider si l’installation doit être visible pour tous les utilisateurs, comment elle sera mise à jour et qui valide les changements de version.

Vérifier que l’installation est propre

Une installation n’est pas terminée quand l’assistant se ferme. Elle est terminée quand vous savez lancer la bonne édition, lire la version et exécuter une commande simple. Ouvrez une nouvelle fenêtre de terminal et testez :

pwsh
$PSVersionTable

Si la commande pwsh ouvre PowerShell 7, vous êtes sur la bonne voie. Si elle n’est pas reconnue, le problème vient souvent du PATH ou d’une session de terminal ouverte avant l’installation. Redémarrer le terminal suffit parfois. Dans un contexte verrouillé, il peut aussi manquer un droit d’installation ou une règle de sécurité locale.

Ne confondez pas la version appelée depuis le menu Démarrer, Terminal Windows et une tâche planifiée. Chaque raccourci peut viser un exécutable différent. Pour un script critique, indiquez explicitement l’environnement attendu. Cette précision évite les erreurs silencieuses où le script tourne, mais pas dans l’édition prévue.

Gérer les scripts sans affaiblir la sécurité

La stratégie d’exécution PowerShell est souvent mal comprise. Elle ne remplace pas un antivirus, une signature obligatoire ou une politique de sécurité complète. Elle sert surtout à éviter l’exécution accidentelle de certains scripts non fiables. Modifier ce réglage uniquement pour contourner une erreur de tutoriel est une mauvaise habitude.

Avant de changer quoi que ce soit, affichez les règles en place afin de savoir quel scope bloque réellement l’exécution :

Get-ExecutionPolicy -List

Si vous développez vos propres scripts sur votre compte utilisateur, une règle au scope CurrentUser peut suffire dans certains cas, sans modifier toute la machine :

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Cette commande ne doit pas devenir une réponse automatique. Dans une entreprise, la stratégie peut être définie par GPO ou par une politique de sécurité. Dans ce cas, forcer un réglage local ne règle pas le fond du problème et peut créer un écart de conformité. La bonne question est : quel script doit tourner, d’où vient-il, qui le maintient et comment prouver qu’il n’a pas été modifié ?

Si vous ne savez pas pourquoi une politique bloque un script, commencez par comprendre le blocage avant de l’assouplir. Cette retenue évite de transformer un test local en réglage durable trop permissif.

Mettre à jour PowerShell proprement

La mise à jour dépend de la méthode d’installation. Si vous avez utilisé winget, la commande de mise à jour reste cohérente avec l’installation et garde le même canal de maintenance :

winget upgrade --id Microsoft.PowerShell --source winget

Avec le Microsoft Store, les mises à jour suivent la logique du Store. Avec un MSI, vous devez généralement installer une version plus récente ou passer par un outil de déploiement. Le point important est de ne pas mélanger les méthodes sans raison. Une machine où PowerShell a été installé par plusieurs chemins devient plus difficile à diagnostiquer.

Pour un usage professionnel, gardez une version de référence et un calendrier de vérification. Les nouveautés sont utiles, mais une mise à jour non testée peut casser un module, un script d’automatisation ou une tâche planifiée. Sur un poste individuel, le risque est faible. Sur plusieurs machines, il mérite un poste pilote.

Les erreurs fréquentes à éviter

La première erreur consiste à suivre un vieux tutoriel sans vérifier la documentation actuelle. PowerShell évolue, les méthodes d’installation aussi, et certaines recommandations anciennes restent visibles longtemps. Utilisez les sources officielles pour choisir la méthode, puis adaptez le niveau de détail à votre contexte.

Pour approfondir ce point, consultez installer Teams Windows, qui traite plus précisément de installer teams sur windows sans se tromper.

La deuxième erreur est de copier des commandes sans savoir dans quelle console elles s’exécutent. Windows PowerShell, PowerShell 7, Invite de commandes et Terminal Windows ne désignent pas exactement la même chose. Quand un guide demande PowerShell 7, ouvrez pwsh, pas seulement “une fenêtre bleue”.

La troisième erreur touche au remoting. Activer l’administration distante peut être utile, mais ce n’est pas une option décorative. Elle suppose des prérequis réseau, des règles de pare-feu, des comptes autorisés et un besoin clair. Sur un poste personnel, le remoting désactivé est souvent la décision la plus saine.

1. ne téléchargez pas un installateur depuis un site miroir inconnu ;
2. ne mélangez pas winget, Store, MSI et ZIP sans documenter le choix ;
3. ne changez pas ExecutionPolicy au niveau machine pour un simple test ;
4. ne lancez pas un script administratif sans vérifier l’édition PowerShell attendue ;
5. ne considérez pas le remoting comme nécessaire pour une installation locale.

Deux contrôles à ne pas sauter

Ces vérifications évitent les installations qui semblent réussies mais deviennent fragiles ensuite.

Sécurité des scripts

Vérifiez la stratégie d’exécution et l’origine des fichiers avant de débloquer un script téléchargé.

Validation de version

Documentez la version installée, la méthode choisie et la commande de mise à jour prévue.

Dépanner une installation qui ne répond pas comme prévu

Le cas le plus fréquent est simple : l’installation s’est bien terminée, mais la commande pwsh n’est pas reconnue. Avant de tout réinstaller, fermez la fenêtre de terminal, ouvrez-en une nouvelle et testez à nouveau. Si le résultat ne change pas, vérifiez que PowerShell 7 apparaît bien dans les applications installées. Le problème vient alors souvent de la variable PATH, d’une installation limitée à un contexte précis ou d’un terminal ouvert avant la fin de l’assistant.

Le deuxième cas concerne les commandes qui fonctionnent dans Windows PowerShell mais échouent dans PowerShell 7. Ce n’est pas forcément une erreur d’installation. Certains modules anciens ont été écrits pour Windows PowerShell 5.1 et ne se comportent pas exactement pareil dans PowerShell 7. Quand un script métier est concerné, testez-le dans les deux éditions, notez le message d’erreur complet et vérifiez la compatibilité du module avant de conclure que PowerShell 7 est mal installé.

Le troisième cas arrive après une installation par plusieurs méthodes successives. Un utilisateur installe d’abord via le Store, puis relance un MSI, puis tente une mise à jour winget. À court terme, cela peut sembler sans conséquence. À moyen terme, vous ne savez plus quel canal met à jour quelle copie, ni quel raccourci pointe vers quelle version. Dans ce scénario, la bonne réparation est moins spectaculaire : choisir une méthode de référence, supprimer les chemins incohérents si nécessaire, puis vérifier l’exécutable réellement appelé.

Pour diagnostiquer le chemin utilisé, vous pouvez demander à Windows où il trouve pwsh, puis comparer le résultat avec l’emplacement attendu :

where pwsh

Si plusieurs chemins apparaissent, documentez celui que vous voulez conserver. Sur un poste individuel, ce travail prend quelques minutes. Sur une équipe, il évite des heures de confusion lorsqu’un script ne produit pas le même résultat selon la machine, le terminal ou le compte utilisateur.

Préparer PowerShell pour un usage quotidien

Une fois PowerShell installé, ne transformez pas immédiatement votre environnement en laboratoire. Commencez par trois réglages sobres : un terminal clair, une méthode de mise à jour connue et un dossier de scripts identifié. Cela suffit pour travailler proprement. Les profils personnalisés, modules avancés, thèmes et alias viendront ensuite, quand vous saurez ce que vous automatisez réellement. Un environnement simple est plus facile à dépanner qu’une console très personnalisée dès le premier jour.

Si vous utilisez PowerShell pour l’administration, gardez une séparation nette entre les tests et les scripts utiles. Un dossier “sandbox” évite de mélanger essais, fragments copiés et commandes de production. Un dossier “scripts-validés” peut contenir uniquement ce que vous relisez, versionnez ou partagez. Cette séparation paraît basique, mais elle réduit fortement le risque de lancer une commande inachevée sur le mauvais poste.

Les modules doivent suivre la même logique. Installez seulement ceux dont vous avez besoin, notez leur rôle et évitez d’accumuler des dépendances invisibles. Quand un script doit être partagé, indiquez les modules requis et la version minimale de PowerShell. Sans cette information, le script devient dépendant de votre machine, ce qui annule une partie de l’intérêt de l’automatisation.

Get-Module -ListAvailable

Enfin, mettez à jour l’aide si vous travaillez souvent hors navigateur. Cette étape n’est pas obligatoire pour installer PowerShell, mais elle améliore le confort quand vous cherchez une option ou un exemple directement dans la console :

Update-Help

Si la commande échoue faute de droits ou de connexion, ce n’est pas bloquant. Notez simplement la limite et utilisez la documentation officielle en ligne. L’important est de garder une source de référence, pas de multiplier les astuces trouvées au hasard.

La méthode recommandée

Pour la plupart des lecteurs, la méthode la plus fiable tient en quatre étapes : installer PowerShell 7 avec winget, rouvrir le terminal, vérifier $PSVersionTable, puis documenter la commande de mise à jour. C’est court, réversible et suffisamment clair pour être reproduit. Le MSI devient préférable si vous devez figer une version, préparer un parc ou valider un déploiement interne.

Gardez Windows PowerShell 5.1 en place, utilisez pwsh pour PowerShell 7, et ne touchez aux réglages de scripts ou d’accès distant que lorsqu’un besoin réel le justifie. C’est cette discipline qui transforme une installation simple en environnement PowerShell fiable.

La prochaine action est donc concrète : choisissez une méthode, installez, vérifiez, notez. Rien de plus, mais rien de moins, car une bonne installation PowerShell vaut surtout par sa reproductibilité.

Pour approfondir ce point, consultez Exploration approfondie de PowerShell : automatisation et, qui traite plus précisément de exploration approfondie de powershell : automatisation et gestion simplifiées.