Votre application mobile a été téléchargée 500 fois, et personne ne l'ouvre deux fois
Cinq cents installations, quarante utilisateurs actifs à sept jours. Le problème n'est presque jamais le code, mais la conception. Voici comment on décide, avant la première ligne, qu'une application mobile sera ouverte une deuxième fois.
Vous avez financé une application mobile. La console affiche cinq cents installations, puis la courbe redescend et ne remonte plus. L'application est toujours sur le téléphone de vos clients, entre une banque et un jeu. Personne ne l'ouvre deux fois.
Ce n'est presque jamais un problème de code. C'est un problème de conception : le projet a été pensé comme une livraison, pas comme un usage.
Je construis des systèmes web et mobiles pour des PME et des startups en France, en Belgique, en Suisse et au Canada, depuis Cotonou. Dans la plupart des briefs mobiles qu'on me présente, la première question posée est celle du framework. La bonne question est ailleurs.
L'installation mesure la curiosité, pas la valeur
Une installation est un clic. Elle récompense une campagne, une note sur la fiche, un article. Elle ne dit rien de ce que votre application apporte.
Une application installée puis abandonnée coûte plus cher qu'une application jamais écrite. Elle occupe votre backlog, génère du support, stocke des données personnelles dont vous êtes responsable, et installe l'idée que le mobile ne marche pas chez vous.
Ce que je regarde en premier dans un audit : la rétention à J7 et à J30, et le nombre d'ouvertures par utilisateur et par semaine. Sur un outil métier, en dessous de trois ouvertures hebdomadaires par utilisateur actif, le produit n'est pas utile. Il est consultable.
Conseil concret : avant de signer un devis mobile, écrivez une phrase qui commence par « mon utilisateur ouvre l'application parce que ». Si vous n'arrivez pas à la terminer sans citer votre marque, vous financez de la communication. Budgétez-la comme telle.
Un usage récurrent se décide avant la première ligne de code
Trois questions, posées dans cet ordre, évitent la plupart des échecs.
À quelle fréquence le besoin revient-il ?
Un besoin quotidien justifie une application. Un besoin trimestriel justifie un espace client web, un email clair et un lien. Beaucoup d'applications de PME sont des espaces clients déguisés, et l'utilisateur le sent : il n'installe pas 40 Mo pour consulter une facture deux fois par an.
Que voit l'utilisateur dans les trois premières secondes ?
L'application s'ouvre pour une raison précise. Si l'écran d'accueil affiche un carrousel institutionnel, un menu de dix entrées et une demande de connexion, l'utilisateur referme. Le premier écran doit exposer l'action utile : le scan, la commande en cours, la tournée du jour, le solde.
Qu'est-ce qui le ramène sans effort ?
C'est le rôle des notifications, et elles doivent être liées à un événement qui concerne personnellement l'utilisateur : sa commande est prête, sa demande a été traitée, son rendez-vous approche. Une notification qui annonce une promotion générale se désactive en trois jours, et une fois désactivée, elle ne revient pas.
Conseil concret : lancez votre première version avec trois écrans et une seule notification automatique. Vous ajouterez le reste quand la rétention tiendra.
Les quatre causes d'abandon que je rencontre le plus
L'application recopie le site, en moins complet. L'utilisateur a déjà le site. S'il retrouve la même chose avec un clavier plus petit, il n'a aucune raison de rester. Une application utile ne résume pas le site, elle fait ce que le site fait mal : photographier, scanner, géolocaliser, notifier, fonctionner hors ligne.
L'authentification est une épreuve. Mot de passe à créer, double validation à chaque ouverture, session expirée. Chaque étape fait perdre des utilisateurs définitivement. Un lien de connexion par email, une session longue et la biométrie suffisent dans la plupart des cas métier.
Le backend n'existe pas vraiment. Une application sans données à jour est une brochure. Sans API solide, sans gestion des comptes, sans synchronisation, l'utilisateur constate vite que l'information est figée et retourne sur le web.
Personne ne mesure. Sans indicateurs d'usage, vous pilotez à l'impression. Je branche la mesure dès le départ, parce qu'une fonctionnalité sans indicateur survit par attachement, pas par résultat.
Ce que je change dans la façon de cadrer
Je pars de l'usage, pas de l'écran. Je définis l'événement qui déclenche l'ouverture, le parcours minimum pour l'atteindre, puis les indicateurs qui diront si ça marche. La technique vient après.
Sur la pile, je reste sobre : un backend unique en Laravel qui sert le site, l'application et les intégrations, une API propre, et Expo / React Native quand le besoin est réellement mobile. Cette architecture évite les doubles saisies et les trois back-offices à maintenir. Le détail est sur mon offre applications mobiles iOS et Android.
Le raisonnement vaut aussi pour les systèmes métier. Sur Tikehub, l'enjeu n'était pas d'ajouter une application à une billetterie existante : un organisateur devait vendre, encaisser et suivre sans assembler cinq outils. Chez IZYGO, le site et le CRM interne partagent le même socle, ce qui évite à l'équipe de ressaisir une demande de devis ailleurs.
Mesurer ce qui compte
Quatre indicateurs suffisent : la rétention à J7 et J30, la fréquence hebdomadaire d'ouverture, le taux de réussite de l'action principale, et le coût par utilisateur actif. Une application se juge sur son usage, pas sur son nombre de téléchargements.
Pour la collecte, restez propre. Une application mobile traite des données personnelles, et le cadre européen s'applique dès que vous visez la France, la Belgique, la Suisse ou le Canada. La CNIL encadre les applications mobiles et rappelle les points de vigilance sur la finalité et la minimisation. Côté outillage, Firebase Analytics couvre la plupart des besoins de mesure, et les recommandations de qualité Android donnent une bonne grille de relecture avant publication.
Conseil concret : fixez un seuil d'abandon écrit avant le lancement. Si la rétention à J30 passe sous 15 %, aucune nouvelle fonctionnalité pendant un mois : vous travaillez le parcours existant.
Conclusion
Une application mobile réussie ne se mesure pas aux téléchargements, mais au nombre de fois où on l'ouvre sans y penser. Cela se décide tôt : fréquence du besoin, simplicité du premier écran, qualité du backend, justesse des notifications. Le framework et la campagne de lancement viennent après.
Si vous avez déjà une application qui dort sur les téléphones et que vous voulez savoir où le parcours casse, je peux regarder votre cas et vous dire ce qui bloque en priorité. Demandez un diagnostic : réponse sous 24 h, avis franc et première piste d'action.
Comment savoir si mon application mobile est réellement utilisée ?
Regardez trois chiffres, pas un seul : la rétention à J7 et à J30, le nombre d'ouvertures par utilisateur et par semaine, et le taux de réussite de l'action principale pour laquelle l'application existe. En dessous de trois ouvertures hebdomadaires par utilisateur actif sur un outil métier, vous avez une vitrine, pas un outil. Ces données se collectent sans être intrusif, à condition de définir les événements à suivre avant la mise en production.
Faut-il développer en natif ou avec React Native ?
Cela dépend de ce que l'application fait, pas de la mode. Si vous devez utiliser intensément la caméra, le Bluetooth, la biométrie, le hors ligne ou des notifications poussées, React Native et Expo couvrent très bien le besoin et vous font gagner du temps sur les deux plateformes. Le natif pur se justifie pour des performances graphiques lourdes ou des intégrations système profondes, ce qui est rare en PME. Dans les deux cas, la vraie question reste le backend : une application sans données fiables échoue, quel que soit le framework.
Que faire d'une application déjà en ligne que personne n'ouvre ?
Ne commencez pas par ajouter des fonctionnalités. Reprenez le parcours existant : ce que voit l'utilisateur à l'ouverture, le nombre d'étapes avant l'action utile, la qualité des notifications et la fraîcheur des données. Dans la majorité des cas, deux ou trois corrections ciblées relancent l'usage sans réécrire l'application. Un diagnostic de quelques jours suffit à identifier le point de rupture et à décider entre corriger, réduire le périmètre ou arrêter le produit.
