---
title: "ZABBIX : Surveillance des versions logicielles déployées"
canonical: "https://blog.kaptus.net/space/BKAP/blog/971866113/ZABBIX%20%3A%20Surveillance%20des%20versions%20logicielles%20d%C3%A9ploy%C3%A9es"
format: markdown
---
> Macro (toc)
# **1. Introduction**
Depuis la fin de l'été 2026, j’ai entrepris de faire évoluer l’infrastructure de supervision de ***KAPTUS*** en migrant progressivement de `Nagios`** vers **`Zabbix`. Cette migration est pour moi l’occasion de revoir ma manière de superviser l’infrastructure :
- supprimer certains mécanismes historiques,
- exploiter les nouvelles possibilités offertes par Zabbix,
- construire une supervision plus centralisée, plus homogène et plus facilement extensible.
Ce chantier a également été l’occasion de concrétiser certains besoins identifiés depuis longtemps, mais que je n’avais jamais eu l’opportunité (ou le temp) de mettre en œuvre.
> ℹ️ L’un d’eux concerne le suivie de **version des applications déployées sur nos serveurs**.
On supervise naturellement :
- la disponibilité,
- les ressources système,
- certains indicateurs propres aux services qu’elles fournissent.
> ⚠️ Mais jamais si **la version déployées est à jour ?**
Cette question paraît simple. Mais y répondre automatiquement sur l’ensemble d’un parc l’est beaucoup moins. Les applications que nous utilisons ne sont pas toutes installées de la même uniforme. Certaines proviennent de paquets système, d’autres sont installées depuis des archives ou exécutées dans des conteneurs. La version installée peut être obtenue avec une commande, une API HTTP, un fichier ou encore les métadonnées d’un paquet. La situation est similaire lorsqu’il s’agit de déterminer la dernière version disponible :
- certaines applications publient leurs releases sur GitHub,
- d’autres utilisent leur propre API
- ou un autre mécanisme de publication.
Il faut donc résoudre deux problèmes distincts :
1. **déterminer de manière fiable la version réellement installée sur chaque serveur ;**
2. **déterminer la dernière version stable disponible auprès de l’éditeur.**
Ensuit, il faut rapprocher ces deux informations afin d’obtenir une donnée de réellement exploitable dans `Zabbix`. C’est de ce besoin qu’est née l’idée du module** Application Versions.**
L’objectif de cet article, est de vous présentez l’architecture mise en place, les choix qui ont été faits pour séparer collecte locale et recherche centralisée des versions, ainsi que leur intégration dans `Zabbix` et `Ansible`.
La finalité est de disposer dans `Zabbix` d’une vue permettant de savoir rapidement
- **quelles applications sont déployées, **
- **dans quelles versions, **
- **lesquelles nécessitent une mise à jour**.
# **2. Pourquoi intégrer cette surveillance à Zabbix ?**
La surveillance des versions logicielles n’est évidemment pas un besoin nouveau et plusieurs catégories d’outils permettent aujourd’hui d’y répondre, au moins partiellement. Les solutions de **gestion de vulnérabilités** et les scanners de sécurité sont capables d’inventorier les logiciels présents sur un système et de confronter leurs versions aux vulnérabilités connues. Les outils de **gestion de parc et de configuration** disposent également de fonctions d’inventaire logiciel. Dans l’univers des conteneurs, d’autres solutions se spécialisent dans la surveillance des images et la détection de nouvelles versions. Enfin, des outils comme **Renovate** ou **Dependabot** excellent dans le suivi des dépendances et des versions déclarées dans les projets logiciels.
Ces solutions répondent cependant à des problématiques différentes. Mon besoin n’était pas uniquement de rechercher des vulnérabilités, de maintenir les dépendances d’un projet ou de détecter qu’une nouvelle image Docker était disponible. Je voulais pouvoir répondre simplement à une question opérationnelle :
> **Pour chacune des applications que j’exploite, quelle version est actuellement déployée et existe-t-il une version plus récente ?**
Mon objectif était avant tout de conserver **Zabbix comme point central de la supervision**. Cela n’exclut pas l’utilisation d’outils spécialisés pour collecter ou enrichir certaines informations, mais la donnée finale doit rester accessible depuis un même endroit et s’intégrer aux mécanismes de supervision existants. Or, au moment où ce besoin devenait concret, j’étais précisément en train de généraliser **Zabbix comme point central de supervision de l’infrastructure**.
Zabbix disposait déjà de nombreux éléments nécessaires :
- les hôtes et leurs agents étaient connus,
- la collecte de données était en place,
- l’historisation,
- les triggers,
- les alertes,
- les tableaux de bord.
Cette approche présente également un avantage important : **la version d’une application devient une donnée de supervision comme une autre**.
Elle peut être :
- historisée,
- affichée,
- recherchée,
- comparée,
- utilisée pour déclencher une alerte.
# **3. Les choix d’architecture**
Le premier choix structurant a été de considérer la **version installée** et la **dernière version disponible** comme deux informations totalement indépendantes.
**La version installée est, par définition, une information locale.**** **Elle dépend d’un serveur et doit être déterminée directement sur celui-ci.
> 📝 ***Une même application peut être installée sur plusieurs serveurs dans des versions différentes, notamment lorsqu’une mise à jour est déployée progressivement.***
Sa collecte est donc effectuée directement sur chaque serveur supervisé, par l’intermédiaire de `Zabbix Agent 2`. Un collecteur local détermine les versions des applications déclarées sur le serveur et les transmet à `Zabbix` sous la forme d’un `JSON`.
**La dernière version disponible répond à une logique très différente. **
> ℹ️ Cette information ne dépend pas du serveur sur lequel l’application est installée. Si dix serveurs utilisent `Forgejo`, il n’y a aucune raison d’interroger dix fois la source officielle pour connaître sa dernière release : le résultat sera identique pour chacun d’eux.
La recherche des versions disponibles est donc **centralisée**. Elle consiste à interroger les différentes sources de publication des applications, puis à normaliser les informations obtenues afin qu’elles puissent être exploitées de manière uniforme.
Avant de développer un mécanisme spécifique pour résoudre cette seconde problématique, j’ai recherché les solutions Open Source existantes. C’est ainsi que j’ai sélectionné `Argus (Release Argus)`. `Argus` est précisément conçu pour surveiller les nouvelles versions de logiciels. Il peut notamment suivre les versions publiées sur `GitHub` ou rechercher une version à partir d’une `URL`, puis présenter les résultats dans une interface Web. Il dispose également de mécanismes de notification et de `webhooks` permettant de réagir à la publication d’une nouvelle version. ([Argus](https://release-argus.io/)).
> ℹ️ Plutôt que de réimplementer cette logique dans `Zabbix`, il m’a donc semblé beaucoup plus pertinent de m’appuyer sur un projet `Open Source`.
`Argus` résolvait cependant seulement **une partie du problème**. Il sait manipuler la notion de version déployée et son interface permet de visualiser les versions suivies.
> ⚠️ **Une limite importante dans mon contexte est qu’**`Argus`** n’associe qu’une seule version déployée à une application surveillée. Il ne permet donc pas de représenter nativement une même application installée dans des versions différentes sur plusieurs serveurs (du moins pour l’instant).**
Mais utiliser `Argus` comme interface principale aurait conduit à créer un second espace de supervision, indépendant de `Zabbix`. Or mon objectif était précisément inverse :
- `Zabbix`** devait rester le point central depuis lequel je peux observer l’état de l’infrastructure**.
J’ai donc choisi de répartir clairement les responsabilités :
1. `Argus`** devient la référence pour déterminer les dernières versions disponibles**,
2. `Zabbix`** reste responsable :**
1. **de la collecte des versions réellement installées, **
2. **de leur rapprochement avec les informations fournies par **`Argus`**, **
3. **de leur historisation, **
4. **de leur présentation par serveur**.
Cette séparation permet d’adapter la fréquence des traitements à la nature de l’information. La version installée est collectée régulièrement afin que `Zabbix` reflète rapidement une modification consécutive à un déploiement ou à une mise à jour. Dans notre cas, cette collecte est effectuée **toutes les 15 minutes**.
À l’inverse, il est inutile d’interroger en permanence les services externes pour rechercher de nouvelles releases. La collecte des versions disponibles peut donc être réalisée à une fréquence beaucoup plus faible.
> 📝 Cette séparation entre **état local** et **référence globale** constitue la base de toute l’architecture du module **Application Versions**.
# **4. Un déploiement entièrement automatisé avec Ansible**
Un déploiement entièrement automatisé avec AnsibleDès le départ, j’ai souhaité que cette nouvelle fonctionnalité respecte un principe déjà largement appliqué dans notre infrastructure : **tout ce qui peut être automatisé doit l’être. **L’ensemble de la solution est donc déployé et maintenu avec `Ansible`. Cette automatisation ne concerne pas uniquement l’installation des composants. Elle couvre également leur configuration, l’intégration avec `Zabbix`, la déclaration des applications à surveiller et leur association avec les différents serveurs. `Ansible` joue ainsi un rôle de **chef d’orchestre** entre les différents éléments de l’architecture. Lorsqu’une nouvelle application doit être supervisée, elle est déclarée dans la configuration puis associée aux serveurs concernés. Le déploiement Ansible se charge ensuite de propager les changements nécessaires et de maintenir une configuration cohérente sur l’ensemble de l’infrastructure. Le même principe s’applique à `Argus` : son installation et sa configuration font partie intégrante du déploiement automatisé. Il n’est donc pas nécessaire de maintenir manuellement sa configuration parallèlement à celle de `Zabbix`.
Cette approche apporte surtout trois bénéfices :
1. **reproductibilité, **
2. **cohérence,**
3. **traçabilité**.
La configuration de la surveillance est gérée de la même manière que le reste de l’infrastructure et peut évoluer avec elle. Cela permet de conserver une séparation claire des responsabilités :
- **Ansible décrit et déploie la solution, **
- **Argus recherche les versions disponibles,**
- **Zabbix centralise la supervision et restitue l’information**.
# **5. Installation et configuration d’Argus**
L'installation a été entièrement intégrée à notre déploiement `Ansible`. `Argus` est exécuté dans un **conteneur Docker** sur le serveur hébergeant `Zabbix`.
`Ansible` prend en charge
- son installation,
- sa configuration,
- son maintien en condition opérationnelle.
Le déploiement reste ainsi reproductible et ne nécessite pas d’intervention manuelle particulière. La configuration des applications surveillées par `Argus` est elle aussi générée automatiquement. Lorsqu’une application est ajoutée au périmètre de surveillance, les informations nécessaires à la recherche de ses nouvelles versions sont propagées jusqu’à `Argus` lors du déploiement. Cette approche permet de ne pas administrer séparément deux référentiels : **la configuration déclarée dans Ansible pilote à la fois ce qui doit être surveillé et la configuration nécessaire aux différents composants de la solution**. Une fois déployé, `Argus` fournit également une interface Web très pratique pour vérifier directement l’état des applications suivies et les dernières versions détectées.
> 📝 Cette interface reste particulièrement utile pour administrer et contrôler le composant, mais elle n’a pas vocation à devenir notre interface quotidienne de supervision. **La restitution opérationnelle de l’information reste centralisée dans Zabbix**, où les versions disponibles peuvent être mises en relation avec les versions effectivement installées sur chacun des serveurs.
# **6. Déclarer les applications à surveiller**
Pour que la solution reste simple à faire évoluer, j’ai choisi de séparer la **définition d’une application** des serveurs sur lesquels elle est réellement installée. Chaque application est ainsi déclarée **une seule fois dans un catalogue centralisé**. Cette définition contient les informations communes nécessaires à sa surveillance, notamment celles permettant d’identifier la dernière version publiée. Le principe peut être résumé par une configuration de ce type :
```yaml
applications:
forgejo:
name: Forgejo
source: github
nextcloud:
name: Nextcloud
source: github
```
Cette définition est ensuite associée aux serveurs qui hébergent réellement l’application. Ainsi, si `Forgejo` est présent sur trois serveurs, il n’est pas nécessaire de définir trois fois comment rechercher sa dernière version. **L’application existe une seule fois dans le catalogue, mais possède autant d’instances déployées qu’il y a de serveurs concernés. **C’est précisément cette distinction qui permet de gérer naturellement le **multi-serveur et le multi-version** : chaque serveur conserve sa propre version installée, tandis que tous partagent la même référence concernant la dernière version disponible. Ce modèle facilite également considérablement l’évolution du périmètre supervisé. L’ajout d’une application consiste essentiellement à la déclarer dans le catalogue, à indiquer sur quels serveurs elle est présente, puis à laisser `Ansible`** déployer automatiquement la configuration correspondante**. On obtient ainsi une configuration centralisée et cohérente, sans avoir à administrer manuellement chaque application dans `Argus` et dans `Zabbix`.
# **7. La collecte des versions installées**
Si la recherche des dernières versions disponibles est centralisée par `Argus`, la situation est différente pour les versions réellement installées. Cette information appartient à chaque serveur. C’est donc **localement que la version de chaque application est déterminée**, avant d’être remontée vers `Zabbix`. Ce choix permet de conserver une vision fidèle de l’état réel de l’infrastructure. Une même application peut être installée sur plusieurs serveurs avec des versions différentes, notamment lors d’un déploiement progressif ou lorsqu’un environnement de développement précède la production. La principale difficulté vient de l’hétérogénéité des applications : il n’existe pas de méthode universelle permettant de connaître leur version.
Selon les cas, celle-ci peut être obtenue :
- en exécutant une commande telle que `--version` ;
- en interrogeant une API HTTP ;
- en lisant un fichier ou une information propre à l’application ;
- en consultant les métadonnées d’un paquet ;
- ou encore en inspectant une application exécutée dans un conteneur.
Par exemple :
```
{
"applications": [
{
"id": "argus",
"name": "Argus",
"server": "protoceratops",
"installed": {
"version": "0.39.0",
"state": "OK",
"checked_at": "2026-10-07T21:54:52.805870Z",
"source": "container"
}
},
{
"id": "phpmyadmin",
"name": "phpMyAdmin",
"server": "protoceratops",
"installed": {
"version": "5.2.3",
"state": "OK",
"checked_at": "2026-10-07T21:54:52.805870Z",
"source": "release_date_filename"
}
}
]
}
```
La solution a donc été conçue pour **s’adapter à l’application plutôt que d’imposer une méthode unique de détection**. Chaque serveur connaît les applications qu’il doit surveiller et la manière de déterminer leur version. La collecte est effectuée périodiquement, puis les informations obtenues sont transmises à `Zabbix`, qui dispose ainsi d’une vision actualisée des versions réellement déployées sur l’ensemble du parc. À ce stade, les deux parties de l’architecture se rejoignent : **Argus fournit la dernière version disponible et les serveurs fournissent leur version installée**. `Zabbix` peut alors rapprocher ces informations pour chaque couple application/serveur et déterminer si une mise à jour est disponible. On passe ainsi d’une simple liste de releases à une information directement exploitable : **savoir précisément quelle application doit être mise à jour, et sur quel serveur**.
# **8. Le résultat dans Zabbix**
Toute cette architecture n’a finalement qu’un seul objectif : **rendre l’information immédiatement exploitable depuis **`Zabbix`.
Un widget spécifique a été développé, **Application Versions**, qui intégré directement au tableau de bord `Zabbix`. Il rassemble les informations provenant des serveurs supervisés et celles fournies par `Argus` afin d’offrir une vue synthétique de l’état des applications déployées.
Pour chaque application, le tableau présente notamment :
- le serveur sur lequel elle est installée ;
- la version actuellement déployée ;
- la dernière version disponible ;
- l’état de la comparaison ;
- la date de publication de la dernière version ;
- un accès direct à la page de la release lorsqu’elle est disponible.
L’objectif est de pouvoir identifier en quelques secondes les applications nécessitant une attention particulière. Une application dont la version installée correspond à la dernière version connue apparaît comme **à jour**. Lorsqu’une version plus récente est détectée, elle est immédiatement signalée comme **mise à jour disponible**.
Cette vue prend tout son intérêt lorsque le nombre de serveurs et d’applications augmente. Une même application peut apparaître plusieurs fois dans le tableau lorsqu’elle est déployée sur plusieurs machines, chaque serveur conservant sa propre version installée.
Il devient ainsi très facile de repérer, par exemple, qu’une application a déjà été mise à jour sur certains serveurs alors que d’autres utilisent encore une version précédente.
Le widget propose également des fonctions de **recherche, de filtrage et de regroupement** permettant de réduire rapidement la vue à un serveur, une application ou un état particulier.
Cette présentation était un élément important du projet. Je ne souhaitais pas simplement collecter une métrique supplémentaire dans `Zabbix`, mais disposer d’un véritable **tableau de bord opérationnel** permettant d’obtenir immédiatement une vision de l’état des versions logicielles de l’infrastructure. La complexité de la collecte reste ainsi invisible au quotidien : `Argus`** surveille les releases, les serveurs remontent leurs versions installées et **`Zabbix`** rassemble le tout dans une vue unique**. Le résultat est une vision centralisée qui permet de répondre immédiatement à trois questions simples :
- **Quelle application ? **
- **Sur quel serveur ? **
- **Une mise à jour est-elle disponible ?**
# **9. Ajouter une nouvelle application**
L’un des objectifs de cette architecture était de pouvoir **étendre facilement la surveillance à de nouvelles applications**, sans avoir à développer un mécanisme spécifique pour chacune d’entre elles.
Lorsqu’une nouvelle application doit être supervisée, il faut essentiellement répondre à deux questions :
- **comment déterminer la dernière version disponible ?**
- **comment déterminer la version réellement installée sur le serveur ?**
Pour la première, `Argus` prend en charge la recherche et le suivi des nouvelles `releases`. Dans de nombreux cas, il suffit d’indiquer le projet `GitHub` correspondant ou la source permettant d’identifier la dernière version publiée.
Pour la seconde, il faut choisir la méthode la plus adaptée à l’application. Selon son mode d’installation, la version peut être obtenue depuis une commande, une `API`, un fichier, un paquet ou encore un conteneur. Il reste ensuite à associer l’application aux serveurs sur lesquels elle est présente. L’ensemble de cette configuration étant géré par `Ansible`, le déploiement se charge de propager les modifications aux différents composants de la solution. Après la collecte suivante, la nouvelle application apparaît dans le widget **Application Versions** au même titre que celles déjà supervisées. Cette approche s’est révélée particulièrement intéressante au fur et à mesure de l’évolution du projet. Le mécanisme initialement conçu pour quelques applications peut être progressivement étendu à des logiciels très différents sans remettre en cause l’architecture générale.
> ✅ **Ajouter une application ne signifie donc pas ajouter une nouvelle supervision : il s’agit simplement d’intégrer une nouvelle application dans un mécanisme de surveillance déjà existant.**
# **10. Conclusion**
Ce projet est finalement assez représentatif de ce que je recherchais en migrant progressivement notre supervision de **Nagios vers Zabbix** : ne pas simplement reproduire l’existant, mais profiter de cette migration pour construire de nouveaux outils répondant à des besoins identifiés depuis longtemps. Le suivi des versions logicielles en est un bon exemple.
Plutôt que de chercher à tout réaliser directement dans `Zabbix`, j’ai préféré m’appuyer sur les points forts de plusieurs outils complémentaires : `Argus` pour sa spécialisation dans la surveillance des `releases`, `Ansible` pour décrire et déployer la configuration de manière reproductible, et `Zabbix` pour centraliser les informations et les restituer sous une forme directement exploitable.
Cette combinaison permet surtout de répondre au besoin qui était difficile à couvrir avec un outil unique : disposer d’une vision **multi-serveur et multi-version**, capable de montrer non seulement qu’une nouvelle version d’une application existe, mais également **où cette application est déployée et quels serveurs doivent être mis à jour**. L’architecture reste par ailleurs ouverte. De nouvelles applications peuvent être ajoutées progressivement sans remettre en cause le fonctionnement général de la solution.
Au-delà du suivi des versions, ce projet illustre aussi l’un des aspects de `Zabbix` que je trouve particulièrement intéressant : sa capacité à devenir une véritable **plateforme centrale de supervision**, autour de laquelle il est possible d’intégrer des sources de données et des outils spécialisés. Le résultat est finalement assez simple à résumer :
- **Argus sait quelles versions sont disponibles, **
- **chaque serveur sait ce qui est réellement installé, **
- **Ansible orchestre l’ensemble,**
- **Zabbix transforme ces informations en une vision globale et opérationnelle de l’infrastructure.**
# **11. L’IA comme outil d’accompagnement du projet**
Un dernier aspect de ce projet mérite d’être mentionné : **l’utilisation de l’intelligence artificielle comme outil d’accompagnement tout au long de sa conception et de sa réalisation**.
J’ai utilisé `ChatGPT` pendant les phases de réflexion pour :
- confronter mes idées,
- étudier différentes architectures,
- identifier leurs avantages et leurs limites et, progressivement, formaliser la solution retenue.
L’IA a ici joué le rôle d’un interlocuteur technique avec lequel il était possible d’explorer rapidement plusieurs pistes avant de prendre les décisions d’architecture. Une fois ces choix définis et validés, `Codex` m’a accompagné dans leur mise en œuvre au sein de l’infrastructure existante :
- développement,
- intégration dans les rôles `Ansible`,
- évolution du module `Zabbix`,
- mise en place des tests nécessaires à la validation des modifications.
Cette façon de travailler s’est révélée particulièrement efficace : **utiliser l’IA pour accélérer l’analyse et l’implémentation, tout en conservant la maîtrise des choix d’architecture, des validations et du résultat final**.
Un autre apport important concerne la **documentation du projet**. J’accorde beaucoup d’importance à ce qu’elle évolue en même temps que le code et la configuration, plutôt que d’être rédigée une fois le projet terminé (avec le risque qu’elle soit déjà partiellement obsolète). L’utilisation de `ChatGPT` et de `Codex` permet d’intégrer cette mise à jour documentaire au processus de développement :
- les décisions prises,
- les évolutions d’architecture,
- les changements apportés à l’implémentation,
peuvent être répercutés au fur et à mesure dans la documentation. **La documentation devient ainsi un élément vivant du projet, maintenu en parallèle du code et non une tâche repoussée à sa conclusion.**
Ce projet constitue ainsi également un exemple concret de la manière dont j’intègre aujourd’hui les outils d’IA dans mon travail d’ingénierie : non pas comme un substitut à l’expertise technique, mais comme un moyen d’augmenter la capacité d’analyse, d’expérimentation et de réalisation.