📱 Vendre dans les magasins d'applications

Qui vend quoi, et ce qui déclenche l'achat intégré

L'achat intégré désigne le mécanisme d'encaissement exploité par le magasin d'applications lui-même, que celui-ci impose pour une partie seulement de ce qu'une application vend. La ligne de partage tient à la nature de ce que le client reçoit, et au lieu où il le consomme. Elle ne dépend ni du montant, ni du pays, ni du modèle économique. Un contenu numérique livré dans l'application relève de l'achat intégré. Un bien physique ou un service rendu hors de l'application relève des moyens de paiement ordinaires, et les deux magasins interdisent dans ce cas d'employer leur propre système. La règle joue donc dans les deux sens. Elle impose l'encaissement du magasin d'un côté de la frontière, et elle l'exclut de l'autre.

Apple écrit cette partition aux points 3.1.1 et 3.1.3(e) de ses App Store Review Guidelines. Ces points réservent l'achat intégré aux biens et services numériques, et exigent un autre moyen de paiement dès que le bien ou le service est consommé hors de l'application. Google Play énonce la même règle dans sa politique de paiements, où Google Play Billing s'impose pour les achats de contenus et de fonctionnalités numériques et se trouve exclu pour les biens physiques. Les deux textes sont publics, versionnés, et modifiés plusieurs fois par an. Une lecture datant de 2022 ne correspond donc plus au texte en vigueur. La vérification porte sur la version publiée au moment où l'architecture d'encaissement est arrêtée.

Trois régimes intermédiaires déplacent cette frontière sans la supprimer. Les reader apps du point 3.1.3(a) couvrent la presse, les livres, l'audio, la musique et la vidéo, et peuvent donner accès à un contenu acheté ailleurs sans jamais le vendre dans l'application. Les services multiplateformes du point 3.1.3(b) autorisent la consommation, sur iOS, d'un contenu acquis sur un autre support. Les applications gratuites autonomes du point 3.1.3(f) sont le compagnon gratuit d'un outil web payant souscrit ailleurs, à la condition qu'aucun achat ni appel à l'achat n'y figure. Aucun de ces trois régimes n'ouvre la vente à l'utilisateur dans l'application. Chacun autorise l'usage, dans l'application, de ce qui a été payé ailleurs, et cette tolérance est régulièrement lue comme une autorisation d'y vendre.

Le régime des reader apps procède d'un engagement pris devant une autorité nationale de concurrence, plutôt que d'une décision commerciale d'Apple. La Japan Fair Trade Commission a clos une enquête sur l'App Store en septembre 2021. Apple s'était engagée à autoriser ces applications à inclure un lien vers un site externe de création et de gestion de compte. L'engagement a été appliqué mondialement à partir de 2022, sous la forme de l'External Link Account Entitlement. Une règle négociée avec le régulateur japonais s'applique donc aux développeurs de tous les pays.

La commission et ses paliers

La commission du magasin désigne la part du prix de vente que le magasin conserve sur chaque achat intégré. Son taux de référence s'élève à 30 % chez Apple comme chez Google, et presque aucun développeur ne le supporte au plein tarif sur toute la durée. Quatre mécanismes le ramènent à 15 %, parfois plus bas, selon la taille du développeur, l'ancienneté de l'abonné, le secteur d'activité et le territoire de distribution. Ces mécanismes ne se cumulent pas librement, et chacun porte ses propres conditions d'entrée et de sortie. Un modèle de revenus qui retient un taux unique s'écarte de plusieurs points du taux réellement appliqué.

L'écart le plus lourd de conséquences porte sur la première année d'abonnement. Google applique 15 % dès le premier prélèvement depuis le 1er janvier 2022, quand Apple maintient 30 % pendant douze mois de service payé avant de basculer à 15 %. Beaucoup d'abonnements mensuels s'interrompent avant d'atteindre douze mois. Sur ces produits, la totalité du chiffre d'affaires iOS supporte le taux plein, alors que le même produit vendu sur Android supporte le taux réduit. Le compte d'exploitation d'une même application diffère donc de quinze points entre les deux systèmes, à prix affiché identique.

