Surveillance des Erreurs (Error Monitoring) : Identifier et Résoudre les Problèmes en Production

Bienvenue dans cette leçon cruciale de notre parcours sur l'observabilité frontend. Après avoir exploré les bases du débogage et l'importance de la performance, nous allons nous attaquer à un pilier fondamental de l'expérience utilisateur en production : la Surveillance des Erreurs ou Error Monitoring.

En production, les choses peuvent toujours mal tourner. Un appel API échoue, une interaction utilisateur déclenche un bug inattendu, une ressource critique ne se charge pas. Sans un système de surveillance robuste, ces problèmes restent invisibles pour vous et votre équipe, ne se manifestant que par des plaintes d'utilisateurs frustrés, une baisse de l'engagement ou, pire encore, une perte de revenus.

Dans cette leçon, nous allons découvrir comment non seulement détecter ces erreurs, mais aussi les comprendre, les prioriser et les résoudre efficacement, transformant ainsi les problèmes latents en opportunités d'amélioration continue.

Qu'est-ce que la Surveillance des Erreurs (Error Monitoring) ?

La surveillance des erreurs est le processus systématique de détection, de collecte, de regroupement et d'analyse des erreurs qui surviennent dans une application logicielle, en particulier dans un environnement de production. Pour le frontend, cela signifie traquer tout ce qui peut perturber l'expérience utilisateur dans le navigateur : erreurs JavaScript, échecs de chargement de ressources, problèmes réseau, etc.

Contrairement au débogage local qui se concentre sur la reproduction et la correction d'un bug spécifique dans un environnement contrôlé, la surveillance des erreurs en production vise à :

Détecter proactivement les problèmes que les utilisateurs rencontrent en temps réel.
Comprendre le contexte exact dans lequel ces erreurs se produisent (quel utilisateur, quel navigateur, quelle page, quelle action).
Alerter rapidement les équipes concernées pour minimiser l'impact.
Fournir les informations nécessaires pour reproduire et corriger les bugs sans avoir à demander plus de détails à l'utilisateur.
Mesurer l'impact des erreurs sur l'expérience utilisateur et le fonctionnement de l'application.

En somme, il s'agit de passer d'une approche réactive (attendre que les utilisateurs signalent des problèmes) à une approche proactive, où votre application vous informe elle-même de ses difficultés.

Pourquoi la Surveillance des Erreurs est-elle Indispensable en Production ?

Ignorer les erreurs en production, c'est comme conduire une voiture sans tableau de bord : vous ne saurez qu'il y a un problème que lorsqu'il est trop tard.

Amélioration de l'Expérience Utilisateur (UX) : Les erreurs sont des points de friction majeurs. Un utilisateur qui rencontre un bug peut ne plus revenir. En détectant et corrigeant rapidement les erreurs, vous assurez une expérience fluide et fiable, renforçant la confiance et la satisfaction.
Protection du Chiffre d'Affaires et de la Réputation : Pour les applications e-commerce ou SaaS, une erreur sur le tunnel de commande ou sur une fonctionnalité clé peut avoir un impact direct et significatif sur les revenus. Une application instable nuit également gravement à la réputation de votre marque.
Détection Précoce et Correction Rapide : Plus vite une erreur est détectée, plus vite elle peut être corrigée. Une surveillance efficace permet souvent de corriger un problème avant même qu'un grand nombre d'utilisateurs ne le rencontrent ou ne le signalent.
Visibilité sur les Problèmes Réels : Vos tests unitaires et d'intégration couvrent une grande partie de votre code, mais l'environnement de production est unique. Les interactions imprévues, les variations de navigateur, les extensions tierces ou les conditions réseau instables peuvent révéler des bugs impossibles à reproduire en développement.
Priorisation des Correctifs : Un système de surveillance des erreurs ne se contente pas de lister les erreurs, il les regroupe, compte leur fréquence et identifie leur impact. Cela permet aux équipes de prioriser les bugs qui affectent le plus grand nombre d'utilisateurs ou les fonctionnalités les plus critiques.
Optimisation des Ressources de Développement : Au lieu de passer du temps à tenter de reproduire un bug signalé vaguement par un utilisateur, les développeurs disposent d'une stack trace complète et du contexte, ce qui accélère considérablement le processus de débogage.

