ATT iOS : ce que c’est, mécanisme de demande de suivi et IDFA

Qu’est-ce qu’ATT (App Tracking Transparency) ?

App Tracking Transparency est un framework d’Apple pour protéger la confidentialité des utilisateurs, présenté dans iOS 14.5. Il exige que les applications obtiennent une autorisation explicite pour accéder à l’identifiant publicitaire de l’appareil (IDFA) avant de l’utiliser pour le suivi.

Avant ATT, les développeurs pouvaient lire l’IDFA sans demander la permission, ce qui permettait aux réseaux publicitaires de créer des profils d’utilisateurs et de suivre leur activité entre les applications et les sites web. Apple a considéré cela comme une violation de la vie privée et a introduit une boîte de dialogue de consentement obligatoire.

Le framework est disponible depuis iOS 14.0, mais est devenu obligatoire pour toutes les applications utilisant IDFA avec la sortie d’iOS 14.5 en avril 2021. Selon Flurry Analytics, après la mise en œuvre d’ATT, moins de 25 % des utilisateurs américains ont consenti au suivi, ce qui a fondamentalement changé le marché de la publicité mobile.

ATT vérifie l’autorisation via une boîte de dialogue système spéciale que l’application ne peut ni modifier ni contourner. L’utilisateur voit un popup standard avec le texte fourni par le développeur et choisit « Autoriser » ou « Demander à l’application de ne pas suivre ».

Comment ATT est lié à la confidentialité dans iOS

Apple positionne ATT dans le cadre de sa stratégie globale de confidentialité, qui comprend également les étiquettes nutritionnelles de confidentialité dans l’App Store et le Manifeste de confidentialité. Les trois mécanismes fonctionnent ensemble : les étiquettes montrent les données collectées par l’application, le Manifeste déclare les raisons de l’utilisation des API, et ATT donne à l’utilisateur le contrôle sur le suivi.

Refuser le suivi ne bloque pas le fonctionnement de l’application elle-même — les utilisateurs peuvent continuer à utiliser toutes les fonctionnalités, mais les réseaux publicitaires ne recevront pas l’IDFA pour la personnalisation et l’attribution. Les alternatives d’Apple à l’IDFA incluent SKAdNetwork et l’attribution probabiliste.

Selon Branch Metrics, après l’introduction d’ATT, la proportion d’applications recevant l’IDFA est passée de 70 % à 20 % à l’échelle mondiale. Cela a conduit à une refonte des approches d’attribution d’installations et de monétisation publicitaire.

Changements dans iOS 15 et 16

Dans iOS 15, Apple n’a pas renforcé les exigences d’ATT mais a ajouté le rapport de confidentialité des applications — un rapport montrant à l’utilisateur la fréquence d’accès des applications aux capteurs et aux données. iOS 16 a élargi le contrôle : l’utilisateur peut modifier à tout moment ses paramètres de suivi via Réglages → Confidentialité → Suivi.

Important : si l’utilisateur sélectionne « Demander à l’application de ne pas suivre » dans la boîte de dialogue ATT, l’application ne reçoit pas la valeur IDFA — elle renvoie à la place une chaîne de zéros : 00000000-0000-0000-0000-000000000000. Tenter de lire l’IDFA par d’autres moyens ou par des méthodes de contournement entraîne le rejet de l’application dans l’App Store.

À partir d’iOS 17, Apple a renforcé les vérifications : si une application demande l’IDFA sans afficher la boîte de dialogue système ATT, elle reçoit un refus au niveau du système d’exploitation, et pas seulement un identifiant vide. Cela élimine la possibilité de collecte en arrière-plan de l’IDFA à l’insu de l’utilisateur.

Comment fonctionne la demande de suivi dans iOS

Le processus de demande ATT comprend trois étapes : vérification du statut, affichage de la boîte de dialogue système et traitement de la réponse. Le développeur ne peut sauter aucune étape — le système d’exploitation contrôle chaque étape.

Vérification du statut d’autorisation

Avant d’appeler la boîte de dialogue, l’application doit vérifier le statut actuel via ATTrackingManager. Les statuts possibles sont : notDetermined (pas encore demandé), restricted (interdit par les politiques de l’appareil), denied (utilisateur refusé), authorized (autorisé).

Si le statut est déjà déterminé (authorized ou denied), la boîte de dialogue ne peut pas être rappelée — l’utilisateur a pris une décision permanente. La seule façon de modifier la décision est via les réglages système d’iOS.

Pour vérifier le statut, on utilise la propriété ATTrackingManager.trackingAuthorizationStatus. L’appel doit avoir lieu sur le thread principal car la boîte de dialogue système est un composant d’interface utilisateur.

import AppTrackingTransparency
import AdSupport

