Choisissez les événements à journaliser, retrouvez une demande en erreur et maîtrisez les accès et le coût des logs de votre application métier.
Un client signale que sa commande a disparu après validation. Le serveur fonctionne et la page répond. Pour comprendre ce qui s’est passé, l’équipe doit retrouver cette opération, suivre son traitement et savoir à quelle étape elle s’est arrêtée. Un journal qui contient seulement « erreur technique » apporte peu d’aide.
Commencez par un parcours que le support doit régulièrement vérifier : création de devis, import de stock ou transmission d’une commande. Les champs utiles apparaissent plus facilement à partir d’un problème concret que d’une liste de technologies à installer.
Partir des questions du support
Pour une commande, la première question concerne son enregistrement. La deuxième porte sur son éventuelle transmission au logiciel de gestion. Une notification peut avoir échoué alors que la commande existe bien. Ces situations demandent des réponses différentes au client.
Décrivez les étapes observables avec la personne qui connaît le processus. Retenez un nom stable par événement : demande reçue, validation refusée, enregistrement terminé, transmission échouée. Le message lisible peut évoluer, mais une recherche enregistrée doit continuer à retrouver le même type d’événement.
Précisez aussi ce que signifie une réussite. Si votre application écrit dans une file de messages, cet événement confirme une mise en attente. La confirmation du traitement final doit venir du service qui l’exécute. Évitez de montrer au support un statut qui confond les deux.
Définir une fiche d’événement commune
Vous pouvez commencer avec le contrat proposé ci-dessous, puis supprimer les champs sans usage démontré.
| Champ | Utilité dans une recherche |
|---|---|
| Horodatage avec fuseau | Reconstituer la chronologie sans ambiguïté |
| Application et environnement | Écarter les événements provenant des tests |
| Nom de l’événement | Retrouver une étape précise du parcours |
| Identifiant de demande | Relier les événements d’une même opération |
| Résultat et code d’erreur | Distinguer rejet métier et panne technique |
| Version déployée | Examiner un changement de comportement |
Choisissez des types cohérents : un identifiant reste une chaîne, une durée conserve la même unité. Documentez le cas où une valeur est inconnue. Un champ vide ne devrait pas changer discrètement de sens selon le développeur qui l’écrit.
OpenTelemetry décrit la corrélation des logs avec les traces grâce au contexte d’exécution. Si votre application utilise déjà cette instrumentation, reprenez ses identifiants. Sinon, un identifiant d’opération métier bien transmis entre vos composants constitue un premier point de recherche. Vérifiez son passage dans les traitements asynchrones : c’est souvent là que votre parcours change de service.
Garder le contenu métier dans son application
L’aide-mémoire OWASP sur la journalisation recommande d’exclure notamment les mots de passe et les jetons d’accès. Il attire aussi l’attention sur les informations personnelles et les chaînes de connexion. Appliquez cette règle au niveau du mécanisme de journalisation, puis vérifiez les exceptions produites par les bibliothèques utilisées.
Pour votre parcours de commande, privilégiez une référence interne au contenu complet du panier ou au corps de la requête. Le support pourra ouvrir la fiche métier avec ses droits habituels si l’enquête le demande. Décidez séparément quels collaborateurs peuvent consulter les journaux techniques.
Demandez un exemple réel de log à chaque ajout de champ. Une revue de la seule structure du code peut laisser passer un message provenant d’un système externe qui recopie une donnée confidentielle. Préparez également une procédure de retrait si une telle donnée arrive malgré les contrôles.
Régler le niveau de détail sans perdre l’incident
Une proposition de départ consiste à conserver les résultats des étapes métier utiles et les erreurs exploitables, puis à activer temporairement davantage de détails sur un périmètre précis. Notez qui a activé ce mode, pour quelle enquête et quand il doit s’arrêter.
Séparez les recherches d’exploitation des besoins d’audit. Un échantillonnage acceptable pour examiner une lenteur peut ne pas convenir à une trace dont vous devez conserver chaque occurrence. La durée de conservation se décide selon l’usage, les contraintes applicables et les accès autorisés ; elle ne se déduit pas du seul espace disponible.
Suivez le volume par application et par catégorie d’événements. Une nouvelle version qui répète le même avertissement peut changer la facture de collecte. Le travail d’attribution des coûts cloud aide alors à identifier le service concerné et à vérifier l’effet de la correction.
Faire un exercice de recherche avant la mise en service
Dans un environnement de test, créez une commande fictive et provoquez un échec de transmission contrôlé. Donnez au support uniquement les informations dont disposerait un client : référence et heure approximative. Observez s’il retrouve le parcours sans demander un accès administrateur supplémentaire.
L’exercice doit permettre de répondre à quatre questions : la commande existe-t-elle, quelle étape a échoué, faut-il la relancer, et comment éviter une deuxième transmission ? Si la dernière réponse manque, complétez le mécanisme de reprise décrit dans notre guide sur les doublons entre CRM et ERP.
Conservez la recherche utilisée et le résultat attendu dans le dossier d’exploitation. Répétez cet exercice après une modification importante du parcours ou du format des événements. Une requête sauvegardée qui ne retourne plus rien mérite la même attention qu’un écran de support cassé.