---
title: "Refus App Store 4.2 et 4.3 : comment corriger votre app"
description: "Refus App Store pour la règle 4.2 (fonctionnalité minimale) ou 4.3 (spam) ? Ce que dit Apple, les causes, comment corriger l’app, répondre ou faire appel."
url: https://develak.com/fr/blog/refus-app-store-guideline-4-2-4-3/
language: fr
updated: 2026-10-03
source: Develak
translations:
en: https://develak.com/blog/app-store-guideline-4-2-4-3-rejection.md
---
Page canonique :
[Guides](https://develak.com/fr/blog/) 14 min de lecture
# Refus App Store pour les règles 4.2 et 4.3 : fonctionnalité minimale et spam, expliqués (2026)
Ce que disent vraiment les règles 4.2 (Minimum Functionality) et 4.3 (Spam) de l’App Store, pourquoi les apps web encapsulées, trop minces, issues de modèles ou en doublon sont refusées, la place des widgets et Live Activities, et comment répondre à App Review ou faire appel.
Studio Develak
Publié le 3 octobre 2026
[Read in English](https://develak.com/blog/app-store-guideline-4-2-4-3-rejection/)
La règle 4.2 (Minimum Functionality) refuse les apps qui n’en font pas assez par elles-mêmes : site web reconditionné, collection de liens, écran unique sans profondeur, app générée à partir d’un modèle commercial. La règle 4.3 (Spam) refuse les apps qui se dupliquent, comme une même app publiée sous plusieurs identifiants de bundle, ou qui n’apportent rien à une catégorie déjà saturée. Pour passer, donnez à l’app une valeur native qui fonctionne sans votre site, une raison d’être distincte de toutes les autres apps (y compris les vôtres), et expliquez cette différence à App Review dans une réponse courte et factuelle avant d’envisager un appel.
## Points clés
- La 4.2 juge l’app elle-même : elle doit être plus qu’un site web, un catalogue de liens ou une action triviale, et offrir une valeur durable.
- La 4.3 juge l’app par comparaison : pas plusieurs identifiants de bundle pour la même app, pas de quasi-copie de ce qui existe déjà en abondance.
- Widgets, Live Activities et App Clips prolongent une app ; les règles attendent qu’ils se rattachent à son contenu, donc l’app principale doit tenir debout seule.
- Les apps issues d’un modèle ou d’un générateur (4.2.6) doivent être soumises par le fournisseur du contenu, ou regroupées dans une seule app « sélecteur ».
- Répondez d’abord dans la section App Review d’App Store Connect (4 000 caractères au plus, pièces jointes possibles) ; ne saisissez l’App Review Board que si l’app a été mal comprise.
- Un portefeuille d’apps de niche est légitime quand chaque app résout un problème différent ; les variantes d’une même app vont dans une seule app.
## Ce que disent vraiment les règles 4.2 et 4.3
Les deux règles figurent dans la section 4, Design, des [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/), publiées en anglais (version citée ici : mise à jour du 8 juin 2026 ; les extraits sont traduits librement). Les messages de refus les citent par leur numéro, parfois avec un sous-point : mieux vaut savoir exactement ce que chacune couvre.
### Règle 4.2 : Minimum Functionality
Le [texte principal de la 4.2](https://developer.apple.com/app-store/review/guidelines/#minimum-functionality) demande des fonctions, du contenu et une interface qui élèvent l’app au-delà d’un « site web reconditionné » (repackaged website). Il ajoute qu’une app qui n’est pas particulièrement utile, unique ou « app-like » n’a pas sa place sur l’App Store, et qu’une app sans valeur de divertissement durable ou sans utilité suffisante peut être refusée. Les sous-points précisent :
| Sous-point | Ce qu’il couvre |
| --- | --- |
| 4.2.1 | Les apps ARKit doivent offrir une réalité augmentée riche et intégrée ; poser un modèle dans une vue AR ou rejouer une animation ne suffit pas. |
| 4.2.2 | Hors catalogues, une app ne doit pas être d’abord un support marketing, une publicité, un extrait de site web, un agrégateur de contenu ou une collection de liens. |
| 4.2.3 | (i) L’app fonctionne seule, sans exiger l’installation d’une autre app. (ii) Si elle doit télécharger des ressources au premier lancement, elle annonce la taille et demande l’accord de l’utilisateur. |
| 4.2.4 et 4.2.5 | Marqués « Intentionally omitted » (retirés) dans la version actuelle. |
| 4.2.6 | Les apps créées à partir d’un modèle commercial ou d’un service de génération d’apps sont refusées, sauf si elles sont soumises directement par le fournisseur du contenu. |
| 4.2.7 | Règles pour les clients de bureau à distance : hôte appartenant à l’utilisateur sur un réseau local, logiciels exécutés sur l’hôte, pas d’interface de type boutique, pas de clients légers pour des apps cloud. |
*Les sous-points de la règle 4.2, résumés d’après les App Review Guidelines*
### Règle 4.3 : Spam
La [règle 4.3](https://developer.apple.com/app-store/review/guidelines/#spam) comporte deux volets :
- **4.3(a), les doublons.** Ne créez pas plusieurs identifiants de bundle pour la même app. L’exemple d’Apple : une app de carte par ville au lieu d’une seule carte mondiale. Les variantes par lieu, équipe sportive ou université doivent vivre dans une seule app, débloquées par des options ou un achat intégré.
- **4.3(b), les catégories saturées.** Ne soumettez pas d’app impossible à distinguer de ce qui existe déjà en abondance. Apple cite les apps de rencontre, lampes torches, effets sonores, fonds d’écran, minuteurs simples et voyance : de nouvelles soumissions n’y sont acceptées que si elles offrent une expérience « sensiblement différente ou améliorée ». Les soumissions répétées d’apps de faible qualité peuvent mener à l’exclusion de l’Apple Developer Program.
La [page App Review d’Apple](https://developer.apple.com/distribute/app-review/) range les deux parmi les problèmes courants. Sous « Not enough lasting value », elle prévient qu’une app qui offre peu de fonctions ou de contenu, ou qui ne concerne qu’un « tout petit marché de niche », peut ne pas être acceptée. Sous « Repeated submission of similar apps », elle conseille de regrouper les apps quasi identiques en une seule.
## Pourquoi une app est refusée pour la 4.2
L’examinateur juge ce qu’il voit dans le build, sur un appareil. Les situations qui mènent à un refus pour fonctionnalité minimale se ressemblent :
- **Les apps web encapsulées.** Une `WKWebView` qui charge votre site, avec une barre d’onglets par-dessus : c’est le cas d’école. La page App Review d’Apple rappelle qu’un site servi dans une app, un contenu web non adapté à iOS et des interactions web limitées ne font pas une app de qualité. Le problème n’est pas la technologie web en soi, mais une app qui se contente de refléter un site.
- **Les apps vitrines et de liens (4.2.2).** Une plaquette d’entreprise, une liste de liens, un lecteur RSS pour un seul blog, une page de boutons de contact.
- **Les utilitaires trop minces.** Un écran, une action, rien d’enregistré, aucune raison de revenir : un convertisseur isolé, un compteur, une fiche de référence statique. Plus la tâche est simple, plus le reste de l’app doit compenser.
- **Les apps issues de modèles ou de générateurs (4.2.6).** Agences et outils de création d’apps qui publient une app par client à partir du même modèle, sous leur propre compte. Les solutions prévues par Apple : le client soumet l’app sous son propre compte, ou le fournisseur publie une seule app agrégée avec une entrée par client.
- **Les apps qui dépendent d’une autre app (4.2.3).** Une app compagnon qui ne fait rien tant qu’une autre app n’est pas installée.
- **Une première impression incomplète.** Des écrans vides sans contenu d’exemple, ou des fonctions derrière une connexion sans compte de démo, font paraître l’app plus mince qu’elle ne l’est.
### Live Activities, widgets et App Clips : une app peut-elle se limiter à cela ?
Des recherches comme « live activity guideline 4.2 » viennent de développeurs dont l’app est surtout une Live Activity ou un widget, avec un écran principal qui se résume à un bouton « Démarrer ». Aucune règle ne cite les Live Activities dans la 4.2 ; voici ce qu’Apple documente réellement :
- **Règle 2.5.16 :** les widgets, extensions et notifications doivent se rapporter au contenu et aux fonctions de l’app. Ce sont des prolongements d’une app, pas des substituts.
- **Les Live Activities** se construisent avec ActivityKit, dans une extension de widget. Les [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/live-activities) les réservent aux tâches et événements qui ont un début et une fin, et ActivityKit les termine au bout de huit heures au plus (elles peuvent rester jusqu’à quatre heures de plus sur l’écran verrouillé). Elles ne doivent afficher ni publicité ni promotion, et la règle 4.5.3 interdit de s’en servir pour du spam.
- **Les widgets** affichent un contenu consultable d’un coup d’œil, rafraîchi périodiquement, et renvoient vers la bonne partie de l’app ; les HIG notent que reproduire l’icône de l’app n’apporte pas grand-chose.
- **Les App Clips** sont une partie légère d’une app complète, pour une tâche rapide ou une démo ; ils accompagnent l’app, ils ne la remplacent pas.
Notre lecture, qui n’engage que nous et pas Apple : l’examinateur ouvre d’abord l’app principale ; si elle ne sert qu’à lancer une Live Activity ou à héberger un widget, un refus 4.2 est probable. La solution consiste à donner une raison d’ouvrir l’app : historique des sessions, réglages qui changent ce que suit la Live Activity, statistiques, chronologie, export des données. La Live Activity ou le widget devient alors la surface pratique d’une vraie app.
*Illustration : un auto-contrôle avant soumission. Il reflète notre lecture des règles 4.2 et 4.3, pas une procédure officielle d’Apple.*
## Pourquoi une app est classée comme spam (4.3)
Un refus 4.3 porte rarement sur une app isolée. Il compare la soumission au reste de l’App Store et, pour les doublons, aux autres apps que vous soumettez :
- **Une app, plusieurs noms.** Le même binaire avec un autre thème, une autre ville, une autre langue ou un autre public, chacun sous son propre identifiant de bundle : c’est exactement l’exemple de la 4.3(a).
- **Les modèles repeints.** Un code source acheté ou un modèle générique republié avec de nouvelles couleurs et une nouvelle icône ; écrans, parcours et descriptions restent reconnaissables.
- **Les catégories encombrées, sans nouveauté.** Une énième lampe torche, app de fonds d’écran ou minuteur simple, avec les mêmes fonctions que des centaines d’autres (4.3(b)).
- **Des fiches qui se ressemblent.** Plusieurs apps d’un même compte avec des captures, descriptions et mots-clés presque identiques font passer des apps différentes pour des doublons.
Deux règles voisines à ne pas confondre : copier l’app d’un autre, son nom ou son interface relève de la 4.1 (Copycats), et le bourrage de mots-clés de la 2.3 (Accurate Metadata). Notre [checklist de soumission App Store](https://develak.com/fr/blog/checklist-soumission-app-store/) couvre ces refus et les autres motifs fréquents.
## Comment faire passer une app à la 4.2
La fonctionnalité minimale ne se mesure pas au nombre de fonctions. La vraie question : quelqu’un rouvrira-t-il cette app la semaine prochaine, et pourrait-elle aussi bien exister sous forme de site ? Ces changements vont dans le bon sens :
| Signal faible | Signal plus solide |
| --- | --- |
| Tout se charge depuis votre site | Écrans clés natifs et utilisables hors ligne, données locales (SwiftData, Core Data ou fichiers) et synchronisation iCloud quand elle a du sens |
| Une action, rien de conservé | Historique, recherche, statistiques, rappels : des raisons de revenir |
| Le widget ou la Live Activity est tout le produit | L’app contient les données et les réglages ; le widget ou la Live Activity y donne un accès rapide |
| Interface générique, contenus provisoires | Conventions de la plateforme, Dynamic Type, mode sombre, contenu d’exemple au premier lancement |
| Aucune intégration à l’appareil | Des fonctions adaptées à la raison d’être : notifications, App Intents et Raccourcis, HealthKit, appareil photo, Apple Watch |
| Connexion obligatoire sans démo | Compte ou mode de démo, et notes de vérification qui disent quoi tester |
*Ce qui ressemble à une « fonctionnalité minimale » et ce qui ressemble à une vraie app*
Ajoutez des intégrations parce qu’elles servent l’usage, pas pour décorer : un widget qui ne fait que reprendre l’icône de l’app n’impressionnera personne. Si votre produit est d’abord un service web, demandez-vous tôt si une app native se justifie ; notre comparatif [SwiftUI, Flutter ou React Native](https://develak.com/fr/blog/swiftui-flutter-ou-react-native/) aide à choisir comment la construire. Et testez le build exact qu’examinera Apple, depuis une installation neuve, via [TestFlight](https://develak.com/fr/blog/guide-testflight/) : les tests externes passent eux aussi par une vérification bêta.
Pour une première version, le périmètre compte plus que la finition. Un [MVP](https://develak.com/fr/services/developpement-mvp-application/) doit être la plus petite app qui apporte déjà une valeur durable par elle-même, pas une coquille qui promet des fonctions pour plus tard.
## Publier beaucoup d’apps de niche en gardant chacune distincte
Develak publie plus de 30 apps sur l’App Store, la plupart pour une niche précise : la 4.3 est donc une règle à laquelle nous pensons avant d’écrire la moindre ligne de code. Partager une architecture, un système de design et des composants entre apps relève de la bonne ingénierie, et ce n’est pas ce que vise la 4.3. Ce qui compte, c’est que chaque app réponde à un besoin différent. Deux apps de sport de notre catalogue illustrent l’idée : [TenRing](https://develak.com/fr/applications/tenring/) enregistre les scores de tir à l’arc et la position des flèches, [Cragly](https://develak.com/fr/applications/cragly/) tient le journal et les statistiques des séances d’escalade. Même studio, mais des utilisateurs, des données et des écrans différents.
Les règles que nous appliquons avant de lancer une nouvelle app :
1. **Un problème par app.** Si deux idées ne diffèrent que par le public, la région ou le thème, c’est une seule app avec des options, pas deux apps.
2. **Un modèle de données propre.** Si les entités et les écrans principaux sont ceux d’une autre app, la raison d’être l’est probablement aussi.
3. **Une valeur native adaptée à la niche.** Les fonctions qu’un utilisateur de cette niche attend, disponibles hors ligne.
4. **Une fiche App Store à elle.** Nom, icône, sous-titre, captures et description écrits pour cette app, pas adaptés d’une app sœur. Une fiche distincte, c’est aussi une meilleure [optimisation App Store (ASO)](https://develak.com/fr/services/optimisation-app-store-aso/).
5. **Des notes de vérification qui énoncent la différence.** Une ou deux phrases sur le public visé et ce que l’app fait que les autres ne font pas.
*Illustration : la checklist que nous appliquons avant d’ajouter une app à un portefeuille.*
## Répondre dans App Review (l’ancien Resolution Center)
Les messages de refus arrivent dans la section App Review de la page de l’app dans App Store Connect, longtemps appelée Resolution Center. D’après l’[aide d’App Store Connect](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/), il suffit d’ouvrir le problème non résolu, de cliquer sur Resolve puis sur Reply to App Review ; la réponse accepte jusqu’à 4 000 caractères et des pièces jointes (captures, documents). Les rôles Account Holder, Admin et App Manager peuvent répondre. Si le refus ne portait que sur les métadonnées, vous pouvez soumettre à nouveau le même build une fois la correction faite.
Une bonne réponse à un refus 4.2 ou 4.3 est courte et vérifiable :
- Remerciez l’examinateur et rappelez la règle citée, pour que l’échange reste centré sur un seul sujet.
- Décrivez en trois ou quatre points concrets ce que l’app fait et qu’un site ou une app sœur ne fait pas.
- Donnez les étapes exactes pour atteindre ces fonctions, un compte de démo si besoin, et joignez un court enregistrement d’écran.
- Si vous avez modifié l’app, dites ce qui a changé et dans quel numéro de build.
- Restez factuel. Comparer avec d’autres apps acceptées aide rarement : chaque app est examinée pour elle-même.
*Illustration : un échange App Review stylisé. Le message de l’examinateur est paraphrasé, ce n’est pas un vrai message d’Apple.*
Un cas particulier : pour une mise à jour corrective d’une app déjà publiée, les règles prévoient que les correctifs ne sont pas retardés pour des manquements aux règles, sauf problèmes juridiques ou de sécurité. Indiquez à App Review, dans l’échange, que vous souhaitez en bénéficier et que vous traiterez le problème dans la prochaine soumission.
## Quand faire appel auprès de l’App Review Board
Un appel s’adresse à l’App Review Board via le [formulaire d’appel](https://developer.apple.com/contact/app-store/?topic=appeal) d’Apple, pas via le fil de messages. La page App Review d’Apple le réserve aux cas où vous estimez que l’examinateur a mal compris le concept et les fonctions de l’app, ou que vous avez été traité injustement. Elle demande d’expliquer précisément pourquoi l’app respecte les règles, de ne déposer qu’un appel par soumission refusée, et de répondre d’abord à toute demande d’information en attente.
- **Faites appel** si l’examinateur est passé à côté de fonctions bien présentes (derrière l’accueil, une connexion ou un réglage), ou a traité une app réellement différente comme un doublon, et que votre réponse dans l’échange n’a rien réglé.
- **Ne faites pas appel** si l’app est vraiment un site encapsulé, un modèle repeint ou une variante d’une autre app du compte. Corrigez le produit : ajoutez de la valeur native, ou fusionnez les variantes en une seule app.
- **Demandez conseil** avant un gros changement : Apple propose des rendez-vous App Review de 30 minutes sur Webex pour discuter des règles.
Soumettre à nouveau le même build sous un autre nom n’est pas une stratégie. Les règles précisent qu’une app refusée à répétition pour le même manquement est examinée plus lentement, et la 4.3(b) prévient que des soumissions répétées de faible qualité peuvent coûter le compte développeur.
## Comment Develak traite les règles 4.2 et 4.3
Pour nos apps comme pour nos clients, nous vérifions la 4.2 et la 4.3 dès l’idée, pas après un refus : l’app fonctionne-t-elle hors ligne, fait-elle quelque chose qu’un site ne peut pas faire, se distingue-t-elle de tout ce que contient déjà le compte ? Avant la soumission, nous rédigeons des notes de vérification qui expliquent la raison d’être de l’app et comment la tester. Nul ne peut garantir une validation, puisque seule Apple décide, mais cette méthode évite les mauvaises surprises. Si vous préparez une app, notre offre de [développement d’application iOS](https://develak.com/fr/services/developpement-application-ios/) couvre la réalisation et les échanges avec App Review, ou [parlez-nous de votre projet](https://develak.com/fr/contact/).
## FAQ
### Que signifie « Guideline 4.2 – Design – Minimum Functionality » ?
L’examinateur estime que l’app n’offre pas assez de fonctions, de contenu ou de valeur propre à une app : le plus souvent un site reconditionné, une collection de liens, un support marketing ou un utilitaire trop mince. La solution : ajouter des fonctions natives à valeur durable, puis les expliquer dans votre réponse, avec les étapes de test et un enregistrement d’écran.
### Une app peut-elle se limiter à une Live Activity ou à un widget ?
Aucune règle ne cite les Live Activities dans la 4.2, mais ce sont, comme les widgets, des extensions que la règle 2.5.16 rattache au contenu et aux fonctions de l’app. Une app principale qui ne sert qu’à lancer une Live Activity risque d’être jugée trop mince. Donnez-lui sa propre valeur (historique, réglages, statistiques) et laissez la Live Activity ou le widget la mettre en avant.
### Toute app qui utilise une vue web est-elle refusée ?
Non. Beaucoup d’apps acceptées affichent du contenu web. Le problème, c’est une app qui est surtout un site : même contenu, même navigation, peu ou pas de natif. Si l’expérience principale fonctionne hors ligne et tire parti de la plateforme, une vue web pour des pages secondaires comme l’aide ou les conditions d’utilisation ne pose pas de problème.
### Peut-on publier plusieurs apps similaires depuis un même compte ?
Plusieurs apps, oui ; plusieurs versions de la même app, non. La règle 4.3(a) demande de ne pas créer plusieurs identifiants de bundle pour une même app et de gérer les variantes par lieu, équipe ou public dans une seule app, par exemple avec un achat intégré. Des apps aux raisons d’être, aux données et aux publics différents peuvent partager code et design sans enfreindre la règle.
### Après un refus 4.2 ou 4.3, faut-il répondre, soumettre à nouveau ou faire appel ?
Répondez d’abord, dans la section App Review d’App Store Connect, si l’examinateur est passé à côté de quelque chose. Soumettez un nouveau build si la critique est fondée et que vous avez modifié l’app. Ne faites appel auprès de l’App Review Board que si vous pensez toujours que l’app a été mal comprise, arguments précis à l’appui, et une seule fois par soumission refusée.
Écrit par
## Le studio Develak
Develak est un studio indépendant d’applications iOS. Nous avons publié 34 apps sur l’App Store depuis 2025, traduites jusqu’en 44 langues, et nous écrivons ces guides à partir de cette expérience de terrain.
[Voir nos 34 apps](https://develak.com/fr/applications/) [Découvrir le studio](https://develak.com/fr/a-propos/)
## D’autres guides iOS
[Tous les guides](https://develak.com/fr/blog/)
Guides 12 min de lecture
### [Guide TestFlight (2026) : testeurs internes et externes, revue bêta et lien public](https://develak.com/fr/blog/guide-testflight/)
Le fonctionnement de TestFlight en 2026 : testeurs internes ou externes, groupes, lien public et critères, revue TestFlight, envoi et traitement des builds, conformité à l’exportation, retours et plantages, et solutions aux statuts « Missing Compliance », builds bloqués ou expirés.
3 octobre 2026
Guides 14 min de lecture
### [Manifeste de confidentialité iOS (PrivacyInfo.xcprivacy) en 2026 : API à motif obligatoire, SDK et ITMS-91053](https://develak.com/fr/blog/manifeste-confidentialite-ios/)
Le guide pratique 2026 du manifeste de confidentialité iOS : les quatre clés de PrivacyInfo.xcprivacy, tous les codes des API à motif obligatoire, les manifestes et signatures des SDK tiers, le rapport de confidentialité Xcode, et comment corriger ITMS-91053 et les autres e-mails d’App Store Connect.
3 octobre 2026
Guides 10 min de lecture
### [Étude de cas : Xlocalize, une app Mac qui traduit les String Catalogs de Xcode par IA](https://develak.com/fr/blog/etude-de-cas-xlocalize/)
Comment Xlocalize, l’app Mac de Develak pour les fichiers .xcstrings, aborde la localisation par IA : format natif de Xcode préservé sans perte, contexte par clé, votre propre clé OpenAI, Claude ou Gemini dans le trousseau, alertes de validation et erreurs signalées clairement. Uniquement des faits publics issus du Mac App Store.
3 octobre 2026
## De ce guide à votre app publiée
Develak conçoit, développe et publie des apps iOS natives pour des fondateurs et des équipes du monde entier, en français comme en anglais.
[Démarrer un projet](https://develak.com/fr/contact/) [contact@develak.com](mailto:contact@develak.com)
---
*Version Markdown de pour les assistants IA, publiée par Develak. Les liens mènent aux pages web ; ajoutez .md à l’URL d’une page pour obtenir sa version Markdown. Index du site : .*