La fin de l’observability approche (et ça me va très bien)

• Depuis plusieurs décennies, l’objectif central des outils d’observability était de rendre compréhensibles par les humains de vastes volumes de données de télémétrie hétérogènes
• Avec l’arrivée de l’IA et des LLM, le paradigme centré sur les « tableaux de bord + alertes + échantillonnage » évolue, et le processus d’analyse est remplacé par l’automatisation
• En pratique, un agent IA a analysé la cause d’un pic de latence en 80 secondes avec 8 appels d’outils, automatisant ce qui se faisait auparavant dans les démos, pour un coût de seulement 60 cents
• Les jolis tableaux de bord ou une instrumentation pratique n’ont plus vraiment de valeur distinctive, car les LLM banalisent l’analyse et OpenTelemetry banalise l’instrumentation
• L’observability du futur aura pour clés du succès des boucles de feedback rapides et des workflows de collaboration IA+humain, ouvrant l’ère de davantage de logiciels et d’automatisation

---

Histoire des outils d’observability et arrivée de l’IA

• Pendant des décennies, l’objectif fondamental des outils d’observability a été de compresser/résumer d’immenses volumes de données hétérogènes (télémétrie) à un niveau compréhensible par les humains
• Chaque fois que de nouvelles abstractions logicielles sont apparues (par ex. Rails, AWS, Kubernetes, OpenTelemetry, etc.),
  divers outils ont été développés pour masquer cette complexité — monitoring, instrumentation, tableaux de bord, alertes adaptatives, échantillonnage dynamique, etc. — afin de fournir une version compressée de la complexité des données adaptée aux capacités cognitives humaines

LLM = approximateur universel de fonctions, et enfin vraiment utile

• Mathématiquement, les LLM ne sont rien d’autre que des approximateurs universels de fonctions (universal function approximator), mais en pratique ils sont très utiles pour résoudre des problèmes d’observability
• Exemple : dans une démo Honeycomb, on demande à un agent IA d’analyser en langage naturel un pic de latence sur une heatmap
  • « Analyse la cause des pics de latence qui se produisent toutes les 4 heures dans le service frontend »
  • Intégration entre un LLM prêt à l’emploi (Claude Sonnet 4) et le Model Context Protocol (MCP) de Honeycomb
  • 80 secondes, 8 appels d’outils, et 60 cents de coût pour une analyse automatique de la cause
• Le niveau atteint permet de résoudre un scénario réel en zero-shot, sans prompt supplémentaire, entraînement spécifique ni guide
• Banalisation de l’analyse (commoditization) :
  • Si les LLM automatisent le travail d’analyse, les anciens différenciateurs des produits d’observability (beaux graphiques, instrumentation facile, etc.) perdent leur sens
  • OpenTelemetry banalise l’instrumentation, et les LLM banalisent l’analyse
  • À l’avenir, la « boucle de feedback rapide » remplacera la valeur centrale des outils d’observability

Le rôle des humains, et les changements à venir

• Le rôle des humains ne disparaîtra pas complètement
  • De la même façon que l’arrivée du cloud n’a pas supprimé l’informatique elle-même, l’IA ne remplacera pas les développeurs/opérateurs
  • Les gains de productivité élargissent l’ensemble du paysage et font naître encore plus de logiciels
• La question clé est la suivante :
  dans un monde où le coût d’écriture/refactorisation/analyse du code chute fortement, et où l’analyse devient quasi constante,
  vers quoi se déplace l’essence même de l’observability ?

Ce qui compte vraiment, c’est le « feedback rapide »

• Le plus important est de disposer de boucles de feedback rapides et serrées à toutes les étapes du développement et des opérations
  • L’IA sera toujours plus rapide que les humains sur la vitesse
  • Les LLM formulent rapidement des dizaines d’hypothèses, échouent, puis finissent par trouver le bon résultat
    (pour un coût très faible)
