Votre réseau vous parle — si vous ne l’écoutez pas, ce sont vos utilisateurs qui vous le diront

En janvier 2026, une panne DNS de 14 minutes chez un hébergeur européen a coupé 3 200 sites parce que personne n’avait configuré d’alerte sur la latence de résolution de son autorité primaire. En février 2025, Orange Business Services a perdu 4 heures de connectivité sur un trunk optique Lyon-Marseille sans notification automatique — le ticket est remonté par un client, pas par la supervision. En avril 2025, un opérateur américain a découvert qu’un commutateur d’agrégation émettait 17 % d’erreurs CRC depuis six semaines sans la moindre alarme.

Le point commun ? La supervision existait — mais elle était silencieuse au moment où elle aurait dû hurler.

Votre réseau émet des signaux en permanence : taux d’erreur sur les interfaces, dépassements de seuils de bande passante, échecs d’authentification SNMP, variations de température sur les optiques, sessions BGP qui flappent. Ces signaux sont gratuits. Ce qui coûte cher, c’est de ne pas les capter. La supervision réseau n’est pas un luxe de datacenter : c’est l’assurance que vous apprenez la panne avant vos utilisateurs.

Trois outils open source dominent le marché en 2026, et ils couvrent tous les parcs sans exception : Zabbix, Checkmk et LibreNMS. Le choix dépend moins de votre budget que de votre nombre d’équipements et du temps d’ingénierie que vous êtes prêt à investir.

Zabbix — le couteau suisse qui ne dit jamais non

Zabbix a fêté ses 25 ans en 2025, et la version 7.0 LTS (dernier correctif 7.0.29 du 28 juillet 2026) reste la plus déployée en production. Une version 8.0 LTS est sur la feuille de route officielle, avec un support annoncé des agents MCP pour connecter la supervision aux assistants IA. Le socle est solide : AGPLv3, gratuit pour tout usage, pas de limite de devices, pas d’édition payante qui bride l’édition gratuite.

L’architecture de Zabbix repose sur trois piliers qui expliquent sa domination dans les grands parcs :

• Les templates. Plus de 200 templates officiels couvrent Cisco, Juniper, Arista, MikroTik, Fortinet, Palo Alto et tout l’écosystème Linux/Windows. Un template Zabbix, c’est un ensemble de règles de découverte, de seuils d’alerte et de dashboards prêts à l’emploi pour un équipement donné. Appliquez le template Cisco IOS by SNMP sur un switch, et Zabbix découvre automatiquement les interfaces, les capteurs de température, les ventilateurs, l’état des piles d’alimentation et les voisins CDP — sans écrire une ligne de configuration.
• Les proxies. Un proxy Zabbix collecte les métriques localement (sur un site distant, derrière un NAT, ou dans un VLAN isolé) et les transmet au serveur central. C’est le composant qui permet à une seule instance Zabbix de superviser plusieurs milliers d’équipements répartis sur des continents différents sans saturer le lien WAN. Le proxy dispose de son propre cache : si le lien vers le central tombe, les données sont stockées localement et synchronisées au rétablissement.
• Le langage d’alerte. Zabbix utilise un moteur de trigger functions qui autorise des conditions arbitrairement complexes : max(/host/key, 5m) > 100M pour une bande passante, nodata(/host/key, 10m) = 1 pour une perte de collecte, ou encore trendavg(/host/key, 1h:now/h) > 80 pour anticiper une saturation avant qu’elle n’arrive. Le graphe de dépendances entre triggers permet d’éviter les cascades d’alertes : si un switch cœur tombe, les 40 alarmes des switches d’accès derrière lui sont automatiquement supprimées.

Zabbix supporte nativement SNMP v1, v2c et v3 (avec authentification SHA/AES), les agents Zabbix (push/pull, chiffrés en TLS 1.3), IPMI, SSH, HTTP, Prometheus, Modbus, MQTT et les bases de données via ODBC. Le polling minimum est de 1 seconde, le stockage peut cibler TimescaleDB (supporté jusqu’à la version 2.28), et l’interface web propose une arborescence de dashboards personnalisable par rôle.

