Comment déclarer les fonctionnalités de médias sociaux dans l’App Store ? Décision de soumission 2026

Le point de départ est la date de soumission et le parcours de distribution, pas le type de projet ni la catégorie affichée sur la fiche. L’annonce d’Apple établit l’application de la demande à partir de septembre 2026 aux nouvelles apps, aux mises à jour et aux demandes de notarisation pour une distribution alternative. Consultez l’annonce officielle d’Apple si vous devez confirmer le périmètre ou si la formulation de l’écran a changé.

Ne confondez pas quatre opérations qui peuvent se suivre, mais qui ne sont pas équivalentes :

• Déclarer une capacité : répondre au questionnaire sur les fonctionnalités présentes dans l’app.
• Obtenir une classification par âge : laisser le système de classification établir le résultat à partir des réponses déclarées.
• Déterminer la disponibilité pour les moins de 13 ans : vérifier si les fonctions concernées leur sont accessibles.
• Soumettre et faire examiner une app : transmettre une compilation et la soumettre au processus de revue ou de notarisation applicable.

Répondre « oui » à la question sur les capacités sociales ne signifie donc pas, à lui seul, que l’app recevra automatiquement une classification donnée, qu’elle sera refusée ou qu’elle deviendra indisponible pour un groupe d’âge. Lisez les réponses comme des déclarations sur le produit, puis vérifiez le résultat de classification et les états de soumission séparément. Apple décrit le questionnaire et les catégories dans son guide de classification par âge d’App Store Connect.

Pour une mise à jour, ne partez pas du principe que les réponses enregistrées lors de la version précédente sont encore exactes. Une modification de l’expérience, même limitée à une nouvelle fonction de publication, peut changer la réponse pertinente. Pour une app déjà distribuée autrement, vérifiez aussi si la démarche engagée est une soumission à l’App Store ou une demande de notarisation : le fait que les deux impliquent des contrôles Apple ne les rend pas interchangeables.

Faites l’inventaire de l’app telle qu’un utilisateur peut l’utiliser dans la version préparée pour soumission. Une feuille de route, une maquette ou une fonction désactivée dans la compilation ne décrit pas nécessairement le produit envoyé. À l’inverse, une fonction activée par configuration distante peut être pertinente si elle est disponible dans l’expérience examinée.

Pour chaque parcours de contenu utilisateur, notez :

• Qui crée le contenu ? Utilisateur final, équipe éditoriale, compte officiel ou source externe.
• Où le contenu apparaît-il ? Profil, fil, recherche, recommandations, page de communauté ou espace privé.
• Comment les autres utilisateurs le découvrent-ils ? Abonnement, classement, suggestions, partage ou navigation entre publications.
• Quelles interactions sont possibles ? Réponse, réaction, partage, signalement ou autre action liée au contenu.
• Quelles conditions limitent l’accès ? Compte, rôle, âge déclaré, autorisation ou paramètre d’administration.

Le but n’est pas de dresser une liste de tous les écrans. Il s’agit de relier chaque réponse à un comportement vérifiable. Conservez les noms des écrans, une courte description du parcours et, si nécessaire, une capture de la compilation concernée. Cette trace est utile lorsqu’une réponse paraît ambiguë ou lorsque l’équipe modifie le produit après la première évaluation.

La catégorie de l’app ne remplace pas cet examen. Une app de création, de vidéo, d’audio ou de design peut intégrer une communauté où les utilisateurs publient et découvrent du contenu. À l’inverse, une app présentée comme sociale peut ne pas offrir de fil ni de découverte de contenu utilisateur. Évaluez les fonctions et leurs relations, plutôt que le positionnement marketing.

À vérifier : évaluez le contenu accessible dans la version réellement soumise. Si un parcours dépend d’un réglage distant, consignez l’état de ce réglage et les conditions qui le rendent accessible.

Apple décrit les fonctionnalités de médias sociaux à partir de la manière dont l’app permet de redistribuer, de mettre en avant ou d’associer des interactions à du contenu créé par les utilisateurs au moyen d’un fil social ou d’un mécanisme similaire de découverte. La définition officielle des valeurs et catégories de classification par âge est le point de contrôle à privilégier lorsqu’un cas n’est pas évident.

Un fil qui rassemble les publications de plusieurs utilisateurs fournit un indice concret de découverte. Des fonctions qui recommandent ces publications, les font remonter ou permettent aux utilisateurs d’interagir avec elles renforcent la nécessité d’examiner la capacité déclarée. Il faut cependant décrire ce que fait votre app, et non conclure à partir d’un indice isolé.

