Log Level dans le développement d’applications : définition, types de niveaux et configuration

Qu’est-ce que le Log Level ?

Log Level est un attribut de chaque message de journalisation qui détermine son importance et l’urgence de son traitement. Les plateformes modernes iOS et Android prennent en charge une échelle unifiée de 6 à 7 niveaux : du plus détaillé (Verbose/Trace) au critique (Error/Assert). Le choix du niveau détermine si le message sera écrit dans le journal avec la configuration actuelle de l’application.

Le concept de Log Level repose sur le principe de la pyramide de criticité : plus le niveau est élevé, moins il y a de messages affichés à ce niveau. Selon Semaphore CI, 2024, dans une application de production, la répartition est la suivante : Info — 60 % des messages, Warn — 25 %, Error — 10 %, Debug — 5 %. Les messages Verbose doivent être complètement désactivés en production.

Chaque plateforme implémente le Log Level via sa propre API. Android utilise android.util.Log avec les méthodes v(), d(), i(), w(), e(). Apple utilise OSLog avec les niveaux default, info, debug, error, fault. Des bibliothèques comme Timber et CocoaLumberjack ajoutent des fonctionnalités supplémentaires au-dessus de ces API standard.

Selon Google I/O 2023, le mauvais choix du Log Level est la cause de 40 % des problèmes de performance en production. Les développeurs laissent des logs Debug dans les builds de mise en production, ce qui entraîne des écritures excessives sur le disque et une décharge accélérée de la batterie.

Types de niveaux de journalisation : de Verbose à Assert

Verbose (TRACE) — le niveau le plus détaillé, destiné exclusivement au développement. À ce niveau, tous les calculs intermédiaires, les itérations de boucle et les résultats de chaque étape de l’algorithme sont affichés. Sur Android, ce niveau correspond à Log.v(), sur iOS — OSLog de type debug (avant iOS 14, os_trace était utilisé).

Debug — messages de débogage utiles pendant le développement et les tests. Ils contiennent des informations sur l’état des objets clés, les résultats des requêtes SQL et les paramètres des appels API. Contrairement à Verbose, les messages Debug sont structurés et sémantiquement significatifs. Sur iOS, ce niveau correspond à OSLogType.debug.

Info — messages informatifs sur les événements normaux de l’application : initialisation du SDK, authentification réussie, ouverture d’écran, réception de données du serveur. Les messages Info ne doivent pas contenir de données personnelles des utilisateurs et doivent être sûrs pour l’analyse en production. Sur iOS, OSLogType.info est utilisé, sur Android — Log.i().

Warn — avertissements sur les problèmes potentiels. L’application continue de fonctionner, mais la situation nécessite de l’attention : taille du cache proche de la limite, version d’API obsolète, réponse réseau lente, nouvelle tentative de connexion. Sur Android — Log.w(), sur iOS — OSLogType.default (pour les avertissements).

Error — erreurs critiques où l’application ne peut pas effectuer l’opération demandée mais continue de fonctionner : requête API échouée, perte de connexion, erreur d’écriture en base de données, absence d’autorisations. Sur iOS, OSLogType.error est utilisé pour les erreurs, sur Android — Log.e().

Assert (WTF) — le niveau le plus élevé, indiquant une situation qui «ne peut pas arriver». Utilisé pour journaliser les bugs qui violent les invariants fondamentaux du système. Sur Android, les messages Assert ne sont pas affichés dans les builds de mise en production par défaut. Sur iOS, WTF (What a Terrible Failure) est traité via OSLogType.fault.

Utilisation du Log Level sur Android

Android Log API — le mécanisme de journalisation intégré du package android.util.Log. Il fournit 6 méthodes statiques : Log.v(), Log.d(), Log.i(), Log.w(), Log.e() et Log.wtf(). Chaque méthode prend un tag (chaîne d’identification de la source) et msg (texte du message).

class UserRepository {
    companion object {
        private val TAG = "UserRepo"
    }

    suspend fun loadUser(id: String): User {
        Log.d(TAG, "Chargement de l’utilisateur avec l’id : $id")

        return try {
            val response = api.fetchUser(id)
            Log.i(TAG, "Utilisateur chargé avec succès")
            response.toUser()
        } catch (e: Exception) {
            Log.e(TAG, "Échec du chargement de l’utilisateur : ${e.message}")
            throw e
        }
    }
}

Filtrage par niveaux dans Android Logcat s’effectue via ADB : adb logcat *:E n’affichera que les messages Error. Dans les builds de production, tous les appels Log.v() et Log.d() sont supprimés par ProGuard/R8 lorsque la minification est activée. Log.i(), Log.w() et Log.e() restent, il est donc important de ne pas afficher de données sensibles via ces méthodes.

Pour le filtrage personnalisé à l’exécution, Android fournit Log.isLoggable(tag, level) — une méthode qui vérifie si le niveau spécifié est activé pour le tag donné. Cela permet d’activer dynamiquement la journalisation détaillée pour un module spécifique sans reconstruire l’application.

Utilisation du Log Level sur iOS et macOS

