La journalisation et la surveillance sont deux piliers de la stabilité des applications mobiles. Selon Gartner (2025), le marché des solutions APM atteindra 8 milliards de dollars d'ici 2027. Une journalisation appropriée permet non seulement de trouver des bugs, mais aussi de prédire les problèmes avant qu'ils n'affectent les utilisateurs.
Points clés
La journalisation des applications mobiles sur iOS repose sur os_log — le système intégré d'Apple, disponible depuis iOS 10. os_log écrit les logs dans un journal système unique (sur l'appareil ou via Console.app), prend en charge les catégories, les niveaux et les balises de confidentialité. La combinaison de la journalisation et de la surveillance sur iOS via Console.app et xcrun permet de suivre les erreurs et les performances en temps réel.
os_log a des niveaux : Default, Info, Debug, Error, Fault. En production, on conserve Error et Fault — Debug et Info sont désactivés. Choisir le bon niveau fait partie de la stratégie de surveillance des applications mobiles sur iOS. Confidentialité : %{public}@ pour les données non protégées, %{private}@ pour les données personnelles.
CocoaLumberjack est une bibliothèque populaire pour la journalisation iOS. Contrairement à os_log, elle prend en charge les formats personnalisés, l'écriture asynchrone et la rotation des logs. DDLog, DDTTYLogger (console), DDFileLogger (fichier avec rotation). Pour la surveillance à distance, CocoaLumberjack peut être combiné avec os_log — écrire dans un fichier pour la journalisation à distance et dans os_log pour Console.app.
Pour la journalisation des applications mobiles sur Android, on utilise Timber — une bibliothèque de Jake Wharton devenue la norme de la plateforme. Timber est un wrapper autour d'Android Log (Logcat) qui ajoute automatiquement la balise de classe et configure Tree. Timber fait partie du système de surveillance des applications mobiles Android : DebugTree pour le débogage, CrashlyticsTree pour l'envoi de données.
Timber utilise Tree — un composant qui décide quoi faire du log. Dans les builds de débogage, DebugTree (sortie vers Logcat), en release — CrashlyticsTree (envoi de plantages). Timber.wtf() journalise les erreurs fatales. Timber.tag("CustomTag") remplace la balise. Pour une surveillance efficace, Timber est combiné avec des outils APM.
Android Log a des niveaux : VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT. ProGuard/R8 supprime Log.d et Log.v en release — Timber permet la journalisation via Plant. Le choix du niveau affecte la qualité de la surveillance de l'application mobile — en production, on conserve WARN et ERROR.
| Outil | Plateforme | Format | Rotation | Distant | Complexité |
|---|---|---|---|---|---|
| os_log | iOS | Structuré | Système | Console.app | Faible |
| CocoaLumberjack | iOS | Texte/JSON | DDFileLogger | Oui (personnalisé) | Moyenne |
| Timber | Android | Texte | Logcat/Personnalisé | Tree | Faible |
| Sentry | iOS/Android | JSON | Serveur | Oui | Moyenne |
| Logcat | Android | Texte | Tampon | ADB | Faible |
Lors du choix d'un outil de journalisation, tenez compte : devez-vous une journalisation à distance, à quelle fréquence les logs changent et qui les analysera. Pour les startups, os_log ou Timber suffisent. Pour les entreprises — CocoaLumberjack avec envoi au serveur. Chez IT Sectr, nous utilisons la combinaison Timber + Crashlytics pour Android et os_log + CocoaLumberjack pour iOS.
Journalisation structurée — écriture des logs au format JSON au lieu de texte brut. Exemple : au lieu de "User login failed", nous écrivons {"event": "login_failed", "user_id": 123, "reason": "invalid_password"}. C'est la base de la surveillance automatique — la stack ELK et Grafana filtrent, agrègent et analysent ces données.
Filtrage par champs : trouvez tous les logs avec event=crash de la dernière heure. Agrégation : construisez un graphique du nombre d'erreurs par version d'application. Intégration avec ELK (Elasticsearch, Logstash, Kibana) ou Grafana. La journalisation structurée n'est pas obligatoire pour les premières versions, mais devient critique lorsque le DAU dépasse 10 000.
Journalisation à distance — envoi des logs de l'appareil vers un serveur pour une surveillance centralisée. Implémentée via un Tree personnalisé (Android) ou des requêtes HTTP. Envoyez uniquement Error et Warning — ne gaspillez pas le trafic de l'utilisateur. Rotation des logs : DDFileLogger (iOS) tous les 1 Mo ou 1 jour. Sur Android, le tampon Logcat est limité.
Application Performance Monitoring (APM) — une classe d'outils pour la surveillance des applications mobiles. L'APM mesure : le temps de démarrage, les requêtes réseau, les FPS, l'utilisation de la mémoire, la fréquence des plantages. Principaux acteurs : Sentry (Performance), New Relic Mobile, Datadog Mobile.
Sentry — non seulement le signalement de plantages, mais aussi la surveillance des performances. Sentry Performance crée des traces distribuées qui montrent combien de temps chaque étape a pris : de l'appui sur un bouton à la réponse du serveur. Prend en charge iOS, Android, Flutter, React Native. Gratuit jusqu'à 5k événements par mois.
New Relic Mobile fournit des métriques : nombre de sessions, temps dans l'application, fréquence des plantages, requêtes réseau. Datadog Mobile est un outil plus moderne avec des tableaux de bord en temps réel et des alertes. Les deux sont payants, mais ont des niveaux gratuits. IT Sectr recommande de commencer avec Firebase Performance et de passer à l'APM payant lorsque le DAU dépasse 100 000.
Firebase Performance — un outil gratuit de surveillance des applications mobiles de Google. Collecte automatiquement les métriques : temps de démarrage de l'application, requêtes HTTP (URL, méthode, code de réponse), FPS. Pour un tracing personnalisé, utilisez l'API Trace. Intégration : ajoutez le SDK à build.gradle (Android) ou Podfile (iOS).
Trace — un segment temporel avec un début et une fin que vous mesurez. Exemple : trace = FirebasePerformance.getInstance().newTrace("checkout_process"). Métriques — indicateurs numériques (taille de la réponse, nombre d'éléments). Firebase Performance ne nécessite pas d'infrastructure serveur — toutes les données passent par le SDK Firebase. Lors de la surveillance d'applications mobiles, l'API Trace fournit un contexte pour l'analyse des performances.
Foire aux questions
Niveaux standard : ERROR (erreurs critiques), WARN (problèmes potentiels), INFO (événements clés), DEBUG (débogage), VERBOSE (traçage détaillé). En production, on conserve ERROR, WARN et INFO, les autres sont désactivés.
Timber est une bibliothèque wrapper autour de Logcat par Jake Wharton pour la journalisation des applications mobiles sur Android. Elle insère automatiquement la balise de classe, configure Tree et désactive les logs en production avec une ligne de code.
APM (Application Performance Monitoring) — une classe d'outils pour suivre les performances : temps de démarrage, requêtes réseau, utilisation de la mémoire, fréquence des plantages. Lors de la surveillance d'applications mobiles, New Relic, Datadog et Firebase Performance aident à trouver les goulots d'étranglement avant les plaintes des utilisateurs.
Pour une startup, Firebase Performance est suffisant — un outil gratuit de surveillance des applications mobiles. New Relic et Datadog sont connectés lorsque des traces détaillées et des tableaux de bord personnalisés sont nécessaires. IT Sectr recommande de commencer avec Firebase et de passer aux solutions payantes lorsque le DAU dépasse 100 000.
La journalisation structurée est un format de logs en JSON ou clé-valeur au lieu de texte brut. Elle permet de filtrer les logs par champs, de construire des graphiques et d'analyser automatiquement dans ELK ou Grafana. Sans logs structurés, il est difficile de trouver des motifs dans des milliers d'enregistrements.
Résumé
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.