Le programme petites entreprises d'Apple s'obtient sur inscription du développeur, et ne s'applique pas automatiquement au compte éligible. L'éligibilité se calcule sur les revenus nets de l'année civile précédente, et le franchissement du million en cours d'année fait basculer au taux plein pour le reste de l'exercice. Le seuil s'apprécie au niveau du développeur, toutes applications confondues, et les comptes associés d'un même groupe s'agrègent. Un éditeur qui répartit son catalogue entre plusieurs entités pour rester sous le seuil s'expose à un redressement contractuel et à la perte du programme.

Les conditions alternatives publiées par Apple pour l'Union européenne en janvier 2024 ont introduit une structure de coût entièrement différente. Elles s'appliquent aux applications distribuées dans l'Union depuis le 6 mars 2024. Le développeur qui les accepte paie une commission de 17 %, ramenée à 10 % s'il relève du programme petites entreprises. S'y ajoutent 3 % lorsqu'il continue d'utiliser le système de paiement de l'App Store, puis un frais de technologie de 0,50 € par première installation annuelle au-delà d'un million sur douze mois. Apple a ajouté des exonérations en mai 2024 pour les petits développeurs et les organismes sans but lucratif. Elle a révisé l'ensemble en 2025, en introduisant des frais d'acquisition initiale et des frais de services de magasin à plusieurs niveaux. Elle a ensuite annoncé le remplacement du frais par installation par une commission assise sur les revenus au 1er janvier 2026. Le barème a changé plusieurs fois depuis 2024. Un tableau recopié à une date donnée cesse donc de décrire les conditions applicables, et la valeur en vigueur figure sur la page que publie Apple.

Le magasin comme marchand de référence

Le marchand de référence est la partie qui vend juridiquement au client final, émet le reçu et supporte les obligations attachées à cette vente. Dans un achat intégré, ce rôle revient au magasin, qui achète le contenu au développeur puis le revend à l'utilisateur final en son nom propre. Cette qualification découle d'une règle fiscale écrite, dont la portée dépasse largement le sujet de la TVA. Elle détermine qui émet la facture, qui décide d'un remboursement, qui répond au client, et qui détient les données de la relation. Le développeur n'exerce aucune de ces quatre fonctions.

La conséquence pratique se lit sur la facture. Le client reçoit un reçu émis par l'entité du magasin, avec la TVA du pays de consommation, et le nom du développeur n'y figure qu'à titre descriptif. Le développeur, lui, réalise une prestation au profit de cette entité, généralement établie hors de son propre pays. Pour les clients de l'Union, Apple contracte par Apple Distribution International Ltd, société irlandaise, si bien que la prestation du développeur européen relève du régime des opérations entre assujettis, avec autoliquidation par le preneur. Un développeur français ne facture donc pas de TVA française sur ses revenus App Store européens. Le consommateur français en a pourtant acquitté une sur son achat, collectée et reversée par le magasin.

Le remboursement d'un achat intégré est décidé par le magasin, sans accord préalable du développeur. Sur l'App Store, le client dépose sa demande auprès d'Apple, qui l'instruit et la tranche seule, puis répercute le montant sur les revenus du développeur du mois concerné. Apple a organisé un canal d'information autour de cette décision. Le développeur reçoit une notification de type CONSUMPTION_REQUEST, à laquelle il dispose de douze heures pour répondre en transmettant des données de consommation. Une notification de type REFUND ou REFUND_DECLINED suit, selon l'issue. Ces données pèsent sur la décision sans la déterminer, et l'absence de réponse dans le délai laisse Apple statuer sur les seuls éléments dont elle dispose, ce qui ne joue pas en faveur du développeur.

