Installer des applications en masse avec winget : une configuration Windows propre en 5 minutes

Ce qu’est winget (et ce que ce n’est pas)

winget est le gestionnaire de paquets en ligne de commande de Microsoft pour Windows. Il installe et met à niveau des applications depuis des sources configurées, avec un flux de travail qui ressemble fortement à l’univers Linux — parce que, oui, nous avons tous vu à quel point cela peut être productif.

Mais ce n’est pas de la magie, et ce n’est pas un remplacement de golden image à lui seul. C’est un moyen fiable et automatisable de télécharger des installateurs, de les exécuter et de suivre ce qui est installé. Vous devez toujours penser comme un opérateur : idempotence, sources, frontières de confiance et modes de défaillance.

Ce que winget fait bien

• Reproductibilité : vous pouvez définir un ensemble d’apps et le réappliquer sur n’importe quelle machine.
• Vitesse : le travail parallélisable devient un effort linéaire : un script, une exécution.
• Mises à jour : il peut auditer et mettre à jour de nombreuses apps en une seule passe.
• Faible friction : il est déjà présent sur les Windows 10/11 modernes via App Installer (ou facile à ajouter).

Ce que winget gère mal (ou pas du tout)

• Gestion de configuration poussée : il ne configurera pas vos clés de registre, dotfiles, certificats ou proxies d’entreprise. Vous aurez toujours besoin de scripts/MDM pour ça.
• Tous les éditeurs : la couverture est bonne, pas totale. Certains fournisseurs résistent aux installations silencieuses comme si c’était un trait de caractère.
• Mode offline-first : winget suppose l’accès réseau aux sources. Vous pouvez pré-stager des éléments, mais ce n’est pas son mode par défaut.
• Tolérance à l’ambiguïté : la recherche par nom peut choisir la mauvaise entrée si vous ne figez pas les IDs et les sources.

Idée paraphrasée (attribuée) : Werner Vogels a souligné qu’il faut construire pour l’échec, pas seulement pour le succès. C’est l’état d’esprit approprié pour les installations en masse : votre plan doit inclure ce que vous faites quand quelque chose n’installe pas.

Faits intéressants et brève histoire

Un peu de contexte vous aide à mieux décider avec winget. Voici des faits concrets, non triviaux, qui comptent opérationnellement :

1. winget a été publié en 2020 sous le nom Windows Package Manager, après que Microsoft ait observé des développeurs réinventer des installateurs avec des scripts et des douleurs.
2. Il est distribué via « App Installer » sur de nombreux systèmes, ce qui signifie que le client winget peut être mis à jour en dehors des grandes versions de Windows.
3. Les « IDs » de paquets sont la poignée stable (comme Git.Git), tandis que les noms sont marketing. Traitez toujours les noms comme des entrées non fiables.
4. winget peut installer depuis plusieurs sources (repo communautaire, Microsoft Store, et sources privées/entreprise), et le choix de la source influence la confiance et le comportement d’installation.
5. Le support d’installation silencieuse dépend de la technologie d’installateur (MSI, Inno Setup, NSIS, EXE custom). winget aide, mais il ne peut pas réécrire la logique d’un installateur éditeur.
6. Il peut exporter/importer l’ensemble des apps d’une machine en JSON, ce qui rend « je veux cette configuration partout » un vrai flux de travail, pas un vœu.
7. Certaines installations nécessitent une élévation admin même si l’app paraît user-level, à cause de drivers, extensions shell ou composants système.
8. Les apps du Store se comportent différemment des classiques Win32 : résolution des dépendances et contexte utilisateur deviennent intéressants en entreprise.
9. Les proxies d’entreprise cassent les setups naïfs car les sources sont des endpoints HTTPS et les installateurs sont des téléchargements distants ; les échecs winget ressemblent souvent à un « réseau aléatoire » jusqu’à ce que vous vérifiiez les bons logs.

Le plan en 5 minutes : de zéro à entièrement provisionné

« Cinq minutes » est réaliste quand vous savez déjà ce que vous voulez installer et que vous ne passez pas ces cinq minutes à faire défiler des sites comme en 2009.

Ce que vous optimisez

