L'observabilité est devenue indispensable pour comprendre le fonctionnement des systèmes d'information. Une application ralentit. Les serveurs sont pourtant peu sollicités. Les métriques sont au vert, mais certains utilisateurs rencontrent des erreurs intermittentes. L'équipe infrastructure ne constate rien d'anormal. Les développeurs soupçonnent la base de données. Les administrateurs réseau pointent un service tiers. Pendant ce temps, l'incident perdure et les équipes multiplient les investigations sans parvenir à identifier la cause profonde.
Cette situation devient de plus en plus fréquente à mesure que les systèmes d'information se complexifient. Cloud, architectures microservices, applications distribuées et multiplication des services rendent les flux plus difficiles à suivre. Une anomalie peut apparaître à un endroit et trouver son origine dans un composant situé ailleurs.
C'est précisément là que l'observabilité prend tout son sens. Loin d'être un simple synonyme du monitoring, elle désigne la capacité à comprendre l'état et le comportement d'un système à partir de l'analyse de ses données télémétriques.
Dans cet article, nous vous expliquons :
- pourquoi le monitoring traditionnel seul ne suffit pas,
- comment les trois piliers de l’observabilité permettent d’analyser vos systèmes,
- et comment la corrélation des données, l’instrumentation, OpenTelemetry et le RUM contribuent à construire une observabilité réellement exploitable.
Observabilité vs Monitoring : pourquoi le monitoring seul ne suffit plus
Les systèmes d'information ont profondément évolué. Les architectures cloud-native, les microservices et le serverless ont apporté davantage de flexibilité et accéléré les déploiements. En contrepartie, ils ont aussi multiplié les composants, les échanges réseau et les dépendances entre applications.
Dans ce contexte, localiser l'origine d'un incident est devenu bien plus complexe. Une simple requête utilisateur peut désormais traverser plusieurs API, bases de données, services tiers ou files de messages avant d'aboutir. Lorsqu'un dysfonctionnement survient, identifier le composant responsable n'est plus immédiat.
Le monitoring traditionnel reste indispensable, mais il répond principalement à une question :
Le système fonctionne-t-il normalement ?
Il surveille des indicateurs tels que :
- l'utilisation CPU ou mémoire ;
- la disponibilité des serveurs ;
- le temps de réponse d'une application ;
- le taux d'erreurs HTTP ;
- l'état des services critiques…
Savoir qu’un serveur est saturé ou qu’une API renvoie une erreur 500 ne suffit plus ; encore faut-il comprendre pourquoi et où le flux s’est rompu dans un labyrinthe de dépendances asynchrones.
Le monitoring détecte des états ou comportements connus. L'observabilité explore des comportements inconnus ou inattendus à partir des signaux disponibles.
Elle permet d'analyser le comportement réel d'une application et de suivre une transaction à travers l'ensemble des composants qui la traitent. Les équipes disposent ainsi des éléments nécessaires pour comprendre l'origine d'une anomalie, même lorsqu'elle résulte d'interactions complexes entre plusieurs services.
Pour les équipes IT, adopter l'observabilité représente un changement de posture critique : on ne cherche plus seulement à être alerté en cas de panne, mais à acquérir la capacité d'interroger le système sur des comportements imprévisibles et inédits.
Les 3 piliers de l’observabilité
Pour rendre un SI pleinement observable, il est indispensable de collecter et de structurer ses données de fonctionnement. La conception de l'observabilité repose sur trois piliers de données télémétriques : les métriques, journaux et traces. Chacun de ces types de données remplit une fonction de diagnostic bien précise et leur complémentarité est la clé de voûte de toute analyse de cause racine (Root Cause Analysis).
Les métriques
Les métriques sont souvent le premier indicateur qu'un problème est en train de se produire. Collectées à intervalles réguliers, elles offrent une vision globale de l'état de santé d'une infrastructure, d'une application ou d'un service. Qu'il s'agisse de compteurs (ex: nombre de requêtes HTTP), de jauges (ex: taux d'occupation de la mémoire vive) ou d'histogrammes (ex: centiles de latence), la métrique est le signal d'alarme du système
Grâce à leur faible volume de stockage et à leur capacité d'agrégation, les métriques sont idéales pour alimenter des tableaux de bord, suivre des tendances et déclencher des alertes.
En revanche, elles présentent une limite importante : elles indiquent qu'une anomalie existe, sans expliquer pourquoi elle s'est produite. Une hausse de la latence ou du taux d'erreurs permet de détecter rapidement un incident, mais ne suffit pas à identifier le composant responsable ni la cause du dysfonctionnement.
Les journaux ou logs
Lorsqu'une alerte est déclenchée, les logs sont souvent la première source consultée pour comprendre ce qui s'est réellement passé. Ils enregistrent, de manière horodatée, les événements produits par une application, un service ou un composant d'infrastructure.
Selon le niveau de détail souhaité, un log peut contenir :
- un message d'erreur explicite ;
- une exception ou une stack trace ;
- une requête vers une ressource ;
- des informations de contexte (identifiant utilisateur, environnement, paramètres d'exécution, etc.).
Aujourd'hui, les applications produisent majoritairement des logs structurés, généralement au format JSON. Cette approche facilite leur indexation, leur recherche et leur corrélation au sein d'une plateforme d'observabilité.
Les logs répondent à une question essentielle : Que s'est-il passé précisément à cet endroit ?
Mais, ils restent limités à la vision d'un composant. Sans mécanisme de corrélation, il est difficile de relier automatiquement les événements produits par plusieurs applications. Lors d'un incident impliquant de nombreux services, analyser uniquement les logs peut rapidement devenir chronophage.
Les traces
Imaginez qu'un utilisateur valide une commande sur votre site web. En quelques millisecondes, sa requête traverse une API Gateway, plusieurs microservices, une base de données et parfois même des services tiers. Si un ralentissement apparaît, comment savoir précisément où le temps a été consommé ? C'est le rôle des traces.
Une trace reconstitue le parcours complet d'une requête à travers l'ensemble des couches logicielles et réseaux du système d'information. Elle montre chaque étape franchie, la durée de chaque traitement et les dépendances entre les différents composants. Vous visualisez ainsi l'enchaînement exact des opérations, du point d'entrée jusqu'à la réponse envoyée à l'utilisateur. Concrètement, une trace est composée de plusieurs spans.
Chaque span représente une unité de travail, comme :
- un appel à une API ;
- une requête vers une base de données ;
- l'envoi d'un message sur un bus d'événements ;
- l'exécution d'une fonction métier.
Chaque span est horodaté et enrichi d'informations telles que sa durée d'exécution ou ses attributs techniques. Ensemble, ils permettent de reconstruire le chemin emprunté par une transaction de bout en bout. En cartographiant le cheminement exact du flux, la trace brise le fonctionnement en silo des composants et pose les bases de la corrélation.
Corréler les données pour comprendre un incident
Posséder des métriques, des logs et des traces est une condition nécessaire, mais grandement insuffisante pour observer un système distribué. Sans un mécanisme de liaison, ces données ne forment qu'un amas de signaux déconnectés. Ils ne suffisent pas à expliquer le parcours complet d'une transaction dans une architecture distribuée.
Toute la valeur de l'observabilité réside dans sa capacité à corréler ces données afin de reconstituer le chemin emprunté par une requête, du point d'entrée jusqu'au composant responsable d'un ralentissement ou d'une erreur.
Comment les données se relient entre elles ?
Lorsqu'une requête utilisateur franchit le premier point d'entrée du SI (par ex. une API Gateway ou un reverse proxy), un contexte d'observabilité est initialisé. Pour assurer ce suivi, plusieurs informations accompagnent chaque requête :
- Le TraceID : Un identifiant unique global qui caractérise la transaction de bout en bout.
- Le SpanID : Un identifiant propre à l'opération locale en cours d'exécution.
- Le Baggage : Un ensemble de paires clé-valeur transportant du contexte métier ou technique (ex: tenant_id, region, user_tier) qui doit être partagé tout au long de la chaîne.
Ces informations sont automatiquement transmises d'un service à l'autre grâce à la propagation de contexte. Ce mécanisme technique permet de tisser un fil d'Ariane à travers l'ensemble des composants du système d'information.
La "propagation" consiste à injecter ces métadonnées dans les couches de transport réseau lors de chaque appel sortant. Des standards comme W3C Trace Context définissent la manière dont ces métadonnées circulent entre les applications, quels que soient les protocoles ou les technologies le supportant. La continuité des traces est ainsi conservée tout au long du traitement d'une requête.
De l'alerte à la cause racine : la corrélation en action
La véritable valeur de l'observabilité apparaît lorsque les métriques, les traces et les logs ne sont plus analysés séparément, mais reliés autour d'une même transaction. C'est cette propagation ininterrompue qui rend la corrélation possible. Sur une plateforme d'observabilité moderne, les trois piliers de la télémétrie fusionnent :
- Métrique : Une métrique indique une hausse anormale de la latence ($p99$) sur le service de paiement.
- Trace : L'ingénieur clique sur la métrique et accède instantanément aux traces correspondantes à cette période. La visualisation de la trace montre que sur 2 secondes de latence totale, 1,8 seconde est consommée par un appel de base de données spécifique.
- Log : En un clic sur ce span de base de données, la plateforme affiche uniquement les logs émis par le thread précis qui a exécuté la requête, révélant un verrou de table (table lock) ou une syntaxe SQL inefficace.
Le bénéfice pour le diagnostic : briser les silos organisationnels
Sans propagation de contexte, la résolution d'un incident dans un SI complexe se résume souvent à une confrontation entre équipes : les développeurs incriminent le réseau, les administrateurs réseau pointent la base de données, et les DBA renvoient la responsabilité au code. Chaque équipe IT dispose souvent d'une vision partielle de l'incident.
En apportant une preuve factuelle et indiscutable du cheminement d'un flux et des points de friction, la corrélation par propagation élimine les conjectures. Elle réduit drastiquement le MTTR (Mean Time To Resolution) en transformant la cellule de crise : on ne cherche plus qui est responsable, mais on visualise immédiatement où se situe le goulet d'étranglement.
Open source vs Progiciels fermés : le défi de l'instrumentation
Un système d'information moderne n'est jamais homogène. Il rassemble des applications développées en interne (souvent open source ou basées sur des frameworks ouverts), des services cloud, et des progiciels du marché (COTS - Commercial Off-The-Shelf) en sources fermées. La qualité de l'observabilité et la capacité à obtenir une visibilité de bout en bout dépendent donc directement de la possibilité d'instrumenter chacun de ces composants.
Applications Sources Ouvertes et développements internes
Pour les projets dont les équipes maîtrisent le code source, l’observabilité peut être pensée dès la phase de conception (Observability by Design) ou intégrée par la suite.
Plusieurs avantages se présentent :
- Une instrumentation plus fine : L'accès au code permet une instrumentation de précision via des SDKs ouverts. Les développeurs peuvent enrichir les spans de trace avec des attributs métiers stratégiques (ex : order_value, customer_segment). Ce niveau de granularité est indispensable pour corréler une défaillance technique à un impact financier ou utilisateur précis.
- Une intégration adaptée à l'application : L'intégration se fait naturellement au niveau du langage ou du framework (comme Spring Boot, NestJS ou .NET ...), permettant de capturer automatiquement les requêtes entrantes ou sortantes, comme les requêtes vers les bases de données, sans altérer la logique métier.
- Une responsabilité à partager entre les équipes : Cette approche exige une forte culture de développement et un investissement en temps pour maintenir la cohérence des pratiques d'instrumentation au sein des différentes équipes de développement.
Progiciels en sources fermées
La situation est différente avec un progiciel propriétaire, comme un ERP ou une solution CRM du marché. Lorsque le code source n'est pas accessible, l'instrumentation doit s'appuyer sur des mécanismes externes. Le système se comporte comme une boîte noire, menaçant de rompre la chaîne de propagation du contexte.
Plusieurs approches peuvent être alors déployées en stratégies de contournement :
- L'instrumentation automatique par agents (Bytecode Manipulation) : Pour les progiciels s'exécutant sur des runtimes virtuels (comme la JVM Java ou le CLR .NET), il est possible d'attacher un agent au démarrage du processus. Cet agent modifie dynamiquement le bytecode en mémoire pour y injecter des points de mesure d'observabilité. Cela permet d'obtenir des métriques de performance et des traces sans toucher au fichier source originel.
- L'approche eBPF (Extended Berkeley Packet Filter) : Révolutionnaire pour le monitoring des boîtes noires sous Linux, la technologie eBPF permet d'injecter des sondes directement au niveau du noyau (kernel) du système d'exploitation. eBPF permet d'observer certains comportements au niveau du système d'exploitation, sans modifier le code source du progiciel et avec une instrumentation généralement peu intrusive.
- L'observabilité périphérique (Service Mesh / Proxies) : Si le progiciel est déployé dans un environnement conteneurisé (Kubernetes), l'utilisation d'un service mesh (comme Istio, Linkerd ou Cilium) permet d'adjoindre un conteneur proxy (sidecar) à côté du progiciel. Ce proxy intercepte tout le trafic réseau entrant et sortant, fournissant ainsi des métriques et des traces réseau pour le compte de la boîte noire.
Les limites structurelles de la boîte noire
Bien que ces techniques de contournement soient puissantes, elles présentent une limite majeure : la perte de granularité. Un agent eBPF ou un proxy réseau saura documenter le temps qu'un progiciel a mis à répondre à une requête HTTP, mais il sera incapable de comprendre ce qui s'est passé à l'intérieur du moteur d'exécution propriétaire si celui-ci rencontre une anomalie.
De plus, si le progiciel reçoit une requête contenant un TraceID mais qu'il ne transmet pas activement cet en-tête lors de ses propres appels sortants vers d'autres API, la propagation du contexte est brisée, créant une zone d'ombre dans la topologie globale du SI.
OpenTelemetry : standardiser la collecte des données d'observabilité
La multiplication des technologies, des langages et des plateformes a longtemps rendu l'instrumentation des applications complexe. Chaque solution d'observabilité pouvait imposer ses propres agents, bibliothèques et formats de données, créant une dépendance forte à l'égard d'un éditeur.
OpenTelemetry répond à cette problématique en proposant un cadre ouvert et standardisé pour instrumenter les applications et collecter leurs données de télémétrie. Il prend en charge les principaux signaux d'observabilité, notamment les métriques, les logs et les traces, tout en facilitant leur transmission vers différentes plateformes d'analyse.
Cette approche permet de dissocier l'instrumentation des applications de la solution utilisée pour exploiter les données. Vous pouvez ainsi standardiser la manière dont vos applications produisent leur télémétrie, tout en conservant davantage de liberté dans le choix de votre plateforme d'observabilité.
OpenTelemetry joue également un rôle important dans la propagation de contexte. En s'appuyant sur des standards ouverts, il facilite la corrélation des données produites par les différents composants d'un système distribué et contribue à reconstituer le parcours d'une transaction de bout en bout.
Pour une DSI confrontée à un environnement hétérogène, OpenTelemetry constitue ainsi une brique structurante pour industrialiser l'instrumentation et construire une stratégie d'observabilité plus cohérente.
Les limites de l'observabilité et les angles morts
L'observabilité permet d'améliorer considérablement la compréhension d'un système d'information, mais elle ne garantit pas une visibilité parfaite. La qualité des diagnostics dépend directement des composants que vous pouvez instrumenter, des données réellement collectées et de la continuité de leur propagation.
Des composants difficiles à instrumenter
Le premier obstacle à une observabilité complète réside dans l'hétérogénéité des systèmes d'information. Bien que l’instrumentation automatique ou eBPF progresse, certains langages propriétaires, environnements legacy ou frameworks applicatifs spécifiques ne supportent pas nativement la propagation de contexte.
- Exemple applicatif : Dans le cas d'une application monolithique développée en C++ legacy ou utilisant de vieux scripts Perl/PHP non mis à jour, aucun agent standardisé ne sait injecter de contexte à la volée.
- Exemple de protocole : De même, si vos microservices communiquent via des protocoles de sérialisation propriétaires ou des flux binaires bruts sur sockets TCP custom (sans utiliser HTTP, gRPC ou des Message Broker comme Kafka ou RabbitMQ), il n'existe aucun emplacement standardisé (comme un en-tête) pour stocker les métadonnées de liaison.
Dans ces environnements, l'impossibilité d'injecter ou de lire les en-têtes de traçage (TraceID) brise net le fil d'Ariane. Le système redevient instantanément une boîte noire, générant des segments de traces orphelins et des zones d’ombre majeures dans l’infrastructure de surveillance du SI.
Les infrastructures réseau peuvent aussi rompre la chaîne de contexte
Au-delà du code, la continuité de la propagation se heurte fréquemment à la réalité des couches basses du réseau. Certains équipements intermédiaires agressifs purgent systématiquement les en-têtes HTTP ou les métadonnées de transport personnalisées (comme le standard W3C traceparent).
- Exemple de proxy et reverse-proxy : Des configurations de sécurité strictes sur des outils comme HAProxy, Nginx ou des API Gateways peuvent être programmées pour appliquer du "Header Stripping" (nettoyage des en-têtes), éliminant tout en-tête inconnu ou non explicitement autorisé dans la Whitelist par mesure de sécurité.
- Exemple d'équipements de sécurité (WAF / Firewalls) : Un Web Application Firewall (WAF) ou un boîtier de déchargement SSL (SSL Offloading) qui inspecte le trafic en profondeur (Deep Packet Inspection) peut interpréter l'en-tête traceparent ou les champs Baggage comme une tentative d'exfiltration de données ou une anomalie de protocole, choisissant de bloquer la requête ou de réinitialiser brutalement la session TCP.
- Exemple d'architectures d'entreprise (EAI / ESB) : Les anciens Enterprise Service Buses (ESB) ou les passerelles de transformation de flux (comme IBM MQ ou Tibco dans certaines configurations anciennes) ont tendance à reconstruire intégralement le message de transport de bout en bout, omettant de recopier les métadonnées d'observabilité d'origine lors de la réémission du message vers le service suivant.
Ce nettoyage de sécurité ou ces contraintes d'optimisation réseau rompent la chaîne de causalité entre les composants, annihilant les efforts de corrélation automatique.
L'observabilité ne remplace pas l'expertise
Un agent d'observabilité pourra documenter un retard ou une perte de connexion, mais il sera incapable d'en identifier la cause physique profonde.
Dans ces scénarios critiques, l'observabilité moderne ne remplace en aucun cas l'analyse fine des flux réseau (packet capture / deep packet inspection) réalisée par des ingénieurs et spécialistes expérimentés. L'œil humain expert, armé d'analyseurs de protocoles, reste l'ultime recours pour corréler les anomalies de bas niveau et découvrir la véritable cause racine (Root Cause Analysis) de l'incident.
Le RUM : observer l'expérience réellement vécue par vos utilisateurs
Une infrastructure au vert, des bases de données aux requêtes optimisées et des microservices affichant un taux de disponibilité de 99,9 % ne garantissent pas à eux seuls le succès d'une application. L'observabilité du socle technique, bien que fondamentale, souffre d'un angle mort : elle s'arrête aux frontières du centre de données ou du cloud.
Le RUM (Real User Monitoring) mesure les performances directement depuis les terminaux des utilisateurs, dans leurs conditions réelles d'utilisation. Il permet notamment de suivre les temps de chargement, les erreurs côté navigateur et les performances d'une application web ou mobile.
Cette visibilité apporte une nouvelle dimension à l'observabilité : elle ne permet plus seulement de comprendre ce qui se passe dans votre infrastructure, mais aussi ce que vivent réellement vos utilisateurs.
En corrélant ces données avec les signaux techniques du backend, vous pouvez alors remonter d'une dégradation constatée côté utilisateur jusqu'à son origine dans le système d'information. Une lenteur observée sur une page peut ainsi être rapprochée d'un appel API dégradé, d'une requête de base de données ou d'un service tiers défaillant.
Le RUM permet ainsi de rapprocher performance technique et expérience utilisateur. Il constitue une brique complémentaire de l'observabilité, particulièrement utile lorsque la qualité de service doit être mesurée du point de vue de l'utilisateur final.
L’observabilité, une nouvelle façon de comprendre votre système d’information
L'observabilité ne remplace pas le monitoring. Elle le complète. Dans un système distribué, savoir qu'un incident existe n'est plus suffisant : il faut comprendre rapidement où il se produit et pourquoi. C'est cette capacité d'analyse qui permet aux équipes IT de réduire les temps de résolution, d'améliorer la disponibilité des services et de gagner en efficacité opérationnelle.
Ce qu’il faut retenir :
- le monitoring permet de détecter une anomalie, tandis que l'observabilité va plus loin en permettant d'en comprendre le contexte et les causes ;
- les métriques, les journaux et les traces constituent les trois piliers complémentaires de la télémétrie ;
- la corrélation des données permet de reconstituer le parcours d'une requête et de remonter plus rapidement vers la cause racine d'un incident ;
- la propagation de contexte facilite le suivi des transactions à travers les différents composants d'un système distribué ;
- l'instrumentation reste un enjeu majeur dans les environnements hétérogènes, notamment lorsqu'ils intègrent des progiciels fermés ou des applications difficiles à instrumenter ;
- OpenTelemetry contribue à standardiser la collecte et la transmission des données d'observabilité ;
- le RUM complète la vision technique en permettant de comprendre l'expérience réellement vécue par vos utilisateurs.
La mise en œuvre d'une démarche d'observabilité ne consiste toutefois pas à multiplier les outils ou à collecter toujours plus de données. Elle nécessite de définir une stratégie cohérente, de sélectionner les bons indicateurs et d'exploiter efficacement les données disponibles.
Nous accompagnons les entreprises dans la mise en place de leur démarche d'observabilité et dans l'optimisation de leurs outils. Notre objectif : vous aider à disposer d'une visibilité exploitable sur votre système d'information et à tirer pleinement parti de vos solutions d'observabilité, pour une supervision plus efficace et une observabilité opérationnelle en continu.
Parce qu'une bonne visibilité ne se limite pas à détecter un problème : elle doit vous permettre de le comprendre, d'en mesurer l'impact et d'agir rapidement. C'est cette capacité à transformer les données en informations utiles qui donne toute sa valeur à l'observabilité.
FAQ Observabilité
Il n'est pas nécessaire d'attendre un incident majeur pour mettre en place une démarche d'observabilité. Elle peut être mise en œuvre progressivement, même si son intégration au plus tôt dans le cycle de vie du système d'information sera le mieux. L’importance est d’évaluer que les principes technologique d’observabilité soient en adéquations avec les technologie employées dans votre SI.
L'observabilité permet notamment de réduire le temps consacré au diagnostic, d'améliorer la fiabilité des services et de faciliter la collaboration entre les équipes. Elle offre également une meilleure visibilité sur les performances du SI et permet de mieux évaluer l'impact réel des incidents ou des évolutions du SI sur les applications et les utilisateurs.
Pas nécessairement. L'observabilité peut compléter les outils déjà présents dans votre environnement. L'enjeu consiste d'abord à identifier les données disponibles, les besoins des équipes et les éventuelles lacunes de visibilité. Selon votre contexte, certaines solutions pourront être conservées, intégrées ou progressivement remplacées.
