L'essentiel
Les App Review Guidelines d'Apple comptent désormais une règle autonome, la 2.5.19, qui interdit les fonctionnalités cachées, dormantes ou non documentées et fait de leur dissimulation par obfuscation du code un motif de retrait de l'app et de résiliation du compte développeur. Les apps sérieuses ne sont pas visées, mais toute équipe qui active un comportement après validation devrait auditer son développement iOS et son processus de release avant d'envoyer le prochain build en review.
Qu'est-ce qui change dans les App Review Guidelines ?
Apple a publié trois modifications le 16 octobre. La principale est la nouvelle règle 2.5.19 : les apps ne doivent pas contenir de « hidden, dormant, or undocumented features », et leurs fonctionnalités doivent être « claires pour les utilisateurs et pour App Review ». Tenter de cacher des fonctions non documentées dans le binaire, « par exemple par obfuscation du code ou d'autres méthodes », justifie selon la règle le retrait de l'app et la résiliation du compte développeur.
Apple présente la règle comme la clarification d'une interdiction ancienne : celle des apps qui paraissent inoffensives en review puis changent après validation, une pratique qu'elle qualifie de bait-and-switch. La deuxième modification étend la règle 1.2 sur les contenus générés par les utilisateurs : elle cite désormais les images intimes non consenties et vise explicitement les apps de création de contenu par IA. La troisième met à jour la section 5 : les apps dont il est établi qu'elles facilitent la traite des êtres humains ou l'exploitation des enfants sont retirées de l'App Store et bloquées en distribution alternative, le canal qu'Apple ouvre dans l'UE aux apps diffusées hors de sa boutique.
The Verge, qui a relayé la mise à jour le jour même, a pointé la cible directe : les apps dites « nudify », qui passent la review comme retoucheurs photo puis débloquent plus tard des fonctions de deepfakes sexualisés.
La règle 2.5.19 touche-t-elle les feature flags et la configuration à distance ?
Pas en tant que technique, mais elle relève l'exigence sur leur usage. Feature flags, déploiements progressifs, tests A/B et interfaces pilotées par le serveur sont la norme en développement mobile, et le texte d'Apple ne les mentionne pas. Ce que la 2.5.19 interdit, c'est la fonctionnalité qu'App Review ne peut pas voir : des chemins de code éteints pendant la review et activés ensuite, ou des capacités volontairement déguisées dans le binaire.
La frontière pratique, c'est le caractère substantiel. Ouvrir un parcours de paiement déjà validé à 10 % des utilisateurs, c'est un déploiement. Activer une fonction que le build validé n'a jamais montrée, comme un nouveau moyen de paiement, un module de chat ou un générateur de contenu, change ce que fait l'app. Ce second cas doit repasser en review sous forme de nouveau build, avec une description dans les notes App Review et des identifiants de démo qui y donnent accès. L'obfuscation destinée à protéger la propriété intellectuelle reste courante ; le risque commence quand elle cache un comportement plutôt qu'une implémentation.
Que doivent faire les apps d'images IA et de contenus utilisateurs ?
La règle 1.2 s'applique désormais aux apps qui permettent aux utilisateurs de « créer, générer, téléverser, partager ou contribuer de toute autre manière » à des contenus, et cite les images intimes non consenties aux côtés de la contrefaçon et du harcèlement. Selon l'annonce d'Apple, ces apps doivent empêcher et supprimer ces contenus de manière proactive, y compris lorsqu'ils sont générés avec des outils d'IA. Les exigences existantes demeurent : filtrage des contenus répréhensibles, mécanisme de signalement avec réponse rapide et possibilité de bloquer les utilisateurs abusifs. Les développeurs sans garde-fous suffisants, ou qui ne corrigent pas les violations après notification, s'exposent au retrait au titre du Developer Code of Conduct.
Pour toute app de génération ou de retouche d'images, la modération ne peut donc plus attendre l'après-lancement. Filtrage des prompts, classification des sorties et boucle signalement-retrait opérationnelle doivent exister dans le build qu'App Review examine.
Pourquoi Apple durcit-elle la review maintenant ?
Apple relie la mise à jour aux fraudes qui ne s'activent qu'après validation. Dans son annonce, elle indique avoir empêché l'an dernier plus de 150 000 apps présentant des problèmes de sécurité d'atteindre les utilisateurs et résilié plus de 193 000 comptes développeurs pour fraude et abus, certains cas relevant d'opérations coordonnées qui cachaient des contenus nuisibles jusqu'après la review. L'IA générative rend ce schéma moins coûteux : une app photo d'apparence anodine peut à tout moment charger un autre modèle ou une autre chaîne de prompts depuis un serveur. Inscrire l'interdiction dans une règle numérotée donne à Apple une base claire pour sanctionner au niveau du compte.
Ce que cela signifie pour les équipes aux États-Unis et dans l'UE
Pour la plupart des équipes produit, la règle change davantage la documentation que l'architecture. L'exposition se trouve dans des pratiques de release qui ont grandi sans penser à la review : des « kill switches » qui débloquent aussi des fonctions non publiées, des expérimentations qui livrent un module entier derrière un flag, ou des builds en marque blanche dont les fonctions propres à chaque client sont activées par configuration après validation. Chacun de ces cas doit être documenté, ou livré dans un build validé.
La sanction au niveau du compte change le calcul de risque pour les entreprises qui publient plusieurs apps sous un même compte développeur. Une seule infraction à la 2.5.19 dans un produit peut, selon les termes d'Apple, mettre tout le compte en danger, d'où l'intérêt d'un responsable de release qui confronte les notes de review à ce que les flags pilotent réellement.
Que change la règle 2.5.19 pour les éditeurs d’apps en France ?
En France, la règle s'ajoute à un cadre déjà dense. Les apps diffusées via des marketplaces alternatives au titre du Digital Markets Act (DMA) restent soumises à la notarisation d'Apple, et la section 5 révisée étend explicitement le blocage à ce canal : la distribution alternative n'est pas une échappatoire. Les éditeurs qui proposent des fonctions d'images IA doivent articuler les nouvelles exigences de la règle 1.2 avec le RGPD pour le traitement des photos de personnes, sous le contrôle de la CNIL, avec les obligations de modération du Digital Services Act (DSA), dont l'Arcom est le coordinateur national, et avec la loi SREN de 2024, qui a fait de la diffusion sans consentement d'hypertrucages à caractère sexuel un délit.
Pour les agences et ESN qui publient des apps en marque blanche pour plusieurs clients sous un seul compte, le risque de sanction au niveau du compte est le point le plus sensible : un inventaire des flags par client et des notes de review à jour sont à prévoir avant la prochaine soumission.
Checklist avant votre prochaine soumission sur l'App Store
- Inventoriez vos flags. Listez chaque clé de configuration à distance et chaque feature flag, et repérez ceux qui activent une fonction absente du build validé.
- Rédigez des notes de review honnêtes. Décrivez les comportements pilotés par le serveur, les fonctions en déploiement progressif et celles propres à un pays, et fournissez à App Review un compte de démo qui y accède.
- Livrez toute nouvelle capacité dans un nouveau build. Si un flag modifiait substantiellement ce que fait l'app, soumettez une mise à jour au lieu de le basculer en production.
- Vérifiez le périmètre de l'obfuscation. Elle doit protéger des détails d'implémentation, pas des fonctions non déclarées.
- Renforcez la modération UGC et IA. Les apps génératives ont besoin d'un filtrage des prompts et des sorties, du signalement, du blocage et d'un processus de retrait documenté dans le build soumis.
- Désignez un responsable de release. Une personne valide que le build, les flags et les notes de review décrivent la même app.
Questions fréquentes
Qu'est-ce qu'Apple a changé dans les App Review Guidelines le 16 octobre 2026 ?
Apple a ajouté la règle 2.5.19, qui interdit les fonctions cachées, dormantes ou non documentées et leur dissimulation dans le binaire, par exemple par obfuscation du code. La règle 1.2 couvre désormais explicitement les images intimes non consenties, y compris générées par IA, et la section 5 a été mise à jour pour que les apps facilitant la traite des êtres humains ou l'exploitation des enfants soient retirées et bloquées en distribution alternative.
Les feature flags et la configuration à distance sont-ils désormais interdits sur l'App Store ?
Non, Apple n'a pas interdit les feature flags en tant que technique. La règle 2.5.19 vise les fonctions cachées à App Review ou activées après validation. La bonne pratique : n'embarquer que des fonctions validées, décrire tout comportement piloté par le serveur dans les notes de review et soumettre un nouveau build lorsqu'un flag modifierait substantiellement ce que fait l'app.
Quelle sanction en cas d'infraction à la règle 2.5.19 ?
Selon Apple, cacher des fonctions non documentées justifie le retrait de l'app de l'App Store et la résiliation du compte développeur. L'annonce ajoute que les apps qui changent après validation peuvent être exclues de l'Apple Developer Program.
La règle 2.5.19 s'applique-t-elle aux apps distribuées via des marketplaces alternatives dans l'UE ?
Les apps diffusées via des marketplaces alternatives au titre du DMA passent toujours par la notarisation d'Apple, et la section 5 mise à jour étend explicitement le blocage à la distribution alternative. Un éditeur français qui passe par ce canal doit donc prévoir les mêmes règles de review que sur l'App Store.
Que doivent faire les apps d'images IA et de contenus utilisateurs selon la nouvelle règle 1.2 ?
Les apps qui permettent de créer, générer, téléverser ou partager des contenus, y compris les apps de création par IA, doivent empêcher et supprimer de manière proactive les images intimes non consenties, filtrer les contenus répréhensibles, offrir un moyen de signalement et permettre de bloquer les comptes abusifs. Les développeurs qui ne corrigent pas les violations après notification s'exposent au retrait.
Sources
Apple Developer — Strengthening App Review Guidelines against nonconsensual intimate imagery and bait-and-switch apps (October 16, 2026)
Apple Developer — App Review Guidelines (updated October 16, 2026)
The Verge — Apple’s updated App Store rules go after ‘nudify’ AI apps (October 16, 2026)