Monitoring d'application web : Sentry, Datadog, PostHog — comment ne jamais être pris par surprise

Introduction

Un bug en production que personne ne détecte pendant 48 heures. Un temps de réponse API qui double sans qu'aucune alerte ne se déclenche. Un parcours utilisateur cassé qui fait chuter les conversions en silence. Ces scénarios ne sont pas des cas extrêmes — ils sont le quotidien des applications web sans monitoring sérieux.

En 2026, le monitoring n'est plus un "nice-to-have" qu'on ajoute après le lancement. C'est une couche d'infrastructure aussi fondamentale que la base de données ou l'authentification. Ce guide couvre les trois piliers de l'observabilité et les outils qui les adressent : Sentry pour les erreurs, Datadog pour l'infrastructure et les performances, PostHog pour l'analytics produit. Avec des exemples d'intégration Nuxt.js/Node.js prêts pour la production.

Les 3 Piliers de l'Observabilité : Logs, Métriques et Traces

Pour qu'une application soit réellement observable, il ne suffit pas de surveiller un seul aspect. L'observabilité repose sur une triade fondamentale, chacune offrant une perspective complémentaire sur le comportement de votre système.

Logs : Le Journal de Bord Détaillé

Les logs sont les enregistrements textuels des événements de votre application. Chaque requête, chaque erreur, chaque action utilisateur peut générer une entrée. Ils sont essentiels pour le débogage et l'analyse post-mortem.

Une bonne gestion des logs est cruciale : ils doivent être structurés (JSON, pas du texte libre), centralisés (pas éparpillés sur 5 serveurs) et facilement consultables. Des outils comme ELK Stack (Elasticsearch, Logstash, Kibana) ou Grafana Loki sont couramment utilisés pour agréger et analyser des volumes massifs.

// ❌ Log non structuré — inutilisable à l'échelle
console.log("User 123 failed to login");

// ✅ Log structuré — filtrable, indexable, alertable
logger.warn({
  event: 'auth.login_failed',
  userId: '123',
  reason: 'invalid_password',
  ip: req.ip,
  timestamp: new Date().toISOString()
});

La qualité des logs est d'ailleurs une composante essentielle de la sécurité des applications web — sans logs fiables, impossible de détecter ou d'investiguer une intrusion.

Métriques : Les Indicateurs de Santé en Temps Réel

Les métriques sont des valeurs numériques agrégées qui mesurent le comportement du système sur la durée : latence moyenne des requêtes, taux d'erreur, utilisation CPU, consommation mémoire. Contrairement aux logs (granulaires), les métriques offrent une vue d'ensemble pour identifier rapidement les tendances et déclencher des alertes.

Les principaux types de métriques :

Prometheus est le standard de facto pour la collecte de métriques, souvent visualisé avec Grafana.

Traces : Le Cheminement d'une Requête

Les traces (distributed tracing) sont vitales dans les architectures microservices. Elles permettent de visualiser le parcours d'une requête utilisateur à travers tous les services, bases de données et composants impliqués. Chaque étape est un "span", et l'ensemble forme une "trace".

[Client] → [API Gateway: 12ms] → [Auth Service: 3ms] → [User Service: 45ms] → [PostgreSQL: 38ms]
                                                       → [Redis Cache: 0.5ms]

Si une requête est lente, les traces révèlent exactement où le goulot d'étranglement se situe. OpenTelemetry est devenu le standard open source pour l'instrumentation, compatible avec Datadog, Jaeger et Grafana Tempo.

Monitoring des Erreurs avec Sentry

Sentry est la première ligne de défense de votre application. Sans monitoring d'erreurs, les bugs peuvent rester latents pendant des jours, impactant silencieusement l'expérience utilisateur.

Pourquoi Sentry ?

Sentry capture, agrège et contextualise les erreurs en temps réel, côté frontend (JavaScript, Vue.js, Nuxt.js) et backend (Node.js, Python, Go). Ses fonctionnalités clés :

• Stack trace complet avec variables locales, environnement et breadcrumbs (parcours utilisateur avant l'erreur)
• Grouping intelligent — les erreurs similaires sont regroupées automatiquement
• Sourcemaps — affiche le code source original même sur du JavaScript minifié
• Alertes configurables — Slack, PagerDuty, email en cas de nouvelle erreur ou pic
• Performance monitoring — transactions lentes, spans détaillés

Intégration Sentry avec Nuxt.js

npx nuxi module add @sentry/nuxt

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@sentry/nuxt/module'],

  sentry: {
    dsn: process.env.SENTRY_DSN,
    sourceMapsUploadOptions: {
      org: 'votre-org',
      project: 'votre-projet'
    }
  }
})

// sentry.client.config.ts
import * as Sentry from '@sentry/nuxt';

Sentry.init({
  dsn: useRuntimeConfig().public.sentryDsn,
  environment: useRuntimeConfig().public.environment,
  tracesSampleRate: 0.2,
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0,
  integrations: [
    Sentry.replayIntegration(),
    Sentry.browserTracingIntegration()
  ]
});

