Andy Garcia · dev freelance
FRENES
Retour au blog
Apple & Conformité

Apple a ajouté deux règles à App Review le 16 octobre. La 2.5.19 peut te coûter ton compte développeur

19 octobre 2026 10 min de lecture

Le 16 octobre, Apple a publié une nouvelle version de ses App Review Guidelines, qui remplace celle du 8 juin. Le journal des modifications compte sept entrées. Deux sont de nouvelles règles : la 2.3.14, sur les ressources créatives, et la 2.5.19, sur les fonctionnalités cachées. Les autres précisent quelles apps relèvent de la 1.2 sur le contenu généré par les utilisateurs, réécrivent la puce sur les liens sortants de la 3.1.1(a), ajoutent à la section 5 le retrait de l'App Store et le blocage de la distribution alternative, et ajoutent des liens vers de la documentation avant et après la soumission.

Apple a présenté cette mise à jour dans un billet d'accompagnement sur les images intimes non consenties et les apps « bait-and-switch » : des apps qui passent la review en étant une chose, et deviennent autre chose après l'approbation. Le même billet indique que l'an dernier (2025), Apple a empêché plus de 150 000 apps présentant des problèmes de sécurité d'atteindre les clients, et résilié plus de 193 000 comptes développeur pour fraude et abus. TechCrunch, le 19 octobre, a lu cette mise à jour comme une interdiction des apps de « nudification » qui se font passer pour des apps ordinaires afin de passer la review.

Voilà la cible. Mais je publie des apps iOS en développeur indépendant, et les mêmes phrases s'appliquent à un développeur solo avec un feature flag comme à un réseau de fraudeurs. J'ai donc lu côte à côte les versions du 8 juin et du 16 octobre. Voici ce qui a changé, règle par règle.

2.5.19 : une vieille interdiction, une nouvelle adresse, une nouvelle phrase

L'interdiction elle-même n'est pas nouvelle. Jusqu'au 16 octobre, la guideline 2.3.1(a) s'ouvrait ainsi : « N'incluez aucune fonctionnalité cachée, dormante ou non documentée dans votre app ; les fonctionnalités de votre app doivent être claires pour les utilisateurs et pour App Review » (ma traduction). Cette phrase a disparu de la 2.3.1(a). Elle ouvre désormais la 2.5.19, mot pour mot, suivie d'une nouvelle : « Tenter de cacher des fonctionnalités non documentées dans le binaire de votre app, par exemple par l'obfuscation du code ou d'autres méthodes, est un motif de retrait de votre app de l'App Store et de résiliation de votre compte développeur. »

Deux choses ont bougé. La règle a quitté la section 2.3, Accurate Metadata, pour la section 2.5, Software Requirements : une fonctionnalité cachée est maintenant classée du côté du binaire, pas de la fiche sur le store. Et la règle porte sa propre phrase de sanction, avec l'obfuscation citée en exemple.

Lis bien cette phrase. Elle n'interdit pas l'obfuscation, qui a des usages légitimes, dont l'anti-tamper. Elle interdit d'utiliser l'obfuscation, ou n'importe quoi d'autre, pour cacher des fonctionnalités non documentées. Le mot qui compte est « non documentées ».

La sanction elle-même n'est pas nouvelle. Dans le texte de juin, la phrase suivante de la 2.3.1(a) faisait du marketing trompeur un motif « similaire » de retrait et de résiliation du compte développeur, et la 2.3.1(b), qui reste, dit qu'un comportement flagrant ou répété est un motif d'exclusion de l'Apple Developer Program. En juillet, Apple a dit à 9to5Mac avoir déjà résilié les comptes développeur derrière 25 apps du type décrit plus bas. Ce qui change, c'est que la phrase de résiliation vise désormais directement les fonctionnalités cachées, dans le binaire, avec l'obfuscation nommée.

