Sentry — ce que c'est, principes et collecte d'erreurs

Qu'est-ce que Sentry dans le développement

Sentry est une plateforme open-source de crash reporting et de surveillance des performances, fondée en 2012. Elle permet aux développeurs de recevoir des notifications d'erreurs en temps réel avec un contexte de diagnostic complet : pile d'appels, valeurs des variables au moment du plantage, séquence des actions de l'utilisateur avant l'erreur et état de l'environnement.

Contrairement aux services agrégés de crash reporting (Google Play Console, App Store Connect), qui fournissent uniquement des statistiques et des graphiques de base, Sentry affiche chaque événement individuellement avec la possibilité de regrouper par type d'erreur et de filtrer par version de l'application. Un Issue dans Sentry est un groupe d'événements avec la même stack trace, permettant de ne pas se noyer dans des milliers de plantages identiques mais de se concentrer sur la correction de la cause racine avec un contexte complet.

Selon Sentry (2025), le temps moyen de détection des erreurs passe de 30 minutes à 30 secondes après l'implémentation du SDK Sentry, et le temps de diagnostic est réduit de 60% grâce aux breadcrumbs automatiques et au contexte environnemental. La plateforme est utilisée par plus de 100 000 organisations dans le monde, dont Airbnb, Microsoft, Instagram et PayPal, traitant des milliards d'événements chaque jour.

Architecture de Sentry : SDK, Relay et traitement des événements

Le système Sentry se compose de trois composants principaux : SDK côté application, Relay (serveur proxy) et backend de traitement des événements. Sentry SDK est une bibliothèque intégrée à l'application qui intercepte les exceptions, collecte le contexte et envoie les événements à Relay via le protocole JSON/HTTPS.

Sentry Relay

Relay est un serveur intermédiaire qui peut être déployé dans l'infrastructure de l'entreprise. Il reçoit les événements du SDK, les filtre selon des règles (données PII, événements inutiles), les met en mémoire tampon et les transmet à Sentry SaaS ou à une instance auto-hébergée. Relay garantit une faible latence — le temps de réception typique d'un événement est de 500 à 1500 ms.

Filtre de données entrantes

Sentry fournit des filtres intégrés pour rejeter les événements indésirables avant leur envoi au serveur : erreurs des environnements de test, erreurs des anciennes versions de l'application, événements en double avec la même empreinte. Filtering permet d'économiser jusqu'à 70% du volume de données dans un projet de production typique, réduisant les coûts de consommation et la charge du canal de communication de l'appareil.

Configuration du SDK Sentry pour iOS et Android

L'installation du SDK Sentry pour les plateformes mobiles prend 5 à 10 minutes et nécessite l'ajout d'une dépendance et l'initialisation avec une clé DSN. DSN (Data Source Name) est un identifiant unique de projet dans Sentry qui indique où envoyer les événements.

Configuration sur Android

Pour Android, Sentry fournit une instrumentation automatique via un plugin Gradle. Le plugin modifie le bytecode à la compilation, ajoutant des wrappers pour toutes les Activities, Fragments et appels réseau. Auto-instrumentation s'active avec une seule option dans build.gradle et permet d'obtenir des breadcrumbs du cycle de vie de l'application sans modifier le code.

import io.sentry.Sentry

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Sentry.init { options ->
            options.dsn = "https://example@sentry.io/project"
            options.tracesSampleRate = 0.2
            options.enableAutoSessionTracking = true
        }
    }
}

Le code initialise le SDK Sentry dans une application Android. Le paramètre tracesSampleRate = 0.2 active le performance tracing pour 20% des sessions, enableAutoSessionTracking crée automatiquement des sessions pour chaque lancement de l'application.

Configuration sur iOS

Le SDK pour iOS prend en charge CocoaPods, Swift Package Manager et Carthage. Après l'installation, le SDK intercepte automatiquement NSException, les signaux (SIGABRT, SIGSEGV) et les erreurs Swift. Sentry Cocoa SDK est compatible avec iOS 12+ et macOS 10.13+, prend en charge Swift Concurrency (async/await) et l'instrumentation automatique d'URLSession.

import Sentry

class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions options: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        SentrySDK.start { options in
            options.dsn = "https://example@sentry.io/project"
            options.enableAutoPerformanceTracing = true
        }
        return true
    }
}

