Auteur : Nicolas Rouanne

Date : 27 janvier 2026

« Tu peux vérifier ce qui se passe dans Sentry ? »

C'est tout ce que j'ai demandé à Claude Code. Ce qui a suivi était un workflow complet de triage d'incidents—interrogation des issues, catégorisation, et création d'issues GitHub correctement liées—le tout en conversation naturelle.

Voici comment je l'ai configuré et à quoi ressemble le workflow.

Configurer l'accès Sentry pour Claude

Claude Code n'a pas besoin d'un serveur MCP dédié à Sentry. Il lui faut juste l'accès au CLI Sentry et votre token d'authentification.

J'avais déjà mon token dans ~/.sentryclirc :

[auth]
token=sntryu_xxx

Quand j'ai demandé à Claude de vérifier Sentry, il a découvert ce fichier automatiquement et s'est mis au travail. Il a utilisé une combinaison de :

• sentry-cli pour lister les organisations et projets
• Des appels directs à l'API REST pour les requêtes détaillées

# Claude listant mes orgs
sentry-cli organizations list

# Claude interrogeant les détails d'une issue via l'API
curl -H "Authorization: Bearer $TOKEN" \\
  "<https://sentry.io/api/0/projects/samm-care/api/issues/?limit=20>"

Le CLI gère les opérations basiques, mais l'API REST est essentielle pour tout ce qui est analytique—comme obtenir les distributions de tags ou les métadonnées des issues.

Triage des issues

J'ai demandé à Claude d'analyser toutes les issues de notre projet Sentry. Il a interrogé l'API et m'a retourné une liste catégorisée :

Issues de test (du setup initial) :

• ZeroDivisionError: division by zero — l'endpoint de test /sentry-debug
• Error: First error — 10 événements de test