Pourquoi tant d'applications mobiles échouent : les 5 causes évitables

La plupart des applications mobiles échouent pour des raisons évitables : un problème que personne ne cherche à résoudre, une première version trop chargée, une rétention jamais pensée, une dette technique qui s'accumule et un abandon après le lancement. L'article détaille ces 5 causes et les 5 décisions concrètes qui vous en protègent.

Quand on lance son application, on regarde les réussites, rarement les échecs. Pourtant, beaucoup d'applications mobiles ne trouvent jamais assez d'utilisateurs pour durer.

Derrière ces échecs, il y a 5 causes récurrentes. Aucune n'a vraiment à voir avec le code. Aucune n'est due à « pas assez de fonctionnalités ». Voici la liste, et ce que vous pouvez faire pour ne pas tomber dedans.

Ce que veut dire « échouer » pour une application mobile

Avant d'attaquer les causes, il faut s'entendre sur la définition. Une application peut échouer de plusieurs façons :

• Échec de lancement : l'application sort, mais ne trouve presque personne. Pas de presse, pas de bouche-à-oreille, pas de référencement. Elle meurt en silence.
• Échec de rétention : l'application fait des téléchargements (parfois beaucoup, grâce à de la publicité payante), mais la plupart des utilisateurs l'abandonnent dans la première semaine. Le coût d'acquisition n'est jamais amorti, le modèle économique ne tient pas. C'est le sujet de l'article sur la rétention.
• Échec économique : l'application a des utilisateurs, mais ne rapporte jamais assez pour couvrir sa maintenance. Elle continue de tourner, mais reste un poids financier.
• Échec de continuité : l'application est lancée, rapporte de l'argent, puis la personne qui la porte abandonne. Pas de mise à jour, plus rien. Elle finit retirée des stores, faute d'avoir suivi les exigences d'Apple et de Google.

La cause d'échec n'est presque jamais celle qu'on imagine. Ce n'est pas « il manquait LA fonctionnalité magique ». C'est un mélange de mauvais diagnostic au départ, de première version mal calibrée, et de désengagement après le lancement. Décortiquons.

Cause 1 : le mauvais problème (résoudre quelque chose que personne ne veut résoudre)

C'est la cause numéro 1, et la plus difficile à accepter quand on porte l'idée. Beaucoup d'applications échouent parce qu'elles résolvent un problème qui n'existe pas vraiment, ou qui existe mais ne mérite pas une application dédiée.

Le piège : confondre « j'ai une idée que je trouve cool » et « il y a une vraie demande non satisfaite ». Une idée cool peut produire une démo cool. Mais elle ne produira pas d'usage régulier s'il n'y a pas de vraie gêne derrière.

Les 3 signaux qui annoncent ce piège

• Vous ne pouvez pas citer 5 personnes précises qui vivent ce problème, avec leur nom et leur contexte. Si vos exemples sont génériques (« tout le monde aimerait mieux organiser ses photos »), vous êtes dans le flou.
• Personne autour de vous ne vous arrache l'idée des mains. Quand vous décrivez le problème, les gens disent « c'est sympa » au lieu de « il me la faut, c'est pour quand ? ». Toute la différence est là.
• Vos premiers testeurs n'ouvrent pas l'application d'eux-mêmes. Ils l'utilisent quand vous leur rappelez. Ce n'est pas un signe de mauvais marketing, c'est un signe que le problème ne gêne pas assez.

Comment l'éviter

Avant d'écrire la première ligne de code, parlez à au moins cinq personnes qui vivent le problème. Ne leur demandez pas si votre idée leur plaît, elles diront oui : demandez comment elles font aujourd'hui. C'est l'étape 2 du guide gratuit.

Cause 2 : le MVP qui n'en est pas un (trop large, trop cher, trop long)

La deuxième cause, presque aussi fréquente, c'est la première version gonflée. Le projet démarre avec quatre fonctionnalités essentielles et arrive en développement avec dix-sept. Le budget et le délai suivent, à la hausse. Et personne ne se rend compte que le produit qui sortira n'est plus une première version : c'est une V2 sortie sans avoir testé la V1.

