IDFA : qu'est-ce que c'est, comment ça marche et demande d'autorisation dans iOS

Qu'est-ce que l'IDFA ?

IDFA (Identifier for Advertisers) est un identifiant alphanumérique unique attribué à chaque appareil Apple à des fins publicitaires. Contrairement à l'IDFV (Identifier for Vendor), l'IDFA est commun à toutes les applications sur l'appareil et peut être réinitialisé à tout moment par l'utilisateur via Réglages — Confidentialité — Publicité — Réinitialiser l'identifiant.

L'objectif principal de l'IDFA est l'attribution d'installations et le suivi de l'efficacité des campagnes publicitaires sur les appareils Apple. Les réseaux publicitaires utilisent l'IDFA pour lier un clic sur une annonce à l'installation d'une application, créer des profils d'utilisateurs et afficher des publicités personnalisées. Depuis la mise en œuvre de l'ATT, le pourcentage d'utilisateurs accordant l'accès à l'IDFA est en moyenne de 20 à 35% selon diverses plateformes d'analyse.

Selon Flurry Analytics (2025), après iOS 18, le taux d'adoption de l'ATT a atteint 92% des appareils actifs, mais la part d'utilisateurs acceptant le suivi est tombée à 22%. Cela a entraîné un changement fondamental dans l'industrie de la publicité mobile, forçant les réseaux publicitaires à rechercher des méthodes d'attribution alternatives.

Une caractéristique clé de l'IDFA est qu'il ne contient pas de données personnelles de l'utilisateur et n'est pas lié à un Apple ID. Cependant, Apple le classe comme un identifiant soumis à la réglementation App Tracking Transparency.

Comment fonctionnent l'IDFA et App Tracking Transparency

App Tracking Transparency (ATT) est un framework Apple présenté dans iOS 14.5 qui exige le consentement explicite de l'utilisateur avant de lire l'IDFA. Sans consentement, la méthode asIdentifierManager retourne un identifiant nul (00000000-0000-0000-0000-000000000000) et l'application ne peut pas suivre l'utilisateur.

Framework App Tracking Transparency

ATT est implémenté via la classe ATTrackingManager avec une seule méthode publique requestTrackingAuthorization(completionHandler:). Lorsque cette méthode est appelée, le système affiche une boîte de dialogue native avec le texte défini par le développeur via la clé NSUserTrackingUsageDescription dans Info.plist. L'utilisateur peut choisir l'une des trois options : « Autoriser le suivi », « Demander à l'application de ne pas suivre » ou « Refuser ».

Le statut d'autorisation est suivi via ATTrackingManager.trackingAuthorizationStatus, qui peut prendre quatre valeurs : notDetermined, restricted, denied ou authorized. Avant de demander ATT, il est recommandé de vérifier le statut actuel et de ne pas appeler la boîte de dialogue si le statut est déjà déterminé — à partir d'iOS 17, appeler à nouveau requestTrackingAuthorization avec un statut denied n'affiche pas la boîte de dialogue et retourne une erreur.

Quand demander l'autorisation

