Console.app : qu’est-ce que c’est, fonctions et comment lire les logs dans macOS

Qu’est-ce que Console.app

Console.app est une interface graphique pour le système de journalisation unifié d’Apple. Elle a remplacé l’ancienne application Console (en tant que partie de macOS) et donne accès à tous les logs système et d’applications écrits via les API os_log, os_trace et syslog. Console.app se trouve dans /Applications/Utilities/ sur n’importe quel Mac.

Contrairement à Xcode, qui n’affiche que les logs de l’application lancée depuis l’IDE, Console.app affiche les logs de tous les processus du système simultanément. Cela permet de diagnostiquer les problèmes qui ne surviennent que lorsque l’application est démarrée en dehors de Xcode ou en arrière-plan. Console.app affiche également les logs système — kernel, launchd, WindowServer — ce qui est utile pour déboguer des problèmes de bas niveau.

Console.app ne nécessite pas d’installation d’outils supplémentaires ni de connexion Internet. Toutes les données sont stockées localement dans une base de données .tracev3, et l’application fonctionne entièrement hors ligne. Pour afficher les logs d’un autre Mac ou d’un appareil iOS, utilisez la commande log collect, puis ouvrez le .logarchive dans Console.app.

Interface de Console.app

L’interface de Console.app se compose de trois zones principales : la barre latérale avec les filtres, la table des messages et le panneau de détails du message sélectionné. La barre latérale contient les sections Devices (sources de logs disponibles), Reports (rapports de crash système) et Saved Searches (requêtes de recherche enregistrées).

La table des messages affiche une liste de logs avec les colonnes : Time (horodatage), Category (catégorie), Level (niveau de criticité — codé par couleur), Process (nom du processus), Message (texte du message). Un clic sur un message ouvre le panneau de détails montrant le sous-système, l’identifiant d’activité, l’ID du thread et le texte complet formaté.

Console.app surligne les messages par couleur : rouge pour Fault, jaune pour Error, bleu pour Debug, gris pour Info. Les messages par défaut ne sont pas surlignés. Cela permet de scanner visuellement le flux de logs et de repérer instantanément les événements critiques.

// Logs qui apparaîtront dans Console.app
import OSLog

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

logger.error("Connection failed: timeout")
logger.debug("Retry attempt 3 of 5")

// Ces messages sont visibles dans Console.app avec le filtre « myapp »

Filtres et recherche dans Console.app

Le filtrage est la fonction principale de Console.app, transformant un flux de milliers de messages par seconde en une liste lisible. Le champ de recherche en haut prend en charge les conditions ET : plusieurs mots séparés par un espace n’affichent que les messages contenant tous les mots. Par exemple, myapp error montre tous les logs de l’application myapp avec le niveau Error.

Filtre de sous-système dans la barre latérale permet de sélectionner un ou plusieurs sous-systèmes. C’est le moyen le plus rapide d’isoler les logs d’une application spécifique des messages système. Filtre de catégorie est disponible après avoir sélectionné un sous-système — il montre toutes les catégories utilisées par l’application sélectionnée. Filtre de niveau restreint les messages par niveau de criticité : on peut afficher uniquement les erreurs ou uniquement les messages de débogage.

Expressions régulières dans la recherche

Le champ de recherche de Console.app prend en charge les expressions régulières via la construction REGEX:pattern. Exemple : REGEX:error.*tim(e|out) trouve tous les messages contenant « error » et un mot commençant par « tim » et se terminant par « e » ou « out ». Les regex ne fonctionnent que dans le champ de recherche, pas dans les filtres de sous-système ou de catégorie.

Modes Live et Historical

Live est le mode temps réel dans lequel Console.app affiche les nouveaux messages dès leur apparition dans le tampon circulaire du noyau. Ce mode est actif par défaut et convient au débogage d’une application en cours d’exécution : vous lancez l’application et voyez ses logs avec un retard de 1 à 5 secondes. Le bouton Live (ou ⌘L) active et désactive le flux.

Historical est le mode d’affichage d’archive. Console.app stocke tous les messages des 7 à 14 derniers jours (configurable dans le système) dans une base de données .tracev3. Le mode Historical ouvre cette archive et permet d’y effectuer des recherches avec n’importe quel filtre, pas seulement le flux actuel. C’est indispensable pour analyser les problèmes survenus pendant la nuit ou lorsque l’application fonctionnait sans être connectée à un Mac.