Le billet d'accompagnement d'Apple décrit la conduite visée : ajouter des fonctionnalités qui n'étaient pas incluses dans la version de l'app soumise à App Review. Ni la guideline ni le billet ne mentionnent les feature flags, la config à distance ou les tests A/B. Ma lecture est que le risque tient dans un seul schéma : un chemin dans le binaire que la review ne voit jamais, activé ensuite depuis un serveur. 9to5Mac a rapporté en juillet plus de 60 apps construites ainsi : elles se comportaient comme leurs captures d'écran presque partout sauf au Brésil, et révélaient des plateformes de paris quand on les ouvrait depuis une adresse IP brésilienne. Les instructions de build trouvées par 9to5Mac prévoyaient un routage piloté à distance vers l'app locale, une page web intégrée à l'app ou un site externe.

Les apps honnêtes activent aussi des fonctionnalités par région, par cohorte ou par date. La ligne que trace la 2.5.19, c'est de savoir si App Review était au courant. Ce qui reste de la 2.3.1(a) dit toujours que toutes les nouvelles fonctionnalités et tous les changements de produit doivent être décrits « avec précision » dans les Notes for Review, que les descriptions génériques seront rejetées, et qu'ils doivent être accessibles pour la review.

2.3.14 : les ressources créatives ne peuvent pas afficher un prix

Les ressources créatives sont des images et des vidéos qui, d'après les consignes d'Apple, apparaissent dans tout l'App Store sous iOS 27 et iPadOS 27 et versions ultérieures : l'en-tête de la page produit, les résultats de recherche, et les emplacements quand ton app est mise en avant. La nouvelle règle dit qu'elles doivent porter sur le contenu et les fonctionnalités de ton app ou sur sa marque globale, et ne doivent pas inclure de contenu inapproprié, de références à d'autres apps dans l'intention d'induire en erreur, d'affirmations invérifiables sur le produit, ni d'« informations de prix précises ou remisées ».

La page de bonnes pratiques d'Apple ajoute sa propre liste : pas d'URL de sites web, pas de symbole de copyright, pas de références à d'autres plateformes, pas de distinctions Apple comme Editor's Choice ou App of the Day. Les ressources doivent respecter une classification d'âge 4+ même si l'app est classée plus haut, et les jeux qui comportent de la violence peuvent utiliser des images d'action, mais doivent éviter le gore et les armes pointées directement sur une personne ou sur le public.

La même page suggère des ressources créatives pour les offres saisonnières. La règle en pratique : mets en avant la saison, pas le prix. Un en-tête « 50 % de réduction » est exactement ce que la 2.3.14 exclut. Elle prolonge une ligne déjà présente dans la 2.3.7, qui interdit les prix dans les noms d'apps, les sous-titres, les captures d'écran et les previews. Je développe aussi un jeu de stratégie, Doomsday: M.A.D., et la ligne sur les images violentes est celle que je mettrais en tête de tout brief pour les visuels du store.

1.2 : les apps de création par IA sont désormais nommées

La version de juin de la 1.2 commençait ainsi : « Les apps avec du contenu généré par les utilisateurs présentent des défis particuliers » (ma traduction). La version d'octobre commence par : « Les apps qui permettent aux utilisateurs de créer, générer, importer, partager ou contribuer de toute autre façon à du contenu ». Elle range les images intimes non consenties parmi les défis, et nomme trois types d'apps : les réseaux sociaux, les plateformes de contenu généré par les utilisateurs et les apps de création de contenu par IA. Ces apps doivent inclure un filtre pour le contenu répréhensible, un moyen de signaler le contenu offensant avec des réponses dans des délais raisonnables, un moyen de bloquer les utilisateurs abusifs, et des coordonnées de contact publiées.

Puis une nouvelle phrase : les développeurs qui ne mettent pas en place des garde-fous appropriés, ou ne corrigent pas les violations identifiées après notification, « peuvent être considérés comme en violation du Developer Code of Conduct ». Suis le renvoi vers la 5.6 : « Votre compte Developer Program sera résilié si vous vous livrez à des activités ou actions non conformes au Developer Code of Conduct. » Le billet d'Apple dit que les exigences de modération couvrent désormais explicitement les images intimes non consenties, y compris celles générées avec des outils d'IA, que les apps de contenu doivent prévenir et retirer de façon proactive.

