Dernière mise à jour : 14 août 2026. Informations vérifiées dans les annonces Apple Developer, l’aide App Store Connect et la documentation Declared Age Range API.

Le 9 juillet 2026, Apple a ajouté les questions sur les capacités de réseau social dans App Store Connect. À partir de septembre 2026, les réponses seront nécessaires pour soumettre une nouvelle application, une mise à jour ou une demande de notarisation pour une distribution alternative. (Annonce Apple Developer sur les changements de classement)

Symptôme : vous choisissez « oui » ou « non » selon la catégorie marketing de votre application, puis vous découvrez que son fil, ses commentaires ou ses fonctions de partage racontent une autre histoire.

Solution la plus rapide : partez des fonctions réellement accessibles en ligne, vérifiez si elles redistribuent ou amplifient du contenu généré par les utilisateurs, puis validez séparément App Store Connect, le code d’âge et les tests Sandbox avant septembre.

Public concerné

Ce guide s’adresse aux développeurs indépendants qui préparent une soumission après septembre 2026, ainsi qu’aux responsables produit et aux équipes mobiles qui doivent éviter un blocage de métadonnées.

Il concerne particulièrement les applications communautaires, les plateformes de contenu, les produits créatifs avec partage public et les applications qui désactivent certaines fonctions pour les moins de 13 ans.

Parcours de décision par fonctionnalité

Ne commencez pas par le nom de votre application ni par sa catégorie dans App Store Connect. Commencez par une fonctionnalité précise et suivez son parcours réel : qui crée le contenu, qui peut le voir, qui peut le recommander et qui peut interagir avec lui.

Cas 1 : outil sans diffusion sociale

Vous êtes généralement dans le parcours « aucune capacité sociale » si votre application :

  • fonctionne comme un outil local de montage audio, de retouche vidéo, de dessin ou de productivité ;
  • affiche uniquement des contenus éditoriaux contrôlés par votre équipe ;
  • conserve les documents dans un espace privé visible par un utilisateur ou une équipe restreinte ;
  • permet un partage ponctuel sans fil public, recommandation ou mise en avant algorithmique.

Cela ne dispense pas d’une vérification. Examinez notamment les commentaires, les profils publics, les réactions, les contenus recommandés et les boutons de republication. Une fonction peut être apparue dans une ancienne version, rester accessible derrière une configuration distante ou être fournie par un composant tiers.

Pour établir votre justification interne, conservez :

  • la liste des fonctions disponibles dans la version soumise ;
  • des captures des écrans pertinents ;
  • la description de la configuration distante utilisée au moment du contrôle ;
  • les notes de version expliquant les fonctions désactivées ;
  • l’identifiant du responsable produit qui a validé le périmètre.

Un espace de travail privé n’est pas équivalent à un réseau social public. En revanche, une galerie visible par tous les utilisateurs, avec réactions et classement, doit être étudiée comme une capacité de diffusion, même si votre produit est présenté comme un outil de création.

Cas 2 : UGC, commentaires et fil de découverte

Apple décrit la capacité Social Media comme la possibilité de redistribuer, amplifier ou rendre interactif du contenu généré par les utilisateurs au moyen d’un fil social ou d’un mécanisme similaire de découverte. Les exemples mentionnés comprennent notamment la republication, les mentions « J’aime », les commentaires, les réactions et les outils qui rendent un contenu plus visible dans un fil, une communauté, une recherche ou un autre parcours de découverte. (Définitions officielles des classements par âge)

La distinction importante est la suivante :

  • UGC simple : les utilisateurs créent du texte, de l’audio, des images ou des vidéos qui sont diffusés dans le cadre prévu par l’application ;
  • capacité sociale : l’application permet à ce contenu d’être redistribué, recommandé, amplifié ou discuté par d’autres utilisateurs ;
  • messagerie : les utilisateurs communiquent directement par texte, voix ou vidéo, ce qui constitue une catégorie distincte à examiner dans le questionnaire.

Une application de création vidéo peut donc avoir un classement différent selon son fonctionnement. Un export vers le stockage local ne crée pas nécessairement une capacité sociale. Une page « tendances » qui pousse les créations populaires, permet les réactions et affiche un classement est beaucoup plus proche de la définition officielle.

