Obtenir de la visibilité sur votre plateforme déployée : monitoring, logs et suivi des erreurs

Déployer une plateforme n’est pas la fin du travail. C’est le moment où votre système quitte l’environnement contrôlé de votre machine et commence à rencontrer de vrais utilisateurs, des réseaux lents, des jetons expirés, des bases de données saturées, des mauvais déploiements, des jobs en arrière-plan, des webhooks rejoués et des API tierces qui tombent au pire moment.

Si vous ne voyez pas ce qui se passe, la production devient un jeu de devinettes. Vous rafraîchissez des dashboards, vous fouillez dans les logs, vous redémarrez des services et vous espérez que le même incident ne reviendra pas. La visibilité transforme ce chaos en travail d’ingénierie.

Ce guide est un plan pratique pour construire cette visibilité. Ce n’est pas une documentation fournisseur géante. Ce n’est pas non plus la promesse qu’un seul dashboard réglera tout. L’objectif est simple : quand votre plateforme déployée est lente, cassée ou étrange, vous devez pouvoir répondre à ces questions :

Qu’est-ce qui échoue ?
Qui est affecté ?
Quand est-ce que cela a commencé ?
Quel déploiement, service, appel, job ou dépendance en est la cause ?
Que faut-il corriger en premier ?

C’est le rôle du monitoring, de l’observabilité, des logs et du suivi des erreurs.

Commencez par les signaux

La stack d’observabilité devient plus simple à comprendre quand on sépare les signaux :

Signal	Ce qu’il permet de comprendre	Outils courants
Erreurs	Qu’est-ce qui a crashé ou levé une exception ?	Sentry, Bugsnag, Rollbar
Traces	Que s’est-il passé pendant cette requête ou ce workflow ?	OpenTelemetry, Tempo, Jaeger, Honeycomb
Métriques	Comment le système évolue-t-il dans le temps ?	Prometheus, Grafana, Datadog
Logs	Qu’est-ce que le service dit avoir fait ?	Loki, Elasticsearch, OpenSearch
Alertes	Qu’est-ce qui exige une intervention humaine maintenant ?	Grafana Alerting, PagerDuty, Opsgenie

Ne commencez pas en installant tous les outils. Commencez par les questions auxquelles vous devez répondre. Une petite plateforme a généralement besoin de quatre choses en premier :

un suivi des erreurs pour les crashs et exceptions
des traces de requêtes et de jobs pour comprendre la latence et les dépendances
des métriques pour la santé, la saturation et les compteurs métier critiques
des logs centralisés et consultables par service, environnement, déploiement et identifiant de requête

Tout le reste s’appuie sur ces bases.

L’architecture pratique

Une bonne architecture de départ pour une plateforme cloud-native ressemble à ceci :

Services applicatifs
  -> Sentry pour les erreurs, releases et contexte utilisateur
  -> SDK OpenTelemetry pour les traces, spans et métriques
  -> OpenTelemetry Collector pour le routage et la normalisation
  -> Prometheus pour le stockage des métriques et les règles d'alerte
  -> Loki ou ELK pour les logs
  -> Grafana pour les dashboards, l'exploration et les alertes
  -> Terraform pour provisionner dashboards, data sources, dossiers et alertes

Le plus important n’est pas le mélange exact de fournisseurs. Le plus important, c’est le flux :

Instrumenter l’application près du code qui traite les requêtes, jobs, files d’attente et appels externes.
Ajouter des données de corrélation comme trace_id, request_id, user_id, tenant_id, environment et release.
Envoyer la télémétrie vers des backends dédiés au lieu de la laisser prisonnière des logs de conteneurs.
Utiliser dashboards et alertes pour opérer le système, pas pour décorer la plateforme.
Provisionner l’observabilité comme du code afin que la visibilité survive aux changements d’équipe, redéploiements et reconstructions d’environnement.

Suivi des erreurs : ajoutez Sentry tôt