Ce qui est difficile avec Zabbix. La courbe d’apprentissage est verticale les deux premières semaines. L’interface, bien que modernisée en 7.0, reste dense. Configurer une règle de découverte de liens LLDP ou un template SNMP personnalisé pour un équipement exotique demande de comprendre le modèle de données interne (items, triggers, prototypes, preprocessing). Et le déploiement initial — base de données, partitionnement, tuning — est plus lourd que ses concurrents. Une fois en place, en revanche, Zabbix ne demande quasiment plus de maintenance.

Checkmk — l’auto-discovery qui fait le travail à votre place

Checkmk a sorti sa version 2.5 au printemps 2026, et cette major release marque un tournant stratégique : la supervision classique (SNMP, agents, logs) et l’observabilité moderne (OpenTelemetry, traces applicatives, métriques RED) fusionnent dans la même interface. L’édition Checkmk Community (anciennement Checkmk Raw) est 100 % open source et gratuite, sans limite de devices.

Là où Zabbix vous demande de choisir consciemment ce que vous supervisez, Checkmk part du principe que tout doit être découvert automatiquement. Branchez un nouveau switch sur le réseau, et en quelques minutes — si le scan de découverte est actif — Checkmk le détecte, l’interroge via SNMP, identifie toutes ses interfaces, ses capteurs matériels, ses voisins de couche 2, et applique les seuils standards du fournisseur. La philosophie est radicalement différente : chez Zabbix, vous déclarez ce que vous voulez surveiller ; chez Checkmk, vous validez ce qui a été automatiquement découvert.

L’agent Checkmk est le deuxième différenciateur fort. Installé sur vos serveurs Linux et Windows, il exécute des centaines de checks locaux — CPU, mémoire, disques, processus, conteneurs Docker, bases de données, applications — et les remonte au serveur central en une seule connexion TCP chiffrée. La surveillance est zero inbound traffic : l’agent initie la connexion vers le serveur, jamais l’inverse. Pour les réseaux segmentés, Checkmk Relay (nouveauté 2.5) est un conteneur léger qui relaie la supervision des équipements SNMP inaccessibles directement, avec chiffrement mTLS.

Parmi les avancées marquantes de la 2.5 :

• OpenTelemetry natif. Les métriques applicatives (latence, taux d’erreur, débit) remontent via OTLP et s’affichent dans les mêmes dashboards que les métriques d’infrastructure. Un pic de latence applicative peut être corrélé à une saturation de l’interface réseau du serveur — dans le même graphe, sans changer d’outil.
• « Explain with AI ». Un bouton dans l’interface alerte qui génère une analyse de cause racine en langage naturel. Pas de la magie, mais une synthèse automatique des événements corrélés qui fait gagner plusieurs minutes de diagnostic pendant un incident.
• Monitoring Azure repensé. 60 % plus rapide, filtrage par tags natifs, dashboards drill-down. La supervision cloud cesse d’être un parent pauvre.
• Dashboards responsives. Du smartphone au mur d’écrans 4K du NOC, les dashboards s’adaptent sans configuration manuelle.

Ce que Checkmk ne fait pas. La version Community est mono-site : pour superviser plusieurs datacenters, il faut acheter l’édition Pro ou Ultimate. Le modèle économique est open core — les fonctionnalités avancées (relay, OpenTelemetry, AI, reporting) sont payantes. L’agent est obligatoire pour une supervision serveur complète, ce qui exclut les appliances fermées. Et le format de configuration (fichiers .mk en Python-like) peut dérouter les équipes habituées au YAML ou au SQL.

LibreNMS — le SNMP plug-and-play qui ne coûte rien

LibreNMS 26.7.0 (sortie le 20 juillet 2026) est le troisième larron, et son positionnement est limpide : SNMP-first, zéro agent, un déploiement qui tient en une commande Docker. 4 800 étoiles GitHub, 2 700 forks, une quarantaine de contributeurs par release mensuelle — la communauté est active et le rythme de sortie (une version par mois) garantit que les nouveaux modèles de switches sont supportés rapidement.

