Trois jours. C’est le délai moyen constaté sur plusieurs boutiques avant qu’un client mécontent finisse par écrire pour signaler qu’il n’arrive pas à payer. Pendant ce temps, la passerelle continue de refuser silencieusement des transactions, l’e-mail d’échec part dans les spams de l’administrateur, et personne ne regarde les journaux serveur tant que le chiffre d’affaires ne dévisse pas franchement.
La solution la plus fiable n’est pas d’ajouter un tableau de bord de plus dans WooCommerce, mais de brancher un outil de suivi d’erreurs externe qui alerte en quelques secondes. Sentry, gratuit jusqu’à un volume raisonnable d’événements, se prête particulièrement bien à ce rôle sur une boutique WordPress.
Pourquoi les journaux WooCommerce ne suffisent pas
WooCommerce écrit ses erreurs de passerelle dans les logs internes, accessibles depuis WooCommerce > État > Journaux. Le problème n’est pas leur contenu, plutôt correct, mais leur visibilité : personne ne les consulte en temps réel, ils tournent en fichiers plats sans alerte, et ils sont souvent purgés automatiquement au bout de quelques jours par les réglages de rétention du serveur.
Un paiement refusé par une passerelle expirée, une clé API révoquée ou un certificat SSL périmé sur l’environnement de test finissent alors invisibles jusqu’à ce que les ventes s’arrêtent. Un outil comme Sentry résout ce problème en poussant l’alerte vers un canal actif : e-mail, Slack, ou SMS selon la configuration retenue.
Installer le SDK PHP et le relier à WordPress
L’installation se fait via Composer, dans le dossier du plugin ou du thème enfant qui portera l’intégration :
composer require sentry/sentry:^2.5
// Dans un fichier chargé tôt, par exemple functions.php du thème enfant
require_once __DIR__ . '/vendor/autoload.php';
\Sentry\init([
'dsn' => 'https://exemplecle@o123456.ingest.sentry.io/1234567',
'environment' => wp_get_environment_type(),
]);La fonction wp_get_environment_type(), disponible depuis WordPress 5.5, permet de distinguer automatiquement un environnement de production d’un environnement de recette si la constante WP_ENVIRONMENT_TYPE est définie dans wp-config.php. Cela évite de recevoir des alertes provenant du site de test du client.
Capturer précisément les échecs de passerelle
Le hook le plus fiable pour intercepter un échec de paiement est woocommerce_order_status_failed, déclenché dès qu’une commande bascule sur le statut failed, quelle que soit la passerelle utilisée :
add_action('woocommerce_order_status_failed', function ($order_id) {
$order = wc_get_order($order_id);
\Sentry\captureMessage(sprintf(
'Paiement échoué : commande #%d, passerelle %s, montant %s',
$order_id,
$order->get_payment_method(),
$order->get_total()
), \Sentry\Severity::warning());
});Pour les passerelles qui exposent des exceptions détaillées, comme un rejet de carte ou un dépassement de plafond, il est utile d’ajouter le message brut de la passerelle au contexte Sentry via \Sentry\configureScope(), afin de disposer du code d’erreur exact renvoyé par le prestataire.
Filtrer le bruit : ce qu’il ne faut surtout pas remonter
Un piège classique consiste à capturer aussi les tentatives normales : une carte simplement refusée par la banque du client pour solde insuffisant n’est pas un incident technique. Sans filtre, Sentry se remplit de centaines d’événements bénins et l’alerte utile se noie dedans.
- Ignorer les codes de refus bancaires standards (fonds insuffisants, carte perdue) listés par la passerelle
- Ne remonter que les erreurs système : timeout réseau, réponse HTTP 5xx du prestataire, clé API invalide
- Regrouper les événements identiques sur une fenêtre de dix minutes pour éviter une alerte par transaction
La distinction se fait généralement en lisant le code d’erreur renvoyé par l’API du prestataire de paiement avant de décider d’appeler captureMessage ou de laisser passer silencieusement.
Configurer des alertes qui atterrissent au bon endroit
Sentry permet de créer des règles d’alerte par projet : un e-mail pour les avertissements, une notification Slack immédiate pour les erreurs critiques. Sur une boutique en pleine activité, il vaut mieux réserver le canal instantané aux incidents qui bloquent réellement le paiement, sous peine de voir l’équipe se désensibiliser aux notifications.
Sur nos projets, une règle simple fonctionne bien : deux échecs de la même passerelle en moins de cinq minutes déclenchent une alerte Slack immédiate, un échec isolé attend le résumé quotidien par e-mail.
En résumé
Brancher Sentry sur WooCommerce ne demande ni extension premium ni développement lourd : une dizaine de lignes suffisent pour capturer les échecs de passerelle au bon niveau. L’essentiel du travail réside dans le filtrage, pour que l’équipe reçoive uniquement des alertes actionnables et ne découvre plus un problème de paiement par un client mécontent trois jours après les faits.
