# Éditeur de site et Sentry en 2026 : un dashboard d’erreurs par template

> Centraliser les erreurs de plusieurs sites FSE dans un seul outil ne suffit pas si elles restent indifférenciées. Construction d'un tableau de bord Sentry regroupant les erreurs par template.

- Auteur : Clément Hadrot
- Publié le : 2026-06-20
- Mis à jour le : 2026-06-20
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/sentry-dashboard-erreurs-par-template/

## L’essentiel

- Chaque erreur est taguée avec le slug du template qui l'a déclenchée
- Le tag repose sur le filtre template_include du cœur WordPress
- Le dashboard trie les templates par nombre d'erreurs cumulées sur sept jours

« Une erreur PHP toutes les quatre minutes en moyenne, répartie sur 46 sites, sans savoir laquelle vient d'où » : c'est le constat qui a motivé la construction de ce tableau de bord, sur un parc de sites FSE gérés par une même agence, jusque-là suivis via des journaux d'erreurs consultés site par site, sans vue d'ensemble.

Sentry était déjà en place sur chaque site individuellement, correctement configuré pour capturer les exceptions PHP. Le problème n'était pas la capture des erreurs, mais leur exploitation : sans information sur le template concerné, une même erreur reportée dix fois sur dix sites différents restait indiscernable d'une erreur ponctuelle isolée.

## Étape 1 : installer le SDK PHP officiel sur chaque site

Chaque site du parc utilise le paquet `sentry/sentry`, initialisé dans un mu-plugin partagé, chargé avant tout autre code du thème pour capturer le plus tôt possible les erreurs survenant au chargement :

```
\Sentry\init( array(
    'dsn' => getenv( 'SENTRY_DSN' ),
    'environment' => wp_get_environment_type(),
) );
```

## Étape 2 : identifier le template en cours de rendu

Le filtre `template_include`, exécuté par le cœur juste avant le chargement effectif du fichier de template, fournit le chemin exact du template résolu pour la requête en cours. Ce filtre a été utilisé pour capturer le slug du template avant toute exécution de son contenu :

```
add_filter( 'template_include', function ( $template ) {
    $slug = basename( $template, '.php' );
    \Sentry\configureScope( function ( $scope ) use ( $slug ) {
        $scope->setTag( 'template_slug', $slug );
    } );
    return $template;
}, 1 );
```

Sur un site en éditeur de site, ce filtre reçoit en réalité le chemin d'un fichier PHP généré dynamiquement par le cœur à partir du template HTML correspondant. Pour retrouver le slug réel du template `.html` d'origine (celui visible dans l'éditeur de site), le tag a été enrichi avec la valeur retournée par `get_page_template_slug()` lorsqu'elle est disponible, en repli sur le nom de fichier sinon.

## Étape 3 : ajouter un tag de site sur un DSN partagé

> L'essentiel à retenir : Chaque erreur est taguée avec le slug du template qui l'a déclenchée ; Le tag repose sur le filtre template_include du cœur WordPress ; Le dashboard trie les templates par nombre d'erreurs cumulées sur sept jours

Les 46 sites partagent le même projet Sentry, distingués uniquement par un tag `site_slug` renseigné à partir d'une constante définie dans le `wp-config.php` de chaque installation. Ce choix, plutôt que de créer un projet Sentry séparé par site, permet de croiser plus facilement les erreurs communes à plusieurs sites du même thème mutualisé.

## Étape 4 : construire le tableau de bord de regroupement

Dans l'interface Sentry, un tableau de bord personnalisé combine deux widgets principaux. Le premier affiche le nombre d'erreurs cumulées sur sept jours, groupées par la combinaison des tags `template_slug` et `site_slug`, triées par ordre décroissant. Le second affiche l'évolution dans le temps du nombre d'erreurs pour les cinq templates les plus problématiques de la semaine, permettant de repérer immédiatement si un pic correspond à un déploiement récent.

## Étape 5 : configurer des alertes ciblées par template

Plutôt qu'une alerte générique déclenchée au-delà d'un seuil global d'erreurs, des règles d'alerte distinctes ont été configurées pour les templates jugés critiques (page d'accueil, tunnel de paiement pour les sites e-commerce du parc), avec un seuil plus bas que pour les templates secondaires, moins visités.

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

- Un pattern partagé par une douzaine de sites générait une erreur silencieuse sur le rendu d'une image de repli manquante, invisible individuellement mais massive une fois agrégée.
- Un seul template, présent sur trois sites seulement, concentrait à lui seul plus d'un tiers des erreurs remontées sur l'ensemble du parc.

> Sans le tag de template, chacune de ces erreurs restait une ligne isolée parmi des milliers d'autres : c'est le regroupement qui a transformé du bruit en signal exploitable.

## En résumé

Ce tableau de bord ne remplace pas un monitoring PHP général au niveau serveur, ni les autres outils d'observabilité déjà en place sur l'infrastructure du parc (surveillance de la charge, du temps de réponse réseau). Il comble un manque précis : relier chaque erreur applicative capturée par Sentry à l'endroit exact du thème bloc qui l'a produite, condition nécessaire pour prioriser les correctifs sur un parc de plusieurs dizaines de sites plutôt que de traiter chaque alerte comme un cas isolé.