Guideline 5.6 : le paywall qui fait refuser ton application

La guideline 5.6 est le code de conduite du développeur. Pour un paywall, Apple la cite avec une phrase type : l'app « attempts to manipulate customers into making unwanted In-App Purchases ». En clair, un bouton de ton tunnel d'achat ne fait pas ce qu'il annonce, ou une offre revient sans que l'utilisateur l'ait demandée. La correction tient en une règle : chaque bouton fait ce qu'il dit, et l'utilisateur choisit seul le moment où il revoit une offre.

J'ai pris ce refus sur TradaZen, mon app d'entraînement au trading, dont je raconte le lancement dans cette étude de cas. Voici la règle, ce que j'ai trouvé dans mon paywall, les schémas à éviter et ma réponse à Apple. Pour la règle voisine sur les demandes de note, lis plutôt le guide de la guideline 5.6.3.

Que dit la guideline 5.6 ?

La 5.6, « Developer Code of Conduct », se trouve dans la section 5 « Legal » des App Review Guidelines. Son premier paragraphe parle de respect : envers les clients, dans les réponses aux avis et dans les échanges avec Apple. Le deuxième vise directement les achats.

Le texte en vigueur pose le principe : « Customer trust is a cornerstone of the App ecosystem. » Il liste ensuite ce qu'une app ne doit jamais faire : profiter des utilisateurs, les escroquer, « trick them into making unwanted purchases », les forcer à partager des données inutiles, « raise prices in a tricky manner », faire payer ce qui n'est pas livré, ou toute autre pratique manipulatrice, dans l'app ou en dehors.

En français : tu ne dois pas obtenir un achat par la ruse. Le texte ne dresse pas de liste de boutons interdits. Il juge l'effet : l'utilisateur a-t-il payé parce qu'il le voulait, ou parce que l'écran l'a piégé ?

La 5.6 regroupe aussi quatre sous-règles :

Sous-règle	Ce qu'elle vise
5.6.1 App Store Reviews	Avis et demande de note
5.6.2 Developer Identity	Infos exactes sur toi
5.6.3 Discovery Fraud	Fraude à la visibilité
5.6.4 App Quality	Plaintes, remboursements

La sanction est écrite dans la règle : « Repeated manipulative or misleading behavior or other fraudulent conduct will lead to your removal from the Apple Developer Program. » Des comportements manipulateurs répétés mènent donc à l'exclusion du programme développeur. C'est une règle générale, et une bonne raison de corriger tout le tunnel d'achat dès le premier refus.

Le message de refus 5.6 pour un paywall

Le message reprend souvent la même phrase : « The app attempts to manipulate customers into making unwanted In-App Purchases. » Apple ne dit pas toujours quel élément est visé. Sur mon refus, il n'y avait rien de plus.

D'autres développeurs décrivent l'écran en cause. Dans un fil du forum Apple de novembre 2024, un développeur relie son refus 5.6 à une offre unique, affichée quand l'utilisateur fermait le premier écran d'abonnement.

La 5.6 ne vise pas que les paywalls. Un développeur a aussi été refusé pour des fonctions qui semblaient cachées pendant la revue. Si ton refus 5.6 ne parle pas d'achat, cherche d'abord ce que le relecteur n'a pas pu voir.

Mon refus 5.6 sur TradaZen

Le 12 octobre 2026, Apple refuse la version 1.5.1 de TradaZen, testée sur iPad Air. Motif : guideline 5.6, avec la phrase type sur les achats non voulus. Aucun écran n'est cité.

J'ai donc relu tout mon tunnel d'achat comme quelqu'un qui veut juste refuser. Le paywall de fin d'onboarding n'a pas de fermeture : l'app demande l'essai ou l'abonnement pour continuer. Trois mécanismes autour de lui pouvaient passer pour de la manipulation :

• Une fausse croix. En haut de l'écran, un bouton en forme de croix, annoncé « Fermer » à VoiceOver, ouvrait une offre réduite au lieu de fermer.
• Une offre qui revenait seule. Tant que l'offre courait, elle se rouvrait quand l'utilisateur revenait dans l'app.
• Une relance promotionnelle. Quitter l'app depuis le paywall programmait une notification qui annonçait une réduction exclusive.

Un détail compte : ces mécanismes existaient déjà dans la version précédente, acceptée trois jours plus tôt. Une acceptation ne valide pas ton paywall pour toujours : un autre relecteur peut lire le même écran autrement.

