# FSE et Sentry : instrumenter les erreurs JavaScript de l’éditeur en production

> Installer le SDK Sentry JavaScript pour surveiller uniquement l'interface du Site Editor, sans toucher au reste du monitoring PHP.

- Auteur : WordPress Développement
- Publié le : 2022-09-26
- Mis à jour le : 2022-09-26
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/sentry-editeur-site-erreurs-javascript/

## L’essentiel

- SDK Sentry chargé uniquement sur l'écran site-editor.php
- Tags contextuels par template et par bloc
- Bruit filtré avant envoi à Sentry

Douze rapports d'erreurs par semaine, tous identiques, tous provenant du même écran : voilà ce que remontait la console d'un client avant qu'on installe un monitoring dédié à l'éditeur de site. Le Site Editor de WordPress est une application React assez dense, et quand un bloc tiers casse son rendu, l'utilisateur ne voit souvent qu'un écran blanc ou un message générique. Sans télémétrie, il faut reproduire le bug à l'aveugle.

Ce billet détaille l'installation ciblée du SDK `@sentry/browser` pour l'interface d'administration du Site Editor uniquement, avec un filtrage strict pour ne pas polluer le projet Sentry avec des erreurs sans rapport. Le monitoring des erreurs PHP côté serveur, lui, reste hors sujet ici : c'est un projet Sentry distinct, avec sa propre configuration.

## Pourquoi ne pas charger Sentry sur tout le back-office

Charger un SDK de monitoring sur chaque écran d'administration a un coût : poids JavaScript supplémentaire, risque de capturer des erreurs générées par des extensions tierces hors de notre périmètre de responsabilité, et volume de données qui explose le quota du plan Sentry. Pour un prestataire qui gère plusieurs sites clients, mieux vaut cibler précisément l'écran où la complexité justifie l'investissement : celui du Site Editor.

La fonction `get_current_screen()` permet d'identifier cet écran avec fiabilité, avant d'enfiler le script correspondant via `admin_enqueue_scripts`.

## Charger le SDK conditionnellement

```
function wpm_enqueue_sentry_site_editor( $hook ) {
    if ( 'site-editor.php' !== $hook ) {
        return;
    }

    wp_enqueue_script(
        'sentry-browser',
        'https://browser.sentry-cdn.com/7.100.0/bundle.tracing.min.js',
        array(),
        '7.100.0',
        true
    );

    wp_add_inline_script(
        'sentry-browser',
        sprintf(
            'window.Sentry && Sentry.init({ dsn: %s, environment: %s, tracesSampleRate: 0.1 });',
            wp_json_encode( WPM_SENTRY_DSN ),
            wp_json_encode( wp_get_environment_type() )
        )
    );
}
add_action( 'admin_enqueue_scripts', 'wpm_enqueue_sentry_site_editor' );
```

> L'essentiel à retenir : SDK Sentry chargé uniquement sur l'écran site-editor.php ; Tags contextuels par template et par bloc ; Bruit filtré avant envoi à Sentry

## Filtrer le bruit avant l'envoi

Sans filtrage, Sentry remonte des erreurs provenant d'extensions de navigateur, de bloqueurs de publicité ou de scripts d'agences tierces injectés par des plugins de statistiques mal isolés. La fonction `beforeSend` du SDK est l'endroit pour éliminer ce bruit avant qu'il ne consomme le quota du projet.

- Rejeter les erreurs dont le message contient `ResizeObserver loop`, un faux positif classique des navigateurs Chromium.
- Ignorer les erreurs dont la pile d'appel ne référence aucun fichier issu de `wp-content/themes/` ou `wp-content/plugins/gutenberg/`.
- Ajouter systématiquement le nom du thème bloc actif comme tag, pour distinguer les incidents par client dans un compte Sentry mutualisé.

On enrichit également chaque événement avec le nom du template en cours d'édition, récupéré via l'objet global `wp.data.select( 'core/edit-site' ).getEditedPostId()`. Cette donnée contextuelle transforme un stacktrace anonyme en ticket exploitable : on sait immédiatement si le crash touche le template d'archive, la page d'accueil ou une template part de pied de page.

## Ce que ça change concrètement

Sur un parc de sites gérés pour plusieurs clients, ce dispositif a permis d'identifier en amont trois régressions provoquées par des mises à jour de blocs tiers, avant même que les clients ne les signalent. Le tag par thème permet de trier rapidement les alertes : une erreur qui touche cinq sites en même temps pointe presque toujours vers une extension mutualisée plutôt qu'un problème local.

Un point d'attention : Sentry facture au volume d'événements. Le `tracesSampleRate` à 0,1 dans l'exemple ci-dessus limite l'échantillonnage des traces de performance à 10 % des sessions, suffisant pour détecter une tendance sans saturer le quota.

### Alerter sans spammer

Une règle d'alerte Sentry configurée pour ne notifier qu'à partir de trois occurrences en une heure évite de réveiller l'équipe pour un incident isolé côté navigateur du visiteur. C'est ce seuil, couplé au filtrage en amont, qui rend le dispositif tenable dans la durée.

> Un monitoring qui remonte tout finit toujours ignoré au bout de trois semaines. Mieux vaut un flux réduit et fiable qu'un flux exhaustif et invisible.

## Notre verdict

Installer Sentry sur le seul écran du Site Editor coûte une vingtaine de lignes de PHP et une politique de filtrage un peu travaillée. Le retour sur investissement se mesure surtout en confiance : on cesse de découvrir les régressions par les tickets clients pour les découvrir par le tableau de bord, souvent plusieurs heures avant que quiconque ne s'en aperçoive. Sur un portefeuille de sites en éditeur de site, c'est un des dispositifs les moins coûteux à mettre en place pour un gain de réactivité immédiat.