Le crash silencieux

Dans le développement backend, la gestion des erreurs est simple. Si votre serveur Node.js plante, les journaux dans stderr crient FATAL ERROR. Le contrôle de santé (ping) échoue. Kubernetes redémarre le pod. Le téléavertisseur (PagerDuty) sonne sur votre téléphone. Vous réalisez immédiatement que quelque chose ne va pas.

Dans le développement frontend, les échecs sont silencieux. Imaginez un utilisateur sur votre site e-commerce. Ils ont passé 30 minutes à naviguer. Ils ont 500 € d’articles dans leur panier. Ils cliquent sur « Procéder au paiement ». Le moteur JavaScript rencontre TypeError : Impossible de lire les propriétés non définies (lecture de 'prix'). Ce qui se produit? L’écran n’explose pas. Le navigateur ne se ferme pas. L’interface utilisateur se fige inévitablement. Le bouton spinner tourne pour toujours. L’utilisateur attend 10 secondes. Ils cliquent à nouveau. Rien. Ils soupirent, ferment l’onglet et se rendent sur Amazon. Vous (le développeur) n’avez aucune connaissance que cela s’est produit. Les journaux de votre serveur affichent “200 OK” pour le chargement de la page. Vous supposez que votre logiciel est parfait. En réalité, vous perdez des milliers de dollars par heure.

C’est ce qu’on appelle Flying Blind. Error Monitoring (Sentry, Datadog, LogRocket) est la solution. Il installe un « Black Box Recorder » (SDK) dans le navigateur de chaque utilisateur. Lorsqu’un crash se produit, il capture l’état, l’envoie au cloud et vous alerte.

Pourquoi Maison Code en parle

Chez Maison Code, nous pensons que l’Observation est la première étape de l’Ingénierie. Nous héritons souvent des bases de code de clients qui disent : « Notre taux de conversion a chuté de 20 % et nous ne savons pas pourquoi ». Nous installons Sentry, et en 10 minutes, nous voyons des milliers de « CheckoutError : undefined is not an object » provenant des utilisateurs de Safari. Le bug était toujours là. Le client était tout simplement sourd. Nous mettons en œuvre une surveillance non seulement pour détecter les bugs, mais aussi pour Quantifier la qualité. Nous aidons les CTO à passer de « Je pense que le site est stable » à « Nous avons un taux de session sans plantage de 99,98 % ».

L’outil : Sentinelle

Sentry est la norme industrielle incontestée en matière de surveillance des performances des applications (APM) et de suivi des erreurs. Il prend en charge tous les langages, mais son intégration avec JavaScript/TypeScript est particulièrement puissante. Il ne se contente pas de capturer le message d’erreur ; il capture le Contexte.

Implémentation : Intégration de Sentry dans Next.js

Avant, configurer Sentry était difficile. Maintenant, c’est automatisé.

Le magicien : Exécutez npx @sentry/wizard@latest -i nextjs. Ce scénario est magique.
- Il crée un projet Sentry via API.
- Il met à jour next.config.js pour télécharger les cartes sources.
- Il crée sentry.client.config.ts (navigateur), sentry.server.config.ts (nœud) et sentry.edge.config.ts (Edge Runtime).
Utilisation (SDK) : Sentry se connecte automatiquement aux événements globaux « window.onerror » et « window.onunhandledrejection ». Vous n’avez généralement pas besoin d’encapsuler le code manuellement dans « try/catch ».

Capture manuelle : Parfois, vous souhaitez détecter une erreur (afin que l’application ne plante pas), mais la signaler quand même.

importer * en tant que Sentry depuis "@sentry/nextjs" ;

fonction asynchrone processPayment() {
  essayez {
    attendre stripe.confirmPayment();
  } attraper (erreur) {
    // Connectez-vous à Sentry, mais affichez une interface utilisateur agréable à l'utilisateur
    Sentry.captureException (erreur);
    toast.error("Le paiement a échoué, veuillez réessayer.");
  }
}

Cartes sources : La pierre de Rosette

Le JavaScript de production est Minified et Uglified. Il supprime les espaces, renomme les variables en « a », « b », « c » et élimine le code mort. C’est excellent pour les performances, mais terrible pour le débogage.

L’Horreur :

Erreur : undéfini n'est pas une fonction
  à un (app-123.js:1:432)
  en b (app-123.js:1:890)

Cela ne vous dit rien.

La solution : cartes sources (.js.map). Ces fichiers mappent le code minifié à la source TypeScript d’origine. Lorsque Sentry reçoit un rapport de crash, il recherche la carte source correspondante. Il « déminifie » efficacement la trace de la pile.

Le résultat :

TypeError : user.address n'est pas défini
  à calculateShipping (src/utils/shipping.ts:45:12)
  sur CheckoutForm (src/components/Checkout.tsx:102:4)

Vous savez maintenant exactement que la ligne 45 de « shipping.ts » est la coupable.

Le contexte est roi

Savoir où il s’est écrasé est l’étape 1. Savoir pour qui il s’est écrasé est l’étape 2. Sentry vous permet d’enrichir l’événement d’erreur avec des balises personnalisées et des données utilisateur.

