Journalisation dans les applications C# : meilleures pratiques de développement .NET

Journalisation dans les applications C# : bonnes pratiques

La journalisation ne consiste pas simplement à écrire des messages dans un fichier. Dans les applications .NET modernes, c'est un outil essentiel pour la surveillance, le débogage et l'audit. Une journalisation correctement configurée permet de trouver rapidement les causes des pannes, d'analyser les performances et de garantir la conformité aux exigences de sécurité. Dans cet article, nous allons examiner les bonnes pratiques de journalisation en C# qui vous aideront à construire un système fiable de collecte d'informations de diagnostic.

Choix de la bibliothèque de journalisation : Serilog vs NLog vs ILogger intégré

Dans .NET, il existe plusieurs solutions populaires. Examinons leurs forces et leurs faiblesses.

• Microsoft.Extensions.Logging (ILogger) — interface abstraite intégrée. Convient aux projets simples. Ne prend pas en charge la journalisation structurée « prête à l'emploi ».
• Serilog — leader en popularité. Se distingue par sa simplicité de configuration, sa prise en charge puissante des journaux structurés et son vaste ensemble de sinks (récepteurs de données).
• NLog — framework mature avec une configuration flexible via XML ou code. Idéal pour les systèmes legacy et les scénarios de routage complexes.

Pour un nouveau projet, Serilog est recommandé. Il s'intègre facilement avec ILogger et fournit une API concise. Exemple de connexion :

// Installation : dotnet add package Serilog.AspNetCoreusing Serilog;

Log.Logger = new LoggerConfiguration()    .MinimumLevel.Information()    .WriteTo.Console()    .WriteTo.File("logs/app-.log", rollingInterval: RollingInterval.Day)    .CreateLogger();

var builder = WebApplication.CreateBuilder(args);builder.Host.UseSerilog(); // Remplacement du logger standard

Utilisation correcte des niveaux de journalisation

Ne mélangez pas tous les messages dans un seul niveau. Utilisez la gradation suivante :

• Trace (0) — informations extrêmement détaillées pour le débogage. Inclut les détails d'exécution de chaque fonction. Activez uniquement dans l'environnement de développement.
• Debug (1) — données utiles pour le développeur : valeurs des variables, résultats d'exécution des méthodes.
• Information (2) — événements métier : « L'utilisateur s'est connecté », « La commande a été créée ». Doivent être compréhensibles non seulement par le programmeur.
• Warning (3) — anomalies qui n'interrompent pas le fonctionnement : dépassement du temps d'exécution, tentatives de connexion répétées.
• Error (4) — exceptions et pannes nécessitant une intervention. Journalisez toujours la pile d'appels complète.
• Critical (5) — erreurs fatales : perte de connexion à la base de données, dépassement de mémoire. Nécessitent une notification immédiate.

Exemple de journalisation correcte dans un contrôleur :

[ApiController][Route("api/orders")]public class OrdersController : ControllerBase{    private readonly ILogger<OrdersController> _logger;

    public OrdersController(ILogger<OrdersController> logger)    {        _logger = logger;    }

    [HttpPost]    public IActionResult CreateOrder(OrderDto order)    {        _logger.LogInformation("Création de la commande {OrderId} pour l'utilisateur {UserId}",             order.Id, order.UserId);                try        {            // logique métier            _logger.LogInformation("Commande {OrderId} créée avec succès", order.Id);            return Ok();        }        catch (Exception ex)        {            _logger.LogError(ex, "Erreur lors de la création de la commande {OrderId}", order.Id);            return StatusCode(500);        }    }}

Journalisation structurée et contexte

Évitez la concaténation de chaînes dans les journaux. Au lieu de Log.Information("User: " + user.Name), utilisez des modèles avec paramètres :

_logger.LogInformation("Utilisateur {UserName} a effectué