« Une erreur JavaScript s’est produite » ne suffit plus à agir dès qu’un site comporte neuf blocs personnalisés partageant le même projet Sentry. Sans contexte, chaque alerte demande d’ouvrir la stack trace, de la lire ligne par ligne, et de deviner quel composant est réellement en cause — un travail répétitif qui finit par ralentir le traitement des vraies urgences.
La solution retenue sur ce projet ne change rien à l’installation de base de Sentry, déjà en place bloc par bloc : elle ajoute un contexte systématique — tag et fil d’interactions — qui rend chaque alerte immédiatement exploitable, même par une personne qui n’a pas écrit le code du bloc concerné.
Le problème d’un projet Sentry partagé sans contexte
Regrouper tous les blocs sous un seul projet Sentry simplifie la configuration côté plateforme, mais dilue l’information si rien ne distingue une erreur d’un bloc d’une autre. Sur ce site, la liste des alertes ressemblait à une succession de messages génériques (« Cannot read properties of null »), tous identiques en apparence, sans indication du bloc à l’origine.
Ajouter un tag par bloc à l’initialisation
Chaque bloc dispose de son propre point d’initialisation JavaScript, dans lequel un tag Sentry est posé avant même que l’utilisateur interagisse avec le composant :
import * as Sentry from '@sentry/browser';
function initBlocCarousel( element ) {
Sentry.setTag( 'bloc', 'carousel-produits' );
Sentry.setTag( 'version-bloc', '2.3.0' );
// ... suite de l'initialisation
}
Ajouter des breadcrumbs sur les interactions clés
Le tag identifie le bloc, mais ne dit rien du contexte au moment du plantage. Les breadcrumbs Sentry retracent, eux, les dernières actions de l’utilisateur avant l’erreur — un clic sur une flèche de carrousel, un changement de filtre, une soumission de formulaire :
function surClicFlecheCarousel( index ) {
Sentry.addBreadcrumb( {
category: 'interaction',
message: `Clic sur la flèche du carrousel, index ${ index }`,
level: 'info',
} );
try {
afficherSlide( index );
} catch ( erreur ) {
Sentry.captureException( erreur );
}
}
Une alerte accompagnée de ce fil d’interactions permet, dans la majorité des cas observés sur ce projet, de reproduire le bug en quelques minutes plutôt qu’en devinant un scénario a posteriori.
Filtrer les alertes par bloc dans l’interface Sentry
Une fois les tags en place, la recherche bloc:carousel-produits dans l’interface Sentry isole immédiatement les erreurs de ce composant précis, sans dépendre de mots-clés dans le message d’erreur lui-même, souvent trop générique pour être utile.
- Créer une alerte Sentry distincte par tag de bloc critique, plutôt qu’une seule alerte générique pour tout le projet.
- Ajouter le numéro de version du bloc en tag, pour repérer immédiatement si une régression coïncide avec une mise à jour récente.
- Conserver un nombre raisonnable de breadcrumbs (les dix à quinze dernières actions suffisent largement), pour ne pas alourdir inutilement chaque évènement envoyé.
Ce que cette approche ne remplace pas
La configuration des règles d’alerte Sentry (seuils, canaux de notification, fenêtres de regroupement) reste un réglage indépendant, à faire une fois côté plateforme, qui ne dépend pas du contexte ajouté ici côté code. Le monitoring des extensions tierces non maîtrisées par l’équipe, lui, dépasse largement ce que ce type d’instrumentation ciblée peut couvrir : Sentry ne peut tagger que ce que le code appelle explicitement.
En résumé
Sur un site multi-blocs, la vraie valeur de Sentry ne vient pas de sa simple présence, mais du contexte qui accompagne chaque erreur capturée. Un tag par bloc et quelques breadcrumbs bien placés transforment une alerte générique en information directement actionnable, sans effort d’investigation supplémentaire.
