Quatorze sites Elementor, gérés en parallèle pour différents clients, avec des widgets personnalisés partagés entre plusieurs projets. Une erreur JavaScript introduite dans un widget commun se propageait donc potentiellement sur l’ensemble du parc, sans qu’aucune remontée centralisée ne permette de le détecter avant qu’un client ne le signale lui-même.
Le besoin exprimé par l’équipe technique tenait en une phrase : voir, en un coup d’œil, quel widget génère le plus d’erreurs JavaScript, sur quel site, et depuis quelle version d’Elementor, sans devoir ouvrir la console de chaque site un par un après chaque déploiement.
Structurer la capture côté client
Le SDK JavaScript de Sentry, chargé sur chaque site via un plugin maison léger, capture par défaut toutes les erreurs non gérées de la page. Sans enrichissement, ces erreurs remontent sans contexte exploitable : impossible de savoir à quel widget Elementor elles se rattachent simplement à la lecture de la pile d’appel.
Sentry.init({
dsn: 'https://exemple@sentry.io/1234567',
environment: window.location.hostname,
beforeSend(event) {
const element = document.elementFromPoint(0, 0);
event.tags = event.tags || {};
event.tags.elementor_version = window.elementorFrontendConfig?.version || 'inconnue';
return event;
}
});
Associer chaque erreur à son widget d’origine
La méthode retenue consiste à intercepter les erreurs remontées par les scripts spécifiques de chaque widget personnalisé, en les enveloppant individuellement plutôt que de compter sur une capture globale imprécise.
function initWidgetAvecCapture(nomWidget, fonctionInit) {
try {
fonctionInit();
} catch (erreur) {
Sentry.withScope((scope) => {
scope.setTag('widget', nomWidget);
scope.setTag('site', window.location.hostname);
Sentry.captureException(erreur);
});
}
}
elementorFrontend.hooks.addAction('frontend/element_ready/carrousel-avis.default', ($scope) => {
initWidgetAvecCapture('carrousel-avis', () => initialiserCarrouselAvis($scope));
});
Le hook frontend/element_ready d’Elementor se déclenche à chaque initialisation d’un widget côté client, ce qui en fait le point d’accroche naturel pour lier une capture d’erreur à un nom de widget précis, quel que soit le site où ce widget est utilisé.
Construire le dashboard côté Sentry
Une fois les tags widget et site systématiquement présents sur chaque événement capturé, le tableau de bord Sentry regroupe les erreurs par ces deux dimensions, avec une vue en tableau triée par volume décroissant sur les sept derniers jours.
| Widget | Nombre d’erreurs (7 jours) | Sites concernés |
|---|---|---|
| carrousel-avis | 184 | 3 |
| compte-a-rebours | 27 | 1 |
| mega-menu-maison | 9 | 2 |
Alerter avant que le client ne le remarque
Une règle d’alerte a été configurée pour notifier l’équipe technique par messagerie interne dès qu’un widget dépasse cinquante occurrences d’erreur sur une fenêtre glissante de 24 heures, un seuil ajusté après plusieurs semaines d’observation pour éviter à la fois le bruit et le silence sur un incident réel.
- Erreurs regroupées par widget et par site, pas seulement par message d’erreur brut
- Tag de version d’Elementor présent sur chaque événement, pour corréler avec les mises à jour récentes
- Seuil d’alerte ajusté empiriquement plutôt que fixé arbitrairement dès le départ
Ce dispositif se limite volontairement au suivi des erreurs JavaScript côté navigateur : le monitoring PHP côté serveur et les autres outils d’observabilité déjà en place sur ce parc (métriques serveur, temps de réponse) suivent une architecture distincte, non traitée ici.
Une erreur qui touche un seul widget partagé sur trois sites différents mérite d’être vue comme un seul incident, pas comme trois tickets isolés ouverts séparément par chaque client.
En résumé
Regrouper les erreurs JavaScript par widget plutôt que par page a changé la façon dont l’équipe priorise ses correctifs sur ce parc de quatorze sites : un widget commun défaillant remonte désormais en tête de liste immédiatement, avant que plusieurs clients ne signalent le même symptôme séparément.