• Philosophie de Honeycomb :
  • Boucles de feedback rapides, partage collaboratif des connaissances, développement/exploitation expérimentaux
  • À l’avenir, l’assistance par IA sera introduite sur tout le cycle de vie du développement et des opérations logicielles
    • Exemples
      • Lors de l’écriture et du déploiement du code, des agents IA fournissent un feedback en temps réel et suggèrent des améliorations de bugs/de qualité
      • En production, détection/analyse/reporting automatique des emergent behavior, puis amélioration automatique après approbation
      • Les organisations les plus avancées automatiseront les rôles SRE/SWE avec l’IA et des outils, jusqu’à atteindre directement des objectifs business
• Conditions de réussite pour le futur de l’observability
  • Performance de requête à très faible latence
  • Stockage unifié des données
  • Workflows de collaboration fluides entre humains et IA
• Conclusion :
  • Les outils d’observability traditionnels centrés sur les tableaux de bord, les alertes et la visualisation
    ne sont plus le cœur du sujet à l’ère de l’IA,
    et seules survivront les « boucles de feedback rapides » et les plateformes de collaboration IA-humain

[redlasha]

Tout comme l’observability n’a pas marqué la fin du monitoring, les LLM ne marqueront probablement pas la fin de l’observability
De même que l’observability s’est développée sur la base d’un monitoring plus avancé, l’analyse par LLM se développera sur la base d’une observability plus avancée

[ethanhur]

J’attends avec impatience de voir à quelle vitesse le domaine de l’observability va innover grâce aux LLM, mais le titre est vraiment trop putaclic lol

[crawler]

Faire la promotion de son propre service en disant que « la fin approche », c’est un peu embarrassant...

Personnellement, j’attends surtout les progrès des vision LLM pour les utiliser dans les tâches de monitoring. J’ai récemment vu le billet d’un parent qui utilisait un VLM pour vérifier, pendant que son enfant dormait, qu’il n’y avait rien d’anormal, et j’ai trouvé ça vraiment intéressant.

[GN⁺]

Commentaires sur Hacker News

• J’ai l’impression qu’on sous-estime collectivement la valeur du déterminisme, et qu’à l’inverse on sous-estime aussi les coûts induits par le non-déterminisme. J’ai récemment testé un autre produit vendu avec un argumentaire similaire, et il essayait de faire une RCA de mes incidents en corrélant des graphes. Le résultat ressemblait à la page Spurious Correlations : quand on le voit, c’est à la fois évident et assez drôle
  • Il faut mieux faire savoir que les séries temporelles sont vraiment vulnérables aux corrélations fallacieuses. Même une valeur de r² ne signifie rien. Le pire, c’est quand on interprète les graphes à l’œil : si les données évoluent dans le temps, il faut utiliser des métriques appropriées à ce type de données
  • Je me trompe peut-être sur le fond, mais même dans une app basée sur un LLM, on peut implémenter une UX déterministe dans les moments vraiment critiques si la conception est bonne. Le LLM peut générer, quand c’est nécessaire, une spécification déterministe de ce qu’il doit faire, puis enregistrer cette tâche ou cette action. On peut faire en sorte que l’utilisateur puisse relancer à tout moment une spécification sauvegardée avec l’historique de la conversation, et que l’IA propose des corrections quand la spécification échoue. Le flux ressemble à l’expérience d’utiliser l’IA pour coder. Il faut simplement restreindre davantage le domaine de la spécification et réfléchir à la manière de récupérer une spécification en échec. C’est réalisable sans exiger de l’utilisateur qu’il apprenne un langage de spécification séparé