func checkTrackingStatus() {
    let status = ATTrackingManager.trackingAuthorizationStatus
    switch status {
    case .notDetermined:
        requestTrackingPermission()
    case .authorized:
        readIDFA()
    case .denied, .restricted:
        useAlternativeTracking()
    @unknown default:
        break
    }
}

Affichage de la boîte de dialogue système

Pour afficher la boîte de dialogue, on appelle la méthode requestTrackingAuthorization avec une closure qui reçoit le résultat du choix de l’utilisateur. Important : la boîte de dialogue ne s’affiche qu’une seule fois. Si le développeur tente de l’appeler à nouveau, le système ignore la demande.

Le texte de la boîte de dialogue se compose de deux parties : un en-tête système (qui ne peut pas être modifié) et un message personnalisé que le développeur spécifie dans Info.plist via la clé NSUserTrackingUsageDescription.

La boîte de dialogue doit apparaître dans un contexte naturel — pas immédiatement au démarrage de l’application, mais lors de la première tentative d’utilisation d’une fonctionnalité liée au suivi. Apple recommande d’afficher la boîte de dialogue après que l’utilisateur a compris la valeur de la fonctionnalité.

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        DispatchQueue.main.async {
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier
                print("IDFA: \(idfa)")
            case .denied:
                print("L’utilisateur a refusé le suivi")
            default:
                break
            }
        }
    }
}

IDFA et restriction d’accès

IDFA (Identifier for Advertisers) est un identifiant publicitaire unique pour les appareils iOS, utilisé pour la publicité ciblée et l’attribution d’installations. Avant ATT, les développeurs l’obtenaient via ASIdentifierManager sans restrictions. Après ATT, l’accès à l’IDFA est bloqué jusqu’à ce que l’utilisateur donne son consentement explicite.

Qu’est-ce que l’IDFA et pourquoi est-il nécessaire

L’IDFA est une chaîne UUID unique pour chaque appareil iOS. Les réseaux publicitaires utilisent l’IDFA pour : suivre les installations d’applications (attribution), afficher des publicités pertinentes basées sur les intérêts de l’utilisateur, mesurer l’efficacité des campagnes publicitaires et le reciblage — ramener les utilisateurs qui n’ont pas terminé une action souhaitée.

Après le refus de suivi par l’utilisateur, ASIdentifierManager renvoie la valeur 00000000-0000-0000-0000-000000000000. L’application peut toujours lire l’IDFA à des fins techniques (comme l’antifraude), mais ne peut pas le transmettre aux réseaux publicitaires.

Selon Singular (2024), le taux de consentement global à ATT est de 25 à 35 %, l’Europe (RGPD) affichant des taux plus élevés (40 à 50 %) que les États-Unis (15 à 25 %). Cela a poussé les plateformes publicitaires à développer des méthodes d’attribution alternatives.

Alternatives à l’IDFA : SKAdNetwork et attribution probabiliste

SKAdNetwork est un framework d’Apple pour l’attribution d’installations sans exposer l’IDFA. Il fonctionne au niveau du système d’exploitation : le réseau publicitaire envoie un postback signé, qu’Apple valide et transmet au développeur. L’attribution se fait sans identifier un utilisateur spécifique, seulement au niveau de la campagne.

L’attribution probabiliste utilise de multiples signaux de l’appareil — modèle, version d’iOS, fuseau horaire, luminosité de l’écran — pour faire correspondre probabilistiquement les installations aux impressions publicitaires. Cependant, Apple interdit cette méthode dans ses directives, et son utilisation peut entraîner le rejet de l’application.

Google, Adjust et AppsFlyer ont développé leurs propres solutions hybrides combinant SKAdNetwork avec des données agrégées propriétaires. Par exemple, Google Ads Conversion Tracking utilise les postbacks SKAdNetwork et ses propres modèles de machine learning pour l’attribution sans IDFA.

Implémentation d’ATT dans le code de l’application

Pour intégrer ATT, vous devez ajouter la clé NSUserTrackingUsageDescription dans Info.plist et importer le framework AppTrackingTransparency. Voici les étapes pour Swift et Objective-C.

Configuration d’Info.plist

La première étape consiste à ajouter la clé NSUserTrackingUsageDescription dans Info.plist avec un texte expliquant pourquoi l’application a besoin de suivi. Ce texte s’affichera dans la boîte de dialogue système. Exemple : « Votre IDFA est utilisé pour afficher des publicités personnalisées et suivre l’efficacité des campagnes. »

Sans cette clé, l’appel de requestTrackingAuthorization entraînera un plantage de l’application — Apple vérifie explicitement la présence de NSUserTrackingUsageDescription avant d’afficher la boîte de dialogue. Le texte doit être concis, spécifique et refléter l’utilisation réelle des données.

Important : la clé est ajoutée manuellement via l’onglet Info de Xcode ou en modifiant le source XML d’Info.plist. Après l’ajout, reconstruisez le projet et vérifiez que la clé apparaît dans le binaire final.