Types d'Erreurs à Surveiller en Frontend

Le paysage des erreurs frontend est vaste. Voici les catégories principales à considérer :

Erreurs JavaScript (Uncaught Exceptions) : Ce sont les erreurs les plus courantes et souvent les plus critiques. Elles peuvent survenir à tout moment et interrompre l'exécution de votre code.
- ReferenceError : Tentative d'accès à une variable non définie.
- TypeError : Opération effectuée sur une valeur de type inattendu (ex: appeler une méthode sur undefined).
- SyntaxError : Erreur de grammaire dans le code (généralement détectée à la compilation, mais peut arriver avec du code généré dynamiquement).
- RangeError : Une valeur numérique est en dehors de l'intervalle autorisé.
- URIError : Erreur lors de l'encodage ou du décodage d'URI.
- EvalError : Erreur liée à l'utilisation de eval().
- Promesses rejetées non gérées (unhandledrejection) : Une promesse qui est rejetée mais n'a pas de catch() pour gérer l'erreur. Elles sont souvent silencieuses et peuvent masquer des problèmes importants.
Erreurs Réseau : Échecs lors des requêtes HTTP (API, chargement de ressources).
- Codes de statut HTTP 4xx (Client Error) ou 5xx (Server Error).
- Échecs de connexion réseau (perte de connectivité).
- CORS errors (Cross-Origin Resource Sharing).
Erreurs de Ressources : Échecs de chargement d'éléments statiques.
- Images (<img>), feuilles de style (<link rel="stylesheet">), scripts (<script>) introuvables ou corrompus.
- Fichiers WebFont non chargés.
Erreurs d'Interface Utilisateur (UI) / Erreurs de Rendu : Des erreurs qui ne sont pas forcément des exceptions JS, mais qui perturbent l'affichage ou l'interactivité.
- Composants qui ne se rendent pas correctement.
- Interactions utilisateur qui ne déclenchent pas le comportement attendu.
- Note : Ces erreurs sont souvent plus difficiles à détecter automatiquement et nécessitent parfois une instrumentation plus spécifique ou des tests de régression visuelle.
Erreurs de Sécurité :
- Violations de la Content Security Policy (CSP).
- Tentatives d'injection XSS.

Comment Mettre en Place la Surveillance des Erreurs ?

Il existe deux approches principales pour surveiller les erreurs : manuellement (pour les cas simples ou spécifiques) et via des services dédiés (recommandé pour la production).

Capturer les Erreurs JavaScript : `window.onerror` et `unhandledrejection`

Le navigateur fournit des mécanismes natifs pour intercepter les erreurs JavaScript globales.

`window.onerror`

Cet événement est déclenché chaque fois qu'une exception non gérée (uncaught exception) se produit dans le code JavaScript de la page. Il est le point d'entrée principal pour la surveillance des erreurs synchrone.

// Attachement d'un gestionnaire d'événements global pour les erreurs
window.onerror = function (message, source, lineno, colno, error) {
    console.group("Erreur JS interceptée (window.onerror)");
    console.error("Message :", message);
    console.error("Source :", source);
    console.error("Ligne :", lineno);
    console.error("Colonne :", colno);
    console.error("Objet Erreur :", error); // L'objet Error lui-même, très utile pour la stack trace

    // Ici, vous enverriez ces informations à votre service de surveillance d'erreurs
    // ou à une API de journalisation.

    console.groupEnd();

    // Retourner true pour indiquer que l'erreur a été "gérée"
    // et empêcher le navigateur de logger l'erreur dans la console ou de déclencher d'autres actions.
    // En production, il est souvent préférable de retourner false pour que l'erreur reste visible dans la console du développeur.
    return false;
};