Nous optimisons pour des résultats reproductibles. La machine doit se retrouver avec les mêmes apps à chaque fois, quel que soit l’opérateur. Deuxième priorité : vitesse. Troisième : prompts minimaux.

Workflow minimum viable

1. Vérifier que winget existe et que les sources sont saines.
2. Rechercher/figer les IDs de paquets (pas les noms) depuis la source prévue.
3. Installer en une commande (ou importer une liste JSON triée).
4. Vérifier l’installation et capturer ce qui a échoué.
5. Mettre à jour tout et revérifier.

Une remarque opérationnelle : les installations en masse échouent en grappes quand vous avez une dépendance partagée comme le réseau, le proxy ou les droits admin. Ne poursuivez pas chaque app individuellement ; traquez la contrainte partagée.

Choisir les paquets : IDs, sources et pourquoi les noms trompent

Si vous retenez une habitude de cet article, retenez celle-ci : verrouillez les IDs des paquets et spécifiez les sources. Chercher « VS Code » peut correspondre à plusieurs paquets, forks ou entrées de nom similaire. Votre futur vous ne vous remerciera pas pour des installations surprises.

Les IDs valent mieux que les noms

Les IDs sont conçus pour être des identifiants stables. Les noms sont conçus pour être cliquables. Vous ne cliquez pas. Utilisez les IDs.

La source compte : confiance, cadence de mise à jour et mécanique d’installation

winget peut tirer du dépôt communautaire (winget source), du Microsoft Store (msstore source) et potentiellement de sources d’entreprise. Elles diffèrent sur :

• Frontière de confiance : qui l’a curaté, qui l’a signé et à quelle vitesse les problèmes sont corrigés.
• Comportement d’installateur : les installations du Store se comportent souvent de façon plus « gérée » mais peuvent être délicates en contexte système.
• Disponibilité des versions : vous n’obtiendrez peut‑être pas la même version depuis deux sources.

Blague n°1 : La seule chose plus ambiguë que « dernière version » est « ça marche sur ma machine ».

Soyez explicite sur la portée : machine-wide vs utilisateur

Certaines packages s’installent par utilisateur, d’autres au niveau système, certains vous laissent choisir via des flags. En environnement entreprise, ça compte parce que le compte qui lance l’installation n’est peut‑être pas l’utilisateur principal. Si vous construisez un poste dev pour vous-même, par‑utilisateur suffit. Si vous déployez une flotte, system‑wide est généralement ce que vous voulez — sauf contraintes de licence ou politique.

Tâches pratiques (commandes + sortie + décisions)

Voici des tâches opérationnelles réelles que vous effectuerez pour rendre les installations en masse ennuyeuses. Chaque tâche inclut une commande, une sortie représentative, ce que signifie la sortie, et la décision suivante.

Tâche 1 : Confirmer que winget est installé (et quelle version)

cr0x@server:~$ winget --version
v1.7.11261

Ce que ça signifie : Le client est présent et exécutable. La version compte car les options et le comportement d’import/export ont évolué au fil du temps.

Décision : Si la commande est introuvable ou que la version est ancienne, corrigez cela avant de diagnostiquer quoi que ce soit d’autre. Ne déboguez pas des installations d’apps avec un outil défaillant.

Tâche 2 : Vérifier la santé des sources (le coupable caché habituel)

cr0x@server:~$ winget source list
Name     Argument                                                         Type
--------------------------------------------------------------------------------
winget   https://winget.azureedge.net/cache                               Microsoft.PreIndexed.Package
msstore  https://storeedgefd.dsx.mp.microsoft.com/v9.0                     Microsoft.Rest

Ce que ça signifie : winget connaît les sources par défaut et leurs endpoints.

Décision : Si msstore manque dans un environnement qui dépend des apps du Store, ajoutez‑le ou cessez d’attendre des paquets du Store.

Tâche 3 : Mettre à jour les sources (quand les résultats semblent obsolètes)

cr0x@server:~$ winget source update
Updating all sources...
Done

Ce que ça signifie : Les index locaux sont rafraîchis. Si vous obtenez « package not found » pour quelque chose que vous savez exister, c’est la première étape.

Décision : Si la mise à jour échoue, votre goulot est réseau/proxy/SSL, pas le paquet.

