In-App Purchase — ce que c'est, types d'achats et fonctionnement de la monétisation

Qu'est-ce que l'In-App Purchase ?

L'In-App Purchase (IAP) est une technologie permettant de vendre des biens et services numériques au sein d'une application mobile. Les paiements sont traités via l'App Store (sur iOS) ou Google Play (sur Android), qui prélèvent une commission pour le traitement de la transaction. Le développeur reçoit les fonds moins la commission de la boutique.

Apple prélève une commission de 30 % (15 % pour les petites entreprises dont le revenu est inférieur à 1 million de dollars). Google Play prélève également 30 % (15 % sur le premier million de dollars de revenu du développeur). Depuis 2024, Google teste le programme User Choice Billing, qui permet aux développeurs d'utiliser des systèmes de paiement alternatifs.

L'IAP est obligatoire pour la vente de biens numériques dans les applications selon les politiques de l'App Store et de Google Play. Les biens physiques, les services (VTC, livraison de repas) et les paiements peer-to-peer peuvent utiliser des systèmes de paiement tiers.

Types d'In-App Purchase : consumable, non-consumable et abonnement

L'App Store et Google Play prennent en charge trois principaux types d'In-App Purchase. Chaque type est conçu pour différents modèles de monétisation. Le choix du type de produit affecte la logique de restauration des achats, la gestion des abonnements et le comportement lors de la réinstallation de l'application.

Consumable (achats consommables)

Les achats consommables sont des articles qui peuvent être achetés plusieurs fois et qui sont consommés lors de l'utilisation. Exemples typiques : monnaie de jeu (pièces, gemmes), vies supplémentaires, boosters, power-ups consommables. Les consommables ne sont pas restaurés lors de la réinstallation de l'application — le développeur gère le solde de chaque utilisateur sur son propre serveur.

Non-Consumable (achats non consommables)

Les achats non consommables sont des articles achetés une fois et qui restent disponibles pour toujours. Exemples : version complète de l'application, niveaux premium, déverrouillage de filtres, suppression de publicités. Les produits non consommables peuvent être restaurés via l'API Restore Purchases : après réinstallation, l'utilisateur peut récupérer les articles précédemment achetés sans payer à nouveau.

Auto-Renewable Subscription (abonnement à renouvellement automatique)

L'abonnement à renouvellement automatique implique des paiements récurrents pour l'accès à du contenu ou un service pendant une période déterminée (semaine, mois, an). L'abonnement se renouvelle automatiquement jusqu'à ce que l'utilisateur l'annule dans les paramètres de son compte. Les boutiques fournissent des notifications serveur (App Store Server Notifications, Google Play Developer Notifications) sur les changements de statut de l'abonnement : renouvellement, expiration, remboursement.

Configuration d'IAP dans App Store Connect et Google Play Console

La configuration de l'In-App Purchase commence dans les panneaux développeur : App Store Connect pour iOS et Google Play Console pour Android. Pour chaque produit, on spécifie un ID de produit (Product ID), un nom, une description, un type et un prix en dollars américains avec conversion automatique dans les devises régionales. Après création, le produit passe par la modération de la boutique.

Dans App Store Connect, les produits IAP sont créés dans la section Features → In-App Purchases. Pour chaque produit, on sélectionne un type (consumable, non-consumable, auto-renewable subscription, non-renewing subscription) et on remplit les noms localisés. Pour les abonnements, des Groupes d'abonnement (Subscription Groups) sont configurés en supplément — des groupes d'abonnements interchangeables.

Dans Google Play Console, les produits gérés sont configurés dans la section Monetise → Products → In-app products. Google utilise les termes Managed Product (analogue à non-consumable) et Subscription. Pour les achats consommables sur Android, un indicateur consume distinct est utilisé, qui réinitialise le produit pour un rachat.

La modération des produits IAP prend généralement 24 à 48 heures dans l'App Store et quelques heures dans Google Play. Les changements de prix sont appliqués immédiatement sans nouvelle modération. Les ID de produit ne peuvent pas être modifiés après création — seulement supprimés et recréés.

Validation des reçus côté serveur et protection contre la fraude

