Ouvrez App Store Connect ou la Google Play Console et vous verrez un nombre qui ressemble à votre chiffre d'affaires. Le mois dernier, il affichait 10 000 . Aucun des deux nombres n'est faux — mais un seul d'entre eux doit figurer dans votre compte de résultat en tant que « revenu », et se tromper sur cette décision peut discrètement fausser votre marge brute, induire en erreur votre taux de croissance, et présenter à un prêteur ou un investisseur une image de votre entreprise qui n'est pas vraie.
C'est la question du mandant contre le mandataire, et selon la norme de comptabilisation des revenus ASC 606 des PCGR américains, ce n'est pas une paperasse facultative — c'est la règle qui décide si vous déclarez 10 000 de coût des ventes, ou seulement 7 000 $ de revenus sans rien d'autre à dire. Pour un développeur indépendant vendant via l'App Store d'Apple ou le Google Play Store, la réponse surprend généralement les gens.
La question que tout développeur d'applications finit par se poser
Le déclencheur est presque toujours le même : un fondateur prépare un pitch deck, demande un prêt aux petites entreprises, ou essaie simplement de répondre à « combien ai-je réellement gagné ce trimestre », et se rend compte qu'il enregistrait comme « ventes » tout ce qui arrivait sur son compte bancaire. Ce montant est net de la commission d'Apple ou Google — ce qui signifie qu'il a déjà la part de la plateforme soustraite.
Le problème est que réduire votre chiffre d'affaires des frais de plateforme n'est pas un choix stylistique. ASC 606 a un test spécifique pour exactement cette situation, et il repose sur une question : qui contrôle ce qui est vendu avant que cela ne soit transféré au client ?
Le test de contrôle ASC 606, en termes simples
Le modèle de revenu en cinq étapes d'ASC 606 vous oblige à identifier les obligations de performance dans un contrat et à déterminer qui les satisfait. Lorsqu'une place de marché ou une plateforme se situe entre vous et le client final — Apple, Google, Etsy, DoorDash, Uber — les normes comptables appellent cela l'évaluation mandant contre mandataire, et le guide des revenus de PwC note que les ventes sur les magasins d'applications sont un exemple typique de situations nécessitant cet examen attentif.
- Mandant : vous contrôlez le bien ou le service avant qu'il ne soit transféré au client. Vous comptabilisez le montant brut total payé par le client en tant que revenu, et la commission de la plateforme devient un coût des ventes (une charge), et non une réduction du revenu.
- Mandataire : la plateforme contrôle l'offre et vous vous contentez d'organiser la vente pour le compte d'autrui. Vous comptabilisez uniquement le montant net que vous conservez comme vos frais.
Trois indicateurs déterminent lequel vous êtes, selon les cadres de Deloitte et PwC :
- Responsabilité d'exécution — qui est responsable si l'application ne fonctionne pas, si l'abonnement n'est pas livré, ou si un client se plaint ? C'est généralement vous, le développeur, pas Apple.
- Risque avant le transfert — qui supporte le risque que « l'inventaire » (votre application, votre contenu, votre niveau d'abonnement) ne se vende pas ou ne satisfasse pas le client ? Là encore, généralement vous.
- Discrétion sur la fixation du prix — qui fixe ce que le client paie réellement ? Vous choisissez le niveau de prix de votre application ; la plateforme ne le négocie pas avec vous transaction par transaction.
Parce que la plupart des développeurs indépendants contrôlent l'expérience produit, possèdent la relation client pour le support et les mises à jour, et fixent leurs propres prix, ils se retrouvent du côté du mandant dans ce test — ce qui signifie que la comptabilité correcte est d'enregistrer le montant brut payé par le client comme revenu, et de traiter la part d'Apple ou Google comme une ligne de coût des revenus, et non comme une réduction invisible.
Les chiffres derrière la commission
Savoir que vous êtes le mandant n'a d'importance que si vous savez ce qui est réellement déduit. Les structures de frais de plateforme ont considérablement changé ces dernières années, et la plupart des développeurs établissent encore leur budget sur des hypothèses obsolètes :
| Plateforme | Taux standard | Taux réduit | Qui est éligible |
|---|---|---|---|
| Apple App Store | 30% | 15% (App Store Small Business Program) | Développeurs avec ≤1 M$ de gains annuels sur l'App Store |
| Abonnements Apple | 30% (année 1) | 15% (année 2 et suivantes) | Tout abonnement après ses 12 premiers mois |
| Google Play | 30% | 15% sur les premiers 1 M$ gagnés par an | Tous les développeurs, appliqué automatiquement par palier |
| Abonnements Google Play | 15% forfaitaire | — | Tous les revenus d'abonnements |
| Apple UE (conditions du DMA) | ~17% + Core Technology Fee | jusqu'à ~20% combiné | Développeurs qui optent pour les conditions commerciales alternatives de l'UE |
Plus les coûts annuels fixes que la plupart des gens oublient d'allouer quelque part : les 99 de Google. Faibles, mais ils ont leur place dans votre plan comptable aussi — généralement en charge opérationnelle générale, pas en coût des ventes.
L'enregistrer correctement : un exemple concret
Disons qu'un client achète un abonnement in-app à 9,99 auprès du client, garde 3,00 sur votre compte bancaire. Enregistrer 6,99 $ comme « revenu » sous-estime votre chiffre d'affaires de 30 % — ce qui compte énormément si vous comparez votre taux de croissance à celui d'un concurrent qui vend en direct, ou si vous expliquez vos marges à un prêteur.
Les écritures correctes reconnaissent la vente complète, puis comptabilisent séparément la commission en charge :
2026-07-18 * "Apple" "Abonnement iOS — vente brute"
Actif:Clients:AppStore 9.99 USD
Produit:VentesApp -9.99 USD
2026-07-18 * "Apple" "Commission App Store 30%"
Charges:CoûtDesRevenus:FraisPlateforme 3.00 USD
Actif:Clients:AppStore -3.00 USD
2026-07-20 * "Apple" "Paiement reçu"
Actif:CompteCourant 6.99 USD
Actif:Clients:AppStore -6.99 USDRemarquez que le compte clients se solde à zéro une fois le paiement encaissé, mais votre compte de résultat affiche toujours 9,99 de coût des revenus — une marge brute de 70 % sur cette vente, et non 30 % mystérieusement manquants. C'est exactement le genre de transaction que les grands livres en texte brut et versionnés gèrent bien : la vente brute, les frais de plateforme et le paiement sont trois événements distincts et vérifiables, au lieu d'un seul dépôt bancaire flou.
Pourquoi le chiffre du tableau de bord ne suffit pas
Même une fois la règle connue, l'appliquer manuellement est plus difficile qu'il n'y paraît. Les rapports standard d'App Store Connect et de la Play Console montrent des totaux agrégés, et non les détails par abonné et par transaction qu'ASC 606 exige techniquement — les produits, les remboursements et la conversion de devises arrivent souvent en un seul montant forfaitaire des jours ou des semaines après la vente réelle. Cet écart est exactement la raison pour laquelle un nombre croissant d'entreprises d'applications par abonnement utilisent les API des plateformes ou des outils comme RevenueCat pour reconstituer les détails par transaction, plutôt que d'essayer de les rétro-ingéniérer à partir d'un résumé mensuel en PDF.
Ignorer cette étape a un coût réel. Un exemple largement cité : un développeur a vu 3 400 étaient dépensables — un écart de plus de 60 % entre le « revenu » qu'il pensait avoir et ce que l'entreprise avait réellement conservé. Les développeurs qui prennent des décisions d'embauche ou de dépenses sur la base du chiffre du tableau de bord, plutôt que du chiffre rapproché, établissent un budget par rapport à un nombre qui n'a jamais été réel.
Erreurs courantes qui faussent vos livres
- N'enregistrer que le dépôt net comme revenu. C'est l'erreur la plus courante et celle dont traite cet article — elle sous-estime à la fois le revenu et le coût des ventes, rendant votre image de marge brute plate et dénuée de sens.
- Ignorer les remboursements et les rétrofacturations. Apple et Google traitent tous deux les remboursements clients pour votre compte, parfois des semaines après la vente initiale — si vous ne faites pas de rapprochement par transaction, les revenus remboursés peuvent rester dans vos livres indéfiniment.
- Mélanger les 99 d'inscription Google dans le coût des ventes. Ce sont des coûts opérationnels fixes, pas des commissions par transaction — ils appartiennent à une catégorie de charges distincte.
- Oublier le barème de frais distinct de l'UE. Si une partie de votre base d'utilisateurs se trouve dans l'UE et que vous avez opté pour les conditions alternatives d'Apple, ces revenus ont une structure de commission différente du reste de votre activité et nécessitent leur propre compte.
Gardez vos finances organisées à mesure que vous évoluez
Que vous soyez un développeur solo avec une seule application sur le store ou que vous dirigiez un petit studio avec quelques produits par abonnement, la décision brut contre net se cumule chaque mois où vous vous trompez — au moment où vous levez des fonds ou demandez un financement, une ligne de revenus sous-estimée est difficile à expliquer. Beancount.io offre aux développeurs un grand livre en texte brut et versionné, conçu pour exactement ce type de transaction en plusieurs étapes — vente brute, commission de plateforme et paiement comme trois écritures distinctes et vérifiables, au lieu d'un seul dépôt bancaire flou. Commencez gratuitement et découvrez pourquoi les développeurs qui pensent déjà en code préfèrent une comptabilité qui fonctionne de la même manière.