• En tant que personne douée en RCA, je crains que des collègues déjà gênés ne se retrouvent encore plus en difficulté en faisant aveuglément confiance à des outils qui donnent des réponses fausses à 10% avec un aplomb total. Je m’inquiète aussi du fait qu’ils risquent de s’en remettre uniquement à l’outil puisqu’ils n’auront plus besoin de dire publiquement qu’ils ne savent pas. Ce serait déjà moins grave si, une fois sa conclusion formulée, l’outil allait chercher des données qui contredisent cette interprétation et indiquait plus clairement des éléments probants ou les zones d’incertitude
  • On peut assez bien atténuer ce problème avec un bon system prompt. J’ai effectivement créé des prompts/instructions personnalisés qui poussent par défaut le LLM vers des réponses plus rigoureuses et mieux étayées, et l’expérience a été très bonne. Le prompt que j’utilise dans ChatGPT est le suivant : « Priorité à la substance, à la clarté et à la profondeur. Traiter chaque proposition, conception ou conclusion comme une hypothèse et la questionner avec acuité. Faire émerger tôt les hypothèses cachées, les trade-offs et les cas d’échec. Éviter les compliments inutiles s’ils ne sont pas fondés. En cas d’incertitude, le dire clairement. Toujours proposer un point de vue alternatif. N’affirmer un fait que s’il est sourcé ou solidement étayé. Si l’on s’appuie sur un raisonnement ou des informations incomplètes, le signaler explicitement. Privilégier l’exactitude à la confiance. » Avec ce type de configuration, la qualité et la profondeur des réponses s’améliorent réellement de manière significative
• L’histoire du type « New Relic a porté la révolution Rails, Datadog a accompagné l’essor d’AWS, Honeycomb a mené OpenTelemetry » est une lecture biaisée. OpenTelemetry (OTel) est né de la fusion officielle entre OpenCensus, lancé par Google, et OpenTracing, lancé par LightStep. Google, LightStep, Microsoft, Uber et d’autres organisations ont participé à la gouvernance initiale. Il est vrai que Honeycomb a fortement contribué au code, à la communauté et à l’adoption technique, mais dire qu’il a « mené » le mouvement est exagéré
  • Je lis ça en tant que personne qui a récemment adopté Honeycomb, et c’est vraiment un outil étonnant. Grâce en particulier à l’auto-instrumentation otel, on peut obtenir des insights en quelques heures. On sent aussi que les fonctions de dashboard et de requête sont issues d’une véritable philosophie de l’observability. Toute notre équipe a été frappée par le niveau de finition de l’outil. Datadog donne davantage l’impression de miser sur le marketing et la checklist “observability”
• Si on met de côté le “discours commercial”, c’est en fait l’une des applications réellement précieuses des LLM. Jusqu’ici, le monitoring et l’observability relevaient surtout des grandes équipes SRE, et la barrière restait très haute pour les petites organisations (du moins du point de vue IT). Choisir des métriques pertinentes, mettre en place des heartbeats et des baselines, tout cela exigeait du temps, des outils spécialisés, un vaste environnement de développement, et même des mécanismes de validation des changements ; la plupart des équipes IT classiques n’osaient même pas s’y attaquer. Désormais, grâce à des LLM entraînés sur les outils les plus répandus, même des équipes IT manquant de budget ou de compétences peuvent implémenter un système d’« observability » réellement solide à partir de frameworks et d’outils open source. Plus besoin de solutions par abonnement tape-à-l’œil. Pour construire des dashboards et mettre en place un monitoring vraiment utile, les LLM sont une véritable bénédiction. Pour une équipe IT capable de lire de la documentation et de faire du troubleshooting, mais sans avoir le temps d’explorer en profondeur toute la gamme de produits poussés par le CIO, l’utilité est énorme. Si on ajoute aux alertes PagerDuty ne serait-ce qu’une suggestion minimale de cause, c’est une révolution de l’observability pour les SMB/PME
  • Identifier des métriques réellement significatives n’est pas un domaine où les LLM excellent, mais pour le reste — heartbeat, baseline, etc. — c’est déjà un terrain qu’on pouvait largement automatiser avec des ConvNet (réseaux neuronaux convolutifs) depuis longtemps. Les questions de déploiement, comme la validation des changements ou les contrôles de stabilité, sortent du périmètre des outils d’observability
  • Même pour une petite équipe SRE, j’attends un impact énorme. Nous sommes deux à gérer des centaines de serveurs bare metal, et quand un incident survient, le processus de réduction de la cause est extrêmement stressant. Au point que j’envisage de construire moi-même un outil du genre MCP (Master Control Program). Plusieurs fois, des problèmes restés latents très longtemps ont fini par éclater sous forme d’erreurs ; dans ce genre de cas, les LLM pourraient être d’une grande aide
