Rentabilité de la publicité d'une application : ROAS, CAC, LTV

Ce que « rentable » veut dire pour une application

Une campagne est rentable quand l’utilisateur qu’elle amène rapporte, net des commissions et du churn, plus qu’il n’a coûté, et que cet argent revient assez vite pour financer la campagne suivante. Le CPI, le ROAS, le taux de conversion ne sont que des étapes intermédiaires pour calculer ou prédire les deux nombres qui comptent vraiment, la LTV et le CAC.

Il est tentant de juger une campagne sur son CPI, ou sur le ROAS que Meta affiche au bout de trois jours. Ni l’un ni l’autre ne répond à la question. Voici la chaîne complète.

Le calculateur ci-dessous suit cette chaîne pas à pas. Vous entrez vos hypothèses, il vous rend le CAC, la LTV simplifiée, le payback et le CPI maximal que vous pouvez vous permettre.

Du CPI au ROAS : la chaîne complète

Étape 1 : du CPI au CAC par payant

Le CPI est le seul chiffre que les plateformes vous donnent en direct, et il ne dit rien de la qualité des installs. Pour passer au CAC, il vous faut votre taux de conversion install → payant, celui que mesure votre outil d’attribution ou votre backend. Le gestionnaire de publicités, lui, ne le connaît pas.

Avec un CPI de 2 € et 4 % d’installs qui finissent par payer, chaque payant coûte 50 €. Même CPI, 1,5 % de conversion, et il coûte 133 €. Le CAC se joue donc sur la conversion bien plus que sur le prix de l’install. Les fourchettes de CPI actuelles sont dans mon benchmark du coût par installation.

Étape 2 : la LTV par courbe de rétention (la méthode juste)

La LTV d’un utilisateur, c’est la somme de ce qu’il rapporte chaque jour, pondérée par la probabilité qu’il soit encore là ce jour-là. Dans la pratique, vous prenez votre courbe de rétention (D1, D7, D30, D90…), votre revenu net moyen par utilisateur actif et par jour, et vous additionnez sur un horizon fixé, 90, 180 ou 365 jours.

LTV(180 j) = Σ (jour 0 → 180) [ rétention(jour) × revenu net par utilisateur actif ce jour ]

J’utilise cette méthode dès qu’une app a trois mois de données. Elle marche pour tous les modèles, abonnement, pub, achats in-app, marketplace, parce qu’elle ne suppose rien sur la forme du churn. Son défaut, c’est qu’il faut une cohorte assez vieille pour connaître la fin de la courbe. Avant cela, on extrapole, en restant honnête sur l’incertitude.

Étape 3 : l’approximation ARPU ÷ churn (et pourquoi « ARPU + 1/churn » est faux)

Pour une app à abonnement, on peut simplifier. Si un abonné paie 8,49 € net par mois et que 8 % des abonnés partent chaque mois, sa durée de vie moyenne est de 1 ÷ 0,08 = 12,5 mois, donc sa LTV est de 8,49 × 12,5 = 106 €. D’où la formule courte :

LTV ≈ revenu mensuel net par payant ÷ churn mensuel

Plusieurs pages françaises qui rankent sur « LTV application » écrivent « LTV = ARPU + 1/churn ». C’est une erreur de transcription, et elle additionne des euros et des mois. Avec les chiffres ci-dessus, elle donnerait 8,49 + 12,5 = 20,99, un nombre qui ne veut rien dire. Le bon opérateur est une division, ou une multiplication par la durée de vie.

L’approximation suppose un churn constant. En réalité, il est très concentré au début. RevenueCat observe que 35 % des annulations d’abonnements annuels ont lieu dès le premier mois (State of Subscription Apps 2026, plus de 115 000 apps). Le churn mensuel « moyen » sous-estime donc la LTV des abonnés qui passent le cap des premiers mois, et la surestime pour les cohortes jeunes. Servez-vous-en pour un ordre de grandeur, puis passez à la courbe de rétention.

Étape 4 : LTV / CAC et payback

Une fois la LTV et le CAC connus, le ratio vous dit si vous gagnez de l’argent, et le payback vous dit quand. Je regarde toujours les deux. Un ratio de 2,5 avec un payback de 14 mois vous oblige à financer 14 mois de dépense avant de revoir un euro, et peu de trésoreries de studio le supportent.

