Votre dashboard affiche 42 graphiques, tout semble vert, mais vos utilisateurs se plaignent de lenteurs. Votre monitoring vous dit que tout va bien — il ne peut pas vous dire pourquoi les utilisateurs souffrent. C’est exactement la différence entre observabilité et monitoring : le premier surveille ce que vous connaissez déjà, la seconde vous permet de diagnostiquer ce que vous n’aviez pas prévu.
Ce guide vous donne un modèle mental durable pour comprendre la distinction, savoir pourquoi les deux approches sont complémentaires et quand passer de l’une à l’autre — indépendamment de tout outil ou vendor.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La définition précise du monitoring et de l’observabilité
- Pourquoi le monitoring seul ne suffit plus dans les systèmes distribués
- Les 3 piliers de l’observabilité : logs, métriques, traces
- La différence entre known unknowns et unknown unknowns
- Quand investir dans l’observabilité (et quand le monitoring suffit)
D’où vient le concept d’observabilité ?
Section intitulée « D’où vient le concept d’observabilité ? »Le terme observabilité ne vient pas du monde informatique. Il a été formalisé en 1960 par le mathématicien Rudolf Kalman dans son article fondateur On the General Theory of Control Systems, dans le cadre de la théorie du contrôle des systèmes dynamiques. Sa définition originale est simple : un système est observable si on peut reconstituer entièrement son état interne à partir de ses sorties externes.
En d’autres termes : peut-on comprendre ce qui se passe à l’intérieur d’un système en regardant uniquement ce qui en sort ? Cette question, posée pour des systèmes mécaniques et électriques dans les années 1960, est devenue cruciale pour les systèmes informatiques distribués des années 2020.
L’analogie est directe : vos applications produisent des sorties — logs, métriques, traces. Si ces sorties sont suffisamment riches et structurées, vous pouvez reconstituer l’état interne du système sans avoir besoin de vous connecter à chaque serveur pour regarder ce qui se passe.
Le monitoring : surveiller ce qu’on connaît
Section intitulée « Le monitoring : surveiller ce qu’on connaît »Le monitoring (ou supervision) est la pratique la plus ancienne et la plus répandue. Son principe est simple : vous définissez à l’avance ce que vous voulez surveiller, vous posez des seuils et vous déclenchez des alertes quand ces seuils sont franchis.
Concrètement, un système de monitoring classique fait trois choses :
- Collecte des métriques à intervalles réguliers (CPU, RAM, disque, réseau, temps de réponse HTTP)
- Compare ces métriques à des seuils que vous avez définis (“alerte si CPU
90% pendant 5 minutes”)
- Vous prévient quand un seuil est franchi (email, SMS, PagerDuty)
Le monitoring répond à des questions que vous avez posées à l’avance : “Est-ce que mon serveur web répond ?”, “Est-ce que le disque est bientôt plein ?”, “Est-ce que la latence dépasse 200ms ?”. Si vous n’avez pas posé la question, le monitoring ne peut pas vous alerter.
En pratique, le monitoring moderne inclut aussi des alertes statistiques (détection d’anomalies, baseline dynamique), mais il reste le plus souvent centré sur des questions définies à l’avance par l’équipe.
Ce que le monitoring fait bien
Section intitulée « Ce que le monitoring fait bien »Le monitoring est excellent pour les situations prévisibles :
- Détecter qu’un service est tombé (check HTTP, TCP, ICMP)
- Suivre la consommation de ressources dans le temps
- Déclencher des alertes sur des seuils connus
- Alimenter des dashboards de supervision
- Valider que les composants “fonctionnent” au sens basique du terme
Pour un serveur monolithique avec quelques services bien identifiés, le
monitoring classique est souvent suffisant. Des solutions comme Nagios,
Zabbix ou même un simple script cron qui vérifie que votre site répond font
parfaitement le travail.
Les limites du monitoring
Section intitulée « Les limites du monitoring »Le problème arrive quand vos systèmes deviennent distribués, dynamiques et interconnectés. Dans une architecture microservices, une requête utilisateur peut traverser 5, 10, voire 20 services avant d’aboutir. Chaque service tourne dans un conteneur éphémère qui peut être recréé à tout moment.
Dans ce contexte, le monitoring atteint ses limites :
- Vous ne pouvez pas anticiper tous les modes de défaillance. Un service peut fonctionner individuellement mais causer des problèmes en interaction avec d’autres.
- Les seuils statiques deviennent inadaptés. Un CPU à 80% peut être normal le lundi matin et anormal le dimanche soir.
- Le monitoring vous dit quoi mais pas pourquoi. “La latence est élevée” ne vous dit pas si c’est la base de données, le réseau, un appel API tiers ou un bug dans votre code.
L’observabilité : diagnostiquer ce qu’on ne connaît pas
Section intitulée « L’observabilité : diagnostiquer ce qu’on ne connaît pas »L’observabilité part d’un postulat différent : dans un système complexe, vous ne pouvez pas anticiper tous les problèmes possibles. Au lieu de définir à l’avance toutes les questions à poser, vous instrumentez votre système pour pouvoir poser n’importe quelle question après coup.
La distinction fondamentale tient en une phrase :
Le monitoring vous dit qu’il y a un problème. L’observabilité vous permet de comprendre pourquoi il y a un problème — même si vous ne l’aviez pas prévu.
Charity Majors, co-fondatrice de Honeycomb et figure de proue du mouvement observabilité, résume cette distinction par deux concepts empruntés à la gestion des risques :
- Known unknowns (les inconnues connues) : vous savez que le CPU peut saturer, vous posez une alerte dessus. C’est le domaine du monitoring.
- Unknown unknowns (les inconnues inconnues) : un race condition entre deux services provoque une corruption de données silencieuse. Vous n’aviez pas prévu ce scénario. C’est le domaine de l’observabilité.
Ce que l’observabilité apporte en plus
Section intitulée « Ce que l’observabilité apporte en plus »L’observabilité ne remplace pas le monitoring — elle l’étend. Un système observable vous permet de :
- Explorer librement les données pour formuler des hypothèses
- Corréler différents signaux (un pic de latence + une erreur de requête SQL + un log d’exception = cause racine identifiée)
- Diagnostiquer des problèmes imprévus sans avoir besoin de redéployer de l’instrumentation
- Réduire le MTTR (Mean Time To Resolution — le temps moyen pour résoudre un incident) en passant directement du symptôme à la cause, au lieu de tâtonner
Pour y parvenir, l’observabilité s’appuie sur trois types de données complémentaires, qu’on appelle les trois piliers.
Les trois piliers de l’observabilité
Section intitulée « Les trois piliers de l’observabilité »Chaque pilier répond à un type de question différent. Ensemble, ils forment une vision complète du comportement de votre système.
Les logs : que s’est-il passé ?
Section intitulée « Les logs : que s’est-il passé ? »Un log (ou journal) est un enregistrement horodaté d’un événement discret. C’est la forme de données d’observabilité la plus ancienne et la plus intuitive — c’est essentiellement votre application qui écrit dans un journal de bord.
Les logs répondent à la question : “Que s’est-il passé à tel moment ?”.
Exemples concrets :
2026-02-08 10:15:32 ERROR [api-gateway] Timeout after 30s connecting to payment-service2026-02-08 10:15:33 WARN [payment-service] Connection pool exhausted (max: 20, active: 20)En corrélant ces deux logs, vous comprenez que le timeout de l’API gateway est causé par l’épuisement du pool de connexions du service de paiement. Sans ces logs, vous ne verriez qu’une hausse de latence inexpliquée.
Les métriques : quelle est la tendance ?
Section intitulée « Les métriques : quelle est la tendance ? »Une métrique est une valeur numérique mesurée à intervalles réguliers. Là où un log décrit un événement ponctuel, une métrique décrit une tendance dans le temps.
Les métriques répondent à la question : “Comment évolue tel indicateur dans le temps ?”.
Les métriques sont le signal le plus compact et le plus économique à stocker. Un compteur de requêtes HTTP occupe quelques octets par point de mesure, là où les logs de ces mêmes requêtes occuperaient des mégaoctets.
Il existe quatre types principaux de métriques :
| Type | Description | Exemple |
|---|---|---|
| Counter | Valeur qui ne fait que monter | Nombre total de requêtes HTTP |
| Gauge | Valeur qui monte et descend | Utilisation mémoire en pourcentage |
| Histogram | Distribution de valeurs, agrégeable côté serveur | Latence des requêtes (p50, p90, p99) |
| Summary | Percentiles pré-calculés côté client, non agrégeable | Latence au 95e percentile |
La différence entre Histogram et Summary est subtile mais importante : l’histogram envoie les buckets bruts au serveur, ce qui permet d’agréger les données de plusieurs instances ; le summary pré-calcule les percentiles sur le client, ce qui est plus précis pour une seule instance mais impossible à fusionner.
Les métriques sont idéales pour déclencher des alertes (“le taux d’erreur dépasse 1%”) et alimenter des dashboards de supervision. Mais elles ne vous disent pas la cause d’une dégradation — pour cela, il faut corréler avec les logs ou les traces.
Les traces : quel chemin a pris la requête ?
Section intitulée « Les traces : quel chemin a pris la requête ? »Une trace suit le parcours complet d’une requête à travers un système distribué. Elle se compose de spans (segments), chaque span représentant une étape du traitement : l’API gateway, le service d’authentification, la base de données, le cache, le service de paiement, etc.
Les traces répondent à la question : “Où la requête a-t-elle passé du temps, et où a-t-elle échoué ?”.
Imaginez une requête de paiement qui met 8 secondes au lieu de 500ms. Sans trace, vous devriez fouiller les logs de chaque service un par un. Avec une trace, vous voyez immédiatement que 7,5 secondes ont été passées dans un appel à un service tiers de vérification de fraude. Le diagnostic passe de 30 minutes à 30 secondes.
Le tracing distribué est le pilier le plus récent et le plus complexe à mettre en place, mais c’est aussi celui qui apporte le plus de valeur dans les architectures microservices.
La force de la corrélation
Section intitulée « La force de la corrélation »Chaque pilier pris isolément a de la valeur, mais la vraie puissance de l’observabilité apparaît quand vous les corrèlez. Voici un scénario typique de diagnostic en 5 étapes :
-
Alerte métrique : le taux d’erreur HTTP 500 dépasse 2% depuis 3 minutes.
-
Dashboard : le graphique de latence montre un pic sur le service
checkout-apià 10h15. -
Logs filtrés : les logs du service
checkout-apimontrent des erreursconnection refusedversinventory-service. -
Trace : une trace prise à 10h15 montre que l’appel à
inventory-servicetimeout après 30 secondes, bloquant toute la chaîne. -
Cause racine : le
inventory-servicea épuisé ses connexions à la base de données après un déploiement qui a doublé le nombre de requêtes SQL par appel.
Sans la corrélation des trois piliers, ce diagnostic aurait pris des heures de fouille manuelle dans différents outils.
L’analogie du médecin
Section intitulée « L’analogie du médecin »Pour résumer la différence entre monitoring et observabilité, prenons l’analogie médicale :
| Médecine | Informatique |
|---|---|
| Thermomètre : mesure la température, alerte si fièvre | Monitoring : mesure le CPU, alerte si seuil franchi |
| Scanner / IRM : image complète, explore les organes | Observabilité : corrèle logs, métriques, traces, explore librement |
| Symptôme : “le patient a de la fièvre” | Alerte monitoring : “la latence est élevée” |
| Diagnostic : “infection bactérienne localisée au poumon droit” | Diagnostic observabilité : “le pool de connexions du service de paiement est saturé” |
Le thermomètre est indispensable — vous en avez besoin pour détecter qu’il y a un problème. Mais personne ne soignerait un patient avec seulement un thermomètre. Le scanner permet de comprendre le problème pour le traiter efficacement.
De la même façon, le monitoring est indispensable — il reste votre première ligne de détection. Mais l’observabilité est ce qui vous permet de résoudre le problème rapidement, surtout quand il est complexe et imprévu.
Monitoring et observabilité ne s’opposent pas
Section intitulée « Monitoring et observabilité ne s’opposent pas »Une erreur fréquente est de penser que l’observabilité remplace le monitoring. Ce n’est pas le cas. Les deux approches sont complémentaires et se renforcent mutuellement.
| Aspect | Monitoring | Observabilité |
|---|---|---|
| Question | ”Est-ce que ça marche ?" | "Pourquoi ça ne marche pas ?” |
| Approche | Réactive — vérifie des conditions prédéfinies | Exploratoire — permet de poser des questions ad hoc |
| Données | Métriques principalement | Logs + métriques + traces corrélés |
| Mode de défaillance | Known unknowns — scénarios anticipés | Unknown unknowns — scénarios imprévus |
| Force | Détection rapide, dashboards, alertes | Diagnostic, corrélation, réduction du MTTR |
| Exemple | ”Le serveur web ne répond plus" | "Le serveur web ne répond plus parce que le DNS interne a un TTL expiré qui cause des lookups en boucle” |
Un système bien instrumenté utilise les deux :
- Le monitoring détecte le symptôme et déclenche l’alerte
- L’observabilité permet au développeur ou à l’ops de diagnostiquer la cause racine et de résoudre rapidement
Quand passer du monitoring à l’observabilité ?
Section intitulée « Quand passer du monitoring à l’observabilité ? »Le monitoring classique reste parfaitement adapté dans de nombreuses situations. Voici un guide de décision pragmatique pour savoir quand investir dans l’observabilité.
Le monitoring suffit quand…
Section intitulée « Le monitoring suffit quand… »- Votre infrastructure est simple : quelques serveurs, quelques services bien connus
- Vos modes de défaillance sont prévisibles : disque plein, service arrêté, certificat expiré
- Votre équipe est petite et connaît l’architecture par cœur
- Vos déploiements sont peu fréquents (quelques fois par mois)
- Vous n’avez pas de microservices ni de systèmes distribués complexes
L’observabilité devient nécessaire quand…
Section intitulée « L’observabilité devient nécessaire quand… »- Vous avez des architectures distribuées (microservices, fonctions serverless, event-driven)
- Les incidents prennent trop longtemps à diagnostiquer (MTTR élevé)
- Vous rencontrez des problèmes intermittents que personne ne peut reproduire
- Vos équipes grandissent et personne ne maîtrise tout le système seul
- Vos déploiements sont fréquents (plusieurs fois par jour, CI/CD continu)
- Vos utilisateurs signalent des problèmes que votre monitoring ne détecte pas
Un scénario concret : l’enquête du vendredi soir
Section intitulée « Un scénario concret : l’enquête du vendredi soir »Pour illustrer la différence en situation réelle, suivons une équipe qui reçoit une alerte le vendredi à 18h.
Avec le monitoring seul
Section intitulée « Avec le monitoring seul »L’alerte indique : “Latence p99 > 2s sur le service checkout”. L’équipe
regarde les dashboards : CPU normal, mémoire normale, disque OK, réseau OK. Le
service checkout a bien une latence élevée, mais aucune de ses métriques de
santé n’est en alerte.
L’équipe commence à fouiller les logs du service checkout à la main. Après 45
minutes, un développeur remarque des messages slow query dans les logs de la
base de données. Mais est-ce la cause ou un symptôme ? Après encore 30 minutes,
l’équipe découvre qu’un déploiement du service recommendation à 17h45 a
introduit une requête N+1 qui sature la base de données partagée. Temps de
résolution : 1h15.
Avec l’observabilité
Section intitulée « Avec l’observabilité »La même alerte arrive. L’ingénieur d’astreinte ouvre la trace d’une requête
lente. Il voit que 1,8s sur les 2,1s sont passées dans un appel au service
recommendation. Il clique sur ce span et voit l’appel SQL sous-jacent : une
boucle de 200 requêtes SELECT identiques. Il corrèle avec les métriques et
confirme que la charge SQL a explosé à 17h45. Il corrèle avec les logs de
déploiement et identifie le commit responsable. Il revient à la version
précédente. Temps de résolution : 12 minutes.
La différence est claire : la détection a fonctionné dans les deux cas. Mais l’observabilité a transformé 1h15 de tâtonnement en 12 minutes de diagnostic ciblé.
Pièges courants
Section intitulée « Pièges courants »Voici les erreurs les plus fréquentes observées dans les équipes qui abordent l’observabilité pour la première fois :
- Confondre quantité de données et observabilité. Collecter des téraoctets de logs sans structure ni corrélation ne rend pas votre système observable. C’est juste du stockage coûteux.
- Ajouter des outils sans changer les pratiques. Installer Prometheus + Grafana + Loki ne crée pas de l’observabilité si personne ne sait poser les bonnes questions aux données.
- Surveiller les mauvais indicateurs. L’utilisation CPU d’un serveur est rarement ce qui intéresse vos utilisateurs. Mesurez ce qu’ils vivent : temps de réponse, taux d’erreur, disponibilité du service.
- Alerter sur tout. Plus vous avez d’alertes, moins chacune a de valeur. Les équipes finissent par ignorer les alertes (alert fatigue), y compris les vraies.
- Croire que l’observabilité est réservée aux “gros”. Même un side-project avec 3 conteneurs Docker bénéficie de logs structurés et de métriques basiques.
À retenir
Section intitulée « À retenir »- Le monitoring surveille des conditions connues (“est-ce que ça marche ?”). L’observabilité permet de diagnostiquer des problèmes imprévus (“pourquoi ça ne marche pas ?”).
- L’observabilité repose sur trois piliers complémentaires : les logs (événements), les métriques (tendances) et les traces (parcours des requêtes).
- Le monitoring et l’observabilité ne s’opposent pas — le monitoring détecte, l’observabilité diagnostique. Les deux sont nécessaires.
- L’observabilité est une propriété de votre système, pas un produit que vous achetez. C’est votre code et votre instrumentation qui rendent un système observable.
- La transition est progressive : commencez par des logs structurés, puis ajoutez les métriques applicatives, et enfin le tracing distribué quand vos architectures le justifient.