# Afficher la dernière erreur Sentry d’un module sur son écran de réglages

> Pourquoi obliger l'équipe de support à ouvrir Sentry pour vérifier l'état d'un module quand l'information peut apparaître directement dans son écran de réglages ?

- Auteur : WordPress Développement
- Publié le : 2024-04-12
- Mis à jour le : 2026-09-30
- Catégorie : Astuces
- URL : https://www.wpmoderne.fr/tips/derniere-erreur-sentry-module-ecran-reglages/

## L’essentiel

- Interroger l'API Sentry par tag applicatif
- Mettre en cache le résultat pour ne pas ralentir l'écran
- Afficher un résumé lisible sans jargon technique

Pourquoi l'équipe de support devrait-elle changer d'outil, se connecter à Sentry, filtrer par projet puis par tag, simplement pour savoir si le module de paiement a récemment renvoyé une erreur ? Cette question, posée lors d'une revue d'ergonomie interne, a mené à un correctif simple : afficher directement la dernière erreur Sentry associée à un module dans son propre écran de réglages, là où l'équipe de support passe déjà du temps à vérifier la configuration.

Ce tutoriel ne traite pas de la configuration de Sentry elle-même — l'intégration côté PHP capture déjà les exceptions avec un tag applicatif par module. L'objectif est de récupérer, via l'API REST de Sentry, la dernière occurrence associée à ce tag et de l'afficher sous forme de résumé lisible, sans obliger quiconque à ouvrir un onglet supplémentaire.

## Structurer les erreurs capturées par module

Pour que la requête ciblée fonctionne, chaque exception envoyée à Sentry depuis le module doit porter un tag distinctif, ajouté au contexte avant l'envoi.

```
\Sentry\configureScope( function ( \Sentry\State\Scope $scope ): void {
    $scope->setTag( 'module', 'paiement' );
} );
```

## Interroger l'API Sentry pour la dernière occurrence

L'API Sentry expose un endpoint `issues` par projet, filtrable par requête de recherche incluant les tags. Un appel serveur récupère la première entrée triée par date la plus récente.

> L'essentiel à retenir : Interroger l'API Sentry par tag applicatif ; Mettre en cache le résultat pour ne pas ralentir l'écran ; Afficher un résumé lisible sans jargon technique

```
function wpmoderne_derniere_erreur_sentry( $module ) {
    $cache_key = 'sentry_derniere_erreur_' . $module;
    $resultat  = get_transient( $cache_key );

    if ( false !== $resultat ) {
        return $resultat;
    }

    $reponse = wp_remote_get(
        sprintf(
            'https://sentry.io/api/0/projects/%s/%s/issues/?query=tag:module:%s&sort;=date&limit;=1',
            SENTRY_ORG_SLUG,
            SENTRY_PROJECT_SLUG,
            rawurlencode( $module )
        ),
        array(
            'headers' => array( 'Authorization' => 'Bearer ' . SENTRY_API_TOKEN ),
            'timeout' => 5,
        )
    );

    if ( is_wp_error( $reponse ) ) {
        return null;
    }

    $issues    = json_decode( wp_remote_retrieve_body( $reponse ), true );
    $resultat  = $issues[0] ?? null;

    set_transient( $cache_key, $resultat, 10 * MINUTE_IN_SECONDS );

    return $resultat;
}
```

## Afficher le résumé dans l'écran de réglages

L'écran de réglages du module ajoute une section dédiée qui affiche le titre de l'erreur, sa date, et un lien direct vers l'issue complète dans Sentry pour l'investigation approfondie si nécessaire.

```
function wpmoderne_afficher_bloc_sentry( $module ) {
    $erreur = wpmoderne_derniere_erreur_sentry( $module );

    if ( ! $erreur ) {
        echo '<p style="color:#00a32a;">Aucune erreur récente signalée pour ce module.</p>';
        return;
    }

    printf(
        '<div style="border-left:4px solid #d63638;padding:8px 12px;background:#fcf0f1;">
            <strong>%1$s</strong><br>
            <span>Dernière occurrence : %2$s</span><br>
            <a href="%3$s" target="_blank" rel="noopener">Voir dans Sentry</a>
        </div>',
        esc_html( $erreur['title'] ),
        esc_html( mysql2date( 'd/m/Y H:i', $erreur['lastSeen'] ) ),
        esc_url( $erreur['permalink'] )
    );
}
```

## Limiter la fréquence des appels à l'API

Interroger Sentry à chaque chargement de l'écran ralentirait inutilement une page consultée fréquemment, et risquerait d'atteindre les limites de quota de l'API. Un transitoire de dix minutes suffit pour ce cas d'usage : l'information reste pertinente sans appel excessif.

- Un module rarement consulté peut se contenter d'une mise en cache plus longue, jusqu'à une heure, sans perte réelle de pertinence.
- Un module critique en période de forte charge peut au contraire justifier un rafraîchissement plus fréquent, avec un bouton « actualiser » manuel plutôt qu'un cache court systématique.

### Adapter le message au public non technique

Le titre brut d'une exception PHP (`TypeError: Argument #1 ($amount) must be of type int`) ne parle à personne côté support. Une table de correspondance simple, associant une signature d'erreur connue à un message clair (« Le module de paiement a reçu un montant invalide, vérifier la configuration de la devise »), rend l'information réellement exploitable sans connaissance technique.

> Une erreur affichée sans traduction en langage métier reste une information pour développeur, pas pour l'équipe qui doit agir en premier.

## Notre verdict

Ce résumé Sentry directement dans l'écran de réglages coûte peu à mettre en place — un appel API mis en cache et un affichage conditionnel — mais change concrètement le réflexe de l'équipe de support, qui n'a plus besoin d'ouvrir un outil externe pour un diagnostic de premier niveau. La configuration de Sentry, elle, reste entièrement du ressort de l'équipe technique.