Le modèle LibreNMS est celui du « ça marche tout de suite ou ça ne marche pas ». Vous déployez l’instance, vous lui donnez une plage d’adresses à scanner, et elle interroge chaque IP en SNMP. Si l’équipement répond, LibreNMS identifie le constructeur et le modèle via le sysObjectID, charge automatiquement les bons OIDs, et commence à grapher les interfaces, la CPU, la mémoire et la température. Le temps entre le docker-compose up et le premier dashboard peuplé se mesure en minutes, pas en jours.

Les points forts qui justifient sa popularité :

• Support SNMP massif. LibreNMS embarque des définitions pour plus de 300 constructeurs — Cisco, Juniper, Huawei, Aruba, MikroTik, Ubiquiti, HPE, Dell, Extreme, FS, Fortinet, et bien d’autres. Le support des nouveaux équipements est communautaire : si un OID n’est pas encore mappé, une pull request de quelques lignes suffit à l’ajouter.
• Auto-discovery SNMP + ARP. Le scan de découverte interroge le routeur par défaut, lit sa table ARP, résout les MAC en constructeurs, et découvre l’intégralité du réseau de proche en proche. Un réseau de 50 switches est cartographié sans intervention manuelle.
• Intégration Oxidized. LibreNMS s’intègre avec Oxidized, le gestionnaire de backups de configuration réseau. Chaque modification de config sur un switch déclenche un backup automatique avec diff Git — vous savez exactement ce qui a changé, quand, et par qui.
• Alerting multi-transport. Email, Slack, PagerDuty, OpsGenie, Microsoft Teams, Telegram, Pushover, et Alertmanager (pour les équipes qui standardisent sur Prometheus). Le système de alert rules permet des conditions composables avec des seuils, des délais et des fenêtres glissantes.
• Billing 95th percentile. Pour les FAI et les hébergeurs, LibreNMS calcule la facturation au 95e centile directement sur les interfaces — une fonctionnalité absente des deux concurrents.

Ce que LibreNMS ne fait pas (et assume). Pas d’agent à installer : tout passe par SNMP, ce qui signifie que vous ne supervisez finement que ce que la MIB de l’équipement expose. Pas de supervision applicative native (pas de check PostgreSQL ou Nginx) — vous pouvez brancher des scripts externes via le système de services, mais ce n’est pas le cœur du produit. Pas de proxy distribué : une instance LibreNMS couvre un site ; pour du multi-site, il faut déployer plusieurs instances. Enfin, le code est en PHP — ce n’est pas un problème technique, mais certaines équipes 100 % Python/Go refusent de maintenir du code PHP en production.

SNMP v3 — le protocole que tout le monde utilise et que presque personne ne sécurise

Les trois outils supportent SNMP v1, v2c et v3. Dans la pratique, la majorité des déploiements utilisent encore SNMP v2c avec une community string en clair — l’équivalent réseau du mot de passe admin/admin. En 2026, maintenir du SNMP v2c en production n’est plus acceptable.

SNMP v3 apporte trois garanties que v2c n’offre pas :

• Authentification par utilisateur (SHA-256 ou SHA-512), pas par community string partagée.
• Chiffrement des données (AES-128 ou AES-256), ce qui empêche un attaquant passif de lire la table de routage ou la configuration des VLANs en capturant le trafic SNMP.
• Intégrité et protection anti-replay via un compteur temporel, qui bloque la rejeu d’une requête SNMP interceptée.

# SNMPv3 authPriv sur un switch Cisco IOS
snmp-server group MONITORING v3 priv read MONVIEW
snmp-server user zabbix MONITORING v3 auth sha Z4bb1x! priv aes 256 M0n1t0r!
snmp-server view MONVIEW iso included

Les trois outils le supportent nativement. Le passage de v2c à v3 est une opération de quelques heures si le parc est homogène (même constructeur, même version d’IOS), et de quelques jours s’il est hétérogène. Le coût principal n’est pas technique — c’est la coordination entre l’équipe réseau qui configure les switches et l’équipe supervision qui met à jour les credentials.