// sentry.server.config.ts
import * as Sentry from '@sentry/nuxt';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 0.5,
  profilesSampleRate: 0.1
});

Enrichir le Contexte des Erreurs

Le contexte fait toute la différence entre une erreur que vous résolvez en 5 minutes et une que vous mettez 3 heures à reproduire :

// Middleware d'identification utilisateur
export default defineNuxtRouteMiddleware(() => {
  const user = useCurrentUser();
  if (user.value) {
    Sentry.setUser({
      id: user.value.id,
      email: user.value.email,
      subscription: user.value.plan
    });
  }
});

// Breadcrumbs manuels pour les actions critiques
function processPayment(orderId: string) {
  Sentry.addBreadcrumb({
    category: 'payment',
    message: `Processing payment for order ${orderId}`,
    level: 'info'
  });

  try {
    return stripe.charges.create({ /* ... */ });
  } catch (error) {
    Sentry.captureException(error, {
      tags: { flow: 'checkout', orderId },
      extra: { cartItems: getCartSummary() }
    });
    throw error;
  }
}

APM et Infrastructure avec Datadog

Sentry excelle sur les erreurs applicatives, mais ne couvre pas l'infrastructure. Datadog comble ce manque avec l'APM (Application Performance Monitoring), le monitoring d'infrastructure et la gestion centralisée des logs.

Quand Datadog Devient Nécessaire

Datadog se justifie quand votre stack se complexifie :

• Plusieurs services backend communiquant entre eux
• Infrastructure conteneurisée (Docker, Kubernetes)
• Bases de données multiples (PostgreSQL, Redis)
• Besoin de corréler métriques infra et performances applicatives

Intégration Datadog APM (Node.js)

// tracing.ts — à importer en PREMIER dans votre application
import tracer from 'dd-trace';

tracer.init({
  service: 'mon-saas-api',
  env: process.env.NODE_ENV,
  version: process.env.APP_VERSION,
  logInjection: true,
  runtimeMetrics: true,
  profiling: true
});

export default tracer;

# docker-compose.yml — agent Datadog
services:
  datadog-agent:
    image: gcr.io/datadoghq/agent:latest
    environment:
      - DD_API_KEY=${DD_API_KEY}
      - DD_APM_ENABLED=true
      - DD_LOGS_ENABLED=true
      - DD_PROCESS_AGENT_ENABLED=true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc/:/host/proc/:ro
    ports:
      - "8126:8126"

Métriques Custom pour Votre SaaS

Au-delà des métriques système par défaut, instrumentez les métriques métier qui comptent pour votre produit :

import { StatsD } from 'hot-shots';

const metrics = new StatsD({
  host: 'localhost',
  port: 8125,
  prefix: 'saas.'
});

// Mesurer la latence d'une opération critique
async function createSubscription(userId: string, plan: string) {
  const start = Date.now();

  try {
    const result = await stripe.subscriptions.create({ /* ... */ });
    metrics.increment('subscription.created', { plan });
    metrics.histogram('subscription.creation_time', Date.now() - start);
    return result;
  } catch (error) {
    metrics.increment('subscription.failed', { plan, error: error.code });
    throw error;
  }
}

// Jauges pour l'état du système
setInterval(() => {
  metrics.gauge('queue.pending_jobs', await getQueueLength());
  metrics.gauge('users.online', await getOnlineUserCount());
}, 30_000);

Analytics Produit avec PostHog

Sentry dit "ça a cassé", Datadog dit "le serveur rame" — mais ni l'un ni l'autre ne répond à "est-ce que les utilisateurs réussissent à faire ce qu'ils veulent ?". C'est le rôle de PostHog : l'analytics produit orienté développeur.

Pourquoi PostHog ?

PostHog combine en un seul outil ce qui nécessite habituellement 3-4 services :

• Product analytics — funnels, rétention, parcours utilisateur
• Session replay — voir exactement ce que l'utilisateur fait
• Feature flags — activer/désactiver des features par segment
• A/B testing — tester des variantes d'UI ou de flow
• Error tracking — détection d'erreurs (concurrent léger de Sentry)

Le tout avec un tier gratuit généreux : 1M d'événements, 5K replays, 100K erreurs par mois.

Intégration PostHog avec Nuxt.js

// plugins/posthog.client.ts
import posthog from 'posthog-js';

export default defineNuxtPlugin(() => {
  const config = useRuntimeConfig();

  posthog.init(config.public.posthogKey, {
    api_host: config.public.posthogHost || 'https://eu.i.posthog.com',
    capture_pageview: false,  // géré manuellement pour le SPA
    capture_pageleave: true,
    persistence: 'localStorage+cookie'
  });

  const router = useRouter();
  router.afterEach((to) => {
    posthog.capture('$pageview', { path: to.fullPath });
  });

  return {
    provide: { posthog }
  };
});