// Exemple de code provoquant une erreur pour démonstration
function provoqueErreur() {
    console.log("Tentative de provoquer une ReferenceError...");
    nonDeclaree.methode(); // `nonDeclaree` n'existe pas
}

// Appelez la fonction pour voir l'erreur dans la console et dans le gestionnaire
// setTimeout(provoqueErreur, 1000); // Décommenter pour tester

Explication du code :

Nous assignons une fonction à window.onerror. Cette fonction reçoit cinq arguments :
- message: Le message d'erreur (ex: "Uncaught ReferenceError: nonDeclaree is not defined").
- source: L'URL du script où l'erreur s'est produite.
- lineno: Le numéro de ligne.
- colno: Le numéro de colonne.
- error: L'objet Error lui-même, qui contient souvent une stack trace très précieuse pour le débogage.
À l'intérieur de cette fonction, vous pouvez traiter l'erreur : l'afficher, l'envoyer à un service externe, etc.
Le fait de retourner true ou false depuis window.onerror est important. true signifie que vous avez géré l'erreur et que le navigateur ne doit pas la logger davantage. false (ou ne rien retourner) signifie que l'erreur n'a pas été entièrement gérée et qu'elle doit être traitée par le mécanisme par défaut du navigateur (affichage dans la console, etc.). En général, il est préférable de laisser le navigateur logger l'erreur (return false) pour avoir une trace complète partout.

`unhandledrejection`

Les promesses JavaScript non gérées (c'est-à-dire une promesse qui rejette sans que son .catch() ne soit appelé) ne sont pas interceptées par window.onerror. Pour ces cas, il faut utiliser l'événement unhandledrejection.

window.addEventListener('unhandledrejection', function (event) {
    console.group("Rejet de Promesse non géré (unhandledrejection)");
    console.error("Raison du rejet :", event.reason); // L'erreur ou la valeur avec laquelle la promesse a été rejetée

    // Ici, vous enverriez `event.reason` à votre service de surveillance d'erreurs.

    event.preventDefault(); // Empêche l'affichage par défaut de l'erreur dans la console (optionnel)
    console.groupEnd();
});

// Exemple de promesse qui rejette sans être gérée
function provoqueRejetPromesse() {
    console.log("Tentative de provoquer un rejet de promesse non géré...");
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            reject(new Error("Quelque chose a mal tourné dans la promesse !"));
        }, 500);
    });
}

// Appelez la fonction pour voir le rejet dans le gestionnaire
// provoqueRejetPromesse(); // Décommenter pour tester

Explication du code :

Nous attachons un écouteur d'événements à window pour l'événement unhandledrejection.
L'objet event contient une propriété reason qui est l'objet Error ou la valeur avec laquelle la promesse a été rejetée.
event.preventDefault() peut être utilisé pour empêcher l'affichage de l'erreur par le navigateur, mais, comme pour window.onerror, il est souvent préférable de le laisser commenter en développement.

Utiliser un Service de Surveillance des Erreurs (Error Monitoring Service - EMS)

Bien que window.onerror et unhandledrejection soient utiles, gérer toutes les subtilités de la collecte, du regroupement, du stockage et de l'analyse des erreurs à grande échelle est complexe. C'est là qu'interviennent les Services de Surveillance des Erreurs (EMS).

Ces services sont des plateformes tierces conçues spécifiquement pour :

Collecter automatiquement les erreurs JS, les rejets de promesses, et parfois les erreurs réseau/ressources.
Regrouper les erreurs similaires pour éviter la surcharge d'informations.
Fournir un contexte riche : stack traces complètes, informations sur l'utilisateur, le navigateur, le système d'exploitation, l'URL, les "fils d'Ariane" (breadcrumbs) des actions utilisateur avant l'erreur.
Offrir des alertes et notifications configurables (Slack, email, SMS, etc.).
S'intégrer avec les outils de développement (GitHub, Jira, etc.).
Permettre le suivi des versions pour savoir quand une erreur a été introduite ou corrigée.
Analyser l'impact des erreurs (nombre d'utilisateurs affectés, taux d'erreur).

