Sentry : maîtriser le tracking d'erreurs dans les applications modernes

Toutes les applications ont des bugs, c'est la réalité du développement logiciel. Ce qui distingue les meilleures équipes, ce n'est pas l'absence d'erreurs, mais la capacité à les détecter rapidement, à les comprendre en profondeur et à les corriger avant que les utilisateurs ne s'en aperçoivent. Sans monitoring adapté, un crash en production est invisible jusqu'à ce qu'un utilisateur se plaigne, et à ce moment-là vous n'avez plus de stack trace, plus de contexte, et aucune idée du nombre de personnes impactées. Sentry est la plateforme open source de monitoring d'erreurs qui comble cet écart, transformant les silences en données structurées et actionnables.

Ce que Sentry capture

Sentry va bien au-delà de la simple capture d'exceptions non gérées. Pour chaque erreur survenant en production, il enregistre la stack trace complète avec le contexte source, une chronologie précise des actions de l'utilisateur ayant précédé le crash, les métadonnées d'environnement comme la version du navigateur et l'OS, et les métriques de performance par release. Le résultat n'est pas un rapport de crash vague, c'est un kit de reproduction complet. Vous savez ce qui a planté, dans quel environnement, après quelle action utilisateur, et pour combien de personnes.

Configurer Sentry

Pour une application Next.js, Sentry s'exécute via un fichier de config côté client qui se charge avant le code de l'application. La DSN identifie votre projet, tandis que les taux d'échantillonnage contrôlent l'agressivité de la capture. Définir replaysOnErrorSampleRate à 1.0 signifie que chaque session se terminant par une erreur bénéficie d'un replay complet, ce qui est précieux pour déboguer les problèmes difficiles à reproduire :

import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  tracesSampleRate: 1.0,
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0,

  integrations: [
    Sentry.replayIntegration({
      maskAllText: true,
      blockAllMedia: true,
    }),
  ],
});

Enrichir le contexte des erreurs

Les erreurs brutes suffisent rarement pour diagnostiquer un problème. Sentry vous permet d'attacher du contexte structuré à chaque événement, rendant chaque rapport immédiatement actionnable plutôt qu'une simple stack trace à décoder isolément.

Identification de l'utilisateur

Savoir quel utilisateur a rencontré une erreur indique combien de personnes sont impactées, si le problème est isolé ou généralisé, et vous donne une piste directe pour investiguer. Cela rend aussi le filtrage et la recherche dans le dashboard Sentry bien plus puissants :

import * as Sentry from "@sentry/nextjs";

Sentry.setUser({
  id: user.id,
  email: user.email,
  username: user.name,
});

// Effacer à la déconnexion
Sentry.setUser(null);

Tags et contexte personnalisés

Le contexte métier est ce qui transforme une stack trace cryptique en une erreur directement actionnable. Si un paiement échoue, vous voulez connaître la devise, le montant et l'utilisateur concerné, pas uniquement le type d'exception. Les tags sont indexés et consultables dans Sentry, ce qui permet de filtrer instantanément toutes les erreurs de paiement en EUR par exemple :

try {
  await processPayment(amount, currency);
} catch (error) {
  Sentry.captureException(error, {
    tags: {
      action: "payment",
      currency: currency,
    },
    extra: {
      amount: amount,
      userId: user.id,
    },
  });
}

Breadcrumbs

Les breadcrumbs vous donnent une trace chronologique des événements précédant l'erreur : requêtes HTTP, événements de navigation, interactions UI, et points de contrôle manuels définis dans votre code. Sentry capture la plupart d'entre eux automatiquement, mais vous pouvez en ajouter manuellement aux étapes clés de vos parcours :

Sentry.addBreadcrumb({
  category: "checkout",
  message: "Utilisateur a cliqué sur le bouton de paiement",
  level: "info",
});

// Les requêtes HTTP, logs console et événements de navigation
// sont tous capturés automatiquement par défaut

