Il y a un problème récurrent quand on travaille avec un assistant IA sur du débogage : l'IA ne sait pas ce qui se passe en production. Elle peut lire le code, analyser une stack trace qu'on lui colle dans le chat, suggérer des pistes — mais elle travaille à l'aveugle. Sans accès aux erreurs réelles, aux logs, aux événements qui se sont produits dans l'environnement d'exécution, elle fait des suppositions.
Ce n'est pas une limite du modèle. C'est une limite d'accès aux outils.
C'est précisément ce problème que MCP vient résoudre. Et c'est ce qui m'a amené à intégrer Sentry et GlitchTip directement dans mon workflow IA.
Pourquoi les agents IA ont besoin d'accéder aux outils d'observabilité
Quand un bug apparaît en production, le contexte utile ne se limite pas au code source. Il comprend aussi la stack trace exacte, les données de l'événement au moment de l'erreur, le nombre d'occurrences, les environnements touchés, parfois des breadcrumbs qui montrent le chemin parcouru avant l'échec.
Aujourd'hui, ce contexte reste cloisonné dans des outils séparés — Sentry, GlitchTip, Datadog, peu importe. Pour l'obtenir, on ouvre un onglet, on cherche l'erreur, on copie la stack trace, on retourne dans l'éditeur, on la colle dans le chat. C'est un aller-retour manuel qui casse le flux de travail et réduit l'agent IA à un outil de suggestion textuelle plutôt qu'à un vrai collaborateur de débogage.
MCP — Model Context Protocol — change cette équation. Il permet à l'agent IA de se connecter directement à ces outils et d'aller chercher lui-même les informations dont il a besoin. Au lieu de lui donner une stack trace, il peut la lire. Au lieu de lui décrire un comportement anormal, il peut consulter les événements récents et constater par lui-même.
Le bénéfice n'est pas seulement un gain de temps. C'est une amélioration qualitative du raisonnement : l'IA travaille sur des données réelles, pas sur une description approximative que j'en ai faite.
Pourquoi j'ai choisi GlitchTip
Sentry est l'outil de référence pour la surveillance des erreurs. Je l'utilise sur des projets clients qui bénéficient déjà de l'infrastructure SaaS et n'ont pas de contrainte d'hébergement. Mais sur mes propres projets — notamment ce site et plusieurs outils internes — j'avais besoin d'une alternative auto-hébergée.
GlitchTip s'est imposé pour plusieurs raisons. Il est compatible avec l'API Sentry, ce qui signifie que les SDK Sentry existants fonctionnent sans modification. Cette compatibilité est importante : elle évite de choisir entre deux écosystèmes et permet de migrer sans réécriture côté application. GlitchTip se déploie avec Docker en quelques minutes, son interface est sobre et fonctionnelle, et le projet est open source avec une communauté active.
Ce n'est pas un remplacement parfait de Sentry — certaines fonctionnalités avancées n'existent pas dans GlitchTip. Mais pour capturer des erreurs, les organiser par projet et les exposer via MCP à un agent IA, c'est largement suffisant. Et le fait de maîtriser l'hébergement change la donne sur les projets où la confidentialité des données est un sujet.
Pourquoi MCP plutôt qu'une intégration manuelle ?
Avant MCP, j'avais expérimenté différentes approches pour donner du contexte à l'IA : copier-coller de stack traces, scripts pour exporter des erreurs en Markdown, parfois même des prompts système qui décrivaient l'état de l'application. Tout cela fonctionnait, mais avec friction. La qualité des réponses dépendait directement de la qualité et de la complétude du contexte que je fournissais — et ce contexte, c'est moi qui devais le construire.
MCP déplace cette responsabilité. L'agent peut maintenant interroger Sentry ou GlitchTip au moment où il en a besoin, avec les paramètres qu'il juge pertinents. C'est une différence de nature, pas de degré.
Configuration dans Codex
Codex d'OpenAI supporte MCP via un fichier de configuration JSON. Voici la configuration que j'utilise pour Sentry :
{
"mcpServers": {
"sentry": {
"command": "npx",
"args": ["-y", "@sentry/mcp-server@latest"],
"env": {
"SENTRY_AUTH_TOKEN": "votre-token"
}
}
}
}
Le token Sentry doit avoir accès en lecture aux projets concernés. J'évite de créer un token avec des droits d'écriture — l'agent n'a pas besoin de créer ou modifier des issues, seulement de les lire.
Configuration dans Claude Code
Claude Code gère MCP via .claude/settings.json. C'est la configuration que j'utilise au quotidien, à la fois pour Sentry sur les projets clients et pour GlitchTip sur mes projets personnels :
{
"mcpServers": {
"glitchtip": {
"command": "npx",
"args": ["-y", "glitchtip-mcp-server"],
"env": {
"GLITCHTIP_TOKEN": "votre-token",
"GLITCHTIP_URL": "https://votre-instance.glitchtip.com"
}
}
}
}
L'URL pointe vers votre instance auto-hébergée. Si vous utilisez GlitchTip Cloud, l'URL est celle fournie lors de la création du compte.
Configuration dans VS Code
VS Code utilise un fichier .vscode/mcp.json à la racine du projet. La configuration est structurellement identique, seule la clé racine change :
{
"servers": {
"sentry": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@sentry/mcp-server@latest"],
"env": {
"SENTRY_AUTH_TOKEN": "votre-token"
}
}
}
}
Un détail pratique : je préfère utiliser l'auto-discover du projet Sentry plutôt que fixer une organisation en dur dans la configuration. Ça évite d'avoir à maintenir des valeurs spécifiques par projet et ça rend la configuration plus portable.
Limites et points de vigilance
Avant d'adopter cette configuration en production, quelques points méritent attention.
Sécurité des tokens. Les tokens d'API ne doivent jamais apparaître dans un dépôt Git. Pour Claude Code, le fichier .claude/settings.json doit être dans .gitignore dès lors qu'il contient des valeurs sensibles. Préférez utiliser des variables d'environnement ou un gestionnaire de secrets plutôt que des valeurs en clair dans les fichiers de configuration.
Périmètre d'accès. Un agent IA qui peut lire vos erreurs de production a accès à des données potentiellement sensibles : messages d'erreur, paramètres de requêtes, informations utilisateur capturées dans les breadcrumbs. Vérifiez que les données envoyées à Sentry ou GlitchTip ne contiennent pas d'informations personnelles non nécessaires avant d'ouvrir cet accès à un agent.
Gestion des accès partagés. Sur des projets d'équipe, la question de qui peut utiliser quel token MCP se pose rapidement. Il vaut mieux définir une politique claire dès le départ plutôt que de laisser chacun créer ses propres tokens avec des droits hétérogènes.
Surconfiance envers l'IA. C'est peut-être le point le plus important. Donner à l'agent un accès direct aux erreurs de production améliore sa capacité de diagnostic — mais ça ne le rend pas infaillible. Il peut mal interpréter un événement, ignorer un contexte non visible dans les données Sentry, ou proposer un fix qui résout le symptôme sans traiter la cause. L'accès aux outils améliore le raisonnement de l'IA, il ne le remplace pas par du jugement humain.
Ce que j'en retiens
Ce qui m'a le plus frappé dans cette intégration, ce n'est pas la configuration elle-même — elle est relativement simple. C'est le changement de posture que ça induit dans la façon de travailler.
Quand l'agent peut accéder directement aux erreurs, la conversation de débogage change de nature. On ne commence plus par décrire le problème — on commence par demander à l'agent de regarder ce qui s'est passé. Il consulte les événements récents, identifie les patterns, pose des questions sur le code concerné. Le flux est plus naturel et les échanges sont plus denses en information utile.
Est-ce que ça remplace le travail de débogage ? Non. Est-ce que ça le change ? Oui, significativement.
L'observabilité n'a pas toujours été perçue comme un outil de développement — plutôt comme un outil d'exploitation ou de SRE. L'intégration via MCP brouille cette frontière. L'erreur de production devient accessible dans le même contexte que le code source, sans changer d'outil et sans perdre le fil de la conversation avec l'agent. C'est une évolution modeste dans la chaîne d'outils, mais elle change la façon dont on pense le cycle développement-déploiement-correction.
À mesure que les agents IA s'intègrent davantage dans les workflows de développement, leur capacité à accéder aux bons outils au bon moment deviendra aussi importante que leur capacité à raisonner sur le code. MCP est une première réponse sérieuse à ce besoin. Ce n'est probablement pas la dernière.