Observabilité d’un logiciel métier : suivre les erreurs que vivent les utilisateurs

L’observabilité relie les journaux, les métriques et les traces aux parcours métier pour expliquer une erreur et mesurer son impact réel.

Un message « une erreur est survenue » ne suffit pas à aider un support. L’équipe doit savoir quelle opération a échoué, pour quel compte, avec quelle version du logiciel et à quel moment. Elle doit aussi distinguer une panne générale d’un cas isolé lié à une donnée particulière.

L’observabilité ne consiste pas à tout enregistrer. Elle consiste à conserver les éléments qui permettent de poser une question et d’y répondre sans exposer inutilement les données des clients.

Partir des parcours importants

Listez les opérations dont l’échec bloque réellement le travail : créer une commande, publier un document, importer un fichier ou envoyer une facture. Pour chacune, décrivez les étapes et le résultat attendu. Le suivi peut ensuite relier les événements techniques à une opération compréhensible par le métier.

Un identifiant de corrélation accompagne la requête entre le navigateur, l’API et les traitements différés. Le support peut alors demander cet identifiant lorsqu’un utilisateur signale un problème. Il doit rester dépourvu de données personnelles et être présenté dans un format facile à copier.

Le nom technique d’un service n’explique pas l’impact. Ajoutez un état métier lorsque c’est possible : « import terminé », « validation refusée » ou « notification en attente ». Un même code d’erreur technique peut correspondre à des conséquences différentes selon l’étape du parcours.

Utiliser les métriques avec prudence

Suivez le volume de requêtes, les erreurs, la durée et le nombre d’opérations réussies. La moyenne peut masquer des temps d’attente élevés pour un petit groupe d’utilisateurs. Utilisez des percentiles et observez les valeurs extrêmes lorsque la rapidité conditionne le travail.

Une métrique métier complète la métrique technique. Le nombre de commandes confirmées, d’importations rejetées ou de factures en attente aide à repérer une interruption silencieuse. Une API peut renvoyer un code de succès alors qu’un traitement secondaire ne s’est pas terminé. La mesure doit couvrir le résultat qui compte.

Définissez un seuil qui déclenche une action. Une alerte permanente finit par être ignorée. Associez chaque alerte à une procédure : vérifier une dépendance, suspendre une file, informer les utilisateurs ou basculer vers un traitement manuel. Les seuils doivent évoluer avec le volume réel.

Écrire des journaux utiles

Un journal doit indiquer l’événement, son niveau, l’identifiant de corrélation, la version et le résultat. Ajoutez la durée et une cause technique quand elle est connue. Évitez d’écrire le contenu complet d’un formulaire, un mot de passe, un jeton ou une pièce jointe.

Les niveaux servent à trier l’information. Une erreur qui empêche une validation nécessite une action. Un avertissement peut signaler une reprise ou une configuration à vérifier. Un message de diagnostic détaillé reste utile pendant une enquête, mais sa conservation doit respecter les règles retenues pour les données.

Conservez un exemple de requête ou de scénario associé aux indicateurs quand cela aide à les interpréter. Une équipe qui voit une hausse des erreurs d’import doit savoir si le volume de fichiers a changé ou si le format attendu a été modifié. La métrique prend son sens avec son contexte opérationnel.

Les logs doivent être structurés pour permettre une recherche fiable. Une phrase différente pour chaque développeur rend les filtres fragiles. Définissez quelques champs communs et documentez leurs valeurs. Les détails spécifiques peuvent rester dans un champ de contexte.

Suivre les traitements asynchrones

Les imports, exports et notifications se poursuivent souvent après la réponse de l’écran. Affichez un identifiant de traitement, un état, une date de début et une date de fin. Enregistrez le nombre d’éléments réussis et rejetés, avec une raison lisible pour les rejets.

Une file peut se bloquer sans faire tomber le site. Mesurez sa longueur, l’âge du plus ancien élément et le nombre de reprises. Un mécanisme de nouvelle tentative doit limiter les répétitions et isoler les messages qui échouent toujours. Les effets de bord doivent supporter une répétition contrôlée, comme dans une intégration API avec gestion des doublons.

Préparer la réponse aux incidents

Conservez un tableau des dépendances et des propriétaires. Quand une alerte apparaît, l’équipe doit savoir qui peut agir et quelle opération peut être suspendue. Une procédure indique aussi comment vérifier le retour à la normale et comment documenter l’incident.

Testez les rapports avec des cas réels anonymisés. Vérifiez qu’un support peut retrouver une opération sans avoir accès à des données auxquelles son rôle ne donne pas droit. Ce contrôle rejoint la conception d’un journal d’audit de logiciel métier.

Enfin, examinez régulièrement les alertes ignorées, les champs inutilisés et les coûts de stockage. Retirez ce qui ne sert plus et gardez les indicateurs qui aident une décision concrète. L’observabilité devient alors un outil de support et de pilotage, au lieu d’un inventaire de logs.

Sources : OpenTelemetry, documentation de référence, Google SRE, monitoring distribué.