Le payback simplifié est CAC ÷ revenu mensuel net. Il ignore le churn, donc il est optimiste. Avec un CAC de 50 € et 8,49 € par mois, il annonce 5,9 mois ; en tenant compte des 8 % d’abonnés perdus chaque mois, le revenu cumulé n’atteint 50 € qu’au bout de 7,6 mois. Le calculateur ci-dessus fait ce calcul avec attrition.

Étape 5 : ROAS D7, D30, D90 et ROAS d’équilibre

Le ROAS est le revenu rapporté à la dépense sur une fenêtre donnée. Le ROAS D7 regarde les sept premiers jours de vie de chaque install, le D30 les trente premiers. Vous lisez des instantanés d’une courbe qui monte encore. Un ROAS D7 ou D30 n’est utile que si vous savez comment il se relie au revenu final et au délai de remboursement.

Le ROAS d’équilibre est le niveau qui, à un horizon donné, rembourse la dépense. Liftoff le définit à la vie entière comme 1 ÷ marge (2026) : avec 25 % de marge, il faut un ROAS de 400 %. Pour une fenêtre courte, le raisonnement passe par un multiplicateur :

Multiplicateur = LTV ÷ revenu net des 30 premiers jours
ROAS D30 d'équilibre = 1 ÷ multiplicateur

Si un payant rapporte 106 € sur sa vie et 8,49 € le premier mois, le multiplicateur est de 12,5 et le ROAS D30 d’équilibre de 8 %. Un ROAS D30 de 17 % est donc excellent pour cette app, alors qu’il ferait fermer une boutique e-commerce. Liftoff donne un ordre de grandeur comparable pour un abonnement à 9,99 $, environ 43 % de ROAS D30 pour être à l’équilibre, avec des hypothèses de rétention plus courtes. Le chiffre dépend entièrement de votre courbe. Calculez le vôtre.

Trois exemples chiffrés sur des hypothèses de travail

Les entrées ci-dessous sont des hypothèses que je choisis pour montrer le calcul. Elles ne viennent d’aucun compte réel, et aucune ne fait office de benchmark. Remplacez-les par vos chiffres.

Exemple 1 : une app à abonnement

Prix 9,99 €/mois, commission store 15 % (le taux du programme Petites Entreprises d’Apple sous un million de dollars de revenus), soit 8,49 € net. CPI 2 €, 4 % des installs deviennent payants : CAC = 2 ÷ 0,04 = 50 €. Churn 8 % par mois : LTV ≈ 8,49 ÷ 0,08 = 106 €. LTV/CAC = 2,1. Payback avec attrition : 7,6 mois.

Revenu D30 par install = 4 % × 8,49 € = 0,34 €, pour 2 € dépensés : ROAS D30 = 17 %. Avec un multiplicateur de 12,5, le ROAS D30 d’équilibre est de 8 %. Cette app est rentable, mais son payback dépasse six mois. Avant de scaler, je travaillerais la conversion en payant ou le churn plutôt que le CPI. Passer de 4 à 5 % de conversion ramène le CAC à 40 € et le ratio à 2,7, et ce gain-là vient souvent du paywall et de la fiche store plus que du média.

Exemple 2 : une app financée par la publicité

CPI 0,50 €, dans la fourchette d’un install Android casual en Europe de l’Ouest. Revenu publicitaire net 0,04 € par utilisateur actif et par jour. Courbe de rétention D1 40 %, D7 15 %, D30 5 %, D90 2 %. En additionnant jour par jour, un install génère environ 8 jours d’activité sur 180 jours, donc une LTV d’environ 0,32 €.

À 0,50 € de CPI, cette app perd 0,18 € par install. Son ROAS D7 est pourtant de 22 % (0,11 € de revenu sur 7 jours), ce qui paraît bon. Voilà le piège des apps monétisées par la pub. La courbe de revenu est très plate après la première semaine, donc le multiplicateur est petit (environ 2,9) et le ROAS D7 d’équilibre est élevé (environ 35 %). Pour que cette app gagne de l’argent, il faut soit un CPI sous 0,32 €, soit un revenu par actif au-dessus de 0,06 € par jour.

Exemple 3 : une marketplace