Tracker les Événements Métier

// Tracker les actions qui comptent pour votre business
function trackSignup(method: 'email' | 'google' | 'github') {
  posthog.capture('user_signed_up', {
    method,
    referrer: document.referrer,
    landing_page: sessionStorage.getItem('landing_page')
  });
}

function trackFeatureUsage(feature: string, metadata?: Record<string, any>) {
  posthog.capture('feature_used', {
    feature,
    plan: currentUser.value?.plan,
    ...metadata
  });
}

function trackCheckout(plan: string, price: number, currency: string) {
  posthog.capture('checkout_started', { plan, price, currency });
}

Sentry vs Datadog vs PostHog : Quel Outil pour Quel Besoin ?

Ces trois outils ne sont pas en compétition directe — ils couvrent des besoins complémentaires :

Stack Recommandé par Maturité

Au stade MVP, la combinaison Sentry + PostHog gratuits couvre 90 % des besoins. N'ajoutez Datadog que lorsque la complexité infrastructure le justifie — c'est-à-dire quand vous passez en architecture microservices ou multi-services avec des conteneurs Docker.

Stratégie d'Alerting : Quand et Comment Alerter

Le monitoring sans alerting, c'est regarder un tableau de bord 24h/24 en espérant repérer un problème. L'alerting sans stratégie, c'est se noyer sous les faux positifs et finir par ignorer les vrais incidents.

Les 4 Règles d'un Alerting Efficace

1. Alerter sur les symptômes, pas les causes — "Le taux d'erreur 5xx dépasse 5 %" plutôt que "Le CPU est à 80 %". Un CPU élevé n'est un problème que s'il dégrade le service.
2. Définir des seuils réalistes — Basez-les sur vos données historiques, pas sur des intuitions. Utilisez les percentiles (P95, P99) plutôt que les moyennes.
3. Hiérarchiser les alertes — Toutes les alertes ne méritent pas un SMS à 3h du matin :
   • P1 (critique) — Service down, données corrompues → SMS + appel
   • P2 (dégradé) — Latence élevée, taux d'erreur anormal → Slack immédiat
   • P3 (attention) — Disk 80 %, queue qui grossit → Slack, traité en heures ouvrées
4. Documenter les runbooks — Chaque alerte doit être liée à une procédure de résolution. "Le taux d'erreur est haut" n'est pas actionnable. "Vérifier les logs Sentry, identifier le déploiement récent, rollback si nécessaire" l'est.

Exemple de Configuration d'Alertes Sentry

// Les alertes Sentry se configurent via l'UI ou l'API
// Voici les règles essentielles à mettre en place :

// 1. Nouvelle erreur jamais vue → Slack #bugs (immédiat)
// 2. Erreur existante qui spike (+200% en 1h) → Slack #incidents
// 3. Taux d'erreur global > 5% → PagerDuty (P1)
// 4. Transaction P95 > 2s sur un endpoint critique → Slack #perf

Checklist Monitoring pour la Mise en Production

Avant de lancer votre application, vérifiez ces points. C'est une étape à intégrer dans votre pipeline CI/CD :

Erreurs & Exceptions

• Sentry configuré côté client ET serveur
• Sourcemaps uploadés automatiquement au build
• Contexte utilisateur attaché aux erreurs
• Alertes Slack/email pour les nouvelles erreurs

Performance

• Endpoints critiques instrumentés (latence, throughput)
• Seuils d'alerte P95 définis sur les routes principales
• Métriques Core Web Vitals trackées (LCP, CLS, INP)

Infrastructure

• Monitoring CPU, mémoire, disque sur chaque service
• Alertes sur la saturation des ressources
• Health checks configurés sur le load balancer

Produit

• Événements métier clés trackés (signup, checkout, feature_used)
• Funnels de conversion configurés dans PostHog
• Session replay activé sur les parcours critiques

Opérationnel

• Runbooks documentés pour chaque type d'alerte
• Rotation d'astreinte définie
• Procédure de rollback testée

FAQ : Monitoring d'Application Web en Production

Conclusion : Du Réactif au Proactif

Le monitoring transforme votre posture opérationnelle : au lieu de découvrir les problèmes par les tickets de support, vous les détectez et les résolvez avant qu'ils n'impactent vos utilisateurs. Le trio Sentry + PostHog + Datadog couvre l'intégralité du spectre — des erreurs de code à la santé infrastructure, en passant par le comportement utilisateur.

Commencez par Sentry et PostHog (gratuits, 30 minutes d'intégration chacun), puis ajoutez Datadog quand la complexité de votre infrastructure le justifie. L'investissement est minime comparé au coût d'un incident non détecté sur un SaaS en production.

Si vous lancez une application et souhaitez mettre en place un monitoring solide dès le départ, contactez notre équipe. Nous intégrons l'observabilité dès la conception de nos applications web sur mesure et SaaS.