On a publié sur l'App Store et sur Google Play des applications qui n'ont rien en commun : un nettoyeur de photos, un compteur de fléchettes, un métronome qu'on sent au poignet, un scanner de documents. Les sujets changent, le chemin reste le même.
Voici ce chemin tel qu'on le suit au studio, étape par étape, avec ce que chacune de ces applications nous a appris.
Avant de créer une application mobile, vérifier l'idée
Presque toutes nos applications sont parties d'un agacement précis. Bone, notre compteur de jeux de dés, est né de parties de Yahtzee sur des applis si chargées de publicités qu'il fallait passer le téléphone en mode avion pour jouer tranquille. Bead vient du même constat côté fléchettes : des compteurs laids, pleins de pubs, et des modes de jeu qui manquaient.
Deckard, un entraîneur au comptage de cartes, est le cas inverse. On ne connaissait aucune application dédiée à cette pratique, et c'est en partie ce manque qui a lancé le projet.
Les deux situations se vérifient en 10 minutes. Ouvrez l'App Store, tapez ce que ferait votre application, et lisez les avis à une étoile des trois premiers résultats. Si les mêmes reproches reviennent et que vous savez y répondre, l'idée tient. Si personne ne propose ce que vous imaginez, cherchez pourquoi avant d'aller plus loin : parfois la place est libre, parfois personne n'en veut.
Écrire un cahier des charges court
Pour une première version, le cahier des charges tient en deux listes. La première dit ce que fait l'application. La seconde dit ce qu'elle ne fera pas encore, et c'est elle qui protège le budget. Chaque fonction ajoutée « tant qu'on y est » se paie en écrans, en développement et en tests.
Verdict, notre application de tri photo, montre bien l'exercice. Elle fait une seule chose : trier sa pellicule d'un geste par photo, pour garder, jeter ou décider plus tard. Tout le reste sert ce geste. La détection des doublons, les filtres par date ou par album, la confirmation avant toute suppression. Pas de compte à créer, et aucune photo ne quitte le téléphone.
Une liste aussi courte surprend souvent. Elle permet pourtant de sortir plus tôt, d'écouter les premiers utilisateurs, et de décider la suite sur ce qu'ils font plutôt que sur ce qu'on imaginait.
La maquette : dessiner chaque écran avant le code
On dessine tous les écrans, enchaînés comme dans l'application finale, et on les fait essayer au doigt sur un vrai téléphone. Une maquette se corrige en une heure. Le même changement sur une application déjà développée touche au code, aux données et aux tests, et prend facilement 2 ou 3 jours.
C'est à ce stade qu'on règle ce qui fait qu'une application se garde ou se désinstalle :
- Le premier écran. Il doit faire comprendre l'application sans tutoriel.
- Le geste principal. Celui qu'on répète cent fois, qui doit tenir d'une main sur le plus petit téléphone visé.
- Les écrans vides et les erreurs. Personne ne pense à les dessiner, tout le monde finit par tomber dessus.
Dans Bead, le geste principal consiste à toucher, sur une cible dessinée à l'écran, l'endroit où la fléchette s'est plantée. Une seconde façon de saisir existe aussi : un pavé numérique, pour taper directement le total de la volée.
iOS et Android : une base de code ou deux
Il faut décider comment l'application sera construite, et ce choix pèse sur le coût de chaque version suivante.
Une base commune pour la plupart des projets
Bead, Bone, Deckard, Zest et Pagelight sont écrites une seule fois, en React Native, puis publiées sur iPhone et sur Android. Les écrans, la logique et les tests sont partagés. Pour une application de jeu, de suivi ou de service, c'est presque toujours le bon choix : on dessine une fois, on corrige une fois.
Le natif quand l'application touche au matériel
Verdict a été développée deux fois, en Swift pour l'iPhone et en Kotlin pour Android. L'application parcourt toute la photothèque et compare les images sur l'appareil, sans rien envoyer. Sur iPhone, elle s'appuie directement sur les outils d'Apple pour la photothèque et l'analyse d'image.
Pulsar, le métronome qu'on sent, va plus loin. Il n'existe que sur iPhone et Apple Watch, parce qu'il repose sur le moteur de vibrations d'Apple, sur la montre, et sur la synchronisation de plusieurs iPhone en local pour qu'un groupe entier sente le même temps. Ces fonctions se programment au plus près du système, en Swift.
Développer et tester sur de vrais téléphones
On développe par morceaux utilisables, pas en un bloc livré à la fin. Vous installez l'application en cours de route, par TestFlight sur iPhone et par le test interne de Google Play sur Android, et vous voyez avancer quelque chose de réel.
Les tests se font sur de vrais appareils, pas seulement sur l'ordinateur. Le simulateur d'Apple, par exemple, ne joue aucune vibration : tester Pulsar sans un iPhone en main n'aurait rien prouvé. Il en va de même pour l'appareil photo, les notifications ou les performances sur un téléphone de quelques années.
Publier sur l'App Store et Google Play
La publication demande plus de préparation qu'on ne le pense. Il faut :
- Un compte développeur à votre nom : 99 $ par an chez Apple, 25 $ une seule fois chez Google.
- Une fiche : nom, sous-titre, description, mots-clés, catégorie.
- Une icône de 1024 pixels et des captures d'écran au format exigé, 1290 × 2796 pixels pour les grands iPhone.
- Une politique de confidentialité et une page d'assistance en ligne. Celles de nos applications sont publiées sur ce site.
Apple examine ensuite chaque version, en général en 1 à 2 jours. Les refus arrivent à tout le monde, et on en a reçu nous-mêmes. Les cinq motifs qu'on a rencontrés :
- des messages d'autorisation, pour l'accès aux photos ou à l'appareil photo, qui n'étaient pas dans la langue principale de l'application ;
- des premiers achats intégrés qui n'avaient pas été soumis en même temps que la version ;
- un écran d'abonnement sans lien vers les conditions d'utilisation et la politique de confidentialité ;
- un bouton « restaurer les achats » qui laissait croire qu'on pouvait récupérer des crédits déjà consommés ;
- des prix affichés sur les captures de la fiche.
Chacun a coûté un aller-retour avec Apple. On les vérifie désormais tous avant chaque soumission.
Après la publication
Une application vit par ses mises à jour : les retours des premiers utilisateurs, les nouvelles versions d'iOS et d'Android chaque année, les fonctions qu'on avait mises de côté. Prévoyez-les dès le départ, dans le budget comme dans le calendrier.
Si vous envisagez de créer une application mobile, même à partir d'une idée encore vague, c'est le bon moment pour en parler. On fait ce travail de bout en bout, du cadrage à la publication, et notre page sur la création d'application mobile détaille la méthode. Pour un premier avis sur votre projet, décrivez-le en quelques lignes : réponse sous 48 heures ouvrées.
BloomwiseÀ retenir