⚡ 🪦 Microsoft enterre PowerShell 2.0 : adieu douce obsolescence, bonjour modernité

Il fut un temps où PowerShell 2.0 régnait en maître sur nos postes. 2009, les dino-scripts gambadaient, Get-Processsuffisait à se sentir DevOps, et les malwares pouvaient dérouler des .ps1 non signés sans demander la carte d’identité.
Août 2025 : Microsoft retire officiellement PowerShell 2.0. Pas de fleurs, pas d’hommage national — juste un “Supprimé des fonctionnalités”. Le vieux tournevis est parti, place à la perceuse connectée.

🕰️✨ Ce qui était bien avant (PowerShell 2.0)

• Compat’ en béton : tournait partout, de Windows 7 à Server 2008 R2.
• Simplicité rustique : pas de JSON, pas de REST, juste des cmdlets basiques et de la logique.
• Tolérant au chaos : scripts non signés ? Pas de souci. Modules antiques ? Pareil.
• Prévisible : pas de mise à jour intempestive, pas d’API qui change tous les mois.
• Culture commune : tout l’écosystème IT avait au moins un script qui ne marchait que sous 2.0 — un classique.

Verdict : comme Internet Explorer 6… dangereux mais “indispensable” pour une poignée d’outils qu’on n’a jamais pris le temps de réécrire.

🔧🔁 Ce qui change (PowerShell 7.x et le monde moderne)

• Multiplateforme : Windows, Linux, macOS — même script, trois cibles (et trois fois plus de tests).
• Sécurité : politiques d’exécution strictes, signatures, intégration Defender/AMS, ConstrainedLanguageMode.
• Perf’ : pipeline optimisé, parallélisme natif (ForEach-Object -Parallel).
• Écosystème : PowerShell Gallery (Install-Module), versions qui bougent, modules cloud à jour.
• Interop : JSON/YAML/REST en première classe, Invoke-RestMethod qui ne pleure plus.
• DevOps-ready : CI/CD (GitHub Actions, Azure DevOps, Jenkins), conteneurs, scripts reproductibles.
• .NET moderne : basé sur .NET (Core) 6/8 — plus rapide, plus portable.

🚀🔮 Ce que ce sera maintenant

1. Migration obligatoire : 2.0 n’étant plus livré, vos scripts devront viser 5.1 ou 7.x.
2. Hybride raisonnable : 5.1 reste le “Windows natif”, 7.x devient le “standard portable”.
3. Discipline : signature des scripts, modules versionnés, revue sécurité.
4. Cloud first : M365, Azure, Graph, Exchange Online — l’autoroute est goudronnée jusqu’à Redmond.
5. Moins d’hérésie : adieux aux cmdlets bizarres non maintenues ; bonjour aux modules officiels.

✅📈 Les plus

• Beaucoup plus sûr : moins de surface d’attaque, meilleure traçabilité.
• Plus rapide : parallélisme et perf’ en hausse.
• Plus actuel : JSON/REST natifs, API modernes, tooling VS Code.
• Portable : même base de code sur serveurs Windows et Linux.
• Écosystème vivant : modules maintenus, gallery centralisée.

❌🧩 Les moins

• Compat’ cassée : certains vieux scripts/modules ne passeront pas sans refonte.
• Courbe d’apprentissage : nouvelles syntaxes, bonnes pratiques à intégrer.
• Dette technique exposée : les “quick & dirty” de 2009 remontent à la surface.
• Gouvernance : signature, politiques d’exécution, pipeline de déploiement à formaliser.

🧪🔍 Ce qui change concrètement (avant / après)

Filtrer des services

• 2.0 :powershellCopierModifierGet-Service | Where-Object { $_.Status -eq "Running" }
• 7.x (plus lisible et rapide) :
  powershell
  Get-Service | Where Status -eq Running

Paralléliser des tâches

