Un client m'a appelé l'an dernier, paniqué. Son app de méditation tournait bien — 9 000 utilisateurs actifs mensuels — et il venait de recevoir un courrier de la CNIL. Motif : il affichait des pubs ciblées à des utilisateurs français sans avoir jamais recueilli un consentement conforme. Il avait branché un SDK publicitaire, lu trois lignes de doc, et publié. Deux mois plus tard, sa régie lui coupait le robinet.
Voilà le problème que personne ne raconte quand on parle de monétiser une application mobile légalement. Tout le monde liste les modèles — app payante, freemium, abonnement, achats intégrés, pub. Personne ne vous explique que le même modèle qui rapporte peut vous coûter votre compte développeur. Et c'est exactement là que ça se joue.
Points clés à retenir
- Le choix du modèle de revenus (payant, freemium, abonnement, achats intégrés, publicité) dépend surtout de votre type d'app et de votre audience — il n'existe pas de recette universelle.
- La publicité ciblée impose un consentement réel : cookies, identifiants publicitaires, données personnelles. Sans ça, c'est une infraction, pas un détail.
- Apple et Google prélèvent une commission sur les transactions in-app (souvent 15 à 30 %), et leurs règles déterminent ce qui est autorisé ou non.
- Vendre, c'est facturer. Facturer, c'est gérer TVA et mentions légales — y compris la TVA intra-UE dès que vous vendez à des particuliers dans d'autres pays.
- Un SDK publicitaire mal intégré peut faire tomber toute votre app, même si le reste est impeccable.
- La conformité n'est pas un frein à la rentabilité : c'est ce qui vous évite de perdre un revenu déjà acquis.
Comment monétiser une application mobile légalement, sans se faire couper les vivres
La question qu'on me pose le plus souvent, formulée telle quelle, c'est : « Comment puis-je monétiser mon application mobile ? » La réponse courte tient en une phrase : vous choisissez un modèle, vous vérifiez que les règles du store et le droit vous autorisent à l'exécuter comme vous l'imaginez, puis vous facturez proprement. L'ordre compte.
Beaucoup font l'inverse. Ils testent une pub agressive, encaissent, puis découvrent les conditions. Franchement, ça se termine mal.
Les modèles qui existent, et ce qu'ils impliquent légalement
Les options sont connues : application payante à l'achat, abonnement, achats intégrés, publicité, dons. Ce que l'on vous dit rarement, c'est que chaque modèle traîne ses propres obligations.
- App payante : simple, mais vous vendez à un consommateur. Droit de rétractation, CGV, facturation.
- Abonnement : revenu récurrent — et obligations de résiliation claire. Un abonnement qu'on ne peut pas annuler facilement, c'est un contentieux qui arrive.
- Achats intégrés : passent par la facturation Apple/Google, donc par leurs règles et leur commission.
- Publicité : le modèle le plus piégeux juridiquement, je détaille plus bas.
- Dons : léger en apparence, mais si vous passez par un store, vous restez soumis à ses conditions.
Un point qu'on oublie : les reader apps. Pour certains contenus (presse, livres, musique), Apple autorise des liens vers un paiement externe. Mais « autorisé » ne veut pas dire « faites ce que vous voulez » — les conditions sont précises, et une mauvaise interprétation vous vaut un rejet.
Le no-code change la donne — pas les obligations
On peut aujourd'hui publier une app sans écrire une ligne de code, via des app builders, puis encaisser avec Apple Pay ou Google Pay. C'est vrai, et c'est une bonne nouvelle pour les indépendants.
Sauf que le no-code ne vous exempte de rien. J'ai vu des créateurs publier une app de suivi sportif en trois semaines avec un outil no-code, brancher une régie pub en deux clics, et se retrouver avec une bannière de consentement vide de sens. Le formulaire existait. Il ne recueillait aucun consentement valable. Résultat : zéro. Aucune donnée exploitable, aucune pub ciblée possible — juste l'illusion d'être en règle.
Le volet légal que personne ne vous explique
C'est ici que 90 % des articles sur la monétisation s'arrêtent. Le mot « légalement » disparaît et on vous vend du rêve.
RGPD, consentement et publicité : la partie qui coûte cher
Dès que vous collectez des données — et une app en collecte presque toujours — vous entrez dans le champ de la protection des données. Pour la pub ciblée, cela signifie un consentement réel : cookies, identifiants publicitaires, intention claire.
Les règles à retenir, sans jargon :
- Le consentement doit être libre, spécifique, éclairé et univoque.
- Un « continuer » implicite n'en est pas un.
- Les mentions « contenu sponsorisé » ou « publicité » doivent être visibles, pas cachées en bas de page.
- La publicité destinée aux enfants suit des règles renforcées : là, on ne joue pas.
Le client dont je parlais au début n'avait pas de bannière trompeuse. Il avait juste oublié que le SDK qu'il utilisait transmettait l'identifiant publicitaire avant tout consentement. C'est une erreur d'intégration, pas de mauvaise foi. Elle lui a coûté une régie et plusieurs semaines de remise en conformité.
Facturation, TVA et obligations quand vous vendez
Vendre, c'est facturer. Et facturer une app, c'est souvent vendre à des particuliers répartis dans plusieurs pays — ce qui déclenche la TVA intra-UE dès que vous dépassez certains seuils, avec un taux qui dépend du pays de l'acheteur.
Deux cas de figure :
| Vente via le store | Vente en direct (hors store) |
|---|---|
| Le store gère la transaction et prélève sa commission | Vous gérez la transaction, la facture et la TVA |
| Vous restez responsable de vos mentions légales et de votre CGU | Vous portez toute la chaîne, y compris le recouvrement |
| Moins de contrôle sur la relation client | Relation directe, mais plus d'obligations |
Les commissions des stores se situent généralement entre 15 et 30 % selon le programme et le chiffre d'affaires. Ce n'est pas un détail comptable : c'est ce qui sépare une idée rentable d'une idée qui ne l'est pas.
Respecter les règles des stores, ou perdre l'accès du jour au lendemain
Apple et Google ne sont pas des partenaires neutres. Ils fixent les règles, encaissent les commissions, et peuvent retirer votre app. Apple a ses App Store Review Guidelines ; Google Play a ses politiques de facturation et ses règles sur les achats intégrés et la publicité.
Ce qui détermine, concrètement, ce qui est autorisé :
- La facturation des contenus numériques doit passer par leur système, sauf exceptions encadrées.
- Les liens vers un paiement externe sont limités, et pas pour tout le monde.
- La publicité doit respecter leurs politiques, y compris sur les audiences sensibles.
Ce que j'ai appris à la dure : lisez les règles avant de coder le tunnel de paiement. Pas après. Refactoriser un flux de paiement déjà en production, je l'ai fait une fois. Je ne le referai pas.
Quelle app rapporte quoi, et pourquoi ce n'est pas votre problème principal
On classe souvent les catégories d'apps par rentabilité : jeux, réseaux sociaux, finance, fitness arrivent en tête. C'est vrai en moyenne. Mais la moyenne ne paie pas vos factures.
La fourchette que l'on voit circuler pour environ 10 000 utilisateurs actifs quotidiens va de quelques centaines à plusieurs milliers d'euros par mois. Un écart de 1 à 30, pour un même volume d'utilisateurs. Pourquoi ? Parce que tout dépend de ce que vous vendez, à qui, et à quel prix. Une app de fitness avec abonnement à 9 €/mois ne vit pas dans le même monde qu'une app de jeu gratuite financée par la pub.
Mon avis, et je le défends : commencez par l'abonnement ou l'achat intégré, gardez la pub pour plus tard. La pub attire les ennuis juridiques, dépend d'un consentement que vous maîtrisez mal, et rapporte peu tant que vous n'avez pas de volume. L'abonnement vous oblige à soigner la valeur — ce qui, bizarrement, améliore aussi la rétention.
Et si je veux juste tester la pub avant de m'engager ?
Faites-le, mais posez d'abord un vrai mécanisme de consentement, et lisez les conditions du SDK avant de l'intégrer. Un test qui vous expose à une plainte n'est pas un test. C'est un pari.
Ce que je ferais à votre place
Trois choses, dans cet ordre. D'abord, choisir un modèle unique et le tester à petite échelle — pas trois en parallèle. Ensuite, vérifier la conformité du tunnel de paiement et du flux de consentement avant la mise en ligne, pas après. Enfin, mettre à jour vos CGU et vos mentions légales dès que le modèle change, parce qu'un changement de modèle sans changement de documents, c'est le genre d'écart qui se remarque en cas de contrôle.
La monétisation légale n'est pas une contrainte qu'on subit après coup. C'est ce qui fait qu'un revenu tient dans le temps. Votre app peut rapporter beaucoup. Encore faut-il qu'elle reste en ligne pour le faire.
Et la question que je pose à chaque créateur qui me montre son tableau de bord : si demain votre régie publicitaire disparaissait, combien de vos revenus survivraient ? La réponse en dit plus long que n'importe quel modèle économique sur le papier.