Source maps

Sans source maps, Sentry affiche des stack traces minifiées pointant vers bundle.js:1:84729, ce qui n'apporte aucune information exploitable. Avec les source maps, vous voyez le fichier TypeScript original, la fonction exacte et la ligne précise. La configuration dans Next.js se fait via le plugin webpack de Sentry, qui les upload automatiquement au moment du build :

import { withSentryConfig } from "@sentry/nextjs";

export default withSentryConfig(nextConfig, {
  org: "your-org",
  project: "your-project",
  sourcemaps: {
    disable: false,
  },
  hideSourceMaps: true,
});

L'option hideSourceMaps garantit que les source maps sont uploadées vers Sentry mais non servies publiquement aux utilisateurs finaux, ce qui est exactement le comportement souhaité en production.

Suivi des releases

Associer chaque initialisation Sentry à un identifiant de release permet de voir quel déploiement a introduit un bug. Sentry peut alors afficher les tendances du taux d'erreurs par release, vous alerter quand une nouvelle release connaît un pic d'erreurs, et vous permettre de marquer des problèmes comme résolus dans une version spécifique :

Sentry.init({
  release: `my-app@${process.env.npm_package_version}`,
  environment: process.env.NODE_ENV,
});

Combiné aux source maps, chaque erreur en production se retrouve ainsi mappée à une ligne précise dans un commit spécifique. La boucle de feedback entre le fait de livrer du code et comprendre son impact devient très courte.

Filtrer le bruit

Une intégration Sentry sans filtres se remplit rapidement d'erreurs d'extensions navigateur, de scripts tiers défaillants et d'avertissements bénins sur lesquels vous ne pouvez rien faire. Le hook beforeSend vous permet d'inspecter chaque événement avant qu'il ne quitte le navigateur et de supprimer tout ce qui ne mérite pas votre attention :

Sentry.init({
  beforeSend(event) {
    // Supprimer les erreurs provenant d'extensions navigateur
    if (event.exception?.values?.[0]?.stacktrace?.frames?.some(
      frame => frame.filename?.includes('extensions')
    )) {
      return null;
    }
    return event;
  },
  ignoreErrors: [
    'ResizeObserver loop limit exceeded',
    'Non-Error promise rejection captured',
  ],
  denyUrls: [
    /extensions\//i,
    /^chrome:\/\//i,
  ],
});

Configurer cela tôt vous évite la fatigue aux alertes et maintient le dashboard Sentry focalisé sur les erreurs qui comptent vraiment.

Surveillance des performances

La surveillance des performances de Sentry va bien au-delà du tracking d'erreurs. Elle permet de tracer des transactions complètes dans votre application, de les décomposer en spans individuels, et de voir précisément où le temps est dépensé. Combinée au suivi des releases, elle permet de détecter les régressions de performance de la même façon que les bugs, avant que les utilisateurs ne commencent à se plaindre :

const transaction = Sentry.startTransaction({
  name: "checkout-process",
  op: "transaction",
});

const validationSpan = transaction.startChild({
  op: "validation",
  description: "Valider les articles du panier",
});

await validateCart();
validationSpan.finish();

const paymentSpan = transaction.startChild({
  op: "http.client",
  description: "Traiter le paiement",
});

await processPayment();
paymentSpan.finish();

transaction.finish();

Dans le dashboard Sentry, cette transaction apparaît sous forme de cascade avec le timing de chaque span, ce qui permet d'identifier facilement quelle opération est lente et si elle a régressé entre les releases.

Conclusion

Sentry transforme le monitoring d'erreurs d'une corvée réactive en une pratique de développement proactive. Avec les source maps pointant vers le vrai code, le suivi des releases liant les bugs aux déploiements, le contexte enrichi rendant chaque erreur actionnable et les données de performance complétant le tableau, vous cessez de deviner ce qui a planté en production pour le savoir avec certitude.