L’observabilité n’est plus la seule responsabilité des équipes de fiabilité des sites ; les développeurs sont de plus en plus invités à ajouter des traces, des logs et des métriques au code qu’ils écrivent, afin de pouvoir diagnostiquer les pannes et comprendre le comportement des applications avant et après leur mise en production. Dans un article publié sur le blog de la CNCF le 25 août 2026, Adriana Villela, responsable de la communauté OpenTelemetry et ambassadrice de la CNCF, et Diana Todea, contributrice à la documentation OpenTelemetry et ambassadrice de la CNCF, présentent une démarche pratique visant à réduire la charge de cette tâche avec OpenTelemetry.
Les autrices partent d’une objection courante chez les développeurs : ajouter de l’instrumentation signifie devoir maintenir davantage de code, introduire une complexité supplémentaire et risquer de voir apparaître des erreurs ou une dette technique. Elles mettent toutefois cette charge en regard de bénéfices pratiques directs, notamment la réduction du temps consacré au débogage, l’accélération de l’achèvement et du déploiement des fonctionnalités, la détection des chemins lents, des nouvelles tentatives invisibles et des cas limites, ainsi qu’une meilleure compréhension des systèmes distribués. Selon elles, l’observabilité aide également à déconstruire les applications produites avec l’aide d’outils d’intelligence artificielle lorsque leur qualité est variable.
Commencer par l’automatisation, puis ajouter ce qui manque
La première recommandation consiste à utiliser une instrumentation sans code lorsqu’elle est disponible. Ce mécanisme ajoute de l’instrumentation à l’application sans modifier le code source, en interceptant les appels aux frameworks et bibliothèques courants à l’exécution ou lors de la compilation. Selon l’article, ce type de prise en charge existe pour Java, .NET, Python, JavaScript, PHP et Go.
Les autrices ne considèrent pas l’automatisation comme une solution complète ; elle ne sait pas nécessairement ce qui est important dans la logique de l’application elle-même. Il faut donc la compléter par une instrumentation manuelle afin d’ajouter des traces, des métriques, des logs, la propagation du contexte et les attributs propres au code. Elles proposent également de pratiquer un développement piloté par l’observabilité, c’est-à-dire d’ajouter l’observabilité pendant l’écriture du nouveau code plutôt que d’y revenir quelques jours plus tard, lorsque les détails de conception sont moins présents à l’esprit du développeur.
Que mérite-t-il d’être mesuré ?
- Les unités de travail importantes : ajoutez des spans pour les requêtes entrantes, comme les appels HTTP, les connexions sortantes aux bases de données, aux caches, aux API et aux files d’attente, ainsi que pour les opérations sensibles du point de vue métier. L’article met en garde contre la création d’un span pour chaque petit appel, car cela peut produire du bruit et masquer les signaux importants.
- Les événements significatifs : utilisez les logs pour expliquer pourquoi un événement donné s’est produit, en vous concentrant sur les erreurs, les échecs de validation, les chemins de nouvelle tentative et de repli, ainsi que les événements de sécurité comme les échecs d’authentification et les refus d’autorisation.
- Le temps de réponse : les métriques de latence aident à déterminer pourquoi une requête donnée prend plus de temps que d’habitude, en particulier dans les parcours en plusieurs étapes, comme l’ajout d’un article au panier puis la finalisation de l’achat.
- Les frameworks et bibliothèques internes : l’instrumentation des frameworks et bibliothèques développés par l’équipe elle-même peut offrir une couverture étendue, car de grandes parties de l’application les traversent.
Utiliser l’intelligence artificielle comme assistant, et non comme substitut à la révision
Les autrices estiment que les outils de programmation assistés par l’intelligence artificielle peuvent réduire le temps nécessaire pour explorer les API et les SDK OpenTelemetry, et aider également à travailler sur du code ancien. Cependant, leur utilisation exige des instructions précises. Elles recommandent de définir le rôle de l’assistant, l’objectif, l’emplacement du code et le langage utilisé, ainsi que les résultats attendus, en joignant les liens vers la documentation ou les exemples de code pertinents.
Elles conseillent également de demander à l’agent d’expliquer ses décisions et, lorsque cela est possible, d’utiliser un autre agent comme arbitre pour remettre ces décisions en question, puis de répéter la tentative et d’améliorer les résultats plutôt que d’accepter la première modification proposée par l’outil. Ces recommandations reflètent l’opinion et l’expérience des autrices et ne garantissent pas que le code produit par l’intelligence artificielle sera correct ou adapté à l’application.
Un parcours local pour comprendre les données de mesure
L’instrumentation n’est pas complète sans moyen de lire les données produites. L’article explique qu’OpenTelemetry Collector fonctionne comme un agent neutre vis-à-vis des fournisseurs : il reçoit des traces, des logs et des métriques provenant de plusieurs sources, les traite si nécessaire, puis les envoie vers une ou plusieurs destinations. Il se compose de récepteurs pour recevoir les données, de processeurs pour modifier, masquer ou échantillonner les attributs, d’exportateurs pour les envoyer, et de pipelines pour définir le chemin de chaque type de signal, ainsi que de connecteurs pour relier deux pipelines.
À des fins de développement, l’article propose une configuration simple qui reçoit les données via OTLP en utilisant gRPC ou HTTP, puis les exporte vers un module de débogage, avec un connecteur SpanMetrics pour convertir la durée des spans en données de métriques utiles à la surveillance des problèmes de latence. Il présente ensuite trois outils open source pouvant être exécutés avec Collector et Docker Compose : OTel Desktop Viewer pour afficher les traces, otel-tui pour afficher les traces, les logs et les métriques ainsi que les relations entre services via une interface terminal, et OTel Front pour afficher les trois mêmes types de données avec un tableau de bord.
Les limites à prendre en compte
L’expérience montre que ces outils ne sont pas dépourvus d’obstacles. Leur configuration a été plus facile pour les autrices grâce à leur expérience préalable avec OpenTelemetry Collector et Docker, tandis que les débutants pourraient rencontrer davantage de difficultés. Les outils dépendent également de projets open source tiers et peuvent ne pas toujours suivre les dernières versions de l’API et du SDK OpenTelemetry ni offrir une parité complète des fonctionnalités.
L’article souligne des défis plus larges dans l’écosystème, notamment les différences d’activité entre les groupes d’intérêt propres à chaque langage, l’absence d’automatisation pour certains langages comme Rust et Elixir, le grand nombre de choix entre les SDK, eBPF et l’instrumentation lors de la compilation, ainsi que les problèmes de stabilité des API, de mise à niveau des dépendances et de cardinalité élevée pour certains attributs.
Lecture éditoriale : la valeur pratique ne réside pas ici dans l’ajout d’un nouvel outil, mais dans la transformation de l’observabilité, qui passe d’une tâche remise à plus tard à une partie intégrante du cycle de développement du code. Le guide définit un point de départ nécessitant peu de friction, puis établit clairement ce que l’automatisation ne peut pas connaître. Toutefois, la source ne fournit aucune comparaison quantitative des performances entre les outils et ne démontre pas qu’une seule démarche convienne à tous les langages ou environnements ; il convient donc de considérer ces recommandations comme un cadre de départ, tout en testant les configurations et en évaluant le volume des données, leur coût et leur adéquation à l’application réelle.