Le mail est arrivé un lundi matin, sujet « Windows planté sur le poste de Karim » : rien de bien méchant en soi, un simple gel d’explorateur, mais assez pour que je reprenne le dossier PowerToys que j’avais lancé trois semaines plus tôt chez un client PME de douze postes. Ce texte est le compte-rendu de ce déploiement, des ratés compris — parce que le download PowerToys en lui-même n’est jamais le problème. C’est tout ce qui vient après qui décide si l’outil tient ou repart à la poubelle au bout d’une semaine.
Pourquoi ce client voulait PowerToys
Le contexte : une PME de services numériques, douze postes Windows 11, une équipe mêlant techniciens support et deux développeurs. Le responsable IT m’avait contacté après avoir vu FancyZones en démonstration chez un confrère — l’idée de fenêtres organisées automatiquement sur des écrans doubles avait tapé dans l’œil de toute l’équipe. S’y ajoutait un besoin très concret : PowerToys Run pour remplacer une recherche Windows jugée trop lente, et le module Awake pour éviter que certains postes de test ne s’endorment pendant des builds longues.
Sur le papier, un download PowerToys via le Microsoft Store ou le package MSI GitHub, une configuration standard, et roulez jeunesse. Dans les faits, ça a pris quatre jours de plus que prévu à cause de trois incidents qui méritent d’être détaillés, parce qu’ils reviennent systématiquement dans mes déploiements PowerToys en entreprise.
Étape 1 : le download PowerToys et le choix du canal d’installation
Premier arbitrage technique : Microsoft Store ou package MSI autonome depuis le dépôt GitHub officiel de PowerToys. Sur un parc de douze machines, j’ai écarté le Store d’entrée de jeu — deux des postes avaient une stratégie de groupe restreignant l’accès au Store pour raisons de conformité interne, héritée d’un ancien audit de sécurité. Le MSI signé Microsoft, récupéré sur la page de releases GitHub, contourne ce blocage et permet en plus un déploiement silencieux via ligne de commande, ce qui compte quand on gère douze postes et pas un seul.
La commande utilisée pour l’installation silencieuse a été la suivante :
msiexec /i PowerToysSetup-0.87.1-x64.msi /quiet /norestartSur dix postes, ça s’est déroulé sans accroc. Sur les deux restants, le service MSI a renvoyé une erreur 1603 générique — le classique message qui ne dit rien et qui oblige à éplucher le journal d’installation. La cause, une fois les logs verbeux activés avec /l*v install.log, s’est révélée être un résidu d’une installation PowerToys antérieure, mal désinstallée par l’utilisateur lui-même six mois plus tôt. Le dossier %LOCALAPPDATA%MicrosoftPowerToys contenait encore des fichiers de configuration verrouillés par un processus fantôme dans le Gestionnaire des tâches. Un redémarrage puis une suppression manuelle du dossier avant relance du MSI a réglé le cas sur les deux postes.
Étape 2 : le conflit de raccourci qui a bloqué toute l’équipe dev
C’est là que les choses sont devenues intéressantes, et pas dans le bon sens. Le lendemain de l’installation, les deux développeurs ont signalé que leur raccourci habituel pour dupliquer une ligne dans leur IDE — Ctrl+Alt+D — ne fonctionnait plus. Après vérification, le coupable était FancyZones : le raccourci par défaut pour activer l’éditeur de zones dans certaines versions de PowerToys recoupe des combinaisons couramment réassignées dans les IDE JetBrains et VS Code selon les extensions installées.
Le diagnostic a pris plus de temps que la résolution, en grande partie parce que le symptôme ne pointait pas vers PowerToys de prime abord. Le raccourci semblait simplement « mort », sans message d’erreur, sans log applicatif visible côté IDE. J’ai fini par isoler le problème en désactivant PowerToys entièrement via l’icône de la zone de notification puis en testant à nouveau le raccourci : fonctionnement immédiat. Confirmation faite, retour dans les paramètres PowerToys, section FancyZones, onglet Raccourcis clavier.
La correction a consisté à réassigner tous les raccourcis PowerToys par défaut susceptibles d’entrer en collision avec les habitudes de développement : FancyZones Editor déplacé sur Ctrl+Win+Alt+D, et surtout, activation du module Shortcut Guide temporaire pour que chaque développeur vérifie lui-même l’absence de conflit avec ses extensions IDE spécifiques avant validation finale. Cette étape manuelle par utilisateur, bien que fastidieuse, s’est révélée indispensable : les deux développeurs n’avaient pas les mêmes extensions actives, donc pas les mêmes zones de conflit.
Étape 3 : la mise à jour automatique qui a cassé un poste
Le troisième incident est arrivé une semaine plus tard, sans intervention de ma part. PowerToys intègre une mise à jour automatique activée par défaut, et l’un des postes techniciens est passé de la version 0.86 à 0.87 pendant la nuit. Au matin, l’utilisateur signalait que PowerToys Run — le lanceur qu’il utilisait dix fois par jour — ne s’ouvrait plus du tout au raccourci habituel Alt+Espace.
Investigation sur place : le service PowerToys apparaissait bien actif dans le Gestionnaire des tâches, aucune erreur visible, mais aucune réaction au raccourci. Premier réflexe, vérifier les paramètres du module Run : toujours activé, raccourci toujours configuré sur Alt+Espace. C’est en croisant avec le journal des événements Windows que j’ai trouvé la piste : un conflit silencieux avec une mise à jour concurrente de l’utilitaire de recherche tiers déjà installé sur ce poste précis, lequel avait lui aussi été mis à jour la même nuit et avait repris la main sur le même raccourci clavier au niveau du hook système, sans avertissement ni message d’erreur des deux côtés.
La solution appliquée sur ce poste a été double : désinstallation complète de l’utilitaire tiers redondant — de toute façon voué à disparaître puisque PowerToys Run le remplaçait dans l’usage quotidien — puis redémarrage du service PowerToys via un arrêt/relance complet depuis le Gestionnaire des tâches plutôt qu’un simple toggle dans les paramètres, qui n’avait pas suffi à libérer le hook clavier. Après ce cycle complet, Alt+Espace a repris son fonctionnement normal.
Ce que ce déploiement m’a appris
Trois enseignements ressortent de ce cas, et je les applique désormais systématiquement avant tout déploiement PowerToys sur un parc de plus de cinq postes.
- Auditer les raccourcis existants avant l’installation. Sur un poste de développeur en particulier, un inventaire rapide des raccourcis actifs dans l’IDE principal évite la majorité des conflits FancyZones et PowerToys Run.
- Désactiver la mise à jour automatique sur les postes de production stables. Le module de mise à jour PowerToys, accessible dans Paramètres généraux, peut être basculé sur vérification manuelle. Sur ce client, j’ai laissé la mise à jour automatique active uniquement sur les deux postes de test, jamais sur les dix postes de production.
- Nettoyer les anciennes installations avant toute réinstallation. L’erreur MSI 1603 rencontrée sur deux postes provenait exclusivement de résidus d’une installation antérieure mal désinstallée. Un passage par l’outil de désinstallation complète, dossier
%LOCALAPPDATA%compris, avant tout nouveau download PowerToys, aurait évité l’incident.
Bilan à trois semaines
Sur les douze postes, PowerToys tourne aujourd’hui sans incident supplémentaire. Les deux développeurs utilisent FancyZones quotidiennement avec des raccourcis reconfigurés qui ne touchent plus à leurs habitudes IDE. Le technicien du troisième incident a retrouvé PowerToys Run et s’en sert désormais pour lancer ses outils de diagnostic plus vite qu’avant. Le responsable IT, lui, a validé le principe d’un modèle de configuration exporté — le fichier de paramètres PowerToys peut être sauvegardé et réimporté via l’option dédiée dans les paramètres généraux — pour les futurs postes du parc, ce qui évitera de refaire à la main les ajustements de raccourcis à chaque nouvelle machine.
Ce que je retiens, au-delà du cas précis : PowerToys est un outil solide et gratuit qui mérite sa popularité, mais son déploiement en environnement professionnel n’a rien d’un simple double-clic. Chaque conflit rencontré ici — raccourci IDE, mise à jour nocturne, résidu d’installation — est prévisible et évitable avec une checklist de pré-déploiement. C’est cette checklist, construite incident après incident, qui fait la différence entre un outil adopté durablement par une équipe et un outil désinstallé au premier problème.
Je reviens sur un point voisin dans un déploiement Docker Desktop, et un autre point utile est couvert dans le choix des fonds Teams.
Pour approfondir, consultez le dépôt officiel de PowerToys ainsi que ses versions publiées.