Tâche 4 : Rechercher un paquet, puis arrêter de faire confiance au nom

cr0x@server:~$ winget search "Visual Studio Code"
Name               Id                Version   Source
------------------------------------------------------
Visual Studio Code  Microsoft.VisualStudioCode 1.86.2    winget
VSCodium           VSCodium.VSCodium  1.86.2    winget

Ce que ça signifie : Plusieurs résultats plausibles. L’ID est l’ancre.

Décision : Choisissez l’ID correct. En environnement géré, standardisez‑le et n’autorisez pas les utilisateurs à improviser.

Tâche 5 : Inspecter un paquet avant l’installation (métadonnées et type d’installateur)

cr0x@server:~$ winget show Microsoft.VisualStudioCode
Found Visual Studio Code [Microsoft.VisualStudioCode]
Version: 1.86.2
Publisher: Microsoft Corporation
Installer Type: exe
Installer Url: https://update.code.visualstudio.com/1.86.2/win32-x64-user/stable

Ce que ça signifie : Vous voyez ce que vous êtes sur le point d’exécuter, y compris le type d’installateur et l’URL.

Décision : Si le type est exe, le comportement silencieux peut varier. Attendez‑vous à des cas limites ; testez sur une VM propre avant de déployer à grande échelle.

Tâche 6 : Installer un paquet avec ID et source explicites

cr0x@server:~$ winget install --id Microsoft.VisualStudioCode --source winget --accept-package-agreements --accept-source-agreements
Found Visual Studio Code [Microsoft.VisualStudioCode] Version 1.86.2
This application is licensed to you by its owner.
Downloading https://update.code.visualstudio.com/1.86.2/win32-x64-user/stable
  ██████████████████████████████  95.2 MB / 95.2 MB
Successfully installed

Ce que ça signifie : winget a récupéré l’installateur et l’a exécuté avec succès.

Décision : Si des invites apparaissent, vous avez omis les flags d’accord ou l’installateur ignore le mode silencieux. Décidez d’accepter l’invite, de remplacer le paquet, ou de préconfigurer les switches via d’autres outils.

Tâche 7 : Installer en masse une liste triée en une commande (utile pour bootstrap)

cr0x@server:~$ winget install --id Git.Git --source winget --accept-package-agreements --accept-source-agreements
Found Git [Git.Git] Version 2.44.0
Downloading https://github.com/git-for-windows/git/releases/download/v2.44.0.windows.1/Git-2.44.0-64-bit.exe
  ██████████████████████████████  64.1 MB / 64.1 MB
Successfully installed

Ce que ça signifie : Installation d’un seul paquet. Mais vous enchaînerez généralement ces commandes dans un script pour une expérience « une exécution ».

Décision : Si vous installez beaucoup d’apps, passez à un fichier d’import pour pouvoir revoir les changements via une revue de code plutôt que d’éditer des scripts à la volée.

Tâche 8 : Exporter l’ensemble des apps de la machine (pour le cloner)

cr0x@server:~$ winget export -o C:\Temp\winget-export.json
Exported package list to: C:\Temp\winget-export.json

Ce que ça signifie : Vous avez maintenant un snapshot JSON des paquets détectables par winget.

Décision : Traitez cet export comme un point de départ, pas comme un évangile. Enlevez le superflu personnel et figez ce que votre organisation supporte réellement.

Tâche 9 : Importer une liste d’apps (le coup « cinq minutes »)

cr0x@server:~$ winget import -i C:\Temp\winget-export.json --accept-package-agreements --accept-source-agreements
Found 12 packages to install.
Installing package 1 of 12: Git [Git.Git]
Successfully installed
Installing package 2 of 12: Visual Studio Code [Microsoft.VisualStudioCode]
Successfully installed
Installing package 3 of 12: Python 3.12 [Python.Python.3.12]
Successfully installed
1 package(s) failed to install.

Ce que ça signifie : winget a parcouru la liste. Un paquet a échoué. C’est normal à l’échelle.

Décision : Ne relancez pas aveuglément. Identifiez le paquet en échec et déterminez s’il s’agit d’un problème transitoire de téléchargement, d’un problème de permissions ou d’une interaction avec l’installateur.