Vérifiez aussi les fonctions secondaires :

  • commentaires publics sur une publication ;
  • partage vers le profil d’un autre utilisateur ;
  • fil « pour vous » ou recommandations ;
  • recherche de publications ;
  • réactions qui augmentent la visibilité d’un contenu ;
  • signalement, blocage et modération ;
  • diffusion progressive activée par une configuration distante ;
  • contenu public accessible depuis une page web intégrée.

Le principal risque est l’écart entre l’interface déclarée et le comportement en production. Une équipe peut répondre « non » parce que la fonction n’apparaît pas dans la capture principale, alors qu’un ancien écran, un compte de test ou une région particulière l’active encore.

Effets sur Time Allowances et le classement

La catégorie Social Media de Time Allowances ne correspond pas à la catégorie principale choisie dans App Store Connect pour aider les utilisateurs à découvrir votre application. Apple précise que cette catégorie dépend de la présence de capacités sociales, quelle que soit la catégorie sélectionnée pour l’application ou le jeu. Les applications concernées peuvent afficher un descripteur Social Media sur leur page produit. (Annonce Apple Developer sur les changements de classement)

Cette séparation évite une erreur fréquente : une application classée dans « Photo et vidéo », « Créativité » ou « Productivité » peut tout de même relever de Social Media si elle organise la redistribution ou la découverte de contenus d’utilisateurs.

Le classement généré dépend ensuite des réponses au questionnaire et des descripteurs applicables. Apple indique notamment que la capacité Social Media peut être associée à un classement 13+, tandis que le contenu généré par les utilisateurs et la messagerie peuvent apparaître dans des niveaux différents selon les autres réponses. Ne déduisez donc pas le résultat final à partir d’une seule fonction.

Les conséquences opérationnelles sont concrètes :

  • l’âge affiché sur la page produit peut évoluer ;
  • la présence d’un descripteur Social Media peut modifier la manière dont les familles identifient l’application ;
  • une réponse incohérente peut attirer une demande de clarification pendant l’examen ;
  • le classement est une information au niveau de l’application et s’applique à toutes les plateformes associées. (Informations officielles sur les applications dans App Store Connect)

Ces règles ne remplacent pas les obligations légales propres aux pays ou aux régions. Elles ne constituent pas non plus une interprétation juridique de votre modèle de modération, de publicité ou de collecte de données.

Parcours pour les moins de 13 ans

Sélectionner l’option indiquant que les fonctions sociales sont désactivées pour les moins de 13 ans ne doit jamais être une solution déclarative uniquement. Apple précise qu’il faut, au minimum, appeler Declared Age Range API pour vérifier la tranche d’âge avant d’activer les fonctions sociales et ne fournir que du contenu adapté à cette tranche.

L’API ne vous remet pas une date de naissance exacte. Elle renvoie une tranche d’âge déclarée par l’utilisateur, son parent ou son responsable légal. Apple précise que cette information peut être confirmée par un moyen de paiement, une pièce officielle ou une autre méthode, mais que votre équipe reste responsable du respect des obligations applicables. (Documentation officielle de Declared Age Range)

Le parcours technique doit couvrir au minimum quatre décisions :

  1. Tranche inférieure au seuil : masquer ou désactiver le fil social, les commentaires publics, les recommandations et les actions qui amplifient le contenu.
  2. Tranche atteignant le seuil : autoriser uniquement les fonctions prévues par votre politique produit et votre questionnaire.
  3. Refus de partage : appliquer une voie de repli sûre, sans considérer l’utilisateur comme automatiquement majeur.
  4. Contrôle parental ou consentement révoqué : retirer l’accès dès que le système ou votre logique de permission l’exige.

Dans Xcode, vous devez activer la capacité Declared Age Range et l’autorisation com.apple.developer.declared-age-range sur la cible concernée. La documentation Apple indique également que l’API doit être intégrée avec une logique de demande et de traitement de la réponse, plutôt qu’avec un simple interrupteur local.

Pour les applications créatives, pensez aux chemins moins visibles : une vidéo exportée dans une galerie publique, une piste audio partagée dans un espace communautaire ou un projet de design rendu découvrable peuvent tous modifier l’analyse. Testez le produit comme un utilisateur, pas seulement comme un administrateur.

