Vous avez sorti votre jeu. Steam affiche 42 000 . Si vous ne savez pas exactement où sont passés les 14 600 $ restants, vous n'êtes pas seul — et surtout, vous ne regardez pas réellement les états financiers de votre entreprise, mais un tableau de bord de boutique qui n'a jamais été conçu pour en tenir lieu.
Le partage des revenus de Steam se résume souvent à « Valve prend 30 % », et pour l'immense majorité des développeurs indépendants, c'est globalement vrai. Mais cette ligne de 30 % n'est que l'une des cinq déductions distinctes qui se dressent entre le prix payé par le joueur et le montant qui atterrit sur votre compte courant professionnel : commission de plateforme, remboursements, conversion de devises, TVA/taxe de vente, et — si vous n'êtes pas contribuable américain — retenue fédérale à la source. Chacune mérite sa propre ligne dans vos comptes, car chacune se comporte différemment sur le plan fiscal, et les regrouper est précisément ce qui pousse les développeurs à soit surpayer leurs acomptes d'impôts trimestriels, soit essuyer une mauvaise surprise de la part de leur comptable en avril.
Voici comment l'argent circule réellement, et comment l'enregistrer pour que vos comptes reflètent la réalité plutôt que votre tableau de bord Steamworks.
Le partage des revenus par paliers de Steam, et pourquoi il compte peu pour la plupart des développeurs
La structure actuelle de Valve est échelonnée en fonction du revenu cumulé par titre :
- Commission de plateforme de 30 % sur les 10 premiers millions de dollars de revenu brut (vous conservez 70 %)
- Commission de plateforme de 25 % sur le revenu compris entre 10 et 50 millions de dollars (vous conservez 75 %)
- Commission de plateforme de 20 % au-delà de 50 millions de dollars (vous conservez 80 %)
Ces paliers ont été ajoutés sous la pression de grands éditeurs menaçant de déplacer leurs titres à gros budget vers des boutiques concurrentes, et non par geste favorable aux indépendants. Les chiffres le confirment : le jeu indépendant médian rapporte entre 5 000 et 15 000 $ de revenu cumulé, et même un titre dans le top 5 % des ventes dépasse rarement le million de dollars. À moins de concevoir le prochain succès retentissant, planifiez vos comptes autour d'une commission fixe de 30 % — les paliers ne sont qu'une erreur d'arrondi pour un jeu qui ne franchit jamais les huit chiffres.
Cela dit, si vous avez un titre qui approche les 10 millions de dollars, c'est exactement le type de seuil que votre comptabilité doit surveiller en temps réel, et non découvrir trois mois plus tard en rapprochant un relevé de paiement. Un plan comptable qui suit le revenu par titre (et non un seul compte global « Revenu Steam ») vous permet d'anticiper le franchissement de palier.
Revenu net : sur quoi Steam vous rémunère réellement
C'est le point qui déstabilise les développeurs venant d'un commerce de détail ou d'un modèle d'abonnement plus simple : la commission de Steam n'est pas calculée sur le prix affiché. Elle est calculée sur le revenu net, c'est-à-dire le revenu brut moins les ajustements applicables.
Le revenu brut inclut la TVA et la taxe de vente perçues à la caisse. Les ajustements applicables comprennent :
- Remboursements et rétrofacturations — le prix d'achat intégral de toute copie remboursée est déduit
- TVA/taxe de vente — les prix Steam incluent la taxe dans la plupart des pays, et Valve la reverse directement à l'autorité compétente ; elle n'entre jamais dans le calcul de votre partage des revenus
- Conversion de devises — les ventes internationales sont réglées en dollars américains au taux de conversion de Valve, qui varie avec les marchés des changes entre la date de vente et la date de paiement
Ce n'est qu'après déduction de tout cela que le partage des revenus de 70/75/80 % s'applique. En pratique : vous ne payez pas la commission de Steam sur une vente remboursée (c'est un avantage), mais vous ne pouvez pas non plus comptabiliser le prix affiché comme revenu dès le départ (ce qui est important, car cela signifie que votre chiffre de « ventes brutes » issu des tableaux de bord marketing sera toujours supérieur à votre revenu brut comptable).
Approche comptable : enregistrez deux chiffres distincts pour chaque période de paiement — le revenu brut de plateforme (net de TVA, avant remboursements) comme ligne de revenu, et les remboursements comme un compte de contre-revenu qui vient s'y soustraire dans votre compte de résultat. Ne comptabilisez pas simplement le montant final déposé comme « Revenu Steam » — vous perdriez la capacité de suivre l'évolution de votre taux de remboursement, l'un des indicateurs de santé les plus utiles pour un studio indépendant.
Les remboursements ne sont pas une erreur d'arrondi — suivez le taux, pas seulement les montants
La politique de remboursement de Steam permet à un joueur de demander un remboursement intégral pour tout achat effectué au cours des deux semaines précédentes, à condition d'avoir joué moins de deux heures. C'est nettement plus généreux que les boutiques console ou mobile, et cela existe pour de bonnes raisons (cela met fin à beaucoup d'abus du type « acheter, pirater la copie sans DRM, se faire rembourser » et instaure la confiance avec les acheteurs). Sur l'ensemble de la plateforme, les taux de remboursement s'élèvent en moyenne à environ 5 % des achats, mais les jeux narratifs courts et les titres pouvant être « terminés sur le chemin critique » en moins de deux heures affichent souvent des taux bien plus élevés — certains développeurs ont signalé des taux de remboursement grimpant à deux chiffres pour des titres qu'un joueur peut terminer en une seule session avant la fin de la fenêtre de deux heures.
Pour vos comptes, cela signifie :
- Considérez les remboursements comme un coût récurrent de votre activité sur Steam, et non comme une exception. Budgétez-les comme un détaillant budgète la démarque inconnue.
- Surveillez le taux de remboursement comme un indicateur clé, pas seulement le montant total remboursé. Un taux qui grimpe après un correctif ou une campagne marketing est un signal — soit un bug, soit une page de boutique trompeuse, soit (de plus en plus fréquent en 2026) un abus de la fenêtre de remboursement ciblant les jeux courts.
- Ne comptabilisez jamais le revenu d'une vente tant que la fenêtre de remboursement n'est pas véritablement passée, si vous appliquez une comptabilisation formelle du revenu (ASC 606) — la plupart des studios indépendants n'ont pas besoin de différer la comptabilisation pour une fenêtre de remboursement de deux semaines, étant donné sa courte durée et son taux statistiquement prévisible, mais si les remboursements sont significatifs et volatils pour votre titre, une provision mensuelle pour remboursements est une approche plus fidèle que de comptabiliser 100 % des ventes brutes et d'encaisser le coup plus tard.
Tarification régionale et la conversion de devises que vous n'avez pas choisie
Steam prend en charge la tarification dans 35 devises, et la mise à jour tarifaire 2026 de Valve va au-delà d'une simple conversion au taux de change en tenant aussi compte du pouvoir d'achat local et des normes de tarification régionales du divertissement — ce qui signifie que votre prix de 19,99 $ US peut se traduire par un prix réel très différent au Brésil ou en Asie du Sud-Est, par exemple, et cette traduction peut évoluer dans le temps même si vous ne touchez jamais à vos propres paramètres de prix.
Deux conséquences pour votre comptabilité :
- Chaque vente internationale est une conversion en dollars, pas un chiffre fixe. Le taux utilisé est celui de Valve au moment du reporting, et non celui du jour où le joueur a acheté le jeu. Si vous suivez le revenu par région à des fins fiscales ou de planification d'entreprise, extrayez la répartition régionale de votre rapport de ventes Steamworks plutôt que d'essayer de la recalculer à partir du montant déposé.
- N'ajustez pas manuellement vos prix régionaux sans vérifier l'effet en aval sur le revenu net par unité. Une baisse de prix dans un pays à TVA élevée peut réduire votre part davantage que ne le suggère la variation du prix affiché, car la TVA est déduite avant l'application du partage des revenus.
Le calendrier des paiements : pourquoi votre dépôt bancaire ne correspond jamais aux ventes du mois
Valve verse les paiements environ 30 jours après la clôture du mois de vente — les ventes de février sont payées fin mars, par exemple — et Steam retient le paiement tant que votre compte n'a pas franchi un seuil minimal de 100 $, ce qui compte pour les petits titres en accès anticipé ou les studios gérant plusieurs petits jeux dont le revenu mensuel d'un titre individuel pourrait ne pas franchir seul ce seuil.
Ce décalage est la source de confusion la plus courante pour les nouveaux développeurs Steam qui constatent que « leurs comptes ne correspondent pas à leur compte bancaire ». La solution est la comptabilité d'exercice standard : enregistrez le revenu le mois où la vente a réellement eu lieu (selon votre rapport de ventes Steamworks), et non le mois où l'argent arrive sur votre compte bancaire. Mettez en place un compte « Créance Steam » qui accumule le revenu net de chaque mois et s'apure lorsque le virement ou le dépôt ACH arrive environ 30 jours plus tard. Sans cela, votre compte de résultat mensuel ressemblera à des montagnes russes sans rapport avec votre tendance de ventes réelle — il reflétera simplement les mois qui ont eu la chance de recevoir un paiement.
Retenue fiscale : l'étape que les développeurs non américains sautent et regrettent
Si vous êtes contribuable américain, Valve vous délivre un formulaire 1099 et vous le traitez comme tout autre revenu professionnel. Si vous n'êtes pas contribuable américain, voici la partie qui piège les gens :
Le revenu Steam est classé comme un revenu de redevance de source américaine (plus précisément, le taux de redevance de droit d'auteur applicable aux jeux et au DLC). Lors de l'intégration Steamworks, chaque partenaire remplit un entretien fiscal et génère soit un formulaire W-9 (développeurs américains), soit un formulaire W-8BEN (développeurs non américains). Selon votre pays de résidence et l'existence d'une convention fiscale avec les États-Unis, Valve retient entre 0 % et 30 % de votre part de revenu avant même qu'elle n'atteigne votre compte bancaire, et le déclare annuellement sur le formulaire 1042-S, délivré au plus tard le 15 mars.
Si vous constatez une retenue de 30 % alors que votre pays a une convention fiscale avec les États-Unis qui vous ouvrirait droit à un taux réduit, vous n'avez probablement pas rempli correctement l'entretien fiscal — souvent parce que vous n'avez pas fourni un numéro d'identification fiscale étranger ou américain là où l'avantage conventionnel l'exige. C'est un formulaire que vous pouvez soumettre à nouveau ; ce n'est pas un taux définitif. Pour un développeur solo, la différence entre une convention non réclamée (30 % retenus) et une convention réclamée (souvent 0 à 15 %, selon le pays) peut représenter des milliers de dollars par an — cela vaut bien une demi-heure pour revérifier l'entretien.
Dans tous les cas, cette retenue constitue une ligne distincte de la commission de plateforme de Steam. Ne mélangez pas « la part de Steam » et « la retenue fiscale » en un seul chiffre dans vos comptes — leur traitement fiscal est totalement différent. Le montant retenu est un prépaiement de votre propre obligation fiscale (vous pouvez éventuellement le réclamer comme crédit d'impôt étranger ou le récupérer selon le traitement fiscal de votre pays d'origine), tandis que la commission de plateforme est simplement les frais de Valve, un point c'est tout, et n'est créditable contre rien.
Un plan comptable simple pour un studio financé par Steam
Pour un petit studio, cinq comptes couvrent presque tout ce qui précède :
- Revenu brut Steam — ventes au prix net de TVA, avant remboursements et commission
- Remboursements Steam (contre-revenu) — valeur en dollars des ventes remboursées ou rétrofacturées
- Frais de plateforme Steam — la commission de 30/25/20 %, suivie séparément de...
- Retenue fiscale Steam — développeurs non américains uniquement ; à traiter comme un actif fiscal prépayé, pas comme une dépense
- Créance Steam — revenu accumulé mais non payé du mois en cours et du mois précédent, apuré lorsque le paiement arrive
Si vous gérez plus d'un titre, ajoutez une classe ou une étiquette par jeu plutôt qu'un tout nouveau jeu de comptes — vous voulez pouvoir comparer la performance des titres sans dupliquer cinq fois votre plan comptable.
Gardez les comptes de votre studio de jeu aussi propres que votre code source
Si vous êtes à l'aise pour lire un rapport de ventes Steamworks, vous êtes à l'aise avec le texte brut — ce qui est exactement le principe sur lequel repose Beancount.io. Plutôt que de vous débattre avec un outil comptable piloté par une interface graphique pour modéliser quelque chose d'aussi irrégulier que des commissions de plateforme par paliers, des provisions pour remboursements et des retenues fiscales à l'étranger, vous l'écrivez une fois sous forme de grand livre versionné et vous obtenez gratuitement tous les calculs qui en découlent. Consultez la documentation pour voir comment les développeurs structurent un grand livre de revenus de marketplace, ou explorez Fava pour une vue tableau de bord des revenus, remboursements et frais par titre, sans quitter le texte brut.