Pourquoi ça tue ? Parce qu'une première version sert à apprendre, pas à plaire. Elle doit être la version la plus petite qui permet de tester votre hypothèse principale. Si elle a 17 fonctionnalités, vous ne testez plus une hypothèse. Vous testez 17 choses en même temps. Et vous ne saurez jamais laquelle a fait le succès ou l'échec.

Le coût caché d'une première version gonflée : non seulement vous dépensez plus, mais vous repoussez de plusieurs mois la rencontre avec vos utilisateurs. Pendant ces mois, d'autres avancent, votre trésorerie diminue, votre fenêtre se referme.

Gardez quatre à cinq fonctionnalités

Pour une première version, gardez quatre à cinq fonctionnalités : celles sans lesquelles votre solution ne tient pas debout. Le test de l'étape 4 du guide gratuit est simple : retirez-en une ; si votre phrase de positionnement devient fausse, elle est essentielle, sinon elle attend dans une liste « plus tard ». C'est cette discipline qui rend possible le format MVP Momentum, à 9 500 € en 60 jours.

Cause 3 : la rétention jamais pensée (l'application qui se télécharge et se supprime)

Voici la cause la plus douloureuse, parce qu'elle frappe les applications qui ont réussi leur lancement. L'application fait 5 000 ou 50 000 téléchargements. On célèbre. Trente jours plus tard, il n'en reste qu'une petite partie.

Ce n'est pas un problème de marketing. C'est un problème de produit. L'application n'a pas été conçue pour être réutilisée, elle a été conçue pour être téléchargée. Les causes les plus fréquentes : un onboarding qui demande trop avant de donner, aucune raison de revenir le lendemain, un premier moment de valeur trop loin.

La rétention n'est pas une optimisation après le lancement, c'est une décision de départ. Les premières secondes sont détaillées dans l'article sur l'onboarding mobile, les raisons de revenir et les chiffres à suivre dans l'article sur la rétention.

Cause 4 : la dette technique invisible (l'application qui s'effondre sous son propre poids)

La quatrième cause est silencieuse, et vicieuse parce qu'elle ne se voit pas avant le lancement. C'est la dette technique.

Une application construite trop vite, sans validation au fil de l'eau, livre des fonctionnalités qui marchent chacune de leur côté mais qui se cassent quand on les combine. Les premiers utilisateurs déclenchent des bugs imprévus. Les notes négatives commencent à tomber sur les stores. On passe l'essentiel de son temps à corriger des urgences, et plus rien à faire avancer le produit.

Les signes classiques de la dette technique après le lancement

• L'application plante sur certains modèles Android moins courants. On découvre que la cible compte beaucoup d'utilisateurs sur ces modèles.
• La création de compte échoue de temps en temps sans message d'erreur clair. Vous ne l'auriez jamais vu en interne, parce que vos tests passaient.
• Les paiements dans l'application échouent par intermittence. L'utilisateur paie, ne reçoit pas son achat, écrit au support. Vous remboursez. Vous perdez du chiffre.
• Chaque mise à jour d'iOS ou d'Android casse quelque chose. Une partie de chaque trimestre passe à rattraper plutôt qu'à avancer.

La dette technique n'est pas un sujet abstrait : chaque évolution coûte un peu plus cher que la précédente, jusqu'au jour où plus personne n'ose toucher au code.

Cause 5 : l'abandon après le lancement (l'application qu'on ne maintient plus)

La cinquième cause est presque administrative. Apple et Google relèvent régulièrement leurs exigences techniques. Ils imposent des nouveautés (étiquettes de confidentialité, Data Safety, ATT, Privacy Manifests). Ils retirent les applications qui ne suivent pas. Une application qu'on ne maintient pas finit par disparaître des stores, sans bruit mais définitivement.

Voici un scénario type d'application abandonnée :

• Mois 0 : publication. Tout va bien.
• Mois 3 à 4 : Apple sort une nouvelle version d'iOS. Quelques utilisateurs signalent un comportement bizarre. Pas grave.
• Mois 6 : Google impose un nouveau niveau d'API minimum. Vos mises à jour sont bloquées tant que vous ne migrez pas. Vous reportez.
• Mois 9 : une bibliothèque Firebase devient obsolète, la compilation casse, l'abonnement développeur Apple est à renouveler.
• Mois 14 : l'application n'est plus proposée aux nouveaux utilisateurs sur les téléphones Android récents, parce qu'elle ne cible plus un niveau d'API assez récent.
• Mois 18 : elle fonctionne mal sur les téléphones récents, et les avis négatifs finissent de l'enterrer.

Ce scénario est si fréquent qu'il a un nom : app rot (le pourrissement d'une application). Et il est entièrement évitable avec une maintenance régulière. La vraie maintenance d'une app mobile se prévoit chaque mois dans votre budget, ou coûte 0 € si vous l'oubliez, avec à la clé la mort lente de votre projet.

