Le WordPress d'aujourd'hui, décodé pour les développeurs

Blocs Gutenberg

Un tableau de bord Sentry par bloc pour un parc de sites : notre mise en place

Construction d'un tableau de bord Sentry regroupant les erreurs par bloc maison, pour centraliser le suivi d'une agence qui opère plusieurs dizaines de sites.

Par Clément Hadrot • 30 juin 2026 • 4 min de lecture • Aucun commentaire
Un tableau de bord Sentry par bloc pour un parc de sites : notre mise en place

47 sites, un seul tableau de bord : c’est le résultat visé par cette agence qui opérait jusque-là un suivi d’erreurs éclaté, site par site, sans vision transversale des blocs maison responsables des incidents les plus fréquents. Ce tutoriel construit le tableau de bord Sentry qui centralise ce suivi, bloc par bloc, plutôt que site par site.

Il ne couvre pas le monitoring PHP général du serveur (déjà assuré par un outil distinct) ni les autres outils d’observabilité déjà en place sur l’infrastructure de l’agence, uniquement la remontée d’erreurs spécifiques aux blocs Gutenberg maison.

Étape 1 — Installer le SDK Sentry côté PHP

Le SDK PHP officiel de Sentry s’installe via Composer sur le plugin réseau qui porte le registre de blocs communs de l’agence :

composer require sentry/sentry
\Sentry\init( array(
    'dsn'         => AGENCE_SENTRY_DSN,
    'environment' => wp_get_environment_type(),
) );

Étape 2 — Attacher un tag « bloc » à chaque erreur

La clé de ce tableau de bord tient dans un tag Sentry personnalisé, attaché avant chaque appel de render_callback, qui identifie précisément le bloc d’origine en cas d’erreur capturée pendant son rendu :

function agence_wrapper_render_bloc( $render_callback, $nom_bloc ) {
    return function ( $attributes, $content, $block ) use ( $render_callback, $nom_bloc ) {
        \Sentry\configureScope( function ( $scope ) use ( $nom_bloc ) {
            $scope->setTag( 'bloc', $nom_bloc );
            $scope->setTag( 'site', get_bloginfo( 'url' ) );
        } );

        try {
            return call_user_func( $render_callback, $attributes, $content, $block );
        } catch ( \Throwable $erreur ) {
            \Sentry\captureException( $erreur );
            return '';
        }
    };
}
L'essentiel à retenir : Tag Sentry dédié attaché à chaque erreur selon le bloc d'origine ; Filtrage du bruit lié aux extensions tierces avant envoi à Sentry ; Tableau de bord unique croisant bloc, site et fréquence d'erreur

Étape 3 — Filtrer le bruit avant envoi

Sans filtrage, Sentry se serait rapidement rempli d’erreurs provenant d’extensions tierces installées sur certains sites du parc, hors du périmètre de responsabilité de l’agence sur ses propres blocs. Un filtre before_send exclut ces erreurs avant même leur envoi, en se basant sur la trace de la pile d’appel :

\Sentry\init( array(
    'dsn'          => AGENCE_SENTRY_DSN,
    'before_send'  => function ( $event ) {
        $trace = $event->getExceptionDataBag()[0]->getStacktrace() ?? null;
        if ( $trace && agence_trace_hors_perimetre( $trace ) ) {
            return null; // Erreur ignorée, hors registre de blocs de l'agence.
        }
        return $event;
    },
) );

Étape 4 — Construire le tableau de bord côté Sentry

Côté interface Sentry, un tableau de bord personnalisé croise trois axes : le tag bloc, le tag site, et la fréquence d’occurrence sur les sept derniers jours. Ce croisement permet de répondre directement à la question qui manquait avant cette mise en place : quel bloc maison génère le plus d’erreurs, sur combien de sites du parc, et depuis quand.

  • Widget de fréquence par bloc, trié par nombre d’occurrences décroissant sur la semaine.
  • Alerte automatique dès qu’un bloc dépasse un seuil d’erreurs sur plus de trois sites simultanément.
  • Lien direct depuis chaque erreur vers le fichier source du bloc concerné dans le dépôt de code de l’agence.

Ce que ce tableau de bord a révélé dès la première semaine

La mise en place a immédiatement révélé qu’un seul bloc, un composant de calcul de devis interactif partagé sur douze sites du parc, concentrait à lui seul près d’un tiers des erreurs remontées, liées à une valeur non numérique transmise par un champ de formulaire externe non maîtrisé par l’agence. Cette information, invisible auparavant faute de vision transversale, a permis une correction unique bénéficiant immédiatement aux douze sites concernés.

Sans vision transversale sur un parc de sites, chaque incident reste un cas isolé à traiter localement ; avec elle, un même correctif profite d’un coup à tous les sites concernés.

Pour aller plus loin

Ce tableau de bord ne remplace pas une supervision serveur classique, mais comble un angle mort spécifique : celui des erreurs qui se produisent dans la logique métier des blocs maison, invisibles pour un outil de monitoring généraliste centré sur la disponibilité du serveur. La documentation officielle du SDK PHP Sentry détaille les autres options de contexte disponibles, utiles pour affiner encore ce tableau de bord au fil du temps.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi