Étiquettes de confidentialité App Store : auditez d'abord vos SDK d'analytics (checklist 2026)

Vos étiquettes de confidentialité App Store doivent couvrir ce que collectent vos SDK d'analytics et autres SDK tiers, et pas seulement ce que votre propre code envoie. Avant de répondre aux questions App Privacy dans App Store Connect, listez chaque SDK de la release, notez les données que chacun envoie hors de l'appareil, et déterminez si une partie sert au tracking. Répondez à partir de cette liste, pas de mémoire.

Les étiquettes de confidentialité App Store doivent-elles inclure les données des SDK tiers ?

Oui. Apple vous impose de déclarer les données collectées par le code de partenaires tiers, même lorsque le SDK les collecte pour d'autres raisons que l'analytics ou la publicité.

La page App Privacy d'Apple définit les partenaires tiers comme « les outils d'analytics, les régies publicitaires, les SDK tiers ou autres prestataires externes dont vous avez ajouté le code à votre app ». Un outil de rapport de plantages ou une bibliothèque de connexion a donc sa place dans votre liste. Le critère de collecte porte sur la transmission : « collecter » signifie « transmettre des données hors de l'appareil d'une manière qui vous permet, à vous et/ou à vos partenaires tiers, d'y accéder pendant une durée supérieure à celle nécessaire pour traiter la requête transmise en temps réel ». Les données traitées uniquement sur l'appareil ne sont pas collectées.

Comment construire un inventaire des SDK pour les étiquettes de confidentialité ?

Construisez l'inventaire à partir des dépendances résolues du build de release, y compris les dépendances transitives, et notez le nom et la version de chaque SDK.

1. Exportez la liste des dépendances résolues pour chaque plateforme : Podfile.lock, Package.resolved, pubspec.lock ou votre arbre de dépendances Gradle.
2. Conservez les dépendances transitives. Les exigences d'Apple concernant les SDK tiers précisent que vous êtes « responsable de tout le code que le SDK inclut dans votre app » : un module partagé tiré par un SDK compte donc aussi.
3. Notez le nom et la version de chaque entrée. Les fournisseurs modifient leur traitement des données d'une version à l'autre, la version a donc sa place dans vos notes d'audit.
4. Signalez les SDK qui figurent sur la liste Apple des SDK tiers couramment utilisés. Pour ceux-ci, Apple exige des manifestes de confidentialité lorsque vous soumettez une nouvelle app ou une mise à jour qui les ajoute, et des signatures lorsqu'il s'agit de dépendances binaires. « Toute version d'un SDK listé, ainsi que tout SDK qui reconditionne ceux de la liste, sont inclus. »

Ajoutez cette étape à votre checklist de soumission App Store pour qu'elle soit exécutée à chaque release, pas seulement la première.

À quels types de données de confidentialité App Store correspond chaque SDK ?

Chaque SDK correspond à un ou plusieurs types de données fixés par Apple, comme les données de plantage (Crash Data), les données de performance, les interactions avec le produit, l'identifiant de l'appareil et les données publicitaires. Lisez la documentation du fournisseur sur les données et remplissez une ligne par SDK :

Apple indique que les données collectées sont « souvent liées à l'identité de l'utilisateur, sauf si des protections spécifiques sont mises en place avant la collecte pour les dé-identifier ou les anonymiser », par exemple en supprimant les identifiants directs comme l'identifiant utilisateur ou le nom. Après la collecte, vous ne devez pas non plus relier les données à l'utilisateur ni les associer à d'autres jeux de données qui l'identifient. Si vous ne pouvez pas confirmer qu'un SDK dé-identifie les données, déclarez-les comme liées.

Quand un SDK d'analytics relève-t-il du tracking ?

Un SDK d'analytics relève du tracking lorsqu'il relie des données sur vos utilisateurs ou appareils à des données issues des apps ou sites d'autres entreprises pour de la publicité ciblée ou de la mesure publicitaire, ou lorsqu'il partage ces données avec un courtier en données.

La définition d'Apple est : « relier des données collectées depuis votre app à propos d'un utilisateur final ou d'un appareil particulier, comme un identifiant utilisateur, un identifiant d'appareil ou un profil, à des données tierces à des fins de publicité ciblée ou de mesure publicitaire, ou partager des données collectées depuis votre app à propos d'un utilisateur final ou d'un appareil particulier avec un courtier en données ». Un analytics qui reste dans les données de votre propre app n'est pas du tracking. Une mesure publicitaire qui partage un identifiant entre apps en est.

Le piège, c'est le partenaire qui n'est pas un SDK publicitaire. L'exemple d'Apple est « un SDK de connexion qui réutilise les données qu'il collecte depuis votre app pour permettre de la publicité ciblée dans les apps d'autres développeurs », ce qui compte comme du tracking même si vous n'utilisez pas le SDK à cette fin. Si l'un de vos SDK fait cela, la solution habituelle est un changement de configuration qui bloque l'usage inter-apps, ou un autre fournisseur.

Pouvez-vous omettre certaines données de SDK de vos étiquettes de confidentialité ?

