# C'est quoi l'observabilité ? Guide pour les équipes ops

URL: https://upstreamapi.com/fr/journal/c-est-quoi-observabilite
Type: blog
Locale: fr
Published: 2026-11-14
Updated: 2026-11-14

---

> L'observabilité explique pourquoi un système se comporte mal à partir de sa télémétrie. Logs, métriques, traces, cardinalité, coûts et premier chemin à instrumenter.

Il est 3 h du matin et l'alerte vient de tomber. Le p99 de l'API de paiement est passé de 180 ms à 1,4 s. Le dashboard CPU, mémoire et taux d'erreur est vert. Chaque panneau pré-construit affirme que le service va bien, et chaque client affirme le contraire. Ce que vous faites dans les dix minutes suivantes détermine la durée de l'incident. C'est le sujet de cet article.

C'est quoi l'observabilité ? C'est la capacité à expliquer pourquoi un système se comporte mal à partir de la télémétrie qu'il émet déjà, y compris pour des pannes que personne n'a prévues. Le monitoring vous dit que la latence du checkout a franchi 800 ms. L'observabilité vous permet de savoir quel client, quelle dépendance ou quel déploiement en est responsable, sans livrer de nouveau code en pleine nuit pour le découvrir.

## Pourquoi la définition compte-t-elle avant les outils ?

Le terme vient de la théorie du contrôle : un système est observable si l'on peut déduire son état interne à partir de ses sorties externes. Le logiciel l'a emprunté, puis les éditeurs l'ont étiré jusqu'à en faire un simple produit de dashboards. Mieux vaut écarter cette extension.

La définition utile pour une équipe d'ingénierie est plus étroite et plus pratique. Un système est observable quand vous pouvez répondre à une nouvelle question sur son comportement, en production, sans déployer de nouvelle instrumentation. Le mot qui compte est « nouvelle ». Une alerte sur seuil répond à une question écrite par quelqu'un le trimestre dernier. Un système observable répond à celle que vous vous posez maintenant.

Ce n'est pas un test de pureté. Personne n'a un système parfaitement observable, et l'objectif n'est pas un score. L'objectif est un chemin plus court entre « quelque chose ne va pas » et « voilà le changement qui l'a causé ». Le temps moyen de détection et le temps moyen de compréhension sont deux nombres différents, et la plupart des équipes ne suivent que le premier.

![Croquis au tableau blanc de services reliés par des flèches](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/3a5d62-i1.webp)

## En quoi l'observabilité diffère-t-elle du monitoring ?

Le monitoring consiste en contrôles contre des modes de défaillance déjà connus : CPU au-dessus de 90 % pendant cinq minutes, taux d'erreur au-dessus de 1 %, file d'attente au-delà de 10 000 messages. Il est peu coûteux, fiable, et vous en aurez toujours besoin. L'observabilité ne le remplace pas.

La différence apparaît quand la panne est inédite. Le monitoring se construit à partir de vos incidents passés. L'observabilité se construit pour le prochain, celui que vous n'avez, par définition, pas encore vu.

Un test simple : prenez vos trois derniers incidents et demandez-vous comment la cause a été trouvée.

- 
Si quelqu'un a lu un dashboard pré-construit et que la réponse s'y trouvait, le monitoring a fait son travail.

- 
Si quelqu'un a parcouru les logs de six hôtes, formulé une hypothèse, puis ajouté une ligne de log et redéployé pour la confirmer, il manquait de l'observabilité.

- 
Si la vraie réponse est venue de la capture d'écran d'un client, vous avez les deux problèmes.

Inutile de débattre pour savoir lequel des deux est le rival de l'autre. Ce sont des couches. Le monitoring est le détecteur de fumée. L'observabilité permet de parcourir le bâtiment après coup et de comprendre quel circuit a déclenché l'incendie.

## Quels sont les trois signaux, et où chacun échoue-t-il ?

Les logs, les métriques et les traces forment le trio classique. Chacun répond à une question différente, et chacun a un mode d'échec que les guides des éditeurs passent souvent sous silence.