• 2.0 : non, sauf bricolage lourd / jobs manuels
• 7.x :
  powershell
  1..5 | ForEach-Object -Parallel { "Tâche $_ - $(Get-Date)" }

Consommer une API JSON

• 2.0 : verbeux, fragile
• 7.x :
  powershell
  $data = Invoke-RestMethod -Uri "https://api.example.com/items" $data | Where Price -gt 100 | Select Name, Price

Gestion de modules

• 2.0 : copie manuelle, GAC, folklore
• 7.x :
  powershell
  Install-Module Microsoft.Graph -Scope CurrentUser Import-Module Microsoft.Graph

Sécurité / exécution

• 2.0 : scripts non signés ? “Passe.”
• 7.x : politique d’exécution, signature recommandée, journalisation renforcée.

🧭📋 Plan de migration express (pragmatique et pas chiant)

1. Inventaire 🗂️
   • Liste les scripts qui tournent encore en 2.0 (tâches planifiées, GPO, outils tiers).
   • Identifie les modules old-school (Exchange on-prem, WMI legacy, etc.).
2. Tests rapides 🧪
   • Essaie en 5.1 puis en 7.x.
   • Note ce qui casse : Where-Object, chemins, encodage, modules non portés.
3. Refactor minimal ✂️
   • Remplace les vieux patterns (Where-Object { $_.x }) par leurs versions modernes.
   • Évite les dépendances WMI obsolètes si un module CIM/REST existe.
4. Sécurité 🔐
   • Mets Set-ExecutionPolicy RemoteSigned (ou AllSigned selon ta politique).
   • Signe les scripts de prod, active la journalisation (transcription, module logging).
5. Packaging & CI 🏗️
   • Versionne tes scripts (Git), ajoute des tests basiques (Pester).
   • Déploie via pipeline (GitHub Actions/Azure DevOps) — fini le copier-coller RDP.
6. Conduite du changement 📣
   • Mini-guide utilisateur (“les 10 différences qui piquent”),
   • Sprint de nettoyage technique,
   • Tableau de bord migration (ce qui reste à porter / remplacé / supprimé).

🧰🆚 Tableau minute “Avant vs Maintenant”

🎯📌 Conclusion (sarcasme dosé, café serré)

Microsoft n’a pas “cassé ce qui marchait” : il a retiré ce qui mettait des portes ouvertes dans vos SI.
PowerShell 7.x est objectivement meilleur — plus rapide, plus sûr, plus adapté aux stacks 2025. Oui, ça demande du boulot : réécrire deux-trois dinosaures, signer des scripts, documenter un pipeline. Mais c’est un effort qu’on aurait dû faire hier.

Morale : si votre prod dépend encore d’un script 2.0 trouvé sur un forum moldave en 2011, la panne n’est pas “à cause de Microsoft”. Elle est à cause du temps qui passe.

🛠️📎 Bonus : snippet “prêt à migrer”

powershell
# Lancer un script en 7.x si présent, sinon fallback 5.1
$ps7 = "${env:ProgramFiles}\PowerShell\7\pwsh.exe"
if (Test-Path $ps7) { & $ps7 -File ".\run.ps1" } else { powershell.exe -File ".\run.ps1" }

Avec Microsoft, c’est toujours un peu comme recevoir un cadeau emballé par un magicien :
tu sais qu’il y a quelque chose dedans, tu sais que ça brille… mais tu n’es pas sûr que ce sera vraiment ce que tu voulais.

PowerShell 7.x a le potentiel d’être un vrai upgrade :

• plus rapide,
• plus sûr,
• plus “cloud-ready”,
• et potentiellement moins sujet aux failles “Made in Legacy 2009™”.

Mais… on connaît la chanson :

• migration parfois douloureuse,
• scripts qui crient à la mort,
• dépendances tierces qui cassent,
• et nouveautés qui arrivent avec leur lot de bugs de jeunesse.

Bref, ça peut être bien, mais comme on dit en IT : « On fait confiance… mais on garde un backup et un rollback plan. »😎

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com