Paywall iOS : 7 erreurs de débutant qui bloquent tes ventes

Pourquoi ton paywall iOS ne vend pas

Ton app est sur l'App Store, les installations arrivent, et pourtant presque personne ne s'abonne. Dans la plupart des cas, le problème n'est ni ton idée ni ton code : c'est ton paywall iOS, l'écran qui présente l'offre payante et demande à l'utilisateur de s'engager. Un paywall montré au mauvais moment, sans essai gratuit, sans bouton de restauration ou sans les mentions qu'Apple exige ne vend pas, ou se fait refuser à la revue.

Voici les 7 erreurs que je vois le plus souvent sur une première app, et comment corriger chacune. Pas de recette magique : des réglages concrets, vérifiables, que tu peux appliquer avant ton prochain envoi à Apple.

Je publie mes propres apps iOS à abonnement : Solys, un réveil à mini-jeux, et TradaZen, un simulateur de trading, toutes les deux branchées sur RevenueCat. Sur les deux, j'ai vécu la même situation : beaucoup d'installations, très peu d'essais gratuits démarrés. Le produit n'était pas en cause. Le paywall et l'onboarding ne menaient pas assez clairement à l'essai. C'est une des raisons qui m'ont poussé à les retravailler en profondeur, et c'est de là que vient cette liste.

Erreur n°1 : montrer le paywall trop tôt, ou trop tard

C'est l'erreur la plus coûteuse, et elle se présente dans les deux sens.

Trop tôt, c'est le paywall qui s'affiche avant que l'utilisateur ait compris ce que fait l'app. Il ouvre l'app, voit un prix, ferme. Il n'a aucune raison de payer puisqu'il n'a encore rien vu.

Trop tard, c'est le paywall caché derrière un bouton « Premium » dans les réglages, ou qui n'apparaît qu'au bout de plusieurs jours d'usage. La plupart des utilisateurs ne le verront jamais. Or un utilisateur qui ne voit pas ton offre ne peut pas s'abonner.

Le bon moment se situe entre les deux : à la fin de l'onboarding, juste après que l'utilisateur a perçu la valeur de l'app. Il a répondu à quelques questions, il a vu ce que l'app va faire pour lui, il a peut-être testé la fonction principale. C'est là que l'offre a du sens.

Concrètement :

• l'onboarding pose des questions utiles et montre un aperçu du résultat ;
• le paywall arrive à la fin de ce parcours, pas au milieu ;
• tu peux le remontrer plus tard, à un moment où l'utilisateur touche une limite de la version gratuite.

Erreur n°2 : ne pas proposer d'essai gratuit

Pour une app que personne ne connaît encore, demander de payer tout de suite est un gros saut. L'essai gratuit réduit ce saut : l'utilisateur teste sans risque, et le paiement ne démarre qu'à la fin de la période d'essai s'il ne résilie pas.

Apple prévoit ce mécanisme sous le nom d'offre de lancement (introductory offer) pour les abonnements auto-renouvelables. Deux règles à retenir, tirées de la page d'Apple sur les abonnements :

• un client ne peut profiter que d'une seule offre de lancement par groupe d'abonnements ;
• dans le parcours d'achat, tu dois indiquer clairement la durée de l'essai et le prix facturé une fois l'essai terminé.

L'erreur fréquente, c'est de proposer un essai sans le dire. Si ton bouton affiche seulement « S'abonner », l'utilisateur ne sait pas qu'il peut essayer gratuitement. Écris-le en toutes lettres sur le bouton ou juste au-dessus : durée de l'essai, puis prix. C'est exactement le genre de détail qui fait la différence entre des installations qui dorment et des essais qui démarrent.

Erreur n°3 : mal mettre en avant l'abonnement annuel

Beaucoup de premières apps proposent un mensuel et un annuel, mais les présentent comme deux options identiques, côte à côte, sans hiérarchie. Résultat : l'utilisateur hésite, et un utilisateur qui hésite ferme souvent l'écran.