Déploiement multi-plateforme

Le classement par âge est défini au niveau de l’application et appliqué entre les plateformes associées. Une application iPhone, iPad et Mac ne doit donc pas être évaluée uniquement à partir de la version la moins fonctionnelle.

Comparez séparément :

  • les fonctions sociales disponibles sur iPhone ;
  • les fonctions disponibles sur iPad ;
  • la version macOS et ses espaces de partage ;
  • les fonctions activées par compte ou par région ;
  • les capacités disponibles dans une version bêta mais pas encore dans la version publique.

Le cas le plus risqué est celui d’une application qui désactive le fil social sur iPhone, mais le laisse ouvert dans son interface macOS. Vous ne devez pas utiliser automatiquement la plateforme la plus restrictive pour représenter l’ensemble de l’application. Documentez la différence et confirmez le traitement attendu dans les ressources officielles avant de soumettre.

Depuis septembre 2026, le même sujet concerne également les demandes de notarisation liées à une distribution alternative. Apple l’a indiqué dans son annonce du 9 juillet 2026, sans publier dans cette annonce de date précise à l’intérieur du mois.

FAQ de préparation

Quand remplir les réponses dans App Store Connect ?

Les questions sont déjà disponibles depuis le 9 juillet 2026. La contrainte de soumission commence « à partir de septembre 2026 » selon Apple. Comme aucun jour universel n’est indiqué dans l’annonce officielle consultée le 14 août 2026, ne planifiez pas votre mise en production sur une date supposée. Enregistrez les réponses dès que le périmètre produit est stabilisé.

Les commentaires suffisent-ils à qualifier une capacité sociale ?

Non. Un commentaire privé entre membres d’un espace fermé n’a pas le même rôle qu’un commentaire public qui augmente la visibilité d’une publication. Vous devez examiner la redistribution, l’amplification et la découverte du contenu. Les fonctions de réaction, de recommandation, de republication ou de recherche sont souvent plus déterminantes que le simple champ de commentaire.

Que faire si le fil est inaccessible aux moins de 13 ans ?

Vous devez prouver que le blocage est réellement appliqué. Avant l’activation des fonctions sociales, demandez la tranche d’âge avec Declared Age Range API, puis testez le comportement pour un utilisateur inférieur au seuil, un utilisateur atteignant le seuil, un refus de partage et une révocation de consentement. Le questionnaire ne remplace pas cette logique d’exécution.

Une nouvelle réponse annule-t-elle automatiquement l’ancien classement ?

Apple génère le classement à partir des réponses et des catégories applicables. Une modification peut donc changer le classement ou les descripteurs affichés, mais elle ne signifie pas automatiquement que l’application sera rejetée. Le risque principal vient de l’incohérence entre les réponses, la page produit, les fonctions en ligne et la version effectivement soumise.

Quels cas faut-il couvrir dans Sandbox ?

La documentation Apple fournit des scénarios avec des bornes inférieures et supérieures, des déclarations parentales ou personnelles, ainsi que des cas de consentement approuvé, refusé ou révoqué. Vérifiez au minimum les utilisateurs sous 13 ans, les tranches adolescentes, les adultes, le refus de partage et la révocation. Les valeurs retournées doivent être comparées à vos journaux de décision. (Tests Age Assurance officiels dans Sandbox)

Checklist de soumission

