Vous avez Grafana. Vous voyez vos CPU, RAM, disk space. Vous croyez être observable. Vous ne l'êtes pas.

C'est une erreur que 80% des PME suisses font. Ils confondent monitoring et observabilité. Ces deux mots ressemblent, mais l'un est réactif et l'autre est prédictif. L'un vous dit "les choses vont mal". L'autre vous dit "pourquoi elles vont mal et comment les réparer".

Comprendre cette distinction peut transformer la manière dont vous maintenez votre infrastructure. Selon Gartner, le marché de l'observabilité atteindra 62 milliards de dollars en 2026, signe que les entreprises investissent massivement pour dépasser le simple monitoring.

Monitoring vs Observabilité : la vraie différence

Monitoring : vous posez les questions que vous savez poser

Le monitoring, c'est de la surveillance passive. Vous décidez à l'avance : "Je veux savoir si le CPU > 80%". Vous mettez une alerte. Grafana vous prévient. Vous réagissez.

C'est utile. Mais c'est limité.

Parce que vous ne savez pas toutes les questions que vous devriez poser. Si le CPU est à 45% mais votre application est lente, pourquoi ? Vos dashboards Prometheus ne vous le disent pas.

Observabilité : vous posez les questions que vous ne saviez pas que vous vouliez poser

L'observabilité, c'est avoir assez d'informations pour debugger n'importe quel problème sans redéployer du code.

Une requête utilisateur est lente. Vous pouvez tracer cette requête à travers :

Le frontend (combien de temps avant la requête ?)
Le load balancer (y a-t-il du queuing ?)
Le service API principal (où le temps s'écoule-t-il ?)
Les appels à la base de données (la DB est-elle en faute ?)
Le service de cache (le cache aide-t-il ?)
Tout cela en une vue cohérente.

Ça, c'est l'observabilité. Et c'est ce que la plupart des PME n'ont pas. Une étude de Datadog révèle que les entreprises disposant d'une stack d'observabilité complète (métriques, logs et traces corrélés) détectent et résolvent les incidents 10 fois plus vite que celles qui se limitent au monitoring classique.

Les 3 piliers de l'observabilité

Pour être observable, vous avez besoin de trois types de données.

1. Les métriques

Les métriques sont des nombres qui changent dans le temps.

Exemples : CPU %, latence en ms, nombre de requêtes par seconde, size des connexions DB, messages en queue, erreurs par minute.

Outils classiques : Prometheus, Grafana, InfluxDB, Datadog

Quand les utiliser : pour voir des tendances. "Depuis 3 jours, le CPU monte graduellement". Vous savez qu'un problème se prépare.

Limite : les métriques ne vous disent pas pourquoi. "CPU élevé" pourrait être 100 choses différentes.

2. Les logs

Les logs sont des événements textuels.

Exemples : "Utilisateur alice@example.com connecté", "Erreur: Connexion DB timeout", "Paiement de CHF 129 traité".

Outils classiques : Elastic Stack, Loki, CloudWatch, Sentry

Quand les utiliser : pour debugger des incidents spécifiques. Vous avez une erreur utilisateur ? Vous trouvez le contexte exact en lisant les logs.

Limite : les logs à volume élevé sont impossibles à parser manuellement. Et trouver le problème dans 10GB de logs, c'est une aiguille dans une botte de foin.

3. Les traces distribuées (Distributed Tracing)

Les traces suivent une requête unique à travers tous vos services.

Exemples : une requête HTTP arrive, elle traverse API → Service 1 → Service 2 → DB → Cache → réponse. Une trace vous montre tout cet arborescence avec les timings.

Outils classiques : Jaeger, Zipkin, Datadog APM, Sentry

Quand les utiliser : pour comprendre les problèmes de performance complexes et les dépendances de services.

Limite : c'est coûteux de tracer chaque requête. Vous devez choisir un taux d'échantillonnage (ex: 1% des requêtes).

Comment ces 3 piliers travaillent ensemble

Incident typique : les utilisateurs se plaignent que l'appli est lente à 15h30 le jeudi.

Étape 1 : Les métriques vous alertent Vous voyez que la latence des API a grimpé de 100ms à 800ms entre 15h29 et 15h35.

Étape 2 : Les traces vous montrent où Vous regardez une trace d'une requête lente. Vous voyez que 700ms sont dépensés dans un appel à la base de données.

Étape 3 : Les logs vous montrent pourquoi Vous regardez les logs du service DB à 15h30. Vous voyez : "Erreur: Too many connections". Quelqu'un a lancé une migration de données à ce moment.

Conclusion : pas un bug. Un opérateur a mal timed une opération. Vous ajustez la procédure.

Sans les trois piliers, vous tournez en cercles. "La DB est lente, mais pourquoi ?" Sans traces, vous ne savez pas. Sans logs, vous ne comprenez pas le contexte. D'après le GitLab DevSecOps Survey 2024, 56% des équipes de développement considèrent que le manque de visibilité sur les systèmes en production est leur principal frein à la résolution rapide des incidents.

Les erreurs que les PME font

Erreur 1 : Seulement des métriques

Vous avez Prometheus + Grafana. Vous avez 50 dashboards. Mais quand un incident arrive, vous êtes bloqué. "CPU élevé, oui, mais pourquoi ?"

Solution : Ajoutez des logs structurés avec Elastic Stack. Le self-hosted peut être coûteux à maintenir, c'est pourquoi envisagez du Elastic managé hébergé en Suisse (c'est ce que propose Hidora). Les logs + les métriques = déjà 80% mieux.