Exemples de Services de Surveillance des Erreurs populaires :

Sentry: Très populaire, offre une version gratuite généreuse et de puissantes fonctionnalités.
Bugsnag: Similaire à Sentry, avec des fonctionnalités d'alerte et de diagnostic robustes.
Datadog (RUM - Real User Monitoring): Fait partie d'une suite d'observabilité plus large, incluant APM, logs, etc.
Rollbar: Un autre acteur majeur avec de bonnes intégrations.
LogRocket: Combine la surveillance des erreurs avec l'enregistrement de sessions utilisateur, permettant de "rejouer" l'expérience exacte d'un utilisateur ayant rencontré une erreur.

Implémentation d'un EMS (Exemple avec Sentry)

L'intégration d'un EMS se fait généralement via l'installation d'un SDK (Software Development Kit) fourni par le service.

// Importez le SDK de Sentry (ou tout autre EMS)
// Si vous utilisez un bundler comme Webpack/Rollup/Vite
import * as Sentry from "@sentry/browser";
import { Integrations } from "@sentry/tracing"; // Pour des fonctionnalités de tracing additionnelles

// Ou via un script CDN dans votre HTML pour des projets plus simples
/*
<script
  src="https://browser.sentry-cdn.com/7.x.x/bundle.min.js"
  integrity="sha384-..."
  crossorigin="anonymous"
></script>
*/

// Initialisation de Sentry au démarrage de votre application
Sentry.init({
    // Votre DSN (Data Source Name) unique fourni par Sentry
    dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
    
    // Définir le nom de l'environnement (développement, staging, production)
    environment: "production", 

    // Définir la version de votre application (très utile pour suivre les régressions)
    release: "mon-app@1.0.0", 

    // Niveau d'échantillonnage des performances (0.0 à 1.0)
    tracesSampleRate: 0.1, 

    // Intégrations optionnelles pour le tracing et d'autres fonctionnalités
    integrations: [
        new Integrations.BrowserTracing({
            routingInstrumentation: Sentry.reactRouterV6Instrumentation, // Exemple pour React Router v6
            // ... autres options de tracing
        }),
    ],

    // Permet d'ignorer certaines erreurs (ex: celles de certains plugins tiers connus)
    ignoreErrors: [
        "ResizeObserver loop limit exceeded",
        "Network Error", // Sentry gère déjà mieux ça, mais comme exemple
    ],

    // Fonction pour filtrer les événements avant de les envoyer à Sentry
    beforeSend(event, hint) {
        // Optionnel : modifier ou filtrer l'événement.
        // Par exemple, anonymiser certaines données ou ignorer des erreurs spécifiques
        // si elles viennent d'utilisateurs testeurs.
        if (event.user && event.user.email === 'test@example.com') {
            return null; // N'envoie pas cet événement
        }
        return event; // Envoie l'événement
    },
});

// ---------- Utilisation de Sentry dans votre code ----------

// 1. Capturer manuellement une exception (par exemple, dans un bloc try...catch)
try {
    throw new Error("Ceci est une erreur forcée dans un try...catch.");
} catch (e) {
    Sentry.captureException(e);
    console.error("Erreur capturée manuellement par Sentry:", e);
}

// 2. Ajouter des informations contextuelles sur l'utilisateur
Sentry.setUser({
    id: "user-123",
    email: "john.doe@example.com",
    username: "john.doe",
});

// 3. Ajouter des informations contextuelles sur la page/composant
Sentry.setContext("checkout_process", {
    step: "shipping",
    cart_items: 3,
    total_price: 120.50,
});

// 4. Ajouter des "breadcrumbs" (fils d'Ariane) - Sentry le fait souvent automatiquement pour les clics
Sentry.addBreadcrumb({
    category: "navigation",
    message: "Navigated to /products",
    level: "info",
});

// 5. Simuler une erreur JavaScript non gérée (sera automatiquement capturée par Sentry)
// const maVariableNonDefinie = undefined;
// maVariableNonDefinie.prop = 123; // Décommenter pour tester une ReferenceError

