Avant de créer une application mobile : les sept questions à se poser

Une application n’est pas un site en plus petit

C’est la question la plus désagréable, et la plus utile. Une application n’est pas une version plus sérieuse d’un site : c’est un objet différent, avec un coût d’entrée différent. L’utilisateur doit chercher, télécharger, autoriser, et garder de la place sur son téléphone.

Elle se justifie quand il y a usage répété et valeur ajoutée réelle : notifications, fonctionnement hors réseau, appareil photo, géolocalisation continue, fidélité. Elle ne se justifie presque jamais quand le besoin est de présenter une offre, prendre un rendez-vous ou publier des actualités. Dans ces cas, un site vitrine bien conçu fera mieux, pour beaucoup moins cher.

Le test simple : vos utilisateurs l’ouvriront-ils au moins une fois par semaine ? Si la réponse honnête est non, l’argent est mieux placé ailleurs.

Le problème que vous résolvez, en une phrase

Pas une liste de fonctionnalités. Une phrase. Permettre à mes clients de réserver un créneau en trois gestes, même sans réseau. Donner à mes techniciens de terrain un carnet de chantier photo qui se synchronise le soir.

Si la phrase n’existe pas, l’application n’existe pas encore : elle existe comme envie, pas comme projet. Et une envie non cadrée devient, en développement, une facture qui gonfle sans que personne ne comprenne pourquoi. Nous passons souvent la première rencontre entière sur cette phrase. C’est du temps gagné.

Qui l’utilisera vraiment

Pas votre cible marketing : vos utilisateurs. Quel âge, quelle aisance technique, quel téléphone, quelle qualité de réseau. Une application destinée à des artisans en déplacement dans les vallées de Savoie ne se conçoit pas comme une application destinée à des étudiants en ville fibrée.

• Le parc d’appareils : uniquement des modèles récents, ou aussi des Android d’entrée de gamme de 2019 ? Cela change le socle technique et le budget de test.
• Les conditions d’usage : mains gantées, plein soleil, une seule main, sous-sol sans réseau ?
• Le niveau de tolérance : un salarié utilisera un outil imparfait s’il est imposé. Un client, non. Il désinstalle.

Ce qui est vital, et ce qui est du confort

L’erreur la plus fréquente consiste à vouloir sortir la version complète du premier coup. C’est le meilleur moyen de dépenser tout le budget avant d’avoir rencontré un seul utilisateur réel.

La démarche saine isole le cœur : la fonction sans laquelle l’application n’a aucun sens. Nous la construisons bien, nous la mettons entre de vraies mains, nous observons. Puis nous ajoutons, en sachant cette fois quoi ajouter.

• Vital : sans cela, l’application n’a plus d’objet.
• Important : améliore nettement l’usage, peut attendre la version suivante.
• Confort : personne ne l’a demandé, l’idée vient de nous.

Notre expérience : la première catégorie contient rarement plus de trois lignes. Le reste est du confort déguisé en nécessité.

À qui appartiennent le code, les comptes et les données

Cette question se pose avant la signature, jamais après. Vérifiez noir sur blanc :

• Le code source vous est-il livré, et sous quelle licence ?
• Les comptes développeur Apple et Google sont-ils créés à votre nom, ou à celui du prestataire ?
• Le nom de domaine, l’hébergement et la base de données sont-ils à votre nom ?
• Où sont hébergées les données de vos utilisateurs, sous quelle juridiction, et récupérables sous quel format ?

Un projet propre est un projet dont vous pouvez partir. Si changer de prestataire signifie tout reconstruire, quelque chose n’a pas été fait honnêtement. C’est le même réflexe que pour un site : nous en parlions déjà dans ce qui fait vraiment varier le prix d’un site.

Le coût de la vie, pas seulement celui de la naissance

Une application n’est pas un livrable, c’est un organisme vivant dans un environnement qui bouge sans vous demander votre avis. Chaque année, il faudra compter l’abonnement développeur Apple, renouvelable, sans lequel l’application disparaît de l’App Store. Les mises à niveau imposées par les plateformes, qui relèvent régulièrement la version minimale ciblée. L’hébergement, si l’application communique avec un serveur. Et les corrections liées aux nouveaux appareils et aux bibliothèques abandonnées.

Une règle de prudence largement partagée dans le métier : prévoir chaque année entre quinze et vingt-cinq pour cent du coût de développement initial. Ce chiffre n’est pas une fatalité, mais il doit être dit avant, pas découvert après. Nous détaillons ce point dans notre article sur le budget d’une application.

Comment les gens la trouveront

Publier n’est pas diffuser. Une application déposée sur les stores sans stratégie est une lettre postée sans adresse. Trois choses à anticiper : le référencement dans les stores, où le nom, le sous-titre et les premières captures décident tout. Le canal réel, car si vos utilisateurs sont vos clients existants, l’application se diffuse par courriel, sur place ou par QR code, pas par la recherche dans l’App Store. Et le premier lancement, ce que voit l’utilisateur avant d’avoir créé un compte, où se joue la majorité des abandons.

Ce que nous faisons de ces sept questions

Nous ne vendons pas d’application. Nous accompagnons des projets, et il arrive que la conclusion honnête d’une première rencontre soit : vous n’avez pas besoin d’une application, vous avez besoin d’un meilleur site. Nous le disons.

Quand l’application se justifie, ces sept réponses deviennent la colonne vertébrale du cahier des charges. La suite est un choix technique, que nous détaillons dans native, hybride ou PWA. Vous restez maître de chaque décision : nous éclairons le chemin, nous ne le choisissons pas à votre place.

Notre page création d’application smartphone détaille la prestation, et vous pouvez nous écrire directement pour en parler simplement.