Google Play organise la même chose différemment. Une demande déposée dans les quarante-huit heures suivant l'achat est instruite par Google, sans intervention du développeur, alors qu'au-delà de ce délai l'utilisateur est renvoyé vers l'éditeur, qui peut rembourser depuis la Play Console. Le développeur détecte les annulations par l'API des achats annulés, qui restitue les achats devenus caducs et distingue l'origine de l'annulation. Un remboursement et une rétrofacturation produisent le même effet sur le solde reversé, alors qu'ils n'ont ni la même signification commerciale ni le même traitement comptable. L'usage consiste donc à les séparer dès l'ingestion des données, à partir de l'origine d'annulation que restitue cette API.

L'absence de données client se répercute sur toute la chaîne aval. Le développeur ne reçoit ni nom, ni adresse électronique, ni adresse de facturation, ni pays de résidence certifié. Les deux magasins offrent un seul point d'accroche technique, sous la forme d'un identifiant opaque que le développeur transmet lui-même au moment de l'achat, appelé appAccountToken chez Apple et obfuscatedExternalAccountId chez Google. Ce champ, renseigné à chaque transaction, est le seul moyen de relier plus tard un achat à un compte applicatif. Les achats passés sans lui ne peuvent plus être rattachés à un compte par la suite.

L'abonnement piloté par le magasin

L'abonnement vendu par achat intégré est un contrat récurrent dont le magasin assure la facturation, le renouvellement et l'extinction. Cette prise en charge retire au marchand les leviers qui composent l'exploitation d'un modèle récurrent. La date de renouvellement, la relance après échec, la période de grâce, la suspension, le changement de formule, la hausse de prix et la résiliation sont tous décidés par la plateforme. Le développeur apprend ce qui s'est passé par une notification serveur, souvent après coup. Son système de facturation enregistre des événements décidés ailleurs, alors qu'un système d'encaissement direct les déclenche lui-même.

Le renouvellement suit un cycle que le magasin fixe seul. Quand le prélèvement échoue, Apple relance pendant une fenêtre qu'elle documente jusqu'à soixante jours. L'échec est signalé au développeur par une notification DID_FAIL_TO_RENEW, assortie le cas échéant du sous-type GRACE_PERIOD qui indique que l'accès reste ouvert. Google Play distingue de son côté une période de grâce, configurable, et une suspension de compte dont il calcule désormais la durée par défaut en retranchant cette période de grâce d'une enveloppe de récupération de soixante jours. Pendant cette suspension, l'abonnement existe sans donner accès au service, et la reprise après régularisation se traduit par une notification SUBSCRIPTION_RECOVERED. Le développeur doit donc reproduire ces états dans son propre système, alors qu'aucun d'entre eux ne dépend de lui.

Les techniques de recouvrement d'une échéance échouée disparaissent avec le mandat, que le développeur ne détient pas. Il ne rejoue pas l'autorisation, ne choisit pas l'heure de la nouvelle tentative, ne propose pas un autre moyen de paiement et n'envoie pas de lien de mise à jour de carte. Toute la chaîne de relance décrite pour un abonnement encaissé en propre s'exécute chez le magasin, avec ses règles et ses résultats, que le développeur ne mesure pas. Il lui reste la communication dans l'application, pour inviter l'abonné suspendu à corriger son moyen de paiement dans les réglages du système. Le taux de récupération est donc produit par la relance du magasin, et cette communication ne le déplace qu'à la marge.

L'authentification forte du porteur relève elle aussi du magasin. Pour un paiement européen, la contrepartie du porteur est le magasin, qui porte la relation d'acceptation et gère l'exemption applicable aux opérations initiées par le marchand. Le développeur ne voit jamais un défi 3-D Secure, ne paramètre aucun seuil, et ne peut pas invoquer une exemption de faible montant sur une transaction qui n'est pas la sienne. Le taux d'autorisation devient un attribut de la plateforme, comparable d'un développeur à l'autre parce qu'il est produit par le même acteur. Cette uniformité prive le développeur d'un levier d'optimisation dont il dispose lorsqu'il encaisse en propre.