La validation des reçus est une étape obligatoire dans le traitement de l'In-App Purchase. L'application cliente envoie un reçu à votre propre serveur, le serveur le vérifie via l'API d'Apple (https://buy.itunes.apple.com) ou de Google (https://androidpublisher.googleapis.com), et ce n'est qu'après une validation réussie que l'article est attribué à l'utilisateur.

Sans validation côté serveur, un attaquant pourrait falsifier la réponse de la boutique et obtenir l'article gratuitement. La validation côté client n'est pas sûre car elle s'exécute dans un environnement contrôlé par l'utilisateur. La validation côté serveur garantit que le reçu est authentique et que le paiement a réussi. Pour Apple, la vérification s'effectue via le point d'accès verifyReceipt (production ou sandbox), pour Google — via l'Android Publisher API. Les deux boutiques renvoient une confirmation au format JSON.

Apple renvoie dans le reçu les données d'achat : product_id, transaction_id, purchase_date, expiration_date (pour les abonnements). Google renvoie des champs similaires via les API Purchases.products.get ou Purchases.subscriptions.get. Le serveur doit stocker le transaction_id de chaque reçu et rejeter les demandes en double avec le même ID pour se protéger contre les attaques par rejeu.

Intégration d'IAP dans une application mobile avec Swift et Kotlin

L'intégration de l'In-App Purchase nécessite la connexion des bibliothèques de plateforme : StoreKit 2 sur iOS et Billing Library 7+ sur Android. Les API permettent de demander une liste de produits, d'initier un achat, de traiter le résultat et de restaurer les articles précédemment achetés.

Swift — StoreKit 2 sur iOS 17+

import StoreKit

func purchaseProduct(productID: String) async throws {
    guard let product = try await Product.products(for: [productID]).first else { return }
    let result = try await product.purchase()
    switch result {
    case .success(let verification):
        let transaction = try verification.payloadValue
        await validateReceipt(transaction)
        await transaction.finish()
    default:
        break
    }
}

Kotlin — Billing Library 7

import com.android.billingclient.api.BillingClient
import com.android.billingclient.api.BillingFlowParams

val billingClient = BillingClient.newBuilder(context)
    .setListener { billingResult, purchases ->
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
            purchases?.forEach { purchase ->
                validateReceipt(purchase)
            }
        }
    }
    .build()

val params = BillingFlowParams.newBuilder()
    .setProductDetails(productDetails)
    .build()
billingClient.launchBillingFlow(activity, params)

Validation des reçus côté serveur (Node.js)

const response = await fetch('https://buy.itunes.apple.com/verifyReceipt', {
    method: 'POST',
    body: JSON.stringify({
        'receipt-data': receiptBase64,
        'password': 'SHARED_SECRET'
    })
})

const data = await response.json()
if (data.status === 0) {
    // Reçu confirmé — octroi de l'article
    await grantProduct(data.receipt.product_id)
}

Meilleures pratiques de monétisation via l'In-App Purchase

La monétisation via l'In-App Purchase nécessite une stratégie de prix et une UX bien pensées. Les utilisateurs sont plus enclins à effectuer leur premier achat si on leur propose un pack de démarrage attrayant à bas prix. Apple et Google recommandent d'afficher le prix du produit avant l'étape de confirmation d'achat.

L'onboarding d'abonnement est une étape critique de conversion. Montrez à l'utilisateur la valeur de l'abonnement avant de demander le paiement : une période d'essai gratuite, une comparaison des forfaits, une liste des avantages. Selon les études, une période d'essai gratuite augmente la conversion en utilisateurs payants de 25 à 40 %.

Restore Purchases est obligatoire pour les produits non consommables et les abonnements. Le bouton de restauration doit être accessible dans les paramètres de l'application ou sur l'écran de paiement. Google et Apple peuvent rejeter l'application si la restauration des achats n'est pas implémentée pour les types d'IAP concernés.

Le délai de grâce (Grace Period) est une période de report pour les abonnements pendant laquelle l'utilisateur conserve l'accès après un échec de paiement. iOS et Android prennent en charge un délai de grâce allant jusqu'à 30 jours. L'activation du délai de grâce réduit le taux d'attrition (churn rate) de 10 à 15 %.

Les tests A/B des prix IAP sont une pratique importante de monétisation. App Store Connect prend en charge les prix locaux (Price Tiers) avec la possibilité de modifier le prix sans nouvelle modération. Google Play Console permet de configurer jusqu'à 5 plans de base avec des prix différents pour un même produit d'abonnement. Il est recommandé de tester au moins deux points de prix : le prix actuel et le nouveau. Le test doit être mené sur 2 à 4 semaines sur un échantillon d'au moins 1 000 utilisateurs par point de prix.

La révision de la boutique et la gestion des rejets est une étape obligatoire de publication d'une application avec IAP. Apple examine particulièrement les applications avec abonnements à renouvellement automatique : vous devez fournir un compte de test avec un abonnement actif, afficher l'écran d'annulation d'abonnement et implémenter Restore Purchases. Google Play est moins strict mais exige une confirmation des droits sur le contenu numérique. Il est recommandé d'ajouter une note pour le relecteur (Review Notes) décrivant la logique IAP.