Le code Swift active le SDK Sentry avec la collecte automatique des métriques de performance. enableAutoPerformanceTracing active la surveillance du temps de chargement des écrans et des requêtes HTTP sans code supplémentaire.

Breadcrumbs et contexte d'erreur

Breadcrumbs sont une séquence chronologique d'événements précédant une erreur. Sentry enregistre automatiquement des breadcrumbs pour les pressions de boutons, les transitions d'écran, les requêtes HTTP et les notifications système. Le développeur peut ajouter des breadcrumbs personnalisés pour la logique métier.

Chaque breadcrumb contient un horodatage, un type d'événement (navigation, http, ui, error), une catégorie et des données arbitraires. Lorsqu'une erreur se produit, tous les breadcrumbs des 2 à 5 dernières minutes (configurable) sont attachés à l'événement. Ce contexte est souvent plus important que la stack trace elle-même : le développeur voit que l'utilisateur a cliqué sur « Payer » après avoir sélectionné un produit, et ensuite seulement le plantage s'est produit. Le nombre maximum de breadcrumbs par défaut est de 200, après quoi les enregistrements les plus anciens sont automatiquement supprimés.

Sentry.addBreadcrumb(
    Breadcrumb().apply {
        category = "payment"
        message = "User tapped Pay button"
        type = "user"
        level = BreadcrumbLevel.INFO
        data["amount"] = "19.99"
        data["currency"] = "USD"
    }
)

Le code ajoute un breadcrumb personnalisé pour une action utilisateur dans le scénario de paiement. Si une erreur se produit après cette action, le développeur verra dans Sentry que l'utilisateur a cliqué sur « Payer » avec le montant de 19,99 USD, permettant une localisation rapide du problème dans le flux de paiement.

Contexte utilisateur

Sentry permet d'attacher des informations utilisateur aux événements : ID, nom d'utilisateur, e-mail. User context est transmis automatiquement avec tous les événements d'une même session, permettant de regrouper les erreurs par utilisateurs et de déterminer combien d'utilisateurs ont été affectés par un bogue spécifique. Il est important de respecter la politique de confidentialité et de ne pas transmettre de données personnelles si la politique de l'application ne le permet pas.

Source maps et symboles de débogage

Dans les builds de production d'iOS et d'Android, le code est généralement minifié ou obscurci. Sans traitement, la pile d'erreurs contiendra des noms incompréhensibles comme « a.b() » au lieu de « UserViewModel.fetchData() ». Source maps (JavaScript) et debug symbols (dSYM pour iOS, ProGuard mapping pour Android) restaurent une pile lisible.

Pour Android, Sentry télécharge automatiquement les fichiers ProGuard mapping via le plugin Gradle lors de la compilation de la version release. Pour iOS, les fichiers dSYM doivent être téléchargés — Sentry fournit un script pour le téléchargement automatique lors de l'archivage. Sans symboles de débogage, la pile d'erreurs dans Sentry sera inutile pour le développeur, donc le processus de téléchargement doit être une étape obligatoire du pipeline CI/CD.

Surveillance des performances avec Sentry

Depuis la version 2020, Sentry inclut la surveillance des performances — collecte de métriques de temps d'exécution des transactions avec distributed tracing. Une Transaction dans Sentry est une unité de travail mesurable : chargement d'écran, exécution de requête API, traitement de tâche en arrière-plan. Chaque transaction contient des spans enfants qui montrent quelles étapes spécifiques ont pris le plus de temps.

La surveillance des performances dans Sentry est intégrée à l'error tracking : si une transaction se termine par une erreur, le span correspondant est marqué avec le statut « error », et le développeur peut naviguer des métriques de performance aux détails de l'exception. Trace ID lie tous les événements (erreurs, transactions, breadcrumbs) en une seule session pour une analyse de bout en bout, offrant une transition transparente entre les onglets Issues et Performance dans un tableau de bord unique de Sentry.

Selon Sentry Performance Benchmark (2024), une application avec la surveillance des performances activée (taux d'échantillonnage de 10%) consomme 2 à 5% de trafic supplémentaire et 1 à 2% de ressources CPU supplémentaires sur l'appareil. Cette surcharge est compensée par une réduction de 70% du temps de diagnostic des performances par rapport au profilage manuel.