Les leviers commerciaux qui subsistent se limitent à ceux que le magasin a modélisés. Apple et Google proposent des offres d'introduction, des codes promotionnels, des offres de reconquête destinées aux anciens abonnés, et des grilles de prix par territoire. Ces objets s'administrent dans la console du magasin, avec leurs contraintes d'éligibilité, leurs durées autorisées et leurs délais de propagation. Une mécanique tarifaire absente du catalogue ne s'implémente pas, et un test de prix conçu pour une facturation propre se réécrit entièrement avant d'exister dans un magasin.

Sortir du système du magasin

La sortie du système du magasin désigne les dispositifs par lesquels un développeur oriente son client vers un paiement réalisé hors de l'application. Deux mouvements distincts ont ouvert des brèches dans l'obligation d'achat intégré, l'un réglementaire et européen, l'autre judiciaire et américain. Ils ne produisent ni les mêmes droits, ni les mêmes coûts, ni la même géographie. Les confondre conduit à concevoir un parcours de sortie licite sur un marché et interdit sur l'autre. Ces deux mouvements attaquent la même règle, celle qui empêchait un développeur de dire à son client qu'un autre prix existe hors de l'application.

Le règlement (UE) 2022/1925 attaque l'obligation d'achat intégré par trois articles distincts. L'article 5, paragraphe 4, autorise l'entreprise utilisatrice à communiquer et promouvoir ses offres auprès des utilisateurs acquis via le service de plateforme, et à conclure des contrats avec eux, gratuitement, sans passer par le contrôleur d'accès. L'article 5, paragraphe 7, interdit au contrôleur d'accès d'imposer l'usage de son service de paiement, y compris les systèmes de paiement pour achats intégrés. L'article 6, paragraphe 4, impose de permettre l'installation et l'usage effectif d'applications et de magasins d'applications tiers. Ces trois obligations sont directement applicables dans l'Union, sans transposition.

L'ordonnance américaine du 30 avril 2025 est allée plus loin que le DMA sur un point, celui du prix de la sortie. Elle interdisait à Apple de percevoir une commission sur les achats réalisés hors application à la suite d'un lien, et d'entourer ce lien d'écrans dissuasifs, de restrictions de formulation ou de contraintes de placement. La cour d'appel du neuvième circuit a confirmé la condamnation pour contournement le 11 décembre 2025, tout en jugeant trop large l'interdiction de toute commission. Elle a renvoyé au juge de première instance le soin de fixer ce qu'Apple peut facturer sur ces transactions. Le canal américain reste donc sans redevance tant que ce montant n'est pas arrêté, sans garantie qu'il le demeure ensuite. La portée géographique de la décision est en revanche fixée. L'injonction a été rendue en application du droit californien de la concurrence déloyale, et ne produit d'effet qu'aux États-Unis.

D'autres juridictions avancent sur des fondements différents. La Corée du Sud a modifié en septembre 2021 sa loi sur les entreprises de télécommunications, pour interdire aux exploitants de magasins d'applications d'imposer un moyen de paiement déterminé. Le Japon a adopté en juin 2024 une loi sur la promotion de la concurrence pour les logiciels de téléphone mobile. Ses obligations d'ouverture s'appliquent depuis décembre 2025, sous le contrôle de la Japan Fair Trade Commission. Au Royaume-Uni, la Competition and Markets Authority avait établi dès son étude de marché de juin 2022 l'existence d'un duopole effectif. Elle a désigné Apple et Google en 2025 comme détenant un statut de marché stratégique, au titre de la loi de 2024 sur les marchés numériques. Le calendrier des mesures correctrices britanniques s'écrit après cette désignation.

Le reversement, et ce qui manque pour le réconcilier

Le reversement désigne le virement par lequel le magasin règle au développeur sa part des ventes d'une période. Il porte sur un agrégat de transactions, et jamais sur une vente prise isolément. Chaque magasin totalise les ventes de la période, en déduit sa commission, les remboursements, les taxes qu'il a collectées et les retenues qu'il opère. Un virement unique suit, par entité juridique et par groupe de devises. Aucune ligne de ce virement ne porte de référence d'achat. La chaîne comptable qui relie une vente à un encaissement bancaire, évidente dans l'acquisition carte classique, est donc rompue par construction.

