C'est quoi l'observabilité ? Guide pratique pour dev

Il est 2 h du matin. L'API de paiement renvoie des erreurs 500 sur environ une requête sur vingt, et tous les tableaux de bord sont au vert. Cet écart entre « le système dit que tout va bien » et « les utilisateurs disent que ça casse » est exactement ce que l'observabilité sert à combler. C'est quoi l'observabilité ? C'est la capacité à comprendre ce qui se passe à l'intérieur de votre système en regardant les données qu'il émet (logs, métriques et traces), assez bien pour répondre à des questions que vous n'aviez pas prévues à l'avance.

Cette dernière précision est tout l'enjeu. Le reste de cet article n'est que du détail.

Observabilité contre monitoring : la question pour laquelle vous n'avez pas écrit d'alerte

Le monitoring répond aux questions que vous aviez déjà en tête. Le CPU dépasse 90 % ? Le taux d'erreur dépasse 2 % ? La file d'attente grossit ? Vous choisissez les métriques, vous fixez les seuils, et une alerte se déclenche dès qu'un seuil est franchi.

L'observabilité répond à la question que vous n'aviez pas pensé à poser. Pourquoi seules les requêtes d'un même client, sur une version précise de l'application et juste après un déploiement, prennent-elles quatre secondes de plus ? Personne n'a d'alerte pour ça, parce que personne ne l'avait prévu.

Les deux ne sont donc pas rivaux. Le monitoring est la couche d'alerte. L'observabilité, c'est ce qui vous permet d'enquêter une fois l'alerte déclenchée, ou quand un client écrit alors qu'aucune alerte n'a jamais sonné. Si votre seul outil est un mur de tableaux de bord préconfigurés, vous faites du monitoring. Si vous pouvez découper les données de production selon n'importe quelle dimension et suivre une requête à travers plusieurs services sans déployer de nouveau code, vous faites de l'observabilité.

Les trois signaux : métriques, logs et traces

La plupart des définitions commencent par les « trois piliers ». L'étiquette est un peu rigide, mais les trois types de données sont bien réels, et chacun excelle dans un rôle précis.

• Les métriques sont des valeurs numériques dans le temps : taux de requêtes, latence p95, mémoire utilisée. Peu coûteuses à stocker, rapides à interroger, parfaites pour savoir si quelque chose cloche. Mauvaises pour répondre à la question « quelle requête, et pourquoi ? ».

• Les logs sont des enregistrements horodatés d'événements ponctuels : un paiement a échoué, une nouvelle tentative est partie, un feature flag a changé d'état. Ils portent le détail, mais des logs non structurés sur un service très sollicité deviennent une botte de foin.

• Les traces suivent une requête unique à travers les services. Chaque saut est un span, avec un début, une durée et des attributs. Une trace est ce qui se rapproche le plus d'une stack trace pour un système distribué.

L'enquête 2025 de Grafana Labs, menée auprès de 1 255 praticiens, montre où en sont réellement les équipes. Selon l'enquête sur l'observabilité de Grafana Labs, 95 % des répondants utilisent des métriques et 87 % des logs, mais seulement 57 % utilisent les traces. Or les traces sont le signal le plus susceptible d'aider sur un bug distribué, et celui que le moins d'équipes ont réellement mis en place.

Oubliez le raccourci qui dit que les métriques indiquent le quoi, les logs le pourquoi et les traces le où. Il sonne bien et échoue en pratique : un bon log structuré vous en dira souvent plus sur le « où » qu'une trace mal instrumentée.

Ce qui rend un système observable en pratique

Émettre des données est nécessaire. Ça ne suffit pas. Un système est observable lorsque ses données présentent trois propriétés.

Une forte cardinalité. Vous pouvez filtrer par identifiant utilisateur, par client, par version de build, par région, par feature flag. Si votre outil vous oblige à agréger d'avance par nom de service et code de statut, vous ne trouverez jamais le seul client qui est dans un état anormal, celui qui a été migré hier soir par exemple.

