Une gestion de paquets propre sous Windows: WinGet, Chocolatey, Scoop et Ansible, chacun sa place

Après des années à automatiser des environnements Linux avec apt, dnf et Ansible, les machines de build Windows restaient le parent pauvre: un %TEMP% d’installateurs exécutés à la main, des versions qui n’ont jamais été les mêmes deux jours de suite et un “ça marchait sur la machine de Jean-Michel” à chaque incident. J’ai découvert et adopté Scoop pour mes environnements Windows et ça change la forme du problème: le poste de build commence à ressembler à un environnement déclaratif que je reconstruis et versionne, au lieu d’un état que je maintiens à la main.

Shims: le tour de magie de Scoop

Ce qui plaît dans Scoop, c’est son approche très Unix/Linux: tout s’installe dans un environnement utilisateur, pas d’admin, pas de registre, une arborescence lisible sous ~\scoop\. Les manifests sont des JSON simples, les versions se pincent, l’installation se scripte et la désinstallation ne laisse pas de debris. Le mécanisme qui tient tout: les shims. Un répertoire ~\scoop\shims sur le PATH, un mini-exécutable par outil qui délègue vers l’installation réelle. Le PATH reste court, les collisions de noms se règlent localement et l’outil disparaît proprement quand on le retire. Peu de magie, presque tout se scripte: exactement ce qu’on attend d’un gestionnaire de paquets pour des machines qu’Ansible va piloter.

Trois gestionnaires, trois responsabilités

Le split entre gestionnaires n’est pas une question de préférence, c’est de la séparation de responsabilités. Chaque outil excelle dans une couche et il est salement mauvais dans les autres:

WinGet: responsabilité poste utilisateur, les applications Windows et le catalogue Microsoft;
Chocolatey: responsabilité système, les MSI, les services, les composants qui exigent des privilèges et une intégration profonde avec Windows;
Scoop: responsabilité toolchain développeur, les CLI, runtimes, SDK, compilateurs et outils de build que je veux installer et reproduire vite dans mon environnement utilisateur (Git, Python, Node, Go, JDK, CMake, Ninja, 7zip…).

Le classique “on installe tout avec Chocolatey” fonctionne, mais il transforme un outil en couteau suisse: un gestionnaire qui installe des services système gère aussi mal votre toolchain qu’un gestionnaire utilisateur gère mal vos services. Ne pas leur faire rentrer tous les logiciels dans le même sac, c’est ce qui rend l’ensemble propre.

Et Ansible par-dessus

Le point que les diagrammes “WinGet + Chocolatey + Scoop en frères” omettent: dans mon infra, ce n’est pas moi qui tape ces commandes, c’est Ansible qui gère tout l’état Windows. Les gestionnaires sont des mécanismes derrière le module Ansible qui les pilote, pas des hiérarchies concurrentes:

Ansible: l'état voulu de la machine Windows
|
+-- WinGet        --> applications desktop, catalogue Microsoft
+-- Chocolatey    --> composants système, services, privilèges
+-- Scoop         --> toolchain dev/CLI, environnement utilisateur
+-- win_package   --> les MSI/EXE qui imposent leur installateur
`-- NuGet         --> PowerShellGet via win_psrepository, si besoin

Concrètement: community.windows.win_scoop pour la toolchain Scoop, chocolatey.chocolatey.win_chocolatey pour les composants système (le module qui a déjà sauvé une supply chain sur l’incident p4v ) et ansible.windows.win_package pour les MSI et EXE qu’aucun gestionnaire ne porte: certains installateurs imposent les leurs, on n’a pas le choix, Ansible pilote l’installateur natif directement, avec les arguments silencieux et les critères d’idempotence qui vont avec. WinGet n’a pas de module officiel dédié: quand une application n’existe qu’au catalogue Microsoft, Ansible la pilote par win_command/win_shell. La config système passe par les modules Windows habituels (registre, services, utilisateurs). Ansible reste la couche qui déclare et maintient l’état attendu, quel que soit le mécanisme d’installation:

- name: Dev toolchain through Scoop
  community.windows.win_scoop:
    name: "{{ item }}"
  loop: [git, python, go, cmake, ninja]

- name: Vendor MSI without a package manager
  ansible.windows.win_package:
    path: C:\install\tool-2.1.msi
    state: present

mise: la couche par projet

Reste l’échelle que ni Ansible ni Scoop ne couvrent: par projet. mise s’installe avec Ansible (scoop install mise ou winget install jdx.mise), est natif Windows et prend le relais à l’échelle du repo: un mise.toml versionné avec le code déclare les versions (Python 3.13, Node 24, Go, Terraform), les variables d’environnement et les tâches (build, test, lint). Ansible prépare la machine, Scoop fournit les outils, mise fixe le contexte du projet. Une réserve honnête: la compatibilité Windows de mise ne garantit pas celle de tous les outils qu’il gère, les backends et les versions dépendent du support Windows de chaque outil.

On sépare même l’environnement de la machine de l’environnement du projet: c’est beaucoup plus propre que de mettre toutes les versions de tooling directement dans le playbook Ansible. Le playbook n’a pas à savoir que le repo X veut Node 24; le mise.toml du repo X le sait.

Environment as Code

Au bout de la chaîne, le poste de travail ressemble à ce que je connais sous Linux: un état déclaré dans des fichiers versionnés, des mécanismes spécialisés derrière une couche d’orchestration et une reconstruction qui tient dans un ansible-playbook plus un mise install. La philosophie d’infrastructure as code n’a jamais été une affaire d’OS; elle exige juste que chaque couche accepte de faire une seule chose.

Le mot de la fin

Je ne remplace pas Chocolatey ni WinGet: je les sépare par responsabilité. Chaque outil fait ce pour quoi il est le plus adapté.
Package managers spécialisés, installateurs natifs quand nécessaire, Ansible pour orchestrer l’ensemble.
Les shims rendent la toolchain utilisateur scriptable et désinstallable proprement.
La machine et le projet sont deux environnements distincts. Ansible tient le premier, mise le second.
Environment as Code, pas une affaire d’OS. Windows inclus, pourvu qu’on refuse le couteau suisse.

[edit: 2026] L’implémentation Ansible de tout ceci: les rôles chocolatey et scoop .