Le monitoring d'erreurs compte plus quand on est seul

Sans lui, le seul moyen de savoir que quelque chose a cassé en production, c'est un utilisateur qui le signale — s'il s'en donne la peine — et à ce moment-là il n'y a plus de stack trace, plus de contexte de requête, aucune idée de combien d'autres ont silencieusement rencontré la même erreur et abandonné en silence. Sentry attrape les exceptions non gérées au moment où elles arrivent, capture la stack trace plus le contexte environnant — données de requête, infos utilisateur si attachées, breadcrumbs qui y mènent — et le fait remonter immédiatement, souvent avant que quiconque ne signale quoi que ce soit.

Sentry.init({ dsn: SENTRY_DSN, environment: process.env.NODE_ENV });

Ça compte de façon disproportionnée pour un projet solo. Sans équipe qui remarque indépendamment que quelque chose est cassé par l'usage quotidien ou la revue de code, le seul vrai système d'alerte précoce d'un développeur solo est le monitoring actif ou la vérification manuelle des logs — et la vérification manuelle des logs ne se fait pas de façon cohérente. Pour une équipe c'est utile mais un peu redondant avec des yeux humains ; pour un mainteneur solo c'est le filet principal.

Quelques choses qui le rendent utilisable plutôt que bruyant :

• Sentry regroupe les erreurs similaires — même forme, qui se répète — en une seule issue plutôt que d'inonder un canal de mille alertes quasi identiques. Sans ça, les erreurs à haut volume se font ignorer par fatigue d'alerte, ou l'alerting lui-même t'entraîne à cesser de regarder.
• Étiquette chaque erreur avec l'environnement. L'erreur locale d'un développeur, attendue et constante pendant le développement actif, ne devrait pas avoir la même urgence qu'un vrai incident de production. Sans l'étiquette, le bruit du dev et les vraies alertes se brouillent en un seul flux.

Le health check de déploiement vérifie seulement que l'application tourne et répond à /health. Sentry est ce qui attrape « l'application est en marche, mais ce flux est cassé depuis six heures et personne ne l'a remarqué » — un mode de défaillance bien plus courant en pratique que l'application entièrement tombée.

Le suivi d'erreurs a son propre coût — une petite surcharge par requête, et un vrai risque de capturer accidentellement des données sensibles dans le contexte d'une erreur si le scrubbing n'est pas configuré délibérément. Ça vaut la peine de revoir activement ce qui finit dans les charges capturées plutôt que de faire confiance aux défauts du SDK, surtout pour un système qui traite les informations personnelles des gens.