Tâche 10 : Lister ce que winget pense être installé (vérification)

cr0x@server:~$ winget list
Name                     Id                         Version
-----------------------------------------------------------
Git                      Git.Git                    2.44.0
Visual Studio Code       Microsoft.VisualStudioCode 1.86.2
Python 3.12.2            Python.Python.3.12         3.12.2
7-Zip 23.01 (x64)        7zip.7zip                  23.01

Ce que ça signifie : C’est la vue de winget, basée sur l’enregistrement des apps installées et les mappages de paquets.

Décision : Si une app est installée mais non listée, winget peut ne pas la gérer. Décidez de la laisser hors bande ou de passer à un équivalent géré par winget.

Tâche 11 : Trouver les mises à jour disponibles (ne pas réinstaller ; mettre à jour)

cr0x@server:~$ winget upgrade
Name               Id                Version Available Source
------------------------------------------------------------
Git                Git.Git           2.43.0  2.44.0    winget
7-Zip              7zip.7zip         23.00   23.01     winget

Ce que ça signifie : Vous êtes en retard sur quelques paquets.

Décision : Dans une flotte, les mises à jour doivent être testées et validées par vagues. Sur une machine perso, mettez à jour. Sur des hôtes de production, soyez conservateur.

Tâche 12 : Mettre à jour tout (quand vous contrôlez l’aire de diffusion)

cr0x@server:~$ winget upgrade --all --accept-package-agreements --accept-source-agreements
Found 2 upgrades.
Upgrading Git [Git.Git]...
Successfully installed
Upgrading 7-Zip [7zip.7zip]...
Successfully installed

Ce que ça signifie : winget a exécuté des mises à jour sur les paquets installés.

Décision : Si c’est une image partagée, capturez les versions après mise à jour et envisagez d’immobiliser les outils critiques. « Latest » n’est pas une politique de contrôle de changement.

Tâche 13 : Verrouiller le bon paquet quand plusieurs collent

cr0x@server:~$ winget install --name "Python" --source winget
Multiple packages found matching input criteria. Please refine the input.
Name         Id                 Version Source
----------------------------------------------
Python 3.12  Python.Python.3.12  3.12.2  winget
Python 3.11  Python.Python.3.11  3.11.8  winget

Ce que ça signifie : winget refuse de deviner. Tant mieux.

Décision : Utilisez --id. Si votre script utilise --name, corrigez‑le maintenant avant que cela ne devienne une dette institutionnelle.

Tâche 14 : Diagnostiquer un échec de paquet unique avec des logs verbeux

cr0x@server:~$ winget install --id SomeVendor.SomeApp --source winget --verbose-logs
Found SomeApp [SomeVendor.SomeApp] Version 5.1.0
Downloading...
Installer failed with exit code: 1603
See logs: C:\Users\user\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\

Ce que ça signifie : Le code de sortie 1603 est une classique erreur MSI « fatal », aussi informative que « rien ». Le chemin des logs est important.

Décision : Consultez les logs de l’installateur pour la raison réelle (prérequis manquant, redémarrage en attente, problème de permissions). Ensuite décidez : ajouter le prérequis, exiger un reboot, ou remplacer le paquet.

Tâche 15 : Réinitialiser les sources quand elles sont corrompues ou modifiées par politique

cr0x@server:~$ winget source reset --force
Resetting sources...
Done

Ce que ça signifie : winget réinitialise les sources par défaut.

Décision : Si une politique d’entreprise exige une source privée, la réinitialisation peut la supprimer. Après réinitialisation, réajoutez les sources d’entreprise approuvées et documentez la baseline.

Tâche 16 : Confirmer si vous êtes élevé (parce que la moitié de Windows tourne autour de ça)

cr0x@server:~$ whoami /groups | findstr /i "S-1-5-32-544"
BUILTIN\Administrators

Ce que ça signifie : Vous êtes dans le groupe Administrators. Cela ne garantit pas que le shell est élevé, mais c’est un indice rapide.

Décision : Si les installations échouent avec accès refusé ou impossibilité d’écrire dans Program Files, relancez depuis un terminal élevé ou optez intentionnellement pour des paquets par‑utilisateur.