Erreur 2 : Logs volumétriques sans structure

Vous loguez tout ("INFO: Dans la fonction foo", "DEBUG: Variable x = 42"). Vous avez 100GB de logs par jour. Votre système de logs plante. Vous n'avez rien.

Solution : Loguez les événements importants avec du contexte. "ERROR: DB_CONNECTION_FAILED user=alice operation=create_invoice timestamp=2026-02-24T15:30:45Z". Structure (JSON) > Volume.

Erreur 3 : Pas de traces

Vous avez des microservices. Une requête traverse 5 services. Quand quelque chose casse, vous ne savez pas quel service est en faute.

Solution : Implémentez du distributed tracing. Commencez avec Jaeger ou Sentry (facile à intégrer). Vous n'avez pas besoin de tracer 100% des requêtes, 5-10% suffisent.

Erreur 4 : Outils mal intégrés

Vous avez Prometheus, Elastic, et Sentry. Mais ils ne parlent pas les uns aux autres. Vous devez jongler entre 3 interfaces pour un incident.

Solution : Utilisez une plateforme unifiée. Hidora propose du Elastic managé hébergé en Suisse, qui intègre métriques, logs et traces dans une seule interface. C'est une alternative souveraine à Datadog ou New Relic. Au minimum, assurez-vous que vos outils partagent des identifiants communs (trace IDs, request IDs).

Erreur 5 : Pas de contexte métier

Vous savez que la latence est élevée. Mais vous ne savez pas : combien d'utilisateurs sont affectés ? Quelle est la perte financière ?

Solution : Loguez des événements métier. "PAYMENT_PROCESSED amount=129.00 currency=CHF user_id=12345 duration_ms=245". Ça vous aide à hiérarchiser.

Construire une stratégie d'observabilité

Commencez simple.

Phase 1 : Baseline (mois 1-2)

Exportez les métriques système (Prometheus) : CPU, RAM, disk, network
Mettez en place un agrégateur de logs (Elastic ou Loki). Loguez chaque erreur + quelques événements clés
Pas de traces encore.

Budget : CHF 200-500/mois de infrastructure + 40h d'implémentation. Selon le CNCF Annual Survey 2024, Prometheus est utilisé par 86% des organisations cloud-native pour la collecte de métriques, ce qui en fait un choix sûr et pérenne.

Phase 2 : Enrichissement (mois 3-4)

Ajoutez des métriques applicatives : requêtes par seconde, erreurs, latence
Structurez vos logs en JSON. Enlevez les logs "debug" inutiles
Commencez à corréler logs + métriques : quand la latence monte, quels logs apparaissent ?

Budget supplémentaire : CHF 100-300/mois.

Phase 3 : Maturité (mois 5+)

Ajoutez du distributed tracing pour les requêtes multi-services
Créez des dashboards métier : combien d'utilisateurs affectés, quel est l'impact ?
Automatisez l'escalade : incident grave → alerter le CTO automatiquement

Budget supplémentaire : CHF 300-600/mois.

Checklist : êtes-vous observable ?

Répondez sincèrement :

Vous avez une métrique pour chaque service critique
Vous pouvez tracer une requête utilisateur à travers vos services
Quand un incident arrive, vous trouvez la root cause en < 30 min
Vos logs ont du contexte (pas juste du texte brut)
Vous avez alertes configurées pour les incidents critiques
Vous pouvez quantifier l'impact d'une panne (utilisateurs affectés, revenue perdue)

Si vous cochez 4+, vous êtes sur la bonne voie. Moins de 4 ? Il y a du travail.

Outils recommandés par type de PME

PME sans infrastructure complexe (< 5 services)

Prometheus + Grafana (gratuitement self-hosted)
Elastic ou Loki pour les logs (coûteux self-hosted, envisager SaaS)
Pas de traces nécessaires au départ

PME avec microservices (5-15 services)

Même base + Jaeger (open-source) pour traces
Ou Sentry si vous pouvez vous offrir SaaS (CHF 300-600/mois)

PME en croissance rapide

Considérez une plateforme unifiée : Datadog, New Relic, ou Grafana Cloud
L'intégration vaut le surcoût

En résumé

Le monitoring vous dit ce qui est cassé. L'observabilité vous dit pourquoi et comment le réparer.

Les trois piliers (métriques, logs, traces) travaillent ensemble. Aucun seul n'est suffisant.

Commencez par les métriques + logs. C'est 80% du chemin. Les traces, vous les ajouterez quand votre infrastructure se complexifie.

Ne cherchez pas la perfection. Une observabilité imparfaite qui fonctionne vaut mieux qu'une théorie de la perfection qui n'existe que sur du papier. Commencez maintenant, même avec des outils basiques. Vous optimiserez plus tard.

Et une fois que vous êtes observable, les incidents deviennent des anomalies qu'on comprend, plutôt que des mystères qu'on subit.

À lire aussi :

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert

Observabilité : pourquoi vos dashboards ne suffisent pas