Les commentaires, les publications et les fonctions sociales méritent une analyse de parcours. Une zone de commentaires intégrée à une fiche ou un espace où chacun peut publier ne permet pas, à lui seul, de déduire la réponse. Vérifiez si le contenu peut être retrouvé, redistribué ou mis en avant par un fil ou une expérience comparable. Si votre produit combine plusieurs fonctions, prenez comme unité d’analyse le parcours complet : création, exposition, découverte et interaction.

À l’autre extrémité, un contenu rédigé uniquement par l’éditeur et présenté sous forme de catalogue ne devient pas du contenu utilisateur simplement parce que les utilisateurs peuvent le consulter. De même, un espace privé de dépôt ne présente pas automatiquement la même logique qu’un fil ouvert à la découverte. Dans ces cas, vérifiez néanmoins si d’autres fonctions de la compilation introduisent une redistribution ou des interactions publiques.

Les zones grises doivent être résolues à partir de la logique réelle du produit. Comparez les écrans et les règles d’accès à la définition officielle ; ne déduisez pas la réponse du seul intitulé d’une fonction. L’article 1.2 des règles d’examen de l’App Store traite par ailleurs du contenu généré par les utilisateurs. Il s’agit d’un point de contrôle utile pour le fonctionnement de l’app, mais il ne remplace pas la réponse au questionnaire de classification par âge.

Si votre app possède les capacités concernées, vérifiez explicitement si les fonctions sociales sont disponibles pour les utilisateurs de moins de 13 ans. Répondez d’après les mécanismes réellement appliqués : restrictions de compte, contrôles d’accès et réglages disponibles dans l’expérience. Une intention de limiter l’accès, sans mécanisme effectif, ne justifie pas de déclarer que ces fonctions sont indisponibles.

Cette vérification ne doit pas être fusionnée avec le résultat de classification par âge. L’état de disponibilité pour les moins de 13 ans fournit une information distincte sur l’accès aux fonctions et peut être pertinent pour la classification associée à l’utilisation des médias sociaux. Il ne permet pas de conclure, à lui seul, à une baisse automatique de la classification, à une exemption d’autres questions ou à une approbation de l’app. Référez-vous aux valeurs et définitions officielles des classifications par âge lorsque vous contrôlez la relation entre les réponses et les catégories attribuées.

Vérifiez également la cohérence entre le questionnaire, l’interface et les règles d’accès. Si l’app propose un fil public mais indique ailleurs que les moins de 13 ans peuvent utiliser ses fonctions sociales, il faut comprendre et documenter cette configuration. Si l’accès varie selon le compte ou la région, notez les conditions pertinentes afin que la réponse ne décrive pas uniquement un cas de test particulier.

Comment reconnaître une fonctionnalité de médias sociaux ?

Examinez si l’app redistribue, met en avant ou permet d’interagir avec du contenu créé par les utilisateurs au moyen d’un fil ou d’un mécanisme similaire de découverte. La catégorie affichée dans la fiche n’est pas déterminante. Faites l’inventaire des parcours de publication, de découverte et d’interaction, puis comparez-les à la définition Apple avant de répondre.

Les commentaires ou les publications suffisent-ils à eux seuls ?

Pas nécessairement. Un commentaire ponctuel ou une publication ne tranche pas automatiquement la question sans examen du contexte. Vérifiez si l’app organise la découverte, la mise en avant ou la redistribution du contenu utilisateur. Si le comportement se situe entre un espace privé et un fil de découverte, documentez le parcours complet et appuyez votre réponse sur la définition officielle plutôt que sur le seul nom de la fonction.

Le questionnaire doit-il être revu avant une mise à jour ?

Oui. Avant de soumettre une mise à jour, vérifiez les réponses de classification par âge dans App Store Connect et actualisez celles qui ne décrivent plus la version préparée. L’obligation de déclaration annoncée par Apple s’applique aux mises à jour concernées à partir de septembre 2026. Cette vérification ne remplace ni la création de la compilation ni son examen.

Une distribution alternative doit-elle aussi être vérifiée ?

Oui. Apple inclut les demandes de notarisation liées à la distribution alternative dans le périmètre annoncé. Vérifiez les exigences du parcours précis que vous utilisez et ne considérez pas une réponse enregistrée dans App Store Connect comme une preuve que la demande de notarisation est terminée. Il s’agit de démarches différentes, avec des états à contrôler séparément.

