# Guideline 3.2.2 Unacceptable : modèle économique refusé

> Guideline 3.2.2 : Apple refuse qu'une fonction dépende d'une note ou qu'un avis soit récompensé. Récompense une action dans l'app, jamais sur l'App Store.

Page originale : [Guideline 3.2.2 Unacceptable : modèle économique refusé](https://devoria.fr/blog/guideline-3-2-2-modele-economique-refuse)
Auteur : [Mehdi Azizi](https://devoria.fr/mehdi-azizi)
Publication : 2026-11-04
Dernière révision du contenu : 2026-11-04


La guideline 3.2.2 liste les modèles économiques qu'Apple refuse. **Pour une app indépendante, le piège classique est d'échanger une note, un avis ou un téléchargement contre un avantage.** Tu peux récompenser une action dans l'app, comme finir un niveau ou regarder une pub. Pas une action sur l'App Store.

Je publie mes propres apps iOS : Solys, TradaZen et Nolera sont sur l'App Store. Ce guide s'appuie sur le texte officiel d'Apple, lu le 15 octobre 2026 dans sa version du 8 juin 2026, et sur des refus 3.2.2 publiés par des développeurs. Les pratiques citées plus bas sont des exemples. Le moment de la demande d'avis relève d'une autre règle, que je détaille dans le guide de la [guideline 5.6.3](https://devoria.fr/blog/guideline-5-6-3-demande-avis-app-store).

## Que dit la guideline 3.2.2 ?

La 3.2.2 se trouve dans la section 3.2, « Other Business Model Issues », des [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#3.2.2). Apple y oppose une liste « Acceptable », la 3.2.1, et une liste « Unacceptable », la 3.2.2. Il précise que ces listes ne sont pas exhaustives.

Dans la version actuelle, la 3.2.2 compte dix alinéas, dont deux vides.

| Alinéa | Ce qui est refusé                  |
| ------ | ---------------------------------- |
| (i)    | Une vitrine d'apps tierces         |
| (ii)   | Vide (« omitted »)                 |
| (iii)  | Gonfler les pubs, app à pubs       |
| (iv)   | Dons sans agrément                 |
| (v)    | Accès restreint sans raison        |
| (vi)   | Vide (« omitted »)                 |
| (vii)  | Gonfler un rang ailleurs           |
| (viii) | Options binaires, CFD sans licence |
| (ix)   | Prêt à plus de 36 % par an         |
| (x)    | Forcer à noter, à télécharger      |

Pour une app indépendante, l'alinéa qui compte le plus est le (x) : « Apps must not force users to rate the app, review the app, download other apps ». Il interdit d'exiger une note, un avis, le téléchargement d'une autre app ou une autre action liée au store pour accéder à une fonction, à un contenu ou à l'app. La phrase suivante fixe la limite : « Apps may otherwise incentivize users to take specific actions within apps ». Les exemples donnés : finir un niveau, regarder une pub.

L'introduction de la [section 3](https://developer.apple.com/app-store/review/guidelines/#3) complète la règle. Apple y vise les avis et classements gonflés par des retours « paid, incentivized, filtered, or fake » : payés, récompensés, filtrés ou faux. La sanction annoncée peut aller jusqu'à l'exclusion du programme développeur.

**Une note ou un avis ne s'achète pas : ni en argent, ni en pièces, ni en fonction débloquée.**

## Ce que la 3.2.2 ne couvre pas

Plusieurs articles en ligne attribuent à la 3.2.2 des cas que le texte actuel range ailleurs. Trois règles voisines comptent pour une app indépendante.

- **Faire payer une fonction du système : 4.10.** La [guideline 4.10](https://developer.apple.com/app-store/review/guidelines/#4.10) interdit de monétiser les capacités de l'appareil ou d'iOS, comme les notifications push, l'appareil photo ou le gyroscope. Elle cite aussi des services d'Apple : stockage iCloud, API Temps d'écran.
- **Imposer une tâche après l'achat : 3.1.2(a).** La [règle 3.1.2(a)](https://developer.apple.com/app-store/review/guidelines/#3.1.2) demande qu'on obtienne ce qu'on a payé sans tâche en plus : publier sur les réseaux, importer ses contacts, ouvrir l'app un certain nombre de fois.
- **Passer à l'abonnement : 3.1.2(a) aussi.** Tu ne dois pas retirer la fonction principale à ceux qui l'ont déjà payée. Le détail est dans le guide de la [guideline 3.1.2](https://devoria.fr/blog/guideline-3-1-2-abonnement-app-store).

## Les cas les plus fréquents pour une app indépendante

Les quatre cas ci-dessous sont des exemples construits pour illustrer la règle.

### Débloquer une fonction contre une note

Exemple : « Note l'app pour débloquer le thème sombre. » C'est exactement ce que l'alinéa (x) interdit. Et le mécanisme ne tient pas techniquement : la fenêtre de notation d'Apple peut ne pas s'afficher, et elle ne dit pas à ton app si la personne a noté.

La sortie : demande la note avec la fenêtre du système, après une réussite, sans condition. Le thème sombre se débloque autrement, gratuitement ou par un achat intégré.

### Récompenser un avis ou un téléchargement

Exemple : « 100 pièces pour un avis 5 étoiles », ou un mur d'offres qui donne des pièces pour installer d'autres apps. Le premier achète un avis, et le « 5 étoiles » le filtre. Le second paie des téléchargements. Un refus 3.2.2 de 2019, [publié sur les forums d'Apple](https://developer.apple.com/forums/thread/115883), visait justement un mur d'offres : « Your app includes content or features that can manipulate the user reviews or chart ranking on the App Store. »

La sortie : récompense des actions qui se passent dans ton app. Finir le tutoriel, gagner trois parties, terminer un défi.

### La pub récompensée

La vidéo récompensée est autorisée : le (x) cite lui-même « watching an ad » parmi les actions qu'une app peut encourager. Deux limites. L'alinéa (iii) refuse les apps conçues surtout pour afficher des pubs. Et un refus de 2022, [publié par un développeur](https://developer.apple.com/forums/thread/705534), dit : « The primary purpose of your app is to encourage users to watch ads or perform marketing-oriented tasks ».

Un autre développeur [rapporte un appel avec un reviewer](https://developer.apple.com/forums/thread/685104) en 2021 : selon lui, les récompenses de valeur réelle, comme l'argent ou les cartes cadeaux, n'étaient pas admises, seulement les récompenses dans l'app. **Garde la pub en option, et la récompense à l'intérieur de l'app.** Le calcul de ce qu'elle rapporte est dans [combien rapporte une application mobile](https://devoria.fr/blog/combien-rapporte-une-application-mobile).

### Rendre payante une fonction gratuite

Exemple : une mise à jour place derrière l'abonnement l'export PDF, gratuit jusque-là. Aucun alinéa de la 3.2.2 ne vise ce cas, et le texte n'interdit pas de faire évoluer ton offre. Ce qu'il protège, c'est ce qui a été payé : quand une app passe à l'abonnement, la 3.1.2(a) demande de laisser à ceux qui ont déjà payé la fonction principale achetée.

Deux précautions. La [guideline 2.3.2](https://developer.apple.com/app-store/review/guidelines/#2.3.2) demande que la description et les captures indiquent clairement ce qui exige un achat : mets ta fiche à jour. Explique aussi le changement dans les notes de revue. Ce que je ferais en plus, par choix et non par obligation : laisser l'export à ceux qui l'utilisaient déjà. Le choix entre les modèles est comparé dans [abonnement ou achat unique](https://devoria.fr/blog/abonnement-ou-achat-unique-app-ios).

## Le tableau : pratique, 3.2.2 et alternative conforme

Voici ma grille avant chaque envoi. La colonne du milieu dit si la pratique tombe sous la 3.2.2, sous une autre règle, ou sous aucune.

| Pratique                     | 3.2.2 ?              | Alternative conforme          |
| ---------------------------- | -------------------- | ----------------------------- |
| Fonction contre une note     | Oui, alinéa (x)      | Demande système après succès  |
| Pièces contre un avis        | Oui, avis récompensé | Pièces pour un niveau fini    |
| Bonus pour installer une app | Oui, alinéa (x)      | Bonus pour une action interne |
| Mur d'offres d'installation  | Oui, en pratique     | Vidéo récompensée simple      |
| « Tu aimes l'app ? » d'abord | Risque, avis filtré  | Même demande pour tous        |
| Vidéo pub contre un bonus    | Non, autorisée       | La garder optionnelle         |
| App faite surtout de pubs    | Oui, alinéa (iii)    | Une vraie fonction d'abord    |
| Carte cadeau contre des pubs | Oui, en pratique     | Récompense dans l'app         |
| Notifications payantes       | Non : règle 4.10     | Faire payer ton service       |
| Partage exigé après achat    | Non : 3.1.2(a)       | Débloquer dès le paiement     |
| Gratuit devenu payant        | Non, aucun alinéa    | Fiche et notes à jour         |
| Achat à vie retiré           | Non : 3.1.2(a)       | Honorer les achats passés     |

Deux points demandent une précision. « Oui, en pratique » renvoie aux refus publiés cités plus haut, pas à un alinéa qui nomme ces cas. Le « Tu aimes l'app ? » qui n'envoie vers la note que les gens contents filtre les avis, ce que vise l'introduction de la section 3. Je le classe en risque, faute d'avoir lu un refus publié sur ce cas précis.

## Corriger un refus 3.2.2

La phrase qui suit l'intitulé dit ce que le reviewer a vu. Trois formulations publiées sur les forums d'Apple reviennent :

- « encourage users to watch ads or perform marketing-oriented tasks » : c'est le modèle entier qui pose problème, pas un écran.
- « manipulate the user reviews or chart ranking » : une récompense contre un avis ou un téléchargement.
- « displays or promotes third-party apps » : la promotion d'autres apps, [jusque dans des pubs](https://developer.apple.com/forums/thread/765722) selon un développeur.

Ensuite :

1. **Retire le mécanisme, pas seulement le texte.** Si la récompense existe dans le code, le reviewer la retrouvera. Prévois un nouveau build.
2. **Remplace-le par l'alternative du tableau.** Une note demandée par la fenêtre du système, une récompense pour une action dans l'app.
3. **Écris des notes de revue précises** : ce qui a changé, et où le vérifier.
4. **Fais appel seulement si l'app a été mal comprise.** Réponds d'abord dans App Store Connect. L'[App Review Board](https://developer.apple.com/help/app-review/after-submitting-for-review/appeal-to-the-app-review-board) accepte ensuite un seul appel par app refusée.

Le modèle de notes que j'utiliserais, en anglais, à adapter :

```text
Hello App Review team,

Thank you for your feedback regarding Guideline 3.2.2.

What changed in build [X]:
- Users no longer receive [reward] for [rating the app /
  writing a review / downloading other apps].
- [Feature] is now available [for free / through in-app
  purchase], with no store-related action required.
- Ratings are requested only through the system prompt,
  after [completed action], for every user.

Where to check: [screen > step].

Best regards,
[Your name]
```

N'écris que ce qui existe dans le build envoyé.

## La checklist 3.2.2 avant soumission

- Aucune fonction ni aucun contenu ne dépend d'une note, d'un avis ou d'un téléchargement.
- Aucune récompense contre un avis, même pour un avis « honnête ».
- La demande de note est la même pour tous, sans question de tri avant.
- Les récompenses viennent d'actions dans l'app, et restent dans l'app.
- La pub récompensée est optionnelle, et l'app a une vraie fonction sans elle.
- Rien de payant ne porte sur une fonction du système en tant que telle.
- Si une fonction gratuite devient payante, la fiche et les notes de revue le disent.

## Un modèle économique conforme dès ta prochaine soumission

Si ton app vient d'être refusée en 3.2.2, le [Kit Review Apple](https://devoria.fr/kits/review-apple) t'aide à retrouver la règle citée et ce qu'elle demande, avec des modèles de notes pour le testeur. Si tu construis ton modèle économique, le [Kit iOS](https://devoria.fr/kits/ios) fournit un onboarding, un paywall et des abonnements déjà codés, que tu règles. Les erreurs de paywall les plus courantes sont dans [paywall iOS : les erreurs de débutant](https://devoria.fr/blog/paywall-ios-erreurs-debutant). Pour un regard humain, [réserve une heure avec moi](https://devoria.fr/coaching).

La démarche complète est sur la page [application refusée par Apple](https://devoria.fr/expertise/application-refusee-par-apple), et le volet technique sur la page [abonnements in-app iOS](https://devoria.fr/expertise/abonnement-in-app-ios). Si tu prépares ta première sortie, [fais ton diagnostic gratuit](https://devoria.fr/diagnostic) : il remet les étapes dans l'ordre et t'envoie ma checklist anti-refus Apple. L'accueil montre comment [créer une application mobile](https://devoria.fr/) avec la review en tête dès le départ.

## Questions fréquentes

### Que veut dire « Guideline 3.2.2 - Business - Other Business Model Issues - Unacceptable » ?

Apple juge que ton modèle économique fait partie des pratiques refusées par la 3.2.2. La phrase qui suit l'intitulé précise le problème : pubs au cœur de l'app, promotion d'autres apps, récompense contre un avis. Le message ne cite pas toujours l'alinéa : relis la liste et tes mécanismes de récompense.

### Peut-on offrir une récompense contre un avis sur l'App Store ?

Non. L'introduction de la section 3 vise les avis récompensés, et l'alinéa (x) interdit de conditionner une fonction à une note. Demande la note avec la fenêtre du système, de la même façon pour tout le monde, sans rien promettre.

### Les vidéos récompensées sont-elles autorisées ?

Oui. L'alinéa (x) cite « watching an ad » parmi les actions qu'une app peut encourager. Le refus arrive quand la pub devient le but de l'app, ou quand la récompense a une valeur réelle hors de l'app, comme une carte cadeau.

### Peut-on rendre payante une fonction qui était gratuite ?

Le texte ne l'interdit pas. Il protège ce qui a été payé : la 3.1.2(a) demande de ne pas retirer la fonction principale à ceux qui l'ont achetée. Mets à jour ta fiche, comme le demande la 2.3.2, et explique le changement dans les notes de revue.

### Quelle différence entre la guideline 3.2.2 et la 5.6.3 ?

La 5.6.3 interdit de manipuler l'App Store, et Apple l'applique aussi aux demandes de note mal placées, au premier lancement par exemple. La 3.2.2 vise le modèle économique : une fonction bloquée contre une note, un avis ou un téléchargement récompensé. Une même demande de note peut toucher les deux.


## Ton projet

[Kit Review](https://devoria.fr/kits/review-apple) : Tout ce que je vérifie avant d'envoyer une app à Apple, la même vérification pour Google Play, et trois skills qui font la relecture avec Claude Code. 49 €, paiement unique. Inclus : La checklist avant l'envoi ; Les refus que j'ai pris, et ce que j'ai corrigé ; Les notes pour le testeur ; Les skills de vérification. Prérequis : une app iPhone ou Android presque prête, et Claude Code ou Cursor. Téléchargement immédiat après le paiement.

[Kit iOS & Android Devoria](https://devoria.fr/kits/ios) : Le code de départ de mes apps, le parcours jusqu'à l'App Store et Google Play avec les messages à donner à Claude, et tous les kits. Claude part d'une app qui tourne déjà. 99 €, paiement unique. Inclus : Le code de départ de ton app ; Les styles visuels ; Le parcours pas à pas ; Kit Review ; Kit Captures ; Kit ASO ; Mises à jour à vie ; Bonus : la séance 1:1 à moitié prix. Prérequis : pour l'iPhone, un Mac avec Xcode 26 ou plus et un compte Apple Developer (99 $ par an) pour publier. Pour Android, Android Studio sur un Mac, un PC Windows ou Linux, et un compte Google Play Console (25 $, une fois). Et Claude Code (abonnement payant) ou Cursor. Téléchargement immédiat après le paiement.

[Diagnostic gratuit](https://devoria.fr/diagnostic) : quelques questions sur ton projet. Il dit ce qui te bloque vraiment, l'ordre des quatre étapes et le kit qui correspond. En laissant ton e-mail, tu reçois la checklist anti-refus Apple : les points vérifiés avant chaque envoi, tirés des refus reçus par les apps du studio.

[Une heure avec moi](https://devoria.fr/coaching) : On regarde ton app ou ton projet Claude, écran partagé : ce qui bloque, ce que je change en premier, et dans quel ordre. 100 € la séance d'une heure, en visio, paiement en une fois. Sujets : L'audit de ton app ; Ton travail avec Claude ; Ta fiche et ton paywall ; Un refus d'Apple.