NetFlow, sFlow, IPFIX — les signaux que vos interfaces vous cachent

SNMP répond à la question « est-ce que l’interface est saturée ? ». NetFlow (Cisco, 1996), sFlow (InMon, 2001) et IPFIX (IETF, RFC 7011, 2013) répondent à la question « qui sature l’interface, vers quoi, et avec quel protocole ? ».

Ces trois protocoles exportent des flow records — des échantillons du trafic qui transitent par une interface — vers un collecteur. Le collecteur (historiquement ntopng, aujourd’hui aussi Elastiflow sur Elasticsearch ou Akvorado sur ClickHouse) agrège les flux et produit des rapports : top talkers, top destinations, protocoles dominants, anomalies de volume.

L’intégration avec la supervision existe, mais elle est indirecte :

• Zabbix ne collecte pas les flux nativement, mais s’interface avec Elastiflow ou ntopng via des trappers ou des scripts externes.
• Checkmk propose un check ntopng dans son catalogue d’extensions, et l’édition Ultimate intègre des métriques de flux via l’API.
• LibreNMS supporte NFSen (collecteur NetFlow/sFlow) en intégration native : les flux d’une interface sont accessibles en un clic depuis la page de l’équipement.

Pour un réseau de moins de 100 équipements, ntopng sur une VM dédiée suffit amplement. Le ticket d’entrée est bas : une commande de configuration sur chaque switch (ip flow ingress / ip flow egress côté Cisco), et le collecteur fait le reste.

Verdict — quel outil pour quel réseau ?

Le choix ne se fait pas sur les fonctionnalités — les trois outils couvrent l’essentiel. Il se fait sur le temps d’ingénierie et le nombre d’équipements.

Si vous partez de zéro aujourd’hui, déployez LibreNMS cet après-midi. Même si vous migrez vers Zabbix ou Checkmk dans six mois, les trois heures passées sur LibreNMS vous auront appris ce que vous devez superviser — et c’est cette connaissance, pas l’outil, qui fait la qualité de la supervision.

Si vous gérez déjà un parc de plus de 200 équipements et que votre supervision actuelle est un tableau Excel et un script ping cron, sautez directement sur Zabbix 7.0. Acceptez les deux semaines de configuration initiale comme un investissement, déployez des proxies sur chaque site, et forcez le passage en SNMP v3 au moment de la migration — c’est l’occasion parfaite pour éliminer le v2c de votre infrastructure.

Si vous êtes une équipe cloud-native qui découvre le réseau par nécessité, Checkmk 2.5 Pro ou Ultimate est votre meilleur pari. Les métriques applicatives et réseau cohabitent dans les mêmes dashboards, et l’AI-driven RCA réduit le temps moyen de diagnostic de vos incidents nocturnes.

Une chose est certaine : la question n’est pas devez-vous superviser votre réseau, mais combien de temps vos utilisateurs continueront-ils à vous servir de système d’alerte. Votre réseau émet des milliers de signaux par seconde. La seule décision qui vous appartient, c’est si vous les entendez.

Références

• Zabbix 7.0.29 Release Notes, Zabbix LLC, 28 juillet 2026.
• Zabbix Features Overview, Zabbix LLC, consulté en juin 2026.
• Zabbix Roadmap — Zabbix 8.0 LTS & MCP Agent, Zabbix LLC, 2026.
• Checkmk 2.5.0 Release Notes, Checkmk GmbH, 2026.
• Checkmk Key Highlights 2.5 — OpenTelemetry, AI, Relay, Checkmk GmbH, 2026.
• LibreNMS 26.7.0 Release, GitHub, 20 juillet 2026.
• LibreNMS Documentation — Auto-Discovery, Alerting, Oxidized, The LibreNMS Project, 2026.
• RFC 3414 — User-based Security Model (USM) for SNMPv3, IETF, décembre 2002.
• RFC 7011 — IP Flow Information Export (IPFIX), IETF, septembre 2013.
• sFlow Version 5 Specification, InMon Corp, 2004.
• ntopng — High-Speed Web-based Traffic Analysis and Flow Collection, ntop, 2026.