Elementor et Sentry : capturer les erreurs JavaScript d’un widget personnalisé

« Sentry recommande d’initialiser le SDK le plus tôt possible dans le cycle de vie de l’application », précise la documentation officielle du projet. Sur un site WordPress classique, « l’application » n’a pas de frontière nette : plusieurs widgets Elementor personnalisés développés pour des clients différents cohabitent, et instrumenter Sentry pour l’ensemble d’Elementor aurait mélangé leurs erreurs dans un flux illisible.

Ce projet portait sur un widget personnalisé de simulateur de devis, développé sur mesure pour un client, où des erreurs JavaScript silencieuses faisaient perdre des soumissions sans que personne ne s’en aperçoive avant plusieurs semaines. L’objectif : capturer précisément les erreurs de ce widget, sans surveiller l’ensemble d’Elementor ni des autres widgets du site.

Pourquoi ne pas instrumenter tout Elementor

Charger le SDK Sentry globalement, sur toutes les pages, capturerait des erreurs provenant de widgets tiers non maintenus par l’agence, de scripts de plugins qu’il n’est pas question de corriger, voire d’extensions de navigateur du visiteur. Le volume d’événements remontés deviendrait vite ingérable, et le quota du plan Sentry (facturé au volume d’événements) serait consommé par du bruit plutôt que par les erreurs qui comptent réellement.

Chargement conditionnel du SDK

Le SDK JavaScript de Sentry est chargé uniquement sur les pages où le widget est présent, via un enregistrement de script conditionnel côté PHP :

function simulateur_enqueue_sentry() {
    if ( ! has_shortcode_or_widget( 'simulateur-devis' ) ) {
        return;
    }
    wp_enqueue_script(
        'sentry-sdk',
        'https://browser.sentry-cdn.com/7.x.x/bundle.min.js',
        [],
        null,
        true
    );
    wp_add_inline_script( 'sentry-sdk', "
        Sentry.init({
            dsn: 'https://exemple@o0.ingest.sentry.io/0',
            tracesSampleRate: 0
        });
    " );
}
add_action( 'wp_enqueue_scripts', 'simulateur_enqueue_sentry' );

La fonction has_shortcode_or_widget est une fonction maison qui inspecte le contenu Elementor de la page courante (via _elementor_data) à la recherche du widgetType du simulateur, pour n’injecter le SDK que là où il est réellement utile.

Isoler les erreurs du widget des autres scripts

• Un tag widget: simulateur-devis est ajouté à chaque événement Sentry via Sentry.setTag
• Le taux d’échantillonnage des traces de performance est volontairement mis à zéro pour ce cas, seul le suivi d’erreurs intéresse ce widget
• Le script du widget encapsule sa logique dans un bloc try/catch qui appelle Sentry.captureException avant de continuer, plutôt que de laisser l’erreur remonter silencieusement

Ce que révèlent les premières alertes

Dans les deux premières semaines de mise en production, Sentry a remonté une dizaine d’erreurs TypeError liées à un champ de formulaire optionnel non initialisé selon la combinaison de réponses choisie par le visiteur, un cas de test que la recette manuelle n’avait pas couvert. La correction a pris moins d’une heure une fois l’erreur précisément localisée avec sa pile d’appels.

Conseil maison : pour un widget Elementor personnalisé livré à un client, un chargement conditionnel de Sentry limité au périmètre du widget coûte peu et rembourse largement son investissement dès la première anomalie détectée avant que le client ne s’en plaigne.

Limites de cette approche

Ce chargement ciblé ne couvre que les erreurs JavaScript exécutées côté navigateur. Les erreurs PHP du rendu serveur du même widget (par exemple un appel API qui échoue silencieusement côté back-end) nécessitent une instrumentation distincte, avec le SDK PHP de Sentry, hors du périmètre de cet article.

En résumé

Instrumenter un widget Elementor personnalisé avec Sentry ne demande ni de couvrir tout le site ni d’accepter un bruit de fond ingérable : un chargement conditionnel, quelques tags de contexte et un try/catch bien placé suffisent à transformer des erreurs invisibles en alertes exploitables.