PatchMon centralise les correctifs d’un parc Linux dans une file d’approbation unique, sans tournée SSH
Le 23 octobre 2026, le bulletin selfh.st a mis en avant PatchMon, une plateforme de gestion de correctifs auto-hébergée sous AGPL v3 qui pilote les mises à jour Linux, FreeBSD et Windows depuis une file unique avec dry-run, approbation et audit. Pour un parc de plus de quelques dizaines de machines soumis à une obligation de traçabilité, elle remplace la tournée SSH et les playbooks maison.
23 octobre 2026. Le bulletin hebdomadaire selfh.st place PatchMon dans sa rubrique « Content Spotlight » : une plateforme de gestion de correctifs auto-hébergée, sous licence AGPL v3, qui pilote les mises à jour d’un parc Linux, FreeBSD et Windows depuis une interface web unique. Même semaine. Le projet revendique 70 000 serveurs gérés, plus de 4 000 installations actives et 3 500 étoiles GitHub. Même semaine, encore. Sa documentation détaille un déploiement Docker qui tient en trois commandes, à condition d’ajouter un PostgreSQL et un Redis externes. Le point qui compte : PatchMon ne corrige pas seulement des paquets — il transforme le patch day, ce rituel où un ops enchaîne les connexions SSH, en une file d’approbation dont chaque étape laisse une trace d’audit.
Le problème que PatchMon prétend régler : le patch day sans système
Avant de juger l’outil, il faut regarder le problème qu’il attaque. Dans une équipe qui gère quelques dizaines de serveurs sans plateforme dédiée, la mise à jour ressemble invariablement à l’un de ces trois rituels.
La tournée SSH. On se connecte à chaque hôte, on lance apt update && apt upgrade, on lit la sortie, on répète quarante-sept fois, et on rate la machine qui comptait.
La prolifération Ansible. Trois playbooks pour trois distributions, des sorties de --dry-run que personne ne lit, et un « ça a tourné ? » auquel personne ne sait répondre sans se reconnecter.
Le tableur. Une ligne par hôte, une colonne « fait », une date tapée à la main. Quand l’auditeur demande des preuves, on ouvre le tableur et on prie.
PatchMon remplace ces trois rituels par une file unique : ce qui est en attente, qui l’a approuvé, ce qui est parti, et ce qu’on peut montrer à un auditeur. C’est un positionnement précis, pas une énième interface posée sur apt.
Ce que fait l’agent : sortant uniquement, multi-OS, sans port entrant
L’architecture mérite qu’on s’y arrête, parce que c’est elle qui rend l’outil crédible sur un parc réel. L’agent PatchMon est un binaire Go léger qui communique uniquement en sortant vers le serveur — aucun port entrant n’est requis sur les hôtes surveillés. Pas de modification de pare-feu, pas d’exposition SSH ni WinRM, pas de VPN obligatoire.
Le serveur, lui, est un binaire Go unique avec l’interface React embarquée : un seul conteneur, pas de runtime Node à déployer. L’agent couvre sept gestionnaires de paquets — apt, dnf, yum, apk, pacman, zypper et pkg (FreeBSD) — auxquels s’ajoute Windows Update. C’est un vrai multi-OS par conception, pas un outil Linux avec un greffon Windows ajouté après coup.
Le déploiement minimal tient dans un Docker Compose, mais il faut le dire franchement : PatchMon exige un PostgreSQL et un Redis externes pour le stockage et les files de travaux. C’est un coût d’exploitation réel, surtout pour un petit homelab qui voulait « juste » surveiller trois machines.
Du dry-run à l’audit : la boucle de mise à jour
La valeur de PatchMon se concentre dans sa boucle de mise à jour, qui impose une discipline souvent absente ailleurs.
Dry-run d’abord. Chaque exécution capture le plan complet de la transaction de paquets avant qu’elle ne touche la production. On sait exactement ce qui changerait.
Approbation ensuite. Un clic transforme le dry-run validé en exécution réelle, avec une trace par hôte : qui a approuvé quoi, et quand.
Planification. Les politiques de correctifs décident du moment : immédiat, fenêtre de maintenance, ou déploiement différé. On approuve maintenant, on exécute plus tard.
Sélectivité. On cible des paquets précis, les seules mises à jour de sécurité, ou une mise à niveau complète — sur les sept gestionnaires.
Historique. Chaque exécution est consultable : code de sortie, durée, paquets touchés, approbateur, hôte.
Le streaming en direct complète le tableau : la sortie de l’agent est poussée en WebSocket dans le navigateur, avec la possibilité d’arrêter une exécution en vol. Pour un SRE qui a déjà vu un upgrade partir sur la mauvaise machine, c’est un filet de sécurité concret.
La conformité comme argument décisif
Le différentiateur le plus sérieux n’est pas technique, il est réglementaire. PatchMon embarque des scans OpenSCAP sur les benchmarks CIS et des évaluations Docker Bench contre les hôtes de conteneurs. On voit quelles règles passent ou échouent, avec la sévérité et les étapes de remédiation, et on suit le score de conformité dans le temps.
Traduit en pratique : quand l’auditeur demande des preuves, le rapport est prêt en minutes, pas en jours. C’est l’argument qui fait basculer l’adoption d’un outil de correctifs — surtout dans les structures soumises à des référentiels qui exigent une traçabilité des correctifs démontrable.
Ce que PatchMon ne remplace pas
PatchMon n’est pas seul sur ce terrain, et le dire franchement aide à situer le verdict. Uyuni, le successeur communautaire de SUSE Manager, gère les correctifs, la configuration et le cycle de vie des systèmes SUSE et Red Hat — mais son périmètre dépasse la mise à jour, c’est un outil de gestion de configuration complet, plus lourd à adopter. Canonical Landscape fait un travail comparable pour Ubuntu, en échange d’une licence Ubuntu Pro sur les hôtes couverts. Ansible AWX et Semaphore couvrent le « j’exécute des playbooks », mais laissent l’audit et la conformité à vos soins.
PatchMon occupe l’entre-deux : il ne fait pas la gestion de configuration, il ne remplace pas un CMDB, et il n’évalue pas la criticité des CVE qui touchent vos paquets — un point à garder en tête si votre exigence est la priorisation par risque. Il excelle en revanche sur une chose précise : transformer « est-ce que c’est patché ? » en une réponse traçable et approuvable. Si c’est exactement la question qu’on vous pose, c’est exactement l’outil qui y répond.
Ce qu’il faut faire
Pour tester PatchMon, le démarrage est rapide.
mkdir patchmon && cd patchmon
bash -c "$(curl -fsSL https://raw.githubusercontent.com/PatchMon/PatchMon/refs/heads/main/docker/setup-env.sh)"
docker compose up -dOn ouvre http://localhost:3000, on crée un compte administrateur, on ajoute un hôte et on copie la commande d’installation d’agent générée par l’interface sur la machine cible. Le chemin de bout en bout est pensé pour les premières minutes.
Avant de déployer en production, trois vérifications s’imposent. Dimensionnez PostgreSQL et Redis : ce sont des dépendances externes, pas des options. Verrouillez l’authentification : OIDC (Authentik, Keycloak, Okta), TOTP et RBAC à rôles granulaires existent — activez-les avant d’exposer quoi que ce soit. Testez le mode proxy du terminal SSH : l’accès SSH/RDP depuis le navigateur peut router par la liaison sortante de l’agent, ce qui évite d’ouvrir SSH en entrée sur les hôtes.
Verdict
Si vous gérez plus de quelques dizaines de machines Linux et que vous devez rendre des comptes — équipe de production, prestataire, entité soumise à audit — PatchMon remplace la tournée SSH et les playbooks maison par une file d’approbation auditable, et son agent sortant unique simplifie le déploiement réseau. Le surcoût PostgreSQL/Redis se justifie dès lors que la traçabilité a une valeur. Si vous avez trois machines dans un homelab, c’est trop d’infrastructure pour le bénéfice : unattended-upgrades bien réglé ou un petit playbook restent plus sobres. La leçon dépasse PatchMon : le patch day redevient un problème d’ingénierie dès qu’il faut prouver qu’on l’a fait — et c’est précisément ce que cette génération d’outils auto-hébergés vient résoudre.