Permission d'accès au calendrier dans le développement mobile — ce que c'est, comment ça marche et demande d'accès

Qu'est-ce que la permission d'accès au calendrier ?

La permission d'accès au calendrier est un mécanisme de protection des données personnelles qui contrôle la lecture et l'écriture d'événements dans les applications de calendrier de l'appareil. Le calendrier contient des informations sensibles : réunions, délais, rappels et plans personnels — c'est pourquoi les OS mobiles classent l'accès à celui-ci comme critique.

Sous iOS, l'accès au calendrier est régulé par le framework EventKit. Une application peut demander un accès en lecture et écriture aux événements, et l'utilisateur peut accorder ou refuser la demande via une boîte de dialogue système. Sous Android, la protection repose sur deux permissions d'exécution : READ_CALENDAR et WRITE_CALENDAR.

Selon une étude du Pew Research Center (2024), environ 45 % des utilisateurs d'appareils mobiles utilisent régulièrement le calendrier, et 62 % d'entre eux refusent l'accès aux applications qui n'expliquent pas la raison de la demande de données du calendrier.

Le principe clé — une application ne doit demander l'accès que pour des fonctionnalités directement liées au calendrier : créer des rappels, synchroniser des événements, importer des horaires.

Comment fonctionne la demande d'accès au calendrier sur iOS

Sous iOS, l'accès au calendrier et aux rappels est fourni via un seul framework — EventKit. La classe centrale EKEventStore gère toutes les opérations : demander la permission, lire les événements, créer et modifier les entrées du calendrier. Lors du premier appel à requestAccess(to:entityType:), le système affiche une boîte de dialogue native avec une explication.

EventKit et EKEventStore

La classe EKEventStore est le point d'entrée vers le sous-système de calendrier iOS. Pour demander l'accès, vous devez appeler la méthode requestAccess(to: .event) en passant le type d'entité (événement ou rappel). Après avoir obtenu la permission, EKEventStore donne accès à tous les calendriers connectés à iCloud, Google, Exchange et d'autres fournisseurs.

Une caractéristique importante : EKEventStore est un objet lourd — sa création prend du temps et consomme des ressources. Il est recommandé de l'initialiser une seule fois et de le réutiliser tout au long du cycle de vie de l'application. Selon la WWDC Session 10117 (2024), Apple recommande de mettre en cache l'instance d'EventStore pour optimiser les performances.

Types d'accès : lecture et écriture

iOS ne sépare pas les permissions de lecture et d'écriture du calendrier — l'utilisateur accorde soit un accès complet, soit le refuse. Cependant, l'application peut contrôler les opérations au niveau du code : lire les événements via EKEventStore.event, créer via EKEventStore.save et supprimer via EKEventStore.remove. Depuis iOS 18, il est possible de demander l'accès uniquement à un type d'entité spécifique — .event ou .reminder.

Sous iOS 17+, Apple a introduit un mécanisme d'accès temporaire : certaines applications peuvent obtenir un accès pour 24 heures après une confirmation unique de l'utilisateur. Cette fonction est particulièrement utile pour les applications qui ont besoin d'un accès ponctuel au calendrier — par exemple, pour importer le programme d'une conférence.

Comment fonctionne la demande d'accès au calendrier sur Android

Sous Android, l'accès au calendrier est protégé par deux permissions distinctes : READ_CALENDAR et WRITE_CALENDAR. Toutes deux appartiennent à la catégorie dangereuse et nécessitent des demandes d'exécution. La séparation de la lecture et de l'écriture permet à l'utilisateur d'ajuster finement le niveau d'accès de l'application.

READ_CALENDAR et WRITE_CALENDAR

La permission READ_CALENDAR permet à l'application de lire les événements de tous les calendriers de l'utilisateur, y compris les noms, heures, participants et descriptions. La permission WRITE_CALENDAR permet de créer, modifier et supprimer des événements. Les deux sont spécifiées dans le manifeste via la balise uses-permission et demandées au moment de l'exécution via ActivityResultLauncher.

À partir d'Android 14 (API 34), le système avertit l'utilisateur si une application demande les deux permissions simultanément. Il est recommandé de les demander séparément : d'abord READ_CALENDAR pour la lecture, puis WRITE_CALENDAR lors de la première tentative de création d'un événement. Selon Google I/O 2024, cette approche réduit le taux de refus de 23 %.

CalendarContract ContentProvider

CalendarContract est un ContentProvider Android qui structure les données du calendrier dans des tables relationnelles. Les principales tables incluent : Calendars (liste des calendriers), Events (événements), Attendees (participants), Reminders (notifications). L'accès aux données se fait via ContentResolver.query() avec une URI et une projection spécifiées.

