iOS 27 donne à Apple, et à un nombre croissant de lois régionales, un moyen formel de indiquer à votre application l’âge d’un utilisateur avant toute collecte de données. Si votre app collecte quoi que ce soit auprès de mineurs, et la plupart des apps grand public le font sans le nommer ainsi, votre façon de demander le consentement et de documenter ce que vous collectez doit changer. Pas un jour. Pour un nombre croissant de régions, dès maintenant.
Ce sujet touche à la conformité, une précaution s’impose donc d’emblée : cet article est un repère pratique pour les équipes marketing et produit, pas un conseil juridique. Vos obligations dépendent d’où se trouvent vos utilisateurs et de ce que fait votre application, un avocat doit valider les détails. Ce guide cartographie ce qu’introduit iOS 27, ce que cela change pour votre tracking et votre segmentation, et une checklist à parcourir avant que le contrôle de l’App Store ne se durcisse. Pushwoosh est une plateforme d’engagement client, et là où le consentement et la collecte de données touchent votre configuration Pushwoosh, nous le signalons précisément.
Ce qu’iOS 27 introduit réellement
Deux API sont au centre du sujet, et elles fonctionnent ensemble.
La Declared Age Range API permet à votre application de demander la tranche d’âge d’un utilisateur, par exemple 13+, 16+ ou 18+, sans jamais demander ni stocker de date de naissance. Apple fournit la tranche ; vous recevez un signal, pas une date. Le framework existe depuis iOS 26, et iOS 27 durcit les exigences et l’application qui l’entourent.
PermissionKit gère le volet consentement parental. Lorsque votre app apporte un changement significatif affectant la façon dont un mineur l’utilise, PermissionKit est le flux qui informe l’utilisateur et, dans les régions réglementées, demande l’accord d’un parent ou tuteur avant que le mineur ne poursuive.
Le point de conception important : le système vous indique quand cela s’applique. Via des signaux comme isEligibleForAgeFeatures et requiredRegulatoryFeatures, l’OS indique si des obligations d’âge s’appliquent à un utilisateur donné et si vous devez demander la tranche d’âge ou le consentement parental. Vous ne devinez pas utilisateur par utilisateur — la plateforme vous transmet l’applicabilité.
Ce que les gros titres «obligatoire en septembre» racontent mal
Il vaut la peine d’être précis ici, car l’obligation n’est pas un interrupteur global unique, et «obligatoire en septembre» n’est pas une formule qu’Apple emploie réellement. Deux choses distinctes sont à l’œuvre, et la couverture médiatique tend à les fondre en une seule échéance.
La première est le contrôle de revue de l’App Store. Apple durcit progressivement ce que votre documentation de confidentialité et votre gestion de l’âge doivent montrer, et les apps avec des fonctionnalités sociales ou de contenu généré par les utilisateurs sont censées mettre en place un contrôle d’âge visible côté utilisateur, appuyé sur la Declared Age Range API. Cela se durcit sur tout le cycle d’iOS 27 plutôt que de basculer un matin daté — si votre app a des fonctionnalités sociales, traitez cela comme un chantier à finir avant votre prochaine version, pas après.
La seconde, avec des échéances fermes, est le droit régional, déjà en vigueur à plusieurs endroits. Apple lie lui-même les obligations Declared Age Range à des juridictions précises : les tranches d’âge sont partagées pour les nouveaux comptes Apple dans l’Utah depuis le 6 mai 2026 et en Louisiane depuis le 1er juillet 2026, et Apple a commencé à bloquer les téléchargements 18+ en Australie, au Brésil et à Singapour le 24 février 2026. D’autres lois suivent leur propre calendrier, certaines déjà en vigueur, d’autres reportées. Les signaux réglementaires du système existent précisément parce que la réponse à «dois-je le faire pour cet utilisateur» dépend de sa région et de l’état actuel du droit de cette région.
Lecture pratique : si vous avez des fonctionnalités sociales ou UGC, ou si vous collectez des données de mineurs dans une région réglementée, c’est un chantier en cours, pas un futur projet. Si aucun des deux ne s’applique encore à vous, garder votre documentation de confidentialité à jour reste attendu, et la carte réglementaire s’étend — construire la capacité maintenant coûte moins cher que de la rattraper plus tard sous la pression d’une échéance.
Pourquoi ce sujet retombe sur le marketing, pas seulement le juridique
L’assurance d’âge ressemble à une tâche juridico-technique jusqu’à ce qu’on suive ce qu’elle touche. Elle retombe alors précisément sur votre façon de tracker et de segmenter.
Si vous collectez des identifiants publicitaires, déclenchez des événements comportementaux automatiques ou construisez des segments sur l’activité in-app, un signal d’âge change ce que vous êtes autorisé à collecter et sur qui. Un utilisateur dans une tranche d’âge protégée n’est pas quelqu’un que vous pouvez inscrire discrètement dans le même tracking comportemental et la même collecte d’ID publicitaire qu’un adulte. Dès que l’OS peut vous dire qu’un utilisateur est mineur dans une région réglementée, «on traque tout le monde de la même façon» cesse d’être un défaut défendable.
C’est aussi le moment de combler une lacune que beaucoup d’apps traînent : un traitement flou ou non documenté des identifiants publicitaires (IDFA sur iOS, GAID sur Android). Si votre documentation de données n’indique pas clairement quels identifiants publicitaires vous collectez et pourquoi, cette lacune était déjà un risque. À mesure que le contrôle de revue se durcit sur le cycle d’iOS 27, elle devient un risque de rejet. Corriger en même temps le volet collecte d’âge et la documentation des ID publicitaires est le geste efficace, puisqu’ils vivent dans les mêmes déclarations de confidentialité.
Votre checklist de conformité
Parcourez-la avec vos partenaires juridiques et techniques :
- Cartographiez où se trouvent vos mineurs. Identifiez les régions où vous opérez qui ont des lois d’assurance d’âge en vigueur, et si votre app a des fonctionnalités sociales ou UGC qui déclenchent le contrôle App Store indépendamment de la région.
- Adoptez les signaux d’applicabilité. Utilisez les signaux OS qui indiquent si des obligations d’âge s’appliquent à un utilisateur donné, plutôt que de construire vos propres suppositions. Laissez la plateforme vous dire quand demander une tranche d’âge ou un consentement.
- Demandez la tranche d’âge, pas la date de naissance. Là où vous avez besoin d’un signal d’âge, utilisez la Declared Age Range API pour obtenir une tranche sans jamais collecter ni stocker une date de naissance qu’il vous faudrait ensuite protéger.
- Câblez le consentement parental pour les changements significatifs. Si des mineurs utilisent votre app, assurez-vous que le flux de consentement pour changement significatif est en place pour les régions qui l’exigent.
- Segmentez le tracking par tranche d’âge. Assurez-vous que les utilisateurs dans des tranches d’âge protégées sont exclus de la collecte d’ID publicitaire et du tracking comportemental non autorisé pour les mineurs. C’est une configuration de collecte de données et de consentement, pas une revue manuelle par utilisateur.
- Mettez à jour votre documentation de confidentialité. Actualisez vos déclarations de confidentialité App Store, et pendant que vous y êtes, comblez la lacune de documentation des ID publicitaires pour que le traitement d’IDFA et de GAID soit clairement indiqué. C’est le premier point que vérifie le contrôle de revue.
- Relisez vos textes de consentement. Assurez-vous que le langage de consentement vu par un mineur ou un tuteur correspond à ce que vous collectez réellement, dans le même esprit que vos pratiques de consentement RGPD.
Gérer proprement la collecte de données sensible à l’âge avec Pushwoosh
Le RGPD, SOC 2 Type I et ISO 27001:2022 sont au cœur de la posture Pushwoosh : centres de données en UE et aux États-Unis, sans exception. Sur cette base, Pushwoosh vous donne la gestion du consentement et les contrôles de collecte de données pour segmenter le tracking par tranche d’âge, exclure les utilisateurs protégés des collectes qui ne les concernent pas, et garder votre traitement des ID publicitaires documenté et propre. Le travail de conformité n’est jamais à effort zéro, mais le volet données ne devrait pas en être la partie difficile.