La bascule entre les modes se fait via le bouton Live dans la barre d’outils. Lorsque Live est désactivé, Console.app affiche les données historiques. Dans ce mode, vous pouvez naviguer dans la chronologie à l’aide du calendrier ou des boutons ← →. Les données historiques ne sont disponibles que pour les logs sauvegardés sur le disque — les messages qui ont été écrasés dans le tampon circulaire n’apparaissent pas dans l’archive.

Exportation et partage des logs

Console.app prend en charge l’exportation des logs filtrés dans plusieurs formats. File → Export → Save permet de choisir le format : .logarchive (format natif d’Apple, inclut toutes les métadonnées), .txt (texte brut avec colonnes) et .json (données structurées avec champs). Pour joindre à un rapport de bug, utilisez .logarchive — il peut être ouvert sur n’importe quel Mac dans Console.app.

Exportation depuis un appareil iOS : via Xcode (Devices → Open Console) ou via la commande log collect --device --output ./archive.logarchive dans le terminal. Ouvrez le .logarchive résultant dans Console.app sur un Mac — les logs proviennent de l’appareil distant, mais les filtres et la recherche fonctionnent comme avec des logs locaux.

// Exportation des logs d’appareil iOS via le terminal
// log collect --device --output ./ios_crash.logarchive
// log show --subsystem com.example.app --last 1h --output json

// Exemple : exporter les logs de la dernière heure
// log show --predicate 'subsystem == "com.example.myapp"' \
//   --info --debug --last 1h --output json > logs.json

// Analyse des logs exportés en Swift
let jsonData = try Data(contentsOf: URL(fileURLWithPath: "logs.json"))
let decoded = try JSONDecoder()
    .decode([LogEntry].self, from: jsonData)

Partage des logs

.logarchive est le format optimal pour envoyer à un collègue ou joindre à un ticket JIRA. Le fichier contient non seulement les messages mais aussi le sous-système, la catégorie, les horodatages, les ID de thread et toutes les métadonnées. La taille de l’archive est considérablement plus petite que les logs bruts grâce à la compression .tracev3. Avant l’envoi, assurez-vous que les logs ne contiennent pas de données privées : utilisez un filtre par sous-système de votre application pour exclure les logs système pouvant contenir des informations confidentielles d’autres processus.

Exemples pratiques de débogage avec Console.app

Diagnostic de crash sans Xcode : si une application plante au démarrage en dehors de Xcode, Console.app affiche un message Fault du processus. Cherchez Reports → Crash Reports dans la barre latérale — des rapports de crash complets avec signature et pile y sont affichés. Utilisez le filtre de sous-système pour votre application et définissez le niveau Error+Fault pour voir tous les événements critiques avant le crash.

Analyse des performances via Console.app

Console.app permet de suivre les retards dans l’application à l’aide d’horodatages. Si plus de temps que prévu s’est écoulé entre deux messages liés (par exemple, « requête envoyée » et « réponse reçue »), c’est un signe de problème de performance. Un filtre sur le sous-système de votre application avec le niveau Default affichera tous les événements clés avec une précision milliseconde.

Recherche de fuites mémoire : lors d’une fuite mémoire, le système envoie un avertissement mémoire via os_log avec la catégorie memory et le niveau Error. Dans Console.app, filtrez par le mot memory et sélectionnez votre sous-système. Si l’avertissement se répète toutes les 5 à 10 secondes, l’application consomme activement de la mémoire. Vous pouvez également activer les logs Debug pour suivre les allocations.

Débogage des requêtes réseau : si votre application utilise os_log pour les événements réseau, Console.app affichera toutes les requêtes et réponses avec les temps. Un filtre category=network réduit le bruit. Si le temps entre une requête et une réponse dépasse les attentes, cherchez des messages avec level=Error — ils indiqueront des timeouts ou des erreurs DNS.

// Structure pour analyser les logs JSON de Console.app
struct LogEntry: Codable {
    let timestamp: String
    let eventMessage: String
    let subsystem: String
    let category: String
    let messageType: UInt8

    var level: String {
        switch messageType {
        case 1: return "Fault"
        case 16: return "Error"
        case 17: return "Debug"
        default: return "Default"
        }
    }
}