Que se passe-t-il après la mise en ligne de votre frontend ? Une surveillance qui fonctionne vraiment
Vous venez de déployer une nouvelle version de votre frontend. Le build est passé, le déploiement terminé, et le CDN sert le dernier bundle. Mais cinq minutes plus tard, un utilisateur en Asie du Sud-Est signale que le bouton de paiement ne fait rien quand on clique dessus. Vos logs serveur n'affichent aucune erreur. Votre API répond correctement. Le problème est invisible depuis votre côté.
Voilà la réalité de la surveillance frontend. Contrairement aux services backend où vous pouvez vérifier l'état des processus, l'utilisation CPU ou les logs de requêtes, votre frontend s'exécute sur des appareils que vous ne contrôlez pas. Différents navigateurs, systèmes d'exploitation, conditions réseau, et même des bloqueurs de publicités peuvent faire que votre code se comporte différemment pour chaque utilisateur. Si vous ne surveillez que vos serveurs, vous volez à l'aveugle.
Pourquoi la surveillance serveur ne suffit pas pour le frontend
Quand votre backend tombe, vous le voyez immédiatement. Le processus s'arrête, le port se ferme, ou le taux d'erreur grimpe dans vos logs. Vous recevez une alerte, vous enquêtez, vous corrigez.
Les pannes frontend sont différentes. Votre JavaScript peut lever une exception uniquement sur Safari 15 sur un vieil iPhone avec une connexion lente. Vos appels API peuvent réussir, mais la logique de rendu échoue silencieusement parce qu'un script tiers n'a pas pu se charger. L'utilisateur voit une page blanche ou un spinner bloqué, mais votre serveur n'a aucune idée que quelque chose s'est mal passé.
Ce fossé signifie que vous avez besoin d'une stratégie de surveillance différente pour le frontend. Vous devez voir ce que vos utilisateurs vivent réellement dans leurs navigateurs, pas seulement ce que votre infrastructure rapporte.
Le taux d'erreur dans le navigateur : le premier signal
La métrique la plus importante à suivre après une release frontend est le taux d'erreur JavaScript dans le navigateur. Il ne s'agit pas d'erreurs API ou d'exceptions côté serveur. Ce sont des erreurs qui se produisent dans votre code s'exécutant sur l'appareil de l'utilisateur.
Les exemples courants incluent :
- Une fonction qui utilise une API navigateur non disponible dans les versions plus anciennes
- Une bibliothèque qui ne parvient pas à se charger parce que le réseau de l'utilisateur a chuté
- Une erreur de référence null parce qu'une réponse API n'incluait pas un champ attendu
- Une erreur de syntaxe introduite lors du build qui n'apparaît que dans certaines configurations de minification
Pour capturer ces erreurs, vous avez besoin d'un outil de Real User Monitoring (RUM) qui collecte les exceptions, les traces de pile, et le contexte navigateur des utilisateurs réels. Des outils comme Sentry, Datadog RUM, ou New Relic Browser fonctionnent en ajoutant un petit script à votre page qui intercepte les erreurs non gérées et les envoie à un collecteur central.
Voici un exemple minimal de configuration d'un gestionnaire d'erreurs global et de capture des performances de chargement de page dans votre application :
// Gestionnaire d'erreurs global pour les exceptions non capturées
window.onerror = function (message, source, lineno, colno, error) {
const errorData = {
message: message,
source: source,
line: lineno,
column: colno,
stack: error ? error.stack : null,
url: window.location.href,
userAgent: navigator.userAgent
};
// Envoyer les données d'erreur à votre endpoint de surveillance
fetch('/api/log-error', {
method: 'POST',
body: JSON.stringify(errorData),
headers: { 'Content-Type': 'application/json' }
});
};
// Capturer les performances de chargement de page
window.addEventListener('load', function () {
const perfData = window.performance.timing;
const pageLoadTime = perfData.loadEventEnd - perfData.navigationStart;
console.log('Temps de chargement de la page (ms) :', pageLoadTime);
// Envoyer au service de surveillance
fetch('/api/log-performance', {
method: 'POST',
body: JSON.stringify({ loadTime: pageLoadTime, url: window.location.href }),
headers: { 'Content-Type': 'application/json' }
});
});
La clé est de configurer des alertes basées sur les variations du taux d'erreur. Si votre taux d'erreur passe de 0,1 % à 2 % immédiatement après une release, quelque chose ne va pas. Vous n'avez pas besoin d'attendre que les utilisateurs se plaignent. Les données vous le disent avant que les plaintes ne s'accumulent.
Temps de chargement de la page : ce que les utilisateurs ressentent vraiment
Votre temps de build et votre vitesse de déploiement n'ont pas d'importance pour vos utilisateurs. Ce qui compte, c'est la rapidité avec laquelle la page apparaît sur leur écran. Un frontend lent éloigne les utilisateurs, nuit aux taux de conversion, et endommage la réputation de votre produit.
Le temps de chargement de la page dépend de plusieurs facteurs :
- La taille de vos bundles JavaScript
- Le nombre de requêtes réseau effectuées par votre page
- La vitesse et la latence du réseau de l'utilisateur
- La puissance de traitement de l'appareil
- La façon dont votre code gère le rendu et l'interactivité
Les outils RUM peuvent vous montrer la distribution des temps de chargement sur l'ensemble de votre base d'utilisateurs. Vous pourriez voir que les utilisateurs d'une région subissent des temps de chargement de 3 secondes tandis que ceux d'une autre région attendent 8 secondes. Ou que les utilisateurs mobiles sur réseau 3G ont une expérience complètement différente de celle des utilisateurs de bureau sur fibre.
Après une release, comparez la distribution des temps de chargement avant et après. Si le temps de chargement médian a augmenté de 500 millisecondes, c'est une régression. Même si la fonctionnalité fonctionne correctement, l'expérience utilisateur s'est dégradée.
Interaction utilisateur : le bouton a-t-il vraiment fonctionné ?
Les taux d'erreur et les temps de chargement vous renseignent sur la santé technique, mais ils ne vous disent pas si les utilisateurs peuvent accomplir leurs tâches. Une page peut se charger sans erreur mais avoir un formulaire de soumission cassé ou une barre de recherche non fonctionnelle.
C'est là qu'intervient la surveillance synthétique. Vous écrivez des scripts automatisés qui simulent un parcours utilisateur dans votre application. Le script clique sur des boutons, remplit des formulaires, navigue entre les pages, et vérifie que chaque étape se termine avec succès.
Par exemple, un test synthétique pour un site e-commerce pourrait :
- Charger la page d'accueil
- Rechercher un produit
- Ajouter le produit au panier
- Passer à la caisse
- Remplir les détails de livraison
- Soumettre la commande
- Vérifier que la page de confirmation de commande apparaît
Exécutez ces tests après chaque déploiement. Si un test échoue à l'étape de paiement, vous savez que quelque chose s'est cassé dans ce flux. Vous pouvez enquêter avant que de vrais utilisateurs ne rencontrent le problème.
La surveillance synthétique ne remplace pas le RUM. Elle offre des vérifications contrôlées et reproductibles, mais ne capture pas toute la variété des environnements utilisateur réels. Utilisez les deux ensemble.
Intégrer la surveillance dans votre pipeline
La surveillance ne devrait pas être une activité séparée qui a lieu après le déploiement. Elle devrait faire partie de votre pipeline de déploiement lui-même.
Voici une séquence pratique :
- Déployer la nouvelle version frontend en production
- Attendre la propagation du CDN (généralement quelques minutes)
- Exécuter un ensemble de tests synthétiques sur les URLs de production en direct
- Attendre cinq à dix minutes pour que les données RUM s'accumulent depuis les utilisateurs réels
- Vérifier le taux d'erreur et les métriques de temps de chargement par rapport à vos seuils
- Si une métrique dépasse le seuil, déclencher un rollback automatique ou notifier l'équipe d'astreinte
Cela ne signifie pas que votre pipeline attend des heures de données RUM. La vérification initiale est un test de santé rapide. Si le taux d'erreur grimpe dans les premières minutes, vous le détectez immédiatement. Si les métriques semblent normales, le déploiement est considéré comme sain, et vous pouvez continuer la surveillance passive.
Checklist pratique pour la surveillance des releases frontend
- Installer un outil RUM qui capture les erreurs JavaScript, les temps de chargement et le contexte navigateur
- Configurer des alertes pour les variations du taux d'erreur après chaque déploiement
- Créer des tests synthétiques pour vos parcours utilisateur critiques
- Exécuter les tests synthétiques automatiquement après chaque déploiement
- Définir des seuils acceptables pour le taux d'erreur et le temps de chargement
- Configurer un rollback automatique ou une notification lorsque les seuils sont dépassés
- Examiner régulièrement les données de surveillance pour repérer les tendances, pas seulement les incidents
Ce qu'il faut retenir
Votre frontend s'exécute sur des appareils qui ne vous appartiennent pas, dans des environnements que vous ne contrôlez pas. Les logs serveur ne vous diront pas quand un bouton cesse de fonctionner ou quand une page se charge trop lentement. Le Real User Monitoring et les tests synthétiques vous offrent la visibilité nécessaire pour détecter les problèmes avant que vos utilisateurs ne les signalent. Intégrez ces vérifications dans votre pipeline de déploiement, et vous saurez en quelques minutes si une release fonctionne réellement, pas seulement si elle a été déployée avec succès.