Catégorie : PowerShell

PowerShell 7.x, PSResourceGet, DSC et scripts d’automatisation : versions, migrations et exemples prêts à adapter pour ton parc.

  • Microsoft Graph PowerShell v3 : fini Windows PowerShell 5.1

    Microsoft Graph PowerShell v3 : fini Windows PowerShell 5.1

    Si tes scripts d’administration M365 tournent encore sous Windows PowerShell 5.1 avec le module Microsoft.Graph, tu as jusqu’au quatrième trimestre 2026 pour changer ça. Dans un billet publié le 16 septembre 2026, l’équipe Microsoft 365 Dev a confirmé que la version 3.0.0 du Microsoft Graph PowerShell SDK n’aura plus de support explicite pour Windows PowerShell 5.1 — seul PowerShell 7.x restera maintenu.

    Ce n’est pas une surprise brutale : Microsoft prépare le terrain depuis des mois avec le retrait progressif d’Azure AD PowerShell au profit de Graph. Mais c’est la première fois que la coupure entre les deux moteurs PowerShell est posée aussi clairement, avec un calendrier précis plutôt qu’une recommandation vague.

    Ce qui change concrètement

    La v3 change surtout l’outillage qui génère les cmdlets à partir du schéma de l’API Graph — l’équipe la présente comme « minimalement disruptive », l’essentiel de l’usage existant devant continuer à fonctionner tel quel. Des divergences volontaires sont prévues, elles seront documentées au fil des billets alpha et bêta à venir. Le changement qui compte vraiment pour toi est ailleurs : les modules v3.x ne cibleront que PowerShell 7.x — alors que la documentation officielle du SDK présente encore aujourd’hui la compatibilité avec Windows PowerShell 5.1 comme un avantage du produit.

    Le calendrier annoncé tient en deux temps :

    • Maintenant à ~12 mois : période de retrait. La branche v2.x reste compatible avec Windows PowerShell 5.1 et continue de recevoir des correctifs de sécurité si nécessaire, mais les bugs spécifiques à 5.1 ne seront plus activement investigués.
    • Q4 2026 : sortie de la v3.0.0. Après ce point, plus aucune nouvelle version v2 n’est publiée, sauf correctif de sécurité critique.

    Dans les commentaires du billet, Gavin Barron de l’équipe Graph précise que la v2.36.1 (ou plus récente) reste fonctionnelle sans limite de date connue, et que les versions antérieures à celle-ci ne peuvent déjà plus utiliser l’authentification interactive par navigateur (Interactive Browser Credential) — un détail qui pousse à une mise à jour immédiate, indépendamment de la question du support 5.1.

    Pourquoi Microsoft fait ce choix

    L’argument technique tient en une phrase : PowerShell 7.x, construit sur le .NET moderne, règle une bonne partie des problèmes de chargement d’assemblies et de conflits de dépendances qui touchent encore 5.1. La v2 du SDK utilisait déjà les Assembly Load Contexts de PowerShell Core pour limiter ces conflits — Microsoft reconnaît elle-même que ce n’est « pas une solution parfaite », et plusieurs commentateurs du billet signalent des conflits persistants quand Graph charge dans la même session que les modules Teams ou Exchange Online. Concentrer l’effort d’ingénierie sur un seul runtime plutôt que de maintenir deux chemins de compatibilité en parallèle, c’est ce qui doit permettre des correctifs plus rapides à l’avenir.

    Ce que ça implique pour tes scripts

    Si tu administres des tenants Microsoft 365 ou Entra ID via PowerShell, trois choses à vérifier dès maintenant plutôt qu’au moment où la v3 sort :

    • Vérifie ta version actuelle du module avec Get-InstalledModule Microsoft.Graph, et mets à jour vers au moins la 2.36.1 si tu es en dessous — l’authentification interactive en dépend déjà.
    • Si tes scripts tournent encore sous Windows PowerShell 5.1 (console powershell.exe, pas pwsh.exe), planifie leur portage vers PowerShell 7 maintenant. C’est généralement direct pour du code Graph pur, moins pour les scripts qui mélangent Graph avec des modules legacy comme ActiveDirectory ou certains modules IIS/Scheduled Task, dont la compatibilité avec PowerShell 7 reste incertaine selon les retours des lecteurs du billet.
    • Si tu exploites System Center Orchestrator 2025, le sujet est plus épineux : son activité de script .NET ne supporte que Windows PowerShell, et Microsoft n’a pour l’instant donné aucune réponse sur ce cas précis dans les commentaires du billet.
    # Vérifier la version installée du SDK Graph
    Get-InstalledModule Microsoft.Graph | Select-Object Name, Version
    
    # Mettre à jour vers la dernière version disponible
    Update-Module Microsoft.Graph
    
    # Confirmer le moteur PowerShell utilisé (7.x attendu, pas 5.1)
    $PSVersionTable.PSVersion

    Pour la bascule elle-même, la documentation officielle sur la migration de Windows PowerShell 5.1 vers PowerShell 7 reste la référence à suivre : emplacement du profil différent, bascule du switch -UseWindowsPowerShell pour les modules encore incompatibles, et liste à jour des modules qui fonctionnent nativement en 7.x.

    Une tendance plus large

    Ce retrait de 5.1 côté Graph s’inscrit dans un mouvement de fond déjà documenté sur ce blog : la feuille de route 2026 de Microsoft pour PowerShell pousse clairement vers 7.x comme plateforme unique, et la Preview 5 de la 7.7 confirme que tout l’investissement produit se concentre désormais là. Windows PowerShell 5.1 n’est pas officiellement retiré de Windows — il reste là, maintenu via les canaux de support Windows standard — mais chaque module d’automatisation majeur qui lâche son support actif est un signal de plus qu’il est temps de migrer, pas une raison de paniquer.

    FAQ

    Mes scripts PowerShell 5.1 avec Graph vont-ils casser du jour au lendemain ?

    Non. La v2.x continue de fonctionner sous 5.1 ; ce qui change, c’est que les bugs spécifiques à 5.1 ne seront plus corrigés activement, et qu’aucune nouvelle fonctionnalité Graph ne sera testée sur ce runtime au-delà de la v2.

    Dois-je attendre la sortie de la v3 pour migrer vers PowerShell 7 ?

    Non, l’inverse : migre maintenant, pendant que tu as le temps, plutôt que dans l’urgence quand la v3 sortira au T4 2026 et que la v2 cessera de recevoir des mises à jour.

    Et pour Azure PowerShell ou le module Active Directory ?

    Ces modules sont déjà listés comme compatibles PowerShell 7 par Microsoft. Le point de friction concerne surtout les modules plus anciens ou très spécialisés (certains modules IIS, Scheduled Task, ou l’activité .NET de System Center Orchestrator), à tester au cas par cas avant de basculer en production.

    Pour la suite

    Commence par un simple Get-InstalledModule Microsoft.Graph sur tes postes d’administration et tes serveurs de script — si tu es sous la 2.36.1, la mise à jour est gratuite et immédiate. Pour la bascule complète vers PowerShell 7, mieux vaut la traiter comme un projet planifié sur les prochains mois que comme un correctif de dernière minute à l’approche du T4 2026.

  • PowerShell 7.7 Preview 5 : pensé pour les agents IA

    PowerShell 7.7 Preview 5 : pensé pour les agents IA

    PowerShell 7.7.0-preview.5 est sorti le 23 septembre 2026, cinquième preview depuis l’ouverture de la branche 7.7 le 28 avril. Pas de date de GA annoncée pour l’instant côté Microsoft. Deux changements de cette preview méritent qu’on s’y arrête, parce qu’ils répondent à des frictions bien réelles plutôt qu’à des ajouts cosmétiques : un réglage pensé pour les agents IA qui pilotent ta session, et un correctif de démarrage qui va soulager pas mal d’admins sous OneDrive.

    $PSStyle.AutoSizeDefaultFormatting : quand ce n’est plus toi qui lis la sortie

    La preview 5 ajoute une propriété $PSStyle.AutoSizeDefaultFormatting, qui force un formatage compact et auto-dimensionné pour les vues table et wide — par défaut, sans avoir à ajouter | Format-Table -AutoSize à chaque commande. L’intérêt saute aux yeux dès que ta session tourne dans un terminal étroit, mais la vraie motivation derrière ce changement est ailleurs : de plus en plus de sessions PowerShell sont désormais pilotées par un agent IA plutôt que lues directement par un humain, et une sortie tronquée ou mal alignée peut faire dérailler un parsing automatisé qui s’attendait à des colonnes propres.

    C’est une propriété $PSStyle, pas une nouvelle cmdlet ni un flag de ligne de commande — tu la positionnes une fois dans ton profil si tu veux ce comportement par défaut sur toutes tes sessions, scriptées ou interactives.

    Le fail-open qui va sauver des démarrages cassés

    Le second changement est plus discret mais plus impactant au quotidien : le fichier powershell.config.json au niveau utilisateur échoue désormais en mode ouvert (fail open) plutôt qu’en faisant planter PowerShell au démarrage. Le ticket (PR #27373) cible précisément le cas d’un fichier de config corrompu ou verrouillé par une synchronisation OneDrive active sur le dossier de profil — un scénario qu’on croise régulièrement en support, où l’utilisateur ne comprend pas pourquoi pwsh refuse de démarrer après un simple déplacement de dossier.

    Attention à la nuance : seul le fichier de config par utilisateur bascule en fail-open. Le fichier de config système continue de faire planter le démarrage s’il ne peut pas être chargé — logique, puisqu’une config système cassée doit rester visible immédiatement plutôt que de s’exécuter silencieusement avec des réglages par défaut potentiellement non voulus.

    Un breaking change qui mérite un test avant upgrade : New-Guid passe en UUID v7

    Dans la liste des breaking changes officielle de la 7.7 (PR #27033), New-Guid génère désormais par défaut des UUID version 7 (triables temporellement) au lieu de la version 4 (aléatoire pure). Le format de sortie ne change pas — ça reste un GUID .NET classique — mais la structure interne, elle, change : un v7 encode un horodatage dans ses premiers octets, ce qu’un v4 ne fait jamais.

    Si un de tes scripts dépend d’une distribution vraiment aléatoire (génération de tokens, tests de charge avec clés dispersées pour éviter les hotspots d’index, etc.), ce changement par défaut peut introduire un biais silencieux. La parade reste simple : appeler directement [guid]::NewGuid() plutôt que la cmdlet si tu as besoin de garantir du v4.

    Le reste de la preview 5, en bref

    • Nouvelle cmdlet New-TemporaryDirectory (PR #27549), contribution externe de @KirtiRamchandani — l’équivalent répertoire de l’historique New-TemporaryFile.
    • Durcissement WLDP : nouveau réglage EnableFileOnlyEntry (PR #26752) côté Windows Lockdown Policy — une brique de plus pour les environnements contraints par Device Guard.
    • Modules mis à jour : Microsoft.PowerShell.PSResourceGet passe en v1.3.0-preview2 (on avait couvert la bascule de ce module vers Microsoft Artifact Registry) et PSReadLine en v2.4.5.
    • Runtime : PowerShell 7.7.0-preview.5 est désormais buildé sur .NET 11.0.0-rc.1 — à ne pas confondre avec les branches LTS 7.6/7.5/7.4, qui restent respectivement sur .NET 10, 9 et 8.

    Rien de tout ça n’est un virage de direction : c’est la continuité directe de la feuille de route 2026 qu’on avait détaillée dans notre article sur PowerShell 7.7, OpenSSH et DSC v3, et ça complète ce qu’apporte déjà DSC v3.3 côté gestion de configuration.

    FAQ

    PowerShell 7.7 est-il prêt pour la production ?

    Non, pas encore — c’est une branche preview, pas de date de GA communiquée à ce stade. Pour la production, reste sur une branche LTS (7.6, 7.5 ou 7.4 selon ta politique de support) et teste les previews à part, sur des machines dédiées.

    Le fail-open du config utilisateur introduit-il un risque de sécurité ?

    Le fail-open ne s’applique qu’au fichier de config par utilisateur, pas au fichier système — celui qui porte les réglages à portée de sécurité reste en fail-closed. L’objectif ici est la résilience du démarrage côté utilisateur, pas un assouplissement des contrôles.

    Dois-je changer mes scripts à cause du passage de New-Guid en UUID v7 ?

    Seulement si tu as une dépendance explicite à une distribution purement aléatoire. Pour la plupart des usages (identifiants d’objets, clés de dictionnaire, etc.), le changement est transparent.

    Pour aller plus loin

    Si tu fais tourner des agents ou des pipelines d’automatisation qui parsent la sortie de PowerShell, teste $PSStyle.AutoSizeDefaultFormatting dès maintenant sur un environnement de preview — c’est le genre de réglage qui t’évite une mauvaise surprise le jour où un agent IA interprète une colonne tronquée comme une valeur vide. Et si OneDrive synchronise ton dossier de profil, note que cette classe de panne au démarrage va bientôt disparaître — sans action de ta part une fois la 7.7 stabilisée.

  • DSC v3.3 : RegistryList, Personalization et –what-if étendu

    DSC v3.3 : RegistryList, Personalization et –what-if étendu

    Le 17 septembre 2026, l’équipe PowerShell a publié Desired State Configuration (DSC) v3.3.0. On avait couvert la feuille de route de cette équipe pour 2026 dans cet article ; cette version en est la dernière étape publiée. Pas de refonte spectaculaire cette fois, mais trois ressources Windows qui comblent des manques réels, un adaptateur générique pour le registre, et une extension du mode --what-if à des ressources où tu en avais vraiment besoin.

    Trois nouvelles ressources dans Microsoft.Windows

    RegistryList : une instance, plusieurs clés

    Jusqu’ici, gérer dix valeurs de registre voulait dire dix instances de Microsoft.Windows/Registry dans ta configuration. Microsoft.Windows/RegistryList regroupe un tableau d’entrées dans une seule ressource. Le binaire registry.exe sous-jacent gagne un commutateur --list pour ça, et les manifestes correspondants sont désormais rassemblés dans un fichier unique, registry.dsc.manifests.json, plutôt qu’éparpillés.

    WindowsFeatureList : le même principe pour les rôles et fonctionnalités

    Même logique appliquée à la gestion des fonctionnalités Windows (rôles, composants optionnels) : une liste plutôt qu’une ressource par fonctionnalité. Cette ressource est une contribution externe, signée Gijs Reijn — un bon rappel que DSC v3 reste un projet open source sur GitHub, pas seulement un produit Microsoft fermé.

    Personalization : accent, thème clair/sombre, transparence

    Nouvelle venue : une ressource qui pilote les réglages de personnalisation Windows — couleur d’accent, mode clair ou sombre, transparence. Utile pour standardiser l’image d’un poste de travail à grande échelle sans passer par une stratégie de groupe dédiée à chaque réglage.

    Pour découvrir ce que chaque ressource accepte :

    dsc resource list 'Microsoft.Windows/*'
    dsc resource schema --resource Microsoft.Windows/Personalization

    L’adaptateur de registre générique

    Microsoft.Windows.Adapter/Registry fait le lien entre des propriétés JSON ordinaires et leur représentation dans le registre, en gérant lui-même les conversions. Pour l’instant, ces conversions ne couvrent que les types utilisés par Personalization — si tu écris une ressource personnalisée qui a besoin d’un type non géré, l’équipe invite explicitement à ouvrir une issue sur le dépôt plutôt que de contourner le problème en silence.

    --what-if s’étend à trois familles de ressources

    Prévisualiser un set sans y toucher, c’est le genre de garde-fou qu’on regrette de ne pas avoir eu la première fois qu’on casse un service en production. La v3.3 étend --what-if à Microsoft.Windows/Service, Microsoft.Windows/FirewallRuleList et aux ressources de configuration SSHD :

    # service.dsc.config.yaml
    $schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
    resources:
      - name: Print Spooler
        type: Microsoft.Windows/Service
        properties:
          name: Spooler
          startType: Disabled
    dsc config set --what-if --file ./service.dsc.config.yaml

    Dans la même veine, FirewallRuleList gagne une propriété unspecifiedRules, qui décide quoi faire des règles non listées dans ta configuration — avec action obligatoire, et direction/profiles en option.

    Filtrage d’export expérimental : attention, la syntaxe va encore bouger

    Quand une ressource ne sait pas filtrer nativement les instances qu’elle exporte, le moteur DSC peut désormais récupérer la liste complète et filtrer lui-même, à partir des propriétés que tu passes en entrée. Le mécanisme accepte les caractères génériques (*, insensibles à la casse) sur les valeurs, s’applique aux sous-propriétés imbriquées des objets, et traite plusieurs éléments d’un tableau comme un OU logique :

    # services.dsc.config.yaml
    $schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
    resources:
      - name: Automatically starting local account services
        type: Microsoft.Windows/Service
        properties:
          startType: Auto*
          logonAccount: '*Local*'

    Pas de gestion des plages de versions ni des bornes numériques pour l’instant — évite donc de t’appuyer là-dessus pour filtrer par version de composant. L’équipe prévient elle-même que la syntaxe de cette fonctionnalité expérimentale peut changer avant de se stabiliser.

    Autres changements à ne pas manquer

    dsc mcp devient dsc server (l’ancien nom reste un alias), avec de nouveaux outils exposés (show_dsc_schema(), invoke_dsc_function(), invoke_dsc_expression()) pour qui pilote DSC via le protocole MCP plutôt qu’en ligne de commande directe. La fonction format() quitte le statut expérimental. Deux nouvelles fonctions arrivent : stateChanged(resourceId(...)), pour savoir si un set a réellement modifié quelque chose, et restartRequired() avec ses variantes système/service/processus.

    Côté outillage en ligne de commande, --required-version remplace --version sur dsc resource * (l’ancien flag reste un alias) et accepte des plages façon Rust — ^1.1, ~1.2.3 :

    dsc resource schema --resource Microsoft.Windows/RegistryList --required-version '^1.1.0'

    Microsoft/OSInfo accepte maintenant des comparateurs (=, <, <=, >, >=) sur la version du système — un seul par instance. Et côté Linux, DSC v3.3 arrive enfin sur packages.microsoft.com en RPM et DEB, à l’image de la bascule que PSResourceGet a connue vers le Microsoft Artifact Registry (on en parlait ici) — ça simplifie l’installation sur les distributions qui s’appuient sur ce dépôt.

    FAQ

    Faut-il migrer mes ressources Registry existantes vers RegistryList ?

    Pas dans l’urgence. Microsoft.Windows/Registry reste disponible ; RegistryList a surtout du sens si tu gères un grand nombre d’entrées et que tu veux réduire le nombre d’instances dans ta configuration.

    DSC v3.3 est-il compatible avec les configurations écrites pour v3.0/v3.1 ?

    L’article d’annonce ne signale aucun changement cassant pour les ressources existantes — les nouveautés sont additives (nouvelles ressources, extension de fonctionnalités existantes). Teste quand même en --what-if avant de déployer en production, par principe.

    Où suivre l’évolution du projet ?

    DSC v3 est développé en open source sur GitHub ; c’est là que partent les issues, les demandes de ressources et les contributions comme celle de WindowsFeatureList.

    Pour aller plus loin

    Si tu n’as pas encore basculé vers DSC v3, le guide d’installation officiel couvre Windows, Linux et macOS. Les notes de version complètes, avec la liste de tous les changements depuis v3.0, sont disponibles sur le dépôt GitHub du projet. Si une des trois nouvelles ressources comble un manque que tu avais contourné avec un script maison, c’est probablement le bon moment pour le remplacer.

  • PowerShell 7.6.6 : ce qui change dans la dernière mise à jour LTS

    PowerShell 7.6.6 : ce qui change dans la dernière mise à jour LTS

    Le 8 septembre 2026, l’équipe PowerShell a livré trois mises à jour de maintenance le même jour : 7.6.6, 7.5.11 et 7.4.20. Rien d’exceptionnel en soi — ce sont des « patch releases », pas des montées de version majeures. Mais la 7.6.6 embarque un changement qui casse silencieusement certains scripts, et un réglage de sécurité qui mérite qu’on s’y attarde si tu geres des postes sous Windows Defender Application Control. Voici ce qui change concrètement, et ce qu’il faut vérifier avant de déployer.

    Ce qui a changé dans PowerShell 7.6.6

    La version tourne sur .NET 10.0.12. Trois modules embarqués ont été mis à jour :

    • Microsoft.PowerShell.PSResourceGet passe en v1.2.0
    • PSReadLine passe en v2.4.5
    • Microsoft.PowerShell.ThreadJob passe en v2.2.0

    Tu peux vérifier ta version installée avec :

    $PSVersionTable.PSVersion
    Get-Module -ListAvailable Microsoft.PowerShell.ThreadJob, PSReadLine, Microsoft.PowerShell.PSResourceGet

    Le piège ThreadJob : vérifie tes scripts avant de monter en version

    C’est le point qui va en surprendre plus d’un. Le module Microsoft.PowerShell.ThreadJob remplace désormais l’ancien module ThreadJob. La cmdlet Start-ThreadJob continue de fonctionner normalement en usage courant — ce n’est pas elle le problème. Le piège, c’est si un de tes scripts appelle la cmdlet par son nom pleinement qualifié avec l’ancien module :

    # Ancien appel qualifié — ne résout plus rien après la mise à jour
    ThreadJob\Start-ThreadJob -ScriptBlock { Get-Process }
    
    # Appel qualifié correct depuis 7.6.6
    Microsoft.PowerShell.ThreadJob\Start-ThreadJob -ScriptBlock { Get-Process }

    Si tu ne fais jamais d’appel qualifié par module dans tes scripts (la grande majorité des usages), tu n’as rien à changer. Mais si une partie de ton code d’automatisation — modules internes, scripts de déploiement hérités — référence explicitement ThreadJob\Start-ThreadJob, fais un grep -r "ThreadJob\\\\" sur ton dépôt de scripts avant de pousser la mise à jour en production. C’est le genre de breaking change qui ne remonte qu’en prod, trois semaines après le déploiement, quand personne ne se souvient plus avoir mis à jour PowerShell.

    Un nouveau réglage WLDP pour les environnements WDAC

    Si tu administres des postes sous Windows Defender Application Control, la 7.6.6 ajoute la prise en charge du paramètre EnableFileOnlyEntry dans la Windows Lockdown Policy (WLDP). Ce réglage fait suite à un correctif livré dans la version précédente (7.6.5, 14 août 2026) qui corrigeait un comportement incohérent du dot-sourcing (pwsh -File) pour les fonctions avancées signées sous WDAC. Autre ajout lié : un repli (fallback) vers AppLocker après l’appel à WldpCanExecuteFile, pour les environnements où WDAC n’est pas la seule couche de contrôle d’exécution en place.

    Si WDAC n’est pas ton quotidien, tu peux ignorer ce point sans arrière-pensée — il ne change rien au comportement par défaut.

    Autres changements à noter

    Trois correctifs plus discrets, mais qui valent d’être connus si tu tombes dessus en debuggant :

    • WildcardPattern.Escape échappe désormais correctement les accents graves isolés (un bug qui affectait les chemins ou motifs contenant un seul backtick)
    • Le paramètre -ChildPath de Join-Path accepte maintenant un tableau de chaînes (string[]) plutôt qu’une seule chaîne — rétrocompatible pour un usage simple, mais à connaître si tu scriptes la construction de chemins dynamiquement
    • Les espaces en fin de nom de source d’événement sont désormais supprimés automatiquement (évite des entrées de journal d’événements mal formées)

    Pourquoi trois versions sorties le même jour ?

    PowerShell maintient plusieurs branches en parallèle, chacune alignée sur un cycle de support .NET différent : 7.4 est une branche LTS (Long Term Support) construite sur .NET 8, 7.5 une branche STS (Standard Term Support, cycle de support plus court) sur .NET 9, et 7.6 — la branche courante — vient de basculer sur .NET 10. Microsoft livre les correctifs de sécurité et de maintenance sur les trois branches actives simultanément plutôt que de forcer une montée de version majeure à chaque patch. Concrètement, si tu es encore en 7.4 pour des raisons de stabilité en production, tu bénéficies des mêmes correctifs de fond sans devoir sauter sur 7.6.

    FAQ

    Dois-je mettre à jour immédiatement vers 7.6.6 ?

    Si tu es déjà sur la branche 7.6, oui, sans urgence particulière — c’est un patch release, pas une version majeure avec son lot d’incertitudes. Vérifie juste l’usage de ThreadJob\Start-ThreadJob qualifié dans ton code avant de déployer à grande échelle.

    Je suis encore en PowerShell 7.4, dois-je migrer vers 7.6 ?

    Pas forcément. 7.4 reste une branche LTS activement maintenue (7.4.20 est sortie le même jour). Migre vers 7.6 si tu as besoin des nouveautés spécifiques à cette branche, pas uniquement pour suivre le numéro de version le plus récent.

    Le changement ThreadJob va-t-il casser Invoke-Command ou les jobs en arrière-plan classiques ?

    Non. Ce changement concerne uniquement le module ThreadJob et la cmdlet Start-ThreadJob utilisée en mode qualifié. Les jobs PowerShell standards (Start-Job, Invoke-Command -AsJob) ne sont pas concernés.

    En résumé

    Une mise à jour de maintenance sans drame, à condition de vérifier un seul point avant de la déployer en masse : les appels qualifiés à ThreadJob\Start-ThreadJob dans ton code existant. Le reste — modules à jour, réglage WDAC pour qui en a besoin, corrections mineures — s’installe sans accroc. Si ton parc utilise encore PSGallery par défaut pour ses modules, ça vaut aussi le coup de relire notre article sur le basculement vers Microsoft Artifact Registry, qui touche directement PSResourceGet mis à jour dans cette même release.

    Pour la vue d’ensemble des évolutions attendues sur PowerShell, OpenSSH et DSC v3 cette année, on avait détaillé la feuille de route 2026 de Microsoft — la 7.6.6 s’inscrit dans cette continuité, pas comme une rupture.

    Source officielle pour le détail complet des correctifs : What’s New in PowerShell 7.6 (Microsoft Learn) et le changelog complet sur le dépôt GitHub PowerShell/PowerShell.

  • Microsoft Artifact Registry, le nouveau dépôt par défaut de PSResourceGet

    Microsoft Artifact Registry, le nouveau dépôt par défaut de PSResourceGet

    Depuis la version 1.3.0-preview1 de PSResourceGet, une simple commande Get-PSResourceRepository affiche une colonne qui change la donne :

    Name                      Uri                                       Trusted Priority
    ----                      ---                                       ------- --------
    MicrosoftArtifactRegistry https://mcr.microsoft.com/                True    40
    PSGallery                 https://www.powershellgallery.com/api/v2  False   50
    

    La PowerShell Gallery, le dépôt communautaire historique que tu utilises probablement depuis des années sans y penser, n’est plus Trusted par défaut. Un nouveau dépôt, le Microsoft Artifact Registry, prend la tête avec une priorité plus haute (40 contre 50 — plus le chiffre est bas, plus PSResourceGet le consulte tôt). Ce n’est pas un détail cosmétique : c’est un changement de posture de sécurité assumé par Microsoft.

    Pourquoi la PowerShell Gallery a perdu la confiance par défaut

    La PowerShell Gallery reste ouverte à quiconque crée un compte et génère une clé API — c’est ce qui en a fait un dépôt communautaire riche au fil des ans. Mais cette ouverture a un coût : plusieurs chercheurs en sécurité ont documenté des scénarios de typosquatting (publier un module au nom presque identique à un paquet populaire pour piéger une faute de frappe) et de spoofing, où un module malveillant se fait passer pour un paquet officiel Microsoft en copiant son nom d’affichage et sa description.

    Rien de tout ça n’est propre à PowerShell — npm et PyPI ont vécu les mêmes attaques, à plus grande échelle encore. Mais pour un administrateur système qui installe des modules avec des privilèges élevés, souvent sur des serveurs de production, le risque n’a rien de théorique. Traiter la Gallery comme non fiable par défaut est une position raisonnable, même si elle demande un temps d’adaptation : tu devras explicitement faire confiance à un dépôt (Set-PSResourceRepository -Name PSGallery -Trusted) ou valider chaque installation communautaire au cas par cas.

    Le Microsoft Artifact Registry, concrètement

    Le MAR n’est pas un nouveau service pensé pour PowerShell : c’est le registre où Microsoft publie déjà ses images de conteneurs officielles. PSResourceGet s’appuie sur cette infrastructure existante depuis la version 1.1.0 du module, et devient dépôt par défaut à partir de la 1.3.0-preview1, aux côtés de PSGallery. Aucune authentification n’est nécessaire pour chercher, télécharger ou installer un paquet — seule la publication est verrouillée côté Microsoft, ce qui élimine mécaniquement le risque de typosquatting sur les modules officiels.

    L’enregistrer prend une seule ligne :

    # Enregistre MAR avec les réglages par défaut (Trusted, priorité 40)
    Register-PSResourceRepository -MicrosoftArtifactRegistry
    
    # Vérifie ce qui est enregistré
    Get-PSResourceRepository
    
    # Recherche et installation, sans rien changer d'autre
    Find-PSResource -Repository MicrosoftArtifactRegistry -Name Az.Accounts
    Install-PSResource -Name Az.Accounts -Repository MicrosoftArtifactRegistry
    

    Si tu es encore sur PowerShell 5.1, ou sur une version de PowerShell 7 antérieure à 7.5.0, il faut d’abord installer PSResourceGet manuellement — le module n’est pas mis à jour automatiquement avec l’exécutable :

    Install-Module -Name Microsoft.PowerShell.PSResourceGet -Repository PSGallery
    

    Le cas Az : plus rapide, mais pas encore sans accroc

    Le module Az est le premier gros bénéficiaire concret de ce changement : l’installer depuis le MAR plutôt que depuis PSGallery accélère nettement le téléchargement, sans passer par le processus de publication communautaire classique. La commande recommandée par Microsoft :

    Register-PSResourceRepository -Name MAR -Uri https://mcr.microsoft.com -ApiVersion ContainerRegistry
    Install-PSResource -Name Az -Repository MAR
    

    Il y a un vrai bug à connaître avant de foncer en production : certains sous-modules, comme Az.KeyVault, échouent à l’installation depuis le MAR avec l’erreur Install-PSResource: Package(s) 'Az.Keyvault' could not be installed from repository 'MAR'. Le correctif est suivi sur le dépôt GitHub de PSResourceGet, mais en attendant, le contournement documenté par Microsoft reste d’installer ce module précis depuis PSGallery. Ce n’est pas gênant tant que tu sais que ce cas existe — ça devient un mauvais moment si tu le découvres au milieu d’un déploiement.

    Ce que ça change pour tes scripts et tes pipelines

    Si tu gères tes serveurs avec des modules exclusivement Microsoft (Az, Microsoft.Graph, ExchangeOnlineManagement dans ses versions récentes), la bascule est presque transparente : enregistre le MAR, laisse PSGallery en untrusted, et tes installations continuent de fonctionner sans invite de confirmation. C’est la configuration que je recommande par défaut sur un serveur de production.

    La situation se complique si tu dépends de modules communautaires bien installés — ImportExcel, PSFramework, ou des modules DSC tiers n’ont aucune raison d’apparaître un jour sur le MAR, qui reste réservé aux publications officielles Microsoft. Dans ce cas, remettre PSGallery en Trusted globalement annule une bonne partie de l’intérêt du changement. Une approche plus fine consiste à garder PSGallery non fiable, et à n’accorder la confiance ponctuellement à l’installation (Install-PSResource -Name ImportExcel -TrustRepository) pour les modules que tu as toi-même audités, plutôt que de rouvrir la porte à l’ensemble du dépôt communautaire.

    FAQ

    Dois-je désinstaller PSGallery ?

    Non, et ce n’est même pas recommandé : de nombreux modules n’existent que là. Le changement porte sur le niveau de confiance par défaut, pas sur la disponibilité du dépôt.

    Le MAR remplace-t-il PSGallery à terme ?

    Non, ce n’est pas l’objectif annoncé. Le MAR couvre les modules officiels Microsoft ; PSGallery reste la référence pour l’écosystème communautaire, qui représente la grande majorité des modules publiés.

    Est-ce que ça concerne aussi PowerShellGet v2 (Install-Module) ?

    Non, cette évolution est propre à PSResourceGet. Si tu es toujours sur PowerShellGet v2, c’est une raison supplémentaire de migrer.

    Faut-il une version précise de PSResourceGet ?

    Le support du MAR existe depuis la 1.1.0, mais il ne devient dépôt par défaut qu’à partir de la 1.3.0-preview1. Vérifie ta version avec Get-Module Microsoft.PowerShell.PSResourceGet -ListAvailable avant de t’étonner qu’il manque à ta liste de dépôts.

    Passe à l’action

    Lance Get-PSResourceRepository sur un de tes serveurs cette semaine, et regarde ce qui en sort. Si PSGallery apparaît encore Trusted sans que tu l’aies décidé consciemment, c’est le bon moment pour revoir cette configuration module par module plutôt que de la laisser filer.

    Pour creuser le sujet, la documentation officielle Microsoft détaille le support du Microsoft Artifact Registry dans PSResourceGet ainsi que les dépôts pris en charge, et BleepingComputer revient sur les failles de spoofing identifiées sur la PowerShell Gallery. On avait détaillé la migration vers PSResourceGet dans cet article, et la feuille de route 2026 de l’équipe PowerShell dans celui-ci.

  • PowerShell 7.7, OpenSSH et DSC v3 : la feuille de route 2026 de Microsoft

    PowerShell 7.7, OpenSSH et DSC v3 : la feuille de route 2026 de Microsoft

    Tu es passé à PowerShell 7.6 LTS et tu as fait le ménage dans tes modules avec PSResourceGet ? Bonne nouvelle : l’équipe PowerShell vient de publier sa feuille de route détaillée pour la suite de 2026, et elle touche à peu près tout ce que tu utilises au quotidien — la console, la gestion des modules, la connexion à distance, et même l’intégration avec les assistants IA. Voici ce qui arrive, et pourquoi ça vaut le coup de t’y préparer dès maintenant.

    PowerShell 7.7 : des irritants du quotidien enfin traités

    Fini les profils et modules planqués dans OneDrive

    Si tes utilisateurs synchronisent leur dossier Documents avec OneDrive ou un autre outil cloud, tu as sans doute déjà vu PowerShell ramer au démarrage : c’est là que sont stockés par défaut les modules utilisateur, les profils et l’aide. La relocalisation expérimentale du PSUserContentPath, attendue en preview, vise justement à sortir ce contenu du chemin de synchronisation cloud pour éviter cette dégradation de performance — un correctif attendu depuis longtemps par qui gère des postes en environnement d’entreprise.

    Chargement de modules sans toucher au profil

    Autre irritant pour qui distribue des outils PowerShell à une équipe : enregistrer un tab-completer ou un Feedback Provider oblige aujourd’hui à modifier le script de profil de chaque utilisateur. La fonctionnalité de chargement de module non basé sur le profil doit permettre d’enregistrer ces extensions sans toucher au profil — un vrai soulagement pour les développeurs d’outils internes qui n’ont plus à demander à chacun de coller une ligne dans son $PROFILE.

    PSReadLine : de l’autocomplétion qui connaît le contexte

    PSReadLine évolue vers une IntelliSense prédictive contextuelle, capable de tenir compte de l’état du répertoire courant — par exemple proposer des complétions différentes selon que tu es dans un dépôt Git ou non. En parallèle, un travail de fond découple la saisie clavier du rendu du terminal, ce qui ouvre la voie à de futures capacités sans dégrader la réactivité de la console.

    Un serveur MCP pour connecter PowerShell aux assistants IA

    Signe des temps : l’équipe développe un serveur Model Context Protocol (MCP) pour PowerShell, avec un premier axe de travail explicitement centré sur la sécurité. L’idée est de permettre à un assistant IA d’interagir avec ton environnement PowerShell de façon structurée et contrôlée, plutôt qu’en lui laissant exécuter des commandes en aveugle. On avait déjà vu Microsoft avancer sur ce terrain côté gouvernance des identités d’agents IA dans Entra ID : la sécurisation des interactions IA devient un fil rouge sur toute la pile Microsoft, pas seulement côté identité.

    PSResourceGet : encore plus rapide, encore plus fiable

    Après la bascule que tu as probablement déjà entamée depuis PowerShellGet, PSResourceGet continue d’évoluer : la migration complète vers le Microsoft Artifact Registry (MAR) comme dépôt de confiance par défaut se poursuit, avec en prime un support du téléchargement et de l’installation concurrents pour accélérer la récupération de plusieurs modules à la fois. L’objectif affiché reste la fiabilité et la scalabilité — utile si tu gères des pipelines CI/CD qui installent des dizaines de modules à chaque run.

    Windows OpenSSH : l’authentification Entra ID à l’étude

    Encore au stade d’exploration active, le support de l’authentification Microsoft Entra ID pour les connexions SSH sur Windows OpenSSH serait une avancée notable : plus besoin de gérer des paires de clés SSH en parallèle de ton infrastructure d’identité, avec la possibilité d’appliquer les mêmes politiques d’accès conditionnel qu’ailleurs dans ton tenant. C’est une piste à suivre plutôt qu’une fonctionnalité disponible aujourd’hui, mais elle s’inscrit dans une tendance de fond : faire d’Entra ID le point de contrôle unique, y compris pour l’administration à distance historiquement gérée par clés.

    DSC v3 : la configuration as code passe un cap

    Desired State Configuration continue sa transformation en plateforme multiplateforme indépendante de PowerShell. DSC v3.2 doit atteindre la disponibilité générale sur la première moitié de 2026, avec des premières préversions d’un adaptateur Python permettant de créer des ressources pour Linux — un signe clair que DSC ne se limite plus à l’écosystème Windows. Le développement de la version 3.3 doit suivre juste après.

    Concrètement, DSC v3 fonctionne comme un outil autonome piloté en ligne de commande, avec des documents de configuration en YAML ou JSON :

    # Vérifier l'état actuel par rapport à la configuration désirée
    dsc config test --file ./serveur-web.config.dsc.yaml
    
    # Appliquer la configuration désirée
    dsc config set --file ./serveur-web.config.dsc.yaml
    

    Tu peux toujours réutiliser tes ressources PowerShell DSC existantes, mais l’outil lui-même ne dépend plus de PowerShell pour fonctionner — un choix d’architecture qui facilite son adoption sur des machines Linux ou macOS. Toute la documentation de référence, y compris le détail des commandes dsc config et dsc resource, est disponible sur Microsoft Learn.

    FAQ

    Faut-il déjà migrer vers PowerShell 7.7 ?

    Non, la plupart de ces fonctionnalités sont encore en développement ou en préversion : reste sur PowerShell 7.6 LTS pour tes environnements de production, et garde un œil sur les préversions 7.7 dans un environnement de test si tu veux anticiper les changements.

    DSC v3 va-t-il remplacer complètement DSC 1.1 / PowerShell DSC 2.0 ?

    À terme, c’est la direction prise par Microsoft, mais aucune date de fin de support n’a été annoncée pour les versions historiques. Si tu démarres un nouveau projet de configuration as code aujourd’hui, DSC v3 est le choix le plus pérenne.

    Le serveur MCP PowerShell est-il déjà utilisable ?

    Il est en cours de développement, avec un focus initial sur la sécurité plutôt que sur la disponibilité immédiate de fonctionnalités. Ce n’est pas encore un outil à déployer en production.

    L’authentification Entra ID pour OpenSSH remplace-t-elle les clés SSH classiques ?

    Pas dans l’immédiat : c’est une piste explorée par l’équipe, pas une fonctionnalité livrée. Continue de gérer tes clés SSH selon tes procédures actuelles en attendant une annonce plus concrète.

    Ce qu’il faut retenir

    Cette feuille de route confirme une tendance de fond : PowerShell se modernise sur trois fronts en parallèle — l’expérience développeur au quotidien (PSReadLine, chargement de modules), la gestion d’infrastructure as code multiplateforme (DSC v3), et l’intégration sécurisée avec les assistants IA (serveur MCP). Garde un œil sur les préversions si tu veux anticiper ces changements, mais rien ici ne justifie de bousculer ta feuille de route de production actuelle.

  • PSResourceGet : dis adieu à PowerShellGet v2 pour gérer tes modules

    PSResourceGet : dis adieu à PowerShellGet v2 pour gérer tes modules

    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.

  • PowerShell 7.6 LTS : ce qui change et comment migrer sereinement

    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

  • Automatisation IT avec PowerShell : le guide complet pour administrateurs système

    Automatisation IT avec PowerShell : le guide complet pour administrateurs système

    Deux heures par semaine à copier des fichiers, vérifier des services ou créer des comptes utilisateurs à la main : si ça te parle, tu n’es pas seul. Beaucoup d’équipes IT n’ont pas encore mis l’automatisation au cœur de leurs pratiques, alors qu’elles pourraient se libérer un temps précieux. PowerShell reste, encore en 2026, l’outil le plus efficace pour reprendre la main sur ces tâches répétitives — que ton infrastructure tourne sous Windows, Linux ou dans le cloud.

    Dans ce guide, tu vas voir pourquoi PowerShell s’est imposé comme la référence de l’automatisation IT, cinq scripts prêts à l’emploi pour commencer dès aujourd’hui, ce que change la version 7.6 LTS, et les bonnes pratiques pour écrire des scripts qui tiennent la route en production.

    Pourquoi PowerShell est devenu incontournable pour l’automatisation IT

    Contrairement à un langage de script classique qui manipule du texte brut, PowerShell fait circuler des objets tout au long de son pipeline. Une commande comme Get-Process ne te renvoie pas une liste de lignes à parser : elle te renvoie de vrais objets .NET, avec leurs propriétés et leurs méthodes, directement exploitables par la commande suivante. Une fois qu’on a compris ça, on ne revient plus en arrière.

    Cette approche change tout pour l’automatisation IT :

    • Multiplateforme : depuis PowerShell 7, tu peux faire tourner le même script sur Windows, Linux et macOS.
    • Intégré à l’écosystème Microsoft : Active Directory, Azure, Microsoft 365, Exchange — tout s’administre en PowerShell.
    • Un socle stable : la version 7.6, sortie en LTS (Long Term Support) en 2026 et bâtie sur .NET 10 LTS, te garantit plusieurs années de support pour tes scripts de production.
    • Une communauté immense : des modules prêts à l’emploi sur la PowerShell Gallery pour à peu près tous tes besoins d’administration.

    Si tu veux creuser, la documentation officielle Microsoft Learn sur PowerShell reste la référence la plus à jour.

    Les bases pour automatiser efficacement avec PowerShell

    Le pipeline orienté objet

    La force de PowerShell tient dans sa syntaxe verbe-nom (Verbe-Nom), cohérente sur l’ensemble des cmdlets : Get- pour lire, Set- pour modifier, New- pour créer, Remove- pour supprimer. Une fois ce principe assimilé, tu devines souvent la bonne commande sans avoir besoin d’ouvrir la documentation.

    # Lister les 5 processus qui consomment le plus de mémoire
    Get-Process | Sort-Object WorkingSet -Descending | Select-Object -First 5 Name, WorkingSet
    

    Filtrer et transformer sans réinventer la roue

    Les cmdlets Where-Object, ForEach-Object et Select-Object couvrent l’immense majorité de tes besoins de filtrage et de transformation de données, sans que tu aies à écrire de boucles manuelles.

    5 scripts PowerShell pour automatiser tes tâches IT quotidiennes

    1. Nettoyage automatique des fichiers temporaires

    $seuil = (Get-Date).AddDays(-30)
    Get-ChildItem -Path "C:\Temp" -Recurse -File |
        Where-Object { $_.LastWriteTime -lt $seuil } |
        Remove-Item -Force -WhatIf
    

    Le paramètre -WhatIf simule l’action sans rien supprimer — garde toujours ce réflexe pour tester un script avant de le lancer en conditions réelles.

    2. Rapport d’utilisation disque automatique

    Get-PSDrive -PSProvider FileSystem | ForEach-Object {
        [PSCustomObject]@{
            Lecteur      = $_.Name
            UtiliseGo    = [math]::Round($_.Used / 1GB, 2)
            LibreGo      = [math]::Round($_.Free / 1GB, 2)
            PourcentLibre = [math]::Round(($_.Free / ($_.Used + $_.Free)) * 100, 1)
        }
    } | Export-Csv -Path "rapport-disques.csv" -NoTypeInformation
    

    3. Création en masse d’utilisateurs Active Directory via CSV

    Import-Csv "nouveaux-utilisateurs.csv" | ForEach-Object {
        New-ADUser -Name $_.Nom -SamAccountName $_.Login `
            -Department $_.Service -Enabled $true `
            -AccountPassword (ConvertTo-SecureString $_.MotDePasse -AsPlainText -Force)
    }
    

    4. Surveillance et redémarrage automatique d’un service critique

    $service = Get-Service -Name "Spooler"
    if ($service.Status -ne 'Running') {
        Restart-Service -Name "Spooler" -Force
        Write-EventLog -LogName Application -Source "Script-Monitoring" `
            -EventId 1000 -Message "Service Spooler redémarré automatiquement"
    }
    

    5. Sauvegarde planifiée avec rotation (conserver les 7 derniers jours)

    $dest = "D:\Backups\$(Get-Date -Format 'yyyy-MM-dd')"
    Copy-Item -Path "C:\Data" -Destination $dest -Recurse
    
    Get-ChildItem "D:\Backups" | Where-Object {
        $_.CreationTime -lt (Get-Date).AddDays(-7)
    } | Remove-Item -Recurse -Force
    

    Un prochain article détaillera comment planifier ces scripts avec le Planificateur de tâches Windows et cron sous Linux.

    Nouveautés de PowerShell 7.6 LTS qui améliorent l’automatisation

    Sortie en 2026 et bâtie sur .NET 10 LTS, la version 7.6 apporte plusieurs améliorations bien concrètes si tu écris des scripts d’automatisation au quotidien :

    • Complétion intelligente : des dizaines d’améliorations de l’auto-complétion (chemins, valeurs de paramètres, noms de modules abrégés) qui te font gagner du temps en console.
    • Get-Clipboard -Delimiter : tu contrôles précisément la façon dont le contenu du presse-papiers est découpé.
    • Register-ArgumentCompleter -NativeFallback : tu peux créer un compléteur générique pour tes commandes natives.
    • Get-Command -ExcludeModule et Join-Path qui accepte désormais un tableau de chemins pour -ChildPath.
    • PSForEach() et PSWhere() comme alias des méthodes intrinsèques, pour des scripts plus concis.
    • Quatre fonctionnalités expérimentales passées en mainstream : PSFeedbackProvider, PSNativeWindowsTildeExpansion, PSRedirectToVariable et PSSubsystemPluginModel.

    Pour le détail des changements et la marche à suivre, j’ai consacré un article complet à PowerShell 7.6 LTS.

    Si tu gères une infrastructure de production, le statut LTS de la 7.6 est l’argument qui compte vraiment : c’est la version à privilégier pour des scripts qui doivent rester stables plusieurs années.

    Bonnes pratiques pour des scripts PowerShell robustes et maintenables

    • Gère les erreurs explicitement avec des blocs try/catch plutôt que de laisser un script s’arrêter silencieusement.
    • Teste toujours avec -WhatIf et -Confirm avant d’exécuter un script qui modifie ou supprime des données.
    • Journalise tes actions (fichier de log ou Event Log Windows) pour pouvoir diagnostiquer un script planifié qui a échoué pendant la nuit — ça t’évite bien des devinettes le lendemain matin.
    • Versionne tes scripts dans un dépôt Git — ça te permet de revenir en arrière si une modification casse un script critique, exactement comme tu le ferais pour du code applicatif.
    • Évite les droits administrateur par défaut : n’exécute en élévation que les parties du script qui en ont réellement besoin.
    • Teste avec Pester, le framework de tests unitaires de l’écosystème PowerShell, dès que tes scripts sont destinés à tourner en production de façon récurrente.
    • Gère tes modules avec PSResourceGet, qui remplace PowerShellGet v2 : voici comment migrer tes scripts.

    FAQ

    Qu’est-ce que PowerShell et en quoi diffère-t-il de CMD ou Bash ?

    PowerShell est à la fois un interpréteur en ligne de commande et un langage de script. Contrairement à CMD ou Bash qui manipulent du texte, PowerShell fait circuler de vrais objets .NET entre les commandes, ce qui simplifie considérablement le filtrage et la transformation de données.

    Faut-il être développeur pour automatiser avec PowerShell ?

    Non, pas besoin. Les bases (cmdlets, pipeline, variables) sont accessibles dès que tu es à l’aise en administration système, sans expérience de développement préalable. La logique de programmation plus avancée (fonctions, modules) vient progressivement avec la pratique.

    PowerShell fonctionne-t-il sur Linux et macOS ?

    Oui, depuis PowerShell 7 (basé sur .NET Core puis .NET), tu peux l’installer sur Windows, Linux et macOS.

    Comment planifier l’exécution automatique d’un script PowerShell ?

    Sous Windows, via le Planificateur de tâches (Task Scheduler) ; sous Linux, via cron en appelant pwsh. Pense à rediriger la sortie vers un fichier de log pour pouvoir diagnostiquer tes exécutions automatiques.

    Quelle est la différence entre PowerShell 5.1 et PowerShell 7.6 ?

    PowerShell 5.1 est la version historique, limitée à Windows et figée en termes d’évolutions. PowerShell 7.6 est multiplateforme, plus performante, bâtie sur .NET 10 LTS, et bénéficie d’un support à long terme — c’est celle à choisir pour tout nouveau script.

    Conclusion

    Pas besoin de maîtriser PowerShell à 100 % pour commencer à gagner du temps. Le bon réflexe : repère une tâche répétitive de moins de 15 minutes, automatise-la cette semaine avec un script simple, puis itère. Les cinq scripts présentés ici sont un point de départ — à toi de les adapter à ton environnement, en gardant en tête les bonnes pratiques de gestion d’erreurs et de tests avant toute mise en production.