Un tableau de bord entièrement vert ne prouve pas que votre système d’information va bien. Il prouve que la partie de votre SI que vos outils savent voir va bien. Le reste, parfois critique, n’a pas de voyant du tout. Cet article explique pourquoi cet angle mort existe, pourquoi il est structurel, et pourquoi le combler suppose de réconcilier deux mondes qu’on a eu tort d’opposer.
J’ai déjà beaucoup écrit ici sur le sujet : sur la distinction entre supervision et observabilité, sur le piège du tout-en-un, sur l’approche à deux pôles. Et, plus en détail, dans le livre blanc « De la supervision à l’observabilité ». Ces textes racontent un trajet : celui que le marché fait faire à tout le monde, de la supervision vers l’observabilité, comme on passe d’un âge à un autre. Cet article-ci commence par une question qu’on ne pose jamais une fois arrivé : et si le trajet avait laissé quelque chose derrière lui ?
Ce qui est en jeu, avant toute technique
Posons-le simplement, sans un mot de jargon. Depuis une dizaine d’années, la manière de surveiller un système d’information a beaucoup progressé. On est passé d’outils qui signalaient qu’un élément tombait à des outils qui expliquent pourquoi tout un service se dégrade. Cette évolution, de la supervision vers l’observabilité, est réelle, et elle est souhaitable.
Mais elle a une contrepartie que peu de directions informatiques voient venir, et c’est elle qui m’intéresse ici. Ces outils modernes ne savent observer que ce qu’on peut équiper : les applications récentes, les environnements conteneurisés, tout ce qui a été conçu, dès l’origine, pour être instrumenté. Le reste, l’équipement réseau, le matériel, les systèmes industriels, les environnements réglementés ou hérités, leur demeure invisible. Non pas mal couvert : structurellement hors de portée.
Le danger, pour un décideur, n’est donc pas qu’un voyant passe au rouge. C’est qu’il n’y ait pas de voyant. L’absence d’alerte n’est pas l’absence de problème : c’est l’absence de capteur. Dans un hôpital, une usine, une collectivité ou une infrastructure souveraine, la part que l’outil ne sait pas voir est souvent celle qui porte la continuité de service et l’exposition réglementaire, précisément celle sur laquelle on ne peut pas se permettre un trou. Notre maison résume sa promesse en trois mots : voir tout, agir vite, sans dépendre de personne. Cet article part d’un aveu de praticien : aujourd’hui, quelque chose empêche encore de voir tout. Et ce quelque chose n’est pas un retard à rattraper.
J’ai passé ma carrière à la charnière de ces deux mondes : la supervision historique, restée au contact du matériel et du réseau, et l’observabilité moderne, que j’exploite en production. C’est de cette position, et pas d’une tribune, que j’écris.
Pour comprendre qu’il s’agit bien d’un angle mort structurel, et non d’une mode technologique de plus, il faut suivre rapidement comment l’observabilité s’est construite. Le lecteur pressé, ou le décideur qui a déjà saisi l’enjeu, peut sauter directement à la section « L’angle mort n’est pas dans le débat ».
Quinze ans à perfectionner la même réponse
L’observabilité moderne a une histoire courte et remarquablement cohérente. En 2018, dans Distributed Systems Observability (O’Reilly), Cindy Sridharan donne au domaine son vocabulaire de référence, à savoir logs, métriques et traces, tout en signalant déjà que des plateformes comme Kubernetes ont fait émerger des modes de défaillance partiels et diffus que la supervision classique ne savait plus nommer. Son essai antérieur, « Monitoring and Observability » (2017), pose la frontière entre les deux notions. Mais regardez le cadre : dès l’origine, c’est celui de l’application distribuée. La question fondatrice est : pourquoi une requête qui traverse quarante services ressort-elle lente ?
La critique interne arrive vite, et c’est un signe de maturité du domaine, mais elle ne sort jamais du cadre. Reprocher aux « trois piliers » d’être consommés en silos plutôt que corrélés entre eux (un argument qu’on retrouve sous le titre « The Three Pillars — Revisited », o11ytime), c’est encore débattre de la bonne façon d’organiser la télémétrie applicative. « Plus de données ne fait pas plus d’observabilité », dit-on à juste titre, mais on parle toujours des mêmes données.
Puis vient l’avant-garde. En 2024, dans « There Is Only One Key Difference Between Observability 1.0 and 2.0 » (Honeycomb), Charity Majors enterre les trois piliers et propose une « observabilité 2.0 » : une source unique de vérité, l’événement large et structuré, dont on dérive tout le reste, métriques, traces et tableaux de bord. C’est, aujourd’hui, le débat le plus pointu du domaine. Et il faut le voir pour ce qu’il est : un débat sur le modèle de stockage de la télémétrie applicative. L’événement large naît de la requête. La frontière de l’innovation, en 2025, oppose deux manières de modéliser ce qu’une application produit sur elle-même.
Il existe bien une tradition qui n’a jamais quitté la machine. Brendan Gregg, avec la méthode USE, Systems Performance (2e éd., 2020) et BPF Performance Tools (2019), pratique depuis toujours une observabilité qui part du noyau et du matériel, pas de la requête. Et une génération d’outils a construit le pont : grâce à eBPF, obtenir une visibilité de grade infrastructure sans instrumenter le code. Coroot, Netdata, Pixie, Parca (Polar Signals), Cilium/Hubble : chacun à sa façon attache des sondes au système plutôt qu’au logiciel. Coroot a même nommé le coût qu’ils suppriment : l’« observability tax », ce prix en temps et en ressources de l’instrumentation manuelle, qui laisse des angles morts sur les services tiers et le legacy.
Mais regardez où s’arrête le pont. eBPF attache des sondes au noyau Linux d’un hôte que vous contrôlez. Gregg analyse la performance d’un système sur lequel vous avez la main. Toute cette ingéniosité, des trois piliers à l’événement large, de la méthode USE à eBPF, partage un présupposé qu’aucun camp n’énonce, parce qu’aucun ne le voit : elle suppose que la chose à observer est instrumentable.
L’angle mort n’est pas dans le débat. Il est sous le débat.
C’est ici que tout se joue. Pendant que l’industrie raffine, génération après génération, la manière de modéliser une télémétrie qu’elle a déjà réussi à collecter, personne ne se bat sur ce qu’elle ne peut pas collecter du tout.
Or le système d’information d’une vraie entreprise n’est pas une flotte homogène de conteneurs Linux coopératifs. C’est un assemblage hétérogène dont une part substantielle est, par construction, fermée à l’instrumentation.
Définition. J’appelle part non-instrumentable du système d’information l’ensemble des composants qui ne peuvent, par nature, accueillir ni agent, ni sonde, ni SDK, ni trace : l’équipement réseau interrogé en SNMP, le matériel physique et les capteurs, les baies de stockage et les appliances, les automates et capteurs industriels (OT/IIoT), les systèmes IBM i, les boîtes noires d’éditeurs tiers, les environnements régulés ou isolés où l’on n’installe ni agent ni sonde. Pour ces objets, il n’y a pas de noyau où attacher une sonde, pas de SDK à intégrer, pas de requête à tracer. Ils restent donc hors de portée de toute observabilité fondée sur l’instrumentation, quelle que soit sa génération. C’est ce que j’appelle aussi, en clair, l’angle mort de l’observabilité.
Sur cette part, l’« observability tax » de Coroot ne devient pas chère : elle devient infinie. Aucune somme de temps ou de ressources ne permet d’instrumenter ce qui n’a pas de surface d’instrumentation.
Et ce n’est pas un résidu en voie de disparition. Pour un hôpital, un site industriel, une collectivité, une infrastructure souveraine, cette part non-instrumentable n’est pas une dette technique qu’on retirera bientôt : c’est la majorité porteuse du système, celle sur laquelle repose le risque opérationnel réel. Le discours dominant la traite comme du legacy en sursis. Mais on ne peut pas observer ce qu’on a décrété obsolète, et déclarer obsolète l’épine dorsale d’un SI hospitalier ou industriel, ce n’est pas une stratégie d’observabilité, c’est une cécité de gouvernance.
L’observabilité, en se construisant contre la supervision, a gagné la corrélation, la haute cardinalité, la capacité à répondre au « pourquoi ». Mais elle a perdu la couverture. La supervision, elle, n’a jamais lâché la couverture du SI réel, elle l’a seulement payée d’une pauvreté analytique : des seuils, des états, peu de corrélation, presque pas de « pourquoi ». Chacun a gardé une moitié de la réponse. C’est exactement le piège que je décrivais dans « Aucun outil ne couvre tout », mais vu une couche plus bas : non plus entre produits, mais entre deux philosophies entières de la mesure.
La boucle, pas la ligne
D’où la thèse de cet article. Le mouvement honnête n’est pas supervision → observabilité, cette flèche qui congédie un monde au profit de l’autre. C’est une boucle : l’observabilité doit revenir vers l’infrastructure qu’elle a laissée derrière elle. Non pour redevenir de la supervision, mais pour apporter sa lentille, corrélation, cardinalité, le « pourquoi », à la part du SI que ni l’observabilité 1.0 ni la 2.0 ne sauront jamais atteindre, parce que toutes deux supposent qu’on peut instrumenter ce qu’on observe.
supervision ⋃ observabilité. La réunion, pas la succession. C’est le seul cadre complet pour un système d’information réel. Ce n’est pas un compromis mou entre deux camps : c’est la reconnaissance que chacun détenait la moitié manquante de l’autre. C’est aussi, très concrètement, l’approche à deux pôles qui structure notre façon de travailler, la finesse de l’observabilité moderne et la couverture de la supervision de terrain, tenues ensemble plutôt qu’opposées.
Et c’est précisément l’interstice qu’une longue pratique de la supervision, prolongée par une stack d’observabilité de production, permet d’occuper. Non pas parce qu’on aurait choisi le bon camp, mais parce qu’on a refusé de choisir.
Voir tout suppose de revenir sur ses pas
Revenons au tableau de bord vert. Le décideur qui le regarde n’a pas besoin de connaître eBPF, le SNMP ou les trois piliers pour comprendre l’essentiel : la sérénité que ce vert inspire dépend entièrement de ce que l’outil est capable de capter. Tant que la stratégie d’observabilité se limite à ce qui est instrumentable, le vert recouvre un trou, et le trou se trouve, statistiquement, là où le risque est le plus lourd : la continuité de service, la conformité, la souveraineté.
« Voir tout » n’est donc pas un slogan : c’est une exigence de couverture, et elle impose de revenir sur ses pas, vers l’infrastructure qu’on croyait avoir dépassée. La bonne question à poser à n’importe quel dispositif d’observabilité n’est pas « combien de données collectes-tu ? », mais « quelle fraction de mon SI réel restes-tu, par construction, incapable de voir ? ».
Sur le plan des outils, cette réintégration a déjà des incarnations concrètes, c’est la couche que « Deux trous dans la stack d’observabilité » décrit en détail, et que cet article surplombe conceptuellement : SenHub Agent, agent OpenTelemetry-natif qui collecte de façon unifiée, y compris ce qui n’a aucun SDK à offrir ; et Toise, la cartographie vivante et interrogeable de l’infrastructure, la part qu’on ne voyait pas, réintroduite dans le graphe. Mais l’outil vient après. C’est la thèse qui compte : tant qu’on raisonne en ligne, on perfectionne une moitié de réponse. Il faut raisonner en boucle.
Si vous voulez le commencement de l’histoire, tout est dans la série : « Supervision vs observabilité », puis le livre blanc « De la supervision à l’observabilité ».
Sources
- Cindy Sridharan, Distributed Systems Observability, O’Reilly, 2018. oreilly.com
- Cindy Sridharan, « Monitoring and Observability », 2017. copyconstruct.medium.com
- « The Three Pillars — Revisited », o11ytime. o11ytime.com
- Brendan Gregg, « The USE Method ». brendangregg.com ; Systems Performance (2e éd., 2020), BPF Performance Tools (2019)
- Coroot, « Using eBPF and predefined inspections to minimize observability tax ». coroot.com
- Charity Majors, « There Is Only One Key Difference Between Observability 1.0 and 2.0 », Honeycomb, 2024. honeycomb.io
- Écosystème eBPF cité : Netdata, Pixie, Parca / Polar Signals, Cilium / Hubble.
