Observability vs Monitoring

Le monitoring vous réveille à 3h du matin avec une alerte : "L'application est cassée." L'observabilité vous permet de comprendre pourquoi elle est cassée — sans avoir à deviner, sans déployer du code de debug en urgence, sans fouiller des logs en vrac pendant que les utilisateurs attendent.

Ce sont deux disciplines complémentaires, pas deux termes interchangeables. Et comprendre la frontière entre les deux change profondément la façon dont vous opérez un système en production.

Le monitoring : surveiller ce que vous connaissez déjà

Le monitoring est la pratique de surveiller des indicateurs prédéfinis pour détecter quand quelque chose sort de la normale. Vous décidez à l'avance ce qui compte, vous définissez des seuils, et vous déclenchez des alertes quand ces seuils sont franchis.

Concrètement, le monitoring couvre :

• Les dashboards — des tableaux de bord qui affichent en temps réel les métriques clés : taux d'erreur, latence moyenne, nombre de requêtes par seconde, utilisation CPU et mémoire.
• Les alertes — des règles qui déclenchent une notification quand une métrique dépasse un seuil. "Si le taux d'erreur HTTP 5xx dépasse 2% pendant 5 minutes, envoyer un PagerDuty."
• Les métriques système — CPU, RAM, disque, réseau. Les métriques applicatives — temps de réponse, taux de succès, taille des files d'attente.

Le monitoring répond bien à la question : "Est-ce que ça fonctionne ?"

Mais il a une limite fondamentale : il ne peut surveiller que ce que vous avez anticipé. Si quelque chose d'inattendu se produit — un problème qui n'a jamais existé avant, une interaction entre services que vous n'aviez pas modélisée — le monitoring ne vous dira pas quoi chercher. Il vous dira juste que quelque chose cloche.

L'observabilité : comprendre ce que vous ne connaissez pas encore

L'observabilité est un concept emprunté à la théorie du contrôle. Un système est dit observable si son état interne peut être inféré à partir de ses sorties externes. Appliqué au logiciel : un système observable est un système que vous pouvez comprendre de l'intérieur en interrogeant ses données de sortie, même pour des problèmes que vous n'aviez pas prévus.

Là où le monitoring vous dit "quelque chose ne va pas", l'observabilité vous permet de poser des questions arbitraires sur votre système et d'obtenir des réponses :

• "Quelles requêtes ont un temps de réponse supérieur à 2 secondes pour les utilisateurs en Europe ?"
• "Le Payment Service est-il plus lent depuis le dernier déploiement ?"
• "Quelle est la séquence exacte d'appels qui a conduit à cette erreur 500 ?"

L'observabilité n'est pas une liste de métriques à surveiller. C'est la capacité à explorer librement l'état de votre système, même en territoire inconnu.

La différence clé : questions prédéfinies vs exploration libre

La distinction la plus utile :

Monitoring = vous posez les questions avant le problème. Vous savez ce qui peut mal tourner et vous le surveillez. Si le problème que vous aviez anticipé se produit, vous êtes prévenus.

Observabilité = vous pouvez poser des questions pendant le problème. Même si vous n'aviez jamais imaginé cette combinaison de défaillances, vous pouvez naviguer dans les données pour trouver la cause racine.

Un tableau simple pour fixer l'idée :

Le monitoring est nécessaire. L'observabilité est ce qui vous permet de survivre aux incidents que le monitoring ne savait pas anticiper.

Les 3 piliers de l'observabilité

L'observabilité repose sur trois types de données, souvent appelés les trois piliers.

1. Les logs structurés

Un log est un enregistrement textuel d'un événement. Mais un log structuré est un log émis dans un format machine-lisible — JSON en pratique — avec des champs cohérents et interrogeables.

{
  "timestamp": "2026-02-21T14:32:01.234Z",
  "level": "ERROR",
  "service": "payment-service",
  "trace_id": "abc123def456",
  "user_id": "usr_9182",
  "order_id": "ord_7734",
  "message": "Timeout connecting to Stripe API",
  "duration_ms": 5002,
  "stripe_endpoint": "/v1/charges"
}

La différence avec un log classique (ERROR: timeout) est massive. Avec des logs structurés, vous pouvez filtrer, agréger, corréler. "Montre-moi tous les timeouts Stripe des 30 dernières minutes pour les commandes supérieures à 100€" devient une requête, pas une lecture manuelle de fichiers.

2. Les traces distribuées

Dans un système monolithique, déboguer une requête lente est simple : regarder le stack trace. Dans un système distribué où une requête traverse dix services, c'est une autre histoire.

Le tracing distribué résout ce problème. Chaque requête entrante reçoit un identifiant unique — le trace_id — qui est propagé dans tous les appels inter-services. Chaque opération génère un span : un enregistrement de début, de fin, de durée et de contexte.

Requête utilisateur  [trace_id: abc123]
│
├── API Gateway          [span: 2ms]
│
├── Order Service        [span: 45ms]
│   ├── Auth check       [span: 8ms]
│   └── DB query         [span: 12ms]
│
└── Payment Service      [span: 5050ms] ← GOULOT
    └── Stripe API call  [span: 5002ms] ← TIMEOUT