**Les métriques** sont des mesures numériques agrégées dans le temps : débit, taux d'erreur, percentiles de latence, saturation. Elles coûtent peu à stocker et répondent vite aux requêtes, c'est pourquoi les alertes reposent sur elles. Leur échec tient à l'agrégation. Un p99 à 1,4 s vous dit que quelque chose est lent. Il ne peut pas vous dire que toutes les requêtes lentes appartiennent à un seul client, sur un seul shard.

**Les logs** sont des enregistrements horodatés d'événements discrets. Ils contiennent le plus de détails et la structure la plus faible, sauf si vous imposez une structure. Leur échec tient au volume et au coût. Des logs non structurés ne se cherchent efficacement que par ceux qui savent déjà quelle chaîne de caractères chercher, ce qui en fait un outil de monitoring déguisé en outil de débogage.

**Les traces** suivent une requête unique à travers les frontières des services, avec un span pour chaque saut et sa durée. Elles sont le seul signal qui montre la forme d'une requête : cet appel a attendu 900 ms une dépendance aval qui a réessayé trois fois. Leur échec tient à la couverture. Un seul service qui perd le contexte de trace casse la chaîne, et une trace trouée est pire qu'inutile, car elle paraît faire autorité.

Avoir les trois signaux ne suffit pas à être observable. Ce qui compte, c'est la corrélation. Il faut pouvoir passer d'un pic de métrique aux traces qui y ont contribué, puis de la trace aux logs de cette requête précise. Si les trois vivent dans des outils séparés sans identifiant commun, vous avez trois systèmes de monitoring, et c'est un ingénieur qui fait la jointure à la main.

## Pourquoi la cardinalité décide-t-elle de tout déboguer ?

La cardinalité est le nombre de valeurs distinctes que peut prendre un champ. `status_code` en a une vingtaine. `customer_id` en a des centaines de milliers. `request_id` en a une par requête.

Les champs dont vous avez le plus besoin pendant un incident sont justement ceux à forte cardinalité. « Quel client est touché ? » est une question sur `customer_id`. « Quelle version déployée sert les requêtes lentes ? » est une question sur `deploy_version`. Si votre modèle de stockage pénalise ces champs, en facturant chaque série unique ou en les supprimant silencieusement, vous ne pourrez pas poser la question qui débloque l'incident.

C'est la véritable ligne de partage entre une configuration tout-métriques et une configuration observable. Les métriques pré-agrégées jettent les dimensions dont vous aurez besoin plus tard. Les événements larges et structurés les conservent, et vous découpez a posteriori.

Voici à quoi ressemble un événement utile en bordure de service : un enregistrement structuré par requête, avec assez de contexte pour découper selon tout ce qui comptera plus tard.

`logger.info("request.completed", {
  trace_id: span.traceId,
  route: "/v1/payments",
  customer_id: ctx.customerId,
  deploy_version: process.env.BUILD_SHA,
  flag_variant: flags.get("new-ledger-path"),
  db_ms: timings.db,
  upstream_ms: timings.upstream,
  status: res.statusCode,
  duration_ms: elapsed,
});`Remarquez la variante du feature flag. Une grande partie des incidents commence par un changement, et l'évaluation d'un flag en est un. Si la variante n'apparaît pas dans l'événement, vous ne pouvez pas vérifier si les requêtes lentes sont celles qui passent par le nouveau chemin.

![Bureau avec un ordinateur portable affichant un dashboard de latence](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/c95a59-i2.webp)

## À quoi ressemble un incident avec et sans observabilité ?

Reprenons le scénario de paiement. Même alerte, même p99 à 1,4 s.

Sans observabilité, la boucle est la suivante : ouvrir le dashboard du service, ne rien trouver, ouvrir celui de la base, ne rien trouver, demander dans le canal d'incident si quelque chose a été déployé. Quelqu'un se souvient d'un changement de configuration, quelqu'un d'autre n'est pas d'accord. Quarante minutes plus tard, vous annulez le dernier déploiement pour voir si cela aide. Ce n'est pas le cas, car la cause était un déploiement progressif d'un flag sur un sous-ensemble de clients.

