Un suivi d’erreur utile relie le message vu par l’utilisateur à une opération, une version et un identifiant de diagnostic sans exposer ses données.
Un support ne peut pas agir sur une capture d’écran qui dit seulement « échec ». Le logiciel doit afficher une explication adaptée et produire un événement technique exploitable. Ces deux contenus ne sont pas identiques : le premier aide l’utilisateur, le second aide l’équipe.
Afficher un message actionnable
Indiquez ce que l’utilisateur peut faire maintenant. Il peut corriger un champ, réessayer, attendre un traitement ou contacter le support. Ne promettez pas une résolution automatique si aucune reprise n’est prévue.
Les erreurs d’autorisation doivent rester neutres lorsque l’existence d’une donnée est confidentielle. Les erreurs de réseau peuvent proposer une nouvelle tentative. Une demande déjà traitée doit afficher son état au lieu de créer une seconde opération.
Conserver le contexte
Associez chaque erreur à une opération et à un identifiant de corrélation. Conservez la version du logiciel, le service concerné, le résultat et la durée. Évitez les mots de passe, jetons et contenus complets de formulaires.
Le journal d’audit et les logs techniques ont des objectifs différents. L’audit décrit une décision métier, tandis que le log explique une exécution. Les deux doivent appliquer des règles d’accès.
Classer et suivre
Un niveau d’erreur doit correspondre à une action. Une panne bloquante mérite une alerte, un rejet de fichier peut produire un rapport, une anomalie de présentation peut rejoindre une file de correction. Chaque catégorie doit avoir un propriétaire.
Suivez la fréquence, le taux de reprise et le temps avant résolution. Les erreurs répétées avec des messages différents peuvent représenter un même défaut. Les indicateurs doivent aider une décision de support, pas seulement remplir un tableau.
Sources : OpenTelemetry, instrumentation, OWASP, journalisation.