// 6. Simuler un rejet de promesse non géré (sera automatiquement capturé par Sentry)
// Promise.reject(new Error("Erreur de promesse non gérée !")); // Décommenter pour tester

Explication du code :

Sentry.init({...}) : C'est la fonction d'initialisation principale.
- dsn: C'est votre clé unique fournie par Sentry qui indique où envoyer les erreurs.
- environment: Permet de distinguer les erreurs venant de différentes étapes de votre CI/CD (dev, staging, production).
- release: Une version spécifique de votre application. C'est essentiel pour savoir si une erreur a été introduite par la dernière mise à jour ou si elle existait déjà.
- tracesSampleRate: Pour la surveillance des performances (Performance Monitoring), il définit le pourcentage de transactions à échantillonner.
- integrations: Permet d'ajouter des fonctionnalités supplémentaires, comme le tracing distribué pour suivre les requêtes à travers les microservices ou des instrumentations spécifiques pour des frameworks (React, Angular, Vue, etc.).
- ignoreErrors: Une liste de messages d'erreur à ignorer. Utile pour filtrer les erreurs connues qui ne sont pas de votre ressort (ex: certaines erreurs de navigateur ou d'extensions).
- beforeSend: Une fonction de rappel qui vous permet d'inspecter et de modifier l'événement d'erreur avant qu'il ne soit envoyé à Sentry. Vous pouvez l'utiliser pour ajouter des informations personnalisées, anonymiser des données sensibles ou même annuler l'envoi de certains événements.
Sentry.captureException(e) : Utilisé pour envoyer manuellement un objet Error à Sentry, généralement dans un bloc try...catch où vous gérez déjà une exception.
Sentry.setUser({...}) : Permet d'associer les erreurs à un utilisateur spécifique (par exemple, son ID, son email). C'est extrêmement utile pour contacter les utilisateurs affectés ou comprendre l'impact sur des segments d'utilisateurs.
Sentry.setContext("clé", { ... }) : Ajoute des données contextuelles supplémentaires qui peuvent aider au débogage. Par exemple, l'état d'un composant, des paramètres de session, etc.
Sentry.addBreadcrumb({...}) : Ajoute une trace des actions précédentes de l'utilisateur. La plupart des EMS instrumentent automatiquement les clics, les changements d'URL, les requêtes XHR/fetch, mais vous pouvez en ajouter manuellement pour des actions métier spécifiques.

Capture des Erreurs Réseau (fetch/XHR)

La plupart des EMS modernes, via leurs SDK, instrumentent automatiquement les requêtes fetch et XMLHttpRequest pour capturer les échecs réseau (codes de statut 4xx/5xx, erreurs de timeout, etc.). Cela se fait généralement via une intégration spécifique dans le SDK (comme BrowserTracing de Sentry). Si vous n'utilisez pas un EMS, vous devrez intercepter ces requêtes manuellement en enveloppant fetch ou en écoutant les événements XHR.

Bonnes Pratiques pour une Surveillance des Erreurs Efficace

Une surveillance des erreurs mal configurée peut être pire que pas de surveillance du tout, vous noyant sous un déluge d'alertes inutiles.