Sentry est souvent le gain le plus rapide parce qu’il fournit vite des informations très utiles : stack traces d’exception, utilisateurs affectés, releases, contexte navigateur/appareil, breadcrumbs et fréquence.

La configuration minimale utile :

configurer Sentry dans chaque frontend, backend, worker et processus de job
définir environment avec production, staging ou preview
définir release avec la version déployée ou le SHA du commit
attacher le contexte utilisateur et tenant quand c’est sûr
activer le tracing de performance seulement là où l’échantillonnage est acceptable
envoyer les source maps pour les builds frontend
marquer les déploiements/releases pour voir les régressions après déploiement

L’erreur que je vois le plus souvent consiste à traiter Sentry comme un simple système de logs d’erreurs. Il est plus utile que cela. Sentry doit vous dire si un nouveau déploiement a déclenché un pic, si un seul client est affecté ou si tout le monde l’est, et si la même exception se produit discrètement depuis des semaines.

Un événement Sentry utile doit répondre à ceci :

service=api
environment=production
release=2026.06.03-9f4a21c
user_id=usr_123
tenant_id=tenant_456
trace_id=7b3f...
transaction=POST /api/orders

Sans ce contexte, une exception n’est qu’une stack trace. Avec ce contexte, elle devient un chemin de débogage.

Tracing : utilisez OpenTelemetry pour toute la requête

Les logs vous disent ce qu’un service a déclaré. Les métriques vous disent ce qui change dans le temps. Les traces montrent le parcours d’une requête ou d’un workflow précis.

OpenTelemetry est un bon choix par défaut parce qu’il est neutre vis-à-vis des fournisseurs. Vous pouvez instrumenter une fois et envoyer les traces vers Grafana Tempo, Jaeger, Honeycomb, Datadog, New Relic ou un autre backend plus tard.

Tracez au minimum :

les requêtes HTTP entrantes
les requêtes de base de données
les opérations de cache
la publication et la consommation dans les files d’attente
les appels vers les API externes
les jobs en arrière-plan
les tâches planifiées

L’objectif n’est pas de tracer chaque fonction. L’objectif est de voir où le temps est passé et où l’échec est entré dans le workflow.

Une trace utile peut montrer :

POST /api/checkout  2.8s
  validate_cart       24ms
  get_user            18ms
  reserve_inventory  480ms
  charge_card        1.9s
  publish_event       30ms
  render_response      8ms

C’est immédiatement plus utile qu’une ligne de log disant “checkout lent”. Vous voyez que le fournisseur de paiement est le goulot d’étranglement.

Pour la plupart des équipes, l’OpenTelemetry Collector vaut la peine d’être ajouté tôt. Il vous donne un point central pour recevoir la télémétrie, appliquer des règles d’échantillonnage, enrichir les attributs et router les données vers le bon backend.

receivers:
  otlp:
    protocols:
      http:
      grpc:

processors:
  batch:
  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert

exporters:
  otlp:
    endpoint: tempo:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [resource, batch]
      exporters: [otlp]

Ce n’est pas une configuration de production complète, mais elle montre la forme : recevoir des données OTLP, les enrichir, les grouper et les exporter.

Métriques : Prometheus pour la santé et les tendances

Les métriques répondent aux questions dans le temps :

Le taux d’erreur de l’API augmente-t-il ?
La latence p95 a-t-elle changé après le dernier déploiement ?
La file des workers prend-elle du retard ?
Le pool de connexions à la base de données est-il saturé ?
Les inscriptions, paiements, uploads ou messages chutent-ils ?

Prometheus est un très bon choix pour les métriques de service : son modèle de données est simple, son écosystème est mature et Grafana fonctionne naturellement avec lui.

Les métriques prioritaires :

Métrique	Pourquoi elle compte
nombre de requêtes	trafic, adoption et chutes soudaines
nombre/taux d’erreurs	casse en production
durée des requêtes	latence visible par l’utilisateur
profondeur de file	saturation des workers
durée et échecs des jobs	fiabilité de l’asynchrone
utilisation du pool DB	saturation avant panne
latence/erreurs des API externes	santé des dépendances fournisseur
nombre/version de déploiement	corrélation avec les régressions