Ce que j'ai changé

• La croix a disparu de cet écran. À sa place, une icône cadeau, annoncée « Réduction exclusive » à VoiceOver, ouvre l'offre quand on la touche. Plus rien ne fait semblant de fermer.
• L'offre ne s'ouvre plus jamais seule au retour dans l'app.
• La notification de réduction est supprimée. Il reste un rappel doux, envoyé une seule fois par installation et seulement si les notifications sont autorisées. Il ne parle ni de prix, ni de réduction, ni de délai.
• Ce rappel est décrit dans le message à App Review, avec son texte et son moment d'envoi.

Ce que j'ai gardé

J'ai aussi relu ce qui restait, en me demandant si chaque élément laissait vraiment le choix.

• Une offre après un achat annulé. Si l'utilisateur annule la feuille de paiement d'Apple pour l'abonnement annuel, une offre de bienvenue s'ouvre. Elle n'a qu'une seule fenêtre de 5 minutes, qui ne redémarre pas : si l'utilisateur annule de nouveau pendant ce délai, elle se rouvre. Elle se ferme d'un geste par la croix ou par « Non merci », et affiche le vrai prix du produit.
• Un minuteur réel de 5 minutes. Son échéance est enregistrée sur l'appareil au premier affichage. Il continue quand l'app est fermée et ne repart pas à zéro à la relance. Une fois écoulé, l'offre disparaît pour cette installation de l'app. Si on la ferme avant, une petite pastille affiche le temps restant et ne rouvre l'offre que si on la touche.
• Un coffre cadenassé. Il montre les objets gagnés pendant l'onboarding, et seulement ceux-là, fermés tant que l'app n'est pas débloquée. Rien n'annonce qu'ils seront perdus.

Ces éléments figurent dans les notes de revue. Le refus ne citait aucun écran : je ne les présente donc pas comme validés par Apple. Ce sont, à mon sens, les versions transparentes de ces mécaniques, et je les ai déclarées.

Le correctif a demandé un nouveau build, puisque tout se passait dans l'app. TradaZen est repartie en revue le 13 octobre 2026.

Les dark patterns de paywall qui déclenchent la 5.6

Apple ne publie pas de liste. Une même mécanique existe souvent en deux versions : celle qui piège et celle qui laisse le choix. Ce tableau les sépare, en croisant le texte des règles, des refus publiés par d'autres développeurs et le mien. La version transparente ne garantit pas une acceptation. C'est celle qui ne cherche pas à tromper. La dernière colonne dit sur quoi repose chaque ligne.

Version manipulatrice	Version transparente	Ce qui l'appuie
Une croix qui ouvre une offre au lieu de fermer	La croix ferme. Un écran qui ne se ferme pas n'affiche pas de croix	Corrigé après mon refus TradaZen
Une offre « unique » qui surgit quand on ferme le paywall	Une réduction derrière un bouton qui l'annonce clairement	Refus publié sur le forum Apple
Une seconde offre lancée après un refus, dans un paywall au prix trompeur	Une seule offre après un achat annulé, au vrai prix, fermable en un geste	Cas Cal AI ; échange rapporté par Superwall
Un paywall ou une offre qui se rouvre seul au retour dans l'app	Il revient quand l'utilisateur touche une limite ou un bouton qui l'annonce	Corrigé après mon refus TradaZen
Une notification de promotion jamais demandée	Promotion après accord explicite, avec désinscription dans l'app	Règle 4.5.4
Un faux minuteur, qui repart à zéro ou dont l'offre revient après la fin	Un délai réel, qui continue même app fermée et s'arrête vraiment	Ma lecture de « trick them », règle 5.6
Des récompenses inventées, ou menacées de disparaître sans achat	Les gains réels de l'utilisateur, montrés sans menace de les perdre	Ma lecture de la règle 5.6
Un essai gratuit qui tait le prélèvement automatique	Durée de l'essai et prix facturé ensuite, à côté du bouton	Page abonnements d'Apple
Un prix par semaine en gros, le montant facturé en petit	Le montant facturé est le prix le plus visible de l'écran	Page abonnements d'Apple
Un bouton de refus qui culpabilise	Un refus neutre, comme « Pas maintenant » ou « Non merci »	Ma lecture de la règle 5.6

