Quinze minutes suffisent pour une première intégration Sentry fonctionnelle dans un thème — un délai dérisoire comparé à celui, sans monitoring actif, qui s’écoule en moyenne entre l’apparition d’une erreur fatale sur un site client et le moment où l’agence en est informée : le temps que le client remarque le problème et prenne la peine d’appeler. Sur un projet de thème sur mesure pour un client à fort trafic, cette latence est devenue inacceptable après un incident resté invisible pendant plusieurs heures un week-end.
La réponse retenue n’a pas été d’instrumenter tout WordPress avec un plugin de monitoring généraliste, mais d’installer le SDK Sentry directement dans le thème, pour capturer uniquement les erreurs qui proviennent de son propre code.
Installation du SDK côté thème
Le SDK PHP de Sentry s’installe via Composer, dans le dossier du thème, à l’écart du cœur de WordPress et des autres extensions :
cd wp-content/themes/mon-theme
composer require sentry/sentry
L’initialisation se fait dans functions.php, en chargeant l’autoload généré par Composer avant toute autre logique du thème :
require_once get_stylesheet_directory() . '/vendor/autoload.php';
\Sentry\init( array(
'dsn' => getenv( 'SENTRY_DSN' ),
'environment' => wp_get_environment_type(),
'traces_sample_rate' => 0.0,
) );
Le DSN (l’URL de projet Sentry) est stocké en variable d’environnement plutôt qu’en dur dans le code, pour ne jamais l’exposer dans un dépôt Git partagé.
Cibler uniquement les erreurs du thème
Sans filtrage, Sentry capturerait toutes les erreurs PHP de l’installation entière, y compris celles provenant du cœur de WordPress ou d’autres extensions, ce qui produirait un bruit important et rendrait le tableau de bord Sentry inexploitable. Un filtre appliqué avant l’envoi limite la capture aux erreurs dont la pile d’appel touche réellement le dossier du thème :
\Sentry\configureScope( function ( \Sentry\State\Scope $scope ): void {
$scope->setTag( 'composant', 'theme-mon-theme' );
} );
set_error_handler( function( $niveau, $message, $fichier, $ligne ) {
if ( false !== strpos( $fichier, get_stylesheet_directory() ) ) {
\Sentry\captureMessage( $message, \Sentry\Severity::error() );
}
return false;
}, E_ERROR | E_WARNING );
Ce filtrage par chemin de fichier évite de dupliquer la surveillance déjà assurée par d’autres outils pour le reste de la plateforme, et garde le périmètre de responsabilité clair entre l’équipe qui maintient le thème et celle qui gère l’hébergement global.
Anonymiser le contexte utilisateur
Par défaut, Sentry peut capturer l’adresse IP et certaines informations de session. Sur un projet soumis au RGPD, ce comportement a été désactivé explicitement pour ne conserver que les informations techniques strictement nécessaires au diagnostic :
\Sentry\init( array(
'dsn' => getenv( 'SENTRY_DSN' ),
'send_default_pii' => false,
) );
Tester la remontée avant de faire confiance à l’outil
Une route de test temporaire, accessible uniquement en environnement de préproduction, permet de vérifier que la remontée fonctionne réellement avant de considérer le monitoring opérationnel :
add_action( 'init', function() {
if ( isset( $_GET['test_sentry'] ) && 'preprod' === wp_get_environment_type() ) {
\Sentry\captureMessage( 'Test de remontée Sentry depuis le thème' );
wp_die( 'Message envoyé à Sentry.' );
}
} );
Ce que cette intégration ne couvre pas
Ce tutoriel se limite aux erreurs PHP survenant côté serveur dans le code du thème. Les erreurs JavaScript côté navigateur nécessiteraient une intégration séparée du SDK Sentry pour navigateur, avec sa propre configuration et son propre DSN, hors du périmètre de cet article. Le monitoring des extensions installées sur le site relève également d’un périmètre distinct, à traiter séparément si besoin.
Sur nos projets à fort enjeu de disponibilité, cette installation minimale de Sentry côté thème est désormais posée dès la recette, avant même la mise en ligne définitive.
En résumé
Une quinzaine de minutes suffit pour installer et filtrer correctement le SDK Sentry dans un thème, afin d’être alerté d’une erreur fatale avant que le client ne le remarque. Limiter la capture au code du thème, via un filtre sur le chemin de fichier, garde l’outil lisible et évite de dupliquer une surveillance déjà assurée ailleurs sur la plateforme.
