Apple visé par une poursuite antitrust au Royaume-Uni concernant l'ATT ? Le 3 septembre 2026, une demande de recours collectif a été déposée devant le Competition Appeal Tribunal (CAT) britannique, alléguant que le cadre App Tracking Transparency (ATT) d'Apple imposait des restrictions anticoncurrentielles aux développeurs tiers tout en favorisant ses propres services publicitaires, estimant les dommages causés aux développeurs britanniques à près de 2 milliards de livres sterling. Pour les architectes mobiles, les directeurs de marketing à la performance et les ingénieurs en infrastructure de données, l'examen minutieux entourant l'attribution mobile préservant la vie privée met en lumière un changement fondamental régissant l'acquisition d'utilisateurs sur les plateformes mobiles. Suite à la restriction de l'accès à l'IDFA par l'ATT, conditionnée à une autorisation explicite de suivi, l'écosystème mobile s'est tourné vers des protocoles de mesure agrégés sur l'appareil et des entonnoirs de découverte Web-to-App de première partie. Évaluer le fonctionnement de l'attribution moderne sans recourir à la surveillance inter-applications nécessite d'examiner l'exposition juridique d'Apple parallèlement aux mécanismes techniques d'AdAttributionKit, aux niveaux d'anonymat des foules et à la persistance des paramètres liés à l'installation.
La plainte antitrust britannique de 2 milliards de livres sterling : allégations juridiques et gouvernance de plateforme
L'action collective déposée à Londres représente un défi juridique majeur pour la gouvernance des données de la plateforme Apple. Portée par une entité ad hoc nommée ATT Collective Action Limited, présidée par l'ancienne directrice principale de la Competition and Markets Authority (CMA) britannique, Ann Pope, et conseillée par le cabinet d'avocats Hausfeld, cette action en opt-out réclame des indemnités au nom des développeurs d'applications britanniques ayant monétisé via la publicité in-app ou acheté des emplacements publicitaires pour générer des installations d'applications iOS depuis l'introduction de l'ATT le 26 avril 2021.
En bref
- Réclamation d'indemnisation de 2 milliards de £ : Déposée devant le Competition Appeal Tribunal britannique le 3 septembre 2026, l'action en opt-out allègue qu'Apple a créé un terrain de jeu commercial inégal sous couvert de protection de la vie privée des consommateurs.
- Allégations d'auto-préférence : La plainte affirme que les développeurs tiers ont été soumis à des invites restrictives pour accéder aux identifiants publicitaires, tandis que le réseau publicitaire interne d'Apple s'est développé sur les surfaces de l'App Store sans barrières interstitielles équivalentes.
- État de la procédure : La plainte est en attente de certification par le tribunal ; les allégations n'ont pas été prouvées devant la justice et Apple a rejeté ces plaintes, soutenant que l'ATT applique des normes équivalentes pour protéger les données des consommateurs sur toutes les applications.
Selon les rapports de Reuters et les déclarations des plaignants publiées par Hausfeld, la poursuite soutient que, bien que la confidentialité des consommateurs soit une protection essentielle, Apple a introduit l'ATT unilatéralement sans consultation adéquate du secteur, perturbant les fondations économiques des éditeurs et développeurs indépendants.
Apple a rejeté ces allégations, déclarant que l'ATT a été conçu pour donner aux utilisateurs un contrôle granulaire sur la possibilité pour les applications externes de suivre leur activité sur des propriétés tierces. Apple maintient que tous les développeurs, y compris elle-même, sont soumis aux mêmes règles concernant le suivi inter-entreprises, et que l'ATT a été salué par les défenseurs de la vie privée dans le monde.
Avant que la plainte ne puisse passer au procès, le CAT doit déterminer s'il convient de certifier l'action comme étant recevable pour des procédures collectives. L'affaire rejoint d'autres litiges majeurs sur la plateforme devant le tribunal, notamment l'appel sur les commissions de l'App Store Kent v. Apple et la poursuite concernant le stockage cloud Which?.
+-------------------------------------------------------------------------+ | CHRONOLOGIE DE LA CONTROVERSE RÉGLEMENTAIRE ATT | +--------------------------+-----------------------+----------------------+ | Date / Période | Jalon de la plateforme| Impact opérationnel | +--------------------------+-----------------------+----------------------+ | 26 avril 2021 | Lancement obligatoire | iOS 14.5 bloque l'IDFA via une invite opt-in | | 2021–2025 | Transition écosystème | L'IDFA réduit favorise l'adoption des postbacks | | 2024–2026 | Expansion AAK & SKAN | AdAttributionKit étend les rapports d'attribution | | | | multi-fenêtres de conversion | | 3 septembre 2026 | Recours collectif CAT | Poursuite antitrust de 2Mds £ pour les dévs UK | | En attente (2026–2027) | Certification CAT | Le tribunal évalue la certification de l'action | +--------------------------+-----------------------+----------------------+
Analyse technique : De l'IDFA déterministe aux cadres de confidentialité agrégés
Pour évaluer les réalités opérationnelles sous-jacentes au litige, les équipes d'ingénierie doivent décortiquer l'évolution de l'architecture d'attribution iOS avant et après l'ATT.
Historiquement, les réseaux publicitaires mobiles s'appuyaient sur l'Identifier for Advertisers (ASIdentifierManager.shared().advertisingIdentifier). L'IDFA est un identifiant publicitaire spécifique à l'appareil — représenté par un UUID 128 bits — qui permettait une mesure déterministe entre différentes applications. Un réseau publicitaire pouvait enregistrer l'IDFA lors d'une interaction publicitaire, le transmettre à un fournisseur d'attribution, et le faire correspondre à l'IDFA interrogé lors du premier lancement de l'application installée, établissant ainsi un lien déterministe entre l'impression et la conversion.
Lorsque l'ATT est entré en vigueur, l'accès à l'IDFA a été placé derrière l'interface ATTrackingManager.requestTrackingAuthorization. Si un utilisateur choisit « Demander à ne pas suivre », ou si le suivi est restreint au niveau du système, l'API renvoie un UUID composé uniquement de zéros (00000000-0000-0000-0000-000000000000). Avec des taux d'acceptation bien inférieurs à une couverture universelle, le suivi inter-applications déterministe a cessé d'être une base fiable pour l'acquisition à grande échelle.
Pour fournir une attribution de campagne sans partager les identités des utilisateurs entre applications, Apple a introduit SKAdNetwork et ultérieurement AdAttributionKit. Notamment, AdAttributionKit fonctionne indépendamment du statut d'autorisation ATT de l'utilisateur, car ses résultats ne contiennent aucun identifiant de suivi spécifique à l'utilisateur ou à l'appareil.
Les mécanismes d'AdAttributionKit reposent sur trois principes architecturaux fondamentaux :
- Double validation cryptographique : Les réseaux publicitaires génèrent des impressions publicitaires signées cryptographiquement à l'aide de JSON Web Signatures (JWS). Lors de l'installation et de la conversion, le système d'exploitation vérifie le jeton d'impression sur l'appareil et génère ensuite un postback d'attribution signé cryptographiquement par Apple, permettant aux réseaux publicitaires de confirmer que la conversion a été certifiée par iOS.
- Fenêtres de remise de postback différées : Pour empêcher les réseaux publicitaires d'utiliser des horodatages d'installation précis pour exécuter des attaques par canal auxiliaire, les postbacks sont envoyés après des délais aléatoires. Apple documente un intervalle aléatoire minimum de 24 à 48 heures entre la préparation du postback et sa réception, le délai total de livraison s'étendant davantage car les fenêtres de conversion (telles que la fenêtre initiale de 48 heures) restent ouvertes à moins d'être verrouillées.
- Niveaux d'anonymat des foules (Crowd Anonymity) : Apple assigne les postbacks d'attribution à l'un des quatre niveaux d'anonymat (Niveau 0 à Niveau 3) déterminé par les conditions au sein de la source publicitaire, de l'application promue, de la zone géographique d'installation et de l'identifiant source hiérarchique. Dans les niveaux inférieurs, les champs de postback sont restreints : les valeurs de conversion fines (0 à 63) sont remplacées par des valeurs grossières (
faible,moyen,élevé) ou totalement omises au Niveau 0, et l'identifiant source est tronqué de quatre chiffres à deux.
+-------------------------------------------------------------------------+ | IDFA DÉTERMINISTE VS. ATTRIBUTION AGRÉGÉE (CONFIDENTIALITÉ) | +-------------------------------------------------------------------------+ | | | [ PARADIGME DÉTERMINISTE PRÉ-ATT ] | | Impression publicitaire (Enregistre l'IDFA : UUID-1) | | | | | v | | Premier lancement app (Lit l'IDFA : UUID-1) | | Résultat : Attribution publicitaire déterministe, en temps réel. | | | +-------------------------------------------------------------------------+ | | | [ PROTOCOLE AGRÉGÉ POST-ATT : AdAttributionKit / SKAN ] | | | | Impression publicitaire (Jeton JWS signé par le réseau) | | | | | v | | [ L'utilisateur installe via l'App Store ] | | | | | v | | [ Traitement d'attribution sur l'appareil ] | | | | | |-- (Calcule fenêtres conversion : délai aléatoire 24-48h) | | |-- (Applique masquage de niveau d'anonymat 0-3) | | v | | [ Postback anonyme signé par Apple envoyé au réseau publicitaire ] | | Payload : Valeur grossière, fine, ou nulle (selon niveau) | | Identifiant source (2-4 chiffres) | | | +-------------------------------------------------------------------------+
Bien qu'AdAttributionKit soit conçu pour mesurer l'efficacité des campagnes tout en réduisant l'exposition des données au niveau de l'utilisateur, ses retours différés et ses rapports agrégés présentent des défis opérationnels pour les enchères algorithmiques en temps réel.
Acquisition mobile en aval et frontière d'installation de première partie
Comme le suivi des utilisateurs entre applications a connu une fidélité des données réduite sous les modèles de postback agrégés, les équipes de marketing à la performance ont accru leur dépendance envers les entonnoirs Web-to-App. Dans une architecture Web-to-App, l'acquisition d'utilisateurs commence sur une propriété web mobile propriétaire de première partie.
Selon les directives de confidentialité d'Apple, le suivi est spécifiquement défini comme le fait de lier les données d'un utilisateur ou d'un appareil collectées à partir de l'application d'une entreprise avec des données collectées à partir des applications, sites web ou propriétés hors ligne d'autres entreprises, à des fins de publicité ciblée ou de mesure. Lorsqu'un annonceur dirige le trafic vers son propre site web (par exemple, https://brand.example.com), cette interaction se déroule dans un contexte de première partie. Engager les utilisateurs, présenter des offres promotionnelles et capturer l'intention d'achat sur un domaine propriétaire ne constitue pas un suivi inter-entreprises, à condition que les données résultantes ne soient pas croisées avec des ensembles de données tiers.
Cependant, faire passer un utilisateur d'une page de destination mobile de première partie vers une application iOS native introduit la frontière d'installation :
+-------------------------------------------------------------------------+ | PARCOURS D'ACQUISITION MOBILE AVAL SÉPARÉ | +-------------------------------------------------------------------------+ | | | [ L'utilisateur atterrit sur une page web mobile de première partie ] | | Contexte capturé : ?channel=partner_promo&discount=SAVE20&sku=8831 | | | | | v | | [ L'utilisateur clique sur le CTA de téléchargement de l'app ] | | | | | v | | [ Redirection vers l'Apple App Store ] | | | | | v | | [ LA FRONTIÈRE D'INSTALLATION : Le flux standard de téléchargement | | ne transfère pas les paramètres de requête web vers le binaire ] | | | | | v | | [ L'utilisateur ouvre l'application pour la première fois ] | | | | | v | | [ Moteur de Deep Linking Différé (Restauration assistée serveur) ] | | | | | v | | [ Paramètres pré-installation éligibles restaurés et onboarding ] | | | +-------------------------------------------------------------------------+
Lorsqu'un utilisateur non installé passe de Safari à l'App Store, les flux de distribution standard ne transfèrent pas les chaînes de requête URL arbitraires dans le package de l'application installée. Lors du premier lancement, l'application native ne peut pas identifier nativement quelle campagne web ou page produit spécifique a dirigé l'utilisateur.
Pour franchir cette frontière sans dépendre d'identifiants de suivi inter-entreprises non autorisés, les équipes d'ingénierie mettent en œuvre des architectures de gestion de liens distinctes :
| Architecture de routage | État app utilisateur | Conservation paramètres après installation | Architecture de confidentialité plateforme |
|---|---|---|---|
| Universal Links vérifiés | App cible installée | Contourne l'App Store ; navigation directe | Utilise l'association domaine-app HTTPS ; dépend des données collectées |
| AdAttributionKit / SKAN | App cible absente | Postback agrégé ; pas de paramètres de requête | Mesure agrégée ; délai 24-48h ; pas de contexte au niveau ligne |
| Deferred Deep Linking (DDL) | App cible absente | Restaure les paramètres pré-installation au 1er boot | Restauration assistée par serveur, soumise aux règles de la plateforme |
Dans les architectures de production, les équipes de développement déploient des cadres de Deferred Deep Linking tels que Branch, AppsFlyer, Adjust ou Opoinstall. Une plateforme comme Opoinstall capture le contexte de campagne éligible (tel que des jetons promotionnels ou des SKU de produits) sur la page de destination du marchand avant de rediriger l'utilisateur vers l'App Store.
Lors du premier lancement de l'application, le SDK client interroge l'infrastructure d'attribution pour restaurer les paramètres de session mis en cache. Selon la documentation de la plateforme sur la page d'accueil d'Opoinstall, ce cadre de transmission différée des paramètres peut restaurer les paramètres lors du premier lancement dans jusqu'à 98 % des instances éligibles, offrant une alternative automatisée aux codes promotionnels manuels.
Il est crucial de maintenir des frontières architecturales claires : Le deferred deep linking ne recrée pas d'événements de mesure tiers jamais observés, et ne contourne pas les règles de suivi de la plateforme. Il restaure un contexte de destination, de campagne ou de référence éligible déjà capturé dans un parcours de première partie autorisé avant que la frontière d'installation ne soit franchie.
// Implémentation Swift illustrant la restauration du contexte au premier lancement.
// Consomme les paramètres d'attribution différée éligibles lors du boot à froid
// sans dépendre d'identifiants publicitaires inter-applications (IDFA).
import UIKit
struct AttributionPayload: Decodable {
let channel: String
let campaignId: String
let targetRoute: String
let promoCode: String?
}
final class FirstLaunchAttributionManager {
static let shared = FirstLaunchAttributionManager()
// Flag d'état de lancement local (pas un identifiant d'attribution ou d'appareil)
private let hasCompletedFirstLaunchKey = "com.app.hasCompletedFirstLaunchRestoration"
private init() {}
/// Indique si l'application a terminé avec succès la restauration des paramètres au premier lancement
var isRestorationPending: Bool {
return !UserDefaults.standard.bool(forKey: hasCompletedFirstLaunchKey)
}
/// Marque le processus de restauration comme résolu pour éviter les exécutions redondantes
func markRestorationCompleted() {
UserDefaults.standard.set(true, forKey: hasCompletedFirstLaunchKey)
}
/// Récupère les paramètres de pré-installation éligibles via un callback SDK.
func handleDeferredAttribution(with payloadResult: Result<AttributionPayload, Error>,
in window: UIWindow?) {
guard isRestorationPending else {
return
}
switch payloadResult {
case .success(let payload):
markRestorationCompleted()
applyNavigationRoute(payload, in: window)
case .failure(let error):
print("Échec de récupération de l'attribution : \(error.localizedDescription)")
}
}
/// Applique le contexte de première partie restauré à la hiérarchie de navigation
private func applyNavigationRoute(_ payload: AttributionPayload, in window: UIWindow?) {
DispatchQueue.main.async {
guard let navigationController = window?.rootViewController as? UINavigationController else {
return
}
if payload.targetRoute.hasPrefix("products/"),
let sku = payload.targetRoute.split(separator: "/").last.map(String.init) {
let detailVC = ProductDetailViewController(sku: sku, promoCode: payload.promoCode)
navigationController.pushViewController(detailVC, animated: true)
}
}
}
}
class ProductDetailViewController: UIViewController {
private let sku: String
private let promoCode: String?
init(sku: String, promoCode: String?) {
self.sku = sku
self.promoCode = promoCode
super.init(nibName: nil, bundle: nil)
}
required init?(coder: NSCoder) { fatalError("init(coder:) non implémenté") }
override func viewDidLoad() {
super.viewDidLoad()
view.backgroundColor = .systemBackground
title = "Produit : \(sku)"
if let code = promoCode {
print("Application automatique du code promo : \(code)")
}
}
}
Questions fréquemment posées (FAQ)
Quelle violation spécifique la poursuite antitrust britannique allègue-t-elle contre Apple ?
En quoi AdAttributionKit diffère-t-il de l'Identifier for Advertisers (IDFA) ?
Comment les campagnes Web-to-App de première partie interagissent-elles avec l'ATT ?
Conseils stratégiques pour les architectes mobiles et les équipes de croissance
La poursuite britannique de 2 milliards de livres sterling concernant l'ATT reflète une vérité industrielle durable : le suivi déterministe illimité des appareils entre applications ne reviendra pas. Indépendamment des décisions des tribunaux sur l'auto-préférence des plateformes, les systèmes d'exploitation mobiles continueront d'imposer des périmètres de confidentialité stricts.
Pour les équipes d'ingénierie mobile et les leaders de la croissance, l'adaptation à cet environnement nécessite trois engagements techniques :
-
Adopter les cadres de confidentialité natifs de la plateforme : Implémenter AdAttributionKit et SKAdNetwork dans les pipelines d'achat publicitaire pour capturer les conversions de campagne agrégées sans dépendre de pratiques de suivi obsolètes.
-
Renforcer les parcours Web-to-App de première partie : Construire des architectures de landing pages web résilientes qui capturent l'intention du client dans des contextes de première partie, en déployant des Universal Links vérifiés pour les utilisateurs installés et le Deferred Deep Linking pour maintenir la continuité lors de l'installation de l'application.
-
Structurer le routage des applications vers l'intention : Structurer l'onboarding natif pour consommer des charges utiles de paramètres dynamiques plutôt que des jetons de suivi au niveau de l'identité, garantissant que les remises promotionnelles et les destinations de deep-link survivent aux séquences de boot à froid de manière transparente et fiable.
Références
-
Reuters. (2026). Apple faces £2 bln UK lawsuit over App Tracking Transparency.
-
Hausfeld. (2026). Collective action filed against Apple on behalf of UK app developers.
-
The Mac Observer. (2026). Apple Faces £2 Billion UK Lawsuit Over App Tracking Transparency, Filed September 3.
-
Apple Developer. (2026). App Tracking Transparency Framework. Apple Documentation.
-
Apple Developer. (2026). AdAttributionKit Overview. Apple Documentation.
-
Apple Developer. (2026). Receiving ad attributions and postbacks. Apple Documentation.
-
Apple Developer. (2026). SKAdNetwork Overview. Apple Documentation.
-
Apple Developer. (2026). Supporting Universal Links in your app. Apple Documentation.
-
Apple. (2026). User Privacy and Data Use. Apple Developer Guidance.
-
Opoinstall. (2026). Deferred Deep Linking and Parameterized App Installation Overview.
Share this article
