iOS 27.2 : comment valider l’invite ATT de l’UE ? Liste 2026

Votre capture montre une invite ATT différente selon le territoire, mais le test ne dit pas si l’application a réellement respecté le choix.

La semaine de validation, traitez iOS 27.2 en séparant trois contrôles : l’invite, le pays de distribution et le traitement de l’autorisation. Le changement d’interface ne modifie pas l’exigence de suivi ; pour les pays explicitement désignés par Apple, prévoyez l’invite de remplacement. Ne validez pas sur une capture seule : confrontez la documentation en vigueur aux résultats reproductibles de votre application.

À qui s’adresse cette liste

Aux ingénieurs iOS qui doivent vérifier l’appel ATT et le traitement du choix.
Aux équipes QA qui définissent la couverture des territoires et des parcours.
Aux responsables CI macOS qui doivent conserver des preuves reproductibles avec Xcode.

Dernière mise à jour : 1 novembre 2026. État des versions et règles vérifié à partir des annonces Apple sur les changements ATT dans l’UE, des notes de publication Apple et des exigences système de Xcode. À réexaminer si iOS 27.2 sort de bêta ou si Apple modifie sa documentation.

Un changement d’invite, pas un changement d’autorisation

Apple indique que iOS 27.2 et iPadOS 27.2 proposent une invite ATT de remplacement dans l’UE. Cette option change la manière de présenter la demande ; elle ne constitue pas une exemption aux règles de suivi. Pour votre publication, gardez donc deux décisions distinctes : quelle invite l’application doit présenter selon sa distribution, et si le traitement des données est autorisé après le choix de la personne.

La distinction compte aussi pour l’architecture de consentement. L’autorisation ATT ne remplace pas les autres choix de confidentialité propres à votre application. À l’inverse, un consentement recueilli dans un écran maison ne vaut pas autorisation ATT. Dans vos tests, consignez ces états séparément et vérifiez que les traitements dépendant du suivi ne démarrent pas avant l’autorisation requise.

Au moment de la vérification, les informations d’iOS 27.2 consultées restent marquées comme bêta dans les annonces et notes de publication Apple. Xcode 27.2 est indiqué comme publié le 29 octobre 2026 dans les informations Apple relatives à Xcode et à ses exigences système. Ne présentez donc pas l’état de Xcode comme une confirmation de la disponibilité générale d’iOS 27.2. Le statut du système et celui de l’outil de développement sont deux faits distincts.

Apple précise que, pour les applications distribuées en France, en Allemagne, en Italie, en Pologne et en Roumanie, seule l’invite de remplacement est proposée. Pour les autres territoires de l’UE, cette alternative est facultative. Vérifiez cette distinction dans la page Apple consacrée à la confidentialité et à l’utilisation des données dans l’App Store. Ne transformez pas une règle donnée pour ces cinq marchés en obligation générale uniforme applicable à toute l’Union.

À retenir : une capture obtenue dans un environnement de test ne démontre pas, à elle seule, que le pays de distribution est correctement pris en compte. Documentez ce que votre test prouve réellement et ce qu’il ne permet pas de vérifier.

Pour l’ingénieur iOS : code d’autorisation et états séparés

Commencez par localiser tous les endroits où l’application demande une autorisation ATT ou prend une décision fondée sur son état. Le contrôle ne consiste pas seulement à repérer un appel : vérifiez quand il est déclenché, ce que l’utilisateur voit juste avant, et quels traitements deviennent possibles après chaque résultat.

La documentation Apple décrit la demande par requestTrackingAuthorization dans la référence de l’appel de demande ATT. Faites correspondre cet appel au parcours produit. Si l’application affiche un écran explicatif préalable, confirmez que celui-ci ne masque pas la nature de la demande et qu’il ne laisse pas entendre qu’un choix maison remplace la décision système.

Vérifiez ensuite l’état d’autorisation renvoyé par le système à l’aide de la documentation Apple sur authorizationStatus. Couvrez les résultats pertinents pour votre application — autorisé, refusé, indéterminé ou restreint — et notez les effets attendus sur le code. Un résultat doit conduire à un comportement explicite, pas à une valeur supposée parce qu’une boîte de dialogue a été affichée.

Enfin, contrôlez la description d’usage intégrée à l’application. Apple documente la clé NSUserTrackingUsageDescription dans la référence de la propriété d’information. Votre texte doit expliquer clairement l’usage concerné et correspondre au comportement réel. Une description générique, contradictoire avec l’écran précédent ou déconnectée du traitement en aval rend la recette difficile à défendre, même si l’appel technique aboutit.

