Comment savoir que votre app est en panne ?

Ce que c'est et pourquoi ça compte

Surveiller une app, c'est savoir qu'elle est cassée avant que quelqu'un vous le dise. Sans ça, si le site tombe la nuit, vous le découvrez le matin. Et souvent personne ne vous écrit pour vous le dire : celui qui trouve l'app cassée la ferme, c'est tout.

Pour moi, la surveillance, ce sont trois pièces qui travaillent ensemble :

• Le contrôle de l'extérieur : un service qui ouvre votre adresse toutes les quelques minutes, comme le ferait un utilisateur, et regarde si elle répond.
• Le journal des erreurs : l'endroit où arrive chaque erreur de l'app, avec la stack trace, c'est-à-dire la ligne de code où ça a cassé.
• L'alerte : l'e-mail ou la notification sur le téléphone que vous recevez quand l'un des deux trouve quelque chose.

Le contrôle doit être à l'extérieur de votre app : si l'app est en panne, elle ne peut pas vous le dire elle-même. Le journal des erreurs, lui, vous dit ce qui casse même quand l'app répond.

Et si vous branchez Claude Code sur le journal des erreurs, vous ne partez pas de zéro quand l'alerte se déclenche.

1. Ce que j'utilise

J'utilise deux services. Ce ne sont pas les seuls : avec d'autres, la démarche est la même.

Pour les erreurs : Sentry

Chaque erreur de l'app y arrive avec sa stack trace, et c'est de là que partent les alertes. L'offre gratuite s'appelle Developer : elle est pour un seul utilisateur et envoie les alertes par e-mail.

Pour le contrôle toutes les 5 minutes : UptimeRobot

Il ouvre votre adresse et, si elle ne répond pas, vous prévient par e-mail et par une notification dans l'app du téléphone. Offre gratuite : 50 monitors, contrôle toutes les 5 minutes ; les conditions d'utilisation, vérifiez-les sur leur site.

2. La demi-heure

Ça se fait une seule fois, en une demi-heure environ si l'app est déjà en ligne.

Sentry dans l'app

1. Créez un projet sur Sentry. Il vous montre le DSN, la clé du projet : c'est l'adresse à laquelle votre app envoie ses erreurs. Vous le retrouvez dans les paramètres du projet, sous Client Keys (DSN).
2. Copiez-le et écrivez à Claude Code :

Ajoute Sentry à cette app avec le DSN que je te donne, dans une variable d'environnement et pas dans le code. Ensuite, déclenche une erreur de test et dis-moi comment je vérifie qu'elle est arrivée.

L'erreur de test, c'est ce qui compte : tant que vous ne la voyez pas arriver sur Sentry, vous ne savez pas si ça marche. Ensuite, vérifiez dans les alertes de Sentry qu'il y a une règle pour les nouvelles erreurs.

Une page à contrôler

La page d'accueil se charge parfois même avec la base de données à l'arrêt. C'est pour ça que je donne au contrôle une page dédiée :

Crée une page /health qui répond ok seulement si l'app et la base de données fonctionnent.

Quand quelque chose ne va pas, la page doit répondre avec un code d'erreur. Si elle affiche une page normale où il est écrit « erreur », le contrôle la voit s'ouvrir et pense que tout va bien. Si Claude ne l'a pas déjà fait, j'ajoute :

Si quelque chose ne marche pas, /health doit répondre avec un code d'erreur, genre 503, et ne doit pas afficher de détails internes comme des mots de passe, des adresses de base de données ou des messages d'erreur complets.

Le contrôle toutes les 5 minutes

1. Sur UptimeRobot, créez un nouveau monitor sur [adresse de votre app]/health, avec un contrôle toutes les 5 minutes.
2. Pour les alertes, activez l'e-mail et l'app sur le téléphone, où vous vous connectez avec le même compte.
3. Pour le tester, mettez un instant une mauvaise adresse dans le monitor et regardez si l'alerte vous arrive. Puis remettez la bonne.

Sentry dans Claude Code

Dernière étape : vous branchez Sentry sur Claude Code avec un serveur MCP, pour que Claude puisse lire vos erreurs. Dans le terminal, lancez cette ligne, avec les noms courts de votre organisation et de votre projet sur Sentry à la place de VOTRE-ORG et VOTRE-PROJET :

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/VOTRE-ORG/VOTRE-PROJET

À la première utilisation, il vous fait vous connecter à Sentry depuis le navigateur ; si ça ne se produit pas, tapez /mcp dans Claude Code et choisissez sentry. La connexion ne vaut que dans le projet où vous avez lancé la ligne.

3. Quand l'alerte se déclenche