En visualisant la trace, vous voyez instantanément où le temps est passé. Pas besoin de corréler manuellement des logs de dix services différents.

3. Les métriques

Les métriques sont des mesures numériques agrégées dans le temps : nombre de requêtes par seconde, latence au 99e percentile, taux d'erreur, taille de la heap JVM. Elles sont compactes, efficaces à stocker, et idéales pour les dashboards et les alertes.

Les métriques en observabilité vont plus loin que le monitoring classique. Elles sont contextualisées par des labels : service=payment, region=eu-west, version=2.4.1. Ce qui permet de décomposer une métrique agrégée pour identifier quelle dimension exacte pose problème.

latence_p99{service="payment", region="eu-west"} = 4800ms
latence_p99{service="payment", region="us-east"} = 120ms

En trois secondes, vous savez que le problème est géographiquement localisé.

Les outils du marché

L'écosystème est riche. Quelques acteurs incontournables :

Solutions tout-en-un (monitoring + observabilité) :

• Datadog — la plateforme la plus complète du marché. Logs, traces, métriques, dashboards, alertes, APM. Puissant, coûteux.
• New Relic — concurrent direct de Datadog, avec un modèle de pricing alternatif basé sur les utilisateurs.

Open-source, à composer soi-même :

• Prometheus — collecte et stockage de métriques. Standard de facto pour le monitoring Kubernetes.
• Grafana — visualisation et dashboards. S'intègre avec Prometheus, Loki, Tempo et des dizaines d'autres sources.
• Loki — agrégation de logs, par Grafana Labs. Pensé pour être simple et économique.
• Jaeger — tracing distribué open-source, issu d'Uber. Compatible OpenTelemetry.
• Zipkin — alternative à Jaeger pour le tracing, plus ancien, toujours utilisé.

Le standard qui change tout :

• OpenTelemetry (OTel) — un standard ouvert pour instrumenter votre code une seule fois et envoyer logs, traces et métriques à n'importe quel backend. Évite le vendor lock-in. En 2026, c'est devenu la norme d'instrumentation.

Exemple concret : déboguer un timeout en production

C'est vendredi après-midi. PagerDuty sonne. L'alerte de monitoring dit : "Latence API supérieure à 3 secondes — SLA à risque."

Sans observabilité, votre debug ressemble à :

1. Regarder les dashboards CPU/RAM — tout est normal.
2. Chercher dans les logs — des milliers de lignes, pas de pattern évident.
3. Deviner : "C'est peut-être la base de données ?" Vérifier. Non.
4. "C'est peut-être le cache ?" Vérifier. Non.
5. Déployer du code de debug supplémentaire. Attendre le prochain incident.

Avec observabilité, votre debug ressemble à :

1. Ouvrir la trace de l'une des requêtes lentes. En 10 secondes, vous voyez que 98% du temps est dans le Payment Service, dans le span stripe_api_call.
2. Filtrer les logs structurés sur service=payment AND duration_ms > 3000. Tous les timeouts pointent vers le même endpoint Stripe : /v1/payment_intents.
3. Regarder les métriques Stripe désagrégées par endpoint. Le p99 de /v1/payment_intents a augmenté de 120ms à 5000ms il y a 45 minutes.
4. Vérifier la status page Stripe. Incident en cours sur leur API en Europe.
5. Activer le fallback vers le circuit breaker. Incident résolu en 12 minutes.

La différence n'est pas anecdotique. C'est la différence entre "on cherche" et "on sait".

Quand passer du monitoring à l'observabilité

Le monitoring seul est suffisant si :

• Votre système est simple — un monolithe avec une base de données.
• Les pannes possibles sont connues et limitées.
• Votre équipe est petite et connaît l'ensemble du code.

L'observabilité devient indispensable dès que :

• Votre architecture est distribuée — microservices, fonctions serverless, événements asynchrones. Une requête qui traverse plusieurs services est impossible à déboguer sans tracing.
• Vos pannes sont imprévisibles — plus votre système est complexe, plus les modes de défaillance sont nouveaux et inattendus. L'observabilité est votre filet de sécurité.
• Votre SLA est exigeant — quand vous devez résoudre un incident en minutes, pas en heures, vous ne pouvez pas vous permettre de deviner.
• Vos équipes sont spécialisées — l'observabilité donne à chaque équipe l'autonomie pour investiguer sans dépendre de quelqu'un qui "connaît le système entier".

La bonne approche en pratique : commencez par du monitoring solide. Des alertes bien calibrées, des dashboards clairs sur vos SLIs et SLOs. Puis investissez dans les trois piliers — en priorité le tracing distribué si vous avez des microservices, car c'est ce qui apporte le plus de valeur immédiate.

Et adoptez OpenTelemetry dès le départ : instrumenter une seule fois pour pouvoir changer de backend sans tout réécrire, c'est la décision qui vous évitera le plus de regrets dans deux ans.

Le monitoring vous dit que quelque chose est cassé. L'observabilité vous dit quoi réparer.