CPI 3 €, 10 % des installs passent une première commande : CAC par acheteur = 30 €. Panier moyen 60 €, commission 15 %, soit 9 € de marge par commande. Quatre commandes par acheteur la première année, et 40 % des acheteurs encore actifs la deuxième : contribution ≈ 36 € + 0,4 × 36 € = 50 € sur deux ans. LTV/CAC = 1,7, payback ≈ 3,3 commandes, soit une dizaine de mois.

Le piège ici est le ROAS calculé sur le volume d’affaires. 4 × 60 € = 240 € de GMV pour 30 € de CAC, soit 800 %, un chiffre flatteur qui ne paie aucune facture. Le ROAS sur marge est de 120 % à un an. Envoyez aux plateformes la valeur que vous gardez plutôt que celle qui transite par vos comptes.

D’où vient le « 3:1 » et pourquoi il ne s’applique pas tel quel

Le ratio LTV/CAC de 3 vient du logiciel B2B, avec ses marges brutes proches de 80 % et ses contrats annuels qui rendent le churn faible. Une app mobile ne ressemble à rien de tout ça. Elle reverse 15 à 30 % aux stores, perd ses abonnés mois après mois, et sa LTV à un an est souvent mesurée avec une marge d’erreur de 20 à 30 % parce qu’une partie du revenu iOS n’est pas attribuée.

À la place, je regarde la marge de contribution après commission et coûts variables, puis le payback en mois, et je garde un œil sur l’écart entre la LTV mesurée et la LTV prédite. Un ratio de 2 avec un payback de quatre mois et une mesure propre est en général un feu vert pour scaler. Un ratio de 3 obtenu avec une LTV extrapolée sur 24 mois pour une app qui a six mois d’existence reste une hypothèse, et je ne scale pas sur une hypothèse. Pour dimensionner la dépense à partir de ces ratios, voyez mon guide sur le budget marketing d’une application.

iOS sous-déclare souvent votre ROAS depuis ATT

Depuis App Tracking Transparency, seuls les utilisateurs iOS qui acceptent le suivi sont attribuables individuellement. Au moment où j’écris, environ la moitié des utilisateurs refusent encore : AppsFlyer mesurait en avril 2025 un taux d’acceptation d’un peu moins de 51 % en France, contre 50 % dans le monde. Pour les autres, l’attribution passe par SKAdNetwork 4 et AdAttributionKit, c’est-à-dire des postbacks agrégés, envoyés avec retard sur plusieurs fenêtres de conversion successives, avec des valeurs masquées quand le volume est trop faible.

Le ROAS iOS que vous lisez dans Meta ou dans votre MMP peut donc s’écarter nettement du ROAS réel, et l’écart grandit quand le volume et le niveau de détail de l’attribution baissent. Avant de couper une campagne iOS, je fais quelques vérifications.

• Comparez le revenu iOS total (App Store Connect) à la dépense iOS totale sur la même période, par pays. Vous obtenez votre ROAS iOS « vrai », toutes sources confondues.
• Utilisez la modélisation de votre MMP (AppsFlyer, Adjust) pour combler les postbacks masqués, en gardant en tête que c’est une estimation.
• Jugez iOS sur des fenêtres plus longues qu’Android, et sur des cohortes assez grosses pour passer les seuils de confidentialité.

Le détail du fonctionnement est dans mon guide sur le tracking des installations iOS.

Organique, incrémentalité : ce que le ROAS ne voit pas

Le ROAS attribué compte les installs que la plateforme revendique. Il passe à côté de deux effets qui tirent en sens contraire. La publicité fait monter le classement dans les stores et déclenche des installs organiques qui n’apparaissent dans aucune campagne, ce qui rend votre ROAS réel plus haut que votre ROAS attribué. En même temps, une partie des installs attribués (retargeting, marque, Apple Ads sur votre propre nom) seraient venus sans publicité, et là votre ROAS réel est plus bas.

Personne n’a un coefficient universel. Je suis le ratio installs organiques ÷ installs payants semaine par semaine, et je regarde comment il bouge quand je coupe ou double un canal. Une coupure d’une semaine sur un pays test, comparée à un pays témoin, en apprend plus qu’un mois de tableaux de bord. J’en parle dans ma stratégie d’acquisition d’utilisateurs.

Ce que j’ai vu sur un gros compte

Les chiffres ci-dessus sont des hypothèses de calcul. Voici un cas réel, sans nom : une app de live streaming et de rencontre sur laquelle j’ai géré jusqu’à 9 M$ de budget par mois. L’étude de cas donne le détail.