Le moment de la demande ATT affecte de manière critique les taux de consentement. Les recherches de Singular (2025) montrent que demander ATT sur l'écran d'intégration (au premier lancement) donne un taux de conversion de 35 à 45%, tandis que le demander après avoir terminé une action (par exemple, après l'inscription) augmente la conversion à 55–65%. Il est recommandé d'afficher un écran de pré-autorisation avec un design personnalisé expliquant la valeur du suivi à l'utilisateur avant la boîte de dialogue ATT système.

Important : l'application ne peut appeler requestTrackingAuthorization qu'une seule fois avant de recevoir une réponse. Une fois que l'utilisateur a choisi « Refuser » ou « Demander à l'application de ne pas suivre », la boîte de dialogue n'apparaîtra plus sur l'appareil. Le développeur doit implémenter des mécanismes de secours pour travailler sans IDFA afin que l'application continue de fonctionner correctement dans des conditions de suivi limité.

Exigences iOS 18+ pour le suivi

Avec la sortie d'iOS 18, Apple a renforcé les exigences pour les applications utilisant l'identifiant publicitaire. Toutes les applications qui demandent l'IDFA ou transmettent des données d'appareil à des fins publicitaires doivent se conformer aux nouvelles règles de l'App Store. Le non-respect entraîne le rejet du build lors de l'examen App Store Connect.

Privacy Manifest et suivi

À partir d'iOS 18, chaque application doit inclure un Privacy Manifest (fichier privacy.xcprivacy) déclarant toutes les API utilisées pour le suivi. Pour l'IDFA, les clés NSPrivacyTracking et NSPrivacyTrackingDomains sont utilisées pour spécifier les domaines des réseaux publicitaires auxquels l'identifiant est transmis. Sans un manifeste correct, l'application est rejetée lors de la modération App Store Connect.

Apple a également introduit l'exigence de spécifier la raison de l'utilisation de l'identifiant publicitaire dans la description de l'application. Si l'application utilise l'IDFA pour l'attribution d'installations, elle doit utiliser SKAdNetwork comme méthode principale, et l'IDFA uniquement comme signal supplémentaire pour améliorer la précision de l'attribution.

Alternatives à l'IDFA

Avec les restrictions croissantes sur l'IDFA, l'industrie a développé plusieurs approches alternatives. SKAdNetwork (StoreKit Ad Network) est le mécanisme d'attribution officiel d'Apple qui fonctionne sans IDFA et ne nécessite pas le consentement de l'utilisateur. SKAdNetwork utilise des requêtes postback signées entre le réseau publicitaire et l'App Store, garantissant la confidentialité de l'utilisateur.

D'autres alternatives incluent : l'attribution probabiliste basée sur l'adresse IP, la version de l'OS et d'autres signaux de l'appareil ; les API agrégées privées comme Private Click Measurement (PCM) de WebKit ; et les solutions propriétaires des plateformes publicitaires utilisant l'apprentissage automatique pour prédire les conversions. Pour le marché chinois, le CAID (Cellular Advertising ID) basé sur les données du réseau de l'opérateur mobile est également utilisé.

Exemples de code pour demander l'IDFA

Implémenter une demande d'IDFA nécessite d'intégrer App Tracking Transparency et de gérer correctement tous les statuts d'autorisation possibles. Voici un exemple complet pour Swift avec un écran de pré-autorisation.

Demande ATT en Swift

L'exemple démontre le flux de travail complet avec l'IDFA : vérification du statut, affichage d'un écran de pré-autorisation, appel de la boîte de dialogue ATT système et obtention de l'identifiant après autorisation.

import AppTrackingTransparency
import AdSupport

func requestIDFAAccess() {
    let status = ATTrackingManager.trackingAuthorizationStatus

    switch status {
    case .notDetermined:
        // Affichage de l'écran de pré-autorisation avec explication
        showPrePermissionScreen { accepted in
            guard accepted else { return }
            ATTrackingManager.requestTrackingAuthorization { newStatus in
                handleATTStatus(newStatus)
            }
        }
    case .authorized:
        // L'utilisateur a déjà donné son consentement — obtention de l'IDFA
        let idfa = ASIdentifierManager.shared().advertisingIdentifier
        print("IDFA : \(idfa.uuidString)")
    case .denied, .restricted:
        // Redirection de l'utilisateur vers les paramètres
        redirectToSettings()
    @unknown default:
        break
    }
}

private func handleATTStatus(status: ATTrackingManager.AuthorizationStatus) {
    if status == .authorized {
        let idfa = ASIdentifierManager.shared().advertisingIdentifier
        // Transmission de l'IDFA au réseau publicitaire
        sendIDFAToAdNetwork(idfa.uuidString)
    }
}

Stratégies pour travailler sans IDFA

Étant donné que la majorité des utilisateurs refusent la demande ATT, les développeurs ont besoin d'un ensemble de stratégies pour travailler efficacement sans l'identifiant. L'approche principale est une combinaison de SKAdNetwork et de méthodes d'attribution probabilistes.

SKAdNetwork et attribution

SKAdNetwork (SKAN) est un framework Apple pour l'attribution d'installations qui ne nécessite pas d'IDFA et n'affiche pas de boîte de dialogue de consentement. Le réseau publicitaire enregistre son ID SKAdNetwork dans le Info.plist de l'application, et après l'installation, l'App Store envoie un postback signé avec les informations de la campagne. SKAN 4.0, présenté dans iOS 17, prend en charge les conversions multiples, les identifiants de source et les valeurs de conversion à granularité grossière.

Limitations de SKAN : délai de postback de 24 à 48 heures, absence d'identifiant utilisateur et valeurs de conversion limitées (jusqu'à 64). Malgré cela, SKAN est devenu le standard de facto pour l'attribution iOS après la mise en œuvre de l'ATT, et tous les grands réseaux publicitaires doivent le prendre en charge pour fonctionner sur les appareils Apple.

Identifiants prédictifs

Des réseaux publicitaires comme Meta et Google ont développé leurs propres solutions basées sur l'apprentissage automatique qui prédisent les conversions sans identifiant utilisateur. Meta Aggregated Events Measurement (AEM) utilise des données agrégées pour l'attribution, tandis que Google Attribution modélise les conversions sur la base de données historiques.

Pour le développeur, il est important d'implémenter plusieurs méthodes d'attribution simultanément : SKAdNetwork comme méthode principale, l'attribution côté serveur via les réseaux publicitaires et des outils d'analyse propriétaires avec modélisation des conversions. La combinaison de méthodes permet de récupérer jusqu'à 70–80% de la précision d'attribution par rapport à l'ère de l'IDFA. Il est recommandé de tester différentes combinaisons de méthodes pendant la phase de test bêta afin de sélectionner l'ensemble optimal pour l'application et le public cible spécifiques.