Utilisez cette liste avec un responsable produit et un responsable technique. Ne la confiez pas uniquement à l’équipe chargée des métadonnées.

  • [ ] Identifier chaque écran qui affiche, recommande, recherche ou redistribue du contenu généré par les utilisateurs.
  • [ ] Vérifier les fonctions sociales désactivées à distance, les anciennes versions et les composants tiers.
  • [ ] Distinguer UGC, Social Media, Messaging and Chat et la catégorie principale de découverte dans App Store Connect.
  • [ ] Reproduire le parcours d’un utilisateur public, d’un membre d’espace privé et d’un utilisateur soumis à une restriction d’âge.
  • [ ] Enregistrer les captures, la version de l’application, la configuration distante et la date du contrôle.
  • [ ] Répondre au questionnaire dans App Store Connect et vérifier que les réponses sont bien sauvegardées.
  • [ ] Comparer les fonctions iPhone, iPad et macOS sous le même identifiant d’application.
  • [ ] Activer Declared Age Range dans Xcode si l’option « fonctions sociales désactivées pour les moins de 13 ans » correspond réellement au produit.
  • [ ] Tester le seuil d’âge, le refus de partage, l’accès autorisé et la révocation du consentement.
  • [ ] Utiliser un compte Sandbox et conserver les bornes d’âge ainsi que les résultats retournés par l’API.
  • [ ] Vérifier la version destinée à l’App Store et la version prévue pour une distribution alternative.
  • [ ] Faire signer le dossier par le responsable produit et le responsable technique avant la soumission.

Pour une équipe qui doit encore préparer un environnement de test isolé, vous pouvez consulter la page MACCOME consacrée aux environnements Mac distants. Le choix d’un Mac cloud pour les tests Xcode doit toutefois dépendre de vos contraintes réelles : version de macOS, compte de test, accès aux appareils, durée du projet et traçabilité des résultats.

Validation finale avant septembre

Le contrôle final doit produire trois éléments distincts :

  1. Une preuve App Store Connect : réponses enregistrées et capture du questionnaire.
  2. Une preuve produit : liste des capacités réellement accessibles dans la version candidate.
  3. Une preuve technique : journaux et résultats des scénarios d’âge, avec l’identifiant de build utilisé.

Ne mélangez pas ces preuves. Une capture du questionnaire ne démontre pas que le fil social est bloqué. À l’inverse, un test réussi dans une ancienne version ne justifie pas une réponse donnée pour une version plus récente.

Si votre application utilise une configuration distante, exportez la configuration ou conservez une copie lisible au moment de l’acceptation. Si les fonctions audio, vidéo ou design disposent d’une galerie publique, testez aussi la visibilité après publication, recherche et recommandation. Les défauts de conformité apparaissent souvent après l’envoi du contenu, pas sur l’écran de création.

Votre plan de repli doit être défini avant la soumission. Si la réponse dépend d’une fonction encore instable, désactivez temporairement cette fonction dans la version candidate ou repoussez la soumission jusqu’à obtenir un comportement vérifiable. Ne choisissez pas une réponse plus favorable uniquement pour éviter une évolution du classement.

Choix de l’environnement Mac

Une mise à jour directe de votre Mac principal peut contaminer l’environnement de production, modifier la version de Xcode ou perturber les comptes de signature. Elle peut également rendre plus difficile la reproduction d’un résultat quelques jours plus tard.

Un Mac local dédié reste pertinent si vous avez besoin d’un accès permanent à des appareils physiques, de périphériques audio ou vidéo, de tests USB, ou d’une charge soutenue pendant plusieurs mois. En revanche, il implique l’achat, la maintenance, les mises à niveau, la gestion des comptes et la conservation des journaux sur une machine séparée.

Un Mac distant isolé est souvent plus adapté à une vérification limitée dans le temps : vous pouvez séparer la version candidate du poste principal, partager une procédure avec un prestataire et fermer l’environnement après la validation. Avant de choisir, vérifiez la latence, les permissions, l’accès aux appareils de test, la version de Xcode et la méthode de récupération des artefacts.

Vous pouvez également examiner les options Mac cloud de MACCOME pour un projet temporaire, puis comparer la durée réellement nécessaire à l’achat d’un appareil réservé. L’objectif n’est pas de louer un Mac par principe, mais d’éviter de modifier votre chaîne de production uniquement pour remplir un questionnaire et effectuer quelques scénarios d’âge.

Votre configuration actuelle — poste partagé, Mac principal non compatible avec la version de test ou environnement difficile à isoler — présente trois défauts réels : elle mélange production et conformité, elle rend les résultats moins reproductibles et elle augmente le risque d’utiliser le mauvais compte ou le mauvais build. Pour une campagne courte avant septembre 2026, louer un environnement Mac auprès de MACCOME peut donc être plus propre qu’un achat précipité, à condition de vérifier à l’avance Xcode, les autorisations, les tests Sandbox et la conservation des preuves.