Le Contexte est Roi : Une erreur sans contexte est presque impossible à déboguer. Assurez-vous que votre EMS capture :
- La stack trace complète et non "minifiée".
- L'URL de la page.
- Le navigateur et le système d'exploitation de l'utilisateur.
- L'utilisateur concerné (ID, email si possible et anonymisé).
- Les breadcrumbs (historique des actions utilisateur).
- Les variables d'état pertinentes au moment de l'erreur.
- Les paramètres d'API ayant pu déclencher l'erreur.
Gestion des Données Sensibles : Soyez extrêmement vigilant avec les données personnelles ou sensibles. Anonymisez, nettoyez ou ne collectez pas d'informations comme les mots de passe, numéros de carte bancaire, etc. La plupart des EMS offrent des options pour sanitiser (nettoyer) les données.
Déduplication et Regroupement Intelligent : Un bon EMS regroupe des milliers d'occurrences de la même erreur en un seul "problème". Configurez-le pour qu'il le fasse efficacement.
Alertes Configurées avec Soin :
- Évitez les fausses alertes ou le bruit. Une alerte doit signifier qu'il y a un vrai problème nécessitant une action.
- Définissez des seuils pertinents (ex: "plus de 100 erreurs identiques en 5 minutes", "erreur affectant plus de 5% des utilisateurs", "nouvelle erreur critique détectée").
- Dirigez les alertes vers les bonnes personnes/équipes (canaux Slack dédiés, listes de diffusion).
Intégration au Workflow de Développement :
- Créez automatiquement des tickets Jira, GitHub Issues ou Trello à partir des erreurs critiques.
- Marquez les erreurs comme "résolues" et vérifiez qu'elles ne réapparaissent pas dans les nouvelles versions.
- Utilisez le suivi de version (release dans Sentry) pour lier les erreurs à des déploiements spécifiques.
Testez votre Système de Surveillance : Ne supposez pas qu'il fonctionne. Provoquez intentionnellement des erreurs en développement et en staging pour vérifier que votre EMS les capture correctement et que les alertes se déclenchent.

Défis et Pièges Courants

Le Bruit : Trop d'erreurs (souvent des erreurs tierces ou mineures) peuvent noyer les erreurs importantes. Une bonne configuration des filtres et des ignorances est cruciale.
Manque de Contexte : Une erreur signalée sans stack trace ou sans informations sur l'utilisateur est quasiment inutilisable.
Impact sur la Performance : L'envoi d'erreurs au serveur peut avoir un coût en performance réseau. Les SDK des EMS sont optimisés, mais une mauvaise configuration (ex: envoi d'événements trop volumineux, trop fréquents) peut nuire.
Gestion des Erreurs Tiers : Les scripts de pub, les SDK d'analyse, etc., peuvent générer leurs propres erreurs. Décidez si vous devez les surveiller ou les ignorer.
Coût des Services : Les EMS ont un coût, souvent basé sur le volume d'événements. Il faut trouver le bon équilibre entre la granularité de la surveillance et le budget.

Conclusion

La surveillance des erreurs est bien plus qu'une simple fonctionnalité technique ; c'est un investissement direct dans la qualité de votre produit et la satisfaction de vos utilisateurs. En mettant en place un système robuste, vous transformez les problèmes potentiels en informations exploitables, permettant à votre équipe de réagir rapidement, de prioriser efficacement et, in fine, de livrer une application plus stable et plus fiable.

En adoptant les bonnes pratiques et en tirant parti des puissants services de surveillance disponibles, vous ne vous contenterez pas de réagir aux problèmes, vous les préviendrez, vous les détecterez et vous les résoudrez avant même qu'ils n'impactent négativement votre expérience utilisateur ou votre activité. C'est une composante indispensable de toute stratégie d'observabilité frontend mature.

Surveillance des Erreurs (Error Monitoring) : Identifier et Résoudre les Problèmes en Production

Qu'est-ce que la Surveillance des Erreurs (Error Monitoring) ?

Pourquoi la Surveillance des Erreurs est-elle Indispensable en Production ?

Types d'Erreurs à Surveiller en Frontend

Comment Mettre en Place la Surveillance des Erreurs ?

Capturer les Erreurs JavaScript : window.onerror et unhandledrejection

window.onerror

unhandledrejection

Utiliser un Service de Surveillance des Erreurs (Error Monitoring Service - EMS)

Implémentation d'un EMS (Exemple avec Sentry)

Capture des Erreurs Réseau (fetch/XHR)

Bonnes Pratiques pour une Surveillance des Erreurs Efficace

Défis et Pièges Courants

Conclusion

Capturer les Erreurs JavaScript : `window.onerror` et `unhandledrejection`

`window.onerror`

`unhandledrejection`