// Application mobile · React Native

Une app mobile qui sert votre opération,
pas l'inverse.

Je construis des applications React Native (iOS + Android) pour les TPE et PME qui ont un vrai besoin opérationnel : équipes terrain, apps client B2C, compagnons SaaS B2B, MVP startups. Diagnostic du flux humain avant la première ligne de code. Code à vous, documentation à vous, comptes stores à vous.

Voir les cas d'usage

// Quand une app mobile a du sens

Une application mobile n'est pas un upgrade automatique d'un site web. Elle a du sens quand l'usage est récurrent (plusieurs fois par semaine), quand on a besoin de fonctions du téléphone (caméra, GPS, scan, notifications push), ou quand le contexte d'utilisation impose un format mobile dédié (terrain, mouvement, mode hors ligne). Si aucune de ces trois conditions n'est remplie, un site web responsive ou une PWA suffit — et coûte 3 à 5 fois moins cher.

// 4 cas d'usage

Ce que je construis (et pour qui).

01

Apps métier pour équipes terrain

Chauffeurs, livreurs, techniciens, commerciaux mobiles. Personnes qui travaillent debout, dans une voiture, ou sur un site client.

Exemple : Dispatch, l'app chauffeur que j'ai construite pour une startup de mobilité (React Native + Firebase + n8n). Tracking GPS, courses en temps réel, statut live.

02

Apps client B2C

Marques avec un programme de fidélité, un catalogue, ou un compte client qui justifie une app plutôt qu'un simple site mobile.

Cas typique : commerce avec carte de fidélité numérique, scan en magasin, notifications promo ciblées, historique d'achats accessible hors ligne.

03

Apps SaaS B2B compagnons

Vous avez déjà un SaaS web qui marche, et vos utilisateurs réclament une app mobile pour les actions rapides (notifications, validation, accès express).

Cas typique : SaaS de gestion documentaire qui ajoute une app pour signer un document depuis le téléphone, ou recevoir une alerte quand une signature arrive.

04

MVP startups (validation marché)

Vous testez un produit avant une levée ou un investissement plus lourd. L'app doit prouver une traction mesurable en 3-6 mois, sans surinvestir.

Approche : périmètre minimal validé avec vous, build en 4-6 semaines, analytics dès le jour 1 pour mesurer les vrais usages avant d'étendre.

// Stack technique

React Native par défaut. Et pourquoi.

Je construis avec React Native + Expo dans 80 % des cas. Le reste du temps, je vous oriente vers Flutter (spécialiste partenaire) ou je propose une PWA si le besoin n'exige pas une vraie app native.

React Native + Expo

  • → Une seule base de code TypeScript pour iOS + Android
  • → Accès complet aux fonctions natives (caméra, GPS, push, biométrie)
  • → Économie de 40-60 % vs développement natif Swift + Kotlin
  • → Build et déploiement stores via Expo EAS
  • → Si vous avez un site Next.js que j'ai construit : code partagé (auth, API, types)

Ce que je ne fais pas

  • → Apps gaming ou 3D intensives (Unity/Unreal sont mieux)
  • → UI ultra-personnalisée avec animations complexes (Flutter est meilleur)
  • → Apps nécessitant des SDK natifs Swift/Kotlin propriétaires non documentés
  • Pour ces cas, je vous oriente vers un spécialiste de mon réseau.

// Comment je structure le projet

Quatre étapes. Toujours dans cet ordre.

01

Simplifier

2 jours d'observation du flux réel. Qui utilise l'app, dans quel contexte (debout, en marchant, en conduisant), pour quelle décision. Identification des écrans qui n'ont aucune raison d'exister. Sans cette étape, on construit 12 écrans au lieu de 5.

Livrable · Cartographie du flux utilisateur + liste des écrans à coder (et à NE PAS coder)

02

Optimiser

Maquettes des écrans clés sur Figma. Validation avec les vrais utilisateurs (pas avec le décideur seul). Le critère n'est pas l'esthétique : c'est le nombre de taps pour accomplir l'action principale. Une app métier réussie tient en 2-3 taps par action.

Livrable · Maquettes Figma cliquables + scénarios testés sur 3-5 utilisateurs cibles

03

Construire

Sprints de 2 semaines. À chaque fin de sprint, démo de ce qui marche réellement sur un téléphone (pas juste sur simulateur). Vous testez en main entre chaque sprint. Pas de surprise au lancement parce qu'on n'attend pas la fin pour montrer.

Livrable · App testable installée sur votre téléphone à chaque fin de sprint (TestFlight iOS, Play Console interne Android)

04

Lancer

Soumission App Store + Play Store (3-7 jours de revue Apple, plus court côté Google). Configuration analytics. Formation 2h des utilisateurs internes. Suivi 3 mois inclus pour les bugs et premiers ajustements remontés du terrain.

Livrable · App publiée sur les 2 stores + dashboard analytics + manuel utilisateur PDF

// Étude de cas

Dispatch · App chauffeur pour une startup de mobilité.

Écosystème complet : application React Native / Expo pour les chauffeurs (Android), dashboard web pour l'admin, automatisations n8n pour les flux de communication, backend Firebase pour le temps réel. Tracking GPS, gestion des courses live, communication multi-canal (in-app + SMS + email).

L'app pensée pour l'usage conducteur (gros boutons, peu de clics, info critique visible). Les tâches répétitives automatisées pour libérer l'admin.

Lire l'étude de cas complète

// Tarifs

Sur devis. Voilà pourquoi.

Je ne publie pas de prix d'entrée. Une app simple (3 écrans MVP, sans backend) n'a rien à voir avec une app fonctionnelle (auth + backend custom + intégrations + soumission stores). Afficher « à partir de 4 990 € » serait honnête sur 20 % des projets et mensonger sur 80 %.