Avec observabilité, la boucle devient : regrouper les requêtes lentes par `flag_variant`, constater que la quasi-totalité passe par `new-ledger-path`, regrouper par `customer_id`, voir que trois gros clients concentrent l'essentiel du volume, ouvrir une trace et constater que l'appel au grand livre se déploie en 40 requêtes SQL séquentielles. Durée totale : quelques minutes. Vous coupez le flag, pas le déploiement.

Remarquez ce que cette seconde boucle n'a pas eu besoin. Elle n'a pas eu besoin d'un dashboard préparé. Elle n'a pas eu besoin que quelqu'un ait prédit à l'avance que la variante de flag serait une dimension intéressante. Elle avait besoin que les données soient là, larges et interrogeables.

C'est l'argument défendu par Honeycomb, et il tient. Mais il ne faut pas croire que c'est gratuit.

## Combien ça coûte, et qui peut se passer de la version chère ?

La télémétrie est d'abord un problème de volume de données avant d'être un problème d'outillage. Selon l'[enquête 2025 de Grafana Labs auprès de 1 255 praticiens](https://grafana.com/blog/2025/03/25/observability-survey-takeaways), une organisation moyenne utilise huit outils d'observabilité différents, et le coût est le critère le plus cité au moment d'en choisir de nouveaux. Ces deux faits sont liés. Les équipes accumulent des outils parce que chacun résout une tranche du problème, puis paient l'ingestion en double dans tous.

Quelques règles pratiques, valables pour la plupart des tailles d'équipe :

- 
**Instrumentez avec OpenTelemetry, pas avec un agent propriétaire.** Le collecteur offre un point unique pour échantillonner, filtrer et router. Changer de backend devient une modification de configuration, pas un projet de réinstrumentation.

- 
**Échantillonnez les traces délibérément.** Gardez toutes les erreurs et toutes les requêtes lentes, et échantillonnez les requêtes saines et rapides. Un échantillonnage fixe à 1 % en tête de chaîne jettera justement la trace dont vous avez besoin.

- 
**Structurez les logs à l'écriture.** Analyser du texte libre au moment de la requête est la façon coûteuse d'obtenir des champs.

- 
**Définissez une rétention par signal.** Métriques sur un an, événements larges sur deux semaines, logs de debug sur trois jours. Les logs de debug du trimestre précédent servent rarement.

Passez à l'approche plateforme complète si vous exploitez quelques services et une seule astreinte, ce n'est pas nécessaire. Une petite équipe tire l'essentiel du bénéfice de logs structurés, de métriques RED et de traces sur les deux ou trois chemins les plus sollicités. Le contrat coûteux, qui fait tout, se rentabilise quand le nombre de services est tel que personne ne garde toute la topologie en tête, ce qui, d'après notre expérience, arrive au-delà de 30 ou 40 services.

## Quels outils valent la peine d'être examinés ?

Le choix dépend de ce que vous voulez exploiter vous-même, de la forme de votre cardinalité et de ce que votre facture peut absorber. Voici un tour rapide et assumé.

Datadog est l'option commerciale la plus complète : métriques, logs, traces et profilage sous un même toit, avec une corrélation solide entre eux. Le prix de cette intégration est une facture qui croît avec le nombre d'hôtes, les métriques personnalisées et le volume de logs ingérés. Pertinent si vous voulez un seul fournisseur et que le budget suit. Vérifiez la ligne des métriques personnalisées avant de vous engager.

Grafana est le choix par défaut quand vous voulez des composants ouverts, auto-hébergés ou achetés en pile managée. Il s'associe bien aux métriques de type Prometheus et aux pipelines OpenTelemetry. Le compromis est opérationnel : vous assemblez davantage, et la dispersion d'outils relevée dans l'enquête vous concerne aussi.

SigNoz est une option open source, native OpenTelemetry, qui place logs, métriques et traces dans un même datastore. C'est important pour le point sur la corrélation, car un stockage commun transforme le passage métrique, trace, puis log en une requête plutôt qu'en un changement d'onglet. C'est raisonnable pour une équipe qui veut l'auto-hébergement sans assembler quatre projets.

Better Stack combine supervision de disponibilité, alerte d'incident et gestion de logs, à un prix pensé pour les petites équipes. C'est un premier pas sensé si vous passez de « on l'apprend par les clients » à quelque chose de structuré. Il est moins adapté à un maillage de services volumineux avec des besoins lourds en traces.

![Allée de centre de données avec des voyants d'état](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/63d34b-i3.webp)

## Comment commencer sans vouloir tout faire d'un coup ?

Ne commencez pas par une évaluation d'outils. Commencez par vos trois derniers incidents et une question honnête : qu'auriez-nous aimé pouvoir demander ?

Voici une séquence qui fonctionne pour une équipe de 50 à 200 ingénieurs :

- 
**Choisissez un chemin de requête critique** et instrumentez-le de bout en bout avec OpenTelemetry. Le checkout, la connexion, ce qui vous réveille à 3 h du matin.

- 
**Émettez un événement structuré large par requête** en bordure de service, avec le client, la version, les variantes de flags et les durées des dépendances.

- 
**Définissez un SLO sur ce chemin** et alertez sur la vitesse de consommation du budget d'erreur, pas sur des seuils bruts. Ces alertes vous réveillent pour un impact utilisateur, et la télémétrie de l'étape 2 vous dit pourquoi.

- 
**Organisez un exercice.** Injectez une panne que vous n'avez pas alertée et mesurez le temps qu'il faut à quelqu'un qui n'a pas écrit le code pour la trouver. Ce chiffre sert de référence.

- 
**Étendez-vous** un chemin à la fois, seulement après que le premier a fait ses preuves lors d'un vrai incident.

L'observabilité s'achète comme une plateforme, mais elle s'adopte comme une habitude. L'habitude consiste à se demander, pendant la revue de code et non pendant l'incident, ce qu'il faudrait savoir pour expliquer ce comportement.

Relisez votre dernier compte rendu d'incident. Cherchez la phrase « nous avons ensuite ajouté des logs pour confirmer ». Chacune de ces phrases désigne une question que votre système n'a pas pu répondre en production. Combien en avez-vous consignées, et lesquelles resteraient sans réponse aujourd'hui ?

## FAQ

### Quelle est la différence entre observabilité et monitoring ?

Le monitoring surveille des modes de défaillance déjà connus, à l'aide de seuils et de contrôles. L'observabilité permet de poser une nouvelle question sur le comportement du système, en production, sans ajouter d'instrumentation. Les deux sont complémentaires.

### Quels sont les trois signaux de l'observabilité ?

Les logs décrivent des événements discrets, les métriques mesurent des valeurs agrégées dans le temps et les traces suivent une requête à travers plusieurs services. Leur valeur vient surtout de la corrélation entre eux, grâce à un identifiant commun.

### Pourquoi la cardinalité est-elle importante ?

Les champs à forte cardinalité, comme l'identifiant client ou la version déployée, sont ceux qui permettent d'isoler la cause d'un incident. Un modèle de stockage qui les pénalise ou les supprime empêche de répondre à ces questions.

### Faut-il adopter OpenTelemetry ?

OpenTelemetry est un standard ouvert qui permet d'instrumenter une fois et de changer de backend sans réinstrumenter le code. C'est le choix le plus sûr pour limiter la dépendance à un fournisseur.

### Combien d'outils d'observabilité une entreprise utilise-t-elle en moyenne ?

Selon l'enquête 2025 de Grafana Labs, auprès de 1 255 praticiens, l'organisation moyenne utilise huit outils d'observabilité différents, et le coût est le critère le plus cité lors d'un choix.

### Par où commencer pour une petite équipe ?

Instrumentez d'abord un seul chemin critique de bout en bout, émettez un événement structuré par requête et définissez un SLO avec des alertes sur la consommation du budget d'erreur. Étendez ensuite la couverture progressivement.