C'est pour ça que chaque projet Zuhd Studio inclut 2 mois après la mise en ligne où tous les bugs sont corrigés sans frais. Ensuite, si vous le souhaitez, MVP Care prend le relais à 299 € par mois, sans engagement : bugs, mises à jour de sécurité et mises à jour imposées par Apple et Google. Les nouvelles fonctionnalités, elles, se chiffrent à part, sur devis.

Comment vous protéger des 5 causes en 5 décisions concrètes

Reprenons les 5 causes une par une, et associons à chacune une décision qui vous protège. Pas une intention : une décision concrète, prise avant le démarrage du projet.

Décision 1 : cinq conversations avant la première ligne de code

Vous ne signez pas de contrat de développement tant que vous n'avez pas parlé à au moins cinq personnes qui vivent le problème, et obtenu une description précise de ce qui les gêne. Si après ces conversations vous ne trouvez pas de gêne claire, votre idée n'est pas prête.

Décision 2 : quatre à cinq fonctionnalités, pas plus

Vous les écrivez noir sur blanc. Tout le reste va dans une liste « plus tard ». Pendant le projet, une nouvelle idée ne remplace pas l'une d'elles : elle rejoint la liste.

Décision 3 : la rétention au cadrage, pas après

Pendant le cadrage, vous définissez explicitement : (a) quel est le moment de valeur, (b) à quelle minute il arrive, (c) quelle raison fait revenir l'utilisateur le lendemain, (d) quel chiffre vous dira si la rétention tient à J+7. Si le cadrage ne contient pas ces 4 points, il n'est pas complet.

Décision 4 : une validation fonctionnalité par fonctionnalité

Vous exigez, par écrit dans le contrat, une validation fonctionnalité par fonctionnalité : chaque fonctionnalité vous est montrée et vous la validez avant que la suivante commence. Pas une livraison en bloc à la fin. Si le prestataire refuse, vous changez de prestataire. C'est le meilleur garde-fou contre la dette technique, décrite plus haut dans la cause 4.

Décision 5 : un plan de maintenance signé avant le lancement

Vous signez l'accord de maintenance avant la publication, pas après. Vous savez à l'avance combien il coûte par mois, ce qui est inclus, et en combien de temps on vous répond. Pour le savoir, demandez à votre prestataire un devis de maintenance avant même la fin du développement. S'il esquive, c'est un signal d'alerte. C'est aussi le dernier conseil de l'étape 7 du guide gratuit : inscrivez la maintenance dans votre budget dès le départ.

Le plan d'action à cocher du guide gratuit reprend ce qui protège des causes 1, 2, 3 et 5 : le problème écrit en une phrase, quatre à cinq fonctionnalités, la mesure d'usage et la remontée des plantages écrites dans le devis, la maintenance prévue dans le budget.

Le piège du « ça ne m'arrivera pas »

La plupart des gens dont l'application a échoué pensaient au début que « ça n'arrive qu'aux autres ». Pas par naïveté, mais par optimisme. Quand on lance, on a confiance, sinon on ne lance pas. Mais l'optimisme ne dispense pas du diagnostic.

Les 5 causes décrites ici ne sont pas des risques isolés. Elles s'additionnent. Une application qui ne vérifie pas son problème, qui sort une première version gonflée, qui oublie la rétention et accumule de la dette technique a très peu de chances d'aboutir. À l'inverse, une application qui passe ces 5 filtres met toutes les chances de son côté. Le marché mobile est exigeant sur la qualité du diagnostic et de l'exécution.

Si vous êtes en train de cadrer votre projet, prenez 30 minutes pour passer chacune des 5 causes en revue. Soyez honnête. Là où c'est encore flou, vous savez où concentrer votre énergie avant de signer avec un développeur.