Blague n°2 : Les installateurs Windows sont comme les chats — parfois ils font ce que vous demandez, et parfois ils vous regardent jusqu’à ce que vous changiez d’approche.

Feuille de route de diagnostic rapide : trouver le goulot vite

Quand les installations en masse échouent, vous avez deux choix : être systématique, ou passer votre après‑midi à apprendre de nouveaux synonymes pour « pourquoi ». Voici la voie systématique.

Premièrement : winget lui‑même est‑il sain ?

• Exécutez winget --version. Si cela renvoie une erreur, arrêtez.
• Exécutez winget source list et winget source update. Si les sources ne peuvent pas se mettre à jour, arrêtez.
• Essayez winget search Git. Si la recherche échoue, arrêtez.

Goulot typique : proxy, inspection TLS, endpoints bloqués, package App Installer cassé.

Deuxièmement : l’échec est‑il au téléchargement, à l’installation ou à l’enregistrement ?

• Phase de téléchargement : les erreurs ressemblent à des timeouts de connexion, 403/404, ou mismatch de hash.
• Phase d’installation : vous obtenez un code de sortie (souvent 1603 pour MSI) ou « installer failed ».
• Phase d’enregistrement : l’installation « réussit » mais winget list ne la montre pas, ou la détection de mise à jour est incorrecte.

Décision : Choisissez votre prochain test selon la phase. Ne traitez pas une erreur réseau comme un problème MSI.

Troisièmement : est‑ce un problème de permissions/élévation ?

• Les erreurs d’écriture dans Program Files ou HKLM sont presque toujours des problèmes d’élévation.
• Certaines packages s’installent par utilisateur par défaut ; si vous exécutez en tant que SYSTEM (MDM), « l’utilisateur » n’est pas celui que vous croyez.

Décision : Décidez si l’app doit être system‑wide ou par‑utilisateur, puis alignez le contexte d’exécution en conséquence.

Quatrièmement : est‑ce le paquet (métadonnées incorrectes, installateur cassé, ou comportement modifié vendor) ?

• Utilisez winget show --id … pour confirmer le type d’installateur et l’URL.
• Retry avec --verbose-logs et inspectez les vrais logs de l’installateur.

Décision : Si le fournisseur a changé les switches silencieux, attendez la mise à jour du paquet, contournez avec votre propre méthode de déploiement, ou choisissez un paquet alternatif.

Cinquièmement : l’échelle et la concurrence vous mordent‑elles ?

• Les installations en masse peuvent saturer disque, CPU ou réseau sur des appareils modestes.
• La protection endpoint peut ralentir chaque installateur téléchargé lors de l’analyse.

Décision : Échelonnez les installations, priorisez les outils critiques en premier et mesurez. « C’est lent » n’est pas un diagnostic.

Erreurs fréquentes : symptômes → cause → correction

Erreur 1 : « Package not found » pour quelque chose que vous voyez en ligne

Symptôme : winget install --id Vendor.App ne retourne aucun paquet correspondant.

Cause : les sources ne sont pas à jour, mauvaise source sélectionnée, ou la machine est bloquée pour atteindre l’index.

Correction : Exécutez winget source update, puis winget search en précisant --source. Si ça échoue encore, traquez proxy/TLS ou restrictions politiques.

Erreur 2 : Mauvaise app installée parce que vous avez utilisé --name

Symptôme : L’installation « a marché », mais l’app est la mauvaise édition/fork/branche.

Cause : collisions de noms. Les noms marketing ne sont pas des identifiants uniques.

Correction : Verrouillez toujours avec --id et généralement --source. Dans les imports, conservez les IDs et supprimez les entrées ambiguës.

Erreur 3 : Les installations échouent avec accès refusé ou impossibilité d’écrire dans Program Files

Symptôme : « Access is denied », « requires elevation », ou codes de sortie liés aux permissions.

Cause : exécution sans élévation ; tentative d’installations machine-wide depuis un terminal non élevé.

Correction : Lancez un terminal élevé pour les installations système, ou choisissez délibérément des installations par‑utilisateur là où c’est approprié. Ne mélangez pas et n’espérez pas.