Pour une nouvelle app ou une mise à jour destinée à l’App Store, ouvrez les informations de l’app dans App Store Connect et contrôlez la section de classification par âge. La page officielle consacrée à la définition de la classification par âge explique où gérer ces réponses. Assurez-vous que l’état présenté dans App Store Connect correspond bien à la version que vous préparez.

Pour une distribution alternative, vérifiez le parcours de notarisation et les informations requises pour la demande. Apple décrit ce processus dans sa page sur la distribution d’une app sur un marché alternatif. N’assimilez pas la fin du questionnaire à une notarisation achevée : l’envoi, les contrôles et les statuts correspondants doivent être vérifiés indépendamment.

Voici une décision exploitable avant l’envoi :

• Si votre app redistribue, met en avant ou permet d’interagir avec du contenu utilisateur via un fil ou un mécanisme similaire de découverte, alors déclarez la capacité en fonction de ce parcours et vérifiez l’état d’accès pour les moins de 13 ans.
• Si l’app contient du contenu utilisateur, mais que sa présentation ne permet pas de conclure clairement à une découverte ou une interaction sociale, alors documentez le parcours et comparez-le à la définition Apple avant de choisir une réponse.
• Si le contenu est uniquement éditorial et qu’aucune fonction ne permet aux utilisateurs de publier, découvrir ou faire circuler leur propre contenu, alors ne déduisez pas une capacité sociale de la seule catégorie ; répondez selon les fonctions effectivement présentes.
• Si vous demandez la notarisation pour une distribution alternative, alors contrôlez aussi cette voie, même si la fiche App Store n’est pas le canal de distribution utilisé.
• Si vous modifiez ensuite le fil, la recherche, les recommandations ou les interactions, alors réévaluez les réponses avant la prochaine soumission.

Cette méthode réduit les erreurs de périmètre sans prétendre prédire l’issue de l’examen. La réponse est une déclaration sur le produit ; la décision de revue, la classification affichée et le statut de notarisation restent des résultats distincts.

Avant d’envoyer la version, consignez la réponse retenue et les éléments fonctionnels qui la justifient. Une note interne courte peut contenir la version concernée, les écrans observés, les règles d’accès et le raisonnement reliant ces comportements à la définition. Si une personne différente gère la soumission, elle pourra reprendre l’analyse sans se fier à une interprétation orale.

Après l’envoi, vérifiez séparément que la déclaration a été enregistrée, que la compilation a été téléversée et que la soumission suit son processus. La documentation Apple explique comment téléverser une compilation dans App Store Connect. La présence d’un fichier téléversé ne prouve pas que le questionnaire est complet ; inversement, un questionnaire rempli ne signifie pas que le fichier est prêt ou que l’examen est terminé.

Si vous utilisez l’API App Store Connect pour automatiser la gestion des informations, examinez les champs pertinents dans la référence officielle de la déclaration de classification par âge. L’API peut aider à gérer une déclaration, mais ne décide pas à la place de l’équipe si un fil, une recommandation ou un espace de publication correspond à la définition. Conservez une validation humaine des comportements du produit, surtout si les réponses sont générées ou propagées par un processus automatisé.

Une évolution fonctionnelle doit déclencher une nouvelle vérification, même si elle semble mineure. L’ajout d’un fil, d’une recherche dans les publications, de recommandations ou de nouvelles interactions peut modifier le parcours de découverte. Inscrivez cette vérification dans la préparation de version plutôt que d’attendre un avertissement après soumission.

La déclaration des fonctionnalités de médias sociaux dans l’App Store est donc une décision fondée sur le produit, pas une étiquette à choisir selon le genre de l’app. Avant votre prochaine soumission, rapprochez la définition Apple des parcours réels, vérifiez le questionnaire et gardez la preuve de votre analyse. Si l’étape suivante exige une compilation ou un téléversement sous macOS, le recours à un Mac distant peut éviter d’acheter une machine dédiée pour une opération ponctuelle ; consultez les formules de location de Mac et évaluez-les selon votre durée d’usage et votre flux de travail. Cette option ne remplace ni la décision sur le questionnaire ni les contrôles d’Apple. Pour une compilation régulière ou un besoin d’interface matérielle locale, votre propre Mac peut rester plus adapté ; si vous avez seulement besoin d’un environnement macOS pour préparer la publication, vous pouvez examiner les modalités de location chez CALMVPS.