3 h du matin. Une alerte. Vous ouvrez cinq onglets — le dashboard infra, l’APM, l’outil réseau, le SIEM, le wiki des runbooks — et au bout de vingt minutes vous savez que ça va mal, sans savoir ce qui a changé depuis hier soir. C’est l’angle mort de la plupart des stacks d’observabilité : beaucoup de signaux, peu de réponses.
En la construisant pour nos clients depuis onze ans, on a fini par cartographier deux trous récurrents dans la stack open source moderne. Le premier est en bas, à la collecte. Le second est en haut, à la compréhension. On a construit un outil open source pour chacun : SenHub Agent et Toise. Voici l’histoire — et pourquoi elle tient en un seul fil.
Trou nº1 — la collecte est un zoo d’agents
Regardez n’importe quelle infrastructure d’ETI : un agent Prometheus ici, un exporter maison là, un capteur PRTG sur les serveurs Windows, un plugin Nagios sur le legacy, un collecteur cloud pour le reste. Chaque outil parle son dialecte. Les noms de métriques divergent, les unités aussi, et le jour où vous voulez migrer vers OpenTelemetry, vous découvrez que « migrer » veut dire ré-instrumenter dix chaînes différentes.
SenHub Agent part du principe inverse : collecter une fois, exporter partout. Un seul binaire Go (~9 Mo, zéro dépendance) embarque des probes — système, bases de données, hyperconvergence, sauvegarde, équipements réseau — et émet le tout via un pipeline OpenTelemetry unique. La même donnée ressort en OTLP, en Prometheus, et nativement en PRTG et Nagios, avec le même vocabulaire de bout en bout.
- Un agent, pas dix. Vous ajoutez une probe dans un YAML, vous ne recollez pas des exporters tiers.
- Un vocabulaire unique sur toutes les sorties : les noms, unités et attributs concordent entre PRTG, Nagios, Prometheus et OTLP.
- Pas de big bang. Vous gardez PRTG ou Nagios aujourd’hui, et la même collecte alimente votre stack OTel le jour où vous basculez. La migration devient un changement de sortie, pas de capteurs.
- Open-core, Apache 2.0 : sondes OS gratuites, sondes éditeurs (Citrix, NetScaler, Veeam, Redfish…) en Pro.
Concrètement : agent.senhub.io. C’est aussi le moteur technique de notre Monitoring as a Service.
Trou nº2 — vous avez des métriques, pas de la compréhension
Admettons la collecte propre. Vous avez maintenant des téraoctets de séries temporelles. Mais une métrique répond à « est-ce que c’est tombé ? », rarement à « pourquoi », et presque jamais à « qu’est-ce qui a changé ? ». Or 80 % des incidents commencent par un changement : un déploiement, une route réseau, une dépendance qui a bougé. Cette information-là — l’inventaire, la topologie, leur évolution dans le temps — n’est pas dans vos métriques.
Toise est la brique qui manque : une carte vivante et temporelle de votre infrastructure. Quels objets existent (hôtes, process, interfaces, adresses, routes, services), comment ils sont reliés, et — surtout — comment tout ça évolue. Le journal est event-sourced et bi-temporel : pas seulement « quel est l’état », mais « qu’est-ce qui a changé, quand, et en quoi est-ce différent d’hier ».
Et comme la vraie question d’un incident n’est jamais une requête SQL bien formée, Toise embarque un serveur MCP natif : votre assistant IA interroge le graphe en langage naturel, pour vous. « Quels switches l’hôte db-07 utilisait-il mardi dernier — et qu’est-ce qui a changé depuis ? » devient une question qu’on pose, pas une enquête de vingt minutes. Les humains gardent l’API GraphQL et une UI de debug intégrée.
Toise est en début de développement, ouvertement : l’architecture, le modèle de données, l’ingestion OTLP et le serveur MCP sont en conception active. C’est le cœur de notre travail d’IA-observabilité (projet Ops Center). À suivre sur toise.dev.
Le fil : OpenTelemetry de bout en bout
Les deux outils ne sont pas deux produits côte à côte : ils s’emboîtent. SenHub Agent émet des événements d’entités OpenTelemetry ; Toise les ingère pour construire son graphe. OTLP est la colonne vertébrale — pas de protocole propriétaire, pas de collecteur maison à maintenir, pas de couche de traduction. Vous pouvez d’ailleurs nourrir Toise depuis n’importe quel producteur OTel (un Collector standard, votre propre instrumentation), pas seulement depuis SenHub Agent.
Ce choix a trois conséquences directes pour vous :
- Zéro lock-in. Standards ouverts, licence Apache 2.0. Votre observabilité reste réversible et intégrable.
- Souveraineté. 100 % self-hostable, sans dépendance aux géants américains de l’AIOps. Le on-premise de bout en bout reste possible.
- Un seul modèle mental. De la collecte au graphe interrogé par l’IA, c’est la même donnée, le même vocabulaire. Moins de surface, moins de colle, moins de dette.
De l’outil à la mission
Pourquoi un cabinet de conseil édite-t-il des outils open source plutôt que de simplement intégrer ceux des autres ? Parce que l’exigence qu’on met dans ces dépôts est exactement celle qu’on apporte chez vous. Nos consultants ont tous fait de la production IT : SenHub Agent et Toise, ce sont les briques qu’on aurait voulu avoir à 3 h du matin. Ce qu’on apprend en les construisant — sur la collecte, la topologie, l’IA appliquée à l’ops — nourrit directement nos missions de supervision, d’observabilité et de Monitoring as a Service.
Envie de creuser ? Tout est sur nos Labs open source. Et si vous voulez déployer ça à l’échelle sans porter la charge, parlons de votre projet.
