Il y a quelques semaines, Julien d’Android-France, a écrit un article coup de gueule contre le piratage des applications Android. Son article, bien écrit et magnifiquement illustré, appuie là où ça fait mal pour montrer l’hypocrisie des utilisateurs Android qui piratent pour 3€ maximum. Je vous laisse lire l’article si ce n’est pas déjà fait.
Je note tout particulièrement un argument contre le seul qui défendait le piratage que je n’arrivais pas à contrer : ceux qui n’ont pas de carte bancaire. Julien rappelle que des services de carte prépayée existe comme, par exemple, à La Poste.
J’aimerai aller un peu plus loin que son article, et que l’on analyse ensemble les différents business modèles qui existent dans le monde des applications mobiles. J’espère que les utilisateurs comprendront que des gens vivent de ces applications, ou que ça pourra donner des idées à certains développeurs qui se découragent à cause du piratage.
Cet article est publié en parallèle sur FrAndroid et sur le blog du Paris Android User Group. Pour ma part, au delà de mes engagements pour ces deux entités, j’ai rejoint professionnellement LevelUp Studio. Nous éditons Beautiful Widgets et Plume, chaque application basée sur un modèle différent. Et je développe le client Android de Footito, sur un modèle lui aussi différent. Je puiserai des exemples pour cet article de mes propres expériences.

Une image de gratuité qui colle à la peau

Android, mis en avant par l’Open Handset Alliance et Google comme un système open source, véhicule souvent une image de gratuité dont il est difficile de se détacher pour les développeurs tiers. On voit que l’Android Market est le magasin, toutes plate-formes mobiles confondues, qui a sa part d’applications payantes la plus faible.
Parmi ces applications gratuites, très peu ne sont là au final que pour la beauté du geste ou dans le simple intérêt de la communauté. Qu’elles soient en code source ouvert ou fermé, on trouve des applications faites le dimanche pour le plaisir, parce que l’utilisateur en avait besoin pour lui et qu’il a voulu la partager avec les autres, pour offrir une alternative à une autre payante, pour se faire une réputation… etc. Heureusement, on ne peut pas lister toutes raisons de faire une applications juste pour le geste.
Mais parce qu’il faut bien gagner sa vie en étant développeur, voyons ensemble les différents business modèles utilisés par les applications mobiles dans l’objectif de produire des revenus.

On paie à l’achat, un point c’est tout

Le premier, et plus évident, est celui de l’application payante. Actuellement, c’est le premier abordé par la plupart des projets mobiles. Il suffit de déposer son applications dans un magasin en déterminant une valeur que devront s’acquitter vos utilisateurs. Sur Android, la grande majorité des prix se situent entre 0,79 et 3€. On retrouve quelques exceptions comme les suites bureautiques et les navigateurs GPS qui peuvent atteindre plus de 50€. Personnellement, je trouve que dans la majorité des cas, ce modèle n’est pas adapté au monde virtuel. Cela fonctionne très bien quand un support physique est nécessaire à l’achat, mais cela devient très difficile à contrôler dans le cas de média digitaux. L’article évoqué en introduction parlait du cas de « monsieur-max » qui voyait 30 licences installées illégalement pour 1 achetée. Ce chiffre suffit à être très démotivant. Évidemment pour Android, des systèmes de protection existent. Mais ils nécessitent toujours Internet. Une application n’offrant pas cet accès ne pourra pas se protéger. De toute façon, une application Android peut facilement être « dé-packagée » pour en retirer la protection et la re-packagée. La nouvelle version ne peut pas être diffusée sur le Market, mais les réseaux alternatifs se débrouillent pour la distribuer sans aucun accord. Dans le cadre de Beautiful Widget, notre solution offre une protection supérieure, car ce n’est pas l’exécution de l’application qui est empêchée, mais l’envoi depuis notre serveur des « thèmes » qui font la valeur de l’application. Nous avons d’ailleurs décidé de distribuer gratuitement une version « lite » sans ces thèmes. Cette protection nous pose un problème de limitation des moyens de diffusion. En effet, nous ne pouvons pas la diffuser hors des deux markets que nous supportons, et ajouter un nouveau market est un peu long. Par exemple, nous ne pouvons pas facilement faire de campagne marketing où nous offririons des licences. Donc pour certains types d’applications, cette solution peut être la seule alternative, mais dans la majorité, ce n’est pas celle que je conseillerai si le combat contre le piratage vous fait peur.

 

Une version limitée gratuite pour promouvoir une complète payante