Pour le produit et la conformité : portée territoriale documentée

Le périmètre doit partir de la distribution effective, non de la seule langue de l’application ni de l’endroit où travaille l’équipe. Faites confirmer par le responsable de publication quels territoires sont prévus, puis confrontez cette liste à la distinction publiée par Apple. L’objectif est de pouvoir expliquer pourquoi l’application utilise l’invite de remplacement ou l’option alternative pour chaque marché visé.

N’interprétez pas la validation technique comme une conclusion juridique. Les équipes produit et conformité doivent confirmer que les déclarations, les traitements de données et les pratiques de distribution de l’application correspondent à leurs obligations. L’annonce Apple précise un comportement de plateforme et une portée territoriale ; elle ne tranche pas à elle seule tous les cas propres à votre service.

Si un territoire n’est pas couvert par vos essais, inscrivez-le comme non vérifié et bloquez la conclusion de conformité qui en dépend. Cette réserve est plus utile qu’une mention vague « testé UE », qui ne distingue ni les marchés soumis à l’invite imposée ni ceux où l’alternative est facultative.

Pour la QA : parcours, texte et Additional Information

La QA doit vérifier le parcours complet, pas seulement le premier affichage. Préparez des conditions d’entrée reproductibles, puis notez l’état ATT avant l’essai, l’écran présenté, l’action effectuée et le résultat observable. L’entrée « Additional Information » mérite un contrôle spécifique : elle doit conduire à l’explication complémentaire ou au choix plus détaillé prévu par la conception, et non à un écran vide ou à un retour incohérent.

Pour chaque scénario, confrontez le texte de l’invite à la finalité réelle du traitement. Vérifiez également que le refus entraîne bien les restrictions attendues dans l’application. Si certains traitements restent possibles pour d’autres finalités, ils doivent rester séparés du suivi nécessitant l’autorisation ATT ; ne laissez pas un résultat positif dans un autre écran de consentement débloquer implicitement le suivi.

Faites apparaître dans les résultats les situations où le système ne présente pas l’invite, où l’état est déjà déterminé ou où un réglage système limite la demande. Ce comportement n’est pas un échec automatique : c’est une condition à qualifier. La conclusion doit préciser si la QA a pu vérifier l’affichage, le choix, la lecture de l’état et l’effet sur les traitements. Sans ces distinctions, une capture du bon écran peut donner une fausse impression de couverture.

Point de recette : ne concluez pas « conforme » parce que l’invite attendue apparaît une fois. Reliez chaque résultat à l’état initial, à l’action de l’utilisateur et au comportement de l’application après cette action.

Pour la CI : environnement et preuve reproductible

Une validation exploitable par l’équipe doit identifier l’environnement exact. Enregistrez la version de Xcode, la version du système d’essai, la cible sélectionnée, le commit testé et les étapes ayant déclenché le parcours. Les exigences système de Xcode évoluent ; vérifiez la compatibilité de la version retenue dans la documentation Apple des exigences Xcode plutôt que de supposer que l’installation disponible sur un nœud convient.

Une configuration d’intégration continue utile comprend les éléments suivants :

• Une tâche dédiée à l’essai ATT, distincte des tests généraux qui ne déclenchent pas le parcours.
• Des journaux associés au commit, à la cible et aux paramètres d’exécution.
• Des résultats séparés pour les chemins autorisé, refusé, indéterminé et restreint, lorsque la cible permet de les reproduire.
• Une capture ou une trace utile à l’analyse, accompagnée des étapes et de l’état initial.
• Une note explicite sur les limites : territoire non reproduit, réglage impossible à imposer ou comportement qui nécessite une vérification hors simulateur.

Le simulateur aide à contrôler le code de l’application et des séquences d’interface reproductibles, mais ne prouve pas à lui seul que la distribution réelle d’une application dans un territoire donné produit le comportement attendu. Distinguez donc la preuve du flux logiciel de la preuve du contexte de distribution. Si un test territorial ne peut pas être reproduit dans votre CI, inscrivez-le dans les risques résiduels et définissez une méthode de vérification complémentaire.

Si vous envisagez un environnement macOS distant, vérifiez d’abord qu’il fournit effectivement la version de Xcode requise, le système d’essai voulu et la cible compatible avec votre test. Les fonctions disponibles dépendent de l’environnement retenu : ne présumez ni la présence d’un appareil physique, ni la possibilité de simuler un territoire, ni l’accès à un compte ou à des réglages particuliers. Pour comparer ce type d’environnement à vos postes existants, consultez les informations de VMSPIN sur les environnements Mac distants et confrontez-les à vos besoins de test avant toute décision.