• Les campagnes étaient optimisées sur le premier achat de coins, et je lisais les cohortes à J0, J3, J7, J14 et J30. Suivies sur un an, elles atteignaient un ROAS brut d’environ 50 % à J90 et 100 % à J180, puis un ROAS net de 100 % à J365, ce qui correspond à environ 200 à 300 % de ROAS brut. Le net s’entend après commissions des stores, écart de frais Stripe et coûts de fonctionnement de l’app. Jugées au seul ROAS D30, ces cohortes auraient eu l’air perdantes.
• Pour décider sans attendre un an, j’ai construit un modèle de progression des cohortes et de ROAS prédit, exposé en API. Il servait à piloter vers 100 % de ROAS brut et net en fin de fenêtre, avec un modèle et des objectifs différents par région. Les États-Unis avaient le meilleur taux de conversion, et au Moyen-Orient un ciblage précis apportait des payeurs à l’ARPPU nettement plus élevé.
• Le pilotage se faisait par objectifs de CPA et de ROAS, et c’est l’enchère, pas le budget, qui limitait la dépense.
• Sur les réseaux publicitaires (AppLovin, ironSource, Moloco, Mintegral), les cohortes mûrissent plus tard que sur Google ou Instagram, et la fraude y est fréquente. Il faut être plus patient avant de trancher.

Pour une app à abonnement, le même raisonnement s’applique avec d’autres points d’attention. Surveillez la conversion install → payant avant le CPI, parce qu’elle pèse plus que lui dans le CAC et que le paywall la fait bouger. Le rapport entre la LTV à un an et le revenu à 30 jours dépend surtout du mix mensuel / annuel : une app qui vend surtout de l’annuel encaisse presque tout le premier mois, une app en mensuel voit son multiplicateur monter avec la rétention. Quant au payback acceptable, il dépend de votre marge, de votre trésorerie et de la vitesse à laquelle le revenu arrive. Il n’existe pas de seuil unique, mais plus la trésorerie est courte, plus il doit l’être aussi, et une levée ne justifie un payback long que si la LTV est mesurée plutôt qu’extrapolée.

Si vous avez du revenu sans savoir quel ROAS ou quel CAC accepter, envoyez-moi vos chiffres de départ depuis la page contact. Ce calcul fait sur vos propres données est aussi le premier livrable de ma gestion de l’acquisition payante.

Erreurs fréquentes

• Comparer la LTV au CPI. La LTV est par payant, le CPI par install ; il vous faut le CAC par payant entre les deux.
• Utiliser le prix affiché au lieu du revenu net. Retirez la commission du store, la TVA si votre prix l’inclut, et les remboursements.
• Calculer la LTV sur 24 mois pour une app de 6 mois. Vous n’avez pas la donnée. Prenez un horizon que vous avez mesuré, et dites que c’est une borne basse.
• Couper iOS sur le ROAS D3 de Meta, c’est-à-dire sur un chiffre incomplet par construction.
• Envoyer la GMV comme valeur de conversion. Les algorithmes se mettent alors à chercher les gros paniers, et la marge ne suit pas forcément.
• Ignorer les remboursements et les échecs de paiement. RevenueCat mesure que 31 % des annulations sur Google Play sont des échecs de facturation, contre 14 % sur l’App Store (2026). Ce churn-là se récupère.

Quand ne pas chercher la rentabilité tout de suite

Au lancement, pendant les quatre à six premières semaines, une LTV encore immature n’est qu’une estimation, et je ne prends aucune décision de scale sur un ratio LTV/CAC. Le but est d’acheter de la donnée : une courbe de rétention, un taux de conversion, une première idée du CPI par canal. On dépense un budget de test fixé à l’avance, on commence par les signaux que les données permettent vraiment de lire (rétention D7, conversion), puis on allonge la fenêtre à mesure que les cohortes mûrissent. À plus grande échelle, c’est précisément le rôle d’un modèle de ROAS prédit.

Même chose quand la mesure n’est pas en place. Sans MMP configuré, sans événements de revenu remontés, sans distinction entre organique et payant, le calcul donnera un chiffre faux avec trois décimales. Dans ce cas, réparez la mesure d’abord. C’est aussi ce que je vérifie en premier dans une analyse gratuite.