Quand l'e-mail ou la notification arrive, j'ouvre Claude Code dans le projet et je colle l'alerte dans ce prompt :

J'ai reçu cette alerte : [colle]. Lis l'erreur sur Sentry et les logs, et écris-moi en cinq lignes : ce qui a cassé, depuis quand, pourquoi, et la correction que tu proposes. Ne touche à rien en production tant que je ne t'ai pas dit ok.

Cinq lignes parce qu'à ce moment-là j'ai besoin de comprendre, pas de lire. « Depuis quand » me dit si le dernier déploiement y est pour quelque chose. Et la dernière phrase est la plus importante : avec l'app en panne, on a envie de corriger à la volée, et une mauvaise correction en production peut faire plus de dégâts que l'erreur.

4. Si vous le voulez automatique

L'étape suivante, c'est de ne même plus avoir à coller l'alerte. Il y a deux façons de faire.

Avec une session ouverte : /loop

La façon simple : vous laissez une session Claude Code ouverte, avec Sentry déjà branché, et vous tapez :

/loop 5m regarde sur Sentry s'il y a de nouvelles erreurs ; si oui, lis la stack trace et écris-moi ce qui a cassé et comment tu le réparerais.

Toutes les 5 minutes, Claude regarde Sentry et ne vous écrit que s'il trouve de nouvelles erreurs : ça fait environ 288 passages par jour, alors gardez le prompt court. Ça ne marche qu'avec la session ouverte et l'ordinateur allumé, et au bout de 7 jours le loop s'efface tout seul.

Ordinateur éteint : une routine avec déclencheur API

Une routine dans le cloud tourne même ordinateur éteint, mais avec un horaire elle démarre au maximum une fois par heure. Pour une alerte, mieux vaut le déclencheur API : une adresse web qui lance la routine quand vous l'appelez avec le bon token.

Deux choses à savoir d'abord : les routines demandent une offre Claude payante et sont encore en préversion, donc leur fonctionnement peut changer.

1. Sur claude.ai/code/routines, cliquez sur New routine. Le projet doit être sur GitHub.
2. Ajoutez Sentry comme connecteur sur claude.ai/customize/connectors : la connexion faite avec claude mcp add vit sur votre ordinateur et la routine ne la voit pas. Retirez les connecteurs qui ne servent pas : pendant la routine, Claude les utilise sans demander.
3. Comme déclencheur, choisissez API et enregistrez. Il s'ajoute depuis le site, pas avec /schedule.
4. Copiez l'adresse de la routine, cliquez sur Generate token et copiez le token tout de suite : vous ne le voyez qu'une fois.
5. Dans votre outil d'alertes, configurez un appel à cette adresse avec le token, avec le texte de l'alerte dans le champ text.

La limite : le déclencheur API a besoin du token et de headers précis, que vous trouvez dans l'exemple à côté de l'adresse. Les outils d'alertes gratuits pourraient ne pas réussir à l'appeler, alors vérifiez d'abord sur le vôtre.

Le texte de l'alerte arrive à la routine comme une donnée à lire, pas comme un ordre : dans le prompt, c'est à vous de lui dire d'enquêter. J'utilise celui-ci :

Enquête sur l'alerte décrite dans le bloc routine-fire-payload. Lis l'erreur sur Sentry, regarde les commits récents et écris-moi en cinq lignes : ce qui a cassé, depuis quand, pourquoi, et la correction que tu proposes. Ne touche à rien en production.

La routine tourne sans vous demander de permissions, et vous trouvez le résultat dans la session qu'elle crée à chaque démarrage. C'est pour ça que « Ne touche à rien en production » reste : elle enquête et propose, vous décidez.

Les erreurs les plus courantes

• Ne contrôler que la page d'accueil : elle peut se charger même avec la base de données à l'arrêt, alors faites contrôler /health.
• Une /health qui répond avec une page normale même quand il y a une erreur : faites-lui renvoyer un code d'erreur.
• Ne rien tester : déclenchez l'erreur de test et une fausse alerte, et regardez si elles vous arrivent.
• Laisser Claude corriger en production pendant l'alerte : demandez d'abord le diagnostic et la proposition, puis c'est vous qui décidez.
• Croire que la routine voit le Sentry branché dans le terminal : ajoutez-le comme connecteur sur claude.ai.

Check-list

• Sentry dans l'app, avec le DSN dans une variable d'environnement
• Erreur de test arrivée sur Sentry
• Page /health qui contrôle l'app et la base de données
• Monitor toutes les 5 minutes sur /health, alertes par e-mail et sur le téléphone
• Sentry branché sur Claude Code, connexion faite
• Prompt d'alerte enregistré là où vous le retrouvez tout de suite

Questions fréquentes