Trente secondes : c’est le délai moyen observé entre une erreur fatale déclenchée en production et la réception de l’alerte correspondante, une fois Sentry correctement installé sur un site WordPress. Ce délai, comparé aux heures voire aux jours qu’il faut parfois pour qu’un client signale un dysfonctionnement, justifie à lui seul l’intérêt de ce type d’outil pour une équipe qui gère un parc de sites en production.
L’installation brute d’un agent de suivi d’erreurs pose cependant une question qui ne doit pas être traitée après coup : quelles données transitent réellement vers ce service tiers hébergé hors de l’infrastructure du client ? Une erreur PHP peut inclure, dans sa trace, le contenu d’une variable contenant une adresse e-mail, un numéro de téléphone, voire un mot de passe en clair si le code source manipule ces données au moment du plantage.
Installer le SDK PHP de Sentry
L’intégration se fait via le SDK officiel PHP de Sentry, chargé tôt dans wp-config.php, avant même le chargement du cœur WordPress, pour capturer les erreurs les plus précoces possibles.
require_once __DIR__ . '/vendor/autoload.php';
\Sentry\init( array(
'dsn' => 'https://xxxx@o000000.ingest.sentry.io/000000',
'environment' => 'production',
'traces_sample_rate' => 0.1,
) );
Le paramètre environment permet de distinguer clairement les erreurs remontées depuis le site de production de celles générées sur un environnement de recette ou de développement, condition indispensable pour ne pas noyer les alertes réellement urgentes sous du bruit de test.
Le filtrage : la partie qui ne doit jamais être négligée
Sentry propose un mécanisme de « scrubbing » par défaut qui masque automatiquement certains champs connus comme sensibles (mots de passe, jetons d’authentification standards). Ce filtrage par défaut ne couvre cependant pas les champs personnalisés propres à un formulaire WordPress spécifique, comme un numéro de sécurité sociale saisi dans un formulaire métier ou une adresse postale complète.
\Sentry\init( array(
'dsn' => 'https://xxxx@o000000.ingest.sentry.io/000000',
'before_send' => function ( \Sentry\Event $event ) {
$request = $event->getRequest();
if ( isset( $request['data']['numero_secu'] ) ) {
unset( $request['data']['numero_secu'] );
}
return $event;
},
) );
Le callback before_send est le point de contrôle final avant l’envoi effectif de l’événement : c’est là que doivent être retirés tous les champs identifiés comme sensibles pour le projet précis, en fonction des formulaires réellement présents sur le site.
Établir la liste des champs à exclure
- Tout champ de mot de passe ou de jeton, même si le scrubbing par défaut les couvre déjà, par prudence
- Les champs de formulaire personnalisés contenant des données de santé, financières ou d’identité
- Les paramètres de requête GET susceptibles de contenir un jeton de connexion ou de réinitialisation de mot de passe
- Les en-têtes de cookie complets, à exclure globalement plutôt qu’à filtrer champ par champ
Séparer les environnements et limiter le volume
Sur un parc de plusieurs sites, il est recommandé de créer un projet Sentry distinct par site, ou au minimum par client, plutôt qu’un projet unique partagé : cela évite qu’une erreur récurrente sur un site noie les alertes d’un autre site plus critique. Le taux d’échantillonnage des traces de performance (traces_sample_rate) mérite aussi d’être réduit sur les sites à fort trafic, pour ne pas générer un volume de données inutilement élevé.
La question à se poser avant chaque champ ajouté à un formulaire client : si ce champ plante un jour et que sa valeur remonte dans une trace d’erreur, est-ce acceptable qu’elle soit stockée chez un tiers ? Si la réponse est non, il rejoint la liste d’exclusion dans
before_send.
En résumé
Sentry apporte une réactivité précieuse face aux erreurs de production, souvent détectées et corrigées avant même qu’un client ne les remarque. Cette réactivité ne doit jamais se faire au prix d’un envoi non maîtrisé de données personnelles vers un service tiers : le filtrage via before_send, construit sur mesure pour les formulaires réels du site, et la séparation stricte des environnements forment la base d’une installation responsable, à mettre en place dès le premier déploiement plutôt qu’en rattrapage.
