Attraper les bugs en vol : surveillance et journalisation des applications JavaScript

Pourquoi votre code JavaScript crie-t-il à l'aide sans que vous l'entendiez ?

Imaginez : vous avez lancé une super application web. Les utilisateurs arrivent, cliquent, tout fonctionne… ou pas ? En réalité, quelque part dans les profondeurs du navigateur, une erreur tombe silencieusement : Uncaught TypeError: Cannot read property 'length' of undefined. L'utilisateur ferme simplement l'onglet et va chez un concurrent, sans que vous sachiez que quelque chose s'est mal passé.

Bienvenue dans la réalité du développement frontend. Sans surveillance et journalisation des applications JavaScript, vous travaillez à l'aveugle. Mais ne vous précipitez pas pour vous prendre la tête — aujourd'hui, nous allons voir comment transformer le chaos des erreurs en un système d'alerte structuré. Vous apprendrez à journaliser correctement les événements, à suivre les performances et à ne pas vous noyer dans un océan de données.

Cet article est votre antisèche pour survivre en production. C'est parti !

Console.log — votre ami ou votre ennemi ?

Commençons par les bases. console.log() est la première chose qui vient à l'esprit de tout développeur. Et c'est normal. Mais si vous l'utilisez dans du code de production, arrêtez-vous. Pourquoi ? Parce que :

\n
• Il encombre la console de l'utilisateur (oui, certains l'ouvrent).
\n
• Il impacte les performances en cas de nombreux appels.
\n
• Il ne fournit pas d'informations structurées.
\n

Utilisez plutôt les niveaux de journalisation. Voici un exemple de bonne approche :

// Mauvais\nconsole.log('User clicked button');\n\n// Bon\nconsole.info('User interaction', { \n    action: 'click', \n    element: '#submit-btn', \n    timestamp: Date.now() \n});\n\n// Pour les erreurs\nconsole.error('API request failed', { \n    status: 500, \n    endpoint: '/api/users' \n});\n\n// Pour les avertissements\nconsole.warn('Deprecated method used', { \n    method: 'fetchData_v1' \n});

Mais même cela n'est que la partie émergée de l'iceberg. La véritable surveillance des applications JavaScript commence là où la console n'est pas accessible.

Journalisation structurée : le JSON à la rescousse

Lorsque votre application grandit, les messages chaotiques dans la console deviennent une bouillie. La solution — la journalisation structurée. Envoyez les données au format JSON pour pouvoir les analyser et les traiter.

Voici comment créer un simple logger :

class Logger {\n    constructor(context = {}) {\n        this.context = context;\n    }\n\n    log(level, message, data = {}) {\n        const logEntry = {\n            timestamp: new Date().toISOString(),\n            level,\n            message,\n            ...this.context,\n            ...data\n        };\n\n        // En production, on envoie au serveur\n        if (process.env.NODE_ENV === 'production') {\n            this.sendToServer(logEntry);\n        } else {\n            // En développement, on affiche dans la console\n            console[level](`[${level.toUpperCase()}] ${message}`, data);\n        }\n    }\n\n    sendToServer(entry) {\n        // Utilisation de sendBeacon pour un envoi garanti\n        navigator.sendBeacon('/api/logs', JSON.stringify(entry));\n    }\n\n    info(message, data) { this.log('info', message, data); }\n    warn(message, data) { this.log('warn', message, data); }\n    error(message, data) { this.log('error', message, data); }\n}\n\n// Utilisation\nconst logger = new Logger({ appVersion: '1.2.3', userId: getUserId() });\nlogger.info('Page loaded', { url: window.location.href, loadTime: performance.now() });

Notez l'utilisation de navigator.sendBeacon() — c'est la meilleure façon d'envoyer des données avant que l'utilisateur ne quitte la page. Les requêtes fetch classiques peuvent être annulées.

Capture des erreurs : try/catch n'est que le début

Les erreurs globales sont les plus sournoises. Elles peuvent survenir n'importe où et sont faciles à manquer. Voici comment configurer une surveillance totale des erreurs JavaScript :

Gestionnaire d'erreurs global

// Intercepter les erreurs non gérées\nw