Le cas Cal AI est rapporté par TechCrunch : Apple a cité la 5.6 pour une seconde offre d'abonnement montrée à ceux qui refusaient la première. Le même paywall était aussi épinglé en 3.1.2(c) : le prix par semaine dominait le montant facturé, et l'essai masquait le renouvellement automatique. L'article ne décrit pas la seconde offre plus en détail.

À l'inverse, Superwall, un éditeur d'outils de paywall qui vend ce type d'offre, rapporte un échange officieux avec Apple en juin 2026. Une offre montrée après un achat annulé y est décrite comme permise. L'insistance ne l'est pas : une offre qui revient à chaque session, ou un parcours dont on ne sort qu'en payant. Superwall précise que ce ne sont pas des règles officielles et que le relecteur garde son jugement. Une offre après un refus reste donc une zone d'appréciation : le texte ne l'interdit pas, des refus publiés existent, et la manière compte.

La règle sur les notifications est la 4.5.4 : pas de promotion par notification sans accord explicite recueilli dans l'app, ni sans moyen de se désinscrire.

Pour le prix, la page d'Apple sur les abonnements est nette : le montant facturé doit être l'élément de prix le plus visible. La raison tient en une phrase : « This ensures that people are not misled. » La règle 3.1.2 ajoute qu'Apple retire les apps qui vendent un abonnement sous un faux jour ou par « bait-and-switch ».

Le test que j'applique maintenant : chaque bouton fait-il exactement ce que son apparence promet, et l'utilisateur peut-il dire non en un geste, sans que l'offre revienne d'elle‑même ?

Les erreurs de paywall plus classiques, celles qui coûtent des ventes sans forcément faire refuser, sont dans paywall iOS : 7 erreurs de débutant.

Comment corriger un refus 5.6

1. Liste tout ton tunnel d'achat. Paywall, offres secondaires, minuteurs, notifications, relances au retour dans l'app. Apple ne dit pas toujours ce qu'il vise. Pour chaque élément, vérifie qu'il est dans sa version transparente : fermable en un geste, minuteur réel, prix exact, aucun retour automatique. Corrige ou retire tout ce qui ressemble à un piège, pas seulement l'élément le plus probable.
2. Rejoue le parcours du relecteur. Supprime l'app, réinstalle-la, termine l'onboarding, puis refuse tout : ferme, annule, quitte l'app, reviens. Note chaque écran qui s'ouvre sans que tu l'aies demandé, et vérifie que tu peux le fermer d'un geste.
3. Prépare un nouveau build. La cause est dans l'app, donc dans le code embarqué. Une mise à jour à distance ne remplace pas le build, comme je l'explique dans le guide de la guideline 2.1.
4. Ne garde rien en réserve. Réactiver une offre à distance après l'acceptation revient à cacher une fonction au relecteur. RevenueCat met lui‑même en garde contre ce réflexe dans son article sur les offres de sortie.
5. Réponds dans App Store Connect, en anglais, en répondant au message d'App Review.

Voici une trame tirée de ma réponse et de mes notes de revue, raccourcie. Remplace le numéro de build et les changements par les tiens, puis liste ce qui reste :

Hello,

Thank you for your feedback on Guideline 5.6.

Issue: on the subscription screen, the button in the top
corner looked like a close button, but it opened a
discounted offer instead of closing the screen.

Changes in build X:
- Nothing on the subscription screen pretends to close it.
  A clearly labeled button now opens the optional offer.
- The offer never reopens by itself when the user comes
  back to the app.
- The notification announcing a discount has been removed.

Still in this build (also described in the review notes):
- [Each remaining offer: what triggers it, how often it
  appears, how the user dismisses it.]
- [Each remaining reminder: its text, when it is sent,
  and under which conditions.]

If another part of the purchase flow still looks unclear,
please tell me which screen, and I will change it.

Best regards,

Ce que tu écris doit correspondre exactement au build. Si tu gardes un rappel ou une offre, même déclenchée automatiquement, décris-les dans la réponse et dans les notes de revue. Si tu penses que le relecteur s'est trompé, Apple permet de faire appel auprès de l'App Review Board, avec un seul appel par soumission refusée. Pour un paywall, corriger me semble plus sûr que contester. Les autres motifs de refus et la façon d'y répondre sont dans pourquoi Apple refuse une app.

La checklist anti-5.6 avant l'envoi

