Si tu tapes encore Install-Module par réflexe, il est temps de regarder ce qui a changé. Depuis PowerShell 7.4, un nouveau module gère l’installation et la publication de packages : PSResourceGet. Il est désormais le standard embarqué dans PowerShell 7.6 LTS, pendant que PowerShellGet v2 et PackageManagement entrent doucement en fin de vie. Si tu gères des scripts, des modules internes ou des pipelines CI/CD qui installent des dépendances PowerShell, voici ce qui change concrètement et comment migrer sans tout casser.
Pourquoi PowerShellGet v2 arrive en fin de course
PowerShellGet v2 et son compagnon PackageManagement datent d’une époque où PowerShell tournait encore essentiellement sous Windows, avec un modèle de providers hérité qui complique la maintenance et ralentit les opérations sur de gros catalogues de modules. Microsoft a retravaillé ce socle de zéro avec Microsoft.PowerShell.PSResourceGet, disponible depuis PowerShell 7.4.0 et embarqué par défaut avec PowerShell 7.6 (voir notre article sur la migration vers PowerShell 7.6 LTS) : plus rapide, pensé cross-platform dès le départ, et compatible avec le protocole NuGet v3.
Ce que PSResourceGet change concrètement
Le changement le plus visible est la disparition du modèle de providers au profit d’un accès direct aux dépôts NuGet, ce qui se traduit par des opérations nettement plus rapides sur la PowerShell Gallery ou sur tes dépôts internes. Les cmdlets ont aussi été simplifiées : au lieu d’avoir des commandes séparées pour les modules et les scripts, PSResourceGet unifie tout sous une seule famille de verbes.
| PowerShellGet v2 | PSResourceGet |
|---|---|
Find-Module / Find-Script |
Find-PSResource |
Install-Module / Install-Script |
Install-PSResource |
Update-Module |
Update-PSResource |
Publish-Module / Publish-Script |
Publish-PSResource |
Register-PSRepository |
Register-PSResourceRepository |
Migrer en pratique
Vérifier ce qui est déjà en place
Sur PowerShell 7.4 et plus, PSResourceGet est déjà présent. Vérifie la version installée et mets-la à jour si besoin, la Gallery reçoit des correctifs régulièrement :
Get-Module -Name Microsoft.PowerShell.PSResourceGet -ListAvailable
Install-PSResource -Name Microsoft.PowerShell.PSResourceGet -Scope AllUsers -Reinstall
Récupérer tes dépôts existants
Si tu as des dépôts NuGet enregistrés sous PowerShellGet v2 (un flux Azure Artifacts interne, par exemple), pas besoin de tout ressaisir à la main : Import-PSGetRepository les reprend automatiquement, à l’exception du dépôt PSGallery par défaut qui est déjà préconfiguré.
Import-PSGetRepository -Force
Get-PSResourceRepository
Adapter tes scripts et tes pipelines CI/CD
Remplace tes appels Install-Module par Install-PSResource dans tes scripts de bootstrap et tes jobs CI/CD. La syntaxe reste proche, avec quelques différences à connaître : Install-PSResource ne charge plus automatiquement le module dans la session courante après installation, il faut un Import-Module explicite. Pour des installations reproductibles avec un fichier de dépendances versionné, utilise le paramètre RequiredResourceFile plutôt que d’égrainer les installations une par une :
Install-PSResource -RequiredResourceFile ./requirements.psd1 -TrustRepository
C’est particulièrement utile dans une pipeline CI/CD où tu veux un comportement déterministe et reproductible d’un run à l’autre. Si tu es justement en train de revoir la sécurité de tes pipelines, ça vaut le coup de coupler cette migration à un audit plus large : on détaille les bonnes pratiques (épinglage par digest, SBOM, authentification sans secret) dans notre article sur la sécurisation des pipelines CI/CD après les attaques supply chain de 2026.
Points de vigilance avant de migrer ton parc
PSResourceGet a encore quelques limitations à connaître avant de basculer en masse. Contrairement à Install-Module, Install-PSResource ne résout pas encore automatiquement les dépendances des ressources provenant de dépôts utilisant le protocole NuGet v3 — tu dois les installer individuellement dans ce cas précis, en attendant que Microsoft comble cet écart dans une future version. Teste aussi tes scripts d’automatisation existants qui s’appuient sur le nom exact des anciennes cmdlets : si tu n’as pas encore migré ces appels, ils continuent de fonctionner (PowerShellGet v2 reste installable en parallèle), mais autant profiter de la bascule vers 7.6 LTS pour nettoyer.
FAQ
PowerShellGet v2 va-t-il cesser de fonctionner du jour au lendemain ?
Non, aucune date de retrait n’est annoncée à ce stade et les deux modules peuvent cohabiter. Mais tout le développement actif se concentre désormais sur PSResourceGet, donc mieux vaut planifier la migration plutôt que la subir.
Dois-je réinstaller tous mes modules après la migration ?
Non, PSResourceGet fonctionne avec les modules déjà installés sur ta machine, quelle que soit la méthode utilisée à l’origine. La migration concerne la façon dont tu installes et gères tes modules à l’avenir, pas ce qui est déjà en place.
PSResourceGet fonctionne-t-il sur PowerShell 5.1 ?
Oui, le module est également disponible pour Windows PowerShell 5.1 via la PowerShell Gallery, même s’il est pensé et optimisé en priorité pour PowerShell 7.x.
Passe à l’action
Si tu migres déjà vers PowerShell 7.6 LTS, c’est le bon moment pour basculer aussi ta gestion de modules vers PSResourceGet : commence par un environnement de test, importe tes dépôts existants, puis remplace progressivement tes appels Install-Module dans tes scripts les plus critiques. Le gain en vitesse et en fiabilité se fait sentir dès les premières exécutions, surtout si tu gères un grand nombre de modules internes.
Laisser un commentaire