Bonjour,
Merci pour cette remarque.
Pour clarifier : Set-ExecutionPolicy -Scope CurrentUser Bypass modifie la policy de façon persistante, ce qui évite de passer -ExecutionPolicy Bypass à chaque appel. Dans notre solution, ce paramètre est déjà passé ponctuellement à l'appel du wrapper, donc le résultat fonctionnel est identique.
Sur la sécurité : l'ExecutionPolicy PowerShell n'est pas à proprement parler une barrière de sécurité — Microsoft le précise lui-même, c'est un garde-fou contre l'exécution accidentelle, pas un mécanisme anti-malware. Elle ne bloque que le lancement de fichiers .ps1 ; elle n'empêche ni les commandes tapées directement en console, ni -EncodedCommand, ni l'exécution d'un .exe/.bat/macro Office. Le passage de Restricted à Bypass au scope CurrentUser n'élargit donc pas significativement la surface d'attaque pour un utilisateur pouvant déjà lancer powershell.exe.
Dans un contexte sans droits admin locaux ni droits réseau étendus (lecteurs de groupe et lecteur personnel uniquement), les risques réels résideraient plutôt dans l'exploitation d'une faille locale d'élévation de privilèges, ou dans l'abus des droits d'écriture déjà existants — deux points indépendants de l'ExecutionPolicy.
Nous rejoignons donc votre prudence : Bypass en mode persistant reste à réserver au testing. Dans notre cas, le paramètre étant appliqué uniquement à l'appel, l'impact sécurité demeure limité.
Cdt.
Le support