Le modèle dont le revenu vient uniquement de la vente de l’application vous tente toujours, malgré le précédent paragraphe ? Je vous propose le modèle lite/full. Comme je l’ai évoqué précédemment, c’est un modèle que nous avons décidé de mettre en place chez LevelUp Studio. Ce modèle a de nombreux avantages. Le premier est offrir une expérience gratuite à vos utilisateurs, la deuxième est de toujours obtenir des revenus par ceux qui veulent une expérience plus riche. Le boulot marketing de ce modèle est de trouver la bonne limite des fonctionnalités de la version lite. Il faut donner assez de fonctionnalités pour que les options manquantes ne frustrent pas l’utilisateur, mais qu’elles donnent suffisamment envie pour qu’une part suffisante passent à l’acte de l’achat. Pour vous aider à trouver cette limite, je pense qu’il faut que la version lite offre une expérience “limitée” mais pas dégradée. La subtilité est à ce niveau là. Le dernier intérêt est de permettre un vrai travail marketing par l’appel que peut créer la version lite. Malheureusement, on augmente les avantages mais on n’échappe pas aux défauts de la seule version payante. Les versions piratées seront sûrement moins diffusée mais elles empêcheront encore plus le passage à l’achat. L’obligation est toujours de protéger l’application.

Financé par la publicité

Le modèle suivant est aussi un modèle très utilisé : celui de la publicité. L’objectif de la régie de publicité, la société qui fourni les publicités au développeur, dicte la façon donc est calculée la rémunération. Les calculs les plus représentés sont le CPA (cout par action), le CPC (cout par clic), et le CPM (cout pour mille). Le CPM est le moins rémunérateur. Il représente un prix pour un millier d’affichage, juste d’affichage de la publicité. C’est en général utilisé pour marketter un message fort, ou pour des marques dont l’image est déjà forte. Le CPC, le plus utilisé, est rémunérateur quand l’utilisateur clique sur la bannière. Malheureusement, c’est aussi celui qui est le plus triché par les développeurs. En positionnant la publicité à des endroits stratégique l’utilisateur cliquera sans le vouloir. Ce n’est bon pour personne. Ni pour la régie qui a des faux, ni pour l’utilisateur dont l’expérience est dégradée. Le CPA est très rémunérateur car il paie quand le clic à déclenché une action (un achat souvent). Mais il est aussi très difficile à atteindre. La publicité doit être ciblée pour être efficace est c’est souvent difficile. Dans le cas de Plume, nous avons décidé de mettre la publicité en tête de liste. Cela nous parait positif pour l’utilisateur car cela ne déclenche pas de clic involontaires, et positif pour nous car les revenus nous paraissent intéressants. Le gros avantage de cette version c’est de ne pas nécessiter de protection. Vous pourrez diffuser l’application au plus grande nombre. Et même mieux, plus vous la distribuerez plus elle vous sera rémunératrice. Malheureusement, la publicité a une image de marque des plus négative. Comme dit précédemment, c’est un moyen de rémunération qui est détourné sur Internet et maintenant sur mobile. Donc c’est souvent mal vu de mettre de la publicité sur une application. De plus, depuis quelques temps, on trouve des outils de protection contre la publicité, ça peut s’apparenter à du piratage de votre application. Vous décidez d’être rémunéré par la pub, mais vos utilisateurs décident que ça ne leur va pas et empêchent votre choix. C’est moins moche, car souvent involontaire, mais le résultat est le même. Le seul conseil que je peux donner est de positionner intelligemment votre publicité. Surtout, ne la mettez pas à un endroit qui soit au dessus du contenu. Pensez par exemple aux têtes de listes, aux écrans de chargement, ou aux écrans de paramétrage. Comme je vous l’ai dit, avec l’essor des bloqueurs de publicités et le détachement de quelques régies majeures, les revenus de publicités peuvent facilement tomber.

Aujourd’hui, un nouveau modèle vient de faire son apparition, plus puissant que le SMS et bien plus ciblé, il s’agit de la notification push. Ce nouveau format de publicité permet de segmenter et de cibler plus finement avec du contenu riche (textes, images, liens vers vidéos ou sites mobiles, questionnaires, coupons de réduction géolocalisés) et d’analyser en temps réel les résultats d’une campagne. Ce type de format permet également de ne cibler que les utilisateurs opt-in pour éviter de spammer ses utilisateurs. C’est un des formats les plus rémunérateurs, très efficace, néanmoins l’offre est encore bien trop pauvre. En France, Surikate est la première régie à proposer ce format dans l’offre SK.Reach.

Le contenu payant, ça paie.