Erreur 4 : L’import marche sur votre laptop mais échoue en environnement corporate

Symptôme : Les imports échouent sur les devices gérés ; les téléchargements expirent ; les installations Store échouent.

Cause : inspection proxy/TLS, Store bloqué, ou politique interdisant certaines sources.

Correction : Validez les sources tôt. Si le Store est bloqué, enlevez les paquets msstore du manifeste et standardisez sur le repo communautaire winget ou une source d’entreprise.

Erreur 5 : « Successfully installed » mais l’app n’est pas là (ou les upgrades ne détectent pas)

Symptôme : winget annonce le succès ; l’app n’apparaît pas dans les menus attendus ; winget list ne la voit pas.

Cause : l’installateur a installé par‑utilisateur sous un autre compte, ou l’app ne s’enregistre pas de manière detectable par winget.

Correction : Confirmez le contexte d’exécution (utilisateur vs SYSTEM). Préférez les paquets qui s’enregistrent correctement. Pour les apps récalcitrantes, gérez‑les hors winget et acceptez la frontière.

Erreur 6 : Les mises à jour en masse cassent une chaîne d’outils critique

Symptôme : après winget upgrade --all, les builds échouent ou des plugins plantent.

Cause : mise à jour de tout sans staging, verrouillage de version ou vérification de compatibilité.

Correction : Dans les équipes, procédez par vagues. Maintenez un manifeste connu‑bon. Mettez à jour les outils dev délibérément, pas impulsivement.

Erreur 7 : Partir du principe que « silent » signifie « jamais d’UI »

Symptôme : des installateurs popent encore des invites pendant des runs en masse.

Cause : l’installateur ignore les flags silencieux, exige un consentement de reboot, ou déclenche des dialogues EULA que winget ne peut pas supprimer.

Correction : Remplacez le paquet, script autour, ou acceptez qu’il ne soit pas automatisable sans coopération du fournisseur. Ne misez pas votre setup de 5 minutes sur un installateur capricieux.

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils déployaient de nouveaux laptops Windows à un groupe mixte : développeurs, analystes, et quelques personnes qui vivaient dans Excel et n’aimaient pas les surprises. L’IT a décidé de « moderniser le provisioning » avec winget. Bonne idée.

La mauvaise hypothèse était petite : « Si on exécute winget en tant que SYSTEM pendant l’enrôlement, les apps seront là pour l’utilisateur. » C’est parfois vrai pour des installateurs system‑wide. C’est aussi parfois très faux. Plusieurs paquets de la liste étaient par‑utilisateur par défaut. Ils se sont installés magnifiquement — simplement pas pour l’humain qui allait se connecter ensuite.

Le lundi matin est arrivé. Les gens se sont connectés et les outils attendus n’étaient pas présents. Les tickets de support ont afflué, et l’équipe a passé des heures à relancer des installations en contexte utilisateur. Certaines apps ont fini dupliquées : une install sous SYSTEM, une autre sous l’utilisateur, plus une détection de mise à jour confuse. C’était un beau bazar, de la façon dont seules les frontières de contexte Windows peuvent être un bazar.

La correction n’a pas été héroïque. Ils ont scindé le manifeste en deux : outils system‑wide installés pendant l’enrôlement (exécution élevée), et apps par‑utilisateur installées au premier login via un script en contexte utilisateur. Ils ont aussi retiré les paquets qui ne se comportaient pas de façon déterministe et ont géré ceux‑ci via le centre logiciel.

La leçon : winget ne vous dispense pas de penser à la portée d’installation. En fait, il vous force enfin à être explicite à ce sujet.

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre organisation a tenté de réduire le temps de provisioning. Ils ont mesuré que le téléchargement des installateurs prenait le plus de temps, donc ils ont optimisé la vitesse réseau : paralléliser tout, lancer les installations aussi vite que possible, et laisser la protection endpoint s’en occuper.

En labo, c’était impressionnant. Sur du vrai matériel, sur un vrai réseau d’entreprise, ça a dérapé. L’usage disque a explosé : plusieurs installateurs se décompressant simultanément, écrivant dans des répertoires temp, et déclenchant des scans antivirus. Le CPU a grimpé. Le réseau est devenu bursty. Des machines qui devaient être « prêtes en minutes » sont devenues lentes, et certaines installations ont expiré ou échoué avec des codes génériques.