Plus tôt cette année, j'ai écrit sur la construction d'une app de fonds d'écran par IA. Avec la formulation du 16 octobre, une app comme ça est une app de création de contenu par IA au sens de la 1.2. Le texte ne dit pas comment « bloquer les utilisateurs abusifs » s'applique quand personne d'autre ne voit ce que tu génères. Je n'attendrais pas qu'un reviewer réponde : une étape de modération sur le prompt et sur la sortie, un bouton de signalement sur chaque image générée, et une adresse de contact que quelqu'un lit vraiment.

3.1.1(a), section 5, et les modifications que le journal a sautées

La 3.1.1(a) permettait aux développeurs bénéficiant d'un entitlement de faire un lien vers « un site web dont le développeur est propriétaire ou dont il assume la responsabilité ». Elle dit maintenant « une destination autorisée », et la puce StoreKit ajoute : « Les destinations approuvées peuvent varier selon la région. » Le Music Streaming Services Entitlement est intégré à cette puce, et les entitlements sont limités à des storefronts précis « et seulement sur certaines plateformes dans chacun de ces storefronts ». Le storefront des États-Unis n'exige toujours aucun entitlement pour les boutons et les liens externes. Je ne lirais pas « destination autorisée » comme « n'importe quelle URL » : vérifie ce que ton entitlement permet dans ta région. L'entitlement des apps de lecture de la 3.1.3(a) dit toujours « un site web dont le développeur est propriétaire ou dont il assume la responsabilité ».

La section 5 s'arrêtait à la notification des autorités pour les apps jugées facilitatrices de la traite d'êtres humains ou de l'exploitation d'enfants. Elle ajoute maintenant que ces apps seront retirées de l'App Store et bloquées de la distribution alternative.

Le journal saute aussi un passage éditorial : chaque « e.g. » du texte de juin, soit 35, a disparu, remplacé par « such as » ou « for example », de même que l'unique « i.e. ». Cette dernière modification touche à l'argent. La 3.1.3(f), l'exemption pour les apps compagnon gratuites et autonomes d'un outil web payant, disait « (i.e. VoIP, Cloud Storage, Email Services, Web Hosting) ». Elle dit maintenant « un outil web payant pour la VoIP, le Cloud Storage, les Email Services ou le Web Hosting ». À la lettre, « i.e. » voulait déjà dire « c'est-à-dire », mais une parenthèse comme celle-là se lit facilement comme des exemples. La nouvelle phrase ne laisse aucune marge : quatre catégories. Si tu construis une app compagnon gratuite pour le SaaS d'un client en dehors de ces quatre, cette exemption n'est pas ta voie.

Ce que je vérifierais avant la prochaine soumission

J'orchestre mon travail avec Claude Code, et c'est le genre d'audit que je lui confierais en premier, avant de vérifier à la main.

  1. Liste chaque flag distant, kill switch, expérience et restriction par région que le binaire lit. Pour chacun, note si la fonctionnalité est visible dans le build soumis à la review. Tout ce qui part dormant et s'active plus tard va dans les Notes for Review, avec la façon d'y accéder.
  2. Vérifie que les menus de debug et internes sont retirés à la compilation des builds de release, et pas cachés derrière un geste.
  3. Si tu obfusques, sois prêt à dire pourquoi, et assure-toi que rien de ce qui est derrière n'est non documenté.
  4. Si tu pousses des mises à jour JavaScript à distance dans une app React Native, confronte chaque mise à jour à la description du billet d'accompagnement : des fonctionnalités qui n'étaient pas dans la version soumise à la review.
  5. Briefe la personne qui fait tes visuels de store : pas de prix, pas de remises, pas d'URL, pas de récompenses que tu ne peux pas prouver, des images adaptées au 4+.
  6. Si les utilisateurs peuvent générer quoi que ce soit, livre le filtre, le bouton de signalement, le blocage et une adresse de contact avant que le reviewer le demande.

Apple dit que les traductions suivront sous un mois. D'ici là, lis la page en anglais.

Rien de tout ça ne ralentit une publication honnête. « Le reviewer ne l'a pas vu » n'a jamais été un raccourci sans risque ; depuis le 16 octobre, la règle dit par écrit que c'est une responsabilité qui pèse sur le compte, et l'endroit le moins cher pour y remédier, ce sont les notes de review, avant d'appuyer sur Submit.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons