iOS et Android, une seule base.
Une base commune fait gagner du temps sur l’essentiel et n’efface pas les différences : les notifications, les achats dans l’application et les règles des magasins restent deux mondes. On le sait au départ, ou on le découvre au refus.
React NativeFlutterExpoLes étapes, dans l’ordre.
- La base commune, et ses frontières. Ce qui se partage : écrans, navigation, appels réseau, état. Ce qui ne se partage pas : notifications, achats, permissions, et tout ce qui touche au système.
- Le lien avec votre back-office. Une API, une authentification qui survit à la fermeture de l’application, un fonctionnement correct en réseau faible. C’est là que se juge une application mobile.
- Les builds, dans un espace isolé. La compilation tourne sur une machine dédiée, jamais sur celle qui sert vos sites : un script d’installation fait ce qu’il veut.
- Les magasins. Fiches, captures, politique de confidentialité, comptes de test pour la revue. Le refus le plus fréquent n’est pas technique : c’est un formulaire incomplet.
À la fin, vous avez ça.
- Les applications iOS et Android, soumises aux deux magasins
- L’API et l’authentification mobile, éprouvées en réseau dégradé
- La chaîne de compilation reproductible, dans un espace isolé
- Les fiches des magasins, avec leurs captures et leurs mentions obligatoires
Les fonctionnalités qui servent ici.
Les questions qu’on nous pose.
Et s’il en manque une, le Discord répond plus vite que cette page.
Peut-on ne faire qu’une seule plateforme ?
Oui, et c’est souvent le bon départ. Mais la décision se prend sur vos utilisateurs réels, pas sur une préférence : regardez d’abord les statistiques de votre site.
Faut-il vraiment une application ?
La question mérite d’être posée avant le chantier. Si vous n’avez besoin ni des notifications, ni de l’appareil photo, ni du hors-ligne, un site installable fait le travail pour une fraction du coût — et il n’y a pas de revue à passer.
Qui tient les comptes des magasins ?
Le client, et c’est préférable : l’application lui appartient. Les jetons de publication restent chiffrés sur la machine de qui publie, et ne passent jamais par un serveur de Nexus.
Dans la même famille.
Application métier
L’outil interne qui remplace le tableur partagé : fiches, droits, historique, exports.
SaaS
Comptes, abonnements, facturation et tableau de bord : un produit en ligne, complet.
Espace client et extranet
Documents, suivi de dossier, messagerie : un accès sécurisé pour les clients.
API et microservices
Une API documentée, testée et versionnée, pour vos applications et vos partenaires.