Création d'application mobile React Native

Ce que veut dire « créer une application mobile » chez nous

Une application mobile, ce n'est pas une maquette exportée puis codée. C'est un produit qui doit démarrer en moins d'une seconde, tenir la charge sur un téléphone d'entrée de gamme de 2021, survivre à une perte de réseau dans le métro, passer la validation d'Apple et de Google, et rester modifiable dans dix-huit mois par quelqu'un d'autre que nous.

On prend un projet du cadrage jusqu'à la publication sur l'App Store et Google Play, backend compris. Concrètement, ça veut dire : les parcours utilisateurs, le design produit, le développement React Native pour iOS et Android, la base de données et l'API, les notifications push, les paiements in-app, l'analytics, la mise en ligne, et le suivi après le lancement.

Pourquoi React Native — et quand ce n'est pas le bon choix

React Native permet d'écrire une seule application qui tourne sur iOS et sur Android. L'économie est réelle : un seul code à écrire, un seul à tester, un seul à maintenir. Mais l'argument qui compte le plus sur la durée est ailleurs. L'écosystème JavaScript et TypeScript est le plus large du marché, ce qui veut dire que vous trouverez toujours quelqu'un pour reprendre votre application. C'est une garantie de continuité que peu de technologies mobiles offrent.

Depuis la New Architecture (Fabric, TurboModules) et le React Compiler, l'écart de performance avec le natif a pratiquement disparu pour les usages courants. Les animations tournent sur le thread UI via Reanimated, les listes affichent des milliers d'éléments sans saccade, et quand un besoin sort vraiment du cadre — un widget système, une caméra sur mesure, du traitement d'image — on écrit le module natif nous-mêmes en Swift ou en Kotlin. C'est exactement ce qu'on a fait sur Ash, avec un widget iOS en Swift et un module Expo en Kotlin.

Reste l'honnêteté du choix. React Native n'est pas la bonne réponse partout. Si votre produit repose sur du calcul 3D temps réel, sur du traitement audio à très faible latence, ou sur une intégration système profonde qui n'existe que d'un côté, le natif reste supérieur. Si vous êtes une équipe déjà installée sur Dart, Flutter est un excellent choix. On vous le dira plutôt que de vous vendre notre stack — un projet mal orienté au départ coûte bien plus cher qu'un devis perdu.

Ce qu'on livre, concrètement

• Le cadrage — utilisateurs, périmètre, contraintes techniques, indicateurs de succès. On sort avec un plan et un budget au forfait.
• Le design produit — parcours, maquettes, prototype cliquable, système de composants et d'interactions. On valide l'expérience avant la première ligne de code.
• L'application — React Native et Expo, TypeScript strict, New Architecture, animations Reanimated, navigation, gestion d'état et cache de données.
• Le backend — le plus souvent Supabase : schéma Postgres, politiques de sécurité RLS, stockage de fichiers, fonctions serveur, authentification.
• Les briques produit — notifications push, abonnements et achats in-app, analytics et tunnels de conversion, liens profonds, internationalisation.
• La mise en ligne — pipeline de build, certificats, fiches store, captures, soumission et suivi de la validation Apple et Google.
• Le code — le dépôt est à vous, documenté, sans dépendance à un outil maison.

Combien de temps, et combien ça coûte

Un MVP mobile bien cadré se livre en 8 à 12 semaines : environ une semaine de cadrage, deux semaines de design, six à huit semaines de développement, une semaine de publication. Vous avez un build installable sur votre téléphone dès la quatrième semaine, puis une démonstration chaque vendredi. Rien ne se découvre à la fin.

Sur le budget, on chiffre au forfait après le cadrage, jamais avant. Ce qui fait vraiment varier le prix, dans l'ordre : le nombre de parcours utilisateurs distincts, la présence ou non d'un backend à construire, le temps réel, les paiements, les modules natifs sur mesure et l'IA. Une application de contenu avec authentification et abonnement n'a pas le même coût qu'une application de terrain avec géolocalisation en arrière-plan et fonctionnement hors ligne.

Notre méthode, en quatre phases

01 — Cadrage

Une semaine pour comprendre le produit, les utilisateurs, les contraintes et les priorités. On repart avec un périmètre écrit, une architecture cible et un budget ferme.

02 — Design produit

Deux semaines de parcours, de maquettes et de prototype cliquable. On teste la navigation avant de développer, parce que c'est là que les corrections coûtent le moins cher.

03 — Développement

Six à huit semaines en sprints hebdomadaires, avec une démonstration chaque vendredi et un build de test dès la semaine quatre. Vous voyez l'application grandir, vous n'attendez pas une livraison surprise.

04 — Publication et suivi

Soumission sur l'App Store et Google Play, analytics et surveillance des plantages, puis trente jours de support inclus. Ensuite, maintenance au forfait ou cycles d'évolution, selon votre besoin.

Ce qu'on a déjà construit

Quatre applications React Native publiées, dont trois développées et éditées par le studio. Ce sont nos meilleures références parce qu'on les fait vivre nous-mêmes : mises à jour, suivi des performances, itérations sur la conversion.

Questions fréquentes

Faut-il deux applications séparées pour iOS et Android ?

Non. Une seule base de code produit les deux applications. On adapte ce qui doit l'être — conventions de navigation, permissions, widgets système, règles propres à chaque store — pour qu'aucune des deux ne donne l'impression d'un portage.

Qui possède les comptes développeur ?

Vous. On publie sur vos comptes Apple Developer et Google Play Console, que vous gardez. C'est important : celui qui détient les comptes détient la distribution de votre application.

Peut-on commencer par une version réduite ?

C'est même ce qu'on recommande. Un périmètre resserré, publié et confronté à de vrais utilisateurs, vous apprend plus en un mois que six mois de spécifications. On construit la version suivante à partir de ce que disent les données, pas des suppositions.

Travaillez-vous avec des équipes techniques internes ?

Oui, régulièrement. On peut mener le projet de bout en bout, ou renforcer une équipe existante sur la partie mobile pendant que vos développeurs restent sur le web ou l'API.