L’équipe a d’abord accusé winget. Puis le repo. Puis Windows Update. En réalité, le schéma était plus simple : ils ont créé une tempête de contention de ressources et appelé ça « optimisation ».

Ils ont reculé vers une approche échelonnée : installer un noyau minimal d’abord (terminal, navigateur, certificats, client VPN), puis une seconde vague pour les outils dev, puis une vague finale pour les apps optionnelles. Ils ont aussi ajouté un petit délai entre les installations lourdes et évité de déclencher des installations Store en même temps que de gros paquets Win32.

Le provisioning est devenu prévisible plutôt qu’occasionnellement rapide. Les opérateurs préfèrent « prévisible » à « parfois impressionnant » à chaque fois.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Celui‑ci n’est pas glamour. C’est le genre de pratique que l’on saute jusqu’au jour où on ne peut plus.

Une petite équipe plateforme gardait un fichier d’import winget dans le contrôle de version. Chaque changement était revu. Ils figeaient les IDs. Ils annotaient pourquoi chaque app figurait dans la liste. Ils gardèrent aussi une petite section « casser la vitre » : quoi faire quand un installateur échoue, quels logs consulter, et quelles apps peuvent être installées manuellement.

Puis un fournisseur a modifié silencieusement un installateur. Le paquet existait toujours, mais l’installation silencieuse a commencé à renvoyer un code non nul à moins qu’un prérequis fût présent. Les machines ont commencé à échouer le provisioning vers 80% de complétion — assez tard pour perdre du temps, assez tôt pour bloquer l’onboarding.

Parce qu’ils avaient un manifeste révisé et une version précédente connue‑bonne du fichier d’import, ils ont rollbacké immédiatement et ont remis de nouvelles machines en service. Puis ils ont enquêté proprement : reproduit dans une VM, confirmé le prérequis, et mis à jour leurs étapes de provisioning. Pas d’héroïsme, juste de la discipline.

La pratique ennuyeuse — manifests versionnés plus rollback — a transformé une semaine potentiellement chaotique en une modification contrôlée.

Listes de vérification / plan étape par étape

Checklist A : Bootstrap poste de travail perso (rapide, pratique)

1. Ouvrez Windows Terminal en tant qu’utilisateur. Si vous savez qu’il faut des installs system‑wide, ouvrez‑le élevé.
2. Vérifiez que winget fonctionne : winget --version.
3. Rafraîchissez les sources : winget source update.
4. Installez d’abord les outils de base (navigateur, améliorations de terminal, git) : figez les IDs et utilisez les flags d’accord.
5. Installez les outils runtime/dev (Python/Node/Java) explicitement par ID et version si besoin.
6. Exécutez winget list et vérifiez ce que vous avez obtenu.
7. Exécutez winget upgrade et décidez de mettre à jour maintenant ou plus tard.
8. Exportez une baseline une fois satisaits : winget export -o ....

Checklist B : Build standard d’équipe (reproductible et révocable)

1. Créez un fichier d’import trié depuis une machine de référence propre, puis épurez‑le.
2. Standardisez sur les IDs ; retirez les apps ambiguës ou optionnelles.
3. Décidez quelles sources sont autorisées. Documentez‑le.
4. Testez l’import sur une VM fraîche et sur un laptop géré (proxy + endpoint protection inclus).
5. Tracez les échecs avec --verbose-logs et construisez une liste connue des « enfants problématiques ».
6. Séparez les installs system‑wide et par‑utilisateur si vous déployez via le contexte SYSTEM.
7. Contrôlez le manifeste en versionnement. Exigez une revue pour les changements.
8. Définissez le rollback : conservez le dernier manifeste connu‑bon et la procédure pour relancer l’import.

Checklist C : « J’ai besoin de ceci en 5 minutes » reconstruction d’urgence

1. Réinitialisez les sources si la recherche est cassée : winget source reset --force.
2. Mettre à jour les sources : winget source update.
3. Lancez votre fichier d’import avec les flags d’accord.
4. Si un paquet échoue, ne bloquez pas tout le setup : retirez‑le temporairement, terminez le provisioning, puis revenez‑y avec les logs.
5. Exécutez winget upgrade --all seulement après que la baseline soit stable.

