Un outil d’erreurs classique te montre dix mille occurrences d’une exception sans conséquence, et l’erreur qui compte — vue douze fois, sur /paiement, par douze personnes qui ont refermé l’onglet — en page trois. Ici, chaque erreur est classée par ce qu’elle a coûté : les visiteurs qui l’ont rencontrée et qui n’ont rien fini ensuite.
Pour chaque erreur : combien de visiteurs distincts l’ont rencontrée sur sept jours, et combien ont quand même déclenché un événement métier ensuite — une commande, une inscription. Les autres sont partis. C’est eux qui classent la liste.
Les identifiants, les URL, les nombres et les numéros de ligne sont effacés avant de grouper : un déploiement déplace les lignes, pas l’erreur. Une seule ligne par erreur réelle, pas dix mille.
Tu marques une erreur résolue. Si elle se reproduit, tu le sais dans la minute : c’est l’alerte la plus utile de toutes, et la seule qui parte dès la première occurrence.
Dans le navigateur, un attribut sur la balise Stats : data-erreurs. Côté serveur, une requête depuis ton gestionnaire d’exception. Pas de SDK, pas de source maps à téléverser.
Ni adresse IP ni identifiant persistant : le visiteur est l’empreinte du jour de Stats, jetée chaque nuit. Une pile d’exemple par groupe, les occurrences trente jours.
Pas de source maps, pas de replay de session, pas de traces distribuées. Si tu as besoin de ça, Sentry le fait très bien. Ce module répond à une seule question : quelle erreur me coûte des clients, aujourd’hui.