Pour le responsable de publication : décision par preuves

Utilisez les critères suivants pour décider d’un pilote, d’une publication ou d’un report :

• Si les territoires de distribution sont confirmés, les règles Apple correspondantes sont consignées, et l’application traite chaque état ATT de façon cohérente, alors vous pouvez soumettre le parcours à la validation QA et CI.
• Si l’invite affichée est correcte mais que l’entrée Additional Information ou le comportement après refus n’a pas été vérifié, alors le résultat reste partiel ; complétez ces essais avant de déclarer la recette terminée.
• Si les essais reposent seulement sur une capture de simulateur, sans version, état initial, étapes ni journaux, alors refusez la conclusion de réussite et relancez un test traçable.
• Si votre cible ou votre territoire ne peut pas être reproduit, alors consignez précisément l’élément non validé, attribuez-lui un responsable et différez la décision qui dépend de cette preuve.
• Si Apple modifie l’état de publication d’iOS 27.2, ses notes ou les règles territoriales, alors réévaluez la matrice avant de réutiliser les résultats précédents.

Avant la mise en production, comparez le rapport d’essai à l’état Apple actuel. Une réussite sur une version bêta ne garantit pas que le même parcours restera identique après une évolution du système ; de même, une mise à jour de la documentation peut nécessiter une nouvelle décision même si le code n’a pas changé. Conservez la date de vérification, les sources consultées et la décision de l’équipe afin que la prochaine personne puisse comprendre pourquoi la version a été acceptée ou retenue.

Pour une équipe qui ne possède pas de poste Mac adapté, l’alternative n’est pas automatiquement la location. Un Mac acheté convient mieux à un usage régulier avec besoins matériels locaux ; un environnement déjà disponible peut suffire pour une recette ponctuelle. En revanche, maintenir un poste sous-dimensionné, attendre l’accès partagé, ou tenter de remplacer les outils Apple par une machine Linux ajoute des contraintes et ne valide pas un parcours ATT sur macOS. Si vous avez besoin d’un environnement temporaire pour vérifier Xcode et vos cibles, comparez les conditions de location Mac chez VMSPIN avec votre durée d’essai et vos exigences réelles. Ne choisissez ce chemin qu’après avoir confirmé les outils et tests nécessaires ; vous pouvez ensuite consulter les options de commande VMSPIN si l’environnement correspond à votre recette.

FAQ

Quels territoires exigent l’invite ATT de remplacement ?

Apple nomme la France, l’Allemagne, l’Italie, la Pologne et la Roumanie pour les applications distribuées dans ces pays. Pour les autres territoires de l’UE, l’invite de remplacement est facultative. Vérifiez la liste de distribution de votre application et la documentation Apple au moment de la publication ; ne déduisez pas la règle applicable à tous les marchés d’un seul test ou d’une seule version linguistique.

L’option de présentation change-t-elle la règle de suivi ?

Non. La présentation alternative n’annule pas l’autorisation ATT lorsque l’application effectue un suivi soumis à cette règle. Gardez l’appel d’autorisation, la lecture de l’état et le comportement après le choix dans votre plan de test. Les consentements propres aux autres fonctions de l’application doivent rester distincts, avec leurs propres conditions et conséquences.

Quels contrôles effectuer autour de l’entrée Additional Information ?

Suivez l’entrée depuis l’invite jusqu’à l’information ou aux choix complémentaires prévus dans votre application. Vérifiez le retour au parcours, le texte affiché et les conséquences du choix sur les traitements. Enregistrez également l’état ATT initial et final. Une capture atteste un affichage à un instant donné, pas la conformité de tout le traitement en aval.

Une nouvelle année permet-elle de réafficher automatiquement la demande ?

Ne fondez pas votre logique sur un renouvellement annuel automatique. Consultez l’état d’autorisation fourni par le système et vérifiez les conditions réelles de présentation de la demande. Testez aussi les réglages susceptibles de limiter le parcours. La bonne décision est de documenter les états reproductibles, pas de programmer une nouvelle invite à partir d’une date sans confirmation Apple.

À quel moment faut-il reprendre la validation ?

Reprenez la vérification si le statut public d’iOS 27.2 évolue, si Apple met à jour ses consignes sur l’ATT ou si votre périmètre de distribution change. Un changement d’outil, de système d’essai ou de parcours produit peut également invalider certaines preuves. Associez chaque nouvelle conclusion à la version, au territoire et aux résultats effectivement testés.