Application mobile : son poids et ses demandes décident plus que ses fonctions

Cet article s’adresse à quelqu’un qui a déjà tranché la question précédente : une application est bien la bonne réponse, l’usage est répété, les gens vous connaissent. Il ne recommencera donc pas le débat.

Il traite ce qui vient ensuite et qui décide en réalité du sort du projet. Une application n’est presque jamais abandonnée pour ce qu’elle fait mal ; elle est abandonnée avant, pendant les deux minutes qui séparent la décision de télécharger de la première utilisation réelle.

Ces deux minutes contiennent trois obstacles que le développement traite comme des détails techniques et que l’utilisateur vit comme des questions : combien cela va me coûter en données, pourquoi dois-je créer un compte, et pourquoi demandez-vous cela.

Trois décisions, prises dans les premières semaines d’un projet, et à peu près impossibles à défaire ensuite. C’est le sujet de cet article, et c’est pour cela qu’il parle si peu de fonctionnalités.

Demander la création d’un compte avant toute utilisation est la décision qui coûte le plus d’utilisateurs, et elle est presque toujours prise pour de bonnes raisons internes.

Elle se défend par le besoin de connaître ses utilisateurs, de synchroniser, de sécuriser. Toutes ces raisons sont réelles et aucune ne justifie de placer la demande au premier écran, avant que la personne ait vu ce qu’elle obtient.

La question à se poser fonction par fonction est : est-ce que celle-ci a besoin de savoir qui est cette personne ? Consulter un catalogue, un horaire, une carte, une disponibilité : non. Passer une commande, voir un historique, recevoir quelque chose : oui.

La bonne architecture est donc en deux temps, et elle demande un peu plus de travail : tout ce qui se consulte est ouvert, et le compte est demandé au moment exact où il devient nécessaire, avec la raison affichée à côté de la demande.

Un cas particulier fréquent en Algérie mérite d’être nommé : l’inscription par numéro de téléphone avec code de vérification. Elle est plus légère qu’un mot de passe et elle a un coût réel — un message qui n’arrive pas est un utilisateur perdu sans recours. Prévoyez toujours une seconde tentative et un autre canal. C’est trois jours de développement et cela récupère des gens qui, autrement, n’avaient aucun moyen de vous le signaler.

Le débat habituel porte sur la technologie : une base de code commune ou deux applications distinctes. C’est une vraie question et ce n’est pas la première.

La première est de savoir s’il faut les deux. Beaucoup de projets lancent simultanément sur les deux plateformes par symétrie, alors que leur public est très majoritairement sur l’une — ce qui double le coût de construction, de test et surtout d’entretien pour une fraction des utilisateurs.

La réponse ne se devine pas, elle se lit : votre site vous dit déjà, depuis des mois, quelle plateforme utilisent les gens qui vous consultent. C’est une donnée que vous avez et que personne ne regarde avant de décider.

Sur la technologie elle-même, la règle de décision est l’usage du matériel. Une application qui affiche, saisit et envoie fonctionne très bien avec une base commune ; une application qui exploite intensivement l’appareil photo, les capteurs ou l’arrière-plan finit par payer cher son intermédiaire.

Et il y a un coût que les devis omettent presque toujours : chaque plateforme a son processus de publication, ses règles et ses délais de validation. Ce n’est pas du développement, c’est de l’administration récurrente, et elle doit apparaître dans le budget annuel. Elle se compte en jours par an et elle ne disparaît jamais.

Entre la décision de chercher votre application et son installation, il y a une page que vous n’écrivez pas vous-même, ou plutôt que vous écrivez sans y penser : la fiche du magasin.

Elle porte quatre choses qui décident : le nom, la première phrase, les premières images, et la taille. Le reste du texte est lu par une minorité et sert surtout à être trouvé.

Les images sont ce qui est réellement regardé, et l’erreur commune est d’y mettre des captures d’écran brutes. Ce qu’il faut montrer est ce que l’application permet de faire, dans l’ordre où quelqu’un s’en servira, avec un mot par image. Quatre images conçues ainsi valent mieux que huit captures fidèles.

Le nom compte plus qu’on ne croit parce qu’il est cherché. Un nom de marque seul suppose qu’on vous connaisse ; un nom de marque suivi de ce que fait l’application est trouvé par les deux publics.

Enfin, les avis du magasin obéissent aux mêmes règles que partout ailleurs dans cette série : ils sont écrits par ceux à qui il est arrivé quelque chose, la réponse utile est courte et factuelle, et le bon moment pour en demander un est juste après une action réussie — jamais au lancement.

Ce que nous refuserons : mettre une création de compte sur le premier écran. Nous savons que cela simplifie l’architecture et que cela remplit une base d’utilisateurs plus vite ; c’est aussi la décision qui perd le plus de gens, et nous préférons construire l’ouverture en deux temps.

Nous refuserons aussi de demander une permission au démarrage. Chacune sera demandée au moment de l’usage, avec sa raison affichée, et le refus sera traité comme un chemin normal plutôt que comme une panne.

Nous refuserons enfin de livrer une application sans budget d’entretien annuel écrit. Une application sans entretien ne se dégrade pas lentement : elle cesse d’être installable, et vous l’apprendrez par un client.

Ce que nous faisons : un plafond de poids fixé avant la première ligne, une première ouverture qui montre quelque chose d’utile avant de demander quoi que ce soit, un comportement défini pour la connexion lente, perdue et revenue, les comptes de publication à votre nom, et une distinction écrite entre les mises à jour qui ajoutent et celles qui sont le prix de rester en ligne.

Et ce que vous devriez faire sans nous cette semaine : regardez dans les statistiques de votre site la répartition de vos visiteurs entre les deux plateformes mobiles. C’est gratuit, la donnée existe déjà depuis des mois, et elle vous dira peut-être que vous n’avez besoin que d’une des deux applications que vous alliez faire chiffrer.