Uniquement lorsqu'un type de données remplit les quatre critères de déclaration facultative d'Apple, ce qui n'est presque jamais le cas des données d'analytics et de plantage. Les critères sont :

• Elles ne sont pas utilisées pour le tracking.
• Elles ne sont pas utilisées pour de la publicité tierce, pour votre propre publicité ou marketing, ni à d'autres fins.
• Elles ne sont collectées que dans des cas peu fréquents, en dehors de la fonctionnalité principale de l'app, et leur fourniture est facultative pour l'utilisateur.
• L'utilisateur les fournit dans l'interface de l'app, il voit clairement ce qui est collecté, son nom ou nom de compte est affiché de façon visible dans le formulaire de soumission, et il choisit activement de les fournir à chaque fois.

Apple ajoute que « les données collectées de manière continue après une demande d'autorisation initiale doivent être déclarées ». Les SDK d'analytics fonctionnent en continu et l'utilisateur ne les choisit pas à chaque fois : ils échouent donc aux deux derniers critères.

À quoi ressemble un audit de SDK finalisé ?

Un audit finalisé attribue à chaque SDK une ligne qui indique quoi déclarer, si les données sont liées à l'utilisateur et si elles servent au tracking. Voici le modèle pour une app hypothétique de suivi d'habitudes avec trois SDK. Les réponses dépendent de la documentation de chaque fournisseur : il ne s'agit pas de constats sur des produits réels.

La ligne « Connexion » change la donne. Elle fait de l'app une app qui pratique le tracking : les étiquettes doivent donc l'indiquer et votre gestion du consentement doit suivre. Passer à un fournisseur de connexion qui ne partage pas les données entre apps, ou désactiver ce partage, coûte bien moins cher avant la soumission qu'après un rejet. Testez ensuite le build de release avec tous les SDK activés, comme dans le plan de test du build de release.

Qu'est-ce qui a mal tourné pour d'autres développeurs ?

Les cas rapportés publiquement montrent trois points de défaillance : des étiquettes qui ne correspondent pas au binaire, des données de SDK dont le développeur n'avait pas connaissance, et des SDK listés livrés sans manifeste.

• Un développeur sur les Apple Developer Forums avait retiré le tracking d'un nouveau build mais ne parvenait pas à le retirer de l'étiquette. App Store Connect affichait « Votre app contient NSUserTrackingUsageDescription, ce qui indique que vous demanderez l'autorisation de suivre les utilisateurs », et la review continuait de rejeter l'app avec « Les informations de confidentialité que vous avez fournies dans App Store Connect indiquent que vous collectez des données pour suivre l'utilisateur… Cependant, vous n'utilisez pas App Tracking Transparency. » Le développeur indique que l'app a été approuvée après avoir déposé un recours et attendu la réponse avant de la soumettre à nouveau.
• Un autre développeur sur les Apple Developer Forums utilisait Firebase Analytics avec la collecte de l'IDFA et de l'IDFV désactivée et une étiquette « pas de tracking », et a quand même reçu un rejet au titre de la Guideline 5.1.2. Le message disait : « La collecte de cookies est une forme de tracking. » Il visait les cookies du contenu web chargé par l'app, et non Firebase. Une réponse a relevé l'incohérence, et aucun correctif n'a été publié.
• Des développeurs dans une issue GitHub de RxSwift ont reçu « ITMS-91061: Missing privacy manifest » pour RxSwift, RxRelay et RxCocoa. Un utilisateur a fait pointer CocoaPods vers la branche 6.8.0, qui contient le manifeste, et indique avoir publié la mise à jour suivante « sans aucun avertissement d'Apple ».

Le point commun : Apple compare vos réponses avec ce que font réellement le binaire livré et son contenu web. Un inventaire construit à partir du vrai build détecte donc ces trois problèmes avant la review.

Comment publier et mettre à jour les étiquettes de confidentialité dans App Store Connect ?

Publiez les étiquettes de confidentialité depuis la section App Privacy de votre app dans App Store Connect. Les réponses ne sont mises en ligne qu'après avoir cliqué sur Publish, et Apple indique que vous pouvez les modifier à tout moment sans soumettre de mise à jour de l'app.

1. Dans App Store Connect, sélectionnez l'app, cliquez sur App Privacy dans la barre latérale, puis sur Get Started.
2. Indiquez si vous ou vos partenaires tiers collectez des données, sélectionnez chaque type de données issu de votre audit, puis cliquez sur Save.
3. Répondez aux questions complémentaires pour chaque type de données, cliquez sur Save, puis vérifiez l'aperçu de la page produit (Product Page Preview).
4. Cliquez sur Publish en haut à droite et confirmez la boîte de dialogue d'exactitude.

D'après Manage app privacy, vous devez avoir le rôle Account Holder, Admin ou App Manager. Si la page produit n'est pas encore en ligne, vos réponses sont publiées en même temps qu'elle. Si l'app est déjà en vente, vos réponses doivent refléter uniquement les données collectées par cette version. Les changements d'URL de politique de confidentialité « sont publiés avec la prochaine version de votre app ». Si la review a déjà signalé des problèmes de confidentialité, commencez par le guide de correction des rejets App Store.