Un contexte qui relie les signaux. Un identifiant de trace sur chaque ligne de log permet de passer d'un span lent aux logs exacts qu'il a produits. Sans ce lien, vous lisez deux histoires séparées et vous devinez comment elles se rejoignent.

Assez de détail pour être utile, sans coût prohibitif. C'est là que la plupart des équipes peinent. Dans la même enquête Grafana, les répondants citaient plus de 100 outils, services et projets différents, et l'équipe moyenne en utilisait huit. Le coût figurait parmi les critères majeurs de choix. Tout collecter est facile. Payer pour tout, c'est la partie qu'on découvre plus tard, souvent sur une facture de fin de mois.

Voici à quoi ressemble le point de départ avec OpenTelemetry, le standard d'instrumentation indépendant des fournisseurs. Cet exemple Python minimal crée un span et y attache les attributs dont vous aurez besoin à 2 h du matin :

from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result

Trois attributs font la différence entre « le paiement est lent » et « le paiement est lent pour le client 4412 sur la version 3.8.1 ». Le guide d'introduction d'OpenTelemetry à l'observabilité détaille les concepts derrière tout ça. Il mérite une lecture, même si votre fournisseur s'occupe du câblage à votre place.

Où les outils d'observabilité se différencient (et où ils ne se différencient pas)

Sous le marketing, la plupart des plateformes ingèrent les mêmes trois signaux. Elles se distinguent par leur modèle de prix, la puissance de leurs requêtes et la quantité d'instrumentation qu'elles font à votre place.

• Les plateformes tout-en-un regroupent métriques, logs, traces, alertes et bien plus. C'est pratique, avec pour contrepartie une facture à l'usage qui grimpe avec votre trafic.

• Les stacks open source comme Prometheus, Loki, Tempo et Grafana vous donnent le contrôle, sans licence par hôte, au prix de les faire tourner et de les régler vous-même.

• Les backends natifs OpenTelemetry acceptent directement le format standard. Changer de fournisseur ne signifie donc pas réinstrumenter chaque service.

Datadog est la référence de la catégorie tout-en-un : couverture large, interface soignée, et une facture qui mérite une revue chaque mois. Ça vaut le coup si vous voulez un seul fournisseur et que le budget suit. Passez votre chemin si la prévisibilité des coûts est votre contrainte principale.

Grafana est le choix open source pragmatique. Vous pouvez commencer par des tableaux de bord sur les données que vous avez déjà, puis ajouter logs et traces au fil du besoin. Prévoyez tout de même un investissement en temps d'ingénierie.

SigNoz est conçu autour d'OpenTelemetry dès le départ et réunit métriques, logs et traces dans une seule interface open source. C'est un bon choix pour une équipe qui veut la vue unique sans le prix d'un tout-en-un.

New Relic se situe entre les deux, avec une plateforme hébergée et une offre gratuite assez généreuse pour mener une vraie évaluation. Jugez-la sur la capacité de votre équipe à répondre à une vraie question de production, pas sur la démo.

Aucun de ces outils ne vous rendra observable à lui seul. L'outil est une interface de requêtes. C'est l'instrumentation qui fait le vrai travail.

La partie que la plupart des guides oublient : l'observabilité s'arrête à la frontière du code

Vous remarquerez cet écart dès que vous utiliserez ces outils sérieusement. Une trace vous dit que charge_card a pris 3,9 secondes et que la partie lente était un appel à payment_client. Elle ne vous dit pas ce que fait réellement payment_client, qui l'a écrit, ni pourquoi il réessaie trois fois sans aucune attente progressive.

Pour le savoir, vous quittez l'outil d'observabilité et vous allez lire le code. Dans un petit service, ça prend dix minutes. Dans un dépôt de 100 000 lignes que se partagent quatre équipes, la lecture est souvent la partie la plus longue de l'incident. Vous savez exactement quel span est lent, et vous passez quand même une heure à comprendre comment le code qui se cache derrière est câblé.

C'est le problème de passage entre les données d'exécution et le code source. C'est pour cela que nous considérons l'observabilité et la compréhension du code comme les deux moitiés d'un même flux de travail :

1. L'observabilité vous dit où ça se passe à l'exécution : quel service, quel span, quel client.

