Les équipes peuvent désormais définir, valider et faire évoluer leurs schémas de télémétrie de manière cohérente grâce à OpenTelemetry Weaver, l’outil lancé par github.com. L’idée centrale est de considérer les signaux d’observabilité — métriques, traces, logs — non pas comme des données accessoires, mais comme une API publique qu’il faut maintenir avec la même rigueur que le code applicatif lui-même.

Ce changement d’approche vise à stopper les scénarios frustrants : des alertes qui cessent de fonctionner après un déploiement parce que les noms de métriques ont changé, ou des requêtes d’observabilité complexes dues à des désignations incohérentes. Weaver fournit les outils nécessaires pour imposer une qualité et une clarté uniformes sur l’ensemble des systèmes.

L’annonce de github.com détaille une série de fonctionnalités autour d’un registre de schémas. Cet outil permet de valider la syntaxe, la sémantique, et même d’appliquer des règles personnalisées à ces conventions. Il peut aussi consolider un registre avec ses dépendances en un seul artefact, ou encore calculer les différences précises entre deux versions de ce registre, ce qui est essentiel pour les processus de mise à jour.

Au-delà de la définition, Weaver permet de tester les données en conditions réelles. Le « live-check » permet de soumettre un flux OTLP — le protocole de télémétrie — et de vérifier sa conformité en temps réel par rapport au registre défini. On peut même utiliser la commande weaver registry emit pour générer des signaux d’exemple basés sur le schéma, offrant ainsi un banc d’essai automatisé avant le déploiement en production.

Cette exigence de standardisation trouve un écho dans le monde des contributeurs de projets open source. Par exemple, l’équipe de Keycloak a souligné que le manque de conventions sémantiques uniformes pour les fournisseurs d’identité oblige les utilisateurs à jongler avec des préfixes personnalisés, ce qui génère une friction notable pour ceux qui attendent une cohérence à l’échelle de l’écosystème.

Si les solutions de télémétrie traditionnelles, comme celles basées sur le pull (type Prometheus), offrent un niveau de confiance élevé car le scraper contacte un point de terminaison connu, les architectures basées uniquement sur le push soulèvent des questions complexes pour les opérateurs de plateformes. La crainte réside dans la vérifiabilité de l’origine d’un signal, et dans le risque qu’un pod compromis inonde l’infrastructure de signaux frauduleux, sans mécanisme de backpressure intégré.

L’arrivée de Weaver semble répondre à ce besoin de gouvernance des signaux. En imposant un schéma formel, on transforme la télémétrie d’une série de données volatiles en un contrat formel, quelque chose qui peut être audité et validé avant qu’elle n’atteigne les systèmes d’alerte. L’outil propose des commandes claires, telles que setup-weaver pour l’intégration dans les workflows d’intégration continue, et des binaires pré-construits pour Linux, Windows et Mac.

Ce qui change pour les développeurs, c’est la possibilité de générer des artefacts directement à partir du schéma. Weaver permet de produire, par exemple, du code Go ou de la documentation Markdown à partir des conventions définies. C’est une démarche qui sort du cadre purement descriptif pour entrer dans l’automatisation concrète des systèmes d’observabilité.

Sources

• GitHub – open-telemetry/weaver: OTel Weaver lets you easily develop, validate, document, and deploy semantic conventions, github.com
• Keycloak’s observability journey: a guide for project maintainers, OpenTelemetry, 2 novembre 2026 (contenu sous licence CC BY 4.0)