L'annuel a pourtant des avantages pour toi comme pour l'utilisateur : un prix mensuel équivalent plus bas pour lui, un engagement plus long pour toi. Pour le mettre en valeur honnêtement :

• présélectionne-le et donne-lui une présentation visuelle distincte ;
• affiche l'équivalent mensuel à côté du prix annuel, pour que la comparaison soit immédiate ;
• indique l'économie réelle par rapport au mensuel, calculée sur tes vrais prix, jamais sur un prix de référence inventé.

Attention à ne pas tomber dans l'excès inverse : le prix réellement facturé doit rester le plus visible. Apple demande que le prix de renouvellement complet soit affiché de façon claire et visible. Un équivalent mensuel en gros et le vrai prix annuel en tout petit, c'est un paywall trompeur, et c'est un motif de refus.

Erreur n°4 : oublier le bouton de restauration d'achat

C'est l'oubli le plus bête et l'un des plus fréquents. Un abonné change d'iPhone, réinstalle l'app, et se retrouve devant le paywall alors qu'il paie déjà. Sans bouton « Restaurer mes achats », il n'a aucun moyen de récupérer son accès.

Ce n'est pas une option. Les règles de revue de l'App Store (règle 3.1.1) demandent un mécanisme de restauration pour tout achat intégré restaurable, et la page d'Apple sur les abonnements liste parmi les éléments de l'écran d'inscription « un moyen pour les abonnés actuels de se connecter ou de restaurer leurs achats ».

Avec RevenueCat, la restauration tient en un appel. Le vrai travail, c'est de vérifier ce qui se passe ensuite :

• l'abonné retrouve bien son accès, sans avoir à relancer l'app ;
• un utilisateur sans achat reçoit un message clair, pas une erreur technique ;
• le bouton est visible sur le paywall lui-même, pas seulement dans les réglages.

Erreur n°5 : oublier les mentions qu'Apple exige

Un paywall qui ne dit pas clairement ce que l'utilisateur va payer peut être refusé. Apple détaille sur sa page consacrée aux abonnements ce qui doit figurer sur l'écran d'inscription :