Utilisez les métriques pour les agrégats, pas pour le détail forensic. Une métrique doit vous dire que POST /api/checkout a un taux d’erreur de 7 %. Une trace ou un événement Sentry doit vous dire pourquoi un checkout précis a échoué.

Les bonnes alertes commencent par quelques règles simples :

Taux d'erreur API élevé pendant 10 minutes
Latence p95 au-dessus du seuil utilisateur
Age de file d'attente au-dessus du SLA
Aucun paiement réussi sur les 15 dernières minutes
Pool de connexions DB au-dessus de 90 %

N’alertez pas sur chaque pic. Alertez quand un humain doit agir.

Logs : Loki ou ELK, mais structurés

Les logs restent essentiels, mais seulement s’ils sont consultables et corrélés. Les logs en texte brut sont l’endroit où le débogage se perd.

Utilisez des logs structurés :

{
	"level": "error",
	"service": "api",
	"environment": "production",
	"release": "2026.06.03-9f4a21c",
	"trace_id": "7b3f...",
	"request_id": "req_abc",
	"user_id": "usr_123",
	"route": "POST /api/checkout",
	"message": "Payment authorization failed",
	"provider": "stripe",
	"duration_ms": 1932
}

Le choix de stack dépend de votre équipe :

Loki convient bien si vous utilisez déjà Grafana et voulez une agrégation de logs attentive aux coûts. Loki indexe les labels, pas chaque mot, donc le design des labels compte.
ELK/OpenSearch convient si vous avez besoin d’une recherche plein texte puissante, d’une indexation plus lourde et d’analyses de logs sur de nombreuses formes d’événements.

Pour beaucoup de plateformes, Loki avec Grafana suffit. Pour les environnements très contraints par la conformité, l’analyse sécurité ou des besoins de recherche complexes, ELK ou OpenSearch peut valoir son coût opérationnel.

Quel que soit le choix, standardisez les labels :

service
environment
region
release
tenant_id
trace_id
request_id
job_name

Ces labels font la différence entre “chercher checkout dans tous les logs” et “montre-moi les erreurs API de production pour ce tenant après le dernier déploiement”.

Grafana : construisez les dashboards autour de questions

Les dashboards Grafana doivent refléter votre manière d’opérer la plateforme. Ne construisez pas un dashboard géant avec tous les graphiques. Construisez de petits dashboards autour de décisions.

Commencez par :

Vue plateforme : disponibilité, nombre de requêtes, taux d’erreur, latence p95, incidents actifs
Santé API : latence par route, taux d’erreur par route, latence des dépendances, saturation
Santé workers : profondeur de file, âge de file, durée des jobs, retries, dead-letter count
Santé métier : inscriptions, paiements, uploads, messages, commandes ou ce que votre plateforme doit continuer à faire
Santé déploiement : release actuelle, taux d’erreur par release, latence par release, signaux de rollback

Les dashboards ne servent pas seulement aux incidents. Ils servent aussi à avoir confiance. Après un déploiement, vous devez savoir si la plateforme va mieux, moins bien ou pareil.

Provisionnez Grafana avec Terraform

Créer des dashboards à la main fonctionne jusqu’au jour où quelqu’un en supprime un, modifie une alerte ou a besoin du même setup en staging. L’observabilité doit être traitée comme de l’infrastructure.

Terraform peut provisionner des dossiers Grafana, data sources, dashboards, règles d’alerte, politiques de notification et points de contact. Une forme minimale ressemble à ceci :

provider "grafana" {
  url  = var.grafana_url
  auth = var.grafana_auth
}

resource "grafana_folder" "platform" {
  title = "Platform"
}

resource "grafana_data_source" "prometheus" {
  type = "prometheus"
  name = "Prometheus"
  url  = var.prometheus_url
}

resource "grafana_data_source" "loki" {
  type = "loki"
  name = "Loki"
  url  = var.loki_url
}

