C’est la réalité du marché en 2025-2026 : malgré les promesses marketing, aucun outil unique ne couvre de manière satisfaisante l’ensemble du spectre, de la supervision réseau la plus basse à la traçabilité applicative la plus fine.
Comprendre cette fragmentation est essentiel avant tout choix de solution. Voici pourquoi chaque famille d’outils a ses propres angles morts.
Les outils de supervision évoluent… mais restent limités
Les éditeurs d’outils d’infrastructure font des efforts considérables pour intégrer des capacités d’observabilité : meilleure gestion des logs, intégrations avec des sources de traces, tableaux de bord enrichis. Ces évolutions sont réelles et utiles.
Cependant, ces outils restent fondamentalement conçus pour la supervision d’infrastructure. Leur modèle de données, leur architecture et leurs agents sont optimisés pour interroger des équipements en SNMP, WMI, ou via des capteurs spécifiques. Ils ne sont pas nativement adaptés aux paradigmes de l’observabilité applicative : instrumentation OpenTelemetry, cardinalité élevée, traçage distribué.
Les plateformes d’observabilité ne remplacent pas la supervision
Inversement, les plateformes d’observabilité excellent dans le traitement des métriques applicatives, des logs structurés et des traces distribuées. Mais elles ne sont pas conçues pour remplacer un outil de supervision d’infrastructure :
- Découverte automatique d’équipements réseau (switches, routeurs, firewalls)
- Supervision SNMP fine avec des milliers de capteurs préconfigurés
- Cartographie et dépendances d’infrastructure physique
- Gestion des SLA et des rapports pour les équipes réseau
Le piège du « tout-en-un »
Certaines solutions SaaS (Datadog, New Relic, Dynatrace) promettent de tout couvrir. Si ces plateformes sont puissantes, elles posent d’autres questions :
- Coût : tarification basée sur le volume de données ingérées, potentiellement très élevée à l’échelle. À 500 Go/jour de logs et métriques, les factures peuvent rapidement atteindre plusieurs dizaines de milliers d’euros par mois.
- Verrouillage éditeur : dépendance à un écosystème propriétaire qui complique toute évolution. Changer d’éditeur signifie ré-instrumenter, ré-former, ré-budgéter.
- Souveraineté des données : externalisation de toute la télémétrie vers un cloud tiers, le plus souvent américain. Pour les SI régulés (ANSSI, HDS, NIS2), c’est rédhibitoire.
- Couverture réelle : couverture insuffisante de la supervision bas niveau réseau et stockage on-premise. Le « tout-en-un » est souvent un « tout pour le cloud public ».
L’enjeu critique de la volumétrie
Lorsqu’on parle d’observabilité, on parle de volumes de données sans commune mesure avec la supervision traditionnelle. Un outil de supervision classique collecte quelques milliers de métriques à intervalles espacés. Une stack d’observabilité ingère en continu des millions de séries temporelles, des flux de logs de l’ensemble des composants applicatifs, et des traces couvrant chaque requête.
À l’échelle d’une infrastructure de taille intermédiaire, les volumes se comptent rapidement en centaines de gigaoctets. Pour les environnements plus conséquents — microservices, Kubernetes, multi-cloud — on atteint facilement le téraoctet, voire la dizaine de téraoctets sur des rétentions de quelques mois.
Le choix d’un backend d’observabilité ne peut pas se faire uniquement sur les fonctionnalités : l’efficacité du stockage est un critère stratégique qui conditionne la viabilité économique du projet.
Comment articuler les outils ?
Plutôt que de chercher l’outil unique, nous défendons une approche dite « bicéphale » — deux pôles complémentaires, chacun optimisé pour son périmètre, interconnectés par des standards ouverts. C’est l’objet de notre prochain article.
Cet article est tiré de notre livre blanc « De la supervision à l’observabilité » (PDF, 2026).