• le nom et la durée de l'abonnement, et ce qu'il donne pendant cette période ;
• le prix de renouvellement complet, affiché clairement et localisé dans les devises disponibles ;
• un moyen de restaurer ses achats (voir l'erreur précédente).

Ajoute une phrase explicite sur le renouvellement automatique : l'abonnement se renouvelle tant que l'utilisateur ne le résilie pas, et il peut le résilier dans les réglages de son compte Apple.

La même page précise aussi que l'app et ses métadonnées App Store doivent contenir des liens vers les conditions d'utilisation et la politique de confidentialité. C'est un point que beaucoup découvrent au moment du refus : il ne suffit pas de mettre ces liens dans l'app, il faut aussi un rappel des conditions de l'abonnement et ces deux liens dans la description de la fiche App Store. Sans eux, c'est un refus au titre de la règle 3.1.2. Sur mes apps à abonnement, je termine la description par un court bloc : conditions de l'abonnement, puis lien vers les conditions d'utilisation et lien vers la politique de confidentialité. Et si ta fiche est traduite, ce bloc doit exister dans chaque langue.

Avant de coller tes liens, ouvre-les dans un navigateur. Un lien vers une page qui n'existe pas vaut un lien absent.

J'ai détaillé les autres motifs de refus qui reviennent souvent dans cet article sur les refus d'Apple, et la fiche App Store elle-même a sa page : optimiser sa fiche sur l'App Store.

Erreur n°6 : ne pas tester le paywall en bac à sable

Un paywall qui s'affiche bien sur le simulateur n'est pas un paywall qui fonctionne. Entre la configuration des produits dans App Store Connect, les offres dans RevenueCat et le code de l'app, il y a beaucoup d'endroits où un détail peut casser : un produit mal rattaché, un prix qui ne se charge pas, un essai qui ne s'affiche pas.

Apple fournit pour ça un environnement de test, le bac à sable (sandbox), avec des comptes Apple de test que tu crées dans App Store Connect, dans « Utilisateurs et accès », onglet Sandbox. Ces comptes servent à tester les achats sans être débité, y compris les renouvellements, les échecs de paiement et les remboursements, comme l'explique la documentation d'App Store Connect.

Avant chaque envoi, déroule au minimum ce parcours sur un vrai iPhone :

1. premier lancement, onboarding complet, arrivée sur le paywall ;
2. démarrage de l'essai avec un compte de test ;
3. vérification que l'accès premium s'ouvre bien ;
4. suppression de l'app, réinstallation, restauration de l'achat ;
5. affichage correct du paywall sur le plus petit et le plus grand iPhone que tu supportes.

Le reviewer d'Apple testera lui aussi l'achat. S'il bloque, c'est un refus.

Erreur n°7 : ne rien mesurer

C'est l'erreur qui empêche de corriger toutes les autres. Sans mesure, tu ne sais pas où les utilisateurs décrochent. Tu vois seulement le résultat final : peu d'abonnés. Tu ne sais pas si le problème est l'onboarding, le paywall, le prix ou l'essai.

C'est exactement ce qui m'a permis de voir le problème sur mes propres apps : les installations étaient là, les essais démarrés non. Sans ces deux chiffres côte à côte, j'aurais pu passer des semaines à retravailler autre chose.

Pose des événements d'analytics à chaque étape clé, par exemple avec PostHog :

• début de l'onboarding ;
• fin de l'onboarding ;
• affichage du paywall ;
• essai démarré ;
• achat ou abonnement confirmé ;
• restauration réussie.

Avec ces événements, tu obtiens un entonnoir. Tu vois l'étape où les utilisateurs partent, et tu sais quoi retravailler en priorité. RevenueCat complète la vue côté revenus : essais, conversions, renouvellements, résiliations.

Un dernier conseil : ne change pas tout en même temps. Si tu modifies le prix, l'essai et le design du paywall le même jour, tu ne sauras jamais ce qui a fait bouger les chiffres.

La checklist paywall avant ton prochain envoi

• Le paywall arrive à la fin de l'onboarding, après une preuve de valeur.
• L'essai gratuit est affiché en clair : durée, puis prix après l'essai.
• L'annuel est mis en avant honnêtement, le prix réellement facturé reste lisible.
• Le bouton « Restaurer mes achats » est sur le paywall et fonctionne.
• Nom, durée, prix de renouvellement et renouvellement automatique sont indiqués.
• Les liens vers les conditions d'utilisation et la politique de confidentialité sont dans l'app et dans la description App Store, dans chaque langue.
• Le parcours d'achat complet a été testé en bac à sable sur un vrai iPhone.
• Les événements d'analytics couvrent chaque étape, de l'onboarding à l'achat.

Si tu hésites encore sur le modèle lui-même, abonnement ou paiement unique, j'ai écrit un guide dédié : abonnement ou achat unique pour ta première app iOS. Et pour la partie technique complète, produits, RevenueCat et validation, tout est sur la page abonnements in-app iOS.

Construire ton paywall avec un accompagnement

Le paywall n'est qu'une pièce. Il dépend de l'onboarding qui le précède, du prix que tu fixes, de la fiche App Store qui amène les utilisateurs, et de la fonction principale de l'app, celle qu'il faut garder simple dans une première version bien cadrée.

Si tu veux construire tout ça avec quelqu'un qui l'a fait sur ses propres apps, c'est le sujet de L'Accélérateur iOS : 4 semaines, 3 lives par semaine en groupe de 10 places au plus, avec l'accès à vie au groupe privé Discord, aux replays et aux modèles, et ton dossier App Store relu avant l'envoi. La troisième semaine est consacrée à brancher l'argent : onboarding, paywall, abonnements RevenueCat et mesures PostHog. La prochaine session commence le lundi 12 octobre 2026, pour 489 €, ou 3 × 163 € sans frais avec Klarna. Personne ne peut te garantir un revenu, mais tu repartiras avec un paywall conforme, testé et mesuré.