Pour insérer un nouvel événement, vous devez utiliser ContentValues en spécifiant le calendrier, l'heure de début et de fin, le titre et la description. CalendarContract prend en charge les fuseaux horaires, les événements récurrents et les rappels avec des intervalles de notification personnalisables.

Exemples de code pour travailler avec le calendrier

L'implémentation des demandes d'accès au calendrier nécessite de prendre en compte les fonctionnalités spécifiques à chaque plateforme. Vous trouverez ci-dessous des exemples en Swift et Kotlin démontrant le travail correct avec EventKit et CalendarContract.

Accès au calendrier en Swift

La demande d'accès au calendrier iOS se fait via la méthode requestAccess de la classe EKEventStore. L'exemple ci-dessous montre la création d'un événement après l'obtention de la permission.

import EventKit

let eventStore = EKEventStore()

eventStore.requestAccess(to: .event) { granted, error in
    guard granted else {
        print("Accès au calendrier refusé")
        return
    }

    let event = EKEvent(eventStore: eventStore)
    event.title = "Réunion d'équipe"
    event.startDate = Date()
    event.endDate = Date(timeIntervalSinceNow: 3600)
    event.calendar = eventStore.defaultCalendarForNewEvents

    do {
        try eventStore.save(event, span: .thisEvent)
        print("Événement créé : \(event.eventIdentifier)")
    } catch {
        print("Erreur de sauvegarde : \(error.localizedDescription)")
    }
}

Accès au calendrier en Kotlin

Sous Android, la demande des permissions READ_CALENDAR et WRITE_CALENDAR se fait via ActivityResultLauncher. L'exemple montre la lecture d'événements depuis le calendrier de l'utilisateur après l'obtention de l'accès.

val calendarPermissionLauncher =
    registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->
        if (permissions[Manifest.permission.READ_CALENDAR] == true) {
            val uri = CalendarContract.Events.CONTENT_URI
            val projection = arrayOf(
                CalendarContract.Events.TITLE,
                CalendarContract.Events.DTSTART,
                CalendarContract.Events.DTEND
            )
            val cursor = contentResolver.query(uri, projection, null, null, null)
            cursor?.use {
                val titleIndex = it.getColumnIndex(CalendarContract.Events.TITLE)
                while (it.moveToNext()) {
                    Log.d("Calendrier", "Événement : ${it.getString(titleIndex)}")
                }
            }
        } else {
            // Afficher l'explication et suggérer d'aller dans les paramètres
            requestPermissionSettingsRedirect()
        }
    }

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    calendarPermissionLauncher.launch(
        arrayOf(Manifest.permission.READ_CALENDAR, Manifest.permission.WRITE_CALENDAR)
    )
}

Bonnes pratiques pour demander l'accès au calendrier

Travailler avec les permissions de calendrier nécessite une stratégie réfléchie qui prend en compte les exigences des deux plateformes et les attentes de l'utilisateur. Suivre les recommandations ci-dessous aide à passer la modération et à augmenter le taux d'octroi des permissions.

Minimisation et contexte de la demande

Demandez l'accès au calendrier uniquement lorsque l'utilisateur effectue une action nécessitant des données du calendrier : « Ajouter au calendrier », « Synchroniser l'agenda », « Importer des événements ». Une boîte de dialogue pré-autorisation (une boîte de dialogue personnalisée avant celle du système) augmente le taux de consentement de 35 %, selon Localytics (2024).

Sous iOS, utilisez la clé NSCalendarsUsageDescription dans le manifeste de confidentialité avec un texte spécifique. Au lieu de « Pour créer des événements », écrivez « Pour ajouter des entraînements à votre calendrier ». Une formulation spécifique augmente le taux de conversion de la demande de 20 à 30 %.

Gestion du refus et redirection vers les paramètres

Si l'utilisateur refuse la demande, n'affichez pas à nouveau la boîte de dialogue système — cela déclenchera neverAskAgain sur Android ou rendra la boîte de dialogue indisponible sur iOS. Proposez plutôt d'aller dans les paramètres via Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS) sur Android ou UIApplication.openSettingsURLString sur iOS.

Lors de la réentrée sur l'écran, vérifiez l'état de la permission. Sur iOS, appelez EKEventStore.authorizationStatus(for: .event) et mettez à jour l'interface utilisateur en fonction de l'état actuel. Sur Android, utilisez ContextCompat.checkSelfPermission() pour vérifier l'état actuel et décider d'afficher le bouton de redirection vers les paramètres.