<!-- Info.plist -->
<key>NSUserTrackingUsageDescription</key>
<string>This identifier is used to deliver
personalized ads and measure campaign performance.</string>

Intégration complète en Swift

Dans un projet réel, il est préférable d’appeler la demande ATT avant le premier lancement d’un module publicitaire ou d’un tracker. Il est recommandé d’expliquer d’abord la valeur du consentement sur un écran séparé (invite de pré-autorisation) — cela augmente les taux de consentement de 20 à 30 %.

Une invite de pré-autorisation est une interface utilisateur personnalisée qui montre l’avantage d’activer le suivi (« Aidez-nous à vous montrer des publicités pertinentes »). Ce n’est qu’après avoir appuyé sur « Continuer » que la boîte de dialogue système ATT apparaît. Adjust (2024) a enregistré une augmentation de 40 % du consentement lors de l’utilisation d’un écran de pré-autorisation.

final class TrackingManager {
    static let shared = TrackingManager()

    func requestTrackingIfNeeded() {
        guard ATTrackingManager.trackingAuthorizationStatus
            == .notDetermined
        else { return }

        ATTrackingManager.requestTrackingAuthorization { _ in
            NotificationCenter.default.post(
                Notification(Name("trackingStatusChanged"))
            )
        }
    }
}

Erreurs lors du travail avec ATT

Les développeurs commettent souvent des erreurs typiques lors de l’intégration d’ATT, qui entraînent une baisse du taux de consentement ou le rejet de l’application par les examinateurs de l’App Store. Examinons les cinq problèmes les plus courants.

Demander ATT immédiatement après le lancement de l’application

L’erreur la plus fréquente est d’afficher la boîte de dialogue système ATT sur le premier écran juste après le chargement de l’application. L’utilisateur ne comprend pas encore la valeur de l’application et est très susceptible d’appuyer sur « Refuser ». IronSource (2023) a montré une baisse de 32 % du consentement lors de la demande sur le premier écran par rapport à la demande après la troisième session.

Recommandation : demandez le suivi après que l’utilisateur a effectué une action de valeur (consulté du contenu, commencé l’intégration) ou après 3 à 5 sessions d’utilisation. Cela augmente la confiance et la perception de la valeur.

Absence d’écran de pré-autorisation

Afficher la boîte de dialogue système ATT sans explication préalable est une erreur qui fait chuter la conversion à 15 – 20 %. L’utilisateur voit une demande inattendue et la refuse instinctivement. Un écran de pré-autorisation expliquant l’avantage augmente le consentement à 35 – 45 %.

Le texte de pré-autorisation doit être spécifique : « Autorisez-nous à afficher des publicités pertinentes — cela nous aide à rester gratuits. » Évitez les phrases vagues — elles diminuent la confiance. GameAnalytics a montré en 2023 qu’un écran de pré-autorisation expliquant l’avantage génère 28 % de consentements de plus qu’un écran vide.

Ignorer le statut restricted et denied

Si l’utilisateur a déjà refusé le suivi ou que le statut est restricted (contrôle parental, politiques d’entreprise), l’application ne doit pas rappeler la boîte de dialogue ATT. Un appel répété ne fonctionne pas et est perçu comme une violation de la vie privée. Passez plutôt à SKAdNetwork et à la publicité contextuelle.

Dans le statut restricted, l’application ne peut pas déterminer si l’option « Autoriser les demandes de suivi » est activée dans les réglages. Dans ce cas, utilisez toujours SKAdNetwork comme seule méthode d’attribution et n’affichez pas d’écran de pré-autorisation.

Lire l’IDFA sans appeler ATT

Lire l’IDFA via ASIdentifierManager.shared().advertisingIdentifier sans autorisation ATT préalable renvoie une chaîne de zéros. Certains développeurs tentent d’utiliser d’anciennes méthodes d’accès à l’IDFA via des API privées — cela garantit le rejet lors de l’examen de l’application.

Apple utilise l’analyse statique de code et le machine learning pour détecter les contournements. Même si l’application passe l’examen, les mises à jour ultérieures ou les vérifications automatiques peuvent révéler la violation et entraîner l’interdiction du compte développeur.

Texte incorrect de NSUserTrackingUsageDescription

Un texte trop long, vague ou trompeur dans la clé NSUserTrackingUsageDescription est un motif de rejet par les examinateurs. Apple vérifie que la description correspond à l’utilisation réelle des données. Si l’application n’a pas de publicité mais mentionne « à des fins publicitaires », l’examinateur rejettera le build.

Format recommandé : une description spécifique de l’objectif d’utilisation de l’IDFA, de 2 à 3 phrases. Exemple pour une application sans publicité : « L’identifiant est utilisé pour l’analyse et la prévention de la fraude. Les données ne sont pas partagées avec des tiers et ne sont pas utilisées pour le profilage. »