// Dans votre AuthProvider ou Layout
utiliserEffet(() => {
  si (utilisateur) {
    Sentry.setUser({
      identifiant : utilisateur.id,
      email : user.email, // Soyez prudent avec les informations personnelles (RGPD)
      segment : utilisateur.isVIP ? "VIP" : "Standard"
    });
  }
}, [utilisateur]);

Dans Sentry Dashboard, vous pouvez désormais exécuter des requêtes puissantes :

“Montrez-moi tous les plantages affectant les utilisateurs VIP.”
“Montrez-moi tous les crashs sur iOS 17.”

Alerte Fatigue : Le garçon qui criait au loup

Le plus grand danger lié à la surveillance des erreurs est le bruit. Si votre chaîne Slack #alerts-prod envoie un ping toutes les 5 minutes avec “Image Failed to Load”, les développeurs désactiveront la chaîne. Ensuite, lorsque la base de données tombe en panne, personne ne le remarque. Il s’agit de Alerte Fatigue.

Stratégie signal/bruit :

Ignorer les erreurs bénignes : Configurez ignoreErrors dans sentry.client.config.ts (par exemple ResizeObserver loop limit).
Protection des pointes : Ne pas alerter sur une erreur. Alerter si : “Plus de 50 utilisateurs rencontrent cette erreur dans 5 minutes.”

Replay de la session : L’option nucléaire

Parfois, une trace de pile ne suffit pas. “L’utilisateur dit avoir cliqué sur le bouton mais rien ne s’est produit. Aucune erreur enregistrée.” Session Replay (LogRocket / Sentry Replay) enregistre une reproduction de type vidéo de la session de l’utilisateur. Il enregistre les mutations DOM, les mouvements de la souris et les clics. Vous pouvez littéralement regarder l’écran de l’utilisateur. “Ah, ils ont triple-cliqué sur le bouton ‘Retour’ pendant l’ouverture du modal.”

Confidentialité (RGPD/CCPA) : C’est sensible. Vous DEVEZ masquer les champs de saisie (mots de passe, cartes de crédit). Sentry fait cela par défaut (maskAllText : true), transformant le texte en ****. Vérifiez cette configuration manuellement.

7. Traçage des performances (transactions Sentry)

Les erreurs sont des crashs. Les Transactions sont lentes. Sentry retrace l’intégralité du cycle de vie de la demande.

L’utilisateur clique sur “Acheter”.
Navigateur (fetch /api/buy) -> 100 ms.
Serveur Next.js (db.insert commandes) -> 500 ms.
API Stripe (charge) -> 2000 ms. Totale : 2,6 s. Si vous surveillez uniquement les erreurs, vous pensez que tout va bien. Mais 2,6 s est inacceptable. Sentry vous montre la « cascade » de la demande, soulignant que Stripe est le goulot d’étranglement. Correction : n’attendez pas Stripe. Utilisez une file d’attente.

Lorsqu’un crash se produit, Sentry peut automatiquement afficher une boîte de dialogue. “On dirait que nous nous sommes écrasés. Racontez-nous ce qui s’est passé.” Types d’utilisateurs : “J’ai cliqué deux fois sur “Appliquer le coupon”.” C’est de l’or. Il connecte le « Stack Trace » (Technique) avec le « User Intent » (Business). Activez cette option pour que les utilisateurs vérifiés puissent établir des relations.

10. État de sortie : confiance dans le déploiement

Vous déployez la version 2.0. Les erreurs augmentent-elles ou diminuent-elles ? Sentry Release Health suit les « sessions sans crash ». v1.0 : 99,9 % sans crash. v2.0 : 98,0 % sans crash. Cela déclenche une alerte automatique : “Régression détectée dans la v2.0”. Vous pouvez effectuer une restauration instantanée avant que les clients ne se plaignent. C’est la boucle de rétroaction qui permet de « déployer le vendredi ».

11. Sécurité de la carte source

Le téléchargement de cartes sources facilite le débogage. Mais il expose également votre code source au public (si vous le téléchargez sur le CDN). Les concurrents peuvent voler vos algorithmes. Correction : téléchargez les cartes sources vers Sentry Artifacts (privé). Ne téléchargez pas de fichiers « .map » sur votre CDN public. Configurez Sentry pour récupérer des cartes en interne. Vous obtenez désormais des traces complètes, mais le monde voit du code obscurci.

12. Conclusion

Vous ne pouvez pas réparer ce que vous ne pouvez pas voir. La surveillance transforme les erreurs des « Ghost Stories » en « tickets actionnables ». Il vous permet d’appeler un client et de lui dire : “Nous avons remarqué que vous aviez eu une erreur lors du paiement. Nous l’avons corrigée. Voici un coupon de 10 %.” C’est ainsi que l’on transforme un échec en fidélité.

Fatigué du débogage aveugle ?

Si votre équipe passe des heures à rechercher des bugs non reproductibles, Maison Code peut vous aider. Nous mettons en œuvre des piles d’observabilité qui vous offrent une vision aux rayons X dans votre environnement de production.

Voler à l’aveugle ?

Nous intégrons les piles de surveillance Sentry/Datadog avec les cartes sources et l’enrichissement du contexte. Embauchez nos architectes.

Surveillance des erreurs : l'enregistreur Black Box