Créer une application mobile iOS et Android : de la maquette aux stores

Une application, ou un site qui marche bien sur téléphone ?

Une application se justifie quand le téléphone apporte quelque chose : la position, les notifications, l’appareil photo, l’usage hors ligne, ou la présence sur les stores. Sinon, un site bien fait suffit et coûte moins cher à faire vivre.

Trois cas tirés de nos projets :

• Tchee, la course à la demande pour Bamako : la position et le suivi en temps réel sont le produit.
• Votons : un quiz à swiper, pensé pour le pouce, publié sur iOS et Android à côté du site.
• Serres Tour App : des visites guidées sur carte, pour des visiteurs qui marchent dans la commune.

Natif, React Native ou web embarqué

Voie	Principe	Quand la choisir
Natif (Swift, Kotlin)	Deux applications, deux bases de code	Besoins très poussés sur un seul système
React Native avec Expo	Une base de code, des composants natifs	La plupart des applications
Web embarqué (Capacitor)	Une application web dans une enveloppe native	Un jeu ou un outil qui existe déjà en web

Tchee et Votons sont construits avec React Native et Expo. Starship Brick Clash, notre casse-briques, utilise Capacitor : une seule base de code pour iOS, Android et le web.

L’API d’abord

L’application n’est que la partie visible. Derrière, une API tient les comptes, les données et les règles. On la conçoit en premier, parce qu’elle sert aussi le site, le back-office et les futures versions.

Pour Tchee, cela veut dire deux applications (passager et chauffeur) qui parlent à la même API : demande de course, attribution, suivi, paiement.

• Appli passager
• Appli chauffeur
• Site
• Back-office

API

• Comptes
• Données
• Règles

Trois règles :

• l’API ne fait jamais confiance à l’application, elle vérifie tout ;
• elle est versionnée, parce que d’anciennes versions de l’application resteront installées des mois ;
• elle répond vite et peu, parce que le réseau mobile est lent et instable.

Concevoir pour le téléphone

• Le pouce. Les actions principales en bas de l’écran.
• Le réseau. Chaque écran prévoit le chargement, l’échec et le mode hors ligne.
• Les permissions. On demande la position ou les notifications au moment où elles servent, en expliquant pourquoi.
• Les langues. Serres Tour App existe en cinq langues, parce que ses utilisateurs sont des touristes.

Le paiement

Deux cas très différents.

Les biens et services réels (une course, un produit livré) se paient avec un prestataire comme Stripe. Il faut aussi regarder les usages locaux. Au Mali, la plupart des passagers paient en mobile money : Tchee accepte la carte et Orange Money, en francs CFA.

Les contenus numériques (un abonnement à l’application, des options) doivent le plus souvent passer par l’achat intégré d’Apple et de Google, qui prélèvent une commission. À prévoir dans le modèle économique dès le départ.

Publier sur les stores

À préparer tôt, parce que rien de tout cela ne se fait en un jour :

• 99 $Applepar an
• 25 $Google Playune seule fois

1. Les comptes développeur. Apple (99 dollars par an) et Google Play (25 dollars, une fois), au nom de la société.
2. Les fiches. Nom, description, captures d’écran par taille d’appareil, icône.
3. La confidentialité. Une politique publiée, et la déclaration des données collectées.
4. Un compte de démonstration pour les validateurs, si l’application demande une connexion.
5. Les tests. TestFlight sur iOS, les pistes de test sur Android.

Les refus les plus courants : une fonction incomplète, une permission mal justifiée, un moyen de paiement non conforme, pas de suppression de compte dans l’application.

Après la sortie

• Le suivi des plantages, version par version.
• Des mises à jour régulières : les systèmes évoluent chaque année, les stores imposent de suivre.
• Les avis, lus et traités.
• Une politique de version minimale, pour pouvoir retirer un jour les vieilles versions de l’API.