composer require sentry/sentry : c’est par cette commande que commence l’intégration de Sentry dans la plupart des extensions WordPress distribuées à plusieurs clients. Le SDK PHP officiel de Sentry permet de capturer une exception non gérée avec son contexte complet — pile d’appels, version de PHP, variables d’environnement pertinentes — et de la faire remonter dans un tableau de bord centralisé, plutôt que de la laisser dormir dans un fichier debug.log que personne ne consultera jamais.
Le bénéfice est réel : sur une extension installée chez plusieurs dizaines de clients, un bug d’incompatibilité avec une configuration serveur particulière peut rester invisible pendant des semaines si personne ne consulte les logs de chaque site individuellement. Sentry centralise ces remontées, avec le nombre d’occurrences, les sites concernés et la fréquence d’apparition. Mais une intégration naïve transforme rapidement le tableau de bord en un flux ingérable de notices PHP sans intérêt.
Initialiser le SDK au bon moment
Le SDK Sentry doit être initialisé le plus tôt possible dans le cycle de chargement de l’extension, idéalement dans le fichier principal, avant que la moindre logique métier ne s’exécute :
\Sentry\init( [
'dsn' => defined( 'MON_EXT_SENTRY_DSN' ) ? MON_EXT_SENTRY_DSN : '',
'environment' => wp_get_environment_type(),
'release' => 'mon-extension@' . MON_EXT_VERSION,
'before_send' => 'mon_ext_filtrer_avant_envoi',
] );
Le paramètre environment s’appuie sur wp_get_environment_type(), disponible depuis WordPress 5.5, pour distinguer automatiquement les remontées provenant d’un environnement de production de celles d’un environnement de développement local — une distinction indispensable pour ne pas polluer le suivi de production avec les erreurs d’un développeur en train de tester une branche instable.
Filtrer le bruit avec before_send
C’est ici que se joue la différence entre un monitoring utile et un monitoring qu’on finit par ignorer. La fonction passée à before_send reçoit chaque événement avant son envoi et peut décider de le bloquer :
function mon_ext_filtrer_avant_envoi( \Sentry\Event $event ): ?\Sentry\Event {
$message = (string) $event->getMessage();
// Ignore les erreurs connues liées à des extensions tierces incompatibles.
if ( str_contains( $message, 'Undefined array key' ) &&
str_contains( $message, 'plugin-tiers-connu' ) ) {
return null;
}
return $event;
}
Sans ce filtre, une notice PHP récurrente déclenchée par un plugin tiers connu et déjà identifié comme non bloquant peut à elle seule représenter 90 % du volume d’événements capturés, noyant les vraies régressions sous un bruit de fond permanent.
Capturer les exceptions gérées volontairement
Toutes les erreurs intéressantes ne sont pas des exceptions non gérées qui remontent jusqu’au gestionnaire global. Certains points critiques du code méritent une capture explicite, même quand l’exception est ensuite rattrapée proprement :
try {
$reponse = wp_remote_post( $url, $args );
if ( is_wp_error( $reponse ) ) {
throw new RuntimeException( $reponse->get_error_message() );
}
} catch ( RuntimeException $e ) {
\Sentry\captureException( $e );
// Traitement de repli propre, sans faire échouer la requête utilisateur.
}
Donner du contexte utile sans exposer de données sensibles
Un événement Sentry sans contexte n’aide pas beaucoup à diagnostiquer : il faut savoir sur quel site, avec quelle configuration, l’erreur s’est produite. Le SDK permet d’attacher des tags et un contexte additionnel via Sentry\configureScope, mais cette pratique impose une vigilance particulière sur les données personnelles :
- Attacher la version de l’extension, de WordPress et de PHP : utile, jamais sensible.
- Attacher l’URL du site plutôt qu’une donnée utilisateur identifiable comme un e-mail ou un nom.
- Ne jamais attacher le contenu brut d’une requête si elle peut contenir un mot de passe ou une donnée de paiement.
Laisser le client désactiver l’envoi
Une extension distribuée à des clients externes ne peut pas imposer silencieusement l’envoi de données de diagnostic vers un service tiers. Une option de réglage, désactivée par défaut ou clairement expliquée à l’installation, doit permettre de couper l’envoi Sentry sans désinstaller l’extension :
if ( ! get_option( 'mon_ext_diagnostics_actives', false ) ) {
return; // Le SDK Sentry n'est jamais initialisé.
}
Une remontée d’erreur qui arrive sans contexte exploitable coûte plus de temps à trier qu’à ignorer. Le filtrage en amont n’est pas un luxe, c’est la condition pour que l’équipe continue réellement à regarder le tableau de bord après la troisième semaine.
En résumé
Intégrer Sentry dans une extension WordPress distribuée apporte une visibilité précieuse sur les erreurs réellement rencontrées en production, à condition de traiter le filtrage du bruit comme une partie intégrante de l’intégration, pas comme une optimisation à faire plus tard. Initialisation précoce, filtre before_send rigoureux, contexte utile sans donnée sensible et option de désactivation claire forment le socle d’une intégration qui reste consultée dans la durée plutôt qu’abandonnée après le premier pic de notifications.