• Chaque croix ferme l'écran. Un écran qui ne se ferme pas n'affiche pas de croix.
• Chaque bouton dit ce qu'il fait, à l'écran et pour VoiceOver.
• Aucune offre ne se cache derrière un bouton de fermeture.
• Une offre déclenchée par un refus, si tu en gardes une, tient dans une seule fenêtre qui ne redémarre pas, au vrai prix, et se ferme d'un geste.
• Aucun paywall ni aucune offre ne se rouvre seul au retour dans l'app.
• Aucune notification de promotion sans accord explicite dans l'app.
• Pas de faux minuteur : un délai affiché est réel, ne repart pas à zéro et s'arrête vraiment.
• Ce que l'écran montre comme gagné l'a vraiment été, sans menace de le perdre.
• L'essai affiche sa durée et le prix facturé ensuite.
• Le montant facturé est le prix le plus visible de l'écran.
• Les notes de revue décrivent chaque offre et chaque rappel présents dans le build.
• Tu as rejoué le parcours en refusant tout, sur iPhone et sur iPad.

Faire relire ton paywall avant Apple

Le Kit Review Apple réunit ma checklist avant l'envoi, mes refus corrigés et deux skills Claude Code qui relisent ton projet, ton paywall et ta fiche. Si Apple refuse, ils préparent ta réponse. Pour un regard humain, réserve une heure avec moi : on rejoue ton tunnel d'achat ensemble, sur ton écran. La démarche complète après un refus est sur la page application refusée par Apple, et la partie technique des abonnements sur abonnements in-app iOS.

Si tu prépares ta première sortie, fais ton diagnostic gratuit : il remet les étapes dans l'ordre et t'envoie ma checklist anti-refus Apple. L'accueil montre comment créer une application mobile avec un paywall pensé pour la review dès le départ.

Personne ne peut garantir qu'Apple acceptera ton app. Ce que je peux faire, c'est t'aider à éviter un refus 5.6 que j'ai déjà payé d'un cycle de revue.

Questions fréquentes

Que veut dire « Guideline 5.6 - Developer Code of Conduct » dans un refus ?

C'est l'intitulé de la règle sur le code de conduite du développeur. Pour une app avec achats intégrés, il signale le plus souvent un tunnel d'achat jugé manipulateur : fausse fermeture, offre qui revient seule, essai ou prix présentés de façon trompeuse. Le message ne précise pas toujours l'écran visé.

Une offre de sortie est-elle interdite par Apple ?

Le texte ne l'interdit pas en toutes lettres. RevenueCat le note aussi, tout en signalant que des développeurs ont été refusés pour ce motif. Les refus publiés visent une offre qui surgit quand l'utilisateur ferme le paywall, ou une seconde offre lancée après un refus. Ce qui sépare la version transparente : une offre facultative, limitée à une seule fenêtre qui ne redémarre pas, au vrai prix, fermable d'un geste, qui ne revient pas d'elle‑même, avec un minuteur réel s'il y en a un. Décris-la dans les notes de revue. Personne ne peut garantir qu'un relecteur la lira ainsi.

Un paywall sans croix est-il autorisé ?

Les règles n'imposent pas de croix, et c'est le choix fait sur TradaZen après ce refus. Ce qu'Apple refuse, c'est un bouton qui ressemble à une fermeture et fait autre chose. Un développeur a toutefois rapporté un refus 5.6 pour un paywall sans sortie dans une app gratuite au téléchargement. Montre la valeur avant de demander l'essai, et dis clairement dans ta fiche que l'app est payante.

Faut-il un nouveau build après un refus 5.6 ?

Oui dans la plupart des cas, parce que la cause est un écran ou un comportement de l'app. Si le problème est hors de l'app, dans la fiche ou les métadonnées, une correction sans build peut suffire. Dans le doute, demande au relecteur quel écran il vise.

Un refus 5.6 peut-il mener à la fermeture du compte développeur ?

La règle le prévoit en cas de comportements manipulateurs répétés, avec exclusion du programme développeur. Elle prévoit aussi qu'un compte fermé peut être rétabli après un plan d'amélioration écrit, approuvé puis vérifié par Apple. D'où l'intérêt de corriger tout le tunnel dès le premier refus.

Quelle différence entre la 5.6 et la 5.6.3 ?

La 5.6 est le code de conduite général : respect, confiance, aucun achat obtenu par la ruse. La 5.6.3 est une de ses sous-règles, sur la manipulation des classements, de la recherche et des avis. Apple l'a citée sur Solys pour une demande de note placée dans l'onboarding.