Un autre modèle est en plein essor est le paiement in-app. Dernièrement, Google offre un outil in-app lié à l’Android Market, mais il existe d’autres possibilités comme Paypal ou Zong. Ce système est très utilisé par les jeux vidéos. Cela permet d’acheter des niveaux, des objets, des solutions, etc. Mais on peut créer de nouveaux business hors du jeu, en payant pour du contenu vidéo par exemple, un abonnement, l’accès à des données. Au final, dans notre société de consommation, tout peut être monnayé. Pour donner toutes les chances à l’application, je vous conseillerai de bien évidemment faire très attention à la valeur monétaire donnée à chaque objet, mais surtout de bien choisir votre paiement. Chaque plate-forme ne produira pas le même effet sur l’achat. Par exemple, plus l’utilisateur doit interagir pour confirmer le paiement plus il risque d’annuler son achat. De même, en discutant avec de nombreux acteurs, j’ai compris que le paiement sur la facture amène à moins de réflexion que par la carte bleue. Selon moi, ce business modèle est le assez risqué. Il dépendra de votre capacité à provoquer l’achat. Si vous n’y arrivez pas, vous distribuerez gratuitement une application dont vous attendez des revenus… qui n’arrivent pas. L’avantage c’est que le piratage ne posera pas de problème.

D’autres business modèles plus inaccessibles existent.

 

 

Une offre de service qui s’étend sur Android

L’application mobile peut être une simple extension de votre service. Dans le cas des opérateurs téléphoniques, il parait évident qu’ils développent des applications pour leurs clients. Et la valeur de l’application vient de la possibilité de se démarquer de la concurrence par elle. De la même façon, de plus en plus de média offrent un accès à leur contenu par une application mobile. Pour l’instant, faire une application mobile c’est se démarquer, dans quelques temps, ce sera aussi nécessaire que de faire un site web.

Dans le cas de Footito, l’application sert à donner un intérêt supplémentaire au site web. L’objectif est d’inciter par le smartphone à revenir encore plus régulièrement sur le site.
Dans ces modèles, l’application ne produit pas de revenus par elle même, mais elle sert de cataliseur à un autre produit.

 

Les autres peuvent parier sur vous

Tout le monde a entendu parler de MyMajorCompany ? Mais si, ce site communautaire où les artistes sont financés par les internautes. Y a des, heu, grands artistes qui sont sortis, comme Grégoire. Il existe la même chose pour Android. Que ce soit par des sites généralistes comme KissKissBankBank, ou plus spécialisé comme Games Plant pour les jeux vidéos. Ce type de site peut être la première étape d’une belle aventure de start-up.

 

Si on prend le meilleur de chaque modèle ?

Pour finir sur les différents modèles, je voudrais proposer une petite cuisine de tout cela. Pour moi, le modèle qui peut convenir au plus de situation est celui de la combinaison du in-app et de la publicité intelligente. L’intérêt est que chacun comble les défauts de l’autre. La publicité apporte un revenu régulier. Le in-app peut apporter plus de volume. On peut ainsi mettre en place une publicité non agressive qui sera mieux perçue par les utilisateurs et par la régie. Je pense que c’est un excellent compromis qui peut être mis en place dans une plus large part d’applications.

 

Pour conclure cet article.

Pour les développeurs, faites travailler votre imagination. Vous venez de la faire travailler pour produire votre application, profitez de l’élan pour trouver la bonne équation qui vous permettra de dégager un revenu. Mais attention, je ne promets pas l’eldorado. La mobilité est clairement dans une bulle. Tant qu’elle grossit de nombreuses structures pourront grossir avec elle. Mais à l’image de l’explosion de la bulle Internet il y a 10 ans, quand la bulle mobile explosera 80% des acteurs seront laissés sur la touche. Gardez toujours à l’esprit qu’une application a une visibilité de 6 mois, mais une entreprise a besoin d’une visibilité de 3 ans. Donc si vous n’êtes pas le problème du détournement d’application, soyez entreprenant, devenez en la solution.
Pour les utilisateurs, la prochaine fois où vous penserez au petit nombril de votre porte monnaie, demandez vous si, dans le cadre de vos activités (ou celle de vos parents), vous aimeriez que vos rémunérations baissent pas par votre choix mais par celui de vos clients. Donc quand vous choisirez à la place du développeur la valeur de son application, c’est lui que vous méprisez. Et le problème c’est bien le détournement des applications et pas les développeurs.

J’espère que cet article aidera les développeurs et ouvrir les yeux des utilisateurs. J’espère que vous prêcherez la bonne parole à votre tour 😉

ps : en écrivant cet article, je me suis posé une question, les développeurs pourront peut-être m’aider. Peut-on lire à l’exécution la clé public qui authentifie la signature ? Cela permettrait de l’envoyer au moment des requêtes réseau pour ne prendre en compte côté serveur que les applications non piratées.

ps2 : Merci à Maxime, Julien, Eyal, Quang-Hai, Vidal et ceux que j’oublie pour leur contribution