FAQ

1) winget est‑il installé par défaut sur Windows 10/11 ?

Souvent, oui — car il est fourni avec App Installer de Microsoft. Mais « souvent » n’est pas « toujours », surtout sur des images entreprise allégées. Vérifiez avec winget --version.

2) Faut‑il utiliser winget install avec des noms ou des IDs ?

Les IDs. Les noms sont pour les humains qui naviguent. Les IDs sont pour les scripts et la reproductibilité. Si vous tenez à la consistance, ne donnez pas au résolveur la possibilité de deviner.

3) Quelle est la meilleure manière d’installer rapidement 20–50 apps ?

Utilisez winget import avec un fichier JSON trié. C’est révocable, diffable, et plus facile à garder cohérent qu’un long script d’installations.

4) Pourquoi winget dit « Successfully installed » mais je ne trouve pas l’app ?

Le cas le plus courant : elle s’est installée par‑utilisateur sous un autre compte (SYSTEM vs utilisateur), ou l’app ne s’enregistre pas comme vous l’attendez. Vérifiez le contexte, puis winget list. Si elle est installée mais pas visible, c’est un problème de packaging/enregistrement, pas une faute de frappe dans la commande winget.

5) winget peut‑il installer des apps du Microsoft Store en environnement entreprise ?

Parfois. Ça dépend si le Store est autorisé et si le device/contexte utilisateur peut l’atteindre. Si le Store est bloqué, ne mettez pas de paquets Store dans votre manifest et n’êtes pas surpris si ça échoue.

6) winget upgrade --all est‑il sans risque ?

Sur une machine perso, généralement. En équipe ou en entreprise, c’est un événement de changement. Planifiez les mises à jour par vagues, testez les chaînes d’outils critiques et conservez des options de rollback.

7) Comment gérer les apps qui ne supportent pas les installations silencieuses ?

Vous avez trois options réalistes : choisir un autre paquet, gérer cette app hors winget (MDM, manuel, ou outil fournisseur), ou accepter les invites. Ne tentez pas de « forcer winget » sur un installateur qui refuse l’automatisation.

8) winget remplace‑t‑il les golden images ?

Non. Il les complète. Les golden images règlent la configuration OS de base et les drivers. winget gère proprement l’installation et les mises à jour des apps. Utilisez les deux si vous voulez vitesse et contrôle.

9) Comment garder plusieurs machines cohérentes dans le temps ?

Maintenez un fichier d’import trié dans le contrôle de version, exécutez‑le pendant le provisioning, et utilisez des cycles de mises à jour contrôlés. L’astuce n’est pas d’installer des apps ; c’est de gérer le changement.

10) Que faire quand un paquet se met soudainement à échouer pour tout le monde ?

Supposez que le fournisseur a changé quelque chose ou qu’un prérequis a bougé. Récupérez les logs avec --verbose-logs, reproduisez sur une VM propre, et revenez au manifeste connu‑bon pendant l’investigation.

Conclusion : prochaines étapes qui tiennent

Si vous voulez une configuration Windows propre en cinq minutes, cessez de traiter les installations d’apps comme une corvée ponctuelle. Traitez‑les comme de l’infrastructure : déclarées, reproductibles et observables en cas d’échec.

Faites ceci ensuite :

1. Exécutez winget source update et vérifiez que les sources sont saines.
2. Construisez une liste d’import triée : exportez depuis une machine connue‑bonne, puis supprimez le bruit.
3. Verrouillez les IDs et spécifiez les sources pour tout ce qui compte.
4. Testez sur une VM propre, puis sur un device géré (proxy et endpoint protection inclus).
5. Contrôlez le manifeste en versionnement et conservez une version précédente prête à rollback.
6. Adoptez la feuille de route de diagnostic rapide pour que les échecs ne deviennent pas des légendes.

Le gain n’est pas seulement la vitesse. C’est que la configuration devient ennuyeuse. Et l’ennui est ce que vous voulez quand vous êtes la personne qu’on appelle en cas de problème.