Depuis quinze ans, un abonnement dans une app veut dire une chose : une personne, un compte Apple ou Google, un prélèvement par mois, et une boîte de support remplie de « est-ce que ma collègue peut utiliser mon identifiant ? ». À deux semaines d'intervalle, les deux stores ont annoncé que ce modèle allait avoir de la compagnie. Apple a publié Get your subscriptions ready for iOS 27 le 16 septembre, et Google a répondu le 29 septembre avec The next era of subscriptions. Lus côte à côte, ils racontent la même histoire : votre abonnement peut désormais être acheté par une équipe, par une entreprise entière, ou dans un lot avec d'autres apps, dont certaines ne sont même pas les vôtres.
Des places, ou comment votre collègue obtient enfin un accès légal
Côté Apple, l'achat multiplaces existe en deux versions. Avec Volume Purchasing, une entreprise ou une école qui utilise Apple Business ou Apple School Manager achète un lot de places d'un coup et les distribue avec son outil de gestion des appareils, un peu comme elle le fait déjà avec les apps ; ça démarre le 22 octobre. Avec Group Purchases, un abonné ordinaire achète plusieurs places dans votre app et invite les autres, et Apple s'occupe de l'invitation et de l'attribution des places, ce qui vous évite de monter un petit service RH dans votre écran de réglages. Celui-là arrive « cet hiver », ce qui dans le calendrier d'Apple peut vouloir dire n'importe quoi entre décembre et les premières jonquilles.
Le détail qui mérite un café : le multiplaces est activé par défaut. Les abonnements créés avant le 14 septembre qui n'utilisent pas StoreKit 2, ou qui ont le Partage familial activé, partent désactivés, mais tout le reste est déjà vendable en gros, sauf si vous le changez dans App Store Connect. Dans la session WWDC26 sur les groupes, Apple montre aussi des tarifs dégressifs, jusqu'à cinq paliers avec une place moins chère pour les grosses commandes, le genre de décision que votre responsable financier voudra prendre plutôt que découvrir.
Google prend la même direction avec les abonnements multiquantité, visant clairement les apps de productivité, d'éducation et d'IA qui vendent à des équipes et à des classes. La différence, c'est le calendrier : dans l'article de Google, celui-ci, comme la plupart de la liste, est encore en test avec des partenaires choisis via un programme d'accès anticipé, donc pour l'instant c'est quelque chose à prévoir plutôt qu'à activer.
Le schéma montre le même abonnement vendu de quatre façons. D'abord, une personne l'achète pour elle-même, comme aujourd'hui. Ensuite, un abonné achète cinq places et invite son équipe. Puis une entreprise achète des places en gros et son service informatique les attribue aux appareils. Enfin, un seul achat débloque plusieurs apps à la fois, en bundle ou en suite.
Les bundles, et les amis que vous ne connaissiez pas
La deuxième idée, c'est de vendre plusieurs choses comme une seule. Chez Apple, les Bundles et Suites permettent à un Bundle de regrouper jusqu'à cinq abonnements, de vos propres apps ou de cinq éditeurs différents au maximum qui signent un avenant commun, tandis qu'une Suite est un seul abonnement qui ouvre jusqu'à quinze de vos apps. Ils arrivent plus tard cette année avec iOS 27, l'accès se demande par formulaire, et tous les abonnements d'un Bundle doivent avoir la même durée (mensuel avec mensuel, annuel avec annuel). Google annonce la même idée sous le nom de cross-developer bundling, plus des paniers mixtes qui vendent un abonnement et un achat unique en un seul paiement, tous deux encore en test. Donc si une app de méditation et une app de course à pied voulaient un jour se marier, les stores impriment déjà les faire-part.
Ce qui marche déjà sur Android
Un élément de l'article de Google est disponible dès maintenant pour tous les développeurs : l'API de messages in-app. Quand un paiement échoue ou qu'une hausse de prix attend l'accord de l'utilisateur, Google Play affiche un court message dans votre app avec un bouton pour régler le problème, au lieu de laisser l'abonnement filer en silence. Google recommande de l'appeler à chaque ouverture de l'app, et ça tient en une dizaine de lignes :
val params = InAppMessageParams.newBuilder()
.addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
.build()
billingClient.showInAppMessages(activity, params) { result ->
if (result.responseCode == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
// Payment fixed or price increase accepted: refresh the status on your server
refreshSubscription(result.purchaseToken)
}
}
Dix lignes pour garder des abonnés dont la carte a simplement expiré : comme retour sur investissement, difficile de faire mieux.
Pourquoi on vous parle sans cesse de StoreKit 2
Toutes les nouvelles options d'Apple exigent StoreKit 2, et il y a une raison sournoise pour laquelle votre code n'est peut-être pas prêt, même s'il l'utilise. La collègue qui accepte une invitation de groupe, ou l'employé dont le téléphone reçoit une place de son service informatique, n'a jamais touché « S'abonner » dans votre app. Si votre app débloque le premium en enregistrant un drapeau juste après un achat, ces personnes verront votre écran de paiement, et le regarderont fixement alors que leur entreprise a déjà payé. La bonne habitude, c'est de demander à StoreKit à quoi l'utilisateur a droit, à chaque lancement :
import StoreKit
/// The active subscription among the given products, however it reached this user:
/// bought here, a seat from a group or a company, or another device.
func activeSubscription(among productIDs: Set<String>) async -> String? {
for await result in Transaction.currentEntitlements {
guard case .verified(let transaction) = result,
productIDs.contains(transaction.productID),
transaction.revocationDate == nil else { continue }
return transaction.productID
}
return nil
}
Si votre app tourne encore sur l'ancienne API StoreKit, cet automne est une bonne excuse pour migrer, parce que c'est le ticket d'entrée pour tout ce qui précède.
Concrètement, je ferais quoi ?
Cette semaine, j'ouvrirais App Store Connect pour décider, abonnement par abonnement, si la vente en gros a du sens, plutôt que de laisser le réglage par défaut décider à ma place. Sur Android, j'ajouterais l'appel aux messages in-app, puisqu'il est disponible et ne coûte presque rien. Ensuite, je vérifierais que l'accès vient des droits (les entitlements) et non d'un écran d'achat, je testerais avec un second compte, et je noterais le 22 octobre dans l'agenda. Les bundles peuvent attendre le bon partenaire, mais la paperasse prend du temps, donc une première discussion vaut le coup si un candidat évident vous vient en tête. Et si vous pensez aussi vendre des fonctions d'IA à des équipes, la question des places arrivera plus vite que prévu.
Si vous voulez de l'aide
Le code de facturation, c'est le genre de code qu'on préfère toucher une seule fois, avec soin. Garder une app en règle avec ce que demandent les stores, c'est l'objet de la page mise à jour et conformité stores, et si vous préférez d'abord savoir où en est votre code StoreKit et Play Billing, l'audit d'application mobile regarde exactement ça.
Sources : Apple Developer News, 16 septembre 2026, Bundles and Suites, Manage purchase options for an auto-renewable subscription, Offer subscriptions to groups and organizations (WWDC26), Android Developers Blog, 29 septembre 2026, About subscriptions, Google Play Billing.