Application mobile : pourquoi je choisis Expo et React Native

Faut-il vraiment une application ?

Non, pas toujours, et c'est la première question que je pose avant d'écrire la moindre ligne. Un site responsive bien construit couvre la grande majorité des besoins d'une PME ou d'un artisan : présence en ligne, prise de contact, catalogue, prise de rendez-vous. Le web s'indexe dans Google, se partage par un simple lien, ne demande aucun téléchargement. Une app, elle, impose un passage par les stores, une installation, des mises à jour. C'est une friction que le visiteur ne franchit que s'il a une vraie raison.

L'app devient pertinente quand le web atteint ses limites. Besoin du matériel de l'appareil : caméra exploitée en continu, GPS en arrière-plan, Bluetooth, capteurs. Notifications push fiables qui ramènent l'utilisateur. Usage hors-ligne réel, là où le réseau manque. Engagement répété au quotidien, où l'icône sur l'écran d'accueil a un sens. Si le client veut « une app » uniquement pour cette icône, je le redirige souvent vers une PWA, plus légère et installable sans store. On choisit la techno après avoir clarifié l'usage, jamais l'inverse.

Pourquoi React Native et Expo par défaut

Quand l'app se justifie vraiment, React Native avec Expo est mon choix par défaut, et pour des raisons de terrain. Une seule base de code TypeScript produit iOS et Android. Là où deux apps natives séparées demandent deux langages, deux équipes potentielles et deux fois la maintenance, je travaille une fois. Pour un budget de PME, ce gain de vélocité fait souvent la différence entre un projet qui sort et un projet qui reste en attente faute de moyens.

Expo prend en charge toute la chaîne pénible que personne n'aime gérer. Les builds tournent dans le cloud avec EAS, sans Mac de build à maintenir ni Xcode à dompter. La signature des binaires, la gestion des certificats, la soumission sur l'App Store et le Play Store sont outillées. Je partage aussi de la logique métier avec mes projets web, puisque c'est le même écosystème React et TypeScript : validations, types, appels d'API se réutilisent. Moins de plomberie, plus de temps sur ce qui compte pour le client.

Les mises à jour OTA changent la donne

L'argument qui emporte souvent la décision, c'est la mise à jour à distance. Avec EAS Update, je pousse un correctif JavaScript directement sur les appareils des utilisateurs, sans repasser par la validation des stores. Concrètement, un bug repéré en production le matin peut être corrigé chez tout le monde l'après-midi. Sur une app native pure, le même correctif attendrait la revue d'Apple, parfois plusieurs jours, pendant que les utilisateurs subissent le problème.

Cela ne dispense pas d'un vrai build quand on touche au code natif : ajout d'une librairie système, montée de version majeure, nouvelle permission. Mais pour le quotidien des petits correctifs et des évolutions d'interface, ce confort est énorme et change la posture face au risque. Je livre plus souvent, par petits incréments. Le natif pur garde sa place sur des cas précis : jeux exigeants, traitement graphique lourd, intégrations système très spécifiques, ou besoin du dernier SDK constructeur le jour de sa sortie. Pour tout le reste, React Native tient la route, y compris en performance avec sa nouvelle architecture.

Comment je structure une app Expo

Je pars sur Expo Router, un routage par fichiers cohérent avec ce que je fais en Next.js : un fichier devient un écran, l'arborescence dessine la navigation. Cette continuité me fait gagner du temps et rend le projet lisible pour quiconque connaît déjà mon front. J'isole la logique métier et les appels réseau dans des hooks et des services dédiés, je centralise le thème dans un design system partagé, et je garde les écrans fins : ils assemblent des composants, ils ne portent pas la complexité.

TypeScript strict dès le premier jour, ce n'est pas négociable : il attrape les erreurs avant l'utilisateur. Pour l'état, je reste léger, souvent Zustand pour l'état local et React Query pour les données serveur, selon le besoin réel plutôt que par habitude. Je sépare nettement les composants d'interface des composants connectés aux données. Et je câble EAS pour les builds et les updates dès le départ, avec des canaux de préversion pour que le client teste sur son propre téléphone avant publication.

Résultat : un projet qui passe de l'idée au store sans friction, maintenable dans la durée. Le client suit l'avancement sur un vrai appareil, valide écran par écran, et reçoit ses correctifs vite. C'est cette combinaison de vélocité et de robustesse qui me fait revenir à Expo et React Native sur la plupart de mes projets mobiles.