• Le titre semble trop sensationnaliste. Ce n’est pas comme si les outils d’observability existants devenaient inutiles. C’est simplement qu’on pourrait passer moins de temps à fabriquer des graphes et à les regarder. C’est comparable à l’effet des LLM dans d’autres domaines : oui, ils aident à aller plus vite sur des tâches qu’on sait déjà faire, et à apprendre comment les faire, mais ils ne remplacent pas complètement une technologie donnée
  • « Accélérer des tâches qu’on sait déjà faire », « aider à apprendre de nouvelles choses » : c’est la deuxième fois aujourd’hui que j’entends cette conclusion. Déduire via l’étape 2, puis pousser à l’extrême l’efficacité de l’étape 1, c’est probablement la direction la plus productive pour la suite
  • Le titre est accrocheur, mais le message est clair — le moat, la barrière à l’entrée, se réduit progressivement
  • J’appelle ce phénomène « l’effet Charity Majors »
• Dans la démo, ils disent : « Ce n’est pas un exemple artificiel. Nous avons posé à l’agent LLM exactement la même question que nous posons à l’utilisateur dans la démo, et il a trouvé immédiatement la bonne réponse, sans prompt supplémentaire, sans entraînement, sans indication. » Mais en réalité, ce scénario faisait déjà partie de la démo, et la solution existe déjà pour ce cas. J’aurais plutôt voulu voir un exemple artificiel permettant de montrer que le modèle généralise à une situation nouvelle qui ne figure pas exactement dans ses données d’entraînement. Les capacités réelles des LLM sont certes utiles, mais pour avancer une déclaration extrême comme « la fin de l’observability », il faut montrer que l’outil sait généraliser
• Je ne pense pas qu’on puisse parler de « fin de l’observability ». Mais les points avancés dans l’article ne sont pas totalement vides de sens non plus. Il est tout à fait probable qu’une nouvelle couche d’agents d’IA émerge dans le SRE, y compris pour la RCA. Même si cela se concrétise, la majeure partie — voire la totalité — de la stack d’observability actuelle restera nécessaire. En outre, tant que les problèmes d’hallucination, de confiance et de stabilité des LLM ne seront pas résolus à la racine, l’analyse approfondie des problèmes restera un travail humain
• La stratégie business du type « avec un peu d’IA, on peut faire tout ce que faisait un expert », c’est vraiment une stratégie business séduisante. Tristement, on pourrait copier-coller cette phrase sur 80% des startups IA actuelles sans que ça choque
  • Ça ressemble peut-être à une moquerie, mais ces « experts un peu compétents » sont des ressources <i>extrêmement</i> coûteuses. Si cette automatisation se matérialise, on comprend aussi pourquoi il y a autant de startups IA approximatives
• Cet article donne l’impression d’avoir été entièrement écrit par une IA. « L’IA met fin à ce paradigme, c’est déjà le cas, cela va transformer fondamentalement la manière de concevoir et d’exploiter les systèmes » — je vois mal en quoi le fait d’interpréter une partie des données équivaut à « la fin de l’observability »
• Le raisonnement selon lequel « on n’a plus besoin de voir les données à travers des graphes et une UI » a des limites bien réelles. Quand les LLM marchent bien, c’est formidable ; quand ils échouent, il faut qu’un humain intervienne et regarde directement les graphes et autres visualisations. Les graphes et les visualisations sont déjà difficiles, mais la collecte réelle des données, ainsi que la conception de requêtes complexes et des modes de stockage, posent un niveau de difficulté bien supérieur. L’observability ne “disparaîtra” que le jour où une véritable intelligence artificielle jugera presque tout de façon quasi parfaite. À ce moment-là, c’est la structure même de la société qui changera complètement, avec une transformation culturelle profonde — sinon une disparition, du moins une transition douloureuse. Oui, l’IA est en train de bouleverser le paysage de l’observability. C’est déjà en cours, mais on est encore loin du compte