2. La compréhension du code vous dit pourquoi dans les sources : quelle fonction, quelle politique de nouvelles tentatives, quelle configuration.

Les équipes qui bouclent la boucle (un nom de span correspond à un fichier, un fichier correspond à un responsable et à une explication) réduisent le temps entre « l'alerte s'est déclenchée » et « le correctif est compris ». C'est surtout une question de discipline. Nommez vos spans d'après les fonctions, mettez le chemin du dépôt dans un attribut de span, et tenez une courte note d'architecture par service. Un assistant IA capable de répondre à des questions sur votre dépôt, du type « où est définie la politique de réessai pour les appels de paiement ? », dispose alors de quelque chose de concret sur lequel s'appuyer.

Trois erreurs qui font croire que l'observabilité ne fonctionne pas

Prendre les tableaux de bord pour le but. Un tableau de bord est la réponse enregistrée à une vieille question. Les équipes qui en construisent quarante sans jamais pratiquer l'exploration ad hoc finissent avec du monitoring dans un emballage plus joli. À chaque incident, demandez-vous si la réponse est venue d'un tableau de bord, ou de l'exploration des données brutes.

Échantillonner trop tôt, ou jamais. Garder 100 % des traces sur un service très sollicité coûte vite cher, et n'en garder que 1 % au hasard jette la rare requête en échec qui vous intéresse. L'échantillonnage en fin de chaîne, qui conserve les traces lentes et en échec et écarte la plupart des traces saines, est le compromis habituel. Décidez-le avant la première facture, pas après.

Laisser dériver les noms d'attributs. Un service écrit user_id, un autre userId, un troisième uid. Alors la requête qui devrait couvrir les trois ne renvoie qu'un tiers du tableau. Mettez-vous d'accord sur une petite convention de nommage pour les attributs de client, d'utilisateur, de version et de flag, et écrivez-la dans le dépôt, là où les gens la trouveront.

Aucune de ces erreurs n'est un problème d'outil. Ce sont des habitudes, et les habitudes coûtent moins cher à corriger que de changer de fournisseur.

Une façon réaliste de commencer sans tout instrumenter d'un coup

Si vous n'avez rien aujourd'hui, résistez à l'envie d'instrumenter tout le système dès la première semaine. Voici une séquence qui fonctionne pour des équipes de 5 à 50 ingénieurs :

1. Choisissez un parcours utilisateur critique. Le paiement, l'inscription, l'appel API principal. Pas tout le système.

2. Ajoutez des logs structurés avec un identifiant de requête. Du JSON, un événement par ligne, un identifiant de trace ou de requête sur chaque ligne.

3. Instrumentez ce parcours avec des traces OpenTelemetry. Incluez les attributs de client, de version et de flag de l'exemple plus haut.

4. Définissez deux ou trois objectifs de niveau de service. Par exemple, 99,5 % des requêtes de paiement réussissent en moins de 800 ms. Les alertes se rattachent à ces objectifs, pas à l'usage du CPU.

5. Passez en revue un incident réel avec les données. Auriez-vous trouvé la cause sans écrire de nouveau code ? Si non, l'écart que vous venez de repérer est votre prochaine tâche d'instrumentation.

L'étape 5 est celle qu'on saute, et c'est pourtant la seule qui vous dit si vous êtes observable. Le reste, c'est de la plomberie.

Ce que nous ferions concrètement

Si votre équipe compte moins de 20 ingénieurs, commencez par l'instrumentation OpenTelemetry et par un backend dont vous pouvez prévoir le prix. L'instrumentation est portable, donc le choix du backend reste réversible. Résistez à l'achat de la plus grosse plateforme parce qu'un concurrent l'a fait.

Si vous payez déjà un outil tout-en-un, ne l'arrachez pas. Auditez ce que vous ingérez, supprimez les logs que personne n'interroge, et investissez les économies dans l'instrumentation des parcours qui comptent vraiment.

Et quelle que soit la voie choisie, notez comment un span se rattache au code. Le tableau de bord vous montre l'incendie. Quelqu'un doit toujours lire le source pour comprendre pourquoi il a commencé.