Les retenues fiscales par pays constituent la deuxième source d'écart. Les magasins collectent et reversent la TVA ou la taxe sur les ventes dans les territoires où ils agissent comme vendeur. Ils répercutent sur le développeur les taxes sur les services numériques instaurées par plusieurs États, soit en ajustant le prix affiché, soit en réduisant le montant reversé. Certains territoires imposent en plus une retenue à la source, opérée par le magasin avant versement, dont l'exonération ou la réduction conventionnelle suppose la production préalable d'un formulaire fiscal dans le compte de paiement. Un développeur qui n'a pas renseigné ces informations découvre la retenue sur le premier virement, sans la récupérer rétroactivement.

Dans les territoires où le magasin collecte lui-même la taxe, celle-ci est retirée du prix payé avant le calcul de la commission. L'assiette retenue est donc le prix hors taxe, et non le montant réglé par le client. Deux clients ayant payé le même prix affiché ne produisent pas le même revenu net, selon leur pays de résidence. Le prix affiché se choisit lui-même dans une grille de points de prix par territoire, qu'Apple a élargie en 2023 à plusieurs centaines de valeurs par pays. Un tarif harmonisé hors taxes sur tous les marchés est impossible à obtenir dans un magasin, alors qu'il est trivial sur un site marchand. Le pilotage du revenu passe donc par une simulation territoire par territoire. Un taux moyen appliqué à l'ensemble du chiffre d'affaires masque ces écarts.

• Ingérer les notifications serveur et les rapports financiers séparément. Les premières donnent l'événement en temps réel et l'identifiant de transaction, les seconds donnent le montant net réellement versé. Aucune des deux sources ne remplace l'autre, et leurs totaux ne coïncident pas sur une même fenêtre calendaire.
• Comptabiliser en brut, puis en net. Le montant payé par le client, la taxe collectée par le magasin, la commission et les remboursements sont quatre grandeurs distinctes ; un revenu suivi directement en net rend impossible toute analyse de prix ou de remboursement.
• Rapprocher les remboursements sur la période où le magasin les impute. Un remboursement accordé en mars sur une vente de janvier se déduit du reversement de mars, ce qui rend l'écart inexplicable dans une comptabilité tenue à la date de vente.
• Traiter les notifications comme non ordonnées et rejouables. Les deux plateformes réémettent, et un traitement non idempotent produit des doubles ouvertures de droits ou des révocations à tort.
• Documenter l'entité contractante par territoire. L'identité de la société du magasin qui achète les contenus détermine le régime de TVA de la prestation du développeur, et elle diffère selon les zones.
• Conserver le calendrier fiscal du magasin dans l'entrepôt de données. L'alignement des périodes est la première cause d'écart de rapprochement, et la plus simple à supprimer définitivement.

La mesure du marché souffre de la même opacité que la réconciliation. Ni Apple ni Alphabet ne publient dans leurs états financiers le chiffre d'affaires de l'App Store ou de Google Play pris isolément. L'un l'agrège dans ses services, l'autre dans une ligne qui mêle abonnements, plateformes et appareils. Les volumes de dépense intégrée couramment cités proviennent donc de cabinets d'estimation, et cette source s'est concentrée après l'absorption de data.ai par Sensor Tower en 2024. Apple publie de son côté une étude commandée au cabinet Analysis Group. Celle-ci évaluait à 1 100 milliards de dollars les facturations et ventes réalisées par les développeurs dans l'écosystème App Store en 2022, dont plus de 90 % sans aucune commission. Le périmètre retenu par cette étude sert l'argumentation de son commanditaire. Le chiffre reste exact au regard de la définition employée. Sa lecture suppose de connaître ce que ce périmètre englobe.