OSLog — le système de journalisation unifié d’Apple, remplaçant l’ancien NSLog. OSLog propose 5 niveaux : debug, info, default (notice), error et fault. Le principal avantage est la journalisation structurée avec prise en charge des chaînes formatées et du filtrage dynamique via la console.

import OSLog

let logger = Logger(
    subsystem: "com.example.app",
    category: "network"
)

func fetchData(from url: URL) {
    logger.debug("Starting request to \(url.absoluteString)")

    do {
        let data = try Data(contentsOf: url)
        logger.info("Received \(data.count) bytes")
    } catch {
        logger.error("Request failed: \(error.localizedDescription)")
    }
}

Le système de filtrage d’OSLog fonctionne au niveau du système d’exploitation. Les messages Debug ne sont écrits que lorsque le débogueur est connecté ou lorsque l’argument -com.apple.CoreData.Logging.debug 1 est activé. Les messages Info sont collectés dans la mémoire de l’appareil (jusqu’à 512 Ko) et sont accessibles via Console.app. Les messages Error et fault sont écrits en continu et sont disponibles pour la collecte via les systèmes de signalement de plantages.

Une fonctionnalité importante d’OSLog : les chaînes formatées avec des espaces réservés. Au lieu de l’interpolation de chaînes Swift (qui est toujours évaluée, indépendamment du niveau), OSLog utilise le format os_log avec %{public}@ et %{private}@ pour distinguer les données sensibles. Les paramètres privés sont masqués dans les logs de production.

Production vs Debug : comment configurer le filtrage des niveaux

La règle principale — un ensemble minimal de niveaux en production : Info, Warn, Error, Assert. Debug et Verbose doivent être désactivés. La raison n’est pas tant la sécurité que la performance : chaque appel de journalisation consomme du temps CPU pour formater la chaîne, même si le message n’est pas affiché.

Formatage paresseux des chaînes

Optimisation critique — n’utilisez jamais l’interpolation de chaînes dans les appels de journalisation. Si la chaîne est construite avant l’appel à log(), du temps CPU est gaspillé même lorsque le niveau est désactivé. Utilisez le formatage paresseux via des lambdas ou des conditions de garde.

Sur Android, la méthode Log.isLoggable() sert cet objectif ; sur OSLog, les chaînes formatées natives avec espaces réservés sont prises en charge. Timber pour Android résout le problème via timber.log.Tree avec vérification du niveau à l’intérieur de l’arbre.

Changement dynamique de niveau à la volée

Remote Log Level — une pratique où le niveau de journalisation est contrôlé depuis le serveur via Firebase Remote Config ou un service similaire. Si une erreur complexe se produit en production, le développeur peut activer à distance la journalisation Debug pour un module spécifique sur les appareils d’un groupe d’utilisateurs sélectionné.

Selon Firebase, 2024, cette pratique réduit le temps de diagnostic des bugs rares de 60 % et permet d’obtenir une image complète du problème sans installer de build de débogage. La principale limitation — la journalisation n’est activée qu’au prochain démarrage de l’application après réception de la configuration.

Filtrage automatique par type de build

BuildConfig.DEBUG sur Android et #if DEBUG sur Swift sont des mécanismes standard de compilation conditionnelle qui désactivent les niveaux de débogage dans les builds de mise en production. Pour une architecture propre, il est recommandé de déplacer la sélection du Log Level vers un conteneur DI ou une usine de journaliseurs afin de ne pas encombrer la logique métier avec des directives conditionnelles.

Bonnes pratiques pour choisir le niveau de journalisation

Première règle — chaque appel de journalisation doit répondre à la question «qui, quoi, quand». Qui — le composant ou le module (tag sur Android, category sur iOS). Quoi — l’événement spécifique ou le changement d’état. Quand — l’horodatage, ajouté automatiquement par le système de journalisation.

Deuxième règle — ne journalisez pas de données sensibles via Info et au-dessus. Mots de passe, jetons, e-mails, numéros de téléphone, coordonnées géographiques précises sont strictement interdits dans tout log qui aboutit en production. Si nécessaire, utilisez le masquage : «email : us***@example.com.»

Troisième règle — le niveau Warn est la responsabilité du développeur, Error — de l’équipe. Warn signifie «il y a un problème potentiel ici, surveillez-le». Error signifie «il y a un problème ici, corrigez-le». N’utilisez pas Error pour des situations attendues et gérées (par exemple, une erreur API 404).

Quatrième règle — cohérence. L’ensemble du projet doit utiliser des conventions de nommage unifiées pour les tags et les catégories. Il est recommandé d’utiliser ClassName.methodName pour les tags Android et module.subsystem pour les catégories iOS. Cela permet de filtrer rapidement les logs par composant.

Cinquième règle — testez vos logs. Dans les tests unitaires, vérifiez que le bon Log Level est appelé dans des scénarios spécifiques. Il existe des bibliothèques de mock de journalisation à cet effet : Mockito pour Android, Cuckoo pour iOS. La vérification des niveaux dans les tests empêche la fuite de messages de débogage en production.