Vous n’avez pas besoin de modéliser chaque panel dans Terraform dès le premier jour, mais les éléments critiques doivent être du code :

data sources
dossiers de dashboards
dashboards partagés
règles d’alerte
points de contact de notification
variables par environnement

Le bénéfice n’est pas seulement la répétabilité. C’est aussi la revue. Les changements d’alertes doivent passer par le même processus de revue que les changements applicatifs.

La corrélation transforme les données en visibilité

La stack fonctionne seulement quand les signaux sont connectés.

Quand une alerte se déclenche, vous devez pouvoir avancer ainsi :

Alerte Grafana
  -> métrique Prometheus montrant un pic de latence p95
  -> trace d'une requête lente
  -> logs avec le même trace_id
  -> issue Sentry de la même release
  -> déploiement qui a introduit la régression

Ce workflow dépend d’attributs cohérents :

service.name
deployment.environment
service.version ou release
trace_id
request_id
user_id ou identifiant de session anonyme
tenant_id si applicable
région cloud ou runtime

C’est là que beaucoup d’équipes échouent. Elles installent de bons outils, mais ne standardisent pas le contexte. Le résultat : cinq systèmes déconnectés et beaucoup de recherche manuelle.

Que construire en premier

Si vous partez de presque rien, construisez dans cet ordre :

Sentry dans chaque runtime pour rendre visibles les exceptions et releases.
Logs structurés avec environnement, service, release, request ID et trace ID.
Traces OpenTelemetry pour les requêtes, jobs, appels DB, files d’attente et API externes.
Métriques Prometheus pour trafic, erreurs, latence, saturation et flux métier clés.
Dashboards Grafana pour la plateforme, l’API, les workers, les déploiements et la santé métier.
Alertes pour les pannes qui affectent les utilisateurs, pas chaque fluctuation technique.
Provisioning Terraform pour les data sources, dashboards et règles d’alerte Grafana.

Cet ordre donne de la valeur rapidement. Sentry attrape la casse évidente. Les logs donnent le détail. Les traces expliquent les workflows. Les métriques montrent les tendances. Dashboards et alertes transforment les données en opérations.

Checklist de visibilité production

Avant de considérer une plateforme prête pour la production, je veux pouvoir répondre à ceci :

Est-ce que je vois quelle release tourne ?
Est-ce que je vois les erreurs par release, service, route et environnement ?
Est-ce que je peux suivre une requête entre services ?
Est-ce que je peux connecter une issue Sentry aux logs et aux traces ?
Est-ce que je vois la latence p50, p95 et p99 des routes critiques ?
Est-ce que je vois la profondeur des files et l’âge des jobs ?
Est-ce que je peux savoir si une dépendance tierce échoue ?
Est-ce que je peux distinguer utilisateurs bloqués et travail arrière-plan retardé ?
Est-ce que je vois les flux métier critiques comme paiements, inscriptions, uploads ou messages ?
Est-ce que je peux reprovisionner la configuration d’observabilité depuis du code ?
Est-ce qu’un ingénieur d’astreinte peut déboguer un incident sans demander à cinq personnes où regarder ?

Si la réponse est non, la plateforme n’est pas encore pleinement visible.

Conclusion

L’observabilité n’est pas un projet de dashboard. C’est une habitude d’ingénierie de production.

Sentry fournit un suivi des erreurs à fort signal. OpenTelemetry fournit des traces et métriques portables. Prometheus fournit le monitoring time-series. Loki ou ELK fournit des logs consultables. Grafana fournit dashboards et alertes. Terraform rend l’ensemble reproductible.

Mais les outils ne sont utiles que lorsqu’ils sont connectés par un contexte cohérent et orientés vers de vraies questions opérationnelles.

La meilleure stack d’observabilité est celle qui vous fait passer de “quelque chose ne va pas” à “ce déploiement a cassé le checkout pour ces utilisateurs parce que cette dépendance est devenue plus lente” en quelques minutes, pas en quelques heures.