Fourchettes indicatives (sans engagement)

  • MVP simple · 3-5 écrans, 1 fonction métier, sans backend custom · 4-6 semaines
  • App fonctionnelle · auth + Firebase + push + 8-12 écrans · 8-12 semaines
  • App complexe · multi-rôles, intégrations tierces, soumission stores · 12-20 semaines

Process : diagnostic gratuit 45 min → cadrage du périmètre → devis détaillé sous 5 jours ouvrés → 30 % d'acompte / 60 % à la livraison / 10 % à la passation. Toutes les factures en HT, franchise de TVA (article 293 B du CGI).

// Questions fréquentes

Tout ce qu'on me demande avant de signer.

React Native, Flutter ou PWA : quelle différence pour mon projet ?

+
Trois technos pour trois usages différents. **React Native** (ce que j'utilise par défaut) : une seule base de code JavaScript/TypeScript pour iOS + Android, accès complet aux fonctions natives du téléphone (caméra, GPS, notifications push, biométrie). Idéal pour 80 % des projets TPE/PME. Économie de 40-60 % vs développement natif pur. **Flutter** (Google, langage Dart) : meilleures performances pour UI sur-mesure avec beaucoup d'animations, mais plus loin de l'écosystème web. Je vous oriente vers un spécialiste Flutter si votre besoin justifie cette stack. **PWA** (Progressive Web App) : votre site web installable sur le home screen du téléphone. Pas d'app store, pas de notifications iOS (Apple bloque encore en grande partie). Bon pour un MVP ultra-rapide ou pour une app qui ne sert qu'occasionnellement. Ma règle : on choisit la techno après le diagnostic du besoin, pas avant.

Combien de temps pour livrer une application mobile ?

+
Entre 4 semaines (MVP simple) et 16 semaines (app complexe avec backend custom). **MVP 3-5 écrans, 1 fonction métier, sans backend custom** : 4-6 semaines. **App fonctionnelle 8-12 écrans, auth + backend Firebase + notifications push** : 8-12 semaines. **App complexe multi-rôles, intégrations tierces, soumission stores** : 12-20 semaines. À chaque sprint de 2 semaines, vous avez une version testable sur votre téléphone via TestFlight (iOS) ou Play Console interne (Android). Pas d'attente jusqu'à la fin pour voir ce qui se construit.

Faut-il publier sur l'App Store, le Play Store, ou les deux ?

+
Les deux dans la majorité des cas, sauf besoin spécifique. App Store (iOS) : audience plus restreinte (28 % du marché smartphone en France), mais utilisateurs avec un panier moyen plus élevé. Soumission Apple = 3-7 jours de revue avec règles strictes. Play Store (Android) : 71 % du marché en France, soumission Google plus rapide (souvent 24-48 h). Moins de friction sur les règles éditoriales. Exception : app métier interne déployée uniquement chez Apple ou uniquement chez Google, sans passage par les stores publics (distribution via MDM ou TestFlight / Play Console interne). Possible et parfois plus rapide.

Comment je garde le contrôle après la livraison ?

+
Le code source est à vous, sur votre GitHub, avec documentation complète. Ce que vous récupérez à la passation : - Repo GitHub avec accès admin - Documentation technique (architecture, stack, dépendances, commandes de build) - Accès aux comptes développeurs Apple + Google (à votre nom, pas au mien) - Manuel de mise à jour basique (changer un texte, une couleur, ajouter un écran simple) - Suivi 3 mois inclus pour les bugs critiques et premiers ajustements Si vous voulez gérer la maintenance en interne après les 3 mois : votre dev peut reprendre. Si vous voulez que je continue : forfait maintenance mensuel sur devis (mises à jour stores, corrections, petites évolutions).

Faut-il un backend dédié pour une app mobile ?

+
Ça dépend de ce que l'app fait. Trois cas typiques. **Pas besoin de backend** : app qui consomme uniquement des données publiques (API tierces, contenu statique). Rare en pratique. **Firebase (Google) suffit** : besoin d'authentification, base de données temps réel, notifications push, storage de fichiers. Couvre 70 % des projets TPE/PME. Économie de 4-8 semaines de dev backend. **Backend custom nécessaire** : logique métier complexe, intégrations multiples, contrôle total sur les données (RGPD strict, secteurs régulés). On part sur Next.js API routes ou un serveur Node dédié, hébergé sur Vercel ou un VPS européen. Le choix se fait après le diagnostic, pas avant.

Vous travaillez à distance ou en présentiel ?

+
Les deux selon le projet, avec une préférence remote pour la phase build. **Diagnostic et observation terrain** : présentiel idéal pour les apps métier internes (chauffeurs, techniciens). Je passe 1-2 jours sur place pour voir le flux réel, parler aux utilisateurs, comprendre les contraintes physiques (gants, soleil, écran cassé, batterie morte). Cette étape ne se fait pas en visio. **Phase design + build** : 100 % remote. Sprints de 2 semaines avec démo en visio à chaque fin de sprint. Vous testez l'app entre les sprints sur votre téléphone. **Lancement + formation** : présentiel selon le besoin (formation utilisateurs en groupe). Sinon, formation en visio + manuel PDF. Déplacements possibles : Paris, Île-de-France, Lyon, Bordeaux pour la France · Kinshasa et Afrique francophone selon la mission.

On parle de votre projet d'app ?

45 minutes de diagnostic gratuit. On regarde si une app a vraiment du sens pour votre besoin, et si oui, lequel des 4 cas d'usage colle. Vous repartez avec une vision claire.

Voir mes réalisations