Ce que j'ai appris en publiant plus de 20 applications Il y a deux sortes de chiffres dans mon parcours : ceux que je mets sur mon site, et ceux qui m'ont appris quelque chose. Ce ne sont pas toujours les mêmes.
Je m'appelle Noé Calmes, je conçois des applications mobiles et web pensées pour rapporter. J'ai publié plus de 20 applications mobiles, les miennes et celles de mes clients, et elles totalisent plus de 1,3 million de téléchargements. Voici ce que j'en ai retenu, dans l'ordre où je l'ai compris, avec les chiffres réels.
1,3 million de téléchargements, et ce que ce chiffre ne dit pas
C'est le genre de chiffre que je mets en avant sur mon site, parce qu'il impressionne et parce qu'il est vrai. Mais il ne dit presque rien de ce qui compte.
Un téléchargement, c'est quelqu'un qui a appuyé sur un bouton gratuit. Il n'a rien promis. Il ouvrira peut-être l'application une fois, peut-être jamais. C'est le chiffre qu'on regarde en premier, parce que c'est celui que les stores affichent et celui que tout le monde comprend.
Ce que j'ai fini par voir : le téléchargement est le chiffre qui flatte, pas celui qui renseigne . Ce qui dit si une application va rapporter, c'est ce que l'utilisateur fait le lendemain, et la semaine d'après. C'est la sixième des raisons que j'ai détaillées dans pourquoi 90 % des applications ne rapportent rien , et c'est la première que j'ai apprise.
300 000 utilisateurs et presque pas de chiffre d'affaires
J'ai conçu la première version de Hush, une messagerie, pour ses créateurs. Elle a dépassé 300 000 utilisateurs. Sur le papier, c'est le genre de succès qu'on raconte. Dans la réalité, elle ne rapportait presque rien, parce que personne, moi compris, n'avait décidé au départ à quel moment elle demanderait à être payée ni pour quoi. J'étais le concepteur : la question était à moi de la poser.
Ce que ça fait, concrètement : tu as énormément de monde, tu as des retours, tu as des avis, et tu n'as pas de revenu. Tu te dis que ça viendra avec le volume. Ça ne vient pas avec le volume. Un modèle de revenu ajouté après coup, sur une application que des centaines de milliers de personnes utilisent gratuitement, se heurte à une habitude déjà prise. La façon de le construire dans le bon ordre est dans comment rentabiliser une application mobile .
La question de Hush, celle que je pose depuis à chaque projet
Je ne commence plus un projet sans savoir où et quand l'utilisateur sort sa carte . Pas en fin de cadrage, au début. Si la réponse n'existe pas, le projet n'est pas prêt, et je le dis.
C'est la leçon qui m'a le plus appris, et c'est aussi pour ça qu'elle vaut quelque chose : je l'ai vue de l'intérieur, sur une application que j'avais conçue, pas dans un livre.
13 000 € par mois sur un marché saturé
Calorie est une application mobile de suivi nutritionnel avec l'IA, que j'ai conçue pour un client. L'idée est banale et le marché était déjà pris : il en existe des dizaines, et celle-ci n'avait rien de neuf sur le papier.
Elle lui rapporte aujourd'hui environ 13 000 € par mois, par abonnement. Pas parce que l'idée était meilleure que les autres. Parce que tout, dans l'application, est construit autour du moment où l'utilisateur comprend ce qu'elle lui apporte, puis du moment où on lui propose de payer. Les premiers écrans l'amènent à la valeur vite. L'écran qui propose l'abonnement arrive quand il a déjà une raison de dire oui.
13 000 €
par mois, par abonnement, sur un marché que tout le monde disait pris.
Ce que ça m'a appris : l'idée n'est presque jamais le sujet . Deux applications avec la même idée peuvent avoir des revenus sans aucun rapport, et la différence ne se voit pas sur la liste des fonctionnalités. Elle se voit dans le parcours. J'ai détaillé les ordres de grandeur dans combien rapporte une application mobile .
Ce que mes propres applications, Wake Up Alarme et Plouff Habitudes, m'apprennent encore
Wake Up Alarme et Plouff Habitudes sont mes applications. Je m'en sers, et c'est ce qui me donne la vision de l'usage réel, celle qui sert ensuite à mes clients.
Parce qu'en usage réel, on voit ce qu'aucune maquette ne montre : l'écran qu'on ouvre vraiment le matin, celui qu'on ne regarde jamais, le réglage qu'on cherche trois fois avant de le trouver, l'écran qu'on ferme sans le lire. Un concepteur qui n'a plus d'application à lui finit par concevoir de mémoire, avec les habitudes d'il y a trois ans.
Ce que j'en retiens : ce qu'un utilisateur dit qu'il fera et ce qu'il fait n'ont pas grand-chose à voir. On conçoit pour ce qu'il fait.
Ce que l'arrivée de l'IA m'a appris sur mon propre métier
Quand les outils qui génèrent une application à partir d'une phrase sont arrivés, j'ai eu la réaction de beaucoup de gens de mon métier : regarder ce qu'ils faisaient vraiment. J'utilise l'IA tous les jours pour écrire du code, et j'ai écrit ce que je pensais de ces générateurs dans Lovable, Base44 et les applications mobiles .
Mais la vraie leçon n'était pas sur ces outils. Elle était sur moi : le code n'a jamais été ce qui coûte cher dans une application . Ce qui coûte cher, c'est tout ce qui a été décidé avant, et tout ce qui est mesuré après. Si une machine écrit le code en une heure, ça ne change rien à la question de Hush : où et quand l'utilisateur paie. Personne ne tape ça dans une phrase.
La leçon la plus récente : savoir dire non, et sur quel support
Le mobile est mon métier d'origine. Jusqu'à récemment, mon site ne parlait que de ça : quand on m'appelait pour « une application mobile », je faisais une application mobile, et je laissais passer le reste.
Aujourd'hui, une partie des projets qui m'arrivent n'ont pas besoin d'être sur un téléphone. Des professionnels qui travaillent assis devant un écran, plusieurs profils, un espace d'administration : c'est une application qui se sert sur ordinateur, une application web, et je le dis avant le devis. Et une partie des idées qui m'arrivent n'ont pas de réponse à la question de Hush : je le dis aussi, et le projet s'arrête là, avant d'avoir coûté quoi que ce soit.
C'est la chose que j'aurais le plus de mal à expliquer à celui que j'étais au début : le travail commence par ce qu'on refuse de construire .
Ce que je ne fais pas : amener les utilisateurs
Les 300 000 utilisateurs de Hush et les abonnés de Calorie, ce n'est pas moi qui les ai fait venir : c'est le travail de ceux qui portent ces applications. Je conçois le marketing dans l'application, ce qui transforme un utilisateur en client. Mon travail commence quand quelqu'un ouvre l'application, et il continue tant qu'il revient et qu'il paie. Avant, rien : la publicité, les réseaux, le référencement, ce n'est pas moi, et quelqu'un qui te promet les deux à la fois te promet trop.
Par où commencer
Si tu dois ne garder qu'une chose de ces vingt applications, garde la question de Hush, et pose-la avant tout le reste.
Écris où et quand ton utilisateur sort sa carte. Pas « il s'abonnera », mais à quel écran, après avoir obtenu quoi. Si tu ne sais pas l'écrire, tu n'as pas encore un projet, tu as une idée, et c'est très bien : c'est le moment de la travailler.Oublie le nombre de téléchargements, ou d'inscriptions, que tu imagines. Remplace-le par le nombre de personnes qui reviendraient la semaine suivante. C'est ce chiffre qui fait le revenu, et il est toujours plus petit.Demande à qui tu parles ce qu'il a vécu. Pas combien d'applications il a faites, mais ce qui a marché, ce qui a échoué, et ce qu'il en a changé. La réponse te dit tout.
Si tu veux que je regarde ton idée avec exactement ce regard, l'audit gratuit prend deux minutes, et la question de Hush y est posée noir sur blanc : tu sauras tout de suite si tu as déjà la réponse.
À lire aussi :
← Retour au blog Accueil · Concevoir une application qui rapporte · Ma méthode · Blog · Tester ton idée · FAQ